关于带有分页的Double Entry Accounting系统存在一个非常严重的问题，我认为这很普遍，但是我仍然没有找到解决我问题的方法。

您可以使用此链接来阅读简单的Double Entry Accounting系统，就像我用Laravel和AngularJS制作的系统一样。

在此系统中，预期结果(例如)如下所示：

ID      In       Out    Balance

1      100.00    0.00   100.00

2       10.00    0.00   110.00

3        0.00   70.00    40.00

4        5.00    0.00    45.00

5        0.00   60.00   -15.00

6       20.00    0.00     5.00

如果将所有交易显示在一页中，则很容易在累积函数中跟踪余额，最后一笔交易的余额是一天结束时的当前余额。

例如，对于特定日期范围$fromDate-> $toDate，我们喜欢：

$balanceYesterday = DB::table('journal')->where('date', '

->join('transactions','transactions.journal_id','journal.id')->where('transactions.type',"=", 0) /* 0 means the account of the company */

->select(DB::raw('SUM(amount) as total_balance'))

->first()->total_balance;

现在我们有了昨天的余额，我们依靠它来计算累积循环中直到此过程结束为止的余额，直到$toDate；

$currentBalance = $currentBalance + $currentTransaction->amount;

$currentTransactionBalance = $currentBalance;

现在，当您有大量交易时，真正的问题就开始了，您需要将它们分页$journal = $journal->paginate(100);，假设每页100个交易，系统将按预期工作在第一页，因为我们已经可以计算并依靠它来计算每次交易后到首页中100笔交易结束时的新余额。

下一页将出现一个问题，即它不知道第一页中上一个事务的最后余额是多少，因此它将再次从$balanceYesterday开始，从而使整个表的计算错误。

我首先要解决的问题是，将最后一个事务amount(在前端)作为参数传输到下一页，并将其用作重新计算的起始金额，这是我拥有的最佳解决方案仅使用<< PREV和NEXT >>按钮，因此很容易修复它。

但是我最近发现，如果我对页码进行分页，则此解决方法将不起作用，因为用户希望浏览各个页面以浏览日记，因此现在无法知道特定页面的最后余额，并且系统将显示错误的计算。

我想做的是找到一种方法来计算特定交易的余额，不管是贷方还是借方，我正在寻找一种方法来知道在特定交易中完成特定交易后的余额是多少到目前为止，我不想添加新的余额列，也不想在其中保存余额，用户不时对交易进行了大量修改和修改，而所有小额修改都会对所有交易造成破坏平衡之后，我不能以任何方式依赖交易ID，因为交易可能具有不同的随机日期，因此将不会按ID进行排序，但可能会按日期，帐户所有者或类型等其他字段进行排序。 。

我一直在这个问题上摸爬滚打大约4个月，我在网上搜索并没有找到解决方案，我希望在经过这么长时间的解释后，我的问题已经很清楚了，希望有人可以为我提供解决方案。

谢谢。

您永远不应该依赖ID值的顺序，这些ID值仅用于标识单个记录，而不用于排序等。在这种情况下，排序顺序是按日期排序，但是我不知道您对相同日期的条目会做什么因为他们的顺序是不确定的。

我从不依赖它们，我先按日期排序，然后再按ID排序以保存同一天进行的交易的正确顺序，感谢上帝，我们不使用小时或分钟，仅使用日期：|

但是，当您按日期排序时，所有具有相同日期的条目都是未定义的，因此您不能按日期排序。并写道：您不能依赖ID的订单，它是未定义的顺序。

我不明白为什么我不能按日期排序，请查看此屏幕快照以了解情况，我们不在乎特定日期的交易时间，同一天进行的交易均以其默认顺序排序。 image.ibb.co/kW90U7/Screen_Shot_2018_04_15_at_02_09_59.png

数据库的结果集仅具有未定义的顺序作为默认顺序。因此，如果按日期排序，则具有相同日期的所有记录都是未定义的顺序。无论如何，这可能有点太理论化了，在您的情况下，请先按日期排序，然后再按ID排序，因为没有重复的ID，所以实际上应该这样做。

我相信，此时您真正需要的唯一一件事就是计算从分页数据集(所有记录，而不仅仅是当前页面的记录)开始到当前页面上显示的第一条记录之前的所有事务的总和。

通过查找整个数据集的开始与当前页面的事务之间发生的事务数，然后通过LIMIT检索它们并将它们加起来，可以得到此结果。

您首先要拥有的是分页查询的确切约束。由于我们要获取除当前页面以外的其他分页记录子集，因此您需要确保两个查询的结果都在相同的顺序中。重用查询构建器对象可以有所帮助(调整以匹配您的实际分页查询)：

$baseQuery = DB::table('journal')

->join('transactions', 'transactions.journal_id', 'journal.id')

->where('date', '>', $fromDate)

->where('date', '

->where('transactions.type',"=", 0)

->orderBy('date', 'asc');

// Note that we aren't fetching anything here yet.

然后，获取分页的结果集。这将执行两个查询：一个查询记录总数，第二个查询特定页面的事务。

$paginatedTransactions = $baseQuery->paginate(100);

从这里，我们可以确定检索先前余额所需的记录。返回的分页对象是LengthAwarePaginator的实例，该实例知道总共有多少条记录，页数，其上当前页等。

使用这些信息，我们可以做一些数学运算来获取所需的记录数：

total records needed = (current page - 1) * records per page

假设用户在第5页上，他们将看到记录401-500，因此我们需要检索以前的400条记录。

// If we're on Page 1, or there are not enough records to

// paginate, we don't need to calculate anything.

if ($paginatedTransactions->onFirstPage() || ! $paginatedTransactions->hasPages()) {

// Don't need to calculate a previous balance. Exit early here!

}

// Use helper methods from the Paginator to calculate

// the number of previous transactions.

$limit = ($paginatedTransactions->currentPage() - 1) * $paginatedTransactions->perPage();

现在我们有了在数据集中但在当前页面之前发生的事务数，我们可以再次使用基本查询来检索和计算总和：

$previousBalance = $baseQuery->limit($limit)->sum('amount');

Adding a highlight here to explain that using your database to perform the SUM calculations will be a big performance benefit, rather than doing it in a loop in PHP. Take advantage of the DB as often as you can!

将此余额添加到原始的"昨天"余额中，对于分页交易，您应该有一个准确的期初余额。

注意：理论上所有伪编码的内容都可能需要调整。如有疑问或问题，很高兴进行修改。

谢谢，我忍不住要哭，因为这几乎是一个完美的解决方案，但是从理论上讲，因为当您调用$previousBalance = $baseQuery->limit($limit)->sum(amount);时它正在计算当前页面中的项目数量，就像您调用->paginate时那样publicating?值，即使将$paginatedTransactions保存为临时值并调用分页方法，它也会以某种方式影响$ baseQuery结果！

伙计，我爱你，非常感谢您提供的出色解决方案，我通过使用Request()->get(page)和自定义$perPage值计算$limit解决了该问题，并且在计算$previousBalance之后运行了分页功能，因此它不会影响结果，谢谢:(

查看Builder::paginate()，看起来确实可以进一步修改构建器。您也可以使用clone关键字来复制基本查询构建器，以防止出现这种情况。很高兴我能帮上忙！

你真的做到了，你很棒，谢谢。

您应该能够为每个记录的余额制定一个真值陈述，只要您可以知道在该有序列表中的每个点上计算余额总和的顺序是什么。

确保这样做会带来巨大的开销，因为您需要查询整个表以显示每条记录，但是首先必须能够做到这一点。如示例所示，只要不分页就可以。

对于分页，您可以做的是预先计算每条记录的余额并将其相对于原始记录进行存储。这样可以对数据进行非规范化，但是这样做的好处是创建分页非常简单。

谢谢，我只是在发布时编辑我的问题，我是说我不想将余额保存在新列中，我之前尝试了一段时间，结果非常糟糕，用户正在更改交易金额不时出现，也就是修改后的总余额。.我一直在寻找一种动态的方法。

他们为每条记录制定真理声明，并为每条记录运行。对于额外的列：重新计算在更改或添加记录集时需要重新计算的那些，请参见数据库触发器。然后，您的数据库将解决此问题。

我已经尝试过了，在更改或插入上一个版本后，我使用了编辑和插入触发器来修改余额。迄今为止，对于5万种日记(= 10万笔交易)，性能结果不佳。.该系统还在存储前几年的数据。我对此很困惑。

不要感到困惑。由于存在大量数据，因此需要花费一些时间来处理它。就是这样。您无法免费获得所有这些操作。但是，在簿记中不允许用户编辑现有记录或为已关闭的时间段添加或删除记录是没有意义的。因此，从理论上讲，您永远都不要修改已关闭年份的余额-这就是过去。因此，您可以一次计算整个过去无问题的余额。如果事情成为过去，那么您也可以计算该跨度。那应该减少caclulcations的数量。

当然！这是关于此系统的主要思想，在所有类似的系统中，都不应修改，就好像您犯了一个错误一样，您应该添加一个COUNTER事务来解决该错误。即使我们关闭了过去的工作并且仅在当年工作，我们也必须允许用户根据其业务类型对我们进行强制性的修改，并且在一年中只有很多要计算的内容，并且用户需要他所说的活动的GOD模式可随时修改任何内容。