Locking transactions

[Mike or Penny Novack]

I am not sure I understand this. Is it possible that the Norwegian 
authorities just don't understand what we programmers can do?

a) It is VERY simple to "lock" a set of books as of some date. One 
simply burns a copy (of the file) to read only medium such as CD or DVD. 
This is then turned over to other custodial care. If at some time in the 
future a question arises of possible data alteration, a simple byte by 
byte compare settles the matter.

b) There is no other "locking" that is possible in the sense that 
absolutely nothing would prevent me (or any other competent systems 
type) from  recreating a changed version of the data. It is difficult (I 
won't say impossible) to devise a locking of data we couldn't simply 
undo in the data file itself. Note that to simply recreate the books 
with altered data does NOT require programming skills -- any of you 
could do this. If a bookkeeper wanted to reserve the ability to alter 
"locked" books, just make a copy of the file prior to locking -- or if 
forgotten, restore from the last backup prior to locking.

c) This is not really different than the situation for old fashioned pen 
and ink on paper accounting. You see before you a physical set of 
journal and ledger books. What assurance do you have that THESE books 
are the only versions in existence or are the version from which reports 
had been produced and submitted? The computerized system isn't any 
different in that regard. Seeing a locked file, you have no way to know 
that's the RIGHT locked file.

Michael D Novack



Birger Baksaas wrote:

>Hello,
>I saw a discussion about locking transactions on 2008-04-14 GnuCash IRC
>logs (http://lists.gnucash.org/logs/2008/04/2008-04-14.html#T16:07:43)
>and a sort of specification in
>http://www.linas.org/linux/gnucash/projects.html. Does anybody know if
>there has been a progress on this?
>
>The background for my question is that the organization behind the
>generally accepted accounting principles (GAAP) in Norway has published
>a statement where they consider accounting systems without locking as
>manual accounting systems. These are only suitable for businesses with
>less than 300 transactions per year, the say. And, everything must then
>be printed out on paper and signed at the end of each accounting period.
>
>It should be quite easy to integrate locking with the Close Book
>function in GnuCash. A check box could trigger this. The function would
>set all transactions with dates before the closing date as read only. If
>the user needs to make changes later, she/ he has to enter new
>transactions with the needed corrections and with dates after the
>closing.  
>
>The point is that normal users should not be allowed to make changes to
>transactions after financial reports are sent to the authorities.
>
>It is probably not critical if the user can enter new transactions
>before a closing date. These transactions will just cause immediate
>problems for the user and have to be corrected. So, GnuCash does not
>have to make comprehensive tests on dates in ordinary use after locking.
>
>- There might be problems with users that hit this function
>unintentionally, but a warning should tell them to make backups before
>locking.
>
>I am programming in C, and could look at implementation if needed.
>Guidance towards the relevant modules and functions would then be
>helpful.
>
>((GnuCash and other Gnu programs such as gretl are excellent in addition
>to own routines, and will be even more useful in the future, I
>believe!!!))
>
>Best regards,
>Birger 
>
>_______________________________________________
>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.
>
>  
>


-- 
There is no possibility of social justice on a dead planet except the equality of the grave.