Dear Devs
The more I consider (b)udget transactions the more I feel it is the
right solution. See
https://docs.google.com/spreadsheets/d/1aaMoMVVTky_Df_haNAeVk3XpsgFIC7eMOOT7uurlV-s/edit?usp=sharing
for an example of a report with these "b"udget and regular transactions.
This demonstrates regular $50 monthly budgeting, and quarterly $300
spending, with 1 overspending, and 1 underspending. It also works with
closing transactions... which are either enabled/disabled according to a
random switch. The chart can also demonstrate the metaphorical envelope.
I think this can easily be hacked into code.
The dilemma is to consider how to modify the schema to achieve this:
option (1) reuse (v)oided transactions which can ensure the datafile is
backward-compatible and the balances are not affected in previous
version, with a kvp flag on the transactions, to identify budgetary
transfers. This will be similar to how closing txns are flagged.
Advantages - are that existing code will count the split amounts as
zero. Previous versions will display the transfers as "v" txns.
Disadvantage - will be budget transactions being treated similar to
voided transactions, in the UI code and will require special handling.
Accessing budgetary amounts will need mechanism similar to
xaccSplitVoidFormerValue.
option (2) add "b" for budget transactions as a clean slate for 3.0
datafiles onwards.
Advantage - clear transaction-type.
Disadvantage - datafile not compatible with previous versions. Requires
special handling within xaccAccountRecomputeBalance to ignore them.
option (3) add these transactions in a separate part of the datafile,
outside the accounts splitlist.
Major Disadvantage - requires numerous code, UI and schema changes.
Either way I'd be grateful if some pointers could be offered? Even if
code, UI and reports are not completed in time for 3.0, it would be nice
to formalize the schema 3.0 release?
I may be able to do TDD for this @rgmerk
Thanks!
On 01/02/18 22:45, Adrien Monteleone wrote:
On Feb 1, 2018, at 8:22 AM, Christopher Lam<christopher....@gmail.com> wrote:
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”.
That enhancement was only for an actual transaction that moves money from a
parent to sub-accounts. I didn’t intend that as a separate layer ‘virtual’
transaction. But yes, I see it could work for both.
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.
My understanding is that the envelopes don’t expire, it’s a retained ‘savings’
so I get they don’t have a date. That doesn’t preclude budgeting by period
though. Say you set a spending budget of $100/$300/$1200 for dining out
(monthly, quarterly, yearly) then you use that as your envelope goal. As you
allocate, you can see if you have hit your goal. (if so, the allocation stops)
If you end up spending under budget, that money remains allocated. (unless you
flow it somewhere else) You’ll just have a head start in your savings plan when
the next period cycles around. An additional calculation would be needed here.
At any point in time, you’d need to see the remaining goal to be saved for.
There should also be a mechanism for letting the user decide how to control the
allocation or flow of money to the envelopes. This could be a ‘stop’ situation
based on if either the monthly, quarterly, or yearly goals are reached. Someone
might want to set a high % to be allocated until perhaps one or two quarters
are saved up, then back off a bit. Or they might want to leave it high until
the goal is reached, but keep saving at a lower level. (that part is good for
emergency funds or debt retirement) Or they might want to only allocate each
month until the goal is reached (which might be the first pay check) and then
stop until the month rolls over.
I know this is sounding more complicated, but if the user can’t control their
savings rate and plan, they probably aren’t going to use the feature much.
By the way, I do like the idea of some sort of color warning with respect to
hitting budget limits.
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.
That changes things entirely. I see no UX issues then.
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’ve heard there was some problems there but didn’t realize that was the cause.
I wonder why that is. Since the user doesn’t have to be exposed to the budget
transactions by default, I don’t see an issue changing to that method then.
Whatever is most efficient.
On that note you might need two status levels. A ‘b’ for ‘budget’ to handle the
current functionality and an ‘e/s’ for ‘envelopes/savings’ to handle savings
toward those budget goals.
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
Let me know when you do. I’d be interested in seeing the work and in testing.
And I’ll be happy to help where I can.
Regards,
Adrien
Chris
On 01/02/18 22:05, Adrien Monteleone wrote:
On Jan 31, 2018, at 2:48 PM, Phil Longstaff<phil.longst...@gmail.com> wrote:
On Wed, Jan 31, 2018 at 11:35 AM, Adrien Monteleone <adrien.montele...@gmail.com
<mailto:adrien.montele...@gmail.com>> wrote:
On Jan 31, 2018, at 10:09 AM, Christopher Lam <christopher....@gmail.com
<mailto:christopher....@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@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
