Future allocated money, aka Envelope Budgeting

Christopher Lam christopher.lck at gmail.com
Thu Feb 1 09:22:33 EST 2018


Hi Adrien,

 From reviewing the code, I still believe the (b)udget transactions 
system works better. The current code calculates all 
Reconciled/Cleared/Unreconciled balances on the fly, and it'll be pretty 
easy to add one for Budget balances. If I'm right, a book with large 
number of transactions over years will require perhaps 20 (b)udget 
transactions per year, which will hardly be straining the datafile or 
the code.

It is also compatible with the suggestion for "manually triggered SX" or 
"transaction templates".

The only feature that the envelope system doesn't support is an 'expiry 
date' for the budget -- some people may prefer monthly/quarterly/annual 
budgets, and so far I can't think how this would work. The register 
would really just need color coding to identify 'balance too close to 
budget' situations.

Try opening a register and see View > Filter by... > Status you'll see 
all 5 statuses are ticked. If by default the suggested "b" transactions 
are disabled then the average user will never see them.

My suggestion also obviates the need for the shadow accounts as your 
recommendation.

IMHO Using a separate kvp system will lead to performance issues similar 
to current Budget on Windows.

I'm rather tempted to hack the code to calculate the budgeted amounts by 
abusing the current (v)oid transactions UI, and it seems very doable :-o

Chris


On 01/02/18 22:05, Adrien Monteleone wrote:
>> On Jan 31, 2018, at 2:48 PM, Phil Longstaff <phil.longstaff at gmail.com> wrote:
>>
>>
>> On Wed, Jan 31, 2018 at 11:35 AM, Adrien Monteleone <adrien.monteleone at gmail.com <mailto:adrien.monteleone at gmail.com>> wrote:
>>
>>
>>> On Jan 31, 2018, at 10:09 AM, Christopher Lam <christopher.lck at gmail.com <mailto:christopher.lck at gmail.com>> wrote:
>>>
>>> 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 amount.
> But I see they aren’t exposed in the Account Edit window. The only way to see what was budgeted is to open the budget module, or to see what’s left is to run a budget report. And even that part is limited as it’s only a all-or-nothing figure for the year, not year-to-date.
>
> Regards,
> Adrien
>>   
>>
>> 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 account.
>>   
>> Phil
> Thanks for clearing that up. Certainly, that seems the more sane route. I would think another set of kvp could be implemented to handle the envelope system then. One set to hold the amount already allocated and another to hold the allocation formula. The original budget pair could be used as the goal.
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel



More information about the gnucash-devel mailing list