IDOC_INBOUND_SINGLE — Process One Inbound IDoc with Long Record Formats
Processes one inbound IDoc using the Release-4.0 long control/data record formats. SAP documents PI_IDOC_CONTROL_REC_40, PT_IDOC_DATA_RECORDS_40, an optional commit indicator, and outputs for the created IDoc number and whether an error occurred before application processing. It is a low-level inbound framework entry point, not a business-object API.
Validated practitioner draft for IDOC_INBOUND_SINGLE: purpose, high-impact parameters, failure behavior, safe administrative use, S/4HANA position, and proof path. Exact target-release signatures are intentionally anchored to SE37 instead of guessed from a different SAP release.
Published 20 Sept 2026· 755 words
What it does
Processes one inbound IDoc using the Release-4.0 long control/data record formats. SAP documents PI_IDOC_CONTROL_REC_40, PT_IDOC_DATA_RECORDS_40, an optional commit indicator, and outputs for the created IDoc number and whether an error occurred before application processing. It is a low-level inbound framework entry point, not a business-object API. Use this function only for the technical layer it owns. Application validation, authorization, persistence, monitoring, and recovery steps around the function remain the caller's responsibility unless the official function documentation explicitly assigns them to the module.
Important parameters
Only parameters that materially change behavior are described here. Exact DDIC types, optional flags, and release-specific additions must be confirmed in SE37 before production coding.
- PI_IDOC_CONTROL_REC_40, PT_IDOC_DATA_RECORDS_40 and PI_DO_COMMIT are the documented core inputs; PE_IDOC_NUMBER and PE_ERROR_PRIOR_TO_APPLICATION report the framework result.
- Keep identifiers such as job count, log handle, IDoc number, object/subobject, client, and logical system together; names alone are rarely unique enough for safe administration.
- When the function returns both a result and technical metadata, retain the metadata in logs so support can reproduce the call.
Exceptions
The safest caller distinguishes expected negative outcomes from technical failures. Do not hide configuration, authorization, lock, communication, or database errors behind a generic success path.
- Invalid IDoc/control data, partner/process configuration errors, or misunderstanding the commit flag and application-status outcome are the main risks.
- Check the active SE37 exception list and SY-SUBRC immediately after the call.
- A technically successful administration call still requires semantic validation: confirm the returned job, log, IDoc, receiver, authorization range, or interval is the one intended.
How to call it safely
Start with the exact technical key and the narrowest possible scope. Validate current status before destructive changes, execute the function, inspect its returned handles/IDs/tables, and then verify the effect in the standard monitor such as SLG1, SM37, WE02, SM12, PFCG/SU53, or number-range administration. Never use a low-level function to bypass an application error that should be corrected and reprocessed normally.
ECC vs S/4HANA
Current SAP IDoc documentation still lists IDOC_INBOUND_SINGLE for classic inbound processing; API-based integrations should use released business services for new designs. Presence in classic S/4HANA does not by itself mean the function is a released ABAP Cloud API. New clean-core integrations should prefer released business APIs, events, CDS views, and managed administration services where SAP provides them.
Common pitfalls
- Using only a human-readable name and omitting the technical key such as client, job count, IDoc number, log number, or number-range subobject.
- Treating a framework-level success as proof that downstream application processing also succeeded.
- Changing technical status, configuration, or locks directly to make a monitor look green instead of correcting the underlying business failure.
- Running broad selection or destructive administration calls without a restrictive filter and an audit trail.
- Ignoring commit/update-task or asynchronous processing boundaries and checking the monitor before the relevant LUW or queue processing has completed.
Whose problem this is
Ownership depends on the framework: Basis owns background jobs, RFC, enqueue and system runtime; integration teams own ALE/IDoc partner/distribution configuration; Security owns authorization design; application developers own correct calls and exception handling; functional teams own the business data that ultimately succeeds or fails after the technical framework hands it off.
Production case and technical verification
IDoc inbound processing depends on partner profile, message/basic type, port, process code and application validation, not only successful receipt of an EDIDC/EDIDD payload. When investigating one inbound purchasing IDoc, capture control record, sender/receiver, message ID, status history and exact segment keys. Compare partner determination in WE20 and application status in WE02/WE05, then look at the processing function or BAPI rejection with its real business document reference. A status indicating data passed to application does not guarantee a PO or invoice posted. Before reprocessing check whether the business object already exists, especially for repeated external messages. Use supported test/reprocessing tools for a scoped IDoc and preserve status history; avoid calling low-level inbound FMs directly as a generic cure for missing partner profiles. Verify one correct target document and no duplicate after retry.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-function-modules/idoc-inbound-singleERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.