Account <account_number> is currently blocked by user RFC <username>.

[former_member193350]

Hello Experts,

I am having one issue that when the CR is getting final checked approved, the idocs are failing at ECC end with the error as "Account <account_number> is currently blocked by user RFC <username maintained at MDG Hub system>.

Strangely this error doesn't come every time, but like 4-5 out of 10, so not sure how to debug this issue.

Note:- This is not only happening with the MDG workflow but also happening when I even tried to manually processed the vendor from BD14.

Could anyone please provide any help/inputs.

Any useful help will be appreciated.

Thanks

Regards

Prateek Agarwal

[former_member603451]

Hello Prateek,

while this is an usual issue with Idoc processing, you can attempt to resolve it yourself by implementing following.

1. If you have a middleware application for Idoc transfer, make sureyou apply sequencing in your middleware, so that Multiple message types using the same vendor account are sent one after the other. the usual sequence will be ADRMAS followed by CREMAS.

2. If the sequencing is already in place and still facing an issue, schedule a batch job with standard program RBDMANI2 with some processing sequence of around 5 to 10 mins. This will make sure the Idocs are reprocessed automatically if they are locked by RFC user.

hope this helps.

thanks

Rahul

[Former Member]

Hi Prateek,

Above error will come IDocs will go in bulk to destination system.

Just configure serilization of IDocs and your error will be gone.

Please find below link for serilization :

SAPTechnical.COM - Serialization of IDOC Message type

Regards,

Sudhir Wakodikar

[former_member193350]

Hi Sudhir,

Thanks for the response.

Actually ,In our case we dont have the bulk scenario and this problem is occurring even when we are changing a  single vendor and a corresponding single idoc gets generated.

Also, when we are processing a single vendor from BD14, this problem occurs.

Regards

Prateek Agarwal

[Former Member]

Hi Prateek,

Yes because first IDoc processing is not completed and next IDoc reaches that why its showing lock,

Try to implement serilization, i guess that will solve your issue.

Thank you..

Regards,

Sudhir Wakodikar

[former_member193350]

Hi Sudhir,

Can you please help me know the idoc sequence for MDG-S scenario like CREMAS or ADREMAS which one will come first.

Regards

Prateek Agarwal

[Former Member]

ADRMAS.

[Former Member]

Hi Prateek,

First ADRMAS then CREMAS.

please update whether your issue got resolved or not with above solution.

Thank you..

Regards,

Sudhir Wakodikar

[former_member193350]

Hello Experts,

Still after performing the serialization settings, I am  getting the below error message with cremas:-

Account <account number> is currently blocked by user <sending system>.

This issue happens intermittently.

Any inputs will be rewarded.

Regards

Prateek

[Former Member]

Hi Prateek,

This could be due to the processing of same Account number by two different consequent IDOCs.

One suggestion could be just try and check changing the output mode from "Collect IDocs" to "Transfer IDoc Immed." in the Partner Profile setting in the sending side.

Also, similarly check whether "Trigger Immediately" is selected on the receiving side in the Partner Profile.

Because "Collect IDocs" or "Trigger by background program" will try to process both the IDOC's at the same time involving same Account number, resulting in interlocking.

[former_member193350]

Hi

Thanks for the response.

In the partner profile settings for both sending and receiving system message type is selected as Trigger Immediately only.

But still facing this issue.

Regards

Prateek

[former_member206605]

Hello Prateek

This is a SAP bug. Even we faced this issue. You can raise OSS. You will get the resolution through correction note.

Kiran

[Former Member]

Hi Kiran Can you provide OSS number?

[former_member206605]

Its -  974504 Inconsistencies in link tables of master data sync.

But suggest to raise OSS with SAP as well. With the above note, our problem is resolved for some extent not 100%.

Kiran