# SAP IDoc Interface Specification Document Template > Source: https://netray.co/tools/sap-idoc-interface-specification-document-template > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer Fill in a structured functional and technical specification for an IDoc-based interface and export it as a clean document. ## Category sap ## Erp SAP ECC / S/4HANA ## Audience - SAP integration developer - SAP functional consultant - Project manager ## Tool **Kind:** template **Output:** document **Fields:** #### Interface ID **Key:** interface_id **Type:** text **Default:** INT-SD-014 #### Interface name **Key:** interface_name **Type:** text **Default:** Customer sales orders to SAP S/4HANA #### Business owner **Key:** owner **Type:** text **Default:** Head of Order Management #### Author **Key:** author **Type:** text **Default:** Integration developer #### Date **Key:** date **Type:** date **Default:** 2026-10-20 #### Direction **Key:** direction **Type:** select **Options:** - Inbound to SAP - Outbound from SAP **Default:** Inbound to SAP #### Partner or external system **Key:** partner **Type:** text **Default:** Customer EDI platform via middleware #### Message type **Key:** message_type **Type:** text **Default:** ORDERS #### Basic IDoc type **Key:** basic_type **Type:** text **Default:** ORDERS05 #### Process code or function module **Key:** process_code **Type:** text **Default:** To be confirmed in WE42 #### Expected volume **Key:** volume **Type:** text **Default:** About 3,000 IDocs per day, peak 800 per hour #### Frequency and schedule **Key:** schedule **Type:** text **Default:** Near real time, processed every 5 minutes in background #### Error handling approach **Key:** error_handling **Type:** textarea **Default:** Failed IDocs (status 51) reported daily to the order desk. Mapping errors corrected at source and resent. Application errors reprocessed through BD87 after the cause is fixed. #### Security and access **Key:** security **Type:** textarea **Default:** Secured transport between middleware and SAP. Technical user with only the authorizations needed for the inbound process. No personal data stored outside SAP. **Blocks:** #### Document control **Table:** **Columns:** - Item - Value **Rows:** **0:** Interface ID **1:** {{interface_id}} **0:** Name **1:** {{interface_name}} **0:** Business owner **1:** {{owner}} **0:** Author **1:** {{author}} **0:** Date **1:** {{date}} #### 1. Purpose and scope **Body:** This document specifies interface {{interface_id}}, {{interface_name}}. Direction: {{direction}}. Partner: {{partner}}. In scope: the message flow described below. Out of scope: changes to the partner system and any master data replication not listed here. #### 2. IDoc definition **Table:** **Columns:** - Attribute - Value **Rows:** **0:** Message type **1:** {{message_type}} **0:** Basic IDoc type **1:** {{basic_type}} **0:** Process code or function module **1:** {{process_code}} **0:** Partner profile (WE20) **1:** Partner number, type and role to be documented **0:** Port (WE21) **1:** To be documented #### 3. Volume and timing **Body:** Expected volume: {{volume}}. Frequency and schedule: {{schedule}}. #### 4. Field mapping summary **Table:** **Columns:** - Source field - IDoc segment and field - Rule or conversion - Mandatory **Rows:** #### 5. Error handling and monitoring **Body:** {{error_handling}} Monitoring: WE02 or WE05 for IDoc status, BD87 for reprocessing. Alert owner and escalation path to be named. #### 6. Security and compliance **Body:** {{security}} #### 7. Test scenarios **Table:** **Columns:** - No. - Scenario - Expected result - Status **Rows:** **0:** 1 **1:** Valid message, all mandatory fields **2:** IDoc status 53, document created **0:** 2 **1:** Unknown partner or missing master data **2:** IDoc status 51 with clear message **0:** 3 **1:** Duplicate message **2:** Handled per duplicate rule **0:** 4 **1:** Peak volume run **2:** No backlog beyond agreed time #### Approvals **Signatures:** - Business owner - SAP functional lead - Integration developer - Basis **Notes:** Starting point to adapt to your project standards. Replace placeholders in the mapping and partner profile sections with the details of your own system and confirm names and process codes in your SAP release. ## Content **Intro:** A good interface specification prevents the argument that starts when the first IDoc fails in production. This template gives you a structured document for an IDoc-based interface that you can fill in, export and send for sign-off. **Sections:** #### How to use the template **Body:** Complete the fields for one interface, then export. Each interface should have its own document with a unique ID, a named business owner, and a clear direction. Fill the IDoc definition from WE30 and WE81 in your system, and the partner profile and port from WE20 and WE21. Then complete the mapping table with one row per target field, including the conversion rule. **Bullets:** - One document per interface, not per project. - Name an owner on the business side, not only IT. - Attach sample payloads and an IDoc from WE19 test runs. #### What the sections cover **Body:** Purpose and scope fix what the interface does and does not do. The IDoc definition identifies the message type, basic type and process code that decide how SAP handles the message. Volume and timing feed sizing and scheduling. The mapping section is where most defects originate, so require a rule for every mandatory field. Error handling and monitoring state who is told when status 51 or another error appears and what they do about it. #### Review checklist **Body:** Before sign-off, confirm the process code exists in WE42 and is assigned to the message type, the partner profile has the correct inbound or outbound parameters, and test scenarios include failure cases as well as success. Check that a duplicate message does not create a second document, that authorizations are limited, and that volume assumptions match what the processing capacity can handle. #### Common mistakes **Body:** Specs that describe only the happy path produce interfaces that nobody knows how to support. Others copy the IDoc structure but omit conversion rules, so each developer guesses unit-of-measure, plant and currency handling differently. Finally, many specs never name who monitors the interface after go-live, leaving errors to age in the IDoc monitor. **Cta:** If you want interface specifications generated from your actual partner profiles and IDoc metadata rather than typed by hand, Netray can build that as a read-only assistant for your team. **Faq:** #### What should an IDoc interface spec include? **Answer:** Purpose, direction, partner, message and basic IDoc type, process code, volume and schedule, field mapping with conversion rules, error handling, monitoring, security and test cases. Add sample payloads as attachments. #### Where do I find the basic IDoc type definition? **Answer:** Use WE30 to display the IDoc type and its segments, and WE81 and WE82 to see message types and their assignment to IDoc types. WE60 provides generated documentation. #### Is this a legal or contractual document? **Answer:** No. It is a technical and functional specification template. If it forms part of a contract with a partner or vendor, have the contractual wording reviewed separately. #### Can I use it for non-IDoc interfaces? **Answer:** Yes with small edits. Replace the IDoc definition section with the service, API or function module details and keep the rest, which applies to any integration. ## Search terms sap interface specification template, idoc interface specification, sap integration design document, sap interface document template word, idoc functional specification, sap technical specification template, sap interface design template, idoc partner profile documentation --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json