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