[GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

[Christopher Lam]

Hi John

Just to be a pain again... I found a small discrepancy - (This is 
different from the previously noted missing-capital-gains situation)

  * if trading-accounts are enabled,
  * a single 100AAPL purchase @ $100 each dated 01/01/18
  * a new increased price $200 on 01/06/18 is recorded,
  * price-source is 'latest' to pick up the new price

There's no trade sale yet -- this means 'trading gains' is $0 -- indeed 
the book will not have any Trading accounts yet.

I'd expect the balance-sheet to record the increased price as 
'unrealized gain'.

Yet the balance-sheet just displays an increased FUNDS valuation at 
$20,000 (i.e. total assets = $20000) without a corresponding increase in 
right-hand-side (ie total equity+liability=$10000).

I'd think the 'correct' balance sheet with trading-accounts enabled, 
*should* still report Unrealized Gains, no?


On 13/08/18 22:51, John Ralls wrote:
>
>
>> On Aug 12, 2018, at 10:04 PM, Christopher Lam 
>> <christopher.lck at gmail.com <mailto:christopher.lck at gmail.com>> wrote:
>>
>> Hi Jralls
>>
>> So just wish to double check my understanding of gnucash's data 
>> format for a balance-sheet on date X
>>
>> There are two possibilities for displaying the right-hand-side
>>
>>  1. Liabilities + Equity + Retained Earnings + Trading Balances
>>  2. Liabilities + Equity + Retained Earnings + Unrealized Gains
>>
>> "Retained Earnings" should be NULL if the user has properly closed 
>> the books on the balance sheet date X.
>>
>> In my understanding, "Trading Balances" and "Unrealized Gains" are 
>> one and the same -- in balance-sheet.scm the 
>> unrealized-gain-collector is only populated if book->trading-accounts 
>> setting is disabled. (btw this causes a 'bug' whereby a book with 
>> 'enable-trading-accounts', but was later switched to 
>> 'disable-trading-accounts' will then add both the 
>> unrealized-gain-collector and the trading-balance the right-hand-side).
>>
>> This seems to be deconstruct current balance-sheet?
>>
>> (I can't seem to find any unrealized-gain issue... from using 
>> different price-sources... perhaps this is beyond my understanding.)
>>
>>
>> On 11/08/18 22:41, John Ralls wrote:
>>> Chris,
>>>
>>> Remember that we’ve long advised users that they need not close 
>>> their books, they can run a balance sheet report for any day. IMO 
>>> removing that capability would be a major breakage.
>>>
>>> I suspect that you needed to use trading accounts because you didn’t 
>>> book the trading gains and losses as income. Users should do that 
>>> regardless of using trading accounts and doing so should make it 
>>> unnecessary for the balance sheet report to include trading accounts.
>>>
>>> Unrealized gains are another matter entirely and are a result of 
>>> using prices from the price database instead of actual cost from the 
>>> transaction data. IMO the balance sheet report shouldn’t be taking 
>>> prices from the price db and shouldn’t be able to see unrealized 
>>> gains, but if price source is going to be an option then an 
>>> unrealized gains line flows from that so that users don’t waste a 
>>> bunch of time chasing an imbalance caused by price differences.
>>>
>>> https://bugs.gnucash.org/show_bug.cgi?id=775368 is related because 
>>> that’s currently how the balance sheet report gets the “actual” costs.
>>>
>>> Regards,
>>> John Ralls
>>>
>>>> On Aug 10, 2018, at 11:40 PM, Christopher Lam 
>>>> <christopher.lck at gmail.com <mailto:christopher.lck at gmail.com>> wrote:
>>>>
>>>> Hi John
>>>>
>>>> I've managed to make the left-side (activa?) match the right-side 
>>>> (passiva?)
>>>>
>>>> https://screenshots.firefox.com/RNvkjaxnYyxpGkYn/null
>>>>
>>>> 1) it does require closing books on the balance-sheet date
>>>>
>>>> 2) it does require adding trading-accounts
>>>>
>>>> The existing balsheet introduces/calculates the "Retained 
>>>> Earnings", "Trading Gains" and "Unrealized Gains", whereas the 
>>>> current iteration of new-balsheet will not.
>>>>
>>>> To me this is the easiest method to ensure both sides produce the 
>>>> same total, and is now technically correct - if the user has not 
>>>> closed their books, the balance sheet won't balance.
>>>>
>>>> This is giving me a headache :(
>>>>
>>>> Should a new balsheet calculate and report these '(fake) retained 
>>>> earnings', and 'unrealized gains' ???
>>>>
>>>> C
>>>>
>>>>
>>>> On 09/08/18 08:32, John Ralls wrote:
>>>>>
>>>>>> On Aug 8, 2018, at 8:51 AM, Geert Janssens 
>>>>>> <geert.gnucash at kobaltwit.be> wrote:
>>>>>>
>>>>>> I haven't been following every detail of this. However I note on 
>>>>>> most balance
>>>>>> sheets the total assets doesn't match total net worth (or 
>>>>>> liabilities/equity).
>>>>>> In most, this is fixed by including the retained earnings.
>>>>>>
>>>>>> I believe at least in most European countries the "left hand 
>>>>>> side" (Assets,
>>>>>> Active) and "right hand side" (Passive or liabilities + equity) 
>>>>>> of the
>>>>>> multicolumn view should balance (it's called balance sheet for a 
>>>>>> reason).
>>>>>> That would suggest retained earnings does have to be part of the 
>>>>>> balance
>>>>>> sheet.
>>>>>>
>>>>>> However I'm not an accountant and perhaps your book is slightly 
>>>>>> contrived so I
>>>>>> don't know the exact answer here.
>>>>>>
>>>>>> As for the "multi-column" vs one column debate, both present the 
>>>>>> same data.
>>>>>> The only difference is visual representation or style.
>>>>>>
>>>>>> As of recently I have become a strong proponent of separating 
>>>>>> structure (or
>>>>>> accounting functionality in a different context) from style, I 
>>>>>> think this
>>>>>> should be delegated to the realm of css. This particular layout 
>>>>>> variation can
>>>>>> IMO be handled by making divs for each large group and either let 
>>>>>> them follow
>>>>>> normal flow or use float to move them next to each other. If you 
>>>>>> will you can
>>>>>> have a European style sheet and an American one, or an Australian 
>>>>>> or whatever.
>>>>>>
>>>>>> As for "categories", I read Frank's earlier reply as if he agreed 
>>>>>> that at
>>>>>> least for now the account organization is something to be done in 
>>>>>> the CoA, not
>>>>>> in report code.
>>>>> The Balance Sheet is indeed supposed to balance, but in normal 
>>>>> practice it balances only when the book is “closed”, i.e. when all 
>>>>> of the income and expense accounts are summed up and added to 
>>>>> Equity. In US corporate books the cumulative total of income and 
>>>>> expenses lives in an Equity account called “Retained Earnings”.
>>>>>
>>>>> In the pen-and-paper days a  “Trial Balance” was computed outside 
>>>>> of the books before closing as a way to catch errors before making 
>>>>> the closing entries and writing the formal Balance Sheet.
>>>>>
>>>>> GnuCash's existing Balance Sheet Report creates the “Retained 
>>>>> Earnings” line so that one need not close the books (Tools>Close 
>>>>> Book) in order to get a balanced report. Removing that feature 
>>>>> might be more formally correct but it would mean that users would 
>>>>> have to close their book before running a balance sheet. That 
>>>>> would be a big change and I don’t think that we want to do it. On 
>>>>> the other hand “Retained Earnings” isn’t the right term for many 
>>>>> cases, so it would be a useful improvement to make it configurable.
>>>>>
>>>>> There’s a second problem with the current report as well: If the 
>>>>> user does close their books periodically they’ll have an account 
>>>>> for the accumulation that may well be called “Retained Earnings”. 
>>>>> The Balance Sheet Report will dutifully report the contents of 
>>>>> that account and, if there are income and expenses after the last 
>>>>> close, add a second “Retained Earnings” line. That looks a bit odd 
>>>>> and might be confusing; ISTR we’ve had comments on the user list 
>>>>> about just that.
>
> Chris,
>
> To demonstrate the price difference on assets creating an “Unrealized 
> Gain” line, I created a fake account with Trading Accounts off and 
> purchased on 1 January 100 shares of a stock for $100, then created a 
> new price for the stock of $200. The resulting Balance Sheet report is 
> the first screenshot below. Price source is set to “nearest in time”.
>
> I repeated the process in a new book with trading accounts enabled and 
> got the second screenshot. As you pointed out, the “Unrealized Gains” 
> line changes to “Trading Gains”. Selling the stock made no difference 
> on the report unless I also booked the 10,000 gain to Income:Short 
> Term Cap Gains, after which the calculated line became “Retained 
> Earnings” as illustrated by the third screen shot.
>
> I went back and did the sale on the non-trading-accounts book and 
> found that indeed “Unrealized Gains” didn’t change after I sold the 
> stock; that’s wrong, it’s a realized gain at that point. Booking the 
> gain to Income changed the line to “Retained Earnings” as it did with 
> trading accounts enabled and as expected.
>
> Finally, to illustrate the effect of price source I removed the sell 
> transaction and changed the price source in report options to “Avg 
> Cost”. The result is the last screenshot, showing the stock at book 
> value and the “Unrealized Gains” line at 0.
>
> Regards,
> John Ralls