Skip to Content
author's profile photo Former Member
Former Member

Purchase requisitions idoc issue


We have found a new interesting thing happening in ECC.

IDOCs does not get processed due to PurReq is being processed.

Then the IDOC goes into status 51 and can no longer be processed by the batch jobs that is running for status 64.

1) Is it possible to keep the status as 64 for these types of errors?

2) If not is it possible to reset these IDOCs from 51 to 64 in a batch job

3) or is it possible to get the batch job to run for IDOCs with status 51?



Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

2 Answers

  • author's profile photo Former Member
    Former Member
    Posted on Nov 24, 2011 at 04:57 PM

    Schedule report RBDMANIN for periodical background processing in transaction SM37.

    Create a meaningful jobname

    Create a job-variant to limit your selections by date, logical message-type, partnernumber, partnertype

    Mark the checkbox "import in the background" in the selection-screen of the variant

    Using the parameter error status, you can define in the report that IDocs with the error message for a blocking error should be automatically subsequently posted.

    Make sure that the batch-user has sufficient authorizations to perform the posting-transaction.

    General information can be found here

    Please check the following thread when the IDOCS should be processed in a specific order

    RBDMANIN execution not ordered by time.

    Edited by: D.Leinweber on Nov 24, 2011 5:57 PM

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Nov 24, 2011 at 05:39 PM


    new !

    that's just the normal behaviour since... almost the beginning of IDoc history.

    1. yes. program RC1_IDOC_SET_STATUS.

    2. yes, but that's not recommanded, as your idoc has been already processed, and it said to you "I cannot update this object because someone or something is currently treating this same object".

    if it's a permanent error like (this customer does not exist), that means with a background process (with a too short frequency) you will overload your system for nothing with a treatment like:

    "idoc 64 -> 51" + "background change: 51-> 64" + "reprocess: 64 -> 51", etc...

    when it's one idoc, it's ok, but if a day you a complete source files with several idocs which are in error.... you will reprocess them several time to say to you the same thing "cannot update because customer does not exist" (for instance).

    3. yes. RBDMANIN in background, or tx BD87 in foreground.

    According to me, it's better to use BD87 as it's a human you can analyze and decide to retreat the data.

    Use background program only if you are sure that the data (in error) was sent a 2nd time after. In your case of purch req. i did not recommanded that.

    Have a look a that:

    Idoc1: role = change value with A on pruch req 123. This idoc is in error (like in your exm: already processing by another...)

    Idoc2: role =change value with B on purch req 123. This idoc arrives 5 min after idoc1. but this times the other processing is finished, and so ecc can integrate this idoc2. So in your systm you have value "B".

    And you with your background process which runs (every hour, for instance), one hour after your Idoc2, you will retreat idoc1, and so now for your purch req, the value is "A"... and no more "B" which was the last value sent by your source system. => Problem !

    4. So why not use it, but be clever/smart before to use such a background retreatment. Estimate the pro/cons.



    P.S : it's because we can, that we have to do it.

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.