Solved: scenario for EDI

Former Member · ‎2008 Apr 18

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

Former Member · ‎2008 Apr 18

Hi Anjali,

As you mentioned first we have to configure.after that we have to send the data using a message type.

actually what happens in edi is first after configuration we have to create idoc using a message type.after that that idoc is sent to a edi interface of sender.this interface will convert the idoc to a format acceptable by the edi standards.after that the data is sent to reciever edi interface which will convert the data received in specific format to idoc .then it will be posted in the database.

the process technically is

In Outbound(sender)system

The application document is created.

The IDoc is generated.

The IDoc is transferred from SAP to the operating system layer.

The IDoc is converted to EDI standards.

The EDI document is transmitted to the business partner

The EDI subsystem reports status to SAP

In Inbound(receiver) system

The EDI transmission is received

The EDI document is converted into an IDoc

The IDoc is transferred to the SAP layer

The application document is created

The application document can be viewed

you asked whether there is any messagetypes like matmas,cremas etc.Go To TRANSACTION 'WE81' which will display all the message types existed.

please reward points if helpful.

Former Member · ‎2008 Apr 18

hi anjali,

the below gives you a entirely about edi and ale idocs pls see

http://books.google.co.in/books?hl=en&id=IKdYRntfsqUC&dq=aleediidoc+sap&printsec=frontcover&source=web&ots=jqB1_VLPcZ&sig=w5TJXHuVIaIKlEGKy18gcBBa6ng#PPP1,M1

and process:

R/3 does not provide any tool to convert IDocs into international EDI format like ANSI X.12, EDIFACT or XML. This conversion needs to be done by an external add-on product which is provided by a variety of companies who specialize in general EDI and e-commerce solutions.

R/3 does not provide conversion to EDI standard formats like X.12, EDIFACT or XML.

Converters exist on UNIX and PC platforms.

Many converters are simple PC programs.

R/3 certification only guarantees that the converter complies to RFC technology and works fine with standard IDoc scenarios.

Real life situations require a flexible and easily adaptable converter program.

SAP R/3 has foregone implementing routines to convert IDocs into international EDI standard formats and forwards those requests to the numerous third party companies who specialize in commercial EDI and e-commerce solutions..

Nearly every standard organization defined an own EDI standard for their members.

So there is X.12 by ANSI for the US, EDIFACT/UN adopted by the United Nations

Organization UNO or XML as proposed by the internet research gurus of W3C.

But there is still more about it. All major industry companies define an additional

file format standard for their EDI partners. Even if they adhere officially to one of

the big standards, they yet issue interpretation guidelines with their own

modifications according to their needs.

If a company does not play in the premier league of industry or banking companies,

it will have to comply with the demands of the large corporations.

As this leads to the insight that there are as many different EDI formats as

companies, it is evident that an EDI converter needs to have at least one major

feature, which is flexibility in the sense of openness towards modification of the

conversion rules.

There are hundreds of converter solutions on the market not counting the individual

in-house programming solutions done by many companies.

EDI is a market on its own. Numerous companies specialize in providing EDI

solutions and services. The majority of those companies also provide converters.

Many of the converters are certified by SAP to be used with R/3. However, this does

not tell anything about the usability or suitability to task of the products

IDOC AND BAPI:

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 where by 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.

BAPI

BAPIs provide a stable, standardized method for third-party applications and components to integrate into the Business Framework. These interfaces are being specified as part of SAP's initiative with customers, partners and leading standards organizations. Also, SAP has implemented the emerging Object Application Group (OAG) specifications with BAPIs.

Pros and Cons for both BAPI and Call Transaction

BAPI

One of the big plusses for BAPIs is that the interface and function are not supposed to change. This is a big plus when you do upgrades or hot packs because the transaction can change (format, required inputs etc) which means you then need to update the call transaction.

Some of the BAPIs are better documented and easier to use than others.

You usually need to perform the BAPI that actually does the COMMIT after you call your BAPI.

The Program coding for calling a BAPI is usually cleaner than setting up the screen flow etc for the Call Transaction.

You don't need to worry about special data circumstances interrupting the normal data flow of the screens and causing errors because of that.

BAPIs probably have better performance since they don't do the screen flow processing.

In general if the BAPI exists for the transaction you want to perform and you can figure out how to use it the BAPI is probably the best way to go.

This is just from my experience working with both BAPI and Call Transaction. I have had some very good successes with BAPIs, but very occasionally found that I could not get the BAPI to perform the update I needed.

The interface concept of the classic R/3 is based on two different strategies: Remote Function Calls (RFC) and data exchange through IDoc message documents. RFC makes direct and synchronous calls of a program in the remote system. If the caller is an external program it will call an RFC-enabled function in R/3 and if the calling program is the R/3 system it will call an RFC-function in another R/3-system or it will call a non-R/3 program through a gateway-proxy (usually rfcexec.exe).

BAPIs are a subset of the RFC-enabled function modules, especially designed as Application Programming Interface (API) to the SAP business object, or in other words: are function modules officially released by SAP to be called from external programs.

IDocs are text encoded documents with a rigid structure that are used to exchange data between R/3 and a foreign system. Instead of calling a program in the destination system directly, the data is first packed into an IDoc and then sent to the receiving system, where it is analyzed and properly processed. Therefore an IDoc data exchange is always an asynchronous process. The significant difference between simple RFC-calls and IDoc data exchange is the fact, that every action performed on IDocs are protocolled by R/3 and IDocs can be reprocessed if an error occurred in one of the message steps.

While IDocs have to be understood as a data exchange protocol, EDI and ALE are typical use cases for IDocs. R/3 uses IDocs for both EDI and ALE to deliver data to the receiving system. ALE is basically the scheduling mechanism that defines when and between which partners and what kind of data will be exchanged on a regular or event triggered basis. Such a set-up is called an ALE-scenario.

The philosophical difference between EDI and ALE can be pinned as follows: If we send data to an external partner, we generally speak of EDI, while ALE is a mechanism to reliable replicate data between trusting systems to store a redundant copy of the IDoc data.

The difference is made clear, when we think of a purchase order that is sent as an IDoc. If we send the purchase order to a supplier then the supplier will store the purchase order as a sales order. However, if we send the purchase order via ALE to another R/3 system, then the receiving system will store the purchase order also as a purchase order.

thanks

karthik

Former Member · ‎2008 Apr 18

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