Lesson 3 of 5
Status handling
9 min
Listen to this lesson
Every step an IDoc takes adds a status record. Reading statuses is the core skill for anyone who supports or tests IDoc interfaces. You do not need to memorize all of them; you need to know the handful that appear every day, which ones mean "waiting", which mean "failed" and which mean "done".
Status numbers are split by direction: outbound statuses use the low numbers and inbound statuses use 50 and above. The display transactions show a traffic light per status group: green for success, red for error and yellow for "in process or waiting for a decision". Your system can show the full list of status values with their texts in the IDoc documentation and status maintenance; check there for codes this lesson does not cover.
Statuses you will see every day
| Status | Direction | Meaning | What to do |
|---|---|---|---|
| 01 | Outbound | IDoc created | Usually passes quickly; if it stays, check the outbound processing |
| 30 | Outbound | Ready for dispatch (ALE service) | Waiting for the dispatch job when the profile collects IDocs (program RSEOUT00) |
| 03 | Outbound | Data passed to port OK | Left SAP. Check the middleware and partner for the next hop |
| 02 / 29 | Outbound | Error passing data to port / error in ALE service | Check port, RFC destination and partner profile |
| 12 | Outbound | Dispatch OK | Set after the receiving system confirms tRFC receipt, when program RBDMOIND runs; without it, IDocs stay in 03 |
| 50 | Inbound | IDoc added | Received; processing follows |
| 64 | Inbound | IDoc ready to be transferred to application | Waiting; when the profile uses background processing, the job (program RBDAPP01) posts it |
| 51 | Inbound | Application document not posted | The posting failed: read the status message, fix the cause, reprocess |
| 53 | Inbound | Application document posted | Success: follow the link to the posted document |
| 56 / 60 | Inbound | IDoc with errors added / syntax error | Structure or partner problem: check partner profile and IDoc type |
| 31 / 68 | Outbound / inbound | Error, no further processing | Closed deliberately; only with a documented decision |
| 32 / 33 and 69 / 70 | Outbound and inbound | IDoc was edited / original of an edited IDoc | Audit trail of a manual change (32/33 outbound, 69/70 inbound) |
Common IDoc statuses. The list is not complete; check status texts in your own system.
- 50 IDoc addedInbound ORDERS IDoc arrives from the middleware
- 64 Ready for applicationWaits for immediate processing or the background job
- 62 Passed to applicationThe posting function has been called
- 53 PostedSales order created; the status message names it
- or 51 Not postedThe posting failed; the message says why, such as a blocked customer
Reading a status 51
Status 51 is the one you will see most. It means the IDoc arrived and was handed to the application, but the application refused to create the document. The status record carries the application's error message, the same message a user would see when entering the document by hand: material not found, customer blocked for sales, pricing error, posting period closed. Many inbound functions also write an application log you can open from the status record for more detail.
Classify every 51 before you act. The cause is usually one of four things: master data (the material or customer is missing or blocked), configuration (a sales area or document type is not set up), mapping (the middleware put the wrong value in a field) or partner data (the partner sent something wrong). The class decides who fixes it.
- Does the error name a master data object (material, customer, supplier, price)?Yes → master data owner fixes it, then reprocess · No → next question
- Does the error name configuration (sales area, document type, period)?Yes → functional consultant fixes it via transport · No → next question
- Is the value in the IDoc different from what the partner sent?Yes → mapping defect for the integration team · No → next question
- Is the partner's value itself wrong?Yes → ask the partner to correct and resend; close the IDoc with a documented decision · No → escalate
What would you do?
An IDoc in CMQ shows status 64 for two hours. The tester wants to raise a defect against the sales order interface. What should he check first?
- Outbound statuses are low numbers; inbound statuses start at 50.
- 53 means posted, 51 means not posted, 64 means waiting for the application, 03 means passed to the port.
- Classify every 51 as master data, configuration, mapping or partner data; the class names the owner.
- Never change a status to hide an error; use 68 (inbound) or 31 (outbound) only with a documented decision.
Check your understanding · not graded
Lesson check
1. What does inbound status 64 mean?
2. A status 51 message says the customer is blocked for sales. Who should fix it?
3. Outbound status 03 tells you what?