Reply from Mr_Aziziyah on Jun 26 at 10:13 PM As I understand PY FI posting is that retro amounts are all brought into the current period.
As a standard accounting practice this would allow standard identification of values by GL account and would certainly help for reconciliation purposes.
The issue is that there are two in retro positions, one being before the D date and the other as payroll progresses through the periods there will be retro to a period after the D date so you will have the scenario of retro amounts for the same wage type going to different GL accounts. If you change the previous GL Setting to change the entries to the new GL settings would this lead to identification and differentiation issues of value assignment after each pay run.
Is this wage type the only one to post to the GL account and hence the assumption that the before date D GL account may no longer be required in the current period. If this is the case I would sit down with someone sensible from the finance section and explain the situation. It may be beneficial to keep the account open and handle with a manual journal entry.
How are the posting's transferred lump sum or the "q" option by Pernr values, may costing also be a consideration. These may be worth a thought also.
I would hazard to guess that creating a new wage type was not a consideration as the current wage type is being generated from multiple business rules coming from one or many interfaces with all sorts of scheduled and ad hoc loads.
I would consider staying with standard. If it is the case of a single wage type to post to the GL account, the retro before D Date can be controlled with the process with the retro posted values to the previous GL account. If many wage types post to the previous GL account this will need to be given consideration.
Worth considering is "can you" control the retro, employees will retro at different payroll periods so you will get the scatter effect of not knowing when this is completed and become uncontrollable, you may want to consider the retro date input effective as being no less than x periods.
I would avoid the RPCIPE work around, one day you might not be there.
I would be interested in what Mr Peter C would have on this, something quirky I'm sure.
I guess more questions than answers, sorry for that.
| | | ---------------Original Message---------------
From: Mostafa Pajouyan
Sent: Tuesday, June 10, 2014 1:33 AM
Subject: Handling Retroactive Posting to GL Accounts
Hi all,
This is a question to Payroll experts with experience on FI Posting.
Below the problem:
Wage Type X is currently assigned to GL Y (Through a Sym Account of course).
Wage Type X is to be assigned to GL Z from a given date (date D).
If there is a retro on wage type X before date D, I do not want it to be posted to GL Y, but I want it to be posted to GL Z.
One solution would be of course to duplicate your Symbolic Accounts.
Create a new set of Symbolic Accounts, that will be linked to GL Z.
This is fine of course, but implies duplicating all your Symbolic Accounts.
The other "solution" would be to assign the current symbolic account to GL Z.
But the problem with this is that if you have a retro, even without a change in wage type X, the previously posting to GLX will be reposted to GL Z fully. Which is not correct.
The third solution is of course to do a 'dirty' code in RCIPE00 user exists, and change the assignment to GL's from the D date. But this is really not ok to my opinion. Dirty option.
I have seen an OSS note 1039346 talking, sort of, about the subject. But nothing really clear in there.
The problem is so trivial, that I want to know if anyone has faced such situation, and if they have a better solution than the ones I think of.
Appreciating if you could share your solution, if you have had the same problem before.
Thanks! |
| Reply to this email to post your response. __.____._ |   _.____.__ |
