Re: Renamed beancount-web to fava
I'm trying to get this working with the dev version of fava, but can't run
`make build-js` with this error:-
for ( var item of map.entries() ) {
^^
SyntaxError: Unexpected identifier
at Module._compile (module.js:439:25)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object.
(/home/ngoonee/fava/fava/static/node_modules/rollup/bin/rollup:5:14)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
npm ERR! Linux 3.13.0-100-generic
npm ERR! argv "node" "/usr/bin/npm" "run" "build"
npm ERR! node v0.10.37
npm ERR! npm v3.10.9
npm ERR! code ELIFECYCLE
npm ERR! fava@0.0.0 build: `rollup -c`
npm ERR! Exit status 8
npm ERR!
npm ERR! Failed at the fava@0.0.0 build script 'rollup -c'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the fava package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! rollup -c
npm ERR! You can get information on how to open an issue for this project
with:
npm ERR! npm bugs fava
npm ERR! Or if that isn't available, you can get their info via:
npm ERR! npm owner ls fava
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR! /home/ngoonee/fava/fava/static/npm-debug.log
make: *** [build-js] Error 1
I notice favadev.pythonanywhere.com is also not public (yet?), so probably
this is already known? My primary interest is actually using the new
transaction input form, really.
--
You received this message because you are subscribed to the Google Groups
"Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beancount+unsubscr...@googlegroups.com.
To post to this group, send email to beancount@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beancount/715458ed-1eef-4d08-af0e-2100cb0daf55%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Gnucash "close books" functionality, remove transactions when import to beancount?
Thanks Martin, that sort of confirms my thoughts on the matter. Most likely because my own background is engineering and computer science rather than accounting, though. Regarding performance, perhaps there can be a convention regarding splitting input files by year. So I'd have one per year, and two 'main' files, one of which includes every year, and one of which includes only this year (maybe plus the previous 1 or 2 years if necessary). On Fri, Dec 23, 2016 at 12:03 PM, Martin Blais wrote: > In Beancount this procedure is something that is done automatically at > reporting time by the software. We call the operation "clear" and there's no > particular reason to stick with the antiquated method of you having to do > this explicitly yourself. We have computers; the software can do that for > you. > > Well, perhaps performance could be one reason, but Beancount is easily fast > enough for 10-15 years of a normal person's data, and the way forward is to > do some performance optimizations instead of forcing the user through this > antiquated practice of having to close on some arbitrary time boundary. I > know H/Ledger users are fond of following old accounting practices for some > sort of romantic attachment, but I question the status quo, and so far I see > no rationale to force you to have to go through this rigamarole just because > people did it this way 20 years ago and commercial software cathers to > people used to that. Just keep your entire dataset in one place and process > it every time. It gives you the freedom to go back to any point in time and > draw a balance sheet or income statement for any arbitrary period. bean-web > by default provides year-boundary subsets, just like you need it. This is an > artifact of reporting. > > If that doesn't work out well for some reason, please let us know (and > please be very specific if you do so, I've thought about this a lot). > > > > On Thu, Dec 22, 2016 at 8:11 PM, Oon-Ee Ng wrote: >> >> With Gnucash, one of the things I did every calendar year end (private >> accounts) was to 'close books'. In summary, what it does is create two >> transactions, the objective of which is to balance all >> incomes/expenses to zero. The period of time covered is normally a >> year, but configurable. >> >> Quick example, initial stage:- >> >> Expenses:Food 200 USD >> Expenses:Drinks 100 USD >> Income:Salary -400 USD >> >> The 'close book' function would then create two transactions which >> would be (in beancount syntax):- >> >> 2014-12-31 * >> Expenses:Food -200 USD >> Expenses:Drink -100 USD >> Equity:CummulativeExpenses 300 USD >> 2014-12-31 * >> Income:Salary 400 USD >> Equity:RetainedEarnings 400 USD >> >> The destination accounts would be configurable, I can't remember where >> I got their names from really. >> >> I found it necessary to do this every year so that within the year I >> could have a clean view of how much I had spent just in this calendar >> year in the account summary (without having to run reports). Of course >> I now realize I should have used the internal view filter in gnucash, >> but... >> >> Anyway the primary question I guess is whether such 'close book' >> transactions make sense, or whether I should get rid of them entirely. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Beancount" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to beancount+unsubscr...@googlegroups.com. >> To post to this group, send email to beancount@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beancount/CAGQ70esYPA%3Dm-KiSq2DoHNSy%3DMDHx-FELBpZqKEJDQWq%3Dsy8TQ%40mail.gmail.com. >> For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "Beancount" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beancount+unsubscr...@googlegroups.com. > To post to this group, send email to beancount@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beancount/CAK21%2BhOc3S_Y6dTGvbxvr8LEGYhN%3DDVrGcZjg8rAfQ8o_ZSWOg%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to beancount+unsubscr...@googlegroups.com. To post to this group, send email to beancount@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAGQ70eu_FRoUJpPzTPfQiHRN0-Oxjwq-PXvdFHiecnOi03W%3Dwg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Gnucash "close books" functionality, remove transactions when import to beancount?
On Sat, Dec 24, 2016 at 4:24 PM, Oon-Ee Ng wrote: > Thanks Martin, that sort of confirms my thoughts on the matter. Most > likely because my own background is engineering and computer science > rather than accounting, though. > > Regarding performance, perhaps there can be a convention regarding > splitting input files by year. So I'd have one per year, and two > 'main' files, one of which includes every year, and one of which > includes only this year (maybe plus the previous 1 or 2 years if > necessary). > A couple of notes: - I think it should be possible to automatically generate the offsetting closing and opening transactions to insert in each of your files to bring the opening balances to what they should be. Note that if you change anything in the past files, those transactions may require updates (that sound like a PIA to me). Anyhow, my point is that the act of "closing" should be automatable with a script. (I'm pretty sure I must have hacked this in the past.) - About performance: I'm revisiting the caching code now so that the parsing stage will have a per-file cache instead of a single large cache for the entire result. That by itself might make a multi-file configuration faster, without an explicit closing of each year, though parsing is only about %30 of processing time. On Fri, Dec 23, 2016 at 12:03 PM, Martin Blais wrote: > > In Beancount this procedure is something that is done automatically at > > reporting time by the software. We call the operation "clear" and > there's no > > particular reason to stick with the antiquated method of you having to do > > this explicitly yourself. We have computers; the software can do that for > > you. > > > > Well, perhaps performance could be one reason, but Beancount is easily > fast > > enough for 10-15 years of a normal person's data, and the way forward is > to > > do some performance optimizations instead of forcing the user through > this > > antiquated practice of having to close on some arbitrary time boundary. I > > know H/Ledger users are fond of following old accounting practices for > some > > sort of romantic attachment, but I question the status quo, and so far I > see > > no rationale to force you to have to go through this rigamarole just > because > > people did it this way 20 years ago and commercial software cathers to > > people used to that. Just keep your entire dataset in one place and > process > > it every time. It gives you the freedom to go back to any point in time > and > > draw a balance sheet or income statement for any arbitrary period. > bean-web > > by default provides year-boundary subsets, just like you need it. This > is an > > artifact of reporting. > > > > If that doesn't work out well for some reason, please let us know (and > > please be very specific if you do so, I've thought about this a lot). > > > > > > > > On Thu, Dec 22, 2016 at 8:11 PM, Oon-Ee Ng > wrote: > >> > >> With Gnucash, one of the things I did every calendar year end (private > >> accounts) was to 'close books'. In summary, what it does is create two > >> transactions, the objective of which is to balance all > >> incomes/expenses to zero. The period of time covered is normally a > >> year, but configurable. > >> > >> Quick example, initial stage:- > >> > >> Expenses:Food 200 USD > >> Expenses:Drinks 100 USD > >> Income:Salary -400 USD > >> > >> The 'close book' function would then create two transactions which > >> would be (in beancount syntax):- > >> > >> 2014-12-31 * > >> Expenses:Food -200 USD > >> Expenses:Drink -100 USD > >> Equity:CummulativeExpenses 300 USD > >> 2014-12-31 * > >> Income:Salary 400 USD > >> Equity:RetainedEarnings 400 USD > >> > >> The destination accounts would be configurable, I can't remember where > >> I got their names from really. > >> > >> I found it necessary to do this every year so that within the year I > >> could have a clean view of how much I had spent just in this calendar > >> year in the account summary (without having to run reports). Of course > >> I now realize I should have used the internal view filter in gnucash, > >> but... > >> > >> Anyway the primary question I guess is whether such 'close book' > >> transactions make sense, or whether I should get rid of them entirely. > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Beancount" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to beancount+unsubscr...@googlegroups.com. > >> To post to this group, send email to beancount@googlegroups.com. > >> To view this discussion on the web visit > >> https://groups.google.com/d/msgid/beancount/CAGQ70esYPA% > 3Dm-KiSq2DoHNSy%3DMDHx-FELBpZqKEJDQWq%3Dsy8TQ%40mail.gmail.com. > >> For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Beancount" group. > > To unsubscribe from this gr
Re: Gnucash "close books" functionality, remove transactions when import to beancount?
Sounds very much like using your 'pad' command on 31st December every year for each account? On Sun, Dec 25, 2016 at 5:33 AM, Martin Blais wrote: > On Sat, Dec 24, 2016 at 4:24 PM, Oon-Ee Ng wrote: >> >> Thanks Martin, that sort of confirms my thoughts on the matter. Most >> likely because my own background is engineering and computer science >> rather than accounting, though. >> >> Regarding performance, perhaps there can be a convention regarding >> splitting input files by year. So I'd have one per year, and two >> 'main' files, one of which includes every year, and one of which >> includes only this year (maybe plus the previous 1 or 2 years if >> necessary). > > > A couple of notes: > > - I think it should be possible to automatically generate the offsetting > closing and opening transactions to insert in each of your files to bring > the opening balances to what they should be. Note that if you change > anything in the past files, those transactions may require updates (that > sound like a PIA to me). Anyhow, my point is that the act of "closing" > should be automatable with a script. (I'm pretty sure I must have hacked > this in the past.) > > - About performance: I'm revisiting the caching code now so that the parsing > stage will have a per-file cache instead of a single large cache for the > entire result. That by itself might make a multi-file configuration faster, > without an explicit closing of each year, though parsing is only about %30 > of processing time. > > > >> On Fri, Dec 23, 2016 at 12:03 PM, Martin Blais wrote: >> > In Beancount this procedure is something that is done automatically at >> > reporting time by the software. We call the operation "clear" and >> > there's no >> > particular reason to stick with the antiquated method of you having to >> > do >> > this explicitly yourself. We have computers; the software can do that >> > for >> > you. >> > >> > Well, perhaps performance could be one reason, but Beancount is easily >> > fast >> > enough for 10-15 years of a normal person's data, and the way forward is >> > to >> > do some performance optimizations instead of forcing the user through >> > this >> > antiquated practice of having to close on some arbitrary time boundary. >> > I >> > know H/Ledger users are fond of following old accounting practices for >> > some >> > sort of romantic attachment, but I question the status quo, and so far I >> > see >> > no rationale to force you to have to go through this rigamarole just >> > because >> > people did it this way 20 years ago and commercial software cathers to >> > people used to that. Just keep your entire dataset in one place and >> > process >> > it every time. It gives you the freedom to go back to any point in time >> > and >> > draw a balance sheet or income statement for any arbitrary period. >> > bean-web >> > by default provides year-boundary subsets, just like you need it. This >> > is an >> > artifact of reporting. >> > >> > If that doesn't work out well for some reason, please let us know (and >> > please be very specific if you do so, I've thought about this a lot). >> > >> > >> > >> > On Thu, Dec 22, 2016 at 8:11 PM, Oon-Ee Ng >> > wrote: >> >> >> >> With Gnucash, one of the things I did every calendar year end (private >> >> accounts) was to 'close books'. In summary, what it does is create two >> >> transactions, the objective of which is to balance all >> >> incomes/expenses to zero. The period of time covered is normally a >> >> year, but configurable. >> >> >> >> Quick example, initial stage:- >> >> >> >> Expenses:Food 200 USD >> >> Expenses:Drinks 100 USD >> >> Income:Salary -400 USD >> >> >> >> The 'close book' function would then create two transactions which >> >> would be (in beancount syntax):- >> >> >> >> 2014-12-31 * >> >> Expenses:Food -200 USD >> >> Expenses:Drink -100 USD >> >> Equity:CummulativeExpenses 300 USD >> >> 2014-12-31 * >> >> Income:Salary 400 USD >> >> Equity:RetainedEarnings 400 USD >> >> >> >> The destination accounts would be configurable, I can't remember where >> >> I got their names from really. >> >> >> >> I found it necessary to do this every year so that within the year I >> >> could have a clean view of how much I had spent just in this calendar >> >> year in the account summary (without having to run reports). Of course >> >> I now realize I should have used the internal view filter in gnucash, >> >> but... >> >> >> >> Anyway the primary question I guess is whether such 'close book' >> >> transactions make sense, or whether I should get rid of them entirely. >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> >> Groups >> >> "Beancount" group. >> >> To unsubscribe from this group and stop receiving emails from it, send >> >> an >> >> email to beancount+unsubscr...@googlegroups.com. >> >> To post to this group, send email to beancount@googlegroups.com. >> >> To view this discussion on the web visit >> >> >> >> http
Re: Renamed beancount-web to fava
Got past that error by using advice from
https://help.pythonanywhere.com/pages/Node/ (used nvm to update
node/npm and added an alias nodejs='node' in .bashrc)
Now my webapp fails with this error, though the same beancount file
works fine on my own machine. Any ideas?
2016-12-24 21:03:58,195 :[2016-12-24 21:03:58,194] ERROR in app:
Exception on / [GET]
2016-12-24 21:03:58,195 :Traceback (most recent call last):
2016-12-24 21:03:58,195 : File
"/usr/local/lib/python3.5/dist-packages/flask/app.py", line 1988, in
wsgi_app
2016-12-24 21:03:58,195 :response = self.full_dispatch_request()
2016-12-24 21:03:58,195 : File
"/usr/local/lib/python3.5/dist-packages/flask/app.py", line 1641, in
full_dispatch_request
2016-12-24 21:03:58,195 :rv = self.handle_user_exception(e)
2016-12-24 21:03:58,195 : File
"/usr/local/lib/python3.5/dist-packages/flask/app.py", line 1544, in
handle_user_exception
2016-12-24 21:03:58,195 :reraise(exc_type, exc_value, tb)
2016-12-24 21:03:58,196 : File
"/usr/local/lib/python3.5/dist-packages/flask/_compat.py", line 33, in
reraise
2016-12-24 21:03:58,196 :raise value
2016-12-24 21:03:58,196 : File
"/usr/local/lib/python3.5/dist-packages/flask/app.py", line 1637, in
full_dispatch_request
2016-12-24 21:03:58,196 :rv = self.preprocess_request()
2016-12-24 21:03:58,196 : File
"/usr/local/lib/python3.5/dist-packages/flask/app.py", line 1831, in
preprocess_request
2016-12-24 21:03:58,196 :func(request.endpoint, request.view_args)
2016-12-24 21:03:58,196 : File
"/home/ngoonee/.local/lib/python3.5/site-packages/beancount_fava-1.2.dev0-py3.5.egg/fava/application.py",
line 182, in _pull_beancount_file
2016-12-24 21:03:58,196 :g.beancount_file_slug = app.config['FILE_SLUGS'][0]
2016-12-24 21:03:58,196 :KeyError: 'FILE_SLUGS'
2016-12-24 21:03:58,194 :Exception on / [GET]
Traceback (most recent call last):
File "/usr/local/lib/python3.5/dist-packages/flask/app.py", line
1988, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python3.5/dist-packages/flask/app.py", line
1641, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/usr/local/lib/python3.5/dist-packages/flask/app.py", line
1544, in handle_user_exception
reraise(exc_type, exc_value, tb)
File "/usr/local/lib/python3.5/dist-packages/flask/_compat.py", line
33, in reraise
raise value
File "/usr/local/lib/python3.5/dist-packages/flask/app.py", line
1637, in full_dispatch_request
rv = self.preprocess_request()
File "/usr/local/lib/python3.5/dist-packages/flask/app.py", line
1831, in preprocess_request
func(request.endpoint, request.view_args)
File
"/home/ngoonee/.local/lib/python3.5/site-packages/beancount_fava-1.2.dev0-py3.5.egg/fava/application.py",
line 182, in _pull_beancount_file
g.beancount_file_slug = app.config['FILE_SLUGS'][0]
KeyError: 'FILE_SLUGS'
On Sun, Dec 25, 2016 at 4:56 AM, Oon-Ee Ng wrote:
>
> I'm trying to get this working with the dev version of fava, but can't run
> `make build-js` with this error:-
>
> for ( var item of map.entries() ) {
>^^
> SyntaxError: Unexpected identifier
> at Module._compile (module.js:439:25)
> at Object.Module._extensions..js (module.js:474:10)
> at Module.load (module.js:356:32)
> at Function.Module._load (module.js:312:12)
> at Module.require (module.js:364:17)
> at require (module.js:380:17)
> at Object.
> (/home/ngoonee/fava/fava/static/node_modules/rollup/bin/rollup:5:14)
> at Module._compile (module.js:456:26)
> at Object.Module._extensions..js (module.js:474:10)
> at Module.load (module.js:356:32)
> npm ERR! Linux 3.13.0-100-generic
> npm ERR! argv "node" "/usr/bin/npm" "run" "build"
> npm ERR! node v0.10.37
> npm ERR! npm v3.10.9
> npm ERR! code ELIFECYCLE
> npm ERR! fava@0.0.0 build: `rollup -c`
> npm ERR! Exit status 8
> npm ERR!
> npm ERR! Failed at the fava@0.0.0 build script 'rollup -c'.
> npm ERR! Make sure you have the latest version of node.js and npm installed.
> npm ERR! If you do, this is most likely a problem with the fava package,
> npm ERR! not with npm itself.
> npm ERR! Tell the author that this fails on your system:
> npm ERR! rollup -c
> npm ERR! You can get information on how to open an issue for this project
> with:
> npm ERR! npm bugs fava
> npm ERR! Or if that isn't available, you can get their info via:
> npm ERR! npm owner ls fava
> npm ERR! There is likely additional logging output above.
> npm ERR! Please include the following file with any support request:
> npm ERR! /home/ngoonee/fava/fava/static/npm-debug.log
> make: *** [build-js] Error 1
>
> I notice favadev.pythonanywhere.com is also not public (yet?), so probably
> this is already known? My primary interest is actually using the new
> transaction input form, really.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Beancount" group.
> To unsubscribe from this group and stop r
Re: Gnucash "close books" functionality, remove transactions when import to beancount?
Sort of; it would be generating one big transaction to remove everything from all accounts, and one corresponding big transaction to add everything to all accounts. Ideally, if you used both files, they cancel each other out, and really, they should be removed automatically somehow. On Sat, Dec 24, 2016 at 4:59 PM, Oon-Ee Ng wrote: > Sounds very much like using your 'pad' command on 31st December every > year for each account? > > On Sun, Dec 25, 2016 at 5:33 AM, Martin Blais wrote: > > On Sat, Dec 24, 2016 at 4:24 PM, Oon-Ee Ng > wrote: > >> > >> Thanks Martin, that sort of confirms my thoughts on the matter. Most > >> likely because my own background is engineering and computer science > >> rather than accounting, though. > >> > >> Regarding performance, perhaps there can be a convention regarding > >> splitting input files by year. So I'd have one per year, and two > >> 'main' files, one of which includes every year, and one of which > >> includes only this year (maybe plus the previous 1 or 2 years if > >> necessary). > > > > > > A couple of notes: > > > > - I think it should be possible to automatically generate the offsetting > > closing and opening transactions to insert in each of your files to bring > > the opening balances to what they should be. Note that if you change > > anything in the past files, those transactions may require updates (that > > sound like a PIA to me). Anyhow, my point is that the act of "closing" > > should be automatable with a script. (I'm pretty sure I must have hacked > > this in the past.) > > > > - About performance: I'm revisiting the caching code now so that the > parsing > > stage will have a per-file cache instead of a single large cache for the > > entire result. That by itself might make a multi-file configuration > faster, > > without an explicit closing of each year, though parsing is only about > %30 > > of processing time. > > > > > > > >> On Fri, Dec 23, 2016 at 12:03 PM, Martin Blais wrote: > >> > In Beancount this procedure is something that is done automatically at > >> > reporting time by the software. We call the operation "clear" and > >> > there's no > >> > particular reason to stick with the antiquated method of you having to > >> > do > >> > this explicitly yourself. We have computers; the software can do that > >> > for > >> > you. > >> > > >> > Well, perhaps performance could be one reason, but Beancount is easily > >> > fast > >> > enough for 10-15 years of a normal person's data, and the way forward > is > >> > to > >> > do some performance optimizations instead of forcing the user through > >> > this > >> > antiquated practice of having to close on some arbitrary time > boundary. > >> > I > >> > know H/Ledger users are fond of following old accounting practices for > >> > some > >> > sort of romantic attachment, but I question the status quo, and so > far I > >> > see > >> > no rationale to force you to have to go through this rigamarole just > >> > because > >> > people did it this way 20 years ago and commercial software cathers to > >> > people used to that. Just keep your entire dataset in one place and > >> > process > >> > it every time. It gives you the freedom to go back to any point in > time > >> > and > >> > draw a balance sheet or income statement for any arbitrary period. > >> > bean-web > >> > by default provides year-boundary subsets, just like you need it. This > >> > is an > >> > artifact of reporting. > >> > > >> > If that doesn't work out well for some reason, please let us know (and > >> > please be very specific if you do so, I've thought about this a lot). > >> > > >> > > >> > > >> > On Thu, Dec 22, 2016 at 8:11 PM, Oon-Ee Ng > >> > wrote: > >> >> > >> >> With Gnucash, one of the things I did every calendar year end > (private > >> >> accounts) was to 'close books'. In summary, what it does is create > two > >> >> transactions, the objective of which is to balance all > >> >> incomes/expenses to zero. The period of time covered is normally a > >> >> year, but configurable. > >> >> > >> >> Quick example, initial stage:- > >> >> > >> >> Expenses:Food 200 USD > >> >> Expenses:Drinks 100 USD > >> >> Income:Salary -400 USD > >> >> > >> >> The 'close book' function would then create two transactions which > >> >> would be (in beancount syntax):- > >> >> > >> >> 2014-12-31 * > >> >> Expenses:Food -200 USD > >> >> Expenses:Drink -100 USD > >> >> Equity:CummulativeExpenses 300 USD > >> >> 2014-12-31 * > >> >> Income:Salary 400 USD > >> >> Equity:RetainedEarnings 400 USD > >> >> > >> >> The destination accounts would be configurable, I can't remember > where > >> >> I got their names from really. > >> >> > >> >> I found it necessary to do this every year so that within the year I > >> >> could have a clean view of how much I had spent just in this calendar > >> >> year in the account summary (without having to run reports). Of > course > >> >> I now realize I should have used the internal view filter in
