[SAP - HCM] 白话版SAP HR

ZZ From http://ec.zdnet.com.cn/managesoft/2008/0303/751754.shtml

 

国内典型用户:
三资部分: SAP, Volkswagen, Microsoft, Bosch, Siemens, AMD, AMECO, AT&S, Metro, Samsung, Basf, Shell, Tyco, 某些HRO供应商, ------
内资部分: 联想, 万科, 招商银行, 浦发银行, 中石化, 中石油, 中国电信(网通被Oracle抢了), 中海油, 养生堂, 同洲电子, 上海电力, 邯郸钢铁------
子模块:
PA (Personnel Administration)
OM (Organizational Management)
PT (Personnel Time Management)
PY (Payroll)
PD (Personnel Development)
Compensation
Benefits
Recruitment (or e-Recruiting)
TE (Training & Event Management, or e-Learning)
ESS&MSS (Employee Self-Service, Manager Self-Service)
Incentive Wage
Shift Planning (with PP)

通常国内用到的模块:
PA, OM, PT, PY (号称"四大")

白话PA

PA基本上就是涵盖各个方面的员工主数据, PA有两个基本概念: Infotype和Action.

Infotype是一类相关信息的集合, 用四位数字为代码, 例如: 0001 组织分配, 0002 个人基本信息, 0006 地址, 0008 基本工资, 0021 家庭成员, 每个Infotype其实就是一个table, table里有很多字段, 比如"0002"这个Infotype里有的字段: 姓/名/称谓/别名/婚姻/宗教/性别等等, 同一个Infotype可以根据人员不同国家呈现不同的屏幕, 并且某些Infotype是特定国家专用的, 比如中国专用的"个人所得税/社保/公积金/政治面貌/档案"等. "身份证号"这个Infotype各国都会用, 但是每个国家的编辑屏幕不一样.

Action表示一个人事事件, 例如雇佣/离职/升迁/跨公司转移等, 按照SAP的逻辑, 一个Action会引发一系列特定的Infotype的增减或变更, Infotype的变更也应该有一个Action作为其缘由, 所以要把相关的Infotype按照特定顺序组合起来, 在给员工执行Action的时候, 这些Infotype会按顺序逐个呈现, 用户在前台逐个维护这些信息, 举个简单的例子, 用户在执行"雇佣"这一Action后, 系统会接连调出Infotype: 个人信息/组织分配/地址/排班/基本工资/银行/休假定额------, 用户在前台把这些信息逐个维护直至完毕. 而所执行的Action也被记录于Infotype 0000中. 这一系列Infotype和对Infotype的操作(创建/修改/删除/终止)的组合称为Infogroup, Infogroup被分配给Action.

HR的每个Infotype都必须指定有效期, 有的Infotype有重叠或间断, 用户可以自己定义每个Infotype的"time constraint", 常用的有三种: 1, 无间断无重叠 2,有间断无重叠 3,有间断有重叠, 以业务为例, "基本工资"这一Infotype的time constraint=1, 某人在某一时点必须且只能有一条记录, 如果在1月8号给员工修改"基本工资", 原有的记录就被掐断(即终止于1月7日这一天, SAP叫做Delimit). time constraint=2的例子: 配偶, 员工可以有配偶可以没有配偶, 但如果有配偶只能有一个, time constraint=3的例子: 子女, 某人可以没有子女, 可以有一个子女, 可以同时有几个子女.

某些Infotype可以有Subtype, Subtype的表结构完全继承于Infotype, 只是用来细化和区别具体的Infotype, 例如: "0021家庭成员"这个Infotype可以有"配偶/子女/父亲/母亲/兄弟姐妹"这些Subtype, 这些都是可定义的, 当某个Infotype或者Subtype在同一时间有多条记录时, 再用"Object ID"作为索引来区别, 例如某员工在同一时间有三个子女, "Object ID"分别为1,2,3, 在允许"一夫多妻制"的国家, 也可以用"Object ID"来指代同时拥有的多个配偶.

白话OM.

SAP的OM是基于对象的结构, 每个业务单元都被描述成一个对象(Object), 常见的有: Position(岗位), Org Unit(部门), Job(工作), Cost Center(成本中心), Person(人,即PA里的Employee), Task(任务), Qualification(资格)等, 由唯一的8位数字表示, 各个对象之间建立起来的联系称为Relationship, Relationship是自动双向的, 由字母A或B加3个数字表示, 比如说你分配某个Person占据了某个Position, 系统创建Relationship B008(某人占据某岗), 同时创建Relationship A008(某岗被某人占据), 删除或者修改一个Relationship时, 对应的双向Relationship自动更新. 各类Object允许的Relationship可以配置, 各Relationship允许的time constraint也可以配置, Object和Relationship都需要指定有效期, 两个Object之间Relationship的有效期不可以大过Object本身的有效期.

Position是连接PA和OM的重要纽带, 在SAP HR里, 某Person并不是直接属于某OrgUnit, 而是因为这个Person占据了某Position, 而这个Position属于OrgUnit, 因而这个Person被连接到该OrgUnit, Person同样以这样的方式获得Job, Cost Center的属性.

面向对象的架构使得SAP里可以建立完全立体的组织架构, 避免了平面/梯级架构的层数限制. 用户可以通过"Root Object + Evaluation Path" 来呈现组织结构里的对象和关系, Evaluation Path通常被叫做"评估路径", 就是各种Relationship的集合. SAP会从根对象开始寻找有指定关系的所有其他Objects, 再从找到的其他Objects开始寻找, 如此一层一层往下寻找一直到找不到为止, 当然, 用户也可以预先限定需要寻找的层数.

似乎SAP对矩阵组织(Matrix)的支持方式不是很好.

OM的一个重要的功能是做结构化授权(Structural Authorization), 顾名思义, 结构化授权是区别于PFCG授权的, 直接以组织结构为对象的授权方法, 可以让User ID只能显示或维护某些特定的Objects, 例如, 通过”根对象+Evaluation Path”, 某经理只能观看所在部门的岗位、员工等对象信息. 在实施结构化授权时, 可以在权限档案里直接维护Object的代码, 也可以维护”根对象+Evaluation Path”, 可以将权限档案赋给某个User ID, 或者赋给某个员工号或者岗位, 再通过员工号或岗位与User ID连接, 这样的好处是, 如果部门经理经过调动, 只要在HR里正常维护这一调动事件, 其User ID的权限会自动更新到新的部门, 而不需要维护其权限档案.

在实施Workflow的环境下(无论SAP自己的还是用户开发的), OM通常也被用来做为Workflow的组织结构.

白话PT

从PT开始, HR的技术特征逐渐增强, HR的事务性业务本身复杂无规律以致难以标准化, 典型的比如对排班考勤的处理、考勤对薪资的影响. 为了更加灵活地满足多样的需求, SAP在PT和PY里运用了Schema的概念, 考勤数据和工资均由专门程序来处理, 而schema就是程序运行时所依据的准则, 比如说: 某些员工计加班/ 某些员工不计加班/什么情况下算缺勤, Schema会按照设定的规则, 调用主数据/配置表/历史结果, 经过几千步的运算后返回结果. 用户可以根据自己的需求修改SAP自带的Schema, 按照自己的独特规则处理考勤和计算工资, 但是修改Schema是一个很有技术难度的事情. 事实上Schema可以理解为"业务上的编程", SAP已经提供了成百上千的Rule/Function/Operation, 正是这三者构成了完整的Schema, 每个Rule/Function/Operation都有其独特的结构和功能, 用户只需要按规定格式填写需处理的对象(time type, wage type, 日期, 主数据, 判断标准等). 可以将Schema/Rule/Operaion/Function理解为封装好的、面向业务对象的、专用的超级函数. 强大可配置选项+完善的国家版本+巨大函数库, 在处理时间及计算工资时, 基本上只有想不到, 没有做不到(给SAP做个广告). 当然, 为了保证系统的连续和完整, 这些东西改的越少越好.

排班计划(Work Schedule Rule), 即每周期内每天的工作起始时间、休息时间, SAP支持弹性工作制, 但是弹性工作制也要限定每天的必须工作时间和周累计工作时间. Work Schedule Rule可以根据工作日、假日、周末分成不同day type和class, 可以轻松处理夜班津贴、假日津贴等

考勤方法, SAP提供两种思路: 正向考勤(Positive)和逆向考勤(Negative), 在员工主数据里指定员工使用正向还是逆向考勤, 所谓正向, 是指记录员工所有的出勤数据, 未记录的视为缺勤, 所谓逆向, 是指只记录有Work Schedule有差异的考勤信息, 未记录的系统视为符合Work Schedule, 不做专门处理, 可见, 逆向考勤是对用户和顾问都比较方便的方法. SAP本身不是考勤软件, 也不附带任何考勤硬件, 只是有考勤数据处理功能, 将考勤数据导入SAP,需要经过专门接口(SAP有标准程序), 或者手工Batch Input.

缺勤与缺勤配额, SAP叫做Absence和Absence Quota, 分别存于员工的主数据2001和2006, 每个缺勤类型就是一个Subtype, 比病假、年假、事假等, 有些缺勤是有额度的比如年假, 只能在年假额度里扣, 而年假额度存储于Infotype2006中, 当Infotype2006中的相应额度用完, 此年假在2001中就不可输入(也可以配置成允许额度为负), 如果有剩余额度, 可以按比例结转下期, 或者用薪资补偿. 缺勤额度可以自动预提, 例如, 根据员工组织、级别、年龄、资历进行带薪年假的预提. 除了缺勤配额, 还有出勤配额, 比如每月最长工作时间、批准的加班时间.

时间评估, 即Time Evalution, 翻译成"时间数据处理"更容易懂, 与工资处理类似, 但是时间处理是每天进行, 工资是每期进行. 在时间处理中, 正向与逆向考勤的区别并不大, 都是将计划考勤与实际考勤对比,处理其差异, 只是正向考勤使用的实际数据来自于外部, 而逆向考勤所用的实际数据等于计划加差异. 在考勤处理时, 时间点称为time event(比如上班刷卡,休息开始刷卡), 两个相邻的time event构成一个time pair, 用户在配置表和schema中定义如何生成和处理time pair, 典型应用例如: 将本月加班时间转为下月的休假配额.

白话PY

Wage Type, 即工资类型, 比如: 基本工资/加班费/年终奖/差旅补贴等等, 每个wage type有很多属性, 比如该wage type是否应税? 是否做为社保基数? 是否要累计? (累计的应用: 工资条上不仅有本月工资, 还有本年累计工资). 一个Wage type有三个基本字段: 金额/数量/单位, 用户在前台只能选择”金额”或”数量/单位”一种维护方式, 如果维护的是”数量/单位”, 则在运行工资时按照预定评估标准计算出金额, 在计件计时工资时很有用. 除了这三个基本字段, 工资的运行结果通常还有多个索引字段, 类似于数据库表中的关键字, 用来连接到其他的表. 例如, 某人某月基本工资应该分配给三个Cost Center, 则此Wage type被劈成三条记录, 每条记录有一个”索引”, 在”成本分配表”中也有三条记录三个索引, 通过索引将”工资结果表”中的Wage type和”成本分配表”中的Cost center连接起来. 在财务记账的时候, Wage type分开记入三个Cost center.

SAP里有四个直接和Payroll直接相关的Infotype用来记录wage type, 其中,
Infotype 0008, 基本工资, 持续的、基本的工资项目
Infotype 0014, 周期性发放, 通常记录长期稳定的补贴项目, 比如一年连续发放的交通补贴、通讯补贴,
Infotype 0015, 附加发放/扣减, 该infotype的有效期是一个时点, 所以用来纪录偶然的发放, 比如偶然的工资调整, 依次出差补贴, 某月的加班费(如果未启用考勤).

三者最大区别是, 0008必须一直存在, 0014必须存在一段时间, 而0015只能存在于某一天, 这一天落在工资核算的某一期间内. 三者的共同点是, 他们都是在正常的每月一次(如果是按月付薪)的payroll run中处理.

Infotype 0267, off-cycle, 即在正常payroll run以外的某一天发放, 以年终奖为例, 如果年终奖和年度最后月工资一起发放, 则年终奖可以放在Infotype 0015, 如果年终奖单独发放, 可以放在Infotype 0267.

Payroll Schema与 Time Schema的结构和原理一样, 只是因为各国法规、社保、所得税不同, 导致内容不同.

回溯机制(Retroactive accounting)是SAP里一个非常巧妙的机制, 在以前期间工资已经发放的情况下, 如果再修改以前期间的工资相关的Infotype, 例如: 考勤/工资/组织分配/银行等(用户可以配置哪些Infotype), SAP就留下一个记号, 表示前期主数据已被修改, 修改日期被记录于infotype 0003里, 本期run payroll时, 系统首先在infotype 0003里发现这个修改, 并从修改当期开始重新计算工资, 重新计算并不象FI那样把以前的记录reverse, 而是把旧记录保留, 打个作废的记号, 新记录重新生成, 对于某些重要的且已经报送的wage type, 新旧记录做一对比, 将差额往下传递一直到本期, 并且在本期反应出来, 例如wage type”银行支付”, 系统会根据以前记录的”已经支付”对比回溯计算的”应该支付”, 将其差额带到本期, 在本期进行补充支付, 而不是调整以前的”已经支付”, 因为实际业务中,以前的”已支付”是无法更改的. 此外, SAP使用Control Record的方法, 能够有效防止payroll run过程中修改主数据、避免少算多算、避免未支付和重复支付.

“已付税款”的逻辑与”银行支付”基本相同, SAP的中国版本还提供了两种处理税差异的方法, 一种是重新计算回溯期间的税基, 将税基差额带到本期然后在本期算税, 一种是重新计算税额, 将税额带到本月, 在本月一起扣税.

Payslip(Remuneration Statement) 运用了Form的形式, 可以在payslip上使用员工主数据、文本、窗体、行项目, 在窗体内, wage type若值为0可以不显示, 而行项目无论值是否为0都显示, payslip里还可以对wage type进行简单的加减, 可以根据不同返回值进行不同处理, 但是没有专门的格式和数学函数, 常用的格式转换可以经过系统自带的conversion功能来完成. Payslip上不仅可以调出本期或累计的wage type, 还可以调出本期或累计的出勤、缺勤、缺勤配额等时间信息. Payslip的Form不支持插入图片.

薪资结果的财务过帐, 主要运用Symbolic Account, Symbolic Accounts是HR和FI的纽带, 用来连接wage type和FI Accounts, 其他一些细节包括:1, 可以对员工进行分组, 同一wage type在不同的组下可以记入不同科目, 比如生产人员的基本工资入制造费用, 销售人员的基本工资入销售费用. 2, 财务科目可以分配BS, PL, Vendor, Customer, 所以, 可以在财务里配置Vendor叫做”税务局”, 然后把代扣个人所得税的wage type直接记到这个Vendor账户里. 对员工的AP、AR, SAP会自动搜索并计入到对应的Employee Vendor、Employee Customer账户 3, 分类汇总, 通常按照Cost center对工资进行分类汇总, 也可以选择其他标准. 4, 可以选择是否使用Clearing总账科目