Conversation
| differenceInSeconds(payment.timestamp, deposit.timestamp) < 240 | ||
| ) { | ||
|
|
||
| // mutate the original array to use in next heurisitc match |
There was a problem hiding this comment.
This similar problem will exist in cash totals as well, needs fix
There was a problem hiding this comment.
Could we implement the layered approach here, but invert it. So first we check 1:1 matching where difference in seconds is very small, then if no matches, continue to broaden the window until there are none yet left to be matched for the date?
There was a problem hiding this comment.
start with 10 seconds and broaden until 240 (or whatever upper limit is) seconds? Then yes.
if more, then no.
There was a problem hiding this comment.
Okay, so there is no case in which a transaction occurs and the deposit could be delayed greater than 240 seconds?
There was a problem hiding this comment.
there could be but having a greater time span make more possibility for bad matches than good ones? this could be wrong but how I understand it now. we can verify with BAs.
Objective:
Fix bug that does not mark
match=truefor certain deposits when they were matched.Issue - reuse of deposits for matching after they were already used for matches!