Multiple changes per HMRD outbound IDoc

[former_member185932]

We are currently implementing HR (SAP ECC 6.0) and having a problem with HRMD outbound IDocs.

Currently the system is creating a change pointer each time an Employee record is changed - we then run RBDMIDOC for the message type and it creates one IDoc for all changed employees using message type HRMD_A07.

However, we'd like to have one IDoc per employee change - so if 10 employees are changed we get 10 IDocs. Is this possible? (The reason is that the recipient system will send an ALEAUD message for each IDoc and we want to be able to identify the specific employee that failed in the event of any errors).

I think the problem is caused by the message type HRMD_A07 having a maximum of 9999999999 E1PLOGI segments. We don't want to create a bespoke message type so any suggestions would be appreciated.

Thanks and regards,

JB

[Former Member]

I don't think there is standard program to handle the scenario. But my suggestion is to create Z Report.

Inside the Z report the call the Standard function module

CHANGE_POINTERS_READ which will return the change pointers, from the list of change pointer get the objects for which IDOC needs to be generated.

With this data call the standard report RHALEINI, in a loop for each employee.

The report will generate an IDOC for each call. U can check whether the IDOC is generated or not, by importing values from the memory ID COMM_HRMD_A into table COMM_CONTROL. if IDOC is generated successfully, call the functon module CHANGE_POINTERS_STATUS_WRITE to update the status of the change pointers.

This logic will Useful. Kindly award points, if satisfies ur requiement

With regards

K.Varadharajan

[MarcelloUrbani]

I had the very same problem, and I found a (mostly standard) workaround:

transaction OOALEBSIZE let you set the maximum number of objects per IDOC.

Works smoothly, but has two drawbacks:

1)It'a not specific to HRMD_A, it may affect every single outbound IDOC generated on that system

2)There's a warning that says it's a standard parameter which may be altered by upgrades or plugins, so it has to be checked everytime you install one

Best regards

Marcello Urbani

P.S. we had a report like the one proposed by Varadharajan, and worked pretty well for some time, but lately my colleagues didn't like the generated IDOCs for some reason I'm not aware of.I think you can get the desired effect with rhaleini anyway, but you should be careful about how you run it.