Skip to Content
Author's profile photo Guillermo Ballesteros

Problems with modified HRMD* idocs? New tool for ALE in HCM helps to detect conflicts!

Dear community,

I bring interesting news for those of you who work with ALE idoc transfers based on HRMD_A or HRMD_ABA message types, specially if you have already done (or soon plan to do) some modifications of the data or to the structure of the default standard idocs.

For those of you who may not know, let me provide a quick recap: ALE integration in HCM is quite flexible and modifiable. HRMD* idocs are generated in the source system(s) with employees or organizational data and are transferred to the target system(s) where they are processed and saved. Already from the source and also in the target, there are many places (outbound/inbound BADIs, exits from RHALE001 enhancement, etc) where customers might add/change/remove any data according to their needs. As far as the ALE integration is flexible, it is also consistent, and in order to guarantee this consistency, some preconditions need to be taken. Sometimes, when customers are dealing with modifications in the idocs, it may happen that some standard precondition is broken, and this will lead to later problems with the idoc processing, and possibly headaches and additional work until the conflict is resolved.

Now, in order to help customers and consultants to detect and control these situations, I am happy to present you the new report:

RHALE_HRMD_ANALYZE (transaction code HRMD_ANALYZE).

Below you can find how the selection screen looks like.

/wp-content/uploads/2015/11/screenshot1_822901.png

Well, so what is the scope of this new tool?


Currently the tool is capable of automatically searching for 5 possible conflicts in HRMD* idocs which correspond to five commonly well known and documented cases. The main advantage of this is that these conflicts can be detected automatically, the affected objects are presented in the results, together with a link to the corresponding documentation (SAP Note, SAP Knowledge Base Article, etc) and therefore the time needed to solve such problems can be strongly reduced.

These checks being carried out currently are:

  • Check use of PROOF field: if this check is active, it will notify of iDocs found with this flag set to ‘X’ in E1PLOGI segment. This flag should remain empty as a requirement to guarantee that the inbound process works properly. More information can be found in KBA 2028221.
  • Check HRMD structure & T777D: if this check is active, it will be checked if the general structure common to all HRMD* idoc types is being respected. This includes the hierarchy E1PLOGI-E1PITYP-E1Pnnnn but also the segment reference customizing informed in fields IDOCS, IDOCS2, IDOCS3 is checked to match existing idoc segments. More information can be found at note 134085.
  • Check E1PITYP, E1Pnnnn dates: if this check is active, it will evaluate if the date condition explained in KBA 1795606 is being followed in the selected iDocs. These rules need to be followed for a correct storage of the data during the inbound processing.
  • Check object repeated in iDoc: if this check is active, it will check if the same object (plan version + object type + object id) is repeated in more than one E1PLOGI segments in the same idoc. This is known to potentially cause the errors described in KBA 2017393.
  • Check subtype consistency: if this check is active, the report will detect cases where the subtype is not kept constant between a E1PITYP segment and its children E1Pnnnn segments. This is a condition that needs to be considered, as explained in KBA 2004553.

And here is an example of how the resulting ALV list would look like:

/wp-content/uploads/2015/11/screenshot2_822957.png

🙂 This application has just been delivered with note 2210950 🙂


If you are interested in it, you can proceed to apply it either from SNOTE or from the corresponding Support Package, when available. Please do not hesitate to check this mentioned note for additional details.

We are open for suggestions and we are considering the possibility of adding more checks in the future. So if you have any question, feedback, comment or suggestion, please feel free to leave it in the comments section below.


Thanks for your time!

Assigned Tags

      5 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Carlos Martinez Escribano
      Carlos Martinez Escribano

      Hi Guillermo,

      Thanks a for sharing this awesome tool!. Dealing with HRMD* idocs has never been easier.

      Regards,

      Carlos.

      Author's profile photo Guillermo Ballesteros
      Guillermo Ballesteros
      Blog Post Author

      Thanks for all your support Carlos! 🙂

      Author's profile photo Sharon Cooksey
      Sharon Cooksey

      Great documentation Guillermo!! Thank you!

      Author's profile photo Former Member
      Former Member

      Thank you. This tool is much better than WE02 WE05, or WE09. I was hoping SAP would still deliver the standard naming convention T-CODE like WE* for Idocs monitoring and configuration but HRMD_ANALYZE would do. 

      Author's profile photo Guillermo Ballesteros
      Guillermo Ballesteros
      Blog Post Author

      Dear Phillip,

      Thanks for your kind words. What happens here is that the scope and origin of all these tools you mention is quite different.

      HRMD_ANALYZE has been explicitly designed for the detection of some known problems with the modifications to iDocs of HRMD_A and HRMD_ABA message types.

      On the other hand, general transactions like WE02, WE05, WE09, WE19 can be used for any iDoc type, regardless the functionality, and have a broader approach, making them very useful too, but as general tools for idoc monitoring and analysis.

      I hope this new addition of HRMD_ANALYZE tool will make things easier to customers who have introduced some specific requirement to these HRMD* iDoc types (through modification) but are then finding unexpected symptoms or errors.

      Best regards,
      Guillermo