--historical uses period-end valuations of prices, while --cumulative doesn't
#2205
Comments
the-solipsist
added
severity2
the-solipsist
changed the title
--historical uses period-end valuation of prices, while --cumulative does not--historical uses period-end valuations of prices, while --cumulative doesn't
|
I will definitely check it out, thanks! |
simonmichael
added
valuation
impact3
|
I found this again. Here's another repro: 1.20 values each cumulative balance with that month's price, which seems correct as month-end price is supposed to be the default for a multi-period report: 1.21 and later values all cumulative balances with the first month's price, which seems wrong, and I guess a regression ?: |
simonmichael
added
A-BUG
|
I bisected this. The first commit that changes the output for provided repros is 7f2536a. |
|
Thank you! I was looking at this but had to put it aside for a while. I'm not certain why valuation was dropped/changed for --cumulative , it may have been just a misunderstanding or |
|
This was what came out of a very extensive discussion here #1353. Essentially, when looking at a cumulative report with valuation, there are two different things you might want presented:
Each is useful in certain circumstances, and we decided that "valuation of the change" was the obvious default for change reports, "change in the valuation" was the obvious default for historical reports, and that cumulative reports were an odd duck where you would sometimes want one and sometimes want the other. If you want the "change in valuation behaviour" instead of the "valuation of the change" behaviour, you can supply the |
|
I can confirm that. The following two outputs are identical. Perhaps what might be needed is for the docs to be clarified. The explanation @Xitian9 has provided can be used, perhaps? We can close this as a non-regression / non-bug. |
@kkoniuszy, this is off-topic, but could you please share the git commands you ran in order to figure out the exact commit that introduced this change? Thanks. I don't know how to use |
|
@the-solipsist Sure. First, start the bisect, then mark Then, on every bisect iteration, try to reproduce the error and run either This is the last revision to test, so You can now run |
|
@Xitian9 @simonmichael I wonder if the report header isn't kind of misleading. It says |
|
No, it's not valued at the end of the first period: each change is valued in the period in which it occurs. The difference is that it is not re-evaluated later on. You can see this from an extension of @simonmichael's example above. You can see that the first transaction is valued at the The way to think about the behaviour is that it operates as a cumulative version of the change report, i.e. what you would get if you just added up all the entries of the change report: |
|
It may help to think of the two different behaviours in terms of where they would be useful. The default behaviour of the change and cumulative reports is what you should think about for things like expenses or revenues. If 10 year ago I bought a cabbage for 1 USD and consumed it, after which the value of the INR against the USD collapsed so that that cabbage would now cost 60 INR instead of 40, I wouldn't expect to see that appear in my change or cumulative reports. On the other hand, if I bought 1 USD and stored it (as an asset, or maybe a liability or equity), after which the value of the INR collapsed, then I would be able to sell my USD for more INR than previously. This is what Different use cases where each would be needed. Generally the default behaviour is more useful for expenses and revenues, the value-change behaviour for assets, liabilities, and equity. |
|
Thanks for the explanation, it's much clearer now. |
That's a very good point, I think it is also worth explaining in the manual that |
|
It would be worth noting that:
Also, I'll note that the following three provide identical results for a journal that starts from 2017-01-01:
while this provides a different result: So the default for Similarly, these two are identical The default for However, the best for |
simonmichael
added
docs
|
Thanks @Xitian9, & all, for the insightful comments! I have converted this to a doc bug, let's try to include these explanations in the manual insofar as they can fit, or perhaps in a separate website doc. I'll work on it if no-one beats me to it. |
--historicaland--cumulativeprovided the same output until v1.20 if the periods were the same.Since v1.21, they no longer do. They diverge if there are multiple commodities with prices that change over the periods.
I'm not sure if this should be counted as a regression or not.
Example
The text was updated successfully, but these errors were encountered: