"correcting" transactions

Mark Rousell markr at signal100.com
Wed Feb 26 14:58:23 EST 2014


On 26/02/2014 13:40, Mike or Penny Novack wrote:
> I think at this point there is confusion about EXACTLY what is being
> asked for.

My approach is simply focussed on making existing GnuCash files
non-editable once written. It doesn't purport to do anything other than
that.

> That is why I earlier made the suggestion that a discussion
> take place among those interested at the purely "business" level
> (ignoring any questions about implementation INCLUDING implementations
> via "work flow" changes).

Indeed, real auditability of the accounting process comes from
business-level precautions. I have not addressed these issues within my
suggestion because they are outwith what any single application program
can provide (although what I proposed would be beneficial).

> If ALL that is requested is "gnucash provide some means that auditing
> could detect if data previous to some data were altered" THIS EXISTS
> NOW.

This is not the issue I addressed. Instead, I looked for a way to
prevent prevent previous data from being altered.

To re-cap once again: I quite clearly made no attempt to try and detect
a new data file being put in the existing data file's place, as no
single application program can prevent that. Prevention or detection of
such a thing is a job business-level procedures and practices.

> It exists by means of burning a read only copy and having that
> stored out of the control of whoever maintains the books. Since proper
> use involves making such copies for backup purposes in any case, just a
> matter of making an extra copy sent elsewhere. Of course in this case
> the auditing tools (compare software) would be outside of gnucash.

Yup. This complements what I proposed and what I proposed complements
this. Neither one replaces the other.

> But if you haven't
> thought of it that way, would it satisfy you if gnucash provided such a
> tool within gnucash? In other words, don't PREVENT alteration (the the
> read/write books) but simply detect if alteration of data entered before
> a certain date has taken place (and identify the changes). That's just a
> function that takes two files (one the read/write books and one the
> frozen books) and a date parameter and determines if any transactions on
> or before that date differ.

This is a very good idea indeed. It doesn't even need to be within
GnuCash as such; it could be done as a separate utility. Either way,
having a way to intelligently compare two (or more) versions of a file
for changes and have any changes highlighted would be tremendously
useful in this context.

> * My sense is that what is wanted is something to lock the read/write
> books

That was effectively my approach (limited to an existing data file) but
I did not propose it because of this:

> because these people aren't making backups to read only medium.
> Perhaps not making backups at all.

I proposed it because I think it is a good idea no matter what. Even if
my idea was implemented (but see below), backups would still be
important, comparing snapshots is still important (as you describe
above), and business-level secure procedures would still be important.
What I proposed can complement these other steps but does not replace
them, just as they do not replace it.

I note, however, John Ralls has made it clear that what I proposed is
outwith the scope of this project, whatever its merits.

Your idea above of providing a way to intelligently compare data files
does seem like a really good idea to me that I would have thought could
be usefully done either within or without of the GnuCash project,
whichever is appropriate.


-- 
Mark Rousell

PGP public key: http://www.signal100.com/markr/pgp
Key ID: C9C5C162
 
 
 



More information about the gnucash-user mailing list