Simple explanation about IDOC

Simple explanation about IDOC  with definition , structures & message types

What is IDOC?

IDOC is simply a data container used to exchange information between any two processes that can understand the syntax and semantics of the data.

In other words, an IDOC is like a data file with a specified format which is exchanged between 2 systems which know how to interpret that data.

IDOC stands for ” Intermediate Document”

IDOC Basics

We can view an IDOC using transaction WE02 or WE05

IDOC Consists of 3 Parts mainly

Control Record:

The administration part (Control Record)- which has the type of idoc , message type, the current status, the sender, receiver etc. This is referred to as the Control record.

Ø  All control record data is stored in EDIDC table. The key to this table is the IDOC Number

Ø  It contains information like IDOC number, the direction(inbound/outbound), sender, recipient information, channel it is using, which port it is using etc.

Ø  Direction ‘1’ indicates outbound, ‘2’ indicates inbound.

Data Record:

The application data (Data Record) – Which contains the data. These are called the data records/segments.

Ø  Data record contains application data like employee header info, weekly details, client details etc

Ø  All data record data is stored in EDID2 to EDID4 tables and EDIDD is a structure where you can see its components.

Ø  It contains data like the idoc number, name and number of the segment in the idoc, the hierarchy and the data

Ø  The actual data is stored as a string in a field called SDATA, which is a 1000 char long field.

Status Record :

The Status information (Status Record)- These give you information about the various stages the idoc has passed through.

Ø  Status record is attached to an I-DOC at every milestone or when it encounter errors.

Ø  All status record data is stored in EDIDS table.

Direction : ‘1’ indicates outbound, ‘2’ indicates inbound.

 

Ø  Outbound :Statuses 1-42 are for outbound

Ø  Inbound: statuses 50-75 are for inbound

 

IDOC Types

Ø  Basic type

                The basic type defines the core structure and content of an IDoc. It represents the standard definition of a specific business document, like a purchase order, invoice, or sales order. The basic type determines the segments (data fields grouped together) that are included in the IDoc, the sequence of those segments, and the data types within each segment. Think of it as the blueprint or template for a particular kind of IDoc. It's identified by a name, for example, ORDERS01 (for purchase orders).

 

Key Characteristics of Basic Types:

•Fixed Structure: The structure of a basic type is predefined and cannot be easily modified.

•Reusable: They are designed to be used across various applications and business processes.

•Standard Segments: They typically include standard segments common to many IDoc types, like control information, partner information, and status information.

•Basis for Extensions: Basic types serve as the foundation for creating extension types, allowing for customization without altering the original standard.

 

Ø  Extension

             An extension type builds upon a basic type by adding custom segments or fields to accommodate specific business requirements. It allows you to enhance the standard IDoc structure without modifying the underlying basic type. This ensures compatibility with standard processes while incorporating company-specific data. For example, you might want to add a field for a customer loyalty number to the standard purchase order IDoc. You would create an extension type based on ORDERS01 to incorporate this additional field.

 

Key Characteristics of Extension Types:

 

Customization: They enable tailoring IDocs to meet unique business needs without disrupting standard functionality.

Inheritance: They inherit all the segments and fields from the underlying basic type.

Flexibility: You can add, delete, or modify segments and fields within the extension type.

Version Control: Extensions are managed with versions, allowing for controlled updates and modifications.

List of IDOC Message Types

Ø  ORDERS - Purchase Order

Ø  ORDCHG - Purchase order Changes

Ø  DESADV - Shipping Notifications

Ø  INBDLV - Inbound Delivery

Ø  REMADV- Payment Advice Processing

Ø  MATMAS - Material Master

Ø  ARTMAS - Article Master

Ø  CREMAS - Supplier Master

Ø  DELINS - Forecast Delivery schedule

Ø  MBGMCR- Post goods movement

Ø  ORDRSP - PO Confirm

Ø  SHPCON - Ship Confirmation/PGI

         

Purchasing:

Ø  ORDERS (Purchase Order): This is the core IDoc for transmitting purchase orders to vendors. It contains all the necessary details about an order, such as materials ordered, quantities, prices, delivery dates, and other conditions. Think of it as the electronic equivalent of a paper purchase order.

 

Ø  ORDCHG (Purchase Order Change): Used to communicate changes to an existing purchase order. This could include modifications to quantities, delivery dates, prices, or other order details. It ensures that both the buyer and vendor are working with the latest version of the order.

 

Ø  ORDRSP (Purchase Order Confirmation/Response): Sent by the vendor back to the buyer as a confirmation or rejection of a purchase order, or to suggest changes. It might contain updated delivery dates, confirmed quantities, or explanations for rejected items.

 

Ø  INBDLV (Inbound Delivery): Represents a delivery of goods from a vendor. It contains information about the expected delivery date, shipping details, and the materials included in the delivery. This allows the buyer to prepare for receiving the goods.

 

Ø  REMADV (Remittance Advice): Used in payment processing to provide details about which invoices are being paid. It links payments to specific invoices and helps with reconciliation. (You listed "Payment Advice Processing" which is the function this IDoc supports, not the IDoc type name itself).

 

Ø  MBGMCR (Post Goods Movement): Documents the movement of goods within the company after they are received. This allows for updating inventory levels and tracking the movement of materials through the warehouse.

 

Logistics and Supply Chain:

Ø  DESADV (Despatch Advice/Shipping Notification): Sent by the vendor to notify the buyer that goods have been shipped. It contains details about the shipment, including tracking information, carrier details, and the shipped quantities. This allows the buyer to track the shipment and plan for its arrival.

 

Ø  DELINS (Forecast Delivery Schedule): Used to communicate planned future deliveries from a vendor. This helps the buyer anticipate upcoming shipments and adjust their planning accordingly. It's essentially a forecast of deliveries.

 

Master Data:

Ø  MATMAS (Material Master): Used to exchange information about materials, including descriptions, units of measure, weights, and other attributes. This ensures that both systems have consistent information about the materials being traded. Crucial for data synchronization between systems.

Ø  ARTMAS (Article Master - often industry-specific): Similar to MATMAS but often used in specific industries like retail or fashion, for managing articles or finished goods. It contains information specific to the industry, such as sizes, colors, or styles.

Ø  CREMAS (Customer Master/Supplier Master): You listed this as "Supplier Master," but CREMAS typically refers to Customer Master. For vendors/suppliers, the IDoc type LIFNR is associated with the Vendor Master. These IDocs are used to exchange information about business partners, including addresses, contact details, payment terms, and other relevant information.

Shipping and Delivery:

Ø  SHPCON - (Shipping Confirmation/Post Goods Issue - PGI): Confirms the shipment of goods and updates the delivery status. This is often linked to the creation of a goods issue document in the shipping system.

 

Key Considerations:

Ø  Versions: These IDoc types can have different versions (e.g., ORDERS01, ORDERS02, etc.), each with slight variations in structure.

Ø  Segments: Each IDoc type is composed of segments, which contain the specific data fields.

Ø  Customization: Companies often customize these standard IDocs by adding custom segments to accommodate specific business needs.

 

IDOC Message Status

Inbound IDOC:

51 - Application Document Not Posted

52 - Application Document Not fully Posted

53 - Application Document Posted

Outbound IDOC:

01- IDOC Generated

02 - Error Passing data to Port

03- Data Passed to port OK

IDOC Reprocessing Method

WE19 - With help of Existing IDOC no we can make the field changes then new IDOC no will be   generated

BD87 - Pass new IDOC no and process it

IDOC Partner Profiles - WE20

Ø  BP - Benefits Provider

Ø  GP - Business Partner

Ø  KU - Customer

Ø  LI - Vendor

Ø  LS - Logical System

Ø  US – User

The Outbound Process

Steps Involved –

1. Create segments(WE31)
2. Create an idoc type(WE30)
3. Create a message type (WE81)
4. Associate a message type to idoc type(WE82)
5. Create a port(WE21)
6. If you are going to use the message control method to trigger idocs then create the function module for creating the idoc and associate the function module to an outbound process code
7. Otherwise, create the function module or stand-alone program which will create the idoc
8. Create a partner profile(WE20) with the necessary information in the outbound parameters for the partner you want to exchange the idoc with. Trigger the idoc.

The Inbound Process

Steps Involved-

1. Creation of basic Idoc type (Transaction WE30)
2. Creating message type (Transaction WE81)
3. Associating the Message type to basic Idoc type (Transaction WE82)
4. Create the function module for processing the idoc
5. Define the function module characteristics (BD51)
6. Allocate the inbound function module to the message type(WE57)
7. Defining process code (Transaction WE42)
8. Creation of partner profile (Transaction WE20)