Re: Reconciliations

[David G <..hidden..>]

Inline responses.

Sent from my Samsung Galaxy Note 4 on the Telstra Mobile network

-------- Original message --------
From: "Yves Lavoie, GaYLi" <..hidden..>
Date: 15/11/2016 01:32 (GMT+08:00)
To: ..hidden..
Subject: [Ledger-smb-devel] Reconciliations

    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.

This is a great catch. Well done.

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?

I'd vote for forbidding out of order approvals. Unless of course something more elegant can be trivially contrived.

One possible way of allowing out of order approvals would be to introduce a pseudo approved state.

Basically if someone wants to approve something out of order flag it pseudo approved . Once the prior items are approved if it hasn't affected the pseudo approved item it can be flipped to approved automatically  (by the approval routine that dealt with the most recent full approval.) 

This can then be iterated through to handle the next possible pseudo approval as needed.

At any time a pseudo approval can be revoked (eg if the effect/data of approval has changed due to prior real approvals) with the result that it needs to be re approved . I'd think a note should be attached if a pseudo is revoked explaining the reason it was returned for re approval 

Regards

David Godfrey 

------------------------------------------------------------------------------

_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel