Saudi Arabia Payroll Localization

[Former Member]

Hi Experts,

My client is using SAP since 2008 under country grouping 99 and now wants to use the KSA Payroll Localisation released by SAP under country grouping 24.

As a first step, We wanted to create new personal areas and assign that to Country grouping 24 so that with the help of a Personal Action, we could move the employees from 99 to 24 country grouping.

Now we are facing a challenge since the new personal area when assigned to the same company code, the country grouping can either remain as 99 or 24 for all personal areas to the same company code ie...when assigning 24 to the new personal area, the old personal areas linked to the same company code are also getting assigned to 24 which will affect our existing configuration.

Please advice the best way to implement the Localization without disturbing the old configurations.

Thanks

Jeffy

[Yamen_Zarnaji]

try to check the below link , as new there is ability to add selection period for personnel area and personnel sub area

  http://scn.sap.com/docs/DOC-49832

[Former Member]

Afraid that one will help inly on a cosmetic level, but not solve the funfpdamental problem. It can define personnel areas to be valid only in a certain period, but not change ccode assignment over time.

For sure you'll never ever be able to have personnel areas assigned to different country codes, but to the same company code. The SAP design just doesn't allow for that. Not at all.

The business reason behind that is that a company code represents an Independent acxounting unit and if you operate in two different countries each of them needs to be a legal unit with their own balance sheet and P&L. Of course you can consolidate them into one, but on the lower level they still need separate balance sheets.

SAP also doesn't really allow for a personnel number (pernr) to change country codes, unless you force it into the data and live with inconsistencies in past master data. To be clean on that would require using the personnelID in the Global Employee solution to link the two different pernrs.

In the last,  I've moved pernrs from 99 to their proper molgas by

- creating new company codes and Personnel areas with the right molga OR changed the molga, if it was the same for all PAs in one company code

- updating infotype 0001 accordingly into the past for the whole history, if PA or CC changed

- updating infotype 0003check fields ITBLD and VIEKN)

- update any other infotypes, where the change requires change in data (often: 0002, 0007, 0016)

- update payroll clusters, if they have had payroll before (hopefully not)

- of course set up config accordingly for the new groupings - making it the same as 99 as much as possible to minimise data changes explained above

THese data changes all need to happen directly in the database tables and cover the full history of records, so you really need to know,what you are doing and habe a good test environment (full copy with all data to be recreated several times, if necessary)

Please consider this as mentioning an option. Not a recommendation. I don't know your full context and particularly not the programming skills and data structure knowledge available.

best of luck

Sven

[Former Member]

Hi Sven

Thanks for the detailed response. We came to this conclusion that a change in Personal Number is inevitable unless we think of editing the Infotype 0003 field VIEKN.

You said you have done this activity in the past with inconsistencies in Master data. Could you tell a few examples on that. I would like to explore that option in detail and your experience will be very helpful on this.

Regards

Jefferson

[Former Member]

Hi Jeffy,

is you change Personnel Number - i.e. terminate employment and hire again, then there are no inconsitencies.

Inconsistencies occur, if you change personnel area etc in PA0001 and VIEKN in IT0003 accordingly. Then there are some infotypes, which may expect special data in country specific PAnnnn tables (most often in IT0002, but also seen in 0007, 0008, 0016, 2001). And then there's the config depending on the MOLGA or on the groupings in T001P, which  may lead to errors due to checks and obligatory fields in each dynpro.

You avoid the bulk of it, if you allign T001P and T588M for your new personnel areas and MOLGAs/VIEKNs with the old ones.

kind regards

Sven

[Former Member]

Hi Experts, any ideas or suggestions, please share

[Former Member]

Hi jeffy,

If you are changing a country grouping from 99 to 24 in with assignment to Personnel area and subarea, then its ok, but i think country grouping is also relevant to Company code also. So, please check the Company code assignment with country grouping with your FICO guys.

Hence a company code will also get changed in this kind of scenario.

Regards,

Jagdish

[Former Member]

That exactly is the problem. Since the system is already running in production live, getting a new company code is ruled out.

Is there any other way where we can bring the new personal areas to country grouping 24 while retaining the old personal areas to 99? The condition is both the personal areas should be assigned with the same company code.