EDI: It is the electronic exchange of documents between the computer systems of partners, using a standard format over a communication network.
BENEFITS OF THE EDI PROCESS:
The implementation of EDI benefits both the sender and the receiver. The following things can be minimized with this process:
Reduced data entry errors: EDI does not involve data entry at multiple points. In a regular process, a sender creates an document on the system, prints the document, and then faxes or mails it to the receiver. The receiver then re keys the same information on their computer. With this procedure, data goes directly from one computer to the another without any involvement.
Reduced process cycle time : The biggest advantage is the reduced processing time of the complete cycle. As soon as documents are entered into the system, they can be processed on the receiving side in seconds. There is a considerable savings in the processing time of document transfer.
Availability of data in electronic form. Data from EDI is a electronic form, which makes it easy to share across the organization. For example, a purchasing department can use the data to evaluate vendors, or a marketing department can use the data to analyze the trends and demands of customers.
Reduced cost : The initial cost of an EDI setup is certainly higher compared to the paper process, but over a long period it is very cost effective. In the long term, the overall cost of exchanging business documents in paper form can cost less per transaction.
Standard means of communication : Because EDI enforces standards on the contents of data, uniform naming standards and field sizes have emerged. Such consistency leads to clearer communication and less ambiguity.
IMPLEMENTATION:
EDI can be implemented in two process:
- Outbound Process.
- Inbound process.
Outbound process : In this process, we create the document, and the document is transmitted to the Operating system layer and it is transmitted over a TCP/IP network.
The outbound process has some specifications and standards which has to be done before transmitting the document.
The outbound process uses
- IDOC types
- selection programs.
- Message control.
- Partner profiles.
- Port Definitions
- Service Programs.
- Tables to generate an IDOC.
- IDOC types: 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 IDOC type ORDERS01 and ORDERS02. The IDOC type is the most important component in the EDI process.
- Selection programs: These are typically implemented as function modules, which are designed to extract application data and create an IDOC. A selection program exists for each message type. The programs are generally named with the following naming convention:
IDOC_OUTPUT_<message type>
In my project, the selection program for message type ORDERS is IDOC_OUTPUT_ORDERS. A four character process code, ME10, has been assigned to this function module. The list of outbound process codes and their corresponding function modules can find with the transaction :
T-code : WE41.
- Message control: It is used in pricing, account determination, material determination, and output determination. The message control component enables to encapsulate business rules without having to write programs. In the EDI process, Message control determines and processes the various outputs associated with an application document.
- Port Definition : A 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 destination.
- Partner profiles: The partner profiles specifies the various components used in the outbound process, the mode in which it communicates with the subsystem and the person to be notified in case of errors.
- Service programs and Configuration tables: The asynchronous outbound process can be seen as a sequence of several processes that work together. In this service programs and configuration tables are used to link the process. The process flow for the outbound process describes the role played by each service program and configuration table.
INBOUND PROCESS: The inbound process uses the following components to post and application document from the IDOC:
- IDOC type.
- Port Definition.
- Posting programs
- Service programs.
- configuration tables.
All the things described above are the same except for the posting programs.
Posting programs: These are implemented in the system as function modules. A posting program exists for each message type. The posting programs are named with the following naming convention.
IDOC_INPUT<message type>
In my project, the posting program for the message type ORDERS I have taken is IDOC_INPUT_ORDERS. A four- character process code, ORDE, has been assigned to this function module. The list of inbound process codes and their corresponding function modules by executing the following transaction.
T-CODE : WE42.
With the above specifications, I have configured the following things before actually start working on the interchange process :
- Configuration of Port Definition.
- Configuration of Partner Profiles.
- Assigning number range and selection of IDOC.
- Assigning organization and user.
- Setting up RFC destination.
- Creation of Purchasing document.
- Creation of receiving fields information.
1.Configuration of Port Definition:
In this section, we provide the complete details about the subsystem, the outbund file and the function module we are using, the status file, which tells about the status of the IDOC.
Transaction Code: WE21.
For EDI process, the port that is used is the FILE port.
Transaction RFC’s are used for ALE applications.
Internet port is used for internet applications.
XML port is used for XML applications.
This is a very important step in the whole process, because all the outbound, inbound and status files are stored in the port definitions.
Configuration of Partner Profiles:
It is important to maintain the profiles of each partner in the business scenario with whom we exchange our business documents.
TRANSACTION : WE20.
There are three views of a partner profile in which different parameters can be entered as a partner :
General Parameters view : These values are stored in table EDPP1.
In this view, it contains very basic information about the partner, such as partner number, partner type, and default individual to notify in case an error occurs. These partner attributes appear at the top of the main partner profiles screen and under the post processing : permitted agent and classification tabs.
Partner number : In EDI, the partner number is a customer number or bank ID. In this case, I have taken my student number(573097) as my partner number.
Partner type : The partner type represents the type of our business partner. In this case, I have taken type as customer(KU).
Assigning number range and selection of IDOC: This is done by the following transaction. This is very important in every EDI applications because it will be a big problem if two IDOC’s are assigned a same value.
T- Code : WE46.
Setting up RFC destination : Every transaction that is transmitted over a network must know the destination point before it is transmitted. This is done by using the Remote Function Call called as RFC. The program called SERVER_EXEC is selected for TCP/IP connections.
The transaction code used for this process is : SM59.
This program starts an application on the server and establishes a network between the two systems.
Creation of application document:
T-code : ME11.
In my project, I have taken a purchasing order as the application document and created all the required fields in the document and saved. As soon as the application document is saved, it fills all the details in the database tables.
The yellow state in the output screen tells that the document is saved without any errors.
Creation of receiving fields information:
For every transaction, the receiver information must be entered for every transaction.
This can be done with the following transaction.
T-code : XD02.
The receiver fields are the most critical in the EDI transaction. If there is something wrong in the information, the application document is transmitted and the acknowledge is given to the sender. But before the transmission, the receiver is notified that the information is available and waits for the permission whether it is ready to share.
In this way, all the fields in the receiver section should be filled before actually sending the document.
THE FOLLOWING STEPS ARE DONE FOR THE SUCCESSFUL TRANSMISSION OF EDI DOCUMENT:
STEP 1:
DEFINING THE GLOBAL PARAMETERS FOR IDOC:
Transaction Code: WE47.
In order an Idoc to be transmitted, it should be first assigned so that all application components can identify the type of Idoc.
This can be done by giving the administrator name and it’s type.
CONFIGURING THE PARTNER PROFILES:
Transaction code : WE20.
I have created a partner profiles with
Partner number : 123 (ANANTH GOWRI SANKAR PATURU)
Partner type : Customer.
OUTBOUND PARAMETERS:
Message type : ORDRSP.
Receiver port : SUBSYSTEM (because all my transactions are residing in my R/3).
Idoc type : ORDERS05
Application : EF (which is the message type supported for this application ).
Process code : SD10 ( Every transaction of this message type for outbound process needs a process code SD10).
INBOUND PARAMETERS:
Message type : ORDERS.
Receiver port : SUBSYSTEM (because all my transactions are residing in my R/3).
Idoc type : ORDERS05
Application : EF (which is the message type supported for this application ).
Process code : ORDE ( Every transaction of this message type for inbound transaction needs a process code ORDE).
In the same way for the receiving end,
Partner number : 3030 (AIR PARTS)
Partner type : vendor.
OUTBOUND PARAMETERS:
Message type : ORDRSP.
Receiver port : SUBSYSTEM (because all my transactions are residing in my R/3).
Idoc type : ORDERS05
Application : EF (which is the message type supported for this application ).
Process code : ME10 ( Every transaction of this message type for outbound process needs a process code ME10).
INBOUND PARAMETERS:
Message type : ORDRSP.
Receiver port : SUBSYSTEM (because all my transactions are residing in my R/3).
Idoc type : ORDERS05
Application : EF (which is the message type supported for this application ).
Process code : ORDR ( Every transaction of this message type for inbound transaction needs a process code ORDE).
CONFIGURING THE RFC DESTINATION :
Transaction Code : SM59.
In the settings of the RFC destination being used in the process, I have taken the destination type as SERVER_EXEC because it is the only one that supports the R/3 system for the version.
CONFIGURING THE PORT DEFINITION :
Transaction Code : WE21.
In the port definition I have taken FILE as the port because it is the only port that supports this EDI transaction. In the port definition, all the outbound process and inbound process are stored in a specific location.
CREATION OF APPLICATION DOCUMENT:
Transaction Code : MK01.
This is the most typical part in the program :
I have created an application document with the above profiles of the sending and the receiver information.
The details are as follows:
Vendor : 3030 (Air parts)
Purchasing organization : 3000. (IDES USA)
Customer : 123 (Ananth gowri sankar paturu).
Material Description : R300.
As soon as the document is saved the Idoc is generated from the NAST table by storing the application document.
CONFIRMATION NUMBER FOR THE APPLICATION DOCUMENT : 4500008604.
CHECKING FOR THE SUCCESSFUL CREATION OF APPLICATION DOCUMENT:
Transaction Code : MK23.
By giving the confirmation number of the application document, the purchase order transaction can be confirmed.
CONFIRMING THE APPLICATION DOUMENT ENTRIES IN THE DATABASE:
Transaction Code : SE16.
By typing the table name NAST in the table entry we can view all the details of the application document.
WRITING A PROGRAM FOR THE VALIDITY OF SENDING AND RECEIVING PROFILES AND GENERATION OF Idoc FOR THE DATA THAT IS SAVED IN THE APPLICATION DOCUMENT :
Transaction Code : SE38.
Program Name :
Database Tables I have used in my program : edpp1, edkp1, eddp1,edk12, edk13, edk21,tede1, tede2, edmat, edmsg, edimsg.
Outbound Parameters Tables : EDPP1
Inbound Parameters Tables : EDP12,EDP13,EDP21.
By retrieving the data from the above tables which are storing the values of the application document and receiving , sending profiles by using SELECT statements, SUBROUTINES , FUNCTION MODUELES , the following things are executed.
- VALIDITY OF THE PARTNER PROFILES.
- GENERATION OF IDOC.
- CORRECT PORT ASSIGNMENT.
- GIVING A PROPER ERROR MESSAGE.
VERIFICATION OF IDOC:
Transaction Code : WE02.
VERIFICATION OF STATUS:
Transaction Code : WE05.
INBOUND PROCESS:
UNPACKING THE IDOC:
Transaction Code : WE19.
I have selected the same idoc which I have used for the outbound process and created a text file called in123.dat and saved the idoc in the current file.
Next, by selecting the function module IDOC_INPUT_MATMAS01, the inbound process flow is started and an incoming Idoc is created in the system.
VERIFICATION OF POSTING OF APPLICATION DOCUMENTS:
Transaction Code: BD87.
With this transaction , the application document is restored.
The final application document is viewed from the current location of the purchase order.
After all the settings are done, the successful posting of an EDI document in the outbound process is done by getting all the details from the data stored in the tables.
Program that I have written to get the details of the partner profiles, port definitions, is ZEFSKFLSDJ.
+91 -8897484484 FREE end_of_the_skype_highlighting (Between 2.30 PM and 6.00 PM)
