Lesson 4 of 6
Partner profiles: inbound parameters
9 min
Listen to this lesson
Inbound parameters tell SAP what to do with an IDoc that arrives from a partner. The key fields are the same as outbound: partner number and type, optional partner function, message type, optional message code and function, and the test indicator. If no inbound row matches the control record of an arriving IDoc, the IDoc interface cannot pick a process code. The IDoc is saved with status 56 (IDoc with errors added) and a work item goes to the IDoc administrator.
Great Lakes' inbound ORDERS row
| Field | Value | Notes |
|---|---|---|
| Partner / type | 17100001 / KU | Must match the sender partner in the IDoc control record that PO builds |
| Partner function | blank | Optional; Contoso leaves it empty so the row matches regardless of the function sent |
| Message type | ORDERS | Purchase orders from the customer |
| Process code | ORDE | Calls function module IDOC_INPUT_ORDERS, which creates the sales order |
| Syntax check (cancel processing after syntax error) | Set | An IDoc that breaks the ORDERS05 structure stops with a syntax error instead of posting partially |
| Processing | Trigger immediately | The order is created as soon as the IDoc arrives; the alternative is Trigger by background program |
| Permitted agent | O2C EDI desk position | Overrides the general profile's agent for this message only |
Great Lakes Fleet Services' inbound partner profile row in CMP.
You can see which process codes exist for a message type with the F4 help on the field, or for all messages in WE64. Process code ORDE is the standard for new orders; order changes (message type ORDCHG) use ORDC, which calls IDOC_INPUT_ORDCHG. Inbound process codes are maintained in WE42, where each one points to a function module (or a workflow task), and WE57 declares which message and basic types that function module accepts.
Message code, message function and the test indicator
Most rows use only the message type, but the key has two optional refinements. A message code or message function lets one partner send the same message type for different purposes, each with its own process code, for example a returns variant of ORDERS. The test indicator is part of the key too: if Great Lakes' middleware marks an IDoc as a test, SAP looks for a row with the test flag set, and if only the productive row exists the IDoc ends in status 56. Contoso keeps test and production traffic in separate systems (CMQ and CMP) instead of using test rows, and tells PO never to set the flag, so one row per message is enough.
Immediate or background processing
Trigger immediately starts the process code as soon as the IDoc is saved. Trigger by background program leaves the IDoc in status 64 (IDoc ready to be transferred to the application) until report RBDAPP01 processes it, typically as a scheduled job and optionally in packets and in parallel. SAP's guidance for packet processing with RBDAPP01 is a packet size of roughly 20 to 100 IDocs. Background processing protects dialog resources during peaks and lets you control timing; immediate processing gives the partner the fastest response. Contoso uses immediate processing for Great Lakes' orders, because the 855 is due within hours, and would switch to background processing only if Monday batches started to compete with users for work processes.
Errors, agents and the two kinds of failure
There are two families of inbound errors, and they reach people in different ways. IDoc interface errors, such as status 56 (no partner profile) or a syntax error, are handled by the IDoc interface's exception handling with system process codes like EDII and EDIY; the work item goes to the permitted agent from the partner profile, or to the IDoc administrator if the partner is not known. Application errors, status 51 (application document not posted), come from the posting function module, for example a missing customer-material info record. For those, the application generates the work item itself.
| Status | Meaning | Who acts | Typical fix |
|---|---|---|---|
| 56 | IDoc with errors added: no matching inbound partner profile | IDoc administrator (Theo's team) | Create or correct the WE20 inbound row, then reprocess in BD87 |
| 60 / 26 | Syntax error inbound / outbound | Integration team | Correct the map or the IDoc type assignment |
| 64 | Ready to be passed to the application | Nobody, if RBDAPP01 is scheduled | Check the background job if IDocs wait too long |
| 51 | Application document not posted | Permitted agent (O2C EDI desk) | Fix master data or configuration, then reprocess |
| 53 | Application document posted | Nobody | Keep as evidence |
What would you do?
On the first day of integration testing in CMQ, Great Lakes' test 850 arrives as an ORDERS IDoc with status 56. The WE20 profile for KU 17100001 exists with an ORDERS inbound row. What is the most likely cause?
- An inbound row needs partner, message type and a process code (ORDE for ORDERS, ORDC for ORDCHG); no match means status 56.
- Trigger immediately posts at once; trigger by background program leaves IDocs in status 64 for RBDAPP01.
- Interface errors (56, syntax) go through IDoc exception handling; application errors (51) come from the posting program.
- Permitted agents in the profile decide who gets the work item; use positions, not individuals.
Check your understanding · not graded
Lesson check
1. Inbound IDocs fail with status 56. What is the most likely configuration gap?
2. Which report processes inbound IDocs left in status 64 by "Trigger by background program"?
3. Which process code is typically used for inbound sales orders from ORDERS IDocs?
4. Who generates the work item for an inbound IDoc in status 51?