ALE Data Transfer Issue--Needs Immediate Attention

[Former Member]

Hello Gurus

I am hoping somebody can guide me here--

We are on E-Rec 603 with seperated standlone e-rec system.

we have set up ALE Data transfer for object type P from ECC QA to E-Rec QA system but unfortunately the I-Doc is always gettign posted with status 52 ( application document not fully posted).

The infotypes 0000,0001,0002,0006 and 0105 are being transferred. The report HRALXYSNC refuses to recognise the 'P' object transferred and says=='data not found for search condition'.

We debugged HRALXSYNC and found that IT 0003 needs to be included but we tried transferring that too--however, the ALE still fails to transfer the data.

Not sure why the data transfer is not happening--what is the best alternative?

Would really reallly appreciate some light....!!

Thanks

Tania

[Former Member · Accepted solution]

Hi Tania:

So you go to ALE PERNR 123 in ECC -> An IDOC is generated and successfully passed to E-Rec. E-Rec attempts to post the IDOC for PERNR 123 and only partially posts, leaving the IDOC in status 52. Is that accurate?

If you're going into E-Rec and running HRALXSYNC you will never find any Employees. Systems other than ECC do not store the Person Object (P). They store the Central Person (CP).

So when you sent the IDOC from ECC to E-Rec, you either did or should have also sent a relationship from the P to the CP. That's the link used to re-connect everything in E-Rec.

In a nutshell, your Business Partners in E-Rec will be based upon Central Person, not Person. The object P doesn't exist in E-Rec. Try looking for Central Persons in HRALXSYNC. There's another issue at hand (which I address below), but depending on what error you're getting with your IDOCs, you may still be getting Central Persons in your E-Rec system.

That does still leave an unopened question though of why your IDOCs posted in status 52 in E-Rec. That means some of it worked, but some didn't. If you go into the status messages of the IDOC it should tell you why it failed to post X many segments. Let me know if you want any help with the error messages you find.

Thanks,

Chris

[Former Member · Accepted solution]

Thanks thanks, Chris for the immediate response.

Now I did go in and check the report HRALXSYNC --it picks up the CP but when i ran it shows nothing on the results page. I presume since the relation B 209 between P and CP is missing.

As per your solution, do I need to transfer the same from ECC to E-Rec?

Also, the following are the errors posted on the I-Doc with status 52.. It refuses to create 0003,0006 and 0105 :

Object 01 ,P ,00112323 does not exist: infotype 0105 cannot be created

Message no. 5-105

Diagnosis

You have tried to create infotype 0105 for plan version 01,object type P,object ID 00112323. However,the object does not exist.

PA objects exist if infotypes 0000, 0001, and 0003 have been created.

PB objects exist if infotypes 4000, 0001, and 0002 have been created.

PD objects exist if infotype 1000 has been created.

Procedure

If necessary, create the object manually together with its infotypes, or make a complete replica of it.

Object 01 ,P ,00112323 does not exist: infotype 0006 cannot be created

Message no. 5-105

Diagnosis

You have tried to create infotype 0006 for plan version 01,object type P,object ID 00112323. However,the object does not exist.

PA objects exist if infotypes 0000, 0001, and 0003 have been created.

PB objects exist if infotypes 4000, 0001, and 0002 have been created.

PD objects exist if infotype 1000 has been created.

Procedure

If necessary, create the object manually together with its infotypes, or make a complete replica of it.

Thanks

[romanweise · Accepted solution]

Hello Tania,

just to get sure here. In your initial post you wrote that you are using E-Recruiting EhP 3.

Up to EhP3 E-Recruiting uses an own implementation for processing IDocs to create internal candidates. Report HRALXSYNC is not part of this processing. Only with EhP 4 E-Recruiting switches to the standard HR-BP integration which includes using HRALXSYNC.

For EhP3 you have to distribute Infotypes 0000, 0001, 0002 and 0105 (Subtypes 0001 and 0010). Infotype 0006 is optional if you need the address for the internal candidates. With EhP4 this changes, Infotype 0006 gets mandatory (except in the I2B scenario where there is a workaround) and you have to distribute the P - CP relation.

You can find a description of the ALE settings for the different releases in note 997181 - but of course you can place additional questions here but therefore we need to be sure with the release you use.

Best Regrads

Roman

[Former Member · Accepted solution]

Hi Roman,,

Thanks for your reply--yes we are on Ehp3.

So what is the best way to convert employees into internal candidates in Ehp3? Do we not use HRALXSYNC then?

Would await your reply please.

Thanks

[romanweise · Accepted solution]

Hello Tania,

follow the settings in the "standalone" attachment to note 997181. It is a bit difficult too read as it mixes EhP3 and EhP4 chapters so you have to be a bit careful.

What is not described there but is important:

- you have to define a distribution model between HR and E-Rec distributing Infotypes 0000, 0001, 0002 and 0105 (subtypes 0001, 0010) for the P object. If needed in the business process you can add infotype 0006 subtype 0001 for address. If you plan the OM integration (assing positions to requisitions in e-recruiting) also distribute infotypes 1000 for O, S, C and the releations betweeen from infotype 1001 - this all is defined by adding filter groups to the distribution model

- the partner setting has to be set to asynchronous on e-recruiting side

The initial distribution has to be done using T-Code PFAL, the best practise for the distribution can be found in the attachment mentioned above,

After the initial distribution you plan RBDMIDOC to process the change pointers from HR and create IDocs for E-Recruiting. In E-Recruiting you plan RBAPP01 with a variant ensuring that all IDocs are processed sequentially (package size 1).

Kind Regards

Roman

[Former Member · Accepted solution]

Hi Roman,

I am still stuck--tried transferring the same data for the object type P but it is still unable to create 0006 and 0105 for the 'P' object..the I-Doc is still in 52 and one of the error messages as below-

Object 01 ,P ,00111088 does not exist: infotype 0006 cannot be created

Message no. 5-105

Diagnosis

You have tried to create infotype 0006 for plan version 01,object type P,object ID 00111088. However,the object does not exist.

PA objects exist if infotypes 0000, 0001, and 0003 have been created.

PB objects exist if infotypes 4000, 0001, and 0002 have been created.

PD objects exist if infotype 1000 has been created.

Also, Do I need to transfer the P-CP relation as well? I tried transferring the B 209 relation between CP and P but still not working.

Thanks

Tania

[romanweise · Accepted solution]

Hello Tania,

first of all we should have a look on your system landscape. If you have e-recruiting on an standalone server, the server installation should only include basis components (BASIS, ABA, PI, ...) and the e-recruiting component. Running e-recruiting standalone on a server with a complete ERP installation is not officially supported up to EhP3.

Could you please check that you either have the first landscape situation or if you have installed a full ERP implemented note 1147882.

Before running some ALE at all ensure that the system works well and w/o any SLG1 entries for external candidates and internal candidates created using report RCF_CREATE_USER.

Then make sure the BAdI implemtations are set accorting to note 997181:

BAdI                    Implementation
HRALE00SPLIT_INBOUND    HR_INB_PROCESS_IDOC -> activated
HRALE00INBOUND_IDOC     HRRCF00_DELETE_SPREL -> activated

HRSYNC_P                CONV_HR_DATA_TO_EREC -> deactivated (if existing)
HRALE00INBOUND_IDOC     HRRCF00_INBD_NEWMOD -> deactivated (if existing)

For the distribution model define a filter restriction the infotypes / subtypes destributed for P to:

Infotype 0000

Infotype 0001

Infotype 0002

Infotype 0006 Subtype 0001

Infotype 0105 Subtyoes 0001, 0010

If you want to include the OM in E-rec (use positions in requisition maintenance, etc.) add a filter for Infotypes 1000 and 1001 for objects P, S, O and C (you can use the subtype to restrict relations and avoid unnecessary relations in the IDoc. P->CP relation is only necessary for EhP 4 and higher.

Make sure you use the best practise step by step descripion for the intial data transfere for EhP 3 documented in note 997181 document Two_Instance_E-REC_Integr_ERP_EN.pdf page 4, add the processing for type C after each object type S step.

Hope that helps.

Kind regards

Roman

[Former Member · Accepted solution]

Hi Roman,

We are upgrading to EhP4 SP5 and trying to set up ALE on a I2B platform, Activated required badi's, Set up required filter group for HRP1001 and subtypes.

When trying to re-distribute just the P objects from HR ( Do we need to re-distribute all the objects or just P?)

we are having the same issues,

"Relationship starting from 01P 00006824 impossible - 01CP30077088 does not exist/is not active

Object 01 ,P ,00006824 does not exist: infotype 0105 cannot be created

Object 01 ,P ,00006824 does not exist: infotype 0006 cannot be created"

You mentioned "you have to distribute the P - CP relation.", how do we do this in PFAL? Any suggestions on how to fix this issues? I really appreciate your time, please help.

Thank you

VK.

[romanweise · Accepted solution]

Hello,

if you are currently upgrading you should directly apply SP 6 as it includes additional ~160 corrections. Furthermore you should apply the following notes from SP 7 as they effect the ALE distribution:

1461128 - Hiring in the future ALE (document not fully posted)

1469270 - ALE Inbound Processing: Double CP->US relationship

1478300 - HRALX: Beziehung CP-NA wird gelöscht im E-Recruiting

To transfer the P-CP relation you have to add the P-CP relation in the filters for the ALE distribution model (the filter group with IT 1001, use the correct subtype for the P-CP relation). Once you have done this the relation will be transfered with the P object when running RHALEINI (T-Code PFAL).

If you upgrade from E-Recruiting EhP 3 or lower you have to distribute all P objects again by using RHALEINI in "Update" transfer mode and evaluation period "all". (As often asked this is documented in SAP note 1241014 - Information for existing customers about EHP 4 under bullet point HR integration). Reason is that the new ALE uses the new basis infotypes 558. If you do not transfer all P objects again, the periodical run of RHALXSYNC will delete information from business partner when syncing it with the 558 intotypes. This is especially important if you decided to not transfer certain information. E.g. if you do not transfer the email address for internal candidates as they shall enter their private one, it is not present in the 558* infotype so without customer adaption RHALXSYNC would delete the email address maintained by the candidate.

(Please note: never redistribute the org. management objects (O, S, C) using HRALEINI in insert transfer mode after the initial distribution. This will delete all relations for these objects in the e-recruiting system including the ones create there. That way you loose all position assignments to requisitions.)

Kind Regards

Roman

[Former Member · Accepted solution]

Hi Roman,

Thanks a lot for your reply. Going to SP6 is not an option at this time. We'll upgrade to it eventually. While going over the I2B document, we've missed the last point

to check 'CL_HRRCF_SYSTEM_CHECK an enhancement that sets the attribute IS_STANDALONE to TRUE.' Do you think this might be the cause of our ALE errors? Also this class came as inactive by default. How could this be?

Please clarify.

Thank you.

[romanweise · Accepted solution]

Hello,

you should in every case apply the enhancement to class CL_HRRCF_SYSTEM_CHECK if you are in a I2-B scenario. Several processings in e-recruiting are depending on the correct identification if the system is standalone or integrated. Unfortenately I have no system access at the moment due to my vacation, but it might be that some processings in the HR - E-Rec integration check this information.

The class should not be delivered as inactive, no class should. If you have always been in the I2-B scenario someone might have changed/modified the class before and it is now undergoing SPAU? (there was a note / sap suggestion to modify the class so it returns the correct value for standalone erp installations even though this scenario wasn't officially supported). if this does not apply to your system you could check the upgrade / patch logs for any errors.

Kind Regards

Roman

[Former Member · Accepted solution]

Hi Roman

I also wanted to ask you if there were any specific BADI's which need to be active in the ECC System for the transfer of data? I am not able to locate which one's are they.

Also, if you could please provide your expert gudiance on this scenario--

We have scheduled Periodic Service, COM_sE_dISPATCHER and also set up TREX..we have created indices in ses_admin and checked com_Se_Search report which shows results...however, in SKPRO7 the search shows no documents and on the recruiter page the results for requisitions under candidate overview page and candidates under TRM is null.

We even re-transported the search profile tables but in vain---this has become a real high prioirty issue and we are at a standstill as to what is happenning..should we stop the job and re-start it or re-create the indices or re-start the TREX? As i am surprised as to why even requisitions are not visible under the button 'search for requisitions' under candidate overview..

Your help will be super super appreciated.

Much thanks!!

[Former Member · Accepted solution]

Hi Roman,

Thanks a lot again for your reply, we've finally resolved the ALE issue, but haven't transferred all the P objects yet. I was just doing some testing on hire activity from PA48 after the data transfer. Everything looks good with out any errors, however after the Hire activity and all the necessary infotypes data existings, the reference user of the external candidate 'RCF_CAND_EXT' is not getting convered to 'RCF_CAND_INT'. Any settings I could have missed?

thank you again

[romanweise · Accepted solution]

Hi,

according to the documentation in note 997181 running PA48 only transfers the employee ID information to e-recruiting (for Ehp 4). The switch from external to internal candidate is done when ALE processes the change pointers for the hiring. Furthermore the switch should be executed at the correct date. According to the note this should still be done by periodical service PROCESS_CAND_STAT_CHANGE if you used a future hiring date but I am not fully sure about that as this is listed under the EhP4 inbount process but is the old EhP3 paragraph. Unfortunately I have no system access currently so I can't check in the coding.

Best Regrads

Roman

[Former Member · Accepted solution]

Hi Roman

This is with reference to the search issue...we have noticed the differnece in entries of T77RCF_SMG_NAVI in DEV and QAS.

Even though we have re-transported the entries the last two columns ( business object and object) are NOT getting updated in QAS Box.

Due to this, the search is not throwing an internal error but no hits, either. Is it possible for you to advice me to replicate the table entirely from the DEV Box?? Search is working great in DEV.

I am at a standstill and would really apreciate your guidance!!

Thanks

[romanweise · Accepted solution]

Hello Tania,

It is very strange that transporting the complete entries has no effect. You should check the transport log for any messages. Also ensure that if you use different client numbers that the correct client is specified on import so the entries are put in the correct client. Furthermore check the system setting that the business function is activated correctly. You can try different ways to transport the entries like SM30 or adding the entries manually to a transport but usually it is a basis issue if a transport is not working correctly.

Overall if I am faced with a customizing inconsistency between systems I usually go for a "full" customizing comparison. I take all T77RCF* tables (you can get them from se11 e.g. table TADIR) and run SCU0 with manual object seletion between DEV/QS and DEV/Prod box. In the result I check all customizing tables for equal entries and if there are any inconsistencies I manually build a transport to tidy things up. If you are not familiar with manual transport building you might need some help of a basis guy / developer. (Be aware that some T77RCF* tables are not customizing as they contain system dependent data e.g. T77RCFBRANCHCOMP which contains the branch IDs which are system dependent BP keys. You can identify these tables by checking if their content includes any object keys from OM or BP or they contain GUIDs like the process variant table T77RCF_RP_ACT).

Kind Regards

Roman

[Former Member · Accepted solution]

Hi Tania,

I am facing the exact same problem.Were you able to resolve the issue? Appreciate any help in this regard.

Regards

Adithya