# Sap Hcm Payroll Configuration - Link: https://www.lorenzo-datasolutions.com/sap-hcm-payroll-configuration/ - Published: 2017-04-01T17:12:41+00:00 - Author: Anipe Abraham sap hcm payroll configuration, SAP Hcm Payroll is one of the key modules in SAP Human Capital Management. It is used to calculate the remuneration for each employee with respect to the work performed by him.SAP Payroll not only consists of remuneration part but also includes other benefits that any organization has to provide for the employee welfare according to different company laws in the [country](https://www.lorenzo-datasolutions.com/employee-central-payroll-videos/) ## Separate Payroll Areas Remember that one of the criteria for choosing separate payroll areas is that each payroll area has to have a separate PAYE reference. You can’t have more than 1 PAYE reference for the same payroll area. There are also other criteria for choosing separate payroll areas. The pay frequency and pay date are key criteria [as well.](https://www.lorenzo-datasolutions.com/self-paced-videos-of-sap-successfactors/) In addition, there may be other factors such as how you wish to report on your employees which may be driven by business needs rather than by SAP validation checks and statutory conditions. ## Error Message relating to Negative Pay You may find that you are running the first payroll period for the new tax year and you get the error[ message:](https://www.lorenzo-datasolutions.com/success-factors-training-videos/) This period’s taxable pay takes total year to date into a negative situation You also get this situation for leavers. See the topic relating to that issue and solution as well. The error and scenario described above can be as a result of a retro going back over the year end for an absence update to the system (e.g. SSP/SMP in the UK). The above error may be solved by re-importing the ORT at the appropriate stage of the schema. It can happen that during the schema when SAP is comparing the ORT it may be using spurious results which may contain incorrect [figures.](https://api.whatsapp.com/send?phone=919912283899&text=&source=&data=&app_absent=) You can get around this by re-importing the ORT using the function IMPRT O, just before the new processing is carried out. See the OSS notes 653211 and 721490. The OSS note 653211 contains more details on how to undertake this piece of work. ## How does SAP handle 52 and 53 week tax years? The answer to the above question is best answered by looking at the many OSS notes which cover the above topic. There are many notes [covering ](https://www.facebook.com/LorenzoDataSolutions/) this topic. ## Handling Late Leavers with GRET Typically the following can happen in your organisation. An employee leaves directly after the bank transfer has been initiated. The company wants to retrieve the money owed. It’s probable that you will end up with a negative value for the technical [wage type ](https://twitter.com/anipeabraham)/121 – taxable gross pay. The error that you will normally see in the payroll log is: GGDN*/121 less than 0 ERROR #NEXTR A * “NEGATIVE TAXABLE PAY… This is a typical situation in the UK which is caused by a late leaver. The UK has a special schema for handling this scenario. The schema is GRET (or your customised version of it) which needs to be run instead of G000 (or your customised version of it). The difference between the 2 schemas is the gross to net processing (G000 uses GNT0 whereas GRET uses GNT9). When the tax rewrite takes place SAP is hoping to get rid of GRET, but until that happens, when you get a negative /121 (which is usually a classic sign for a late leaver) you will need to run GRET. With GRET, the retro processing does not take place as per usual with the normal schema. In addition, whereas the normal schema G000 calculates the tax cumulatively( unless the employee is on a week1/month1 tax basis), GRET recalculates the tax period by period. ## Searching for Key Documents on the SAP Support website If you struggle to remember where SAP holds the key documents and guides for HR and Payroll, just type in the shortcut after the www.service.sap.com URL. For the UK add “hrgb”. The full URL then becomes: www.service.sap.com/hrgb For other countries just add the 2 appropriate letters after hr. The following are valid examples: www.service.sap.com/hrza South Africa www.service.sap.com/hrde Germany If you are searching for UK specific documents relating to SxP, eFiling etc just drill down into the documents in the menu on the left hand side or use the useful“ Quick Links” on the right hand side. ## Checking for Deleted Payroll Results To find out which payroll results have been deleted you can check this by using transaction code SLG1. Use the object HRPU. ## Reporting on Payments sent to the bank There are a number of different reports for determining the cash breakdown of bank payments made to employees. UK payroll staff used to use the report RPCGTNG0. This was replaced by the Payroll Journal report (RPCLJNG9) as outlined in OSS note 427685. Whilst the payroll journal is useful, it requires the wagetypes to be configured on evaluation class 03. The transaction code to get to this report is PC00_M08_CLJN. Another useful report is the Payroll Results Check Tool (RPCRECG0). Before this can output meaningful results, the Payroll Results Check Tool generation ( RPURECG0) has to be run. For these reports to run properly, configuration has to be carried out for evaluation class 15. Another extremely useful report output is the Cash Breakdown for Cash Payment based on Payment Method (H99CMLI0). The required transaction code is PC00_M99_CMLI0_NEW. Use the SAP standard variants to start with. The variant SAP&GB_PAYMENT is a good one to start with. When you get your output, click on the hyperlink which is offered to you when you hover on the * on each of the different output lines. ## General This will be old hat for most of you, but for those who are learning payroll, it is important to remember that there are certain mandatory infotypes which an employee must have, in order for you to run a successful payroll for them. One of those infotypes is Planned Working Time (0007). If you delete an employee’s Basic Pay infotype ( 0008) record, the payroll will still run, but falls over if you have entered any overtime etc. You can, however, have an infotype 8 record, without any wagetypes. ## Payroll Simulation from IT 0008 Payroll Simulation from Infotype 0008 – Feature PM004 If you wish to run a payroll simulation from infotype 8, you can do so by modifying the feature PM004 – to reflect the lines indicated below. 1. 000030 IT D ABKRS 2. 000040 IT S1 &PM004=1/INFOTYPE 8 S1 3. 000050 IT S3 &PM004=1/INFOTYPE 8 S3 4. 000060 IT W1 &PM004=1/INFOTYPE 8 W1 5. 000070 IT ** &PM004= The above variants were created. The feature links the payroll area to the corresponding feature. ## Details of Deleted Payroll Results Choose transaction SLG1. The Evaluate application log screen appears. In the Object field, enter HRPU. In the Time Restriction group box, enter dates and times to determine the period you want to check. Choose Program Execute. A list of payroll results deleted during the specified period is displayed. The list displays the deletion date and the administrator who has deleted the payroll result. Select an entry from the list. Choose Goto Display messages ## Notifications on Payslip – General and Personnel Use the menu path: Tools SAP Script Standard Text or transaction code SO10. **Use the ID:** HR_G which is the one for general messages. Type the message, save it and then attach it to an employee or group of employees on IT 128 – sub-type 1 or 2, so that it can appear on the payslip. You can use the fast entry screen for master data – transaction code PA70. Note that for personal messages, you need to create an IT 0128 sub-type 2 for each applicable employee. For general messages you have to create an IT 0128 sub-type 1 for each and every employee in the payroll area. This can be a bit of an effort if you have a few thousand employees. Larger customers might wish to use CATT procedures or write an ABAP routine to automate the update. There is a program RPU12800 which is a model report for creating batch input sessions for infotype 0128 subtype 2, personal notifications. You still have to use the standard fast data entry functions to enter records for subtype 1, general notifications, en masse. ## Constant Amounts on a Wage Type – Indirect Valuation If you are wanting to assign a value against a particular wage type you can use 3 different methods. 1. If you have the same value for different pay scale types and areas you can enter the amounts on table T510 for each type or area. You need to set the characteristics of the wage type to TARIF. When entering the wage type on IT0008, you specify the wage type and the value will then be defaulted in. 2. If you have the same value for each employee in the company, you can use T539J. Remember to insert the WT on the table and have the characteristics set to PRZNT or SUMME for the Indirect Valuation module. When entering the WT on IT 0008, you don’t get to see the value of the amount. 3. If you have the same value for each employee for a particular WT, you can use table T511k which allows you to insert different constants. As in the previous case you will not be able to see the amount once entering the WT on IT 0008. You can use different levels on the number/units to give you the flexibility to call different amounts. You can then call the constants found in T511K with the different amounts, where each amount is linked to a different level. ## Payslip Config Extras When writing rules for the payslip, remember that the rule has to cover all possibilities in order for it to work correctly. In other words, if the rule checks for EE Group, ensure that you have interrogated all the EE groups, otherwise the rule will not work correctly. SAP has validation rules set up within the payslip config. If you wish to bypass this validation – enter the config directly on the T512… tables. If you wish to configure a field on the payslip and SAP gives you the warning message“ the table or field you entered is not valid”. You can enter the pertinent table into table T514K and the field into table T514N. You may even find some fields on SAP-standard payslips which do not exist in these tables. ## Payroll Control Record Transaction Code: PA03 Menu Path: Payroll Tools Control Record The payroll control record allows you to control the state of the payroll run. Control records are not transported across clients. They have to be created in each client. The control record only advances to the next payroll period when you move it from a state of “Exit Payroll” to “Released for Payroll”. You will be prompted with the warning: Payroll area xx: Do you want to release the period xx.yyyy for payroll?. Clicking yes will advance the payroll control record. If you wish to change either the payroll period or the earliest retro accounting period, you have to delete the control record and then recreate it with the correct dates. Remember that if you are loading your cumulative values into period 6/2001( i.e. running XLK0 for 6/2001) then you should set the earliest retro date to 7/2001. This will stop anyone from entering any data which may cause the payroll to try and retro into a period in which SAP never created a full set of payroll results. The icons at the top left of the screen show you which employees have a matchcode of W (those employees who have had data modifications during the current payroll monthly cycle). The icon showing 2 employees next to one another is used to list all the employees who have been processed through the payroll for the current month. The locked icon indicates which employees have been locked and will therefore not be processed through the payroll. ## Pre-DME When running the Pre-DME program, each employee processed has a specific time and date stamped in their payroll results in the BT table. This will be the same for all employees processed in each report – which is done per payroll area. If for some reason the report is terminated during processing, you can re-run the Pre-DME with the relevant time and date in the boxes at the bottom LHS. Fill in the time and date in the field Repeat Run and tick the checkbox “flagged records only”. This will pick up all those employees and put them into a clean file. You can then run it again without the date and time – which will pick up all the employees who had not been processed at the time of the initial program termination – i.e. they would have no record on their BT table in their payroll results. Take care to enter the payroll area in both the “period” and “selection” options. Failing to enter the payroll area in the selection field will mean that everyone in a payroll area with the same period parameters as the one selected at the top will be processed – which is rather dangerous. ## Schemas and PCRs 1. Viewing the contents of any of the important tables during the payroll processing is very useful when trying to find the source of an error. In the schema, you can use the function “print” and the name of the internal table in the parameter column – for example it, ot, ort etc. Use the Operation “print” in the “cycle”, to view the head entry of the “it” for every loop of the cycle. 2. Wishing to stop the payroll processing with a break point. You can do so using the conventional method of setting “break points” in the ABAP debugger. Alternatively, you can insert a “BREAK” command in the schema at the point where you wish the program to stop. The corresponding ABAP will break at run-time. You don’t have to set up breakpoint in ABAP explicitly. When you reach the break, you can modify the table contents as is the case with the normal ABAP debugger. ## Basic Pay split with different currency and payment method **Scenario:** You would like an employee’s basic pay to be split into 2 or more parts – with each part defined against a different currency. You need to create more than one IT 0009 records – bank details with subtype ‘other banks’. Here you can specify the absolute amount or a percentage to pay out with a specified currency. ## Reversing Incorrectly paid amounts **Scenario:** You may find that a payroll user mistakenly enters P45 details for a re-hire. After running the payroll the CRT will have the P45 taxable pay and tax paid wage types in it. How can you clear these out of the CRT? Assign WTs E505 & E506 to IT 0015. You can then enter the reverse amounts for the affected employees. Make sure that these work in your version of the payroll schema, and that they cumulate the CRT or create wage types /505, /506 in the current RT and that these are updating CRT.Payroll Results – Averages over a Period You may have a requirement to produce a report that averages certain wage types over a number of periods. You could use the Wage Type Distribution (RPCLGV09) to give you results for the past xx pay periods. You could then load the output into Excel to get the averages. ## Basic Pay and Currencies You are trying to create a basic pay infotype for an employee and it is giving you a warning message “No currency could be determined for country grouping xx” You have already made the correct entry in table T510F ransaction Code: PE01 Human Resources Payroll Europe Great Britain Tools Maintenance Tools Schemas Double-clicking on a sub-schema will take you to the maintenance screen for that schema. Double-clicking on any of the rules (PCR’s) will take you to the rule editor. You can tell the difference between sub-schemas a rules by looking at the parameters. The name of the sub-schema can be found in the Par 1 column. The main schema generally calls all the different sub-schemas. The sub-schemas will then call the payroll rules. In most cases, when a rule is called, there will be parameters in the Par 2 or Par 3 columns. In the main, most sub-schemas are called by the “copy” command. Schemas, rules and features in SAP use the following line editor commands. This allows you to move, delete, copy and insert lines. All the commands are entered in the area used for the line numbers. Overwrite any of the numbers with the commands shown below. For the commands using 1 letter – hit the return key once you have entered the letter. For the commands using 2 letters – hit the return key after the first 2 letters have been entered or after both sets have been entered. The most commonly used commands are: | **Line Command** | **Description** | | **D** | Deletes a line | | **I** | Inserts a line | | **M** | Moves a line | | **C** | Copies a line | | **DD** | Indicates the start of a block to be deleted | | **DD** | Indicates the end of a block to be deleted | | **CC** | Indicates the start of a block to be copied | | **CC** | Indicates the end of a block to be copied | | **MM** | Indicates the start of a block to be moved | | **MM** | Indicates the end of a block to be moved | Once you have chosen the block to move or copy, you need to show where to move or copy it to in the schema. The following commands indicate where you can copy or move the lines to. | **Line Command** | **Description** | | **A** | Places the block after the chosen line | | **B** | Places the block before the chosen line | Remember when calling the PCR from the schema: GEN means that the wagetype is **** i.e. you haven’t specified one and NOAB means that it will look at any EE Sub-Grouping. If you want the rule to use specific wage types or groupings, then leave either blank. Use the print option and VAR (PAR 2) in the schema to output the variable table during processing. Position is very important for schemas. Look to see where a similar piece of processing has taken place. If in doubt, place the rule after the similar data has been read and processed. Commonly used Functions | **Function** | **Description** | | **PIT** | Process Input Table | | **PRT** | Process Results Table | | **COPY** | Calls a schema placed in PAR1. | | **BLOCK** | Defines the start and end of a nested node | | **IF/ELSE/ENDIF** | The schema is processed if the condition is fulfilled | | **Pxxx** | Processes the information held in infotype xxxx. | | **ACTIO** | Actio calls a PCR. It is processed, irrespective of whether the wage type exists or not. | Commonly used Parameters | **Parameter** | **Description** | | **GEN** | Process any wage type | | **9000** | Processes only wage type 9000 | | **NOAB** | Process for any EE sub-group groupings | | **1** | Processes the rule only for EE sub-group grouping of 1 | Payroll PCR’s **Transaction Code**: PE02 Menu Path: Human Resources Payroll Europe Great Britain Tools Maintenance Tools Rules Commonly used operations in payroll configuration | **Operation** | **Description** | | **\*** | This covers all the remaining entries not already specified. If you leave the line blank for the operation then the WT is dropped. Remember you always have to have an option for * in your PCR. | | **ADDCU** | Cumulates the wage type into the relevant cumulation (/101…) and valuation(/201…) wage types | | **ADDNA \*** | From the IT, Number and Amt are cumulated into the OT. Blank is OT whilst E refers to the RT. | | **ADDNA 4067** | Current Num and Amt are added in to wage type 4067. | | **ADDWSE9N03** | This operation is very similar to ADDWT. The only difference is that it writes the value to table V0 as well | | **ADDWSI\*** | Store the current wage type in the IT. | | **ADDWT \*** | Store wage type in IT/OT | | **ADDWT 1103** | All the current values for amt, num and rte are added to the values that are currently held in wt 1103 | | **ADDWT&T** | Adds the current wage type to the variable table as T – which can be used at a later stage | | **ADDWTA\*** | The values in the wage type are copied to the previous employer table VAG – called in the rules XDPI, XDPR & XDPT | | **ADDWTC\*** | The values in the current wage type are added into the CRT | | **ADDWTC/101** | The values in the current wage type are added into the CRT for the technical wage type /101 | | **ADDWTD\*** | The values in the current wage type are added into the Difference table DT | | **ADDWTD/551** | The values in the current wage type are added into the difference table DT for the technical wage type /551 | | **ADDWTD/APO** | Add the current wage type to the difference table (DT) | | **ADDWTE** | Store amount in Results Table (RT) – difference with line below | | **ADDWTE\*** | Add the current wage type to the results table RT | | **ADDWTE/101** | Add the current wage type to the results table as /101 | | **ADDWTH/201** | Add the current wage type to the old results table (ORT) as wage type /201 | | **ADDWTI\*** | Add the current wage type to the input table IT | | **ADDWTI/101** | The values in the current wage type are added into the input table IT for the technical wage type /101 | | **ADDWTL\*** | Add the current wage type to the results table last payroll (LRT) | | **ADDWTN** | Used in XLON | | **ADDWTN/LRP** | (Loans – XLON) | | **ADDWTW** | Add the current wage type to the wage maintenance table | | **AMT- 9023** | Subtract amount field from wage type 9023 from Table IT (if wage type 9023 is available.) | | **AMT%33.33** | Multiply the amount by 33.33% | | **AMT%KSAPRO** | Multiply the amount by the value SAPRO held in table T511k | | **AMT-& T** | Amount minus the value held in variable T | | **AMT\*-1** | Amount multiplied by negative 1 | | **AMT\*12** | Multiply amount by 12 | | **AMT\*KGENAU** | Multiply the amount by the constant GENAU held in table T511k. GENAU is used to factor up by 4 or 5 factors of 10 to avoid the issue of errors caused by rounding. | | **AMT-.04** | Subtract 0.4 from the amount field | | **AMT/2** | Divide the amount by 2 | | **AMT/KGENAU** | Divide the amount by the factor GENAU held in the constants table T511k | | **AMT/KPKWPR** | Amount divided by the constant PKWRP held in table T511K | | **AMT/KZF001** | Amount is divided by constant ZF001 from table T511K | | **AMT? \*** | Compare the value held in the amount field for all wage types | | **AMT? /GPY** | Compare the value held in the amount field for wage type /GPY | | **AMT?& ZAPR** | Compare the value held in the amount field against the constant ZAPR | | **AMT?0** | Compare the value held in the amount field against 0 | | **AMT?E /167** | Compare the amount against the value of the amount held in the results table RT for wage type /167 | | **AMT?IGRUEB** | Compare the current amount against the limit held for the bank transfer | | **AMT+ /564** | Add the amount from wage type /564 from the IT | | **AMT+ 0001** | Add amount field from wage type 0001 from Table IT (if wage type 0001 is available.) | | **AMT+ 9013** | Add amount field from wage type 9013 from Table IT (if wage type 9013 is available.) | | **AMT+& ZSAP** | Add the value held in the variable ZSAP to the amount for the current wage type being processed | | **AMT+E 910B** | Add the current amount to the RT and place in wage type 910B | For customers using SAP payscales to maintain the Basic Pay information on employee records, there are at least 2 ways to update this information after a payscale review which results in changes to the amounuts. One is the lengthy manipulation of individual or multiple entries directly in the payscale table T510. The other, discussed here, is through the use of the SAP standard Payscale Update program RPU51000.prerequisites **access to create transports:** since this program is run in the development system and when the changes are saved, an SAP customizing transport is created, the person carrying out the changes must have authority within their SAP profile to create customizing transports. This access would normally be required anyway if the payscales were being updated via direct maintenance of table T510. **payscale structure is known** as there is no direct prior reference to the payscale structure, other than through the drop down lists on the selection screen (see image below), it is important that the payscale structure is known beforehand to ensure all relevant changes to groups and levels are carried out correctly.selection screen * ![sap hcm payroll](data:image/gif,GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF% FF%21%F9%04%01%00%00%00%00%2C%00%00%00%00%01%00%01%00%00%02%01D%00%3B) * sap hcm payroll The fields on the SAP standard selection screen shown above are fairly intuitive and allow for the updating of single entries or ranges. N.B. check out the settings for your organisation in T503 to confirm the correct grouping for CAP In the example above, an increase of 10% is to be made on the 3rd level ADMIN payscale within payscale type and area GR:04. The rounding will then be applied as per the normal roundup or down to 2 decimal places, before the increase is applied. There are options to specify rounding increments, as well as restrict the resulting increase to maximum or minimum limits.output ![payroll](data:image/gif,GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF%FF%21%F9%04% 01%00%00%00%00%2C%00%00%00%00%01%00%01%00%00%02%01D%00%3B) payroll The output confirms the old entry and the 2 new entries -the old one has automatically been delimited based on the date provided for the increase. This display can be filtered using the buttons at the top of the screen to display old payscalesor display new payscales. If the values shown are not correct -due to rounding or other reasons, simply go back to the selection screen and update the fields as required then re- run. When the output is correct, clicking on the save new payscales will update T510 with the changes. ![payroll sap](data:image/gif,GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF%FF%21%F9% 04%01%00%00%00%00%2C%00%00%00%00%01%00%01%00%00%02%01D%00%3B) payroll sap The form editor includes certain validation. This validation precludes you from entering, for example, a field where it clashes with another field. To get around this, you can enter the fields directly on the tables holding the form entries ( table T512E/F etc). If there is a clash then the one will overwrite the other. If you wish to copy a SAP standard form that exists within client 000, you can do so using the menu path in the IMG: Forms Remuneration Statement Copy Standard Form If you wish to stop everyone from being able to modify the form, change the attributes to allow only a designated person to modify the form. Remember that when forms are placed in transport requests, it is the snapshot of the form, at that time that is saved. Be careful then, when more than one person is working on the form – especially when it comes to the order of the transports. When creating a new form, you will invariably copy another form which closely matches the desired form. Remember to look at the size of the form you are copying. You may be constrained later on – if you are wishing to increase the form area. If the table or field you wish to print on the payslip, is not available, then you can add the table entries to table T514K and the field entries to table T514N. You need to enter the table entry first and then the field entry. When setting up the windows for payments and deductions, use the entry **F2 to catch all the wage types with the setting of F2 on evaluation class 02. To show the text of a payroll area on the remuneration statement. In the HR Form editor, single fields sub-object, use table VERSC (header data from payroll results) and use table field ABKRS (payroll area). In the print options, ensure that 01 is in the conversion box to “replace key with text” **Copying a Standard Payslip** Whenever you wish to copy a SAP standard payslip Copy the standard form from client 000 to your client (transaction code PDF8). Copy the standard form you have copied to another form name (using the customer naming convention – starting with Z.) Never copy across country versions – always choose a standard form in your own country version. **Compress Payslip** Use the transaction code SPAD. Device formats – change Device type: your printer type Format : existing format (X_65_80 or another) EXECUTE Device formats copy to new device format Modify the printer initialization (escape sequences). **Payslip Display – Retro Amounts** You wish to show retro calculation payments separately on the same payslip or together with the current monthly amount Look at the front screen of the remuneration statement. Look at the different options offered at the bottom of the screen. **Page Numbers on a Payslip** You wish to display payslip page numbers. Create field “xrt-pagno” in individual fields (form editor) for page number of remuneration statement.No matter how well prepared you may be ahead of the Payroll deadline, or how tight your processes are, you will inevitably encounter issues that impede the running of Payroll. As your system evolves with new developments being added by Consultants/Analysts and by SAP themselves via OSS notes, small payroll errors will occur most periods. Luckily, 99% of these errors can be resolved very quickly when you know how. At Strategic Data Solutions, we are proud of our dedicated Payroll Support arm and this article lists a few of the more common issues experienced by our customers over the last couple of months. By no means definitive, this document will at least guide you in the right direction with regards to quickly resolving an issue that may be delaying the Payroll process. **Maternity Discrepancies** An employee taking Maternity Leave will be entitled to Statutory Maternity Pay ( SMP) at 90% of their average weekly earnings (for the first six weeks of Maternity). However, what if you notice that the payments are not correct? This is a common problem when the Maternity period is split – the first day of Maternity is not the first day of the period. Take our employee, Mrs Maternity. She is starting her Maternity period on the 19.04.2009( Sunday) and is entitled to £200.00 per week for the rest of April. The week of 19.04.2009 to 25.04.2009 is fine, she will receive £200.00. The last portion of April is not a full week. From the 26.04.2009 to 30.04.2009, she is entitled to 5 days OMP only and therefore £142.86 (5/7th) However, on your system she is receiving £200.00 for the first week as expected but an inflated amount of £160.00 for the last five days of the month. If she were to receive this, she’d technically be overpaid. The reason for this inflated figure is that you and SAP have different ideas as to what makes up a ‘week’. In the case above, SAP is only considering working days in the calculations. This is fine in most cases where the period neatly begins and ends on Monday or Friday but problematic when the period is split as above. The SAP calculation for Mrs Maternity looks like this: Sunday the 19th April is not a working day so is not payable. Monday the 20th to Friday the 24th account for 100% (5/5th) of the week so will pay £200. Saturday the 25th is non-payable. For the second week, again Sunday the 26th is not payable but Monday the 27th to Thursday 30th are and this accounts for 80% of the SAP week (4/5th). Therefore, 80% of £200 is paid for the partial week. This equals the £160. It all comes down to simple fractions – 4/5ths is more than 5/7ths and as such, the employee is unfairly benefiting and receiving slightly more pay than if the payments were being calculated based on Calendar days. **e-Filing Issues** By now, all of your Tax and NI data will have been filed successfully and you can relax knowing that you made it through another Year End. But wait, the HMRC don’t want you to get too comfortable so as of 06.04.2009 have introduced online,in-year filing for P45 and P46 starter information, as well as making it compulsory for you to send your leaver info via SAP also. It’s safe to say the introduction of the new functionality to you, the Payroll customer, has not been the smoothest of operations. However, it now seems like the corner has been turned and the in-year movements are working as they should. By far the biggest problem our clients encountered was around the P45 Leaver transaction and its integration with the new Starter program, RPUEF0_STARTER. This starter program was introduced to be used from 06.04.2009 and was not a required program before that date as it was assumed Payroll departments would continue to file paper starter notifications with the HMRC. The problem occurred when running the transaction PC00_M08_CP45 at the end of Payroll period. When the XML was generated in the live submission, only a few records were successfully processed with the vast majority of records failing with the error message “starter program not run for employee”. This created a ‘catch 22’ scenario – most employees were failing because the starter program had not been run when they started (this could be any date within the last 10 years or so) but then the starter program was only available from 06.04.2009 anyway so could not possibly have been utilized. Because SAP has yet to develop the Time Travel module, a simpler resolution was issued. If you experience the same error message when producing P45’s for leaver employees, you must download OSS note 1310431 and get an ABAP Developer to make the code changes relevant to your system. The changes occur in the P45 program and require either the deletion of the lines of code that generate the error or to change the error to a warning message (system dependant). **Negative Taxable Pay** Depending on the size of your payroll, it’s likely you will have an issue with employees with Negative Taxable Pay. SAP Payroll will not process an employee for whom the taxable pay for the period is less than zero. The taxable pay is held against Payroll wage type /121 and the most common reason for a negative /121 is when an employee is overpaid. Luckily, SAP provides a separate schema for processing employees with negative taxable pay – Schema ‘GRET’. This is SAP standard and will likely have been copied as a client version, most commonly named ‘ZRET’ or ‘9RET’. If an employee is failing payroll with the error message ‘Negative Taxable Pay /121’, always try the GRET schema and 9 times out of 10 the record will process and your payroll will now be error free. Unfortunately, GRET does have limitations. You will not be able to run an employee through GRET if the record needs to retroactively run across tax periods. This is a common occurrence around Year End. If your employee is paid for the entire period of March 2009 but then in April 2009 you receive notification that the employee left employment on the 10th March 2009, there is a clear overpayment for the period of 10th to 31st March 2009. This will need to be recovered in April 2009, the first period of the new tax year. Because you cannot utilise GRET in this situation, consider creating some wage types to be used in infotype 15 (Additional Payments) that will allow negative records to process by giving the erroneous employee enough extra taxable pay so that their /121 equals zero. Wage Types should be created to suit your business needs and there are several aspects to consider: Should the WT feed into total pay or net pay. Do you need to offset any additional taxable pay for EOY reporting? Does the WT constitute a loan and therefore is it subject to recovery? Once all of these have been considered, a solution can be delivered that you can apply to all future overpayments that span the tax year. **Payroll Completed** As above, this is by no means a guide to all the individual payroll issue you may encounter but may just put you on the path to resolving that one, stubborn payroll error that’s holding up the entire process. ## Wage type characteristics **Dates** Everyone knows how important dates are in SAP – wage types are no exception. You can hold different configuration for a wage type for specific date periods. Click on the > symbol to see whether there are more records for different date periods. SAP confusingly calls the start date “Start Time” and the end date “Exit”. **Amount** Minimum and maximum values – you can specify minimum and maximum values for a wage type. This is useful to stop input errors at source. Having meaningful values set here can prevent errors at the input stage rather than having to find them in your payroll exception reports or even at a later stage. The difficulty most customers find is that it is very hard to decide on what values to use for each instance. Our recommendation is to configure meaningful values for most of the wage types that are input manually. You might only prevent a few incorrect inputs of data, but it may well save your organisation a lot of money. **Add to total** Tick this indicator if you would like the value for this wage type to be included in the basic pay total for the employee. **Input combination** This controls what values are allowed at data entry – i.e. whether you have to enter an amount or you can enter either an amount or a number with units etc. There are 5 options for both amount and number and these are controlled separately for both. The help is very useful in these fields and won’t be repeated here. **Time Levelling and Time Sheet** **Basic hours** Defines whether the wage type is a wage type for basic hours or a bonus wage type. The indicator is used for time levelling. **Number / Unit** **Time Unit / Measurement** This allows you to stipulate the hours, months, years, shares etc If you have stipulated that the user is to enter units on the input combination, then you should choose one of the entries from the drop down. **Minimum and Maximum Number** This is the threshold value for minimum and maximum amount which can be entered for a wage type in the Basic payinfotype (0008). If you create or change a wage type in the Basic pay infotype (0008), the system checks the minimum value of a wage type against the created or changed value. If the value entered in the infotype exceeds the defined minimum value for the wage type, the system issues the relevant information message. **Indirect Valuation** **Indirect Evaluation Module** You can use the indirect evaluation module to output various default values for wage types on different infotypes. The most commonly used features are as follows: Sap Hcm Payroll Configuration **TARIF:** this method valuates according to the “collective agreement group and level” specifications you enter in the IMG. Wage types with TARIF will use the settings on the wage type and the values held in table T510 to populate the relevant value into the relevant infotype. There are 4 different module variants for TARIF – A, B, C and D. See the SAP help for more assistance.Sap Hcm Payroll Configuration **PRZNT:** this is used where you have a wage type being a constant percentage of another wage type and wish this to be shown on the infotype. The wage type in question and the wage type that the percentage is based upon (base WT), are all held in table T539J.Sap Hcm Payroll Configuration **ANSAL:** this is used in table T539J for the wage types which you would like to be accumulated and shown as Annual Salary on screen 2010 on infotype 0008 – Basic Pay.Sap Hcm Payroll Configuration **SUMME:** very similar to the ‘PRZNT’ module except that the value of the wage type to be evaluated indirectly is always the entire basic pay. There are different module variants, which can be viewed in more detail in the SAP help.Sap Hcm Payroll Configuration **CONST:** Module for constant valuation of wage types according to table T510K ( V_T510K view). The module variants are either blank, M or P. **Module Variant** – there are different module variants based on the different methods chosen. Please look at the SAP help using the F1 key. There are too many to list on this page. The help is not very detailed in this area – but fortunately there are other helpful documents within SAP in other areas. The best thing is to just have a go. If you are still stuck, then there are the traditional SAP help sites on the Web.Sap Hcm Payroll Configuration **Reduction Method** – there are a few different options here. The help documentation is fairly clear about how each method can be used.Sap Hcm Payroll Configuration **Rounding Type** – this is either A, B, C or blank (no rounding type used). The help documentation is fairly useful. **Rounding Divisor** – put in here whether you wish to round to the nearest 1 pence or cent or put it 100 if you wish to round to the nearest pound or dollar etc. **Rewritable** – you tick this checkbox if you want to allow the users to be able to overwrite any of the number, units or amounts that have been defaulted by indirect evaluation. Don’t tick if you wish to stop the user from overwriting anything. **Permissibility of wage types** This functionality is really useful if you wish to exclude users from using any wage types for a particular set of employees. For example you may have pensioners in your organisation who could only ever have 2 particular wage types. Configure your system so that they are in a particular employee subgroup grouping or personnel subarea grouping.Sap Hcm Payroll Configuration **Employee Subgroup groupings** This gives you the flexibility of allowing only certain groups of employee subgroups to be assigned certain wage types. The functionality used here means that you need to bear this in mind when determining what your employee subgroups are in your organisation. Sap Hcm Payroll Configuration **Personnel Subarea groupings** This gives you the flexibility of allowing only certain groups of personnel subareas to be assigned certain wage types. The functionality used here means that you need to bear this in mind when determining what your personnel subareas are in your organisation. Sap Hcm Payroll Configuration For each wage type in the table holding the “permissibility of wage types” (T511), you will see options to enter values under ESG groupings and PSA groupings. The values start from 0 to 9 which means that you have 10 possible ESG and PSA groupings. The options are either blank (wage type not permissible), 1 (wage type is permissible) or 2 (wage type is permissible – with a warning being generated).Sap Hcm Payroll Configuration You need to have a 1 in both the ESG and PSA grouping for an employee’s grouping for the employee to be allowed to use that particular wage type.Sap Hcm Payroll Configuration **Direct verses Indirect Evaluation** **Wage type defaults** **Wage type constants** Wage type constants can be held in various different tables. Table T511K is used to hold payroll constants which are used during the processing of payroll. These won’t be seen on an employee’s record on the master data, but will get called during the payroll processing and used in the calculations.Sap Hcm Payroll Configuration Table T511P is also used to hold payroll constants used during payroll processing. Traditionally the difference related to T511K being used to hold amounts used as multipliers in payroll calculations and T511P was used for specific values brought in to the calculations. These days there is is not such a defined difference. Constants from T511P are called with the prefix P in payroll PCR’s, those from T511K are called with the prefix K. Table T539J is used in indirect evaluation in combination with the module chosen in the wage type characteristics held in table T511 for the wage type. Remember to check that you are using the same module in both tables – this will happen to you at some point.Sap Hcm Payroll Configuration Table T510J can be used for assigning a particular constant to a wage type. Using this table, the amount is not pulled into the employee’s record. The value gets called when you actually process payroll for the employee.Sap Hcm Payroll Configuration Table T510K can be used as well for wage types being assigned a constant where the indirect valuation in table T511 for the wage type is set to CONST. **Processing classes** Processing classes are used during payroll calculations. There are numerous processing classes and the principal ones should be known to you as a payroll consultant. Look at the SAP standard wage types starting with a letter to see which processing classes have been assigned in those wage types to get an idea of the most important ones. Sap Hcm Payroll Configuration The table which holds these items is V_512W_D. **Evaluation classes** Evaluation classes are used post-processing of payroll. Take a look at the SAP standard wage types to see the most important evaluation classes.Sap Hcm Payroll Configuration The table which holds these items is V_512W_D. **Cumulation classes** Cumulation classes are used in payroll processing. In simple terms they can be likened to buckets which amounts are added to. Each cumulation class corresponds to a specific technical wage type. The technical wage type is always a value of 100 more than the cumulation class. The cumulation class 1 (total gross) gets processed during payroll as /101. The cumulation class 11 (pensionable pay) gets processed during payroll as /111. **Creating new wage types** Remember that when creating a new wage type it is always better to copy an existing wage type which is very similar in characteristics to your new wage type. Using this method, will ensure that all the relevant table entries will get copied as well.Sap Hcm Payroll Configuration The wage type statement and distribution share a number of features. These will be mentioned in the section below. Any additional features specific to the wage type distribution – will be mentioned in the specific section.Wage Type Statement Use the Menu Path: HR – Payroll Accounting – Europe – GB – Subsequent Activities– Per Payroll Period – Lists/Statistics – Wage Type Statements Transaction code: SE38/SA38 with report: RPCLGA09 Alternatively, use the direct transaction code: PC00_M99_CLGA09 Note: There is no configuration for the Wage Type Statement and Distribution reports. However you can save variants for frequently used reports or for templates that can be used for ‘frequently requested information’.Sap Hcm Payroll Configuration Wage Type Statements are used for reporting on a single period, either on RT or CRT.Hints & Tips When running a Wage Type Statement against CRT, not all of the values in the ‘read cumulative results’ options window work – however ‘Y’ for Annual should always work. Sap Hcm Payroll Configuration When running a wage type statement, you have to enter a payroll area and period. Note: When you get to the selection screen, you will notice that the sort sequence has entries specified (highlighted green box below the yellow arrow). Go into the selection to remove the sort sequence. Save a variant for the report.Sap Hcm Payroll Configuration You will also notice that the a number of selection fields at the bottom part of the screen have been ticked. Take the ticks off to meet your individual requirements. The evaluation is limited to one country. Personnel numbers assigned to a different country are listed afterwards in the error log. Selection criteria and parameters Special Payroll Runs This refers to off-cycle payrolls that have been processed. The following options are allowed for the first selection field: A Bonus payment B Correction accounting C Manual check Regular payroll run The blank entry is defaulted by the program. The second box (selection field) is an indicator used to distinguish between different off-cycle payroll runs created on the same day. The third selection field allows you to enter a date, on which the off cycle payroll would have been run. “Wage type to be evaluated” parameter In this field, enter all wage types for which you want to carry out an evaluation. If you do not specify a wage type, the system selects them all. Please note that it is only possible to select wage types which are listed in the RT or CRT. “New page per wage type” parameter If you activate this parameter, a page break is inserted for each new wage type included in an individual report. This parameter is not used if a totals report is run. “Evaluation type” parameter You can carry out two types of evaluation: Individual evaluation Totals evaluation With the individual evaluation, the number and amount for each wage type are printed for each person. The totals evaluation only prints the selected wage types and totals for all employees selected. The totals evaluation is therefore a summary of the individual evaluation without the personnel numbers and employee names.Sap Hcm Payroll Configuration The “Reference period” field allows you to specify a payroll period as a comparison period for the selected reporting period. The comparison results and the absolute and relative differences are then included in the list printout. Note: This requires a list width of 132 characters – requiring you to choose an appropriate print format. “Sort sequence” pushbutton When sorting and evaluating data according to cost centres, the last work centre data (table WPBP) is relevant for the assignment of the wage types for an employee. The evaluation does not take place from the point of view of cost accounting, in other words, the report program does not consider cost distribution, or cost assignment. Only the employees last master cost centre is taken into account.Sap Hcm Payroll Configuration “Sort names” parameter When an individual evaluation is performed, the employee names are printed out, sorted in ascending order by personnel number. If you set a flag for this parameter, output is sorted on the employee’s last name. “Totals formation” parameter This parameter can be used to modify standard output after changing the sort criteria. The following options are possible: Total after a change of wage type Total after a change of personnel number Error messages and troubleshooting If you find incorrect values in the wage type statement, check the RT and CRT first. Check the amount assigned to the wage type in the RT or CRT, and check if there is a split in work centre data (table WPBP). The following system messages are intended to help you locate and solve errors: Message: Parameter “Sort: Field names” not supported You have tried to use the database parameter ‘Sort: Field names’. The wage type statement uses the parameter ‘Sort sequence’ instead. Please use the latter. Message: Different period modifiers You cannot perform evaluations for payroll areas with different period modifiers. Reselect the payroll areas which have the same payroll period modifiers. Look at table T549A to see the relationship between payroll period and period modifier.Sap Hcm Payroll Configuration Wage Type Distribution Use the Menu Path: HR – Payroll Accounting – Europe – GB – Subsequent Activities– Per Payroll Period – Lists/Statistics – Wage Type Distribution Transaction code: SE38/SA38 with report: RPCLGV09 Alternatively, use the direct transaction code: PC00_M99_CLGV09 Wage Type Distributions are used for reporting over a number of periods on the RT only.Selection criteria and parameters The wage type distribution uses a date selection period rather than a specific payroll period. This allows you to enter a period which incorporates more than one payroll period. The date is read from table 549S. The value in the field “Date ID” is used to check against table T549S To qualify for Statutory Sick Pay, an employee must: be sick for at least 4 or more days in a row – this can include weekends and bank holidays. These 4 days are called the Period of Incapacity for Work. earn, before tax and National Insurance, an average of £95.00 a week, i.e. the Lower Earnings Limit for National Insurance Contributions. An employee’s average weekly earnings for sickness (AWES) is calculated by taking the average gross taxable pay over the 8 week period before the sickness began. This 8 week period is known as the qualifying period and may vary slightly depending on whether you are paid weekly or monthly, or at other intervals. If you have been sick for two spells or more of at least 4 days in a row with 8 weeks or less between them, they will be counted as one Period of Incapacity for Work, in other words, waiting days will not be served for the second period of sickness. SSP currently pays £79.15 per week for 28 weeks.SSP calculations within GBSXP Using GBSXP, in the standard UK payroll schema, SAP is able to calculate an employee, s entitlement to Statutory Sick Pay based on the above rules. When calculating a employee’s entitlement to SSP, the first calculation made within GBSXP is to determine the dates of the relevant qualifying period for the employee, based on the dates of the sickness entered in infotype 2001. ![sap payroll](data:image/gif,GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF%FF%21%F9% 04%01%00%00%00%00%2C%00%00%00%00%01%00%01%00%00%02%01D%00%3B) sap payroll SAP then interrogates any payroll results it has previously calculated for the employee that fall within the 8 week qualifying period and specifically looks at the values that have been stored for average bases /212 and /213. By looking at these values, SAP is able to calculate the employee’s average weekly earnings for sickness. When configuring SAP to correctly calculate the average weekly earnings, each taxable wage type that an employee can receive within the qualifying period must be assigned to either valuation basis /212 or /213. A wage type is assigned to /212 if its value is directly related to an employee’s rate of pay, e.g. Overtime, Basic pay, etc. A wage type is assigned to /213 if it is not directly related to an employee’s rate of pay, e.g. First Aid Allowance, Company Bonus, etc. Each taxable wage type must feed into one of these valuation bases, so when these valuation bases are summed together the result is the total gross taxable pay that an employee received. By looking at the values held for valuation bases /212 and /213 in the payroll results that fall within the qualifying period, SAP calculates the employee’s AWES and determines whether they are eligible to receive SSP. ![payroll](data:image/gif,GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF%FF%21%F9%04% 01%00%00%00%00%2C%00%00%00%00%01%00%01%00%00%02%01D%00%3B) payroll Once the AWES has been calculated, GBSXP then calculates how much SSP the employee is entitled to on a daily basis, based on the length of the absence and whether there has previously been another absence of more than 4 days within 8 weeks. ![sap hcm payroll](data:image/gif,GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF%FF% 21%F9%04%01%00%00%00%00%2C%00%00%00%00%01%00%01%00%00%02%01D%00%3B) sap hcm payroll The next step within GBSXP is to add in any Occupational Sick Pay that is due to the employee. ![sap payroll](data:image/gif,GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF%FF%21%F9% 04%01%00%00%00%00%2C%00%00%00%00%01%00%01%00%00%02%01D%00%3B) sap payroll The SSP then needs to be offset against the OSP. SAP makes a decision on how to perform this offset by interrogating feature GOFFS. In this case the OSP is to be minimised, in other words the OSP is to be reduced by the whole amount of SSP. ![sap](data:image/gif,GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF%FF%21%F9%04%01% 00%00%00%00%2C%00%00%00%00%01%00%01%00%00%02%01D%00%3B) sap Here the Paid OSP Deduction for each day is the same as Paid SSP. At this point, SAP makes the distinction between Paid SSP and Paid SSP (Optional) and this distinction leads to 2 separate wage types being generated, SSPP (Paid SSP) and SSPO (Paid SSP (Optional)).Sap Hcm Payroll Configuration Paid SSP is generated when there is not enough OSP is to cover the statutory payments due to the employee. Paid SSP (Optional) is generated when the OSP is already more than the statutory payments due to the employee. Both these wagetypes, SSPP and SSPO, have been set to print control for payments in evaluation class 2, so they will both appear in the standard payslip. /SPY is a cumulation of these wagetypes and can be used to print on the payslip, alternatively a customer wagetype, 9SSP for example, can be made using a PCR to avoid making unnecessary changes to SAP standard wagetypes.SSP exceptions If the absence is too short to qualify for SSP, this warning message will appear when payroll is run for the employee. ![payroll](data:image/gif,GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF%FF%21%F9%04% 01%00%00%00%00%2C%00%00%00%00%01%00%01%00%00%02%01D%00%3B) payroll If the absence is too short to qualify for SSP, this warning message will appear when payroll is run for the employee. ![payroll](data:image/gif,GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF%FF%21%F9%04% 01%00%00%00%00%2C%00%00%00%00%01%00%01%00%00%02%01D%00%3B) payroll HR Support Packs The Support Packs issued by SAP each February contain the new values for SSP rates. These can be seen in the IMG by following the menu path: Payroll Payroll: Great Britain Statutory and Occupational Absences Statutory Absence: SSP Display SSP Rates remember that these values cannot be changed manuallySSP Calculations across Go Live date When historical absence data is loaded as part of go live, SAP needs to be able to read this data without actually retro’ing back past the go live date, so that it knows whether the employee has exhausted their right to SSP, or if they have had an absence within the 8 week qualifying period. To enable SAP to do this, transaction PC00_M08_CONV needs to run for every employee who has an absence history. This report fills in table NCALE with the SxP history( it must be run for every statutory absence) for each employee and is used by SAP to calculate any further entitlements. Transaction PC00_M08_CONV also fills NCALE with any occupational entitlements that the employee may have used up from their occupational absence schemes. ![payroll](data:image/gif,GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF%FF%21%F9%04% 01%00%00%00%00%2C%00%00%00%00%01%00%01%00%00%02%01D%00%3B) payroll SxP Calendar The SxP calendar, PC00_M08_SxP is a very useful tool when querying why an employee has been paid a certain amount of SxP. The calendar shows how SAP has classified each day that the employee was absent for – e.g. whether it was a waiting day, a non-working day or a paid SSP day. ![payroll](data:image/gif,GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF%FF%21%F9%04% 01%00%00%00%00%2C%00%00%00%00%01%00%01%00%00%02%01D%00%3B) payroll Making a backup of the SAP system table T512W (‘Wage Type Valuation’), is recommended prior to the implementation of a new R/3 HR Support Package. Since the table has delivery class E, this means that all wage types within this table which are defined within the SAP namespace will be subject to change by the import of an R/3 HR Support Package. Any such changes are applied to all clients. Many customers find it necessary to make customizing changes to wage types within the SAP namespace in this table. Any such changes are overwritten with the implementation of a new R/3 HR Support Package. Making a back up copy of table T512W enables any customizing changes to be re-imported into SAP once the Support Packs have been applied. A back up of this table could also be taken in instances where significant changes are to be made to the wagetypes within the SAP system table T512W and a failsafe is required to restore the configuration back to previous settings.Making a Backup **Transaction:** SA38 **Program: RPU12W0S** The SAP standard program “Save/Reload a Backup Version of Table T512W” is used to create a backup copy of the wage types from table T512W. The program makes a copy of the table into the SAP system table T512B. This copy can then be reloaded back into T512W once the upgrade or changes are complete. ![sap hcm payroll](data:image/gif,GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF%FF% 21%F9%04%01%00%00%00%00%2C%00%00%00%00%01%00%01%00%00%02%01D%00%3B) sap hcm payroll If saved successfully, you will see the following screen message and the table will have been backed up to table T510B as indicated: ![sap hcm payroll](data:image/gif,GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF%FF% 21%F9%04%01%00%00%00%00%2C%00%00%00%00%01%00%01%00%00%02%01D%00%3B) sap hcm payroll The program can also be used to delete previously saved backup copies.Reloading a Backup **Transaction: SA38** **Program: RPU12W0S** This SAP standard program is used to reload a previously saved backup copy of the wage types from table T512B to table T512W. The program only reloads the wage types from table T512B that are also available in table T512W. N.B. Since you no longer need wage types that are deleted with an HR Support Package or whose validity end date is changed in table T512W, you cannot reload these wage types from table T512B.** Features** You can reload the entire backup copy. To do so, select all the indicators on the selection screen.You can choose to reload only the following parts of the backup copy:Specific or all processing classesSpecific or all cumulationsSpecific or all evaluation classesAll valuation basesAll average valuation bases ![sap hcm payroll](data:image/gif,GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF%FF% 21%F9%04%01%00%00%00%00%2C%00%00%00%00%01%00%01%00%00%02%01D%00%3B) sap hcm payroll Once executed, the following screen shows how many items are copied back and how many elements have been changed since the HRSP update: ![sap hcm payroll](data:image/gif,GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF%FF% 21%F9%04%01%00%00%00%00%2C%00%00%00%00%01%00%01%00%00%02%01D%00%3B) sap hcm payroll Purpose and use There are two main ways to expand a Payroll or Time Schema and each has advantages and disadvantages over the other. One is to run the programs for at least one individual with the Log Display option selected. The other is through transaction RPDASC00 which allows for the option of ‘exploding’ the schemas down as far as individual steps within a PCR. Expanding or exploding a schema can be extremely useful in route- causing issues or locating configuration which may need to be copied or maintained. Application **RPDASC00** The main difference with Displaying the Log of a payroll or time processing, is that RPDASC00 explodes the entire schema (to whatever level is chosen) -not just the part relevant to a particular employee. This is particularly useful in locating such things as wagetypes and PCRs which will not necessarily have been processed. Layout also differs being more the traditional table view format rather than the tree view format presented by the Display Log. However, since this is an expansion of the whole schema, there is exact reference to line numbers and sub schemas (excluding any lines which have been commented out), making location and editing of a particular point within the schema easier. If the options are selected such that all schemas and calculation rules are expanded, a search for (e.g.) a particular wagetype will return every possible occurrence of that wagetype within the schema. This allows tracking of every stage of processing and may help to reveal errors in PCRs, configuration which can be duplicated and modified, etc. The disadvantage of this way of expanding the schemas is that any wagetypes which are not processed within the schema but are just read in and posted to a table, to the RT for instance, will not be found. Usage Many companies have the need to make payments direct from employees’ salary to a third party company (e.g. charitable donations, medical insurance payments). There are two main ways to do this within SAP Payroll. One is to make the deduction through the payroll process and assign the amount to a specific GL code. This is then transferred to FI and the payment is made to a vendor account. A more direct process, providing that the third party account details are known, is to use the SAP standard ‘External Transfers’ infotype (0011) Process **IMG:** Personnel Management Personnel Administration Payroll Data External Transfers The first step is to define the wagetype that will be used on IT0011 to record the payments. Within the SAP standard payroll schema, these wagetypes are then processed within the “Gross to Net processing (Great Britain)” subschema GNT0, via the “Processing request for external transfers” function P0011 and “External bank transfers – International( read infotype 0011)” calculation rule X055. N.B. External Transfers are not, as standard, processed in retro. Once the wagetype has been set up, a Payee Key is required to connect the amounts being processed with the correct Bank Key and Account number. For each external account to which payments are to be made, a separate Payee Key must be defined. If the payments are to be made as part of the normal BACS run, payment method should be indicated as ‘E’ BACS ![sap hcm payroll](data:image/gif,GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF%FF% 21%F9%04%01%00%00%00%00%2C%00%00%00%00%01%00%01%00%00%02%01D%00%3B) sap hcm payroll The wage type is then entered using the SAP standard External Transfers infotype( 0011), with the amount that is to be paid over and the correct Payee Key. The account details will be automatically populated from the entries made previously: ![sap hcm payroll](data:image/gif,GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF%FF% 21%F9%04%01%00%00%00%00%2C%00%00%00%00%01%00%01%00%00%02%01D%00%3B) sap hcm payroll When payroll is run, external payments that have been processed as BACS, are shown as separate entries in the BT table of the payroll results: ![sap hcm payroll](data:image/gif,GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF%FF% 21%F9%04%01%00%00%00%00%2C%00%00%00%00%01%00%01%00%00%02%01D%00%3B) sap hcm payroll The details of the account to which the payment is to be made, can be seen in the BACS file: ![sap hcm payroll](data:image/gif,GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF%FF% 21%F9%04%01%00%00%00%00%2C%00%00%00%00%01%00%01%00%00%02%01D%00%3B) sap hcm payroll As part of the changes to Statutory Maternity Pay brought in by the government, employees on maternity leave were given the right to be able to return to work for up to 10 days without this affecting their SMP payments. Previously, an employee who had undertaken any work during their Normal Maternity Leave would have forfeited any SMP for that whole week, however it was decided that in order for employees to ‘keep in touch’ with their colleagues and employers that this should be changed. If an employee utilises all 10 of their available KIT days during their Maternity leave, then they will lose the right for any Statutory Maternity Pay for the whole week for any subsequent days that they work. KIT days are not compulsory and must be agreed upon by both the employee and the employer. A KIT day can consist of any type of work, be it simply a meeting or a whole day’s normal work, however any day in which work is undertaken, even if it is only for half an hour, counts as one whole KIT day. Employees should be paid for KIT days. However, it is up to the discretion of the employer how this pay should be calculated. The employee should know how much pay they are to receive before taking a KIT day. The SAP standard solution for KIT days treats them as absences; this can cause difficulties when entering KIT days because a collision occurs between the employee’s maternity leave and their KIT day. The maternity leave needs to be delimited the day before the KIT day begins and restarted the day after the KIT day ends. When doing this, it is essential to check that the maternity leave is not treated as two separate absences, to ensure this does not happen the maternity leave needs to have 20 ‘linking days’ specified in table T5GPBS21 (the view is V_T5GPBS21). When entering a KIT day onto SAP, an employee’s SMP will remain unaffected, however any Occupational Maternity Pay they may be entitled to during this period will be affected. When a KIT day is entered, SAP does not consider this as a day on which OMP should be paid and as such will not reduce the entitlement for this day, so when the maternity leave restarts after the KIT day, the employee’s OMP entitlement will be the same as it was before the KIT day. This means that the OMP and SMP payments will then be out of synch. i.e. If an employee is entitled to 39 weeks SMP and 39 weeks OMP and takes 6 KIT days during this period, then their OMP will end 6 days after their SMP. The SAP standard solution for KIT days does not allow for hours to be used for calculation of pay; it will only pay a full day’s remuneration. SAP will use the wage types that the employee would usually earn were they not on maternity leave to pay the employee for a KIT day instead of using OMP ( e.g. Wage Type 1000, Basic Pay ) any allowances in infotype0014 will also be paid for KIT days. When calculating the weekly offset between OMP and SMP, SAP classes all the pay earned on the KIT day as OMP **For Example:** An employee, whose normal weekly wage is £350.00, receiving Lower Rate SMP and 50% Occupational Maternity Pay would receive; **SMP £124.88** **OMP £175.00** No OMP offset would be needed, because the total gross for the week is not more than the total gross for a normal working week. The same employee, if they were to undertake 2 KIT days in a week would receive; **SMP £124.88** **OMP £175.00** **KIT days £100 (2 days @ £50)** **OMP offset = (SMP + OMP + KIT days) – Normal Gross** **= 124.88 + 175 + 100 – 350** = £49.88 **Therefore the OMP Paid would be: 175 – 49.88 = £125.12.** NB: With this new calculation it is now possible to receive negative OMP for a Sunday– Saturday week, this was not previously the case. Overpayments dealt with by SAP can be complex to calculate and difficult to manage. The following document provides some useful tips and insights into how overpayments can be dealt with, both in the UK and in other country versions of SAP. SAP is a retroactive accounting system, i.e. it will automatically re-calculate an employee’s pay if any pay data on their personnel file is changed retrospectively. This means that SAP automatically calculates and reclaims overpayments unless there is a manual user intervention. The way that SAP deals with an overpayment depends on the amount and timing of the overpayment. If the net overpayment is small enough that it can be fully reclaimed through the employee’s normal wage, then SAP will automatically reclaim it. SAP will recalculate and refund an employee’s pension and tax contributions, providing the employee does not have an emergency tax code and the overpayment is being reclaimed in the same tax year, however SAP needs to be told to re-calculate the NI contributions. Using Infotype 0793, Payments Made in Error, an end user can instruct SAP which payments NI was deducted from in error, this Infotype then prompts SAP to re-calculate the NI for the relevant periods and refund any deductions due. Infotype 0793 can also now be used for multiple employments. If the net overpayment is more than the individual would have earned during a pay period, meaning the employee is left with a zero net pay after payroll has been run, then SAP generates wage type /561, ‘Claim’. This wage type is held in the results table and shows how much SAP calculates the employee still owes after the current period. During the next payroll run, wage type /561 is brought through by SAP and converted to wage type /563, ‘Claim from previous month’. When SAP reclaims an overpayment over a period of time, /561 always shows how much SAP calculates the employee still owes at the end of the period, so the amount of the wage type should reduce each month. The difference between /561 and /563 shows the net amount that SAP has reclaimed from the overpayment in a single month. When an overpayment crosses a tax year, SAP cannot refund any statutory deductions such as tax or NI, however it will try and reclaim the overpayment in full. This causes problems because the net overpayment that SAP calculates and hence tries to reclaim does not take into account the tax and NI owed to the employee. If an employee who has been overpaid wants to pay back the money in instalments over a period of time, then a net loan system needs to be put in place. By loaning the employee a net payment of the amount of the overpayment through Infotype 0015 on SAP and then reclaiming the net payment in instalments from Infotype 0014, an end user can prevent SAP from deducting the overpayment all in one period and enable the employee to pay back the overpayment over a more manageable period of time. The problem of an overpayment spanning across a tax year needs to be dealt with by resubmitting the end of yearfigures to the Inland Revenue and claiming a refund for any statutory deduction that has been overpaid. To ensure the employee repays the correct amount net, an end user needs to loan the net amount of the deductions incorrectly taken in the previous tax year through Infotype 0015, until they are received from the Inland Revenue. The tax year to date figures also need to be manually changed to ensure that the correct amount of tax is deducted from the current tax year. If you wish to know more about the above solution and best practice process in handling overpayments in your organisation, feel free to contact us. We can go through any of the above points in more detail and determine the optimal solution for your company. Following a payscale review, if the payscales have been modified then it will be necessary to update the employees’ Basic Pay records with the new amounts. SAP provides a standard report to do this (PRITRF00), aimed at the end user or administrator, which negates the need for data input via LSMW or manual updating of each infotype record.prerequisites , Sap Hcm Payroll Configuration payscales have been updated either by direct maintenance of T510 or using the SAP standard report RPU51000. authorisation to maintain the employee records to be updated. Authorisations with SAP may limit access to certain employee groups.Sap Hcm Payroll Configuration wage type is indirectly valuated for basic pay on IT0008. a new action / reason may be required for the pay increase event (see below). **selection** ![sap hcm payroll](data:image/gif,GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF%FF% 21%F9%04%01%00%00%00%00%2C%00%00%00%00%01%00%01%00%00%02%01D%00%3B) sap hcm payroll Whilst the selection screen initially appears quite daunting, the period and employee selection options offer the usual SAP HR reporting options for filtering the employees to whom the increase is to be applied.Sap Hcm Payroll Configuration The fields under Additional data relate closely to those used to update the payscales using RPU51000. They can be used to further filter the population to whom the increase is to be applied, and also enable the increase to be applied in batches. This may be useful of the SAP authorisations of the end user running the report prevent their maintaining certain employees, or if a certain group of employees are being maintained and therefore require their pay inceases to be processed at a different time.Sap Hcm Payroll Configuration The Date of standard pay increase forms the start date of the new IT0008 record which will be created. If this date falls before any changes in payscale amounts, and the new record is therefore the same as the old record, then no new record will be created and this will be indicated on the output screen.Sap Hcm Payroll Configuration Various options are available for the Subtype for Basic Pay infotype and this should be chosen in accordance with the settings in the customer’s system. The Event for std pay increase field requires an action (first 2 characters) and reason (last 2 characters) to be entered. the SAP standard entry for the UK is 1602. However, this may not work in all systems and it might be necessary to create a new customized action and reason. If this is necessary, the action must include at least IT0000, IT0001 and IT0008.Sap Hcm Payroll [Configuration](https://www.lorenzo-datasolutions.com/employee-central-payroll-content/) **output and batch input** Once the selections are correct and executed, the output shows the potential changes that will be made, along with any information or error messages. The batch input session must then be processed and the Basic Pay records will be updated. Existing records will be[ automatically ](https://www.lorenzo-datasolutions.com/sap-hr-personnel-administration/) delimited.