SAP IDoc status codes for inbound and outbound flows

SAP IDoc (Intermediate Document) status codes indicate the processing state of IDocs in the system. These status codes differ for inbound and outbound IDocs, providing transparency and traceability for data exchange. Below is a detailed breakdown:

---

Inbound IDoc Status Codes

Inbound IDocs represent data received into the SAP system.

Status Code	Description
50	IDoc added to the database.
51	Error during inbound processing.
52	IDoc processed but warnings were issued.
53	IDoc processed successfully.
62	IDoc edited (used during debugging).
64	IDoc ready to be transferred to application.
65	IDoc passed to application.
68	IDoc archived.

Common Errors (Status 51)

• Missing or incorrect master data (e.g., vendor, material).
• Syntax or semantic issues in the IDoc segments.
• Application-level validation errors.

---

Outbound IDoc Status Codes

Outbound IDocs represent data sent from the SAP system to a partner system.

Status Code	Description
01	IDoc created.
02	IDoc passed to the ALE layer.
03	IDoc data sent to the partner system (successfully).
04	Error during outbound processing.
05	IDoc sent to external system (IDoc in the receiver's system).
06	IDoc not transferred because of syntax errors.
07	IDoc was manually changed.
08	Application document not created (error in processing).
12	Dispatch OK (IDoc successfully delivered).
18	Triggered via workflow.
30	IDoc ready for dispatch (not yet processed).
32	IDoc edited.

Common Errors (Status 06/04)

• Incorrect partner profile configuration (e.g., port or message type).
• Network or system connectivity issues.
• Issues with translation/mapping (e.g., EDI to IDoc format).

---

Lifecycle of an IDoc

For Outbound:

1. 01: IDoc is generated.
2. 02: IDoc is passed to the ALE layer for processing.
3. 03: IDoc is successfully sent to the partner.
4. 12: Confirmation of successful dispatch.

For Inbound:

1. 50: IDoc is created in the SAP system.
2. 64: IDoc is ready for application processing.
3. 53: IDoc is successfully processed.
4. 51: IDoc encountered an error.

Overview of SAP IDOC Structure

The IDoc (Intermediate Document) structure in SAP is designed to facilitate the exchange of business data between systems. 

It has a hierarchical structure divided into three main components:

---

1. Control Record (EDIDC)

The control record provides metadata about the IDoc and serves as a header. It contains information required for processing and routing the IDoc.
Key Fields in the Control Record:

• IDoc Number: A unique identifier for the IDoc.
• Direction: Specifies whether the IDoc is inbound (2) or outbound (1).
• Message Type: Defines the type of business process (e.g., ORDERS, INVOIC).
• Basic Type: Specifies the structure of the IDoc (e.g., ORDERS05, INVOIC02).
• Sender/Receiver Information: Includes:
  • Partner Type (e.g., KU for customer, LI for vendor).
  • Partner Number (identifies the trading partner).
  • Logical System (represents SAP or external systems).
• Status: Tracks the current state of the IDoc (e.g., created, sent, processed, or error).

---

2. Data Records (EDID4)

The data records contain the actual transactional data. They are organized into segments, which represent logical groups of data.
Structure of a Data Record:

• Segment ID: Identifies the segment type (e.g., E1EDK01 for header data).
• Parent Segment: Links child segments to their parent for a hierarchical relationship.
• Segment Data: Contains the field values in a flat structure.

Types of Segments:

• Header Segment: Contains general information, such as document date, document type, and trading partner details.
  • Example: E1EDK01 (Header Data)
• Item Segments: Holds line-item-specific details, such as product, quantity, and price.
  • Example: E1EDP01 (Item Data)
• Summary Segments: Provides totals or summaries for the document.
  • Example: E1EDT01 (Totals Data)

Segments can be mandatory or optional, depending on the IDoc type and the business process.

---

3. Status Records (EDIDS)

The status records track the lifecycle of the IDoc, providing information about its processing status.
Key Fields in Status Records:

• Status Code: Indicates the current state of the IDoc.
  • Examples:
    • 03: Outbound IDoc sent to the partner system.
    • 12: Inbound IDoc successfully processed.
    • 51: Inbound IDoc with errors during processing.
• Timestamp: Records when the status change occurred.
• Message: Describes the status or any error encountered.

---

Hierarchical Relationship in IDoc

IDocs follow a hierarchical structure:

1. Control Record: One per IDoc.
2. Data Records: One or more, depending on the transaction.
   • Data records can have a parent-child relationship (e.g., header → item → sub-item).
3. Status Records: One or more, as the IDoc moves through its lifecycle.

Comparison of SAP IDoc types with X12 transaction sets and EDIFACT message types

Purchase Order

Process	SAP IDoc Type	X12 Transaction Set	EDIFACT Message Type
Purchase Order	ORDERS	850	ORDERS
Purchase Order Response	ORDERS05	855	ORDRSP
Purchase Order Change	ORDCHG	860	ORDCHG

---

Invoice

Process	SAP IDoc Type	X12 Transaction Set	EDIFACT Message Type
Invoice	INVOIC	810	INVOIC
Credit Note	INVOIC02	812	CREMUL

---

Shipping and Delivery

Process	SAP IDoc Type	X12 Transaction Set	EDIFACT Message Type
Advanced Ship Notice (ASN)	DESADV	856	DESADV
Shipping Schedule	SHPMNT	862	DELFOR
Delivery Information	DELVRY	940	IFTMIN

---

Payment

Process	SAP IDoc Type	X12 Transaction Set	EDIFACT Message Type
Payment Order	PAYEXT	820	PAYORD
Remittance Advice	REMADV	823	REMADV

---

Inventory Management

Process	SAP IDoc Type	X12 Transaction Set	EDIFACT Message Type
Inventory Inquiry/Advice	INVRPT	846	INVRPT
Inventory Adjustment	INVMAS	947	INVRPT

---

Master Data

Process	SAP IDoc Type	X12 Transaction Set	EDIFACT Message Type
Material Master Data	MATMAS	832	PRICAT
Customer Master Data	DEBMAS	814	PARTIN
Vendor Master Data	CREMAS	814	PARTIN

---

Logistics

Process	SAP IDoc Type	X12 Transaction Set	EDIFACT Message Type
Transportation Order	TRANSP	204	IFTMIN
Shipment Status	SHPMNT	214	IFTSTA

Overview of SAP IDOC (Intermediate Document)

SAP IDoc (Intermediate Document) is a standard SAP document format used for exchanging information between SAP systems or between an SAP system and an external system. 

SAP IDoc serves as a container for data and facilitates the seamless integration of business processes by enabling structured data exchange.

---

Key Features of SAP IDoc

1. Standardized Format:
   IDocs follow a standardized structure, making them ideal for various business transactions like purchase orders, invoices, and shipment notifications.

2. Asynchronous Communication:
   IDocs are typically processed asynchronously, allowing systems to exchange information without being dependent on real-time responses.

3. Versatility:
   Used for both SAP-to-SAP integration and SAP-to-Non-SAP integration.

4. Error Handling:
   Includes robust error monitoring and reprocessing capabilities through SAP tools like the WE02 or WE05 transaction codes.

---

Structure of an IDoc

An IDoc consists of three main sections:

1. Control Record:
   Contains metadata such as sender/receiver information, message type, and IDoc type.

2. Data Records:
   Contains the actual business data in hierarchical segments. Each segment represents a part of the business process (e.g., customer details, order items).

3. Status Records:
   Tracks the status of the IDoc during its lifecycle, such as created, processed, or error.

---

IDoc Workflow

1. Outbound Processing:

   • The data is extracted from the SAP application layer.
   • Converted into an IDoc format using a message type and IDoc type.
   • Sent to the target system via middleware or directly.

2. Inbound Processing:

   • The IDoc is received from an external or SAP system.
   • Validated and converted into SAP application data.
   • Errors, if any, are logged for reprocessing.

---

IDoc vs EDI

Aspect	IDoc	EDI
Purpose	Internal SAP communication	External communication with partners
Format	SAP-specific	Industry-standard (e.g., X12, EDIFACT)
Flexibility	Limited to SAP functionality	Used across multiple systems
Middleware	SAP ALE, PI/PO, or BTP	VANs or custom integrations

---

Benefits of Using IDocs

1. Seamless Integration:
   Facilitates communication between SAP modules and external systems.

2. Standardization:
   Reduces complexity by providing a predefined format.

3. Error Tracking:
   Provides robust monitoring and troubleshooting capabilities.

4. Customization:
   Supports custom IDoc types for specific business needs.

Comparison of EDI envelopes (X12, EDIFACT and Tradacoms)

Aspect	X12	EDIFACT	Tradacoms
Hierarchy Levels	3 Levels: Interchange, Functional Group, Transaction Set	3 Levels: Interchange, Functional Group (optional), Message	3 Levels: Transmission, Batch, Message
Interchange Header	ISA (Interchange Control Header)	UNB (Interchange Header)	STX (Start of Transmission)
Interchange Trailer	IEA (Interchange Control Trailer)	UNZ (Interchange Trailer)	END (End of Transmission)
Functional Group Header	GS (Group Header)	UNG (Group Header, optional)	BAT (Batch Header)
Functional Group Trailer	GE (Group Trailer)	UNE (Group Trailer, optional)	EOB (End of Batch)
Message Header	ST (Transaction Set Header)	UNH (Message Header)	MHD (Message Header)
Message Trailer	SE (Transaction Set Trailer)	UNT (Message Trailer)	MTR (Message Trailer)
Envelope Flexibility	Fixed, strict hierarchy	Flexible, group header optional	Simpler and flatter hierarchy
Control Numbers	ISA/IEA, GS/GE, ST/SE control numbers for tracking	UNB/UNZ and UNH/UNT control numbers	STX/END and MHD/MTR identifiers
Data Format	ASCII	ISO 9735	Fixed-width ASCII
Regions of Use	Primarily North America	Global (Europe, Asia, and others)	Primarily UK and retail industries
Main Applications	Retail, healthcare, supply chain	International trade, shipping, logistics	Retail and grocery sectors
Validation	Comprehensive control number validation	Message-level validation	Batch-level validation
Complexity	Moderate complexity, widely adopted	High complexity, globally scalable	Simple structure, industry-specific

Identification Code Qualifiers in the EDI Industry

EDI qualifiers are codes used to provide additional context or specify the meaning of the accompanying data. 

They help differentiate data elements and ensure that the correct information is processed. For example, a qualifier might specify that a particular identifier represents a buyer, supplier, or warehouse.

Importance of Qualifiers

• Ensure data accuracy.
• Provide context for interpreting data elements.
• Facilitate compatibility across trading partners and systems.

Most Used Identification Code Qualifiers in the EDI Industry

1. 01 - D-U-N-S Number

   • Universally accepted for identifying companies in global commerce.
   • Used extensively in financial and supply chain EDI transactions.

2. 92 - Assigned by Buyer or Buyer's Agent

   • A critical qualifier for custom identification codes in buyer-specific setups.

3. ZZ - Mutually Defined

   • Offers flexibility in custom trading partner agreements.
   • Commonly used for non-standard codes.

4. 08 - UCC/EAN Global Trade Item Number (GTIN)

   • Essential for product identification in industries like retail, healthcare, and consumer goods.

5. 20 - Standard Point Location Code (SPLC)

   • Frequently used in logistics for identifying geographic shipping points.

6. 9 - Federal Taxpayer ID

   • Common for tax and regulatory compliance in B2B transactions.

7. UL - Global Location Number (GLN)

   • Highly used in supply chain and logistics to track company and facility locations.

---

Overview of 1PL, 2PL, 3PL, 4PL, and 5PL

The terms 1PL, 2PL, 3PL, 4PL, and 5PL describe different levels of logistics and supply chain management services. 

They represent a hierarchy of logistics providers, each offering varying levels of service and integration.

---

1PL (First-Party Logistics)

• Definition: Involves the manufacturer, producer, or retailer managing logistics and transportation of goods using their own resources.
• Key Features:
  • Company owns and operates its fleet of vehicles and warehouses.
  • Limited reliance on external parties.
• Example: A local farmer delivering produce directly to customers using their own truck.

---

2PL (Second-Party Logistics)

• Definition: Refers to outsourcing transportation or warehousing to a logistics company that specializes in a specific function.
• Key Features:
  • The logistics provider offers a single service, like shipping or storage.
  • Typically involves carriers like shipping companies or freight forwarders.
• Example: A manufacturer hiring a trucking company to deliver products.

---

3PL (Third-Party Logistics)

• Definition: A comprehensive logistics provider that manages multiple aspects of logistics for a client.
• Key Features:
  • Includes warehousing, transportation, distribution, and sometimes inventory management.
  • Reduces the complexity for businesses by consolidating logistics activities.
• Example: A retailer using FedEx or DHL for inventory storage and last-mile delivery.
• Common Use Cases:
  • E-commerce businesses outsourcing order fulfillment.
  • Manufacturers using third-party warehouses to store inventory.

---

4PL (Fourth-Party Logistics)

• Definition: A logistics integrator that manages and oversees the entire supply chain. Often referred to as a supply chain orchestrator.
• Key Features:
  • Acts as a single interface between the client and multiple logistics providers (e.g., 3PLs).
  • Focuses on optimization, strategic planning, and technology integration.
  • Often handles activities like supplier management, demand planning, and analytics.
• Example: A large corporation hiring a 4PL provider to manage all aspects of its supply chain, including 3PL coordination.
• Advantages:
  • Greater supply chain visibility and efficiency.
  • Strategic focus beyond operational logistics.

---

5PL (Fifth-Party Logistics)

• Definition: A provider that focuses on end-to-end logistics solutions using advanced technology and big data to optimize the supply chain.
• Key Features:
  • Leverages artificial intelligence (AI), automation, and predictive analytics for supply chain management.
  • Typically involves managing e-commerce and omni-channel logistics.
  • Emphasizes scalability and flexibility to meet dynamic market demands.
• Example: An e-commerce company using a 5PL for AI-driven demand forecasting, automated inventory replenishment, and logistics.
• Distinct Features:
  • Focuses on networked logistics, coordinating with 3PLs and 4PLs.
  • Suited for global, highly complex supply chains.

---

Comparison Table

Level	Focus	Services Provided	Key Features	Example
1PL	Self-managed logistics	Own transportation and warehousing	Directly handled by the company	Farmer delivering own produce
2PL	Single outsourced service	Transportation or storage	Hired service provider for specific logistics tasks	Trucking company for delivery
3PL	Multiple logistics services	Warehousing, distribution, inventory management	End-to-end logistics management	FedEx for fulfillment
4PL	Supply chain integration	Strategic planning, 3PL management	Full supply chain visibility	Supply chain orchestrators
5PL	Technology-driven supply chain	AI, automation, big data for end-to-end logistics	Focus on digital transformation	AI-powered e-commerce logistics

Summary

• 1PL to 5PL represent an evolution from basic self-managed logistics to advanced, technology-driven supply chain solutions.
• Businesses choose the appropriate level based on their size, complexity, and strategic needs.
• The trend toward 4PL and 5PL reflects growing demand for integration, visibility, and efficiency in global supply chains.