On 5/24/2017 10:56 PM, doncram wrote:
Thank you to David T. and to Michael D Novack and others for
observations on closing. Ideas from these and other comments that I
can look for in past ("annual") discussions oughta be incorporated
into documentation. Some notes while this is fresh:
*Note freezing is not the same...the prior years data stays in your
system, and if it is not frozen then errors can be introduced, you
might accidentally add or change a prior year transaction. In
commercial standard accounting, the past data is locked by password at
least, and prior year info is only changed in exceptional
circumstances (explain those...and how even for public restatements of
financials, the past info is likely not changed).
*I still am gathering that password-locking the past period data is
not possible.
This is getting tiresome?
In ANY computerized system, "password locking" protects only against
accidental changes to the data. It does not protect against malicious
alteration by a person skilled in software. You underestimate the levels
of protection necessary to lock out somebody who can get physical access
to your machine << eg: can I interrupt the boot sequence and change the
boot order so instead of coming up in the usual operating system the
machine will boot from a different device and thus the operating system
of my choice? >> This problem is much more severe in the case of "open
software" where a far lower degree of skill is necessary to get around
password protection. But some of us have the skills and tools to get
around it even if not open software.
And since this began as a "close the books" discussion, whether prior
period data remains in the (new period) books is your choice. When I
discussed simply making read only copies and passing these out of the
bookkeeper's control I was demonstrating a work flow that could provide
proof* of alteration of prior data. Most people consider that enough,
and would prefer to be able to look at prior data (in the current books)
and not have to reload from a backup copy to do that. BUT, if that is
what you want, after closing the books you can create the new set of
books without prior data. That mimics the usual procedure of back in the
days of pen and ink on paper in bound volumes, where new volumes were
begun with the new accounting period. In other words, you are talking
about "work flow" matters and not the application itself.
And no, backup instruction do not belong in application guides. On our
computers, we have data created by lots of different applications. We
need backup procedures that back up ALL of our data. So discussion of
alternatives for backup belong in a "computer users" guide, not
application by application. Our working backups these days are usually
not on read only medium. But it wasn't that many years ago, before large
external drives became cheap, that I was burning even these to read only
DVD.
Michael
* Yes, I was sometimes called upon to do that, run byte by byte compares
to demonstrate that something HAD been altered.
_______________________________________________
gnucash-user mailing list
gnucash-user@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.
