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

FI

SD

Financial Accounting

Sales & Distribution

CO

MM

Materials PP Mgmt Production Planning

QM

Quality Mgmt

Controlling

AM

R/3

Asset Mgmt

Client / Server ABAP PM

Plant Maintenance

HR

Human Resources

PS

WF

Project System

Workflow

IS

Industry 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 3

Level 2 BC600

2 days

SAP Business Workflow - Introduction

BC095

3 days

Business Integration Technology BC400

5 days

BC601 Build and Use SAP Business Workflow

5 days

BC615

3 days BC670 2 days Programming Display Functionality 3 days

Data Archiving

ABAP Workbench Concepts and Tools BC410 5 days ABAP Workbench Programming User Dialogs (Level 3)

 SAP AG 1999

3 days

SAP Business Workflow - Programming

SAP ArchiveLink

BC660

BC610

BC440 5 days Developing Internet Applications

BC680

Workflow

Archiving

2 days

Data Retention Tool (DART)

R/3 Web Connection

Business Integration Technologies II Level 2

Level 3 BC619 3 days Application Link Enabling (ALE) Technology BC620 2 days SAP IDoc Interface Technology

BC095

3 days

Business Integration Technology

CA150 2 days Building Enterprise Solutions with SAP Components

CA210

Data Exchange

4 days

EDI Interface

BC420

5 days

Data Transfer CA925 5 days Programming with BAPIs in Visual Basic CA927 5 days R/3 Interface and BAPI Programming in C++

 SAP AG 1999

BC621 1 day SAP IDoc Interface Development

BC415 2 days Communication Interfaces in ABAP CA926 5 days Programming with BAPIs in JAVA

Interface Programming

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 Business Process

2

SD EDI Application Requirements

9

General Settings

3

Inbound Invoice Processing

10

Port Definitions

4

Payment/Remittance Process

11

Partner Profiles

5

Price Catalog, Inventory 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 TRADACOMS UCS II, WINS SEDAS

EDIFICE EIAJ EDIFER

2 X1 HL7

T C FA I ED

EDIFICE ELFE

CEFIC

PHOENIX ARUA GALIA ODETTE VDA BAI, BAI2 MultiCash S.W.I.F.T. HBCI

ATA SPEC2000 AECMA SPEC2000M  SAP AG 1999

EANCOM GENCOD TRADACOMS UCS II, WINS SEDAS

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 Document

System 2 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 Electronic Form

Workflow

Forms Feed Flows

 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

SAP System R/3

IDoc

IDoc

IDoc

EDI Subsystem

SAP System R/3

Transaction 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 Application

Data MM SD ...

Message Control

IDoc Interface & ALE Services

System 2 e.g. EDI subsystem

Inbound Application

Workflow

IDoc

File tRFC XML ...

IDoc Interface & ALE Services

System 2 e.g. EDI subsystem

 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 Create application document

Message Control

Partner Profile General Settings

Create IDoc Archive IDocs ?

Check Partner, find Port

EDI Subsystem ?

Receive Data do further processing

Port Description, Partner Profile

Documentation Tools

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?

R/3-System R/3-System

no

Error handling

 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 Subsystem?

Documentation Tools

Pass Data to R/3 system

Archive IDocs ?

Port Description, Partner Profile

Check Partner, create IDoc

Create Document

Workflow

Ok? no

Ok?

no

Partner Profile

Error handling

General Settings

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)

Course Overview

1

IDocs in the Business Process 2

Workflow and IDocs

8

SD EDI Application Requirements

9

General Settings

3

Inbound Invoice Processing

10

Port Definitions

4

Payment/Remittance Process

11

Partner Profiles

5

Price Catalog, Inventory Advice

12

MM EDI Application Requirements

6

Test of Processing

13

Message Control & IDocs

7

Documentation Tools

14

 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

Miscellaneous Topics

18

Conclusion

19

 SAP AG 1999

© SAP AG

CA210

2-4

IDoc Concept, Technical

EDI subsystem

EDI message

SAP System R/3

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 realtime 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 Section

Segment

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 segment name

Application Data 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

Status records

Application data

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 M

E1TLSUM

1

C

E1HDADR

E1ITDOC

C

M

5

2

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 Interface/ALE Services 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

IDoc Interface/ALE Services 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 Interface/ALE Services 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 SAPCLNT 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 Interface/ALE Services

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

You are now 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-20

Data Used in the Exercises Data

Data in Training System

Company Code:

3000

PO Vendor number

V100##

Purchasing Organization:

3000

Purchasing Group

000

Plant

3000

PO Material

DCC-##

PO Output type

NEU

Customer number

300##

Customer Material

CCS-##

Sales Organization

3000

Distribution Channel

10

Division

00

Order Acknowledgment Output Type

BA01

Advance Shipment Notification Output Type

LAVA

Invoice Output Type

RD00

© SAP AG

CA210

Data in IDES System

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)

Course Overview

1

Workflow and IDocs

8

IDocs in the Business Process

2

SD EDI Application Requirements

9

Genera Generall Settings

3

Inbound Invoice Processing

10

Port Definitions

4

Payment/Remittance Process

11

Partner Profiles

5

Price Catalog, Inventory Advice

12

MM EDI Application Requirements

6

Test of Processing

13

Message Control & IDocs

7

Documentation Tools

14

 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

Miscellaneous Topics

18

Conclusion

19

 SAP AG 1999

© SAP AG

CA210

3-4

Customizing via IMG R/3 Customizing IMG Basis Components Basis Services

IMG Documentation Project Documentation

IDoc Interface

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 (IDoc)

Unit of Measure (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 client 100

PR2 client 200

Logical system PR1CLNT100

Logical system 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 XYZ01

Type “Short01”

 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 At the conclusion of these exercises, you will be able to: • 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 Unit: General Settings 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 Unit: General Settings 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 Unit: General Settings 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

At the conclusion of this unit, you will be able to: 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)

Course Overview

1

Workflow and IDocs

8

IDocs in the Business Process

2

SD EDI Application Requirements

9

General Settings

3

Inbound Invoice Processing

10

Po Porrtt Definitions

4

Payment/Remittance Process

11

Partner Profiles

5

Price Catalog, Inventory Advice

12

MM EDI Application Requirements

6

Test of Processing

13

Message Control & IDocs

7

Documentation Tools

14

 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

Miscellaneous Topics

18

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 & status

File + RFC

EDI Any 2.1 on

IDoc

tRFC

ALE Any 3.0 on

IDoc & status

IDoc

CPI-C

MIME

R/2

Internet

3.0 on

3.1 on

IDoc

ABAP

Any 4.5 on

IDoc

XML

EC Any 4.6 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

1

RFC

2

4

IDoc File Status Report

out.script

Call

Read

RFC

Read

rfcexec IDoc File

3

4

2

1

3

startrfc in.script status.script

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

IDoc Interface

SAPconnect SAPoffice

MIME-email

External 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

Port 1 (e.g. Type “file”)

Port 2 (e.g. Type “file”)

External System 1

IDoc

Port 3 (e.g. Type “tRFC”)

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 At the conclusion of these exercises, you will be able to: • 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\\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\\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\\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\\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 Field Name

Input Data

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. 1-2-2 Enter the following information: Parameters for Outbound File

Field Name

Input Data

Directory

\usr\sap\\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. 1-3-2 Enter the following information: Parameters for Outbound: Trigger Field Name

Input Data

RFC Destination

SERVER_EXEC

Directory

\usr\sap\\SYS\global\

Command File

Converter_start

1-4 1-4-1 Select Inbound file tab. 1-4-2 Enter the following information: Parameters for Inbound File Field Name

Input Data

Directory

\usr\sap\\SYS\global\

Function module

Blank

Inbound file

Inbound

1-5 1-5-1 Select the Status file tab. 1-5-2 Enter the following information:

Parameters for Status File Field Name

Input Data

Directory

\usr\sap\\SYS\global\

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

At the conclusion of this unit, you will be able to: 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)

Course Overview

1

Workflow and IDocs

8

IDocs in the Business Process

2

SD EDI Application Requirements

9

General Settings

3

Inbound Invoice Processing

10

Port Definitions

4

Payment/Remittance Process

11

Partner Profiles

5

Price Catalog, Inventory Advice

12

MM EDI Application Requirements

6

Test of Processing

13

Message Control & IDocs

7

Documentation Tools

14

 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

Miscellaneous Topics

18

Conclusion

19

 SAP AG 1999

© SAP AG

CA210

5-4

Partner Profiles: Business Scenario

As a member of the integration team of your 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 message

Outbound

Port IDoc Type EDI Structure receiver of notifications

Partner Application process code message type

Partner message

Message Control Parameters

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 profile.

Partner Profile

Description 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 record

Document

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, language,...

Partn: Noefoods; Appl: EF; cndtype: NEU Process code: ME10 Message type : ORDERS

Partn: Noefoods; Port: T70CLNT810 IDoc Type: ORDERS01

Message type: ORDERS receiver of notifications:

NAST record

Message Control settings

General Outbound

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

IDoc

Error

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)

Partner: Smartmart; message: ORDERS

IDoc Type: ORDERS01

Partner: Smartmart; message: ORDERS

process code: ORDE; receiver of notifications: EDI-responsible for orders from partner Smartmart

IDoc Control record

Inbound processing

 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 Profile

Example: Inbound processing 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

You are now able to: 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 At the conclusion of these exercises, you will be able to: • 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 Unit: Partner Profiles Topic: Customer Partner Profile Creation At the conclusion of these exercises, you will be able to: • 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 Unit: Partner Profiles 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. Field Name Partn.number

Input Data 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. 1-2-2 Enter the following information: Field Name

© SAP AG

Input Data

Partn.Funct.

VD

Message Type

ORDERS CA210

5-19

1-2-3 From Partner profiles: Outbound parameters: Select Outbound options tab. 1-2-4 Enter the following information: Maintenance of outbound options Field Name

Input Data

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. 1-2-4 Enter the following information: Post processing: permitted agent Field Name

Input Data

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. 1-2-6 Enter the following information: Maintenance of outbound parameters Field Name

Input Data

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

1-3-2 Enter the following information: Message Control Field Name

Input Data

Application

EF

Message Type

NEU

Process Code

ME10

1-3-3 Press Save icon. 1-3-4 Green arrow back. 1-4 1-4-1 From the Partner Profile screen: Press [Create Inbound parameter] button. 1-4-2 Enter the following information: Maintenance of inbound parameters Field Name

Input Data

Partn.Funct.

VD

Message Type

ORDRSP

1-4-3 For Inbound options enter the following information. Inbound options Field Name

Input Data

Process Code

ORDR

Processing by function module

Trigger immediately

1-4-4 Select the Post processing: permitted agent tab.

© SAP AG

CA210

5-21

1-4-5 Enter the following information: Post processing: permitted agent Field Name

Input Data

Typ

S

Agent

Enter same value found on general partner profile

Lang.

EN

1-4-6 Press Save icon. 1-4-7 Green arrow back. 1-5 1-5-1 From the Partner Profile screen: Press [Create Inbound parameter] button 1-5-2 Enter the following information: Maintenance of inbound parameters Field Name

Input Data

Partn.Funct.

VD

Message Type

DESADV

1-5-3 For Inbound options enter the following information. Inbound Options Field Name

Input Data

Process Code

DELS

Processing by function module

Trigger immediately

1-5-4 Select the Post processing: permitted agent tab.

© SAP AG

CA210

5-22

1-5-5 Enter the following information: Post processing: permitted agent Field Name

Input Data

Typ

S

Agent

Enter same value found on general partner profile

Lang.

EN

1-5-6 Press Save icon. 1-5-7 Green arrow back.

© 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

At the conclusion of this unit, you will be able to: 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)

Course Overview

1

Workflow and IDocs

8

IDocs in the Business Process

2

SD EDI Application Requirements

9

General Settings

3

Inbound Invoice Processing

10

Port Definitions

4

Payment/Remittance Process

11

Partner Profiles

5

Price Catalog, Inventory Advice

12

MM EDI EDI Appli Application Requirements

6

Test of Processing

13

Message Control & IDocs

7

Documentation Tools

14

 SAP AG 1999

© SAP AG

CA210

6-3

MM EDI Application Requirements: 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

6-4

MM EDI Application Requirements: Business Scenario

As a member of the integration team of your 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

Vendor master data: Partner number, type, role Vendor master data: own account on vendor’s system Vendor material info: vendor’s material name

Control record Receiver

Data record

Data record

Message Control condition record, medium “6” (EDI)

E1EDKA1: Partner information E1EDP19: Material number

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” (LFB1EIKTO). 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

You are now able to: 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 At the conclusion of these exercises, you will be able to: • 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 Unit: MM EDI Application Requirements Topic: Create Outbound Purchase Order At the conclusion of these exercises, you will be able to: • 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 Unit: MM EDI Application Requirements Topic: EDI Application Setup

1-1

From the SAP Easy Access menu, open folders LOGISTICS → MATERIALS MANAGEMENT → PURCHASING → MASTER DATA → VENDOR → CENTRAL → CHANGE 1-1-1 Enter the following information: Change Vendor: Initial Screen Field Name

Input Data

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 Field Name Account at vendor

Input Data Your customer number 300##

1-1-2-3 Press Save icon. 1-1-2-4 Green arrow back to the SAP Easy Access menu. 1-2

From the SAP Easy Access menu, open folders LOGISTICS → MATERIALS MANAGEMENT → PURCHASING → MASTER DATA → INFO RECORD → CREATE

© SAP AG

CA210

6-14

1-2-1 Enter the following information: Create Purchasing Info Record: Initial Screen Field Name

Input Data

Vendor

V100##

Material

DCC-##

Purch Org

3000

Plant

3000

1-2-2 Press Enter. 1-2-3 Enter the following information: Create Info Record: General Data Field Name Vendor mat. No.

Input Data CCS-##

1-2-4 Press the [Purch org. data 1] button. 1-2-5 Enter the following information: Create Info Record: Purch. Orgainzation Data 1 Field Name

Input Data

Plnd dely time

1

Standard qty.

1

ConfContrK

0001

Tax code

I0

Net price

3.60

1-2-6 Press the Save icon. 1-2-7 Green arrow back.

© SAP AG

CA210

6-15

Solutions Unit: MM EDI Application Requirements Topic: Create Outbound Purchase Order

2-1

Create a purchase order for your vendor. From the SAP Easy Access menu, open folders LOGISTICS → MATERIALS MANAGEMENT → PURCHASING → PURCHASE ORDER → CREATE → VENDOR/SUPPLYING PLANT KNOWN 2-1-1 Enter the following information: Create Purchase Order: Initial Screen Field Name Vendor

Input Data V100##

Press [Enter]. When the Org. Data screen appears enter the following information: Create Purchase Order: Org. data Field Name

Input Data

Purchasing org.

3000

Purch. Group

000

Company

3000

Enter the following information: Create Purchase Order: Item Overview Field Name

Input Data

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 Field Name

Input Data

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.

2-1-3 Record the Purchase Order number. ___________________________________________________

© 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

At the conclusion of this unit, you will be able to: 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)

Course Overview

1

Workflow and IDocs

8

IDocs in the Business Process

2

SD EDI Application Requirements

9

General Settings

3

Inbound Invoice Processing

10

Port Definitions

4

Payment/Remittance Process

11

Partner Profiles

5

Price Catalog, Inventory Advice

12

MM EDI Application Requirements

6

Test of Processing

13

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

Miscellaneous Topics

18

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 are responsible for setting up the IDoc interface. 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 process

NAST record

IDoc Interface/ALE Services

 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 TNAPR

Table SPFLI Table TNAPR Table RSNASTED

output, e.g. IDoc 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

R S N A S T E D

Read Partner Profile Call Selection Module (by Application) Call ALE Services

'1'/ '2'

Transfer according to OUTMOD

Single IDoc

TNAPR

'3'/ '4'

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

Save

Prio = 4

OUTMOD = 1

Save

Prio = 1

OUTMOD = 1

Save

Prio = 1

OUTMOD = 3

Save

Prio = 1

OUTMOD = 4

Subsystem

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 nontriggering. 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

You are now able to: 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 At the conclusion of these exercises, you will be able to: • Complete configuration to automatically propose EDI output for all outbound messages There is an agreement between you and your trading partner to 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

1-1

From the SAP Easy Access menu, open folders LOGISTICS → MATERIALS MANAGEMENT → PURCHASING → MASTER DATA → MESSAGES → PURCHASE ORDER → CREATE 1-1-1 Enter the following information: Create Output – Condition Records: Purchase Order Field Name Output type

Input Data NEU

1-1-2 Press the [Key combination] button and choose the access based on Purch.Org./Vendor for EDI. 1-1-3 Enter the following information: Create Condition Records [New]: Fast Entry Field Name

Input Data

Purch. Organization

3000

Vendor

V100##

PartF

VD

Partner

Leave blank or V100##

Medium

6

Timing

4

Language

EN

1-1-4 Press the Save icon.

© SAP AG

CA210

7-17

1-2

From the SAP Easy Access menu, open folders LOGISTICS → MATERIALS MANAGEMENT → PURCHASING → PURCHASE ORDER → CREATE → VENDOR KNOWN/SUPPLYING PLANT KNOWN 1-2-1 Enter the following information: Create Purchase Order: Initial Screen Field Name Vendor

Input Data V100##

1-2-2 Press [Enter]. 1-2-3 When the Org. Data screen appears enter the following information: Create Purchase Order: Org. data Field Name

Input Data

Purchasing org.

3000

Purch. group

000

Company

3000

1-2-4 Enter the following information: Create Purchase Order: Item Overview Field Name

Input Data

Material

DCC-##

Quantity

100

Delv. Date

Future date

Plant

3000

1-2-5 Press [Enter]. 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 1-2-8 Press Save icon.

© SAP AG

CA210

7-18

1-3

From the SAP Easy Access menu, open folders TOOLS → BUSINESS COMMUNICATION → IDOC → IDOC BASIS → IDOC → IDOC LISTS 1-3-1 Enter the following information: IDoc lists Field Name

Input Data

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). ______________________________________________________ 1-4

From the SAP Easy Access menu, open folders LOGISTICS → SALES AND DISTRIBUTION → MASTER DATA → OUTPUT → SALES DOCUMENT → CREATE 1-4-1 Enter the following information: Create Output – Condition Records: Sales Field Name Output type

Input Data BA01

1-4-2 Press the [Key combination] button and choose the access based on Sales Organization/Customer Number. 1-4-3 Enter the following information: Create Condition Records [EDI Order Response]: Fast Entry Field Name

© SAP AG

Input Data

Sales Organization

3000

Customer

300##

PartF

SP

Partner

Leave blank or 300##

Medium

6

Timing

4

Language

EN CA210

7-19

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

From the SAP Easy Access menu, open folders LOGISTICS → SALES AND DISTRIBUTION → MASTER DATA → OUTPUT → SHIPPING → CREATE 1-5-1 Enter the following information: Create Output – Condition Records: Shipping Field Name Output type

Input Data LAVA

1-5-2 Press the [Key combination] button and choose the access based on Sales Organization/Customer Number. 1-5-3 Enter the following information: Create Condition Records [Outg.ship.notifica.]: Fast Entry Field Name

Input Data

Sales Organization

3000

Customer

300##

PartF

SH

Partner

Leave blank or 300##

Medium

6

Timing

4

Language

EN

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

© SAP AG

CA210

7-20

1-6

From the SAP Easy Access menu, open folders LOGISTICS → SALES AND DISTRIBUTION → MASTER DATA → OUTPUT → BILLING DOCUMENT → DISPLAY 1-6-1

Enter the following information:

Display Output – Condition Records: Billing Field Name Output type

Input Data RD00

1-6-2 Press [Key combination] button and choose access based on Billing type. 1-6-3 Press the Execute icon. ______________________________________________________

© 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

At the conclusion of this unit, you will be able to: 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 and IDocs

Course Overview

1

8

IDocs in the Business Process

2

SD EDI Application Requirements

9

General Settings

3

Inbound Invoice Processing

10

Port Definitions

4

Payment/Remittance Process

11

Partner Profiles

5

Price Catalog, Inventory Advice

12

MM EDI Application Requirements

6

Test of Processing

13

Message Control & IDocs

7

Documentation Tools

14

 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

Miscellaneous Topics

18

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 setting up the IDoc interface. 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?

no

Error handling

message

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

EDIN

Message Control

Message w/ NAST record

EDIM

NAST Record

EDIX

IDoc Interface

EDIO EDIP

IDoc

Message IDoc w/ syntax error IDoc 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

EDI subsystem

IDoc message

EDIL

Status Report

IDoc

EDIM

Message

IDoc Interface

EDII

IDoc

EDIY

IDoc with syntax error

IDoc

SAP application

Application

IDoc without 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

Selected agents

Role Role resolution resolution

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

Notification Concept (2)

Specific for partner and message Inbound/ Inbound/ Outbound Outbound

Specific for partner, but for all messages General General

Valid for all partners and messages General General settings settings (IDoc (IDoc Administration) Administration)

Allowed Allowed agents agents

 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

Notification Concept (3)

Possible Possible agents agents

Organization Organization structure structure

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 ...

belongs to ...

describes ...

Work center Job

Position(s)

specifically describes ...

describes ...

Owner

User

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 Supervisor

Define jobs 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

Material CSS-99 not defined in sales EDI/ALE error message Inbound partner profile not available Order part number # p-3539 Review Customer Order #7654 Review Customer Order # 7789

Rec. on 19.02.1998 19.02.1998 19.02.1998 19.02.1998 19.02.1998 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

At the conclusion of this unit, you will be able to: 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-19

Workflow and IDocs: Unit Summary

You are now able to: 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-20

Exercises Unit: Workflow and IDocs Topic: Staff Assignment in PD-ORG At the conclusion of these exercises, you will be able to: • 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

© SAP AG

Link your user id to the your appropriate position in the Organization Structure IDOC_NOTIF.

CA210

8-21

Exercises Unit: Workflow and IDocs Topic: Error Reprocessing Preparation At the conclusion of these exercises, you will be able to: • 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 Unit: Workflow and IDocs Topic: Error Reprocessing Creation At the conclusion of these exercises, you will be able to: • 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-1-1 Record the Purchase Order number. ______________________________________________________

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

© SAP AG

Use Monitoring tool, IDoc lists, to check on the status of the inbound sales order.

CA210

8-23

Exercises Unit: Workflow and IDocs Topic: Error Reprocessing At the conclusion of these exercises, you will be able to: • 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 Unit: Workflow and IDocs Topic: Staff Assignment in PD-ORG

1-1

From the SAP Easy Access menu, open folders TOOLS → SAP BUSINESS WORKFLOW → ORGANIZATIONAL PLAN→ ORGANIZATIONAL PLAN → ORGANIZATION AND STAFFING → CHANGE → SETTINGS → MAINTENANCE INTERFACE 1-1-1 Enter the following information: Organization Plan / Change Field Name

Input Data

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 TOOLS → BUSINESS COMMUNICATION → IDOC → IDOC BASIS → IDOC → PARTNER PROFILE Open folder Partner type KU. 2-1-1 Select the appropriate partner number for your group. Partner Profiles: Initial Screen Field Name Partner Number

Input Data 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-5 Press Save icon. 2-1-6 Green arrow back to the SAP Easy Access Menu. 2-2

From the SAP Easy Access menu, open folders LOGISTICS → MATERIALS MANAGEMENT → PURCHASING MASTER DATA → INFO RECORD → CHANGE 2-2-1 Enter the following information: Change Purchasing Info Record: Initial Screen Field Name

Input Data

Vendor

V100##

Material

DCC-##

Purchasing org.

3000

Plant

3000

2-2-2 Press Enter. © SAP AG

CA210

8-26

2-2-3 Enter the following information: Change Purchasing Info Record: General Data Field Name Vendor mat. No.

Input Data Add an ‘X’ to the end of your material number to make it invalid

2-2-4 Press Save icon. 2-2-5 Green arrow back to the SAP Easy Access menu.

© SAP AG

CA210

8-27

Solutions Unit: Workflow and IDocs Topic: Error Reprocessing Creation

3-1

From the SAP Easy Access menu, open folders LOGISTICS → MATERIALS MANAGEMENT → PURCHASING PURCHASE ORDER → CREATE → VENDOR/SUPPLYING PLANT KNOWN 3-1-1 Enter the following information: Create Purchase Order: Initial Screen Field Name Vendor

Input Data V100##

3-1-2 Press [Enter]. 3-1-3 When the Org. Data screen appears enter the following information: Create Purchase Order: Org. data Field Name

Input Data

Purchasing org.

3000

Purch. group

000

Company

3000

3-1-4 Enter the following information: Create Purchase Order: Item Overview Field Name

Input Data

Material

DCC-##

Quantity

100

Delv. Date

Future date

Plant

3000

3-1-5 Press [Enter]. © SAP AG

CA210

8-28

3-1-6 Press Save icon and record the Purchas Order number. _______________________________________________ 3-2 From the SAP Easy Access menu, open folders TOOLS → BUSINESS COMMUNICATION → IDOC → IDOC BASIS → 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. 3-2-1-1 Enter the following information: Modification of Outbound File Triggering Inbound Processing Field Name

Input Data

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

3-3

From the SAP Easy Access menu, open folders TOOLS → BUSINESS COMMUNICATION → IDOC → IDOC BASIS → IDOC → IDOC LISTS 3-3-1 Enter the following information: IDoc lists Field Name

Input Data

Date Created

Keep default

Time Created

Keep default

Partner number

300##

3-3-2 Press the Execute icon. 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 Unit: Workflow and IDocs Topic: Error Reprocessing

4-1

From the SAP Easy Access menu, open folders 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.

Field Name Partner number

Input Data 300##

4-1-2-3-3 From the Partner Profile screen: Press [Create Inbound parameter] button. 4-1-2-3-4 Enter the following information: Maintenance of inbound parameters Field Name

Input Data

Partner Function

SP

Message Type

ORDERS 4-1-2-3-5 For Inbound options enter the following information.

Maintenance of inbound options Field Name

© SAP AG

Input Data

Process Code

ORDE

Processing by function module

Trigger immediately CA210

8-31

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

Input Data

Typ

S

Agent

Enter same value found on general 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 4-2-3 Enter the following information: Edit Data Record Field Name

Input Data

QUALF

002

IDTNR

CCS-##

4-2-4 Press the Save icon. 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. 4-3

From the SAP Easy Access menu, open folders TOOLS → BUSINESS COMMUNICATION → IDOC → IDOC BASIS → IDOC → IDOC LISTS

© SAP AG

CA210

8-32

4-3-1 Enter the following information: IDoc lists Field Name

Input Data

Date Created

Keep default

Time Created

Keep default

Partner number

300##

4-3-2 Press the Execute icon. 4-3-3 Double-click on the inbound IDoc number. 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

At the conclusion of this unit, you will be able to: 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 Overview Diagram (1) Course Overview

1

IDocs in the Business Process

2

SD EDI Application Requirements

General Settings

3

Inbound Invoice Processing

10

Port Definitions

4

Payment/Remittance Process

11

Partner Profiles

5

Price Catalog, Inventory Advice

12

MM EDI Application Requirements

6

Test of Processing

13

Message Control & IDocs

7

Documentation Tools

14

Workflow and IDocs

8 9

 SAP AG 1999

© SAP AG

CA210

9-3

SD EDI Application Requirements: 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

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 are responsible for setting up the IDoc interface. 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

Data record

Data record

sender

Customer master data: Partner number, type, role

E1EDKA1: partner information

Customer master data: Own account at customer’s side

E1EDP19: Material number

Customer material info: 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?

no

Create workitem

R/3-System R/3-System  SAP AG 1999

© SAP AG

CA210

9-9

SD EDI Application Requirements: Unit Summary

You are now able to: 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 Topic: EDI Application Setup At the conclusion of these exercises, you will be able to: • 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 At the conclusion of these exercises, you will be able to: • Create the business application documents and IDocs necessary to simulate a business cycle. There is an agreement between you and your trading partner to 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-1-1 Record the Purchase Order number. ______________________________________________________

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 Unit: MM/SD EDI Application Requirements Topic: Advanced Ship Notice Chain At the conclusion of these exercises, you will be able to: • Create the business application documents and IDocs necessary to simulate the advanced ship notice cycle. There is an agreement between you and your trading partner to 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 Unit: SD EDI Application Requirements Topic: Outbound Invoice Process At the conclusion of these exercises, you will be able to: • Create the business application document and IDoc necessary to simulate the outbound invoice. There is an agreement between you and your trading partner to 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 Unit: SD EDI Application Requirements Topic: EDI Application Setup

1-1

From the SAP Easy Access menu, open folders LOGISTICS → SALES AND DISTRIBUTION → MASTER DATA BUSINESS PARTNERS → CUSTOMER → CHANGE → COMPLETE 1-1-1 Enter the following information: Customer Change: Initial Screen Field Name

Input Data

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 Field Name Acct at cust.

Input Data 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 Field Name Acct at cust.

Input Data Your vendor number V100##

1-1-4 Press Save icon. © SAP AG

CA210

9-15

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

From the SAP Easy Access menu, open folders LOGISTICS → SALES AND DISTRIBUTION → MASTER DATA AGREEMENTS → CUSTOMER-MATERIAL INFORMATION → CREATE 1-2-1 Enter the following information: Create Customer-Material Info Record Field Name

Input Data

Customer

300##

Sales organization

3000

Distribution channel

10

1-2-2 Press Enter. 1-2-3 Enter the following information: Create Customer-Material Info Record: Overview Screen Field Name

Input Data

Material no.

CCS-##

Cust. Material

DCC-##

1-2-4 Press the Save icon. 1-2-5 Green arrow back to the SAP Easy Access menu. 1-3

From the SAP Easy Access menu, open folders LOGISTICS → MATERIALS MANAGEMENT → PURCHASING MASTER DATA → INFO RECORD → CHANGE 1-3-1 Enter the following information: Change Purchasing Info Record: Initial Screen Field Name

© SAP AG

Input Data

Vendor

V100##

Material

DCC-##

Purchasing org.

3000

Plant

3000

CA210

9-16

1-3-2 Press Enter. 1-3-3 Enter the following information: Change Purchasing Info Record: General Data Field Name Vendor mat. No.

Input Data Remove the ‘X’ that you placed on the vendor’s material number

1-3-4 Press Save icon. 1-3-5 Green arrow back to the SAP Easy Access menu.

© SAP AG

CA210

9-17

Solutions Unit: MM/SD EDI Application Requirements Topic: Purchase Order to Sales Order with Acknowledgments Chain 1-1

From the SAP Easy Access menu, open folders LOGISTICS → MATERIALS MANAGEMENT → PURCHASING PURCHASE ORDER → CREATE → VENDOR/SUPPLYING PLANT KNOWN 1-1-1 Enter the following information: Create Purchase Order: Initial Screen Field Name Vendor

Input Data V100##

Press [Enter]. When the Org. Data screen appears enter the following information: Create Purchase Order: Org. data Field Name

Input Data

Purchasing org.

3000

Purch. Group

000

Company

3000

Enter the following information: Create Purchase Order: Item Overview Field Name

Input Data

Material

DCC-##

Quantity

100

Delv. Date

Future date

Plant

3000 Press [Enter]. Record the Purchase Order number. ______________________________________________________

© SAP AG

CA210

9-18

1-2

From the SAP Easy Access menu, open folders TOOLS → BUSINESS COMMUNICATION → IDOC → IDOC BASIS → TEST → INBOUND PROCG. OF MODIFIED OUTB. FILE 1-2-1 Enter the following information: Modification of Outbound File Triggering Inbound Processing Field Name

Input Data

Sender Partner number

300##

Sender Partner type

KU

Sender Partner function

SP

Message type

ORDERS

Sender Port

File port created in Port Definition unit exercise

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. 1-3

From the SAP Easy Access menu, open folders TOOLS → BUSINESS COMMUNICATION → IDOC → IDOC BASIS → IDOC → IDOC LISTS 1-3-1 Enter the following information: IDoc lists Field Name

Input Data

Date created

Keep default

Time created

Keep default

Partner number

300##

1-3-2 Press the Execute icon. 1-3-3 Double-click on the inbound IDoc number. 1-3-4 Record the sales order number found in the status message. ___________________________________________________ © SAP AG

CA210

9-19

1-4

From the SAP Easy Access menu, open folders 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. Press the Execute icon.

1-5

From the SAP Easy Access menu, open folders TOOLS → BUSINESS COMMUNICATION → IDOC → IDOC BASIS → TEST → INBOUND PROCG. OF MODIFIED OUTB. FILE 1-5-1 Enter the following information: Modification of Outbound File Triggering Inbound Processing Field Name

Input Data

Sender Partner number

V100##

Sender Partner type

LI

Sender Partner function

VD

Message type

ORDRSP

Sender Port

File port created in Port Definition unit exercise

1-5-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

9-20

1-6

Display the purchase order that was acknowledged with the turnaround utility. From the SAP Easy Access menu, open folders LOGISTICS → MATERIALS MANAGEMENT → PURCHASING 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 Unit: MM/SD EDI Application Requirements Topic: Advanced Ship Notice Chain

2-1

From the SAP Easy Access menu, open folders LOGISTICS → SALES AND DISTRIBUTION → SHIPPING AND TRANSPORTATION → OUTBOUND DELIVERY → CREATE → COLLECTIVE PROCESSING OF DOCUMENTS DUE FOR DELIVERY → SALES ORDERS 2-1-1 Enter the following information: Sales order, fast entry Field Name

© SAP AG

Input Data

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##

Sales organization

3000

Distribution channel

10

Division

00

2-1-1-1

Press the Execute icon.

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.

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. From the SAP Easy Access menu, open folders LOGISTICS → SALES AND DISTRIBUTION → SHIPPING AND TRANSPORTATION → PICKING→ CREATE TRANSFER ORDER → SINGLE DOCUMENT 2-1-2-1

Enter the following information:

Create Transfer Order for Delivery Note: Initial Screen Field Name

2-2

Input Data

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 has been created.

2-1-2-4

Green arrow back to the SAP Easy Access menu.

Use the turnaround test tool to bring in your Advanced ship notice. From the SAP Easy Access menu, open folders TOOLS → BUSINESS COMMUNICATION → IDOC → IDOC BASIS → TEST → INBOUND PROC. OF MODIFIED OUTBOUND FILE

© SAP AG

CA210

9-23

2-2-1 Enter the following information: Modification of Outbound File Triggering Inbound Processing Field Name

Input Data

Sender Partner number

V100##

Sender Partner type

LI

Sender Partner function

VD

Message Type

DESADV

Sender Port

File port created in Port Definition unit exercise

2-2-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. 2-3

Use Monitoring tool, IDoc lists, to determine if your Advanced ship notice processed successfully. From the SAP Easy Access menu, open folders TOOLS → BUSINESS COMMUNICATION → IDOC → IDOC BASIS → IDOC → IDOC LISTS 2-3-1 Enter the following information: IDoc lists Field Name

Input Data

Date created

Keep default

Time created

Keep default

Partner number

V100##

2-3-2 Press the Execute icon. 2-3-3 Double-click on the inbound IDoc number. 2-3-4 Record the Advanced ship notice document number found in the status message. ___________________________________________________

© SAP AG

CA210

9-24

Solutions Unit: SD EDI Application Requirements Topic: Outbound Invoice Process

3-1

From the SAP Easy Access menu, open folders LOGISTICS → SALES AND DISTRIBUTION → BILLING BILLING DOCUMENT → CREATE 3-1-1 Enter the following information: Create Billing Field Name or Data Type Delivery note number

Values Delivery note created in previous exercise

3-1-2 Press the [Execute] button. 3-1-3 Press the Save icon. 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

At the conclusion of this unit, you will be able to: 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)

1

Workflow and IDocs

8

IDocs in the Business Process

2

SD EDI Application Requirements

9

General Settings

3

Inbound Inbound Invoice Invoice Processing Processing

Port Definitions

4

Payment/Remittance Process

11

Partner Profiles

5

Price Catalog, Inventory Advice

12

MM EDI Application Requirements

6

Test of Processing

13

Message Control & IDocs

7

Documentation Tools

14

Introduction

10

 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

Miscellaneous Topics

18

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 contained in Purchase Order

General Ledger Account Additional Account Assignments

Company Code Assignment External Tax Codes

Company Code Assignment

Program Parameters

External Tax Codes

MM in Partner Profile Message Code field

Program Parameters 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

You are now able to: 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-9

Exercises Unit: Inbound Invoice Processing Topic: Inbound Invoice Configuration At the conclusion of these exercises, you will be able to: Complete the partner profile for inbound invoice processing Post an inbound invoice against the Purchase Order

There is an agreement between you and your trading partner to 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

1-1

From the SAP Easy Access menu, open folders TOOLS → BUSINESS COMMUNICATION → IDOC → IDOC BASIS → Double-click “Partner Profile”. Open folder Partner type LI 1-1-1 Select the appropriate partner number for your group Partner Profile: Initial Screen Field Name Partner number

Input Data V100##

1-1-2 From the Partner Profile screen: Press [Create Inbound parameter] button. 1-1-3 Enter the following information: Maintenance of inbound parameters Field Name

Input Data

Partn. Funct.

VD

Message Type

INVOIC

Message Code

MM

1-1-4 For Inbound options enter the following information. Maintenance of inbound parameters Field Name

1-2

Input Data

Process Code

INVM

Processing by function module

Trigger immediately

From the SAP Easy Access menu, open folders TOOLS → BUSINESS COMMUNICATION → IDOC → IDOC BASIS → TEST → INBOUND PROC. OF MODIFIED OUTBOUND FILE

© SAP AG

CA210

10-11

1-2-1 Enter the following information: Modification of Outbound File Triggering Inbound Processing Field Name

Input Data

Sender Partner

V100##

Sender Partner type

LI

Sender Partner function

VD

Message type

INVOIC

Variant

MM

Sender Port

File port created in Port Definition unit exercise

1-2-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. 1-3

From the SAP Easy Access menu, open folders TOOLS → BUSINESS COMMUNICATION → IDOC → IDOC BASIS → IDOC → IDOC LISTS 1-3-1 Enter the following information: 1-3-2 IDoc lists Field Name

Input Data

Date created

Keep default

Time created

Keep default

Partner number

V100##

1-3-2 Press the Execute icon. 1-3-3 Double-click on the inbound IDoc number. 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

At the conclusion of this unit, you will be able to: 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)

Course Overview

1

Workflow and IDocs

8

IDocs in the Business Process

2

SD EDI Application Requirements

9

General Settings

3

Inbound Invoice Processing

10

Port Definitions

4

Payment/Remittance Process

11

Partner Profiles

5

Price Catalog, Inventory Advice

12

MM EDI Application Requirements

6

Test of Processing

13

Message Control & IDocs

7

Documentation Tools

14

 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

Miscellaneous Topics

18

Conclusion

19

 SAP AG 1999

© SAP AG

CA210

11-4

Payment Remit. Process: Business Scenario

As a member of the integration team of your company SmartMart, you are responsible for setting up the IDoc interface. 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

Check

Bank Bank transfer transfer

Invoice Invoice

Vendor Vendor

Direct Debit Credit Credit Advice Advice El. El. bank bank statement statement

Bank Bank // Lockbox Lockbox provider provider Payee Payee (Beneficiary) (Beneficiary)

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

Credit Advice

PEXR2002/CREADV

Debit Advice

PEXR2002/DEBADV

Remittance Adv

PEXR2002/REMADV

Account Stmt

FINSTA01/FINSTA-FST

Lockbox

FINSTA01/LOCKBX

Account Info

FINSTA01/FINSTA-ACP

Remittance Adv

PEXR2002/REMADV

Payment Order

PEXR2002/PAYEXT

Direct Debit

PEXR2002/DIRDEB

Paymt Control

IDCREF01/EUPEXR

Accounting Advices

Bank Data Buffer

SAPSystem Documents

Treasury Advices

Payment Database

 SAP AG 1999

© SAP AG

CA210

11-7

Invoice and Payment Process

customer incoming invoice

remittance advice

payment program

collective payment

vendor

bank

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_, 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 x

R/3 Automatic Payment Transactions: Parameters Parameters

Edit

Goto

Environment

Systems

Help

?

x X

Selection

Print programs

Run date

22 . 06 . 1998

Identification

PAY1

Additional log….

B.ex/pmt request

Posting date

22 . 06 . 1998

Docs entered up to

22 . 06 . 1998

Customer items due by

Payments control Company codes

3000

Pmnt meths

Next posting date

C

30.08.1998

ENTRY Accounts Vendors (from / to)

10001

Entry

1

Foreign currencies

Customers (from / to

Rat types for conversn

10099

1

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

R/3 Automatic Payment Transactions: Parameters Parameters

Edit

Goto

Environment

Systems

Help

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

R/3 Automatic Payment Transactions: Parameters Parameters

Edit

Goto

Environment

Systems

Help

?

x X

Selection

Print programs

Run date

22 . 06 . 1998

Identification

PAY1

Additional log….

Posting date

22 . 06 . 1998

Docs entered up to

Required logging type

3000

22 . 06 . 1998

Customer items due by

Additional Log

Payments control Company codes

B.ex/pmt request

x

Pmnt meths

Next posting date

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)

10001

Accounts Vendors (from / to)

10001

1

Rat types for conversn

10099

1

1

Foreign currencies

Customers (from / to Entry

Entry

CustomersENTRY (from / to

10099

1

x X Entry

1

Entry

1 0

0

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) x

R/3 Automatic Payment Transactions: Parameters Variant

Edit

Goto

System

Help

?

x Variant attributes

X

i

Program run date

Identification feature

22 . 06 . 1998 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) x

R/3 Automatic Payment Transactions: Parameters 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 x

R/3 Automatic Payment Transactions: Payment Run Edit

Goto

Environment

Systems

Help

?

x Status

Proposal

Parameters

Run date

22 . 06 . 1998

Identification

PAY1

Print programs

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 x

R/3 Automatic Payment Transactions: Payment Run Edit

Goto

Environment

Systems

Help

?

x Status

Log default value

Run date

22 . 06 . 1998

Identification

PAY1

Default value

Pmnt run

Print programs

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 EDI Interface Interface

SAP Server

Customer

EDI Server

EDI/ANSI Lockbox Data Flow

SAP-User IDOC IDOC

Pmt. Advice Table Remittance Remittance Advice Advice

Bank Stmt. Table

ANSI ANSI 823 823Message Message

Lockbox LockboxProgram Program

Bank

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

At the conclusion of this unit, you will be able to: 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) Course Overview

1

Workflow and IDocs

8

IDocs in the Business Process

2

SD EDI Application Requirements

9

General Settings

3

Inbound Invoice Processing

10

Port Definitions

4

Payment/Remittance Process

11

Partner Profiles

5

MM EDI Application Requirements

6

Test of Processing

13

Message Control & IDocs

7

Documentation Tools

14

Price Catalog, Catalog, Inventory 12 Advice

 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

Miscellaneous Topics

18

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 PR A S

Material or Article and price

PRICAT Creation Who gets the information ? Which data do they get ? When do they get the data ?

IDocs

What is the appropriate format

IDocs

tem sys b u IS ED

ALE Layer

IDoc File

Convert IDoc data into PRICAT format

Sender PRICAT

rs Use

Processing of the PRICAT Message

Recipients Passing on of the EDI data from the database to a third system

PRICAT 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

You are now able to: 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 At the conclusion of these exercises, you will be able to: Complete the configuration necessary to create the Price Catalog Create the PRICAT IDoc

There is an agreement between you and your trading partner to 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

1-1

From the SAP Easy Access menu, open folders SALES AND DISTRIBUTION → MASTER DATA → PRODUCTS → ASSORTMENTS → ASSORTMENT → MODULE → CREATE 1-1-1 Enter the following information: Assortment Module Create: Initial Screen Field Name

Input Data

Module type

Standard module

Module

Group##

1-1-2 Select the [Items] button and enter the following information: Assortment Module Create: Items Field Name

Input Data

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 1-2

From the SAP Easy Access menu, open folders SALES AND DISTRIBUTION → MASTER DATA → PRODUCTS → ASSORTMENTS → ASSORTMENT → GENERAL ASSORTMENT → CREATE

© SAP AG

CA210

12-11

1-2-1 Enter the following information: Assortment Create: Initial Screen Field Name Assortment

Input Data Group##

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

Input 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 Field Name Matl group

Input Data 010

1-2-4 Select the [Assortment user] button and enter the following information: Assortment Create: Assortment user Field Name

Input Data

Customer

300##

Sorg.

3000

DC

10

Division

00

1-2-5 Save and green arrow back. 1-3

From the SAP Easy Access menu, open folders SALES AND DISTRIBUTION → MASTER DATA → PRODUCTS → ASSORTMENTS → ASSORTMENT → MODULE → ASSORTMENT ASSIGNENT → MAINTAIN

© SAP AG

CA210

12-12

1-3-1 Enter the following information: Assortment Create: Initial Screen Field Name Module

Input Data Group##

1-3-2 Select the [Items] button and enter the following information: Assortment Create: Basic Data Field Name Assortment

Input Data Group##

1-3-3 Select the [Skip all errors] button. 1-3-4 Save and green arrow back. 1-4

From the SAP Easy Access menu, open folders 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: Field Name

© SAP AG

Input Data

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 CA210

12-13

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

From the SAP Easy Access menu, open folders SALES AND DISTRIBUTION → MASTER DATA → AGREEMENTS →CATALOGS → PRICING CATALOG → CREATE 1-5-1 Enter the following information: PRICAT processing: Manual creation Field Name

Input Data

Sales organization

3000

Distribution channel

10

Division

00

Assortment

Group##

Module

Group##

Profile

GR##

1-5-2 Press the Execute icon. 1-5-3 Press the [Create PRICAT] button. 1-5-4 Enter the following information: Enter transfer parameters Field Name

Input Data

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. 1-6

From the SAP Easy Access menu, open folders TOOLS → BUSINESS COMMUNICATION → IDOC → IDOC BASIS → IDOC → IDOC LISTS

© SAP AG

CA210

12-14

1-6-1 Enter the following information: IDoc lists Field Name

© SAP AG

Input Data

Date created

Keep default

Time created

Keep default

Partner number

300##

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

At the conclusion of this unit, you will be able to: 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)

Course Overview

1

Workflow and IDocs

8

IDocs in the Business Process

2

SD EDI Application Requirements

9

General Settings

3

Inbound Invoice Processing

10

Port Definitions

4

Payment/Remittance Process

11

Partner Profiles

5

Price Catalog, Inventory Advice

12

MM EDI Application Requirements

6

Message Control & IDocs

7

Test Test of of Proce Processing ssing

Documentation Tools

13 14

 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

Miscellaneous Topics

18

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 WE16

WE14, WE19

External System (Port)

Outbound IDoc File

WE12

Inbound IDoc File

WE17 WE18 Status report

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 IDoc based on the Message Control record. With transaction WE14, program RSEOUT00 test the forwarding of an IDoc to the receiver system, e.g. as preparations for the inbound testing EDI processing with an EDI subsystem

Application Message Control WE15

IDoc Interface WE14 WE19

Outbound 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 inbound processing of an IDoc by coping an outbound file, and handle the copy as an inbound file.

Application Workflow WE19

With transaction WE16, test the inbound processing of an IDoc by picking-up any inbound file. With transaction WE19, Test Tool test the inbound processing of an IDoc by creating the IDoc in an editor and feeding the result to the inbound process.

IDoc Interface WE16

Outbound IDoc file

WE12

Inbound IDoc file

 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 the reactions in behalf of the status report. With transaction WE18, create a status report and initiate the processing as with transaction WE17. With transaction WE19, Test Tool create a status report as IDoc type SYSTAT01 and follow inbound testing features.

Application Workflow WE19 WE19

IDoc Interface WE17 WE18

Status 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 (for Inbound only)

mass testing

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

You are now able to: 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 At the conclusion of these exercises, you will be able to: 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

1-1

From the SAP Easy Access menu, open folders TOOLS → BUSINESS COMMUNICATION → IDOC → IDOC BASIS → 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. From the SAP Easy Access menu, open folders TOOLS → BUSINESS COMMUNCATION → IDOC → IDOC BASIS → IDOC → IDOC LISTS

© SAP AG

CA210

13-14

1-2-1 Enter the following information: IDoc lists Field Name

Input Data

Date created

Keep default

Time created

Keep default

Partner number

300##

1-2-2 Press the Execute icon. 1-2-3 Double-click on the inbound IDoc number. 1-2-4 Record the sales order number found in the status message. _______________________________________________

© 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

At the conclusion of this unit, you will be able to: 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)

1

Workflow and IDocs

8

IDocs in the Business Process

2

SD EDI Application Requirements

9

General Settings

3

Inbound Invoice Processing

10

Port Definitions

4

Payment/Remittance Process

11

Partner Profiles

5

Price Catalog, Inventory Advice

12

MM EDI Application Requirements

6

Test of Processing

13

Message Control & IDocs

7

Documentation Tools

14

Introduction

 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

Miscellaneous Topics

18

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

Rels. 3.0

E2...001

Field 1

Field 3 Field 4

internal external

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

You are now able to: 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 At the conclusion of these exercises, you will be able to: 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

© SAP AG

Download the documentation for IDoc type ORDERS01 in ‘C' format.

CA210

14-11

Solutions Unit: Documentation Tools Topic: Documentation Download

1-1

From the SAP Easy Access menu, open folders TOOLS → BUSINESS COMMUNICATION → IDOC → IDOC BASIS → 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

At the conclusion of this unit, you will be able to: 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)

1

Workflow and IDocs

8

IDocs in the Business Process

2

SD EDI Application Requirements

9

General Settings

3

Inbound Invoice Processing

10

Port Definitions

4

Payment/Remittance Process

11

Partner Profiles

5

Price Catalog, Inventory Advice

12

MM EDI Application Requirements

6

Test of Processing

13

Message Control & IDocs

7

Documentation Tools

14

Course Overview

 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

Miscellaneous Topics

18

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 Addresses

Translator Message Handling

Archiving 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 Control Record

Test?

Inbound Processing (Partner Profile)

(Number, type, role) (type, variant, function)

Partner

Message

Process Code; with ALE?; Receiver of 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 inbound IDoc

Document

System R/3

System R/3

IDoc

Subsystem

IDoc Transaction

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

You are now able to: 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

At the conclusion of these exercises, you will be able to: 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

At the conclusion of this unit, you will be able to: Describe the various monitoring tools Execute the monitoring transactions

 SAP AG 1999

© SAP AG

CA210

16-2

IDoc Monitoring: Course Overview Diagram (1)

Course Overview

1

Workflow and IDocs

8

IDocs in the Business Process

2

SD EDI Application Requirements

9

General Settings

3

Inbound Invoice Processing

10

Port Definitions

4

Payment/Remittance Process

11

Partner Profiles

5

Price Catalog, Inventory Advice

12

MM EDI Application Requirements

6

Test of Processing

13

Message Control & IDocs

7

Documentation Tools

14

 SAP AG 1999

© SAP AG

CA210

16-3

IDoc Monitoring: Course Overview Diagram (2)

Working with an EDI Subsystem

IDoc

Mon Monitori itoring ng

15 16

Archiving IDocs

17

Miscellaneous Topics

18

Conclusion

19

 SAP AG 1999

© SAP AG

CA210

16-4

IDoc Monitoring: Business Scenario

As a member of the integration team of your 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

“RSEIDOCM”

Statistics

List

4711 4712 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

Date of Change

List List

Statistics Statistics

Display Display

Display Display

Partner, message,...

All All Monitoring Monitoring Programs Programs

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” 12 = “transfer ok”

13 = “repeated 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

You are now able to: Describe the various monitoring tools Execute the monitoring transactions

 SAP AG 1999

© SAP AG

CA210

16-14

Exercises Unit: IDoc Monitoring Topic: IDoc Statistics At the conclusion of these exercises, you will be able to: 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

1-1

From the SAP Easy Access menu, open folders TOOLS → BUSINESS COMMUNICATION → IDOC → IDOC BASIS → IDOC → IDOC STATISTICS 1-1-1 How many outbound orders have been created and are being sent to the translator? Enter the following information: IDoc statistics Field Name

Input Data

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. Enter the following information: IDoc statistics – extended selection Field Name

Input Data

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

Press the Execute icon. © 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

At the conclusion of this unit, you will be able to: 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)

1

Workflow and IDocs

8

IDocs in the Business Process

2

SD EDI Application Requirements

9

General Settings

3

Inbound Invoice Processing

10

Port Definitions

4

Payment/Remittance Process

11

Partner Profiles

5

Price Catalog, Inventory Advice

12

MM EDI Application Requirements

6

Test of Processing

13

Message Control & IDocs

7

Documentation Tools

14

Course Overview

 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

Miscellaneous Topics

18

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

Archivingprograms

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

2

26

20 25 42 1 30

3

18

39 32

33

38

X

41

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

15

17

14

16

13

22

marked Status are achievable in the SAP Standard

 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

70

64

69

73

71

54

62

53

57

marked Status are achievable in the SAP Standard  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

You are now able to: 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

At the conclusion of this unit, you will be able to: 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)

1

Workflow and IDocs

8

IDocs in the Business Process

2

SD EDI Application Requirements

9

General Settings

3

Inbound Invoice Processing

10

Port Definitions

4

Payment/Remittance Process

11

Partner Profiles

5

Price Catalog, Inventory Advice

12

MM EDI Application Requirements

6

Test of Processing

13

Message Control & IDocs

7

Documentation Tools

14

Course Overview

 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

As a member of the integration team of your 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

At the conclusion of this unit, you will be able to: 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

You are now 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

19-2

Conclusion: Course Overview Diagram (1)

Course Overview

1

Workflow and IDocs

8

IDocs in the Business Process

2

SD EDI Application Requirements

9

General Settings

3

Inbound Invoice Processing

10

Port Definitions

4

Payment/Remittance Process

11

Partner Profiles

5

Price Catalog, Inventory Advice

12

MM EDI Application Requirements

6

Test of Processing

13

Message Control & IDocs

7

Documentation Tools

14

 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

Miscellaneous Topics

18

Conclusion ion

19

 SAP AG 1999

© SAP AG

CA210

19-4

Recommended Follow-up Courses

BC600 BC600

CA210 CA210

BC601 BC601

BC621 BC621

BC610 BC610

WB350

BC619 BC619

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 within the SAP standard. BC660 Data Archiving - At the end of BC660 you will be able to configure and implement archiving within the SAP standard. 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

© SAP AG

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. 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 settings Check units of measure [Units of Measure (w/o dimension)] button.

General

Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Basis Components Basis Services IDoc Interface/Electronic Data Interchange Logical system Create logical system. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Basis Components Basis Services IDoc Interface/Electronic Data Interchange Logical system Assign logical system. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Basis Components Basis Services IDoc Interface/Electronic Data Interchange Create number ranges Number range IDocs. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Basis Components Basis Services IDoc Interface/Electronic Data Interchange Create number ranges Number range Ports. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Basis Components Basis Services IDoc Interface/Electronic Data Interchange Replace technology with SAP Business Workflow. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Basis Components Basis Services IDoc Interface/Electronic Data Interchange Used extended exception handling for status return. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Basis Components Basis Services IDoc Interface/Electronic Data Interchange Delete process technology in EDI processing of Logistics. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Basis Components Basis Services IDoc Interface/Electronic Data Interchange Execute Workflow Autocustomizing. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Basis Components Basis Services IDoc Interface/Electronic Data Interchange Activate event receiver linkage for IDoc inbound. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Basis Components Basis Services IDoc Interface/Electronic Data Interchange IDoc administration. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Basis Components Basis Services IDoc Interface/Electronic Data Interchange Set proposal values for partner profiles. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Basis 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. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Materials Management Purchasing Messages Output Control Access Sequences Access Sequence for Purchase Order.

Define

Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Materials Management Purchasing Messages Output Control Access Sequences Access Sequence for Outline Agreement.

Define

Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Materials Management Purchasing Messages Output Control Access Sequences Access Sequence for Scheduling Agreement Release/Expediter.

Define

Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Materials Management Purchasing Messages Output Control Message Types Define Message Types for Purchase Order. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Materials Management Purchasing Messages Output Control Message Types Define Message Types for Outline Agreement. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Materials Management Purchasing Messages Output Control Message Types Define Message Types for Scheduling Agreement Release/Expediter. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Materials Management Purchasing Messages Output Control Message Determination Schemas Define Message Schemas for Purchase Order. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Materials Management Purchasing Messages Output Control Message Determination Schemas Define Message Schemas for Outline Agreement. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Materials Management Purchasing Messages Output Control Message Determination 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. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Sales and Distribution Electronic Data Interchange EDI messages Configure EDI partners Assign Customer/Vendor to Sales Organization Data. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Sales and Distribution Electronic Data Interchange EDI messages Configure EDI partners Determine Partner Functions for EDI Outbound Processing. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Sales and Distribution Electronic Data Interchange EDI messages Handle Messages for Inbound Orders. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Sales and Distribution Electronic Data Interchange EDI messages Configure EDI partners Convert SAP Item Category to IDoc Item Category.

© SAP AG

CA210

20-8

Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button and Distribution Basic Functions Pricing Pricing control Define condition types Maintain Condition Types.

Sales

Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Sales and Distribution Basic Functions Pricing Pricing control Define and Assign Pricing Procedures Maintain Pricing Procedures. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Sales 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. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Financial Accounting Accounts Receivable and Accounts Payable Business Transactions Incoming Invoices/Credit Memos EDI Assign G/L Accounts for EDI Procedures. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Financial Accounting Accounts Receivable and Accounts Payable Business Transactions Incoming Invoices/Credit Memos EDI Assign Additional Account Assignments for EDI Procedure. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Financial Accounting Accounts Receivable and Accounts Payable Business Transactions Incoming Invoices/Credit Memos EDI Assign Tax Codes for EDI Procedures. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Financial Accounting Accounts Receivable and Accounts Payable Business Transactions Incoming Invoices/Credit Memos EDI Enter Program Parameters for EDI Incoming Invoice.

Outbound Payments EDI configuration: Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Financial Accounting Account Receivable and Accounts Payable Business Transactions Outgoing Payments Automatic Outgoing Payments Payment Method/Bank Selection Configure Payment Program Company Codes Paying. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Financial Accounting Account Receivable and Accounts Payable Business Transactions Outgoing Payments Automatic Outgoing Payments Payment Method/Bank Selection Configure Payment Program Payment methods In company code. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button Financial Accounting Account Receivable and Accounts Payable Business Transactions Outgoing Payments Automatic Outgoing Payments Payment Method/Bank Selection Configure 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 Accounting Account Receivable and Accounts Payable Business Transactions Outgoing Payments Automatic Outgoing Payments Payment Method/Bank Selection Configure 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: Tools AcceleratedSAP Customizing Edit Project Accounting Bank Accounting Business Transactions Define Posting Data.

[SAP Reference IMG] button Financial Payment Transactions Lockbox

Tools AcceleratedSAP Customizing Edit Project Accounting Bank Accounting Business Transactions Define Control Parameters.

[SAP Reference IMG] button Financial Payment Transactions Lockbox

Tools AcceleratedSAP Customizing Financial Accounting Bank Accounting

Edit Project [SAP Reference IMG] button. Select Bank Accounts Define Lockboxes for House Banks.

Electronic Bank Statement: Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button. Select Financial Accounting Bank Accounting Business Transactions Payment Transactions Electronic Bank Statement Create Transaction Types. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button. Select Financial Accounting Bank Accounting Business Transactions Payment Transactions Electronic Bank Statement Assign Bank to Transaction Types and Currency Classes. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button. Select Financial Accounting Bank Accounting Business Transactions Payment Transactions Electronic Bank Statement Create Keys for Posting Rules. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button. Select Financial Accounting Bank Accounting Business Transactions Payment Transactions Electronic Bank Statement Assign External Transactions to Posting Rules. Tools AcceleratedSAP Customizing Edit Project [SAP Reference IMG] button. Select Financial Accounting Bank Accounting Business Transactions Payment Transactions 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.

IDoc

IDoc Basis

IDoc

Port Definition.

Business Communication

IDoc

IDoc Basis

IDoc

Partner Profile.

Tools Business Communication Entry icon.

IDoc

IDoc Basis

IDoc

Partner Profile

Port Definition: Tools

Business Communication

Partner Profile: Tools

© SAP AG

CA210

Fast Data

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 file.

Business Communication

IDoc

IDoc Basis

Test

Inbound procg of modified outb.

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 object.

Business Communication

IDoc

IDoc Basis

Development

Message / application

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 Proposals.

IDoc

IDoc Basis

Control

Partner profile

Outbound

Tools Business Communication Proposals.

IDoc

IDoc Basis

Control

Partner Profile

Inbound

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 Staffing Create.

Organizational plan

Organizational plan

Organization and

Tools Business Workflow Organizational plan Organizational plan Staffing Change Settings Maintenance Interface.

Organization and

Tools Business Workflow Staffing Display.

Organization and

Organizational plan

Organizational plan

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 Posting.

Materials Management

Inventory Management

Goods Movement

Transfer

Logistics Materials Management Immediately.

Material Master

Material

Create (General)

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 plant known.

Purchasing

Purchase order

Logistics Materials management Create Vendor Known.

Purchasing

Outline Agreement

Scheduling Agreement

Logistics Materials management Delivery Schedule Maintain.

Purchasing

Outline Agreement

Scheduling Agreement

Logistics Materials management Create SA Release.

Purchasing

Outline Agreement

Scheduling Agreement

Logistics Create.

Materials Management

Purchasing

Master data

Messages

Purchase Order

Logistics Change.

Materials Management

Purchasing

Master data

Messages

Purchase Order

Logistics Display.

Materials Management

Purchasing

Master data

Messages

Purchase Order

Logistics Create.

Materials Management

Purchasing

Master data

Messages

Outline Agreement

© SAP AG

CA210

Create

Vendor/Supplying

20-12

Logistics Materials Management Change.

Purchasing

Master data

Messages

Outline Agreement

Logistics Materials Management Display.

Purchasing

Master data

Messages

Outline Agreement

Logistics Materials Management Purchasing Agreement Delivery Schedule Create.

Master data

Messages

Scheduling

Logistics Materials Management Purchasing Agreement Delivery Schedule Change.

Master data

Messages

Scheduling

Logistics Materials Management Purchasing Agreement Delivery Schedule Display.

Master data

Messages

Scheduling

SAP Office menu path: Office

Workplace

Inbox

Workflow.

Sales and Distribution Master Data and Application Processing menu paths: Logistics Complete.

Sales and Distribution

Master data

Business partners

Customer

Create

Logistics Complete.

Sales and Distribution

Master data

Business partners

Customer

Change

Logistics Complete.

Sales and Distribution

Master data

Business partners

Customer

Display

Logistics Create.

Sales and Distribution

Master Data

Agreements

Customer Material Information

Logistics Sales and Distribution Change.

Master Data

Agreements

Customer Material Information

Logistics Sales and Distribution Display.

Master Data

Agreements

Customer Material Information

Logistics

Sales

Order

Create.

Logistics Sales and Distribution Sales System Object services Linked IDocs.

Order

Change. Enter the sales order number then

Logistics

Order

Display.

Sales and Distribution

Sales and Distribution

Sales

Logistics Sales and Distribution Module Create.

Master Data

Products

Assortments

Assortment

Logistics Create.

Sales and Distribution

Master Data

Products

Assortments

General Assortment

Logistics Sales and Distribution Module Assortment Assignment

Master Data Maintain.

Products

Assortments

Assortment

Logistics Create.

Master Data

Agreements

Sales and Distribution

Catalogs

Pricing Catalog

Accounting Master Data and Application Processing menu paths: Accounting

Financial Accounting

Accounts Payable

Periodic processing

Payments.

Archiving menu path: Tools

Administration

© SAP AG

Administration

Archiving. 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 Inbound Processing in Cash Management documentation icon

FI FI BL Enhancements to Bank Statement EDI Inbox.

Help Release Notes [Complete list 4.0] button 4.0A Inbound Processing in Cash Management documentation icon

FI FI BL Enhancements to Lockbox EDI Inbox.

Help Release Notes [Complete list 4.0] button 4.0A Inbound Processing in Cash Management documentation icon Information) EDI Inbox.

FI FI BL Enhancements to Account Balance Query (Polling

© 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”, where is the ID of the receiving R/3 System, e.g. C11.

RCVPRN

Partner number of the recipient. In ALE scenarios, this value is CLNT, where is the client of the receiving R/3 System and 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 function

Application

Message type

LF (VD)

EA

LF (VD)

Change

Message category

Process code

NEU

REQOTE

ME12

EF

NEU

ORDERS

ME10

LF (VD)

EF

NEU

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)

X

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 -u -p -c -h -s -g -x -F EDI_DATA_INCOMING -E PATHNAME=$DIRWORK/$1 -E PORT= 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 2. Receive/Send IDocs or send

CPI-C

Status records LU 6.2

IDoc Interface R/2 R

 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 code

Task

Role resolution

EDIM EDIN EDIL EDIP EDIO EDIX EDII EDIY

TS30000020 TS70008037 TS70008373 TS60001307 TS00007989 TS00008070 TS00008068 TS00008074

30000001 70000141 30000001 30000001 30000013 30000013 30000013 30000013

Administrator, system profile Partner profile, system profile Administrator, system profile Administrator, system profile Representative, partner profile Representative, partner profile Representative, partner profile Representative, partner profile

EDIS EDIR

TS30000078 TS70008125

30000001 30000001

Administrator, system profile Administrator, system profile

RSEIDOCM application

TS30200108 TSnnnnnnnn

30200013 00000134

Party from selection screen 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”: For detailed information, see the documentation for the function module 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”: For detailed information, see the documentation for the function module EXIT_SAPLIEDP_001. b) Message type PAYEXT – accessing function module “002”: For detailed information, see the documentation for the function module EXIT_SAPLIEDP_002. c) Message type DIRDEB – accessing function module “003”: For detailed information, see the documentation for the function module 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& := ‘®UP-BUKRS(*)&®UP-BELNR(*RF0)&®UPGJAHR&’ /: 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

© SAP AG

HEADER

Letter header

ADDRESS

Sender and address of the payee CA210

20-30

PAGE

Page counter INFO INFO

Date, payment document number, etc. 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

© SAP AG

MAIN

530

upper section of accompanying sheet

MAIN

531

total per currency

MAIN

532

lower section of sheet

SUMMARY 520

form summary section 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 countryspecific 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).

Change system parameters in customizing 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 ISO-Codes are transmitted by EDI – therefore you must maintain both fully and 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

Check unit of measurement 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

Damage caused to data by errors 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 System administration changes You can change all the data from a generated IDoc change within a test system. However, you require the following authorization:

Object:

S_’IDOCMONI’

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.

Change system parameters in customizing 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 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 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

Damage caused to data by errors 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. For detailed information, see the documentation for the function module 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

System administration changes You can change all the data from a generated IDoc in a test system. To do this, you need the following authorization: Object:

S_’IDOCMONI’

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

-

© SAP AG

You can process the data further with transaction FLB1.

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 Logical Msg

Direction EDI Std

Module

R/3 Release IDoc Type

204 Motor carrier shipment information Outbound ANSI CARNOT SHPMNT SHPMNT03 IFTMIN

SD

4.0A

601 Export Data Declaration EXPINV

SD

3.0A

EXPINV01

4.0A

EXPINV02

4.6A

EXPINV03

2.1A

INV_ID01

3.0A

INVOIC01

4.0A

INVOIC02

2.1A

INV_ID01

3.0A 4.0A

INVOIC01 INVOIC02

3.0A

PEXR2001

3.0A

PEXR2001

4.5A

PEXR2002

4.5A

PEXR2002

3.0A

PEXR2001

3.0A

PEXR2001

4.5A

PEXR2002

Outbound

ANSI

DELVRY01 4.5A SHPMNT03 4.5A

EXPINV EXPINV 810 Invoice INVOIC

Inbound

ANSI

MM/FI

INVOIC INVOIC 810 Invoice INVOIC

Outbound

ANSI

SD

INVOIC INVOIC 812 Credit/Debit Adjustment CREADV

Inbound

ANSI

FI

DEBADV CREADV DEBADV 812 Credit/Debit Adjustment CREADV

Outbound

ANSI

FI

DEBADV CREADV © SAP AG

CA210

20-46

4.5A

PEXR2002

3.0D

PEXR2001

4.5A

PEXR2002

3.0D

PEXR2001

4.5A

PEXR2002

3.0D

PEXR2001

4.5A

PEXR2002

DEBADV 820 Payment Order PAYEXT

Outbound

ANSI

FI

PAYEXT 820 Remittance Advice REMADV

Outbound

ANSI

FI

REMADV 820 Remittance Advice REMADV

Inbound

ANSI

FI

REMADV 820 Credit advice GSVERF

Inbound

ANSI

FI

3.0A

GSVERF01

(ERS – Evaluated Receipt Settlement) 820 Account Statement FINSTA

Inbound

ANSI

FI

4.0A

FINSTA01

823 Lockbox LOCKBX

Inbound

ANSI

FI

4.0A

FINSTA01

830 Planning Schedule DELINS

Inbound

ANSI

SD

3.0A

DELFOR01

4.5A

DELFOR01

3.0A

DELFOR01

4.5A

DELFOR01

w/ Release Capability DELFOR 830 Planning Schedule DELINS

Outbound

ANSI

MM

w/ Release Capability DELFOR 832 Price Catalog PRICAT

Outbound

ANSI

SD

4.5A

PRICAT01

840 Request for Quotes REQOTE

Inbound

ANSI

SD

2.1A

ORD_ID01

840 Request for Quotes REQOTE

Outbound

ANSI

MM/PUR

2.1A

ORD_ID01

© SAP AG

CA210

20-47

3.0A

ORDERS01

3.0D

ORDERS02

4.0A

ORDERS03

4.5A

ORDERS04

4.6A

ORDERS05

2.1A

ORD_ID01

3.0A QUOTES

ORDERS01

3.0D

ORDERS02

4.0A

ORDERS03

4.5A

ORDERS04

4.6A

ORDERS05

2.1A

ORD_ID01

3.0A QUOTES

ORDERS01

3.0D

ORDERS02

4.0A

ORDERS03

4.5A

ORDERS04

4.6A

ORDERS05

2.1A

ORD_ID01

3.0A

ORDERS01

3.0D

ORDERS02

4.0A

ORDERS03

4.5A

ORDERS04

4.6A

ORDERS05

REQOTE REQOTE REQOTE REQOTE REQOTE 843 Quotes QUOTES

Inbound

ANSI

SD

QUOTES QUOTES QUOTES QUOTES 843 Quotes QUOTES

Outbound

ANSI

SD

QUOTES QUOTES QUOTES QUOTES 850 Purchase Order ORDERS

Inbound

ANSI

SD

ORDERS ORDERS ORDERS ORDERS ORDERS © SAP AG

CA210

20-48

850 Purchase Order ORDERS

Outbound

ANSI

MM/PUR 2.1A

ORD_ID01

3.0A

ORDERS01

3.0D

ORDERS02

4.0A

ORDERS03

4.5A

ORDERS04

4.6A

ORDERS05

ORDERS ORDERS ORDERS ORDERS ORDERS 852 Stock and sale data PROACT

Inbound

ANSI

SD

4.5A

PROACT01

852 Stock and sale data PROACT

Outbound

ANSI

SD

4.5A

PROACT01

855 P.O. Acknowledgement ORDRSP

Inbound

ANSI

MM/PUR 2.1A

ORD_ID01

3.0A ORDRSP

ORDERS01

3.0D ORDRSP

ORDERS02

4.0A ORDRSP

ORDERS03 4.5A ORDERS04

ORDRSP 4.6A

ORDERS05

2.1A

ORD_ID01

3.0A ORDRSP

ORDERS01

3.0D ORDRSP

ORDERS02

ORDRSP 855 P.O. Acknowledgement ORDRSP

Outbound

ANSI

SD

4.0A ORDRSP

ORDERS03 4.5A ORDERS04

ORDRSP 4.6A

ORDERS05

2.2A

DES_ID01

ORDRSP 856 Advance Ship Notice DESADV

Inbound

ANSI

MM

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 DESADV

Outbound ANSI

SD

2.2A

DES_ID01

SD/SHP

3.0A

DESADV01

4.0A

DELVRY01

4.0A

SHPMNT02

4.5A

SHPMNT03

4.5A

SHPMNT03

2.2A

ORD_ID01

3.0A

ORDERS01

3.0D ORDCHG

ORDERS02

4.0A ORDCHG

ORDERS03

4.5A ORDCHG

ORDERS04

4.6A ORDCHG

ORDERS05

MM/PUR 2.1A

ORD_ID01

3.0A ORDCHG

ORDERS01

3.0D ORDCHG

ORDERS02

DESADV DESADV SHPMNT SHPMNT SHPADV 860 Purchase Order Change Request ORDCHG

Inbound

ANSI

SD

(buyer initiated) ORDCHG

860 Purchase Order Change Request ORDCHG

Outbound ANSI

4.0A ORDCHG ORDCHG

ORDERS03 4.5A ORDERS04

4.6A

ORDERS05

ORDCHG 861 Credit Advice (ERS) GSVERF

Inbound

ANSI

FI

3.0A

GSVERF01

861 Credit Advice (ERS) GSVERF

Outbound ANSI

FI

3.0A

GSVERF01

© SAP AG

CA210

20-50

862 Shipping Schedule DELINS

Inbound

ANSI

SD

3.0A

DELFOR01

4.5A

DELFOR01

3.0A

DELFOR01

4.5A

DELFOR01

TXTRAW01

DELJIT 862 Shipping Schedule DELINS

Outbound ANSI

MM

DELJIT 864 Text Transaction TXTRAW

Inbound

ANSI

3.0A

865 P.O. Change Acknowledgement ORDRSP

Inbound

ANSI

MM/PUR 2.1A

(seller initiated) ORDRSP

ORD_ID01

3.0A

ORDERS01

3.0D

ORDERS02

ORDRS 4.0A ORDERS03 ORDRSP 4.5A ORDERS04 ORDRSP

865 P.O. Change Acknowledgement ORDRSP

Outbound ANSI

SD

(seller initiated) ORDRSP

875 Purchase Order ORDERS

Inbound

UCS

SD

4.6A ORDRSP

ORDERS05

2.1A

ORD_ID01

3.0A

ORDERS01

3.0D ORDRSP

ORDERS02

4.0A ORDRSP

ORDERS03

4.5A ORDRSP

ORDERS04

4.6A ORDRSP

ORDERS05

2.1A

ORD_ID01

3.0A ORDERS

ORDERS01

3.0D ORDERS

ORDERS02

4.0A ORDERS03 ORDERS 4.5A ORDERS04 ORDERS 4.6A ORDERS © SAP AG

CA210

ORDERS05 20-51

875 Purchase Order ORDERS

Outbound UCS

MM/PUR 2.1A

ORD_ID01

3.0A ORDERS

ORDERS01

3.0D ORDERS

ORDERS02

4.0A ORDERS03 ORDERS 4.5A ORDERS04 ORDERS 4.6A ORDERS05 ORDERS 876 P. O. Change Request ORDCHG

Inbound

UCS

SD

2.1A

ORD_ID01

3.0A

ORDERS01

3.0D ORDCHG

ORDERS02

4.0A ORDCHG

ORDERS03

4.5A ORDCHG

ORDERS04

4.6A ORDCHG

ORDERS05

(buyer initiated) ORDCHG

876 P. O. Change Request ORDCHG

Outbound UCS

MM/PUR 2.1A

(buyer initiated) ORDCHG

ORD_ID01

3.0A

ORDERS01

3.0D ORDCHG

ORDERS02

4.0A ORDCHG

ORDERS03

4.5A ORDCHG

ORDERS04

4.6A ORDCHG

ORDERS05

879 Price change PRICAT

Outbound ANSI

SD

4.5A

PRICAT01

880 Invoice INVOIC

Inbound

MM/FI

2.1A

INV_ID01

3.0A

INVOIC01

4.0A

INVOIC02

ANSI

INVOIC INVOIC

© SAP AG

CA210

20-52

880 Invoice INVOIC

Outbound ANSI

SD

2.1A

INV_ID01

3.0A

INVOIC01

4.0A

INVOIC02

INVOIC INVOIC 888 Item Maintenance PRICAT

Outbound ANSI

SD

4.5A

PRICAT01

889 Promotion Announcement PRICAT

Outbound ANSI

SD

4.5A

PRICAT01

940 Shipping Order SHPORD

Outbound ANSI

SD

4.0A

DELVRY01

Warehouse Order WHSORD

Outbound ANSI

SD

4.0A

DELVRY01

945 Shipping Confirmation SHPCON

Inbound

ANSI

SD

4.0A

DELVRY01

Warehouse Confirmation WHSCON

Inbound

ANSI

SD

4.0A

DELVRY01

947 Warehouse Inventory WMMBXY

Inbound

ANSI

MM/IM

3.0A

WMMBID01

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