Problem with additional actions and HR_MAINTAIN_MASTERDATA

[Former Member]

Dear experts,

I'm using HR_MAINTAIN_MASTERDATA to enter personnel actions into infotype 0000. Additional actions is on, when entering actions for the same date in PA30 this works fine. All actions are entered in IT0302 (i.e. all have P0302 = 'X' in table T529A).

HR_MAINTAIN_MASTERDATA is used in a report that receives data (actions) from an external interface. Assume I receive two actions for the same date (call them ZA and ZB). When I try to enter both actions in one run (by two sequential calls to HR_MAINTAIN_MASTERDATA) the first action ZA is overwritten by the second ZB and does not appear in IT0302. For the first call the MODIFIED_KEYS table has 2 entries (0000 and 0001) whereas for the second call MODIFIED_KEYS contains only an entry for infotype 0001.

When I run the interface again, it detects the missing action ZA and tries to enter the action again. In the second run this works, IT0302 then contains ZB with SEQNR 000 and ZA with SEQNR 001 (which is now the wrong order, of course).

Do you have any ideas, why the first action is overwritten and not properly moved to IT0302 in the first run?

I've tried LUW_MODE 1 and 0 with COMMIT WORK AND WAIT after each call, but no success. Could this be related to any kind of buffering?

Thanks in advance!

Regards,

Daniel

[Former Member · Accepted solution]

Hi Daniel,

Are both your action's ZA nad ZB type of opertaion same? ie. INS?

You said if you do from PA30, actually you shld be running actions from PA40, ok however the point is

the way PA40 works is based on infogroups, you must try to mimic that thru your FM.

for ex: if u look at this [link|http://cid-59a30bdab5c23882.skydrive.live.com/self.aspx/Public/hire.jpg?#comments] its a Hire action where all operations are INS meaning Create.

and if you look at this [link|http://cid-59a30bdab5c23882.skydrive.live.com/self.aspx/Public/change%20in%20pay.jpg] its a change in pay action where you are editing only the Infotype that changes because of that action with operation COP.

i wld like to know is this how you are executing both the actions. I wld assume both your actions have same set of infotypes with INS for all in both cases. hence getting over written.

Try doing additional actions with above scenario and see if it works. by Updating not creating Infotypes, in your second action.

also please ensure you are commiting data after ZA and again after ZB.

[harishtk1]

I would recommend NOT using HR_MAINTAIN_MASTERDATA or HR_INFOTYPE_OPERATION for updating IT 0000 (including 0302) and IT 0001.

Please use a BDC for these two infotypes. Feel free to use above FMs for any toher infptype.

I am not an ABAP expert, so i cannot tell you how to over come these issues, but in my experience as a functional consultant, there is no solution for issues created by these function modules when updating IT0000/0001, and issues are several. Even if you test this succesfully, the update may still fail at a later stage and all the information you will get from SAP is " A complex error has occurred".

YMMV.

Hope this helps.

[Former Member]

Hi Harish,

Its not true that those two FM will create issues,many are using it successfully for hiring and employee even.If the process is clear and if impliemented correctly it shldnt give any problem.

Its matter of learning.

and Daniel, pls take a look at this ongoing discussion at this [thread|; you will know why is it important to to run two different action types.

[Former Member]

Hello Hruser,

Thanks for your answer. Perfect analysis, perfect answer. Indeed, I tried to enter both actions with INS!Changing the second (infotype) action ZB to COP resolved my problem.

Thanks a lot!

@Harish: The 'Complex application error' is really annoying. But Hruser is right, it can be resolved by a thorough analysis. My tip: Switch dialog_mode to 2 to see what's happening. The complex application error is usually triggered by an upcoming dialog screen, which cannot be processed in dialog_mode 0.

Best Regards,

Daniel

P.S. Is there any rule of thumb when to use which action. I've already experiences some problems with LIS9 when I tried to delimit an infotype. I finally used MOD to delimit an entry...

[Former Member]

Hi Daniel,

Good to know it worked. Coming to ur PS question.

P.S. Is there any rule of thumb when to use which action. I've already experiences some problems with LIS9 when I tried to delimit an infotype. I finally used MOD to delimit an entry...

Delimit is an easy concept, but multiple ways of doing it so to say..its my personal opinion that to fully understand Delimits functionality and how it works its important to understand [Time constraints |http://help.sap.com/erp2005_ehp_02/helpdata/en/48/35c9f24abf11d18a0f0000e816ae6e/content.htm]of infotypes .

from SAP GUI, PA30 you can delimit a record manually by changing the default end date. (if permitted by time constraints) when you change the end record the record gets delimited.

another way is to use Delimit functionality which again essentially does the same, you give a delimitaion date and the record gets delimited to that day.

This Functionality is automatically done by some time constraints for ex: TC 1, when ever a new record is created, the old record gets demilited to a day prior to the creation of new record. for these scenarios where you want to delimit because there is going to be a new record you can use MOD.

but say an employee is going to be terminated, all his active infotypes such as Basic pay etc needs to be delimited but with out creating new record. in which case you HAVE to use LIS9.

neverthiless i see no issue using LIS9 to delimit in any scenario where you want to delimit.Only thing is you would need multiple calls if done using an FM.

i hope it is clear.