Hi all,
Our current reconciliation code is based on the fact that approval
closely follows submit and that no more than one submit is pending.
This pose problems in 2 cases:
1. When separation of duties is in effect and approval is delayed
2. When migrating from SQL-Ledger, for all submits are done by the
migrator but all approvals are deferred to a user because they
cannot be undone and would create an unsolvable situation for users
it they were to be approved by the migrator and error were present.
The problems arises because we do not record the date when a transaction
cleared, so when an approval is done, future transactions are already
present in the database and gets affected before they should.
To fix this, PR2203 was submitted and adds recording of cleared time to
the transactions and stop relying on the maximum id of the transactions.
As this affects a sensitive part, carefull inspection will have to be
done before we move toward that. But it fixed SL 3.0 migration problems
for an 8 years database.
We also currently only send a warning when unapproved transactions are
present before submit or approval. Submits pose no problem for reports
can be deleted a reconciliation restarted anew.
Approvals are another story because we forbid undoing. So currently one
can approve the latest reconciliation, refuse a prior one, submit and
approve a different version and possibly invalidate an already approved
reconciliation. This would be a deadlock situation. I suggest to forbid
out of order approvals.
Any comments?
Yves
------------------------------------------------------------------------------
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
