Skip to Content

Failure of IDOCs getting posted

Challenges are like hard rocks. You cannot move further unless you cross them.

Dealing with our R3 XI MDM scenario, we came across a major challenge which initially was impossible to even track. But eventually when tried to trace out what was going wrong,things became much more apparent. 

Let me just start with the basics of the scenario. We were dealing with the Vendor master.The data was extracted from ECC using the client extractor program. The same was enriched and sent back to ECC system using PI as the middleware tool. We had customized the standard business content as well as standard maps depending on the requirements.


Every care was taken to see that the IDOCs got posted successfully. Inspite of thatwe faced some hurdles like incompatible cross system data types, mandatory data, incorrect field mapping etc. to name few of them. Finally when we got through fixing all of them, we came across a very different type of error. When the transaction we02 was executed in ECC,it displayed error code status 51 saying RF02K-D0130 was not an input field. This was like an ice berg for us…We were really amazed to see the error as the field had no relevance as far as MDM and PI were concerned. Realizing that it had something to deal with R3 used the transaction recorder to find out as to from where did the field come into the picture.

The field RF02K-D0130 actually is a process data field that is used to select the payment transaction view of the vendor which gives the bank related data of the vendor. Thinking that it might be dealing with batch processing, we even tried with LSMW but that too didn’t work. We reprocessed the IDOC  (T Code we19)  using a different PI user. Surprising the IDOCs got posted successfully. After spending days in gathering clues as to what could have gone wrong we finally thought of comparing the authorization of both the users. To our surprise, what we saw was that an authorization to transaction FDKUSER was not given to the PI user which was causing all trouble. The absence of this authorization was causing the IDOCs to fail on ECC side as it also contained  the payment transaction details of the vendors.  Once given,  the problem got solved.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Former Member
    I am currently seeing error when we invoke VC iview for BAPI_VENDOR_EDIT and when we try to display the data for one of the vendor it gives error in System log for FDKUSER tcode.  We tried to maintain the entry for that vendor for my userid in FDKUSER, but still giving shortdump DYNPRO_SEND_IN_BACKGROUND.  Do you know if we need to have trusted communication from BI to R3 as well as SSO?

Leave a Reply