Reconciliations

["Yves Lavoie, GaYLi" <..hidden..>]

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
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel