Patch to partially add recursion to budgets

[Chris Shoemaker]

On Wed, Sep 27, 2006 at 12:59:34AM -0500, Gregory Alexander wrote:
> Budgets are almost what I need to get gnucash to do what I want.
> 
> I'm having a problem in that budget behavior is inconsistently
> recursive over accounts.  I have a bug open on that.

Honestly, I read that bug once, and didn't immediately understand it,
and figured I would just wait until I had more time to look more
closely at it.  However, in light of this patch, I'm thinking that
what you describe is probably not so much a bug as a difference of
expectations.  See below...

> 
> Attached is a patch that starts along the path of making recursion
> optional for budget calls, but stops short of propogating the change
> all the way up to the report interface.
> 
> Would people please comment if I'm on the right track?  I modeled the
> recursive behavior off Accounts.c

Ok, this is certainly one direction to go.  You might be able to
gather from the design notes at the top of gnc-budget.h why I didn't
go this way.  Just to clarify the implications of this approach: 

At the end of the day, you need two sets of comparable numbers,
actuals and budgeted.  To be comparable, they need to be either both
recursive or both not.  

Currently, GnuCash only supports "both recursive".  However, that
_doesn't_ mean that budgeted values are summed from children accounts'
budgeted values.  (That would quickly become very complicated in
multi-currency situations.)  Instead, the user specifies the "summary"
budgeted value, i.e. recursive.  (To verify this, try out the bugdet
estimator tool.)  In this implementation you don't have the ability to
budget for transactions that post to a parent account while excluding
transactions that post to the account's children.  I think this is an
uncommon need.

So, what would happen if GnuCash supported "both not recursive"?  For
one, you now have to specify budget values for the actual accounts
that transactions are posted to.  You lose the ability to choose a
parent account, and to budget at a level of detail less than what you
use for accounting.  I think this is quite a common need.

Side note: Can you specify budgets non-recursively, but then report
recursively?  Maybe, but then the "reported" budget value for a parent
account with some non-recursive value is different than the
"specified" budget value for that account.  Isn't that pretty weird?

Anyway, I concluded that being able to budget at different levels of
detail was more important than being able to budget for accounts
excluding their children.

That said, if you really want to specify budgets non-recursively, then
you're really changing the meaning of the stored values, so you should
reflect that in the budget model, with an additional boolean structure
member.  That way, you can ensure that the reporting is consistent
with the specification method.


-chris


> 
> Thanks!


> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel