HR_MAINTAIN_MASTERDATA fails to delete

[former_member330884]

Hi experts,

I have a very strange situation and this might take a few passes to actually understand what I mean and what the problem is before any answers are forthcoming. Unless it's something simple, fingers crossed

Consider the following 2 scenarios.

Call HR_MAINTAIN_MASTERDATA to delete a it2002 record from a web service.

Scenario 1.

A web service class is called directly to delete the 2002 attendance record

WEB_SERVICE_CLASS_DELETE -> CREATE CLASS INSTANCE OF REQUESTED DELETE -> DELETE METHOD PASSING DATA

The data passed gets to the delete call and calls HR_INFOTYPE_OPERATION like so:

CALL FUNCTION 'HR_INFOTYPE_OPERATION'

    EXPORTING

      INFTY                       = '2002'

      NUMBER                  = me->pernr

      SUBTYPE                 = im_p2002-subty

      VALIDITYEND            = im_p2002-endda

      VALIDITYBEGIN         = im_p2002-begda

      RECORD                   = im_p2002

      RECORDNUMBER     = im_p2002-seqnr

      OPERATION              = 'DEL'

      NOCOMMIT               = 'X'

    IMPORTING

      RETURN                 = ls_return.

Which in turn, calls HR_MAINTAIN_MASTERDATA which then calls HR_MAINTAIN_MASTERDATA in dialog mode:

Line (324) of HR_MAINTAIN_MASTERDATA

CALL DIALOG 'HR_MAINTAIN_MASTERDATA' using BDCDATA mode 'N'

    EXPORTING

    PSPAR

    PROPOSED_VALUES

    LUW_MOD

    PS

    PSINFO

    PREFTAB

This works fine and never fails.

Scenario 2

A web service class is called directly to update some records and involves deleting the 2002 record attendance record before then creating a new record

WEB_SERVICE_CLASS_UPDATE -> CREATE CLASS INSTANCE OF REQUESTED UPDATE -> DELETE METHOD PASSING DATA

The data passed gets to the delete call and calls HR_INFOTYPE_OPERATION like so:

CALL FUNCTION 'HR_INFOTYPE_OPERATION'

    EXPORTING

      INFTY                       = '2002'

      NUMBER                  = me->pernr

      SUBTYPE                 = im_p2002-subty

      VALIDITYEND            = im_p2002-endda

      VALIDITYBEGIN         = im_p2002-begda

      RECORD                   = im_p2002

      RECORDNUMBER     = im_p2002-seqnr

      OPERATION              = 'DEL'

      NOCOMMIT               = 'X'

    IMPORTING

      RETURN                 = ls_return.

Which in turn, calls HR_MAINTAIN_MASTERDATA which then calls HR_MAINTAIN_MASTERDATA in dialog mode:

Line (324) of HR_MAINTAIN_MASTERDATA

CALL DIALOG 'HR_MAINTAIN_MASTERDATA' using BDCDATA mode 'N'

    EXPORTING

    PSPAR

    PROPOSED_VALUES

    LUW_MOD

    PS

    PSINFO

    PREFTAB

This fails every time without no apparent reason.

Debugging takes me all the way to the line 324 of HR_MAINTAIN_MASTERDATA and the difference is, when stepping through the code, F5 step into the CALL DIALOG line fails without an error, the debugger simply bombs out.

When the operation works in Scenario 1 it works every time and stepping into the dialog call works fine.

I compared the data going into the dialog call and it is byte for byte identical, no difference in the data. The user matches and no auth errors occur.

With testing, I did something quite strange which shouldn't really be done, I populated the LOCKINDICATOR flag on the original creation of the it2002 record, doing that allowed the delete to work every time in EVERY single scenario I could test, but then payroll will fail to process properly so that isn't an option.  The question is why, why if adding the LOCKINDICATOR flag does everything work fine yet remove it and the delete fails but ONLY in scenario 2, scenario 1 always works regardless. 

In scenario 2, as I mentioned, the debugger literally bombs out on pressing step into, no errors, no warnings, just vanishes (and the delete never happens obviously).

I am guessing some clarification will be needed here, any ideas no matter how silly appreciated, if this can be understood then i would like to be able to!

Thanks,

Malcolm

[former_member330884]

I fixed the issue although it still doesn't explain the above.

[Former Member]

Nocommit should be blank otherwise database commit won't happen .

[former_member330884]

Hi,

thanks for the reply. I did remove the NOCOMMIT and it worked fine

The remaining question is, why with NOCOMMIT included does the operation work all the time in scenario 1 if the NOCOMMIT is supposed to mean do not commit data to the database?

That aspect I do not understand. I also tested previously without the flag and could make the operation fail in some scenarios, the operation completed but the record was not deleted (and it did not fail either)

Thanks,

Malcolm

[Former Member]

Hi Malcolm ,

Maintain master data fm is like call dialog so it definitely needs commit.

Hr infotype operation internally calls maintain master data but I have seen few scenarios it does not depend on commit , it's been while I looked at code inside for now that is what I know but can dig into it and reply if needed.

Thanks ,

Sheshu

[Former Member]

Hi,

Other thing is few times it gets committed if you run in debug mode vs directly .

Thanks,

Sheshu

[former_member330884]

I understand that, but leaving the process alone the deletions were working in scenario 1.

Thanks for your help!

Malcolm

[Former Member]

Will only know if you debug I guess .

Anyways glad it worked .

Thanks,

Sheshu