"correcting" transactions

David Beattie dvdbeattie at yahoo.com
Fri Feb 21 17:25:16 EST 2014


Victor,

I fully agree with your comments (below).  Typos & mistakes will happen, and so will fickle customers who write checks for different amounts than we ask for,... and it's much easier and nicer in the sole-proprietor-ship model to be able to simply correct our mistakes (and those of others) rather than having the software declaring us to be careless idiots and enforcing some kind of messy audit trail on fixing mistakes.  Also, there are certain operations that are not really supported directly in the GnuCash user interface and it's often much easier to enter a transaction deliberately wrong, and then change it, for example by entering a split transaction without all the splits, then editing it to add the splits, or by duplicating another transaction with similar splits and then editing things.  These things could be supported by fancy dialog boxes which let us get everything right before posting a duplicated transaction,... or by having some sort
 of modification operation on an invoice rather than allowing an un-post to correct invoice line items, but since GnuCash doesn't create this kind of audit trail currently, these fancy dialogs aren't necessary to keep things clean, when we can just do the work directly in the register and/or in the business features without each change generating an audit log entry.  I like a clean, simple view of my finances, not one cluttered by extra transactions or log entries every time I make a mistake or take several steps to arrive at the desired data.  If GnuCash ever does get a change audit trail feature, I hope it's something that can be hidden, and only shown when necessary.

In terms of the risk of shooting ourselves in the foot.... I've been saved more than once by GnuCash's automatic backups, running every 15 minutes, so that if I do screw up, I can open the old version of the data file, either for reference to undo my damage, or restoring it permanently and starting from the backup as a new basis.  I'm perfectly happy with this level of protection from human error, since the moment I realize I've done something stupid, I can consult a backup... and otherwise, I don't have to be fighting the computer just to do simple things.  Also, incidentally, there is an audit log stored, in a sense, alongside the .gnucash file and alongside the backups, in text files.  It's not complete, though, since it doesn't record changes to the business data; and I know it's meant for diagnostic purposes and for error recovery in case of a crash (which doesn't even work properly if business features were used), but in some rudimentary
 sense, these error recovery logs are providing an audit trail too, since they record every change we make (with the exception of the changes to the business data).

For marking transactions as read-only, with a dialog box to change them....  isn't that what clearing and reconciling is all about?  I reconcile my accounts regularly, and I find that I do, in fact, get a warning if I want to change data that's already been marked as reconciled.  It's not as automatic as the date range thing you're talking about, but it has the advantage that when an account is reconciled, you've double-checked the data integrity (via a bill, or a zero balance), and found the data to be correct at the time the transactions were marked reconciled.

--David

 
On Friday, February 21, 2014 7:03 AM, R. Victor Klassen <rvklassen at gmail.com> wrote:
  

Just to throw one other perspective into the list, the current discussion has strayed into the realm of what can and cannot be traced/changed and why one can never really make a transaction truly “read only”.

Thirty years ago it was “well known” (but not necessarily widely acknowledged) that the reasons for protection (passwords, file permissions, etc. ) were, in order 1) to help keep users from shooting themselves in the foot; 2) to protect users from other users trying to be helpful but actually shooting them in the foot; and 3) to protect against malicious users.

Too often we think only of case 3) without considering case 1).

I would love the ability to set a date range read only - with the ability to over-write the read-only nature of the transaction with a warning.   That way if I accidentally enter a transaction with an unreasonable date (and I got to choose what was reasonable) I would be warned, and avoid having to search for a transaction because it disappeared to some date I didn’t intend.   I really don’t care that I could override the read-only nature of the date range.  Or that I could edit an XML file directly, or any of that.  Where only one or two people - that trust each other fully on the finances of this business - ever interact with GNUcash, it’s not fraud we’re worried about, it’s correcting mistakes - and better still avoiding them.

Now as far as modifying transactions go - in a real corporate production system I might have to enter balancing transactions every time I need to correct something, but in GNUcash I can find the original transaction or invoice and correct the error.   Yesterday I changed some account names when I was reviewing last year’s records.  No amounts or dates changed, but some income was better categorized after this.  Remember, we’re not pros (mostly), so we make mistakes, or even change our minds from time to time.   The other month I had to change an amount on a transaction when there had been a typo in transcribing it from a handwritten cheque to GNUcash, and on reconciliation it became clear that the reason it was a few cents of balancing was in a transcription error.   I really like being able to go back and correct things when they are wrong, rather than having to put in correcting transactions.   And this is really OK for the sole
 proprietorship.

And finally, the posting date defaults to when I do the data entry.  On a cash based accounting system if I post invoices and bills when the money changes hands I would get the reports to look right, but invoices would not have invoice numbers, since they need to be posted before being printed or they say “invoice in progress” where the number should be.   Because of the way GnuCash treats posting dates, on an accrual based system, they should be posted on the date the invoice is effective - when the goods change hands, or the invoice is written - or the date the bill has on it, in the case of bills received.   And the default will be wrong, so if I forget to change that before posting I need to be able to go back and fix it.  Which is why it’s nice to be able to fix it.



_______________________________________________
gnucash-user mailing list
gnucash-user at gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


More information about the gnucash-user mailing list