EDI

Former Member · ‎03-26-2008

CAN ANY SEND MATERIAL FOR EDI

THANK Q

Former Member · ‎04-05-2008

The EDI interface is used to connect an EDI subsystem to the SAP system. EDI subsystems perform all EDI-related tasks such as Converting the data Handling messages or interchanges Communications Managing the partner profiles Monitoring processing. The EDI interface is based on IDoc technology. IDoc technology is independent of EDI standards. All data is exchanged via files between the SAP System and the EDI subsystem. The synchronous RFC (remote function call) is used to define the time of transfer of the files between both systems. Via the EDI interface, the following data can be exchanged:

Outbound IDocs. IDocs are transferred from the SAP System to the EDI subsystem.

Inbound IDocs. IDocs are transferred from the EDI subsystem to the SAP System.

Status report. To inform the SAP System of the progress of processing of the outbound IDocs, the EDI subsystem transfers the status report to the SAP System.

The object of the certification is the technical test of the interface between SAP System and EDI subsystem. The transfer of outbound IDocs, inbound IDocs and the status report are tested. The test is performed for the EDI standard UN/EDIFACT. As an example, the messages used are:

Outgoing order (ORDERS)

Incoming order (ORDERS)

Outgoing order response (ORDRSP) and

Incoming order response (ORDRSP).

benifits of edi

Reduced data entry errors,

Reduced processing cycle time

Availability of data in electronic form

Reduced paperwork

Reduced inventories and better planning

The Outbound Process

1.The application document is created. The first step in the outbound process involves creating an application document such as a purchase order or sales order and saving it in the database tables. This step is no different from the way in which these documents are normally created. It is the following steps that have relevance to EDI. The document is created and leaves some hooks for the EDI process to begin.

2.the IDoc is generated. The application document just created is now formatted to an IDoc format. At this point you can think of IDoc as yet another format in which the application document has been represented. For example, think of how a date can be stored in different formats—imagine a date as a document with three components: day, month, and year. In one case, you represent it as MM/DD/YYYY, a standard American way of representing a date. To make it meaningful for a German partner, you have to represent it as DD.MM.YY. IDocs follow a similar concept of representing information in different ways. The data in the application document format is suitable for the application modules, screens, and internal programs. A document in an IDoc format is suitable for processing by EDI components, as later sections explain in more detail.

3.The IDoc is transferred from SAP to the operating system layer. The IDoc created in Step 2 resides in the SAP database repository. This IDoc document must be passed down to the operating system layer for processing by the EDI subsystem. In Step 3, the IDoc is transferred to the operating system as a text file. The document is still in an IDoc format. The only difference is the medium of storage.

4.The IDoc is converted to EDI standards. The IDoc format is an SAP proprietary format. For EDI purposes, the document in IDoc format has to be converted into an EDI standard format. Third-party software called a translator carries out the transformation process and reports status back to the SAP system. SAP refers to these translators as EDI subsystems, and has certified several subsystems for connectivity to SAP. SAP takes no responsibility for translation. Thus, from SAP's perspective, after the IDoc is delivered to the subsystem, SAP does not have control over the process, but it maintains the status reported by the EDI subsystem.

Caution SAP does not restrict you to using certified systems, but doing so adds assurance of connectivity, compatibility, and support. Because there are many technical and business issues to worry about, I do not recommend exploring non-certified systems.

5.The EDI document is transmitted to the business partner. After the document is converted to an EDI standard format, it is transmitted to a trading partner based on the partner's EDI settings. This step is not part of the SAP EDI architecture, but is mentioned here to describe the complete process from a business perspective.

6.The EDI subsystem reports status to SAP. When an IDoc is under the control of the EDI subsystem, the subsystem can optionally report the state of processing at various milestones back to the SAP system. This mechanism is always recommended because it provides complete visibility of the process from within SAP, and the user does not have to be involved with the intricacies of the EDI subsystem.

The Inbound Process

The inbound process simply reverses the steps of the outbound process.

The inbound process consists of five steps.

1.The EDI transmission is received. EDI documents are received from a business partner via the VAN. These documents are in one of the EDI standard formats. The documents are deposited in a common repository for the subsystem. This part of the process is not part of the SAP EDI architecture.

2.The EDI document is converted into an IDoc. The EDI-specific headers and trailers are stripped off, and the document is converted into an IDoc format suitable for SAP applications. The process is carried out at the EDI subsystem level.

3.The IDoc is transferred to the SAP layer. The IDoc created in Step 2 is stored in a text file at the operating system layer. The subsystem starts an inbound program in the SAP layer. This program reads the IDoc file and creates an IDoc in the SAP repository for further processing.

4.The application document is created. The IDoc received from the subsystem is passed to a posting program. This program creates an application document such as a sales order, purchase order acknowledgment, invoice, or shipment notice.

5.The application document can be viewed. The application document created via EDI is the same as any document created manually in the system: The document can be viewed using standard application transactions. For example, if an incoming sales order was created via EDI, you could view the sales order document via transaction VA03.

hope this material wil help to u

reward points if it is useful.

regards

dilip

Former Member · ‎04-07-2008

Hi,

This is a EDI guide and u can find more information.

If this is Useful Please give points.

Advanced guide to EDI configuration

1. PRE-REQUISITES FOR EDI

1.1. SAP R/3 system, Interfaces and EDI subsystem

The SAP EDI architecture consists of:

• EDI-enabled applications, to support the automatic processing of business transactions.

• The IDoc interface, which consists of IDoc types and function modules that form the interface to the application. There are IDocs available that support orders and invoices. IDocs are identical for inbound and outbound processing.

Eg. ORDERS02

• The EDI subsystem, which converts the IDoc types into EDI message types and vice versa. This component of the EDI architecture is not supplied by SAP, thus the existing ASI EDI subsystem will be used.

Eg: Gentran or Mercator

• EDI Interface between SAP R/3 system and EDI subsystem. For inbound processing, this involves opening the inbound message file, and processing the IDoc messages. For outbound processing, this involves selecting the outbound documents, creating an outbound message file and writing this file to the shared directory. The exact transfer times are scheduled using batch jobs. Please refer to ‘EDI Production Configuration Guide’ for further interface details.

1.2. Business Rules and Conditions

In the Interchange Agreement, with each vendor, the following will be stipulated:

• EDIFACT / ANSI X12 message type - this will link to the IDoc that will be used in SAP R/3.

• Time that the supplier will open his mailbox - this will dictate when transmissions can take place.

• Trading partner identification number.

• Version of EDIFACT / ANSI X12 that the supplier is using.

1.3. Overview of Concepts

1.3.1. Object types (IDoc):

IDoc type Logical message type Description

ORDERS01 ORDCHG Order change

ORDERS01 ORDERS Order

ORDERS01 ORDRSP Order response

INVOIC01 INVOIC Invoice

IDoc types are:

• partner independent

• identical for inbound and outbound processing

• dependent only on message types

• independent of EDI standards

• independent of subsets.

1.3.2. Message Control

Message control is a ‘conditioning technique’ used to direct output for business documents created by SAP transactions. For example, when a purchase order is created, it is the message control component that determines that the document should be sent to a printer, or alternatively via EDI or fax.

Message control consists of a hierarchy of decision structures (called condition components) to allow for flexible output determination. Each application is associated with an output procedure, and each procedure can be made up of several condition types (for multiple output). Access sequences are used to regulate how and whether a condition type is to be processed.

2. ONCE-OFF CONFIGURATION PER CLIENT

The following transactions should be followed in sequence. Most of the data should be pre-configured by SAP, however it is important that this is confirmed by examining each entry.

2.1. Set-up SAP Business workflow for error handling (PPOM)

Purpose: A workflow organisation (e.g. “EDI Department”) may be set-up where exceptions and error-messages generated during EDI processing can be directed (instead of only to a single user).

3.1H: Transaction: PPOM (Tools -> Business Engineering -> Business Workflow -> Organisation -> Definition Tools -> Organisational plan)

Define an Organisational Structure to be used in EDI Admin set-up by following the next steps:

2.1.1. Create Org Unit

Create an Org Unit, e.g. EDI Dept with a long description of EDI Department - All IDoc Notifications.

Choose the Staff assignments icon and complete the details.

2.1.2. Create Positions

Create the 'Manager' and 'staff' positions, leaving the job descriptions empty.

2.1.3. Assign Holders

Assign holders to each position.

2.1.4. Assign workflow tasks

Assign the workflow tasks to the entire department (for our purposes).

Click on Department, select the Task profile icon, assign task.

To assign the inbound order's error task, enter a search string of OR* in the pop-up menu. Select the following:

- ORDCHG_Error

- ORDERS_Error

- ORDSRP_Error

For Invoices use INV* as a search string and add the following:

- INVCON_Error

- INVOIC_FI_Er

- INVOIC_MM_Er

2.2. Configure EDI inbound processing workflow

Purpose: To activate the automatic processing of inbound IDocs using workflow methods.

2.2.1. Create Batch User

Confirm the following details with the Basis System Administrators and/or Workflow Configuration Specialist:

• A user for batch processing should be defined, typically user WF-BATCH.

• The batch user should have SAP_ALL and SAP_NEW authorisations.

• The batch user should be set as a background user

2.2.2. Configure Workflow for RFC (SWUB)

• Enter the batch user name (WF-BATCH) as well as the password.

• Click the “Test” button (or press the F5 key). This should result in a message “RFC Test successful”. Any other result indicates that the batch user WF-BATCH has not been set-up correctly or the password is incorrect.

• The details should be saved using the “Save” button or by pressing the F11 key.

2.2.3. Verify Workflow Customising (SWU3)

• The “Test RFC” item should have a red cross next to it.

• Press the “Autocustomize” button (F6) and workflow should be re-customised.

• Use the “Test RFC dest.” Button or press the F7 key to test the RFC destination. This should result in the message “Ping performed successfully”.

• The red cross on the item list should now be a green tick.

2.2.4. Workflow Configuration Notes

If this procedure does not work as expected, it may be due a problem in the release code for V3.1H. Confirm that OSS Note 81974 has been applied by a Basis administrator. This requires a source code change to be made.

2.3. Cross Application /IDoc interface/EDI components: (SPRO)

Purpose: To enable/configure EDI parameters and configuration for entire client.

All changes to default configuration should be documented using the “Notes” facility in the IMG. (Ref. Appendix B - SAP Notes Format). This assumes that an ALE/EDI project view has been set up by the BASIS system configuration team. (Ref. Appendix A - Authorisations).

3.1H: IMG Cross-Application Components IDoc interface/Electronic Data Interface IDoc interface

2.3.1. Create IDoc number range: (OYSN)

Number range for IDocs called EDIDOC.

Will use internal numbering.

Use only one number range.

2.3.2. Create Port definition number range: (OYSN)

Number range for generated port names, called EDIPORT.

Will use internal numbering.

Use only one number range.

2.3.3. Create IDoc type number range: (OYSN)

Number range for IDocs called EDIDocTYP.

Assigns numbers internally for IDoc types when they result from the automatic combination of basic IDoc types and customer extensions.

2.3.4. Set-up IDoc administration: (WE46)

Set up EDI client-specific system parameters:

For Rel 3.1H:

- MAXSYNERR - maximum number of syntax errors that will be logged in the status records. Default is 15, for testing use 30 (maximum allowed).

- EDIADMIN - IDoc administration

User to notify in case of an EDI Basis error.

Type in EDIADMIN, tab to System Parameter field, select organisational unit - SAP will insert Org structure number as created by SAP EDI workflow (refer previous point).

- TESTPORT eg. SAPF01

Name of the port that will be used as a default in the IDoc turn-around utility. Type portname in, since it can't be selected.

- SEGDVCLASS - Development class for segment editor.

Optional. When IDocs are extended, this is the default development class for the R/3 correction and transport system.

- IDOCEDIT (Ref. Chapter 1-26)

Optional. If blank, system allows user-developed IDoc extensions.

2.3.5. Convert error processes:

Information about error processes - confirm that they exist.

2.3.6. Activate event coupling for inbound processing

Once the workflow has been set up as described in the section “Configure EDI inbound processing workflow”, the event coupling may be activated using this item. This allows inbound processing to be started when IDocs are read into the SAP system.

• Dialogue box with message “Activate IDoc Inbound?” should appear.

• Choose the “Yes” Button.

• Message “Event-event receiver coupling activated successfully” should appear.

2.3.7. Authority Management

This is about the authority to perform a particular action in R/3, for example EDI Administrator. Refer to appendix A.

2.4. Cross Application/ ALE Components:

2.4.1. PORT Definition (WE21)

Definition of directory location and name of shell script to be executed to trigger EDI subsystem.

3.1H: IMG Cross-Application Components  ALE  Communication  Manual maintenance of partner profile  Define port

Under port type File create the relevant port names for example SAPF01.

The version indicator control how the control record of outbound IDocs is created - an indicator of '2' will write the control record in the format of R/3 release 3.0.

Please note that these parameters depend on the EDI sub-system features. For further details, refer to the EDI Technical Interface guide.

Enter the rest of the parameters as follows:

Parameters <Portname>

Command file parameters - mandatory

Logical destination: SERVER_EXEC

Directory: /home/edi/<portname>/

Shell script: start_converter

Automatic button:(1-5) Will not be used

Outbound file parameters - mandatory

Directory: /home/edi/<portname/

Outbound file: edi_out

Function module: See text below

Inbound file parameters

Directory: /home/edi/<portname/

Inbound file: edi_in

Function module: See text below.

Status file parameters

Directory: /home/edi/<portname>/

Outbound file: status.idoc

Function module: Leave blank if using above

• Both the portname and the exchange directory should be created according to the same naming convention. However, the portname should be in upper case whereas the corresponding directory name should be in lower case (see examples below).

Portname (upper case):

Exchange directory name (lower case):

/home/edi/<portname>

where <portname> consists of:

EDI<system name><client number><id char>

<system name> is the name of system on which port exists eg. DEV, PRD etc.;

<client number> is name of client on system which will use this port; and

<id char> is a single alphabetical character such as ‘a’,’b’ etc. typically, ‘a’ will denote dynamic outbound file naming (used for testing) whereas ‘b’ will denote static outbound file naming. All ports will use static inbound filenames.

For example, the name of a port using dynamic file naming on system DEV, client 110 would be named EDIDEV110A. The exchange directory would be named edidev110a.

Note that the function “EDI_PATH_CREATE_USERNAME_DT_TM” can be used in the “Function module” field of the Outbound file parameters if IDocs are to be written to multiple files. In this case, the corresponding outbound filename field should be left blank. The standard IDoc exchange interface between the SAP EDI component and the EDI subsystem uses a single file for each transfer direction. However, should the exchange interface change, or for testing purposes, the function modules for dynamic naming can be used.

2.4.2. Control of EDI processes in R/3

2.4.2.1. Maintain: Outbound Process Code (WE41)

3.1H: IMGCross-Application ComponentsALE Extensions  Outbound

Check that the outbound EDI processes in the R/3 system are defined. Indicates which ABAP/4 function module to execute in order to create an outbound IDoc.

The following assignments are available for R/3:

2.4.2.2. Maintain: Inbound Process Code (WE42)

3.1H: IMGCross-Application Components  ALE  Extensions  Inbound

Check that the inbound EDI processes in the R/3 system are defined. Indicates what kind of inbound processing to execute.

A long list of options is available under Processing by function module, relevant ones are:

INVF INVOIC FI Invoice receipt (Financial Accounting)

INVM INVOIC MM Invoice verification (Mat Management)

ORDC ORDCHG Change customer order

ORDE ORDERS Create customer order

ORDR ORDRSP Purchase order confirmation

2.4.2.3. Control: System Process Codes (WE40)

Choose Processing by task. Check that the codes indicating the type of EDI processing error are defined. The only valid entries are the entries shown on the screen, as they are directly called via the EDI basis module.

2.4.2.4. Control: Status maintenance (WE47)

Check that the codes indicating status of IDoc processing are defined. The status values for outbound IDocs are between 01 and 39, while the status values for inbound IDocs begin with 50. These values are delivered by SAP and cannot be customised.

2.4.2.5. Control: Partner Types (WE44)

Check that the codes that identify the commercial relationships between the receiver and sender are defined. Values are delivered by SAP. Names of the programs and routines that validates the entry of the EDI trading partner ID:

Partner type Report name Form routine

B - Bank RFETESTP READ_T012

KU - customer RSETESTP READ_KNA1

LI - vendors RSETESTP READ_LFA1

LS - logical system ( ALE) RSETESTP LOGSYS

2.4.2.6. Control: Forward Inbound (WE45)

Allows for the forwarding of IDocs to a specific application. Contains the exactly defined destination of an inbound IDoc within the SAP system. Usually no changes are required.

2.4.2.7. Control: Status Process code (WE56)

Choose Processing by task: The following set-up has been provided as default:

Process code: EDIS

Identification: TS30000078

Description: EDI-IDoc status record processing

The process code is for inbound status, The ID type is an identification code for inbound processing method (workflow or standard task) of the status record.

3. MM IMG CONFIGURATION

3.1. Global settings (IMG):

3.1.1. Units of measure (IMG  Global settings):

The ISO code is important for EDI. It is used to convert the internal SAP units of measure into standard units.

The MM configurer must link the Unit Of Measure, EACH, with the ISO code PCE (Piece).

3.2. Link Schema to Purchase order

Check the following:

3.1H: IMG  MM  Purchasing  Message determination  Message determination  Message Schemas

Execute transaction “Define Message Schemas for Purchase Order” (M/36)

Select transaction: Assign Schema to purchase order

Add: Usage =B for output

Application = EF for purchase order

Procedure = RMBEF1 for purchase order

3.3. Link application to EDI interface via message control:

3.1H: IMG  MM  Purchasing  Messages  Output Control

Check following under Output Control:

Condition table

Access sequence

Message types

Message schema

Output control

3.4. Enabling Multiple Output for Purchase Orders (Optional)

For example: EDI & Printing

3.1H: IMG  MM  Purchasing  Message determination  Message determination Access sequence

• Create new access sequence (e.g. ZPUR), copy the access sequence 0001 but leaving the ''E'' flag blank (Exclusive is off). (Transaction M/50)

• Goto Define message types  maintain message types:

Create a new message type (e.g. NEU1), setting the output type to 1 for printed output and using ZPUR as access sequence. (Transaction M/34)

• Goto Message Schema  define message schema  maintain output determination procedure:

Update procedure RMBEF1 by adding a step for the new condition type (e.g. NEU1) prior to the standard delivered step for NEU. (Transaction M/36)

• Goto Processing program  Define Processing program  Output program: Purchase Order.

- Add a NEU1 record to table TNAPR. The program FORM Routine and layout must be specified. (Copy an existing NEU record). (Transaction OMTB)

• Goto Processing program  Define Processing program  Output by partner type.

- Add NEU1 record for VN (vendor). (Transaction OMTG)

3.5. Link Output type (fax=2, E-mail=7) to NEU (Purchasing)

3.1H: IMG  MM  Purchasing  Message determination  Message determination Access sequence

• Goto Processing program  Define Processing program  Output program: Purchase Order.

- Add another NEU record to table TNAPR with the appropriate output medium. Copy an existing NEU record. (Transaction OMTB)

• Goto Processing program  Define Processing program  Output by partner type.

- Add NEU record for VN (vendor). (Transaction OMTG)

4. SD APPLICATION REQUIREMENTS

Assumption: SD is only used for testing purposes and configuration is based on a need basis - only configure the minimum.

Reference SAP Course manual Chapter 11.

4.1. EDI Configurations

4.1.1. Conversion of SAP item categories to IDOC item categories (VOE1)

3.1H: IMG  S&D  EDI  EDI Messages  Conversion of SAP item categories to IDOC item categories

Add the following entry:

For Standard Item description : 0 OR LDN

Typically error message: ''Transaction LDN is not defined".

4.1.2. Partner functions

3.1H: IMG  S&D  EDI  EDI Messages  Configure EDI Partners Partner  Application  Partner function

Check that the following partner functions exist: (at least)

SP Sold-to party

VN Vendor

BP Bill-to party

SH Ship-to party

Note - the German abbreviation is passed to the IDoc.

4.2. S&D Sales Configurations

4.2.1. Maintain Item categories

IMG  S&D  Sales  Sales document  Sales doc item  Define item categories

Add LDN for standard item:

Item type = B

Relev for billing = B

Tick following: Bus data item

Sched line allowed

Credit active

Pricing

Screen seq. grp = N

4.2.2. Assign Item categories

3.1H: IMG  S&D  Sales  Sales document  Sales doc item  Assign item categories

Add/Update the following entries:

1 2 3

Sales doc type OR OR OR

Item category group NORM DIEN LEIS

Item category LDN TAD

LDN LDN

4.2.3. Assign Schedule line categories

3.1H: IMG  S&D  Sales  Sales document  Schedule lines  Assign Schedule line categories

Add Item category LDN to table (with no other parameters).

4.3. S&D Pricing Configurations

4.3.1. EDI pricing condition types

3.1H: IMG  S&D  Basic functions  Pricing  Pricing control  Define condition types  Maintain condition types

Maintain the following condition types:

EDI 1 - Calculate type =C for Quantity

EDI 2 - Calculate type = B for Fixed amount

4.3.2. SD Pricing procedures (V/08)

IMG  S&D  Basic functions  Pricing  Pricing control  Define & Assign pricing procedures

Maintain pricing procedure for ZVAA01 (Standard).

Select control and add EDI1 and EDI2 as steps 1 and 5 respectively with no other parameters.

Former Member · ‎04-07-2008

Hi,

Check the following links

See the below links

/people/bla.suranyi/blog/2006/06/08/sap-xi-supports-edifact

/people/william.li/blog/2006/03/17/how-to-get-started-using-conversion-agent-from-itemfield

/people/paul.medaille/blog/2005/11/17/more-on-the-sap-conversion-agent-by-itemfield

http://www.stylusstudio.com/edi/XML_to_X12.html

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/b0b355ae-0501-0010-3b83-8f2...

Check this for Conversions-

/people/bla.suranyi/blog/2006/06/08/sap-xi-supports-edifact

http://www.seeburger.it/fileadmin/it/pdf/2005_04_sapphire_Ferrero_transcript.pdf

http://www.seeburger.com/fileadmin/com/pdf/Butler_Group_SEEBURGER_Technology_Audit.pdf

http://www.seeburger.com/fileadmin/com/pdf/AS2_General_Overview.pdf

http://www.seeburger.com

http://www.seeburger.com/fileadmin/com/pdf/AS2_General_Overview.pdf

http://www.seeburger.it/fileadmin/it/pdf/2005_04_sapphire_Ferrero_transcript.pdf

http://www.seeburger.com/fileadmin/com/pdf/SEEBURGER_SAP_Adapter_engl.pdf

http://www.seeburger.com/fileadmin/com/pdf/Butler_Group_SEEBURGER_Technology_Audit.pdf

http://www.sap.com/france/company/events/2006/02-01-Automotive-Seeburger.pdf

http://h41123.www4.hp.com/presentations/ISUG/XISeeBurger.ppt

http://www.sap.com/asia/company/events/nwtechdays/presentation/australia-slides/Pre-Built_Integratio...

Cn you plz let me know ifyou have any queries

Gentran is one of the most wide used edi subsytems

What is EDI?

EDI is commonly defined as the computer-to-computer exchange of common business documents using a standardized format. It is more specifically defined as the automatic company-to-company exchange of information for common business functions such as purchasing, invoicing, remittance advises, transportation, etc. With EDI, electronically transmitted data replaces paper documents (e.g., purchase orders, invoices, purchase acknowledgment) throughout the business transaction cycle. Data is “translated” into a standard format sent most commonly through public data transmission networks.

EDI stands for ELCTRONIC DATA INTERCHANGE.

as the name specifies,it is used to transfer the data from SAP to non sap or nonsap to SAP.

with particular standards like ASNSI12,EDICFACT,etc...

EDI subsytems are,

Gentran,Tibco

http://www.netweaverguru.com/EDI/HTML/IDocBook.htm

http://www.sapgenie.com/sapedi/idoc_abap.htm

www.sapgenie.com/sapedi/edi_sap_training.htm

www.sap-img.com/basis/ difference-between-edi-and-idoc.htm

help.sap.com/saphelp_nw04/helpdata/ en/35/26b592afab52b9e10000009b38f974/content.htm

help.sap.com/saphelp_nw04/helpdata/ en/35/26b594afab52b9e10000009b38f974/content.htm

http://www.onestopsap.com/interview-Question/edi/