Scenario for EDI

Question

hi can anybody tell me how the concept of EDI works?
1)do configurations like setting logical system, partner profiles etc have to be  made?
2)is there standard idocs like MATMAS or CREMAS that are sent via EDI?
3)is there a step-by-step procedure for EDI

Answer 1

hi anjali,
IDocs are basically a small number of records in ASCII format, building a logical
entity. It makes sense to see an IDoc as a plain and simple ASCII text file, even if it
might be transported via other means.
Any IDoc consists of two sections:
the control record
which is always the first line of the file and provides the administrative information.
the data record which contains the application dependent data, as in our example below the material master data.
We will discuss the exchange of the material master IDoc MATMAS in the
paragraphs that follow..
The definition of the IDoc structure MATMAS01 is deposited in the data dictionary
and can be viewed with WE30.
The very first record of an IDoc package is always a control record. The structure of this control record is the DDic structure EDIDC and describes the contents of the data contained in the package.
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 customised.
Once the IDoc data is handed over to a processing function module, you will no
longer need the control record information. The function modules are aware of the
individual structure of the IDoc type and the meaning of the data. In other words:
for every context and syntax of an IDoc, you would write an individual function module or business object (note: a business object is also a function module in R/3) to deal with.
The control record has a fixed pre-defined structure, which is defined in the data
dictionary as EDIDC and can be viewed with SE11 in the R/3 data dictionary. The
header of our example will tell us, that the IDoc has been received from a sender
with the name PROCLNT100 and sent to the system with the name DEVCLNT100 .
It further tells us that the IDoc is to be interpreted according to the IDoc definition called MATMAS01 .
All records in the IDocs, which come after the control record are the IDoc 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 is always 1000 characters long.
You can view the definition of any IDoc data structure directly within R/3 with transaction WE30.
Regardless of the used IDoc type, all IDocs are stored in the same database tables
EDID4 for release 4.x and EDID3 for release 2.x and 3.x. Both release formats are
slightly different with respect to the lengths of some fields.
Depending on the R/3 release, the IDoc data records are formatted either according
the DDic structure EDID3 or EDID3. The difference between the two structures
reflects mainly the changes in the R/3 repository, which allow longer names starting
from release 4.x.
All IDoc data record have a segment info part and 1000 characters for data IDoc type definition can be edited with WE30 Data and segment info are stored in EDID4 .
All IDoc data records are exchanged in a fixed format, regardless of the segment type. The
segment’s true structure is stored in R/3’s repository as a DDic structure of the same name.
The segment info tells the IDoc processor how the current segment data is structured
and should be interpreted. The information, which is usually the only interest, is the name of the segment EDID4-SEGNAM.
The segment name corresponds to a data dictionary structure with the same name,
which has been created automatically when defining the IDoc segment definition
with transaction WE31 .
For most applications, the remaining information in the segment info can be ignored
as being redundant. Some older, non-SAP-compliant partners may require it. E.g.
the IDoc segment info will also store the unique segment number for systems, which
require numeric segment identification.
To have the segment made up for processing in an ABAP, it is usually wise to move
the segment data into a structure, which matches the segment definition.
When R/3 processes an IDoc via the standard inbound or outbound mechanism, the IDoc is stored in the tables. The control record goes to table EDIDC and the data goes to table EDID4.
All IDoc, whether sent or received are stored in the table EDID4. The corresponding
control file header goes into EDIDC.
There are standard programs that read and write the data to and from the IDoc base.
These programs and transaction are heavily dependent on the customising, where
rules are defined which tell how the IDocs are to be processed.
Of course, as IDocs are nothing more than structured ASCII data, you could always
process them directly with an ABAP. This is certainly the quick and dirty solution,
bypassing all the internal checks and processing mechanisms. We will not reinvent
the wheel here.
To do this customising setting, check with transaction WEDI and see the points,
dealing with ports, partner profiles, and all under IDoc development.
All inbound and outbound Documents are stored in EDID4 Avoid reinventing the
wheel Customising is done from the central menu WEDI and see the points,
dealing with ports, partner profiles, and all under IDoc development
The declaration of valid combinations is done to allow validation, if the system can
handle a certain combination.
The combination of message type and IDoc type determine the processing algorithm. This is
usually a function module with a well defined interface or a SAP business object and is set up
in table EDIFCT.
The entry made here points to a function module which will be called when the IDoc
is to be processed.
The entries for message code and message function are usually left blank. They can
be used to derive sub types of messages together with the partner profile used.
Figure 25: Assign a handler function to a message/message type
The definition for inbound and outbound IDocs is analogous. Of course, the function
module will be different.
R/3 uses the method of logical process codes to detach the IDoc processing and the
processing function module. They assign a logical name to the function instead of specifying the physical function name.
The IDoc functions are often used for a series of message type/IDoc type
combination. It is necessary to replace the processing function by a different one.
E.g. when you make a copy of a standard function to avoid modifying the standard.
The combination message type/IDoc will determine the logical processing code,
which itself points to a function. If the function changes, only the definition of the processing codes will be changed and the new function will be immediately
effective for all IDocs associated with the process code.
For inbound processing codes you have to specify the method to use for the
determination of the inbound function.
This is the option you would usually choose. It allows processing via the ALE
scenarios.
After defining the processing code you have to assign it to one or several logical
message types. This declaration is used to validate, if a message can be handled by
the receiving system.
The inbound processing code is assigned analogously. The processing code is a pointer to a function module which can handle the inbound request for the specified IDoc and message type.
The definition of the processing code is identifying the handler routine and assigning a serious of processing options.
You need to click "Processing with ALE", if your function can be used via the ALE
engine. This is the option you would usually choose. It allows processing via the
ALE scenarios.
Associate a function module with a process code
For inbound processing you need to indicate whether the function will be capable of
dialog processing. This is meant for those functions which process the inbound data
via call transaction. Those functions can be replayed in visible batch input mode to
check why the processing might have failed.
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
see this link for all info on idocs
http://abapprogramming.blogspot.com/2007/11/abap-idocs-basic-tools.html
thanks
karthik
reward me points if usefull