Beruflich Dokumente
Kultur Dokumente
ALE is a set of
Tools
programs and
data definitions
that provides the mechanism for distributing functionality and data across
multiple system.
What Data can be Exchanged ?
Transaction Data
SD, MM etc.
Master Data
Material, Customer, Vendor, etc.
Control Data
Organizational Reference Information
Plants, Sales Orgs, etc.
Data required to enable tightly coupled, distributed applications
- Separate HR, Separate Treasury, etc.
IDOC is the acronym for Intermediate Document. It is simply a data
container used to exchange information between any two processes that
can understand the syntax and semantics of the data. IDocs are relatively
simple to understand. But, like most simple things they are difficult to
explain.
IDocs are basically simple ASCII data streams. When they are stored to a
disk file, the IDocs are simple flat files with lines of text, where the lines
are structured into data fields.
The typical structured file has records, each record starting with a leading
string that identifies the record type. Their specification is stored in the
SAP data dictionary.
Characteristics: An IDoc is not a process
In SAP system IDocs are stored in the database
Every IDoc has a unique number (within a client)
IDocs are independent of the sending and receiving system ( SAP to
SAP as well as Non-SAP)
IDocs are based on EDI standards (like ANSI X.12, EDIFACT )
IDocs can be viewed in a text editor and do not contain any binary
data. Data is stored in character format.
The information which is exchanged by IDocs is called a message and the
IDoc is the physical representation of such a message. The name
messages for the information sent via IDocs is used in the same ways
as other EDI standards. Everybody who has ever dealt with interface
programming will find IDocs very much like the hierarchical data files
used in traditional data exchange. International standards like the
ODETTE or VDA formats are designed in the same way as IDocs are.
Other EDI standards like XML, ANSI X.12 or EDIFACT/UN are based on a
data description language. They differ principally from the IDocs concept,
because they use a programming language syntax (e.g. like Postscript or
HTML) to embed the data.
Features ALE / IDocs
Reliable communication
IDoc Type
IDoc type is a document structure that describes the order in which fields
and records occur, as well as the data type of these fields. The EDI
document to be generated has an equivalent message type defined in the
SAP system. The message type is based on an IDOC structure. As an
example, if an EDI transaction of 850, which is a purchase order, is to be
generated, the message type ORDERS is assigned to it. This message is
based on an IDOC type such as ORDERS05. The IDOC type is the most
important component in the EDI process.
An IDOC type is also referred to as basic IDOC type. A basic IDOC type
has the following characteristics:
Name: A basic IDOC type can be assigned up to a 30 character name in
release 4.0 and later. Segments of a previous version of an IDOC type are
never deleted. This approach is necessary to maintain backward
compatibility. In the standard list of IDOCs for example ORDERS01,
ORDERS02, ORDERS03, ORDERS04, ORDERS05 types are available. The
last two characters represent the version.
List of permitted segments: Only the segments defined in the IDOC
type can be used in an IDOC.
Hierarchy of segments: The hierarchy of segments specifies the physical
sequence and any parent-child relationship in the segments. A parentchild relationship signifies that the child segment can not exist without the
parent.
Mandatory versus optional segment: When used in an IDOC type,
each segment has an attribute that defines whether the segment is
optional or mandatory.
Maximum/Minimum range for each segment: When used in an IDOC
type each segment has an attribute that defines the minimum and the
maximum number of times a data record corresponding to a segment can
exist in an IDOC.
IDOC Record Types & Structures
An IDOC is an instance of an IDOC type. An IDOC has a record oriented
structure. Although there are several records in an IDOC, they are still
classified as one of the three record types:
Control Record
Data Record
Status Record
Control Record
The control record contains all of the control information about an
IDOC; this information basically includes the IDOC number, sender
and receiver information, and information such as the message type
it represents and the IDOC type.
Features of IDoc control record:1.There is only one control record per IDOC.
2.The structure of the control record is the same for all the IDocs
and is defined by SAP.
3.The structure of the control record is defined by the data
dictionary structure EDI_DC40 in release 4.0 onwards. The control
record is stored in the EDIDC table.
4.One control record defined by the SAP Data Dictionary structure
EDI_DC40, with a record length of 524 bytes.
The control record carries all the administrative information of the IDoc,
such as its origin, its destination and a categorical description of the
contents and context of the attached IDoc data. This is very much like the
envelope or cover sheet that would accompany any paper document sent
via postal mail.
For R/3 inbound processing, the control record is used by the standard
IDoc processing mechanism to determine the method for processing the
IDoc. This method is usually a function module but may be a business
object as well. The processing method can be fully customized.
Data Record
All records in the IDocs, which come after the control record, are data
records. Data records contain the actual application data. They are all
structured alike, with a segment information part and a data part which is
1000 characters in length, filling the rest of the line.
All records of an IDoc are structured the same way, regardless of their
actual content. They are records with a fixed length segment info part to
the left, which is followed by the segment data, which are always 1000
characters long.
Regardless of the used IDoc type, all IDocs are stored in the same
database tables EDID4 for release 4.x and EDID3 for release and 3.x.
Both release formats are slightly different with respect to the lengths of
some fields.
Data records for IDocs from version 4.0 on are stored in the EDID4
table, while version 3.0-3.1 IDoc data records are in EDID2.
Status Records
The status record conforms to the data dictionary structure EDI_DS40 for
IDocs from version 4.0 on and EDI_DS for previous versions. Status
records are stored in the EDIDS table. 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: status codes of 01 to 49 are reserved for outbound
processes, and 50 and above for inbound processes.
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. The latest status code is also maintained in the
control record.
An IDOC may have one or more status records (multiple 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. So we could not see status records in an IDoc flat
file outside the SAP system.
Fields in the Status Record Table (EDIDS):
Client
DOCNUM
IDoc number
LOGDAT
LOGTIM
COUNTR
CREDAT
CRETIM
STATUS
Status of IDoc
UNAME
User Name
REPID
Program Name
ROUTID
STACOD
Status code
STATXT
SEGNUM
SEGFLD
STAPA1
Parameter 1
STAPA2
Parameter 2
STAPA3
Parameter 3
STAPA4
Parameter 4
STATYP
STAMQU
STAMID
Status message ID
STAMNO
TID
Transaction ID
APPL_LOG
Application log
3. The IDoc is transferred to the SAP layer. The IDoc text file is
stored at the SAPs operating system layer. The EDI subsystem
triggers an inbound program in the SAP layer. Then a SAP
application reads the IDoc file and stores an IDoc in the SAP
database repository for further processing.
4. The application document is created. The IDoc is then passed to
a posting program. This program creates an application document
such as a sales order, purchase order acknowledgment, invoice etc.
The document can be viewed using standard application transaction.
Description
04
05
06
Translation OK
07
08
Syntax check OK
09
10
Interchange handling OK
11
12
Dispatch OK
13
Retransmission OK
15
16
17
22
23
24
36
MAPPING
EDIFACT
SEGMENT
<->
UNH, UNT
<->
BGM
<->
NAD
<->
BGM, RFF
<->
DTM,PAT
E2EDK05 - Conditions
<->
MOA, ALC
<->
TAX, MOA
<->
PCD
<->
FTX
IDOC SEGMENT
<->
FTX
<->
LIN, QTY
<->
DTM
<->
<->
MOA, PRI
<->
TAX, MOA
<->
CNT