On Thu, Jul 24, 2014 at 3:05 PM, John Wiegley <[email protected]> wrote:
> >>>>> 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? > > This example is already sorted , I mentioned it above. Rounding individual postings is fine at the time of multiplying by cost. This is one of the place you mentioned at end of the mail. It is not correct to round at the time of multiplying by current value, i was just trying to indicate and compare the error. I have discussed this in the end. Yes, i want to use the balance_t object. 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. > > I am also skeptical about this method. Probably we need to find another method but I am less aware of any accounting trick on it The problem is how do you find total worth of your shares. You will simply multiply the total quantity with market value? The rounding feature is expected to match this total irrespective of how these shares were purchased. Sorting will help round only subtotal of each commodity if required. If not sorting then some kind of metadata may be helpful ( I haven't thought about this fully). > 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. > Thanks for making the model clear. > 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 this sum is what we need to check . An account may have multiple commodities and the postings may not be sorted by commodity but you will expect your total to match worth of your commodities.As in this example. D 1000.00 EUR 2012-01-01 * A 1 AAA @@ 10.00 EUR C 2012-02-01 * A 1 BBB @@ 20.00 EUR C P 2012-07-01 AAA 10.123 EUR P 2012-07-01 BBB 20.123 EUR 10.12 + 20.12 = 30.24 EUR Well this example has been discussed many times. If you round the total sum you will get 30.25 EUR but in actual you will have 30.24 EUR. This is because you will get 10.12 EUR from valuation of total quantity of AAA which is one in this case and 20.12 EUR from valuation of total quantity of BBB. Now, where can rounding come into play here? There are several places: > > - Round postings with extra precision right away. > not required, purpose is to maintain as much precision we can. > - Round after multiplying the cost by the quantity > This is required. Practically, transactions rounded to two places after decimal are common. For example , 2012-01-01 * A 1 AAA @@ 10.123 EUR C C should reflect 10.12 EUR in balance. Please correct if you meant differently. - Round after multiplying the present value by the quantity > This is to be avoided, for simple reason that the rounding error will reflect in the total. > - Whenever any two postings are summed, round the sum, thereby producing > a > rather lossy rounding of the account balance (in all cases). > This is to be avoided, not required. > - Round the account total after summing the rationals internally. > Not exactly the total but whenever postings related to one commodity are summed, its subtotal should be rounded. Please correct me if I am wrong. > > No one of these methods is universally correct. Some system may require > one > or more. > > None of these methods involve sorting. > > None of these require sorting because it does not tackle the condition when account has multiple commodities , rounding the account total after summing the rationals internally is required but then it should be done for subtotal of each commodity and not just the composite of all. 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 > > I don't want to change the default behavior but only if the feature is used. This is a commodity specific directive. > John > > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "Ledger" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/ledger-cli/yX1PFXXJekM/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- 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.
