On Saturday 16 February 2008, Geert Janssens wrote:> > 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 som! e 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, > a! nd correcting them doesn't fall in the category of "tampering". It mak es > 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 i! t 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.> I think there is some confusion in the discussion about the requirements - I took it to be that there be an unalterable (by the application user, not the systems administrator) audit trail. The discussion reminds me of the days when people kept manual checkbook registers. A "non-accountant" person might write the entries in in pencil and if they ever made a mistake on an entry, simply erase the error and, if necessary, recalculate the balance from that point forward making it "look" like the error had never happened in the first place. An "accountant", however, would always write the entries in in ink and, if an error occurred, write a new "adjusting" entry on the date the error was discovered to get the balance right and annotate the original entry to point to the adjusting entry. That way a full audit trail of what happened would be preserved and when the checkbook was reconciled to the bank statement, the two entries (the original entry and its adjustment) would be treated together to match the bank's item. The trouble is that gnucash looks like the "non-accountant" person writing in pencil - the transaction shown in a register is the "latest version" of the entry which may have been changed many times with no audit trail of the changes. It may be tempting to change gnucash so that it "writes in ink" at the user-interface level but that seems very constraining on the one hand and like a big job on the other. Since gnucash already writes transaction logs for recovery purposes, perhaps there is a way to provide the required audit trail using that mechanism with fewer, smaller changes. We should keep in mind the distinction between "business transactions" (for example, writing a check, issuing an invoice) and "data-entry transactions" (the one or more entries into the system needed to get the business transaction properly reflected in the system of record). If someone wrote a check for 150.50 of your favorite unit of currency and entered it into the system as 150.05 with the wrong payee and wrong transfer account and then at three separate times went back in and corrected the amount, the description, and the transfer account(s), there would be four data-entry transactions to get the one business transaction right in the system and there should be an audit trail of all of them. But it seems unnecessary to clutter up gnucash's user interface and reports and everything to get this. My question for the developers who understand the internals: 1. Could the existing mechanism for generating transaction logs for recovery purposes be modified reasonably easily to write an "audit trail entry" to a new "audit trail log" for any new register entry and/or any individual change to an existing register entry? 2. If so, could a report be written fairly simply that would show this audit trail detail for any specified register entry (or all entries within a date range, or for several accounts within a date range, etc.)? This would show the original transaction plus all changes resulting in the transaction shown in the register window, with dates and times (and user in the future if user level tracking is ever implemented). 3. If so, would it be fairly simple to implement a book-level option, to be selected at the time that a book is created, that would activate this functionality? If selected, it would keep the audit trail log for all time and make the audit trail report(s) accessible, if not gnucash would function as today. If this is feasible, it seems that this might satisfy the requirement with relatively few and isolated changes. This seems like a general approach and so, if this would satisfy the German requirement, or go a ways towards it, it would also help with US GAAP requirements and those elsewhere. Issues of account-level applicability would no longer matter. Issues of controlling data entry by date or relative to book closings or by user or anything else would be separate items. This would simply provide an accurate and complete audit trail. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
