Feature request from German list: Disable editing of transactions
minfrin at sharp.fm
Fri Feb 15 17:50:51 EST 2008
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3287 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20080216/04d99009/attachment.bin
More information about the gnucash-devel