sapexperts _ how to reset infotype 0003 and address complex retroactive payroll accounting...

Search FAQ | Advisors | Log Out

Share | 0

Home > HR > Articles > How to Reset Infotype 0003 and Address ComplexRetroactive Payroll Accounting Requirements

How to Plan and Manage aSuccessful Payroll Parallel Run

by Owen McGivneyLead Consultant, HCMWorksApril 14, 2011SAPexperts/HRParallel runs are often the most demanding phase of anyHR and payroll implementation. Yet little formal advice isavailable and most users seem to learn throughexperience only. This general overview of the processshows that detailed planning, setting expectations, andgood communication are the keys to a successful parallelrun.

Key Concept

A payroll parallel run is the process of verifying that a newSAP payroll system is as good as (or better than) the legacypayroll system it is replacing. A set of employees and datais loaded onto the SAP payroll system so that it matches thelegacy payroll system. A payroll period that has alreadybeen run on the legacy payroll system and used to payemployees is then recreated on the new SAP payrollsystem. The payroll results are then compared between thetwo systems down to employee and pay element level. Byproving that the new payroll system matches the legacysystem, the business can have confidence that the newsystem has been configured well and will pay its employeescorrectly.

Most people who work with SAP systems are familiar with thetesting model necessary to get an enterprise-wide businesssystem up and running. Units of functionality are tested inisolation, and then grouped together by business transactionsas functional tests. A string of transactions are run together totest an end-to-end business scenario, and business scenariosare tested with their links to interfaces and external systemsas integration tests. Other test phases, for example,user-acceptance testing and stress testing, may also beincorporated. Most ERP modules, however, don’t have a testphase in which direct comparisons are made to the legacysystem that is being replaced (Figure 1). This is because the

0

J’aime 0

Our Community

BusinessObjectsExpert

subscribers canlogin here. >>

Have a question,comment, or idea?

BI Financials HR SCM CRM Solution Manager GRC ProjectManagement

IT

SAPexperts | How to Reset Infotype 0003 and Address Complex Retroa... http://sapexperts.wispubs.com/HR/Articles/How-to-Plan-and-Manage-...

1 sur 10 01.06.2012 13:21

Figure 1

Figurer 2

functionality differs so much in terms of scope, process,method, and data that comparisons between the SAP systemand the legacy system are impractical.

Typical ERP testing hierarchy

Payroll systems are an exception to this rule. The majority ofbusinesses and payroll departments are adamant that theywant the transition to any new payroll system to be seamless.In general the employees’ pay should stay the same, asshould the detailed breakdown of payments, deduction, taxes,and benefits. To prove that this is the case, an additionaltesting phase is used to compare employees’ pay on alike-for-like basis between the two systems. All the stepsnecessary to compare employees are collectively called thepayroll parallel run process (Figure 2).

Payroll testing hierarchy

Copyright © 2012. Wellesley Information Services. All Rights Reserved.

| Contact Us | Partners | FAQ | About Us

20 Carematrix Drive, Dedham, MA 02026USASales and Customer Service:1.781.751.8779Email:[email protected]

SAP and the SAP logo are trademarks orregistered trademarks of SAP AG in Germanyand several other countries.

About WISPublications &KnowledgebasesInsider LearningNetwork

SAPinsiderSeminars onDemandConferences andSeminarsSAP PRESS

News RoomSitemapPrivacyTerms and Conditions


2 sur 10 01.06.2012 13:21

If a parallel run isn’t carried out, it is very unlikely that the newsystem would pay employees correctly. Even the most skilledusers would be unable to foresee and test every possiblecombination of pay elements. Beyond this it’s possible (or evenlikely) that key elements of data migration, integration withinSAP to SAP ERP HCM, Financial Accounting (FI), ManagerialAccounting (CO), and to external systems will fail at somelevel. By working through a complete set of real payrollcalculations, the parallel run should flush out issues thatotherwise wouldn’t be identified using the usual testingmethodology.

Consequently the parallel run is an essential part of any payrollimplementation. It promotes confidence in the design andconfiguration of the new payroll system and is usually a keyinput into the go/no-go decision. Depending on the design andmethod of the parallel payroll process additional benefits mayinclude:

Validation of the data migrationVerification of the full payroll life cycleProvision of real data for integration within SAP (e.g.,FI/CO) and third-party systemsValidation of payslips, bank transfer files, and payrollreportsOpportunities for training the payroll department

The rest of this article gives more detail about how to design asuccessful parallel run and the key areas of focus.

Parallel Run Steps

It is good practice to carry out parallel runs over multiplepayroll periods. It is rarely possible to identify and resolve allconfiguration and data migration issues in one go; there arenormally enough changes to warrant successive parallel runson fresh data sets. So in general parallel runs will be carriedout for two or three different payroll periods.

The basic steps for carrying out a parallel run for one payrollperiod are shown in Figure 3.


3 sur 10 01.06.2012 13:21

Figure 3 One payroll period’s parallel runsteps

Steps 3 to 7 in this sequence are repeated until the successcriteria have been met.

Choosing the Parallel Run Periods

A typical payroll month is a good candidate for a parallel run;any month with an annual or periodic business activity whichadds complexity is less suitable. For example if a back-datedpay award occurs in July then ideally you wouldn’t want tochoose this as your first parallel run month. Things to look outfor are:

Company shutdowns and advance pay runsPay awards (any annual pay increases/pay scalechanges, especially if these involve back-datedchanges)Any significant organization change or mass employeecontractual changes

It’s not a case of avoiding these because the payroll systemcan’t cope, since these items should be tested independentlyelsewhere. It is simply a recognition that it’s worth minimizingsituations that increase the difficulty of the parallel runs withoutimproving the quality. Indeed once suitable parallel run periodshave been identified you should also look out for items that


4 sur 10 01.06.2012 13:21

aren’t incorporated during the selected period (e.g., bonusruns, public holidays, company days, and share awards). Youcan then modify the periods chosen or supplement the parallelruns with additional test cases in user-acceptance orintegration testing.

Loading Data for Parallel RunsParallel runs are normally carried out off-line during periodsthat have already been paid on the legacy system in order tofit in with the project timelines. For example, a parallel run onApril data may take place in August because this is the start ofthe parallel run phase. A snapshot of HR and payroll data istaken from the legacy payroll system and migrated to the SAPsystem. Let’s consider two different approaches to how thiscan be done:

Full automatic load: All employee HR and payroll data isextracted at the point in time immediately before payrollis run on the legacy system (the payroll run date). Thisdata is loaded into the SAP system using LSMW, batchinput session, or any other automated upload method.No manual data entry is required; however, changes topayroll data which took place over the course of thepayroll period may be missed. For example, anemployee who has a salary increase at some point inthe parallel run month may be loaded with either theiroriginal or their increased salary only, depending onwhether the change is effective from before or after thedate used for extraction. An employee who left thecompany partway through a month may be missedsince they were not active at the point the extractswere run. Consequently some additional method isrequired to pick up relevant transactional changes thattook place during the payroll period.Dual data entry: All basic employee data is extractedand loaded at the start of the payroll period. Anytransactional data (e.g., changes to pay anddeductions, tax codes, and new hires) is loadedmanually into SAP via direct entry of information by thepayroll department. There is a dual entry of data — alldata input on the legacy system is mirrored on the SAPsystem. Although this can be labor intensive, thismechanism captures the most errors as both thesystem and some SAP processes and transactions aretested. Practical methods of ensuring that data isentered equivalently on both systems must be devised.Hybrid or mixed approaches are also possible

Other key factors to consider are the technical capabilities ofthe legacy system, and whether the IT or payroll team havethe technical ability and resources to extract this data. It’s alsoworth pointing out that many payroll systems do not have theability to take snapshots retrospectively — they are only ableto produce a valid set of live data at the date of extraction. Ifthis is the case then, if possible, take a full copy of the legacypayroll database for each parallel run and store it untilrequired. If it’s not possible to store a copy of the legacypayroll database then the data must be extracted (e.g., into aset of spreadsheets) at the time the payroll was run on thelegacy system. The exact choice depends on the technicalcapabilities of the legacy system, cost, and legacy payrollresource availability. The potential pitfall with the second optionis that if any legacy extract is missed, lost, becomescorrupted, or is later discovered to be defective then it may be


5 sur 10 01.06.2012 13:21

impossible to recreate that data on the SAP system, whichmay jeopardize the parallel run.

Employee PopulationsThe employee population that is tested in each phase of theparallel run needs to be determined. It’s possible to parallelrun all employees, to choose a subset of employees randomly,to choose a subset according to business scenario (e.g.,employees in specific employee or pay-scale groupings, or onmaternity or sick leave), or to choose any combination ofthese three. There isn’t any single right method and the exactchoice depends on the size of the payroll population and howhomogenous (or payroll similar) they are. The employeepopulation chosen should be sufficiently large to giveconfidence that all potential issues have been discovered. Theresources, technical skills, and time available also have abearing.

From the point of view of the SAP system, the guiding principlehere is to identify and resolve all configuration issues as earlyas possible. If a partial employee population is chosen, thenfocus on the weakest areas of the payroll. These may includepart-period factoring for new hires; leavers and employeeswith unpaid absences; employees who have multiple costcenters, basic pay, and/or planned working time changes(known as wpbp splits) in the month; and statutory absenceprocessing (e.g, .parental-leave pay). The workshops,requirements gathering, and configuration phases should haveestablished where potential areas of difficulty lie. The worstsituation to be in is where the most complicated andintractable technical issues are discovered right at the end ofthe testing phase, as fixing these may cause unintentionalerrors in functionality that has previously been working.

Planning the Parallel Runs

Once the payroll periods have been chosen, further planning iscarried out to identify key dates and dependencies, such asrelevant cut-offs, pay dates, and interface runs. This should bedone jointly with the payroll department, as normally only theywill understand the complete flow of payroll data and anyaccompanying quirks or irregularities.

Table 1 shows a high-level parallel run plan. This outlines thepayroll periods that are being compared, the employeepopulation tested, and any additional testing in each phase.The plan shows that as the parallel run progresses, morefunctionality such as posting payroll costs to FICO, interfacesto third-party systems, production of bank transfer files, andreporting is also tested. In this example, based on the UK taxyear which starts in April, no cumulative values are required forthe first parallel run, but these are required for the twofollowing parallel runs.


6 sur 10 01.06.2012 13:21

Table 1

Table 2

High-level parallel run plan

Setting Successful Exit Criteria

Successful exit criteria must be established and agreed tobefore the parallel run starts (Table 2). The comparisonbetween the SAP system results and the legacy payroll resultsis normally carried out across a range of wage types (e.g.,gross pay elements, deductions, taxes and social insurance)to ensure that all payroll calculations are correct. However, forsuccess criteria it is normally sufficient to focus on employeenet pay as this figure needs to be communicated across thebusiness where only a headline figure may be appreciated. Amatch on net pay is defined as:

1) Both systems have the same net pay (or a difference withintolerance)

2) The SAP system is correct; the legacy system paidincorrectly.

3) An explainable variance (i.e., a difference due to differentcalculation methods)

Example of exit criteria for athree-month parallel run

The acceptable tolerance also needs to be established andagreed upon with the client (such as rounding issues andpossible currency conversion issues).

The type of issues to be resolved in each parallel run alsovaries; see Figure 4, below:


7 sur 10 01.06.2012 13:21

Fiugre 4 Relative proportion of errorsresolved in each parallel run

Parallel Run 1 typically highlights multiple data migrationerrors. Invalid field values, dates, format, or signs may still bepresent, or other more serious problems may only becomeapparent when data is processed through the payroll schema.There will also be a substantial number of configuration errorsrequiring changes to schemas, rules, wage types, and otherpayroll configuration. It’s also likely that whatever method isused to compare the SAP system results and the legacypayroll results will contain some mapping errors, and anamount of recalibration will be required here. Typically the rateof increase of matching employees will be high as there arelikely to be a number of simple configuration fixes that shouldcorrect a large number of employees. At the end of thisparallel run, around 85 percent of employee should match onnet pay.

Parallel Run 2 should start with a high percentage match asthere should be minimal data migration errors remaining. Mostof the time should be spent resolving configuration issues withpayroll.

By parallel Run 3, data migration and mapping errors shouldhave been eliminated and there should be minimalconfiguration errors remaining. While most companies wouldlike to exactly match net pay for 100 percent of all employees,this is generally not achievable due to data entry and timeconstraints. Often the final percent consists of heavilycorrected and adjusted employee pay records that wouldmatch if sufficient time were spent; however, on balance it isnot worth spending this time as no useful additional payrolltesting actually results. In the example case shown in Table 2,an exit criterion of 99 percent has been agreed upon.

Communication Plan


8 sur 10 01.06.2012 13:21

It is important to have a communication plan for parallel runs toensure that the process proceeds as smoothly as possible.Some key points at which the parallel run should be raisedare:

During bid and project preparation: The importance ofthe process should be stressed so that the requiredclient resources can be costed and facilitatedKick-off meetings: Should explain parallel testingconcept, the time frame, training schedules, andparticipant responsibilitiesParallel run testing meetings: To recap and review tasksand responsibilities before and during the parallel runphase

The communication plan (and planning in general) shouldadequately cover the fact that parallel runs generally cause alarge spike in the workload for everyone involved. It can bedifficult to resource within the payroll department as oftenthere are not enough employees to simultaneously run the(real) legacy payroll and work on the parallel run. Sometimesthis leads to working long days, nights, or weekends. If this isunavoidable it can be partly mitigated by giving as muchadvance warning as possible.

The communication plan should also be used to calibrateexpectations. It can be useful to clarify that the parallel runtests the payroll configuration (e.g., schemas, rules, wagetypes, and payroll functions) and not necessarily the entire setof HR and payroll processes or end-to-end integration.Occasionally a misconception arises that everything will bepicked up in the parallel run, whereas the truth is that,depending on the method of data migration and theworkarounds chosen, it is possible that the parallel run hasbypassed a whole set of fundamentals required at go-live.Examples are:

End-to-end HR and payroll processes are not tested(e.g., employees are uploaded to individual infotypes byLSMW, not by using the hiring action)User training and skills are not tested as data isuploaded using LSMW, not manuallyEnd-to-end integration with interfaces and third-partysystems are not tested since these may not be live atthe time the parallel run is carried outSAP user roles and authorizations are not tested as alldata is loaded by a single LSMW data migration user

In fact all these areas need to be covered by separate testingstreams and verified in their own right.

This misunderstanding can present itself at the end of asuccessful set of parallel runs. The client and even projectmanagers can take away the message that the system workswithout understanding the nuances of exactly what has andhasn’t been tested. This may lead to unrealistic ideas aboutthe volume and nature of faults expected during and aftergo-live and consequently the appropriate level of supportrequired.

If the parallel runs have not gone well, in some cases theclients or project managers may propose continuing to runboth systems in parallel after go-live. The idea is that this


9 sur 10 01.06.2012 13:21

would provide a safety net for the SAP payroll system, since itwould be possible to revert to the legacy system if required.This is normally a bad idea for the following reasons:

If there is a real risk the new payroll system couldunderperform, then it may not be ready to go liveanywayIt is practically impossible to ensure that identical dualentry of data will take place on both systems over anextended period of timeThe HR/payroll team data entry is doubled at a time ofalready high workloadAll SAP system training, change management, andcommunications become dilutedIt signifies a lack of confidence and undermines the newsystemEven if there are significant payroll issues, it is oftenadvantageous to resolve these issues quickly

Owen McGivneyOwen McGivney is the lead consultant atHCMWorks based in London, England. Hehas worked on implementing SAP HR andpayroll systems since 1998. Owen hasdelivered UK, Irish, and multinationalpayroll solutions for a wide range ofprivate- and public-sector clients. He has a

special interest in combining ABAP programming withconfiguration to create innovative and effective solutions.

To contact the author click here: Owen McGivney. If you havecomments about this article or HR Expert, or would like tosubmit an article idea, please contact the HR Expert editor.


10 sur 10 01.06.2012 13:21

sapexperts _ how to reset infotype 0003 and address complex retroactive payroll accounting...

Documents