本文主要是介绍SAP HCM PE02 保存自定义operation数据dump问题，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
问题描述？
今天在做增强的时候遇到一个很奇怪的问题，当PE02保存规则的时候，如果输入自定义的operation的时，系统就dump，index in PERFORM too large.he current ABAP program "RPUCCCX0" had to be terminated because it found atatement that could not be executed.开始以为是自己增强做的有问题，一直查增强代码的位置，后来想想不对，此增强一直是可以使用的，换个规则都没问题，只是这个规则保存出问题。所以定位的原因应该排查在此规则上。
上图可以看出，有179个参数，但是列表只有97个被调用。所以初步估计是自定义的operation没加到标准的列表，导致系统循环的时候找不到。因为SAP SCHEMA的参数表是存在T52A0中的，所以需要更新此表的排序码.开始犯一个错误，就是选的国家一直是28.所以系统帮我生成更新是这个程序PCOIPCN0,这个程序里面确实有zztab这个自定义operation的编码，见下下图：但是问题是报错的地方不是PCOIPCN0，而是RPUCCX0,所以系统要更新是RPUCCX0这个程序，而不是更新PCOIPCN0。所以问题进一步定位，那现在问题就是RPUCT300为什么更新PCOIPCN0而不更新RPUCCX0，这时候回想国家字段没有选99的原因。
把国家改成99，然后重新执行下报表，发现系统更新的是RPUCCX0这个程序，这正是我们需要的，那既然系统会更新这个程序，那就要看zztab这个自定义的operation会不会嵌入进去，t52a0的表会不会更新。
由上图可以看出，RPUCCX0程序已经更新且zztab嵌入进去。所以此次更新达到我们的要求，那现在的问题就是为什么保存pe02调用是RPUCCX0而不是PCOIPCN0，所以我查看源代码发现，下图是代码的调用逻辑顺序。
后来发现自定义函数在创建的时候，有选国家的分配，没有选择其他国家
但是规则创建的时候选的国家是*，所以系统走RPUCCX0，如果国家分组选的是28，那么就会走PCOIPCN0
这篇关于SAP HCM PE02 保存自定义operation数据dump问题的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
