BIT320 en Col21 FV Part A4[1] - EDI Integration Technology

BIT320 EDI IntegrationTechnology mySAP Technology

Date Training Center Instructors Education Website

Participant Handbook Course Version: 2002 Q1 Course Duration: 1 Day(s) Material Number: 50066257

An SAP course - use it to learn, reference it for work

Copyright Copyright © 2003 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Trademarks •

Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation.

•

IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®, AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation.

•

ORACLE® is a registered trademark of ORACLE Corporation.

•

INFORMIX®-OnLine for SAP and INFORMIX® Dynamic ServerTM are registered trademarks of Informix Software Incorporated.

•

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

•

Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.

•

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

•

JAVA® is a registered trademark of Sun Microsystems, Inc.

•

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

•

SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.

Disclaimer THESE MATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAP EXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR APPLIED, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THESE MATERIALS AND THE SERVICE, INFORMATION, TEXT, GRAPHICS, LINKS, OR ANY OTHER MATERIALS AND PRODUCTS CONTAINED HEREIN. IN NO EVENT SHALL SAP BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES OF ANY KIND WHATSOEVER, INCLUDING WITHOUT LIMITATION LOST REVENUES OR LOST PROFITS, WHICH MAY RESULT FROM THE USE OF THESE MATERIALS OR INCLUDED SOFTWARE COMPONENTS.

About This Handbook This handbook is intended to complement the instructor-led presentation of this course, and serve as a source of reference. It is not suitable for self-study.

Typographic Conventions American English is the standard used in this handbook. The following typographic conventions are also used. Type Style

Description

Example text

Words or characters that appear on the screen. These include field names, screen titles, pushbuttons as well as menu names, paths, and options. Also used for cross-references to other documentation both internal (in this documentation) and external (in other locations, such as SAPNet).

23-12-2003

Example text

Emphasized words or phrases in body text, titles of graphics, and tables

EXAMPLE TEXT

Names of elements in the system. These include report names, program names, transaction codes, table names, and individual key words of a programming language, when surrounded by body text, for example SELECT and INCLUDE.

Example text

Screen output. This includes file and directory names and their paths, messages, names of variables and parameters, and passages of the source text of a program.

Example text

Exact user entry. These are words and characters that you enter in the system exactly as they appear in the documentation.

Variable user entry. Pointed brackets indicate that you replace these words and characters with appropriate entries.

© 2003 SAP AG. All rights reserved.

iii

About This Handbook

BIT320

Icons in Body Text The following icons are used in this handbook. Icon

Meaning For more information, tips, or background Note or further explanation of previous point Exception or caution Procedures

Indicates that the item is displayed in the instructor’s presentation.

iv


23-12-2003

Contents Course Overview ......................................................... vii Course Goals ...........................................................vii Course Objectives .....................................................vii

Unit 1: Overview of the EDI Subsystem .............................. 1 Introduction to EDI ......................................................2

Unit 2: Message Control................................................ 15 Configuring Message Control ....................................... 16

Unit 3: Data Transfer to the EDI Subsystem via Transactional RFC .......................................................................... 49 RFC ..................................................................... 50

Unit 4: The EDI Process ................................................ 61 Outbound Process .................................................... 62 Inbound Process ...................................................... 80

Unit 5: Productive System ............................................. 93 Monitoring EDI Process .............................................. 94

Appendix 1: Appendix

.............................................. 117

Index ....................................................................... 123

23-12-2003


v

Contents

vi

BIT320


23-12-2003

Course Overview This course describes the procedures involved in implementing business scenarios for communicating with a business partner using EDI. These scenarios are predefined by SAP. In addition, the course describes the various options and settings for connecting a subsystem to an SAP system.

Target Audience This course is intended for the following audiences: • •

Project team members Consultants

Course Prerequisites Required Knowledge •

BIT300/BC619 ALE Integration Technology

Recommended Knowledge • •

Basic knowledge of the SAP R/3 Enterprise system, such as the one provided in the course SAPTEC/SAP50 (Basis Technology) BIT100/BC095 (Business Integration Technology)

Course Goals This course will prepare you to: •

• •

Describe the procedures involved in implementing SAP-predefined business scenarios for communicating with a business partner using EDI Explain the tasks of an EDI subsystem Describe the different options for connecting to an EDI subsystem

Course Objectives After completing this course, you will be able to: • • •

23-12-2003

Describe the tasks of a subsystem Describe the different options for connecting a subsystem to an SAP system Use the example scenario "Purchase order for a business partner using EDI" to make the following settings:


vii

Course Overview

• • •

BIT320

Explain message determination and message control using transmission medium EDI Connect to the EDI subsystem using a tRFC port Connect to the EDI subsystem using a file port

SAP Software Component Information The information in this course pertains to the following SAP Software Components and releases:

viii


23-12-2003

Unit 1 Overview of the EDI Subsystem Unit Overview The focus of this unit is on understanding the structure of EDI documents. In addition, this unit explains the tasks of an EDI subsystem.

Unit Objectives After completing this unit, you will be able to: • •

Identify the structure of EDI documents Explain the tasks performed by an EDI subsystem

Unit Contents Lesson: Introduction to EDI.......................................................2

23-12-2003


1

Unit 1: Overview of the EDI Subsystem

BIT320

Lesson: Introduction to EDI Lesson Overview This lesson focuses on the structure of Electronic Data Integration (EDI). In addition, the lesson describes the structure of an EDI document. In addition, you will learn about the tasks performed by an EDI subsystem.

Lesson Objectives After completing this lesson, you will be able to: • •

Identify the structure of EDI documents Explain the tasks performed by an EDI subsystem

Business Example XYZ Ltd, a leading car manufacturer, has business partners all over the world with whom it carries out procurement and order processing. The company has implemented the EDI Integration Technology for the sales and procurement transactions with its business partners. As the EDI consultant of the company, you need to configure the sales and purchase documents using the EDI interface.

Structure of EDI Documents

Figure 1: EDI Standards (Selection)

Continued on next page

2


23-12-2003

BIT320

Lesson: Introduction to EDI

In addition to the EDI standards EDIFACT and ANSI x.12, there are industry-specific EDI standards. Note that only select industries and standards are shown here.

Figure 2: Structuring Business Data

For exchange of electronic data between two business partners, both partners must agree on the structure of the document. For common scenarios, there are standards that establish the structure of the electronic document. The standard determines whether a particular information must be contained in the document or it is optional. In other words, it helps determine the required entry fields and the optional fields.

Figure 3: Technical Conversion: Row Type

The information is grouped together in rows, called segments, according to the content.

Continued on next page 23-12-2003


3


BIT320

The properties of a segment field are described by a data element that contains the following information: • •

Semantic properties, such as field name, description, and possible values and their meaning Technical properties: Type and length

Figure 4: Technical Conversion: Document Class

The actual EDI document type is made up of segments or rows. Attributes determine whether each segment is mandatory or optional and how often it can be repeated. In addition, you can define hierarchical relationships between segments, resulting in segment groups. You can also decide whether each segment group is mandatory or optional and how often the group can be repeated. A mandatory segment within an optional group only has to be contained in the document if the group is contained.


4


23-12-2003

BIT320


Figure 5: Structure of a Communication IDoc

Each IDoc in the database contains one control record, multiple data records, and status records. The important part of the control record is the IDoc number, which is assigned internally in the system. This number is unique within the logical system. You define the value range in each system using a number range interval. The control record also contains the key fields of the partner profiles and the last processing status. The data records correspond to the master IDoc. The status records contain the processing steps of the IDoc. This is a record of the statuses that the IDoc has passed through, such as "created" or "ready for sending". This data is important for monitoring and communication.



5


BIT320

Tasks of an EDI Subsystem

Figure 6: Example: Electronic Purchase Order

There can be different EDI standards for business scenarios that use electronic data interchange. When exchanging documents with business partners, both parties need to agree on which standards are used. The standards are regularly revised, so you also need to establish the version. An example is electronic ordering: The EDIFACT standard is ORDERS: Purchase Order Message and the ANSI X.12 standard is 850: Purchase Order . An EDI subsystem has the task of converting SAP IDocs into EDI documents of the required EDI standard.

Figure 7: Communication With Partners Using an EDI Subsystem


6


23-12-2003

BIT320


The SAP application sends an IDoc to the subsystem. In this example using a purchase order, the message type is ORDRSP. The subsystem reads the IDoc and converts it to an EDI document. Then, this document is sent to component suppliers where it is handled as an order. If the goods can be delivered, the component supplier sends an order confirmation as an EDI document to the subsystem. Then, the subsystem converts the EDI document into an IDoc with the message type ORDSP (order/purchase order confirmation) and sends the IDoc to the SAP System.

Figure 8: Tasks of the Subsystem: Routing

The recipient information from the control record of the IDoc is used for determining the correct recipient. Data regarding how you need to send the EDI documents to the recipient must be available in the subsystem.

Figure 9: Tasks of the Subsystem: Mapping



7


BIT320

The subsystem must know the IDoc type of the IDoc that is converted. The EDI standard is defined according to the recipient, which is taken from the control record of the IDoc. Because semantically identical fields may be in different places in the different standards, you need to define mapping rules between the IDoc type and the EDI standard you are using. The subsystem uses these mapping rules to structure the EDI document and send it to the recipient.

Figure 10: EDI Subsystem: Responsibilities

The most important task of the EDI subsystem is converting to or from the required EDI standard. This task is carried out by the translator as a subfunction of the EDI subsystem. The individual criteria, such as selecting and assigning fields, are mapping components (usually customer-specific). Further processing, or message handling, is divided into outbound processing, inbound processing, and status confirmation. In outbound processing, the messages transferred from the translator are combined in transmission files. In inbound processing, the messages are separated from the transmission files and sent to the translator. Status confirmations depend on the selected EDI standard, such as the standard ANSI X.12 uses functional and interchange acknowledgments to confirm successful data transfer between EDI systems. Physical data transfer takes place using the communication module of the EDI subsystem. This also includes the implementation of the communication protocols, such as X.25 and X.400. The communication module is often produced by a different supplier. Partner profiles contain the individual settings for a partner and a process, such as which mapping is used. The addresses are required by the communication module.


8


23-12-2003

BIT320


Archiving takes place in accordance with various laws and directives. These include the guidelines laid down by the relevant tax authorities. When EDI processes are monitored, certain statuses are expected to be sent to the R/3 System as reference points to ensure integration with the applications.



9


BIT320

Lesson Summary You should now be able to: • Identify the structure of EDI documents • Explain the tasks performed by an EDI subsystem


10


23-12-2003

BIT320

Unit Summary

Unit Summary You should now be able to: • Identify the structure of EDI documents • Explain the tasks performed by an EDI subsystem



11

Unit Summary

BIT320


12


23-12-2003

BIT320

Test Your Knowledge

Test Your Knowledge 1.

The properties of a segment field in an EDI-Document are described by a data element that contains information about the and properties. Fill in the blanks to complete the sentence.

2.

The EDI subsystem is responsible for: Choose the correct answer(s).

□ □ □ □

A B C D

Mapping from EDI standard to IDoc type Mapping from IDoctype to EDI standard Error Handling Message Handling



13

Test Your Knowledge

BIT320

Answers 1.

The properties of a segment field in an EDI-Document are described by a data element that contains information about the semantic and technical properties. Answer: semantic, technical

2.

The EDI subsystem is responsible for: Answer: A, B, D The most important task of the EDI subsystem is converting to or from the required EDI standard. This task is carried out by the translator as a subfunction of the EDI subsystem. The EDI subsystem also carries out Message handling.


14


23-12-2003

Unit 2 Message Control Unit Overview This unit explains the method of converting communication with a business partner to EDI if the communication uses message control and has formerly been achieved using print outs. In addition, the unit explains how to check and modify message control settings.

Unit Objectives After completing this unit, you will be able to: • • •

Describe how to convert communication with Business Partner to EDI Describe how to check and modify message control settings Describe how to set up partner profile

Unit Contents Lesson: Configuring Message Control ........................................ 16 Exercise 1: Partner Profile and Condition Record ...................... 35 Exercise 2: Condition Elements in Output Determination.............. 39

23-12-2003


15

Unit 2: Message Control

BIT320

Lesson: Configuring Message Control Lesson Overview This lesson focuses on how to configure message control. The lesson explains how to convert communication with Business Partners to EDI. In addition, the lesson explains how to check and modify message control settings. Finally, the lesson explains how to set up partner profile.

Lesson Objectives After completing this lesson, you will be able to: • • •

Describe how to convert communication with Business Partner to EDI Describe how to check and modify message control settings Describe how to set up partner profile

Business Example XYZ Ltd, a leading car manufacturer, has business partners all over the world with whom it carries out procurement and order processing. The company has implemented the EDI Integration Technology for the sales and procurement transactions. As the EDI consultant of the company, you need to configure message output in the SAP application.

Overview of Message Control

Figure 11: Message Determination and Message Control: Scenario


16


23-12-2003

BIT320

Lesson: Configuring Message Control

Communication with a business partner can be explained using the following example: Until now in our example firm, orders for parts from a component supplier are processed on paper. • • •

A purchase requisition is forwarded from the production system to the head office using ALE. At the head office, the best value supplier is found and an order is created. This order is printed and sent to the component supplier in the mail.

This ordering scenario will be converted to Electronic Data Interchange. The supplier expects the order in the EDI standard format. • • •

A purchase requisition is forwarded from the production system to head office using ALE. At the head office, the best value supplier is found and an order is created. An electronic document is created for the order in the EDI standard format and sent to the component supplier over a network connection.

Figure 12: Message Control: Transmission Medium

In the application programs, various transmission mediums are predefined for creating an order.



17


BIT320

Every time you save a new or changed application document such as a quotation request, an order, or an outline agreement, the system checks whether to generate an output format for this application document. This output format represents a message. Message = Information that is output by various methods, such as printer, email, EDI or fax. The information and format that is output depends on the message. Output can occur using different media, decided either in the application document itself, or automatically using message determination. The application document to be output is placed in a message waiting queue from which it is released for printing and for output using EDI. This release can be either manual or automatic.

Figure 13: Message Control: Message Types

Different variants can also be predefined for the contents of the messages. These are the message types. In the purchasing area (abbr. EF), the message types defined in the standard include the following: • • •

NEW: New application documents. The complete purchasing document is output as a message. MAHN: Dunning notices and reminders for the purchasing document. AUFB: Reminder for order confirmation.


18


23-12-2003

BIT320


For further details, see the documentation on message control.

Figure 14: Partner Functions

The business partner "vendor" can adopt different roles in relation to the enterprise. For example during the procurement phase, the vendor is the order recipient, the goods supplier, the invoicing party, and the payment recipient. Maintaining partner functions in the vendor master record allows you to distribute one or more of these functions for different vendor master records.



19


BIT320

Message Determination

Figure 15: Message Determination for Transmission Medium EDI

When creating an order, message determination checks whether a message should be generated. If the transmission medium 6 (EDI) is used, the system checks whether a suitable condition record exists and the corresponding partner exists in the partner profile. If message determination is successful, a message is created. Messages are stored in the database table NAST and are also known as NAST records.


20


23-12-2003

BIT320


Figure 16: Message Determination: Customizing

The program specifies the abbreviation for the application. Message determination uses a schema to determine the message type used. An access sequence is assigned to the output type. This access sequence helps determine a condition type. The condition type determines key fields. A condition record must be maintained for the condition type. In the condition record, value pairs are assigned key fields with the following values: • • • • •

A partner function, such as order recipient or goods supplier A partner, such as a vendor from the vendor master A transmission medium, such as printing or EDI A time, such as 1 for create message with periodic job or 4 for create message immediately A language in which the message texts should be created

You can maintain condition records using the transaction NACE. If the transmission medium EDI is chosen, the partner must exist in the partner profile.



21


BIT320

Figure 17: Example: Create Order

With the configuration of the standard training systems, the following information needs to be maintained for an order: • • • •

Purchase document type: Choose normal order Vendor: Organizational data: Purchasing organization, purchasing group, and company code Items: Material number, plant, and order quantity

In this example, the vendor and the purchasing organization are key fields of the condition table and are relevant for message determination.


22


23-12-2003

BIT320


Figure 18: Message Determination: Condition Record

For successful message determination, a suitable condition record must exist in the system. A valid partner must be maintained for the values of the key fields of the condition table from the order. To maintain the condition record for the example scenario, choose: The menu path: SAP Menu → Logistics

→ Materials Management → Purchasing → Master Data → Messages → Order → Change The output type NEW and The key combination Purchasing Output Determination: Purchasing org./Vendor for EDI



23


BIT320

Figure 19: Maintaining the Condition Record

You can maintain condition records using the transaction NACE. For the applications that use message control, maintenance transactions for condition records are available in the application menu. For example, to maintain the condition record for the example scenario, choose: The menu path: SAP Menu → Logistics

→ Materials Management → Purchasing → Master Data → Messages → Order → Change The output type NEW and The key combination Purchasing Output Determination: Purchasing org./Vendor for EDI


24


23-12-2003

BIT320


Figure 20: Message Determination: Partner Profile

In addition to the condition record, a suitable partner profile must also be maintained for successful message determination. For the partner type vendor , a partner that matches the value in the condition record must exist. For this vendor, a suitable message type must exist for the partner function that is maintained in the condition record. In the additional data for message control, you need to enter a process code for outbound processing as well as the application and the relevant message type. This process code helps determine the function module, which later determines the relevant application data from the NAST records and creates the master IDoc.



25


BIT320

Figure 21: Message Determination: Details

The program specifies the abbreviation for the application. Message determination uses a schema to determine the message type used. An access sequence is assigned to the output type. This access sequence is used to determine a condition type. The condition type determines key fields. A condition record must be maintained for the condition table. In the condition record, value pairs are assigned key fields with the following values: • • • • •

A partner function, such as order recipient or goods supplier A partner, such as a vendor from the vendor master A transmission medium, such as printing or EDI A time, such as 1 for creating message with periodic job or 4 for creating message immediately A language in which the message texts should be created

You can maintain condition records using the transaction NACE. If you choose the transmission medium EDI, the partner must exist in the partner profile.


26


23-12-2003

BIT320


Figure 22: Message Determination: Multiple Condition Tables

An application can have more than one condition table. The access sequence determines the order in which the system searches for condition records for a condition table. In the above example, the system first searches for a condition record for the condition table 27, followed by a condition record for condition table 25, and a condition record for condition table 26. You can also define termination conditions and permit more than one condition record for each condition table.

Figure 23: Message Determination: Multiple Messages



27


BIT320

You can also assign multiple message types to a schema. If this is the case, all message types of the schema are processed. For each output type, the condition tables are processed according to the assigned access sequence. A unique output type is assigned to one access sequence. Within an application, an access sequence can be assigned to more than one output type.

Setting Message Control

Figure 24: Message Control: Scenario

Interfaces to EDI messages are integrated in the SAP application components. Note that SAP does not offer or supply EDI conversion or communication software (the EDI subsystem) but provides an open general interface to these systems, such as CA-EDI. EDI subsystems assume responsibility for all EDI-oriented tasks, such as data conversion, communication, administration of partner profiles, and process monitoring. To find information on certified products in the Service Marketplace, choose the Quicklink CSP in the Software Partner Directory. Then, choose Software Category → EDI subsystems. To check and maintain the processing programs for application, output type, and transmission medium, use the maintenance view V_TNAPR. Navigate to extended table maintenance by choosing System → Services → Table Maintenance → Extended Table Maintenance and enter the view V_TNAPR.


28


23-12-2003

BIT320


Figure 25: Message Control for the Transmission Medium EDI

If the transmission medium EDI is used, information regarding when a master IDoc is created from the NAST record is stored in the condition record. Time 4 means that the program RSNAST00 is called immediately after the application document is stored. This program uses the program RSNASTED to generate an IDoc for each NAST record. Time 1 means that only one NAST record is created. To create IDocs, the program RSNAST00 must be scheduled as a background job or started manually.



29


BIT320

Figure 26: Generating IDocs from NAST Records

The program RSNAST00 reads the NAST records that match the selection conditions. For the EDI transmission medium, a routine of the program RSNASTED is called for each NAST record. The process code for the partner contained in the NAST record is determined from the partner profile. The system can use the process code to determine the outbound module. The outbound module is called. In the outbound module, the data necessary for creating the master IDoc is read from the application document. The values are entered in the corresponding segment fields and a master IDoc is created. In the program RSNASTED, the master IDoc is transferred as the data part of the communication IDoc and extended by the addition of the control record and the status record. The communication IDoc is saved to the database. Further processing of the communication IDoc corresponds to ALE processing. If "collect IDocs" is set in the partner profile, the communication IDoc is transferred to the communication layer by the program RSEOUT00. If "pass IDocs immediately" is set in the partner profile, the communication IDoc is transferred to the communication layer straight away.


30


23-12-2003

BIT320


Partner Profile

Figure 27: Partner Profile: Message Control

You can use the transaction code to control which application module is used to generate the IDoc. The NAST record is used to transfer the document key to the application module. The module finds the application data and maps it to the segments of the master IDoc. The transaction code attribute "with ALE Services" controls whether you can use the ALE services "segment filtering" and "field conversion" to adjust the IDoc. If this attribute is not set, the master IDoc is transferred unchanged into the data part of the communication IDoc and saved to the database.

Figure 28: Process Code



31


BIT320

For an overview of the process codes sorted by the message type, see the transaction WE64. A process code in outbound processing contains the following information: • •

Name of process code Attributes – –

•

Direction: Outbound or inbound Message type: Name of message type, or checkbox "For all Message Types" – Message variant: Name of message variant, or checkbox "For all Message Variants" – Message function: Name of message function, or checkbox "For all Message Variants" Processed by – – – –

Workflow task: In this case, the name of the task is entered for the process ID Function module: If this is used, the name of the function module is entered for the process ID and you select between: Processing with the ALE service: The services segment filtering and field conversion of the ALE layer are processed Processing without the ALE service: The function module is called directly at runtime without the services of the ALE layer being available


32


23-12-2003

BIT320


Figure 29: Summary

In the partner profile, a link is created between the settings in message determination and message control and the technical properties for sending a message. The partner function, application, and message type must match the settings in the condition technique. Partner type, message type, IDoc type, and transaction code determine how the IDoc is structured.



33


BIT320


34


23-12-2003

BIT320


Exercise 1: Partner Profile and Condition Record Exercise Objectives After completing this exercise, you will be able to: • Maintain the partner profiles for your EDI vendor

Business Example XYZ Ltd, a leading car manufacturer, has recently implemented the EDI Technology for the sales and procurement transactions with its business partners. You are a member of the EDI project team for your company. Enter the company T-BIL## as the EDI vendor with whom you want to exchange purchase orders and order acknowledgments.

Task 1: Maintain the partner profiles for your EDI vendor, as follows: • Purchase orders can be sent to the EDI vendor • Order acknowledgments from the vendor can be received The corresponding master data in the MM application has already vendor as follows: 1.

Maintain the Partner Profile . First, enter the header data for the vendor. Position the mouse on the partner type LI and choose Create. Enter the vendor T-BIL## and a LI and choose Create. Enter the vendor T-BIL## and a permitted agent.

2.

Configure the outbound processing. Choose Create outbound parameters . Enter the vendor, such as code LF in this case. The message type is ORDERS. First, maintain the Outbound options . For this exercise, choose the receiving port BIT320_EDI, which represents the connection to your EDI subsystem. You will create a port in a later exercise. Choose the IDoc type ORDERS03. Outbound processing for confirmations is determined using message control. Therefore, you must also maintain the Message Control tab page. The application is linked to Message Control. In message control, the process is identified by the partner function (code LF) and the application (application EF and message type NEU). You determine how the document data is generated in the form of an IDoc




35


BIT320

by choosing the process code. Remember there can be several process codes for one message. Select the latest version of confirmation outbound processing using the process code ME10. 3.

Now, configure inbound processing for the order acknowledgment outbound parameters . Enter the vendor (code LF). The message type is ORDERS. First, maintain the Outbound options : For this exercise, choose the receiving port BIT320_EDI, which represents the connection to your EDI subsystem. You will create a port in a later exercise. Choose the IDoc type ORDERS03. Because outbound processing for confirmations is determined using Message Control, you must also maintain the Message Control tab page. The application is linked to Message Control. In MC, the process is identified by the partner function (code LF) and the application (application EF and message type NEU). You determine how the document data is generated as an IDoc by choosing the process code. Remember that in some circumstances there can be several process codes for one message. Select the most recent version of confirmation outbound processing using process code ME10.

4.

Now, configure inbound processing for the order acknowledgment in Create inbound parameters . The process depends on the vendor and the message. The correct partner profile is determined using the information sent to your system by the EDI subsystem in the control record. Therefore, select the message ORDRSP to identify the process. The actual processing of the IDoc is selected using the process code. Select the process code ORDR.

5.

Check the settings you have entered by selecting Partner → Check . ## is the number of your group (01 to 18).

Task 2: Check the condition record for the vendor T-BIL## 1.

Choose the following from the SAP Easy Access Menu: Logistics → Materials Management → Purchasing → Master Data → Messages → Purchase Order → MN06 - Display . Choose the message type NEU and the key combination Purchasing Output Determination: Purch. Org./Vendor for EDI . On the next selection screen, choose the purchasing organization 1000 and the vendor T-BIL## . In this condition record, enter the role LF , the partner T-BIL## , the medium 6 for EDI and the time 4 for Create IDoc Immediately. ## is the number of your group (01 to 18).


36


23-12-2003

BIT320


Solution 1: Partner Profile and Condition Record Task 1: Maintain the partner profiles for your EDI vendor, as follows: • Purchase orders can be sent to the EDI vendor • Order acknowledgments from the vendor can be received The corresponding master data in the MM application has already vendor as follows: 1.

Maintain the Partner Profile . First, enter the header data for the vendor. Position the mouse on the partner type LI and choose Create. Enter the vendor T-BIL## and a LI and choose Create. Enter the vendor T-BIL## and a permitted agent. a)

2.

Choose the “Postprocessing: Permitted agents” tab page. Use the F4 help to select an agent.

Configure the outbound processing. Choose Create outbound parameters . Enter the vendor, such as code LF in this case. The message type is ORDERS. First, maintain the Outbound options . For this exercise, choose the receiving port BIT320_EDI, which represents the connection to your EDI subsystem. You will create a port in a later exercise. Choose the IDoc type ORDERS03. Outbound processing for confirmations is determined using message control. Therefore, you must also maintain the Message Control tab page. The application is linked to Message Control. In message control, the process is identified by the partner function (code LF) and the application (application EF and message type NEU). You determine how the document data is generated in the form of an IDoc by choosing the process code. Remember there can be several process codes for one message. Select the latest version of confirmation outbound processing using the process code ME10. a)

3.

Now, configure inbound processing for the order acknowledgment outbound parameters . Enter the vendor (code LF). The message type is ORDERS. First, maintain the Outbound options : For this exercise, choose the receiving port BIT320_EDI, which represents the connection to your EDI subsystem. You will create a port in a later exercise. Choose the IDoc type ORDERS03.




37


BIT320

Because outbound processing for confirmations is determined using Message Control, you must also maintain the Message Control tab page. The application is linked to Message Control. In MC, the process is identified by the partner function (code LF) and the application (application EF and message type NEU). You determine how the document data is generated as an IDoc by choosing the process code. Remember that in some circumstances there can be several process codes for one message. Select the most recent version of confirmation outbound processing using process code ME10. a) 4.

Now, configure inbound processing for the order acknowledgment in Create inbound parameters . The process depends on the vendor and the message. The correct partner profile is determined using the information sent to your system by the EDI subsystem in the control record. Therefore, select the message ORDRSP to identify the process. The actual processing of the IDoc is selected using the process code. Select the process code ORDR. a)

5.

Check the settings you have entered by selecting Partner → Check . ## is the number of your group (01 to 18). a)

Task 2: Check the condition record for the vendor T-BIL## 1.

Choose the following from the SAP Easy Access Menu: Logistics → Materials Management → Purchasing → Master Data → Messages → Purchase Order → MN06 - Display . Choose the message type NEU and the key combination Purchasing Output Determination: Purch. Org./Vendor for EDI . On the next selection screen, choose the purchasing organization 1000 and the vendor T-BIL## . In this condition record, enter the role LF , the partner T-BIL## , the medium 6 for EDI and the time 4 for Create IDoc Immediately. ## is the number of your group (01 to 18). a)


38


23-12-2003

BIT320


Exercise 2: Condition Elements in Output Determination Exercise Objectives After completing this exercise, you will be able to: • Find information for condition elements in output determination

Business Example XYZ Ltd, a leading car manufacturer, has recently implemented the EDI Integration Technology for the sales and procurement transactions with its business partners. You are a member of the EDI project team. You need to check the condition elements for output determination for the application V1: Sales.

Task 1: Check the procedures for the application V1: Sales: 1.

Which procedures are assigned to the application V1? In the transaction NACE, use the Procedures pushbutton or navigate directly to the transaction NACZ.

2.

Which output types are assigned to the procedure V06000: Quotation Output? Select the procedure V06000 and double-click the Control node in the navigation tree.

Task 2: Check the output types for the application V1: Sales: 1.

Which output types are assigned for the application V1? In the transaction NACE, use the Output Types pushbutton or navigate directly to the transaction NACZ.

2.

Which access sequence is assigned to the output type AN00: Quotation? Select the output type AN00 and choose the Detail pushbutton.

3.

Navigate to the detail view of the access sequence.




39


BIT320

Task 3: Check the access sequence of the output type AN00: 1.

Which access sequences are assigned to the application V1: Sales? In the transaction NACE, use the Access sequences pushbutton, or navigate directly to the transaction NACX.

2.

Which accesses are defined in the access sequence found in the above step statement? Select the access sequence and double-click to navigate to the Accesses node in the Access display.

3.

Which condition table is assigned to the access 02: Order Type?


40


23-12-2003

BIT320


Solution 2: Condition Elements in Output Determination Task 1: Check the procedures for the application V1: Sales: 1.

Which procedures are assigned to the application V1? In the transaction NACE, use the Procedures pushbutton or navigate directly to the transaction NACZ. a)

The following schemata are assigned: V05000: Inquiry output V06000: Quotation output V07000: Scheduling agreement output V08000: Contract output V10000: Order output V10001: Cash sales output

2.

Which output types are assigned to the procedure V06000: Quotation Output? Select the procedure V06000 and double-click the Control node in the navigation tree. a)

The following output types are assigned: AN00: Quotation MAIL: Internal message




41


BIT320

Task 2: Check the output types for the application V1: Sales: 1.

Which output types are assigned for the application V1? In the transaction NACE, use the Output Types pushbutton or navigate directly to the transaction NACZ. a)

The application V1 has the following output types: Sales: AF00: Inquiry AN00: Quotation BA00: Order confirmation BA01: EDI order response EDI ESYM: Warnings and info EVEN: Workflow event KO00: Contract KRML: Credit processing LP00: Scheduling agreement MAIL: Internal message RD03: Cash sales invoice and some additional output types in the customer namespace created for training courses in the SAP training system.

2.

Which access sequence is assigned to the output type AN00: Quotation? Select the output type AN00 and choose the Detail pushbutton. a)

3.

The access sequence 002: Order Type is assigned.

Navigate to the detail view of the access sequence. a)

Double-click on the field ‘access sequence’ in ‘general data’.



42


23-12-2003

BIT320


Task 3: Check the access sequence of the output type AN00: 1.

Which access sequences are assigned to the application V1: Sales? In the transaction NACE, use the Access sequences pushbutton, or navigate directly to the transaction NACX. a)

The application V1 has the following access sequences: Sales: 0001 SalesOrg/DistCh/Div/Customer 0002 Order type 0003 SalesOrg/Customer 0004 SalesOrg/Sales order type 0005 Credit control area 0008 Credit check 0009 SalesOrg/Cust/Order type 00010 SalesOrg/Sold-to party 0011 SORG/CUSTNO SORG/OTYPE An access sequence in the customer namespace created in the SAP training system for a training course.

2.

Which accesses are defined in the access sequence found in the above step statement? Select the access sequence and double-click to navigate to the Accesses node in the Access display. a)

3.

Only one access is defined using condition table 007.

Which condition table is assigned to the access 02: Order Type? a)

The condition table 007 is assigned to the access 10.



43


BIT320

Lesson Summary You should now be able to: • Describe how to convert communication with Business Partner to EDI • Describe how to check and modify message control settings • Describe how to set up partner profile


44


23-12-2003

BIT320

Unit Summary

Unit Summary You should now be able to: • Describe how to convert communication with Business Partner to EDI • Describe how to check and modify message control settings • Describe how to set up partner profile



45

Unit Summary

BIT320


46


23-12-2003

BIT320

Test Your Knowledge


How is message determination customized in the EDI subsystem?

2.

If is set in the partner profile, the communication IDoc is transferred to the communication layer. Fill in the blanks to complete the sentence.

3.

What type of information is contained in the process code for outbound IDoc processing? Choose the correct answer(s).

□ □ □ □

A B C D

Name of process code Transmission medium Message type Message function



47

Test Your Knowledge

BIT320

Answers 1.

How is message determination customized in the EDI subsystem? Answer: Message determination uses a schema to determine the message type used. An access sequence is assigned to the output type. This access sequence is used to determine a condition type. The condition type determines key fields.

2.

If pass IDocs immediately is set in the partner profile, the communication IDoc is transferred to the communication layer. Answer: pass IDocs immediately

3.

What type of information is contained in the process code for outbound IDoc processing? Answer: A, C, D A process code in outbound processing contains information about the name of process code and other attributes, such as Direction, Message type, Message variant and Message function.


48


23-12-2003

Unit 3 Data Transfer to the EDI Subsystem via Transactional RFC Unit Overview This unit describes the steps involved in data transfer using transactional RFC. In addition, the unit explains the method for making the required settings in the partner profile and port definition for transferring an IDoc to the subsystem using transactional RFC. Finally, the unit explains how to check the settings for the RFC destination.


Describe the method of making required settings in the partner profile and port destination Check the settings for RFC destination

Unit Contents Lesson: RFC ..................................................................... 50

23-12-2003


49

Unit 3: Data Transfer to the EDI Subsystem via Transactional RFC

BIT320

Lesson: RFC Lesson Overview This lesson focuses on how to transfer IDocs to the subsystem using transactional RFC. The lesson explains how to make the required settings in the partner profile and port destination. In addition, the lesson explains how to check the settings for an RFC destination.


Describe the method of making required settings in the partner profile and port destination Check the settings for RFC destination

Business Example XYZ Ltd, a leading car manufacturer, has business partners all over the world with whom it carries out procurement and order processing. The company has implemented the EDI Integration Technology for the sales and procurement transactions with its business partners. To communicate with your business partner, you, as the EDI consultant of the company, are required to define a communication medium between the two logical systems.


50


23-12-2003

BIT320

Lesson: RFC

Data Transfer from SAP System to EDI Subsystem via Transactional RFC

Figure 30: Process Diagram: Communication Layer

If an IDoc to be transferred to the EDI subsystem is created using message control, a communication IDoc is saved to the database (as with ALE). The IDoc is either transferred immediately to the communication layer or using the program RSEOUT00. Here, the port type is used and maintained in the partner profile for the partner and the message type. If the port is the tRFC port, the control and data part of the communication IDoc are converted to the RFC-specific format.



51


BIT320

Figure 31: Partner Profile: Ports for EDI

Not all subsystems can use tRFC to communicate with the SAP system. You must therefore be aware of the technical capabilities of the subsystem before defining the port.

Figure 32: Registration at Runtime

The subsystem is registered under a program ID at the Gateway of the SAP system. An RFC destination of the type T is required for communicating with the subsystem. Registration must be selected and the program ID of the subsystem must be entered for this RFC destination.


52


23-12-2003

BIT320

Lesson: RFC

Figure 33: Partner Profile, Port and RFC Destination

See the following for an overview of the settings: Communication occurs using an RFC destination of the type T. For this type, registration has been selected and the program ID of the subsystem entered. Enter this RFC connection in the port of the type tRFC that you want to use. Enter this port in the outbound partner profile settings for the partner who is to receive the EDI document. The partner profile is carried out for each partner and each message type. This enables you to model very complex partner relationships.



53


BIT320

Grouping IDocs to Packages

Figure 34: Sending Individual IDocs by RFC

If you enter packet size 1 in the partner profile, a transaction ID is generated for each IDoc when the IDocs are transferred to the communication layer. This ID is sent to the target system using tRFC. The following steps are involved for creating tRFC: •

•

• •

1: The IDoc is read from the database. A transaction ID is generated, such as number 123456 on the slide. The IDoc is stored in the tRFC queue under the transaction ID in the RFC format. 2: An RFC connection to the target system is created. If this is possible, the data packet for this transaction ID, such as 123456 in this case, is transported to the target system. As soon as the target system has successfully received the data packet 3, a success message is sent to the sending system (4). Immediately after the success message has been received, the data packet for the affected transaction ID is deleted from the tRFC queue.

If the transfer is unsuccessful, the data packet remains in the tRFC queue. Use the transaction SM58 to check the content of the tRFC queue. If the target system cannot be reached, the connection is repeated after n minutes. Here, n is defined in the system settings. Use the transaction SM58 to check the general settings for tRFC. Choose "Execute" to navigate from the selection screen to the list. Then, choose Info → System settings to display a dialog box with the required information.


54


23-12-2003

BIT320

Lesson: RFC

This system setting can be overridden in every RFC destination by a local setting. Navigate to the RFC destination display, such as using transaction SM59), choose: Destination → tRFC Options.

Figure 35: Sending Packets by tRFC

In the partner profile, you can enter a packet size n > 1. This means that n IDocs are grouped together in one transaction ID. Choosing an appropriate packet size can optimize the runtime behavior.

Figure 36: IDoc Inbound Processing: Process Diagram

After the IDoc is received by tRFC, the subsystem can evaluate the data of the control record and the data records and convert it to the EDI format of the recipient.



55


BIT320

Lesson Summary You should now be able to: • Describe the method of making required settings in the partner profile and port destination • Check the settings for RFC destination


56


23-12-2003

BIT320

Unit Summary

Unit Summary You should now be able to: • Describe the method of making required settings in the partner profile and port destination • Check the settings for RFC destination



57

Unit Summary

BIT320


58


23-12-2003

BIT320

Test Your Knowledge


The subsystem is registered under a program ID at the of the SAP system. Fill in the blanks to complete the sentence.

2.

What happens if the transfer of an IDoc in the tRFC queue is not successful? Choose the correct answer(s).

□ □ □ □

A B C D

Transaction ID for the document is deleted Transaction ID for the document remains in the queue Transaction ID is generated IDoc is read again



59

Test Your Knowledge

BIT320

Answers 1.

The subsystem is registered under a program ID at the Gateway of the SAP system. Answer: Gateway

2.

What happens if the transfer of an IDoc in the tRFC queue is not successful? Answer: B If the transfer of an IDoc in the tRFC queue is unsuccessful, the data packet remains in the tRFC queue.


60


23-12-2003

Unit 4 The EDI Process Unit Overview The focus of this unit is on understanding Outbound and Inbound Processing using the file port.

Unit Objectives After completing this unit, you will be able to: • • • •

Describe the structure of an IDoc file Describe the method to make appropriate settings in the file port for Outbound Processing Describe the method to make appropriate subsystem settings Make appropriate settings for Inbound Processing

Unit Contents Lesson: Outbound Process..................................................... 62 Exercise 3: Connecting to a subsystem using a file port ............... 73 Exercise 4: Creating a file port for Outbound Processing.............. 75 Exercise 5: Maintaining Partner Profile................................... 77 Lesson: Inbound Process....................................................... 80 Exercise 6: Runtime behaviour ............................................ 85

23-12-2003


61

Unit 4: The EDI Process

BIT320

Lesson: Outbound Process Lesson Overview This lesson focuses on the steps involved in outbound processing. The lesson explains the structure of an IDoc file. In addition, the lesson describes the method for making appropriate settings in the file port for Outbound processing. Finally, the lesson explains how to make subsystem settings.

Lesson Objectives After completing this lesson, you will be able to: • • •

Describe the structure of an IDoc file Describe the method to make appropriate settings in the file port for Outbound Processing Describe the method to make appropriate subsystem settings

Business Example XYZ Ltd, a leading car manufacturer, has business partners all over the world with whom it carries out procurement and order processing. The company has implemented the EDI Integration Technology for the sales and procurement transactions with its business partners. To transfer documents from the SAP system to the business partner, you, as the SAP administrator of the company, need to make appropriate settings for Outbound processing.


62


23-12-2003

BIT320

Lesson: Outbound Process

Structure of an IDoc file

Figure 37: Structure of an IDoc File:

In the sequential file, all the fields are saved together consecutively without separators. The segments are separated from each other by an end-of-line character. The structure of the individual segments must be known to interpret the file. The first segment must be different to the header segment, which contains data for the whole IDoc. This segment must differ from data segments. Data segments contain a header part. This part contains, among other things, the name of the segment type and a 1000-byte data part. The structure of the data part is determined by the segment type. To display information about the structure, use the transaction WE63 (IDoc type parser). Note: The structure of the segments can be release-independent. Therefore, note the segment version in the selection screen of the transaction WE63.



63


BIT320

Figure 38: Internal and External Structures

IDoc types are distinguished by their segments, that is, the structure or raster laid over the data part of the data record. These segments exist in both internal and external form. • •

Internally, as a release-independent structure (SAP names begin with E1), containing all the defined segment fields. Externally, as a release-dependent structure (SAP names begin with E2), containing only the segment fields defined for the specified release in the partner profile.

In addition to the segments, there are IDoc record types in both internal (in the R/3 database) and external (as structures sent to the external system) forms. Both have changed in various R/3 releases. The documentation tools export the external structures in this case. As a result, you need to enter the following parameters in the documentation tools: • •

The version of the external record types, as entered in the port definition The release of the external segments, as entered in the partner profiles

The default values are the current release number and the relevant status record version. If you change the values, “go back to the past”.


64


23-12-2003

BIT320


Port Settings for Outbound Process

Figure 39: File Port: Outbound Processing

IDoc outbound processing: In step 1, the IDoc interface creates a new file with the transferred IDocs. In the second step, the program RFCEXEC (synchronous RFC) is called with the path to an executable program (in this case: “out.script”) and also the path to the IDoc file. Therefore, OUT.SCRIPT contains the path and name of the file as input values. In step 3, it then calls the external system, which reads the file in step 4. After the IDoc file has been successfully processed, the external system must delete the IDoc file. The call command in OUT:SCRIPT depends on the external system. RFCEXEC and STARTRFC are example programs for the use of the RFC library. These programs are supplied with the RFC library.

Figure 40: Outbound Processing: File Path and File Name



65


BIT320

The RFC-SDK must be installed on the server of the subsystem. This program packet needs the program RFCEXEC (or RFCEXEC.exe), which is started by the SAP system. The SAP system transfers variables such as file path and file name. In the port, enter the file path and the name of the file to be created. The path is entered according to the directory on the subsystem server where the program RFCEXEC is stored. To avoid overwriting files, you can dynamically generate file names. The following function modules are available for this: •

•

•

EDI_PATH_CREATE_CLIENT_DOCNUM or EDI_LPATH_CREATE_CLIENT_DOCNUM: Generate names from the IDoc number. This guarantees that the names are unique. This function module is recommended by SAP. EDI_PATH_CREATE_USERNAME or EDI_LPATH_CREATE_USERNAME: Generate names from the name of the current user. If the IDoc is generated by background processing using the program RSOUT00, ensure that the name of the batch user is used here. If more than one IDoc file is created, overwriting may occur. To display more function modules: In the transaction WE21, choose the "Outbound File" tab page for a file port and use the input help (F4 help) for the "Function module" field.

If different servers are running on different operating systems, it may be useful to use a logical directory. For more details, see the slide Customizing Logical Path Names .


66


23-12-2003

BIT320


Logical System

Figure 41: Customizing Logical Path Names

Using a platform-independent logical path name determines the path under which files are stored. Depending on the operating system, the physical paths determined in Customizing are used. You can use the Customizing transaction FILE to create logical paths and assign a physical path name to a logical path for each syntax group. A syntax group is a name for a group of operating systems that use the same syntax for file names and paths. From port maintenance, double-click on the path name to navigate to the transaction FILE. The platform-specific physical path must contain the reserved word as a placeholder for the file name. The path can also contain other reserved words. For more information, see the F1 help documentation. The following are selected examples of placeholders: • • • • • •

Name of the R/3 application according to the SY-SYSID Host name according to SY-HOST Client according to SY-MANDT Logon language according to SY-LANGU Date according to SY-DATUM Year according to SY-DATUM, four characters



67


BIT320

Subsytem Settings

Figure 42: Starting the Subsystem Automatically

If the SAP system is to transfer the IDocs to the subsystem using files and actively trigger processing of the files using the subsystem, you need to make the following settings in the partner profile: •

•

Enter the file port to be used to automatically start processing in the subsystem. For more information on the port, see the slide Outbound Processing: Triggering the Subsystem . Select the Start Subsystem radio button.


68


23-12-2003

BIT320


Figure 43: Outbound Processing: Triggering the Subsystem

If the SAP system is to trigger the subsystem, you need to maintain additional settings in the port. These settings are on the "Trigger Outbound Processing" tab page. RFC destination: •

The program RFCEXEC registers at the gateway under a program ID. Enter an RFC destination that contains this program ID and for which registration is selected. The RFC destination must have connection type T (start external program using TCP/IP).

Command file: •

The subsystem is triggered using a Shell script (command file). Make the following settings in the port: – –

Name of the command file The path for the directory on the subsystem server where the program RFCEXEC is stored



69


BIT320

Figure 44: Outbound Processing Runtime Behavior: (With Triggering Subsystem)

At runtime, the program RFCEXEC (or RFCEXEC.exe) is started using the RFC connection. The SAP system transfers parameters to this program. These parameters include the path and name of the file to be read and the path and name of the script to be started. The program RFCEXEC starts the Shell script (command file) and transfers the file name and path to this script. The script moves the file to a work directory and starts the subsystem routine responsible for processing IDoc files. For example, of a command file (Shellscript) – Outbound. Note: In this example, the operating system is UNIX. #!/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 for starting the EDI subsystem here. echo ++ removed IDoc file $FILE from application server >> $DIRWORK/ediadm.trace chmod 666 $DIRWORK/ediadm.trace


70


23-12-2003

BIT320


Figure 45: Outbound Processing Without Starting the Subsystem

If you do not want the SAP system to actively trigger the subsystem, enter "Do not start subsystem" in the partner profile.

Figure 46: Outbound Processing Runtime Behavior (Without Triggering the Subsystem)

If the SAP system does not inform the subsystem as soon as a new file is created, the subsystem must check the IDoc file directory regularly to see whether new files are received. Then, the new files are read and processed. The subsystem deletes files that have been successfully processed from the directory.



71


BIT320


72


23-12-2003

BIT320


Exercise 3: Connecting to a subsystem using a file port Exercise Objectives After completing this exercise, you will be able to: • Check the settings for RFC connections

Business Example XYZ Ltd, a leading car manufacturer, has implemented the EDI Integration Technology for the sales and procurement transactions with its business partners. As a member of the EDI project team, set the RFC destination between the two systems.

Task: Check the RFC destination BIT320_SUBSYSTEM: 1.

Choose the following in the IMG to navigate to RFC destination maintenance: Application Link Enabling (ALE)

→ Sending and Receiving Systems → Systems in Network → Define Target Systems for RFC Calls 2.

Check the RFC destination BIT320_SUBSYSTEM of the type TCP/IP. Which attributes are set for this RFC connection?

3.

Test the RFC connection using the Test connection pushbutton.



73


BIT320

Solution 3: Connecting to a subsystem using a file port Task: Check the RFC destination BIT320_SUBSYSTEM: 1.

Choose the following in the IMG to navigate to RFC destination maintenance: Application Link Enabling (ALE)

→ Sending and Receiving Systems → Systems in Network → Define Target Systems for RFC Calls a)

Alternatively, choose the following from the SAP Easy Access menu: SAP Menu

→ Tools → Administration → Administration → Network → RFC Destinations or choose the transaction SM59. 2.

Check the RFC destination BIT320_SUBSYSTEM of the type TCP/IP. Which attributes are set for this RFC connection? a)

3.

The RFC connection is set to Registration under the program ID BIT320.

Test the RFC connection using the Test connection pushbutton. a)

If the program RFCEXEC is not registered under the program ID BIT320 at runtime, an error message is displayed.


74


23-12-2003

BIT320


Exercise 4: Creating a file port for Outbound Processing Exercise Objectives After completing this exercise, you will be able to: • Create a file port for Outbound Processing

Business Example XYZ Ltd, a leading car manufacturer, has recently implemented the EDI Integration Technology for the sales and procurement transactions with its business partners. As a member of the EDI project team, you need to exchange data from one system to another using a file port.

Task: Create a file port with the name BIT320_##: 1.

Navigate to port maintenance by choosing the following in the IMG: Application Link Enabling (ALE)

→ Sending and Receiving Systems → Systems in Network → Asynchronous Processing → Assigning Ports → Define Port 2.

Create a file port with the name BIT320_##:

3.

Choose the record type 40 and enter a short text

4.

Maintain the settings for the outbound file. The instructor will inform you of the file path. For this exercise, call the path . Use a function module to generate the file name. This name should contain both the current client and the IDoc number.

5.

Maintain the settings for Trigger outbound processing: Select the attribute Start Automatically . Check the RFC destination BIT320_SUBSYSTEM: The instructor will inform you of the directory for the command file BIT320. For this exercise, call the path .



75


BIT320

Solution 4: Creating a file port for Outbound Processing Task: Create a file port with the name BIT320_##: 1.

Navigate to port maintenance by choosing the following in the IMG: Application Link Enabling (ALE)

→ Sending and Receiving Systems → Systems in Network → Asynchronous Processing → Assigning Ports → Define Port a) 2.

Alternatively, choose the transaction WE20.

Create a file port with the name BIT320_##: a)

3.

Choose the record type 40 and enter a short text a)

4.

Maintain the settings for the outbound file. The instructor will inform you of the file path. For this exercise, call the path . Use a function module to generate the file name. This name should contain both the current client and the IDoc number. a)

Enter the file path under Physical directory. Ensure that the path is complete and has all the correct separators. For example in the Windows NT environment, the path must end in “\” so that the file name can be added on directly. Choose the function module EDI_PATH_CREATE_CLIENT_DOCNUM. If you are using a logical path, choose the function module EDI_LPATH_CREATE_CLIENT_DOCNUM.

5.

Maintain the settings for Trigger outbound processing: Select the attribute Start Automatically . Check the RFC destination BIT320_SUBSYSTEM: The instructor will inform you of the directory for the command file BIT320. For this exercise, call the path . a)

Enter the path under Directory and ensure the path is complete (as in 1-2-4). For Command file , enter BIT320.bat.


76


23-12-2003

BIT320


Exercise 5: Maintaining Partner Profile Exercise Objectives After completing this exercise, you will be able to: • Maintain Partner Profile for Outbound Processing

Business Example XYZ Ltd, a leading car manufacturer, has implemented the EDI Integration Technology for the sales and procurement transactions with its business partners. As a member of the EDI project team, you need to define the business partner’s profile to maintain business partner information.

Task 1: Maintain the partner profile for the partner T-BIL## in the following manner: 1.

In the outbound settings for the message type ORDERS, enter your port BIT320_##. Select Create IDoc immediately and Do not start subsystem .

2.

Maintain the inbound settings for the message type ORDRSP (Purchase order confirmation): Inbound processing is carried out using the IDOC_INPUT_ORDRSP function module. In the partner profile, choose Trigger immediately .

3.

Which transaction can you use to search for process codes for a message type?

Task 2: Check your access authorization for the directory . 1.



77


BIT320

Solution 5: Maintaining Partner Profile Task 1: Maintain the partner profile for the partner T-BIL## in the following manner: 1.

In the outbound settings for the message type ORDERS, enter your port BIT320_##. Select Create IDoc immediately and Do not start subsystem . a)

2.

Maintain the inbound settings for the message type ORDRSP (Purchase order confirmation): Inbound processing is carried out using the IDOC_INPUT_ORDRSP function module. In the partner profile, choose Trigger immediately . a)

3.

This setting enables you to view the outbound file in this exercise. This is not possible when Start subsystem is selected because the subsystem deletes the file after successful processing.

Enter the process code ORDR.

Which transaction can you use to search for process codes for a message type? a)

You can use the transaction WE64 to search for process codes for inbound and outbound processing.

Task 2: Check your access authorization for the directory . 1. a)


78


23-12-2003

BIT320


Lesson Summary You should now be able to: • Describe the structure of an IDoc file • Describe the method to make appropriate settings in the file port for Outbound Processing • Describe the method to make appropriate subsystem settings



79


BIT320

Lesson: Inbound Process Lesson Overview This lesson provides an overview of the Inbound process and explains the port settings for the Inbound process. In addition, the lesson enables you to make Inbound File Path Settings.

Lesson Objectives After completing this lesson, you will be able to: •

Make appropriate settings for Inbound Processing

Business Example XYZ Ltd, a leading car manufacturer, has business partners all over the world with whom it carries out procurement and order processing. The company has implemented the EDI Integration Technology for the sales and procurement transactions with its business partners. To transfer documents from the business partner to the SAP system, as the SAP administrator of the company, you, need to make appropriate settings for Inbound processing.

Overview of the Inbound Process

Figure 47: IDoc Inbound Processing Process Diagram


80


23-12-2003

BIT320

Lesson: Inbound Process

After the external call, the EDI_DATA_INCOMING function module reads the IDoc from the file and saves it to the database. This triggers the workflow event PROCESSSTATEREACHED. The task TS30200090 must be assigned to this event by event linkage. This task determines the transaction code and triggers inbound processing depending on the attributes of the transaction code. To activate event linkage for IDoc inbound processing, choose the following in the IMG: Basis → Basis Services → IDoc Interface/Electronic Data Interchange → Activate Event Receiver Linkage for IDoc Inbound Processing

Port Settings for the Inbound Process

Figure 48: File Port: Inbound Processing

IDoc inbound processing: In step 1, the external system generates an IDoc file. In step 2, the system starts the R/3 System by executing the program STARTRFC. STARTRFC receives the logon parameters and the names of the function module to be executed, the port and the path to the IDoc file. The STARTRFC command can be included in an executable program, IN.SCRIPT in this example. In step 4, the triggered R/3 system processes the IDoc file and deletes it after successful processing. It is important that the external system logs on to an R/3 System with a user that has the appropriate authorizations for creating application documents. RFCEXEC and STARTRFC are example programs for the use of the RFC library with which they are supplied.



81


BIT320

Inbound File Path Settings

Figure 49: Inbound Processing: File Path and File Name

For inbound processing using a file port, a file port must exist in the system and client in which the IDoc is to be processed. The subsystem triggers the call of the function module EDI_DATA_INCOMING. The file, path name, and port name are transferred to this function module. If the path and the file name are not explicitly specified, the entries from the port are used.

Figure 50: Call Inbound Function Module


82


23-12-2003

BIT320


Inbound processing can be triggered from a Shell script (command file) using the program STARTRFC. For more information on the options, choose the following in the directory of the RFC-SDK: Selected examples of parameters: • • • • • • • • • • • •

-3 Connection to an R/3 system -t Activate trace - The data is written in the dev_rfc file -c Client -l Logon language -u SAP user - This user must be of the type communication and must have the appropriate authorizations. -p Password -h Host (application server) -s System number (= instance number) -g Gateway host if a central gateway is used -g Gateway service if a central gateway is used -F Function module, such as EDI_DATA_INCOMING in this example -E Parameter of function module, such as PATHNAME={pathname} and PORT={SAP File PORT} in this example



83


BIT320


84


23-12-2003

BIT320


Exercise 6: Runtime behaviour Exercise Objectives After completing this exercise, you will be able to: • Exchange documents with business partners using the Outbound and Inbound Process.

Business Example XYZ Ltd, a leading car manufacturer, has recently implemented the EDI Integration Technology for the sales and procurement transactions with its business partners. As a member of the EDI project team, you need to exchange documents with business partners using the Outbound and Inbound Process.

Task 1: Check the runtime behavior: 1.

Create a purchase order in the same way as in the exercise for message control.

2.

Write down the IDoc number for your order.

3.

Check the files in the directory . Which file belongs to the IDoc created by you? The subsystem has not been started. If Do not start subsystem is set in the partner profile, at which level would you start the subsystem?

4.

Change the partner profile for the partner T-BIL## and message type ORDERS to Start subsystem .

5.

Re-enter the purchase order according to step 1 of this task. Check the status of the IDoc using the Status Monitor (BD87). Has the subsystem been started?

6.

For this exercise, the subsystem is simulated by a program that receives the IDoc for a purchase order and generates a purchase order confirmation. The steps Convert IDoc to EDI document and send to vendor and Receive purchase order confirmation from vendor and convert to IDoc are then skipped. An IDoc file for the purchase order confirmation is saved in the directory . The file name includes the IDoc number. You therefore need to delete the IDoc file you created in step 5 of this task from the directory and find the file for the purchase order confirmation instead.




85


BIT320

Task 2: Trigger inbound processing for the IDoc for the message type ORDRSP, using the program RSEINB00. Ensure the file you enter for the purchase order confirmation belongs to your purchase order. 1.


86


23-12-2003

BIT320


Solution 6: Runtime behaviour Task 1: Check the runtime behavior: 1.

Create a purchase order in the same way as in the exercise for message control. a)

2.

Write down the IDoc number for your order. a)

3.

Check the files in the directory . Which file belongs to the IDoc created by you? The subsystem has not been started. If Do not start subsystem is set in the partner profile, at which level would you start the subsystem? a)

4.

The subsystem would be started at the file or operating system level. If the subsystem does not start even when Start subsystem is set in the partner profile, the IDoc in the SAP system is set to status 20 and the process code EDIP is triggered. To restart IDoc processing with triggering the subsystem, use the standard task TS60001307.

Change the partner profile for the partner T-BIL## and message type ORDERS to Start subsystem . a)

5.

Re-enter the purchase order according to step 1 of this task. Check the status of the IDoc using the Status Monitor (BD87). Has the subsystem been started? a)

6.

If the subsystem is started, the IDoc has status 18.

For this exercise, the subsystem is simulated by a program that receives the IDoc for a purchase order and generates a purchase order confirmation. The steps Convert IDoc to EDI document and send to vendor and Receive purchase order confirmation from vendor and convert to IDoc are then skipped. An IDoc file for the purchase order confirmation is saved in the directory . The file name includes the IDoc number. You therefore need to delete the IDoc file you created in step 5 of this task from the directory and find the file for the purchase order confirmation instead. a)




87


BIT320

Task 2: Trigger inbound processing for the IDoc for the message type ORDRSP, using the program RSEINB00. Ensure the file you enter for the purchase order confirmation belongs to your purchase order. 1. a)

In the selection screen, enter


88


23-12-2003

BIT320


Lesson Summary You should now be able to: • Make appropriate settings for Inbound Processing



89

Unit Summary

BIT320

Unit Summary You should now be able to: • Describe the structure of an IDoc file • Describe the method to make appropriate settings in the file port for Outbound Processing • Describe the method to make appropriate subsystem settings • Make appropriate settings for Inbound Processing


90


23-12-2003

BIT320

Test Your Knowledge


The parameters specified in the documentation tools are the of the external record types and the of the external segments. Fill in the blanks to complete the sentence.

2.

When specifying the file name during Outbound processing, the EDI_PATH_CREATE_CLIENT_DOCNUM function module generates names from the IDoc number. Determine whether this statement is true or false.

□ □ 3.

True False

At runtime, the program RFC connection.

is started using the

Fill in the blanks to complete the sentence.

4.

During Inbound Processing, which parameter defines the connection to an R/3 system in the STARTRFC program? Choose the correct answer(s).

□ □ □ □

A B C D

-t -c -3 -g



91

Test Your Knowledge

BIT320

Answers 1.

The parameters specified in the documentation tools are the version of the external record types and the release of the external segments. Answer: version, release

2.

When specifying the file name during Outbound processing, the EDI_PATH_CREATE_CLIENT_DOCNUM function module generates names from the IDoc number. Answer: True When specifying the file name during Outbound processing, the EDI_PATH_CREATE_CLIENT_DOCNUM function module generates names from the IDoc number. This guarantees that the names are unique. This function module is recommended by SAP.

3.

At runtime, the program RFCEXEC is started using the RFC connection. Answer: RFCEXEC

4.

During Inbound Processing, which parameter defines the connection to an R/3 system in the STARTRFC program? Answer: C Inbound processing can be triggered from a Shell script (command file) using the program STARTRFC. You can specify the -3 parameter to define the connection to an R/3 system.


92


23-12-2003

Unit 5 Productive System Unit Overview The focus of this unit is on identifying the different status values in the process flow. In addition, the unit explains the method for working with test tools.


Describe the different options that a subsystem has for transferring status values to the SAP system Identify and implement different test tools

Unit Contents Lesson: Monitoring EDI Process............................................... 94 Exercise 7: Test Tool (order acknowledgment) .........................101 Exercise 8: Test Tool (Order Confirmation) .............................107

23-12-2003


93

Unit 5: Productive System

BIT320

Lesson: Monitoring EDI Process Lesson Overview This lesson describes the options that a subsystem has for transferring status values to the SAP system. In addition, the lesson gives an overview of the test tools for the Outbound and Inbound processes.


Describe the different options that a subsystem has for transferring status values to the SAP system Identify and implement different test tools

Business Example XYZ Ltd, a leading car manufacturer, has business partners all over the world with whom it carries out procurement and order processing. The company has implemented the EDI Integration Technology for the sales and procurement transactions with its business partners. As the SAP administrator of the company, you are required to check the status of IDocs.

Status Values

Figure 51: Status Values of the SAP System (Outbound)

18 EDI subsystem triggered OK.


94


23-12-2003

BIT320

Lesson: Monitoring EDI Process

20 Error triggering EDI subsystem. This error triggers the process code EDIP. In the standard system, the workflow task TS60001307 is assigned to this process code.

Figure 52: Status Processing: File Port

If a subsystem is connected by a file port, it can use the following mechanisms to report status information to the SAP system: The subsystem creates a file with a line structure that corresponds to the structure EDI_DS40. The file can have multiple lines. Each line contains new status information. In addition to the new status information, the line must contain the IDoc number, client, date, and time so the SAP system can correctly assign the new status information. The file with errors is processed by the function module EDI_STATUS_INCOMING. For test purposes, you can use the transaction WE18 to create an outbound file. To start status processing using the function module EDI_STATUS_INCOMING, select the flag "Start status processing immediately". Using the transaction WE17, you can integrate any files with errors into the the SAP system for testing. This program calls the function module EDI_STATUS_INCOMING, and provides it with the error file. Caution: As in the case of an original inbound IDoc, the status file is deleted after being read successfully. Therefore, the test can be carried out only once for each file.



95


BIT320

Figure 53: Call Inbound Function Module for Status

Inbound processing can be triggered from a Shell script (command file) using the program STARTRFC (startrfc.exe). For more information on the options, choose the following in the RFC-SDK directory. Also, see the documentation for SAPRFC.ini. Selected examples of parameters: • • • • • • • • • • • •

-3: Connection to an R/3 system -t: Activate trace - Data is written in the dev_rfc file -c: Client -l: Logon language -u: SAP user - This user must be of the type communication and must have the appropriate authorizations -p: Password -h: Host (application server) -s: System number (= instance number) -g: Gateway host, if a central gateway is used -g: Gateway service, if a central gateway is used -F: Function module, such as EDI_STATUS_INCOMING in this example -E: Parameter of function, such as PATHNAME= and PORT= in this example


96


23-12-2003

BIT320


Figure 54: Status Processing: tRFC Port.

If a subsystem is connected by a tRFC port, it can use the following mechanisms to report status information to the SAP system: •

The subsystem creates an IDoc with the message type STATUS and IDoc type. This IDoc is transferred to the SAP system by tRFC.

Inbound processing occurs using the SAP-supplied single-step task TS30000206. The status records in the IDoc are then transferred to the outbound IDoc to which they refer. If not all the status records are successfully transferred to the relevant IDocs, the inbound IDoc has the status 52. If none of the transferred status records are successfully processed, the IDoc has the status 51. In both these cases, error handling is started for the inbound IDoc. Error handling is started by triggering the event STATUSIDOCERROR. The single-step task TS30000207 is the receiver for this event. As a selected agent, you edit the IDoc when executing the work item. For example, you can change the number of the IDoc to which a particular status record refers. This helps you assign the status to the correct outbound IDoc. If the IDoc has been changed in this way, you can choose Edit → Process to restart processing. The system makes another attempt to process the other status records that were not successfully posted the first time. If this is successful, the IDoc receives the status 53. Note: Error handling for inbound processing of the status IDoc is successful only if the event receiver linkage for the workflow event STATUSIDOCERROR for the business object IDOCSTATUS is activated for the standard task TS30000207. To activate this event receiver linkage from the IMG, choose: Basis Basis Services → IDoc Interface/Electronic



97


BIT320

Data Interchange → Activate event receiver linkage for IDoc inbound . You can test the status processing of IDoc types using the IDoc test tool transaction WE19.

Figure 55: Status Values for Subsystems

IDocs that are transferred to the subsystem can receive confirmation of the current status from the subsystem. The status values used are shown on the slide. As a standard setting, status values that always represent error situations are assigned the process code EDIR. The standard workflow task TS70008125 is assigned to this process code. You can use the status value maintenance (transaction WE47) to change the assignment of process codes to status values to suit your requirements. To check and change the assignment to a workflow task, use the transaction WE56.


98


23-12-2003

BIT320


Test Tools

Figure 56: Test Tool for Outbound and Inbound Processing

The arrows show the layers where the tests start. Relevant transaction information is also displayed. Outbound processing is on the left and inbound processing is on the right. According to the process code (in the partner profiles), the inbound test IDocs are either processed directly in the application or using a workflow. All test programs write a special status. Therefore, you can determine whether or not each IDoc was generated for test purposes. The IDoc statistics provide an overview of all test IDocs (F5 key, also see "Statistics and Monitoring"). The test tool (WE19) is the most general tool. Both inbound and outbound processing can be tested for one IDoc (which you can even create manually). The other test programs require either an existing file, a message status record (NAST record from message control), or a file in the file system (at the operating system level). If you have selected a file port in outbound processing, a complete test cycle from outbound processing to inbound processing can be executed including the file system.



99


BIT320


100


23-12-2003

BIT320


Exercise 7: Test Tool (order acknowledgment) Exercise Objectives After completing this exercise, you will be able to: • Use the test tool • Use IDoc display to trace IDocs

Business Example XYZ Ltd., is a leading car manufacturer. It has recently implemented the EDI Integration Technology for the sales and procurement transactions with its business partners. You want to test the following as soon as possible: • •

Sending purchase orders Receiving order acknowledgments

Task 1: 1.

Create a purchase order for methanol, material number SH-100, from the vendor T-BILnn by selecting Logistics → Materials Management → Purchasing → Purchase Order → Create → Vendor Known (transaction ME21).

2.

As a member of the purchasing department, you belong to purchasing organization 1000 and purchasing group 001. The methanol is required for plant 1100 (Berlin). Company code is 1000 (IDES AG 1000).

3.

After you have successfully entered the data, select Header → Messages from the menu in the item overview to check the proposal for the output of the purchase order via Message Control. If dispatch time 4 is selected, an IDoc for this purchase order is generated when the data is saved.

4.

Change to Purchase Order → Display . By selecting System → Links the IDoc that has just been generated is displayed.




101


BIT320

Task 2: 1.

You can use the purchase order IDoc generated as a template for the inbound order acknowledgment you need to test.

2.

From the initial node of the IDoc Interface, choose Test → Test Tool. Choose Existing IDoc and call the value help, in which you search with the recipient partner number. Choose Create.

3.

Select the control record (the first record) by clicking with the mouse and change the following fields: Recipient, Port: SAP Sender, Port:

PORT-nn

Sender, Partner number:

T-BILnn

Sender, Partner type:

LI

Sender, Partner function:

LF

Message type:

ORDRSP

Choose Continue . 4.

The order acknowledgment should contain at least the order number of the vendor. Therefore, you need to create a corresponding segment. Copy the segment E1EDK02 and change the following fields: Qualifier:

002

Document:

For example, BC620-Test-4711

Choose Continue to close the dialog box. 5.

You need to assign the acknowledgment of your vendor to the item. Create a corresponding segment E1EDP02 after the item segment E1EDP01 as a subsegment. Maintain the following fields: Qualifier:

001

Document:

Order number, in the segment E1EDK02, qualifier 001, field document

Document item: Document item, in the segment E1EDP01, field document item Continued on next page


102


23-12-2003

BIT320


Choose Continue . 6.

Choose Standard Inbound and then Continue .

7.

The system changes your original order. You can display the changed order by selecting Logistics → Materials Management → Purchasing → Purchase Order → Display . If you double-click the item, the acknowledgment number that is transferred will be displayed. By selecting System → Links from the item overview, you can display the IDoc linked to the outbound purchase order and the IDoc linked to the inbound acknowledgment. is the three-character system ID, such as ID3. nn is the number of your exercise group. This number can range from 1 to 18.



103


BIT320

Solution 7: Test Tool (order acknowledgment) Task 1: 1.

Create a purchase order for methanol, material number SH-100, from the vendor T-BILnn by selecting Logistics → Materials Management → Purchasing → Purchase Order → Create → Vendor Known (transaction ME21). a)

2.

As a member of the purchasing department, you belong to purchasing organization 1000 and purchasing group 001. The methanol is required for plant 1100 (Berlin). Company code is 1000 (IDES AG 1000). a)

3.

After you have successfully entered the data, select Header → Messages from the menu in the item overview to check the proposal for the output of the purchase order via Message Control. If dispatch time 4 is selected, an IDoc for this purchase order is generated when the data is saved. a)

4.

Change to Purchase Order → Display . By selecting System → Links the IDoc that has just been generated is displayed. a)

Task 2: 1.

You can use the purchase order IDoc generated as a template for the inbound order acknowledgment you need to test. a)

2.

From the initial node of the IDoc Interface, choose Test → Test Tool. Choose Existing IDoc and call the value help, in which you search with the recipient partner number. Choose Create. a)

3.

Select the control record (the first record) by clicking with the mouse and change the following fields: Continued on next page


104


23-12-2003

BIT320


Recipient, Port: SAP Sender, Port:

PORT-nn

Sender, Partner number:

T-BILnn

Sender, Partner type:

LI

Sender, Partner function:

LF

Message type:

ORDRSP

Choose Continue . a) 4.

The order acknowledgment should contain at least the order number of the vendor. Therefore, you need to create a corresponding segment. Copy the segment E1EDK02 and change the following fields: Qualifier:

002

Document:

For example, BC620-Test-4711

Choose Continue to close the dialog box. a) 5.

You need to assign the acknowledgment of your vendor to the item. Create a corresponding segment E1EDP02 after the item segment E1EDP01 as a subsegment. Maintain the following fields: Qualifier:

001

Document:

Order number, in the segment E1EDK02, qualifier 001, field document

Document item: Document item, in the segment E1EDP01, field document item Choose Continue . a) 6.

Choose Standard Inbound and then Continue . a)

7.

The system changes your original order. You can display the changed order by selecting Logistics → Materials Management → Purchasing → Purchase Order → Display . If you double-click the item, the Continued on next page



105


BIT320

acknowledgment number that is transferred will be displayed. By selecting System → Links from the item overview, you can display the IDoc linked to the outbound purchase order and the IDoc linked to the inbound acknowledgment. is the three-character system ID, such as ID3. nn is the number of your exercise group. This number can range from 1 to 18. a)


106


23-12-2003

BIT320


Exercise 8: Test Tool (Order Confirmation) Exercise Objectives After completing this exercise, you will be able to: • Use the IDoc display to trace IDocs

Business Example As a member of your EDI project team in the purchasing department, you need to test the following as soon as possible: • •

Process of sending purchase orders Process of receiving order confirmations

Task 1: 1.

To create a purchase order for your vendor T-BIL##, choose the following in the SAP menu: Logistics → Materials Management → Purchasing → Purchase Order → Create → ME21N → Vendor Known .

2.

As a member of the purchasing department, you belong to the purchasing organization 1000 and the purchasing group 001. Company code is 1000 (IDES AG 1000).

3.

For the item 001, enter the material methanol, material number SH-100. The methanol is required for the plant 1100 (Berlin). Enter an order quantity. After the data is entered successfully, choose Messages from the toolbar in the item overview to check the proposal for the output of the purchase order using message control. If dispatch time 4 is selected, an IDoc for this purchase order is generated when data is saved.

4.

Choose the following from the SAP menu: Logistics → Materials Management → Purchasing → Purchase Order → ME23N-Display. To display the IDoc you created, choose System → Object Services , followed by the Links icon. Make a note of the IDoc number.

Task 2: Now, call transaction BD87 and display the IDoc from 2-4. 1.

What is the status text of the IDoc? Continued on next page



107


2.

BIT320

Where can you find the following entries from your order: The specified -Sold-to party - Vendor - Goods recipient?

Task 3: Optional: Change the condition record for your vendor T-BIL## so that the time for creating a message is set to 1. Send by periodic scheduled background job. Also, change the partner profile for the vendor T-BIL## and for the order type ORDERS so that it is set to Collect IDocs . Which steps do you need to follow to create an outbound IDoc for a purchase order? 1.

Create a new IDoc by repeating steps 2-1 to 2-3. Make a note of the purchase order number.

2.

Use the program RSNAST00 to generate a program from the NAST record. For the object key, enter the purchase order number so that you only evaluate the messages for your own purchase orders.

3.

Use the status monitor to check the status of the created IDoc.

4.

Which program can you use to ensure that the IDoc is sent?


108


23-12-2003

BIT320


Solution 8: Test Tool (Order Confirmation) Task 1: 1.

To create a purchase order for your vendor T-BIL##, choose the following in the SAP menu: Logistics → Materials Management → Purchasing → Purchase Order → Create → ME21N → Vendor Known . a)

2.

As a member of the purchasing department, you belong to the purchasing organization 1000 and the purchasing group 001. Company code is 1000 (IDES AG 1000). a)

3.

For the item 001, enter the material methanol, material number SH-100. The methanol is required for the plant 1100 (Berlin). Enter an order quantity. After the data is entered successfully, choose Messages from the toolbar in the item overview to check the proposal for the output of the purchase order using message control. If dispatch time 4 is selected, an IDoc for this purchase order is generated when data is saved. a)

4.

Choose the following from the SAP menu: Logistics → Materials Management → Purchasing → Purchase Order → ME23N-Display. To display the IDoc you created, choose System → Object Services , followed by the Links icon. Make a note of the IDoc number. a)

Task 2: Now, call transaction BD87 and display the IDoc from 2-4. 1.

What is the status text of the IDoc? a)

2.

The status text reads: IDoc written to file

Where can you find the following entries from your order: The specified -Sold-to party Continued on next page



109


BIT320

- Vendor - Goods recipient? a)

Display the data records for your IDoc. Sold-to party: Segment E1EDK1 AG Vendor: Segment E1EDK1 LF Goods recipient: Segment E1EDK1 WE

Task 3: Optional: Change the condition record for your vendor T-BIL## so that the time for creating a message is set to 1. Send by periodic scheduled background job. Also, change the partner profile for the vendor T-BIL## and for the order type ORDERS so that it is set to Collect IDocs . Which steps do you need to follow to create an outbound IDoc for a purchase order? 1.

Create a new IDoc by repeating steps 2-1 to 2-3. Make a note of the purchase order number. a)

2.

Use the program RSNAST00 to generate a program from the NAST record. For the object key, enter the purchase order number so that you only evaluate the messages for your own purchase orders. a)

From the menu bar, choose System → Services → Reporting to start the transaction SA38 and enter RSNAST00. Choose Execute . In the selection screen, enter the following values: Output application: EF Object key: Output type: NEU Transmission medium: 6 Then, choose Execute .

3.

Use the status monitor to check the status of the created IDoc. a)

4.

Start the status monitor (transaction BD87). The IDoc should have the status 30: IDoc ready for dispatch.

Which program can you use to ensure that the IDoc is sent? a)

Program RSEOUT00. In the selection screen, enter the IDoc number. For Basic Type, enter the IDoc type to trigger dispatch of your IDoc.


110


23-12-2003

BIT320


Lesson Summary You should now be able to: • Describe the different options that a subsystem has for transferring status values to the SAP system • Identify and implement different test tools



111

Unit Summary

BIT320

Unit Summary You should now be able to: • Describe the different options that a subsystem has for transferring status values to the SAP system • Identify and implement different test tools


112


23-12-2003

BIT320

Test Your Knowledge


The status value 51 indicates that none of the transferred status records are successfully processed. Determine whether this statement is true or false.

□ □ 2.

True False

is the most widely used test tool for Outbound and Inbound processing. Fill in the blanks to complete the sentence.



113

Test Your Knowledge

BIT320

Answers 1.

The status value 51 indicates that none of the transferred status records are successfully processed. Answer: False If not all the status records are successfully transferred to the relevant IDocs, the inbound IDoc has the status 52. If none of the transferred status records are successfully processed, the IDoc has the status 51. In both the cases, error handling is started for the inbound IDoc.

2.

WE19 is the most widely used test tool for Outbound and Inbound processing. Answer: WE19


114


23-12-2003

BIT320

Course Summary

Course Summary You should now be able to: • • • • • •

Describe the tasks of a subsystem Describe the different options for connecting a subsystem to an SAP system Use the example scenario "Purchase order for a business partner using EDI" to make the following settings: Explain message determination and message control using transmission medium EDI Connect to the EDI subsystem using a tRFC port Connect to the EDI subsystem using a file port



115

Course Summary

BIT320


116


23-12-2003

Appendix 1 Appendix

Required Fields in Inbound Processing (IDoc Control Record) The following tables contain the fields from the IDoc control record that: • • •

Must always be entered by the external system in the structure EDI_DC40. Must be entered in special cases by the external system in the structure EDI_DC40. May be entered by the external system in the structure EDI_DC40 (optional fields). If the values are entered, they are checked by the IDoc Interface.

The following fields must always be entered by the external system:

23-12-2003

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, such as 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).


117


BIT320

RCVPOR

Receiver port: = “SAP”, where is the ID of the receiving R/3 System, such as C11.

RCVPRN

Partner number of the recipient. In ALE scenarios, this value is CLNT. Here, 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, such as 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, such as “SD” for the SD module.

Fields 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

The Outbound processing mode, such as send IDocs individually and start subsystem. Each value is overwritten in inbound processing.


118


23-12-2003

BIT320


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.

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

EA

LF

Change

Message category

Process code

NEU

REQOTE

ME12

EF

NEU

ORDERS

ME10

LF

EF

NEU

ORDCHG

ME11

AG

V1

AN00

QUOTES

AG

V1

BA00

ORDRSP

WE

V2

LAVA

DESADV

WE

V3

AUS1

EXPINV

RE

V3

RD00

INVOIC

X

SD05 SD09 (invoice)

Example: Command file (Shellscript) - Outbound Note: In this example, a UNIX operating system is used. #!/bin/sh DIRWORK=/users/ediadm cd $DIRWORK FILE=’basename $1’ date >> $DIRWORK/ediadm.trace echo ++ run external system with file $FILE >> $DIRWORK/ediadm.trace # insert command to start EDI subsystem here



119


BIT320

echo ++ removed IDoc file $FILE from application server >> $DIRWORK/ediadm.trace chmod 666 $DIRWORK/ediadm.trace 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. Data Used in the Exercises Data

Data in training system

Customer side: Material

SH-100

Vendor

T-BIL##


120


23-12-2003

BIT320


Purchasing organization

1000

Purchasing group

001

Plant

1100

## is your group number Important Menu Paths Archiving Tools → Administration Administration → Data archiving Display IDoc IDoc initial screen: IDoc → Display IDoc IDoc Administration IDoc initial screen: Control → IDoc Administration IDoc initial screen Tools → Business Communication IDoc → IDoc Basis IDoc statistics IDoc initial screen: IDoc → IDoc statistics Maintaining an RFC destination IDoc initial screen: IDoc → RFC destination Maintaining archiving status IDoc initial screen: Control → Status maintenance Partner profile IDoc initial screen: IDoc → Partner profile Port definition



121


BIT320

IDoc initial screen: IDoc → Port definition Processing tests IDoc initial screen: Test →


122


23-12-2003

Index A

O

Access Sequence, 21

Outbound Processing, 8

C

S

Control record, 5

Schema, 26 Segment, 4 Status record, 5

D Data record, 5

T

E EDI, 17 EDI standard, 3 EDI Subsystem, 6

I

Translator, 8

W WE18, 95 WE19, 99

Inbound Processing, 8

N NAST records, 20

23-12-2003


123

Index

124

BIT320


23-12-2003

Feedback SAP AG has made every effort in the preparation of this course to ensure the accuracy and completeness of the materials. If you have any corrections or suggestions for improvement, please record them in the appropriate place in the course evaluation.

23-12-2003


125

BIT320 en Col21 FV Part A4[1] - EDI Integration Technology

Recommend Documents