Perhaps this should get tied into the book closing clode? When you close the books on a period, all the transactions in that period become uneditable? We DO have the ability to mark a transaction specifically as read-only. It wouldn't be too hard to also mark the txns as read-only as we process them for the book closing.
-derek Quoting Geert Janssens <[EMAIL PROTECTED]>: > 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 > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH [EMAIL PROTECTED] PGP key available _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel