"correcting" transactions

[J. Elfring]

Hi,

I guess, I posted to the wrong end of this thread :)
Please have a look on my proposal in the last paragraph here:
https://lists.gnucash.org/pipermail/gnucash-user/2014-February/053298.html

Cheers, Jörg
(@MOD: Please reject the other version of this post, sent from another
address)




2014-02-26 20:58 GMT+01:00 Mark Rousell <markr at signal100.com>:

> 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
>
>
>
>
> _______________________________________________
> 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.
>