EDI Application Data for Automotive Suppliers - h3 IT Ch3-itc.eu/BP-EDI_Automotive_EN_DE.pdf · SAP...

SAP ECC 6.00

March 2007

English

EDI Application Data for Automotive Suppliers

SAP AG Dietmar-Hopp-Allee 16 69190 Walldorf Germany

Overview Document

SAP Best Practices EDI Application Data for Automotive Supplier

Copyright

© Copyright 2007 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.


Introduction

Electronic Data Interchange

Electronic Data Interchange (EDI) is used to electronically exchange business documents, such as schedule lines, purchase orders, invoices, and so on.

Because of the particularly large volumes of data and very high logistical demands, EDI is now indispensable in logistics for the automobile industry. Just-in-time processing and optimized utilities processes for production require fast reliable data transmission between business partners.

To enable partners to communicate, it is necessary to define the route via which data is exchanged (point-to-point, mailbox, and so on), and the structure and format of the data exchanged.

For this purpose, EDI standards have been defined, which specify the structure and format of the individual business documents. These include the UN/EDIFACT standard, ANSI1 X.12 or VDA2, or the ODETTE3 standard, all of which are used in the automobile industry.

R/3 IDoc Concept

IDoc4 is a standard SAP format for exchanging data between systems. It can be used to exchange data between R/3 Systems (ALE5), and between R/3 Systems and non-SAP systems (for example, an EDI subsystem, or a warehouse management system).

EDI and ALE

Document

IDoc

Message

IDoc IDoc

SAP R/3 System

SAP R/3 System

EDI Subsystem

EDI Subsystem

SAP R/3 System

SAP R/3 System

EDI Subsystem

EDI Subsystem

1 American National Standards Institute – www.ansi.org

2 Verband der Automobilindustrie – www.vda.de

3 Organisation for Data Exchange by Teletransmission in Europe – www.odette.org

4 Intermediate Document

5 Application Linked Enabling


The format of the IDoc is completely independent of the database structures of the individual business documents; in other words, the IDoc functions as a data container between the application formats and is used by both systems as a "language" in which they can "communicate".

R/3 System

System 1

SAP Application

Document

EDI Subsystem

R/3 System

R/2 System

Other non-SAP System

System 2

Document IDoc

Asynchronous Processing Message Based

To convert EDI messages to the corresponding IDoc, an EDI subsystem (converter, translator) is required. This system converts the data from the EDI standard to IDoc.

In the IDoc interface, additional settings must be made. These are required for correct IDoc processing and fault-free application document updates. The IDoc interface is designed to operate asynchronously; in other words, the application document update is not directly linked to receipt of the IDoc.


Critical Success Factors

EDI Requirements

EDI Project

To execute the EDI project, it is necessary to consider a number of points. The scope of the project and the outlay required depend on the particular company and industry sector, which means that these factors must be assessed on a customer-specific basis. Since the scope and use EDI has increased considerably in recent years (particularly in the automobile industry), if an EDI project is to be executed successfully, it is absolutely essential to plan internal and external outlay.

As a general rule, it should be ensured that EDI projects are executed in good time and take into consideration the individual modules involved. This means that EDI processing must be considered when each of the modules is implemented. Otherwise, there is a danger that processes that have already been defined and implemented will have to be rethought and modified, which can entail considerable additional outlay.

In the following, the most important points for successful execution are described.

Selecting partners

To determine the scope of the project, the business partners with whom EDI is intended are specified. The messages exchanged and the EDI standards used are also specified.

General speaking, configuring inbound messages requires approximately 3-5 times as much outlay as configuring outbound messages.

In sales and distribution, customers generally specify whether they wish to communicate via EDI and which messages and standards should be used.

In procurement, it is usually possible to determine the scope, duration, and size of the EDI project oneself, thereby enabling distortions in scheduling to be corrected.

In addition to the above, it is necessary to estimate the data volume that can be expected every month, since this can influence the number of application servers or the size of the R/3 System.

If you foresee a large number of IDocs that have to be imported time-critically to the system during periods of maximum work load, it is certainly advisable to consider setting up your own application server for IDoc processing.

To convert EDI messages (for example, VDA or ANSI X.12) to IDoc format, an EDI subsystem is required. It is necessary to select a suitable product. Since the IDoc interface is an open interface, it is compatible with products from various subsystem providers.

SAP AG does not provide EDI subsystems. SAP-certified subsystem providers are listed, however, in SAPNet at http://www.sap.com/csp/products under "Cross Application - Miscellaneous".

Please note that the certification involved here is a technical/functional certification of the subsystem; in other words, tests are carried out to determine that IDocs can be transmitted and received, and that a status report can be generated for transmitted IDocs. This certification does not test the business functionality of the subsystem!

Implementing the EDI procedure

It is advisable to carry out implementation in five steps:


1. Complete implementation of the SAP application To allow the EDI or IDoc functionality to be implemented, the SAP applications involved must already be installed. The applications must be configured to take EDI in account.

2. Internal test of the IDoc interface The test comprises the technical/functional test (for example, communication between the subsystem and R/3 System), as well as a business/functional test (for example, updating of individual documents, test of the partner profile set).

3. Local test with EDI subsystem Tests are carried out to ensure that the outbound and inbound IDocs can be processed correctly by R/3 or the subsystem.

4. Remote test with EDI subsystem The remote test focuses on communication with the business partner, as well as the processing of messages by the partner system involved.

Going live

To ensure successful operation, all tests must be completed successfully before the go-live date. At the start of production operation, when real data is imported to the system from business partners, adjustments will nonetheless be required.

Examples of possible problems include: incomplete conversion in the subsystem, incomplete master data and movement data, and so on. During the initial phase, it is particularly important that you observe all inbound IDocs closely, and rectify any defects quickly.

Further information on this topic can be found in the SAPNet - R/3 Frontend (Note 47071).

Message Types

With EDI, message types are normally allocated uniquely to SAP document types. Their names correspond, on the whole, to those of the UN/EDIFACT standard. The message type ORDERS is, therefore, allocated to the SAP document type Purchase Order or Sales Order.

a) Forecast/JIT delivery schedule

On the basis of material requirements planning, schedule lines are created, which are transmitted to the vendor as forecast or JIT delivery schedules (FDS/JIT). In the vendor's system, the inbound schedules create customer requirements, which are forwarded to materials planning, and subsequently delivered.

b) Shipping notification (EDI delivery note)

When the precise delivery date of the scheduled material has been fixed by the vendor, the appropriate shipping information can be transmitted to the customer in the form of shipping notifications. The customer uses these shipping notifications to carry out precise receipt planning and support goods receipt.

c) Delivery order (MAIS)

When the precise delivery date for the scheduled material has been specified by the customer, the appropriate delivery information is transmitted to the vendor in the form of delivery orders (also known as MAIS orders or MAIS delivery schedules). The vendor uses the delivery orders to control shipping.

d) Credit memo procedure

In the automobile industry, it is not customary for vendors to invoice delivered goods. The customer usually valuates the delivered goods with the agreed prices in the outline agreements and forwards the appropriate credit memos to the vendor.


Outputting MM credit memos (or the related option of EDI output) is available as of Release 4.0.

e) Invoices (alternative to credit memo procedure)

As an alternative to the credit memo procedure, the vendor can also send invoices to the customer, which is processed by invoice verification in the customer's system.

f) Clearing invoice

If changes are made to the prices for deliveries that have already been delivered and settled, the customer subsequently creates clearing invoices with which possible credit/debit memos are transmitted to the vendor. Outbound processing (MM) of this subprocess is not implemented in the R/3 System.

g) Payment advice note

Payment advice notes are used to transmit information concerning the payment transactions to the vendor. As a rule, these payment advice notes refer to the credit memos or invoices transmitted previously. This means that when amounts correspond, the relevant open items can be automatically cleared by the receiver.

Outbound Messages

The message types listed in the following tables represent a selection of the most important inbound and outbound EDI messages implemented in the R/3 System.

Direction

Mess. type

Description IDoc type EDIFACT

ANSI

X12

VDA ODETTE

From Release

Process code

CARNOT Delivery: Shipping notification

DELVRY01 4922 40A DELV

O DELFOR Delivery schedule (FDS) DELFOR01 DELFOR 830 4905 DELINS

45A ME14

O DELINS Delivery schedule (FDS) DELFOR01 DELFOR 830 4905 DELINS

30A ME14

O DELINS Delivery schedule (JIT) DELFOR01 DELJIT 862 4915 DELINS

40A ME13

O DELINS Delivery schedule (JIT) DELFOR01 DELJIT 862 4915 DELINS

40A ME13

O DELJIT Delivery schedule (JIT) DELFOR01 DELJIT 862 4915 DELINS

45A ME13

O DESADT Shipping notification DESADV01 4913 AVIEXP

30A SD06

O DESADV Delivery: Shipping notification

DESADV01 DESADV

856 4913 AVIEXP

30A SD05


DELVRY01 DESADV

856 4913 AVIEXP

40A DELV


DESVRY02 DESADV

856 4913 AVIEXP

45A DELV


DESVRY03 DESADV

856 4913 AVIEXP

46A DELV

O GSVERF Cred. memo procedure GSVERF01 DEBADV

812 4908 INVOIC

30A GSVE

O INVOIC Invoice/Billing document INVOIC01 INVOIC 810

880

4906 INVOIC

30A SD09

O INVOIC Invoice/Billing document INVOIC01

INVOIC02

INVOIC

30A

40A

SD08

O ORDCHG Purchase order/order change

ORDERS01

ORDERS02

ORDERS03

ORDERS04

ORDERS05

ORDCHG

860

876

30A

30E

40A

45A

46A

ME11

O ORDERS Purchase order/order ORDERS01 ORDER 850 4925 30A ME10


Direction

Mess. type


ANSI

X12

VDA ODETTE

From Release

Process code

ORDERS02

ORDERS03

ORDERS04

ORDERS05

S 875 30D

40A

45A

46A

O ORDRSP Purchase order/order confirmation

ORDERS01

ORDERS02

ORDERS03

ORDERS04

ORDERS05

ORDRSP

855

865

4926 30A

30E

40A

45A

46A

SD10

O PAB_ORDERS

Quantity release from KANBAN

ORDERS03 DELJIT 4915 45A PJNO

O SBINV Credit memo procedure with invoice creation

GSVERF01 INVOIC 810

820

INVOIC

45A SBII

O REMADV Payment advice note PEXR2001

PEXR2002

REMADV

820 4907 REMADV

30A

45A

ALE

Inbound Messages

Direction

Mess. type


ANSI

X12

VDA ODETTE

From Release

Process code

I DESADV Delivery: Shipping notification

DESADV01 DESADV

856 4913 30A DESA


DELVRY01 DESADV

856 4913 40A DELS


DESVRY02 DESADV

856 4913 45A DELS


DESVRY03 DESADV

856 4913 46A DELS

I EDLNOT EDL delivery notes DESADV01 INVRPT 846 4913 30A EDLN

I DELJIT Delivery schedule (JIT) DELFOR01 DELJIT 862 4915 45A DELI

I DELORD Delivery order (MAIS procedure)

ORDERS03 DELJIT 40A DELO





I DELINS Delivery schedule (FDS) DELFOR01 DELFOR

830 4905 30A DELI

I DELFOR Delivery schedule (FDS) DELFOR01 DELFOR

830 4905 45A DELI

I GSVERF Credit memo procedure for logistics invoice verification

GSVERF01 812 4908 46A MRRL

MRKO

MRNB

I INVOIC Invoice receipt

(MM – invoice verification)

Message variant MM

INVOIC01 INVOIC 810

880

4906 30A INVM

I INVOIC Invoice receipt

(MM – logistics invoice verification)

Message variant MM

INVOIC01 INVOIC 810

880

4906 40A INVL

I INVOIC Invoice receipt (FI)

Message variant FI

INVOIC01 INVOIC 810

880

4906 30A INVF

I KANBAN KANBAN call KANBAN01 DELJIT 4915 45A KANB

I ORDERS Purchase order/order ORDERS01

ORDERS02

ORDERS03

ORDERS04

ORDERS05

ORDERS

850

875

4925 30A

30D

40A

45A

46A

ORDE

I ORDERS Purchase order/order ORDERS01 ORDER 850 4925 30A ORDE_


Direction

Mess. type


ANSI

X12

VDA ODETTE

From Release

Process code

ORDERS02

ORDERS03

ORDERS04

ORDERS05

S 875 30D

40A

45A

46A

BY_WF

I ORDCHG Purchase order/order change

ORDERS01

ORDERS02

ORDERS03

ORDERS04

ORDERS05

ORDCHG

860

876

30A

30E

40A

45A

46A

ORDC

I ORDRSP Purchase order/order confirmation

ORDERS01

ORDERS02

ORDERS03

ORDERS04

ORDERS05

ORDRSP

855

865

4926 30A

30E

40A

45A

46A

ORDR

I REMADV Payment advice note PEXR2001

PEXR2002

REMADV

820 4907 30A

45A

REMA

Note: Further development of DESADV01 is discontinued as of 40A.

Workflow Tasks of Inbound Messages

Exception or error handling is defined as a workflow. The exception handling tasks provided by SAP for the IDoc interface are single-step tasks.

The following table lists the single-step tasks that can arise in inbound processing if a fault occurs in updating the application.

Message Type Message Variant WF Task Description WF Task

DESADV DESADV_error TS00008178

EDLNOT EDLNOT_error TS00008065

DELJIT DELINS_error TS00008000

DELORD DELORD_error TS20000117

DELINS DELINS_error TS00008000

DELFOR DELINS_error TS00008000

GSVERF GSVERF_error TS 00008175

INVOIC FI INVOIC_FI_er TS 00008056

INVOIC MM INVOIC_MM_er TS 00008057

KANBAN KANBAN_error TS 24500055

ORDERS ORDERS_error TS 00008046

ORDCHG ORDCHG_error TS00008115

ORDRSP ORDRSP_error TS 00008075

REMADV REMADV_error TS 00007949

EDI Subsystems

Selecting the Subsystem

A large number of EDI subsystems are available on the market, most of which are used to communicate with partners and convert EDI standards. Certified providers are listed in SAPNet at http://www.sap.com/csp/products under "Cross Application - Miscellaneous".

When the subsystem is selected, attention must be paid to the following questions:

1. How many/which business partners and messages are selected for EDI messages?

2. Can all the desired messages be processed?

3. Do conversion tables already exist for specific messages and business partners? (For example, VDA 4905 to IDoc type DELFOR01.)


4. What total costs will arise - software licenses, installation, creation of conversions, and (if necessary) maintenance and support for the subsystem?

5. Can the original messages be archived? (Please note legal stipulations.)

6. What are the technical prerequisites?

7. Can the subsystem be expanded flexibly and simply to include additional partners and messages?

8. Who will create or adjust conversion tables; who will carry out maintenance for the subsystem? Is outsourcing operation desired and feasible?

9. Can status confirmations (information about the processing status in the subsystem) be sent to the R/3 System?

Installing the Subsystem

When subsystems are installed, attention must be paid to the following questions:

1. Where is the subsystem installed?

2. Is a breakdown strategy necessary?

3. What are the technical prerequisites for communication with partners or with the R/3 System – leased line, switched line, protocols X.25, X.400, and so on?

4. What data volume is likely to accrue?

Mapping

To convert data from the EDI standard to IDoc format, it is necessary to specify how the conversion is to be carried out; in other words, fields of the EDI standard are allocated to fields of the IDoc format. These allocations can be of varying degrees of complexity. This type of allocation is called mapping.

R/3 IDoc Interface

The following is a useful procedure for Customizing and configuring the IDoc interface:

1. Carry out basis customizing of the IDoc interface.

2. Configure IDoc administration.

3. Define workflow setting in Customizing for Basis.

4. Specify the ports to be used.

5. Configure the partner profile.

Customizing

Basis Customizing for the IDoc interface can be found under Basis Components Basis Services IDoc Interface/ Electronic Data Interchange. Customizing for Distribution (ALE) can be found under Basis Services Distribution (ALE).

In the following, the most important Customizing points are presented.

Logical system

To transmit and receive data via the IDoc interface, it is necessary to identify the R/3 System uniquely. This is particularly important in a distributed R/3 landscape. The logical system is used for this purpose.


A logical system is an application system in which the applications interact on the basis of shared data. In SAP terms, a logical system corresponds to a client; in other words, the logical system is the unique identification of a client across several R/3 Systems. The name of the logical system can be selected freely: it is expedient, however, to consider a naming convention.

You define the logical system in ALE Customizing.

Example: <Systemname>CLNT<Client>; (R3TCLNT100 or R3PCLNT800)

Changing the name of the logical system in the production system is not recommended. (On this point, see Note 187297).

Event receiver linkage

In this section, the event receiver linkage will be activated. IDocs in inbound processing are initially stored in the database and then transferred to application-specific inbound processing, which is determined via the partner profile. Except with port type 'tRFC', this transfer is trigger by the event PROCESSSTATEREACHED.

With event receiver linkage, the standard task TS30200090, which carries out processing (the 'event receiver'), is linked to this event and activated.

This has particular advantages with large data quantities imported via the file interface, as well as with parallel updates, since reading the file and updating the application are carried out separately.

General settings

1. Global Parameters: You specify general settings, such as the EDI administrator and other processing details, in Customizing under "IDoc Administration".

2. In IDoc Administration (Control IDoc Administration), you can also maintain user parameters, such as test port, list views, and so on.

Long names – short names

The extended namespace has been introduced as of Release 4.0. This means that as of 4.0 new or customer-specific objects can have longer names. This affects the following objects in the IDoc interface:

1. Message type (formerly 6 digit).

2. IDoc type (formerly 8 digit).

3. Segment name (formerly 7 digit).

4. Allocation basic type + extension as of 4.0 a new IDoc type has been defined.

In other words, when communication is carried with an EDI subsystem that can interpret only IDoc types based on the Release 3.x naming convention, the IDoc types must be converted, or IDoc types that have been expanded must be assigned to a new IDoc type.

Workflow Autocustomizing

"Workflow Autocustomizing" carries out the basic settings in Workflow required for IDoc processing. Workflow Customizing settings made earlier are not overwritten.

The settings are not transported; in other words, you also have to carry out this step in the production system.

The following steps are carried out with Autocustomizing:

Configuration of a client-dependent RFC destination ("WORKFLOW_LOCAL_<Client>").

Scheduling of a background job for deadline monitoring.


Setting of an active plan version.

Classification of single-step tasks as general tasks.

Maintenance of a system administrator for Workflow.

Application-specific Customizing

Depending on the particular application, specific EDI Customizing settings are required to ensure that the relevant application documents are updated correctly.

Application-specific EDI Customizing can be found in the hierarchy for the particular applications.

Settings

Structure of the IDoc type

The IDoc type defines the structure of an IDoc. IDocs are subdivided into three different record types in the SAP database.

Status Records IDoc-ID Status information

Data Records IDoc-ID Sequence/Hierarchy Segment Format definition for

• Header data • Item data

Control Record IDoc-ID Sender-ID Receiver-ID IDoc type and message type EDI standard

IDoc Record Types

Control record: The control record contains information such as the IDoc number, IDoc type (for example, DELFOR01), the message type (for example, DELFOR), the partner number, and partner type. For each IDoc, there is exactly one control record. Database table: EDIDC

With inbound IDocs, the following fields must be completed (see structure EDI_DC40):

TABNAM Structure used: EDI_DC40

DIRECT "2" (inbound processing)

IDOCTYP Basic type (for example, ORDERS01)

MESTYP Message type (for example, ORDERS)

SNDPOR Sender port; must be defined as port in receiving R/3 System

SNDPRN Partner number of sender; in R/3 System, must correspond to a partner number from the partner profile

SNDPRT Partner type of sender; in ALE scenario (R/3 to R/3), this is 'LS' (logical system); in non-ALE scenario (R/3 –


non-SAP system) this is usually 'KU' (customer) or 'LI' (vendor)

RCVPOR Recipient port = "SAP<SYSID>", where <SYSID> is the ID of the receiving system; for example, C11, R3P, and so on.

RCVPRN Partner number of receiver; in ALE scenario, logical system of receiving system; in non-ALE scenarios, value is application-specific (usually freely selectable)

RCVPRT Partner type of receiver; in ALE scenario, 'LS'; in non-ALE, scenario application-specific (usually freely selectable)

Some fields must be completed according to particular cases:

CIMTYP Customer extension of basic type. This extension must be included in the corresponding partner profile.

MESFCT Message function for further subdividing messages (cf. INVOIC); must be included in the corresponding partner profile.

MESCOD Message variant for further subdividing messages; must be included in the corresponding partner profile.

SNDPFC Partner function sender; must be included in the corresponding partner profile.

TEST Flag for test mode; must be included in the corresponding partner profile.

As of Release 4.0, with outbound IDocs, the logical system of the current client is entered in the SNDPRN and SNDPRT 'LS' fields; in other words, if IDocs are transmitted between two R/3 Systems, the partner (vendor or customer) does not have to be specified in the partner profile of the receiving system (this applies up to Release 3.x-); the logical system of the source client is specified instead.

Data Record

Control part, contains segment name (e.g., E1EDKA1)

Application Data Field 2 Field 1 ...

Segment Segment

The segment is stored in the unstructured area for the

application data

Data Record and Segment Structure

Data record: The application data or the individual segments are stored in the data records. Several data records can occur in the IDoc. The data records comprise a control part and an application data part. The control part contains the segment name (for example, E1EDKA1), the hierarchy level on which the segment is located, and so on. The data part contains the segment fields (application data) and is of the data type character; in other words, the segment fields are stored in an unstructured form, but the information on the structure of the data record is accessed via the segment name in the control part. Database table: EDID* (table name is release dependent) Each segment is stored as a structure in the Data Dictionary.

Status record: Status records are used as a milestone in the processing of an IDoc. Several status records can exist for each IDoc. The status records are not, however, forwarded to a subsystem. The subsystem itself transmits only the control record and the data record. With outbound IDocs, however, the subsystem can return a status for the transmitted IDoc. For example, the system can report whether the conversion has been carried out successfully, or whether the message has been sent successfully to the partner. Database table: EDIDS


Communication with Older Releases

Field 1 Field 2

Field 1 Field 2

Field 2

2.1/2.2

3.0/3.1

4.0

New Field 3

Field 1 Field 3

D Differences in the IDoc Record Types

The IDoc record types are stored in the Data Dictionary according to their structure. In the course of releases, various fields have been added (for example, in Release 3.0 partner function in the control record) or fields were made longer (for example, as of 4.0 IDoc type). Following an upgrade, you must set the version of the record type in the port definition to ensure that the upgraded system can communicate with subsystems that do not yet understand the new IDoc record types.

Version 2 Structure of Release 3.X (see structure EDI_DC and EDI_DD)

Version 3 Structure of Release 4.X (see structure EDI_DC and EDI_DD)

Port definition

Ports are communications links via which the IDocs are exchange with R/2, R/3, or external systems.

If the IDoc interface is used, a port must always be defined, even if IDocs are only received, since the interface only accepts recognized ports.

The IDoc interface supports various transmission techniques, which can be used according to the particular application.

File and tRFC are the most commonly used port types for EDI and are described in greater detail below.


Port Definition

SAP Application

IDoc Interface & ALE Services

IDoc IDoc

MIME

Internet

CPI-C

IDoc & IDoc & Status Status

R/2

IDoc IDoc

tRFC

Various. Systems

IDoc & IDoc & Status Status

File + RFC

Various Systems

IDoc IDoc

ABAP

IDoc IDoc

XML

Electronic Commerce

2.1 As of 3.0 As of 3.0 As of 3.1 As of 4.5 As of 4.6

Various Systems

1. File interface

IDocs are created as files at the operating system level. The receiving system (EDI subsystems) can read and process the data. The structure of the IDocs must correspond to the structure specified in the R/3 System. When data is transferred via the file interface, attention must be paid to the following:

The SAP R/3 System overwrites files that share the same name; in other words, you must ensure that the outbound file is not overwritten. To prevent data from being lost, you can use function modules that generate a file name dynamically. This prevents data from being overwritten, even if the receiver system cannot collect the file (for example, because of a breakdown). The system proposes the function modules when you create a port of the type File.

Data can also be lost if the systems access a file simultaneously. This can occur as a result of specifying particular times at which the subsystem or R/3 System reads or writes, or as a result of the receiver system being started by means of synchronous RFC (triggering).

To use the file interface File without triggering, you have to make the following settings:

Outbound processing: Create a port of the type File: In the port, you must specify the outbound path and the (variable) file name. The subsystem reads all the files in the defined folder periodically and processes them.

Inbound processing: Schedule Report RSEINB00; to do this, you must specify the file name and the path.

If the file interface File is used with triggering, the process flow is as follows:


1

Write

IDoc File

4

Read

2

RFC

3

Call

rfcexec rfcexec

out.script out.script

IDoc Interface

External System

1

Write

IDoc File Status Report

startrfc startrfc in.script in.script

status.script status.script

3

RFC

2

Call

4

Read

Process Flow with Port Type “File” (with Triggering)

With outbound IDocs, the file is placed in the specified folder (step 1). The program "rfcexec" is then started with a shellscript (step 2); this, in turn, starts the subsystem (step 3), which reads the generated file (step 4).

With inbound IDocs, the file is generated (step 1); R/3 inbound processing is then started via a shellscript, which is called up with the appropriate parameters by the program "startrfc" (step 3). The R/3 System reads the data from the file. After the file has been processed successfully, it is deleted by the R/3 System.

Outbound processing: Creating a port of the type File – Maintain the outbound file (path and name). – Maintain the command file, which is called up by the standard SAP program "rfcexec" and is used to call up the subsystem. – Maintain the logical destination (see transaction SM59), which contains the path to the "rfcexec" program.

Inbound processing: - Create a script, which the standard SAP program "startrfc" calls with the logon parameters, the function module to be executed, as well as the file name. – Maintain a user authorized to execute the function module and create IDocs.

When the file interface is used, it should be ensured that a file is not generated for every inbound IDoc. This can result in problems with performance, particularly where large amounts of data are involved, since a synchronous RFC is transmitted for every file.

1. Transactional Remote Functional Call (tRFC) The sender system calls the appropriate inbound function module in the receiver system and transmits the IDocs as tables. The inbound function modules are: - Up to Release 3.X: INBOUND_IDOC_PROCESS - As of Release 4.X: IDOC_INBOUND_ASYNCHRONOUS If you intend to use the tRFC for outbound processing, you must create a port of the type RFC. You assign the port a logical destination (Transaction SM59), which specifies the receiver system.


In contrast to synchronous RFC, which terminates in the event of an unsuccessful call, the call for a transaction RFC is buffered; in other words, when a breakdown causes a call to fail, it can be repeated a later. The profile data for tRFCs can be found under Tools Administration Monitor Transactional RFC.

Partner Profile

In the partner profiles, various parameters for inbound and outbound processing are stored, which are required for communication via the IDoc interface.

Basic Terms

Process code

A process code is a specific processing type implemented by means of a function module or a workflow. Process codes are used to process IDocs.

With inbound processing, IDocs are read from the database, and the data is transferred to the appropriate application. With outbound processing, the appropriate R/3 document is read and stored in the database as an IDoc.

You can define your own process codes for customer-specific processing. Examples of process codes are listed under Message Types. In the system, you can find the process codes and thus the corresponding processing routines in the IDoc Basis menu under Control Process code Outbound, Inbound or in the menu ALE Development IDocs Inbound processing Define process code.

Notification concept

In the event of an error, workflow tasks are triggered in the IDoc interface (depending on the type of error involved). These tasks must be forwarded to agents or user groups.

Elements of the organizational structure can be used to specify agents or user groups. Elements that can be used for this purpose include: organizational unit, job, position, person/user (users in the R/3 System), and work center. These are maintained via the HR module or in the development transaction workflow.

The agents are maintained in IDoc administration, in the partner profile generally, and in the partner profile for each direction and message type.

With determination of permitted agents, the system initially searches the partner profile in the inbound or outbound parameters.

If the appropriate parameters do not exist, the agent is stored in the general data of the partner profile is used.


Determining Permitted Agents

General IDoc

Administration

Partner Profile General

Partner Profile Message + Direction

Administrator for the IDoc Interface

Permitted Agents

Permitted Agents

De t e rm i n a t i o n

O f

A g e n t s

If there is no partner profile for the parameter, the agent stored in IDoc administration is used.

The agent determined in the IDoc interface is only the "permitted agent" for one workflow task.

The "permitted agents" are stored in the appropriate workflow task. You can either store special user groups or define the task as a general task (in other words, all the users that exist in the system are allocated to the task).

In the role resolution, the intersection "selected agents" is formed from "permitted agents" and "possible agents".

Role Resolution

Role Resolution

Organizational Structure

Workflow Task

Partner Profie

IDoc Interface

Possible Agents

Permitted Agents

Selected Agents Selected Agents


With determination of permitted agents, the system initially searches the partner profile in the inbound or outbound parameters.

This functionality can be used, for example, to determine the user group, according to whether the error is in the IDoc interface (for example, partner profile not maintained) or in the application (for example, material master not maintained). For this purpose, the IDoc administrators are entered in the workflow tasks used for error handling in the IDoc interface, and the users from the relevant user department are entered in the workflow tasks used for error handling in the particular application.

Maintaining Partner Profiles

Partner profiles are subdivided into four areas, which are described in greater detail below.

Partner Profiles

Partner Application

Partner

General

Partner Message

Outbound Parameters

Partner Message

Inbound Parameters

Parameters for Message Control


General Partner Profile

The general partner profile contains the partner (from the master data) or the logical system as a key.

For example, the customer with customer number 7000 is created as a partner profile. The user "AM user" has been entered as "possible agents" in the event of an error.

The general partner profile with one vendor is therefore, as follows: in contrast to customer 7000, with vendor L7000, the outbound parameters are maintained.


Outbound Parameters

The key for the outbound parameters comprises the partner, partner type, partner function, message type, message variant, message function, and the flag for test mode.

The port via which communication with the appropriate subsystem is to be carried out is assigned to the partner profile in the outbound parameters. In this example, communication is carried out via a port of the type tRFC. A packet size must be specified for this port type. This size should be between 20 and 100, otherwise the packets will be too large, and the buffer required will impair system performance, or the number of RFC calls will be very high.

The output mode determines when the data is forwarded to the receiver system - in other words, whether generated IDocs are sent immediately to the receiver system, or whether they are first collected via a background program ("Collect IDocs").


With the port type File (not illustrated here), you can also set whether the subsystem is triggered via the "rfcexec" program.

If extensions of the basic IDoc type have been created and are intended to be used, the corresponding extension must be entered in the outbound parameters.

The Segment Release field controls how the segment types in a particular IDoc type are converted to the assigned segment fields; in other words, the segment definitions that are valid for the specific release are used to specify each segment type in an IDoc.

If the field is empty, the segment definition of the current release is used.


Parameters for Message Control

These settings link Message Control in MM and SD with the partner profiles. The key here also contains application, message type from Message Control, and the change message flag (which can be used in MM with the message type ORDCHG). If data is sent directly via ALE, these settings are not required

The transaction code that carries out outbound processing is stored in the parameters for Message Control.

In Message Control itself, processing via EDI is addressed via the Medium field.

Medium Description

6 Without ALE distribution model

A With ALE distribution model


The processing program RSNASTED and the form routine EDI_PROCESSING, which triggers outbound processing via EDI, are stored in the TNAPR Message Control table.

Inbound Parameters

The same seven key fields used with inbound processing are used as keys. With the structure of the inbound control record, attention must be paid to completing the seven tuples accordingly.

This also means that the partner functions, for example, (SNDPFC field) must be transferred empty if the field is empty in the corresponding partner profile.

Three inbound parameters are maintained for customer 7000; GSVERF (credit memo procedure), DELFOR (delivery schedule for component supplier), DELORD (delivery order - MAIS pick-up sheet).

In this example, the key terms in inbound processing for schedule lines comprise the following fields:

Description Corresponding field in control record of IDoc

Subsystem – R/3 Value

R/3 – R/3

Partner number SNDPRN 1001 P3PCLNT100

Partner type SNDPRT KU LS

Partner function SNDPFC SP

Message type MESTYP DELFOR DELFOR

Message function MESFCT

Message variant MESCOD

Test TEST

If communication is carried out between two R/3 Systems, the logical system of the source client must be entered, since the control record will be completed accordingly by the sender system.

It is also necessary to enter the process code DELI, by means of which the corresponding inbound processing is controlled.

The inbound parameters can also be used to control whether inbound processing is triggered immediately or carried out via a background program.

Particularly with large quantities of data imported via tRFC, you should consider having the PBDAPP01 program carry out processing in the background, since otherwise system performance can suffer considerably.

As in the general data of the partner profile, the "permitted agents" for error handling can be maintained in the outbound and inbound parameters. These entries are made specifically for the inbound or outbound side and for the particular message.


Process Flow

Up to this point, the individual modules required for inbound and outbound processing have been explained. The following describes how the individual elements interact.

Outbound Processing

In outbound processing, an application document is generated – for example, a schedule for a scheduling agreement. Message determination proposes one or more message records with the corresponding medium. Where EDI is involved, the Medium field contains the value "6" or "EDI".

Depending on the settings in Message Control, outbound processing is triggered immediately (dispatch time "4"); the messages are processed subsequently via the background program RSNAST00 (dispatch time "1“); or they are triggered via programs in the application (dispatch time "3").

Outbound Processing

Application Document Data

Message Control Message Record

RSNASTED - Form Routing EDI_PROCESSING

Immediate Processing Dispatch Time 4

RSNAST00

Batch Dispatch Time 1

Read Partner Profile IDoc Processing

Call Up Function Module for Selection

Call Up ALE Service

IDoc Generated in Database

Output Mode 3/4 Collect IDocs

Status 30 RSEOUT00

Output Mode 1/2 Individual IDoc Output via Port

Message control triggers the RSNASTED program, which is stored in the TNAPR Customizing table. The program accesses the partner profile and determines the appropriate process code. Via the process code, the selection function module that reads the data from the document tables is read, and the IDoc is generated. The ALE service is then called up, which enables data to be converted or IDoc segments to be filtered, for example.

The IDoc is saved in the SAP database. Depending on the settings in the partner profile, further processing is either carried out immediately or via a background program. The program selects IDocs with the status "64".

Inbound Processing

The subsystem generates an IDoc and either transfers this directly to the R/3 System via transactional RFC or creates a file.


With tRFCs, the function module IDOC_INBOUND_ASYNCRONOUS (as of Release 4.0), which receives the data and triggers further processing, is called up.

With the file interface, the R/3 System is triggered via the external program 'startrfc'. Using the function module EDI_DATA_INCOMING, the R/3 System reads the file and then initiates further processing.

The inbound parameters of the partner profile are read, and the IDoc is stored in the database. Depending on the settings in the partner profile, inbound processing is either triggered immediately or started via a background program. The program selects IDocs with the status "64".

Inbound Processing

Subsystem

Generate IDoc

Idoc File tRFC

File Interface

Startrfc in. script

EDI_DATA_INCOMING IDOC_INBOUND_ASYNCRONOUS Reads Files

IDoc Generated in Database

Partner Profile Read

RBDAPP01

Status 64

Update Module Triggered

Application Document Generated

Customer/Vendor Relationship

The following example is mapped in the PCS System for the Automotive Industry. For the sake of simplicity, a transactional RFC is used, which transfers the data within the same client; in other words, the customer/vendor relationship is mapped in one client. This situation can arise in practice if two independent companies with reciprocal business relations are mapped in one system by means of two company codes and wish to communicate via EDI.

Live CAR AG in Munich and vendor Zulieferer ABS exchange schedule lines via EDI.


Customer/Vendor Relationship

Live CAR AG - MM Sicht Scheduling Agr .: 5600000003

Order Confirmation: 35000103

Zulieferer ABS - SD View Scheduling Agr .: 35000103

Purch . Ord . No.: 5600000003

Customer Number: 1010

Vendor Number at Customer Location: L1001

Material Number: AS1-3000

Customer Material Number: EXT-AS1-3000

Vendor Number: L1001

Customer Number at Vendor Location: 1010

Material Number: EXT-AS1-3000

Vendor Material Number: 1010

To map the customer/vendor relationship for EDI in the system, the following data is maintained in the system.

Live CAR AG – MM View Live CAR AG has created scheduling agreement 5600000003. In this schedule agreement, the vendor material number AS1-3000 has been maintained at the item level for material EXT-AS1-3000.

In the vendor master record of the vendor Zulieferer ABS (vendor number L1001), the "Customer number at vendor" field has been maintained with the value "1010" in the Correspondence view.

Message control for controlling EDI outbound processing has been set so that message type LPH1 with the medium "EDI" is found and proposed for vendor L1001.

In the next step, the output parameters of the partner profile for vendor L1001 (partner type "LI"), and of the corresponding partner function from Message Control (in this case, "LF"), as well as the message type "LPH1" are maintained. The process code "ME14" calls up the selection function module, which reads the data for the schedule and creates the outbound IDoc.

Zulieferer ABS – SD Side


The IDoc is "sent" via the set RFC port, and an inbound IDoc is generated in the target system. The latter IDoc includes the transmitting logical system as sender information relevant for determining the partner profile. The inbound partner profile for the logical system, therefore, must be created.


With an EDI subsystem, the vendor/customer number is usually used as sender information.

At Zulieferer ABS, inbound parameters of the partner profile are, therefore, set as follows.


At Zulieferer ABS, SD scheduling agreement 35000103 for customer 1010 (Live CAR AG) has been created, and the MM scheduling agreement number 560000003 (Live CAR AG) has been entered as the purchase order number.

In the customer master record, the vendor number at the customer location (L1001) has been maintained in the Correspondence or Order view.

In the customer-material information, the customer material number EXT-AS1-3000 has also been allocated to material number (AS1-3000).

The application update is carried out via the process code DELI. Scheduling agreement 35000103 is found via standard matchcode selection, and the delivery schedules are posted to the system.

Irrespective of the settings in the IDoc interface, appropriate EDI settings for each application must be made in Customizing; otherwise the application cannot be updated correctly.


Error Handling

Some errors that have arisen when the application document was posted can be made detectable and repairable in the applications by means of specific tasks and the corresponding process code (see Partner Profiles)

Exception handling in the IDoc interface is implemented by means of a process code and a workflow task (single-step task).

The following process codes are available and can be found in IDoc Basis Control System process code:

Code Type Description

EDII TS00008068 Inbound, error message with IDoc; for example, wrong control record

EDIL TS70008373 Error message without IDoc (status report)

EDIM TS30000020 Error message without IDoc; for example, file could not be opened

EDIN TS70008037 Display MC document (outbound w/o IDoc)

EDIY TS00008074 Inbound, syntax error in IDoc

EDIO TS00007989 Outbound, error handling with IDoc

EDIP TS60001307 Outbound, error message with IDoc packet (for background processing)

EDIX TS00008070 Outbound, syntax error in IDoc

To receive exception messages or status confirmations from the subsystem, the subsystem use the IDoc type SYSTAT01 (message type STATUS) to confirm statuses such as "Dispatch OK" or "Error in Conversion" for each sent IDoc. The partner profile must be maintained accordingly.

Controlling is carried out via the process code EDIS or EDIR, which trigger error handling when a status classified as an error is confirmed. The status process codes can be found under IDoc Basis Control Process code status.


Customer Extensions

In both inbound and outbound IDoc processing, the demands on the IDoc interface as regards flexibility and customer-specific extensions are very high. Various options for extending the IDoc interface are, therefore, available.

Customer-Specific Process Codes

Function modules or workflows are linked to the process codes entered in the partner profile. In the EDI environment, these are usually function modules.

In outbound processing, these function modules select the data and the structure of the IDocs; in inbound processing, they read the IDocs and update the data in the application.

The function modules can be found above the process codes specified under IDoc Basis Control Inbound or Outbound.

As a rule, the function modules begin with IDOC_<Direction>_<Message type>.

Examples: IDOC_INPUT_ORDERS, IDOC_OUTPUT_ORDERS, IDOC_INPUT_DELVRY, and so on.

If specific demands mean that it is no longer possible to implement the customer-specific expansions by means of customer functions, you can create your own process code and function module to carry out processing. To do this, however, you must observe specific conventions. These are described clearly in the ALE programming guidelines.

Customer Functions

A large number of user exits (older function modules) or customer functions exist in the function modules these can be used, for example, to read further data, customer-defined checks, data extensions, and so on.

Customer functions are managed via extensions in the transaction CMOD.

Finding the right extension is often difficult: You have the following options:

Search in the list of expansions; possible restriction via development class, and so on.

Direct search for the term "customer function" in the function module coding; to find the correct expansion, you can now search for the table MODSAP via the name of the function module.

With customer functions, attention must be paid to the fact that these are often executed several times in a processing function module; in other words, you have to check which segment or qualifier is currently being processed.

Attention must also be paid to the fact that function modules are used by several partners. You must ensure that the expansions necessary for one partner do not influence processing for another partner.

You must also ensure that the project that contains the expansion is active; otherwise the customer-specific processing routine will not be executed.


IDoc Trouble Shooting using “Status Monitor for ALE Messages” (Transaction code BD87)

Purpose Normally, the inbound IDoc will end with status “53” and the outbound EDI will end with status “03”. But in some case, the IDoc can not be processed successfully due to application or technological errors.

With the status monitor provided by SAP, we can monitor the processing status of IDoc in inbound and outbound processing and you process IDoc manually.

Prerequisites

The error related to application data have been solved.

Locate the IDoc with error

You can get it with the following procedures:

Rune the following activity:

SAP Menu SAP Easy Access Tools Business Communication IDoc Basis IDoc IDoc Lists

Transaction code WE05

1. Confirm the following values in the IDoc lists screen:

Field Description User action and values

Comment

Standard

Date created

Time created

Date last changed

Time last changed

Logical message type SBWAP etc. With your own message type

Output code

Message function

Test option

Partner type

Partner function

Partner number

Partner port

2. Choose Execute (F8).

3. In the IDoc lists screen in the left-hand pane, select the entry with errors, for example, entry marked “51 Application document not posted”. In the right-hand pane, double-click the entry. A list of all the IDoc numbers with status 51 is now displayed. Make a note of the number you want to update.


Procedure

1. Run the following activities

R/3 Menu SAP Easy Access Tools ALE ALE Administration Monitoring Status Monitor for ALE Messages

Transaction code BD87

2. Confirm the following values in the Choose IDocs screen:

Field Description User action and values Comment

Standard

IDoc NUMBER Number of IDoc with error

Date created

Time created

Date last changed

Time last changed

IDoc status

Partner system

Message type

3. In the status monitor for ALE messages screen, expand to the lowest level. Select the entry with error, for example “No scheduling agreement could be found”.

4. Choose “Edit – Restrict and Process (Shift + F8)”.

5. In the “Manual Processing of IDocs: Post IDocs Not Yet Posted” screen, select the field Background Processing.

6. Choose Execute (F8).

7. In the “Display Status Record”, choose Edit – Process – Foreground processing (F8)

8. Confirm the messages that appear.

9. In the Hit List screen, confirm the messages that appear.

10. The system outputs a message telling you that the IDoc has been successfully updated by the application.

11. Click Back to return to the SAP Easy Access screen.

Result

The IDoc is processed successfully.

EDI Application Data for Automotive Suppliers - h3 IT Ch3-itc.eu/BP-EDI_Automotive_EN_DE.pdf · SAP...

Documents

Transcript of EDI Application Data for Automotive Suppliers - h3 IT Ch3-itc.eu/BP-EDI_Automotive_EN_DE.pdf · SAP...