Budgets and inconsistent handling of account sign reversal.

Jeff Kletsky gnucash at allycomm.com
Mon Feb 22 10:06:48 EST 2010

Good news?

A budget report using eguile runs in a couple seconds, instead of nearly 
20 using the HTML-renderer classes.

Bad news?

Looks like budgets, as they exist today, are apparently unaware of the 
sign-ed-ness of accounts and "ignore" the sign-reversed options (None, 
Income & Expense, or Credit Accounts).

This means that, depending on how you set those flags in the UI, you may 
be on-target, or off target by a factor of two (positive budget for 
expenses, but with negative expenses, due to UI settings). I haven't 
assessed the breadth of the changes that it would entail, but, in my 
opinion, having budget values behave consistently with account values 
seems like a reasonable objective.

If I do decide to tackle having the "internal" budget numbers consistent 
with their associated accounts, and the UI representations responsive to 
the sign-reversed accounts settings (both the budget entry screen and 
reports need "fixes" from what I can tell), how does GNUCash handle 
schema and/or data upgrades? Is there a precedent for how object 
representations are updated from one version to the next? The "ideal" 
thing from a user perspective would be that nothing is seen, at least 
for those users that have "Credit Accounts" for their selection.



More information about the gnucash-devel mailing list