Announcement:
wanna exchange links? contact me at sapchatroom@gmail.com.
Posted by
Admin at
Reply from mostafa_pajouyan on Dec 2 at 5:45 AM Hi Imran,
You have 2 choices:
First choice to be tested is to:
Keep the same PERSG/PERSK. Only change the MOLGA
Keep the same WERKS/ BTRTL. Only change the MOLGA
This way, you do not need to change any Master Data.
Just duplicate all tables (All) where Molga was 99 to Molga 24.
In system point of view, its as if you are saying that you were under Molga 24 for the beginning.
Now, since HRPY_RGDIR has MOLGA as one of the values, it might be tricky.
But you will really only know the impact when testing. I believe its fine.
Since all your groupings remain the same, I have the feeling that it should be ok.
Second choice is to do a radical approach, by creating whole new sets of PERSG/PERSK, WERKS/ BTRTL.
Which will require you to reassign all your employees to these groupings at Go Live.
You still will have to duplicate all tables where Molga was 99 to Molga 24.
This solution is likely to be fine since it's a very standard and proven approach.
Its as if the employee changes a company for example.
But its worth trying the first option first.
Keep us posted with your findings.
I will be interested to know what has happened.
Good luck.
May I ask which company is this?
| | | ---------------Original Message---------------
From: Irfan Malik
Sent: Monday, December 02, 2013 5:04 AM
Subject: Implementation Strategy for MOLGA 99 change to 24 KSA
Hi Mostafa,
I had same thing in my mind but since T503 doesn't have date dependent entries therefore I doubt this change might jeopardize the current system.
Actually currently our basis consultant is working on activation of KSA local solution and this will be the first thing I will be testing in the system since this require very minimal efforts.
What I suspect is that, that with this approach i.e. after simply changing MOLGA 99 to 24 payroll might now allow me run retro runs since the payroll driver will be different than RPCALCX0 and also RT already available in the system was run under 99 cgrp schema and it may be possible that master data in the system would malfunction since as you know the whole configuration's dependancy is based on enterprise structure.
In addition, with this approach even we will have to make configurational changes in the groupings of Payroll/Time Management because as you know when you attempt to make changes in configuration nodes specially grouping, the system usually asks the country grouping and in this case 24 grouping would be empty.
As for your question, I do not intend to create new personnel areas if it would have been a vanilla implementation. The only reason I believe will be required to create new personnel areas exclusively will be because to retain master data so that no inconsistency occurs.
Thanks,
Muhammad Irfan |
| Reply to this email to post your response. __.____._ | In the Spotlight Become a blogger at Toolbox.com and share your expertise with the community. Start today.   _.____.__ |
