IDOC

IDOC - Intermediate Document. Data container for data exchange between SAP systems
or between a SAP system and a Non-SAP system.

IDoc (for intermediate document) is a standard data structure for electronic data interchange
(EDI) between application programs written for the popular SAP business system or between an
SAP application and an external program. IDocs serve as the vehicle for data transfer in SAP's
Application Link Enabling (ALE) system. IDocs are used for asynchronous transactions: each
IDoc generated exists as a self-contained text file that can then be transmitted to the requesting
workstation without connecting to the central database. Another SAP mechanism, the Business
Application Programming Interface (BAPI) is used for synchronous transactions.
A large enterprise's networked computing environment is likely to connect many geographically
distributed computers to the main database. These computers are likely to use different hardware
and/or operating system platforms. An IDoc encapsulates data so that it can be exchanged
between different systems without conversion from one format to another.
IDoc types define different categories of data, such as purchase orders or invoices, which may
then be broken down into more specific categories called message types. Greater specificity
means that an IDoc type is capable of storing only the data required for a particular transaction,
which increases efficiency and decreases resource demands.
An IDoc can be generated at any point in a transaction process. For example, during a shipping
transaction process, an IDoc may be generated that includes the data fields required to print a
shipping manifest. After a user performs an SAP transaction, one or more IDocs are generated in
the sending database and passed to the ALE communication layer. The communication layer
performs a Remote Function Call (RFC), using the port definition and RFC destination specified
by the customer model. The IDoc is transmitted to the receiver, which may be an R/3, R/2, or
some external system.
We can create / upload IDOC's from legacy system to SAP by using a Third party tool Mercator.
It may be used to convert Legacy files to Idoc format. Mercator provides an IDOC tree import
facility, SAP provides the export facility. You can transfer the Idoc layouts from SAP to Mercator
automatically and then map.

An IDoc is a transactional message, in the form of a pure ASCII file, sent from a SAP-connected
application to other applications. Most of an IDoc message consists of fields of data grouped into
segments. The segments themselves have a hierarchical relation to each other.
Since an IDoc is a message, both the sending and receiving applications must conform to a
common convention about where, in a given IDoc, each piece of data will be found. To this end,
SAP AG has defined several hundred IDoc types and a large number of segment types. And SAP
owners can create their own custom IDoc types and segment types.
A sending application must construct an IDoc of a given type in accordance with these definitions;
and a receiving application, must conform to the definitions when parsing the IDoc. This means
that identifying a parser file is one step in setting up receiving application to use data from IDocs.
A parser file for an IDoc type contains the information that the receiving application needs to
parse the IDocs; such as what segments can appear in it, which segments are repeatable, what
data fields will appear in each segment, what order the fields will be in, and what length each field
will have.
IDoc types have names of six letters and two numerals. SHPMNT01 is an IDoc that embodies a
message about shipments. SAP revises the definitions of IDocs from time-to-time, and the two
numerals at the end of the name identify the revision.
Segment names may end in three digit version numbers. For example, E2KNA1M001 is a
segment for the DEBMAS02 (customer masters) IDoc type.

What is ALE?
ALE is SAP proprietary technology that enables data communications between two or more SAP
R/3 systems and/or R/3 and external systems. When a new enterprise resource planning (ERP)
solution such as R/3 is implemented, companies have to interface the ERP system with legacy
systems or other ERP systems. ALE provides intelligent mechanisms whereby clients can
achieve integration as well as distribution of applications and data. ALE technology facilitates
rapid application prototyping and application interface development, thus reducing
implementation time. The ALE components are inherently integrated with SAP applications and
are robust, leading to a highly reliable system.
ALE comes with application distribution/integration scenarios as well as a set of tools, programs,
data definitions, and methodologies that you can easily configure to get an interface up and
running.
The following building blocks are fundamental to ALE functionality:
Logical System. A Logical System (LS) is the representation of an R/3 or external system in SAP
R/3 for the distribution of data to and from the R/3 System. Every R/3 client used for ALE or EDI
has to have a base LS associated with the client. This LS becomes the sender for outbound
messages and a receiver for inbound messages. In addition to the base LS, a second LS should
be created within that R/3 system for each R/3 or external system used for ALE interfaces. In an
inbound ALE interface, this second LS represents the sender (another R/3 or external system)
with respect to the base LS (receiver). In an outbound ALE interface, this second LS is the
receiver on behalf of the R/3 or external system with respect to the base LS (sender).
Message type. A message type represents the application message exchanged between R/3
systems and R/3 and an external system. A message type characterizes the data sent across
systems and relates to the structure of the data called an IDOC type (see below). For example,
MATMAS is a message type for Material Master, and INVOIC is a message type for an Invoice
(Billing Document). ALE supports over 200 message types in R/3 and about 200 application
areas.
IDOC type and IDOC. An Intermediate Document (IDOC) type represents the structure of the
data associated with a message type (DEBMAS02 for message type DEBMAS Customer
Master, and WMMBID02 for message type WMMBXY Goods Movements), while an IDOC is an
object containing the data of a particular message type. IDOCs are data containers with
intelligence built in. Each IDOC contains one and only one business object. For example, an
IDOC of type SHPMNT01, message type SHPMNT, will contain data only of one Shipment
Document. Generally, the architecture of an IDOC is independent of the message type by virtue
of ALEs ability to redefine it for any message type.
An IDOC consists of three record types: the control record, the data record, and the status record

The following building blocks are fundamental to ALE functionality:

Logical System. A Logical System (LS) is the representation of an R/3 or external system in SAP
R/3 for the distribution of data to and from the R/3 System. Every R/3 client used for ALE or EDI
has to have a base LS associated with the client. This LS becomes the sender for outbound
messages and a receiver for inbound messages. In addition to the base LS, a second LS should
be created within that R/3 system for each R/3 or external system used for ALE interfaces. In an
inbound ALE interface, this second LS represents the sender (another R/3 or external system)
with respect to the base LS (receiver). In an outbound ALE interface, this second LS is the
receiver on behalf of the R/3 or external system with respect to the base LS (sender).
Message type. A message type represents the application message exchanged between R/3
systems and R/3 and an external system. A message type characterizes the data sent across
systems and relates to the structure of the data called an IDOC type (see below). For example,
MATMAS is a message type for Material Master, and INVOIC is a message type for an Invoice
(Billing Document). ALE supports over 200 message types in R/3 and about 200 application
areas.
IDOC type and IDOC. An Intermediate Document (IDOC) type represents the structure of the
data associated with a message type (DEBMAS02 for message type DEBMAS Customer
Master, and WMMBID02 for message type WMMBXY Goods Movements), while an IDOC is an
object containing the data of a particular message type. IDOCs are data containers with
intelligence built in. Each IDOC contains one and only one business object. For example, an
IDOC of type SHPMNT01, message type SHPMNT, will contain data only of one Shipment
Document. Generally, the architecture of an IDOC is independent of the message type by virtue
of ALEs ability to redefine it for any message type.

An IDOC consists of three record types: the control record, the data record, and the status
record
. The control record, or EDI_DC, is a control structure that contains several fields with
information about the IDOC, such as what IDOC type it is, the message type, sender and receiver
information, and direction (1 for outbound, 2 for inbound). This information provides control data
on the outbound, and processing options on an inbound IDOC. It also has as its key the Client
(MANDT) and the IDOC number (DOCNUM). The EDI_DC record of an IDOC is stored in table
EDIDC. Every IDOC has one control record.
The data record, which conforms to the structure EDI_DD, contains the application data. Every
EDI_DD record has a key portion that is 55 bytes in length (or 63, depending on the SAP
release), which consists of several fields describing the content of the record. The key of 55/63
bytes is followed by a field SDATA, which is 1000 bytes in length and of data type Long
Character. The SDATA field holds the application data, and its structure is determined by the key
field SEGNAM (Segment Name). An IDOC consists of one or more data records, and its
sequence and structure are dictated by the sequence and structure of segments in a given IDOC
type. The SDATA portion of the data record is redefined for every occurrence based on the
structure of the segment, with the first 55/63 bytes of the data record identifying the segment
name, sequence, and hierarchy. In an outbound interface, ALE/EDI function modules populate
these segments with application data. In an inbound interface, the application modules process
the data contained in the segments. Data records are stored on table EDID2 that belongs to the
cluster EDI30C.
In SAP, from a Data Dictionary perspective, IDOC segments adhere to a naming convention.
Each segment has three components, each marked by a different prefix E1 for segment type,
E2 for segment definition, and E3 for segment documentation. For example, the first segment of
IDOC type DEBMAS02 is E1KNA1M. Its definition is contained in structure E2KNA1M, and its
documentation is in E3KNA1M. When the IDOC is externalized, we see the segment name
addressed by its E2 prefix. For all practical purposes, we will use only the E2 prefix when
referring to IDOC segments. Also, most segment names represent Data Dictionary tables.
The status record conforms to the dictionary structure EDI_DS. It contains information on the
state of the IDOC as it passes through the various stages of processing. The STATUS field has a
length of two bytes (data type CHAR), with a range of values: 0141 for outbound and 5073 for
inbound IDOCs. The status record also includes date and timestamps for when that particular
state was reached. The status records maintain a history of the IDOC states. An IDOC may have
one or more status records, which are stored in table EDIDS .These records can be accessed or
created only by SAP function modules (APIs), and are not externalized.
IDOC objects consist of a Basic IDOC type, an Extension type, and an IDOC type.
In an R/3 system, IDOCs are identified by a unique IDOC number (field DOCNUM), and all three
record types are tied together with this number. The IDOC number is internally assigned by SAP.
It is possible to maintain the number range of IDOCs.