CA210 EDI Interface PDF

CA210 EDI Interface
CA210
EDI Interface
 SAP AG 1999
System R/3
Release 4.6B
September 2000
Mat. No.: 5004 1963
Copyright
Copyright 2000 SAP AG. All rights reserved.

Neither this training manual nor any part thereof may
be copied or reproduced in any form or by any means,
or translated into another language, without the prior
consent of SAP AG. The information contained in this
document is subject to change and supplement without prior
notice.
All rights reserved.
 SAP AG 1999
Trademarks:
Microsoft ®, Windows ®, NT ®, PowerPoint ®, WinWord ®, Excel ®, Project ®, SQL-Server ®,
Multimedia Viewer ®, Video for Windows ®, Internet Explorer ®, NetShow ®, and HTML Help ®
are registered trademarks of Microsoft Corporation.
Lotus ScreenCam ® is a registered trademark of Lotus Development Corporation.
Vivo ® and VivoActive ® are registered trademarks of RealNetworks, Inc.
ARIS Toolset ® is a registered Trademark of IDS Prof. Scheer GmbH, Saarbrücken
Adobe ® and Acrobat ® are registered trademarks of Adobe Systems Inc.
TouchSend Index ® is a registered trademark of TouchSend Corporation.
Visio ® is a registered trademark of Visio Corporation.
IBM ®, OS/2 ®, DB2/6000 ® and AIX ® are a registered trademark of IBM Corporation.
Indeo ® is a registered trademark of Intel Corporation.
Netscape Navigator ®, and Netscape Communicator ® are registered trademarks of Netscape
Communications, Inc.
OSF/Motif ® is a registered trademark of Open Software Foundation.
ORACLE ® is a registered trademark of ORACLE Corporation, California, USA.
INFORMIX ®-OnLine for SAP is a registered trademark of Informix Software Incorporated.
UNIX ® and X/Open ® are registered trademarks of SCO Santa Cruz Operation.
ADABAS ® is a registered trademark of Software AG
The following are trademarks or registered trademarks of SAP AG; ABAP™, InterSAP, RIVA, R/2,
R/3, R/3 Retail, SAP (Word), SAPaccess, SAPfile, SAPfind, SAPmail, SAPoffice, SAPscript,
SAPtime, SAPtronic, SAP-EDI, SAP EarlyWatch, SAP ArchiveLink, SAP Business Workflow, and
ALE/WEB. The SAP logo and all other SAP products, services, logos, or brand names included
herein are also trademarks or registered trademarks of SAP AG.
Other products, services, logos, or brand names included herein are trademarks or registered
trademarks of their respective owners.
The R/3 Integration Model
SD FI
Sales & Financial
Distribution Accounting
CO
MM Controlling
Materials
PP Mgmt AM
R/3
Production Asset Mgmt
Planning
QM Client / Server PS
Project
Quality
Mgmt
PM ABAP WF
System
Plant Main-
Workflow
tenance
HR IS
Human Industry
Resources Solutions
 SAP AG 1999
SAP's R/3 System has set new norms for standard software that can be universally implemented.
R/3 uses advanced development techniques to achieve comprehensive integration of business
administration and data processing.
R/3 combines state-of-the-art technology with comprehensive business administration functionality
to provide a fully integrated business solution for your company.
Business Integration Technologies I
Level 2 Level 3
BC600 2 days BC601 5 days BC610 3 days
SAP Business Build and Use Workflow
SAP Business SAP Business
Workflow - Introduction Workflow - Programming
Workflow
BC615 3 days
SAP ArchiveLink BC670 2 days
BC095 3 days Programming Display
Business Integration Functionality Archiving
Technology
BC660 3 days BC680 2 days
BC400 5 days Data Archiving Data Retention Tool
(DART)
ABAP Workbench
Concepts and Tools
BC410 5 days BC440 5 days

ABAP Workbench Developing R/3 Web Connection
Programming User Internet Applications
Dialogs (Level 3)
 SAP AG 1999
Business Integration Technologies II
Level 2 Level 3
BC619 3 days
Application Link
Enabling (ALE)
Technology
BC620 2 days BC621 1 day
SAP IDoc Interface SAP IDoc Interface - Data Exchange
Technology Development
BC095 3 days CA210 4 days
Business Integration EDI Interface

Technology
CA150 2 days
Building Enterprise BC420 5 days
Solutions with SAP Data Transfer
Components BC415 2 days
Communication
CA925 5 days Interfaces in ABAP Interface
Programming with Programming
BAPIs in Visual Basic CA926 5 days
Programming with
CA927 5 days BAPIs in JAVA
R/3 Interface and BAPI
Programming in C++
 SAP AG 1999
Course Prerequisites
Level 2 course in a revelent application

EDI knowledge is strongly recommended
 SAP AG 1999
Target Group
Audience:
Project team EDI analysts responsible for implementing EDI
Duration: 4 days
 SAP AG 1999
Notes to the user

The training materials are not teach-yourself programs. They complement the course instructor's
explanations. Your material includes space for noting additional information.
Course Overview
Contents:
Course Goals
Course Objectives
Course Content
Course Overview Diagram
Main Business Scenario
Course Introduction
 SAP AG 1999
© SAP AG CA210 1-1

Course Goals
This course will prepare you to:

Explain the possibilities offered by the IDoc
Interface for electronic data interchange
Configure the system to handle the IDoc
interface
 SAP AG 1999
© SAP AG CA210 1-2

Course Objectives
At the conclusion of this course, you will be able to:

Configure the IDoc interface
Trace the processing of IDocs within the system
Find out the correct IDoc types for your business
processes.
 SAP AG 1999
© SAP AG CA210 1-3

Contents
Preface
Unit 1 Course Overview Unit 10 Inbound Invoice Processing

Unit 2 IDocs in the Business Process Unit 11 Payment/Remittance Process
Unit 3 General Settings Unit 12 Price Catalog, Inventory Advice
Unit 4 Port Definitions Unit 13 Test of Processing
Unit 5 Partner Profiles Unit 14 Documentation Tools
Unit 6 MM EDI Application Unit 15 Working with an EDI Subsystem
Requirements Unit 16 IDoc Monitoring
Unit 7 Message Control and IDocs Unit 17 Archiving IDocs
Unit 8 Workflow and IDocs Unit 18 Miscellaneous Topics
Unit 9 SD EDI Application Unit 19 Conclusion
Requirements
Exercises Appendices
Solutions
 SAP AG 1999
© SAP AG CA210 1-4

Course Overview Diagram (1)
Course Overview 1 Workflow and IDocs 8

IDocs in the SD EDI Application
Business Process 2 Requirements 9
Inbound Invoice
General Settings 3 Processing
10
Payment/Remittance
Port Definitions 4 Process 11
Price Catalog, Inventory
Partner Profiles 5 Advice 12
MM EDI Application
Requirements
6 Test of Processing 13
Message Control & IDocs 7 Documentation Tools 14

 SAP AG 1999
© SAP AG CA210 1-5

Course Overview Diagram (2)
Working with an
EDI Subsystem 15
IDoc Monitoring 16
Archiving IDocs 17
Miscellaneous Topics 18
Conclusion 19
 SAP AG 1999
© SAP AG CA210 1-6

Main Business Scenario
You are a member of the integration team (either

SmartMart or NOE Food Company)
You are responsible for setting up the IDoc
interface.
You must know the basics of the IDoc format and
of IDoc processing; both outbound and inbound
processing.
The outbound customer is SmartMart.
The inbound customer is NOE Food Company.
You will be testing your configuration through the
creation of business documents which you will
exchange between SmartMart and NOE Food
Company.
 SAP AG 1999
© SAP AG CA210 1-7

Introduction
Contents:
EDI location in SAP
IDoc Overview
Overview of EDI Interface
 SAP AG 1999
© SAP AG CA210 1-8

Introduction: Topic Objectives
At the conclusion of this topic you will be able to:

Indicate where the EDI interface is located in
the SAP system
Describe the overview of the EDI interface
Define the general concept of the IDoc
 SAP AG 1999
© SAP AG CA210 1-9

EDI Standards in the World
EANCOM
GENCOD
EDIFICE TRADACOMS
EIAJ UCS II, WINS
SEDAS
EDIFER
2
X1 T
EDIFICE
ELFE
C
IFA
ED
CEFIC
HL7
PHOENIX
ARUA
GALIA EANCOM
ODETTE GENCOD
VDA TRADACOMS
UCS II, WINS
SEDAS
BAI, BAI2
ATA SPEC2000 MultiCash
AECMA SPEC2000M S.W.I.F.T.
HBCI
 SAP AG 1999
IBUs and SBUs clockwise:

SAP Consumer Products
SAP Insurance
SAP Public Sector
SAP Telecommunications
SAP Chemicals
SAP Pharmaceuticals
SAP Retail
SAP Banking
SAP Mill Products
SAP Aerospace & Defense
SAP Media
SAP Automotive
SAP Health Care
SAP Service Provider
SAP Utilities
SAP Oil & Gas
SAP Engineering & Construction
SAP High Tech & Electronics
© SAP AG CA210 1-10

Introduction to SAP EDI
 SAP AG 1999
SAP EDI is a cross-application function that is delivered with the SAP Basis component.
SAP EDI allows for Electronic Data Interchange between your company and your trading partners.
In the following chapters you will learn how to configure SAP EDI and enable your partners with the
R/3 Applications.
© SAP AG CA210 1-11

IDoc Concept
System 1 System 2
Document IDoc Document
message oriented
asynchronous
 SAP AG 1999
IDoc is an SAP Standard format for data exchange between systems. IDoc means Intermediate
Document, and is intermediate in two senses:
Message oriented - Data reside in the applications as well, only in other formats (the application
documents). The IDoc stands between these application documents, as a language, spoken by the
communicating applications. It does not matter whether the application is programmed by SAP or
by another foreign system.
Asynchronous - Data can already reside in IDocs before an application document is created. This
is important, for instance, when wrong data were transmitted: In this case, the application
document shall only be created when the data are corrected.
The IDoc interface is available in R/3 starting with Release 2.1A, in R/2 starting with Release 5.0F.
© SAP AG CA210 1-12

IDoc Applications
WWW
message Internet
Intranet
R/2 System
ICR/OCR
Document
ALE IDoc
EDI
EDI Message
Message
R/3 System Forms

Feed
Flows
Electronic
Workflow Form
 SAP AG 1999
Examples of systems/applications which use IDocs:

ALE Application Link Enabling
EDI Electronic Data Interchange
ICR Intelligent Character Recognition
OCR Online Character Recognition
WWW World Wide Web
© SAP AG CA210 1-13

The IDoc Interface
EDI Standard Independent

ANSI X.12
EDIFACT
Proprietary
EDI Subsystem Independent

“Certified” EDI Subsystems
Not limited to use of “Certified” subsystems
 SAP AG 1999
The intermediate document, or IDoc, interface was designed by SAP application developers.
It is independent of any EDI standards, and is also independent of any EDI subsystem (translator).
© SAP AG CA210 1-14

Electronic Commerce
Document
IDoc
SAP System R/3 SAP System R/3
IDoc IDoc
Transaction
EDI Subsystem Message EDI Subsystem
 SAP AG 1999
Business partners exchange business documents on a logical level, this is physically achievable by
means of letters, fax or phone. All those methods have one thing in common: the technical structure
of the documents get lost, and the recipient has to re-enter the information in their system.
With EDI the technical structure of the document is retained. This enables the recipient to
automatically process the document using their business software. Since both partners are
independent, they will make independent decisions on their IT infrastructure and their business
software. Hence EDI standards are required, to map from the application data structure of the sender
into the EDI standard, and from the EDI standard into the application data structure of the recipient.
This means the partners stay independent.
The IDoc is the data structure of the SAP application at the interface. This gives a unified interface to
any EDI subsystem regardless of the SAP module, which creates or receives the messages.
By linking SAP systems directly, IDoc can be transmitted without a mapping into EDI standards.
This is the ALE (Application Link Enabling) approach. Partners are, in a technical sense, linked
together, which means they loose some of the independence of their IT infrastructure.
The IDoc format can be considered an EDI standard when used for EDI. However, translating IDocs
into other standards has the advantage of communication with more partners.
The advantage of IDocs is that the SAP applications only have to know the format IDoc - not several
EDI standards and thus, are more easily maintained. The disadvantage is that an EDI Subsystem
must be bought when other EDI standards are to be used.
© SAP AG CA210 1-15

IDoc Data Flow
Outbound Data Inbound
Application MM Application
SD
...
Message Control Workflow
IDoc Interface & IDoc IDoc Interface &

ALE Services ALE Services
System 2 File System 2

e.g. EDI subsystem tRFC e.g. EDI subsystem
XML
...
 SAP AG 1999
Please read the left (outbound) from top and the right (inbound) from bottom.
Message Control is in use with transactions of the supply chain, applications MM and SD, in
outbound processing.
Workflow is conditional with all inbound processing by all SAP applications.
Nevertheless Workflow is in use with all SAP applications to report on exceptions in the
implemented processes. For details please refer to the notification and monitoring section.
© SAP AG CA210 1-16

IDoc Processing Flow: Outbound
R/3
R/3 System
System
Create application document
Create IDoc
Check Partner, find Port
Receive Data
do further processing
External
External System
System
 SAP AG 1999
In the following, data flow is always viewed from the R/3 system. Therefore, if data is sent from an
R/3 system to an arbitrary external system, this is called outbound processing, or simply outbound.
Outbound processing comprises
Creating the application document
Creating the respective outbound IDoc
Finding the partner and port
Passing the IDoc to the external System via the Port.
© SAP AG CA210 1-17

IDoc Topics: Outbound
R/3
R/3 System
System
Partner
Message Create application document
Profile
Control General
Settings
Create IDoc
Archive Port
IDocs ? Description,
Check Partner, find Port Partner Profile
EDI Documentation
Subsystem ? Tools
Receive Data
do further processing
External
External System
System
 SAP AG 1999
Smartmart must setup its interface for outbound processing.

Via the Port description, SmartMart defines the systems to receive IDocs, and the technical
communication parameters.
Smartmart defines NOE Food Company as a partner for the message type ORDERS in the Partner
Profiles. Here, Smartmart enters the port it had defined earlier.
Outbound IDocs created in the R/3 system shall be archived and deleted in the system.
The Documentation tools tell the EDI Subsystem which IDoc types it must understand.
© SAP AG CA210 1-18

IDoc Processing Flow: Inbound
External System
Pass Data to R/3 system
Check Partner, create IDoc
Create Document Ok?
no
Ok? no
Error handling
R/3-System
R/3-System
 SAP AG 1999
Data reception from an external system plus data processing within the R/3 system is called inbound
processing or, simply, inbound.
Inbound processing comprises:
data takeover from an external system via an inbound port
creating the inbound Idoc(s)
finding the correct processing type via the partner profiles
creating the application document(s)
If an error occurs, error handling (more general: exception handling) starts. This is another kind of
processing and is not only connected to inbound processing.
© SAP AG CA210 1-19

IDoc Topics: Inbound
External
External System
System
EDI Documentation
Subsystem? Pass Data to R/3 system Tools
Port
Archive
Description,
IDocs ? Check Partner, create IDoc
Partner Profile
Create Document Ok?

Workflow no Partner
Profile
General
Ok? Error handling Settings
no
R/3-System
R/3-System
 SAP AG 1999
NOE Food Company must setup its IDoc interface for inbound processing.
The Documentation tools tell the EDI Subsystem which IDoc types it must understand.
The port name must appear in the Port description; otherwise, the IDoc is not accepted.
In the Partner Profiles, NOE Food enters Smartmart as an Inbound Partner for the message
ORDERS. In addition, responsible agents for error processing are entered here, specific for Partner
and message.
In the general settings, NOE Food defines responsible agents which are notified in the case that no
agent could be found from the partner profiles. This is the case when the inbound IDoc originates
from someone which is not defined as a partner in the partner profiles.
As with Smartmart, NOE Foods wants to archive and, afterwards, delete inbound IDocs which are
completely processed.
© SAP AG CA210 1-20

Summary: Introduction
EDI is located in the Basis portion of the SAP system.

The IDoc type is an open standard interface which is the
integration point between the SAP system and other SAP
systems or perhaps an EDI subsystem.
There are two different ways of processing an IDoc:
inbound and outbound.
 SAP AG 1999
© SAP AG CA210 1-21

Introduction: Unit Summary
You are now able to:

Indicate where the EDI interface is located in the
SAP system
Describe the overview of the EDI interface
Define the general concept of the IDoc
 SAP AG 1999
© SAP AG CA210 1-22

IDocs in the Business Process
Contents
IDoc record types
IDoc and IDoc type
IDoc processing: inbound and
outbound direction
 SAP AG 1999
© SAP AG CA210 2-1

IDocs in the Business Process: Unit Objectives
At the conclusion of this unit you will be able to:

Define the difference between IDoc and IDoc type
Describe the general structure of an IDoc
Point out where in the (business) process chain
the IDoc is created
 SAP AG 1999
© SAP AG CA210 2-2

IDocs in the Business Process: Course Overview
Diagram (1)

Inbound Invoice
10
Payment/Remittance
MM EDI Application
Requirements

 SAP AG 1999
© SAP AG CA210 2-3

IDocs in the Business Process: Course Overview
Diagram (2)
Working with an
EDI Subsystem 15
IDoc Monitoring 16
Archiving IDocs 17
Conclusion 19
 SAP AG 1999
© SAP AG CA210 2-4

IDoc Concept, Technical
EDI subsystem SAP System R/3
EDI message IDoc SAP document
Proper interface between application and

EDI subsystem
Basic support for application
API for development
easy to use
Real-time EDI
Independent of EDI standards
Independent of trading partners
 SAP AG 1999
The interface with the applications is given by:

the IDoc data structure (this is the IDoc type)
the API (application programming interface) to create, read and process IDocs
The data flow is triggered from the source by RFC (Remote Function Call). This guarantees real-
time processing.
An IDoc type is dependent on the logical message (business document) only, but independent of a
specific EDI standard for that logical message.
The IDoc is independent of trading partners, this means:
all data from the master records and the SAP document is filled into the IDoc
the mapping - selection of data to be transmitted - is defined a the EDI subsystem only
© SAP AG CA210 2-5

The Intermediate Document (IDoc)
Application
Intermediate Document type
Control record
Data record
Administrative Segment
Section
Status record
EDI subsystem
 SAP AG 1999
This graphic represents the IDoc as the interface between the EDI subsystem and the R/3 application.
It is very important to note that the IDoc is data stored in a structured format - it is not a process or
any kind of executable code.
An IDoc structure can be used to support multiple message types, for example the data in a sales
order is very similar to the data in a purchase order, therefore both of these message types can use
the same IDoc format.
© SAP AG CA210 2-6

IDoc Architecture
Record structure
control section (key) and data section
identical for outbound and inbound processing
Fields in the data segments according to EDI standards
field length
field type
field values
Application programming interface (API)
creation of IDocs
processing of IDocs
status log
 SAP AG 1999
Field lengths and types are compared with the data element directories of
UN/EDIFACT,
ANSI X12 and
SAP’s data repository
Codes for coded fields are taken from international standards where the standard applies. For
example - Country codes, currency codes, and unit of measure codes use the ISO (International
Standards Organization) codes.
© SAP AG CA210 2-7

IDoc Support
Storage of IDocs for

Processing at a later time
Reference
Display of IDocs
Monitoring and reporting on IDoc processing
Utilities for Documentation of
IDoc types
Record types
Segment types
Utilities for IDoc definition
IDoc structures at segment level
IDoc segments at field level
 SAP AG 1999
IDocs are stored in three tables in SAP. They are stored by record type. The three IDoc tables are:
EDIDC- control records
EDID4 - data records from release 4.x onward
EDID2 - data records from release 3.0C to 3.1I
EDIDD - data records from release 2.0A to 3.0B
EDIDS - status records
© SAP AG CA210 2-8

IDoc Record Types
Control record
Data records
Status records
 SAP AG 1999
Each IDoc in the R/3 database consists of

exactly one control record
data records which hold the application data in segments and describe the hierarchy of these
segments.
status records holding well defined processing steps. Therefore, IDocs far ahead in the processing
chain generally contain more status records than IDocs where processing has just begun.
However, when an IDoc is exchanged with an external system, it only contains the control record
and the data records.
If the external system notifies the R/3 system about what has happened to its IDocs, it can do so by a
status report. In this case, the R/3 system receives status records. The R/3 system attaches the records
to the right outbound IDoc which is still stored in its database.
The R/3 system can also actively send status reports outbound, but only via the special IDoc type
SYSTAT01. Note that in this case, again only control and data records are exchanged. The relevant
status information is contained in the data records.
To summarize: IDocs exchanged between two systems are always smaller than their R/3 database
counterparts, since they do not contain status records.
© SAP AG CA210 2-9

Control Record
Control record IDoc-ID

Partner
IDoc Type and logical message
external structure
 SAP AG 1999
The IDoc-ID is an important part of the control record. It is a simple number which is internally
generated. It uniquely identifies the IDoc in the R/3 system. Status reports always refer to that
number.
The control record also contains the key fields of the partner profile: partner and logical message (3
fields each) as well as a test flag. For inbound IDocs, these key fields determine the dependent
parameters of the inbound partner profile, e.g. which was the IDoc should be processed within the
R/3 system.
The three key fields of the partner (e.g. the receiver for outbound IDocs) are:
number (In the R/3 system, this is the master data number which may be internally generated)
type (customer, vendor, bank or logical system in ALE scenarios)
role (important for outbound processing via message control)
The three message fields are:
message type (if possible, follows UN/EDIFACT notations). For example, ORDERS, INVOIC
code (optional)
function (optional; e.g. changed message)
Other fields are related to mapping IDocs to another EDI standard, e.g. the EDI standard structure or
the EDI message archive.
© SAP AG CA210 2-10

Data Record and Segment Structure
Data record
Control area, contains Application Data
segment name Field 1 Field 2 ...
Segment
 SAP AG 1999
The control area of a data record contains the name of the segment. In the R/3 system, the segment is
defined as a structure, i.e. a series of fields of certain length and data type. Generally, one segment
field is related to one application field.
The application data area of a data record is a single field of 1000 bytes. This is where the
application data resides.
By virtue of the segment name field in the control area, the unstructured application data field of the
data record gets its structure. This always happens when the application writes data into the IDoc or
reads data from the IDoc, because data transfer occurs through the segments.
The data type of the segment fields is character.
If possible, coded fields abide by ISO rules.
© SAP AG CA210 2-11

Status Record
Status record IDoc ID

Status information
 SAP AG 1999
The IDoc number is an important part of the status record. It points to the IDoc to which the status
records belong. Thus, it is possible that status records can be transferred separately and still be
attached to the right IDoc.
First, status information is given by the status value, or simply status, a two-digit number assigned to
a well defined process step.
More detailed information is given by three fields naming an R/3 message. If, for instance, a
processing error occurs, the error message can be included in the new status record reporting the
error situation.
Consider the message SAPEA211; the three fields then take the following values:
- SAP: R/3 message displayed in a standard window (Field STAMQU)
- EA : message class as defined in table T100 (Field STAMID)
- 211 : message number as defined in table T100 (Field STAMNO)
If STAMQU describes messages defined by an external system, messages of that system may be
displayed in a special way. To that end, a special display program must be written and be entered
into table TEDE3.
Other fields of the status record are the date and time when the record was created, and the name of
the program that created it.
© SAP AG CA210 2-12

IDoc Record Types: Summary
Control record IDoc-ID

Partner
IDoc-Type and logical message
External structure
Data records
Control area Application data
Status records IDoc-ID

Status information
 SAP AG 1999
In summary: the IDoc consists of three record types.

The control record contains information about the type of message be exchanged, and to whom it is
being sent/received.
The data records hold the application data.
The status records represent the life-cycle or major milestones of the IDoc's life.
© SAP AG CA210 2-13

IDoc Types
Control Record
Data records, displayed as a tree
E1HDDOC E1TLSUM
M 1 C 2
E1HDADR E1ITDOC
C 5 M 1
E1ITSCH
C 99 C 5
Status records
 SAP AG 1999
Each business process (e.g. a purchase order) is transferred by a special IDoc type which can hold
the relevant data.
An IDoc type is defined through its segments, their hierarchy, order and repeatability. This
information is part of the control area of the data records.
The segment hierarchy can be visualized in a tree as parent and child segments. It gives structure to
the application data.
In conclusion: IDoc types are special data structures tailored to special applications or messages. If
such a structure is filled with application data, an IDoc is created (the instance of the IDoc type).
© SAP AG CA210 2-14

Inbound and Outbound Processing
SAP application
IDoc Interface/ALE Services
R/3 System
External System
Outbound direction Inbound direction
 SAP AG 1999
Directions are always defined as viewed from R/3. Thus, in the outbound direction, IDoc data are
transferred from the application via the IDoc interface to the external system. The inbound direction
processes data from the external system via the IDoc interface to the application.
For inbound processing, the external system must have certain authorizations since it will be creating
documents (IDocs and application documents) within the R/3 system.
Both the inbound and outbound processing directions have multiple ways of processing. These are
explained in the following slides.
© SAP AG CA210 2-15

Outbound Processing via Message Control
SAP application
Document
Message control (NAST)
NAST
record
IDoc
External System
 SAP AG 1999
SAP applications can create IDocs directly or via message control.

When message control is involved, there is the possibility that it can be further processed (i.e.,
filtered) by the ALE services before it is passed to the port.
The IDoc Interface passes every IDoc to the chosen port, according to the technical port description.
Examples for Port types are:
External System = R/3 System: Common is the transactional RFC (Standard ALE scenario)
External System = EDI Subsystem: Common is the file interface.
© SAP AG CA210 2-16

Direct Outbound Processing (FI and ALE)
SAP Application
Master
IDoc
Comm.-IDoc Comm.-IDoc Comm.-IDoc
External System
 SAP AG 1999
During direct outbound processing with ALE scenarios, the ALE services are always called. The
services:
filter the IDoc. Segment fields containing data not necessary for the recipient system are removed
from the IDoc
change the (segment) version. If the recipient system is on an earlier release of SAP or is using an
earlier version of a segment in the IDoc type, the version can be changed here. This means that
less data is transported, since later versions of segment can only contain more fields than former
versions and never less fields.
Occasionally split the IDoc into several IDocs. The can happen in ALE distribution scenarios,
where more than one system receives the data.
To achieve these tasks, the ALE services transform one Master IDoc (passed to the function module
MASTER_IDOC_DISTRIBUTE into one (or more) Communications IDoc(s). Only
Communication IDocs are saved in the database.
The process is slightly different for IDocs created from the FI (financial) area of R/3. A master IDoc
is not created and the ALE services are not called. However, the IDocs are processed through the
IDoc interface to the external system.
© SAP AG CA210 2-17

Inbound Processing via Workflow
External System
IDoc
IDoc +
Process
SAP Business Workflow

IDoc
Document Error
SAP Application
 SAP AG 1999
The external system sends IDocs to the R/3 system via a port name which is defined in R/3. The port
name of the R/3 system can be SAP<SID>CLNT<XXX> e.g. SAPC11CLNT810 for an R/3 system
C11 and client 810.
If the IDoc interface knows the external system (as an inbound port), it accepts the inbound IDocs
and starts processing: For instance, it performs a syntax check and tries to find the IDoc sender,
found in the control record, in the partner profile.
The partner profile determines if the IDoc is directly passed to the application (ALE function
module) or if a workflow is started. If a workflow is started, the ALE services may be called before
the inbound IDocs are stored in the database.
© SAP AG CA210 2-18

Direct Inbound Processing with ALE
External System
IDoc
IDoc
SAP Application
 SAP AG 1999
During direct inbound processing, the ALE services are always called. As in the outbound case, they
can do filtering and change versions. However, inbound IDocs cannot be split.
The ALE processed IDoc is stored in the database. This is called an application IDoc as opposed to
the communication IDoc of outbound processing.
The ALE services can also be called when workflow is invoked.
© SAP AG CA210 2-19

IDocs in the Business Process: Unit Summary

Define the difference between IDoc and IDoc type
Describe the general structure of an IDoc
Point out where in the (business) process chain
the IDoc is created
 SAP AG 1999
© SAP AG CA210 2-20

Data Used in the Exercises
Data Data in Training System Data in IDES System
Company Code: 3000
PO Vendor number V100##
Purchasing 3000
Organization:
Purchasing Group 000
Plant 3000
PO Material DCC-##
PO Output type NEU
Customer number 300##
Customer Material CCS-##
Sales Organization 3000
Distribution 10
Channel
Division 00
Order BA01
Acknowledgment
Output Type
Advance Shipment
Notification Output LAVA
Type
Invoice Output RD00
Type
© SAP AG CA210 2-21

Exercises
Unit: IDocs in the Business Process
At the conclusion of these exercises, you will be able to:

Describe what is meant by an IDoc type
Indicate how IDoc types are used in SAP
IDocs are used to move data into and out of the SAP system. It is
therefore necessary to understand what their components are and how
they are used in the SAP system.
1-1 What is an IDoc type?

___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
1-2 What are the three records types within the Intermediate Document?
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
1-3 Which IDoc record type contains the data which is used to determine the partner
profile information and the direction the data is to travel (into/out of SAP)?
___________________________________________________________________
1-4 The ____________________ is the main key that links the three record types
within an IDoc.
1-5 Are different IDoc types used for inbound messages as opposed to outbound
messages?
___________________________________________________________________
1-6 What is the difference between an IDoc type and an IDoc?

___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
© SAP AG CA210 2-22
1-7 True/False: Status records are sent out of the SAP system?
___________________________________________________________________
1-8 The rule-based condition technique used to output IDocs is called:

Workflow Management
Message Control
Intermediate Document
None of the above
1-9 The rule-based inbound processing technique is called:

Output Determination
Partner Profiles
Workflow Management
None of the above
1-10 Does SAP have a different IDoc type for each transaction or document in R/3?
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
© SAP AG CA210 2-23

Solutions
Unit: IDocs in the Business Process
1-1 An IDoc type is a hierarchical structure containing segments which have fields
that hold application data taken from the SAP database, or application data
which is to create an application document in SAP. Examples are ORDERS02
and MATMAS01, which contain segments that relate to order information and
material master information respectively.
1-2 The three records types within an Intermediate Document (IDoc) are the control
record, data record, and status record.
1-3 The control record contains the fields, which are the keys to the partner profile,
and the direction field value indicates whether the IDoc is outbound or inbound.
1-4 The IDoc ID (number) is the main key that links the three record types within an
IDoc.
1-5 No. The same IDoc types can be used for inbound and outbound messages.
1-6 An IDoc type is a structure which is defined by its segments, hierarchy, order and
repeatability. It is meant to indicate the type of data that will be found in an
IDoc. An IDoc is an instance of an IDoc type with the structure filled with the
application data and assigned an IDoc ID (number) and housed in the IDoc
tables.
1-7 False only the control record and the data records are sent out of SAP. Status
records are sent into SAP to update an IDoc.
1-8 Message Control
1-9 Workflow Management
1-10 No. The IDoc type represents a series of related business documents. For
example, the MM outbound PO, the SD inbound PO, the SD outbound Order
Confirmation and the MM inbound Order Confirmation all use IDoc type
ORDERS01, which contains the structure for order information.
© SAP AG CA210 2-24

General Settings
Contents:
Units of Measure
Logical System
Number Ranges
Process Technology
Workflow Customizing
Event Receiver Linkage
IDoc Administration
Proposal Values for Partner Profile
Map Long Names to Short Names
 SAP AG 1999
© SAP AG CA210 3-1

General Settings: Unit Objectives
At the conclusion of this unit, you will be able to:

State which parameters can be customized
Determine the time when the IDoc administrator is
notified
 SAP AG 1999
© SAP AG CA210 3-2

General Settings: Course Overview Diagram (1)

Genera
Generall Inbound Invoice
3 10
Settings Processing
Payment/Remittance
MM EDI Application
Requirements 6 Test of Processing 13
 SAP AG 1999
© SAP AG CA210 3-3

General Settings: Course Overview Diagram (2)
Working with an
EDI Subsystem 15
IDoc Monitoring 16
Archiving IDocs 17
Conclusion 19
 SAP AG 1999
© SAP AG CA210 3-4

Customizing via IMG
R/3 Customizing
IMG
Basis Components
Basis Services
IDoc
IMG Documentation
Interface
Project Documentation
Project Management
Activities
 SAP AG 1999
For the IDoc interface, general parameters can be set using the IMG. The IMG is an implementation
guide helping you to customize your R/3 system according to your needs. Maintaining the relevant
customizing tables is done in activities.
By selecting the appropriate attributes, users can display only the activities that are required in each
case. For example, if a customer wishes to adopt all SAP standard settings, only the activities with
the attribute ”required” must be executed.
The IMG node or path for the IDoc Interface is Basis Components --> Basis Services -->IDoc
Interface / Electronic Data Interchange. You should read the IMG documentation, which is available
for each activity (double-click on the relevant document).
You can also create your own projects from the standard IMG : projects are a type of view of the
standard IMG, which are used by different teams. The IMG offers project management functions
(resource planning, etc.), as well as functions for creating your own project documentation via
customer notes.
© SAP AG CA210 3-5

Units of Measure
ISO Code Unit of Measure

(IDoc) (SAP)
CS CSE
CS BOX
CS CSE
CS CAR
 SAP AG 1999
There are several fields that may be in the IDoc that are presumed to follow International Standards
Organization values. These fields are currency, country, and unit of measure.
The ISO Unit of Measure may or may not be the same as the SAP internal unit of measure.
Additionally, the trading partner may or may not be following the ISO standard for unit of measure.
It may be necessary to configure additional ISO unit of measure codes to associate with the SAP unit
of measure code.
In the configuration of the SAP unit of measure, there are two fields of interest. The ISO code field is
where the association is made between the ISO unit of measure code and the SAP internal unit of
measure code. The other field is the Primary code field. This is used for inbound information to
determine which single SAP internal unit of measure will be assigned.
For outbound information, many SAP internal units of measure can translate to a single ISO unit of
measure code. The ISO code is placed in the IDoc.
For inbound information an ISO unit of measure code will translate in a single SAP internal unit of
measure code which has the primary code checked.
© SAP AG CA210 3-6

Logical System
Create Logical System

Assign Logical System
PR1 PR2
client 100 client 200
Logical system - Logical system -

PR1CLNT100 PR2CLNT200
 SAP AG 1999
A logical system is a way to name each system/client combination in the system landscape. It is the
way to address where information is being sent to or received from.
All EDI transactions are ALE enabled and ALE technology requires the use of a logical system.
The typical naming convention for logical systems is:
system id CLNT client
All clients in a system must have a unique logical system name. It is also true that the same clients
on different instances must have unique logical system names. For example: DEV client 100 could
be named DEVCLNT100, and PRD client 100 could be named PRDCLNT100.
It is usually the function of the Basis systems people to create logical system names and assign them
to each client.
© SAP AG CA210 3-7

Number Ranges
IDoc Interface
[…]
 SAP AG 1999
Number ranges are intervals of natural numbers which are assigned to objects by the R/3 system.
This is called “internal number assignment”.
In the IDoc interface, number ranges are set for:
IDocs: The IDoc number is taken from this number range
Ports: These numbers identify the tRFC ports
Mailbags: Mailbags are only used when communicating with an R/2 system. Here, IDocs are
communicated in mailbags. Note that this item only exists prior to release 4.5x
These number ranges are set in the IDoc interface IMG component.
© SAP AG CA210 3-8

Replace Process Technology with Workflow
Only necessary when upgrading from 2.1/2.2

IMG Activities:
Change exception handling
Change inbound processing
 SAP AG 1999
Please note the IMG documentation of the individual activities.
© SAP AG CA210 3-9

Use extended exception handling for status return
Converts status codes assigned to system process code

EDIS to EDIR
IMG activity when upgrading to 4.6x
 SAP AG 1999
System process code EDIR is used for notification of negative status values of status reports.
The advantage that EDIR has over EDIS is that further processing of incorrect IDocs is possible.
This activity is only required when upgrading to 4.6x. If this is a new installation then EDIR status
code is already assigned.
This item can be run as a simulation run and then as the actual run.
© SAP AG CA210 3-10

Delete Process Technology from System
Remove unnecessary process codes from system

IMG Activity:
Delete process technology in EDI processing in logistics
Trial run
Final run
 SAP AG 1999
© SAP AG CA210 3-11

Workflow Auto-Customizing
Configures Workflow Runtime and Development Environments

IMG Activity:
Workflow Runtime System:
Active plan version exists
Workflow administrator maintained
Workflow RFC destination configured completely
Generic decision task classified completely
Tasks for document generation fully classified
T77* tables all available
Monitoring jobs for missed deadlines is scheduled
Monitoring jobs for work items with errors is scheduled
Sending to objects and HR objects activated
PD control tables complete
 SAP AG 1999
© SAP AG CA210 3-12

Event Receiver Linkage
IDoc Interface
Event
Processing
R/3 Application
 SAP AG 1999
When IDocs are received, they are first stored in the database. In a second and independent step, they
are processed further (an exception to this rule is the port type “tRFC”, where processing takes place
in one step). This is made possible through the workflow event concept. When IDocs are stored in
the database, an event is created which waits for its “receiver” in the system. The receiver (a function
module) finds the event and starts further inbound processing. Through this step, the function
module has consumed the event: It is no longer there in the system. It is up to the workflow manager
to decide when the consumer starts to look for events. Thus, saving IDocs and processing them
further is separated in time (“asynchronous processing”).
To enable this new form of inbound processing to take place, the corresponding event must be
actively linked to the receiver.
You must therefore activate the event-receiver linkage in the IMG for the IDoc Interface.
© SAP AG CA210 3-13

IDoc Administration: Global Parameters
Allowed Agent to be notified in general (IDoc Administrator)

System Environment (Basis System)
Details of Processing
 SAP AG 1999
The IDoc Administrator is always notified when an error occurs during IDoc processing and no
partner profile could be found. Otherwise, the partner-specific agent (and the message-specific agent,
if required) entered in the partner profile is notified.
In the system environment, the IDoc Interface is informed whether non-Basis components exist, e.g.
Message Control or application components. If these entries are not made, it is possible that the IDoc
Interface may call function modules, for example, which do not exist in the specified system (Basis
system only).
Precessing details:
The maximum number of syntax errors that can be recognized in one IDoc and therefore logged as
status records. The larger this value, the higher the probability that the error messages do not refer
to ”real” errors, but only subsequent errors.
Whether or not inbound processing is triggered synchronously (not via the event-receiver linkage)
(port type File).
System parameters can be entered as ”global parameters” from the IDoc Interface initial screen by
selecting Control -> IDoc Administration or from the IMG for the IDoc Interface.
You should use the F1 Help function for the entry fields.
© SAP AG CA210 3-14

IDoc Administrations: User Parameters
Tests
Documentation Tools
IDoc Lists (4.0x - 4.5x only)
IDoc Display (4.0x - 4.5x only)
Development (4.0x - 4.5x only)
 SAP AG 1999
User-specific parameters of the IDoc interface cannot be set in the IMG. Instead, choose transaction
code WE46 from the entrance menu of the IDoc interface.
The parameters for monitoring the IDoc data flow are display parameters.
The port value is a test parameter, which is proposed as standard by the test programs.
For the documentation tools, you should define the default documentation output, for example,
whether the individual segment fields are also to be included in the documentation of IDoc types.
You can enter a default development class for the development of IDoc types and segments. Course
BC621 contains more information about developing and defining IDoc types.
Monitoring parameters are for layout.
© SAP AG CA210 3-15

Proposal Values for Partner Profile
Proposal Value
 SAP AG 1999
For quick definition of the partner profile, you set up templates in the IMG.
The templates are set per partner type and direction.
Press the button templates from within the partner profile (transaction WE20) to get the templates for
your actual direction and partner type. Then, modify the defaults according to your needs.
Since partner profiles require a port, you can also define a port in the IMG. Note this item is only
valid through release 4.5x.
In the IDES system, the following message types are set for the vendor or customer, depending on
the direction:
DELINS - forecast/JIT delivery schedule
ORDCHG - change purchase order/sales order
ORDERS - purchase order/sales order
DESADV - shipping notification
INVOIC - invoice/billing document
ORDRSP - order confirmation
© SAP AG CA210 3-16

Map Long Names to Short Names
Release 4.x Release 3.X
Type LongName Type “Short01”

XYZ01
 SAP AG 1999
Release 4.0 introduced the extended namespace. IDoc interface objects (e.g. IDoc types) new to 4.0
can have longer names than before.
This fact can lead to problems when communicating with older releases, which understand only short
names. If needed, tables must be maintained which map short names to long names and vice versa.
These mapping tables are maintained in the IMG or from the development menu of the IDoc
interface. From the relevant object (IDoc types or segments), choose transaction code WE70 for
Basic IDoc types, WE71 for Extension IDoc types, WE72 for IDoc types or WE73 for Message
types. Also note the online IMG documentation.
© SAP AG CA210 3-17

General Settings: Unit Summary
You are now be able to:

State which parameters can be customized
Determine the time when the IDoc administrator is
notified
 SAP AG 1999
© SAP AG CA210 3-18

Exercises
Unit: General Settings

Topic: Customizing in the IMG

• Describe what IDoc customizing is done in the IMG for general
settings
IDocs are used to move data into and out of the SAP system. It is
therefore necessary to understand what the general customizing is for
IDoc processing no matter which direction IDocs are going. This
setup is also independent of the use of the IDoc (EDI, ALE, Internet).
1-1 How many different number ranges can be set up for IDoc processing and what are
they?
____________________________________________________________
____________________________________________________________
1-2 How many different number ranges are used for numbering IDocs?
____________________________________________________________
____________________________________________________________
1-3 What is the event receiver linkage?

____________________________________________________________
____________________________________________________________
____________________________________________________________
1-4 Which port type does not make use of the event receiver linkage?
____________________________________________________________
____________________________________________________________
1-5 Why is the IDoc Administrator important?

____________________________________________________________
____________________________________________________________
© SAP AG CA210 3-19

1-6 When must the configuration for replacing the process technology with Business
Workflow be done?
____________________________________________________________
____________________________________________________________
1-7 What is the advantage of using templates for partner profiles?

____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
1-8 True or False:
1-8-1 Releases of SAP older than 4.0x can understand the long names of Logical
Messages, Basic IDoc Types, Extensions, IDoc Types, and Segments?
______________________________________________________
______________________________________________________
© SAP AG CA210 3-20

Exercises

Topic: User parameters
At the conclusion of these exercises, will be able to:

• Configure the system for the IDoc user parameters
It is necessary to set up the user parameters for testing of IDoc

processing in the system.
2-1 Configure the IDoc administration user parameters. Select:

Output as C header file, and Test using file interface.
2-1-1 For Test using file interface use Group## for the Testport.
2-1-2 For Output as C header file use C:\Temp\ for the local directory and a local
file w/o extension name of IDoc.
© SAP AG CA210 3-21

Solutions

Topic: Customizing in the IMG
1-1 Two. IDocs, and Ports
1-2 Only one number range is used to number IDocs no matter whether they are
going into or out of the SAP system. It also does not matter if the IDoc is being
used for EDI, ALE or the Internet.
1-3 If IDocs are to be processed inbound and not synchronously or through the tRFC
port, then IDocs are processed through the workfow event concept. The event
receiver linkage starts the workflow event when inbound IDocs are brought into
the SAP system.
1-4 The tRFC port does not require the event receiver linkage to be executed.
1-5 The IDoc Administrator is important because it is the party to notify when the
party to notify cannot be determined from the message specific partner profile or
the general partner profile.
1-6 When the SAP system is upgraded from 2.1x/2.2x to 3.0x and beyond.
1-7 The use of templates for partner profiles allows for fast entry of partner profiles if
all trading partners have the same messages inbound and/or outbound.
1-8 False. Starting with Release 4.0x the Logical Message, Basic IDoc Types,
Extensions, IDoc Types and Segments increases their length to 30 characters
from 6 – 8 characters prior to 4.0x. If IDocs are sent to earlier releases they only
know the shorter names. Thus there is a series of tables which connect long
names to short names.
© SAP AG CA210 3-22

Solutions

Topic: User Parameters
2-1 From the SAP Easy Acces menu, open folders

Tools → Business Communication → IDoc → IDoc Basis → Control.
Double-click "IDoc administration".
Select the [Display <>Change] button and click on the Test tab.
2-1-1 For Test using file interface use enter your Group## in the TestPort field.
2-1-2 Select Documentation tab and enter the following information for C-Header
output:
C-header output
Field Name Input Data
Local directory C:\temp\
Local file w/o extension IDOC
2-1-2-2 Press the Save icon.

2-1-2-3 Return to the SAP Easy Access menu by selecting the [Back]
button.
© SAP AG CA210 3-23

Port Definitions
Contents:
Port types and their typical fields of use
Port description
Communication with older releases
 SAP AG 1999
© SAP AG CA210 4-1

Port Definitions: Unit Objectives

Decide which port type to use for which system
Define the port description in the R/3 system
Configure the settings necessary for a specific port
type
Configure your R/3 system for communication with
releases earlier than 4.x
 SAP AG 1999
© SAP AG CA210 4-2

Port Definitions: Course Overview Diagram (1)

Business Process
2 Requirements 9
Inbound Invoice
10
Payment/Remittance
Porrtt Definitions
Po 4 Process 11
MM EDI Application
 SAP AG 1999
© SAP AG CA210 4-3

Port Definitions: Course Overview Diagram (2)
Working with an
EDI Subsystem 15
IDoc Monitoring 16
Archiving IDocs 17
Conclusion 19
 SAP AG 1999
© SAP AG CA210 4-4

Port Definitions: Business Scenario
As a member of the integration team of your

company, SmartMart, you are responsible for
setting up the IDoc interface.
SmartMart uses an EDI subsystem. You must
decide which port type is adequate for your EDI
subsystem.
 SAP AG 1999
© SAP AG CA210 4-5

Port Types of the IDoc Interface
SAP Application
IDoc Interface & ALE Services
IDoc & IDoc &

IDoc IDoc IDoc IDoc
status status
File
tRFC CPI-C MIME ABAP XML
+ RFC
EDI ALE EC
R/2 Internet Any
Any Any Any
2.1 on 3.1 on 4.5 on 4.6 on
3.0 on 3.0 on
 SAP AG 1999
The IDoc interface offers 6 different communication channels, defined by the appropriate port types,
within system R/3.
Port type File - Transfer of information via files and synchronous RFC for triggering of the
destination by the source. This allows transfer of IDoc data and the status report.
Port type tRFC - Transfer of all information via (asynchronous) transactional RFC. This is the
preferred method in ALE scenarios and allows transfer of IDoc data.
Port type CPI-C - Transfer of all information via CPI-C. This option is in use only with system R/2
coupling based on the R/2-IDoc interface as released in R/2, 5.0F. This allows transfer of IDoc data
and the status report.
Port type Internet - Transfer of all information via the Internet as MIME attachment. This allows
transfer of IDoc data.
Port type ABAP - Transfer of all information with customer specific program logic. This is thought
to be a Project-Exit for any unforeseen communication channel. IDocs are exchanged as tables with
an internal R/3 function module. This is the only port type where IDocs don‘t leave the R/3 system.
The function module is customer written and can do anything with the IDoc.
Port type XML - Transfer of all information via XML compatible files, including DTD if requested.
This port type is released as prototype, changes and enhancements are expected for future releases.
© SAP AG CA210 4-6

Port Description: Port Type File
RFC Destination
(TCP/IP Connection)
rfcexec
out.script
Outbound Trigger
Outbound File
IDoc File
Inbound File
Status Report
Status File
 SAP AG 1999
The IDoc interface port description holds technical communication parameters. To make a port
useable, further parameters outside of the IDoc interface have to be set.
Name and directory of the outbound trigger (a.k.a. command file pre-4.6x) (called by rfcexec) which
starts the external system. This must be set if the R/3 system is to start, or trigger, the external
system (by RFC). For triggering, one needs to define an RFC destination (e.g. SERVER_EXEC).
This is done with transaction SM59 (TCP/IP connections). This setup is usually done by Basis.
Outbound - Directory name - specify a physical directory path or a logical directory path (new with
Release 4.6x). File name - determined via a static name or via a dynamic name based on a function
module (recommended).
Inbound - Directory name - configuration can be optional based on parameters used by the external,
sending system. If the inbound parameters are set here, they serve as default parameters for the test
tools. As with the outbound parameters, a physical directory path or a logical directory path (new
with Release 4.6x) can be specified. File name - determined via a static name (most commonly used
configuration) or via a dynamic name based on a function module.
Status - Directory name - configuration can be optional based on parameters used by the external,
sending system. If the status parameters are set here, they serve as default parameters for the test
tools. As with the outbound and inbound parameters, a physical directory path or a logical directory
path (new with Release 4.6x) can be specified. File name - determined via a static name (most
commonly used configuration) or via a dynamic name based on a function module.
It is important that the port exists even if it is only used for the inbound process, since the IDoc
interface only accepts known port types.
© SAP AG CA210 4-7

Data Flow for file Port type (trigger)
IDoc Interface
Write RFC 4 3
1 2 Read RFC
rfcexec startrfc
IDoc File
IDoc File Status Report in.script
out.script status.script
Read Call 1 2
4 3 Write Call
Subsystem
 SAP AG 1999
Outbound direction:
Step 1: The IDoc interface creates a new file and fills it with one or more IDocs.
Step 2: The IDoc interface calls the C program rfcexec, handing over the path to an executable
script (e.g. out.script) and name and location of the IDoc file.
Step 3: out.script calls the external system, passing the IDoc file name and location.
Step 4: After successfully processing, the external system must delete the IDoc file.
Inbound direction for IDocs and status report:
Step 1: The external system creates an IDoc file.
Step 2: It starts the R/3 system via the C program startrfc. Startrfc contains the logon parameters
and the name of the function module, the (ínbound) port and the IDoc file path. The startrfc
command can be held in an executable script (e.g. in.script). It is important that the calling system
is known as an R/3 user who has the appropriate authority to create the application documents
corresponding to the IDocs.
Step3: The R/3 system reads the IDoc file and deletes it after successfully reading and loading the
IDocs into the R/3 system IDoc tables.
The status report is processed in exactly the same manner, with the only difference being that a status
file is passed instead of an IDoc file.
"rfcexec" and "startrfc" are C routines from the RFC library delivered with the R/3 system.
© SAP AG CA210 4-8

Port Description: Port Type “tRFC”
RFC Destination
(R/3 Connection)
Application Server
of the external system
Port name (automatically generated)
 SAP AG 1999
The port description only contains the name of an already existing RFC destination. When the port is
entered, the system generates a name starting with an A and ending with a 9-digit number. The
internal number generation needs a number range, which is set in IDoc interface customizing.
Alternatively to the IDoc interface port description, tRFC ports can be (and generally are) maintained
in the ALE customizing.
The RFC destination is maintained as an R/3 connection using transaction SM59.
© SAP AG CA210 4-9

Data Flow for Port Type “tRFC”
IDoc Interface
RFC Interface
TCP/IP
RFC Interface
External System
 SAP AG 1999
tRFC means that one system calls a function module of another system. For IDoc exchange, this
means that the sending system is always the active system. It calls the function module in the
receiving system and passes the IDocs as arguments. The function modules of this port type are
inbound function modules.
Inbound function modules are INBOUND_IDOC_ASYNCHRONOUS (new for Release 4.0) and
INBOUND_IDOC_PROCESS (older Releases). To send an IDoc to an R/3 system older than 4.0,
one must call INBOUND_IDOC_PROCESS: This is set in the Port Version.
Non-R/3 systems need the R/3 RFC library. From transaction SE37, the external RFC interface can
be generated. If a non-R/3 system is able to receive an IDoc via tRFC, it must additionally contain a
function module analoguous to INBOUND_IDOC_ASYNCHRONOUS or
INBOUND_IDOC_PROCESS.
All passed IDocs are asynchronously stored in the data base via a single COMMIT WORK
command.
© SAP AG CA210 4-10

Port Description: Internet
Internet
Destination
Internet address
Folder for Outbound IDocs IDoc
Additional mail attributes
 SAP AG 1999
The most important part of the port description is the internet address (IP address). Together with the
IDoc, it is passed to the internet gateway (or the Microsoft exchange server) via SAPconnect.
Further parts of the port description are the mail attributes:
a description text which can be read as the mail body the mail title of the mail body and a folder of
the owner system where outbound IDocs can be stored for control purposes.
The general settings (IDoc administration) contain the folder where exception messages on inbound
IDocs will be stored.
© SAP AG CA210 4-11

Data Flow for Port Type “Internet”
IDoc
File
IDoc
SAPconnect
IDoc MIME-email External

Interface SAPoffice System
 SAP AG 1999
For internet delivery, IDocs are stored in another format (SAPoffice name: R3I), a table 255 digits
wide. This table is passed by SAPconnect to
either the internet gateway (program sendmail) or
the Microsoft exchange server.
The program sendmail is already part of a UNIX operating system. It must be bought for a Windows
NT system.
The gateway (or the Microsoft exchange server) convert the IDoc table to the MIME format.
For inbound direction, data flow proceeds exactly the opposite way. Internet IDocs appear as mail
attachments in the mailbox of the addressee.
To use this port type, the following additional parameters must be set (not part of the port
description):
A SAPconnect knot must exist for the address type INT (for routing of the internet messages)
The SAPoffice user must have an address for the address type INT to be able to receive IDocs.
© SAP AG CA210 4-12

Port Description: Port Type XML
RFC Destination
(TCP/IP Connection)
rfcexec
out.script
Outbound Trigger
Outbound File IDoc File
 SAP AG 1999
IDoc data is written not in IDoc format, but rather in XML format in a file at operating system level.
The names of XML tags refer to the IDoc record types or IDoc segments. XML is designed to be a
self-descriptive Internet-enabled language. Tags can be defined here and recorded in a Document
Type Definition (DTD). As a result, XML is extendible and corresponds in particular to the new
definition of IDoc types concept. IDocs in XML format can be displayed immediately with the
corresponding Internet browser.
Name and directory of the outbound trigger file (called by rfcexec) which starts the external system.
This must be set if the R/3 system is to start, or trigger, the external system (by RFC). For
triggering, one needs to define an RFC destination (e.g. SERVER_EXEC). This is done with
transaction SM59 (TCP/IP connections). This is a set up outside of the IDoc interface.
Outbound - Directory name - specify a physical directory path or a logical directory path (new with
Release 4.6x). File name - determined via a static name or via a dynamic name based on a function
module (recommended).
Choose whether the IDocs should be written together with the corresponding DTD in the XML file.
The DTD contains the tags that are used in the XML IDoc, therefore tags are for the IDoc record
types and the individual segments. The tags are named in the same way as the individual fields.
If possible, you must replace country-specific special characters such as ä,ö,ü with international
characters like ae,oe,ue. In addition, you must maintain the Conversion table and then select Convert
special characters. You must note, however, that the character strings in the segment fields can then
change length.
© SAP AG CA210 4-13

Port Type XML, e.g. Message SYPART
 SAP AG 1999
The above capture was manually edited with line-wraps to enhance the readability.
The file is coded with the code page of the SAP application server.
Because some Browsers are not able to display XML files containing national characters, filters can
be defined with the port definition.
Same as with port type File rfcexec and startrfc with function module EDI_DATA_INCOMING
(rfcexec.exe and startrfc.exe on Windows NT) can be used to trigger between source and destination.
© SAP AG CA210 4-14

Communication with Older Releases
Version 3
Field 2 Field 3 Field 1 4.X
Version 2
Field 1 Field 2 New Field 3 3.0/3.1
Version 1
Field 1 Field 2 2.1/2.2
 SAP AG 1999
IDoc Record types are defined by their structure in the ABAP dictionary.
Structure definitions have changed in different releases; for instance, the extended name space was
introduced with R/3 Release 4.0. This meant that segment names can now contain 27 digits (instead
of the former 7). This caused the field - segment name - to be longer in the data record control area.
To be able to communicate with earlier releases, the port description contains the version:
Version 1: record types are exchanged with structure of Releases 2.1/2.2
Version 2: record types are exchanged with structure of Releases 3.0/3.1
Version 3: record types are exchanged with structure of Releases 4.X
In addition for the Port type tRFC, a non-R/3 system must know the correct name of the function
module to be called.
The R/2 system record types always have the same structure. Therefore, no version has to be
maintained for the Port Type “CPI-C”.
© SAP AG CA210 4-15

Ports and Port Types
IDoc Interface
IDoc IDoc IDoc
Port 1 (e.g. Type Port 2 (e.g. Type Port 3 (e.g. Type

“file”) “file”) “tRFC”)
External System 1 External System 2
 SAP AG 1999
© SAP AG CA210 4-16

Port Definitions: Unit Summary
IDocs or status records are always exchanged with

an external system via ports.
The port description defines the target system and
technical communication parameters. Furthermore,
it is here where you define which R/3-Release is
understood by the receiving system.
Further parameters (also outside of the R/3 system)
have to be set to use a port.
Generally, there are six port types representing six
different communication techniques.
 SAP AG 1999
© SAP AG CA210 4-17

Exercises
Unit: Port Definitions

Topic: Create a File Port

• Create a file port
It is necessary to set up a file type port definition to indicate the path that
the data will travel from SAP to a subsystem where the data is kept in a
file until the subsystem is ready to use it or pass it to SAP.
1-1 Create a file port type for your group for the current release of the control record.
1-2 Create the outbound file parameters using the directory path of:
\usr\sap\<SID>\SYS\global\ where SID is the training system id and Function
module EDI_PATH_CREATE_USERNAME.
1-3 Create the command file parameters using the logical destination of
SERVER_EXEC, the directory path of: \usr\sap\<SID>\SYS\global\ where SID
is the training system id and Shell script Converter_start.
1-4 Create the inbound file parameters using the directory path of:
\usr\sap\<SID>\SYS\global\ where SID is the training system id and the Inbound
file name of Inbound.
1-5 Create the status file parameters using the directory path of:
\usr\sap\<SID>\SYS\global\ where SID is the training system id and the Status file
name of Status.
© SAP AG CA210 4-18

Solutions
Unit: Port Definition

Topic: Create a File Port
1-1 From the SAP Easy Acces menu, open folders

Tools → Business Communication → IDoc → IDoc Basis → IDoc
Double-click "Port Definition".
1-1-1 Select or open File folder and the Create icon.

1-1-2 Enter the following information:
New Entries: Overview of Created Entries

Port Group##
Description Port for group ##
Select the IDoc record types SAP Release 4.x radio button under Version.
1-2
1-2-1 Select Outbound file tab.
Parameters for Outbound File

Directory \usr\sap\<SID>\SYS\global\
Function module EDI_PATH_CREATE_USERNAME
Outbound file Blank
Select the Physical directory radio button
© SAP AG CA210 4-19

1-3
1-3-1 Select Outbound:Trigger tab.
Parameters for Outbound: Trigger

RFC Destination SERVER_EXEC
Command File Converter_start
1-4
1-4-1 Select Inbound file tab.
Parameters for Inbound File

Function module Blank
Inbound file Inbound
1-5
1-5-1 Select the Status file tab.
Parameters for Status File

Function module Blank
Status file Status
1-5-3 Press Save icon.

1-5-4 Note the newly created Port name.
_________________________________________________________
© SAP AG CA210 4-20

Partner Profiles
Contents:
Standard
Fast Entry
 SAP AG 1999
© SAP AG CA210 5-1

Partner Profiles: Unit Objectives

Explain the purpose of the process code and the
partner profiles
Execute the partner profile transaction
 SAP AG 1999
© SAP AG CA210 5-2

Partner Profiles: Course Overview Diagram (1)

Inbound Invoice
10
Payment/Remittance
Partner Price Catalog, Inventory
Profiles 5 Advice 12
MM EDI Application
 SAP AG 1999
© SAP AG CA210 5-3

Partner Profiles: Course Overview Diagram (2)
Working with an
EDI Subsystem 15
IDoc Monitoring 16
Archiving IDocs 17
Conclusion 19
 SAP AG 1999
© SAP AG CA210 5-4

Partner Profiles: Business Scenario

company (SmartMart or NOE Foods), you are
responsible for setting up the IDoc interface.
SmartMart must define NOE Foods as its
receiving partner for the IDoc outbound
processing. You have already set up an
appropriate port.
NOE Foods must define SmartMart as a sending
partner for the inbound direction.
In both cases, you must maintain the appropriate
partner profile of the IDoc interface.
 SAP AG 1999
© SAP AG CA210 5-5

Structure of the partner profile
General Partner
Partner
Profile
receiver of notifications
Partner Outbound
message
Port
IDoc Type
EDI Structure
receiver of notifications Partner
Application
process code
message type
Partner Message Control Parameters
message
process code
receiver of notifications
Inbound
 SAP AG 1999
There are four parts of the partner profile:

General settings: Keys are the partner taken from the master data (2 fields: number and type).
Further fields relate to this partner in general: For instance, here you must determine one user or
position to be informed in case of errors. This user is only informed if there are no specific users to
be found in the inbound or outbound parameters.
General outbound settings: Keys are partner (3 fields: number, type and role), message (3 fields:
type, variant, function) and a test flag. The partner points to the general settings. Further fields are
the outbound port and the IDoc type. This means that partner, message and test flag uniquely
determine the outbound port and IDoc type.
The general outbound settings must always be maintained, no matter which outbound route is
defined: the direct one or the one under message control.
Message Control settings: Additional parameters have to be set when message control is being
used (MM and SD modules). Key fields are the application, the partner (3 fields) and the condition
type. These fields are the key fields of the table NAST. The partner points to the general partner
profile. Caution: The condition type is also a kind of message but is different from the message
type of the partner profile.
Inbound settings: Keys are partner, message (3 fields each) and a test flag. The partner points to
the general partner profile. Additional parameters are the process code which determines the
inbound processing. This means that partner, message and test flag uniquely determine how the
inbound IDoc is being processed.
© SAP AG CA210 5-6

Output modes, File Port type
Partner
Partner Description Profile
profile.
transfer single IDoc and start (trigger)

external system
transfer single IDoc;

no Trigger
transfer batch of IDocs and start

(trigger) external system
transfer batch of IDocs;

no Trigger
 SAP AG 1999
The transfer time is only well defined if the external system is triggered, which requires a specific
output mode for the file port type. Triggering helps maintain data consistency.
Non-triggered data transfer includes the danger that IDoc or status files may be multiply processed,
or not processed at all.
Other port types always include triggering (because there is no intermediate data dock like the
operating system file). Thus, there are only output modes with triggering included.
The IDoc interface programs use numbers for the output mode (field OUTMOD). These can take the
values from 1 to 4 (read from top to bottom in the slide).
© SAP AG CA210 5-7

Partner Profiles: Outbound processing (1)
SAP Application
Document
Message Control
NAST Document
record
General + Outbound
R/3 System
IDoc
Following system
 SAP AG 1999
Smartmart wants to send orders via the IDoc interface. From the MM module, output is always
determined by message control. Therefore, Smartmart has to maintain the following parts of the
partner profile:
The general setting: The NOE Food Company's name is entered as the partner number, as it
appears in the master data. Its partner type is LI, identifying NOE Food Company as a vendor in
the R/3 system.
The general outbound parameters: Partner number and type are entered as in the general settings.
An additional parameter is the partner role LF (vendor). The role must be entered because it points
to the corresponding entry in the table NAST of the message control. The message type is
ORDERS. This name utilizes the EDIFACT notation.
The message control parameters: partner role is LF, message type is ORDERS. Keys specific to
NAST are the application EF (purchase order) and the condition type NEU.
The message is used in production. Therefore, the test flag is not set.
Note: Only key fields are mentioned here.
© SAP AG CA210 5-8

Partner Profiles: Outbound processing (2)
Partn: Noefoods; Appl: EF; cndtype: NEU Object type, NAST record
language,...
Partn: Noefoods; Appl: EF; cndtype: NEU Process code: ME10 Message
Message type : Control
ORDERS settings
Partn: Noefoods; Message type: ORDERS

General
Port: T70CLNT810 receiver of notifications: Outbound
IDoc Type: ORDERS01 EDI-responsible for orders from
Partner NOE Food Company
 SAP AG 1999
As always, key fields uniquely determine the other dependent fields. When Smartmart sends an order
to NOE Food Company, the partner profiles have the following effect:
Message control (NAST) creates a NAST data record containing application EF, condition type
NEU and partner NOE Food Company. These fields uniquely determine the process code ME10
and the message type ORDERS.
The process code names the function module filling the IDoc type with application data. The
message ORDERS and partner NOE Food Company are assigned to the corresponding fields of
the general outbound settings, which are key fields. They determine that the IDoc type
ORDERS01 is to be used (i.e. filled with application data); they also determine the outbound port.
In conclusion, the NAST record determines IDoc type, port and function module, i.e. the whole
outbound processing. Of course, it also determines the non-key fields, e.g. the receiver of
notifications.
The appendix gives a set of commonly used combinations of NAST and outbound partner profile
settings.
© SAP AG CA210 5-9

Partner Profiles: Inbound processing (1)
Sending System
IDoc
General + Inbound
IDoc +
Process
SAP Business Workflow
Document Error
IDoc
SAP Application
 SAP AG 1999
NOE Food Company wants to receive purchase orders from SmartMart in the R/3 module SD. The
following parts of the partner profile must be set.
The general settings: Here Smartmart's partner number is entered as it appears in the SD master data.
The partner type is KU (customer).
Inbound processing: partner number and type are entered as in the general settings. Message type is
ORDERS.
The message will be used in production. Therefore, the test flag is not set.
Note: Only fields are mentioned here.
© SAP AG CA210 5-10

Partner Profiles: Inbound processing (2)
IDoc Type: IDoc

Partner: Smartmart; message: ORDERS
ORDERS01 Control record
process code:
Partner: Smartmart; message: ORDERS
ORDE; Inbound
receiver of notifications:
EDI-responsible for
processing
orders from partner
Smartmart
 SAP AG 1999
As always, key fields uniquely determine the other dependent fields. Therefore, when Quickdeliver
receives an order from Smartmart, the partner profiles have the following effect:
The inbound IDoc contains the partner Smartmart and message type ORDERS in its control
record. Together with the test flag (also part of the control record), these key fields uniquely
determine the inbound process code ORDE.
ORDE names a function module reading the inbound IDoc.
In conclusion, the IDoc determines how it is being processed in the inbound direction. Of course,
it also determines the non-key fields, e.g. the receiver of notifications.
© SAP AG CA210 5-11

Process Codes - Outbound
Partner
Example: Message Control Parameters in the Partner profile Profile
Partner
Application
Cond.Type
Process Code
Function module
(writes application data to outbound IDoc) IDoc
 SAP AG 1999
A process code is nothing more than a second name for a process, e.g., a function module or a
workflow. Objects of processing are the IDocs.
The partner profiles only contain the process codes, never the real name of the function module.
Thus, it is possible to replace an old process by a new one for all relevant partners in one single step,
assigning the new process to the old process code.
Partner profiles contain process codes for the inbound and outbound direction. In addition, there are
process codes for error handling. These don't save work in the sense outlined above. However, they
were introduced for completeness.
In the outbound case, the process code for output is found on the message control (setup for
messages output from the SD and MM module). There is no process code or Message Control
parameters for messages going out from modules other than SD and MM. The outbound process
codes always identifies a function module.
© SAP AG CA210 5-12

Process Codes - Inbound
Partner
Example: Inbound processing Profile
Partner
message
Process Code
Function module/Workflow
(reads data from inbound IDoc and processes it further)
 SAP AG 1999
The inbound partner profiles always contain the process code, identifying either a workflow or a
function module (direct way).
There are two types of process codes for error handling:
System: error handling for IDoc processing (both inbound and outbound)
Status: error handling for status processing
All process codes are accessed through the menu entry Control in the IDoc interface.
Check the online documentation (extended help) for further information on process codes.
© SAP AG CA210 5-13

Fast Entry of Partner Profiles
IMG Proposals or Control Menu

Partner Type
Direction
Logical Message Configuration
Outbound Parameters
Message Control Parameters
Inbound Parameters
Partner Profile Entry
Partner Number
Partner Type
Fast Entry icon
 SAP AG 1999
In the IMG under the IDoc Interface section in the Basis Services area, or under the Control menu of
the IDoc Basis section, you can create proposals for the different messages that are exchanged with
trading partners. These proposals are created by partner type and direction. For example, a proposal
would be created for outbound vendor messages - direction 1 (outbound), partner type LI (vendor).
The logical messages are added to the proposal. Each logical message can be configured for the
appropriate outbound and message control parameters. This configuration consists of defining:
Outbound parameters - partner function, message code and function, port definition, IDoc type
(basic, extension), collect IDocs (if not selected then immediate is assumed) start subsystem (if not
selected then do not start is assumed), receiver of notifications (recipient type, id)
Message Control parameters - application, message type, process code, change message flag
Inbound parameters - partner function, message code and function, trigger background, trigger
immediate, process code, receiver of notifications (recipient type, id)
Partner Profile entry consists of entering the value SAP master data number for the trading partner
and the partner type and selecting the Fast Entry icon. The system will display a screen on which the
direction of the configuration is determined. Once this is selected then the list of logical messages is
presented and the appropriate messages for the trading partner can be selected from the list.
© SAP AG CA210 5-14

Partner Profiles: Unit Summary
Explain the purpose of the process code and the

partner profiles
Execute the partner profile transaction
 SAP AG 1999
© SAP AG CA210 5-15

Exercises
Unit: Partner Profiles

Topic: Vendor Partner Profile Creation

• Create the vendor partner profile entries
Certain messages (outbound Purchase Orders and inbound Purchase

Order Acknowledgements, Advanced Ship Notices and Invoices) are
traded with the vendor.
Note: The general partner profile for the vendor has already been
created.
1-1 Examine the general partner profile entry for your vendor.
1-1-1 What is the partner status of your trading partner?
___________________________________________________________
1-1-2 What are the default receiver of notifications for your trading partner?
___________________________________________________________
1-2 Create the outbound parameters vendor partner profile entry for outbound Purchase
Order using message type ORDERS, partner function VD, the file port created in
the Create a File Port exercise, transfer IDoc immed, do not start subsystem, basic
type ORDERS01.
1-3 Create the message control vendor partner profile entry for outbound Purchase
Order using application EF, message type NEU, partner function VD, message type
ORDERS, process code ME10.
1-4 Create the inbound parameters vendor partner profile entry for inbound Purchase
Order Acknowledgment using message type ORDRSP, partner function VD,
process code ORDR, and immediate processing.
1-5 Create the inbound parameters vendor partner profile entry for inbound Advanced
Ship Notification using message type DESADV, partner function VD, process code
DELS, and immediate processing.
© SAP AG CA210 5-16

Partner Profiles Exercises

Topic: Customer Partner Profile Creation

• Create the customer partner profile entries
Certain messages (inbound Sales Order and outbound Sales Order

Acknowledgement, Advanced Ship Notification, and Invoice) are traded
with the customer.
Note: The general partner profile for the customer has already been
created.
2-1 Examine the general partner profile entry for your customer.
2-1-1 What are the 6 different partner types?
___________________________________________________________
2-1-2 Can the default receiver of notifications be changed on the
outbound/inbound parameters screen?
___________________________________________________________
2-2 Create the outbound parameters customer partner profile entry for outbound Sales
Order Acknowledgement using message type ORDRSP, partner function SP, the
file port created in the Create a File Port exercise, Collect IDocs, do not start
subsystem, and basic type ORDERS01.
2-3 Create the message control customer partner profile entry for outbound Sales Order
Acknowledgement using application V1, message type BA01, partner function SP,
message type ORDRSP, and process code SD10.
2-4 Create the outbound parameters customer partner profile entry for outbound
Advance Shipment Notification using message type DESADV, partner function
SH, the file port created in the Create a File Port exercise, transfer IDoc immed, do
not start subsystem, and basic type DELVRY01.
2-5 Create the message control customer partner profile entry for outbound Advance
Shipment Notification using application V2, message type LAVA, partner function
SH, message type DESADV, and process code DELV.
© SAP AG CA210 5-17

2-6 Create the outbound parameters customer partner profile entry for outbound Invoice
using message type INVOIC, partner function BP, the file port created in the Create
a File Port exercise, transfer IDoc immed, do not start subsystem, and basic type
INVOIC01.
2-7 Create the message control customer partner profile entry for outbound Invoice
using application V3, message type RD00, partner function BP, message type
INVOIC, and process code SD09.
2-8 Create the outbound parameters customer partner profile entry for outbound Price
Catalog using message type PRICAT, partner function SP, the file port created in
the Create a File Port exercise, tranfer IDoc immed, do not start subsystem, and
basic type PRICAT01.
2-9 Create the inbound parameters customer partner profile entry for inbound Sales
Order using message type ORDERS, partner function SP, process code ORDE, and
immediate processing.
© SAP AG CA210 5-18

Solutions

Topic: Vendor Partner Profile Creation
1-1 From the SAP Easy Access menu, open folders

Tools → Business Communication → IDoc → IDoc Basis → IDoc
Double-click "Partner Profile".
Open folder Partner type LI.
1-1-1 Select the appropriate partner number for your group.

Partn.number V100##
1-1-2 Select Classification tab.
1-1-3 A – active, the trading partner must be active in order for messages to be
exchanged. A status of I means that the trading partner is inactive. A
status of T indicates that this trading partner is to be used as a template
for creating new trading partner profiles.
1-1-4 Select Post Processing: permitted agent tab.
The default receiver of notifications is broken out into Type S for Position,
Agent 50017123- 50017134, 50017155-5001762 for the internal id
number of your Student Group under organizational unit IDoc_Notif
which is found in the PDOrg (Personnel Development Organization
structure) and Lang. EN for English.
1-2
1-2-1 From the Partner Profile screen: Press [Create outbound parameter] button.

Partn.Funct. VD
Message Type ORDERS
© SAP AG CA210 5-19

1-2-3 From Partner profiles: Outbound parameters: Select Outbound options tab.
Maintenance of outbound options

Receiver Port File port created in Port Definition unit
exercise
Output Mode Transfer IDoc immediately
Do not start subsystem
Basic Type ORDERS01
1-2-3 Select the Post processing: permitted agent tab.
Post processing: permitted agent

Typ S
Agent Enter same value found on general
partner profile
Lang. EN
1-2-5 Click over to the right and select EDI Standard tab.
Maintenance of outbound parameters

EDI Standard X
Message Type 850
Version 004010
1-3
1-3-1 Select the Message Control tab and press the [Insert line] button.
© SAP AG CA210 5-20

Message Control
Application EF
Message Type NEU
Process Code ME10
1-3-4 Green arrow back.
1-4
1-4-1 From the Partner Profile screen: Press [Create Inbound parameter] button.
Maintenance of inbound parameters

Partn.Funct. VD
Message Type ORDRSP
1-4-3 For Inbound options enter the following information.
Inbound options
Process Code ORDR
Processing by function module Trigger immediately
© SAP AG CA210 5-21


Typ S
partner profile
Lang. EN
1-5
1-5-1 From the Partner Profile screen: Press [Create Inbound parameter] button

Partn.Funct. VD
Message Type DESADV
Inbound Options
Process Code DELS
© SAP AG CA210 5-22

Typ S
partner profile
Lang. EN
© SAP AG CA210 5-23

MM EDI Application Requirements
Contents:
MM Application Requirements
Master Data
Confirmation Control
Sending a Purchase Order
Sending a Scheduling Agreement
Forecast
Delivery Schedule
 SAP AG 1999
© SAP AG CA210 6-1

MM EDI Application Rqmts: Unit Objectives

Send out a purchase order in IDoc format
Describe what EDI-specific master data has to be
set up
Locate the area where scheduling agreements,
forecasts and delivery schedules are created
 SAP AG 1999
© SAP AG CA210 6-2

MM EDI Application Requirements: Course
Overview Diagram (1)

Inbound Invoice
10
Payment/Remittance
MM EDI
EDI Appli
Application

 SAP AG 1999
© SAP AG CA210 6-3

MM EDI Application Requirements: Course
Working with an
EDI Subsystem 15
IDoc Monitoring 16
Archiving IDocs 17
Conclusion 19
 SAP AG 1999
© SAP AG CA210 6-4

MM EDI Application Requirements: Business
Scenario

company (SmartMart or NOE Food Company) you
are responsible for setting up the IDoc interface.
Both companies run EDI Subsystems.
Ports and the partner profile have already been set
up, now you want to send test IDocs.
To send test IDocs, you must set-up your own
relevant application.
 SAP AG 1999
© SAP AG CA210 6-5

MM Application Requirements EDI (1)
MM Vendor Master Records

General Data
Address
Company Code Data
Account Info
Correspondence
Purchasing Organization Data
Purchasing Data
MM Info Records
Purchasing Material Info Records
 SAP AG 1999
Vendor Master records

General Data
Address
Company Code Data
Account Info
Correspondence
Purchasing Organization Data
Purchasing Data
MM Purchasing Info Records
© SAP AG CA210 6-6

EDI specific master data, MM module
Control record
Vendor master data:
Partner number, type, role Receiver
Vendor master data: Data record

E1EDKA1: Partner
own account on vendor’s
information
system
Data record
Vendor material info: E1EDP19:
vendor’s material name Material number
Message Control
condition record,
medium “6” (EDI)
IDoc
IDoc Type
Type ORDERS01
ORDERS01
 SAP AG 1999
The MM master data must contain certain parameters which are sent to the orders IDoc recipient.
Besides partner number and type, the partner function must be set in the vendor's master data. The
partner role must be included in the additional outbound partner profile for message control (NAST).
The vendor master data should contain the own name as it appears as the partner number in the
recipient's partner profile. This name should be entered in the field “account at vendor's side” (LFB1-
EIKTO). It is compared with the partner number of the recipient's inbound partner profile. Not
maintaining the field requires that the recipient must maintain an additional mapping in his system.
The vendor material information must contain the vendor's name of the material to be ordered. The
name is transferred by segment type E1EDP19. From this segment, the SD recipient determines
which material was ordered.
The Message Control condition record must contain a 6 (EDI) denoting the sending medium.
Otherwise, the IDoc interface will not be activated.
© SAP AG CA210 6-7

MM Application Requirements EDI (2)
MM Acknowledgement Records
Confirmation Categories
External Confirmations
Internal Confirmations
Confirmation Control Keys
Confirmation Sequence / Monitoring
 SAP AG 1999
Confirmation sequence:
This allows you to specify the chronological order in which the individual confirmations within a
confirmation control key are expected and which confirmation categories are to be automatically
monitored.
Monitoring Period (MP) - The value in days that a confirmation must be received
Reference Date (D) - Determines the mode of monitoring:
If the acknowledgment is not received in the period between the PO Date plus the monitoring
period then submit the PO for the monitoring report.
If the acknowledgement is not received before the period between the Delivery Date minus the
monitoring then submit the PO for the monitoring report.
Note: The transaction for the acknowledgment monitoring report is ME92 (RM06ENAB). Also for
the PO to be monitored the Order Acknowledgement Req'd field in the PO must turned on.
Processing Time (PT) - Time it takes to process the confirmation.
TolTooE (Early Tolerance) - Sets the maximum number of days before the delivery date that the
order will be accepted
TTL (Late Tolerance) -Sets the maximum number of days after the delivery date that the order will
be accepted
© SAP AG CA210 6-8

Purchase Order of SmartMart
R/3 System of Smartmart
Book order, write NAST record
Find port for partner NOE Food Company
Create IDoc and pass it to port
Take over the data
External system = Smartmart’s EDI subsystem
 SAP AG 1999
For Smartmart, data flow looks like the following:

Since the order is created in MM, outbound processing has to take place under message control.
The master data record types of the vendor NOE Food Company therefore contain a condition
record for an EDI message corresponding to the orders application document. Message control
finds this condition record and writes out a NAST table record for the message status.
NAST record key fields are assigned to the corresponding key fields of the partner profile. They
determine the process code, which in turn identifies the outbound processing; creating an
outbound IDoc via a function module.
Key fields of the partner profile (message control parameters) are assigned to key fields of the
general outbound partner profiles. This determines the IDoc type applied (ORDERS01) and the
outbound port.
Now, the IDoc interface knows which IDoc type to fill with which function module. The IDoc is
created. The partner profile determines that the IDoc will be immediately passed to the port.
© SAP AG CA210 6-9

Scheduling Agreement
Scheduling Agreement - Types

Without Release Strategy
Outline agreement
Delivery schedule
With Release Strategy
Forecast
Just-in-Time (JIT)
Material Master Configuration
Just-In-Time indicator
 SAP AG 1999
The scheduling agreement can be created with or without releases. Here the difference is based on
which document type is used. Scheduling agreement document type LP denotes without release and
document type LPA is used with release capability. The term release is used here to mean a type of
rolling delivery schedule issued against scheduling agreement and also to connote approval or
“giving the green light” to the vendor.
If we do not use the release strategy then the sequence of events would be as follows: Create the
outline agreement which indicates what materials and total quantity and other pertinent information
similar to a Purchase Order. If configured, as soon as the document is saved, it is considered official
and can be transmitted to the vendor. This will make use of the output condition type NEU found in
output procedure RMBEV1. Next the delivery schedule would be created. This indicates to the
vendor the expected delivery dates and quantities. Again as soon as the document is saved, if
configured, this is an official document which can immediately be transmitted to the vendor. Here
we use output condition type LPET found in output procedure RMBEL1.
In using the release capabilities, we are saying that the scheduling agreement has more of an internal
character and we can change it as necessary and only upon releasing do we wish to transmit the
information to the vendor. We still create the outline agreement but use document type LPA instead
of LP. We would then create a delivery schedule which can contain a forecast of delivery dates and
quantities or Just-in-Time delivery dates and quantities. We then can create releases and send to the
vendor our forecast (output type LPH1) or JIT (output type LPJ1).
If will be doing JIT then need to set the JIT indicator on for the material in the material master.
© SAP AG CA210 6-10

MM EDI Application Requirements: Unit Summary

Send out a purchase order in IDoc format
Describe what EDI-specific master data has to be
set up
Locate the area where scheduling agreements,
forecasts and delivery schedules are created
 SAP AG 1999
© SAP AG CA210 6-11

Exercises
Unit: MM EDI Application Requirements

Topic: EDI Application Setup

• Add the entries in the vendor master data for EDI processing
• Create the purchasing information record
The vendor master data contains a field owned by the EDI process to
populate a segment in the IDoc. Additionally, cross reference records can
be set up to identify your vendor's material with your material.
1-1 Maintain an account at vendor in the vendor master using your vendor V100## and
the account at vendor of 300##.
1-2 Create the vendor material info record for your material DCC-## and the vendor's
material CCS-##.
© SAP AG CA210 6-12

Exercises

Topic: Create Outbound Purchase Order

• Create the outbound Purchase Order via EDI
• Manually propose EDI output
There is an agreement between you and your trading partner to

communicate Purchase Orders via EDI.
2-1 Create a purchase order to your vendor.

2-1-1 Buy 100 cartons of double chocolate chip cookies at 3.60 a carton.
2-1-2 Manually propose output via the IDoc (EDI) for the Purchase Order output
type using output type NEU, output medium EDI, and timing Send
immediately (when saving the application).
2-1-3 Record the Purchase Order number.
________________________________________________________________
© SAP AG CA210 6-13

Solutions


LOGISTICS → MATERIALS MANAGEMENT → PURCHASING →
MASTER DATA → VENDOR → CENTRAL → CHANGE
Change Vendor: Initial Screen

Vendor V100##
Company code 3000
Purchasing Organization 3000
1-1-2 Select Correspondence in the Company Code section.

1-1-2-1 Press [Enter].
1-1-2-2 Enter the following information:
Change vendor: Correspondence Accounting

Account at vendor Your customer number 300##
1-1-2-3 Press Save icon.

1-1-2-4 Green arrow back to the SAP Easy Access menu.

MASTER DATA → INFO RECORD → CREATE
© SAP AG CA210 6-14

Create Purchasing Info Record: Initial Screen

Vendor V100##
Material DCC-##
Purch Org 3000
Plant 3000
1-2-2 Press Enter.

Create Info Record: General Data

Vendor mat. No. CCS-##
1-2-4 Press the [Purch org. data 1] button.

Create Info Record: Purch. Orgainzation Data 1

Plnd dely time 1
Standard qty. 1
ConfContrK 0001
Tax code I0
Net price 3.60
1-2-6 Press the Save icon.

© SAP AG CA210 6-15

Solutions

Topic: Create Outbound Purchase Order
2-1 Create a purchase order for your vendor.

From the SAP Easy Access menu, open folders
PURCHASE ORDER → CREATE → VENDOR/SUPPLYING PLANT
KNOWN
Create Purchase Order: Initial Screen

Vendor V100##
Press [Enter].
When the Org. Data screen appears enter the following information:
Create Purchase Order: Org. data

Purchasing org. 3000
Purch. Group 000
Company 3000
Enter the following information:
Create Purchase Order: Item Overview

Material DCC-##
Quantity 100
Deliv. Date Enter a future date
Plant 3000
Press [Enter].
© SAP AG CA210 6-16

2-1-2 Enter the output information by pressing the [Messages] button.
Create Purchase Order: Output

Output type NEU
Medium EDI
PartF VD
Partner V100##
Check the timing of the output by selecting the entry and press the [Further
Data] button.
Make sure the Dispatch time entry is Send immediately (when saving the
application).
Green arrow back once.
Press the Save icon.
___________________________________________________
© SAP AG CA210 6-17

Message Control and IDocs
Contents:
Message finding and message editing
Condition elements
Output time
 SAP AG 1999
© SAP AG CA210 7-1

Message Control and IDocs: Unit Objectives

Explain the various condition elements
Find an example in the MM customizing
View and edit the proposed message from within
the MM transaction
 SAP AG 1999
© SAP AG CA210 7-2

Message Control and IDocs: Course Overview
Diagram (1)

Inbound Invoice
10
Payment/Remittance
MM EDI Application
Mess
Message
age Cont
Control
rol &
& IDocs
IDocs 7 Documentation Tools 14
 SAP AG 1999
© SAP AG CA210 7-3

Message Control and IDocs: Course Overview
Diagram (2)
Working with an
EDI Subsystem 15
IDoc Monitoring 16
Archiving IDocs 17
Conclusion 19
 SAP AG 1999
© SAP AG CA210 7-4

Message Control and IDocs: Business Scenario
You are a member of the integration team of your

company SmartMart. As a member of the team you
Both companies run EDI subsystems.
An order by SmartMart is created as a message by
the module “message control” before it is
formatted as an IDoc. You know the presettings of
this module in the SAP standard but want to know
about further possibilities of message control, and
how it works in general.
 SAP AG 1999
© SAP AG CA210 7-5

Outbound processing and message control
SAP Application
Document
find
message control
edit
NAST process
record
 SAP AG 1999
Message control (NAST) creates messages from application documents. The possible messages are
created as condition records in the customizing.
From the set of possible messages, NAST searches those that fit to the actual application data. This
message finding can result in more than one, or possibly none. In the following, let us assume that
exactly one message was found.
If supported by the application, the found message is proposed for Editing in the very transaction
which started NAST. In the case of creating an MM purchase order, this means that the message can
be edited before saving the application document.
In any case, the message is created and processed (if not deleted in the editing process). For instance,
when the order is to be printed, the print format is determined, and the message is sent to the printer.
If the message is to be sent out as an IDoc, the corresponding processing program RSNASTED is
already part of the IDoc interface.
The new message creates a new entry in the table NAST. Part of this entry is the processing status
which can hold the following values: 0 = not yet processed, 1 = successfully processed, 2 =
processed with error.
Note: For better reading, the slide does not show the transfer of the IDoc to an external system;
however, this is also part of outbound processing.
© SAP AG CA210 7-6

Message Control
SAP application edit
application data
message finding
message proposal
NAST record
Processing Table
Table TNAPR
SPFLI
Table
Table RSNASTED
output, e.g. IDoc
TNAPR
IDoc
Program
RSNASTED
 SAP AG 1999
The process diagram shows again message finding, message editing and message processing.
NAST allows the setting of a processing time flag: This controls whether the message has to be sent
immediately after creating the application document, or at a later time. In the latter case, you must
run the report RSNAST00 as a batch job; otherwise, the message stays unprocessed.
The NAST table record points to a BOR (Business Object Repository) object which holds all
application data relevant for the message.
The table TNAPR holds the processing programs; in the case of EDI, the entry is the program
RSNASTED.
© SAP AG CA210 7-7

Condition Elements
SAP application
1:n
procedure
m:n
condition type
n:1
access sequence
m:n
access to table
 SAP AG 1999
Message finding uses the condition technique which is the same as used in the SD pricing: Messages
are searched according to a pre-defined sequence to save time and allow preferences. The condition
elements and their hierarchy define this sequence.
Messages are records of a condition table. Several condition tables can belong to a condition type.
The condition tables are accessible according to a pre-defined access sequence, and with different
key fields.
Several condition types can belong to a procedure; several procedures can belong to an application,
e.g. the application EF (purchasing).
If an application uses NAST to send an EDI message, only the procedures belonging to that
application are searched for messages, not all procedures present in the R/3 system.
With the condition element access sequence, you can control whether only one message is to be
found. To achieve this, you set the “exclusive” flag.
© SAP AG CA210 7-8

Procedures
Each MM and SD application is associated with an output

procedure.
An output procedure can be made up of multiple condition
types, therefore producing multiple output (i.e. EDI and
printed output).
“Requirement” entry can further restrict the proposing of
output - i.e. do not propose EDI dispatch advice until a
goods issue is performed.
Note: Requirement entry is also possible at access sequence
definition.
 SAP AG 1999
Procedures are found in the IMG in the MM or SD application area.

Transaction VOFM to reach the requirements menu then Requirements → Output control
© SAP AG CA210 7-9

Condition Types
Defines the output medium:

Printer; Fax; Telex; E-Mail (internal SAPoffice, external);
EDI; ALE; Workflow Event; Workflow Task
Special Event - ABAP call
Timing
Batch
Immediate
Partner Function
To whom output is directed (Ship-to, Sold-to, Billing Partner,
etc.)
How to handle Changed Output
 SAP AG 1999
Condition type configuration is also found in the MM or SD application area of the IMG.
© SAP AG CA210 7-10

Access Sequences
Determines if output is proposed by the R/3 MM or SD

application.
Output is determined at runtime, based on application data
Can be very general - i.e. propose printed output for all
purchase orders; or very specific - i.e. propose EDI output
of purchase orders only for a limited number of vendors.
 SAP AG 1999
Access sequences are client-independent. They are used to indicate the table number which holds the
condition records.
Access sequences are the matching keys between the conditions record and the application data.
© SAP AG CA210 7-11

Condition Records
Created from within the MM or SD application area

Created for each Condition Type/Access Sequence
combination as appropriate
Indicate to whom output is to be directed and the output
medium, output timing, and language
Searched during application document creation by
Message control logic to determine if output will be
proposed
 SAP AG 1999
Condition records are created from within the MM or SD application area not from the IMG.
© SAP AG CA210 7-12

Message Processing: EDI
Check NAST Record

TNAPR
R
Read Partner Profile S
N
Call Selection Module A
(by Application) S
T
Call ALE Services
E
Transfer according
D
to OUTMOD
'1'/ '2' '3'/ '4'
Single IDoc IDoc Batch via

RSEOUT00
 SAP AG 1999
The sending medium is part of the condition record which is pre-defined in the customizing. Sending
media for IDoc processing are:
6 EDI (without distribution model)
A ALE (with distribution model)
With these parameters, the program RSNAST00 starts the EDI message processing program
RSNASTED.
The output mode (field OUTMOD in the control record) "1" and "2" have the effect that single IDocs
are passed from RSNASTED.
With output mode “3" and “4", IDocs are not passed directly. Instead, they are collected by the
program RSEOUT00 in batch mode.
© SAP AG CA210 7-13

Outbound Timings
Application NAST IDoc Interface Subsystem
Save Prio = 4 OUTMOD = 1

Realtime

Fast batch

Batch

Batch
 SAP AG 1999
Note that there are two output times when using message control. One controlled by NAST, the other
by the IDoc interface. Each of these "times " can only be switched between now (immediate) and
some time later ( batch). The latter case means that the processing program must be started as a batch
job at a later time, the former case means that it is started immediately during processing.
Because there are two stop signs, one should reflect where to raise them. In many cases, it does not
make too much sense to raise both of them.
If an EDI subsystem is used with port type file, there is even a third stop sign: triggering or non-
triggering.
The right side of the slide shows the EDI terminology for the different timing combinations.
© SAP AG CA210 7-14

Message Control and IDocs: Unit Summary

Explain the various condition elements
Find an example in the MM customizing
View and edit the proposed message from within
the MM transaction
 SAP AG 1999
© SAP AG CA210 7-15

Exercises
Unit: Message Control and IDocs

Topic: Message Control Setup and Purchase Order

• Complete configuration to automatically propose EDI output for all
outbound messages

communicate Purchase Orders via EDI.
1-1 Create a condition record for the Purchase Order for your vendor trading partner
(V100##) using output type NEU and access Purch Org/Vendor for EDI.
1-2 Create another outbound purchase order for your vendor V100## for 100 cartons of
double chocolate chip cookies at 3.60 a carton. Record your Purchase Order
number.
____________________________________________________________
1-3 Use Monitoring tool, IDoc lists, to check if an outbound Purchase ORDERS IDoc
was created for your vendor.
____________________________________________________________
1-4 Create a condition record for the order acknowledgement for your customer trading
partner (300##) using output type BA01 and access Sales Organization/Customer
nbr.
1-5 Create a condition record for the advanced shipping notice for your customer
trading partner (300##) using output type LAVA and access Sales
Organization/Customer nbr.
1-6 What is the document type(s) used in the condition record(s) of output type RD00?
____________________________________________________________
© SAP AG CA210 7-16

Solutions
Unit: Message Control and IDocs

Topic: Message Control Setup and Purchase Order

MASTER DATA → MESSAGES → PURCHASE ORDER → CREATE
Create Output – Condition Records: Purchase Order

Output type NEU
1-1-2 Press the [Key combination] button and choose the access based on
Purch.Org./Vendor for EDI.
Create Condition Records [New]: Fast Entry

Purch. Organization 3000
Vendor V100##
PartF VD
Partner Leave blank or V100##
Medium 6
Timing 4
Language EN
© SAP AG CA210 7-17

PURCHASE ORDER → CREATE → VENDOR KNOWN/SUPPLYING
PLANT KNOWN

Vendor V100##
1-2-2 Press [Enter].

1-2-3 When the Org. Data screen appears enter the following information:

Purch. group 000
Company 3000

Material DCC-##
Quantity 100
Delv. Date Future date
Plant 3000

1-2-6 Check to see if Message control is proposing output.
1-2-7 If Message control is proposing EDI output, the purchase order must be
saved to generate an outbound purchase order
© SAP AG CA210 7-18

TOOLS → BUSINESS COMMUNICATION → IDOC → IDOC BASIS →
IDOC → IDOC LISTS
IDoc lists
Date Created Keep default
Time Created Keep default
Partner number V100##
1-3-2 Press the Execute icon.

1-3-3 Check to see if your IDoc was successfully passed to the port (status 03).
______________________________________________________

LOGISTICS → SALES AND DISTRIBUTION → MASTER DATA → OUTPUT
→ SALES DOCUMENT → CREATE

Create Output – Condition Records: Sales
Output type BA01
1-4-2 Press the [Key combination] button and choose the access based on Sales
Organization/Customer Number.

Create Condition Records [EDI Order Response]: Fast Entry
Customer 300##
PartF SP
Partner Leave blank or 300##
Medium 6
Timing 4
Language EN
© SAP AG CA210 7-19

1-4-5 Green arrow back to the SAP Easy Access menu.

LOGISTICS → SALES AND DISTRIBUTION → MASTER DATA →
OUTPUT → SHIPPING → CREATE
Create Output – Condition Records: Shipping

Output type LAVA
1-5-2 Press the [Key combination] button and choose the access based on Sales
Organization/Customer Number.
Create Condition Records [Outg.ship.notifica.]: Fast Entry

Customer 300##
PartF SH
Partner Leave blank or 300##
Medium 6
Timing 4
Language EN
© SAP AG CA210 7-20

LOGISTICS → SALES AND DISTRIBUTION → MASTER DATA →
OUTPUT → BILLING DOCUMENT → DISPLAY
Display Output – Condition Records: Billing

Output type RD00
1-6-2 Press [Key combination] button and choose access based on Billing type.
______________________________________________________
© SAP AG CA210 7-21

Workflow and IDocs
Contents:
Inbound processing
Exception handling
Notification concept
Units of organization
 SAP AG 1999
© SAP AG CA210 8-1

Workflow and IDocs: Unit Objectives

Explain how the responsible agent is notified when
an error occurs in the IDoc interface
Maintain the structure of the organization
 SAP AG 1999
© SAP AG CA210 8-2

Workflow and IDocs: Course Overview Diagram (1)
Workflow
Course Overview 1 and IDocs
8
Inbound Invoice
10
Payment/Remittance
MM EDI Application
Requirements

 SAP AG 1999
© SAP AG CA210 8-3

Workflow and IDocs: Course Overview Diagram (2)
Working with an
EDI Subsystem 15
IDoc Monitoring 16
Archiving IDocs 17
Conclusion 19
 SAP AG 1999
© SAP AG CA210 8-4

Workflow and IDocs: Business Scenario
As a member of the integration team of enterprise

NOE Food Company, you are responsible for
You receive an order of customer SmartMart as an
inbound IDoc of type ORDERS01. Your process
code points to direct inbound processing using an
ALE function module. Error handling proceeds via
workflow.
You must set-up the agents to be notified in case
of error.
 SAP AG 1999
© SAP AG CA210 8-5

Workflow in Inbound Processing
IDoc interface & ALE services
IDoc +
process Review
Workflow Edit IDocs
etc...
Document
SAP application
 SAP AG 1999
Inbound processing may use a workflow pointed at by an appropriate process code. This workflow
can be defined as needed. Examples are:
Review: First, an application document will be created from the inbound IDoc. Then, the document
will be posted to an agent for review.
Edit: First, the IDoc will be edited by an agent before the application document is created.
Forward: The inbound IDoc will be forwarded to other agents or kick off new outbound IDocs.
NOTE: For better reading, the slide does not display the IDoc inbound from an external system; yet,
this is part of inbound processing.
© SAP AG CA210 8-6

Workflow in Exception Handling
Check partner, Create IDoc
Create appl. Doc. Ok?
no
Ok? Error handling message

no
R/3-System
 SAP AG 1999
Exception handling is always defined as a workflow. One or more agents can be informed about the
error situation. The agents are defined in the IDoc interface and in the organization model (PD-ORG)
of your company.
SAP delivers only single-step tasks for error handling, both for inbound and outbound processing.
The slide only shows inbound error handling.
© SAP AG CA210 8-7

Outbound Data Flow w/ Notification Points
SAP application
Document
Message w/
EDIN NAST record
Message Control
EDIM Message
NAST
Record
IDoc w/
EDIX syntax error
IDoc Interface
EDIO IDoc
IDoc
EDIP IDoc batch
EDIS
EDI subsystem EDIR Status report
Customer
 SAP AG 1999
The single-step tasks are identified by system process codes.

The process code EDIM holds for both inbound and outbound processing. Here, no IDoc could be
created yet, so no direction is given.
The process code EDIO holds for outbound IDocs containing faulty application data.
The process code EDIX identifies IDoc format or syntax errors.
The process code EDIN (new with 4.6) creates a notification based on the message control record
(NAST record). This allows to branch for most document types into the appropriate application
transaction and reprocess the message from that point.
The process code EDIP (new with 4.5) creates only one single notification for all the IDocs facing
the same error in a single run of program RSEOUT00.
Notifications about status, which are reported by the EDI subsystem, can be created by process code
EDIS (notification only) or EDIR (notification with reprocessing) in standard. Customer specific
tasks can be assigned by defining customer specific process codes.
The process codes are assigned to the status values in the status table. By assigning any process code
to a status value, this value is defined as bad instead of good. Bad statuses trigger notifications.
© SAP AG CA210 8-8

Inbound Data Flow w/ Notification Points
TXTRAW IDoc message
EDI subsystem
EDIL Status Report
IDoc
EDIM Message
IDoc Interface EDII IDoc
IDoc with
EDIY syntax error
IDoc
IDoc without
SAP application Application application document
 SAP AG 1999
Inbound exception handling is like the outbound case. Errors arising when creating the application
document (e.g. by wrong input data) are sometimes handled by application-specific tasks and
identified by process codes.
The process code EDIL (new with 4.6) is used with error messages received via status reports but
there is no IDoc created.
The process code EDIM holds for both inbound and outbound processing. Here, no IDoc could be
created yet, so no direction is given.
The process code EDII holds for inbound IDocs containing error messages.
The process code EDIY identifies IDoc format or syntax errors.
Notifications from the EDI subsystem prior to IDoc creation can be received with logical message
TXTRAW implemented by IDoc type TXTRAW01 and TXTRAW02. The message can be directed
to any organizational unit as well as any SAP user account.
IDoc type TXTRAW01 takes the recipients from the related partner profile.
IDoc type TXTRAW02 is new with 4.6. The IDoc type allows you to determine the recipients as
well as the heading of the mail from the outside.
© SAP AG CA210 8-9

Notification Concept (1)
Organization
Organization structure
structure
Possible
Possible agents
agents
task
task
Role
Role resolution
resolution Selected agents
Partner
Partner profile
profile
Allowed
Allowed agents
agents
IDoc
IDoc interface
interface
 SAP AG 1999
The agents found in the IDoc interface are only the allowed agents of a workflow task. Attached to
the task itself is the set of possible agents. The role resolution determines the set of agents which are
both allowed and possible. These agents are called the actual agents.
All actual agents get the work item (as the instance of the workflow task) into their integrated inbox.
The function module for the role resolution is called EDI_ROLE_FOR_PROCESSING. For
instance, it takes partner and message from the partner profile as role parameters to get the set of
allowed agents.
The corresponding IDocs can only be further processed starting from the integrated inbox.
Note: If the tasks are defined as general tasks, all agents are possible agents, and the set of actual
agents equals the set of allowed agents.
© SAP AG CA210 8-10

Specific for Specific for Valid for all

partner partner, partners
and message but for all and messages
messages
Inbound/
Inbound/ General
General General
General settings
settings
Outbound (IDoc Allowed
Allowed agents
agents
Outbound (IDoc Administration)
Administration)
 SAP AG 1999
Allowed agents are maintained in the following parts of the partner profile: inbound and outbound
(optional), and general (required). When an error occurs (e.g. a syntax error), the most specific
allowed agent is determined. The search starts in the inbound or outbound entries, since agents
specific for partner and message can be defined here.
If no agent could be found in the inbound/outbound entries (either because there was none, or
because there was no partner profile for the actual partner/message combination), the general partner
profile is searched for an agent specific to the actual partner.
If the search fails again (because there was no partner profile for the actual partner), search continues
in the IDoc administration (field: EDIADMIN). Since this field is only optional, it may happen that
no one is notified.
Therefore, it's always a good idea to enter an allowed agent in the IDoc administration.
In all cases, the agent can be a single person (type US = user) or a whole group which must exist in
the PD-ORG model, either as a position, job, or an organizational unit.
© SAP AG CA210 8-11

Organization
Organization structure
structure Possible
Possible agents
agents
Org.Unit
Job
Position
 SAP AG 1999
Workflow auto-customizing (transaction SWU3) characterizes all tasks relating to the IDoc interface
as general tasks, i.e. all R/3 system users are possible agents. One can reduce this set using an
organization structure.
The organization structure defines a hierarchy of responsibilities. For instance, one could have a
general organization unit “administrators” comprising as sub-unit the job “IDoc administrator”. This
job can contain several positions held by an equal number of human beings. One could enter the job
(not individuals) as an allowed agent in the IDoc interface.
It is also possible to enter a position (not the individual holding it) as “allowed agent”. The
advantage is that notifications are tied to responsibilities, not to individuals whose responsibilities
can change. This concept can be compared to the process code and the process behind it.
© SAP AG CA210 8-12

Objects of Organization Management
Cost center
assignment
Cost center
Organizational unit
includes ...
describes ... belongs to ...
Work center
Job Position(s)
specifically
describes ... Owner User
describes ...
Task
 SAP AG 1999
Elements of the organization structure which can be entered as possible agents of a standard task are:
organization unit
job
position
Further elements are work center and cost center
Organizational units are organizational areas of a company that are grouped together in a logical
manner
Examples: “department”, “team”, “group”
Jobs are areas of activity in a company described by tasks. Jobs are usually defined for all
organizational units.
Examples: “Administrative Assistant”, “Administrator”, “Accounting Clerk”
Positions are derived from each job. Each position is usually filled by one or more employee / user.
Examples: “SD Administrative Assistant”, “General Administrative Assistant”
Work center is the physical location where an employee performs his/her tasks at the company.
Cost center is an accounting element that may be tied to an organizational unit.
© SAP AG CA210 8-13

Maintain Structure of Organization
Customizing activity
Entrance from workflow menu
 SAP AG 1999
An element of the organization structure must be defined. Second, R/3 system users must be
assigned to elements.
Both can be done in the customizing or from the workflow definition menu (transaction PPOM).
© SAP AG CA210 8-14

Maintaining an Organizational Structure
Define the organizational units

Staffing schedule
Define jobs Supervisor
Derive and define positions from job Staff Staff Staff

Assign owner to positions
Define supervisory position (supervisor link)
 SAP AG 1999
Maintaining the organizational structure: transaction PPOM

Defining organizational units (F9):
The organizational units are arranged hierarchically (link: “reports to”)
After selecting the organizational unit: staffing schedule
Staffing schedule: define jobs
Enter a verbal job description
Staffing schedule: define positions
Derive positions from existing jobs (link: “is described by”).
The positions are automatically linked with the selected organizational unit (link: “belongs to”)
Staffing schedule: assign owners
Assign a user (US) to a position (link: “owner”)
Staffing schedule: supervisory position
Identify a position as manager of the organizational unit (link: “manages”)
© SAP AG CA210 8-15

Organizational Structure and Workflow
What is involved?
Defining who is responsible for processing a task:
Fixed assignment of a task to an employee
The task “Orders Inbound Error” is performed by
Judy Jones, Mark Miller, and Sam Smith
Flexible assignment of tasks, based on the jobs or
organizational units (groups, projects)
The task “Invoice Inbound Error” is performed by the
employees whose activity profile is described by the job
“Department manager”.
Customizing activity during product implementation
 SAP AG 1999
SAP Business Workflow integrates a component of organization management

(PD - Personnel Planning and Development)
This component, like the workflow system itself, is provided with the Basis component of the R/3
System.
© SAP AG CA210 8-16

Integrated Inbox
Workflow Inbox
Work item Edit Goto Extras Settings Folders System Help
Number of entries 5
ST EU Description AT Rec. on
Material CSS-99 not defined in sales 19.02.1998
EDI/ALE error message 19.02.1998
Inbound partner profile not available 19.02.1998
Order part number # p-3539 19.02.1998
Review Customer Order #7654 19.02.1998
Review Customer Order # 7789 19.02.1998
 SAP AG 1999
The integrated inbox can be accessed directly via transaction SO01. Actual agents find here the
workitem, i.e. the concrete instances of the single step tasks.
Workitems can be edited by one agent. As a consequence, it vanishes from the integrated inbox of all
other actual agents.
© SAP AG CA210 8-17

Processing from Integrated Inbox
Process from application document

Foreground
Foreground from error
Background
Edit IDoc then process
Foreground
Foreground from error
Background
 SAP AG 1999
Workitems may be processed in several ways:

Foreground - walks through the application screen by screen by pressing [ENTER] until the screen
which contains the error is reached. Once the error is fixed, the user must continue to [ENTER]
until the system decides it is ready to save the application document.
Foreground from where the error occurred - processes the screens in background until the screen
with the error is encountered. Once the error is fixed, the user must press [ENTER] once more and
the screens will be processed in background until another error is encountered or the system
decides it is ready to save the application document.
Background - generally used when the error is due to a configuration problem which when fixed
will allow the IDoc to process correctly
Edit the IDoc data records to fix the erroneous data and then choose one of the above processing
modes.
© SAP AG CA210 8-18

Workflow and IDocs: Unit Summary

Explain how the responsible agent is notified when
an error occurs in the IDoc interface
 SAP AG 1999
© SAP AG CA210 8-19

Workflow and IDocs: Unit Summary
Explain how the responsible agent is notified

when an error occurs in the IDoc interface
 SAP AG 1999
© SAP AG CA210 8-20

Exercises
Unit: Workflow and IDocs

Topic: Staff Assignment in PD-ORG

• Assign personnel for error notification
The business has determined that when IDocs are processed and errors
occur, automatic error notification is to take place.
1-1 Link your user id to the your appropriate position in the Organization Structure
IDOC_NOTIF.
© SAP AG CA210 8-21

Exercises

Topic: Error Reprocessing Preparation

• Ensure that the system is set up so that errors will occur
A new inbound message will be created. However, we will remove some

configuration so that the incoming message will fail a couple of ways –
first with a technical error and then with an application error.
2-1 Delete the inbound parameters for Orders from your customer partner profile. This
will cause an EDI technical error.
2-2 Change your Purchasing Material Info record for your vendor (V100##) and
material (DCC-##) by placing an ‘X’ behind the vendor’s material CCS-##. This
will cause an application error.
© SAP AG CA210 8-22

Exercises

Topic: Error Reprocessing Creation

• Create a technical error
By eliminating the partner profile in the previous exercise, when an order

comes into SAP for your customer, it will error with a technical error
since the IDoc will not be able to find the inbound partner profile entry.
3-1 Create another purchase order for your vendor.

______________________________________________________
3-2 The purpose of this portion of the exercise is to simulate inbound processing. Since
there is no actual EDI subsystem, it is necessary to find a source of inbound data.
This is accomplished by using a test utility that changes the direction and other key
fields in the control record of an outbound IDoc, converting it into an inbound
IDoc.
3-2-1 Change the sender information to your customer number, partner type KU,
and partner function SP for the logical message ORDERS.
3-3 Use Monitoring tool, IDoc lists, to check on the status of the inbound sales order.
© SAP AG CA210 8-23

Exercises

Topic: Error Reprocessing

• Fix the technical error by reprocessing the IDoc from within the
Workflow inbox
• Fix the application error by editing the IDoc and reprocessing it
• Recreate the configuration deleted in the previous exercise
IDocs that have errors can be processed by personnel that have been
notified. The EDI department members would handle technical errors
and application personnel would handle errors from the application.
4-1 Check your integrated inbox to see if there are any messages that can be processed.
4-1-1 Select an item to process.
4-2 Return to the inbox, refresh and select the message to process.
4-3 Use the Monitoring tool, IDoc lists, to determine the sales order number.
4-3-1 Record the Sales Order number.
______________________________________________________
© SAP AG CA210 8-24

Solutions

Topic: Staff Assignment in PD-ORG

TOOLS → SAP BUSINESS WORKFLOW → ORGANIZATIONAL PLAN→
ORGANIZATIONAL PLAN → ORGANIZATION AND STAFFING →
CHANGE → SETTINGS → MAINTENANCE INTERFACE
Organization Plan / Change

Organizational unit IDOC_NOTIF
Overall view X
1-1-2 Press the Change icon.

1-1-3 Double click on IDOC_NOTIF
1-1-4 Click on the appropriate position STUDENT_GROUP##.
1-1-5 Press the [Assign holder] button.
1-1-6 Enter your login user name.
1-1-7 Green arrow out of the transaction.
© SAP AG CA210 8-25

Solutions
Unit: Workflow and Idocs

Topic: Error Reprocessing Preparation
2-1 From the SAP Easy Access Menu

IDOC → PARTNER PROFILE
Open folder Partner type KU.
2-1-1 Select the appropriate partner number for your group.
Partner Profiles: Initial Screen

Partner Number 300##
2-1-2 Press the Change icon.

2-1-3 Select the ORDERS message type entry in the Inbound parameters section.
2-1-4 Press Delete icon.
2-1-6 Green arrow back to the SAP Easy Access Menu.

LOGISTICS → MATERIALS MANAGEMENT → PURCHASING
MASTER DATA → INFO RECORD → CHANGE

Change Purchasing Info Record: Initial Screen
Vendor V100##
Material DCC-##
Plant 3000
2-2-2 Press Enter.
© SAP AG CA210 8-26

Change Purchasing Info Record: General Data

Vendor mat. No. Add an ‘X’ to the end of your material
number to make it invalid

© SAP AG CA210 8-27

Solutions

Topic: Error Reprocessing Creation

KNOWN

Vendor V100##

3-1-3 When the Org. Data screen appears enter the following information:

Purch. group 000
Company 3000

Material DCC-##
Quantity 100
Plant 3000

© SAP AG CA210 8-28
3-1-6 Press Save icon and record the Purchas Order number.
_______________________________________________

TEST → INBOUND PROCG OF MODIFIED OUTB. FILE
3-2-1 Change the sender information to your customer number, partner type KU,
and partner function SP for the logical message ORDERS.
Modification of Outbound File Triggering Inbound Processing

Sender Partner number 300##
Sender Partner type KU
Sender Partn.function SP
Message Type ORDERS
Sender Port File port created in Port Definition unit
exercise
3-2-1-2 Press the Execute icon.
The message ‘IDoc file copied and transferred to inbound processing'

should appear at the bottom of your screen on the message line or as a
pop-up box.
© SAP AG CA210 8-29

IDOC → IDOC LISTS
IDoc lists
Partner number 300##

3-3-3 Double-click on the inbound IDoc number.
3-3-4 Record the status of your inbound IDoc found in the status message.
___________________________________________________
© SAP AG CA210 8-30

Solutions

Topic: Error Reprocessing

OFFICE → WORKPLACE → INBOX
Double –click “WORKFLOW”
4-1-1 Select the EDI item and press the Execute icon.
4-1-2 When the status record appears
4-1-2-1 Select from the menu bar Status record → Error text.
4-1-2-2 Scroll down until find red [execute function] and single click
4-1-2-3 Reenter the inbound parameters for the customer.
4-1-2-3-1 Open folder Partner type KU.
4-1-2-3-2 Select the appropriate partner number for your group.

4-1-2-3-3 From the Partner Profile screen: Press [Create Inbound

parameter] button.
4-1-2-3-4 Enter the following information:

Partner Function SP
Message Type ORDERS
4-1-2-3-5 For Inbound options enter the following information.
Maintenance of inbound options

Process Code ORDE
© SAP AG CA210 8-31

4-1-2-3-6 Select the Post processing: permitted agent tab.
4-1-2-3-7 Enter the following information:

Typ S
partner profile
Lang. EN
4-1-2-3-8 Press Save icon.

4-1-2-3-9 Green arrow back two times.
4-1-2-4 Return from the text and press the [Process] button.
4-2 Return to the inbox, refresh, select the message and press the Execute icon.
GOTO → IDOC DISPLAY
Open Data records folder.

4-2-1 Expand the E1EDP01 segment to view the child segments.
4-2-2 Choose the E1EDP19 002 segment by double clicking on the change icon.
DATA RECORD → DISPLAY -> CHANGE
Edit Data Record

QUALF 002
IDTNR CCS-##

4-2-5 Green arrow back three times.
4-2-6 Return to the status record display screen and press [Process] button.
4-2-7 Refresh the screen and note that the work item has disappeared.

IDOC → IDOC LISTS
© SAP AG CA210 8-32

IDoc lists

4-3-4 Record the sales order number found in the status message.
_______________________________________________
© SAP AG CA210 8-33

SD EDI Application Requirements
Contents:
z SD Application Requirements
z Booking a Sales Order
 SAP AG 1999
© SAP AG CA210 9-1

SD EDI Application Requirements: Unit Objectives

z Receive a Sales Order as an inbound IDoc
z Describe what EDI-specific master data has to be
set up
 SAP AG 1999
© SAP AG CA210 9-2

SD EDI Application Requirements: Course

Inbound Invoice
10
Payment/Remittance
MM EDI Application
 SAP AG 1999
© SAP AG CA210 9-3

SD EDI Application Requirements: Course
Working with an
EDI Subsystem 15
IDoc Monitoring 16
Archiving IDocs 17
Conclusion 19
 SAP AG 1999
© SAP AG CA210 9-4

SD EDI Application Requirements: Business
Scenario
z As a member of the integration team of your

company (SmartMart or NOE Food Company) you
z Both companies run EDI Subsystems.
z Ports and the partner profile have already been set
up, now you want to send test IDocs.
z To send test IDocs, you must set-up your own
relevant application.
 SAP AG 1999
© SAP AG CA210 9-5

SD Application Requirements EDI (1)
z SD Customer Master Records

Correspondence view
Account at customer
Sales view
Account at customer
z SD Info Records
Customer Material Info Records
 SAP AG 1999
© SAP AG CA210 9-6

SD Application Requirements EDI (2)
z SD Configuration EDI
Partner Conversion
Partner Functions
Customer/Supplier Assignments
Handle messages for Inbound Orders
Convert SAP Item Category to IDoc Item Category
z SD/EDI Pricing
EDI Pricing Condition Types
Maintain Pricing Procedure
 SAP AG 1999
© SAP AG CA210 9-7

EDI-specific master data, module SD
Control record
Customer master data:
sender Partner number, type, role
Data record Customer master data:

E1EDKA1: partner
Own account at
information
customer’s side
Data record
E1EDP19: Customer material info:
Material number customer’s material name
Customizing SD:
assignment customer/
vendor to sales organization
IDoc
IDoc Type
Type ORDERS01
ORDERS01
 SAP AG 1999
© SAP AG CA210 9-8

Sales Order on NOE Food Company’s side
External
External System
System == NOE
NOE Food
Food Company’s
Company’s EDI
EDI subsystem
subsystem
Transfer data to R/3 system
Find process for Smartmart’s IDoc, Create IDoc
Book sales order Ok?
no
Ok? Create workitem

no
R/3-System
R/3-System
 SAP AG 1999
© SAP AG CA210 9-9

SD EDI Application Requirements: Unit Summary

z Receive a Sales Order as an inbound IDoc
z Describe what EDI-specific master data has to be
set up
 SAP AG 1999
© SAP AG CA210 9-10

Exercises
Unit: SD EDI Application Requirements


• Add the entries in the customer master data for EDI processing
• Create the customer material information record
The customer master data contains fields owned by the EDI process to
populate a segment in the IDoc. Additionally, cross reference records can
be set up to identify your customer's material with your material.
1-1 Maintain an account at customer in the customer master using your customer 300##
and the account at customer V100##.
1-2 Maintain the customer material info record for your material CCS-## and the
customer's material DCC-##.
1-3 Change your Purchasing Material Information record (DCC-##) for your vendor
(V100##) by removing the ‘X’ from the vendor’s material number (CCS-##).
© SAP AG CA210 9-11

Exercises
Unit: MM/SD EDI Application Requirements

Topic: Purchase Order to Sales Order with
Acknowledgments Chain
• Create the business application documents and IDocs necessary to
simulate a business cycle.

communicate Purchase Orders and Sales Orders and Acknowledgements
via EDI.
1-1 Create a Purchase Order using the same data as in the first create outbound
purchase order exercise.
______________________________________________________
1-2 Use the turnaround test tool to bring in your sales order.
1-3 Use Monitoring tool, IDoc lists, to determine the Sales Order number.
______________________________________________________
1-4 From the sales order change screen determine the IDoc number that is linked to the
sales order business object for the outgoing order response.
1-4-1 Record the IDoc number.

______________________________________________________
1-4-2 Use the testing transaction which will send the output from the IDoc
interface layer to the operating system file.
1-5 Use the turnaround test tool to bring in your sales order acknowledgement and
update your Purchase Order.
1-6 Display the purchase order that was acknowledged with the turnaround utility.
1-6-1 Record the acknowledgement number (sales order number).
______________________________________________________
© SAP AG CA210 9-12

Exercises

Topic: Advanced Ship Notice Chain

• Create the business application documents and IDocs necessary to
simulate the advanced ship notice cycle.

communicate Advanced Ship Notices via EDI.
2-1 Create a Delivery note for the sales order created in the last exercise using the
collective delivery note process.
2-1-1 Record the Delivery note number.
______________________________________________________
2-1-2 Once the delivery note has been created, create the warehouse transfer order
using warehouse number 300.
2-2 Use the turnaround test tool to bring in your Advanced ship notice.
2-3 Use Monitoring tool, IDoc lists, to determine if your Advanced ship notice
processed
© SAP AG CA210 9-13

Exercises

Topic: Outbound Invoice Process

• Create the business application document and IDoc necessary to
simulate the outbound invoice.

communicate Invoices via EDI.
3-1 Create the Invoice for the delivery note from the previous exercise.
3-1-1 Record the Invoice number.
______________________________________________________
© SAP AG CA210 9-14

Solutions


LOGISTICS → SALES AND DISTRIBUTION → MASTER DATA
BUSINESS PARTNERS → CUSTOMER → CHANGE → COMPLETE
Customer Change: Initial Screen

Customer 300##
Company code 3000
Sales organization 3000
Distribution channel 10
Division 00
1-1-2 Select the [Company Code] button and then select the Correspondence tab
and enter the following information:
Customer Change: Correspondence

Acct at cust. Your vendor number V100##
1-1-3 Select the [Sales area data] button and then select the Orders tab and enter
the following information:
Customer Change: Sales Sales Area

Acct at cust. Your vendor number V100##
© SAP AG CA210 9-15


LOGISTICS → SALES AND DISTRIBUTION → MASTER DATA
AGREEMENTS → CUSTOMER-MATERIAL INFORMATION → CREATE

Create Customer-Material Info Record
Customer 300##
1-2-2 Press Enter.

Create Customer-Material Info Record: Overview Screen
Material no. CCS-##
Cust. Material DCC-##


MASTER DATA → INFO RECORD → CHANGE

Change Purchasing Info Record: Initial Screen
Vendor V100##
Material DCC-##
Plant 3000
© SAP AG CA210 9-16

1-3-2 Press Enter.
Change Purchasing Info Record: General Data
Vendor mat. No. Remove the ‘X’ that you placed on the
vendor’s material number

© SAP AG CA210 9-17

Solutions

Topic: Purchase Order to Sales Order with
Acknowledgments Chain

KNOWN
Vendor V100##
Press [Enter].
When the Org. Data screen appears enter the following information:
Purch. Group 000
Company 3000

Material DCC-##
Quantity 100
Plant 3000
Press [Enter].
Record the Purchase Order number.
______________________________________________________
© SAP AG CA210 9-18

TEST → INBOUND PROCG. OF MODIFIED OUTB. FILE

Sender Partner number 300##
Sender Partner type KU
Sender Partner function SP
Message type ORDERS
exercise
Press the Execute icon.

pop-up box.

IDOC → IDOC LISTS
IDoc lists
Date created Keep default
Time created Keep default

___________________________________________________
© SAP AG CA210 9-19

LOGISTICS → SALE AND DISTRIBUTION → SALES
ORDER → CHANGE
1-4-1 Press [Enter]. Then use menu path:

SYSTEM → LINKS
1-4-2 Record the IDoc number for the ORDRSP.

___________________________________________________
1-4-3 From the SAP Easy Access menu, open folders
TOOLS → BUSINESS COMMUNICATION → IDOC → IDOC BASIS
→ TEST → OUTBOUND PROCESSING FROM IDOC
Enter your IDoc number.


TEST → INBOUND PROCG. OF MODIFIED OUTB. FILE

Sender Partner number V100##
Sender Partner type LI
Sender Partner function VD
Message type ORDRSP
exercise

pop-up box.
© SAP AG CA210 9-20

1-6 Display the purchase order that was acknowledged with the turnaround utility.

PURCHASE ORDER → DISPLAY
1-6-1 Press the [Item Details] button and view the vendor's Sales order number in
the Acknowl.no field.
1-6-2 Record the acknowledgement number (sales order number).
___________________________________________________
© SAP AG CA210 9-21

Solutions

Topic: Advanced Ship Notice Chain

LOGISTICS → SALES AND DISTRIBUTION → SHIPPING AND
TRANSPORTATION → OUTBOUND DELIVERY → CREATE →
COLLECTIVE PROCESSING OF DOCUMENTS DUE FOR DELIVERY →
SALES ORDERS
Sales order, fast entry

Shipping point/receiving pt 3000
Deliv.creation date Current date
To Original requested delivery date from
Purchase Order from the previous
exercise
Ship-to party 300##
Division 00

2-1-1-2 When you are presented with the Activities Due for Shipping
“Sales orders, fast display” list select the entry for your last sales
order.
2-1-1-3 Select the [Create Background] button.
2-1-1-4 When you see the message at the bottom of the screen “See log
for information about creating deliveries” use menu path GOTO
Æ CREATE DELIVERY LOG. You should see on the next
screen: Created deliveries 1 Number of notes 0 and some
additional information about weight, volumn and Lab. Required
in days.
© SAP AG CA210 9-22

2-1-1-5 Highlight the number under the Group column by single clidk.
Using menu path GOTO Æ DOCUMENTS you can determine
the delivery doucment created.
2-1-1-6 Record the Delivery document number.
___________________________________________________
2-1-1-7 Green arrow back four times to the SAP Easy access menu.
2-1-2 Once the delivery note document has been created, create the warehouse
transfer order using warehouse number 300.

LOGISTICS → SALES AND DISTRIBUTION → SHIPPING AND
TRANSPORTATION → PICKING→ CREATE TRANSFER ORDER
→ SINGLE DOCUMENT
Create Transfer Order for Delivery Note: Initial Screen

Whse number 300
Plant 3000
Delivery Delivery note number created above
Foreground/background Background
Adopt pick.quantity 2
2-1-2-2 Press [Enter].

2-1-2-3 You should receive a message at the bottom of the screen
indicating that the transfer order <transfer order number> has
been created.
2-1-2-4 Green arrow back to the SAP Easy Access menu.
2-2 Use the turnaround test tool to bring in your Advanced ship notice.
TEST → INBOUND PROC. OF MODIFIED OUTBOUND FILE
© SAP AG CA210 9-23


Sender Partner number V100##
Message Type DESADV
exercise

pop-up box.
2-3 Use Monitoring tool, IDoc lists, to determine if your Advanced ship notice
processed successfully.

IDOC → IDOC LISTS

IDoc lists

2-3-4 Record the Advanced ship notice document number found in the status
message.
___________________________________________________
© SAP AG CA210 9-24

Solutions

Topic: Outbound Invoice Process

LOGISTICS → SALES AND DISTRIBUTION → BILLING
BILLING DOCUMENT → CREATE
Create Billing
Field Name or Data Type Values
Delivery note number Delivery note created in previous
exercise
3-1-2 Press the [Execute] button.

3-1-4 Record the Invoice number.
___________________________________________________
© SAP AG CA210 9-25

Inbound Invoice Processing
Contents:
Logistics Invoice Verification
Configuration for inbound invoice processing
MM vs FI invoice configuration
Inter-company billing
 SAP AG 1999
© SAP AG CA210 10-1

Inbound Invoice Processing: Unit Objectives

Configure the system for inbound invoice
processing
Explain which configuration items are used with
MM inbound invoices
Explain which configuration items are used with FI
inbound invoices
 SAP AG 1999
© SAP AG CA210 10-2

Inbound Invoice Processing: Course Overview
Diagram (1)
Introduction 1 Workflow and IDocs 8

Inbound
Inbound Invoice
Invoice
Processing 10
Payment/Remittance
MM EDI Application

 SAP AG 1999
© SAP AG CA210 10-3

Inbound Invoice Processing: Course Overview
Diagram (2)
Working with an
EDI Subsystem 15
IDoc Monitoring 16
Archiving IDocs 17
Conclusion 19
 SAP AG 1999
© SAP AG CA210 10-4

Logistics Invoice Verification
Replaces conventional MM invoice processing

New process code for EDI PO related invoices - INVL
Benefits of LIV over convention invoice processing
creates an invoice and an accounting document
only 2 screens of data to process vs 4 screens
can be used with blanket POs
creates invoices in batch in background
used with inter-company invoice processing
 SAP AG 1999
There are currently three flavors of inbound invoice processing - Purchase Order related invoices
which come in two flavors - conventional MM invoice processing and Logistics Invoice
Verification; and non-PO related or financial invoices.
For PO related invoices Logistics Invoice Verification (LIV) is now the recommended methodology
for EDI. The process code for LIV is INVL and executes function module
IDOC_INPUT_INVOIC_MRM found in function group MRMH. Conventional MM invoice
processing may still be used and the process code is INVM which executes function module
IDOC_INPUT_INVOIC_MM found in function group IEDI.
Financial invoices utilize the process code INVF and function module IDOC_INPUT_INVOIC_FI
which is also found in function group IEDI.
© SAP AG CA210 10-5

Inbound Invoice Configuration
Company Code Assignment

General Ledger Accounts
Additional Account Assignments
Conversion of External Tax Codes
Invoice Program Parameters
 SAP AG 1999
Comp. Code Name in the Invoice - The name of the company code in the invoice must correspond to
the name for out company transferred by the EDI partner. EDI incoming processing needs this name
to be able to uniquely determine the company code to which the invoice is to be posted. It is pulled
from the IDoc partner segment (E1EDKA1) with a partner role of ‘RE' (bill-to), field NAME1.
The material/service number corresponds to the name transferred by the EDI partner for produced
goods and services or supplied goods. The G/L account to be posted to is determined via this name.
The entry can be made generically using the character ‘*'; first an entry with the precise name is
searched for, then if no exact entry exists, a search with the generic argument is carried out.
For the surcharge/discount postings for header conditions, the table is accessed with value ‘+'
(surcharge) or ‘-' (discount).
Additional account assignment table includes business area, cost center, controlling area, asset
numbers, order number, project number, network number, plant, profit center and business segment.
It can also be searched generically or a specific search based on data from the IDoc.
Conversion of tax codes from an external format (as received in an EDI message) to an internal
format (as defined with the R/3 system).
Conversion of tax code is based on the tax type and rate field combination compared to data from the
IDoc.
Configuration of the EDI program parameters, determines the program switches and default G/L
posting keys, clearing accounts, and default vendor posting keys.
© SAP AG CA210 10-6

MM vs FI Inbound Invoice Configuration
MM : FI :
Purchase Order Based No Purchase Order
Accounting Assignments General Ledger Account
contained in Purchase Order
Additional Account
Company Code Assignment Assignments
External Tax Codes Company Code Assignment
Program Parameters External Tax Codes
MM in Partner Profile Program Parameters
Message Code field
FI in Partner Profile Message
Code field
 SAP AG 1999
There is less configuration for MM (PO related) inbound invoices because the accounting
information (General Ledger account and Special Ledger accounting) is contained within the
Purchase Order.
The inbound invoice makes use of the message function field on the partner profile. This helps the
inbound invoice function module distinguish between PO related (MM) and non-PO related (FI)
invoices.
© SAP AG CA210 10-7

Inter - company Billing Configuration
Also known as “Forward Inbound”

Configuration includes:
Logical address which consists of:
Sending company code
Sending customer number
Destination consists of:
Receiving company code
Receiving vendor number
Partner Profiles
Outbound invoice for customer
Inbound invoice from vendor
 SAP AG 1999
Inter-company billing is usually based on a transfer of product from one company code to another
within the corporate umbrella.
When the transfer of product has occurred the selling (sending) company invoices the buying
(receiving) company.
The transaction is accomplished by the creating an invoice in the SD application of one company
code and forwarding it to the MM or FI application of the other company code.
The configuration for the IDoc process consists of creating logical addresses for the selling (sending)
company code concatenated with the customer number of the buying (receiving) company. The
destination in the details screen consists of the buying(receiving) company code concatenated with
the vendor number of the selling (sending) company. The application area is V3 which indicates
Sales and Distribution invoice processing.
Partner profiles are created for both sides of the transaction. The outbound partner profile outbound
options of partner function BP, logical message of INVOIC, message code of MM or FI depending
on whether there is a purchase order associated with the transfer of product, appropriate port, transfer
immediate, basic type of INVOIC01 or INVOIC02, transfer immediately and don’t start the
subsystem. Message Control parameters of logical message type of INVOIC, message code of MM
or FI (must be the same as on the outbound options), process code of SD08. The inbound partner
profile consists of no partner function, message type INVOIC, message code of MM or FI (must
match what was entered in the outbound, processes code of INVL (if MM) or INVF (if FI), trigger
immediately
© SAP AG CA210 10-8

Inbound Invoice Processing: Unit Summary

Configure the system for inbound invoice
processing
MM inbound invoices
FI inbound invoices
 SAP AG 1999
© SAP AG CA210 10-9

Exercises
Unit: Inbound Invoice Processing

Topic: Inbound Invoice Configuration

Complete the partner profile for inbound invoice processing
Post an inbound invoice against the Purchase Order

communicate Invoices via EDI.
1-1 Create the inbound parameters vendor partner profile entry for inbound Invoice
using message type INVOIC, message code MM, partner function VD, process
code INVM, and immediate processing.
1-2 Use the turnaround test utility to bring the inbound invoice into the system and post.
1-3 Use Monitoring tool, IDoc lists, to determine the Invoice number.
________________________________________________________________
© SAP AG CA210 10-10

Solutions
Unit: Inbound Invoice Processing

Topic: Inbound Invoice Configuration

Double-click “Partner Profile”.
Open folder Partner type LI
1-1-1 Select the appropriate partner number for your group
Partner Profile: Initial Screen

1-1-2 From the Partner Profile screen: Press [Create Inbound parameter] button.

Partn. Funct. VD
Message Type INVOIC
Message Code MM

Process Code INVM

TEST → INBOUND PROC. OF MODIFIED OUTBOUND FILE
© SAP AG CA210 10-11


Sender Partner V100##
Message type INVOIC
Variant MM
exercise

pop-up box.

IDOC → IDOC LISTS
1-3-2
IDoc lists

1-3-4 Record the Invoice document number found in the status message.
___________________________________________________
© SAP AG CA210 10-12

Payment/Remittance Process
Contents:
Outbound Payment/Remittance Advice Configuration
Payment Program Processing
Inbound Lockbox Configuration/Processing
Inbound Bank Statement/Account
Configuration/Processing
Inbound Remittance Advice Configuration/Processing
 SAP AG 1999
© SAP AG CA210 11-1

Payment/Remittance Process: Unit Objectives

Describe the configuration necessary to configure
the outbound payment/remittance advice
List the steps involved in running the payment
program
Describe the configuration and processing of the
inbound lockbox
Explain the configuration and processing for the
inbound remittance advice
Describe the configuration and processing of the
inbound bank statement
 SAP AG 1999
© SAP AG CA210 11-2

Payment/Remittance Process: Course Overview
Diagram (1)

Inbound Invoice
10
Payment/Remittance
Port Definitions 4 Process
11
MM EDI Application

 SAP AG 1999
© SAP AG CA210 11-3

Payment/Remittance Process: Course Overview
Diagram (2)
Working with an
EDI Subsystem 15
IDoc Monitoring 16
Archiving IDocs 17
Conclusion 19
 SAP AG 1999
© SAP AG CA210 11-4

Payment Remit. Process: Business Scenario

company SmartMart, you are responsible for
Both companies run EDI subsystems.
An invoice from NOE Food Company has been
created in the system and is now ready for
payment. The payment is to be sent to your bank
and the admittance advice is to be sent to the
NOE Food Company.
Both documents will be sent via EDI.
 SAP AG 1999
© SAP AG CA210 11-5

The ‘financial cycle’ using EDI messages
Customer
Customer Payment order Bank
Bank
Payer
Payer
Debit advice
El. bank statement
Remit.
Remit. Advice
Advice Bank
Bank transfer
transfer
Check
Invoice
Invoice
Direct Debit Bank

Bank // Lockbox
Lockbox
Vendor
Vendor
provider
provider
Credit
Credit Advice
Advice
Payee
Payee
(Beneficiary)
(Beneficiary)
El.
El. bank
bank statement
statement
Lockbox
Lockbox Info
Info
 SAP AG 1999
The SAP EDI invoice and payment cycle could alternatively handle the sending of the invoice from
the vendor to the customer.
The customer runs the payment program to created payment orders and remittance advices. The
remittance advices are sent directly to the vendor(s). The payment orders are sent to the bank.
The bank then notifies the customer of debit advices (the removal of money from the customer's
account) and notifies the vendor of credit advices (the receipt of money in the vendor's account).
Once the payment notification is received from the bank, the vendor will apply the payment to the
open invoices by checking the remittance database to see if remittance advice information has also
been received from the customer to indicate which invoices and invoice line items are to be closed.
© SAP AG CA210 11-6

EDI messages in FI
Invoice INVOIC02/INVOIC
SAP-
Credit Advice PEXR2002/CREADV
Debit Advice PEXR2002/DEBADV Accounting

System
Advices
Remittance Adv PEXR2002/REMADV
Account Stmt FINSTA01/FINSTA-FST Bank Data

Buffer Documents
Lockbox FINSTA01/LOCKBX
Account Info FINSTA01/FINSTA-ACP

Treasury
Advices
Remittance Adv PEXR2002/REMADV
Payment Order PEXR2002/PAYEXT
Direct Debit PEXR2002/DIRDEB Payment

Database
Paymt Control IDCREF01/EUPEXR
 SAP AG 1999
© SAP AG CA210 11-7

Invoice and Payment Process
customer remittance
advice
incoming payment
invoice program
collective
payment bank
vendor incoming
payment
outgoing
invoice
remittance
advice
 SAP AG 1999
SAP EDI invoice and payment cycle handles the sending of invoices from the SD module from the
vendor to the customer receiving the invoice.
The customer then runs the payment program from the Accounts Payable module found in FI.
The payment program is equipped to handle a variety of payment methods and can generated
payments for a select range of vendors or all vendors.
The payment programs are country specific and payment method specific. The naming convention
for the payment programs is RFFO<country code>_<payment method>, i.e. RFFOUS_C which will
generate check payments.
The payment program will also generate the remittance advices.
The remittance advices and payment orders then are sent to the bank for further processing. The bank
will send the payment and remittance information to the vendor.
The vendor will then apply the payment and remittance advice to Accounts Receivable to clear open
invoices and their items.
© SAP AG CA210 11-8

Outbound Payment Configuration
Paying Company Code

Payment advice form
EDI accompanying sheet
House Bank
Partner number
EDI payment methods
 SAP AG 1999
Define for each paying company code, the remittance advice form if remittance advices are to be
printed.
Define for each paying company code, the EDI accompanying sheet. This form produces the control
totals report for each payment run.
It is from the house bank configuration that the EDI bank trading partner number (name) is defined
and from where the partner profile for the bank is initiated.
Also in the house bank configuration, in the DME (data medium of exchange) section, is where the
EDI compatible payment methods are defined.
The best source of configuration information is found in the appendix or in the release notes for 3.0D
in the Financial Accounting area for accounts payable.
© SAP AG CA210 11-9

Outbound Payment/Remittance Configuration
Partner Profile Partner

Profile
Test IDoc
Final (non-test) IDoc
Vendor Master
Payment Transaction Screen (General Data)
Bank account information
Payment Transactions Screen (Company Code Data)
Payment methods
House bank
Pmt adv. by EDI
 SAP AG 1999
The partner profile may be set up for the bank, and/or vendor trading partners. The bank receives the
payment order which can also contain the remittance information. The vendor trading partner may be
set up to receive the remittance information directly. Both types of trading partners can be set up for
both test and final (non-test) IDocs to be created from the payment run.
Test IDocs can be generated from the proposal run.
Final IDocs are generated from the payment run.
Set up or verify the following when configuring the Vendor Master with the information that is
specific to EDI:
Payment Transactions Screen (Company Code data)
- Payment Methods
- House bank
- Pmt adv. by EDI = 'x' (for EDI FI remittance advice)
Payment Transactions Screen (General Data)
- Bank account information for Electronic Funds Transfer
© SAP AG CA210 11-10

Outbound PAYEXT/REMADV Processing
Payment program Parameters

Print Program Variant
 SAP AG 1999
The payment program parameters indicate which companies are to be searched, the payment
methods that are to be used, and which accounts (vendor and customer) are to be paid.
Additional program parameters include the additional log, and the print program.
Additional log specifies the results of the due date check, payment method selection in all cases of an
open invoice and if it is included in the proposal for payment, and line items included in the payment
document.
The print program specifies how the payment orders are to be generated i.e. check, wire transfer,
dme file.
The print program variant specifies the options to use with the print program.
© SAP AG CA210 11-11

Payment Program Parameters
R/3 Automatic Payment Transactions: Parameters x
Parameters Edit Goto Environment Systems Help
x ?
X Selection Print programs Additional log…. B.ex/pmt request
Run date 22 . 06 . 1998 Posting date 22 . 06 . 1998

PAY1 Docs entered up to 22 . 06 . 1998
Identification
Customer items due by
Payments control
Company codes Pmnt meths Next posting date
3000 C 30.08.1998
ENTRY 1 1
Accounts Foreign currencies
Vendors (from / to) Customers (from / to
10001 10099 Rat types for conversn
Entry 1 1 Entry 0 0
 SAP AG 1999
The payment program parameters indicate which companies are to be searched, the payment
methods that are to be used, and which accounts (vendor and customer) are to be paid.
Sample parameters would be:
- Company codes = '3000’
- Payment Meths = 'C’
- Next posting period = some future time,
- Accounts Vendors = '10099’
- Customers = none
© SAP AG CA210 11-12

Program Parameters - Print Program
x ?
Other variants
Print forms / Data medium exchange
Report Requested variants More
RFFOAVIS
RFFOEDI1 PAY1
RFFOUS _ C
Lists
Report Requested variants
 SAP AG 1999
Specify the variant for the EDI program
© SAP AG CA210 11-13

Program Parameters - Additional Log
x ?
X Selection Print programs Additional log…. B.ex/pmt request
Run date 22 . 06 . 1998 Posting date 22 . 06 . 1998

PAY1 Docs entered up to 22 . 06 . 1998
Identification
Customer items due by
Payments control Additional Log x
Company codes Pmnt meths Next posting date
Required logging type
3000 C 30.08.1998
Due date check
Payment method selection in all cases
Pmnt method selection if not successful
Line items of the payment documents
Accounts
Vendors (from / to) CustomersENTRY
(from / to 1 1
10001 10099
Accounts Foreign currencies
Vendors (from / to) Customers (from / to
10001 10099 Rat types for conversn
Entry 1 1 Entry 0 0
Entry 1 1 X Entry
x 0 0
 SAP AG 1999
The additional log will generate information in the proposal log or the payment log as to why an
invoice was chosen or not based on the due date, what the payment method is for a particular
invoice, and the line item information on the invoice.
© SAP AG CA210 11-14

Program Variant (1)

Variant Edit Goto System Help
x ?
Variant attributes X i
Program run date 22 . 06 . 1998
Identification feature PAY1
Proposal run only
Company code selection
Paying company code 3000 to
Sending company code 3000 to
Further selections
Payment methods C to
Payment methods supplement to
Business area to
House bank 3000 to
Account ID 3000 to
Currency key to
Payment document number to
 SAP AG 1999
The print program variant specifies the options to use with the print program
A sample variant would be:
PAY1 which would be associated with RFFOEDI1 report
Use SE38 to change/edit the print program variant PAY1
Relevant data includes (as an example):
Program run date = set to current date, Identification feature = matches payment program, Paying
company code = '3000', Sending company code = '3000', Payment methods = 'C', House bank =
'3000', Account Id = '3000', Generate SAP IDoc = 'x', Print payment advice notes = 'x', Print
payment summary = 'x'
© SAP AG CA210 11-15

Program Variant (2)

Variant Edit Goto System Help
x ?
Variant attributes X i
Print Control
Generate SAP IDoc Printer Print immediately
Print payment advice notes Printer Print immediately
Print payment summary Printer Print immediately
Output Control
Number of invoice details
Alternative accompanying sheet
Number of accompanying sheets
Number of sample printouts
No.items in payment summary

Payment document validation
Texts in recipients language

Currency in ISO code
 SAP AG 1999
The print program variant specifies the options to use with the print program
A sample variant would be:
PAY1 which would be associated with RFFOEDI1 report
Use SE38 to change/edit the print program variant PAY1
Relevant data includes (as an example):
Program run date = set to current date, Identification feature = matches payment program, Paying
company code = '3000', Sending company code = '3000', Payment methods = 'C', House bank =
'3000', Account Id = '3000', Generate SAP IDoc = 'x', Print payment advice notes = 'x', Print
payment summary = 'x’.
© SAP AG CA210 11-16

Outbound PAYEXT/REMADV Processing
Schedule Proposal
‘Test’ IDocs
Post and Print
Schedule Payment
Actual IDocs
Post and Print
 SAP AG 1999
If test PAYEXT/REMADV records are to be sent out (test flag = 'x') then when the proposal is
scheduled select the Post and Print option.
If actual PAYEXT/REMADV records are to be sent out then do not select the Post and Print option
on the proposal.
After any necessary editing of the payment proposal is done, schedule the payment run. If actual
PAYEXT/REMADV records are to be sent out then select the Post and Print option on the payment
run.
© SAP AG CA210 11-17

Schedule Proposal
R/3 Automatic Payment Transactions: x

Payment Run Edit Goto Environment Systems Help
x ?
Status Proposal Parameters Print programs
Run date 22 . 06 . 1998
Identification PAY1
Status
Parameters have been entered
Automatic Payment Transactions
Start date 22.06.1998 Start immediately

ENTRY
Start time 00 :00 : 00
Foreign currencies
Customers (from / to
Target computer Rat types for conversn
Post and Print
x Entry 0 0
 SAP AG 1999
Schedule the proposal run. This will examine all invoices and based on the selection criteria
determine if an invoice will be chosen.
The proposal can then be edited to select the invoices to be paid during the payment run.
If test IDocs are to be generated then mark the Post and Print checkbox.
© SAP AG CA210 11-18

Schedule Payment
R/3 Automatic Payment Transactions: x
Payment Run Edit Goto Environment Systems Help
x ?
Status Log default value Default value Pmnt run Print programs
Run date 22 . 06 . 1998
Identification PAY1
Status
Parameters have been entered

Payment Proposal has been created
Automatic Payment Transactions
Start date 22.06.1998 Start immediately

ENTRY
Start time 00 :00 : 00
Foreign currencies
Customers (from / to
Target computer Rat types for conversn
Post and Print
x Entry 0 0
 SAP AG 1999
Based on the edited proposal, the final invoices are selected for payment and the payment is created
for the payment method specified in the parameters.
If actual IDocs are to be created, then mark the Post and print checkbox.
© SAP AG CA210 11-19

Payment Program Result
Payment Order and/or

Remittance Advice IDocs
 SAP AG 1999
© SAP AG CA210 11-20

Inbound Payment Processing
Partner Profile set up for the bank trading partner:

Lock box
Logical Message - ‘LOCKBX’
No Partner function specified
Process Code - ‘LOBX’
Electronic Bank Statement
Logical Message - ‘FINSTA’
No Partner function specified Bank
Process Code - ‘FINS’

Lock box application configuration
Electronic Bank Statement application configuration
 SAP AG 1999
A partner profile is created for each house bank sending electronic bank statements or lock box data.
The house bank must be designated as EDI, which is done through the configuration of the house
bank as was done for outbound payments. The DME (data medium of exchange) configuration is
where the trading partner number (name) for the bank is identified. The partner profile can be created
from within the DME configuration or via the normal path to create partner profiles. The partner type
is ‘B' for bank. The house bank DME configuration is done no matter if the incoming payment is via
electronic bank statement or lock box
The Cash Management application must be configured to accept electronic banking statements for
such items as posting rules, company code, data for house bank account, etc.
For lock box, there is also some additional configuration for control parameters, and postings as well
as the configuration items regarding posting rules, company code, data for house bank account, etc.
Please see the appendix or the release notes for 4.0A under Financial Accounting, Bank Accounting,
Enhancements to Inbound Processing in Cash Management.
© SAP AG CA210 11-21

EDI/ANSI Lockbox Data Flow
Customer SAP-User
SAP Server
EDI Server
EDI
EDI IDOC
Interface IDOC
Interface
Pmt. Bank
Advice Stmt.
Table Table
Remittance
Remittance ANSI
Advice ANSI
Advice 823
823Message
Message
Bank Lockbox
LockboxProgram
Program
Lockbox
 SAP AG 1999
Customers send their payments to a lockbox. The bank collects the data and sends an ANSI 823
message to the SAP user’s EDI server. The server translates the message using as standard EDI
interface into an IDOC (intermediary document) and sends it to the SAP server.
Once the message is received by the SAP server, the data is stored in the FINSTA01 Lockbox IDoc
Type in the IDoc tables.
At the same time, a program is kicked off which generates the following;
Check information is stored in bank statement tables
Payment advices are created which detail the disposition of the checks i.e. payment amount,
invoice numbers, customer numbers, etc.
Then the lockbox program is launched and the payment advices are cleared against customer open
items. Any checks that could not be fully processed by the lockbox process can be manually
processed using the post processing transaction.
© SAP AG CA210 11-22

Customizing Lockbox
Lockbox configuration tables

T049A Posting Data
T049B General Parameters (new format ‘IDOC’)
T049L Lockboxes for House Banks
Partner Profile through House Bank configuration
 SAP AG 1999
Table T049A indicates the bank identification (Origin) and bank account (Destination). Here also are
specified the company code to receive the funds, house bank, account id, bank G/L account, and the
bank G/L clearing account. The posting parameters are required to determine the posting document
types for the bank and the customer, and the posting keys for the debits and credits for the G/L and
the customer.
Table T049B indicates the general parameters for the lockbox posting. The format that should be
indicated here is LOCKBOX and IDOC. The other posting parameters will be dependant on the
Accounts Receivable department. Typically, the settings would be marked with a check mark for the
G/L account postings, and the Incoming customer payments. If the bank information for the
customer is not already included in the customer master then mark the Insert bank details box and in
the program box insert ADDBNKDETAIL. This will update the customer master with the
customer’s bank information when it coming in on the payment. Additionally, the typical setting for
the G/L account posting type is ‘1’. The setting for partial payments is blank unless the accounts
receivable department will accept partial payments and not wish to create residual items.
Table T049L indicates the lockbox numbers used at your banks for your accounts. All lockboxes for
which you are going to receive checks must be specified here.
As we saw in the creation of outbound payments, we need to configure the partner profile for the
incoming payment transaction. This is done via the DME screen of the House Bank configuration.
© SAP AG CA210 11-23

Account Statement
Bank statement
IDoc Type FINSTA01 - message type FINSTA
Document type FST (E1IDKU1-BGMTYP)
Bank Account Information (Intraday)
IDoc Type FINSTA01 - message type FINSTA
Document type ACP (E1IDKU1-BGMTYP)
 SAP AG 1999
The Account Statement or Electronic Bank Statement can be used for multiple purposes.
It can be a summary statement similar to your personal bank statement showing the month’s
activities in your account(s).
The Account Statement can also be used to show the account activity for a single day and would be
something that would be received on a daily basis.
The differences in the use of the account statement are determined in the field BGMTYP on the
E1IDKU1 segment with FST to indicate the month activities and ACP to indicate the daily activities.
© SAP AG CA210 11-24

Customizing EDI Account Statement
T028V Transaction types

T028B Allocate banks - planning type, summarization
T028D Posting rule keys
T028G Assign transactions
T033F Posting rules
House banks → DME → EDI Partner no.
 SAP AG 1999
There are several transactions that need to be configured in order for the electronic bank statement or
account polling to work properly.
First we want to add a valid transaction type of IDoc.
The bank must know what transaction type we will be using for the processing. An entry similar to
the lockbox entry is made for the bank identifier and the bank account and the transaction type of
IDoc.
The cash management group should understand what the various activities will be used with the
account and should create the posting rule keys which determine just what the activity is.
The assignment of external transaction codes would be how we interpret the bank’s activity codes
with those we have set up in the system to represent those various activities.
The posting rules will determine what kind of document types are created in the system, the debit
and credit posting keys, and any calculations made on the activity. Again this is something the cash
management or accounts receivable personnel should set up.
As we have seen previously, we may need to set up the bank as a trading partner for the electronic
bank statement. This is done through the House Bank configuration on the DME screen.
© SAP AG CA210 11-25

Inbound REMADV Processing
Partner Profile for Customer trading partner

Logical Message - ‘REMADV’
No Partner function specified
Process Code - ‘REMA’
Company Code Assignment
Company Name from IDoc
Company Code derived from Name
 SAP AG 1999
A partner profile is for each customer sending remittance advice information.

Payments are made against invoices associated with a particular company.
Company code is assigned through the Implementation Guide as is done for inbound invoices, and is
based on the name found in the E1EDKA1-NAME1 field.
© SAP AG CA210 11-26

Payment/Remittance Advice Program
Program - SAPLIEDP
Function Group - IEDP
Function Modules:
Outbound - FI_EDI_PAYEXT_PEXR2001_OUT (payment
orders)
Outbound - FI_EDI_REMADV_PEXR2001_OUT (remittance
advices only)
Inbound - IDOC_INPUT_REMADV
Inbound - IDOC_INPUT_FINSTA
Inbound - IDOC_INPUT_LOCKBX
 SAP AG 1999
The outbound payment/remittance advice and inbound lockbox, financial statement, and remittance
advice function modules are all found in SAPLIEDP program.
© SAP AG CA210 11-27

Payment/Remittance Process: Unit Summary
The outbound payment/remittance process

involves a great amount of configuration for the
EDI interface
The payment/remittance process execution is a
multi-step process involving setting up the
parameters, program variants, additional logs,
and then running the proposal, editing the
proposal, then running the payments.
Test IDocs are created in the proposal stage and
non-test IDocs are created in the payment stage.
The inbound payment/remittance process is fairly
easy to configure requiring just partner profile
configuration.
 SAP AG 1999
© SAP AG CA210 11-28

Price Catalog, Inventory Advice
Contents:
Price Catalog
Inventory Advice
 SAP AG 1999
© SAP AG CA210 12-1

Price Catalog, Inventory Advice: Unit Objectives

Describe the configuration and processing
necessary to create the outbound price catalog
Describe the pertinent information around
creating the inbound inventory advice
 SAP AG 1999
© SAP AG CA210 12-2

Price Catalog, Inventory Advice: Course Overview
Diagram (1)

Inbound Invoice
10
Payment/Remittance
Price Catalog,
Catalog, Inventory
MM EDI Application
 SAP AG 1999
© SAP AG CA210 12-3

Price Catalog, Inventory Advice: Course Overview
Diagram (2)
Working with an
EDI Subsystem 15
IDoc Monitoring 16
Archiving IDocs 17
Conclusion 19
 SAP AG 1999
© SAP AG CA210 12-4

Price Catalog, Inventory Advice: Business
Scenario
When our customers order products from us, they

can send in our product codes and pricing
enabling us to process their orders more quickly.
Often there are changes in our products and
prices which we need to communicate to our
customers
If we deal with third-party warehouses to ship
and/or store our product, it is necessary for us to
understand the inventory position and movements
of our product so that we can know what is
available for our customers to purchase from us.
 SAP AG 1999
© SAP AG CA210 12-5

Price Catalog - Procedure to Output
/3
APR Material PRICAT Creation
S or Article Who gets the information ?
IDocs
and price Which data do they get ?
When do they get the data ?
What is the appropriate format IDocs ALE Layer
tem
ubsys
IS IDoc File
ED
Convert IDoc data into
PRICAT format
Sender
PRICAT Recipients
rs
Use Processing of the Passing on of the
EDI data from PRICAT
PRICAT Message
the database to a
third system Information
 SAP AG 1999
We create the price catalog information when we want to send a complete or partial list of product
offerings to our customers.
The price catalog information contains the description of the product, prices and pricing conditions
(including taxes) and logistics information for each product. The price catalog can also contain
general information which is valid for every customer or customer-specific information, such as
special conditions. A time-frame can also be specified for how long the information is valid.
© SAP AG CA210 12-6

Application Functionality
Material master data maintenance

Customer master data maintenance
Pricing/conditions maintenance
Assortment planning
Assortment module
Assortment
Profile
Units of Measure Transferred
IDoc creation - partner profile(s)
Creation of price catalog
 SAP AG 1999
There are many functional areas that require the proper configuration before the PRICAT IDocs can
be created. The materials must be created in the material master with all of the information required
by the price catalog, i.e. the product description, material group, and units of measure to name a few.
The customers must be defined in the customer master and in the appropriate sales are for which you
are going to send the price catalog.
The pricing data must be created. This can take many forms from generic pricing for all customers,
to customer-specific pricing. Any special pricing conditions like discounts and surcharges, freight,
and taxes must be maintained.
Assortment planning gets to what materials are going to be included in the price catalog, and for
which customers in a specific sales area or areas. Assortment planning involved the creation of one
or more assortment modules which are assigned to an assortment. Finally a profile is built and the
units of measure for transfer can be determined.
The creation of the IDoc involves the creation of a partner profile for each recipient defined in
assortment.
The IDocs are created manually via transaction VPRE.
Note: When creating the outbound partner profile, there is no message control involved.
© SAP AG CA210 12-7

Inventory Advice
IDoc Type - WMMBID01

Transaction Code(s)
Movement Type(s)
Plant(s)
Storage Location(s)
 SAP AG 1999
IDoc type WMMBID01 is a very simple IDoc type consisting of a very few segments. A single
header segment which indicates the document and posting dates and the transaction code. A single
item segment which contains the material, plant, storage location, movement type, quantity, unit of
measure, etc.
The transaction code is very important as it indicates if the IDoc is for a goods issue or a transfer
posting. Transaction MB1A is used for goods issue and MB1B is used for transfer posting.
If you would look at the material master, you will find in the plant/storage location data that there are
many buckets which describe the characteristics of the inventory. It is via movement types which are
assigned to one of the two transaction codes that move inventory from one category to another and
perhaps from one plant to another or from a storage location to another storage location.
With the help of the inventory manager, you can decide which plant/storage locations are valid and
what transaction code/movement types are valid for inventory movements.
© SAP AG CA210 12-8

Price Catalog, Inventory Advice: Unit Summary

Describe the configuration and processing
necessary to create the outbound price catalog
Describe the pertinent information around
creating the inbound inventory advice
 SAP AG 1999
© SAP AG CA210 12-9

Exercises
Unit: Price Catalog, Inventory Advice

Topic: Price Catalog Creation

Complete the configuration necessary to create the Price Catalog
Create the PRICAT IDoc

communicate Price Catalog information via EDI.
1-1 Create an Assortment module for your material.
1-2 Create an Assortment for your group using Sales organization 3000 and
Distribution channel 10, with Material group 010 and your customer number
(300##).
1-3 Assign your assortment module to your assortment.
1-4 Create a Profile for your group.
1-5 Create the price catalog IDoc.
1-6 Use the Monitoring tool, IDoc lists, to look at your PRICAT IDoc.
© SAP AG CA210 12-10

Solutions
Unit: Price Catalog, Inventory Advice

Topic: Price Catalog Creation

SALES AND DISTRIBUTION → MASTER DATA → PRODUCTS →
ASSORTMENTS → ASSORTMENT → MODULE → CREATE
Assortment Module Create: Initial Screen

Module type Standard module
Module Group##
1-1-2 Select the [Items] button and enter the following information:
Assortment Module Create: Items

Module Description Assortment Module for Group##
Valid from Enter the current date
Valid to 12/31/9999
Material CCS-99
1-1-3 Save and green arrow back.

1-1-4

ASSORTMENTS → ASSORTMENT → GENERAL ASSORTMENT →
CREATE
© SAP AG CA210 12-11

Assortment Create: Initial Screen

Assortment Group##
1-2-2 Select the [Basic Data] button and enter the following information:
Assortment Create: Basic Data

Assortment Description Assortment for Group##
Status Active, can be assigned to assort users
Sales org. 3000
Distr.channel 10
1-2-3 Select the [Material groups] button and enter the following information:
Assortment Create: Mat. groups

Matl group 010
1-2-4 Select the [Assortment user] button and enter the following information:
Assortment Create: Assortment user

Customer 300##
Sorg. 3000
DC 10
Division 00

ASSORTMENTS → ASSORTMENT → MODULE → ASSORTMENT
ASSIGNENT → MAINTAIN
© SAP AG CA210 12-12

Assortment Create: Initial Screen

Module Group##
1-3-2 Select the [Items] button and enter the following information:
Assortment Create: Basic Data

Assortment Group##
1-3-3 Select the [Skip all errors] button.


TOOLS → ACCELERATEDSAP → CUSTOMIZING → EDIT PROJECT →
[SAP REFERENCE IMG] button → SALES AND DISTRIBUTION
→ELECTRONIC DATA INTERCHANGE → PRICING CATALOG
→REQUIREMENTS PROFILES
1-4-1 Select [New Entries] button and enter the following information:

Profl. GR##
Description Profile for group##
Plant 3000
OrdTyp OR
Gross PR00
Net PN00
Sprice PN10
CondTyp HD00
Tax JR1
Tax JR2
Tax JR3
VAT 1
© SAP AG CA210 12-13

1-4-2 Save and green arrow back out of the IMG.

SALES AND DISTRIBUTION → MASTER DATA → AGREEMENTS
→CATALOGS → PRICING CATALOG → CREATE

PRICAT processing: Manual creation
Division 00
Assortment Group##
Module Group##
Profile GR##
1-5-3 Press the [Create PRICAT] button.

Enter transfer parameters

Partner type KU
Partner function SP
1-5-5 Press enter.

1-5-6 Note the IDoc number for your price catalog IDoc.
______________________________________________________
1-5-7 Green arrow twice out of the transaction.

TOOLS → BUSINESS COMMUNICATION → IDOC → IDOC BASIS → IDOC
→ IDOC LISTS
© SAP AG CA210 12-14

IDoc lists
© SAP AG CA210 12-15

Test of Processing
Contents:
Outbound testing
Inbound testing
Status testing
 SAP AG 1999
© SAP AG CA210 13-1

Test of Processing: Unit Objectives

Use the test tool
Distinguish between the special test programs and
decide when they are useful
 SAP AG 1999
© SAP AG CA210 13-2

Test of Processing: Course Overview Diagram (1)

Inbound Invoice
10
Payment/Remittance
MM EDI Application Test
Test of
of
Requirements
6 Proce
Processing
13
ssing

 SAP AG 1999
© SAP AG CA210 13-3

Test of Processing: Course Overview Diagram (2)
Working with an
EDI Subsystem 15
IDoc Monitoring 16
Archiving IDocs 17
Conclusion 19
 SAP AG 1999
© SAP AG CA210 13-4

Test of Processing: Business Scenario
After successfully testing your own IDoc interface

and connecting your EDI subsystem, you want to
test the file transfer from and to your EDI
subsystem
 SAP AG 1999
© SAP AG CA210 13-5

Test Layers: Overview
Application
Message Control Workflow
WE15 WE19 WE19
IDoc Interface
WE17
WE14, WE19 WE16
WE18
External Outbound WE12 Inbound Status

System IDoc File IDoc File report
(Port)
File system
 SAP AG 1999
The arrows show the layers where the tests start, as well as finding the relevant transaction. To the
left is outbound, to the right inbound processing. Depending on the process code (partner profile
entry), the inbound IDocs are processed directly within the application, or via a workflow.
The test tool (WE19) is the most general tool. It allows testing of both inbound and outbound
processing starting with an IDoc created from within the tool.
The other test programs require either a file on the operating system level, an IDoc already present or
a NAST table record (message control).
When choosing a file port for outbound processing, one can run a complete test cycle (outbound and
inbound) including the operating system.
When testing starting from NAST (WE15), one can test if a NAST table record leads to the creation
of a correct outbound IDoc. It requires that processing has to be stopped when the NAST record is
written. This is achieved by setting the message control sending time to 1. The NAST record holds
the processing status 0 (not processed yet). WE15 is nothing more than starting RSNAST00
manually.
Both transaction WE14 and WE19 (IDoc and outbound test tool) test the transfer of one or more
IDocs to the defined port. The former test (WE14) requires an outbound IDoc not yet passed to the
port (IDoc status 30). This is achieved by setting the output mode in the partner profile to collect
IDocs.
Both transactions, modified outbound file (WE12) and test original inbound file (WE16), test the
takeover of an IDoc file by the interface. WE12 changes control record entries to change an
outbound to an inbound IDoc before it passes the IDoc to the interface.
Note: WE16 erases the inbound file after successful reading. This does not apply to the outbound
IDoc file read by WE12. It can be used for further test runs.
© SAP AG CA210 13-6

IDoc Outbound Testing
With transaction WE15, program

RSNAST00 test the creation of an Application
IDoc based on the Message
Control record. Message Control
With transaction WE14, program

RSEOUT00 test the forwarding of WE15
an IDoc to the receiver system,

e.g. IDoc Interface
as preparations for the inbound WE14

WE19
testing
EDI processing with an EDI
Outbound
subsystem IDoc file
With transaction WE19, Test Tool,

outbound IDoc files can be
created.
 SAP AG 1999
The outbound test with transactions WE14 and WE15 requires that areas to be tested do not post and
run immediately, but according to time schedules.
To test creation of IDocs from MM and SD, e.g. ORDERS, DESADV, INVOIC, Message Control
priority has to be 1.
To test transfer of IDocs to file, e.g. EDI subsystem, output mode has to be 3 or 4 in the IDoc
partner profile. Output mode 3 means collect IDocs and start EDI subsystem via synchronous
RFC. Output mode 4 means collect IDocs and do not start EDI subsystem.
With transaction WE15, program RSNAST00, testing of the creation of IDocs is based on the
Message Control record. This is available for applications MM-PUR and SD only, the send priority
in Message Control has to be 1.
With transaction WE14, program RSEOUT00, testing of the forwarding of one or more IDocs to the
receiver system, e.g. an EDI subsystem. This is available for all applications, the output mode in the
IDoc partner profile has to be 3 or 4.
With transaction WE19, the creation of outbound IDoc files is done independently of any application
or implementation.
The IDocs created by WE19 for outbound have as their initial status 42 (instead of status 01) from
release 4.6A on.
© SAP AG CA210 13-7

IDoc Inbound Testing
With transaction WE12, test the Application

inbound processing of an IDoc
by coping an outbound file, and Workflow
handle the copy as an inbound
file.
WE19
With transaction WE16, test the
inbound processing of an IDoc IDoc Interface
by picking-up any inbound file.
WE16
With transaction WE19, Test Tool
test the inbound processing of
an IDoc by creating the IDoc in Outbound WE12 Inbound
IDoc file IDoc file
an editor and feeding the result
to the inbound process.
 SAP AG 1999
The inbound test, whether initiated by transaction WE12 or WE16, picks up IDocs from a file and
posts them to the SAP database. For all three transactions it depends on the process code assigned in
the IDoc partner profile how further processing is done. This affects how and when application
documents are created.
With transaction WE12 a test can be repeated, only the copy is removed, but not the source file itself
(unless the source is overwritten by any other activity or person).
With transaction WE16 the test can be done only once. If it was successful, the source file will be
removed (deleted).
Transaction WE19 allows to repetition of the test via a choice of template (logical message, IDoc
type, or IDoc). Further on it offers functionality to store the IDoc in a file and to use dialog and
debugging modes for the processing.
All IDocs created by WE12, WE16 or WE19 for inbound have as first status 74 (instead of status 50)
from release 4.6A on.
© SAP AG CA210 13-8

IDoc Status Testing
With transaction WE17, test the

processing of the status report, and Application
the reactions in behalf of the status
report. Workflow
With transaction WE18, create a

WE19 WE19
status report and initiate the
processing as with transaction
WE17. IDoc Interface
With transaction WE19, Test Tool WE17

WE18
create a status report as IDoc type
SYSTAT01 and follow inbound
Status
testing features. report
 SAP AG 1999
The status test (WE17, WE18) allows checking that status information and details are correct as well
as to test notification procedures defined with SAP Business Workflow. It is required that the status
report references only outbound IDocs that actually exist in the IDoc database.
With transaction WE17 the status report can be processed from the file interface. The test can be
done only once. If it was successful, the source file will be removed (deleted).
With transaction WE18 the status report can be created into a file. The status report can then be
processed immediately or picked up later by transaction WE17.
Transaction WE18 is available from release 4.6A on.
Some port types do not support the status report, therefore it is possible to receive a status report by
IDocs of type SYSTAT01. In this case it is simply an inbound IDoc test with a specific process (e.g.
not ORDERS, but STATUS). Please proceed as described for "IDoc Inbound Testing".
© SAP AG CA210 13-9

Test Tool Abilities
Test Tool
Direct Call
mass testing
(for Inbound only) Function module
create File
 SAP AG 1999
The test tool has the following options:

The IDoc can be edited, both in structure (IDoc type) and data level. You can use a database IDoc
as a template but can also build your own IDoc segment by segment.
Once the IDoc has been completed and before testing is initiated, the IDoc can be checked for
syntax errors (new in release 4.6a).
Mass testing can send the IDoc many times to a file for inbound processing.
With a file port, one can have an inbound IDoc file created. It is possible just to create the file
without starting inbound processing. Therefore, the IDoc is available for further tests.
You can directly call the inbound function module. This works around the partner profile, i.e. the
IDoc is saved in the database and immediately passed to the function module.
Note: If the function module is called directly and errors occur, workflow is not invoked.
Mass testing for outbound is possible by repeating the IDoc many times into the outbound file.
© SAP AG CA210 13-10

When to Test which Program?
Exchange with file system: WE16 (Inbound),

WE17 (inbound status report), WE19 (outbound,
set Port accordingly)
Read NAST record: WE15
Transfer from interface to further inbound
processing: WE19 (direct function module call)
Transfer to IDoc interface: WE19 (outbound and
standard inbound)
Transfer to arbitrary port (outbound): WE19
 SAP AG 1999
Use WE12 (inbound modified outbound file) when MM and SD modules are configured but the EDI
subsystem is not in place yet. This will test the SAP EDI configuration - Message Control, and
Partner Profile configuration.
Use WE16 or WE19 when only one side of the two application modules (MM or SD) is to be
implemented.
Use WE14 or WE15 when you want to simulate the batch environment for outbound documents.
© SAP AG CA210 13-11

Test of Processing: Unit Summary

Use the test tool
Distinguish between the special test programs
and decide when they are useful
 SAP AG 1999
© SAP AG CA210 13-12

Exercises
Unit: Test of Processing

Topic: Inbound Test Tool

Create a new IDoc and process it by copying and modifying an
existing IDoc
IDocs can be created to test the configuration of the IDoc interface set up
as well as test the application areas. If the legacy system or translator is
not yet available, testing and configuration does not have to wait.
1-1 Copy the successfully posted (status 53) inbound ORDERS IDoc from Unit –
Business Workflow and IDocs, Unit – Error reprocesssing.
1-1-1 Change the quantity fields on the E1EDP01 segment.
1-1-2 Change the quantity field on the E1EDP20 segment to the same number you
changed on the E1EDP01 segment.
1-1-2 Change the overall field on the E1EDS01 segment to reflect your new
quantity times price.
1-1-3 Execute the IDoc by using the function module IDOC_INPUT_ORDERS
1-2 Use Monitoring tool, IDoc lists, to determine the Sales Order number.
________________________________________________________________
© SAP AG CA210 13-13

Solutions
Unit: Test of Processing

Topic: Inbound Test Tool

TEST → TEST TOOL
1-1-1 Select the Existing IDoc and enter the IDoc number.
1-1-2 Change the quantity fields and net value field on the E1EDP01 segment.
Enter the IDoc number and Press Create icon.
Double click on the E1EDP01 segment.
Change the two quantity fields and the net value field to reflect the new
quantity times the unit price on the E1EDP01 segment.
Press [Enter].
1-1-3 Change the quantity field on the E1EDP20 segment.
Double click on the E1EDP20 segment.
Change the quantity field(s) to match what was entered on the E1EDP01
segment.
Press [Enter].
1-1-4 Change the overall field on the E1EDS01 segment to reflect your new
quantity times price.
Double click on the E1EDS01 segment.
Change the overall field to reflect your new quantity times price.
Press [Enter].
1-1-5 Execute the IDoc by using the function module IDOC_INPUT_ORDERS
Press the [Inbound Function Module] button.
Enter the function module IDOC_INPUT_ORDERS.
Press [Enter].
1-2 Use Monitoring tool, IDoc lists, to determine the sales order number.
TOOLS → BUSINESS COMMUNCATION → IDOC → IDOC BASIS →
IDOC → IDOC LISTS
© SAP AG CA210 13-14

IDoc lists

_______________________________________________
© SAP AG CA210 13-15

Documentation Tools
Contents:
Record types, IDoc types, segments
Output formats
Process codes
 SAP AG 1999
© SAP AG CA210 14-1

Documentation Tools: Unit Objectives

Use the documentation tools
Decide in which situation they may help you
 SAP AG 1999
© SAP AG CA210 14-2

Documentation Tools: Course Overview Diagram (1)
Introduction 1 Workflow and IDocs 8

Inbound Invoice
10
Payment/Remittance
MM EDI Application
Requirements
Documentation Tools
Message Control & IDocs 7 14
 SAP AG 1999
© SAP AG CA210 14-3

Documentation Tools: Course Overview Diagram (2)
Working with an
EDI Subsystem 15
IDoc Monitoring 16
Archiving IDocs 17
Conclusion 19
 SAP AG 1999
© SAP AG CA210 14-4

Documentation Tools: Business Scenario
Having tested your R/3 system for IDoc

processing, you want to include your EDI
subsystem.
Your EDI subsystem must learn the structure of
the IDoc type you want to change. You know there
are documentation tools of the IDoc interface, but
you have to know what they can do in order to
facilitate the setup of your EDI subsystem.
 SAP AG 1999
© SAP AG CA210 14-5

Internal and External Structures
Segment
E1... Field 1 Field 2 Field 3 Field 4
Rels.
internal
3.0 external
E2...001 Field 1 Field 2
 SAP AG 1999
IDoc Types are distinguished through their segments, i.e. the structure laid upon the unstructured
field SDATA of the data record.These segments exist both in internal and external Form:
the internal form is a release-independent structure (SAP segment names start with E1) containing
all segment fields defined.
the external form is a release-dependent structure (SAP segment names start with E2) containing
only those fields which were defined in the release chosen in the partner profile.
Besides the segments, there are also external and internal structures of the record types. Both have
changed with each release (2.2 to 3.0 to 4.0). Again, the documentation tools only refer to the
external structures.
When running the documentation tools, you have to define:
the release relevant for the segments (which segment definitions). This is the same parameter
which you set when maintaining the partner profile.
the release relevant for the record types. This is the same parameter which you set in the version
when maintaining the port description.
© SAP AG CA210 14-6

Output in Different Formats (1)
Hierarchy HTML
 SAP AG 1999
IDoc types, segments and record types can be displayed in user-friendly and machine readable
formats:
R/3 tree display - this is also used for the record types even if they do not have a hierarchy
HTML - use the *_f file for loading the frame in your Web browser. The other two files created
are the data file (*_d) and the index file (*_i).
Documentation also pertains to the data elements of the segment structure fields. There is application
documentation available for individual IDoc types.
© SAP AG CA210 14-7

Output in Different Formats (2)
Begin typedefine struct edi_dc

… {…}
End edi_dc
 SAP AG 1999
Machine readable formats are:

A simple chain of declarations easily readable by a parser
C header
meta IDoc, type SYRECD01
You start the documentation tools from the entry menu of the IDoc interface via Documentation. The
parser has its own menu entry both for record and IDoc types.
Finally, there are the “Meta IDocs”. There are two special IDoc Types describing the formats in their
data records. The types are called:
SYIDOC01 - contains the Format definition of an IDoc Type (i.e. record types and segments)
SYRECD01 - contains the Format definitions of the IDoc record types. A possible application is
an EDI Subsystem which only knows the record type versions of Releases 2.X and 3.X (that is, the
Versions 1 and 2 showing up in the port description). Using SYRECD01 with record type version
1 or 2, the EDI Subsystem can be informed about the new 4.0 Version (version 3).
© SAP AG CA210 14-8

Process Code
Access via logical message

Outbound process codes via Message Control
Inbound process codes not generated from a BAPI
 SAP AG 1999
The documentation of process codes is a process-oriented view.

Access is made by outbound messages, and inbound messages through the logical message. All
process codes associated with the logical message by direction are found under the logical message.
Only outbound process codes that are initiated via Message Control are shown.
Inbound process codes are shown for all processes which have their own implementation which is
not generated from a BAPI (Business Application Programming Interface).
© SAP AG CA210 14-9

Documentation Tools: Unit Summary

Use the documentation tools
Decide in which situation they may help you
 SAP AG 1999
© SAP AG CA210 14-10

Exercises
Unit: Documentation Tools

Topic: Documentation Download

Download the documentation for IDoc type ORDERS01
A translator will be used to format IDocs from data received from other
trading partners. It is necessary for the translator to understand the
format of the IDoc type.
1-1 Download the documentation for IDoc type ORDERS01 in ‘C' format.
© SAP AG CA210 14-11

Solutions
Unit: Documentation Tools

Topic: Documentation Download

DOCUMENTATION → IDOC TYPES
1-1-1 Enter ORDERS01.

1-1-2 Press the [C header] button.
1-1-3 Press the [Save] button after confirming the entries as c:\temp\ and IDOC.
1-1-4 You should receive a message “Export to directory ‘c:\temp\', file ‘idoc.h'
completed successfully” on the status line or as a popup window.
© SAP AG CA210 14-12

Working with an EDI Subsystem
Contents:
Translating to another Standard
Mandatory control record fields
EDI Subsystem Certification process
 SAP AG 1999
© SAP AG CA210 15-1

Working with an EDI Subsystem: Unit Objectives

List the responsibilities of an EDI Subsystem
Inform the EDI Subsystem about IDoc formats
Distinguish between mandatory and optional
control record fields
 SAP AG 1999
© SAP AG CA210 15-2

Working with an EDI Subsystem: Course Overview
Diagram (1)

Inbound Invoice
10
Payment/Remittance
MM EDI Application

 SAP AG 1999
© SAP AG CA210 15-3

Working with an EDI Subsystem: Course Overview
Diagram (2)
Work ing with

Working with an
an
EDI
EDI Sub
Subsyst
system
em 15
IDoc Monitoring 16
Archiving IDocs 17
Conclusion 19
 SAP AG 1999
© SAP AG CA210 15-4

Working with an EDI Subsystem: Business
Scenario
You want to add your EDI Subsystem

Read about which formats it must know and which
IDoc control record fields it must fill for inbound
processing.
 SAP AG 1999
© SAP AG CA210 15-5

Responsibilities of an EDI Subsystem
Partner Profile Translator Archiving
Addresses Message Handling Monitoring
Communication
 SAP AG 1999
The EDI Subsystem has very similar tasks like the IDoc interface - this time, the tasks pertain to the
individual EDI standard, not to the IDoc standard.
The most important task is to translate the two standards (IDoc and EDI standard). This is done by
the Translator
Further processing is called message handling. This is divided into inbound, outbound and status
report, just like in the IDoc interface. The status report on ANSI X.12 messages are called functional
acknowledgements. Instead of IDocs, interchange files are exchanged which may contain more than
one IDoc. A status report on such an interchange file is called an interchange acknowledgement.
The Communication with the external system is like Triggering within the IDoc Interface. Like the
R/3 System, the subsystem owns a gateway.
The Partner Profiles allows configuration processing specific to partner and application document
type. There are also subsystems, which translate into different EDI Standards, depending on the
partner.
The technical communication addresses may be compared to the TXCOM entries in the R/3 system
(see port type CPI-C).
The interchange files and EDI messages are archived in accordance with the legal requirements.
Like the IDoc status, the functional acknowledgements are monitored.
© SAP AG CA210 15-6

Mandatory Fields Inbound IDoc: Control Record
Partner Message Test? IDoc

(Number, type, role) (type, variant, function) Control Record
Partner Message Test? Inbound

Processing
(Partner
Process Code; with ALE?; Receiver of Profile)
notifications; etc.
 SAP AG 1999
In inbound processing, the IDoc interface connects control record fields to the key fields of the
partner profile. Other fields are explicitly checked during inbound processing.
Therefore, the EDI subsystem must fill certain fields of the control record. Examples:
Partner, message (three fields each) and test flag (1 field) must match one partner profile set. For
instance, the partner function must be left empty if this field is empty in the corresponding partner
profile.
direction = 2 (inbound), structure = EDI_DC40 (external control record structure of Release 4.0).
An R/3 System of Release 3.X would expect another kind of structure.
Receiver's and sender's port
IDoc Type. The IDoc interface checks if it is assigned to a message. The assignment is done via
transaction WE82, starting from the IDoc interface main menu.
Special requirements need additional fields, for example:
(customer's) extension of the IDoc type (see BC621course)
logical Address of Sender/Recipient for automatic forwarding (see “general settings”)
Express flag if inbound processing shall immediately start via an ALE function module.
Other fields will be left empty to avoid mistakes. See the appendix for a complete list of all control
record fields.
© SAP AG CA210 15-7

EDI Certification
Certified process
Purchase Order, out
Customer order, in
Order confirmation, out
P.O. Acknowledgement, in
Certified functionality
file interface w/ RFC
outbound IDoc
status report Document
inbound IDoc
System R/3 System R/3
IDoc IDoc
Transaction
Subsystem Subsystem
 SAP AG 1999
The SAP system creates purchase orders in MM. The purchase orders are transferred to the EDI
subsystem as IDocs.
The EDI subsystem translates the IDoc into an EDI message and sends the status report belonging to
that IDoc to SAP. The EDI subsystem then re-translates the EDI message into an IDoc and sends the
IDoc to SAP.
The SAP system receives customer orders in SD. The IDocs are processed and customer orders are
confirmed by order confirmations. The order confirmations are transferred to the EDI subsystem as
IDocs.
The EDI subsystem translates the IDoc into an EDI message and sends the status report belonging to
that IDoc to SAP. The EDI subsystem then re-translates the EDI message into an IDoc and sends the
IDoc to SAP.
The SAP system receives purchase order acknowledgements related to the original purchase orders
in MM. The test cycle is finally evaluated by the application that originated the whole process by
comparing the content of the original purchase order with that of the purchase order
acknowledgement.
A list of certified EDI subsystem vendors you will find in:
OSS note 41365 for releases 3.0/3.1
OSS note 114714 for releases 4.0/4.5/4.6
SAPnet, http://www.sap.com/products/compsoft/certify/index.htm
© SAP AG CA210 15-8

Working with an EDI Subsystem: Unit Summary

List the responsibilities of an EDI Subsystem
Inform the EDI Subsystem about IDoc formats
Distinguish between mandatory and optional
control record fields
 SAP AG 1999
© SAP AG CA210 15-9

Exercises
Unit: Working with an EDI Subsystem

Understand the major responsibilities of the EDI subsystem
An EDI subsystem has some to handle the movement and translation of

data from one format to another. It also has some very specific activities
that it performs.
1-1 _______________ and _______________ are the major tasks of the EDI
subsystem.
1-2 True/False. Functional acknowledgements are sent back into the SAP system.
_________________________________________________________________
1-3 True/False. EDI subsystems have partner profiles.

_________________________________________________________________
1-4 _______________ is similar to the Triggering concept within the IDoc interface.
1-5 What are the mandatory fields on the IDoc control record?
_________________________________________________________________
_________________________________________________________________
1-6 True/False. The partner (number, role, type) and message (type, variant, function)
are the keys to the partner profile and must match exactly with the control record.
_________________________________________________________________
© SAP AG CA210 15-10

Solutions
Unit: Working with an EDI subsystem
1-1 Translating and Communication are the major tasks of the EDI subsystem.
1-2 False. The results of the functional acknowledgement can be sent back into SAP
as a status record, but the functional acknowledgement itself is not sent back into
SAP.
1-3 True. EDI subsystems have partner profiles that keep such information as the
message type (ANSI 850, EDIFACT ORDERS, etc) and the version, the trading
partner identification, and where to communicate the trading partners
information.
1-4 Communication is similar to the Triggering concept within the IDoc interface.
1-5 The mandatory fields on the IDoc control record are the partner (number, type,
role), message (type, variant, function), test flag.
1-6 False. The test flag is also a key to the partner profile and must also match
exactly between the control record of the IDoc and the partner profile along with
the partner, and message fields.
© SAP AG CA210 15-11

IDoc Monitoring
Contents:
IDoc Display
IDoc Lists and Statistics
Active Monitoring
Find IDoc
Workitem Analysis
Workload Analysis
 SAP AG 1999
© SAP AG CA210 16-1

IDoc Monitoring: Unit Objectives

Describe the various monitoring tools
Execute the monitoring transactions
 SAP AG 1999
© SAP AG CA210 16-2

IDoc Monitoring: Course Overview Diagram (1)

Inbound Invoice
10
Payment/Remittance
MM EDI Application
 SAP AG 1999
© SAP AG CA210 16-3

IDoc Monitoring: Course Overview Diagram (2)
Working with an
EDI Subsystem 15
IDoc
Mon
Monitori
16
itoring
ng
Archiving IDocs 17
Conclusion 19
 SAP AG 1999
© SAP AG CA210 16-4

IDoc Monitoring: Business Scenario

company, it is your responsibility to set-up the
IDoc interface.
SmartMart has sent test IDocs to NOE Food
Company. Both companies run EDI subsystems.
For production and test use, IDocs will be traced.
You must become familiar with the IDoc
monitoring tools and feel comfortable using
them.
 SAP AG 1999
© SAP AG CA210 16-5

Monitoring Programs: Overview
Passive Monitoring Active Monitoring
Statistics “RSEIDOCM”
4711
4712
List 4713
4718
Display
 SAP AG 1999
In error cases, the IDoc interface always notifies agents actively (error handling via workflow).
In addition, the IDoc interface features three passive and one active program for IDoc monitoring.
The passive monitoring tools can be ordered according to their level of detail. The IDoc statistics
assign IDocs to status groups according to their actual status e.g. “inbound error occurring within the
IDoc interface”. The tool “IDoc list” already lists the single IDocs. Finally, the tool “IDoc display”
allows for direct access to an individual IDoc (display only). Double click goes into the details. The
passive monitoring tools can be found in the IDoc interface menu IDoc.
Active monitoring (Report RSEIDOCM) uses the status groups of IDoc statistics. It is possible to
define boundary values above which responsible agents will be notified via a work item. Active
monitoring can be understood as an individually configurable error handling.
Active monitoring is planned as a job which can be set up through standard job definition. Variants
are created in the ABAP editor.
© SAP AG CA210 16-6

Monitoring Selection Fields
Control Record
Creation Date of Partner,

Date Change message,...
List
List Statistics
Statistics All
All Monitoring
Monitoring
Programs
Programs
Display
Display Display
Display
Active
Active Monitoring
Monitoring
 SAP AG 1999
The monitoring programs are reports which select IDocs of the R/3 database according to certain
criteria. These selection fields are part of the IDoc control record.
The most important selection field is the date of IDoc creation. The IDoc statistics tool selects
according to the date of IDoc change. IDoc display offers this field as an additional selection
parameter.
All monitoring programs allow selection of IDocs according to partner and message. In IDoc
statistics, this works via the extended selection.
The highest number of selection fields is offered by the display tool. Besides the IDoc ID, one can
select according to EDI specific parameters (use of an EDI subsystem), e.g. the transmission file
within the EDI subsystem. This enables monitoring of the data flow within the EDI subsystem.
© SAP AG CA210 16-7

Monitoring Output fields
Control Record Date,

Status,
Partner,
message...
Data Records
Segments
IDoc Display
Status Records Status
Statistics
(monitoring
history)
 SAP AG 1999
All monitoring programs primarily return fields of the control record. This helps to limit the return
times.
If “repaired IDocs” are traced (function monitoring history in IDoc statistics), then the statistics tool
also checks the status records, which hold IDoc history.
When one goes directly into the display of a single IDoc, all three record types are displayed: control
record, data and status records.
Therefore, IDoc statistics selects all IDocs which have experienced a status change within the pre-set
time interval, while active monitoring selects all IDocs which were created during that time.
© SAP AG CA210 16-8

Status group - Monitoring/Statistics
4 = “successful
transfer to
target system”
13 = “repeated 12 =
transfer ok” “transfer ok”
39 = “IDoc in
target system
(ALE)”
 SAP AG 1999
For better display in active monitoring and statistics, statuses are grouped in status groups.
In the standard, the R/3 system assigns each status to a group via the “qualification” (synonym of
status group). This assignment can be changed from the entrance menu of the IDoc interface by
executing transaction WE47.
For the status groups which are delivered in the R/3 standard, refer to the extended help within the
statistics tool.
© SAP AG CA210 16-9

Graphical Representation
Statistics
History
Time Distribution
 SAP AG 1999
Graphics may be printed, downloaded to a file or copied to a clipboard for use in presentations.
© SAP AG CA210 16-10

Find IDoc
In IDoc Database or
In IDoc Archive file
Search IDoc data records

for business content
 SAP AG 1999
It is now possible to find IDocs which contain specific business data. The IDoc data records are
searched for the string of data specified. For example, search for material number 999888.
The search can look for IDocs that are still in the IDoc database or in the IDoc archive file(s).
If the search is made in the archive file, then the prerequisite of the archive file is that an index must
have been built for it. More information about the creation of the archive index is available in the
IDoc Archiving unit.
© SAP AG CA210 16-11

Workitem Analysis
Mainly relates to exception handling

Has similar functions as IDoc statistics. The main
difference is the object of statistics: workitems versus
IDocs
 SAP AG 1999
Workitems are concrete instances of generally defined single step tasks. The IDoc interface mainly
uses them for exception handling in the inbound direction. They contain the faulty IDoc or the faulty
application document which was created from the inbound IDoc.
As in IDoc statistics, the workitem analysis allows for display of a workitem belonging to a specific
task. This can be helpful if no agent could be found for the workitem, and it therefore did not appear
in anybody's inbox. Starting with the workitems, one can jump to IDoc display.
The workitem analysis is reached via transaction SWI2.
© SAP AG CA210 16-12

Workload Analysis
Determine workload with regard to

Individual employees
Positions
Jobs
Organizational Units
Provides a view of selected agents Integrated Inbox
 SAP AG 1999
Workload analysis shows the distribution of workitems across organizational units or positions.
Workload analysis can be used to determine where there might be an overload situation for one user
as opposed to a too light situation.
The workload analysis is reached via transaction SWI5.
© SAP AG CA210 16-13

IDoc Monitoring: Unit Summary

Describe the various monitoring tools
Execute the monitoring transactions
 SAP AG 1999
© SAP AG CA210 16-14

Exercises
Unit: IDoc Monitoring

Topic: IDoc Statistics

Determine what type and number of IDocs have been created and
where the IDocs are in the processing cycle
There is a need to determine how many IDocs have been processed and if
they have been processed successfully.
1-1 Determine the number of IDocs by logical message type created during the class
timeframe using the extended evaluation of IDoc statistics.
1-1-1 How many outbound orders have been created and are being sent to the
translator?
1-1-2 How many inbound invoices have successfully created invoice application
documents?
© SAP AG CA210 16-15

Solutions
Unit: IDoc Monitoring

Topic: IDoc Statistics

IDOC → IDOC STATISTICS
1-1-1 How many outbound orders have been created and are being sent to the
translator?
IDoc statistics
Last changed on From date Keep default
Last changed on To date Keep default
Changed at From time Keep default
Changed at To time Keep default
Press the Detailed Selection icon.

IDoc statistics – extended selection
Date of change From date Blank out
Date of change To date Blank out
Time changed From time Keep default
Time changed To time Keep default
Creation date From Enter starting date for class
Creation date To Enter ending date for class
Creation time From Keep default
Creation time To Keep default
Messages Fill in radio button
© SAP AG CA210 16-16

Page down using down arrow on top of screen until come ORDERS logical
message.
Check value in In transfer field.
___________________________________________________
1-1-2 Page up using the up arrow on top of screen until come to INVOIC logical
message.
Check value in Completed in application field.
___________________________________________________
© SAP AG CA210 16-17

Archiving IDocs
Contents:
The Archiving Object IDoc
Status transitions
Achievable Status
 SAP AG 1999
© SAP AG CA210 17-1

Archiving IDocs: Unit Objectives

Describe how IDocs are archived and what the
system does
Describe what is a status transition
Maintain the achievable status within the system
 SAP AG 1999
© SAP AG CA210 17-2

Archiving IDocs: Course Overview Diagram (1)

Inbound Invoice
10
Payment/Remittance
MM EDI Application
 SAP AG 1999
© SAP AG CA210 17-3

Archiving IDocs: Course Overview Diagram (2)
Working with an
EDI Subsystem 15
IDoc Monitoring 16
Archivin
iving
IDoc
IDocss
17
Conclusion 19
 SAP AG 1999
© SAP AG CA210 17-4

Archiving IDocs: Business Scenario
When the business process has been completed,

the processed IDocs should be deleted from the
database
This requires that you must archive the relevant
IDocs before they are deleted. The IDocs must
therefore be assigned an archiving status.
When configuring the IDoc Interface, you can
determine which statuses can be archived.
 SAP AG 1999
© SAP AG CA210 17-5

Archiving Object: IDoc
IDoc interface
Archiving-
programs
optional:
export
File System
 SAP AG 1999
Using the archiving programs of the IDoc interface, achievable IDocs are copied from the R/3
database to one or more archive files in the file system (operating system level). The ADK
customizing (archive development kit, extended function library) determines if they are exported to
an external medium, e.g. magnetic-optical disks.
In a second and separate step, the archived IDocs can be deleted from the R/3 database.
The Archiving programs of the IDoc Interface are called via the central archiving transaction SARA,
with argument IDOC as the Archiving object. Through the archiving object, SARA recognizes which
programs to call (object-oriented approach).
The archiving programs require a “variant” containing, for instance, the logical message and the time
period during which IDocs were created. The programs check if the actual status is achievable.
The archiving run is complete after the deleting job is finished. A complete archiving run therefore
really has moved (not copied) IDocs from the database to an external system.
© SAP AG CA210 17-6

ADK: Programs for IDoc Archiving
Archiving with RSEXARCA, RSEXARCB

using variants
periodic archiving
Deleting with RSEXARCD
implicit
separate
Reading an archive with RSEXARCR
Reloading an archive with RSEXARCL
 SAP AG 1999
There are four main tasks that can be performed:

archiving IDocs, which means a snapshot of the IDocs will be saved to the archive
deleting IDocs, an existing archive is read and the IDocs already saved will be deleted from the
database
reading an IDoc archive
reloading an IDoc archive
Archiving IDocs can be done using the reports RSEXARCA or RSEXARCB (since 3.0C):
the latter is supported for periodic usage, since the selection options do not refer to an absolute
date but refer to a relative date seen at runtime
Customizing allows the user to determine, if the deletion of archived IDocs is automatically
performed immediately after archiving them, or if the deletion has to be triggered by a batch job.
Reading an archive can be used for doing statistics.
Reloading can also be done on a single archive object, this is a feature since 3.0C and can be enabled
by indexing the archive data, which has to be done in customizing.
© SAP AG CA210 17-7

ADK: Transaction 'SARA' as Control Center
Monitoring
jobs
archives
Customizing
maximum size of archive
direct link to optical archive
logical filename
implicit deleting
Scheduling
 SAP AG 1999
Transaction 'SARA' is the control center for any archiving that is done with the ADK:
monitoring scheduled, running or finished jobs
monitoring archives, displaying their status, size, physical location,
Customization allows to control the most important properties like:
maximum size of the archive files
the logical filenames to be used, the mapping from the logical to physical filenames depending on
the various OS is done in transaction FILE
enabling of automatic delete after archiving
link to optical archive
indexing archives
© SAP AG CA210 17-8

Outbound Status Transitions, written by the R/3 system
37 31
29
26 2
20
25
42
1
30 3 18 X
39 41
32 33 38 35
40
marked Status are achievable in the SAP Standard
 SAP AG 1999
Status values can be appended to an IDoc only in well-defined combinations. The allowed combinations can be
deduced from the slide. Individual status values are:
01 IDoc created
02 Error passing data to port
03 Data passed to port OK
18 Triggering EDI subsystem OK
20 Error triggering EDI subsystem
25 Processing despite syntax error (outbound)
26 Error during syntax check of IDoc (outbound)
29 Error in ALE service
30 IDoc ready for dispatch (ALE service)
31 Error - no further processing
32 IDoc was edited
33 Original of an IDoc which was edited
35 IDoc reloaded from archive
37 IDoc added incorrectly
38 IDoc archived
39 Receipt confirmed by target system
40 Application document not created in target system
41 Application document created in target system
42 IDoc created by test transaction
X R/3 System connecting point
© SAP AG CA210 17-9

Outbound Status Transitions, written by the subsystem
4 5 7 9 11 23
X 36
24 6 8 10 12 13
15 17
22
14 16
 SAP AG 1999
For an EDI Subsystem, the allowed Status transitions are shown above. Symbols/values mean:
X R/3 System connecting point
04 Error within control information of EDI subsystem
05 Error during translation
06 Translation OK
07 Error during syntax check
08 Syntax check OK
09 Error during interchange handling
10 Interchange handling OK
11 Error during dispatch
12 Dispatch OK
13 Retransmission OK
14 Interchange Acknowledgement positive
15 Interchange Acknowledgement negative
16 Functional Acknowledgement positive
17 Functional Acknowledgement negative
22 Dispatch OK, Acknowledgement still due
23 Error during retransmission
24 Control information of EDI subsystem OK
36 Electronic signature not performed (timeout)
© SAP AG CA210 17-10

Inbound status transitions, written by the R/3 system
56 68
65
63
60
61 52
51
74
50 64 62 53
70 69 73 71 54 57
 SAP AG 1999
For inbound processing, the allowed Status transitions are shown above. Values mean:
50 IDoc added
51 Error: Application document not posted
52 Application document not fully posted
53 Application document posted
54 Error during formal application check
56 IDoc with errors added
57 Test IDoc: Error during application check
60 Error during syntax check of IDoc (inbound)
61 Processing despite syntax error (inbound)
62 IDoc passed to application
63 Error passing IDoc to application
64 IDoc ready to be passed to application
65 Error in ALE service
68 Error - no further processing
69 IDoc was edited
70 Original of an IDoc which was edited
71 IDoc reloaded from archive
73 IDoc archived
74 IDoc added by test transaction
© SAP AG CA210 17-11

Maintain Status Values - Archiving
IDoc status ..
Description ...
Processing
Direction .
Processing level .
Effect
Qualification
.
Archiving
Poss.
excluded
 SAP AG 1999
From the entrance menu of the IDoc interface, use transaction WE47 to assign different attributes to
the individual status values. One attribute is the IDoc with that status as achievable.
Use this transaction to find the general description of status values.
© SAP AG CA210 17-12

Archiving IDocs: Unit Summary

Describe how IDocs are archived and what the
system does
Describe what is a status transition
Maintain the achievable status within the system
 SAP AG 1999
© SAP AG CA210 17-13

Miscellaneous Topics
Contents:
Process Codes
System
Status
Status Groups
Display Status
tRFC
File Interface
Generate File Name
 SAP AG 1999
© SAP AG CA210 18-1

Miscellaneous Topics: Unit Objectives

Explain where to configure the system process
codes
Determine if IDoc files are incomplete
Create new selection(s) for file naming
conventions
 SAP AG 1999
© SAP AG CA210 18-2

Miscellaneous Topics: Course Overview Diagram (1)

Inbound Invoice
10
Payment/Remittance
MM EDI Application
 SAP AG 1999
© SAP AG CA210 18-3

Miscellaneous Topics: Course Overview Diagram (2)
Working with an
EDI Subsystem 15
IDoc Monitoring 16
Archiving IDocs 17
Miscellaneous
Topics
18
Conclusion 19
 SAP AG 1999
© SAP AG CA210 18-4

Miscellaneous Topics: Business Scenario

company (SmartMart or NOE Foods), you are
responsible for setting up the technical
environment and deciding if messages received
should generate an immediate message
 SAP AG 1999
© SAP AG CA210 18-5

System, Status Process Codes
System (technical) error tasks are associated with system

process codes
System process codes can
notify the receiver using an express notification
be deactivated from workflow notification
The status process codes are invoked when error statuses
are received by SAP from the external system.
Status process codes can also notify the receiver using an
express notification
 SAP AG 1999
The system process codes represent the technical error tasks that can occur during IDoc processing.
Some examples would be if the outbound file could not be opened perhaps because of permissions,
the system attempted to create the IDoc from Message Control and had a problem, the system
couldn’t find a partner profile or a message specific partner profile.
New is the ability to set an express flag and notify the IDoc administrator(s). Here we would see a
pop up box when an error has occurred. It is also possible now to deactivate the technical messages
from workflow notification. This would not be recommended however, unless you have other
monitoring in place.
The status process codes are invoked when error statuses are received by SAP from the external
system. Some examples would be if the IDoc could not successfully be translated, or perhaps we
receive a negative functional acknowledgment back from our trading partner.
New also is the ability to set an express flag and receive a pop up box indicating that the error status
has been received so that more proactive action can be taken.
© SAP AG CA210 18-6

Status Group Maintenance
Status Groups:
8 categories for outbound
8 categories for inbound
Assigned to status codes
Used in IDoc statistics monitoring tool
Stop light concept
red - processing completed with errors
yellow - processing incomplete
green - processing completed successfully
 SAP AG 1999
Each status code used in IDoc processing is assigned to one of 16 categories (8 outbound, 8
inbound).
Status codes 00 - 49 are assigned to the outbound categories which include generated, ready for
dispatch, being sent, completed in target system, with errors in interface, with errors in external
system, and with delete flag (logically deleted).
Status codes 50-99 are assigned to the inbound categories which include generated, transferred to
application, transferred to dialog, completed in application, with errors in interface, with errors in
application, and with delete flag (logically deleted).
Each of the 16 categories follow a red light concept which we see in the IDoc lists. The red are for
processing completed with errors, yellow are for processing incomplete, and green where processing
has been successfully completed.
© SAP AG CA210 18-7

Display Status
Determines the processing state for tRFC

Determines if IDoc files have been completely
processed
Where to restart if not complete
 SAP AG 1999
While inbound IDoc files are being process or if the inbound file processing is terminated early, an
entry is made in the table EDFI2. The directory path and file name are entered. Additional
information found in this table are the restart points in the file.
Normally, once an inbound file is completely and successfully processed the entry is removed from
this table. If you find entries in this table, it is a red flag that you may be missing inbound
information as some terminations have taken place.
If files of the same directory path and file name are found on this table an attempt will be made to
restart the file from the last record and last IDoc number.
You can clean up this table by resending the file from the translator or utilizing the inbound original
inbound file transaction. You would also want to investigate why files are terminating and staying in
this table.
© SAP AG CA210 18-8

Generate File Name
Add new function modules for file naming convention
 SAP AG 1999
If the SAP provided function modules for the naming of files sent to the operating system does not
meet your requirements then you can create your own function modules. The new function modules
can be added to the list of valid function modules.
When new ports are created, the new function modules will be available for use.
© SAP AG CA210 18-9

Miscellaneous Topics: Unit Summary

Explain where to configure the system process
codes
Determine if IDoc files are incomplete
Create new selection(s) for file naming
conventions
 SAP AG 1999
© SAP AG CA210 18-10

Conclusion
Contents:
Curriculum Path
 SAP AG 1999
© SAP AG CA210 19-1

Conclusion: Objectives

Configure the IDoc interface
Trace the processing of IDocs within the system
Find out the correct IDoc types for your business
processes.
 SAP AG 1999
© SAP AG CA210 19-2

Conclusion: Course Overview Diagram (1)

Inbound Invoice
10
Payment/Remittance
MM EDI Application
 SAP AG 1999
© SAP AG CA210 19-3

Conclusion: Course Overview Diagram (2)
Working with an
EDI Subsystem 15
IDoc Monitoring 16
Archiving IDocs 17
Conclusion
ion 19
 SAP AG 1999
© SAP AG CA210 19-4

Recommended Follow-up Courses
BC600
BC600 CA210
CA210 BC619
BC619
BC601
BC601 BC621
BC621
BC610
BC610 WB350 BC660
BC660
 SAP AG 1999
CA210 SAP EDI Interface - At the end of CA210 you will be able to configure and implement EDI
within the SAP standard.
BC621 SAP IDoc Development and Extension - At the end of BC621 you will be able to develop
new IDoc types or extend existing IDoc types.
BC600 SAP Business Workflow - Introduction - At the end of BC600 you will be able to use and
implement workflow templates.
BC601 SAP Business Workflow - Build and Use - At the end of BC601 you will be able to build
your own workflows within the SAP standard.
BC610 SAP Business Workflow - Programming - At the end of BC610 you will be able to program
you own workflows within the SAP standard
BC619 SAP ALE Interface - At the end of BC619 you will be able to configure and implement ALE
BC660 Data Archiving - At the end of BC660 you will be able to configure and implement archiving
WB350 Condition Technique - At the end of WB350 you will be able to configure and implement
the various condition techniques within the SAP standard.
© SAP AG CA210 19-5

Recommended Follow-up Activities
Go through the exercises using IDES data

or your own data
Read on-line documentation
Read IMG documentation
Read release notes
 SAP AG 1999
© SAP AG CA210 19-6

Conclusion: Unit Summary
Additional classes are available to supplement

the knowledge transfer from this class
 SAP AG 1999
© SAP AG CA210 19-7

Appendix
Contents:
This section contains supplementary material to be used
as reference
This material is not part of the standard course
Therefore, the instructor might not cover this during the
course presentation
 SAP AG 1999
© SAP AG CA210 20-1

Appendix
Glossary
Access sequence Sequence used by Message Control to access condition

records when searching for messages.
Access An access identifies the document fields used by the system

when searching for a condition record.
Basic type IDoc type supplied by SAP. Basic types can be modified by
customers to create a new, upward-compatible IDoc type.
Condition component Part of the hierarchy that is examined when

searching for a message. Example: the message type which is at the top of
the hierarchy: when a (new) purchase order is posted, only the messages
under the node for message type NEW are searched.
Condition record Data record in which the key fields represent the condition under
which the message is "found". The remaining fields describe the
message itself. Therefore, if one of the data records transferred
from the application matches these key fields, the message is
found and can be processed (e.g. exported as a print form or as
an electronic message.
Control record The part of an IDoc which contains the data for identifying the
sender and recipient, as well as the structure of the IDoc itself.
Each IDoc always has one control record.
Data record The part of an IDoc which contains the application data. An
IDoc usually contains more than one data record.
EDI = Electronic Data Interchange (e.g. documents) between business

partners, sometimes in separate countries, who may use different
hardware, software and communication services. The data is
formatted according to specific standards.
EDI message Standard format for a business process (for example, a

purchase order) to be handled by EDI. Various EDI standards (EDIFACT
or ANSI X12) can define different EDI messages for the same business
process.
© SAP AG CA210 20-2

EDI standard General format for data to be transferred electronically.
An EDI standard generally comprises:
EDI syntax
Data element service
Message type service
The SAP standard 'IDoc' is not yet an EDI standard, but can be compared
to other EDI standards.
EDI subsystem System which converts the SAP standard IDoc into an
EDI standard (e.g. EDIFACT, ANSI X12) and vice versa. In addition to this
task (which is carried out by the EDI subsystem converter), there are also
administration activities, e.g. archiving the transferred messages, and
technical tasks, e.g. technical connection to the subsequent system and
syntax checks for formats, to be considered.
Field catalog Contains all fields which can be selected as key fields for
condition tables in Message Control.
File interface = port type “File”
Hierarchy level Determines the position of a segment in a tree structure. A

segment carries business data in an IDoc. Dependencies in the
application data can be represented in this tree structure, i.e. the
various hierarchy levels.
IDoc Interface Definition of IDoc types and data interchange methods (port
definitions) between SAP Systems and partner systems.
IDoc type SAP format in which the data for business process is to be sent.
An IDoc is a real business process, formatted according to a
certain IDoc type.
Inbound processing Conversion and processing of data for a business process from
the time the data is received in IDoc format to the posting of the
corresponding document(s) in the SAP application.
Mapping Rules for assigning the data elements of an EDI message type to
the fields of an IDoc type.
Message Control Module designed to offer interfaces for further processing for
applications. This includes descriptions of the various data
configurations and the required actions. An example of an action
is printing a document at a certain time in German. The action is
triggered when the application transfers data that matches your
configuration.
© SAP AG CA210 20-3

Message determination A check to determine whether the application data
matches the condition records (specified in Customizing)". If this is the case,
one or more messages are "found" and can then be processed (e.g. sent
electronically).
In message determination, a search is made for the condition records using a
predefined hierarchy.
Message status record = MC record. Log record for the MC table which
describes the send status of a message in Message Control.
Message Business process (for example, a purchase order), which is

transferred in IDoc-Format between an SAP System and an
external system.
Notification If an error occurs (for example, an IDoc with incorrect syntax), a
notification is sent to one or more users. The users responsible
are defined in the IDoc Interface or indirectly via the
organization model (PD-ORG). Notifications are sent to the
integrated inbox.
Optional segment Part of an IDoc type (standard format for data communication),
which can include additional, optional data about the business
process. The segment does not therefore have to appear in an
IDoc for a specific business process.
Outbound file Contains certain IDocs to be sent for port type “File”.
Outbound processing Conversion and processing of SAP document data from posting a
document to sending the data in IDoc format.
Partner profile Definition of the general conditions for electronic data

interchange with a business partner via the IDoc Interface: which
message is sent in which direction using which method?
If a partner profile does not exist, communication with a partner
via the IDoc Interface is not possible.
Partner Communication partner for the IDoc Interface. Definition from

SD: “An individual within or outside of your own organization who is of
commercial interest and who can be contacted in the course of a business
transaction.”
Port Description of the channel used by the SAP system for

communicating with the external system during electronic data
interchange. There are various technical methods for
implementing this type of communication (port types). The
selection of the port type depends on the technical configuration
of the external system. Example: most EDI subsystems read
IDocs in the form of sequential files, i.e. the port type 'File' is
used.
© SAP AG CA210 20-4

Process code Another name for a defined processing type, e.g. a function
module or an SAP Business Workflow task. In contrast, a
defined IDoc type (standard format for data communication) is
usually assigned to a certain process code. If the processing type
for this IDoc type is to be changed, you should assign the
corresponding process code to the new processing type. Without
the process code, this IDoc type must be assigned to the new
processing type directly.
Record type An IDoc type consists of the following three record types:
- Control record
- Data record
- Status record
Required segment The part of an IDoc type which contains important application
data and must therefore exist in an IDoc for an actual business
process.
Schema A group of messages. A schema is searched for messages which

are to be processed for the specified data configuration (e.g. sent
electronically or printed).
Segment Structure that includes the application data for an IDoc from the
data records. As a result, the data can be assigned to the correct
application fields.
Status Processing status of an IDoc (SAP standard format for

electronic data interchange), for example: "generated" or "ready for
sending".
An IDoc has usually had several statuses, which are stored in the status
records and reveal information about the IDoc history. The current
(processing) status is also stored in the control record for the IDoc.
Status confirmation Report from an external system about the

processing status of business data received from the R/3 System in IDoc
format. The status confirmation is added to the IDoc in the R/3 System in
the form of status records.
Status file File that contains the status records sent to the IDoc Interface by
the EDI subsystem for outbound messages.
Status group The status group contains several statuses ("milestones" in the
process chain), so that the monitoring programs only have to
consider these groups and not each individual status. Examples:
Group 3 = outbound: IDoc in the external system
Group B = inbound: IDoc sent to application
© SAP AG CA210 20-5

Status record One of the three record types in an IDoc (SAP standard format
for electronic exchange of application data).
Each status record contains a status which corresponds to one
step in IDoc processing. This means that the number of status
records increases as the processing continues.
Translator Converts internal data formats (IDocs) into EDI messages and
vice versa. The translator is a component of the EDI subsystem.
Transmission file A data packet which contains the messages to be exchanged

electronically. The messages are EDI messages, i.e. they are
formatted according to an EDI standard (e.g. EDIFACT).
The conversion of the SAP standard IDoc into the EDI standard
is carried out by an external system (EDI-subsystem).
© SAP AG CA210 20-6

Important Menu Paths
IMG menu paths:
IDoc processing configuration:
Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button General
settings Check units of measure [Units of Measure (w/o dimension)] button.
Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Basis
Components Basis Services IDoc Interface/Electronic Data Interchange Logical system
Create logical system.
Components Basis Services IDoc Interface/Electronic Data Interchange Logical system
Assign logical system.
Components Basis Services IDoc Interface/Electronic Data Interchange Create number ranges
Number range IDocs.
Components Basis Services IDoc Interface/Electronic Data Interchange Create number ranges
Number range Ports.
Components Basis Services IDoc Interface/Electronic Data Interchange Replace technology
with SAP Business Workflow.
Components Basis Services IDoc Interface/Electronic Data Interchange Used extended
exception handling for status return.
Components Basis Services IDoc Interface/Electronic Data Interchange Delete process
technology in EDI processing of Logistics.
Components Basis Services IDoc Interface/Electronic Data Interchange Execute Workflow
Autocustomizing.
Components Basis Services IDoc Interface/Electronic Data Interchange Activate event
receiver linkage for IDoc inbound.
Components Basis Services IDoc Interface/Electronic Data Interchange IDoc administration.
Components Basis Services IDoc Interface/Electronic Data Interchange Set proposal values
for partner profiles.
Components Basis Services IDoc Interface/Electronic Data Interchange Map long names to
short names.
© SAP AG CA210 20-7

Materials Management EDI configuration:
Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button
Materials Management Purchasing Confirmations Set up Confirmation Control
[Confirmation sequence] button.
Materials Management Purchasing Messages Output Control Access Sequences Define
Access Sequence for Purchase Order.
Access Sequence for Outline Agreement.
Access Sequence for Scheduling Agreement Release/Expediter.
Materials Management Purchasing Messages Output Control Message Types Define
Message Types for Purchase Order.
Message Types for Outline Agreement.
Message Types for Scheduling Agreement Release/Expediter.
Materials Management Purchasing Messages Output Control Message Determination
Schemas Define Message Schemas for Purchase Order.
Schemas Define Message Schemas for Outline Agreement.
Schemas Define Message Schemas for Scheduling Agreement Release/Expediter.
Sales and Distribution EDI configuration:

Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Sales
and Distribution Electronic Data Interchange EDI messages Configure EDI partners
Convert External to Internal Partner Numbers.
and Distribution Electronic Data Interchange EDI messages Configure EDI partners Assign
Customer/Vendor to Sales Organization Data.
Determine Partner Functions for EDI Outbound Processing.
and Distribution Electronic Data Interchange EDI messages Handle Messages for Inbound
Orders.
Convert SAP Item Category to IDoc Item Category.
© SAP AG CA210 20-8

and Distribution Basic Functions Pricing Pricing control Define condition types
Maintain Condition Types.
and Distribution Basic Functions Pricing Pricing control Define and Assign Pricing
Procedures Maintain Pricing Procedures.
and Distribution Electronic Data Interchange Pricing Catalog Requirements Profiles.
Invoice EDI configuration:

Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Financial
Accounting Accounts Receivable and Accounts Payable Business Transactions Incoming
Invoices/Credit Memos EDI Assign Company Code for EDI Incoming Invoice.
Invoices/Credit Memos EDI Assign G/L Accounts for EDI Procedures.
Invoices/Credit Memos EDI Assign Additional Account Assignments for EDI Procedure.
Invoices/Credit Memos EDI Assign Tax Codes for EDI Procedures.
Invoices/Credit Memos EDI Enter Program Parameters for EDI Incoming Invoice.
Outbound Payments EDI configuration:

Accounting Account Receivable and Accounts Payable Business Transactions Outgoing
Payments Automatic Outgoing Payments Payment Method/Bank Selection Configure
Payment Program Company Codes Paying.
Payment Program Payment methods In company code.
Payment Program Banks Master records Enter company code value [House banks] button
Select the house bank [DME] button Enter EDI partner number [Partner profile] button.
Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] Financial
Payment Program Banks Master records Enter company code value [House banks] button
Select the house bank [DME] btton [EDI-compatible pymt meth.] button.
© SAP AG CA210 20-9

Inbound Payments EDI configuration:
Lockbox:
Accounting Bank Accounting Business Transactions Payment Transactions Lockbox
Define Posting Data.
Accounting Bank Accounting Business Transactions Payment Transactions Lockbox
Define Control Parameters.
Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button. Select
Financial Accounting Bank Accounting Bank Accounts Define Lockboxes for House Banks.
Electronic Bank Statement:

Financial Accounting Bank Accounting Business Transactions Payment Transactions
Electronic Bank Statement Create Transaction Types.
Electronic Bank Statement Assign Bank to Transaction Types and Currency Classes.
Electronic Bank Statement Create Keys for Posting Rules.
Electronic Bank Statement Assign External Transactions to Posting Rules.
Electronic Bank Statement Define Posting Rules for Electronic Bank Statement.
IDoc configuration and processing menu paths:

IDoc Monitoring:
Tools Business Communication IDoc IDoc Basis IDoc IDoc Statistics.
Tools Business Communication IDoc IDoc Basis IDoc IDoc Lists.
Tools Business Communication IDoc IDoc Basis IDoc Display IDoc.
Tools Business Communication IDoc IDoc Basis IDoc Find IDoc In Database.
Tools Business Communication IDoc IDoc Basis IDoc Find IDoc In Archive.
Port Definition:
Tools Business Communication IDoc IDoc Basis IDoc Port Definition.
Partner Profile:
Tools Business Communication IDoc IDoc Basis IDoc Partner Profile.
Tools Business Communication IDoc IDoc Basis IDoc Partner Profile Fast Data
Entry icon.
© SAP AG CA210 20-10

Testing tools:
Tools Business Communication IDoc IDoc Basis Test Test Tool.
Tools Business Communication IDoc IDoc Basis Test Outbound from MC.
Tools Business Communication IDoc IDoc Basis Test Outbound Processing from IDoc.
Tools Business Communication IDoc IDoc Basis Test Generate status file.
Tools Business Communication IDoc IDoc Basis Test Process status file.
Tools Business Communication IDoc IDoc Basis Test Inbound procg of modified outb.
file.
Tools Business Communication IDoc IDoc Basis Test Inbound procg of orig.inb. file.
Documentation:
Tools Business Communication IDoc IDoc Basis Documentation IDoc segments.
Tools Business Communication IDoc IDoc Basis Documentation IDoc types.
Tools Business Communication IDoc IDoc Basis Documentation Process codes.
Tools Business Communication IDoc IDoc Basis Documentation IDoc record types.
Tools Business Communication IDoc IDoc Basis Documentation IDoc type (parser).
Development:
Tools Business Communication IDoc IDoc Basis Development IDoc segments.
Tools Business Communication IDoc IDoc Basis Development IDoc types.
Tools Business Communication IDoc IDoc Basis Development Message types.
Tools Business Communication IDoc IDoc Basis Development IDoc type / message.
Tools Business Communication IDoc IDoc Basis Development Message / application
object.
Control:
Tools Business Communication IDoc IDoc Basis Control Outbound process codes.
Tools Business Communication IDoc IDoc Basis Control Inbound process codes.
Tools Business Communication IDoc IDoc Basis Control System process codes.
Tools Business Communication IDoc IDoc Basis Control Process code status.
Tools Business Communication IDoc IDoc Basis Control Maintain Status Values.
Tools Business Communication IDoc IDoc Basis Control Maintain Status Groups.
Tools Business Communication IDoc IDoc Basis Control Display status record.
Tools Business Communication IDoc IDoc Basis Control Generate file name
Tools Business Communication IDoc IDoc Basis Control Partner profile Outbound
Proposals.
Tools Business Communication IDoc IDoc Basis Control Partner Profile Inbound
Proposals.
Tools Business Communication IDoc IDoc Basis Control Forward Inbound.
Tools Business Communication IDoc IDoc Basis Control IDoc Administration.
© SAP AG CA210 20-11

SAP Business Workflow menu paths:
Organization Plan:
Tools Business Workflow Organizational plan Organizational plan Organization and
Staffing Create.
Staffing Change Settings Maintenance Interface.
Staffing Display.
Workflow Monitoring:
Tools Business Workflow Development Reporting Work Item Analysis_FREQ.
Tools Business Workflow Development Reporting Work Item Analysis_DEAD.
Tools Business Workflow Development Reporting Work Item Analysis_DURA.
Tools Business Workflow Development Reporting Workload Analysis.
Materials Management Master Data and Application Processing menu paths:

Logistics Materials Management Inventory Management Goods Movement Transfer
Posting.
Logistics Materials Management Material Master Material Create (General)
Immediately.
Logistics Materials Management Material Master Material Change Immediately.
Logistics Materials Management Material Master Material Display Display Current.
Logistics Materials management Purchasing Master Data Vendor Central Create.
Logistics Materials management Purchasing Master Data Vendor Central Change.
Logistics Materials management Purchasing Master Data Vendor Central Display.
Logistics Materials management Purchasing Master Data Info record Create.
Logistics Materials management Purchasing Master Data Info record Change.
Logistics Materials management Purchasing Master Data Info record Display.
Logistics Materials management Purchasing Purchase order Create Vendor/Supplying
plant known.
Logistics Materials management Purchasing Outline Agreement Scheduling Agreement
Create Vendor Known.
Delivery Schedule Maintain.
Create SA Release.
Logistics Materials Management Purchasing Master data Messages Purchase Order
Create.
Change.
Display.
Logistics Materials Management Purchasing Master data Messages Outline Agreement
Create.
© SAP AG CA210 20-12

Change.
Display.
Logistics Materials Management Purchasing Master data Messages Scheduling
Agreement Delivery Schedule Create.
Agreement Delivery Schedule Change.
Agreement Delivery Schedule Display.
SAP Office menu path:

Office Workplace Inbox Workflow.
Sales and Distribution Master Data and Application Processing menu paths:
Logistics Sales and Distribution Master data Business partners Customer Create
Complete.
Logistics Sales and Distribution Master data Business partners Customer Change
Complete.
Logistics Sales and Distribution Master data Business partners Customer Display
Complete.
Logistics Sales and Distribution Master Data Agreements Customer Material Information
Create.
Change.
Display.
Logistics Sales and Distribution Sales Order Create.
Logistics Sales and Distribution Sales Order Change. Enter the sales order number then
System Object services Linked IDocs.
Logistics Sales and Distribution Sales Order Display.
Logistics Sales and Distribution Master Data Products Assortments Assortment
Module Create.
Logistics Sales and Distribution Master Data Products Assortments General Assortment
Create.
Logistics Sales and Distribution Master Data Products Assortments Assortment
Module Assortment Assignment Maintain.
Logistics Sales and Distribution Master Data Agreements Catalogs Pricing Catalog
Create.
Accounting Master Data and Application Processing menu paths:

Accounting Financial Accounting Accounts Payable Periodic processing Payments.
Archiving menu path:

Tools Administration Administration Archiving.
© SAP AG CA210 20-13

Release Notes:
Help Release Notes [Complete list 3.0/3.1] button Release notes for 3.0D Financial
Accounting Accounts Payable EDI (Outgoing): Payment Request and Debit Notes.
Help Release Notes [Complete list 4.0] button 4.0A FI FI BL Enhancements to
Inbound Processing in Cash Management documentation icon Bank Statement EDI Inbox.
Inbound Processing in Cash Management documentation icon Lockbox EDI Inbox.
Inbound Processing in Cash Management documentation icon Account Balance Query (Polling
Information) EDI Inbox.
© SAP AG CA210 20-14

Required Fields in Inbound Processing (IDoc Control Record)
The following tables contain the fields from the IDoc control record which:
• must always be entered by the external system in structure EDI_DC40
• must be entered in special cases by the external system in structure EDI_DC40
• may be entered by the external system in structure EDI_DC40 (optional fields). If the
values are entered, they are checked by the IDoc Interface.
Fields which must always be entered by the external system:
Field Description
TABNAM Record type (structure): = “EDIDC_40” for IDocs to be processed in Release 4.0.
DIRECT Direction: = “2” (inbound).
IDOCTYP Basic type.
MESTYP Message type, e.g. ORDERS. Assigned to one or more IDoc types in the IDoc
Interface.
SNDPOR Sender port. Must be defined as a port in the receiving R/3 System.
SNDPRN Partner number of the sender. Must correspond to a partner number from the
partner profiles.
SNDPRT Partner type of the sender. “LS” (logical system) in ALE scenarios. In non-ALE
scenarios, this value is usually “KU” (customer) or “LI” (vendor).
RCVPOR Receiver port: = “SAP<SYSID>”, where <SYSID> is the ID of the receiving R/3
System, e.g. C11.
RCVPRN Partner number of the recipient. In ALE scenarios, this value is
<SYSID>CLNT<CLNT>, where <CLNT> is the client of the receiving R/3
System and <SYSID> is defined in the field RCVPOR. In non-ALE scenarios,
this value is application-specific (e.g. the value can be the organization number).
RCVPRT Partner type of the recipient “LS” (logical system) in ALE scenarios. In non-ALE
scenarios, this value is application-specific (e.g. “SD” for the SD module).
© SAP AG CA210 20-15

Fields which are entered in special cases
Field Description
CIMTYP Customer extension to a basic type. Must be present in the corresponding partner
profile.
MESFCT Message function for further message division. Must be present in the
corresponding partner profile.
MESCOD Message code for further message division. Must be present in the corresponding
partner profile.
SNDPFC Partner function for further partner division. Must be present in the corresponding
partner profile.
TEST Test flag.
EXPRSS Express flag: if this flag is set, the ALE services are called immediately in IDoc
inbound processing.
Optional fields
Field Description
MANDT Client in the R/3 System. An incorrect entry causes an error.
DOCREL R/3 release version. An incorrect entry causes an error.
OUTMOD Outbound processing mode (e.g. send IDocs individually, start subsystem). Each
value is overwritten in inbound processing.
DOCNUM IDoc ID. As the inbound IDoc is generated first in the database, each value here is
overwritten by the internal IDoc ID.
CREDAT Date of IDoc generation. Handling as in DOCNUM.
CRETIM Time of IDoc generation. Handling as in DOCNUM.
© SAP AG CA210 20-16

Typical combinations of MC fields and fields from outbound partner profiles
Process code and Message type are fields in the IDoc partner profiles, all other fields belong to
Message Control (MC):
Partner Application Message Change Message Process code

function type category
LF (VD) EA NEU REQOTE ME12
LF (VD) EF NEU ORDERS ME10
LF (VD) EF NEU X ORDCHG ME11
LF (VD) EL NEU DELINS ME14
LF (VD) EL LPET DELINS ME13
LF (VD) EL LPH1 DELFOR ME14
LF (VD) EL LPJ1 DELJIT ME13
AG (SP) V1 AN00 QUOTES SD12
AG (SP) V1 BA00 ORDRSP SD10
WE (SH) V2 LAVA DESADV DELV
WE (SH) V3 AUS1 EXPINV FT01
RE (BP) V3 RD00 INVOIC SD09 (invoice)
Example: Command file (Shellscript) - Outbound
Note: in this example, a UNIX operating system is used.
#!/bin/sh
DIRWORK=/users/ediadm
cd $DIRWORK
FILE='basename $1'
date >> $DIRWORK/ediadm.trace
echo ++ run external system with file $FILE >> $DIRWORK/ediadm.trace
# insert command to start EDI subsystem here
echo ++ removed IDoc file $FILE from application server >> $DIRWORK/ediadm.trace
chmod 666 $DIRWORK/ediadm.trace
© SAP AG CA210 20-17

Example: Command file (Shellscript) - Inbound
Note: in this example, a UNIX operating system is used.
#!/bin/sh
DIREXEC=/users/ediadm/run
DIRWORK=/users/ediadm
cd $DIRWORK
date >> $DIRWORK/ediadm.trace
echo ++ start SAP system with file $1 >> $DIRWORK/ediadm.trace
$DIREXEC/startrfc -3 -t
-d <system ID> -u <user> -p <password> -c <client>
-h <router string> -s <system number>
-g <gateway machine> -x <gateway name>
-F EDI_DATA_INCOMING
-E PATHNAME=$DIRWORK/$1
-E PORT=<subsystem>
chmod 666 $DIRWORK/ediadm.trace
Note: the script for status files only differs from the script for inbound IDocs because the
function module EDI_STATUS_INCOMING is called.
© SAP AG CA210 20-18

The port description contains the RFC and host destination. The RFC destination (R/2 destination) is
created by transaction SM59 and only serves to hold the logon data. The host destination points to an
entry in the R/3 table TXCOM.
The TXCOM entry contains both a logical destination and a gateway. This gateway contains a
sideinfo file which assigns the logical destination (from table TXCOM) to a logical unit on the R/2
side. The logical unit is part of the network architecture SNA, identifying hardware and software.
Apart from the target system, the port description also contains technical parameters, e.g. the size of
the CPI-C buffer and a flag if the R/2 system is to send an acknowledgement of receipt.
The exact function and configuration of this port type can be found in
R/2 manual S53.2 (IDoc interface): Chapter 8 of this manual describes in detail how CPI-C receiver
and sender will be set up in case of connecting to an EDI subsystem.
the R/3 OSS note 61524 and
the R/2 OSS notes 52553 and 57014.
© SAP AG CA210 20-19

Data Flow for Port Type “CPI-C”
IDoc Interface R/3
TCP/IP
1. Start Communication
CPI-C 2. Receive/Send IDocs or send
Status records
LU 6.2
IDoc Interface R/2
 SAP AG
The R/2 system is always passive: Communication is always started from the R/3 system. Data
flows are:
- Outbound, IDoc from R/3 to R/2 (R/3 sends IDocs)
- Inbound, IDoc from R/2 to R/3 (R/3 receives IDocs)
- Status report (R/3 sends and receives exactly one Status record per IDoc)
Communication uses the CPI-C commands (Common User Programming Interface). The Gateway
translates the CPI commands to
- commands of the LU 6.2-protocol on the R/2 side (IBM Mainframe)
- commands of the TCP/IP protocol on the R/3 side (Client/Server Systems).
IDocs are stored synchronously in the database.
© SAP AG CA210 20-20

P o rt T yp e A B A P
ID oc Interface
ID O C _IN B O U N D _A S Y N C H R O N O U S
O w n_function O w n _p ro g ram
?
 SA P AG 2000
The purpose of the port type ABAP programming interface or „ABAP“ is to allow individually
taylored processing of IDocs. This comprises support of translation and formatting functionality.
For outbound processing the port definition takes the name of a custom implemented function
module. Inside the function module the formatting and communication has to be implemented. The
custom function module has to follow the interface of the template function module
OWN_FUNCTION.
For inbound processing any custom program has to invoke function module
IDOC_INBOUND_ASYNCHRONOUS with the data in IDoc format.
© SAP AG CA210 20-21

Table of Notification Tasks
Process Task Role

code resolution
EDIM TS30000020 30000001 Administrator, system profile

EDIN TS70008037 70000141 Partner profile, system profile
EDIL TS70008373 30000001 Administrator, system profile
EDIP TS60001307 30000001 Administrator, system profile
EDIO TS00007989 30000013 Representative, partner profile
EDIX TS00008070 30000013 Representative, partner profile
EDII TS00008068 30000013 Representative, partner profile
EDIY TS00008074 30000013 Representative, partner profile
EDIS TS30000078 30000001 Administrator, system profile

EDIR TS70008125 30000001 Administrator, system profile
RSEIDOCM TS30200108 30200013 Party from selection screen

application TSnnnnnnnn 00000134 Representative, partner profile
All application tasks can be found by the logical message as search term!
 SAP AG 2000
The role resolutions 30000013 and 00000134 hook in on the partner profile level by evaluating the
control record. This requires a unique IDoc in the situation of error.
The role resolution 70000141 hooks in on the partner profile level by deriving that information from
the message control record (NAST record) given.
The role resolution 30000001 hooks in on the IDoc interface profile level, because of an IDoc does
not exist (e.g. file open error), or the technical nature of the error (e.g. syntax error in EDI
subsystem).
The role resolution 30200013 is specific, because the receiver of notification is given explicitly when
the progam RSEIDOCM, which may initiate the notification, is scheduled.
For convenience in the Business Workflow Explorer the notification tasks are grouped into task
groups:
TG70000015 All administration tasks mentioned in above table
TG70000016 All generic tasks of processing, e.g.Forward IDoc
TG20000010 All application tasks for notification mentioned in above table
in use with EDI in the supply-chain.
TG20000011 The 3 groups mentioned before plus inbound processes
implemented as SAP Business Workflows in the supply-chain.
© SAP AG CA210 20-22

EDI (Outgoing): Payment Orders and Debit Memos
Description
Payment orders and debit memos, which used to be sent by diskette or
telecommunications to the bank executing the order, can now be transmitted via
electronic data interchange (EDI). Thus the house bank receives payment information
quicker than before and can carry out further processing automatically.
Procedure
The application first stores all payment data in intermediate documents (IDoc). At the
same time, the payment program indicates each payment order that can be sent via EDI.
In this way, these payments are reserved for EDI: they cannot be settled via DME or
form printing.
The new payment medium program, RFFOEDI1, processes data to be sent by EDI,
storing the payment data in intermediate documents and transferring it to the EDI
subsystem.
For further information see the program documentation RFFOEDI1.
An external converter creates a standardized message out of the generated data and
sends it to the bank. Subsequent confirmation and authorization can be made within a
workflow. A reference IDoc containing the status of all processed payment IDocs is
returned to the application. Once the bank receives authorization, it begins executing
the transmitted transactions.
Change system parameters in customizing

To create payment IDocs in the application, you first have to customize the payment
program.
1. Defining the EDI house banks

In the DME data for the house bank, enter a partner number for each bank capable
of using EDI. You can use this number to refer back to the bank when making
further settings in the EDI subsystem. For further information see “Define house
banks” in the Financial Accounting Implementation Guide.
2. Defining the EDI payment methods

In the DME data for the house bank (table T012E), also maintain the EDI payment
methods for this bank.
© SAP AG CA210 20-23

Maintaining the interface to the subsystem
To send the created IDocs, you have to make additional settings in the EDI subsystem.
To make these settings, choose Administration Process technology in the System
Administration menu.
For more detailed information on the following points see the “Basis IDoc interface”
documentation.
1. First maintain the port descriptions for one or more ports throught which data
exchange is to be made. To do this, choose IDoc Port definition in the Process
Technology menu.
2. You also need to maintain the partner profiles for each house bank. To do so
choose IDoc Partner profile.
a) First maintain the general data for each bank with partner type “B”. Partner
type “B” is defined in client 000 of the standard system.
b) Define the outbound parameters and the used intermediate document type
“PEXR2001” for each message type (e.g. “PAYEXT” or “DIRDEB”)
c) Define the outbound parameters for the logical bracket around all payment
orders with message type “EUPEXR” and intermediate document type
“IDCREF01”.
d) Define the inbound parameters for the logical bracket around all payment orders
with message type “EUPEXR”. If you want the system to automatically start
processing when an IDoc is received, specify the required process code. If
possible, copy process code “FI04”, which is delivered with the standard
system, from client 000.
3. You can also define your own process codes. To do this choose Control
Inbound process code.
Setting up the workflow
Before confirming and authorizing an EDI message, you need to make sure that the
correct data has been processed and sent. To do this, you compare the reference data
returned by the subsystem with the output data. Data verification and subsequent
authorization can be made within a workflow. Workflow “WS00400051” is delivered
as a model. To use the workflow model in a different client, copy it from client “000”
with the workflow workbench tools and specify an administrator in the basic data for
the workflow.
In the workflow model, the data received is first checked in a background job to see
whether it is correct and complete. A responsible body (person, job, position) is then
determined via a role module (“00400131”) and, depending on the result of the
verification procedure, is later called to confirm the data or erase the reason for an
error.
© SAP AG CA210 20-24

Maintain the OrgObjects of the role module. For further information see the step
“Define organization objects for authorizations in workflow” in the Implementation
Guide.
Further customizing
ISO-Codes are transmitted by EDI – therefore you must maintain both fully and
correctly the tables for converting the SAP codes into ISO codes for currency, units of
measure and countries. For more information on this, access the Implementation Guide
under “Global settings” in the following chapters:
Set countries
Currencies
Check unit of measurement
Damage caused to data by errors
From an organizational point of view, you need to make sure that no other payment
medium programs access the same dataset at the same time that RFFOEDI1 accesses it.
When you schedule the payment runs in the payment program, RFFOEDI1 will be run
before all other payment medium programs.
If one or more payments could not be made via EDI, you can modify the EDI status of
the payment documents by using program RFFOEDI2. You can then either retransmit
the data by EDI or create a conventional data medium. For further information see the
documentation for program RFFOEDI2.
When using the standard workflow, you need to make sure that an administrator, who
is automatically informed of any errors that occur, is defined with the basic workflow
data.
Modifying the output data using a customer function
When you create the output data, you can access the dataset via well-defined interfaces
in order to read or change it. For this purpose, the system supports several customer
functions, which are accessed either dynamically or at predefined (static) points in time.
The function modules are stored in the enhancement “FEDI0002”.
© SAP AG CA210 20-25

1. Static calls
The following customer functions are accessed when intermediate documents
PAYEXT and DIRDEB are created, and can be used for customer modifications:
a) New EDI partner – accessing function module “901”:
For detailed information, see the documentation for the function module
EXIT_SAPLIEDP_901.
b) Save interim document – accessing function module “902”:

The function module is called up immediately before the data of an intermediate
document is written. For detailed information, see the documentation for the
function module EXIT_SAPLIEDP_902.
c) End EDI partner – accessing function module “903”:

EXIT_SAPLIEDP_903.
2. Dynamic calls
In addition to accessing at predefined points in time, you can access the current dataset
via a customer function when writing individual segments. To do this, you first need to
define at which segments the corresponding call up is to take place.
To start with you maintain table “FEDICUS”. For further information, see the step
Call up customer functions in the Financial Accounting Implementation Guide.
Depending on the message type used, the following customer functions are called up:
a) Message type REMADV – accessing function module “001”:
EXIT_SAPLIEDP_001.
b) Message type PAYEXT – accessing function module “002”:
EXIT_SAPLIEDP_002.
c) Message type DIRDEB – accessing function module “003”:
EXIT_SAPLIEDP_003.
Software/hardware requirements
You require an EDI subsystem on an EDI server.
© SAP AG CA210 20-26

System administration changes
Within a test system you can change all the data within a created IDoc. To do this you
need the following authorizations:
Object: S_’IDOCMONI’
Activity: ‘02’
All changes to an IDoc are logged in the system. To ensure that the subsystem
processes the original data of a payment IDoc, this authorization is restricted to
exceptions and is only for temporary use in the productive system.
Planning
Further notes
The EDI interface enhancement concept allows you to add further segments to the
existing IDoc structures e.g. for industry-specific or customer-specific data. These
segments must then be processed accordingly by the converter.
Example
You can transfer the segment text for an incoming invoice to the payment recipient by
defining a user-defined text segment within the position data as an enhancement and
filling it with a customer function.
For further information on Customizing see the “Accounts Receivable and Accounts
Payable” step in the Financial Accounting Implementation Guide.
“Payment orders and debit memos by EDI”.
© SAP AG CA210 20-27

EDI (Outgoing): Payment Orders and Debit Memos Program RFFOEDI1
Description
This program generates the Intermediate Documents (IDoc) for payment orders made
via EDI.
In addition to the payment media, you can output the related advice notes, EDI
accompanying sheets and payment summaries in a single program run.
For a more detailed description of the entire functionality, see EDI Outgoing Payment
Orders.
Requirements
Payment Program Configuration
The parameters that control the process for the payment medium programs are
configured in customizing. For further information on payment program configuration,
refer to the Implementation Guide.
1) Here you need to make specification for the paying company code. To do this,
select the relevant paying company code via Company codes Paying.
If payment advices are to be printed, define a SAPscript payment advice form for
use with all company code payment methods. You will find the form
F110_IN_AVIS as an example in the standard system.
You need to create and enter text modules in which the texts for the header, footer,
signature and sender are stored. These modules can be included in the forms when
they are used. To do this, select Goto Sender details, from where you can also
branch into text maintenance by selecting the modules. The names of the text can
be defined by the user, for example, F_0001_HEADER for the letter header in
company code 0001.
In addition to the payment advice form, you define here the EDI accompanying
sheet (F110_EDI_01 in the standard system).
2) Here you need to make company code specifications for the payment method. To
do this, choose Payment methods In company code, then select the paying
company code and the payment method and maintain the following data via Goto
Form data:
© SAP AG CA210 20-28

- Sorting the correspondence.
- Sorting line items
- The issuer data.
Note: The issuer details are used on the accompanying sheet and must be filled out
as follows:
Line 1 issuer name 1
Line 2 issuer name 2
Line 3 street/P.O.box
Line 4 city
3. The user must define instruction keys to control which instructions are given to the
banks that are required to carry out the payment order.
4. You need to make further specifications for creating the payment medium using the
house banks configuration functions. To do this, select your house bank from the
house bank maintenance screen after entering the paying company code via Goto
House banks, and then maintain the necessary data via Goto DME. For more
details, refer to the online documentation for the relevant fields.
Define a partner number for each house bank that offers EDI. Choose Goto to
maintain the partner profiles and the payment methods allowed for EDI for each
house bank.
5. You must define state control bank indicators which are used in the report to the
central bank.
These central bank indicators are specified when posting the invoice document in
the screen containing extra data. The “SCB/supplying country” field group of the
payments abroad data must therefore be set to required entry or optional entry fields
via the reconciliation account field status.
Setting up and changing the SAPscript forms (layout sets)
The following describes the layout of the SAPscript forms in brief. If the forms
available in the standard system are sufficient for your requirements, you can skip this
part of the documentation.
You can find further information on forms and the SAPscript editor in the guides on
styles and form maintenance and Word processing in the SAPscript editor: select the
menu path Help R/3 library.
© SAP AG CA210 20-29
1. When setting up SAPscript forms (layout sets), symbols are included in the text;
these are then replaced by actual values when the payment medium programs are
run. The fields which can be used for this are defined in the Repository and
contained in the following structures:
REGUH Settlement data from the payment program

REGUP Edited invoice items from the payment program
REGUD Formatted data for printing the forms
SPELL Amounts and digits in words
FSABE Data on accounting clerk
2.
Note: if you want the document long text for an accounting invoice document to be
printed on the payment advice form, you must make the following enhancement in
element ‘Long text for invoice document’ (specially designed for this purpose):
/: DEFINE &TXT& := ‘&REGUP-BUKRS(*)&&REGUP-BELNR(*RF0)&&REGUP-

GJAHR&’
/: INCLUDE &TXT& OBJECT BELEG ID xyz
The text ID that you must enter for this text (xyz) is defined in the configuration
menu and can be read from there. In the standard system, text ID 0003 is
predefined for the payment advice information.
Note: the check totals in the EDI accompanying sheet can be issued via structure
E1IDRS1.
3. Layout of the payment advice form (F110_IN_AVIS in the standard system)
Pages
FIRST First page per payment advice

NEXT Subsequent pages if page overflow
EDI List of advices sent per EDI
LAST Form summary section per house bank
Windows and elements

HEADER Letter header
ADDRESS Sender and address of the payee
© SAP AG CA210 20-30

PAGE Page counter
INFO Date, payment document number, etc.
INFO 605 Account number of the sender at the recipient
INFO2 Information on the next pages
REPEAT Information for the test print or proposal run
MAIN Form of address before the letter
MAIN 610-x Short text for payment method x
MAIN 610 Letter when 610-x is missing
MAIN 611-A Short text for zero clearing
MAIN 612 Alternative payee
MAIN 613 Notification takes place in order
MAIN 614 Signature
MAIN 615 Heading of the invoice item information
MAIN 620 Carryforward at page top after page overflow
MAIN 625 Invoice item information
MAIN 625-TX Long text for invoice
MAIN 625-HR Information line for Payroll Accounting
MAIN 630 Sum total
MAIN 631 User-defined text after invoice items
MAIN 675 Header for EDI advices
MAIN 676 List of EDI advices
TOTAL 630 Sum total of fixed items
CARRYFWD 635 Carryforward at page bottom for page overflow
FOOTER Letter footer
SUMMARY Form summary section
4. EDI accompanying sheet layout (F110_EDI_01 in the standard system).
Pages
FIRST EDI accompanying sheet
LAST form summary section per house bank
Windows and elements

MAIN 530 upper section of accompanying sheet
MAIN 531 total per currency
MAIN 532 lower section of sheet
SUMMARY 520 form summary section
© SAP AG CA210 20-31
Check that the SAPscript forms (layout sets) which you use have the layout described
and, in addition, check that the forms are active (both in the original language as well as
in all languages into which the forms were translated).
Periodic processing
Before the payment medium programs can be started, the payment program run must
have been successfully completed. Check the status of the payment run, or schedule
the payment medium programs by specifying one or more variants.
Note: If you want to use the ‘Payment document update’ option, the payment
documents must be updated between the time of the payment program run and the time
of the payment medium program run.
Output
Forms and lists
Printout files are created per company code and house bank. These can either be
printed via the print manager or immediately. Depending on the parameter you select,
you can print out one or more of the following:
- accompanying sheet for the payment medium

- payment advice notes (as long as the information cannot be sent via EDI)
- payment summary
- error log
The number of output files is specified in the flow trace; this makes finding and
allocating them within the print manager easier.
Note: If the program was started online, then you reach the print manager from the list
generated by selecting one of the output files displayed.
Payment advice note
As well as printing payment advice notes, they can also be sent by fax or EDI.
© SAP AG CA210 20-32

1. To send a customer or vendor a payment advice note by EDI, you need to mark the
relevant indicator Pyt adv. by EDI in the master record on the screen ‘Payment
transactions Accounting’ and to maintain partner profile.
Using an external translator, the IDoc generated by the program must be converted
into the required EDI format (e.g. REMADV) and sent.
2. To send a customer of vendor a payment advice by fax, the output type (print or
fax) selected must be defined using process interface 00002040 (Open FI). A
prerequisite is that preparations for faxing have been made in Basis.
You can also use process interface 00002050 to change the print parameters for
payment advice notes.
IDoc
Payment instructions that have previously been sent to the bank on disk or by data
transmission are now transmitted by EDI via the IDoc interface.
The payment data are stored in the system as SAP intermediate documents. An
external EDI sub-system generates a standardized message based on these IDoc and
sends it to the bank. After receiving confirmation from the payer (e.g. by electronic
signature), the bank processes the payment orders.
Relevant information on each IDoc (file format, creation date, payment amount in local
currency, payment documents used etc.) is stored in the system and, identically to
conventional data media, this can be called up using the DME management functions.
Additional DME management functions include:
• Displaying status and contents for the intermediate documents generated

• Generating a payment summary for the data medium
• Generating an accompanying sheet for the EDI message.
Error messages and error log
Termination of processing
You can find out the reason why processing was terminated (for example, production
run not yet carried out, form does not exist or is not active) by looking at the error
message or the related long text.
Internal SAPscript error

© SAP AG CA210 20-33
Check the layout of the forms. It must fulfill the above-mentioned conditions. You
cannot, for example, create a bank transfer with the check print program, since bank
transfers and checks have a completely different layout structure.
Error log
If errors, which do not terminate the payment medium program occur when creating the
output, the system lists them in the error log. If such a log is created, you must look it
over because only you can decide whether the payment medium or payment advices are
useless due to the errors the system finds, and decide whether they must be recreated
after the errors have been rectified.
During background processing, the system outputs the error log twice, in the flow trace
for the job and in a printout file. The flow trace contains information on how to rectify
the errors (from the error message long texts).
You can display the long text online by choosing the error log from the list of generated
output files and then the error message in question.
Payment orders that cannot be issued by EDI due to various errors that have occurred
are listed in the error log and marked as defective. You then have two options:
3. Send the payment orders in question to the bank using a conventional payment
medium, which is created by the program specified for this purpose in the country-
specific configuration screen for this payment method.
2. Solve the problem described in the long text in the log and then change the status of
the payment from ‘Transmission error’ to ‘Not yet transmitted’, which enables you
to restart the EDI transmission process.
© SAP AG CA210 20-34

EDI Input: Electronic Account Statement
Description
The account statement that was previously retrieved using a file interface can now be
imported by electronic data interchange (EDI). This process is automatic and allows
you to process account statement information in the system.
An account statement consists of two levels. On the summary level, the house bank
account is identified and the current account balance is transmitted. On the sales level,
transactions for the bank account are logged. Sales can be described in detail in some
messages (credit memo or debit note). In this case, only a reference to these messages
is transferred in the account statement.
EDI account statement processing takes place in three steps. In the first step, data is
automatically imported into the system and stored in bank data storage or in the
payment advice note database. In the next step, you have to plan program RFEBKA30,
which generates the postings from the account statement. The subsequent processing
transaction for the electronic bank statement (FEBA) is also available for processing
the account statement.
The account balance request (polling information) is a special kind of account

statement. No sales are transferred in this case, and information is stored in a separate
area in bank data storage. Instead of postings, payment advice notes from cash
management and forecast are generated. You can use program RFEBPI20 for
subsequent processing.
Procedure
The payee’s bank sends an account statement as an EDI message (like FINSTA in
EDIFACT standard) to its customers. The customer’s EDI subsystem generates an
intermediate document (IDoc type FINSTA01, logical message FINSTA) from the EDI
message, and the intermediate document is forwarded to the SAP system. The process
code from the partner profile controls processing of the intermediate document.
Processing
When the intermediate document is processed, its data is transferred to SAP data
storage for the account statement and the payment advice notes. Customizing will be
evaluated and this data (posting rules, company code, data for house bank account, etc.)
added to the account statement. The system then searches for the credit memos and
debit notes referenced in the account statement and stores the key from the payment
advice note database in the account statement. Information for payment clearing is
© SAP AG CA210 20-35
taken from the advice notes, which contain the document number as well as any other
criteria required by the user. If no detailed data is stored in the credit memo or the
debit note (no advice note items), the data is transferred to the account statement and
the advice note is deleted. If no errors occur, inbound processing ends with an update
of bank data storage. The postings that result from the account statement must then be
generated by a program (RFEBKA30 above).
To set up a partner for inbound account statements with EDI, you have to maintain the
partner profiles for EDI in the system administration menu. Choose Administration
Process Technology IDoc Partner profiles
You have to create a partner with process code ‘FINS’ (input parameters) for input.
The matching message name is ‘FINSTA’. For the credit memo, the process code is
‘CREA’, message ‘CREADV’, while you use process code ‘DEBA’ and message
‘DEBADV’ for the debit note.
More information is available in the documentation on EDI interfaces.
Maintain partner profiles
For the partner profile for a bank (partner type ‘B’), the bank must be ‘EDI-able’. You
indicate this by entering the EDI partner number in the ‘DME’ part of the house bank
data. This step must be completed prior to maintaining the partner profile, as only
banks marked as ‘EDI-able’ banks can be selected at that point.
Maintain house bank data
Further Customizing
correctly the tables for converting the SAP codes into ISO coded for currency, units of
measure and countries.
For more information on this, access the Implementation Guide under “Global settings”
in the following chapters:
Set countries
Currencies
© SAP AG CA210 20-36

Input of account statements by EDI is a form of an electronic bank statement.

Therefore, you have to maintain the Customizing tables for the electronic bank
statement.
When you use the account statement to request an account balance (polling
information), you must enter a planning type in the assignment of banks to activity
types. Payment advice notes for cash management and forecast are then generated
automatically.
More notes about Customizing are available in the Treasury IMG under “Cash
Management Incoming”.
Data Maintenance:
Activity types
Assign banks
Key for posting rules
Assign activities
Posting rules
Report selection
If an error occurs, standard workflow task FINSTA_ERROR is started. You must

make sure that an administrator is stored in the basic task data who can be informed
automatically if an error occurs.
Maintain task
Modification of Data with the Customer Function
When the intermediate document is processed, you can access the dataset from defined
interfaces to read or change it. To this end, customer functions are supported that can
be called up at certain times. The function modules are stored in the ‘FEDI0005’
enhancement.
The following customer functions are called when intermediate documents of type
FINSTA01 are processed and can be used for customer modifications:
1. Saving an account statement – calling function module ‘201’:
© SAP AG CA210 20-37

The function module is called immediately before the account statement data is
written. Detailed information is available in the documentation for function module
EXIT_SAPLIEDP_201 in enhancement FEDI0005.
Process SAP enhancement
2. Dynamic Calls
You can also access the dataset when individual segments for each customer
function are written. But you must first define for which segments a call is to take
place.
Maintain the table ‘FEDICUS’.
Function module 202 is called for processing the segments specified in table
FEDICUS.
Detailed information is available in the documentation for function module
EXIT_SAPLIEDP_202 FEDI0005.
Maintain table FEDICUS

Process SAP enhancement
Important note:
Enhancement FEB00001 for the electronic bank statement also runs for IDoc input
(program RFEBKA30 calls the program, where the user exit is called). It is not
necessary to transfer the code that may be stored there to one of the customer functions
in enhancement FEDI0005.
Soft/Hardware Conditions
You need an EDI subsystem on an EDI server.
Peculiarities of Installation
You can change all the data from a generated IDoc change within a test system.
However, you require the following authorization:
Activity: ‘02’
© SAP AG CA210 20-38

All changes to an IDoc are logged in the system. To ensure that the subsystem actually
processes the original data from a payment IDoc, authorization can only be granted
within a production system for exceptional cases and for a limited period of time.
Effects on Batch Input
Further notes
The enhancement concept for EDI interfaces allows you to add more segments – for
industry or customer-specific data, for instance – to existing IDoc structures. These
must be delivered by the translator.
© SAP AG CA210 20-39

EDI Inbox: Lockbox Data
Description
Lockbox, which has, until now, been retrieved from the house bank using mormal
telecommunications of a lockbox provider, can now be received using Electronic Data
Interchange (EDI). The data flows into the system automatically and you can process it
there.
EDI lockbox processing consists of three steps. In the first step, the data is
automatically imported into the system and stored in the bank data store. The next step
is to schedule the report program RFEBLB30; this uses the lockbox data to generate the
following postings. The last step is to process the lockbox data using transaction
FLB1.
Procedure
The bank or lockbox provider sends the lockbox data as an EDI message (for example:
823 in ANSI X.12 standard) to its customers. The customer’s EDI subsystem uses the
EDI message to create an interim document (IDoc type FINSTA01, logical message
LOCKBX) which it then passes on to the SAP System. Further processing of the
interim document is controlled by the transaction code form the partner agreement.
Processing
During processing, the data is transferred from the interim document into the data store
for lockbox data. The customizing is evaluated and this data (posting rules, company
code, house bank account data, and so on) is added to the lockbox data. If no errors
occur, the system updates the bank data store which completes processing. You must
then run program RFEBLB30 to generate the postings resulting from the lockbox data.
To set up a partner for entering lockbox data using EDI, you must maintain the EDI
partner agreements in the system administration menu. To do this, go to the system
administration menu and choose Administration Process Technology IDoc
Partner profile. You must then create a partner with process code “LOBX” (inbound
parameters). The matching message name is “LOCKBX”. For more information, read
the Basis EDI interface documentation.
Maintain Partner Profiles
In the case of the partner profile for bank/lockbox providers (partner type “B”), the
latter must be flagged as “EDI-compatible”. You effect this by entering the EDI
partner number in the DME part of the house bank data. You must do this BEFORE
© SAP AG CA210 20-40

maintaining the partner profile, because, in the latter step, only “EDI compatible” banks
can be selected.
Maintain House Bank Data
Further Customizing
correctly the tables for converting the SAP codes into ISO codes for currency, units of
measure and countries.
For more information on this, access the Implementation Guide under “Global settings”
in the following chapters:
Set countries
Currencies
Generally speaking, you maintain the customizing tables for lockbox processing as you
would for other lockbox formats.
For more information on customizing, go to the Treasury implementation guide and
choose Cash Management Inbox.
Maintaining Data:
Control parameters
Postings
In the event of errors, the system triggers the standard workflow task
LOCKBX_ERROR. You must ensure that the basic data for workflow includes an
administrator that can be automatically informed of any errors.
Maintain Task
© SAP AG CA210 20-41

Modification of Data Using Customer Function
During interim document processing, you can intervene to read or change the dataset
using clearly defined interfaces. To this end, the system supports a number of customer
functions, which are accessed at particular times. The function modules are stored in
the enhancement “FEDI00005”.
The following customer functions are accessed during processing of type FINSTA01
interim documents; you can use them for customer modification:
1. Saving lockbox data – accessing function module 201:

This function module is accessed immediately before the lockbox data is written.
EXIT_SAPLIEDP_201 in enhancement FEDI0005.
Edit SAP Enhancements
2. Dynamic Access
It is also possible to access the dataset when writing individual segments. You
must first define the segments where you want this to happen.
First, maintain table FEDICUS. For more information, go to the “Access customer
functions” step in the Financial Accounting implementation guide.
Function module 202 is now accessed for processing of the segments specified in
table FEDICUS. For detailed information, read the documentation on function
module EXIT_SAPLIEDP_202 in enhancement FEDI0005.
Maintain table FEDICUS

Edit SAP Enhancement
Important Note:
Enhancement FEBLB001 for lockbox data will also run when IDoc is received.
(Program RFEBLB30 accesses program RFEBLB20, where the user exits are
accessed.) This means that it is not necessary to transfer the data stored there to one of
the customer functions in enhancement FEDI0005.
Soft-/Hardware Prerequisites
You require an EDI subsystem on the EDI server
Special Features in Installation
© SAP AG CA210 20-42

You can change all the data from a generated IDoc in a test system. To do this, you
need the following authorization:
Activity: ‘02’
The system logs all the changes made to an IDoc. They ensure that the subsystem
actually does process the original data from a payment IDoc, this authorization should
only be granted in exceptional cases in productive systems, and then only for a limited
time.
Effects on Batch Input
Further notes
The Enhancement Concept for the EDI Interface enables you to add segments, such
as for industry- or customer-specific data, to the existing IDoc structure. These must
then be delivered by the converter.
© SAP AG CA210 20-43

EDI Inbox: Lockbox Data Program RFEBLB30
Description
Lockbox Service
Payment transaction in the USA are conducted almost exclusively by check. So that
checks can be deposited more quickly, the banks offer a “lockbox service” whereby
checks are sent directly from customer to the bank (lockbox). The bank credits the
checks to the payee’s account and uses file transfer to pass the information on to the
payee.
Procedure
The bank sends a data carrier to the payee, sometimes several times a day, containing
the most important information on the check (MICR number) and, where appropriate,
the document numbers from the payment memo.
This data carrier is then used to generate postings for accounts receivable and general
ledger (G/L) accounting.
Advantages of the Lockbox Service
• Quicker check collection, depositing, and crediting means better liquidity for
payees.
• Payees need spend less time on processing payments.
When you use the IDoc interface, SAP Lockbox Processing is a three step process.
- Data is read in automatically and stored in the bank data.
- You must then schedule program RFEBLB30 which processes the lockbox
data (by producing payment memos and postings, creating the check and
posting logs, generating batch input for creating new bank details).
- You can process the data further with transaction FLB1.
© SAP AG CA210 20-44

Customizing
Important Lockbox Processing Control Parameters
Here, you can maintain the parameters for the type of posting and the format of the
lockbox file. Choose “BDB” as the format here.
Customizing Entries for Posting Materials
For each lockbox, you stipulate which accounts are to be posted with which document
types and posting keys. The key is the bank account ID (destination, origin) as
supplied by the lockbox file.
© SAP AG CA210 20-45

SAP EDI Supported Messages
The following list maps the logical messages and IDoc types to the
corresponding ANSI X12 transaction sets. That is, the logical message can be
copied to the transaction sets named.
Transaction/Description Direction EDI Std Module R/3 Release IDoc Type

Logical Msg
204 Motor carrier shipment information Outbound ANSI SD 4.0A DELVRY01
CARNOT 4.5A SHPMNT03
SHPMNT 4.5A
SHPMNT03 IFTMIN
601 Export Data Declaration Outbound ANSI SD 3.0A EXPINV01
EXPINV
4.0A EXPINV02
EXPINV
4.6A EXPINV03
EXPINV
810 Invoice Inbound ANSI MM/FI 2.1A INV_ID01

INVOIC
3.0A INVOIC01
INVOIC
4.0A INVOIC02
INVOIC
810 Invoice Outbound ANSI SD 2.1A INV_ID01

INVOIC
3.0A INVOIC01
INVOIC 4.0A INVOIC02
INVOIC
812 Credit/Debit Adjustment Inbound ANSI FI 3.0A PEXR2001

CREADV
3.0A PEXR2001
DEBADV
4.5A PEXR2002
CREADV
4.5A PEXR2002
DEBADV
812 Credit/Debit Adjustment Outbound ANSI FI 3.0A PEXR2001

CREADV
3.0A PEXR2001
DEBADV
4.5A PEXR2002
CREADV
© SAP AG CA210 20-46
4.5A PEXR2002
DEBADV
820 Payment Order Outbound ANSI FI 3.0D PEXR2001

PAYEXT
4.5A PEXR2002
PAYEXT
820 Remittance Advice Outbound ANSI FI 3.0D PEXR2001

REMADV
4.5A PEXR2002
REMADV
820 Remittance Advice Inbound ANSI FI 3.0D PEXR2001

REMADV
4.5A PEXR2002
REMADV
820 Credit advice Inbound ANSI FI 3.0A GSVERF01

GSVERF
(ERS – Evaluated Receipt Settlement)
820 Account Statement Inbound ANSI FI 4.0A FINSTA01

FINSTA
823 Lockbox Inbound ANSI FI 4.0A FINSTA01

LOCKBX
830 Planning Schedule Inbound ANSI SD 3.0A DELFOR01

DELINS
w/ Release Capability 4.5A DELFOR01
DELFOR
830 Planning Schedule Outbound ANSI MM 3.0A DELFOR01

DELINS
w/ Release Capability
4.5A DELFOR01
DELFOR
832 Price Catalog Outbound ANSI SD 4.5A PRICAT01

PRICAT
840 Request for Quotes Inbound ANSI SD 2.1A ORD_ID01

REQOTE
840 Request for Quotes Outbound ANSI MM/PUR 2.1A ORD_ID01

REQOTE
© SAP AG CA210 20-47

3.0A ORDERS01
REQOTE
3.0D ORDERS02
REQOTE
4.0A ORDERS03
REQOTE
4.5A ORDERS04
REQOTE
4.6A ORDERS05
REQOTE
843 Quotes Inbound ANSI SD 2.1A ORD_ID01

QUOTES
3.0A ORDERS01
QUOTES
3.0D ORDERS02
QUOTES
4.0A ORDERS03
QUOTES
4.5A ORDERS04
QUOTES
4.6A ORDERS05
QUOTES
843 Quotes Outbound ANSI SD 2.1A ORD_ID01

QUOTES
3.0A ORDERS01
QUOTES
3.0D ORDERS02
QUOTES
4.0A ORDERS03
QUOTES
4.5A ORDERS04
QUOTES
4.6A ORDERS05
QUOTES
850 Purchase Order Inbound ANSI SD 2.1A ORD_ID01

ORDERS
3.0A ORDERS01
ORDERS
3.0D ORDERS02
ORDERS
4.0A ORDERS03
ORDERS
4.5A ORDERS04
ORDERS
4.6A ORDERS05
ORDERS
© SAP AG CA210 20-48

850 Purchase Order Outbound ANSI MM/PUR 2.1A ORD_ID01
ORDERS
3.0A ORDERS01
ORDERS
3.0D ORDERS02
ORDERS
4.0A ORDERS03
ORDERS
4.5A ORDERS04
ORDERS
4.6A ORDERS05
ORDERS
852 Stock and sale data Inbound ANSI SD 4.5A PROACT01

PROACT
852 Stock and sale data Outbound ANSI SD 4.5A PROACT01

PROACT
855 P.O. Acknowledgement Inbound ANSI MM/PUR 2.1A ORD_ID01

ORDRSP
3.0A ORDERS01
ORDRSP
3.0D ORDERS02
ORDRSP
4.0A ORDERS03
ORDRSP 4.5A ORDERS04
ORDRSP
4.6A ORDERS05
ORDRSP
855 P.O. Acknowledgement Outbound ANSI SD 2.1A ORD_ID01

ORDRSP
3.0A ORDERS01
ORDRSP
3.0D ORDERS02
ORDRSP
4.0A ORDERS03
ORDRSP
4.6A ORDERS05
ORDRSP
856 Advance Ship Notice Inbound ANSI MM 2.2A DES_ID01

DESADV
MM/PUR 3.0A DESADV01
DESADV
4.0A DELVRY01
DESADV
© SAP AG CA210 20-49

4.0A SHPMNT02
SHPMNT
4.5A DELVRY02
DESADV
4.5A SHPMNT03
SHPMNT
856 Advance Ship Notice Outbound ANSI SD 2.2A DES_ID01

DESADV
SD/SHP 3.0A DESADV01
DESADV
4.0A DELVRY01
DESADV
4.0A SHPMNT02
SHPMNT
4.5A SHPMNT03
SHPMNT
4.5A SHPMNT03
SHPADV
860 Purchase Order Change Request Inbound ANSI SD 2.2A ORD_ID01

ORDCHG
(buyer initiated) 3.0A ORDERS01
ORDCHG
3.0D ORDERS02
ORDCHG
4.0A ORDERS03
ORDCHG
4.5A ORDERS04
ORDCHG
4.6A ORDERS05
ORDCHG
860 Purchase Order Change Request Outbound ANSI MM/PUR 2.1A ORD_ID01
ORDCHG
3.0A ORDERS01
ORDCHG
3.0D ORDERS02
ORDCHG
4.0A ORDERS03
ORDCHG 4.5A ORDERS04
ORDCHG
4.6A ORDERS05
ORDCHG
861 Credit Advice (ERS) Inbound ANSI FI 3.0A GSVERF01

GSVERF
861 Credit Advice (ERS) Outbound ANSI FI 3.0A GSVERF01

GSVERF
© SAP AG CA210 20-50
862 Shipping Schedule Inbound ANSI SD 3.0A DELFOR01
DELINS
4.5A DELFOR01
DELJIT
862 Shipping Schedule Outbound ANSI MM 3.0A DELFOR01

DELINS
4.5A DELFOR01
DELJIT
864 Text Transaction Inbound ANSI 3.0A TXTRAW01

TXTRAW
865 P.O. Change Acknowledgement Inbound ANSI MM/PUR 2.1A ORD_ID01

ORDRSP
(seller initiated) 3.0A ORDERS01
ORDRSP
3.0D ORDERS02
ORDRS
4.0A ORDERS03
ORDRSP
4.6A ORDERS05
ORDRSP
865 P.O. Change Acknowledgement Outbound ANSI SD 2.1A ORD_ID01

ORDRSP
(seller initiated) 3.0A ORDERS01
ORDRSP
3.0D ORDERS02
ORDRSP
4.0A ORDERS03
ORDRSP
4.5A ORDERS04
ORDRSP
4.6A ORDERS05
ORDRSP
875 Purchase Order Inbound UCS SD 2.1A ORD_ID01

ORDERS
3.0A ORDERS01
ORDERS
3.0D ORDERS02
ORDERS
4.0A ORDERS03
ORDERS 4.5A ORDERS04
ORDERS
4.6A ORDERS05
ORDERS
© SAP AG CA210 20-51
875 Purchase Order Outbound UCS MM/PUR 2.1A ORD_ID01
ORDERS
3.0A ORDERS01
ORDERS
3.0D ORDERS02
ORDERS
4.0A ORDERS03
ORDERS 4.5A ORDERS04
ORDERS
4.6A ORDERS05
ORDERS
876 P. O. Change Request Inbound UCS SD 2.1A ORD_ID01

ORDCHG
ORDCHG
3.0D ORDERS02
ORDCHG
4.0A ORDERS03
ORDCHG
4.5A ORDERS04
ORDCHG
4.6A ORDERS05
ORDCHG
876 P. O. Change Request Outbound UCS MM/PUR 2.1A ORD_ID01

ORDCHG
ORDCHG
3.0D ORDERS02
ORDCHG
4.0A ORDERS03
ORDCHG
4.5A ORDERS04
ORDCHG
4.6A ORDERS05
ORDCHG
879 Price change Outbound ANSI SD 4.5A PRICAT01

PRICAT
880 Invoice Inbound ANSI MM/FI 2.1A INV_ID01

INVOIC
3.0A INVOIC01
INVOIC
4.0A INVOIC02
INVOIC
© SAP AG CA210 20-52

880 Invoice Outbound ANSI SD 2.1A INV_ID01
INVOIC
3.0A INVOIC01
INVOIC
4.0A INVOIC02
INVOIC
888 Item Maintenance Outbound ANSI SD 4.5A PRICAT01

PRICAT
889 Promotion Announcement Outbound ANSI SD 4.5A PRICAT01

PRICAT
940 Shipping Order Outbound ANSI SD 4.0A DELVRY01

SHPORD
Warehouse Order Outbound ANSI SD 4.0A DELVRY01
WHSORD
945 Shipping Confirmation Inbound ANSI SD 4.0A DELVRY01

SHPCON
Warehouse Confirmation Inbound ANSI SD 4.0A DELVRY01
WHSCON
947 Warehouse Inventory Inbound ANSI MM/IM 3.0A WMMBID01

WMMBXY
997 Functional Acknowledgement This is a technical confirmation. This is not exchanged via an individual
message but the status report for IDoc processing
© SAP AG CA210 20-53

CA210 EDI Interface PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

CA210 EDI Interface PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

CA210 EDI Interface

Copyright 2000 SAP AG. All rights reserved.

All rights reserved.

BC410 5 days BC440 5 days

BC095 3 days CA210 4 days

Business Integration EDI Interface

Level 2 course in a revelent application

Notes to the user

© SAP AG CA210 1-1

This course will prepare you to:

© SAP AG CA210 1-2

At the conclusion of this course, you will be able to:

© SAP AG CA210 1-3

Unit 1 Course Overview Unit 10 Inbound Invoice Processing

© SAP AG CA210 1-4

Course Overview 1 Workflow and IDocs 8

Message Control & IDocs 7 Documentation Tools 14

© SAP AG CA210 1-5

© SAP AG CA210 1-6

You are a member of the integration team (either

© SAP AG CA210 1-7

© SAP AG CA210 1-8

At the conclusion of this topic you will be able to:

© SAP AG CA210 1-9

IBUs and SBUs clockwise:

© SAP AG CA210 1-10

© SAP AG CA210 1-11

© SAP AG CA210 1-12

R/3 System Forms

Examples of systems/applications which use IDocs:

© SAP AG CA210 1-13

EDI Standard Independent

EDI Subsystem Independent

© SAP AG CA210 1-14

© SAP AG CA210 1-15

Outbound Data Inbound

Message Control Workflow

IDoc Interface & IDoc IDoc Interface &

System 2 File System 2

© SAP AG CA210 1-16

Create application document

Check Partner, find Port

© SAP AG CA210 1-17

Smartmart must setup its interface for outbound processing.

© SAP AG CA210 1-18

Pass Data to R/3 system

Check Partner, create IDoc

Create Document Ok?

© SAP AG CA210 1-19

Create Document Ok?

© SAP AG CA210 1-20

EDI is located in the Basis portion of the SAP system.

© SAP AG CA210 1-21

You are now able to:

© SAP AG CA210 1-22

© SAP AG CA210 2-1

At the conclusion of this unit you will be able to:

© SAP AG CA210 2-2

Course Overview 1 Workflow and IDocs 8

Message Control & IDocs 7 Documentation Tools 14

© SAP AG CA210 2-3

© SAP AG CA210 2-4

EDI subsystem SAP System R/3