End of Year

[Cameron Thorne]

I know this comes up every quarter or so, and yes, I have read through
the archived mailing lists and the wiki on this subject, but I need
some specific help with how to run year-end on my file.  I think the
feature in bug 106383 will be exactly what I need - once it gets
turned on in one of the 2.x releases, but even then it is incomplete
with regard to paid/closed invoices.

I have been using my current file since January 1, 2004, so it now has
almost 3 years of information in it.  The file is going on 5MB now,
and growing fast since my finances are getting more and more
complicated and as I use more of the Gnucash modules.  It has been
suggested to me to run a year-end process, and start using one file
per year to keep things tidy.  I like this idea since it lets me clean
up deprecated accounts in my account tree, but all the usual simple
methods (exporting your account tree and starting fresh) don't take
into account the business module.  I have created-but-unposted
invoices and unpaid invoices for both customers and vendors that span
year-end.

If I export my account tree to a new file, and use that new file, I
will have to manually enter my starting balances (no big deal), and
manually recreate all my invoices and jobs (arduous).  If I archive my
current file and start with a copy, then manually delete the last
three years of transactions and replace with a zeroing transaction
(arduous), I will be able to maintain my invoices.  However, I will
also maintain all old, closed/paid invoices as well, since there is no
way to delete invoices from Gnucash.

Old stock prices should also be cleared at year-end, and though there
is already a way to do this easily within the application, it would be
nice if it were part of any built-in year-end closing.

So in short - is it possible to use one-file-per-year if you utilize
the Gnucash business modules?  If so, how do you handle it?

Is it appropriate to add the integration of business module invoice
logic and stock/security price clearing to Bug 106383?

Thanks as always.

-- Cameron