Locking transactions

Tue Mar 10 18:12:51 EDT 2009

Hi again

Every country probably have the same requirement for locking for
business accounting. The point is to have one file only, not a separate
one for each year. If the authorities make a review, they first check
that the business have posted transactions up to current date and then
look for the details they want from previous years in the same system
(file). 

It is not easy to make balanced changes to previous transaction details
in such systems without trace as long as previous periods are locked in
the user interface. That is why authorities (in probably all countries)
trust them. 

Of course programmers can go into the database (or xml file), but to
make such changes balanced and without affecting current period, would
be quite hard. One could not claim that such changes was unintentional,
either.

The best solution, as I see it now, would be a "Set Read Only" menu item
separate from "Close Book". The input dialog will only ask for a date.
Then the users can turn transactions read only before the given date as
often as they need and want to, every day if they wish. I would do it
once a year after last year's accounts are finalized, have come back
from the auditor, and ready to be sent off to the tax authority. Then I
would set everything before Dec 31 as read only. (In the mean time, I
would have continued with the new year's transactions, in the same
file).  

Birger    

On ti., 2009-03-10 at 14:20 -0500, Mike or Penny Novack wrote:
> 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.
> >
> >  
> >
> 
> 