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>
> wrote:
>
>   
>> 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>
>>>       
>> wrote:
>>     
>>>> 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
>>>>         
>> code,
>>     
>>>> 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
>>>>         
>> x
>>     
>>>> divided by y). Using absolute values here gave the intended results.
>>>>         
>>> Ah, I see... so is the "weighted average" price source defined as
>>>       
>> "weighted
>>     
>>> average price experienced during buys and sells, not including
>>>       
>> transaction
>>     
>>> 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
>>>       
>> excluded?
>>
>> Indeed I introduced this option only with contexts in mind where there were
>> no
>> capital loss transactions are included. I have no idea how this has been
>> used
>> 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
>>>       
>> from
>>     
>>> 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
>> 2001.
>> 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
>> discussion...)
>>
>>     
>
> 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).
>
> -Charles
>   

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.


-Dave

>
>   
>> Christian
>>
>>     
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>   



More information about the gnucash-devel mailing list