BADI HRALE00INBOUND_IDOC

Hello Gurus,
Did anyone used BADI HRALE00INBOUND_IDOC? We have existing business process where SRM Organization hierarchy is integrated with SAP HR and any changes are flowing correctly through the standard ALE interface...
But we have to manually maintain default cost center and ship to address for each position in the system....IDoc which flows from SAP HR to SRM does contain cost center for each position, Can that cost center be placed as default for that position with this BADI??
In our business scenario we can not able to put default cost center at department level as in same department there are users with different cost center....
Please advise....
Thank you in advance for your inputs.
Best Regards
Ritesh

You would like to replace some field in the incoming infotype, when the IDOC is being posted in your system, right?
If so, yes, this BADI is ok for this task.
Also, if your replacement logic is as simple as setting some default constant value, you should have a look at 'Converting Data Between Sender and Receiver ' subtree of transaction SALE. You don't have to write any abap then.

Similar Messages

Using HRALE00INBOUND_IDOC BADI for HRMD_A message, infty 0105

Hello Experts,
I am using HRALE00INBOUND_IDOC BADI for HRMD_A message type (for HR master data and infotype 0105).
I have configured OUTBOUND and INBOUND systems. I have created Z programe for idoc generation.
In Z program, changing only one filed i.e. USRID_LONG (EMAIL Address).
After executing the Z program IDOC is generating and if we see in WE05 then it is in YELLOW color with status 30 and 01.
After that i am using we19 or BD87 and process the IDOC then it will come in green color. I am checking on INBOUND system, IDOC is receving successfuly with green color and with updated data.
But If we go to PA30 transaction code and check to the email address (infty 0105 and subtype 0010) that is not updating.
Why? If i am receving IDOC successfuly then why Data base table is not updating?
Thanks in advance,
Ranveer

Hello Anatony,
BADI HRALE00INBOUND_IDOC is trrigering in INBOUND side.
Now data is updating, but problem with data.
s_e1plogi-plvar = '01'.
s_e1plogi-otype = 'P'.
s_e1plogi-objid = '00000014'.
s_e1plogi-opera = 'U'.
APPEND s_e1plogi.
int_edidd-segnam = c_e1plogi.
int_edidd-hlevel = '02'.
int_edidd-sdata = s_e1plogi.
APPEND int_edidd.
s_e1pityp-plvar = '01'.
s_e1pityp-otype = 'P'.
s_e1pityp-objid = '00000014'.
s_e1pityp-infty = '0105'.
APPEND s_e1pityp.
int_edidd-segnam = c_e1pityp.
int_edidd-hlevel = '03'.
int_edidd-sdata = s_e1pityp.
APPEND int_edidd.
U for update. If sender system have data for 0010 subtype, and recevier side 10 subtype is blank. In that case infotype 0105 is creating, but if infotype is already available on INBOUND system and wants to update, in that case data is not updating and IDOC in red color with 51 status. Message is " Infotype 0105 cannot be updated on database table PA0105".
My logic is for update....
select * from pa0105 into table int_pa30
              where pernr = '00000014'.
int_pa30-usrid_long = 'ABC1 ATTHERATE SAP.COM'.
modify int_pa30 transporting usrid_long
where usrid_long = 'XYZ ATTHERATE SAP.COM'.
*--To send the data to 510 Client thru IDOC.
loop at int_pa30.
    int_pa0105-infty = '0105'.
    move-corresponding int_pa30 to int_pa0105.
    append int_pa0105.
endloop.
So, where is my fault kindly update me.
Thanks in Advance,
Regards,
Ranveer

BADI ZHRALE00INBOUND_IDOC not working

Hi *,
I have implemented BADI HRALE00INBOUND_IDOC .
For some reasons I cannot activate the BADI.
I think this could be the right BADI as per my requirement I have to check segment E1P0002 field PERID, which is indeed the TAX NUMBER.
I have to read the content of this segment extract the tax number and pass TAX TYPE as ES1, before IDOC is post, and I would say before saving the object.
I have collect the following BADI:
HRALE00INBOUND_IDOC
HRALE00INBOUND_OBJEC
HRALE00SPLIT_INBOUND
HRALEX_INBOUND
Which one can fit for my purpose?
Please don't be shy feel free to suggest.
Regards,
AndreA

Hi Andrea,
Could you please let me know how you solved the problem?
I am also facing the same issue.
Am getting the error message that "There are already implementations active".
And I see already that CRM_O_BP_RELAT is already implemented which is a standard implementation.
Thanks

E-Recruiting 6.04. Issue with internal candidates e-mail.

Hi,
We are on E-Rec 604 with seperated standlone e-rec system.
We did the initial transfer of employees with ALE and we though that all were ok, but now we realized that there are some internal candidates that no have e-mail adress in e-recruiting.
We have been investigating and those employees have filled the infotype 105 subtype 0010 in Hr system. In E-Recruting system the user created by ALE has the e-mail too, but in transaction BP only a few of them have filled the field e-mail in the block of adress independent comunication. So only this few internal candidates have e-mail in the portal of E-Recruiting.
We are looking for any differences of those employees in HR system but we can´t find anything.
Someone could help me with the reason of this problem, please?.
And someone know if there is any way for repared this in the e-recruiting system.
Best Regards,
Esther

Hi,
I just want point out the HCM ALE processes. Firstly independently of connected to eRecruiting or not.
The message type HRMD_B is containing the infotypes belonging to the software component SAP_BASIS.
The message type HRMD_ABA is containing the infotypes of the message type HRMD_B and the infotypes belonging to the software component SAP_ABA.
The message types HRMD_B and HRMD_ABA must be used to distribute HCM data into non-ERP based landscapes.
The message type HRMD_A is containing the infotypes of the message type HRMD_B and the infotypes belonging to the software component SAP_HR. It should then be used to distribute HCM data into an ERP based landscapes.
Esther is describing an eREcruiting standalone based on an ERP landscape. Therefore, the message type HRMD_A should be used.
Then, from the HCM integration in Business Partner point of view, the standard implementation of the BAdI HRALE00INBOUND_IDOC should be deactivated. This implementation is normally converting the object P into a CP, because the object P is known only in HR (and ERP based landscape). In an ERP based landscape, the P will exist with its CP. The integration to the BP will not work during the ALE-Inbound process, but during the Synchronization run (report HRALXSYNC). The implementation makes sense only in none-ERP based landscapes (where message type HRMD_ABA will be used).
Ester should then adapt her distribution model to be able to distribute the necessary infotypes for the consistency of a P (infotypes 0000, 0001, 0002, 0003) as well as the one which are used for the BP-integration (infotype 0006 subtype 1, infotype 0009, infotype 0105 subtypes 0001, 0005, 0010, 0020), as well as the HR-object CP and its relationship to the P (infotypes 1000 and infotype 1001 subtype B209).
With the hope it is clarifying the usage of the message types depending on the used scenario and on the used landscapes.
Best regards.
Pierre

Problem with data distribution from HCM to e-Recruiting

Hello masters:
I have a problem when I try to distribute data from HCM to e-Recruiting. I´m getting code 51 just for the PA infotypes segments (E1P0000, E1P0001, etc.). The error message tha I am receiving is:
"Error in subroutine read_namtb for structure of infotype".
My e-Recruiting system is SAP EHP 1 for SAP NetWeaver 7.0, so I'm using Business Partners for storing data from PA infotypes.
I'm using message type HRMD_ABA, basic type HRMD_ABA05.
I think it could be the implementation HRRCF00_INBD_NEWMOD from the badi HRALE00INBOUND_IDOC, because it usually get inactive even though I go to activate it.
Does anybody knows what can I do?
Thanks in advance!
Edited by: Rodrigo Arenas Arriola on Jun 25, 2009 2:45 AM

Hello Rodrigo,
Ifyou are using EhP1 for NW 7.0 you should have E-Recruiting 600 EhP 4 on your system.
I never encountered this special error message so far, so i have to "guess". The message indicates that the system had trouble reading some infotype information.
The ALE distribution for EhP4 is storing the PA data in new infotypes 558*. The error you get points to a missing BAdI activation. If the BAdIs are not activated correctly, ALE will try to write the information from the PA infotypes 1 to 1 into the E-Recruiting system. But E-Recruiting does not know the PA infotypes which should exactly lead to the error you get.
Could you check the following settings:
BAdI                     Implementation
HRSYNC_P                 CONV_HR_DATA_TO_EREC -> active
HRALE00INBOUND_IDOC      HRRCF00_INBD_NEWMOD -> active
HRALE00SPLIT_INBOUND     HR_INB_PROCESS_IDOC -> inactive
HRALE00INBOUND_IDOC      HRRCF00_DELETE_SPREL -> inactive
Kind Regards
Roman

How to add custom infotype in ALE for HRMD_A message type

Hi Friends-
Pls help me for our req we are using HRMD_A Message Type for HR master data but now we need to add one custom infotype ( 9902 ) also in standard ALE filters for this message type how i can do that pls let me know ?
<<removed_by_moderator>>
Regards
Meeta & Glory
Edited by: Vijay Babu Dudla on Dec 14, 2008 11:38 PM

Hi
Thanks for your support,
Pls let me know which steps i should go ? my secanrio is inbound side only,
step 1 ) Define idoc extension for HRMD_A01 using WE30 transaction and define it in partner profiles
step 2) do i need to write some code in BADI also to update information for my custom infotype also if yes then where and which BADI pls let me know ? because already am working on one badi HRALE00INBOUND_IDOC for few validation for incoming data.
step 3 ) add this new custom infotype in my standard ALE filters.
Pls let me know if am mistaking some where or if i have to do some thing else ?
Regards
Meeta & Glory

Transfer HRMD_ABA01 IDocs to SAP Non-HR system

Hi all,
We need to transfer HRMD_ABA01 (Basic Type) IDOCs from ECC to BW system. The BW system doesn't have PA data for Employee
and this results in an Error - 'Error in subroutine read_namtb for structure of infotype'. While debugging it was found that the infotype 105
doesn't exist in the BW system but the Inbound IDOC has the relevant segment E1P0105.
Now, I want to remove this segment from the IDOC. What is the best way to do it? Handling it through the BADI in Inbound processing or any other means?
Thanks,
Sharmila

Hi Glen,
Thanks for the reply. Infotype 0105 doesn't exist in BW system and there is no segment defined for it in T777D. And, the HR integration is also active (T77S0).
BADI "HRALE00INBOUND_IDOC" doesn't have any implementations.
My requirement here is to delete the segment corresponding to Infotype 0105 from the Inbound IDOC. I would like to know whether we could do IDOC reduction at the Outbound side or Delete segments before Inbound processing.

HRMD_A Scheduler is in state "not ready"

I am using IDOC type HRMD_A to upload data for infotype IT0002 & IT0006. The IDOCs go in to status 51 with message 'Scheduler is in state "not ready"'
I am able to upload data for other data objects using IDOCs correctly.
Please advice how to overcome this error message.

Dear Ibrahim,
this error message can appear if a certain BADI implementation is activated for BADI HRALE00INBOUND_IDOC. This is the case e.g. in one of the IDES environments.
You can go into transaction SE18 and select BADI Name, enter HRALE00INBOUND_IDOC and select Enhancement Implementation->Overview from the menu. Here, there is one highlighted (yellow) implementation that you need to select (doubleclick). Then, you need to change to edit mode, ignore the warning, and select Implementation->Deactivate from the menu and save. I had to exercise the last steps twice. I hope that helps.

ALE ISSUE HRMD_A

HI Experts,
We have a issue where we are sending the data from one HR system to another HR system using ALE message type HRMD_A07. So in sending system if we create a record which has a validity date of 01/01/2011 to 12/31/9999. The change pointers take that record and update it in the receiving system which is fine but instead of delimiting the record on the receiving end it inserts the record. So in the receiving end we have two records with 12/31/9999 end dates which we dont want.
Is there a BAPI or Setting in the t77s0 table which will prevent this from happening and instead of directly updating the table it delimits the old record and create a new one. Any help would be much appreciated. Thanks

Hello Hasan,
Last year we had faced the same problem As per our investigation std. HRMD i/b idoc processing doesn't provide data delimition.(We were using an ECC6.0 system)
If you check the i/b processing FM IDOC_INPUT_HRMD, there is a BAdI HRALE00INBOUND_IDOC. You can use the method PROCESS_IDOC( ) for user-defined IDoc processing.
Inside the method you can call an FM (for e.g., HR_INFOTYPE_OPERATION ) which can delimit the infotype.
BR,
Suhas
PS: Alternatively you can use the function-exit 'EXIT_SAPLRHA0_003'.

Search employee details from Business partner number input

Dear friends
I am searching employee details by having input as a business partner number from infotype 0000. as pernr has only 8 character in size and bp in 10 char in size. would you please tell me how we can access employee detais from business partner number.
p.s : I am doing this in CRM system
Business partner ?->infotype(0000)-->?
Any help will be appreicated.
Regards
Naeem

Dear Naeem,
as a CRM environment is not able to run at the same sytsem / client with HR, the employee data (e.g. infotype actions (IT 0000)) only is available in a scenario with ALE-distribution from a HR-system.
In this case the employee data from HR-system will be distributed via idocs (message type HRMD_ABA) to the CRM-system and saved to databases HRP558x [x=0 - 5; 0= IT0000; 1 = IT0001; 2 = IT0002; 3 = IT0006, subtype 1; 4 = IT0009; 5 = IT0105, subtype 0005, 0010, 0020] for the central person (object type CP).
The activated business partner integration (table T77S0, group HRALX, switch HRAC) will create / update related business partners (relation is saved within table HRP1001, subtype B207) according to the mapping of data during idoc inbound processing (active CRM implementation of a BAdI HRALE00INBOUND_IDOC processed within the function module (FM) IDOC_INPUT_HRMD (stored in table TBD52 for evcode = HRMD).
Reading specific infotype data of a central person (databases HRP558x) will be done using the FM RH_READ_INFTY.
Regards,
Michael

Avoiding change pointers for data with status planned

Hi,
we have to distribute HCM-data, standard infotypes and customer infotypes, into other SAP sytems. One of the receiving systems must not get data with the status planned (istat = 2).
Which would be the best way to avoid planned data in the receiving system? Is it possible to avoid creating change pointers for planned data in the delivering system or have I to delete the planned data in the receiving system while processing the idocs via user-exit?
Best regards
Stefan

Dear Stefan,
You can create the change pointers manually from the IDOC data (e.g.with FM CHANGE_POINTERS_CREATE) during the inbound processing within of the customer-exits of enhancement RHALE001 or within an own BAdI implementation of BAdI HRALE00INBOUND_IDOC.
Or else you can use method IDOC_DATA_FOR_RECEIVER_MODIFY of BAdI HRALE00OUTBOUND_IDOC. In this case please make sure that note 1292241 is implemented.
Hope it helps,
Christine

Prob wth Extending HRMD_A06 basic type

Hi All,
I have some custom fields in PA0002 table. So i extended HRMD_A06 and in user-exits i am populating custom fields. Out bound side everything is OK. But it is giving 51 error in inbound side. Probelm with read_namtb subroutine. it is chking the custom segment in T777D table...
I am unable to solve the problem. Can anyone hlp me in this regard.

May be this helps you !!

FYI
SymptomThe standard scenario for the distribution of HR master data and organizational data via message type HRMD_A only covers a limited number of infotypes.
Additional standard infotypes should be distributed using a customer enhancement.
Other terms
PFAL, RHALEINI, HRMD_A
Reason and Prerequisites
In the standard scenario, only infotypes are distributed, which are required for a distributed HR in a non HR-system.
Solution
The following activities are required if standard infotype Pnnnn (with nnnn = infotype number) is to be distributed in addition.
Consider the restrictions at the end of this note in particular!
Release 3.1
1. Source code corrections:
According to the attachment (programs not contained in the standard system), repairs are necessary in the Includes LRHA2U06 and UP50RU01.
You only have to change Include UP50RU01 if it is a PA infotype.
If you also want to distribute infotypes starting with 2nnn or 9nnn, an additional repair in Include LRHALF01 is necessary. Remember that in this case the Infotype 2011 is stored differently than the other infotypes and cannot therefore be distributed.
Note that these changes are not contained in the standard system.
2. Customizing:
Transaction WE31 for Z1Pnnnn (in the sending system and the receiving system):
For each additional infotype, create a new segment type Z1Pnnnn (with nnnn = infotype number).
Transaction SM30 for table T777D only for PD infotypes (in the sending system and the receiving system):
For the entry infotype nnnn, enter Z1Pnnnn in field IDOC segment.
Transaction WE30 for ZRMD_A01 (in the sending system and the receiving system):
With Transaction WE30, create extension ZRMD_A01.
Create E1PITYP as a reference segment type, as child segments of this, the extension segment types Z1Pnnnn. As an IDoc type, create ZRMD_A01 for the basic IDoc type HRMD_A01 and extension ZRMD_A01.
Transaction WE82 (in the sending system and the receiving system):
The entry for message type HRMD_A and basic IDoc type HRMD_A01 is copied to a new entry with the extension ZRMD_A01.
Transaction WE20 (in the sending system):
In the sending system, for the partner number of the receiving system in the outbound parameters, enter ZRMD_A01 as idoc type in the line for entry message type HRMD_A.
Transaction WE57 (in the receiving system):
Copy the entry for function module name IDOC_INPUT_HRMD, basic IDoc type HRMD_A01 and message type HRMD_A, and enter ZRMD_A01 in the field extension.
As of Release 4.0B
1. Source code corrections:
Implement the attached advance corrections or:
Apply Hot Package for 4.0B: SAPKH40B02 or
Legal Change Patch for 4.0B: SAPKE40B02
The Include UP50RU01 must only be changed if it is a PA infotype.
Include UP50RU01 is not contained in the Hot Package and must be changed in accordance with the advance correction if the Legal Change Patch is not applied.
After applying the Hot Package (and manually repairing the UP50RU01) or the Legal Change Patch, only the Customizing activities are necessary.
2. Customizing
Transaction WE31 for Z1Pnnnn (in the sending system and the receiving system) :
For each additional infotype, create a new segment type Z1Pnnnn (with nnnn = infotype number). The function "Create by copying" can be used to reduce the work load.
Transaction SM30 for table T777D (in the sending system and the receiving system):
For entry infotype nnnn, enter Z1Pnnnn in field IDOC segment.
Transaction WE30 for ZRMD_A02 (in the sending system and the receiving system):
With Transaction WE30, recreate extension ZRMD_A02.
The linked basic type is HRMD_A02. Insert the new Z1Pnnnn segments as child segments of E1PITYP.
Transaction WE82 (in the sending system and the receiving system):
Copy the entry for message type HRMD_A and basic type HRMD_A02 to a new entry with extension type ZRMD_A02.
Transaction WE20 (in the sending system):
In the sending system enter ZRMD_A02 as an 'Extension' for the partner number of the receiving system in the outbound parameters in the entry message type HRMD_A with basic type HRMD_A02.
Transaction WE57 (in the receiving system):
Copy the entry for the FM name IDOC_INPUT_HRMD, basic type HRMD_A02 and message type HRMD_A, and in field 'Extension' enter ZRMD_A02.
As of Release 4.5A
Here, the Customizing activities described in Release 4.0B are to be carried out.
As of Release 4.5A, HRMD_A03 is used as the basic type and ZRMD_A03 is used as the extension type.
As of Release 4.6A, HRMD_A04 is used as a basic type and ZRMD_A04 is used as an extension type.
As of Release 4.6C, HRMD_A05 is used as a basic type and ZRMD_A05 is used as an extension type.
As of Release 4.70, HRMD_A06 is used as a basic type and ZRMD_A06 is used as an extension type.
Restrictions:
SAP cannot offer any support concerning compatibility with different releases for the additional infotypes of the enhancement in the standard system. For release specific changes to the infotypes of the enhancement a client-specific solution must be found (project solution).
Other known restrictions:
Known restrictions are listed here with possible solution approaches. If you should discover a restriction that is not yet documented, you can inform us of this via the R/3 SAPNet Frontend with a low priority problem message.
01/25/1999: PA infotypes with subtypes are not found in T591A
For infotypes in personnel administration, whose subtypes are stored in a different table than T591A according to table T582A, distribution works in the transfer mode 'Insert' and using the change pointers. Distribution in the transfer mode 'Update' does not work. The approach to solve the problem is a customer-specific extension of the routine HR_INFTY_GET in program RHALEINI by the corresponding infotype/subtype combinations.
02/01/1999: Workflow infotypes
Workflow infotypes, thus in the area 12xx, are not supported since the object type workflow is not supported in the standard ALE scenario. The approach to solve the problem is the use of the manual transport connection (RHMOVE30).
05/17/1999: Infotype 2011
The Infotype 2011 is stored differently than the other infotypes and therefore cannot be distributed.
11/09/2000: Segment for infotypes with a width of more than 1000 characters
The maximum width of a segment is 1000 characters. For this reason it cannot be generated automatically for infotypes with a width of more than 1000 characters.
A possible solution is to create the segment manually and to only insert the key fields and the application fields that are really needed in the segment in order to avoid exceeding the 1000 characters. The values of the fields are transported from infotype into the segment and vice versa in the case of infotypes that are distributed additionally. The reason is that the fields have the same names in segment and infotype.
07/17/2002: In ALE inbound processing, only the data records of the infotypes are posted - similar to the infotypes to be distributed in the standard. No additional functions regarding possibly dependent or derived data in other (database) tables are executed. A solution approach is to distribute the dependent or derived data in a separate (customer) scenario or implement a customer exit (RHALE001) or a BADI (HRALE00INBOUND_IDOC) with the desired functionality.

How to add custom Template transaction types ( for Quote ) ?

How to add custom template in transaction types?
Note : I have gone through below note. But not getting appropriate solution for this.
982142.1 (OM Sales Order Template Not Available In Layout Template LOV For Print&Preview)
444687.1 (OM Quote Template Not Available In Layout Template LOV for Print And Preview)
Thanks in advance..
Sameer

Hi
Thanks for your support,
Pls let me know which steps i should go ? my secanrio is inbound side only,
step 1 ) Define idoc extension for HRMD_A01 using WE30 transaction and define it in partner profiles
step 2) do i need to write some code in BADI also to update information for my custom infotype also if yes then where and which BADI pls let me know ? because already am working on one badi HRALE00INBOUND_IDOC for few validation for incoming data.
step 3 ) add this new custom infotype in my standard ALE filters.
Pls let me know if am mistaking some where or if i have to do some thing else ?
Regards
Meeta & Glory

E-Recruiting Multiple Employment

Hi all,
I am about to start a project implementing e-recruiting with Enhancement Pack 4 and I was wondering if anyone knew if there are any improvements to the handling of multiple/concurrent employees?
I have found a presentation from SAP which stated that in EHP4 there would be "Improved concurrent and global employment handling". However I have not seen anything like this in the release notes.
Has anyone implemented this or does anyone know any more detail about the changes?
Thanks
Tom

Hello,
Below is the detailed explanation from SAP regarding CE.
ALE - Inbound Processing and Concurrent Employment (New)
As of SAP E-Recruiting, Enhancement Package 4 (ERECRUIT 604), Business Function HCM, SAP E-Recruiting 2, the ALE inbound processing has changed. The ALE distribution is now based on the inbound processing of HR master data with integration to the Business Partner.
In the standard system, SAP delivers the implementation HRRCF00_INBD_NEWMOD of the BAdI HRALE00INBOUND_IDOC ( HR-CA-ALE: Inbound Processing for HR Master Data). The implementation is based on the HR-ALE pre-implementation EnhancedDistribution. This Enhanced Distribution is responsible for all HR master data and data for the Business Partner. In the standard system, the implementation HRRCF00_INBD_NEWMOD uses the method PROCESS_IDOC to delete all relationships between positions and persons from the inbound IDocs as well. Instead of the Person (object type P), the system assigns the Central Person (object type CP) to the Position (object type S).
SAP E-Recruiting uses the POST_PROCESS_IDOC method to perform the specific IDOC processing. In doing so, the system creates new candidates (object type NA) from the IDOC data and/or updates information for the candidate.
Concurrent Employment
The change to ALE inbound processing enables you to use SAP E-Recruiting even when Concurrent Employment is active in the connected HR system. SAP E-Recruiting then behaves as follows:
u2022     If an employee has multiple work contracts in the HR system, then a Candidate (NA) object is created in SAP E-Recruiting with the assigned objects Central Person (CP) and Business Partner (BP). All work contracts are accessible via the candidate.
u2022     In the case of Concurrent Employment, an internal candidate is regarded as active if at least one of the candidate's work contracts is active.
To be able to use Concurrent Employment, SAP E-Recruiting requires a decoupled infotype framework in the underlying HR system.
Effects on Existing Data
Once you have activated the business function, the system no longer executes the coding of the two implementations that were previously relevant for ALE distribution.
u2022     BAdI: HRALE00SPLIT_INBOUND, BAdI implementation HR_INB_PROCESS_IDOC
u2022     BAdI: HRALE00INBOUND_IDOC, BAdI implementation HRRCF00_DELETE_SPREL
This also means that any user-defined implementations of the BAdIs cannot be executed any more. If necessary, you have to create a new implementation for the BAdI HRALE00INBOUND_IDOC by using the implementation HRRCF00_INBD_NEWMOD.
The BAdI HRALE00SPLIT_INBOUND is no longer supported. To use the new ALE distribution, you have to deactivate the previous implementations of the BAdI. Before you activate the business function, you must repair any incomplete data records that were created during the previous data distribution. Otherwise, you have to perform ALE distribution for the data of the affected persons once again with the new distribution method.
If you activate Concurrent Employment (system parameter RECFA RECCE) and there are different instances (standalone scenario), you must execute again the ALE distribution for the candidates already available in the system for whom an entry exists in the table T77RCF_P_STAT (Bookmark Employee Status Based on HR Data).
Effects on Customizing
The conversion of the ALE inbound processing affects the following Customizing activities:
u2022     For more information, see Customizing for SAP E-Recruiting under Technical Settings -> SAP ERP Central Component (ECC) Integration -> Software Runs on Different Instances -> Set Up ALE Distribution for SAP E-Recruiting.
u2022     In the Customizing activity BAdI: Inbound Processing for HR Master Data, you activate the implementation HRRCF00_INBD_NEWMOD of the BAdI HRALE00INBOUND_IDOC or a user-defined implementation.
u2022     The ALE distribution is based on the inbound processing of HR master data with integration to the business partner; in other words, you must have the business partner integration switched on. For this, you have entered "X" for the system switch HRALX HRAC (Activate HR Integration) and "ON" for the system switch HRALX OBPON (Integration O-BP Activated) in the HR system. You have also activated the implementation CONV_HR_DATA_TO_EREC of the BAdI HRSYNC_P.
Activation of Concurrent Employment in SAP E-Recruiting affects the following Customizing
activities:
u2022     You use the system parameter RECFA RECCE (Concurrent Employment Active in ERecruiting System) to activate Concurrent Employment. You make this setting in Customizing under Technical Settings -> Set System Parameters.
u2022     For more information about Concurrent Employment for SAP E-Recruiting, see Customizing under Technical Settings -> SAP ERP Central Component (ECC) Integration -> General Notes for Concurrent Employment.

Adding segment to Idoc

Hello Guys,
I have an inbound Idoc in my system with 'N' segments. If I need an 'N+1' segment in the idoc, is it possible to add the new segment using the BADI HRALE00INBOUND_IDOC?
regards,
Gergo

Hi,
It depens of type of IDOC. Check Note 753153 - FAQ: Customer-functions in IDOC_INPUT_ORDERS for instance for IDOC ORDERSXX.
Regards,
Eduardo

BADI HRALE00INBOUND_IDOC

Similar Messages

Maybe you are looking for