How to close a financial year

Mike or Penny Novack stepbystepfarm at dialup4less.com
Thu May 25 11:25:50 EDT 2017


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.


More information about the gnucash-user mailing list