Reporting: weighted average price source
David G. Hamblen
dhamblen at roadrunner.com
Fri Jul 4 20:21:21 EDT 2008
Charles Day wrote:
> On Fri, Jul 4, 2008 at 12:48 PM, Christian Stimming <stimming at tuhh.de>
>> Am Freitag, 4. Juli 2008 20:30 schrieb Charles Day:
>>> On Fri, Jul 4, 2008 at 2:58 AM, Christian Stimming <stimming at tuhh.de>
>>>> Am Freitag, 4. Juli 2008 04:31 schrieb Charles Day:
>>>>> For reports, does anyone know why the calculation for price source
>>>>> "weighted average" uses the absolute value in its calculations? It
>>>>> seems to me that this gives incorrect results.
>>>> If I recall correctly, this code comes from the old days when I added
>>>> this to
>>>> track "my personal exchange rate" between USD and EUR. Without this
>>>> I think if I bought x USD for y EUR and later sold x USD for y EUR, the
>>>> resulting rate turned out zero instead of the expected value (which is
>>>> divided by y). Using absolute values here gave the intended results.
>>> Ah, I see... so is the "weighted average" price source defined as
>>> average price experienced during buys and sells, not including
>>> fees such as commission"? Because if so, then do you think that exchanges
>>> with a zero "amount", such as capital gains and losses, should be
>> Indeed I introduced this option only with contexts in mind where there were
>> capital loss transactions are included. I have no idea how this has been
>> since then, or how other people have used it.
>>> Example: Buy 5 USD for 4 EUR (exchange rate = 0.8), then sell 5 USD for 3
>>> EUR (exchange rate = 0.6), giving a 1 EUR capital loss. I am guessing
>>> your response that would expect to see the weighted average price of the
>>> buy and the sell alone, which is (4 + 3) / (5 + 5) = 0.7.
>> Exactly. That was what I intended when I introduced that option back in
>> I didn't actually record any capital loss transactions.
>>> However, the
>>> current formula includes the capital loss in the calculation: (4 + 3 + 1)
>>> (5 + 5 + 0) = 0.8. Of course, this assumes that you actually record the
>>> capital loss. (GnuCash doesn't require you to, but failing to record the
>>> loss puts the books out of balance.)
>>> Now on the other hand, what I am proposing is to get rid of the absolute
>>> value but keep the zero "amount" exchanges. That would change the
>>> definition to "weighted average cost for shares currently held, not
>>> including transaction fees such as commission". A few users have been
>>> asking for this option, which I maybe could add.
>> This option seems to make a lot of sense, too, but it will show different
>> numbers. Hence I'm not sure whether a complete replacement of the existing
>> option is the best idea, and maybe a new option is the better way to go.
>> (Although adding yet another option is always the sub-optimum result of a
> I think the version I am proposing would be useful, particularly for the
> balance sheet, since it could show assets at cost (no unrealized gains). A
> couple of users have said that this is the standard way of preparing
> financials in India. One described it as not counting chickens before they
> are hatched. I believe adding this option would close bugs 460721, 521403
> and 538800.
> As far as what to do with the current "weighted value" option, what do you
> think? Replace it, or leave it in but modify it to leave out zero "amount"
> splits? Do you want to make this decision?
> It is interesting to know your own personal exchange rate sometimes, but I
> don't think it is a very useful way of valuing current holdings. For me it
> would be more useful to revalue by "nearest in time" (comes from the price
> DB) or "nearest exchange" (i.e. taking the exchange rate from the nearest
> recorded trade - another option that doesn't exist at this point).
A few years back (v1.8x), I had problems with these absolute values, and I
patched report-utilities.scm,and commodity-utilites.scm so that the balance
sheet would balance. In addition to completely removing all the numeric:abs,
I also had to do something about the division by zero in commodity-utilities
when there was a zero share balance. I'm using the "Nearest in Time" and the
problem went away in the 2.x updates. If anyone's interested, I can dig up
my old postings.
Anyway, I vote for getting rid of absolute values in bookkeeping.
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
More information about the gnucash-devel