（请注意，我对时间和劳动力处理的了解是有限的。这只是之前需要修复的其他人完成的事情，而不是一般的 T&L 实施）
背景
企业有一项 Stat Holiday Bank 政策，没有安排在假期工作的员工可以获得 7.5 小时的银行信贷。如果未采取并导致付款，则有效期为 90 天内。
此运输与物流规则的初始实施并未正确确定到期的银行统计假期已被使用，因此经常在错误的日期支付的情况。
规则重新实现的方法。
- Banked 和 Taken 事件需要匹配，而不是仅仅应用 90 天时效规则。
#1Banked,#2Banked,#3Taken真的意味着#1Banked被 取消了#3Taken，所以只有#2Banked到期了。在这种情况下，Payout 确实是 Taken 的一种形式。
所以规则改写如下：
Record.TL_COMPLEAV_TBL将自最后一个 0 余额日期以来的所有行以及 T&L Batch 的所有行加载POI_START_DT到工作表中。- 将 Taken 的当前 Batch 传入
TL_IPT1行添加到工作表中。 - 按年龄对事件进行排名，即 Banked #1、Banked #2、Banked #3。采取#1，采取#2。
- Cross-out Banked 具有匹配 Taken 的事件。
什么有效
到目前为止，一切都很好。当我检查员工赚取的实际日期并从银行休假时，我可以在适当的时间生成支出。我检查了TL_IPT1原始实现发出的行，并且我自己的内容在所有字段上都匹配，但付款日期除外。
什么行不通。
当我们通过 重新处理 Time and Labor 时Process.TL_TIMEADMIN，新规则不会生成错误完成的支出。实际上，它不会向TL_IPT1.
然而，Time and Labor 发现支付没有发生并产生逆转。-7.5 小时到付款，与原始付款日期相同。
到目前为止，一切都很好。
但是，下一次Process.TL_TIMEADMIN运行时，如果我有一个银行时间赚取事件，那么事情就会出错。
Section.TL_COMPTIME.DA000开始，进行一些计算，打电话DD000，而不是说将 7.5 赚取的小时数添加到已存储的 15 小时，给 22.5 它将设置银行为 0 小时。
奇怪的是，我曾对普通运输与物流实施支持到期和老化的概念表示惊讶，TL_COMPLEAV_TBL但据企业主说，对此没有任何作用。 Section.TL_COMPTIME.DA000，我还没有详细审查，似乎是为了跟踪 Taken 和 Earned，所以它在我看来几乎是因为它决定进行自定义规则已经完成的老化。
在无事可做时什么都不做，我是否采取了错误的方法来支持逆转？当我看到之前的付款不正确时，我是否应该在当天TL_IPT1插入一行？TL_QUANTITY=0
我相当有信心我的支付计算是正确的 - 它们与以前的相同，只是日期不同。但我不知道如何处理逆转。