Thilo Pfennig wrote:
I think from the acounting perspective every entry consists on som field like the date, the accounts, some text,... I also dont think a mix of inalterable accounts and alterable accounts makes much sense because every entry has two ends, so if one end is inalterable the other one has to be, too.
This isn't true - each entry can have more than two ends in the form of splits, the only requirement is that all the splits add up to zero.
An example of where one split remaining alterable becomes important is when one side of the split goes to "income - sales" (for example), and the other side goes to "bank account". Gnucash isn't the authoritative source for bank account information (the bank is) and therefore it should remain editable until the bank statement is reconciled, but gnucash is the authoritative source for sales. So it must remain possible to allocate the bank split to say "petty cash" or "overs and unders" if a mistake was found.
Of course if the end user wanted gnucash to treat the bank account as uneditable, nothing stops the user from locking both the bank account and the sales account.
I have the strong feeling that different views would help. So that one can look at all without correcting entries. My guess is that it would be better if all new files where made in the same way but that the view could be changed (default view / strict accounting view or so).
I designed a system for an insurance company that worked somewhat like this. Any invoice they raised could be corrected, but this was implemented by automatically reversing out the old entry, and creating a new one. The reversal and the original entry reversed were linked together.
This allowed them to view their accounts minus the reversals, while their auditors would view the accounts with the reversals and so have full visibility of what happened.
To implement this, you would just need to provide a right-click menu option "reverse this transaction", which would add a mirrored version of the transaction for you.
This wouldn't be a solution for everyone though, I certainly wouldn't want that on any accounts I was not authoritative for. Keeping it configurable would be important.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
