Inserting infotype 2001 using HR_INFOTYPE_OPERATION

[Former Member]

Hi,

Has anybody experienced the problem that the call to HR_INFOTYPE_OPERATION returns a key and no error messages but the actual records are not updated in the pa table ?

I'm experiencing this problem right now with trying to insert infotype 2001 records.

Even when I use dialogmode 2 and process the records on the foreground they all look ok and SAP gives no error when saving the records but also on the foreground, table pa2001 is not updated.

Hereby a piece of the code I use:

Form YGRM_create_it2001.

DATA: L_P2001 TYPE P2001.

*DATA: L_P2001 like PA2001.

*DATA: L_P2001 type pa2001.

DATA: L_CAPFODEKEY TYPE BAPIPAKEY, Return type BAPIRETURN1.

*

L_P2001-PERNR = VA_pernr.

L_P2001-INFTY = '2001'.

L_P2001-SUBTY = '100'.

L_P2001-ENDDA = VD_currentdate.

L_P2001-BEGDA = VD_currentdate.

L_P2001-SEQNR = VN_SEQ.

L_P2001-AEDTM = sy-datum.

L_P2001-UNAME = sy-uname.

L_P2001-BEGUZ = VD_beginhour.

• 800 secs = half an hour

L_P2001-ENDUZ = VD_beginhour + 1800.

L_P2001-AWART = '100'.

L_P2001-ABWTG = 0.

L_P2001-STDAZ = '0.5'.

L_P2001-ABRST = '0.5'.

• To enqueue the selected employee

CALL FUNCTION 'ENQUEUE_EPPRELE'

EXPORTING

pernr = VA_pernr

EXCEPTIONS

foreign_lock = 1

system_failure = 2

OTHERS = 3.

IF sy-subrc = 0.

*INSERT pa2001 FROM L_P2001.

call function 'HR_INFOTYPE_OPERATION'

exporting

infty = '2001'

number = VA_pernr

subtype = '100 '

objectid = ' '

lockindicator = ' '

validityend = VD_currentdate

validitybegin = VD_currentdate

record = L_P2001

operation = 'INS'

nocommit = ' '

dialog_mode = '2'

importing

return = return

key = L_CAPFODEKEY.

*use dialog_mode '2' for foreground processing

endif.

• To dequeue the selected employee

CALL FUNCTION 'DEQUEUE_EPPRELE'

EXPORTING

pernr = VA_pernr.

Any help would be highly appriciated.

Greetings,

Ivo Aelberts.

[suresh_datti · Accepted solution]

Hi Ivo,

I don't see anything wrong with the code.. Did you try to put an explicit COMMIT WORK statement in your program (after the function call)? If that doesn't work,

You can replace the function HR_INFOTYPE_OPERATION with BAPI_PTMGRATTABS_MNGCREATION & BAPI_TRANSACTION_COMMIT

Regards,

Suresh Datti

[Former Member · Accepted solution]

Hi Suresh,

Just tried the commit, but it didn't work. Its really strange to see it work on the foreground and then looking in the pa2001 table and seeing it is not updated.

My user has sap_all on the system, so authorisation is also not a problem.

Thanks for reffering to the BAPI functions, I'l try them after our easter weekend. I'll keep you informed if that works better.

Thanks a lot for your fast reply !

Ivo Aelberts.

[Former Member]

In Absence info type(2001) the length of the subtype is 4 Character so please try use '0100' instead of '100' and then try .

[Former Member]

Hi every one,

sorry , I have problem for the Infotype 2001 also , pls answer this if you knows.

We are planning to send legacy system data of Infotype 2001 to the SAP R/3 HR system, for this we are using ‘HRSM_D01’ Idoc basic type , E1BP7011_2 segment and Standard inbound processing Function module ‘IDOC_INPUT_HRSM_SCHEDULE’ to post the data into the tables PTEXDIR and PTEX2000 then after we running Standard programe ‘RPTEXTPT’ to post the document.

Question # 1 : Is it correct way to handle Infotype 2001 data from the Legacy system to the SAP R/3 system?

If it is correct , we have error while using this FM : IDOC_INPUT_HRSM_SCHEDULE’ at

FM : HRTIM_PTEX2000_INSERT Line # 80 .

L_PTEXDIR-INFTY = '2000'. --> Hardcoded ‘2000’

In Debugging mode , we changes to ‘2001’ , then it working fine.

Question#2 : Do you have any OSSnote for the above error or what we have to do?

Question#3 : Is there any OSSnotes for Program RPTEXTPT to show the correct status list?

Thanking you,

Ram

[Former Member]

Hi,

This is a strange problem but I faced a similar problem I used a different function module to lock a person I had the same error. It worked for me when I used BAPI_EMPLOYEE_ENQUEUE/DEQUEUE.

Regards

Vick

[Former Member]

Suresh is right. You might still have the same problem.

I think you are having this problem because of the memory.

Try using 'SUBMIT ....' 'AND RETURN' command and use 'HR_INFOTYPE_OPERATION in that submitted program.

Ahmad

[Former Member]

To all who have the same problem,

I have got the solution.

The problem was I was using the form within a DYNAMIC ACTION using table T588Z for calling the form routine.

The Dynamic Actions somehow use buffers to write infotype data and these buffers were not written to table pa2001.

This problem was solved by calling form routine

PUT_INFOTYP_BUFFER(SAPFP50P). This SAP form routine writes the PA30 buffers to the tables.

Kind regards,

Ivo Aelberts.

[suresh_datti]

Hi,

First off, thanks for sharing your solution..

There must be a reason for using this function call in a Dynamic Action.. I am curious.. are you doing any computation & passing specific values to 2001?

Also, how did you figure out this buffer routine? debugging? or did SAP suggest it?

Regards,

Suresh Datti

[Former Member]

Hi Suresh,

I was a bit fast, the solution I described still cases incidental errors.

Sometimes, we have buffer problems using this solution in which case the ORIGINAL record made by the user is not saved (see below for full solution description).

I as functional HR consultant handed my work over to Vincent van der Steen, our ABAP consultant (specialised in HR ABAP) and he found the buffer routine by debugging the PA30 transaction.

Vincent is now going to use your BAPI functions, maybe they work better.

Full solution:

To get an overview of the full solution, we use a form routine to create infotype 2001-100 records (LEAVE) based upon it2001-116 records (leave HR, customer specific) created by the user.

This form routine uses the form routine I submitted to this forum for creating the infotype 2001-100 records.

I (functional HR consultant who likes to use ABAP when needed inserted a function call within table T588Z for function code 04 (create) of infotype 2001 subtype 116. This way, when a user creates a 116 record the form routine is triggered to make 100 records.

You may be thinking: Why use ABAP for this ....

Well the 100 records are not equal to the 116 records but are split in half hours. Thats why I cannot use the SAP standard functionality of table T588Z.

We do all this as workaround for a SAP bug in the SAP absence collision table, which is unable to delimit records on a hourly base.

Maybe you have more suggestions to solve this ?

Thanks for your replies !

Ivo Aelberts

[suresh_datti]

Hi Ivo,

From what I can understand it is more a timing issue than anything else.. You might still have the same problem even when you use the BAPIs. One option could be to put an explicit COMMIT WORK statement before the function call to HR_INFOTYPE_OPERATION or even a <i><b>WAIT UP TO 10 SECONDS</b></i> might help.

Regards,

Suresh Datti