The fixed date locking should be stronger, ideally requiring a password.
The previous year would be locked only when the Treasurer or
other authorized person is really finally signing off on all reporting,
after performing all necessary closing entries to recognize accruals (see
my comment in separate thread "closing of accounts, and locking, "not
needed in Gnucash"? Needed!") and reviewing the financial reports
thoroughly. This matches up to how nonprofits and businesses have to
operate. For a nonprofit, the final financial statements would be given to
board , and used in applications for grant funding, and in filing
IRS-required financial statements which are eventually published online at
Guidestar, and so on. One doesn't want incompatible versions being printed
out and reported publicly, ever! One really needs to finalize the previous
year, for many purposes.
This IS available in one sense. With all of the organizations that I
have been Treasurer for (and using gnucash) when the year end
books/reports have been presented to the Board AND APPROVED (that is a
vote) I would burn copies (of the books and reports at that point in
time) to "write once medium", keep one and give one into the custody of
another organizational officer.
The point is less that the books can't be modified than whether any post
final approval modification could be easily detected.
Please bear in mind that because I made my living doing software (was a
senior systems analyst and senior business analyst) I did NOT consider
any password protection in programs, printed bank statement SUPPOSEDLY
from the bank, etc. to be a reliable safeguard with respect to ME <<
thus I would request another officer to get a statement directly from
the bank to compare, not one from me. After all, I was paid to direct
computers to produce statements just like that >>
Mind, having learned bookkeeping in the old pen and ink on paper days,
the only editing of transactions I ever did in gnucash was correct
immediate errors at the time the transaction was being entered. If an
error older than that was being corrected, would be done the old
fashioned way with a correcting transaction to preserve an audit trail.
Michael D Novack
PS: I would not (in my case) consider even password protection in even
proprietary non-open software to be adequate. I have wielded tools like
disassemblers in my day. The change to almost any program to override
password protection is quite trivial once you find the spot in the
program where done; modify the destination of ONE branch instruction so
a wrong answer goes to the same place as a right one. You don't even
have to reassemble/recompile, just alter the machine code with a hex
editor.
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
