GnuCash Opens Dirty?

[David T. via gnucash-devel]

Hello,

When I open GnuCash with no file (i.e., “gnucash --nofile”), I find that if I 
immediately attempt to open a different file or exit the program altogether 
(i.e., without doing anything to the current session), I am warned that all 
changes to the current file will be lost. Given that I: a) have made no 
changes, and b) have “nofile” open at the time, this dialog is absurd. 

GnuCash should NOT consider “nofile” to be dirty, and thus should NOT ask that 
I save “nofile”. I don’t see any bugs filed for this.

David 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: What version of txf export used in windows version 2.6.19

[Alex Aycinena]

Jeffrey,

I don't recall where I got it, but I will send a copy directly to your
email when I can get to the machine that it is on.

Regards,

Alex

On Fri, Feb 2, 2018 at 4:10 PM, jeffrey black 
wrote:

> On 1/30/2018 3:41 PM, Alex Aycinena wrote:
>
>
> -- Forwarded message --
>> From: Jeffrey Black 
>> To: gnucash-devel@gnucash.org
>> Cc:
>> Bcc:
>> Date: Sat, 27 Jan 2018 18:13:02 -0700 (MST)
>> Subject: What version of txf export used in windows version 2.6.19
>> I tried importing my txf output file into H block Premium 2017, hoping
>> it
>> works this year.  It doesn't.  I know they have a problem with importing,
>> it
>> creates multiple copies of schedules C and F.  That is their problem not
>> GnuCash.
>>
>> I am under U.S. 1040 tax code.  Using windows version 2.6.19 of GnuCash.
>>
>> 3 questions.
>>
>> 1)  Looking in the txf.scm file it looks like you are using V42 not V41
>> from
>> the date fields. IE.
>>
>> (cons 'N370 #(none "Sched F" "Custom hire (machine work)" 1 #t ""
>> ((2012
>> "7") (2011 "7a or b") (1990 "9"
>>
>> Which version is it actually exporting?  V41 or V42?  The header says V41.
>>
>>
> The latest version as of the report re-write was V41, dated 6/16/06, which
> was used. The dates you see are used for the report formatting and have
> nothing to do with the TXF output or the version of the txf spec. It has
> not been updated, yet, to version 42 because I did not know of it until
> just now.
>
>
>
>> 2)  Also, there is very little information available about the internal
>> format of a .TXF file.  In Windows, does it matter if each line with data
>> ends in a carriage return , then followed by a blank line of only
>>  ?IE:
>>
>> V041
>> 
>> AGnuCash 2.6.19
>> 
>> D01/26/2018
>> 
>> ^
>> etc..
>>
>>
> I don't know the answer to that specifically. When the report was first
> re-written there was a problem initially on the Windows platform with line
> endings that was fixed and tested by the user on Windows that reported the
> problem. I don't recall what tax software he used. You could test the
> relevance of the blank lines by using a text editor with a small sample to
> try different combinations and see if you get different results.
>
>
>
>> 3)  there are only 685 codes in V041 and 717 codes in Version 042, all 3
>> digits.  Where did you find the codes with four digits?
>>
>>
> There is a TXF Spec for Business "Business Tax Exchange Format for Forms
> 1065, 1120, 1120S, 990, 990-PF, 990-T", V41, that was used.
>
>
>
>>
>>
>> --JEffrey Black M.B.A.
>>
>
>
>  Regards,
>
> Alex
>
> Alex:
>
> Thank you for the information.
>
> Hopefully GnuCash V3 will have increased support for all of the V42 tax
> codes.  I will add it to the wish list.  And while I am at it, wish that
> Inuit and co-conspirators would update the TXF to V43 (not likely), so it
> fits more of the new or updated forms.
>
> Considered doing a build of GnuCash on my own, with the V42 codes and
> quickly rejected the idea.  I do not have time right now to even begin to
> attempt to update all of the related source code.
>
> As for importing TXF files containing references to schedules C and F, H
> Block's techs have absolutely no idea how to do it either.  Meaning they do
> not support it.  Thankfully the printed report generated by GnuCash lists
> the form and last known line where data goes.  Anything that makes filling
> out IRS forms faster and easier is a god send.
>
> In regards to the V41 business tax codes, I have been unable to locate the
> specs for it.  Can and would you point me to a link for it?
>
> --JEffrey Black M.B.A.
>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

RE: Future allocated money, aka Envelope Budgeting

[Matt Graham]

Wow! That become contentious quick!!!

The primary issue I’m seeing here is one of philosophy. What is GNUCash for? 
What is the purpose? What “should” be included and what “shouldn’t” be?
As has been highlighted, when someone loads up software they have a preset 
notion in their own mind of how it “should” work, and that is usually their own 
very narrow context (e.g. “That’s not how budgets work!”).

My assumption on purpose: Open source software is created out of need and 
altruism. People who know how and want help create and maintain the project 
both because they are interested in software and enjoy the process, but also 
because they like being altruistic and providing something that others find 
useful.

Based on that assumption, I have had the attitude “All requests should be 
considered and prioritised by the devs, but of course they will mainly 
implement what they find useful and of course they will only give how much time 
they can afford to”.

The natural flow on from my attitude is that I should indeed throw in what I 
want/need from my financial tools, but not expect anyone to act on it. If I 
want it done, I need to donate my time and implement it because it is 
definitely unreasonable to demand others to do it when it isn’t useful for 
them. (On that note, I’m keen to help out, but don’t yet have knowledge (and 
also struggle for time) in all this).

I have lots of specific comments against what people are saying, but all would 
be unhelpful if my fundamental attitude to the project is wrong.

Thanks and regards,

Matt

From: John Ralls
Sent: Saturday, 3 February 2018 3:51 AM
Cc: gnucash-devel
Subject: Re: Future allocated money, aka Envelope Budgeting



> On Feb 2, 2018, at 7:25 AM, Wm via gnucash-devel  > wrote:
>
> There is, IMO, work to be done on on the underlying db structure, have you 
> seen this monster ?
> ===
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.gnucash.org%2Fwiki%2Fimages%2F8%2F86%2FGnucash_erd.png=02%7C01%7C%7C6ee9ecfa03c24c97580d08d56a5d2671%7C84df9e7fe9f640afb435%7C1%7C0%7C636531870670279982=aEzd9p0oY9t1%2Bczj66N5%2Fg3bfwhBmGEq6YCXy2xn%2FEA%3D=0
>  
> 
> ===
> It is as ugly as an ugly thing (I'd say what I thought but I'd like more than 
> a  mod to get to read this).

Sure is.

Step 1 in getting to being able to clean it up was converting the backend that 
implements it to C++ with clearly defined objects instead of a rather quirky 
collection of macros. That’s in the current “unstable” and will be released in 
3.0.

Step 2 is to convert the corresponding objects in libgnucash/engine to C++ 
objects with proper constructors so that creating an object doesn’t involve 
calling a bunch of property setters (one at a time!) that want to commit the 
object and write it back to the database. That will be my focus for the next 
development cycle.

Once that’s in hand we can consider refactoring the schema into something a bit 
more reasonable and get away from sucking the whole DB into memory at load time.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnucash.org%2Fmailman%2Flistinfo%2Fgnucash-devel=02%7C01%7C%7C6ee9ecfa03c24c97580d08d56a5d2671%7C84df9e7fe9f640afb435%7C1%7C0%7C636531870670279982=hTrghqjNt8XEYkE05%2FGtO7YQQre21RRVh%2Fm9LZMP8LY%3D=0

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: What version of txf export used in windows version 2.6.19

[jeffrey black]

On 1/30/2018 3:41 PM, Alex Aycinena wrote:

-- Forwarded message --
From: Jeffrey Black 
>
To: gnucash-devel@gnucash.org
Cc:
Bcc:
Date: Sat, 27 Jan 2018 18:13:02 -0700 (MST)
Subject: What version of txf export used in windows version 2.6.19
I tried importing my txf output file into H block Premium 2017, hoping it
works this year.  It doesn't.  I know they have a problem with importing, it
creates multiple copies of schedules C and F.  That is their problem not
GnuCash.

I am under U.S. 1040 tax code.  Using windows version 2.6.19 of GnuCash.

3 questions.

1)  Looking in the txf.scm file it looks like you are using V42 not V41 from
the date fields. IE.

(cons 'N370 #(none "Sched F" "Custom hire (machine work)" 1 #t "" ((2012
"7") (2011 "7a or b") (1990 "9"

Which version is it actually exporting?  V41 or V42?  The header says V41.


The latest version as of the report re-write was V41, dated 6/16/06, which was 
used. The dates you see are used for the report formatting and have nothing to 
do with the TXF output or the version of the txf spec. It has not been updated, 
yet, to version 42 because I did not know of it until just now.


2)  Also, there is very little information available about the internal
format of a .TXF file.  In Windows, does it matter if each line with data
ends in a carriage return , then followed by a blank line of only
 ?IE:

V041

AGnuCash 2.6.19

D01/26/2018

^
etc..


I don't know the answer to that specifically. When the report was first 
re-written there was a problem initially on the Windows platform with line 
endings that was fixed and tested by the user on Windows that reported the 
problem. I don't recall what tax software he used. You could test the relevance 
of the blank lines by using a text editor with a small sample to try different 
combinations and see if you get different results.


3)  there are only 685 codes in V041 and 717 codes in Version 042, all 3
digits.  Where did you find the codes with four digits?


There is a TXF Spec for Business "Business Tax Exchange Format for Forms 1065, 
1120, 1120S, 990, 990-PF, 990-T", V41, that was used.




--JEffrey Black M.B.A.


 Regards,

Alex

Alex:

Thank you for the information.

Hopefully GnuCash V3 will have increased support for all of the V42 tax codes.  
I will add it to the wish list.  And while I am at it, wish that Inuit and 
co-conspirators would update the TXF to V43 (not likely), so it fits more of 
the new or updated forms.

Considered doing a build of GnuCash on my own, with the V42 codes and quickly 
rejected the idea.  I do not have time right now to even begin to attempt to 
update all of the related source code.

As for importing TXF files containing references to schedules C and F, H 
Block's techs have absolutely no idea how to do it either.  Meaning they do not 
support it.  Thankfully the printed report generated by GnuCash lists the form 
and last known line where data goes.  Anything that makes filling out IRS forms 
faster and easier is a god send.

In regards to the V41 business tax codes, I have been unable to locate the 
specs for it.  Can and would you point me to a link for it?

--JEffrey Black M.B.A.

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Future allocated money, aka Envelope Budgeting

[John Ralls]

> On Feb 2, 2018, at 7:25 AM, Wm via gnucash-devel  > wrote:
> 
> There is, IMO, work to be done on on the underlying db structure, have you 
> seen this monster ?
> ===
> https://wiki.gnucash.org/wiki/images/8/86/Gnucash_erd.png 
> 
> ===
> It is as ugly as an ugly thing (I'd say what I thought but I'd like more than 
> a  mod to get to read this).

Sure is.

Step 1 in getting to being able to clean it up was converting the backend that 
implements it to C++ with clearly defined objects instead of a rather quirky 
collection of macros. That’s in the current “unstable” and will be released in 
3.0.

Step 2 is to convert the corresponding objects in libgnucash/engine to C++ 
objects with proper constructors so that creating an object doesn’t involve 
calling a bunch of property setters (one at a time!) that want to commit the 
object and write it back to the database. That will be my focus for the next 
development cycle.

Once that’s in hand we can consider refactoring the schema into something a bit 
more reasonable and get away from sucking the whole DB into memory at load time.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Future allocated money, aka Envelope Budgeting

[Wm via gnucash-devel]

On 02/02/2018 08:17, Christopher Lam wrote:

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.


Christopher, I've looked at your spreadsheet, it is pretty but I 
wouldn't do it it like that.  I also don't presume that the way that I'd 
do it would be something anyone else would like.  Do you see the problem 
yet ?


I'm not even sure the existing budgeting should be part of gnc in the 
long run, it is too quirky.  Every time someone new looks at it they 
say, "that isn't how a budget works! it should be like this ..."


Reason ?  Because budgets are personal things and gnc is not an 
"inspirational" accounting package.  gnc doesn't have a "run your life 
this way at it will be better, promise" attachment.  Why ?  Because it 
isn't selling anything.


I'd like it to stay that way.

=

There is, IMO, work to be done on on the underlying db structure, have 
you seen this monster ?

===
https://wiki.gnucash.org/wiki/images/8/86/Gnucash_erd.png
===
It is as ugly as an ugly thing (I'd say what I thought but I'd like more 
than a  mod to get to read this).


My point is that if the db made more sense you wouldn't even be thinking 
of writing code for your envelope budgeting, you'd open your spreadsheet 
and grab the stuff you wanted from the db, if you were happy with your 
work you'd say on the *user* list "hey folks, I've made a nifty envelope 
budgeting spreadsheet" and someone else would say, "that's neat, 
Christopher, how about you get it put on the gnc wiki" etc




The dilemma is to consider how to modify the schema to achieve this:


Have you seen the schema ?  Link just above.

There *are* people that can get useful stuff out of the existing schema 
but there aren't many of us.  IMO we do *not* need extra crap inside the 
db that will just have to be picked out later on.


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


if TDD is
===
https://en.wikipedia.org/wiki/Test-driven_development
===
then let me know how it works alongside gnc because as a db person there 
are some really obvious things I can fix in minutes ... but if the stuff 
I wanted done got done, you wouldn't need to do what you want to do, etc.


Or as someone might once have said, let's feed the horse before we ask 
it to pull the cart to the brewery where we load the beer, oh, have we 
brewed the beer yet? no we need to get the barley from the field for 
that, ok, get the horse and cart and get the barley from the field, but 
we haven't fed the horse yet, ok, go get some hay, from the field, using 
the horse and cart ? etc


Don't try making sense of the para above, it isn't meant to make sense :)

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Future allocated money, aka Envelope Budgeting

[Wm via gnucash-devel]

On 31/01/2018 20:18, Matt Graham wrote:

Love the thoughts!

Simplicity is king I think. I am going to ponder your idea for longer Chris.. 
It may be that there is a better way to structure budgeting in gnc, or as 
Adrian says maybe a new user interface is the better way to go.

One thing on my todo list is to look into how I can attach a text field to each budget entry, and 
each account (to explain how the number was defined. Eg in my monthly budget I might want to attach 
a comment to the "Dining out" account that says "$50 per weekend, plus $100 each Wed 
for taking the wife to dinner" (if only I had the cash for that)). So, I may be looking 
more into budget account structures soon and thus be better placed to see the more flexible way 
forward...




Right click / Associate file with transaction


this should *not* be in devel, folks

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Future allocated money, aka Envelope Budgeting

[Mike or Penny Novack]

On 2/2/2018 7:04 AM, Wm via gnucash-devel wrote:

On 31/01/2018 16:09, Christopher Lam 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.
I disagree that the time is yet ripe for this discussion to be on the 
developer's list. It should be there only AFTER the "what is wanted" has 
been fully defined from the user perspective. The reason some of you 
think the time IS ripe is that you are missing some of the potential 
complexities of the behavior desired << you are considering only the 
special case where the amounts are equal >>  That I can see "special 
case" is that although I don't use "envelope budgeting" I frequently am 
dealing with an analogous situation where the amounts are sometimes 
equal and sometimes not*.


To see this limiting the context of "envelope budgeting" we need to 
realize that there are two types of envelope budgeting, strict << CAN'T 
use more than what is in an envelope >> and less strict where if an 
expenditure DOES use more than what is left in an  envelope the 
remaining portion comes from some other envelope of general funds. I 
contend that this IS the real situation that most people using "envelope 
budgeting" face. Yes, you may have allocated a certain amount for the 
envelope for "dining out" or other discretionary activity BUT if the 
envelope say for "gasoline" doesn't contain enough to fill the tank you 
are likely to decide to skip going out for dinner rather than give up 
driving.


I am suggesting that IN GENERAL going to use manual adjustment/choices 
so the call to automate premature unless can deal with those issues.


Michael D Novack

* Examples from my world (accounting for non-profits)
 The organization has a fund for "zero turn mower for orchard Y". 
The fund has built up to a balance of $2400 by the time the mower is 
purchased for $2700. All the funds in the special account are used plus 
$300 of general funds.


 The organization sells tee shirts as a fund raiser. For 
non-profits, gross sales and cost of goods sold are line items on the 
990/990-EZ. So the sale of a tee shirt is a debit to cash, a credit to 
gross sales, a debit to cost of goods sold, and a credit to tee shirt 
inventory << but presumably the latter two amounts are less than the 
first two or would not be making a "profit" >>


 And yes, I am able to do a "two side split" transaction, but even 
for me might be quicker/easier to do it in two simple transactions.

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Future allocated money, aka Envelope Budgeting

[Wm via gnucash-devel]

On 31/01/2018 16:09, Christopher Lam 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.


[snip]



What do we think of this?

The budget balance for an asset account represents "money remaining to 
allocate", and the budget balance for an expense account effectively 
represents "the upper limit that I'll allow this account to be". The 
budget balance, minus running balance represents "money left in 
envelope". I can increase envelope contents by transferring budget money 
from asset to the expense accounts.


I wouldn't know how to handle credit card nor loan interest.

I think it's an interesting thought experiment. The devil will be in the 
details.


The advantage will be that the underlying code can handle this augmented 
functionality without major difficulty (famous last words.)


this "problem" is already "solved" in our friendly ledger-cli applications.

It is *not* a case of gnc people not knowing what to do or how to do it.

for e.g. I am, at the moment, in the process of doing my multiple view 
portfolio analysis starting from


https://www.ledger-cli.org/3.0/doc/ledger3.html#Asset-Allocation

which is more or less what envelope budgeting is plus a bit.

see

https://www.ledger-cli.org/3.0/doc/ledger3.html#Working-with-multiple-funds-and-accounts

The reason I don't think this is likely to get done in gnc any time soon 
(think decades) is because the UI will never satisfy anyone.


My 2 free Trump cents.

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Future allocated money, aka Envelope Budgeting

[Christopher Lam]

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  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