Different IDoc behavior between Dev and Quality

[Former Member]

Hello all,

Our team is currently experiencing an issue between our Development and Quality systems.

The system is currently configured to send an output via EDI using output type NEU whenever a PO is changed. This sends out an outbound IDoc that causes the generation of another IDoc which is inbound, and upon processing the Inbound IDoc using BD87, should save the applied changes to the counterpart Intercompany Sales Order of the PO.

This is working correctly in Development. However, in Quality it is behaving differently; instead of saving the counterpart Intercompany SO, it creates a new SO every time an Inbound IDoc is processed.

Comparing how the IDocs are generated in both systems, we noticed that Dev was using the partner profile ORDCHG, whereas Quality was using ORDERS. We assume that it is this difference that is causing the difference in behavior.

However, checking the partner number in WE20, the partner number has both ORDCHG and ORDERS configured with the same Partner Role, Message Function, etc. How does the system choose between ORDCHG and ORDERS and if ever, can this be configured?

I hope my explanation of the issue was clear.

Thank you very much, of course points will be given to relevant answers.

Regards,

Marc

[naimesh_patel]

When the subsequent Inbound IDOC is getting generated, you would need to make sure that it being created with the proper partner profile. As you have suspected, Inbound Process code ORDERS would create a new order and ORDCHG would change the order. As both message types use different process code.

ORDERS should use ORDE, to FM IDOC_INPUT_ORDERS

ORDCHG should use ORDC, to FM IDOC_INPUT_ORDCHG

In your partner profile for the inbound IDOC, you need to make sure the partner has inbound process code as ORDC.

Inbound Parameters > Inbound Options (Tab) > Process Code field

The Inbound IDOC generation program should also consider this setting. Generally the control record is populated with the details from the table EDP21.

Regards,
Naimesh Patel

[Former Member]

Hello Naimesh,

Thank you for this input. We also assumed that this would be the case, but please take a look at the following:

As you can see, there are multiple instances of each Message Type configured for the Partner Profile, and the Inbound Parameters within each are correct as well (ORDCHG has ORDC, ORDERS has ORDE). Our question would be, then, is how does the system pick which of these to choose from?

We have assumed that a user exit may be involved. Are their exits that determine this selection?

Thank you very much.

[naimesh_patel]

Since message function is used, there must be a call to the FM  IDOC_INBOUND_WRITE_TO_DB in the outbound message processing user exit. When the control record is built, a specific message function would be sent to the IDOC. Based on the setting in Partner profile, system would select the inbound processing code.

The NEU would call process code ME10 (create) / ME11 (change). User-exit EXIT_SAPLEINM_011 would be most suitable place to start. If not, check EXIT_SAPLEINM_002 or EXIT_SAPLEINM_001.

Regards,
Naimesh Patel

[Former Member]

Hello Naimesh,

Thank you very much for this input. However, we were not able to find any helpful bits of code in the three exits mentioned.

Where is the control record being built in the code? Perhaps there may be an answer there. Our instance of the FM IDOC_INBOUND_WRITE_TO_DB is being called in standard only:

Thank you very much.

[naimesh_patel]

Looks like your IDOC is being generated from the Remote call - could be from inside ECC or could be from outside ECC.

In the debugger, you would be able to see what data is coming in the control record. Based on that you would have to trace back the origin of the IDOC.

Regards,
Naimesh Patel

[Former Member]

Hi Naimesh,

It turns out that the only reason it was happening was because manually applying the output NEU in the Messages panel of the PO automatically triggers ORDERS. Our SD functional figured and it out and all is well.

Thank you for all your help.

Regards,

Marc