>>>>> tripun goel <[email protected]> writes:
> Right now, the ledger keeps the amounts in the order of the posts are
> parsed.
> Consider the following example, the posts are not sorted by date but by
> commodity .
> After valuation AAA ( 4 * 10,123=40.492 GBP) should be rounded to 40.49
> GBP and XXX ( 4 * 10.123 =40.492 GBP) should be rounded to 40.49 GBP so
> the total balance in account "P" should be 80.980 GBP after rounding. As
> of now , If I enter posts in any manner it does not matter for ledger and
> the balance will always be the same. But keeping it sorted by commodity
> will be helpful for rounding the subtotal of each commodity. Again, if I
> would have rounded each amount after valuation I would get 80.960 GBP (
> 10.12 + 10.12 ... 8 times) which is not correct.
I still don't see what sorting is doing to fix anything in this example. Why
are you rounding the value of individual postings? What does sorting have to
do with that? The balance_t type's job is to accumulate value segregated by
commodity. Are you meaning to use that?
I would never trust a rounding methodology based on sorting postings. We must
find a solution that is not so ad-hoc. I'd like to see some math involved
here as well, rather than just descriptions of how the code could be changed
to produce the expected value.
Right now the model is very simple: Every posting has a quantity, a commodity,
and optional cost. That cost is always normalized to a "per unit" cost
internally, so it doesn't matter if the user uses @ or @@, it is the same to
Ledger. The historical value of a posting is the cost times the quantity; the
current "market" value of a posting is the valuation of its commodity times
its quantity.
And account's balance is the sum of its postings. An account's value either
historically or present-day is the sum of the values of its postings, as
described previously.
Now, where can rounding come into play here? There are several places:
- Round postings with extra precision right away.
- Round after multiplying the cost by the quantity
- Round after multiplying the present value by the quantity
- Whenever any two postings are summed, round the sum, thereby producing a
rather lossy rounding of the account balance (in all cases).
- Round the account total after summing the rationals internally.
No one of these methods is universally correct. Some system may require one
or more.
None of these methods involve sorting.
So let us start this issue over, from the beginning, and get to the bottom of
what is potentially correct, and how best to introduce options to enable those
features. The default behavior will remain as it is now, but I am open to
several possibilities for adding these extensions:
command-line options
global directives
account/payee/commodity specific directives
metadata directives
John
--
---
You received this message because you are subscribed to the Google Groups
"Ledger" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
