[GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp
christopher.lck at gmail.com
Mon Aug 13 01:04:58 EDT 2018
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:
> 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.
> 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
>> 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' ???
>> 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
>>>> In most, this is fixed by including the retained earnings.
>>>> I believe at least in most European countries the "left hand side"
>>>> Active) and "right hand side" (Passive or liabilities + equity) of the
>>>> multicolumn view should balance (it's called balance sheet for a
>>>> That would suggest retained earnings does have to be part of the
>>>> 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.
>>> John Ralls
>>> gnucash-devel mailing list
>>> gnucash-devel at gnucash.org
>> gnucash-devel mailing list
>> gnucash-devel at gnucash.org
More information about the gnucash-devel