Inline responses.
Sent from my Samsung Galaxy Note 4 on the Telstra Mobile network
-------- Original message --------
From: "Yves Lavoie, GaYLi" <ylav...@yveslavoie.com>
Date: 15/11/2016 01:32 (GMT+08:00)
To: ledger-smb-devel@lists.sourceforge.net
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:
When separation of duties is in effect and approval is delayed
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
RegardsDavid Godfrey
------------------------------------------------------------------------------
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
