On Wed, Jan 31, 2018 at 11:35 AM, Adrien Monteleone <
> > On Jan 31, 2018, at 10:09 AM, Christopher Lam <christopher....@gmail.com>
> > Hi Matt- I thought this should move to the devel list, because of
> technical details, and this discussion will be very speculative.
> > I had a thought about how envelope budgeting could work: "divide your
> paycheck into separate envelopes for different purposes".
> > A solution: *Create another type of transaction.*
> > There's already u(n)reconciled, (c)leared, (y)reconciled, (v)oid
> transactions. And (f)rozen I believe is unused. Let's create a new type -
> (b)udget. But the balances are handled differently.
> > It would require some UI and calculations changes --
> > 1. The account budget balance is always maintained similarly to
> Running/Reconciled/Cleared Balances. But it would count all previous
> split-values *and* the (b)udget split amounts. However the budget running
> balance is not shown in the default register. This means, existing
> balances/register are unchanged.
> Having transactions in an account register that don’t affect the balance
> is going to be very problematic. I think this would really confuse users.
> I would think budget levels for each expense account could be exposed in
> the properties/preferences for each one.
That's basically how it's done now. It uses the kvp (key-value pair)
mechanism and each account has a kvp per budget per period with the budget
> The allocation of budget money would have to be handled with a special
> dialog on demand, or as part of an income/asset account preferences with
> percentages/formulas. (essentially a template transaction that fires when
> entries are made in that account)
> We already have a budgeting mechanism to set how much we *want* to spend
> on a particular expense.
> What we’re discussing here is a way to ‘save up’ funds received for each
> of those expenses.
> If I understand correctly, the budget module uses hidden accounts to keep
> track of everything. I would think these same accounts, or other hidden
> accounts paired with them, could do the job.
This is incorrect. It uses kvp (key-value pair) structures attached to each
gnucash-devel mailing list