on 11-23-2011 12:48 AM
We are testing our Support pack / YELC implementation and have the following payroll error for around 100 employees:
"Some personnel assgmts can not have payroll run together."
I'm wondering if some of conversion records for these employees are causing a problem. Our go-live date was in 2007 but some of them have changes to the payroll area on different dates depending on which assignment you're looking at. In most cases the inconsistent payroll area is on a withdrawn assignment - so it should not be going through payroll, correct? I wouldn't think a withdrawn assignment should mattter, and I'm not sure why payroll is now looking back this far.
It is strange that the support pack implementation is all of a sudden prompting an error with these people, as they've been OK running through payroll for several years now.
Anyone have an idea as to what is causing this?
Hello,
Note 1274704 is a pilot note, that is the reason you can't able to see the note. Kindly raise a message stating you like to do the pilot testing for the note, your customer id will be included in the note so you can access it.
I am attaching the text of the note, except the coding part
"
Symptom
The system issues one of the following error messages of message class
HRPAY99_CE:
o 012 Person ID &1: Some personnel assgmts cannot have payroll run
separately
o 013 Person ID &1: Some personnel assgmts cannot have payroll run
together
Other terms
CE, MPSD, payroll area, change, check, HRPAY99_CE
Reason and Prerequisites
o You use the solution for concurrent employment (CE) or Multiple
Period Start Days (MPSD).
o You already had concurrently employed people in your legacy
system, and migrated these to your SAP system.
o You already used the solution for concurrent employment before
Note 1148671 was implemented in your system.
Solution
As there were recurring inconsistencies in payroll results due to
payroll area changes, Note 1148671 revised and completed the relevant
check.
Implement Notes 1148671, 1166292 and 1260915 as early as possible. If
required, you can implement them first in your test system and analyze
the incorrect persons there.
The following section describes the rules that must be complied with
when changing payroll areas. These rules already applied with the
implementation of the solution for concurrent employment even if they
were not described as clearly and in as detailed a manner as here, and
were not prevented by a check in some cases.
Adhering to the rules is required to comply with legal stipulations (for
example, tax assignment for the employer) and to prevent technical
Page 2
problems (for example, with retroactive accounting or cumulations).
Basic conditions:
(FC1) Payroll must always be run together for two assignments for which
payroll was run together once.
(FC2) Payroll must always be run independently for two assignments for
which payroll was run independently.
(FC3) The condition (FC2) must apply to the entire period as of the
start of the concurrent employment.
(FC4) At the start of the concurrent employment one assignment only can
be transferred for every person.
For the Multiple Period Start Days (MPSD) solution the following also
applies:
(FC5) You cannot change an assignment to another payroll area of the
payroll area group.
Explanation:
Ad (FC1), (FC2): These conditions are required as a change to the
payroll area can be viewed as an extensive assignment change. In this
case you must restrict the relevant assignments and create new
assignments with the new payroll area.
An exception to this is changing the payment period (specified in the
period modifier of the payroll area). In this case you can change all
assignments for a person with the affected payroll area simultaneously
to another payroll area (where the new payroll area must be identical to
the old payroll area with the exception of the period modifier).
These conditions apply regardless of the status (active, inactive) as a
retroactive status change may take place and inactive assignments may
also receive payroll results (due to retroactive accounting from an
active period, if a second assignment was active at the time).
Two assignments for the same employer must always have the same payroll
area (for MPSD payroll area group).
If the assignments are for various employers, they can also be in
different payroll areas. However, if they are in the same payroll area,
they are treated by the check as if they were for the same employer
(that is, (FC1) applies).
Ad (FC3): This is an additional restriction of (FC2) and ensures you
comply with (FC1).
Ad (FC4): All additional assignments for the same person must have a
hire date after the start of the concurrent employment. Assignments that
previously (in the legacy system) belonged to the same person must be
delimited and a new assignment must be created.
This condition is required to prevent problems when reading the last
payroll result.
Page 3
Ad (FC5): This condition is required to prevent gaps due to postponed
period data.
Payroll areas not relevant to payroll (T549A-CALCR = SPACE) are treated
in the same way as all other payroll areas (in particular, (FC1)
applies). If a payroll area like this is assigned to an assignment, no
payroll result should be created.
Workaround for inconsistencies
You must comply with the above conditions, as already mentioned, to
prevent inconsistencies in the future. However, for this reason it is
not possible to deliver the tasks described in the following section
(for the restriction of checks) in the Standard SAP System.
In addition, you must (and it is recommended for the purposes of
revision) make the changes as a modification. These changes should be
kept as limited as possible, which is why a previous analysis of the
reasons for the above messages is required for every individual person.
If it is possible to correct the master data, we obviously recommend you
do so.
For all inconsistencies discovered, set the earliest personal
retroactive accounting date (the field P0003-PRDAT) to a date after the
inconsistency, to avoid new inconsistencies for retroactive accounting.
For the analysis, proceed as follows:
o Determine the start date of the concurrent employment (CE start
date) with the view V_T77S0 for the group CCURE and the semantic
abbreviation PAYmm, where mm stands for your country.
o Note all payroll areas of the assignments with the relevant
intervals as follows (A = assignment; AA, BB, and so on = payroll
areas; / = CE start date);
A1: AA / AA BB
A2: / AA BB
A3: / CC
o Use transaction PC_PAYRESULT to determine for which intervals no
payroll results exist (highlighted by =):
A1: ==AA==/ AA BB
o Determine which of the above conditions (FC1) - (FC5) triggers an
error message and in which time interval this occurs.
The information listed in the following section is incomplete and will
be supplemented in a few days. However, you can start with the analysis
as described above and can also implement master data corrections (as
described under 2).
1. If the system issues an error message due to a current change of a
Page 4
payroll area, correct the master data. This is the actual task of
the check. You do not have to set P0003-PRDAT here.
A1: AA / AA BB =====
A2: / AA BB =CC=
(FC1) has not been complied with. A2 must remain in BB, or A1 must
change to CC.
2. If the system issues the error message due to a payroll area change,
in which there are no payroll results, correct the master data.
A1: AA / AA =BB= BB
A2: / AA ===== BB
If the payroll was run subsequently, the system issues the error
message in the master data maintenance (transaction PA30) that a
retroactive payroll area change is not permitted.
In this case, check again if NO payroll results exist for all
assignments for the period in which you want to correct the payroll
area.
Deactivate the check in the subroutine CHECK_BEFORE_ABRDT in the
include MP000100. (It is sufficient to turn the MESSAGE statement to
comment.)
Change the payroll area. (In the above example change A1 from =BB=
to =AA= or A2 from / AA ===== to / AA =BB= ; restrict the
records, so that intervals without payroll results only can be
changed.
Reactivate the check in the infotype 0001.
If the system issues the error message due to an inconsistency that
is before the CE start date (that is, due to (FC4)), delete all
assignments for the person with the exception of one assignment.
This is required, in particular, if you have already run productive
payrolls for the assignments affected before the CE start date. (The
payroll was run for these assignments individually and they cannot
be selected as belonging together in the system.)
If this is not possible, or you migrated the data from an external
system, ensure that there are no payroll results before the CE start
date. In this case, you can turn the check (FC4) to comment (either
for all persons if there are no payroll results before the CE start
date, as they have gone LIVE, or for individual persons if the
payroll was not run previously for all their assignments.
You must always set the earliest personal retroactive accounting
date at least to the CE start date.
"
With Regards,
S.Karthik
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello,
There is Basic condition which needs to be followed, otherwise you will receive the error
*****************************************************************************************************************
Basic conditions:
(FC1) Payroll must always be run together for two assignments for which
payroll was run together once.
(FC2) Payroll must always be run independently for two assignments for
which payroll was run independently.
(FC3) The condition (FC2) must apply to the entire period as of the
start of the concurrent employment.
(FC4) At the start of the concurrent employment one assignment only can
be transferred for every person.
Explanation:
Ad (FC1), (FC2): These conditions are required as a change to the
payroll area can be viewed as an extensive assignment change. In this
case you must restrict the relevant assignments and create new
assignments with the new payroll area.
An exception to this is changing the payment period (specified in the
period modifier of the payroll area). In this case you can change all
assignments for a person with the affected payroll area simultaneously
to another payroll area (where the new payroll area must be identical to
the old payroll area with the exception of the period modifier).
These conditions apply regardless of the status (active, inactive) as a
retroactive status change may take place and inactive assignments may
also receive payroll results (due to retroactive accounting from an
active period, if a second assignment was active at the time).
Two assignments for the same employer must always have the same payroll
area (for MPSD payroll area group).
If the assignments are for various employers, they can also be in
different payroll areas. However, if they are in the same payroll area,
they are treated by the check as if they were for the same employer
(that is, (FC1) applies).
Ad (FC3): This is an additional restriction of (FC2) and ensures you
comply with (FC1).
Ad (FC4): All additional assignments for the same person must have a
hire date after the start of the concurrent employment. Assignments that
previously (in the legacy system) belonged to the same person must be
delimited and a new assignment must be created.
This condition is required to prevent problems when reading the last
payroll result.
*****************************************************************************************************************
For more information on this review the note 1274704- CE: Inconsistencies due to changes of payroll area, which explains in detail about it.
With Regards,
S.Karthik
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi S Karthik,
I work with Judie and together we're trying to resolve this issue (I represent the Basis angle). Thank you for your clarifying explanations of the FCx checks. We were aware of the FC conditions, but this clarifies their purpose nicely. In fact, in our system we have deactivated FC4 on the advice of SAP Development Support two years ago when we first implemented Enhancement Pack 3 (we're now on EhP4), because we know that we have inconsistent master data that was converted from our legacy system. Unfortunately, this data is several years in the past, predating our conversion by some years (we converted in 2007), and of course payroll has been run (successfully) numerous times, so it is no longer possible to go back and edit the bad master data. Thus, we've just been trying to eliminate any condition checks or processing that might go back that far in time (there is no reason we would ever retro that far back today).
We were aware of the existence of Note 1274704, but we've never been able to see the Note -- it's not released to customers. We have asked SAP Customer Support to let us see the Note so we can determine if it's applicable, but that hasn't happened yet. Any chance you can tell us more about this Note, if you have a copy of the text?
Thanks,
Matt
User | Count |
---|---|
91 | |
7 | |
7 | |
4 | |
3 | |
3 | |
3 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.