Feature request from German list: Disable editing of transactions

[Graham Leggett]

Christian Stimming wrote:

> Some German business users brought up a "feature" request that sounds a bit 
> weird for a programmer: They asked for a gnucash mode of operation where the 
> user can not edit older transactions anymore!

Makes perfect sense - wearing my programmer hat on financial systems, 
making it "hard" to change historical data is a normal part of financial 
systems.

> I'm still not completely sure how the actual implementation would look like.

The simplest way to implement this is to define a date: transactions 
before this date become read only, and it becomes impossible to enter 
transactions before this date as well. This is enforced by the gui.

This date might be set to a fixed point in time, for example to end of 
the previous tax year - transactions from this year (or this month) can 
be edited, but not last year. The date would be set when the accountant 
signs off the tax return, or when a month is signed off and closed.

Or, the date might be set to a floating date, such as t-1 (yesterday), 
ie transactions can only be created today onwards. This would provide a 
significantly stricter environment, where all incorrect transactions 
would be forced to be reversed and recreated.

You would definitely want to set this per account, because some accounts 
in gnucash are authoritative (eg accounts dealing with the issuing of 
invoices), but other accounts track some external account source, such 
as a bank account. It would be pretty useless if you were prevented from 
correcting errors while reconciling a bank account.

As to trying to go as far as preventing people from modifying the data 
file and "cook the books", that is outside the scope of gnucash, just as 
it is out of scope of any accounting program. This is easily prevented 
by taking snapshots of the accounting over time, making it very 
difficult to hide an attempt to make an unauthorised entry. I use 
subversion for this (the gnucash source file is checked into source 
control), but writing the files to read-only DVD or CD solves this problem.

Regards,
Graham
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3287 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20080216/04d99009/attachment.bin