Advanced guide to_edi_configuration

Advanced guide to EDI configuration – 4.5B

Advanced guide to EDI configuration
4.5B

Print Date: 14/01/1998 06:51:00 PM Version 1.0 Page 1 of 17


Table of Contents
1. PRE-REQUISITES FOR EDI.............................................................................................4
1.1. SAP R/3 system, Interfaces and EDI subsystem.............................................................4
1.2. Business Rules and Conditions.......................................................................................4
1.3. Overview of Concepts.....................................................................................................4
1.3.1. Object types (IDoc):.................................................................................................4
1.3.2. Message Control.......................................................................................................5
2. ONCE-OFF CONFIGURATION PER CLIENT..............................................................6
2.1. Set-up SAP Business workflow for error handling (PPOM)..........................................6
2.1.1. Create Org Unit........................................................................................................6
2.1.2. Create Positions........................................................................................................6
2.1.3. Assign Holders.........................................................................................................6
2.1.4. Assign workflow tasks.............................................................................................6
2.2. Configure EDI inbound processing workflow................................................................6
2.2.1. Create Batch User....................................................................................................7
2.2.2. Configure Workflow for RFC (SWUB)..................................................................7
2.2.3. Verify Workflow Customising (SWU3)..................................................................7
2.2.4. Workflow Configuration Notes...............................................................................7
2.3. Cross Application /IDoc interface/EDI components: (SPRO)........................................7
2.3.1. Create IDoc number range: (OYSN).......................................................................7
2.3.2. Create Port definition number range: (OYSN) .......................................................8
2.3.3. Create IDoc type number range: (OYSN)...............................................................8
2.3.4. Set-up IDoc administration: (WE46).......................................................................8
2.3.5. Convert error processes:...........................................................................................9
2.3.6. Activate event coupling for inbound processing......................................................9
2.3.7. Authority Management ..........................................................................................9
2.4. Cross Application/ ALE Components:............................................................................9
2.4.1. PORT Definition (WE21)........................................................................................9
2.4.2. Control of EDI processes in R/3............................................................................10
3. MM IMG CONFIGURATION.........................................................................................14
3.1. Global settings (IMG):..................................................................................................14
3.1.1. Units of measure (IMG  Global settings):..........................................................14
3.2. Link Schema to Purchase order....................................................................................14
3.3. Link application to EDI interface via message control:................................................14
3.4. Enabling Multiple Output for Purchase Orders (Optional)..........................................14
3.5. Link Output type (fax=2, E-mail=7) to NEU (Purchasing)..........................................15
4. SD APPLICATION REQUIREMENTS..........................................................................16
4.1. EDI Configurations.......................................................................................................16
4.1.1. Conversion of SAP item categories to IDOC item categories (VOE1).................16
4.1.2. Partner functions....................................................................................................16
4.2. S&D Sales Configurations............................................................................................16
4.2.1. Maintain Item categories........................................................................................16
4.2.2. Assign Item categories...........................................................................................16
4.2.3. Assign Schedule line categories.............................................................................17
4.3. S&D Pricing Configurations.........................................................................................17
4.3.1. EDI pricing condition types...................................................................................17
4.3.2. SD Pricing procedures (V/08)................................................................................17



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.
Conditioning Technique
1-1

Output procedure i.e.MM/SD application associated with

1-many How to handle output
Eg. NEU (for purchase order via EDI)
Condition types Output Medium (EDI)
Timing (Immediately etc.)
Partner Function
Output Spool
1-1

“How and If” of Condition Types
Based on run-time data
Determines output by MM or SD
Access Sequence
Output at run-time
General vs Specific



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):
<portname>
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.


Advanced guide to_edi_configuration

More Related Content

Viewers also liked (7)

Similar to Advanced guide to_edi_configuration (20)

Recently uploaded (20)

Advanced guide to_edi_configuration