1.HFIUCPL0我们都知道，在SAP中维护员工的主数据时，为了保证数据的一致性，SAP会自动的把当前的员工数据锁定，这样其他的用户就只能查看，而不能维护。这个设计是SAP严谨性的一个体现，但是同时也给实际的使用带来了一定的困扰，尤其是在结算工资的时候，经常会碰到运行了工资计算的程序后，发现一堆错误都是“用户不能锁定“的错误。只能一个一个打电话或者发mail去催促别人赶紧完成主数据的维护。有没有一个好的方法来解决这个问题呢？答案当然是有的，并且不止一种：1.通过流程来规范：规定主数据的维护（包括人事资料、考勤数据等）的截止时间。但是这种方法在实际执行的过程中，效果也不是特别好，毕竟执行力不是通过一些流程的规范就能够提高的；2.通过技术的手段来处理：SAP已经考虑到了这个问题，所以提供了一个标准的程序，可以在运行工资计算的程序之前，先检查一下有哪些员工的数据是不能锁定的，必要的时候还可以发mail通知，甚至把该用户的session给踢掉（当然需要相应的授权）。这个程序的名字就是我今天要介绍的主角——HFIUCPL0。图1HFIUCPL0运行界面如上图，上半部分是选择的界面，和其他人事的报表的选择界面大同小异。下半部分是程序运行的选项，从上到下依次是：只显示锁定的用户：显示哪些员工的数据当前被哪个用户锁定图2显示锁定的用户发送mail给用户：给锁定的用户发mail踢掉锁定用户的session：把锁定用户的session给踢掉有了这个程序以后，我们就可以通过运行它来做工资计算之前的检查了。它的TCode是PC00_M44_UCPL，当然我们也可以自定义一个Z开头的、容易记忆的TCode。2.RDDKOR54顾问在实施的时候，主要的工作之一就是维护IMG中的数据。而IMG说穿了，也就是一堆堆的Table或者View。所以顾问实际上也就是在维护Table或者View的数据。但是有个问题是顾问在维护的时候经常碰到的，就是”命名空间“。比如说维护工资项的时候，是不允许用字母开头的；维护自定义的rule的名称时，是不允许用A-Y打头的等等。如果你没有使用用户的命名空间，而是使用了SAP的命名空间，一般情况下，你的下场有两个：1.无法保存；2.以后在升级版本的时候，你做的修改被SAP所覆盖所以顾问在配置系统的时候，还是要遵守命名空间的规定的。当然，有些有经验的项目团队会在项目配置开始之前，就先准备一个命名规范，规定报表如何命名，工资项如何命名等，这样也就防止了上述问题的发生。但是，会不会有人会问：SAP到底有哪些给用户使用的命名空间呢？这个问题，可以通过运行程序-RDDKOR54来得到答案。如上图，就是程序的运行界面，你可以输入你要维护的Table或者View的名称。如以PersonnelCalculationRule的名称为例，我们知道PersonnelCalculationRule是保存在T52CE表中，就在文本框中输入T52CE，然后运行，得到如下画面：我们从程序运行的结果可以清楚的看到，PersonnelCaluationRule的用户命名空间是不包括A-Y开头的。有人也许会问：怎么知道我要维护的表或者试图的名称是什么呢？鉴于这个问题太过”三俗”，我就不在这里回答了，自己想办法解决吧3.TABLE和VARGB今天不谈报表，谈一下SAPPayroll中比较常用的两个Operation——TABLE和VARGB。为什么要说这两个Operation？起因是来自于网上的一个帖子：一个老印（如果我没猜错的话，应该是个印度人）讲述了他碰到的一个问题。他们的系统中在信息类型0001中增加了一个自定义字段”能否享受福利基金”，选择”E-是”或者”N-否”。然后在工资计算中去读取这个值，来计算对应的金额。他们自定义的PCR类似下面这样：TABLEP0001VARGBZZZZ(自定义字段的字段名)*ADDDWTE<具体如何计算>就像童话故事的结局一样，他们已经解决了计算福利基金的问题，从此过上了幸福的生活。但是，悲剧发生了。他们最近碰到了一个问题：有一名员工，2010/01/01能享受福利基金；到了2010/03/01的时候，不能享受了。结果在算3月份工资的时候，由于其他的主数据更改导致回算到1月份的工资，发现回算的1月份、2月份的工资里面都把福利基金给扣掉了。也就是说：在回算1月份、2月份的工资时，VARGBZZZZZ取出来的数不是”E”。为什么会这样呢？难道TABLE不支...
