Infotype 0077 and error Data record has grouping value "" instead of

[Former Member]

Dears,

Would you be able to help me on one topic:

In a global HCM solution which is in one productive client some of the countries are using infotype 0077 and this is working fine while performing Hirin action.

However if we do the IA planning action in another country (for creating expats) then I can't save infotype 0001 because i receive this message:

Data record 504538300077       9999123120120301000 has grouping value "" instead of "KZ"

Message no. PBAS_SERVICE039

Diagnosis

The data record with the key 504538300077       9999123120120301000 was saved with the grouping value "." The system, however, determined the grouping value "KZ."

After that i searched on the internet and I saw that there is a note resolving this problem 783499, however we would like to avoid maintaining some switches for Concurrent employment and we are not using that.

Possible solution:

I went to table V_T582G and saw that IT 0077 is assigned with grouping reason XMOL, and for testing i changed that to XNON and i was able to save infotype 0001 without any error messages.

My question is, what is the impact of changing for IT0077 in table V_T582G from XMOL to XNON, is there any impact on other functionalities? Because we would like to change from XMOL to XNON but we need a bigger picture what does it mean for that Infotype

Thank you very much for your reply.

Romano

[dsharmak · Accepted solution]

Hello Romano,

it is a setting in table T582G for IT0077. Table T582G says for which
assignments of a person data records should be kept the same/identical
("grouped").
In the SAP standard the corresponding setting for IT0077 is set to be
grouped for all assignments within the same country grouping (MOLGA) ->
XMOL. Example: infotype records should only be grouped for pernrs within
the same MOLGA, e.g.08. Assignments with another MOLGA (e.g. 10) are
not grouped. So, it is possible to have different infotype data for
different country groupings.

Suppose someone changed this setting from XMOL to XALL. And this means that all IT0077-records should be grouped independently from the country grouping. So, all IT0077-records have to be exactly the same for pernr 511988 and 854184.
The problem with this is that it´s not possible to group infotypes across the "country grouping boundaries" in case the infotype has a view
infotype for any country. Reason is that for country US (MOLGA 10)
IT077 has no view infotype whereas for country GB (MOLGA 08) IT0077 has
a secondary infotype (-> IT0998). Due to this fact IT0077-records can
never look the same for those different personnel numbers.

Technically the reason is as follows: pernrs 511988 and 854184 are
inconsistent regarding their T582G-settings and for that reason they
have to be repaired by means of RPUFIXDS. The report copies IT0077-data
from one pernr (511988) to the other (854184) but since data from pernr
511988 does not contain the necessary secondary view infotype data
(IT0998) the system raises an exception and dumps.

Report RPUFACEVIEKN and RPUPAV00 did not pick up any personnel number
since regarding those 2 reports all personnel numbers are already
consistent. The problem was no missing IT0998 for an existing pernr from
Great Britain but only with the data sharing mechanism with setting
T582G-GPRSN = 'XALL'. And this mechanism gets triggered with report
RPUFIXDS. I assume the short dump would also occur if you changed IT0077
for pernr 854184 via PA30.

So, in order to solve the issue kindly change setting T582G-GPRSN
("Grouping Reason for Personnel Assignments") from 'XALL' back to 'XMOL'
as it has been deliverd by SAP.

Though the explanation is Very Big, but you should not change this,Instead you should use the report RPUFIXDS.

Best Regards,

Deepak.

[Former Member · Accepted solution]

Hello Deepak,

Thank you for the explanation, I really appreciate it.

However, as I wrote, I am having this issue when XMOL is assigned to IT0077, not XALL. If I change from XMOL to XNON then i don't have this issue anymore.

Therefore I asked, is it bad to change from XMOL to XNON.

Thanks and regards,

Romano

[dsharmak · Accepted solution]

Hi Romano,

If you change the XMOL to XNON, then all IT0077-records should be grouped independently from the country grouping. It is not possible to group infotypes across the "country grouping boundaries" in case the infotype has a view. So data will be independent of Groupings and all. Also would suggest for Concurrent employment, those switches should be activated as per note 783499, Otherwise Concurrent employment functionality would not work correctly. For removing of your error you should run the report RPUFIXDS.

Best Regards,

Deepak..

[harishtk1 · Accepted solution]

As recommended above, do not change any of the settings in T582G.

Run RPUFUXDS to fix inconsistencies already identified

Set PC_UI CCURE to X in Table T77S0

and run following reports

RPUFACECPRFN, RPUFACEVIEKN

This will prevent inconsistences from happening again in the future.

Read Notes 783499,and 1447867 to get an understanding about this whole issue and its fix.

Hope this helps.

[Former Member · Accepted solution]

Dear Deepak and Harish, so you are suggesting not to change table T582G.

Our only concirn is if we activate this switch for concurrent employment, that it might impact other functionalities we have even if we don't use Concurrent employment.

Best regards,

Romano

[harishtk1 · Accepted solution]

Romano

All this switch does is to nesure that grouping field is populated for all PA infotypes which can potentially be sued for Concurrent Employment.Even if you do not have concurrent employment, you still need to activate this switch to enable processes that use this framework to work properly - and that means any ESS/MSS processes on portal.

In order to implement concurrent employemnt, in addition to this swirch there are other things you need to do.

I have never worked in concurrent employment, but I have always needed to activate this switch (since 2005 or thereabouts) in order to prevent inconsistencies in personal data.

IT 0077 in particular, along with IT 0002, 0006, 0009 etc do need to be copied over for multiple personal assignments or reference personnel numbers and therefore should not be changed in T582G.

Hope ths helps