Balance assignment on date #2274
Conversation
This will help keep balance assertions/assignments consistent when transactions are be out of order.
The balance of virtual accounts reflects postings from the same real account, and not vice-versa. The same should be true for postings in the same transaction.
|
It is part of the design of Ledger that anything syntactic is based on the actual ordering of transactions in the journal, and not the meaning of things like "dates" — even though I agree that this can become counter-intuitive at times. My suggestion would be to use Ledger itself to sort the data that you import, so that your balance assertions can be applied to the expected transactions, rather than to add new logic like this to Ledger itself, since no other aspect of Ledger incorporates design elements like this. |
|
@jwiegley, now that you mention it, I agree that ordering by date for the purpose of balance assertions is completely arbitrary. However, I still do not quite understand how to achieve the use case in the OP by "using Ledger itself to sort the data that you import"; perhaps you can explain further. Keep in mind that the imported data is already sorted, and the manual section of the journal is also practically sorted. But when the two sections are combined by Running Because of this error, it is not even possible to "use Ledger itself to sort the data that you import". And even if the error wasn't an issue, that workflow would require running a pass to merge the manual/generated sections every time I update the journal, which is not user friendly at all. |
|
Perhaps it would be possible to add a command line option to specify the sort order to use for evaluating balance assertions. That way, evaluating it based on the date is not arbitrarily hard-coded. |
|
Since the desired (default) behavior is to evaluate balance assertions based on the original order of transactions, I think it would be good to add a test case for that. (It's just a bit odd that I made this PR without breaking any existing test cases.) |
|
You are right that including from two sources creates an impossible scenario for the current implementation. This is why I created support for UUID-based shadowing: If two transactions, possibly in different files, have the same UUID metadata tag (i.e., UUID: some-string-you-create), Ledger will check that they are equal (except for soft data, like balance assertions), but otherwise all but the first are ignored. This allows you to track the same transaction by multiple "views", such as in different files and with a different balance assertion on each, so long as the amounts reflected and the UUID are identical. |
|
That is an interesting idea to use the UUID tag. If I do that, would I have to keep around all the old versions of the generated file and manually include the most recent version before each balance assertion? |
I don't think I fully understand this question. Why wouldn't you keep around all past data? |
"Keeping around all past data" and "keeping around all old versions of a file" are very different. If I use the UUID feature instead of the filtered balance assertion, then my example above would turn into this: Notice that I have to keep all the old versions of the generated file even though newer versions contain all the same data. |
|
I see. There is another recent PR that offers the ability to print hashes of entry data, that would be stable in this situation and could be used as the UUID... |
This changes the behavior of balance assignment/assertion to take into consideration the date of the posting. When computing the account balance for the purpose of balance assignment, the account postings are filtered to only include those that occur on or before the date of the balance assignment.
My practical use case is I have a journal file that is automatically generated/updated by a script, and then I include this generated journal in my main journal. So it is quite normal for my larger journal to appear out of order as some generated transactions are more recent than some manually entered transactions even though all the generated transactions appear first in the journal. Before this PR, a balance assignment in the manual part of the journal would be affected by newer transactions in the generated journal. On top of that, the posting amount that is computed from the balance assignment would change each time I update the generated journal. This PR fixes this so I can use balance assignments in the manual journal and they will only be affected by transactions from the generated journal that have an earlier (or same) date.
Unfortunately, this does not help me put balance assignments in the generated journal as they will never be affected by postings that are parsed later (in the manually-entered part of the journal). Doing so could lead to ambiguities in computing balance assignments.
As a bonus, I fixed a bug that was left over from PR #1857. And I fixed #2273 even though I am still only 95% sure that it was broken in the first place as I haven't yet seen any comments on that issue.