cancel
Showing results for 
Search instead for 
Did you mean: 

CE Payroll Error: Some personnel assgmts can not have PY run together

Former Member
0 Kudos

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?

Accepted Solutions (0)

Answers (2)

Answers (2)

former_member182083
Active Contributor
0 Kudos

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

former_member182083
Active Contributor
0 Kudos

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

Matt_Fraser
Active Contributor
0 Kudos

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