Hi, I'll just chime in with some of my personal findings and observations. Most of this based on my personal experience and may not be valid for everyone. But I thought different insights might be useful to get a complete picture.
On Saturday 16 February 2008, Graham Leggett wrote: > An example of where one split remaining alterable becomes important is > when one side of the split goes to "income - sales" (for example), and > the other side goes to "bank account". Gnucash isn't the authoritative > source for bank account information (the bank is) and therefore it > should remain editable until the bank statement is reconciled, but > gnucash is the authoritative source for sales. So it must remain > possible to allocate the bank split to say "petty cash" or "overs and > unders" if a mistake was found. > Graham's comment on bank reconciliation makes me wonder wether this new feature request isn't some kind of variation on reconciliation ? I used to get a warning when I tried ot modify a reconciled transaction with the option to allow the change or not. To my confusion, this doesn't seem to work anymore in version 2.2.1 on Mandriva. Maybe this has changed ? But a similar method could be used to completely disable editing on a per account basis. In another accounting program I'm using (commercial, windows-only program for the Belgian accounting market), disabling the editing of transactions is a user initiated action: after entering a number of transactions, and verifying them, a user can choose an option "doorboeken" which I would translate as "book through". From that point on, these transactions are no longer editable, the "book through" action is irreversible. But allowing the user to initiate the action, provides room to fix human errors (mistyping a number, or posting to a wrong account). It is perfectly normal to make such mistakes, and correcting them doesn't fall in the category of "tampering". It makes sense to only disable the editing after the entries have been verified. In the other accounting program, we usually do the final "booking through" only quarterly, after having verified all inputs and just before printing the official VAT/tax reports. <sidenote> In this particular program, the transactions are grouped in accounting periods (configurable as either months or quarters). When choosing "book through" you select for which accounting period you wish to perform this. Although the "booked through" transactions can't be edited, it's still possible to add new transactions in the same accounting period. This allows for midperiod analysis on data that is verified, while later on still entering new transactions in the period. Although not part of the original request, I would really like to see this concept of accounting periods in GnuCash as well. It's a concept required by Belgian law (we have quarterly or monthly VAT declarations) and it helps in dealing with some other difficult cases as well, like for example booking a forgotten bill from a previous VAT period. </sidenote> Regardless of this, using a set date to disable editing of transactions shouldn't prevent new transactions to be entered before that date, like for example a forgotten invoice. Assuming the feature is user-enabled, it should also be enabled separately per account. In my typical scenario, I enter invoices and bills earlier than I enter bank account information. So I would disable editing on invoices and bills earlier than I would on bank accounts. _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
