Lesson 2 of 5
IDocs for testers
10 min
Listen to this lesson
IDocs are still at the heart of many SAP integrations, especially EDI with suppliers and customers and distribution of master data. A tester who can read an IDoc and its status can confirm in minutes whether an interface worked, and can point developers to the exact segment and message when it did not.
Three kinds of record
The message type says what business document it is (ORDERS for a purchase order, INVOIC for an invoice, DESADV for a shipping notification). The basic type defines the segment structure, and extensions add customer segments. The data records hold the fields: for a Contoso order, the header segments carry the PO number and currency, the partner segments carry the supplier and ship-to, and the item segments carry CMC-RTR-200, 500 pieces and the price.
Status codes a tester must know
| Status | Direction | Meaning | Tester's reading |
|---|---|---|---|
| 03 | Outbound | Data passed to port OK | The IDoc left SAP; check the next hop |
| 30 | Outbound | IDoc ready for dispatch | Waiting to be sent, often by a scheduled job |
| 02 | Outbound | Error passing data to port | Not sent; usually a port or connection problem |
| 64 | Inbound | Ready to be transferred to the application | Received, not yet processed; may be waiting for a job |
| 53 | Inbound | Application document posted | Success; find the created document |
| 51 | Inbound | Application document not posted | Business error; read the status message |
Common IDoc status codes. Your system's full list is in the IDoc status maintenance (WE47).
Tools for testers
WE02/WE05: IDoc lists. Select by date, message type, partner and direction; open an IDoc to see control, data and status records.BD87: status monitor. IDocs grouped by status, with the error message and the option to reprocess after the cause is fixed.WE19: test tool. Create a test IDoc, often by copying an existing one, edit segment values and start inbound processing. SAP's documentation recommends it for testing inbound processing.WE20: partner profiles. Shows which message types are set up for which partner and how they are processed.
Proving an inbound IDoc worked
- Find the IDoc in WE02 by message type ORDERS, partner Great Lakes Fleet Services and direction inbound.
- Check the current status is 53. If it is 64, processing has not run yet; if 51, read the message.
- Open the status 53 record: the message usually names the document created, for example sales order 1000457.
- Display that sales order and compare it with the IDoc's segments: customer, ship-to, product, quantity, requested date, price if sent.
- Check the follow-on: did the order trigger the expected confirmation back to the customer?
When an inbound IDoc fails with 51, the status record holds the application's error message, such as an unknown product or a blocked customer. Fix the cause, typically master data or mapping, and reprocess the same IDoc in BD87, rather than asking the partner to resend. Editing IDoc data directly is technically possible but leaves an audit trail and should follow your project's controlled procedure; in production it is often restricted.
- Is the inbound IDoc in status 53?Yes → open the status record, find the created document and compare it with the segments · No → next question
- Is it in status 64?Yes → received but not processed: check the scheduled processing job before logging a defect · No → next question
- Is it in status 51?Yes → read the status message, fix the cause in master data or mapping, then reprocess the same IDoc in BD87 · No → check WE47 for the meaning of the status
- After reprocessing, is it now 53 with the right document?Yes → test passes · No → log a defect with the IDoc number, status message and segment values
For outbound IDocs, the proof runs the other way. Start from the business document, such as PO 4500002210, and check that its output was processed and created an IDoc. Open the IDoc and compare its segments with the PO: supplier, items, quantities, prices, delivery dates. Then follow the IDoc into middleware. If the partner sends back an order confirmation, find that inbound message as well and check that it updated the PO's confirmation data.
- Business documentPurchase order 4500002210 for CMC-RTR-200 from Lakeside Components.
- Output processedThe PO's output creates an outbound ORDERS IDoc.
- IDoc checkedStatus 03, and segments match the PO: supplier, items, quantities, prices, dates.
- MiddlewareFollow the message to the partner in the middleware monitor.
- Confirmation backThe inbound order confirmation updates the PO's confirmation data.
What would you do?
An inbound ORDERS IDoc from Great Lakes Fleet Services sits in status 51 with the message that the material is not maintained for sales organization 1710. What is the right course of action for Maria and the test team?
- An IDoc has a control record, data records in segments, and status records.
- Know the key statuses: 03 and 30 outbound, 02 outbound error, 64 waiting, 53 posted, 51 not posted.
- Use WE02/WE05 to display, BD87 to monitor and reprocess, WE19 to test inbound processing, WE20 for partner profiles.
- Status 53 proves a document posted; compare it with the IDoc to prove it is right.
Check your understanding · not graded
Lesson check
1. Which IDoc record holds the message type, partner and direction?
2. What does inbound status 53 mean?
3. Which transaction lets you reprocess an IDoc after fixing the cause of a 51 error?
4. Which tool creates and edits a test IDoc to start inbound processing?