(Note that my knowledge of Time and Labor processing is limited. This is just something that was done previously by someone else that needs fixing, not a general T&L implementation)
Background
Business has a Stat Holiday Bank policy, where employees who are not scheduled to work on holidays get a 7.5 hour bank credit. Expiry is within 90 days if not taken and results in a payout.
The initial implementation of this T&L Rule did not correctly determine cases where a Banked Stat Holiday due for expiration had already been taken and, as a result, often paid out at the wrong dates.
Approach for Rule reimplementation.
- The Banked and Taken event need to be matched up, rather than just applying 90 day aging rules.
#1Banked,#2Banked,#3Takenreally means that the#1Bankedis cancelled out by the#3Taken, so that only#2Bankedis up for expiration. In this context, a Payout really is a form of Taken.
So the rule was rewritten as follows:
- Load all
Record.TL_COMPLEAV_TBLrows since the last 0-balance date, and up the T&L Batch'sPOI_START_DT, into a work table. - Add current Batch incoming
TL_IPT1rows for Taken into work table. - Rank events by age i.e. Banked #1, Banked #2, Banked #3. Taken #1, Taken #2.
- Cross-out Banked events that have a matching Taken.
What works
So far, so good. I can generate Payouts at appropriate times, when I examine the actual dates that the employees earned and took banked time off. I checked the TL_IPT1 rows that the original implementation was emitting and my own contents match on all fields, except for the date of payout.
What doesn't work.
When we re-process Time and Labor via Process.TL_TIMEADMIN, the new rule does not generate payouts that had been done incorrectly. It in fact, does not send anything to TL_IPT1.
Time and Labor however picks up that the payout isn't happening and generates a reversal. -7.5hrs to Payout, same date as original payout.
So far, so good.
However, the next time that Process.TL_TIMEADMIN is run, if I have a banked time earned event, then things go wrong.
Section.TL_COMPTIME.DA000 kicks in, does some calculations, calls DD000 and instead of say adding 7.5 earned hours to a banked 15, giving 22.5 it will set the bank to 0 hours.
Oddly enough, I had expressed surprise that the vanilla T&L implementation supports the notion of expiry and aging in TL_COMPLEAV_TBL but then, according to the business owner, does nothing with it. Section.TL_COMPTIME.DA000, which I haven't reviewed yet in detail, seems to be intended for keeping track of Taken and Earned so it almost looks to me as it then decides to do aging that the custom rule has already done.
By doing nothing when there is nothing to do, am I taking the wrong approach to support reversals? Should I instead insert a row into TL_IPT1 with TL_QUANTITY=0 for that day, when I see that there was a previous incorrect payout?
I am fairly confident that my payout calculations are correct - they are the same as the previous ones, only the dates differ. But I don't know how to handle reversals.
