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

[Christopher Lam]

Hi All

The state of balsheet-pnl for now, imho is feature complete and has nicer
well-documented internal functions. However I'm still stumped by various
equity calculations, unsure how to emulate all combinations of
trading/unrealized/realized gains/losses. JRalls has helpfully created some
illustrative tests, but these would need plugging into the new balsheet
which isn't immediately obvious. And for me to spend a few months getting
to understand the formulas.

For this matter I wouldn't be keen to replace the current balsheet yet. I
know some users are keen to maintain the current balsheet's calculations
and I can't guarantee the new one will produce the same equity section.

So, for now, the options are to add the multicolumn balsheet as a new menu
item and seek user feedback about equity calculations, or leave it unmerged
and unfinished, which is another shame.

On Fri, 17 Aug 2018 at 21:20, Christopher Lam 
wrote:

> Hi David
>
> I refer you to a prior discussion:
> https://lists.gnucash.org/pipermail/gnucash-user/2018-June/077758.html
>
> I appreciate balance-sheet is a formal accounting report. The problem is,
> as always, within the details.
>
> Initially I thought we could leave currencies unconverted.
>
> Then Geert reminded me *all* currencies *must* be allowed to convert to a
> user-selected common-currency. Because a balance-sheet is really a
> valuation of all of your assets, into a legal currency of your choice. The
> price used must be either (1) actual transactional prices - either
> average-cost or weighted-average - both terms whose exact definitions
> currently elude me despite looking at code (2) from the pricedb -
> latest/nearest.
> (* PS what's the strategy if accounts are in EUR/USD/GBP, with plenty of
> pricing data in these 3 currencies, but user prefers common-currency to be
> JPY, and pricedb has EUR/USD, USD/GBP, GBP/AUD and AUD/JPY amounts? Answer:
> Internal logic will try to find an intermediate pricedb pair, eg.
> GBP->AUD->JPY at the nearest date available, and EUR/USD will result to 0
> JPY Except my report will convert GBP->JPY correctly and leave EUR/USD
> in original currency )
>
> The next issues are all to do with Equity:
>
> (1) trading-accounts are optional. As we know, trading accounts will
> compute *REALIZED GAINS,* so that EUR>USD>EUR transfers at different
> prices *must* result in a realized-gain recording. If the trading-accounts
> are disabled, the current balance-sheet will make an attempt at computing
> its own Realized Gains. It assumes the user hasn't recorded realized-gains
> during currency conversions. IMHO There's currently a logic error if there
> are trading-accounts in a book with book property trading-accounts
> disabled. Moreover, if trading-accounts are disabled, and the user has
> recorded but underestimated realized gains, I think the balsheet *should*
> report the delta amount as unrealized-gains too???
>
> (2) selection of a report common-currency must compute *UNREALIZED GAINS*,
> e.g. if EUR/USD/GBP accounts are reported for balsheet in JPY, and JPY has
> increased in value between transaction-dates and report-date, presumably
> all amounts must increase? This is not proven correctly handled yet. I
> still think there's an error - the Asset report-currency amount will use
> the higher price, but the unrealized gains are not computed when
> trading-accounts are disabled.
>
> (3) income and expense amounts are technically closed to equity on
> balsheet-date but we don't enforce this, so, their difference must account
> for *RETAINED EARNINGS* or some other similar heading. If user has closed
> books correctly on balsheet-date, then the balsheet should report retained
> earnings to be $0.
> If anyone can help me, please do. Spreadsheets or formula sheets welcome.
> Double-entry is all fun and games until trying to compute a balance-sheet!
> The above, not an accountant yadda yadda.
>
> On 17/08/18 00:27, David T. wrote:
>
> Hi,
>
> I admit that I haven’t been following the details of thsi thread that 
> closely, but it would seem to me that if a user has selected price source 
> “Latest,” then the report will of necessity include an Unrealized Gains line 
> in order to balance, as John said. I agree with his suggestion that 
> Unrealized Gains might not belong in a Balance Sheet report, but I note that 
> as a personal user of GnuCash, I am rather interested in the current value of 
> my empire, ephemeral though it may be. I’m eager to see how rich I am Right 
> Now! Bwa Ha Ha Ha!
>
> Seriously, though, since “Balance Sheet” seems to be a commonly-used term in 
> accounting to refer to a particular general type of report and content (I 
> base this on the fact that Googling “Balance Sheet report definition” yields 
> numerous accounting websites with explanations of what a balance sheet is and 
> does), perhaps there could be a separately-identified and named report to 
> give the armchair trader the putative value of their holdings 

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

[Christopher Lam]

Hi David

I refer you to a prior discussion: 
https://lists.gnucash.org/pipermail/gnucash-user/2018-June/077758.html


I appreciate balance-sheet is a formal accounting report. The problem 
is, as always, within the details.


Initially I thought we could leave currencies unconverted.

Then Geert reminded me *all* currencies *must* be allowed to convert to 
a user-selected common-currency. Because a balance-sheet is really a 
valuation of all of your assets, into a legal currency of your choice. 
The price used must be either (1) actual transactional prices - either 
average-cost or weighted-average - both terms whose exact definitions 
currently elude me despite looking at code (2) from the pricedb - 
latest/nearest.


(* PS what's the strategy if accounts are in EUR/USD/GBP, with plenty of 
pricing data in these 3 currencies, but user prefers common-currency to 
be JPY, and pricedb has EUR/USD, USD/GBP, GBP/AUD and AUD/JPY amounts? 
Answer: Internal logic will try to find an intermediate pricedb pair, 
eg. GBP->AUD->JPY at the nearest date available, and EUR/USD will result 
to 0 JPY Except my report will convert GBP->JPY correctly and leave 
EUR/USD in original currency )


The next issues are all to do with Equity:

(1) trading-accounts are optional. As we know, trading accounts will 
compute _REALIZED GAINS,_ so that EUR>USD>EUR transfers at different 
prices *must* result in a realized-gain recording. If the 
trading-accounts are disabled, the current balance-sheet will make an 
attempt at computing its own Realized Gains. It assumes the user hasn't 
recorded realized-gains during currency conversions. IMHO There's 
currently a logic error if there are trading-accounts in a book with 
book property trading-accounts disabled. Moreover, if trading-accounts 
are disabled, and the user has recorded but underestimated realized 
gains, I think the balsheet *should* report the delta amount as 
unrealized-gains too???


(2) selection of a report common-currency must compute _UNREALIZED 
GAINS_, e.g. if EUR/USD/GBP accounts are reported for balsheet in JPY, 
and JPY has increased in value between transaction-dates and 
report-date, presumably all amounts must increase? This is not proven 
correctly handled yet. I still think there's an error - the Asset 
report-currency amount will use the higher price, but the unrealized 
gains are not computed when trading-accounts are disabled.


(3) income and expense amounts are technically closed to equity on 
balsheet-date but we don't enforce this, so, their difference must 
account for _RETAINED EARNINGS_ or some other similar heading. If user 
has closed books correctly on balsheet-date, then the balsheet should 
report retained earnings to be $0.


If anyone can help me, please do. Spreadsheets or formula sheets 
welcome. Double-entry is all fun and games until trying to compute a 
balance-sheet! The above, not an accountant yadda yadda.


On 17/08/18 00:27, David T. wrote:

Hi,

I admit that I haven’t been following the details of thsi thread that closely, 
but it would seem to me that if a user has selected price source “Latest,” then 
the report will of necessity include an Unrealized Gains line in order to 
balance, as John said. I agree with his suggestion that Unrealized Gains might 
not belong in a Balance Sheet report, but I note that as a personal user of 
GnuCash, I am rather interested in the current value of my empire, ephemeral 
though it may be. I’m eager to see how rich I am Right Now! Bwa Ha Ha Ha!

Seriously, though, since “Balance Sheet” seems to be a commonly-used term in 
accounting to refer to a particular general type of report and content (I base 
this on the fact that Googling “Balance Sheet report definition” yields 
numerous accounting websites with explanations of what a balance sheet is and 
does), perhaps there could be a separately-identified and named report to give 
the armchair trader the putative value of their holdings as of a given date. 
Then the Balance Sheet could be dedicated to the real world situation (i.e., no 
need for the PriceDB at all—just use the transaction prices), while the new 
report could include unrealized gains explicitly. A descriptive name (“Trade 
Value”? “Speculative Value”? “Castles in the Sand”?) could help make clear the 
difference between the two.

David


On Aug 16, 2018, at 7:30 AM, John Ralls  wrote:

Chris,

That’s because you used price source = “latest” which uses the most recent 
price in the pricedb for the purchase as well as the valuation.

Regards,
John Ralls


On Aug 16, 2018, at 12:58 AM, Christopher Lam  wrote:

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 

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

[David T. via gnucash-devel]

Hi,

I admit that I haven’t been following the details of thsi thread that closely, 
but it would seem to me that if a user has selected price source “Latest,” then 
the report will of necessity include an Unrealized Gains line in order to 
balance, as John said. I agree with his suggestion that Unrealized Gains might 
not belong in a Balance Sheet report, but I note that as a personal user of 
GnuCash, I am rather interested in the current value of my empire, ephemeral 
though it may be. I’m eager to see how rich I am Right Now! Bwa Ha Ha Ha!

Seriously, though, since “Balance Sheet” seems to be a commonly-used term in 
accounting to refer to a particular general type of report and content (I base 
this on the fact that Googling “Balance Sheet report definition” yields 
numerous accounting websites with explanations of what a balance sheet is and 
does), perhaps there could be a separately-identified and named report to give 
the armchair trader the putative value of their holdings as of a given date. 
Then the Balance Sheet could be dedicated to the real world situation (i.e., no 
need for the PriceDB at all—just use the transaction prices), while the new 
report could include unrealized gains explicitly. A descriptive name (“Trade 
Value”? “Speculative Value”? “Castles in the Sand”?) could help make clear the 
difference between the two.

David

> On Aug 16, 2018, at 7:30 AM, John Ralls  wrote:
> 
> Chris,
> 
> That’s because you used price source = “latest” which uses the most recent 
> price in the pricedb for the purchase as well as the valuation.
> 
> Regards,
> John Ralls
> 
>> On Aug 16, 2018, at 12:58 AM, Christopher Lam  
>> wrote:
>> 
>> 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 = $2) without a corresponding increase in 
>> right-hand-side (ie total equity+liability=$1).
>> 
>> 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 >>> > 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
 
 Liabilities + Equity + Retained Earnings + Trading Balances
 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.
> 
> 

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

[John Ralls]

Chris,

That’s because you used price source = “latest” which uses the most recent 
price in the pricedb for the purchase as well as the valuation.

Regards,
John Ralls

> On Aug 16, 2018, at 12:58 AM, Christopher Lam  
> wrote:
> 
> 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 = $2) without a corresponding increase in 
> right-hand-side (ie total equity+liability=$1).
> 
> 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 >> > 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
>>> 
>>> Liabilities + Equity + Retained Earnings + Trading Balances
>>> 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  > 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  
>>>  wrote:

Re: [GNC-dev] New balsheet (and P 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 = $2) without a corresponding increase in 
right-hand-side (ie total equity+liability=$1).


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 
mailto:christopher@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 
mailto:christopher@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 
 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 

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

[Christopher Lam]

Hi John

Thank you - plenty of material here for test cases.

I note your observation that selling a stock at an increased price, in a
book without trading-accounts, without properly booking the capital-gain to
income leads to an incorrect balance-sheet. This is illus by txn-A and
txn-B below. This shouldn't arise -- all cap-gains must be documented
according to documentation - either together with the sell transaction, or
in a separate transaction. So, IMHO the incorrect report as you found out
does not really need fixing.

01-jan-18 Txn-A - buy
Asset:Broker -$1
Asset:Broker:Stock +100 AAPL (+$1)

01-jun-18 Txn-B - sell
Asset:Broker +$2
Asset:Broker:Stock -100 AAPL (-$2)

01-jun-18 Txn-C - cap-gain
Asset:Broker:Stock 0AAPL (+$1)
Income:Capital-Gains -$1

Moreover, about that price-source... I'll try and replicate.

C
On 13/08/18 22:51, John Ralls wrote:



On Aug 12, 2018, at 10:04 PM, Christopher Lam 
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 
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 
 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 

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

[John Ralls]

So I see. Even though I carefully put them at the end.

 Fortunately Chris should have gotten a direct copy without Mailman’s 
interference.

Regards,
John Ralls


> On Aug 13, 2018, at 8:33 AM, Adrien Monteleone 
>  wrote:
> 
> John,
> 
> Mailman was hungry. It ate your screenshots.
> 
> Regards,
> Adrien
> 
>> 
>> 
>> 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
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org 
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel 
> 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Adrien Monteleone]

John,

Mailman was hungry. It ate your screenshots.

Regards,
Adrien

> 
> 
> 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
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[John Ralls]

> On Aug 12, 2018, at 10:04 PM, Christopher Lam  
> 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
> 
> Liabilities + Equity + Retained Earnings + Trading Balances
> 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 >> > 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  
>  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.
> 

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

[Adrien Monteleone]

Sorry John,

I forgot that GnuCash used the same term for the calculated amount.

Yet another case where my fingers need to slow down and let my brain ponder 
things.

Regards,
Adrien

> On Aug 13, 2018, at 9:08 AM, John Ralls  wrote:
> 
> Adrien,
> 
> Yes, that’s formally correct. As I’ve said repeatedly in this thread, GnuCash 
> has long had a design feature that one can get a balanced Balance Sheet 
> report without closing one’s book. The Balance Sheet report does that by 
> summing up the expense and income accounts’ balances and reporting the total 
> in a “Retained Earnings” line. If one has closed one’s book in the past and 
> so has a “Retained Earnings” account, the Balance Sheet report will have two 
> lines called “Retained Earnings”.
> 
> Regards,
> John Ralls
> 
> 
>> On Aug 12, 2018, at 10:26 PM, Adrien Monteleone 
>>  wrote:
>> 
>> Are not Retained Earnings part of Equity? And then, that account would only 
>> be used in a close books process, not without it. Closing the books should 
>> zero the income and expense accounts TO Retained Earnings.
>> 
>> Regards,
>> Adrien
>> 
>>> On Aug 13, 2018, at 12:04 AM, Christopher Lam  
>>> 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  > 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  
>>> 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 

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

[John Ralls]

Adrien,

Yes, that’s formally correct. As I’ve said repeatedly in this thread, GnuCash 
has long had a design feature that one can get a balanced Balance Sheet report 
without closing one’s book. The Balance Sheet report does that by summing up 
the expense and income accounts’ balances and reporting the total in a 
“Retained Earnings” line. If one has closed one’s book in the past and so has a 
“Retained Earnings” account, the Balance Sheet report will have two lines 
called “Retained Earnings”.

Regards,
John Ralls


> On Aug 12, 2018, at 10:26 PM, Adrien Monteleone 
>  wrote:
> 
> Are not Retained Earnings part of Equity? And then, that account would only 
> be used in a close books process, not without it. Closing the books should 
> zero the income and expense accounts TO Retained Earnings.
> 
> Regards,
> Adrien
> 
>> On Aug 13, 2018, at 12:04 AM, Christopher Lam > > 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 >>>  >> 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  
>> 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 

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

[Adrien Monteleone]

Are not Retained Earnings part of Equity? And then, that account would only be 
used in a close books process, not without it. Closing the books should zero 
the income and expense accounts TO Retained Earnings.

Regards,
Adrien

> On Aug 13, 2018, at 12:04 AM, Christopher Lam  
> 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 >> > 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  
> 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 

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

[Christopher Lam]

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 
mailto:christopher@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 
 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 

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

[John Ralls]

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  
> 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  
>>> 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 

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

[Christopher Lam]

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  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.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Adrien Monteleone]

> On Aug 9, 2018, at 7:37 AM, Geert Janssens  wrote:
> 
> For reports on the other hand it's not important what Gtk+ implements as the 
> reports are html rendered via webkit (essentially a built-in webbrowser) so 
> the W3C css rules matter here..

Can’t believe I didn’t remember that. This makes the solution much easier. I’m 
generally not a fan of table layouts, but being this is tabular data, it’s 
probably the most semantic approach. In that case, the columns feature of CSS3 
wouldn’t come into play. But they will be useful with respect to 
multi-vs-single column presentation. Setting a 2-column preference would set a 
CSS rule for 2 columns and then set a rule for the second column data to be in 
column ‘2’. Each section of the report would have to be its own table for that 
to work. I don’t think floats are needed. (and would only move the sections 
around based on the width of the report window anyway)

> 
>> My guess would be to set classes on the accounts for the column position and
>> set left margin or padding on the classes accordingly. (I think Geert
>> mentioned something along these lines in an earlier reply)
>> 
> That's indeed what I had in mind, but I haven't tried myself either. So I 
> can't tell how feasible it is anyway. I don't see an issue for accounts as 
> they are left-justified. I don't know for the right-justified amounts though. 
> People with more html/css experience may want to share their views here.
> 


I’ve yet to generate an HTML table via code (certainly not scheme) but I’ll 
take a crack at it with PHP and see what works, then that could be translated. 
I should think padding-right rules could be used on the amounts that are 
right-justified.

All of this now makes me curious to start examining the current HTML being 
generated for reports to see what’s at play.

Regards,
Adrien
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Geert Janssens]

Op donderdag 9 augustus 2018 13:22:09 CEST schreef Adrien Monteleone:
> > On Aug 8, 2018, at 10:02 PM, Christopher Lam 
> > wrote:
> > 
> > Hi devs,
> > 
> > 
> > Account Balances are either displayed indented (same as account-depth,
> > with a few exceptions) or single-column. I'd rather not do indenting in
> > CSS because I can't figure out CSS. The CSS style would be “:n columns"
> > or something and I have not idea how this works.
> CSS3 does columns, but I don’t see anything yet looking over the Gtk+ CSS
> docs to indicate they’ve implemented it.
> 
Heh, it shows you have been digging deep into the Gtk+ CSS :) I think you even 
understand it better than me by now.
For reports on the other hand it's not important what Gtk+ implements as the 
reports are html rendered via webkit (essentially a built-in webbrowser) so 
the W3C css rules matter here..

> My guess would be to set classes on the accounts for the column position and
> set left margin or padding on the classes accordingly. (I think Geert
> mentioned something along these lines in an earlier reply)
> 
That's indeed what I had in mind, but I haven't tried myself either. So I 
can't tell how feasible it is anyway. I don't see an issue for accounts as 
they are left-justified. I don't know for the right-justified amounts though. 
People with more html/css experience may want to share their views here.

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Adrien Monteleone]

> On Aug 8, 2018, at 10:02 PM, Christopher Lam  
> wrote:
> 
> Hi devs,
> 
> 
> Account Balances are either displayed indented (same as account-depth, with a 
> few exceptions) or single-column. I'd rather not do indenting in CSS because 
> I can't figure out CSS. The CSS style would be “:n columns" or something and 
> I have not idea how this works.

CSS3 does columns, but I don’t see anything yet looking over the Gtk+ CSS docs 
to indicate they’ve implemented it.

My guess would be to set classes on the accounts for the column position and 
set left margin or padding on the classes accordingly. (I think Geert mentioned 
something along these lines in an earlier reply)

Having not taken much of a gander at the report code, I certainly don’t know 
how difficult that would be or if it is even possible.

Regards,
Adrien
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Christopher Lam]

Hi devs,

On 09/08/18 08:32, John Ralls wrote:

On Aug 8, 2018, at 8:51 AM, Geert Janssens  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.
This book is not particularly contrived :) there are no imbalance or 
orphan accounts; there's EUR/USD/FUND; there's pricing USD/FUND only; 
there are a few income txns; and Asset:Broker is the only parent-account 
its own balance. It aims to test most aspects of balsheet. I've attached 
datafile, and it can be loaded to try existing balance-sheet and 
eguile-balsheet to confirm the $32.50 vs $32.00 discrepancy.

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.
This dual- or single-column or asset/liability/equity or 
asset/equity/liability sounds reasonable to define in CSS.


Account Names are either displayed indented, or as full-account-name -- 
any other option would be too confusing.


Account Balances are either displayed indented (same as account-depth, 
with a few exceptions) or single-column. I'd rather not do indenting in 
CSS because I can't figure out CSS. The CSS style would be ":n columns" 
or something and I have not idea how this works.

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.
Aha this is where the discrepancy and the retained earnings line comes 
from!... I haven't solved this yet, and still trying to figure out how 
it should work.

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.

Agreed


CL Inc.gnucash
Description: application/gnucash
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[John Ralls]

> On Aug 8, 2018, at 8:51 AM, Geert Janssens  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.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Geert Janssens]

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.

Regards,

Geert

Op woensdag 8 augustus 2018 17:13:32 CEST schreef Christopher Lam:
> Hi Frank,
> 
> I would think if the multiple categories of accounts are desired, they
> should be designed in the Chart of Accounts rather than the balance
> sheet. At least this is what I'd design my book as, rather than trying
> to code various formulas in scheme.
> 
> I've rendered the same test book multiple ways.
> 
> https://imgur.com/a/s5a3oZu
> 
> Notice
> 
> 1. according to the house accountant, the 'retained earnings' shouldn't
> be part of balance sheet, right?
> 
> 2. balsheet-eguile and balsheet-legacy calculate retained earnings
> differently - should these be included???
> 
> C
> 
> On 08/08/18 09:57, Frank H. Ellenberger wrote:
> > The tables in
> > https://de.wikipedia.org/wiki/Gewinn-_und_Verlustrechnung#Gliederung
> > show the grouping for the 3 regions AT (UGB), DE (HGB) and intl (IFRS).
> > The latter can be adapted for the less formal US (GAAP). They are shown
> > for 2 different methods:
> > Period costing Method (Gesamtkostenverfahren) and
> > Cost of Sales Method (Umsatzkostenverfahren)
> > 
> > I have currently no idea, how to get this different forms from the
> > report by options.
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Christopher Lam]

Hi Frank,

I would think if the multiple categories of accounts are desired, they 
should be designed in the Chart of Accounts rather than the balance 
sheet. At least this is what I'd design my book as, rather than trying 
to code various formulas in scheme.


I've rendered the same test book multiple ways.

https://imgur.com/a/s5a3oZu

Notice

1. according to the house accountant, the 'retained earnings' shouldn't 
be part of balance sheet, right?


2. balsheet-eguile and balsheet-legacy calculate retained earnings 
differently - should these be included???


C


On 08/08/18 09:57, Frank H. Ellenberger wrote:

The tables in
https://de.wikipedia.org/wiki/Gewinn-_und_Verlustrechnung#Gliederung
show the grouping for the 3 regions AT (UGB), DE (HGB) and intl (IFRS).
The latter can be adapted for the less formal US (GAAP). They are shown
for 2 different methods:
Period costing Method (Gesamtkostenverfahren) and
Cost of Sales Method (Umsatzkostenverfahren)

I have currently no idea, how to get this different forms from the
report by options.



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Frank H. Ellenberger]

Hi Adrien,

Am 31.07.2018 um 02:27 schrieb Adrien Monteleone:
> Frank,
> 
> I’ve been following this for a while, and perhaps I’m not understanding, but 
> are the groupings just presentational?

Usually the sums of this groups are economic indicators, e.g. if
current assets < current liabilities
there is a liquidity problem.

> If that’s the case, I would think the place to address this is in the report 
> options, not the account structure. (you could use any structure you need, 
> and easily re-group based on the rule you decide or need to follow.)

The tables in
https://de.wikipedia.org/wiki/Gewinn-_und_Verlustrechnung#Gliederung
show the grouping for the 3 regions AT (UGB), DE (HGB) and intl (IFRS).
The latter can be adapted for the less formal US (GAAP). They are shown
for 2 different methods:
Period costing Method (Gesamtkostenverfahren) and
Cost of Sales Method (Umsatzkostenverfahren)

I have currently no idea, how to get this different forms from the
report by options.

> Regards,
> Adrien

Regards
Frank

P.S.
I found a translation of my preferred account template at
https://www.datev.de/web/de/datev-shop/material/skr-04-englisch/


pEpkey.asc
Description: application/pgp-keys
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Adrien Monteleone]

> On Aug 7, 2018, at 5:00 PM, Frank H. Ellenberger 
>  wrote:
> 
> 
> 
> No, the grouping should be part of the account template - at least in
> the current state. At some point in the future one could think about
> additional account attributes to improve reporting...
> 

I think this is only a limitation of the current report. If it’s being 
re-written anyway, I’d suggest:

Default sections for the report, each section having it’s own account selection 
option(s). (not one all-encompassing set of accounts for the entire report)

In the long term, default sections could be labeled based on a preference 
setting for the book/entity. But short term, There could be multiple balance 
sheet ‘reports’ each with the appropriate sections for entity types and/or 
jurisdictions. Or, simply have a set number of sections and you get to name 
each one whatever you want and select its own accounts to include.

This way the user can specify which accounts are ‘current vs. fixed’ or ’short 
term vs. long’, which accounts constitute ‘cash’ and so on. (or whatever the 
sections may be)

Of course, it’s just a suggestion. I can’t say how much extra work that would 
be, but that approach might cover many use cases.

> 
> BTW has somebody a better expression here? For "source" I would expect a
> selection from transaction, price database and online quotes.
> 

’Source’ with those options seems pretty reasonable as to what is being asked 
for. (though maybe preface ’transaction’ with ‘previous’ or something similar)

> 
> From
> https://screenshotscdn.firefoxusercontent.com/images/556716da-ba2e-4bed-9bd7-c7232542ab6f.png
> I am confused. I would have expected:
> Liability and Equity (header)
>  Equity (group)
>  Liability (group)
> Liability and Equity (footer)

I agree, they should appear once, combined is fine as that’s pretty standard, 
but they should only appear once.

Regards,
Adrien
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Frank H. Ellenberger]

Am 06.08.2018 um 14:40 schrieb Christopher Lam:
> 
> (*: we all know Gnucash has evolved through generations rather than a
> grand design )
... because there is no all-purpose, all-country grand design.

> 1) Frank et al requests some analysis of accounts for grouping into
> Short/Long, etc. I disagree. The current balance-sheet does not make any
> judgements into the types of monies held in various asset/liability
> accounts, and I do not particularly think it is universally agreed which
> assets should be long/short-term, which ones are fixed etc. The current
> balance-sheet will just take a nested list of asset/liability accounts,
> and simply list them sequentially, up to depth-limit. The ways that an
> account can be tagged fixed, long or depreciation, contra, etc is not
> something the current balance-sheet can understand, nor am I willing to
> impose my judgement to report. The Tutorial and Concepts Guide does
> encourage that Fixed Assets are held in account structure
> Assets:Fixed:Asset1 and its depreciation amounts are recorded in
> Assets:Fixed:Asset1:Depreciation, and I see no problem in that, and
> balsheet (old or new) will diligently report all amounts.
> 
> However I do understand there may be a wish for a customized balsheet to
> apply heuristics/rules for depreciation/current/fixed etc assets but
> this requires expert accounting knowledge.

No, the grouping should be part of the account template - at least in
the current state. At some point in the future one could think about
additional account attributes to improve reporting...

:
> 3) In the screenshot, EUR Amounts not converted to USD is not confusing
> at all. In the test book there are USD/GBP prices but no USD/EUR prices.
> The old balance-sheet would convert any EUR amount to 0 USD and display
> an incorrect total.4) The amounts being links are a new feature - the
> new income-statement links to a transaction report detailing the
> amounts, and the new balance-sheet links to the register entry which
> documents the exact balance-sheet figure.

At least for official reports, I assume, all assets are expected to be
appraised in local currency. But because the rules differ between
governments and over time, GnuCash can not do it automagical.

Perhaps we should explain in the documentation, that the user should see
this as their input error. They should have at least one price per
commodity. And if they have multiple they should select the "price source".

BTW has somebody a better expression here? For "source" I would expect a
selection from transaction, price database and online quotes.

:
> 7) The sections are copied from balance-sheet and they need
> experimentation... I'd be grateful if anyone can review the section
> amounts are selecting the correct amounts. I don't think I've got it
> 100% correct and need feedback.

From
https://screenshotscdn.firefoxusercontent.com/images/556716da-ba2e-4bed-9bd7-c7232542ab6f.png
I am confused. I would have expected:
Liability and Equity (header)
  Equity (group)
  Liability (group)
Liability and Equity (footer)

BTW an option, which to show first (equity or liability) would be fine
here bacause country specific rules differ here.
Compare the position of "Eigenkapital" in the german and swiss
subsections of
https://de.wikipedia.org/wiki/Bilanz#Aufbau_der_Bilanz

Frank
> C


pEpkey.asc
Description: application/pgp-keys
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Christopher Lam]

Hi All

Thank you for feedback - I *do* take all feedback into account, even if 
I don't always agree with them-- and this is from my understanding of 
Gnucash evolution(*) rather from any expert knowledge of accounting.


(*: we all know Gnucash has evolved through generations rather than a 
grand design )


1) Frank et al requests some analysis of accounts for grouping into 
Short/Long, etc. I disagree. The current balance-sheet does not make any 
judgements into the types of monies held in various asset/liability 
accounts, and I do not particularly think it is universally agreed which 
assets should be long/short-term, which ones are fixed etc. The current 
balance-sheet will just take a nested list of asset/liability accounts, 
and simply list them sequentially, up to depth-limit. The ways that an 
account can be tagged fixed, long or depreciation, contra, etc is not 
something the current balance-sheet can understand, nor am I willing to 
impose my judgement to report. The Tutorial and Concepts Guide does 
encourage that Fixed Assets are held in account structure 
Assets:Fixed:Asset1 and its depreciation amounts are recorded in 
Assets:Fixed:Asset1:Depreciation, and I see no problem in that, and 
balsheet (old or new) will diligently report all amounts.


However I do understand there may be a wish for a customized balsheet to 
apply heuristics/rules for depreciation/current/fixed etc assets but 
this requires expert accounting knowledge.


2) Subtotals being above or below the account-and-children family is 
something that current balsheet already does, and I'm keen to preserve. 
The current balance-sheet allows 4 combinations of 
display/parent-account-subtotal strategies, and 2 of them produce 
nonsensical reports. I've distilled 4 into 2 valid possibilities, and I 
know the 2 other options are nonsensical. From prior discussion, some 
preferred above, and some preferred below, so be it.


Additionally, I have seen numerous examples, from my nested chart of 
accounts with account-depth of 4, that the amount indenting is just 
wrong. I have fixed it.


3) In the screenshot, EUR Amounts not converted to USD is not confusing 
at all. In the test book there are USD/GBP prices but no USD/EUR prices. 
The old balance-sheet would convert any EUR amount to 0 USD and display 
an incorrect total.4) The amounts being links are a new feature - the 
new income-statement links to a transaction report detailing the 
amounts, and the new balance-sheet links to the register entry which 
documents the exact balance-sheet figure.


4) Amounts being indented are not my preference, however they are 
indented in existing balsheet and I'd rather leave the possibility for 
those who prefer. It could be done in CSS, but it's not difficult at all 
to leave it in scheme.


5) Amounts being clickable is a nice addition... do try and see what it 
does.


6) My main concern remains the accuracy of figures -- I use official API 
to retrieve xaccAccountBalanceAsOfDate so I don't doubt the amounts are 
right, but I'm not sure the outcome when unusual CoA are used eg 
depreciation, contra accounts, equity with opening-entries or 
closing-entries etc.


7) The sections are copied from balance-sheet and they need 
experimentation... I'd be grateful if anyone can review the section 
amounts are selecting the correct amounts. I don't think I've got it 
100% correct and need feedback.


C

On 31/07/18 09:04, Adrien Monteleone wrote:

Chris,

Here are my impressions and questions, perhaps I’m not understanding what you 
were trying to show with the screenshot. (does this contain illustrations of 
multiple presentation possibilities all-in-one or is this intended as how the 
report will look by default?)

The asset summary at the top seems confusing and isn’t labeled. If I don’t know 
who or what this entity is or how their books are arranged, how do I know what 
these figures represent?

Each section seems to be missing the standard headings. (Current/Non, Short/Long 
Term, Fixed/Intangible etc.) I know other discussions have touched on the 
duplication in some reports in the menus, but maybe this is how it’s addressed - 
have a basic report that has multiple entries based on the report type desired for 
a particular entity. (or determined by book/app preferences, say report defaults 
for a particular jurisdiction) So there might be a Personal Balance Sheet, Small 
Business Balance Sheet, Public Entity / Non-Profit Statement of Financial Position, 
etc. Each would have the appropriate major sections in the report with the standard 
headings expected for each. The account structure *might* mimic this but it 
shouldn’t have to. The report options should ask the user to select the accounts to 
include for each section. (rather than just one account list for the entire report) 
So you would select the accounts to include in Current Assets, the accounts to 
include in Fixed Assets, the accounts to include in Short Term Liabilities, etc. 

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

[Geert Janssens]

Op dinsdag 31 juli 2018 03:04:25 CEST schreef Adrien Monteleone:
> I see too that some child amounts show in two currencies but not others.
> (looks like just the GBP accounts) Is this intended or just an illustration
> (or an omission)?

I think this is to illustrate how the report would look if some exchange rates 
are missing.

Your remark shows the current state is confusing. I think the report should 
render a note or even warning at the beginning to indicate which exchange 
rates are missing and the consequences this has:
- only the commodity/foreign currency value is displayed
- (more important) these values are not added to any higher level subtotal

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Geert Janssens]

Op vrijdag 27 juli 2018 15:01:17 CEST schreef Christopher Lam:
> Latest iteration of balsheet
> 
>   * restored amount-indenting. IMHO this is now producing sane indenting
> for any subtotal strategy

For a completely different idea: is indenting something that could be handled 
with a css stylesheet ? I imagine adding classes to each account/amount based 
on their level in the account hierarchy, and then in a css stylesheet add 
incremental padding per level. Different stylesheets could then independently 
choose to indent (and how).

>   * option to toggle amount/account indenting

Which would then not be needed. The stylesheet could take care of that for 
you.

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Adrien Monteleone]

Chris,

Here are my impressions and questions, perhaps I’m not understanding what you 
were trying to show with the screenshot. (does this contain illustrations of 
multiple presentation possibilities all-in-one or is this intended as how the 
report will look by default?)

The asset summary at the top seems confusing and isn’t labeled. If I don’t know 
who or what this entity is or how their books are arranged, how do I know what 
these figures represent?

Each section seems to be missing the standard headings. (Current/Non, 
Short/Long Term, Fixed/Intangible etc.) I know other discussions have touched 
on the duplication in some reports in the menus, but maybe this is how it’s 
addressed - have a basic report that has multiple entries based on the report 
type desired for a particular entity. (or determined by book/app preferences, 
say report defaults for a particular jurisdiction) So there might be a Personal 
Balance Sheet, Small Business Balance Sheet, Public Entity / Non-Profit 
Statement of Financial Position, etc. Each would have the appropriate major 
sections in the report with the standard headings expected for each. The 
account structure *might* mimic this but it shouldn’t have to. The report 
options should ask the user to select the accounts to include for each section. 
(rather than just one account list for the entire report) So you would select 
the accounts to include in Current Assets, the accounts to include in Fixed 
Assets, the accounts to include in Short Term Liabilities, etc. Perhaps this 
can be somewhat determined or guessed by default, but that might be lots of 
work. The same would be needed for Income/P

I find totals/subtotals above the child amounts to be odd. Perhaps less 
emphasis on the parent label, with maybe a colon indicator (like on the 
wikipedia entry) would be cleaner with a bold subtotal/total line will make the 
important numbers stand out more. (that is, not showing the amount on the 
initial label line at all)

Also, usually single lines are to delineate figures from subtotals and double 
lines to indicate totals from subtotals. (again like the wikipedia sample)

I don’t think the figures need to be indented as well, just marked off with 
single/double lines and appropriate line-spacing. For account indentions, does 
the report indent contra-accounts? Most statements I’ve seen that have them do 
so.

I understand and like that I have the option for levels deeper than 1 or 2, but 
usually such official statements are intended as an overview, not for detailed 
analysis. They should be very easy to read and decipher without extraneous info 
or styling. And ideally, you should accomplish this with plain-text monospaced. 
Perhaps work it back to that point and then embellish if needed.

A few minor points:
---

Is there is a reason why the child totals are also links? It lends a sense of 
clutter.

I noticed in the Equities & Liabilities section that some figures have no 
currency symbol. While I might be able to figure out what they are by studying 
the document, that info should be more readily discern-able at a glance. I’m 
puzzled by that section though. Usually it’s one or the other (separated or 
consolidated) but not both. Also, the total for Assets and the total for 
Liabilities & Equity should be on the same horizontal line when in 2-column 
mode.

I see too that some child amounts show in two currencies but not others. (looks 
like just the GBP accounts) Is this intended or just an illustration (or an 
omission)?

Regards,
Adrien

> On Jul 27, 2018, at 8:01 AM, Christopher Lam  
> wrote:
> 
> Latest iteration of balsheet
> 
> * restored amount-indenting. IMHO this is now producing sane indenting
>   for any subtotal strategy
> * restore dual columns (i.e. left=asset/income, right=liability/expense)
> * the above two only enabled when multicols are disabled
> * option to toggle amount/account indenting
> * incorporated bug 623381 recommendations for sections labels/totals
> * added sections for equity, liability+equity
> * modify 'original-currency' display to match eguile report i.e.
>   smaller font, precedes converted currency
> 
> I would really like feedback on
> 
> * accuracy of amounts
> * accuracy of sections
> o further tweaking of option names/sections/ordering
> 
> Screenshot:
> https://screenshots.firefox.com/nhaiX1ehSA2GXA97/null
> 
> On 25/07/18 15:53, Frank H. Ellenberger wrote:
>> Am 19.07.2018 um 13:09 schrieb Christopher Lam:
>>> Hi Frank
>>> Thank you - I can restore the dual-columns when the periods have been
>>> disabled.
>>> I'd prefer to limit the number of options; so, if the "period duration" is
>>> disabled, the report will automatically show dual columns
>> while intl. IFRS and DE-GOB/HGB reqire one, US-GAAP requires 3 previous
>> years in the Income statement.
>> https://de.wikipedia.org/wiki/Gewinn-_und_Verlustrechnung#Vorjahresbetr%C3%A4ge
>> 
>>> (Asset/Income=left, Liability+Equity/Expense = right). 

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

[Adrien Monteleone]

Frank,

I’ve been following this for a while, and perhaps I’m not understanding, but 
are the groupings just presentational?

If that’s the case, I would think the place to address this is in the report 
options, not the account structure. (you could use any structure you need, and 
easily re-group based on the rule you decide or need to follow.)

Regards,
Adrien

> On Jul 25, 2018, at 2:53 AM, Frank H. Ellenberger 
>  wrote:
> 
> Am 19.07.2018 um 13:09 schrieb Christopher Lam:
>> Hi Frank
>> Thank you - I can restore the dual-columns when the periods have been
>> disabled.
>> I'd prefer to limit the number of options; so, if the "period duration" is
>> disabled, the report will automatically show dual columns
> 
> while intl. IFRS and DE-GOB/HGB reqire one, US-GAAP requires 3 previous
> years in the Income statement.
> https://de.wikipedia.org/wiki/Gewinn-_und_Verlustrechnung#Vorjahresbetr%C3%A4ge
> 
>> (Asset/Income=left, Liability+Equity/Expense = right). This works?
> 
>> Can you please show me good examples of idealised T-account balance
>> sheet/income statement? Or the scaled form? I have no idea.
> 
> To get an impression you could starting from:
> 
> https://en.wikipedia.org/wiki/Balance_sheet - which has
> #US_small_business in account form and #Sample in scaled form -
> or
> 
> https://en.wikipedia.org/wiki/Income_statement and an example in account
> form: https://debitoor.de/lexikon/gewinn-und-verlustrechnung-guv
> 
> Note: There are several different methods for grouping the positions
> with differrent pros and cons allowed for different company types:
> Gesamtkostenverfahren, Umsatzkostenverfahren & IFRS. Currently I have no
> better idea for the grouping than adjusting the account structure.
> 
> Optionally select other languages e.g.
> https://de.wikipedia.org/wiki/Bilanz#Aufbau_der_Bilanz
> 
> HTH
> Frank
> 
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Christopher Lam]

Latest iteration of balsheet

 * restored amount-indenting. IMHO this is now producing sane indenting
   for any subtotal strategy
 * restore dual columns (i.e. left=asset/income, right=liability/expense)
 * the above two only enabled when multicols are disabled
 * option to toggle amount/account indenting
 * incorporated bug 623381 recommendations for sections labels/totals
 * added sections for equity, liability+equity
 * modify 'original-currency' display to match eguile report i.e.
   smaller font, precedes converted currency

I would really like feedback on

 * accuracy of amounts
 * accuracy of sections
 o further tweaking of option names/sections/ordering

Screenshot:
https://screenshots.firefox.com/nhaiX1ehSA2GXA97/null

On 25/07/18 15:53, Frank H. Ellenberger wrote:

Am 19.07.2018 um 13:09 schrieb Christopher Lam:

Hi Frank
Thank you - I can restore the dual-columns when the periods have been
disabled.
I'd prefer to limit the number of options; so, if the "period duration" is
disabled, the report will automatically show dual columns

while intl. IFRS and DE-GOB/HGB reqire one, US-GAAP requires 3 previous
years in the Income statement.
https://de.wikipedia.org/wiki/Gewinn-_und_Verlustrechnung#Vorjahresbetr%C3%A4ge


(Asset/Income=left, Liability+Equity/Expense = right). This works?
Can you please show me good examples of idealised T-account balance
sheet/income statement? Or the scaled form? I have no idea.

To get an impression you could starting from:

https://en.wikipedia.org/wiki/Balance_sheet - which has
#US_small_business in account form and #Sample in scaled form -
or

https://en.wikipedia.org/wiki/Income_statement and an example in account
form: https://debitoor.de/lexikon/gewinn-und-verlustrechnung-guv

Note: There are several different methods for grouping the positions
with differrent pros and cons allowed for different company types:
Gesamtkostenverfahren, Umsatzkostenverfahren & IFRS. Currently I have no
better idea for the grouping than adjusting the account structure.

Optionally select other languages e.g.
https://de.wikipedia.org/wiki/Bilanz#Aufbau_der_Bilanz

HTH
Frank




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Frank H. Ellenberger]

Am 19.07.2018 um 13:09 schrieb Christopher Lam:
> Hi Frank
> Thank you - I can restore the dual-columns when the periods have been
> disabled.
> I'd prefer to limit the number of options; so, if the "period duration" is
> disabled, the report will automatically show dual columns

while intl. IFRS and DE-GOB/HGB reqire one, US-GAAP requires 3 previous
years in the Income statement.
https://de.wikipedia.org/wiki/Gewinn-_und_Verlustrechnung#Vorjahresbetr%C3%A4ge

> (Asset/Income=left, Liability+Equity/Expense = right). This works?

> Can you please show me good examples of idealised T-account balance
> sheet/income statement? Or the scaled form? I have no idea.

To get an impression you could starting from:

https://en.wikipedia.org/wiki/Balance_sheet - which has
#US_small_business in account form and #Sample in scaled form -
or

https://en.wikipedia.org/wiki/Income_statement and an example in account
form: https://debitoor.de/lexikon/gewinn-und-verlustrechnung-guv

Note: There are several different methods for grouping the positions
with differrent pros and cons allowed for different company types:
Gesamtkostenverfahren, Umsatzkostenverfahren & IFRS. Currently I have no
better idea for the grouping than adjusting the account structure.

Optionally select other languages e.g.
https://de.wikipedia.org/wiki/Bilanz#Aufbau_der_Bilanz

HTH
Frank




pEpkey.asc
Description: application/pgp-keys
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Christopher Lam]

Hi Frank
Thank you - I can restore the dual-columns when the periods have been
disabled.
I'd prefer to limit the number of options; so, if the "period duration" is
disabled, the report will automatically show dual columns
(Asset/Income=left, Liability+Equity/Expense = right). This works?
Can you please show me good examples of idealised T-account balance
sheet/income statement? Or the scaled form? I have no idea.
C



On 19 July 2018 at 05:17, Frank H. Ellenberger <
frank.h.ellenber...@gmail.com> wrote:

> Hi Chris,
>
> Am 18.07.2018 um 15:13 schrieb Christopher Lam:
> > The state of balsheet-pnl.scm, is as follows:
> >
> > I think it is stable and featureful enough to be a replacement, but
> > there are no tests yet to validate a transition. This may happen over
> > the next few months.
> >
> > It incorporates all balance-sheet.scm and income-statement.scm
> > functionality with the following known differences:
> >
> >  * no option to show double-column ie Asset=left, Expense/Equity=right
> >(because I prefer leaving space for multiple data columns )
>
> That is a problem for users in continental Europe, probably also other
> non english speaking countries. We use the traditional T account
> representation, while english speaking countries prefer the scaled (from
> ital. for step stairs) form.
>
> The T account representation easens also simple liqudity checks (current
> assets > current lianilities, medium term assets > medium term
> liabilities ...). Similar comparing groups of income & expense is desired.
>
> IMHO the ability to compare groups is as much, if not more important
> than compares over time.
>
> Regards
> Frank
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Frank H. Ellenberger]

Hi Chris,

Am 18.07.2018 um 15:13 schrieb Christopher Lam:
> The state of balsheet-pnl.scm, is as follows:
> 
> I think it is stable and featureful enough to be a replacement, but
> there are no tests yet to validate a transition. This may happen over
> the next few months.
> 
> It incorporates all balance-sheet.scm and income-statement.scm
> functionality with the following known differences:
> 
>  * no option to show double-column ie Asset=left, Expense/Equity=right
>    (because I prefer leaving space for multiple data columns )

That is a problem for users in continental Europe, probably also other
non english speaking countries. We use the traditional T account
representation, while english speaking countries prefer the scaled (from
ital. for step stairs) form.

The T account representation easens also simple liqudity checks (current
assets > current lianilities, medium term assets > medium term
liabilities ...). Similar comparing groups of income & expense is desired.

IMHO the ability to compare groups is as much, if not more important
than compares over time.

Regards
Frank


pEpkey.asc
Description: application/pgp-keys
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Christopher Lam]

The state of balsheet-pnl.scm, is as follows:

I think it is stable and featureful enough to be a replacement, but 
there are no tests yet to validate a transition. This may happen over 
the next few months.


It incorporates all balance-sheet.scm and income-statement.scm 
functionality with the following known differences:


 * no option to show double-column ie Asset=left, Expense/Equity=right
   (because I prefer leaving space for multiple data columns )
 * no option to hide/show individual sections/their labels (eg
   Display/show asset section)
 * no display/show accounting-style rules (no space at all)
 * flatten list at depth limit (I don't understand its strategy at all
   and prefer to disable it)
 * balance-sheet.scm with Display/Parent-account-balances=none will
   disable amounts for accounts-with-children, which I think is
   nonsensical -- if an account has children, unless its amount is $0,
   it must be displayed, either recursive or multilevel.
 * choosing a common-report-currency when there are missing prices will
   now leave the amount in its original currency, instead of converting
   to $0.00
 * new balsheet will not compute unrealized gains -- from my
   understanding this doesn't belong in the balance sheet
 * I haven't coded the price source to average-cost or
   weighted-average, both of which will set a single exchange rate
   through all multicolumns -- are these options important???

Future plans:

 * I think the account-amount calculating functions are good enough to
   be reused to replace net-charts, category-barchart etc.
 * Hopefully the unintelligible old code can then be dumped for good.

C


On 03/07/18 15:41, Geert Janssens wrote:

Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam:

Hi Stephen, Dave 

Thank you -

Dave - the changes are merely cosmetic therefore easy.

It sounds there are still 2 desired presentational types - (1) Dave's
approach = *recursive-bal* - 'parent' accounts generally collect their
children account amounts; if they also have their own amount, the latter is
rendered on the next line, indented as a child account. (2) Stephen's
approach = *multilevel-bal* - parent accounts' amounts are hidden unless
they exist.


I'm not sure I understand the difference here. Isn't this expressing the same
thing twice in different ways ? Perhaps I'm missing a subtlety in the English
language...

Or is the difference whether the totals are shown above or below the children
?

Geert




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Christopher Lam]

Still at 
https://raw.githubusercontent.com/christopherlam/gnucash/maint-balsheet-pnl/gnucash/report/standard-reports/balsheet-pnl.scm


Latest - removed accountname formatting in recursive-bal. Now they are 
styled normally but the amounts are bold/bigger if they contain 
children-amounts.


https://screenshots.firefox.com/NcMKts75npXbP4Bc/null

C

On 05/07/18 03:40, Stephen M. Butler wrote:

Could you repost the location to pull the latest?  My memory is
over-full and appears to be working the LIFO method of cleanup.


On 07/04/2018 05:13 AM, Christopher Lam wrote:

I've restored multilevel-subtotals... using an easier tack than
previously: instead of keeping lists(1 per account-depth) of lists (1
per column) of collectors, it'll just climb up the hierarchy and print
parent acc's balance+children until the next account-depth is reached.

Please help beta test!

I've made some cosmetic changes too. eg dates in their own row,
double-underline for grand-total only.

I do not think it'll be wise to reduce font sizes for account-depth.

Still remaining:

- fix negative signs strategy


On 03/07/18 16:17, Christopher Lam wrote:

Broadly yes, one approach is that parent accounts always show totals
for themselves+children, the other approach is the totals appear
after each parent+children.

Same information presented in 2 different ways.

The difference is that the recursive subtotals are easier When
reaching an account, it just queries if it has children, and if yes
check if they have own amount, and if yes insert next line for own
account.

Multilevel subtotals require collectors to keeping track of amounts
while cycling the account list.

On Tue, 3 Jul 2018, 15:41 Geert Janssens mailto:geert.gnuc...@kobaltwit.be>> wrote:

 Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam:
 > Hi Stephen, Dave 
 >
 > Thank you -
 >
 > Dave - the changes are merely cosmetic therefore easy.
 >
 > It sounds there are still 2 desired presentational types - (1)
 Dave's
 > approach = *recursive-bal* - 'parent' accounts generally
 collect their
 > children account amounts; if they also have their own amount,
 the latter is
 > rendered on the next line, indented as a child account. (2)
 Stephen's
 > approach = *multilevel-bal* - parent accounts' amounts are
 hidden unless
 > they exist.
 >
 I'm not sure I understand the difference here. Isn't this
 expressing the same
 thing twice in different ways ? Perhaps I'm missing a subtlety in
 the English
 language...

 Or is the difference whether the totals are shown above or below
 the children
 ?

 Geert




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Christopher Lam]

Oops https://screenshots.firefox.com/pttTjFEtYTJLXzam/null

Sorry for spam, fixed screenshot


On 04/07/18 21:20, Christopher Lam wrote:


Forgot to include a screenshot to illustrate

https://screenshots.firefox.com/Z7HOv5pb2qbRc5NP/null

- recursive balance vs. multilevel (and saner alignment of numbers)
- common-currency vs. original currency (notice better handling of 
missing USD/GBP prices than balance-sheet.scm)

- for this illustration periodic columns have been disabled

C


On 04/07/18 20:13, Christopher Lam wrote:


I've restored multilevel-subtotals... using an easier tack than 
previously: instead of keeping lists(1 per account-depth) of lists (1 
per column) of collectors, it'll just climb up the hierarchy and 
print parent acc's balance+children until the next account-depth is 
reached.


Please help beta test!

I've made some cosmetic changes too. eg dates in their own row, 
double-underline for grand-total only.


I do not think it'll be wise to reduce font sizes for account-depth.

Still remaining:

- fix negative signs strategy


On 03/07/18 16:17, Christopher Lam wrote:
Broadly yes, one approach is that parent accounts always show totals 
for themselves+children, the other approach is the totals appear 
after each parent+children.


Same information presented in 2 different ways.

The difference is that the recursive subtotals are easier When 
reaching an account, it just queries if it has children, and if yes 
check if they have own amount, and if yes insert next line for own 
account.


Multilevel subtotals require collectors to keeping track of amounts 
while cycling the account list.


On Tue, 3 Jul 2018, 15:41 Geert Janssens > wrote:


Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam:
> Hi Stephen, Dave 
>
> Thank you -
>
> Dave - the changes are merely cosmetic therefore easy.
>
> It sounds there are still 2 desired presentational types - (1)
Dave's
> approach = *recursive-bal* - 'parent' accounts generally
collect their
> children account amounts; if they also have their own amount,
the latter is
> rendered on the next line, indented as a child account. (2)
Stephen's
> approach = *multilevel-bal* - parent accounts' amounts are
hidden unless
> they exist.
>
I'm not sure I understand the difference here. Isn't this
expressing the same
thing twice in different ways ? Perhaps I'm missing a subtlety
in the English
language...

Or is the difference whether the totals are shown above or below
the children
?

Geert








___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Christopher Lam]

Forgot to include a screenshot to illustrate

https://screenshots.firefox.com/Z7HOv5pb2qbRc5NP/null

- recursive balance vs. multilevel (and saner alignment of numbers)
- common-currency vs. original currency (notice better handling of 
missing USD/GBP prices than balance-sheet.scm)

- for this illustration periodic columns have been disabled

C


On 04/07/18 20:13, Christopher Lam wrote:


I've restored multilevel-subtotals... using an easier tack than 
previously: instead of keeping lists(1 per account-depth) of lists (1 
per column) of collectors, it'll just climb up the hierarchy and print 
parent acc's balance+children until the next account-depth is reached.


Please help beta test!

I've made some cosmetic changes too. eg dates in their own row, 
double-underline for grand-total only.


I do not think it'll be wise to reduce font sizes for account-depth.

Still remaining:

- fix negative signs strategy


On 03/07/18 16:17, Christopher Lam wrote:
Broadly yes, one approach is that parent accounts always show totals 
for themselves+children, the other approach is the totals appear 
after each parent+children.


Same information presented in 2 different ways.

The difference is that the recursive subtotals are easier When 
reaching an account, it just queries if it has children, and if yes 
check if they have own amount, and if yes insert next line for own 
account.


Multilevel subtotals require collectors to keeping track of amounts 
while cycling the account list.


On Tue, 3 Jul 2018, 15:41 Geert Janssens > wrote:


Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam:
> Hi Stephen, Dave 
>
> Thank you -
>
> Dave - the changes are merely cosmetic therefore easy.
>
> It sounds there are still 2 desired presentational types - (1)
Dave's
> approach = *recursive-bal* - 'parent' accounts generally
collect their
> children account amounts; if they also have their own amount,
the latter is
> rendered on the next line, indented as a child account. (2)
Stephen's
> approach = *multilevel-bal* - parent accounts' amounts are
hidden unless
> they exist.
>
I'm not sure I understand the difference here. Isn't this
expressing the same
thing twice in different ways ? Perhaps I'm missing a subtlety in
the English
language...

Or is the difference whether the totals are shown above or below
the children
?

Geert






___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Christopher Lam]

I've restored multilevel-subtotals... using an easier tack than 
previously: instead of keeping lists(1 per account-depth) of lists (1 
per column) of collectors, it'll just climb up the hierarchy and print 
parent acc's balance+children until the next account-depth is reached.


Please help beta test!

I've made some cosmetic changes too. eg dates in their own row, 
double-underline for grand-total only.


I do not think it'll be wise to reduce font sizes for account-depth.

Still remaining:

- fix negative signs strategy


On 03/07/18 16:17, Christopher Lam wrote:
Broadly yes, one approach is that parent accounts always show totals 
for themselves+children, the other approach is the totals appear after 
each parent+children.


Same information presented in 2 different ways.

The difference is that the recursive subtotals are easier When 
reaching an account, it just queries if it has children, and if yes 
check if they have own amount, and if yes insert next line for own 
account.


Multilevel subtotals require collectors to keeping track of amounts 
while cycling the account list.


On Tue, 3 Jul 2018, 15:41 Geert Janssens > wrote:


Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam:
> Hi Stephen, Dave 
>
> Thank you -
>
> Dave - the changes are merely cosmetic therefore easy.
>
> It sounds there are still 2 desired presentational types - (1)
Dave's
> approach = *recursive-bal* - 'parent' accounts generally collect
their
> children account amounts; if they also have their own amount,
the latter is
> rendered on the next line, indented as a child account. (2)
Stephen's
> approach = *multilevel-bal* - parent accounts' amounts are
hidden unless
> they exist.
>
I'm not sure I understand the difference here. Isn't this
expressing the same
thing twice in different ways ? Perhaps I'm missing a subtlety in
the English
language...

Or is the difference whether the totals are shown above or below
the children
?

Geert




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Christopher Lam]

Broadly yes, one approach is that parent accounts always show totals for
themselves+children, the other approach is the totals appear after each
parent+children.

Same information presented in 2 different ways.

The difference is that the recursive subtotals are easier When reaching
an account, it just queries if it has children, and if yes check if they
have own amount, and if yes insert next line for own account.

Multilevel subtotals require collectors to keeping track of amounts while
cycling the account list.

On Tue, 3 Jul 2018, 15:41 Geert Janssens  wrote:

> Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam:
> > Hi Stephen, Dave 
> >
> > Thank you -
> >
> > Dave - the changes are merely cosmetic therefore easy.
> >
> > It sounds there are still 2 desired presentational types - (1) Dave's
> > approach = *recursive-bal* - 'parent' accounts generally collect their
> > children account amounts; if they also have their own amount, the latter
> is
> > rendered on the next line, indented as a child account. (2) Stephen's
> > approach = *multilevel-bal* - parent accounts' amounts are hidden unless
> > they exist.
> >
> I'm not sure I understand the difference here. Isn't this expressing the
> same
> thing twice in different ways ? Perhaps I'm missing a subtlety in the
> English
> language...
>
> Or is the difference whether the totals are shown above or below the
> children
> ?
>
> Geert
>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Geert Janssens]

Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam:
> Hi Stephen, Dave 
> 
> Thank you -
> 
> Dave - the changes are merely cosmetic therefore easy.
> 
> It sounds there are still 2 desired presentational types - (1) Dave's
> approach = *recursive-bal* - 'parent' accounts generally collect their
> children account amounts; if they also have their own amount, the latter is
> rendered on the next line, indented as a child account. (2) Stephen's
> approach = *multilevel-bal* - parent accounts' amounts are hidden unless
> they exist.
> 
I'm not sure I understand the difference here. Isn't this expressing the same 
thing twice in different ways ? Perhaps I'm missing a subtlety in the English 
language...

Or is the difference whether the totals are shown above or below the children 
?

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Christopher Lam]

Hi Stephen, Dave 

Thank you -

Dave - the changes are merely cosmetic therefore easy.

It sounds there are still 2 desired presentational types - (1) Dave's
approach = *recursive-bal* - 'parent' accounts generally collect their
children account amounts; if they also have their own amount, the latter is
rendered on the next line, indented as a child account. (2) Stephen's
approach = *multilevel-bal* - parent accounts' amounts are hidden unless
they exist.

With *multilevel *balances we expect multiple sublevels; so the following
becomes feasible:
Expenses:Household:Child1   (parent-acc without amount)
Expenses:Household:Child1:Sports = $30
Expenses:Household:Child1:Clothing = $40
TOTAL Expenses:Household:Child1 = $70

Expenses:Household:Child2 = $20 (parent-acc with amounts)
Expenses:Household:Child2:Sports = $20
Expenses:Household:Child2:Clothing = $20
TOTAL Expenses:Household:Child2 = $60
TOTAL Expenses:Household = $xxx
TOTAL Expenses = $yyy
^ notice there will be as many TOTAL lines as there are levels from root.

I'll try to restore the multilevel subtotals - I had received no feedback
and it is rather difficult to debug; as I mentioned to Stephen I'd removed
it, but I expect it can be done.

The existing code is a mess and I want them gone, but will need to know the
amounts are correct.

C

On 30 June 2018 at 18:50, DaveC49  wrote:

> Chris,
>  I have the multicolumn report up and running in V3.2. In addition to
> adding
> your file I also had to incorporate it in the CMakeLists.txt in
> ~/gnucash/report/standard-reports to have it available from the menu.
> Initially I will just comment on the presentation, as I don't have a
> testfile setup with which I can check the numbers out yet.
>
> I need to emphasize that these are my personal preferences for clarity of
> presentation and not any accounting profession standard as such. IAS-1
> (https://www.iasplus.com/en/standards/ias/ias1) the IFRS standard does not
> specify any particular layout and format and mainly concentrates on what
> content has to be presented in the four standard financial statements (some
> individual jurisdictions may be more prescriptive):
> Statement of financial position (balance sheet);
> Statement of profit and loss and other comprehensive income;
> Statement of cash flows;
> Statement of changes in equity.
>
> One of the problems of a multicolumn report is in representing an account
> heirarchy which is more than 2 to 3 levels deep as I'm sure you have
> already
> discovered. You run out of ways of clearly delineating the totals at each
> level fairly quickly. This is much easier when you can have a column at
> each
> level of the heirarchy.
>
> 1. I would put the date headings one line up from the Asset Bold heading.
> 2. i wouldn't use double lines under sub-totals within the major Asset,
> Liability and Equity groups but would just use a single line under them and
> reserve the double underline for the total in each of those major sections,
> 3. With the Totals, I would not incorporate the full account heirarchy in
> the heading, but just the parent account that the subtotal is for. Then
> indenting of the account heirarchy can then indicate the heirarchy level
> and
> what are totals at that level. You could perhaps augment this by using
> decreasing font sixes as the heirarchy level increases.
> 4. If it is possible, I would have the total of any transactions direct to
> the parent account displayed in the same manner as any of its child
> accounts
> and balances so that the total displayed for the parent is the balance of
> the direct transactions + any child account totals. If no direct
> transactions, drop this as a line item. Since GnuCash does allow this
> 5. Also consider totalling up rather than down (avoids having to repeat the
> Level Heading with a Total label.
> 6. There is no need for a separate Net Worth item as that is what Equity
> is.
>
> I have attached a LibreOffice document illustrating what I mean by the
> above
> in case it is not clear. I have illustrated a case where Petty Cash is a
> parent account which has transactions into it as well as having a child
> account (Ignore any table lines).
> MultiColumnBalSheetLayoutSuggestions.odt
>  MultiColumnBalSheetLayoutSuggestions.odt>
>
> Hope this helps with some ideas.
>
> Cheers
> David
>
>
>
> -
> David Cousens
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[DaveC49]

Chris,
 I have the multicolumn report up and running in V3.2. In addition to adding
your file I also had to incorporate it in the CMakeLists.txt in
~/gnucash/report/standard-reports to have it available from the menu. 
Initially I will just comment on the presentation, as I don't have a
testfile setup with which I can check the numbers out yet. 

I need to emphasize that these are my personal preferences for clarity of
presentation and not any accounting profession standard as such. IAS-1
(https://www.iasplus.com/en/standards/ias/ias1) the IFRS standard does not
specify any particular layout and format and mainly concentrates on what
content has to be presented in the four standard financial statements (some
individual jurisdictions may be more prescriptive):
Statement of financial position (balance sheet);
Statement of profit and loss and other comprehensive income;
Statement of cash flows;
Statement of changes in equity.

One of the problems of a multicolumn report is in representing an account
heirarchy which is more than 2 to 3 levels deep as I'm sure you have already
discovered. You run out of ways of clearly delineating the totals at each
level fairly quickly. This is much easier when you can have a column at each
level of the heirarchy. 

1. I would put the date headings one line up from the Asset Bold heading.
2. i wouldn't use double lines under sub-totals within the major Asset,
Liability and Equity groups but would just use a single line under them and
reserve the double underline for the total in each of those major sections,
3. With the Totals, I would not incorporate the full account heirarchy in
the heading, but just the parent account that the subtotal is for. Then
indenting of the account heirarchy can then indicate the heirarchy level and
what are totals at that level. You could perhaps augment this by using
decreasing font sixes as the heirarchy level increases.
4. If it is possible, I would have the total of any transactions direct to
the parent account displayed in the same manner as any of its child accounts
and balances so that the total displayed for the parent is the balance of
the direct transactions + any child account totals. If no direct
transactions, drop this as a line item. Since GnuCash does allow this
5. Also consider totalling up rather than down (avoids having to repeat the
Level Heading with a Total label.
6. There is no need for a separate Net Worth item as that is what Equity is.

I have attached a LibreOffice document illustrating what I mean by the above
in case it is not clear. I have illustrated a case where Petty Cash is a
parent account which has transactions into it as well as having a child
account (Ignore any table lines).
MultiColumnBalSheetLayoutSuggestions.odt

  

Hope this helps with some ideas.

Cheers
David



-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[John Ralls]

Chris,

OK, I think that’s a good choice.

As a general design principle I’d like to see the reports use QofQuery as much 
as possible--and extend QofQuery as necessary--because that makes it easier to 
reimplement as database queries.

Regards,
John Ralls


> On Jun 24, 2018, at 2:50 AM, Christopher Lam  
> wrote:
> 
> I think I'll forego a noclosing_balance upgrade in C.
> 
> According to https://bugzilla.gnome.org/show_bug.cgi?id=570042 
>  the "Closing Entries" 
> transactions did not always receive a special KVP-based flag until the commit 
> onhttps://github.com/Gnucash/gnucash/commit/4b2800145 
>  on datafiles generated 
> from 27-11-2008 and later.
> So, to find and exclude these closing entries, we can use the following 
> strategies:
> xaccTransGetIsClosingTxn, will query the KVP flag
> Run a QofQuery and add xaccQueryAddClosingTransMatch (also queries the KVP 
> flag)
> Free-text search "Closing Entries" to seek these old closing entries
> So a P report will necessarily need to do both filtering for KVP and 
> free-text search.
> 
> The multicolumn report will be different enough from the old balance-sheet 
> and income-statement that I think I should spin it off into a different 
> report altogether, and the others will be sunsetted. Hopefully this new 
> report will be broadly acceptable because the old reports have a *lot* of 
> supporting unintelligible old code, especially to handle closing-entries as 
> above.
> 
> C
> 
> On 24/06/18 00:51, Christopher Lam wrote:
>> Hi John, the split->noclosing_balance is updated in 
>> xaccAccountRecomputeBalance. Will continue copypasta coding until it works!
>> 
>> On Sat, 23 Jun 2018, 23:56 John Ralls > > wrote:
>> 
>> 
>> > On Jun 22, 2018, at 9:42 PM, Christopher Lam > > > wrote:
>> > 
>> > Hi All
>> > 
>> > I'm working through balance-sheet.scm and overhauling this report.
>> > 
>> > At the same time, I can see that balance-sheet.scm and 
>> > income-statement.scm can be merged together.
>> > 
>> > After all
>> > 
>> > * balance sheet = asset/liability/equity balance at date X,
>> > * income statement = difference in income/expense balances at date X and Y
>> > 
>> > The issue I have is that the balance sheet can call 
>> > xaccAccountGetBalanceAsOfDate(acc,date) directly to nicely retrieve the 
>> > balance, whereas income statement cannot directly call it because it also 
>> > includes closing transactions.
>> > 
>> > My proposal is to augment xaccAccountGetBalanceAsOfDate to accept a 3rd 
>> > boolean argument i.e. 
>> > xaccAccountGetBalanceAsOfDate(acc,date,ignoreclosing) which will 
>> > selectively produce the balance, ignore closing transactions.
>> > 
>> > This is partly done in the last commit of 
>> > https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
>> >  
>> > 
>> >  - it will augment API everywhere, and also modify Account.cpp, especially 
>> > xaccAccountRecomputeBalance which will call 
>> > xaccTransGetIsClosingTxn(xaccSplitGetParent(split)) for each split in the 
>> > account to determine closing status and cache the balances for each split. 
>> > See draft on 
>> > https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
>> >  
>> > 
>> >  - this currently fails because I'm not good at C.
>> > 
>> > *My query is whether it will be too expensive to call 
>> > xaccTransGetIsClosingTxn for each split in Account.cpp to produce the 
>> > split->noclosing_balance, which will be crucial to calculate income 
>> > between two dates.*
>> > 
>> > *Currently this 'closing-txn' filter is done in income-statement.scm via a 
>> > "Closing Entries" string/regex filter and xaccTransGetIsClosingTxn calls, 
>> > which IMHO is not ideal either.
>> > *
>> > 
>> > Any help welcome!
>> > 
>> > P.S. if this last commit is removed, the 
>> > https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
>> >  
>> > 
>> >  branch contains work-so-far for updated balance-sheet. Screenshot 
>> > https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null 
>> >  - see the 
>> > multilevel subtotals were previously horizonal, are now vertical; 
>> > original-currency amounts, and multiple-date balance sheets.
>> > 
>> > _
>> 
>> Chris,
>> 
>> Only profiling will tell how much of a performance hit this creates.
>> 
>> I don’t see where in your commit you’re computing the split’s no-closing 
>> balance. Perhaps that’s why it doesn’t work?
>> 
>> Regards,
>> John 

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

[Christopher Lam]

Seeking beta testers. This will not be in v3.2.

https://github.com/christopherlam/gnucash/tree/maint-balsheet-pnl

Or, anyone with a relatively recent maint can copy the file directly 
into the build's standard-reports folder: 
https://raw.githubusercontent.com/christopherlam/gnucash/maint-balsheet-pnl/gnucash/report/standard-reports/balsheet-pnl.scm


Adds new balsheet and new income-statement. I still have further ideas 
in the pipeline, just wish to check accuracy of amounts produced. Not 
all options have been implemented. Testing closing amounts through KVP 
wasn't an issue after all; the closing entries are first sought, cached, 
then analyzed as required. For posterity C could also produce noclosing 
balances for easier future reports, but I think this works well so far.


C

On 24/06/18 17:50, Christopher Lam wrote:


I think I'll forego a noclosing_balance upgrade in C.

According to https://bugzilla.gnome.org/show_bug.cgi?id=570042 the 
"Closing Entries" transactions did not always receive a special 
KVP-based flag until the commit on 
https://github.com/Gnucash/gnucash/commit/4b2800145 on datafiles 
generated from 27-11-2008 and later.


So, to find and exclude these closing entries, we can use the 
following strategies:


 1. xaccTransGetIsClosingTxn, will query the KVP flag
 2. Run a QofQuery and add xaccQueryAddClosingTransMatch (also queries
the KVP flag)
 3. Free-text search "Closing Entries" to seek these old closing entries

So a P report will necessarily need to do both filtering for KVP and 
free-text search.


The multicolumn report will be different enough from the old 
balance-sheet and income-statement that I think I should spin it off 
into a different report altogether, and the others will be sunsetted. 
Hopefully this new report will be broadly acceptable because the old 
reports have a *lot* of supporting unintelligible old code, especially 
to handle closing-entries as above.


C

On 24/06/18 00:51, Christopher Lam wrote:
Hi John, the split->noclosing_balance is updated in 
xaccAccountRecomputeBalance. Will continue copypasta coding until it 
works!


On Sat, 23 Jun 2018, 23:56 John Ralls > wrote:




> On Jun 22, 2018, at 9:42 PM, Christopher Lam
mailto:christopher@gmail.com>> wrote:
>
> Hi All
>
> I'm working through balance-sheet.scm and overhauling this report.
>
> At the same time, I can see that balance-sheet.scm and
income-statement.scm can be merged together.
>
> After all
>
> * balance sheet = asset/liability/equity balance at date X,
> * income statement = difference in income/expense balances at
date X and Y
>
> The issue I have is that the balance sheet can call
xaccAccountGetBalanceAsOfDate(acc,date) directly to nicely
retrieve the balance, whereas income statement cannot directly
call it because it also includes closing transactions.
>
> My proposal is to augment xaccAccountGetBalanceAsOfDate to
accept a 3rd boolean argument i.e.
xaccAccountGetBalanceAsOfDate(acc,date,ignoreclosing) which will
selectively produce the balance, ignore closing transactions.
>
> This is partly done in the last commit of

https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
- it will augment API everywhere, and also modify Account.cpp,
especially xaccAccountRecomputeBalance which will call
xaccTransGetIsClosingTxn(xaccSplitGetParent(split)) for each
split in the account to determine closing status and cache the
balances for each split. See draft on

https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
- this currently fails because I'm not good at C.
>
> *My query is whether it will be too expensive to call
xaccTransGetIsClosingTxn for each split in Account.cpp to produce
the split->noclosing_balance, which will be crucial to calculate
income between two dates.*
>
> *Currently this 'closing-txn' filter is done in
income-statement.scm via a "Closing Entries" string/regex filter
and xaccTransGetIsClosingTxn calls, which IMHO is not ideal either.
> *
>
> Any help welcome!
>
> P.S. if this last commit is removed, the

https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
branch contains work-so-far for updated balance-sheet. Screenshot
https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null - see the
multilevel subtotals were previously horizonal, are now vertical;
original-currency amounts, and multiple-date balance sheets.
>
> _

Chris,

Only profiling will tell how much of a performance hit this creates.

I don’t see where in your commit you’re computing the split’s
no-closing balance. Perhaps that’s why it doesn’t work?

Regards,
John Ralls

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

[Christopher Lam]

I think I'll forego a noclosing_balance upgrade in C.

According to https://bugzilla.gnome.org/show_bug.cgi?id=570042 the 
"Closing Entries" transactions did not always receive a special 
KVP-based flag until the commit on 
https://github.com/Gnucash/gnucash/commit/4b2800145 on datafiles 
generated from 27-11-2008 and later.


So, to find and exclude these closing entries, we can use the following 
strategies:


1. xaccTransGetIsClosingTxn, will query the KVP flag
2. Run a QofQuery and add xaccQueryAddClosingTransMatch (also queries
   the KVP flag)
3. Free-text search "Closing Entries" to seek these old closing entries

So a P report will necessarily need to do both filtering for KVP and 
free-text search.


The multicolumn report will be different enough from the old 
balance-sheet and income-statement that I think I should spin it off 
into a different report altogether, and the others will be sunsetted. 
Hopefully this new report will be broadly acceptable because the old 
reports have a *lot* of supporting unintelligible old code, especially 
to handle closing-entries as above.


C

On 24/06/18 00:51, Christopher Lam wrote:
Hi John, the split->noclosing_balance is updated in 
xaccAccountRecomputeBalance. Will continue copypasta coding until it 
works!


On Sat, 23 Jun 2018, 23:56 John Ralls > wrote:




> On Jun 22, 2018, at 9:42 PM, Christopher Lam
mailto:christopher@gmail.com>> wrote:
>
> Hi All
>
> I'm working through balance-sheet.scm and overhauling this report.
>
> At the same time, I can see that balance-sheet.scm and
income-statement.scm can be merged together.
>
> After all
>
> * balance sheet = asset/liability/equity balance at date X,
> * income statement = difference in income/expense balances at
date X and Y
>
> The issue I have is that the balance sheet can call
xaccAccountGetBalanceAsOfDate(acc,date) directly to nicely
retrieve the balance, whereas income statement cannot directly
call it because it also includes closing transactions.
>
> My proposal is to augment xaccAccountGetBalanceAsOfDate to
accept a 3rd boolean argument i.e.
xaccAccountGetBalanceAsOfDate(acc,date,ignoreclosing) which will
selectively produce the balance, ignore closing transactions.
>
> This is partly done in the last commit of

https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
- it will augment API everywhere, and also modify Account.cpp,
especially xaccAccountRecomputeBalance which will call
xaccTransGetIsClosingTxn(xaccSplitGetParent(split)) for each split
in the account to determine closing status and cache the balances
for each split. See draft on

https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
- this currently fails because I'm not good at C.
>
> *My query is whether it will be too expensive to call
xaccTransGetIsClosingTxn for each split in Account.cpp to produce
the split->noclosing_balance, which will be crucial to calculate
income between two dates.*
>
> *Currently this 'closing-txn' filter is done in
income-statement.scm via a "Closing Entries" string/regex filter
and xaccTransGetIsClosingTxn calls, which IMHO is not ideal either.
> *
>
> Any help welcome!
>
> P.S. if this last commit is removed, the

https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
branch contains work-so-far for updated balance-sheet. Screenshot
https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null - see the
multilevel subtotals were previously horizonal, are now vertical;
original-currency amounts, and multiple-date balance sheets.
>
> _

Chris,

Only profiling will tell how much of a performance hit this creates.

I don’t see where in your commit you’re computing the split’s
no-closing balance. Perhaps that’s why it doesn’t work?

Regards,
John Ralls



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Christopher Lam]

Hi John, the split->noclosing_balance is updated in
xaccAccountRecomputeBalance. Will continue copypasta coding until it works!

On Sat, 23 Jun 2018, 23:56 John Ralls  wrote:

>
>
> > On Jun 22, 2018, at 9:42 PM, Christopher Lam 
> wrote:
> >
> > Hi All
> >
> > I'm working through balance-sheet.scm and overhauling this report.
> >
> > At the same time, I can see that balance-sheet.scm and
> income-statement.scm can be merged together.
> >
> > After all
> >
> > * balance sheet = asset/liability/equity balance at date X,
> > * income statement = difference in income/expense balances at date X and
> Y
> >
> > The issue I have is that the balance sheet can call
> xaccAccountGetBalanceAsOfDate(acc,date) directly to nicely retrieve the
> balance, whereas income statement cannot directly call it because it also
> includes closing transactions.
> >
> > My proposal is to augment xaccAccountGetBalanceAsOfDate to accept a 3rd
> boolean argument i.e. xaccAccountGetBalanceAsOfDate(acc,date,ignoreclosing)
> which will selectively produce the balance, ignore closing transactions.
> >
> > This is partly done in the last commit of
> https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
> - it will augment API everywhere, and also modify Account.cpp, especially
> xaccAccountRecomputeBalance which will call
> xaccTransGetIsClosingTxn(xaccSplitGetParent(split)) for each split in the
> account to determine closing status and cache the balances for each split.
> See draft on
> https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
> - this currently fails because I'm not good at C.
> >
> > *My query is whether it will be too expensive to call
> xaccTransGetIsClosingTxn for each split in Account.cpp to produce the
> split->noclosing_balance, which will be crucial to calculate income between
> two dates.*
> >
> > *Currently this 'closing-txn' filter is done in income-statement.scm via
> a "Closing Entries" string/regex filter and xaccTransGetIsClosingTxn calls,
> which IMHO is not ideal either.
> > *
> >
> > Any help welcome!
> >
> > P.S. if this last commit is removed, the
> https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
> branch contains work-so-far for updated balance-sheet. Screenshot
> https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null - see the
> multilevel subtotals were previously horizonal, are now vertical;
> original-currency amounts, and multiple-date balance sheets.
> >
> > _
>
> Chris,
>
> Only profiling will tell how much of a performance hit this creates.
>
> I don’t see where in your commit you’re computing the split’s no-closing
> balance. Perhaps that’s why it doesn’t work?
>
> Regards,
> John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[John Ralls]

> On Jun 22, 2018, at 9:42 PM, Christopher Lam  
> wrote:
> 
> Hi All
> 
> I'm working through balance-sheet.scm and overhauling this report.
> 
> At the same time, I can see that balance-sheet.scm and income-statement.scm 
> can be merged together.
> 
> After all
> 
> * balance sheet = asset/liability/equity balance at date X,
> * income statement = difference in income/expense balances at date X and Y
> 
> The issue I have is that the balance sheet can call 
> xaccAccountGetBalanceAsOfDate(acc,date) directly to nicely retrieve the 
> balance, whereas income statement cannot directly call it because it also 
> includes closing transactions.
> 
> My proposal is to augment xaccAccountGetBalanceAsOfDate to accept a 3rd 
> boolean argument i.e. xaccAccountGetBalanceAsOfDate(acc,date,ignoreclosing) 
> which will selectively produce the balance, ignore closing transactions.
> 
> This is partly done in the last commit of 
> https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
>  - it will augment API everywhere, and also modify Account.cpp, especially 
> xaccAccountRecomputeBalance which will call 
> xaccTransGetIsClosingTxn(xaccSplitGetParent(split)) for each split in the 
> account to determine closing status and cache the balances for each split. 
> See draft on 
> https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
>  - this currently fails because I'm not good at C.
> 
> *My query is whether it will be too expensive to call 
> xaccTransGetIsClosingTxn for each split in Account.cpp to produce the 
> split->noclosing_balance, which will be crucial to calculate income between 
> two dates.*
> 
> *Currently this 'closing-txn' filter is done in income-statement.scm via a 
> "Closing Entries" string/regex filter and xaccTransGetIsClosingTxn calls, 
> which IMHO is not ideal either.
> *
> 
> Any help welcome!
> 
> P.S. if this last commit is removed, the 
> https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
>  branch contains work-so-far for updated balance-sheet. Screenshot 
> https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null - see the multilevel 
> subtotals were previously horizonal, are now vertical; original-currency 
> amounts, and multiple-date balance sheets.
> 
> _

Chris,

Only profiling will tell how much of a performance hit this creates.

I don’t see where in your commit you’re computing the split’s no-closing 
balance. Perhaps that’s why it doesn’t work?

Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Christopher Lam]

Hi All

I'm working through balance-sheet.scm and overhauling this report.

At the same time, I can see that balance-sheet.scm and 
income-statement.scm can be merged together.


After all

 * balance sheet = asset/liability/equity balance at date X,
 * income statement = difference in income/expense balances at date X and Y

The issue I have is that the balance sheet can call 
xaccAccountGetBalanceAsOfDate(acc,date) directly to nicely retrieve the 
balance, whereas income statement cannot directly call it because it 
also includes closing transactions.


My proposal is to augment xaccAccountGetBalanceAsOfDate to accept a 3rd 
boolean argument i.e. 
xaccAccountGetBalanceAsOfDate(acc,date,ignoreclosing) which will 
selectively produce the balance, ignore closing transactions.


This is partly done in the last commit of 
https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances 
- it will augment API everywhere, and also modify Account.cpp, 
especially xaccAccountRecomputeBalance which will call 
xaccTransGetIsClosingTxn(xaccSplitGetParent(split)) for each split in 
the account to determine closing status and cache the balances for each 
split. See draft on 
https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances 
- this currently fails because I'm not good at C.


*My query is whether it will be too expensive to call 
xaccTransGetIsClosingTxn for each split in Account.cpp to produce the 
split->noclosing_balance, which will be crucial to calculate income 
between two dates.*


*Currently this 'closing-txn' filter is done in income-statement.scm via 
a "Closing Entries" string/regex filter and xaccTransGetIsClosingTxn 
calls, which IMHO is not ideal either.

*

Any help welcome!

P.S. if this last commit is removed, the 
https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances 
branch contains work-so-far for updated balance-sheet. Screenshot 
https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null - see the 
multilevel subtotals were previously horizonal, are now vertical; 
original-currency amounts, and multiple-date balance sheets.


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel