在SucessFactors的定额有效扣优先级如何与SAP定额优先级匹配从上线到现在一直是困惑我的问题，最近集团调整假期有效性规则，这才使我有时间彻底研究两套系统的规则。
1.首先我们来看SuccessFactors有效性规则配置，在这与SAP有差异的是系统会自动先匹配预定的结束日期，如果预定结束日期一样，系统去找预定的开始日期（先进的地方也是困惑我的地方）。
2.然后我们SAP定额的几个信息类型，2001(假期类型)，2006(定额类型)，0416(定额补偿类型)，涉及的表是PA2006、PTQUODED、PA0416,ER关系图如下：
也许看ER图对有些小朋友看的比较辛苦，直接看数据可能更直观，PTQUODED-QUONR=PA2006-QUONR=PA2001-QUONR,这个字段关联请假扣除那条定额，PTQUODED-DOCNR=PA0416-DOCNR关联是结转加班费与定额之间关系
我们看看底层数据，是不是这个时候来感觉，理解容易一点
3.上面介绍是表直接的关系，更关键的上线如果两个系统扣减优先级不一致，数据就乱套,SF能请假到SAP就提示余额不足，对运维是个非常困难的事情，我都不知道我当时是如何坚持下来，想想甲方不一定就比乙方好弄，想想原来处理问题的及时性，到现在撒子都要走流程，有问题就是测试不充分，宝宝苦啊~~~，言归正传，SAP提供一个业务规则调整后批量刷新原来直接关系的程序，简单理解就是重新刷新扣减优先级，保证两边系统扣减规则一致性(SAP强大的地方)，注意这里不但会刷新2001余2006的关系，也会刷新0416与2006的关系，所以标准解决方案总是复杂“难搞”的。
4.执行如上程序以后，表之间的关联关系也会随之改变，原来的笨办法就是把原来的数据删除，然后重新同步，想想原来够傻的。
5.此刻并不是终点，问题点随之而来，上面我在难搞标记红色，是因为标准解决方案你永远都不知道如何走向，当员工2006的扣减结束是2020-05-31且剩余2天假期，此时结转0416的定额，系统会自动把2020-05-31的优先扣除，因为老外觉得，过期的年假或者调休都应该有补偿的，所以在程序中参数写死，
执行ignore_interval这段代码后，扣减日期自动就变成18000101到99991231，所以过期的数据就还会出现，即使调整优先级结束日期都是99991231。
6.如果需要增强需要实现BADI，PT_QUOTA_DEDUCTION
参考手册:KBA2399188 IT0416 Leave Compensation in the wrong quota record
