【精选】SAP HCM正向考勤取卡总结（方案篇）

做HCM考勤的顾问都知道，正向考勤是记录员工每个排班日的实际工时发生过程的考勤方式，主要是制造业在使用。但是，具体实施起来每个项目都有非常多的个性化细小的需求。通用的都需要面临的两个问题是与第三方考勤机系统的集成以及集成之后数据该如何同步刷新到信息类型2011中。

与第三方考勤机系统的集成基本属于技术实现问题，现在主流的有IDOC方式，API方式，Web Service方式，自开发调用RFC方式（主要是针对不能直接与SAP集成或者直接集成技术不支持情况开发一个中间程序完成两者的集成）。

使用此方案对于正向考勤来说，所有的DWS必须设置取卡范围。 必须在PT之前或者PT时构建好评估日的PT表。

DWS需要设置取卡范围的原因是，设置的DWS只设置了标准的上下班时间。由于上下班不能在卡机端区分出来。只能按时间发生顺序来定义卡是上班还是下班。为了确定卡是否属于评估日，需要通过取卡范围来界定，如果指定的话评估驱动程序如法判定出这张卡与那张卡成对，会导致实际卡数是成对的但是评估之后仍然是缺卡的异常。

如果员工的休息日加班也是排有上下班时间的DWS的话不需要特殊考量。针对休息日排班是OFF这样的没有具体的上下班时间，没有具体的取卡时间范围的情况需要根据实际情况决定。建议使用前一天工作日的取卡结束之后的后一秒作为OFF的取卡开始，如果后一天是OFF的话以23:59:59作为结束，如果是非OFF的话以次日班次的取卡开始的前一秒作为结束。如果前一天仍然是OFF的话则以当天的00:00:01作为当天的取卡开始。

由于设置了取卡范围，对员工实际上班的影响就是，员工如果发生需要跨取卡范围上班的情况，必须在当天取卡范围的结束前打卡，同时必须在次日取卡开始后打卡。

适合传统的集中地点考勤打卡的方式。往往是几台机子放在几个固定的地点，员工不论上班或者下班均在同几台考勤机子上刷卡。

此方案基本同方案1一样，不同的是需要根据某个考勤相关的字段值（例如信息类型0007的时间管理状态字段值）最终确定需要把员工的评估日中取卡范围的那些卡作为考勤评估的有效卡。

根据有效卡数确定那些卡有效的功能逻辑同样是两种实现方式：一是放在独立的取卡功能程序中，二是放在schema的function中完成。

现在多数企业均在园区中使用了第三方的一整套的园区管理系统（最新流行的说法是智慧园区系统）。主要是集门禁设备、园区监控设备、车辆进出管理、人员进出管理、外部访客进出管理、电梯使用权限控制、办公区域及生产区域的门禁权限控制等一套统一的软硬件系统。

鉴于此，多数企业使用员工进出的门禁数据作为考勤依据。而不再是固定的考勤卡机的方式。门禁系统员工的进出是发生在两组设备（一组是进门设备，一组是出门设备）上的是可以区分清楚进出即上下班的。

如果指定区域的门禁设备的进出记录全部作为员工的有效考勤记录的话，可以不需要给DWS设定取卡范围而是直接将所有的记录根据进为P10出为P20的方式同步到信息类型2011中。注意不需要设置日分派标志，PT驱动程序RPTIME00或RPTIME01会根据DWS的时间设置设定每张卡的日分派标志。

如果是需要明确区分员工的加班是属于那一天的，以便具体判定该加班是1.5倍、2.0倍还是3.0倍。加班倍数的判定特殊的主要是夜班情况的发生，《劳动法》只规定了不同情况的执行倍数，却没有针对夜班该怎么计算做出规定。

如下是劳动法的规定： 所以，实际中不同的公司计算方式是不同的，有的按排班日来算，这种在SAP中相对来说比较好处理。有的按实际的自然日计算，这样就需要把一个评估日拆分成两部分来分别计算发生的工时。

如果加班是按排班日来判定的，还是需要设置DWS的取卡范围，因为评估驱动程序设置一对卡的所属时比较灵活，如果这对卡中有一张在DWS的区间内就算当天的，但是如果都不在的话就不好确定，可能算当天的也可能算后一天的。

如果加班是按实际的自然发生日来计算的话，可以不设置取卡范围。

此方案与方案3的区别在于，如果进入信息类型2011的卡即为有效卡的话需要自定义功能程序实现写入逻辑，这样的话必须要有DWS的取卡范围。

如果是在Schema中的function中实现的话，需要将所有卡都写入2011中，同时DWS的取卡范围也是需要的，然后根据逻辑重新构建评估日的PT表中的卡对数信息即可。

至于取卡次数的设定，同方案2一致即可。

该方案的情况相对复杂一些。对于卡的时间事件类型能区分的卡使用P10和P20区分清楚，不能区分的使用P01。

这种情况一般是企业存在多种考勤方式，例如：固定点考勤、门禁考勤、微信/钉钉移动考勤，或者总部是门禁，但是人员出差到其他子部时使用的是固定点考勤方式等造成了多种考勤方式混用的情况。

因为存在不区分的情况所以DWS必须设定取卡范围。然后可以通过自定义程序实现有效卡的写入2011或者在Schema中重构评估日的PT表。

就个人经验而言，区分上下班卡+所以卡有效的方案是实现最简单，开发量最少的。如果第三方考勤机本身就对与SAP的集成做了适配的话只需要配置即可。例如KABA考勤机系统就实现了通过IDOC的方式集成到SAP。

其他方案均需要自开发程序或者Schema的Function完成取卡过程。

对于考勤取卡，个人认为应该分为两个步骤完成，一是抓卡过程实现的是从各种考勤机中抓取数据到SAP中，具体可以存到自建的表也可以存到标准的CC1TEV中。二是取卡过程从各种考勤方式终端汇总到SAP的原始卡数据中依据具体的取卡逻辑获取有效卡作为评估的依据。如果没有多种考勤方式终端的话两个过程可以合并为一个，否则建议先汇总，毕竟不同的终端数据汇总到SAP的效率是不同的。

从已经实现过的方案看对于需要自开程序或者Function的，开发function的方案效率更高，一是代码逻辑简单，二是执行性能好，三是能适应某些员工排班在考勤月结之前频繁变更的情况。 由于不需要自己写大量的获取人员排班信息以及DWS具体的信息等其他考勤相关的标准信息，所以代码只有核心逻辑代码。 直接利用评估驱动程序的能力执行效率高，取卡与评估同时进行。 对于变更员工排班频繁的制造考勤员来说月底处理考勤的效率高，不需要等待取卡程序漫长的运行之后再等待评估的完成，直接进行评估。

本篇是依据个人经验总结的所有的方案内容简述篇，不是具体的实施FDS，如有不当之处还请同行指正。

另外，计划后面写一篇具体的设计与代码实现篇，内容将涵盖具体的配置表的DDIC的设计，自定义Function的逻辑设计，以及具体的核心代码的共享。