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 –
- Create
segments(WE31)
- Create
an idoc type(WE30)
- Create
a message type (WE81)
- Associate
a message type to idoc type(WE82)
- Create
a port(WE21)
- 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
- Otherwise,
create the function module or stand-alone program which will create the
idoc
- 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-
- Creation
of basic Idoc type (Transaction WE30)
- Creating
message type (Transaction WE81)
- Associating
the Message type to basic Idoc type (Transaction WE82)
- Create
the function module for processing the idoc
- Define
the function module characteristics (BD51)
- Allocate
the inbound function module to the message type(WE57)
- Defining
process code (Transaction WE42)
- Creation
of partner profile (Transaction WE20)
