edi idoc connection

[Former Member]

Hi

can any one please tell me how is the flow between edi and idoc in layman's lang

is the ale involved in between edi and idoc process

how he data is coming from edi tool and how the idoc is creating and how it is processing the idoc into sap system

Thanks,

kumar

[Former Member]

can any one plz throw some inf on this

[Former Member]

Hi,

Difference Between EDI and IDOC

EDI is nothing but Electronic data interchange. SAP will support EDI through Intermediate documents (IDOCS).

EDI (Electronic Document interchange) - EDI is the electronic exchange of business documents between the computer systems of business partners, using a standard format over a communication network.

EDI is also called paperless exchange.

Advantages:

Reduced Data entry errors

Reduced processing time

Availabilty of data in electonic form

Reduced paperwork

Reduced Cost

Reduced inventories and better planning

Standard means of communications

Better business process

EDI has two process

1. Outbound process

2. Inbound process

OP:

1.Application document is created.

2.IDOC is generated

3.IDoc is transferred from SAP to Operating system layer

4.Idoc is converted into EDI standards

5.Edi document is transmitted to the business partner

6.The Edi Subsystem report status to SAP

IP:

1.EDI transmission received

2.EDI document is converted into an IDOC

3.IDOC is transferred to the SAP layer

4.The application document is created

5.The application document can be viewed.

IDOC:

IDOC is a container that can be used to exchange data between any two process.

Each iDoc is assigned a unique number for tracking and future reference.

iDoc Consist of several segments,and segments contain several fields.

iDoc contains the following three type of records...

1.One Control Record.

2.One or many Data Record

3.One or many Status record.

PORT:

Port is used in the outbound process to determine the name of the EDI subsystem program,the directory path where the idoc file will be created at the operating system level,the idoc file names and the rfc desinations.

RFC Destination:

Used to define the characteristics of communication links to a remote system on which a functions needs to be executed.

Partner Profile:

Partner profile specified the various componets used in an outbound process ( Partner number,IDoc type,message type,Port,Process code),the mode in which it communicates with the subsystem(batch or immediate) and the person to be notified in case of errors.

Message Control

Used in pricing,account determination,material determination,and output determination.The message control component enables you to encapsulate business rules with out having to write abap programs.

Process:

Setup RFC destinations SM59

Port Destinations WE21

Partner Profile WE20

Message control NACE

Purchase Order ME21

Check IDOCs WE02,WE05

Explain to me about Idoc?

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.

EDI/IDoc: How is an EDI project carried out?

Note Number

0047071

Released on 29.01.1997

Release

Symptom

How should you go about an EDI project? What steps are required?

Additional key words

IDoc, EDI, EDIFACT, ANSI X12, ODETTE, VDA

Cause and preconditions

Solution

When executing an EDI project, different aspects must be considered. The expense for such a project must be determined on an individual basis, as such projects are customer-specific and require a lot of consultation.

The following aspects are involved in an EDI project:

1. Selection of business partners

You must choose the business partners involved in the EDI. The EDI standard to be used and the messages to be exchanged must be the same for all partners.

1. Selection of the EDI Subsystem

An EDI Subsystem (translator, converter) is required to convert the SAP format IDoc into the message format of an EDI Standard. You must select a corresponding product. The IDoc interface is open, so that various EDI Subsystems can be added.

SAP does not offer any EDI subsystem itself!

Within our Authentication Program (Complementary Software Program CSP), SAP has certified some of these systems. Please note here, that this is a purely technical and functional authentication of the interface. That is, we test whether IDocs can be sent and received and whether a status report is created for sent IDocs. The authentication is not a business-based, functional test.

1. Implementation of the EDI procedure

You are recommended here to follow four steps:

a. Complete implementation of the SAP application

b. Internal SAP test of the IDoc interface

c. Test the IDoc interface with the EDI Subsystem

d. Start production

In particular the internal SAP test of the IDoc interface great attention is be dedicated since he allows in a very early stage to recognize errors and lacks of implementation.

Complete implementation of SAP application

Before you start implementing the EDI or IDoc functionality, the affected SAP applications must be implemented and their functionality must be available.

Internal SAP test of the IDoc interface

The test is made up of a combination of the technical, functional test as well as the business-based, functional test.

Technical, functional test

Here, you should test whether IDocs from the SAP application are created and that they can be transferred to the file system (Outbound processing). Furthermore, you should test whether IDocs are copied in the file system and can be processed by the SAP application (Inbound processing).

The individual steps can be supported with test tools:

Output: Test from the NAST record (message control for MM and SD) with transaction WE15. An application document must previously be created in the application. Output: Test from the IDoc with transaction WE14. An application document must previously be created in the application. Inbox: Test from a formally correct inbound file with transaction WE16. The file can be made available first, or must be manually created with an editor in the usual way. Inbox: Test from an outbound file with transaction WE12. The file comes from one of the two named output tests. Inbox: Test from IDoc, including manual creation of the IDocs, with transaction WE19 (only from Release 3.1).

Business-based, functional test

For the created output IDocs, you must check that the IDoc contains all the data that was agreed on with the partner. This means that the data must be checked and compared field by field. If differences are found, proceed as follows:

Can the data be produced by maintaining the basic data (customer, vendor, material or information record)? Can the data be produced by additional input in the transactions for the documents (purchase order, order, etc)? Is the corresponding application function that processes this data available at all?

You should, of course, proceed int he same way for incoming IDocs. However, this check can be made using the SAP application. This decides, whether the data is sufficient to create or change an application document. Exceptions which cause notification via the SAP Business Workflow are triggered if necessary.

In the tests, you should also check that these notifications reach the correct people.

Once the tests described here have been completed and were successful, you can start connecting the EDI subsystem.

Test the IDoc interface with the EDI Subsystem

With the EDI Subsystem, you must conduct both local and remote tests.

Local test

In the local test of outgoing messages, you must ensure that the EDI messages created from the IDocs are in accordance with your partner. Via transaction WE17, you should also test that the status report of the EDI subsystem contains the required information on the initial IDocs and that exceptions are forwarded to the correct people.

For incoming messages, you should check that the IDocs created from these messages can be processed by the SAP application. That is, the corresponding application documents can be created or changed.

Remote test

With the remote teset, you should pay attention to the communication with the partner as well as the processing of the messages by the respective partner system.

Please note, that many EDI standards allow messages to be transferred in a test mode. Thus, you can test the chain of processing, transmission and further processing and distinguish these messages from "productive" messages at the same time.

The test mode is indicated in the IDoc in the control record in the field TEST. In the EDI standard EDIFACT, this is made clear in the service segment UNB, data element 0035, and in the EDI standard ANSI X12, in the service segment ISA, data element I14.

For SAP, it is entered in the partner profile for output. In the input, it is the key field of the partner profile, so that the business processes can also be controlled by this.

Start production

The productive phase of the EDI application may only be started if the tests were completed successfully.

The tests here represent the minimum requirements for a successful EDI project. Further information can be obtained from the National Standardization Office (in Germany, the DIN) or through your EDI consulting partner.

Source code corrections

Related notes

0032121 EDI/IDoc: Workflow in the EDI and IDoc basis

0041365 EDI/IDoc: Certified EDI subsystems for 3.0 and 3.1

0044416 EDI/IDoc: Messages from IDoc processing

0114714 EDI/IDoc: Certified EDI subsystems for 4.x

0116610 EDI/IDoc: Notifications from IDoc processing

Regards,

Brown.

[Former Member]

Hi Brown

your mesg is ver helpful i have few questions

can we transfer from non-sap to non-sap using EDI.

is the idoc only the format edi transfer messsage ? or is idoc only for sap to no-sap systems vice versa ?

can u tell what r the diff types of edi subsystem?

is edi tool means edi subsytem?

thanks,

kumar.m

[rakesh_kumar]

Dear Kumar

1. EDI is a International standard (not a SAP prop. standard) to transfer documents between two systems. So it is possible to transfer data between two non sap systems. The only catch is, the non SAP system should have some means (read program) which converts the data of the document into EDI standard format and then send it to the recipient, where recipient should have some means to receive the data in the standard format and convert it back into something useful in the recipient system.

If your systems are on the same network (within your intranet/ WAN), you need not use any standard format to transfer the data. You can write custom programs to transfer the data.

2. You have to understand why IDoc came into picture. IDoc called Intermediate Document, is something standard for SAP. As there are multiple international standards (EDIFACT, ANSI, and more...) and they also keep changing the format every sometime. So if SAP tries to fulfill these standard directly, SAP will have to write lot of code to send the data differently. For example, for sending a document in EDIFACT standard, SAP will have to write code to transform the data into this standard and send it. And for sending a document in ANSI X12 standard, SAP will have to write more code to transform this data into ANSI format. Now, if there is a new standard comes into picture, again SAP have to write more code to support that standard. This becomes difficult in the long run.

As a solution, SAP uses IDocs which define the structure of the data to be sent. So SAP programs convert their data to the IDoc format and sends it to the receiving system (in case of EDI, the data is sent to the operating system's file system). The transformation of the IDoc into the various EDI standards are done by partners. These partners take data in IDoc format and convert it to EDI format according to the requirement and send this converted data across to the receiver. The recipient also does the same thing in reverse. It receives the data and converts it in EDI standard to IDoc standard and post it to SAP system. The SAP system then take care of the IDoc in the standard way.

Now the final recipient can be a non SAP system. Here the recipient has to coded to receive the EDI and process the data accordingly.

Same is true for a non SAP sender. non SAP sender can send the data in EDI format and receiver on SAP side will convert it into the SAP standard IDoc format and pass it to SAP system for processing.

3. Types of EDI subsystems: I don't know the answer. One answer can be based on the EDI standard the subsystem can support. For example one type can support EDIFACT, another type can support ANSI X12 but I am not sure.

4. If EDI subsystem are same as EDI tools: It should be the same. But I don't know the answer.

One more point, EDI is generally used to transfer data from your system to systems which are out of your company (meaning LAN/ WAN). In all other cases, using EDI can be an overkill. In cases where you want to transfer data between a SAP system to a non SAP system, EDI can be used, but there should be better custom programs to do this as translation to and from EDI format is an extra step and always an overhead.

IDoc format is also used to transfer data between different SAP system on a LAN/ WAN. In this case, the IDoc data is directly passed to the recipient using RFC, without using any IDoc subsystems.

Regards, Rakesh

[Former Member]

Hi Kumar,

IDOC is Intermediate data container. we send IDOC through ALE or EDI process.

we normally use EDI process to send the IDOC from SAP system to NON SAP systems.

and ALE is used to send IDOC from SAP to SAP systems

we have some Tcodes to pass these dat from one system to another system. like to send Material we have BD10 tcobe.

like that we send the data. and to receive we have BD11 tcode.

we have these tcodes to send and receive only the MASTER DATA.

An IDoc is simply a data container that is used to exchange information between any two processes that can understand the syntax and semantics of the data...

1.IDOCs are stored in the database. In the SAP system, IDOCs are stored in database tables.

2.IDOCs are independent of the sending and receiving systems.

3.IDOCs are independent of the direction of data exchange.

The two available process for IDOCs are

Outbound Process

Inbound Process

AND There are basically two types of IDOCs.

Basic IDOCs

Basic IDOC type defines the structure and format of the business document that is to be exchanged between two systems.

Extended IDOCs

Extending the functionality by adding more segments to existing Basic IDOCs.

To Create Idoc we need to follow these steps:

Create Segment ( WE31)

Create Idoc Type ( WE30)

Create Message Type ( WE81)

Assign Idoc Type to Message Type ( WE82)

Creating a Segment

Go to transaction code WE31

Enter the name for your segment type and click on the Create icon

Type the short text

Enter the variable names and data elements

Save it and go back

Go to Edit -> Set Release

Follow steps to create more number of segments

Create IDOC Type

Go to transaction code WE30

Enter the Object Name, select Basic type and click Create icon

Select the create new option and enter a description for your basic IDOC type and press enter

Select the IDOC Name and click Create icon

The system prompts us to enter a segment type and its attributes

Choose the appropriate values and press Enter

The system transfers the name of the segment type to the IDOC editor.

Follow these steps to add more number of segments to Parent or as Parent-child relation

Save it and go back

Go to Edit -> Set release

Create Message Type

Go to transaction code WE81

Change the details from Display mode to Change mode

After selection, the system will give this message “The table is cross-client (see Help for further info)”. Press Enter

Click New Entries to create new Message Type

Fill details

Save it and go back

Assign Message Type to IDoc Type

Go to transaction code WE82

Change the details from Display mode to Change mode

After selection, the system will give this message “The table is cross-client (see Help for further info)”. Press Enter.

Click New Entries to create new Message Type.

Fill details

Save it and go back

now go to bd64 there you have to create a modal view and assign message type which you create to transfer the data to reciver system.

u can also check this Link

http://www.saptechnical.com/Tutorials/ALE/CustomIDOC/Create.htm

reward if helpful

raam