SAP ABAP IDOC'S BASIC TOOLS I

There are several common expressions and methods that you need to know, when dealing
with IDoc.

The message type defines the semantic context of an IDoc. The message type tells
the processing routines, how the message has to be interpreted.

The same IDoc data can be sent with different message types. E.g. The same IDoc
structure which is used for a purchase order can also be used for transmitting a sales order. Imagine the situation that you receive a sales order from your clients and in addition you receive copies of sales orders sent by an subsidiary of your company.


An IDoc type defines the syntax of the IDoc data. It tells which segments are found
in an Idoc and what fields the segments are made of.

The processing code is a logical name that determines the processing routine. This
points usually to a function module, but the processing routine can also be a
workflow or an event.

The use of a logical processing code makes it easy to modify the processing routine
for a series of partner profiles at once.

Every sender-receiver relationship needs a profile defined. This one determines

• the processing code
• the processing times and conditions
• and in the case of outbound IDocs
• the media port used to send the IDoc and
• the triggers used to send the IDoc

The IDoc partners are classified in logical groups. Up to release 4.5 there were the
following standard partner types defined: LS, KU, LI.

The logical system is meant to be a different computer and was primarily introduced
for use with the ALE functionality. You would use a partner type of LS, when
linking with a different computer system, e.g. a legacy or subsystem.

The partner type customer is used in classical EDI transmission to designate a
partner, that requires a service from your company or is in the role of a debtor with
respect to your company, e.g. the payer, sold-to-party, ship-to-party.

The partner type supplier is used in classical EDI transmission to designate a
partner, that delivers a service to your company. This is typically the supplier in a
purchase order. In SD orders you also find LI type partners, e.g. the shipping agent.



Message Type – How to Know What the Data Means


Data exchanged by an IDoc via EDI is known as message. Messages of the same kind belong to the same message type.

The message type defines the semantic context of an IDoc. The message type tells
the receiverhow the message has to be interpreted.

The term message is commonly used in communication, be it EDI or
telecommunication. Any stream of data sent to a receiver with well-defined
information in itis known as a message. EDIFACT, ANSI/X.12, XML and others
use message the same way.


Unfortunately, the term message is used in many contexts other than EDI as well.
Even R/3 uses the word message for the internal communication between
applications. While this is totally OK from the abstract point of view of data
modelling, it may sometimes cause confusion if it is unclear whether we are
referring to IDoc messages or internal messages.


The specification of the message type along with the sent IDoc package is especially
important when the physical IDoc type (the data structure of the IDoc file) is used
for different purposes.


A classical ambiguity arises in communication with customs via EDI. They usually
set up a universal file format for an arbitrary kind of declaration, e.g. Intrastat,
Extrastat, Export declarations, monthly reports etc. Depending on the message type,
only applicable fields are filled with valid data. The message type tells the receiver which fields are of interest at all.


Partner Profiles – How to Know the Format of the Partner

Different partners may speak different languages. While the information remains the same, different receivers may require completely different file formats and communication protocols.

This information is stored in a partner profile.

In a partner profile you will specify the names of the partners which are allowed to
exchange IDocs to your system. For each partner you have to list the message types
that the partner may send.

For any such message type, the profile tells the IDoc type, which the partner expects
for that kind of message.

For outbound processing, the partner profile also sets the media to transport the data to its receiver, e.g.

• an operating system file
• automated FTP
• XML or EDIFACT transmission via a broker/converter
• internet
• direct remote function call

The means of transport depends on the receiving partner, the IDoc type and message
type (context).

Therefore, you may choose to send the same data as a file to your vendor and via
FTP to your remote plant.

Also you may decide to exchange purchase data with a vendor via FTP but send
payment notes to the same vendor in a file.

For inbound processing, the partner profile customizsng will also determine a
processing code, which can handle the received data.


IDoc Type – The Structure of the IDoc File

The IDoc type is the name of the data structure used to describe the file format of a specific IDoc.

An IDoc is a segmented data file. It has typically several segments. The segments
are usually structured into fields; however, different segments use different fields.

The Idoc type is defined with transaction WE30, the respective segments are defined
with transaction WE31.

Processing Codes

The processing code is a pointer to an algorithm to process an IDoc. It is used to allow more flexibility in assigning the processing function to an IDoc message.

The processing code is a logical name for the algorithm used to process the IDoc.
The processing code points itself to a method or function, which is capable of
processing the IDoc data.

A processing code can point to an SAP predefined or a self-written business object
or function module as long as they comply with certain interface standards.

The processing codes allow you to easily change the processing algorithm. Because
the process code can be used for more than one partner profile, the algorithm can be
easily changed for every concerned IDoc.

The IDoc engine will call a function module or a business object which is expected
to perform the application processing for the received IDoc data. The function
module must provide exactly the interface parameters which are needed to call it
from the IDoc engine.

In addition to the writing of the processing function modules, IDoc development requires the
definition of the segment structures and a series of customising settings to control the flow of the IDoc engine.

In Summary

Customise basic installation parameters
Define segment structures
Define message types, processing codes

Segments define the structure of the records in an IDoc. They are defined with transaction WE31.

Check first, whether the client you are working with already has a logical system
name assigned.

The logical system name is stored in table T000 as T000-LOGSYS. This is the table
of installed clients.

If there is no name defined, you need to create a logical system name . This means
simply adding a line to table TBDLS. You can edit the table directly or access the
table from transaction SALE.

The recommended naming convention is

sysid + "CLNT" + client

If your system is DEV and client is 100, then the logical system name should be:
DEVCLNT100.

System PRO with client 123 would be PROCLNT123 etc.
The logical system also needs to be defined as a target within the R/3 network.
Those definitions are done with transaction SM59 and are usually part of the work
of the R/3 basis team.