IDoc Inbound Processing for CREMDM & DEBMDM

[michael_theis]

Hi experts,

I'd like to gather some feedback from you regarding the topic ERP IDoc Inbound Processing for CREMDM & DEBMDM. As you all know, there's currently no option to directly process CREMDM/DEBMDM IDocs in ERP. Currently you have to use PI for splitting the CREMDM/DEBMDM message into its related ADRMAS and CREMAS/DEBMAS IDocs.

My areas of interest are:

1) How satisfied are you with the current situation? Does the split work? Are there issues or problems in the current message handling? What are the Pro's and Con's from your point of view?

2) What would be the requirements for a CREMDM/DEBMDM handler? What would you expect? Maybe you have implemented something similar on project basis and could post some feedback?

One painpoint I'd see with a CREMDM/DEBMDM inbound is that you'll lose the IDoc Monitoring capabilities. The message split allows a single record tracing in the IDoc Monitor (as there is a 1:1 relation between IDocs and records). This changes for the mass processing. The monitor would display only the status of the IDoc and you'd need some other monitoring capabilities to check the results on record level. What are your thoughts about that? Is the monitoring important? Would the application log be a feasible solution for that challenge?

Additional comments are welcome, of course.

Best regards

Michael

PS: @ Matt, please contact me by mail. thanks.

[Former Member · Accepted solution]

Hello Michael,

We have also used the same PI set up for posting IDOCs through CREMDM/DEBMDM message splitting into its related ADRMAS and CREMAS/DEBMAS IDocs.

The Only issue we faced was when there was an upgrade in PI development system, so some of the config properties had changed, and because of that out IDOC was getting failed, since some of the mandatory fields for generation of that IDOC was not getting published through PI Interface.

This was taken care by making the configuration settings in PI later on.

APart from this we have not faced any such issues with this approach..As far as monitoring capabilities are concerned, we do get individual level monitoring views only.

Regards,

Shailesh

[michael_theis]

Hi experts,

thank you all for your valuable feedback so far. You confirmed my assumption that one of the nastiest issues is the IDoc split combined with the internal number range in case of Customer/Vendor creation. I'll investigate this issue during the ALE inbound for sure.

Best regards

Michael

[Former Member]

Hello ,

Here are some other pain areas regarding the message split :

1. Complicated monitoring proess & reprocessing error idocs : We have to monitor ADRMAS & CREMAS or ADRMAS & DEBMAS during inbound processing. Also we could not find any best practices to reprocess error idocs. E.g. If ADRMAS fails & CREMAS succeeds what is the impact . Also the impact if it is reveresed. We know for sure that if CREMAS fails , vendor will not be created / updated. But we could not find specific pointers for ADRMAS failures.

2. It is a tedious process to link CREMAS with corresponding ADRMAS idoc specially when SAP maintains internal number range for vendors.

3 . The process is complicated if you are managing customer or vendor contact information with contact address . We could succesfully implement the integration but it took us a while to reach end-point.

4. Splitting really does not seem to support if ERP maintains internal number range.

5. Another major issue we observed is , if ADRMAS is under process & corresponding DEBMAS or CREMAS is posted , it fails raising the message that Account is locked. Default serialization does work in ERP system . But overlap of few microseconds also cause this error.

Hope this helps !!

Please let me know if you need any other specific details since we have used MDM - ECC integration using PI to its maximum extent .

Regards

Yogesh

[Former Member]

Hi Yogesh,

Would you be able to share details how did you implement it?

Thanks!

[Former Member]

Hi Michael,

The major issue we faced when ECC was having Internal Number range for Vendor.

Basic idea before spitting CREMDM into CREMAS & ADRMAS is to have LIFNR in both CREMAS & ADRMAS.

But as we couldn't pass Vendor Number from MDM to ECC, we were losing addition address attributes of ADRMAS(Mobile Phone, Company Postal Code, Email etc), as CREMAS & ADRMAS was not getting linked in ECC.

If there would have been CREMDM Idoc processing in ECC, then this scenario was easy to handle.

And having Internal Number range in ECC is quite a normal scenario in real time.

Thanks,

Maheshwari