SAP ECC 6.00
March 2007
English
EDI Application Data for
Automotive Suppliers
Overview Document
SAP AG
Dietmar-Hopp-Allee 16
69190 Walldorf
Germany
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.
SAP Best Practices
EDI Application Data for Automotive Supplier
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
SAP R/3
System
IDoc
SAP R/3
System
IDoc
IDoc
Message
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
SAP Best Practices
EDI Application Data for Automotive Supplier
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".
Asynchronous Processing
Message Based
System 1
SAP
Application
Document
 R/3 System
System 2
IDoc
Document
 EDI Subsystem
 R/3 System
 R/2 System
Other non-SAP System
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.
SAP Best Practices
EDI Application Data for Automotive Supplier
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:
SAP Best Practices
EDI Application Data for Automotive Supplier
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.
SAP Best Practices
EDI Application Data for Automotive Supplier
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.
Dir
ecti
on
Mess.
type
Description
IDoc type
EDIFAC
T
ANS
I
X12
VDA
CARNOT
DELVRY01
DELFOR01
DELFOR
830
4905
O
DELFOR
Delivery: Shipping
notification
Delivery schedule (FDS)
O
DELINS
Delivery schedule (FDS)
DELFOR01
DELFOR
830
4905
O
DELINS
Delivery schedule (JIT)
DELFOR01
DELJIT
862
4915
O
DELINS
Delivery schedule (JIT)
DELFOR01
DELJIT
862
4915
O
DELJIT
Delivery schedule (JIT)
DELFOR01
DELJIT
862
4915
O
DESADT
Shipping notification
DESADV01
O
DESADV
DESADV01
O
DESADV
O
DESADV
O
DESADV
O
GSVERF
Delivery: Shipping
notification
Delivery: Shipping
notification
Delivery: Shipping
notification
Delivery: Shipping
notification
Cred. memo procedure
O
INVOIC
Invoice/Billing document
INVOIC01
O
INVOIC
Invoice/Billing document
O
ORDCHG
Purchase order/order
change
O
ORDERS
Purchase order/order
INVOIC01
INVOIC02
ORDERS01
ORDERS02
ORDERS03
ORDERS04
ORDERS05
ORDERS01
DELVRY01
DESVRY02
DESVRY03
GSVERF01
ODE
TTE
From
Release
Process
code
40A
DELV
DELI
NS
DELI
NS
DELI
NS
DELI
NS
DELI
NS
AVIE
XP
AVIE
XP
AVIE
XP
AVIE
XP
AVIE
XP
INV
OIC
INV
OIC
45A
ME14
30A
ME14
40A
ME13
40A
ME13
45A
ME13
30A
SD06
30A
SD05
40A
DELV
45A
DELV
46A
DELV
30A
GSVE
30A
SD09
INV
OIC
30A
40A
30A
30E
40A
45A
46A
30A
SD08
4922
4913
DESAD
V
DESAD
V
DESAD
V
DESAD
V
DEBAD
V
INVOIC
856
4913
856
4913
856
4913
856
4913
812
4908
810
880
4906
ORDCH
G
860
876
ORDER
850
4925
ME11
ME10
SAP Best Practices
Dir
ecti
on
Mess.
type
EDI Application Data for Automotive Supplier
Description
O
ORDRSP
Purchase order/order
confirmation
O
O
PAB_OR
DERS
SBINV
Quantity release from
KANBAN
Credit memo procedure
with invoice creation
O
REMADV
Payment advice note
IDoc type
EDIFAC
T
ORDERS02
ORDERS03
ORDERS04
ORDERS05
ORDERS01
ORDERS02
ORDERS03
ORDERS04
ORDERS05
ORDERS03
S
ANS
I
X12
875
ORDRS
P
855
865
GSVERF01
INVOIC
PEXR2001
PEXR2002
REMAD
V
DELJIT
VDA
ODE
TTE
30D
40A
45A
46A
30A
30E
40A
45A
46A
45A
4926
4915
810
820
820
4907
From
Release
Process
code
SD10
PJNO
INV
OIC
45A
SBII
REM
ADV
30A
45A
ALE
ODE
TTE
From
Release
Process
code
Inbound Messages
Dir
ecti
on
Mess.
type
Description
IDoc type
EDIFAC
T
ANS
I
X12
I
DESADV
DESADV01
4913
30A
DESA
DESADV
856
4913
40A
DELS
I
DESADV
856
4913
45A
DELS
I
DESADV
856
4913
46A
DELS
I
I
I
EDLNOT
DELJIT
DELORD
DESADV01
DELFOR01
ORDERS03
DESAD
V
DESAD
V
DESAD
V
DESAD
V
INVRPT
DELJIT
DELJIT
856
I
846
862
4913
4915
30A
45A
40A
EDLN
DELI
DELO
I
DELORD
ORDERS04
DELJIT
45A
DELO
I
DELORD
ORDERS05
DELJIT
46A
DELO
I
DELINS
Delivery: Shipping
notification
Delivery: Shipping
notification
Delivery: Shipping
notification
Delivery: Shipping
notification
EDL delivery notes
Delivery schedule (JIT)
Delivery order (MAIS
procedure)
Delivery order (MAIS
procedure)
Delivery order (MAIS
procedure)
Delivery schedule (FDS)
DELFOR01
I
DELFOR
Delivery schedule (FDS)
DELFOR01
DELFO
R
DELFO
R
I
GSVERF
Credit memo procedure
for logistics invoice
verification
GSVERF01
I
INVOIC
INVOIC01
I
INVOIC
I
INVOIC
I
I
KANBAN
ORDERS
Invoice receipt
(MM – invoice
verification)
Message variant MM
Invoice receipt
(MM – logistics invoice
verification)
Message variant MM
Invoice receipt (FI)
Message variant FI
KANBAN call
Purchase order/order
I
ORDERS
Purchase order/order
DELVRY01
DESVRY02
DESVRY03
VDA
830
4905
30A
DELI
830
4905
45A
DELI
812
4908
46A
INVOIC
810
880
4906
30A
MRRL
MRKO
MRNB
INVM
INVOIC01
INVOIC
810
880
4906
40A
INVL
INVOIC01
INVOIC
810
880
4906
30A
INVF
KANBAN01
ORDERS01
ORDERS02
ORDERS03
ORDERS04
ORDERS05
ORDERS01
DELJIT
ORDER
S
850
875
4915
4925
KANB
ORDE
ORDER
850
45A
30A
30D
40A
45A
46A
30A
4925
ORDE_
SAP Best Practices
Dir
ecti
on
EDI Application Data for Automotive Supplier
Mess.
type
Description
I
ORDCHG
Purchase order/order
change
I
ORDRSP
Purchase order/order
confirmation
I
REMADV
Payment advice note
IDoc type
ORDERS02
ORDERS03
ORDERS04
ORDERS05
ORDERS01
ORDERS02
ORDERS03
ORDERS04
ORDERS05
ORDERS01
ORDERS02
ORDERS03
ORDERS04
ORDERS05
PEXR2001
PEXR2002
EDIFAC
T
S
ANS
I
X12
875
VDA
ORDCH
G
860
876
ORDRS
P
855
865
4926
REMAD
V
820
4907
ODE
TTE
From
Release
Process
code
30D
40A
45A
46A
30A
30E
40A
45A
46A
30A
30E
40A
45A
46A
30A
45A
BY_WF
ORDC
ORDR
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
DESADV
EDLNOT
DELJIT
DELORD
DELINS
DELFOR
GSVERF
INVOIC
INVOIC
KANBAN
ORDERS
ORDCHG
ORDRSP
REMADV
Message Variant
FI
MM
WF Task Description
DESADV_error
EDLNOT_error
DELINS_error
DELORD_error
DELINS_error
DELINS_error
GSVERF_error
INVOIC_FI_er
INVOIC_MM_er
KANBAN_error
ORDERS_error
ORDCHG_error
ORDRSP_error
REMADV_error
WF Task
TS00008178
TS00008065
TS00008000
TS20000117
TS00008000
TS00008000
TS 00008175
TS 00008056
TS 00008057
TS 24500055
TS 00008046
TS00008115
TS 00008075
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.)
SAP Best Practices
EDI Application Data for Automotive Supplier
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.
SAP Best Practices
EDI Application Data for Automotive Supplier
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.
SAP Best Practices



EDI Application Data for Automotive Supplier
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.
IDoc Record Types
Control Record
IDoc-ID
Sender-ID
Receiver-ID
IDoc type and message type
EDI standard
Data Records
IDoc-ID
Sequence/Hierarchy
Segment
Format definition for
• Header data
• Item data
Status Records


IDoc-ID
Status information
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
DIRECT
IDOCTYP
MESTYP
SNDPOR
SNDPRN
SNDPRT
Structure used: EDI_DC40
"2" (inbound processing)
Basic type (for example, ORDERS01)
Message type (for example, ORDERS)
Sender port; must be defined as port in receiving R/3 System
Partner number of sender; in R/3 System, must correspond to a partner number from the partner profile
Partner type of sender; in ALE scenario (R/3 to R/3), this is 'LS' (logical system); in non-ALE scenario (R/3 –
SAP Best Practices
RCVPOR
RCVPRN
RCVPRT
EDI Application Data for Automotive Supplier
non-SAP system) this is usually 'KU' (customer) or 'LI' (vendor)
Recipient port = "SAP<SYSID>", where <SYSID> is the ID of the receiving system; for example, C11, R3P,
and so on.
Partner number of receiver; in ALE scenario, logical system of receiving system; in non-ALE scenarios, value
is application-specific (usually freely selectable)
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
MESFCT
MESCOD
SNDPFC
TEST
Customer extension of basic type. This extension must be included in the corresponding partner profile.
Message function for further subdividing messages (cf. INVOIC); must be included in the corresponding
partner profile.
Message variant for further subdividing messages; must be included in the corresponding partner profile.
Partner function sender; must be included in the corresponding partner profile.
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 and Segment Structure
Data Record
Control part, contains
segment name (e.g., E1EDKA1)
Application Data
Field 1 Field 2
...
The segment is stored in the
unstructured area for the
application data
Segment


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
SAP Best Practices
EDI Application Data for Automotive Supplier
Communication with Older Releases
Differences in the IDoc Record Types
Field 1
Field 3
Field 1
Field 2
Field 1
Field 2
Field 2
New Field 3
4.0
3.0/3.1
2.1/2.2
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.
SAP Best Practices
EDI Application Data for Automotive Supplier
Port Definition
SAPApplicatio
n
IDoc Interface & ALE
Services
IDoc &
Status
File
+ RFC
Various
Systems
2.1
IDoc
tRFC
Various.
Systems
As of 3.0
IDoc &
Status
CPI-C
R/2
As of 3.0
IDoc
MIME
Internet
As of 3.1
IDoc
ABAP
Various
Systems
As of 4.5
IDoc
XML
Electronic
Commerce
As of 4.6
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:
SAP Best Practices
EDI Application Data for Automotive Supplier
Process Flow with Port Type “File” (with Triggering)
IDoc Interface
Write
1
RFC
2
rfcexec
out.script
4
RFC
Read
IDoc File
Call
Read
3
4
3
IDoc File
Status Report
1
startrfc
in.script
status.script
2
Write
Call
External
System
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.
SAP Best Practices
EDI Application Data for Automotive Supplier
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.
SAP Best Practices
EDI Application Data for Automotive Supplier
Determining Permitted Agents
General IDoc
Administration
Partner Profile
General
D
e
t
e
r
m
i
n
a
t
i
o
n
Administrator for the
IDoc Interface
Permitted Agents
O
f
Partner Profile
Message + Direction
A
g
e
n
t
s
Permitted Agents
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
Organizational Structure
Possible Agents
Workflow Task
Role Resolution
Selected Agents
Partner Profie
IDoc Interface
Permitted Agents
SAP Best Practices
EDI Application Data for Automotive Supplier
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
General
Partner
Message
Outbound Parameters
Partner
Application
Parameters for
Message Control
Partner
Message
Inbound Parameters
SAP Best Practices
EDI Application Data for Automotive Supplier
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.
SAP Best Practices
EDI Application Data for Automotive Supplier
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").
SAP Best Practices
EDI Application Data for Automotive Supplier
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.
SAP Best Practices
EDI Application Data for Automotive Supplier
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
6
A
Description
Without ALE distribution model
With ALE distribution model
SAP Best Practices
EDI Application Data for Automotive Supplier
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
Partner number
Partner type
Partner function
Message type
Message function
Message variant
Test
Corresponding field in
control record of IDoc
SNDPRN
SNDPRT
SNDPFC
MESTYP
MESFCT
MESCOD
TEST
Subsystem – R/3
Value
1001
KU
SP
DELFOR
R/3 – R/3
P3PCLNT100
LS
DELFOR
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.
SAP Best Practices
EDI Application Data for Automotive Supplier
SAP Best Practices
EDI Application Data for Automotive Supplier
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
RSNAST00
Batch
Dispatch Time 1
Message Record
Immediate Processing
Dispatch Time 4
RSNASTED - Form Routing EDI_PROCESSING
IDoc Processing
Read Partner Profile
Call Up Function Module for Selection
Call Up ALE Service
Output Mode 3/4
Collect IDocs
RSEOUT00
IDoc Generated in Database
Status 30
Output via Port
Output Mode 1/2
Individual IDoc
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.
SAP Best Practices
EDI Application Data for Automotive Supplier
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
Subsyste
m
File Interface
Generate IDoc
Startrfc
in.script
tRFC
IDOC_INBOUND_ASYNCRONOUS
EDI_DATA_INCOMING
Idoc File
Reads Files
Partner Profile Read
IDoc Generated in Database
Status 64
RBDAPP01
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.
SAP Best Practices
EDI Application Data for Automotive Supplier
Customer/Vendor Relationship
Zulieferer ABS - SD
Scheduling
Agr.: 35000103
View
Scheduling
Sicht Agr.: 5600000003
Live CAR AG - MM
Purch. Ord . No.: 5600000003
Order Confirmation: 35000103
Customer Number: 1010
Vendor Number: L1001
Vendor Number
at Customer Location: L1001
Customer Number
at Vendor Location: 1010
Material Number: AS1-3000
Material Number: EXT-AS1-3000
Customer
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
SAP Best Practices
EDI Application Data for Automotive Supplier
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.
SAP Best Practices
EDI Application Data for Automotive Supplier
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.
SAP Best Practices
EDI Application Data for Automotive Supplier
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.
SAP Best Practices
EDI Application Data for Automotive Supplier
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
EDII
EDIL
EDIM
EDIN
EDIY
EDIO
EDIP
EDIX
Type
TS00008068
TS70008373
TS30000020
TS70008037
TS00008074
TS00007989
TS60001307
TS00008070
Description
Inbound, error message with IDoc; for example, wrong control record
Error message without IDoc (status report)
Error message without IDoc; for example, file could not be opened
Display MC document (outbound w/o IDoc)
Inbound, syntax error in IDoc
Outbound, error handling with IDoc
Outbound, error message with IDoc packet (for background processing)
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.
SAP Best Practices
EDI Application Data for Automotive Supplier
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.
SAP Best Practices
EDI Application Data for Automotive Supplier
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, doubleclick 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.
SAP Best Practices
EDI Application Data for Automotive Supplier
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
Date created
Time created
Date last changed
Time last changed
IDoc status
Partner system
Message type
Number of IDoc with error
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.