Inbound IDOC not getting generated

[Former Member]

Dear Experts,

I am MM-functional consultant, while suporting one process I came across one issue in which an Outbound IDOC is created via PO output and this in return creates SO.

I understand that there is one outbound IDOC and it created another Inbound IDOC corresponding to earlier IDOC. Both IDOC can be seen as related IDOC's in BD87 if we check the Outbound IDOC.

In my case Outbound IDOC is procesed and is green but the corresponding Inbound IDOC is not generated. I can manually trigger the Inbound IDOC using T-Code WE19 and the SO is generated. But with this process I cannot see both IDOC as related one's in BD87 while checking the Outbound IDOC.

This process is working well in other environments/system.

Plese advise where should I look for cause.

Thanks

Manish.

[vadimklimov]

Hello Manish,

What is the outbound IDoc's status for the successful IDoc? Is it '03'? If so, this only means that the IDoc was successfully sent from ALE layer to the corresponding communication layer (dispatched to the port), but doesn't reflect status of communication (e.g. if corresponding transaction was actually sent from the sender system and was received by the receiver system).

Thus, it would be recommended to:

1. Check status of corresponding transaction at RFC level in the sender system (if the scenario is using transactional RFC - via tx. SM58, if queued RFC - via tx. SMQ1). If there are erroneous RFC transactions for the transmitted IDoc, further analysis should be done in RFC area (please send details of the RFC error if this is the case).
2. If transaction was successfully processed in RFC layer, can you please check inbound IDocs in the receiver system and let me know if you find any of them and in which status they reside?

Regards,

Vadim

[Former Member]

This was error I saw in SM58

User is locked. Please notify the person responsib le

Message no. SR053

[vadimklimov]

Hello Manish,

The error message clearly indicates the root cause: in the receiver system, please check the user account that is used for affected RFC calls and unlock it, if possible and allowed by your security team. If unlocking that user account is not possible, please replace the user in the employed RFC destination maintained in the sender system with the one that is unlocked and has sufficient authorizations in the receiver system.

Regards,

Vadim

[Former Member]

The message does not mention the user ID, Is there any way to check this user account?

[Former Member]

Please check with BASIS, they will help you, it can be service user.

[vadimklimov]

Hello Manish,

In transaction SM58, you should be able to see RFC destination that is used by the caller system to access called system - for each erroneous or executing tRFC entry, this will be seen in the column 'Target System'. The identified RFC destination should be then checked in transaction SM59 (or you reach it by double clicking on the target system name directly in SM58). There, please check maintained user on the tab 'Logon & Security'. On this tab, you will either be able to see the specific user that is maintained in the destination and that is used by caller to authenticate itself in the called system, or, if the checkbox 'Current user' is active, then the RFC call coming via this RFC destination to the remote system, will be performed in the context of the same user of as the one invoking RFC call from caller system - the one that can be ideitified from the column 'Caller' in SM58.

Regards,

Vadim