Problems with modified HRMD* idocs? New tool for ALE in HCM helps to detect conflicts!
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.
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:
🙂 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!