轉自http://www.itpub.net/viewthread.php?tid=795903&extra=page%3D2%26amp%3Bfilter%3Ddigest
白話版SAP HR
SAP HR
別名: SAP HCM(Human Capital Management)
國內典型用戶:
三資部分: 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總賬科目.
別名: SAP HCM(Human Capital Management)
國內典型用戶:
三資部分: 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總賬科目.