Idoc enhancement with ABAP

[Former Member]

Hi all,

we are currently in a project to implement SAP HR as HR master and distribute HR master data to other legacy systems using SAP XI.

There will be two different interfaces from SAP HR to XI, one for real-time updates of changes (delta) and one for batch updates of complete records. We use SAP R/3 4.7 ext2 and want to use Idoc type HRMD_A06 which contains all HR data (we will have to add segments for two infotypes, but that is not the problem).

The problem is that there is some information we need to distribute that not automatically gets included in this Idoc type (such as SAP personell number for manager of the org.unit an employee belongs to). My guess is that this has to be filled using some custom ABAP.

Does anyone have any experience with adding such information to an Idoc? We can always find a suitable field in the Idoc to store the values if we only can retrieve the correct information.

And secondly, how do we make sure this extra information is stored for the correct employee segment in the Idoc?

Finally, can we implement this function module so that it runs after the general Idoc is created, runs through the entire IDoc and adds the correct information for each employee segment, and then send the finished IDoc to XI? This goes for both real-time interface (implemented using change-pointers) and batch interface (scheduled job to collect master data).

Any information or experience on this matter will be highly appreciated. Any other suggestions to how this problems can be solved are also welcome.

Thanks in advance.

Best regards, Kenneth Eriksen

[former_member38878 · Accepted solution]

Hi,

The requirement can be met by spending some effort on customization.

1. Consider the batch update of complete records.

For Example, An employee data with his positions,org unit,job,relationship should be dstributed to the external systems.

Following filters needed to be added :

0000,0001,0002,1000, 1001(subtype -A002).

When u run PFAL transaction for employee object with plan version 01,object type-P and object id -(Employee pernr)

All data related to filtered infotype will be picked up .

As per the standard idoc, only relationships between positions will be picked up.Requires a Manager pernr to send to external system.

Solution :

1. Create a new segment ZIP0001 with field names Employee pernr, Manager pernr.

2. Extend the HRMD_A06 idoc type with extension ZHRMD_A06 and attach new segment ZIP0001 to the original segment E1p0001.

3. Now its time to fill the data exactly.Implement a user exit in the function module EXIT_SAPLRHA0_003 and also the source code as follows :

***user exit changes**

case segment_type.

when 'E1p0001'.

l_plans = e1p0001-plans.

SELECT SINGLE SOBID INTO L_SOBID FROM HRP1001

WHERE OTYPE = 'S'

AND OBJID = L_PLANS

AND PLVAR = '01'

AND RSIGN = 'A'

AND RELAT = '002'

AND BEGDA <= SY-DATUM

AND ENDDA >= SY-DATUM.

if sy-subrc eq 0.

SELECT SOBID BEGDA ENDDA INTO CORRESPONDING

FIELDS OF LIT_SUPERVISOR FROM HRP1001

WHERE OTYPE = 'P'

AND OBJID = L_SOBID

AND PLVAR = '01'

AND RSIGN = 'A'

AND RELAT = '008'

AND BEGDA LE SY-DATUM

AND ENDDA GE SY-DATUM.

if sy-subrc eq 0.

• Get the latest Manager by sorting and assign the employee pernr and manager pernr to z1p0001.

endif.

endcase.

2. Change-pointers :

when there is a change in positions,new manager relationships, change-pointers specific to infotype 1001 will be triggered.

implement the logic in user exit :EXIT_SAPLRHA0_001

A. Infotype 1001 contains the Employees position with A002 relatioship to managers position.

Determine the employees pernr from 1001 employees position.

Select employee data from infotype 0001 and fill segment E1p0001.

B. Code applicable to bacth job in user exit 0003 will be applicable to this scenario.

C. Proper care should be taken in user exit 0001 - it should not fill E1p0001 records for the second time.

The above solution will solve ur requirement.

Please let me know for any concerns.

Regards,

Senthil

[Former Member · Accepted solution]

Thanks a lot Senthil, that was very helpful! There are additional fields that need to be populated for the employee using the user exit, but I guess the same logic can be applied to retrieve that information also.

I will try to implement what you suggested, and might come back to you I discover any issues. Thanks. Regards Kenneth.

[Former Member · Accepted solution]

Hi again Senthil

Just a couple of follow-up questions to the solution you outlined.

Is it possible to send both old and new value in the IDoc when there are changes?

Can we include data for additional infotypes, not only the infotypes that have changed? Is this done using the user exit, or is there a more standard way of including extra infotypes

Any comments are highly appreciated.

Best regards,

Kenneth

[former_member38878 · Accepted solution]

Hi Kenneth,

Actually change-pointers related to IDOcs capture the latest changes and will be distributed immediately to the other SAP or NON-SAP systems to keep the sending and recieving systems in sync.

1.) It is possible to send old and new value by overriding standard functionality of sending the latest changes. Consider this scenario,

Employee to Manager relationships:

42001234 01-10-2004 - 10-12-2004 42005678

42001234 11-12-2004 - 31-12-9999 42009123

Relationships delimited on 10-12-2004,change pointers related to infotype 1001 will be triggerd for the subtype A002(reports to). When u are filling the custom segments,

Employee no and New manager no- It is also possible to have a other field in the custom segemnt called 'Old manager'. The value can be filled by reading the HRP1001 table for relatioship A002 and A008 for the foll condition.

begda <= sy-datum -1.(or) new record begda -1

endda >= sy-datum -1.(or) new record begda -1

As change pointers executed today, the old record should have been delimited the previous day.

2. It is possible to send data for additional infotypes, but it can be filled in the userexit when some changes happened for the specific infotypes.

Consider this scenario :

1.) Added filters 0000,0001,0002.

Whenver changes happened in 0000 or 0001 infotype, change pointers triggered in BDCPV table and u can find data for E1p0000 and E1p0001 in the user exit. But u want to send 0002 data , though it is not changed.

Add the additional logic in the user exit to fill the data for infotype 0002.

Please let me know for any concerns.

Regards,

Senthil

[Former Member · Accepted solution]

Thanks a lot Senthil! Very helpful information!

[Former Member · Accepted solution]

Hi Senthil

I still have some problems with the exits, I am a bit confused with what exit to use when.

You say that EXIT_SAPLRHA0_003 can be used for the batch sending of data, but the description of this exit says: Import Parameters of ALE Inbound Processing IDOC_INPUT_HRMD

I want to implement code for outbound processing, can EXIT_SAPLRHA0_001 be used for both my batch and change-pointer scenarios?

Or can I use EXIT_SAPFP50M_002 (Customer Checks for Personnel Administration and Recruitment) to implement the code?

The extra fields I want to add (such as manager for employee, org unit name, company code) should be added for every employee both in batch and change-pointer transfers. RBDMIDOC is used for change-pointers, and RHALEINI is used for batch transfers.

Do I need a separate exit for both programs? Or is there an exit connected with the RSEOUT00 report (which both processes use for actually sending the data)?

Again, your help is much appreciated.

Best regards,

Kenneth Eriksen

[former_member38878 · Accepted solution]

Hi Kenneth,

Sorry for the misleading information abt the user exit at the first place.

For batch process,

1. Run PFAL transaction.

2. Follow the same process to determine the manager in user exit EXIT_SAPLRHAL_003. set the parameter flag as 'X'. Also export the parameter 'Flag' to memory id in the user exit after the process.perform the logic to determine manager pernr only if infotype 0001 is filled.

3. Second user exit EXIT_SAPLRHA0_001 will follow the previous exit. Import the parameter from memory id. if flag eq X. no process.

4. Manager pernr will be passed.

**************

For change-pointer process,

only 1001 information should be triggered by change-pointers.

1.)run rbdmidoc to trigger change-pointers for hrmd_a.

2.)user exit EXIT_SAPLRHAL_003 will be executed internally in the first step. should not perform manager logic as no 0001 infotype filled. It means parameter FLAG is blank.

3). in the user exit EXIT_SAPLRHA0_001 , perform manager logic for change-pointers only if flag eq space.

following logic should be followed :

a.) IDOC_DATA fill contains the 1001 records.

b.) loop at idoc_data.

read each record and determine 0001 infotype for all employees with new manager(as described in my first reply). append the 0001 records into idoc_data_temp.

c.) process each record by record in idoc_data.

d.) after the endloop. move all the records from idoc_data_temp to idoc_data.

now idoc_data will contain only 0001 records no 1001 records.

e.) again loop at idoc_data, perform manager pernr logic.

The change-pointer process is just overriding the standard process and manipulating custom records.

this is the one way of achieving the solution.

The other solution to achieve change-pointers is to perform lot of customization.

1.) create a custom program to read the change-pointers from bdcpv table to read the unprocessed records for message type hrmd_a.

2.)create infotype 0001 records from 1001 data.

3.) also perform manager pernr logic for 0001 records as we are not calling standard transaction(master_idoc_create_smd_hrmd).

4.) follow the logic in the sample program to create idocs.

FUNCTION ZSKIT_CREATE_IDOCS.

*"----

-

---

""Local interface:

*"----

-

---

DATA:

*·······control·record·for·the·IDoc

IDOC_CONTROL LIKE EDIDC,

*·······data·records·for·the·IDoc

T_IDOC_DATA LIKE EDIDD OCCURS 0 WITH HEADER LINE,

*·······table·for·the·IDocs·created·by·MASTER_IDOC_CONTROL

T_COMM_CONTROL LIKE EDIDC OCCURS 0 WITH HEADER LINE,

*·······partner·type·for·logical·system

C_PARTNER LIKE EDIDC-RCVPRT,

*·······help·variable·for·the·check·if·an·IDoc·has·to·be·created

H_CREATE_IDOC.

*·variables·specific·for·this·example

DATA:

*·······field·strings·with·IDoc·segment·structure

E1XITEM LIKE ZSKILL_CAT occurs 0 with header line,

*·······data·to·be·put·to·the·control·record

C_MESSAGE_TYPE LIKE EDIDC-MESTYP VALUE 'XAMPLE',

C_BASE_IDOC_TYPE LIKE EDIDC-IDOCTP VALUE 'XAMPLE01',

*·······segment·types·to·be·put·to·the·data·record·table

C_HEADER_SEGTYP LIKE EDIDD-SEGNAM VALUE 'E1XHEAD',

C_ITEM_SEGTYP LIKE EDIDD-SEGNAM VALUE 'ZSKILL_CAT'.

E1XITEM-SKILL_ID = '12345678'.

E1XITEM-SKILL_TYPE = 'SKI'.

E1XITEM-SHORT_TEXT = 'Test'.

E1XITEM-LONG_TEXT = 'Test skill'.

E1XITEM-TENANT_ID = 'check1234'.

E1XITEM-BEGDA = sy-datum.

E1XITEM-ENDDA = sy-datum.

E1XITEM-SKILL_UP = '01234567'.

E1XITEM-SKILL_DOWN = '3456789'.

append E1XITEM.

clear E1XITEM.

E1XITEM-SKILL_ID = '12345678'.

E1XITEM-SKILL_TYPE = 'Test'.

E1XITEM-SHORT_TEXT = 'Check'.

E1XITEM-LONG_TEXT = 'check skill'.

E1XITEM-TENANT_ID = 'test1234'.

E1XITEM-BEGDA = sy-datum.

E1XITEM-ENDDA = sy-datum.

E1XITEM-SKILL_UP = '01234567'.

E1XITEM-SKILL_DOWN = '3456789'.

append E1XITEM.

clear E1XITEM.

*···put·the·application·item·record·to·the·IDoc·segment

loop at e1xitem.

*···append·record·to·IDoc·data·table

T_IDOC_DATA-SEGNAM = C_ITEM_SEGTYP.

T_IDOC_DATA-SDATA = E1XITEM.

APPEND T_IDOC_DATA.

ENDLOOP.

idoc_control-rcvprt = 'LS'.

IDOC_CONTROL-RCVPRN = 'DI2440'.

IDOC_CONTROL-MESTYP = 'ZSKIT'.

IDOC_CONTROL-IDOCTP = 'ZSKIT'.

CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE'

*·in·update·task···"if·application·document·is·posted·in·update·task

EXPORTING

MASTER_IDOC_CONTROL = IDOC_CONTROL

TABLES

COMMUNICATION_IDOC_CONTROL = T_COMM_CONTROL

MASTER_IDOC_DATA = T_IDOC_DATA.

*exceptions

*···········error_in_idoc_control··········=·1

*···········error_writing_idoc_status······=·2

*···········error_in_idoc_data·············=·3

*···········sending_logical_system_unknown·=·4

*···········others·························=·5.

*·A·commit·work·has·to·be·done.·It·could·also·be·done·in·the·calling

*·application.

COMMIT WORK.

READ TABLE T_COMM_CONTROL INDEX 1.

IF SY-SUBRC <> 0.

*·no·IDoc·was·created,·you·can·react·here,·if·neccessary

ENDIF.

ENDFUNCTION.

5.) also set the change-pointers records as 'processed' status using standard function module.(search for function module starting like change_pointers_read_mode_set)

Please decide between 2 solutions .

Also revert back for any concerns.

Regards,

Senthil

[Former Member · Accepted solution]

Again, a very big thank you! This is exactly the kind of help I was looking for. Br, Kenneth