BC620 - SAP IDoc Interface (Technology) BC620

R/3 System Release 46B 25.06.2002

0

BC620 - SAP IDoc Interface (Technology)................................................................................................................1 Copyright.................................................................................................................................................................2 Business Integration Technologies II..................................................................................................................3 Course Prerequisites............................................................................................................................................4 Target Group.......................................................................................................................................................5 Course Overview.....................................................................................................................................................1 Course Goals.......................................................................................................................................................2 Course Objective(s).............................................................................................................................................3 Course Content....................................................................................................................................................4 Course Overview Diagram..................................................................................................................................5 Main Business Scenario......................................................................................................................................6 Basic Principles.......................................................................................................................................................1 Topic Objectives.................................................................................................................................................2 IDoc Concept.......................................................................................................................................................3 IDoc Applications...............................................................................................................................................4 EDI and ALE.......................................................................................................................................................5 Process Flow: Sending Data................................................................................................................................6 IDoc Settings: Sending Data...............................................................................................................................7 Process Flow: Receiving Data.............................................................................................................................8 IDoc Settings: Receiving Data............................................................................................................................9 Basic Principles: Summary...............................................................................................................................10 IDocs in Business Processes...................................................................................................................................1 IDocs in Business Processes: Course Objectives................................................................................................2 Business scenario................................................................................................................................................3 IDoc Record Types..............................................................................................................................................4 Control record.....................................................................................................................................................5 Data Records and Segment Structures................................................................................................................6 Status Record.......................................................................................................................................................7 IDoc Record Types: Summary............................................................................................................................8 IDoc Types..........................................................................................................................................................9 Outbound and Inbound Processing...................................................................................................................10 Outbound Processing using Message Control...................................................................................................11 Direct Outbound Processing using ALE...........................................................................................................12 Inbound Processing using Workflow................................................................................................................13 Direct Inbound Processing using ALE..............................................................................................................14 IDocs in Business Processes: Summary............................................................................................................15 IDocs in Business Processes Exercise...............................................................................................................16 IDocs in Business Processes Solutions.............................................................................................................18 Documentation Tools..............................................................................................................................................1 Documentation Tools: Unit Objectives...............................................................................................................2 Overview Diagram (Sending Data).....................................................................................................................3 Business scenario................................................................................................................................................4

Internal and External Structures..........................................................................................................................5 Output in Various Formats I................................................................................................................................6 Output in Various Formats II..............................................................................................................................7 Documentation Tools: Summary........................................................................................................................8 Documentation Tools Exercise...........................................................................................................................9 Port Definition.........................................................................................................................................................1 Port Definition: Unit Objectives.........................................................................................................................2 Overview Diagram (Sending Data).....................................................................................................................3 Port Definition: Business Scenario.....................................................................................................................4 IDoc Interface: Port Types..................................................................................................................................5 Port Definition: Port Type ..................................................................................................................................6 Process Flow: Port Type File (with Triggering).................................................................................................7 Port Type XML: Flat File and XML File............................................................................................................8 Port Type XML: Flat File and XML File (2)......................................................................................................9 Port Definition - Port Type tRFC......................................................................................................................10 Process Flow: Port Type tRFC..........................................................................................................................11 Port Definition: CPI-C (R/2 System)................................................................................................................12 Process Flow: Port Type CPI-C........................................................................................................................13 Port Definition: Internet....................................................................................................................................14 Process Flow: Port Type Internet......................................................................................................................15 Port Definition: PI.............................................................................................................................................16 Process Flow: Port Type PI...............................................................................................................................17 Communication with Older Releases................................................................................................................18 Port Definition: Summary.................................................................................................................................19 Port Definition Exercise....................................................................................................................................20 Partner Profiles........................................................................................................................................................1 Partner Profiles: Unit Objectives.........................................................................................................................2 Overview Diagram (Sending Data).....................................................................................................................3 Partner Profiles: Business Scenario.....................................................................................................................4 Partner Profiles: Fields........................................................................................................................................5 Checking Partner Profiles....................................................................................................................................6 Partner Profiles: Outbound Processing I.............................................................................................................7 Partner Profiles: Outbound Processing II............................................................................................................8 Partner Profiles: Inbound Processing..................................................................................................................9 Process Codes I.................................................................................................................................................10 Process Codes II................................................................................................................................................11 Process Codes III...............................................................................................................................................12 Outbound Modes: Port Type File......................................................................................................................13 Partner Profiles Output......................................................................................................................................14 Partner Profiles: Summary................................................................................................................................15 Partner Profiles Exercise...................................................................................................................................16 The Test Tool..........................................................................................................................................................1

................3 Test Layers: Overview...............................................................................................................................................................................................................................................3 Outbound Processing using Message Control..................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................11 Additional Test Programs...............................................................................................................6 Message Processing: IDocs.......4 Test Layers: Outbound Processing.........................................................................................................................................................................................................................................................................6 EDI-Specific Master Data in Sales..........1 Message Control and IDocs: Unit Objectives...................................5 IDoc Administration: Global Parameters...................................................................................................................................................................................................................................................................................................................................................................................................................................................................................Short Names.........1 A Process Chain: Unit Objectives........................................................4 Message Control and IDocs.........................................................................................................1 General Settings: Unit Objectives.................2 A Process Chain: Business Scenario...........................................................2 Processing Tests: Business Scenario.............................................................................2 Test Tool Options (2).......................................................9 A Process Chain...............7 Dispatch Times in Outb...............................................................................................10 General Settings Exercise................8 Summary.................................5 Condition Elements.......................................................................................................................10 Message Control and IDocs: Solution.............................................................................................................6 Test Layers: Status Confirmation.......2 Customizing using the IMG............................................................................................................................................11 General Settings...........................4 Event-Receiver Linkage...............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................4 EDI-Relevant Master Data in Purchasing....................................2 Business Scenario...................5 Standard Order for QuickDeliver........................................................................................................................................................................................................................................................................................................................................9 Message Control and IDocs Exercise..............................................6 IDoc Administration: User Parameters......................7 When to Test Which Function?............................................................................4 Message Control..........................................................................................................................Test Tool Options.....5 Test Layers: Inbound Processing......................................................................................................................................................................................................................................................................................................8 ..............8 Long Names ..................................................................................................................................................................................................................................1 Processing Tests: Unit Objectives.............................................................................................................................................. Procg using MC............................................................................................................................................................................................................................................................................................................................................................................................3 Test Tool Exercise......................3 Number Ranges..................................................................................................................3 Purchase Orders for SmartMart.........................................................................8 Processing Tests: Summary..........................................................................7 A Process Chain: Summary.............................................................................7 Fast entry..............................................................9 General Settings: Summary.................................

...............4 EDI Subsystem: Responsibilities........................................................................................................................................................................................................................................................................................................................................................................................3 Inbound Processing with Workflow................................8 .......................................................................................................................................................................................................................................................................................................................................................................................................................................................... Processing: Control Record................................................................................................................................................................9 Statistics and Monitoring..................................4 Exception Handling with Workflow......................................................................................................................................................................................................8 Using an EDI Subsystem Exercise........................................................................................................8 Statistics and Monitoring: Summary.................................7 Using an EDI Subsystem: Summary..............................................................................................................................................................................................................................................................11 Integrated Inbox.................................................1 Workflow and IDocs: Unit Objectives.........1 Using an EDI Subsystem: Unit Objectives..............................................6 Status Transfers in Inbound Processing..9 Archiving................................................................................................................................................................................................................................................................................................................................................................................................12 Workflow and IDocs: Summary.........................5 Required Fields in IDoc Inb..................................................................................................................................................6 Status Group: Monitor/Statistics......................7 Work Item Analysis.....................6 More Documentation.....2 Business Scenario....................................................................................................................................................................................................................................14 Using an EDI Subsystem...................................................................................1 Archiving: Unit Objectives.....................................................................4 Selection Fields for Monitoring.....................................................................5 Implementing Functions...........................................................................................................................5 Exceptions in Outbound Processing........................................................................................................5 Status Transfers in Outbound Processing...............................................................................................6 Exceptions in Inbound Processing......................................................................................................................................2 Overview Diagram (Sending Data)..............................................3 Archiving: Business Scenario........................7 Notification Concept I..................................................................................................................................................2 Overview Diagram (Receiving Data).................................................................................................................................................10 Statistics and Monitoring: Solution..............................................................................1 Statistics and Monitoring: Unit Objectives.........................................................................................................................................................................................................................................................................................................3 Monitoring Programs: Overview.........................................................................8 Notification Concept II...........................................................................................................................................................................................10 Maintaining an Organizational Structure..............................................................9 Statistics and Monitoring Exercise.................................................................................................................................................................................................2 Workflow and IDocs: Business Scenario....13 Workflow and IDocs Exercise............................................................3 Business Scenario...............................................9 Notification Concept III.............................................4 Archiving Object: IDOC...........................................................................................................................................................................................................12 Workflow and IDocs......................................................................................................................................................................................................................Process Chain Exercise....................................................................................................

.............Status Maintenance ...........................................................................................................................10 Course Summary..........11 Appendix..........................................................................................................Archiving.........................................9 Archiving: Summary..................................................................................................................................1 Appendix.................................................................................................................................................................................................................2 ..........................................................................................

0 BC620 .: 5003 4022 . No.SAP IDoc Interface (Technology) BC620 SAP IDoc Interface (Technology) © SAP AG 1999 © SAP AG    Release: 4.6A Status: January 2000 Mat.

Lotus ScreenCam ® is a registered trademark of Lotus Development Corporation. InterSAP. Other products. SAP EarlyWatch. and Netscape Communicator ® are registered trademarks of Netscape Communications. California. Excel ®. SAPfind. RIVA. Multimedia Viewer ®.0. WinWord ®. SAPtime. INFORMIX ®-OnLine for SAP is a registered trademark of Informix Software Incorporated. logos. USA. Indeo ® is a registered trademark of Intel Corporation. All rights reserved. © SAP AG 2001                   Trademarks: Microsoft ®. Windows ®. or brand names included herein are trademarks or registered trademarks of their respective owners. services. OS/2 ®. Neither this training manual nor any part thereof may be copied or reproduced in any form or by any means.2 Copyright Copyright 2001 SAP AG. SAPtronic. The SAP logo and all other SAP products. SAPaccess. ARIS Toolset ® is a registered Trademark of IDS Prof. The information contained in this document is subject to change and supplement without prior notice. NT ®. Internet Explorer ®. Visio ® is a registered trademark of Visio Corporation. UNIX ® and X/Open ® are registered trademarks of SCO Santa Cruz Operation. SAPoffice. Vivo ® and VivoActive ® are registered trademarks of RealNetworks. SAP (Word). Saarbrücken Adobe ® and Acrobat ® are registered trademarks of Adobe Systems Inc. SAPscript. SAP-EDI. logos. . NetShow ®. and ALE/WEB. IBM ®. SAP Business Workflow. and HTML Help ® are registered trademarks of Microsoft Corporation. TouchSend Index ® is a registered trademark of TouchSend Corporation. Inc. Inc. OSF/Motif ® is a registered trademark of Open Software Foundation. SAPfile. services. Netscape Navigator ®. or brand names included herein are also trademarks or registered trademarks of SAP AG. SAPmail. PowerPoint ®. All rights reserved. ORACLE ® is a registered trademark of ORACLE Corporation. or translated into another language. Video for Windows ®. Scheer GmbH. SAP ArchiveLink. ABAP™. Project ®. R/3. SQL-Server ®. without the prior consent of SAP AG. R/2. ADABAS ® is a registered trademark of Software AG The following are trademarks or registered trademarks of SAP AG. DB2/6000 ® and AIX ® are a registered trademark of IBM Corporation. R/3 Retail.

0.3 Business Integration Technologies II Level 2 BC619 3 days Application Link Enabling (ALE) Technology BC620 2 days SAP IDoc Interface Technology BC095 3 days CA210 EDI Interface 4 days BC621 1 day SAP IDoc Interface Development Data Exchange Level 3 Business Integration Technology CA150 2 days Building Enterprise Solutions with SAP Components BC420 Data Transfer 5 days BC415 2 days Communication Interfaces in ABAP CA926 5 days Programming with BAPIs in JAVA CA925 5 days Programming with BAPIs in Visual Basic CA927 5 days R/3 Interface and BAPI Programming in C++ © SAP AG 1999 Interface Programming .

as gained from courses SAP20 and SAP50. for example © SAP AG 1999 .4 Course Prerequisites  Recommended: Basic knowledge of the R/3 System.0.

5 Target Group  Participants:    Consultants Administrators Project team members  Duration: 2 days © SAP AG 1999 .0.

1 Course Overview Contents:  Course Goals  Course Objective(s)  Course Content  Course Overview Diagram  Main Business Scenario © SAP AG 1999 (C) SAP AG BC620 1 .

2 Course Goals This course will enable you to: Understand the possibilities offered by the IDoc Interface for electronic data transfer Use the IDoc Interface © SAP AG 1999 (C) SAP AG BC620 2 .1.

you will be able to: Configure the IDoc Interface Trace the processing of IDocs in the system Select and use the correct IDoc types for your business processes © SAP AG 1999 (C) SAP AG BC620 3 .3 Course Objective(s) At the conclusion of this course.1.

1.4 Course Content Preface and Introduction Unit 1 Unit 2 Unit 3 Unit 4 Unit 5 Unit 6 Unit 7 Unit 8 Course Overview Basic Principles IDocs in Business Process Documentation Tools Port Definition Partner Profiles The Test Tool MC and IDocs Exercises Solutions Appendix © SAP AG 1999 Unit 9 Unit 10 Unit 11 Unit 12 Unit 13 Unit 14 Unit 15 General Settings Further Test Programs A Process Chain Statistics and Monitoring Workflows and IDocs Using an EDI Subsystem Archiving (C) SAP AG BC620 4 .

create templates for configuring the IDoc Interface.  (C) SAP AG BC620 5 .1. Workflow A Process Chain Partner Profiles Partner Profiles Port Definition Port Definition EDI Subsystem? EDI Subsystem? External flow Data System Documentation Documentation Tools Tools © SAP AG 1999 The units can be divided as follows: Units which describe how to configure the IDoc Interface Units which describe the data flow in the R/3 System and between R/3 Systems and external systems  The unit "Test" describes an important step in the process of configuring the IDoc Interface.5 Course Overview Diagram R/3 System IDocs in Business Processes Archive IDoc? Archive IDoc? Test. for example. The emphasis is placed on the implementation of the test programs in the data flow. monitoring Message Control.  The unit "General Settings" describes Customizing activities which. You should therefore consider this chapter to be more advanced than the other "configuration chapters".

The IDocs are to be translated into another EDI standard form. Both companies have R/3 Systems and must configure their IDoc Interface accordingly. (C) SAP AG BC620 6 . QuickDeliver wishes to immediately post these purchase orders electronically.1. the company SmartMart wishes to send purchase orders to QuickDeliver via EDI.6 Main Business Scenario SmartMart QuickDeliver SAP R/3 System IDoc SAP R/3 System IDoc EDI Subsystem Message EDI Subsystem © SAP AG 1999  In order to reduce costs.

2 Basic Principles Contents:  IDoc concept and fundamental terms  Data flow and process flows when using the IDoc Interface © SAP AG 1999 (C) SAP AG BC620 1 .

EDI and ALE  Identify the basic steps in IDoc processing © SAP AG 1999 (C) SAP AG BC620 2 . you will be able to:  Explain the terms IDoc.2.2 Topic Objectives At the conclusion of this unit.

the application document is only created when the data is corrected. The IDoc communicates between these application documents.3 IDoc Concept System 1 Document System 2 IDoc Document  Message-oriented  Asynchronous © SAP AG 1999 IDoc is an SAP standard format for data transfer between systems.  The IDoc Interface is available in the R/3 System from Release 2. for instance.Data can be stored in IDocs before an application document is created.0F.Data is also stored in applications. It is intermediate in two respects:  Message-oriented . only in other formats (the application documents). It is not important whether the application is programmed by SAP or by another third-party system. when incorrect data is transferred: In this case. as the language spoken by both applications.  (C) SAP AG BC620 3 .  Asynchronous . IDoc stands for Intermediate Document.1A onwards and in the R/2 System from Release 5. This is important.2.

..2.4 IDoc Applications Business Connector Internet Intranet ALE IDoc R/3 System EDI Subsystem R/2 System Workflow Electronic Form Other Systems. © SAP AG 1999  Examples of systems or applications which use IDocs:  ALE: Application Link Enabling  EDI: Electronic Data Interchange  Business Connector: Sending business documents using the Internet (C) SAP AG BC620 4 .

The disadvantage is that SAP do not supply an EDI subsystem and customers must purchase such a subsystem when other EDI standards are to be used.not several EDI standards .and are therefore easier to maintain.12) by EDI subsystems. or both. Within the R/3 System. The advantage is that SAP applications only have to recognize the IDoc format .5 EDI and ALE Document SAP R/3 System IDoc IDoc SAP R/3 System IDoc EDI Subsystem Message EDI Subsystem © SAP AG 1999      Two special IDoc application areas should be defined:  EDI: Electronic data interchange between different companies  ALE: Electronic data interchange between different systems within one company Systems can exchange IDocs either directly (for example R/3 with R/3) or have them translated into other standards (for example UN/EDIFACT or ANSI X. translating IDocs into other standards has the advantage of allowing communication with more partners. However. or read data from IDocs. only IDoc formats are used.2. (C) SAP AG BC620 5 . The application which uses IDocs (for EDI or ALE) must be able to write data to IDocs. The IDoc format is valid as an EDI standard when used for EDI. All translations into other EDI Standards are performed by an EDI subsystem.

process further External system © SAP AG 1999 In the following examples. Therefore. data flow is always seen from the point of view of the R/3 System.  Outbound processing includes: Posting the application document Generating the corresponding outbound IDoc Finding the partner and the port Transfer of the IDoc to the external System via the port   (C) SAP AG BC620 6 .2. if data is sent via IDocs from an R/3 System to an external system. the process is called outbound processing or simply outbound. find port Transfer data.6 Process Flow: Sending Data R/3 System Post document Generate IDoc Check partner.

 Outbound IDocs created in the R/3 System should be archived by SmartMart and then deleted.7 IDoc Settings: Sending Data R/3 System Post document Archive IDoc ? Archive IDoc ? Generate IDoc Partner Profiles Partner Profiles Check partner. find port Port Definition Port Definition External System EDI Subsystem ? EDI Subsystem ? Transfer data.  (C) SAP AG BC620 7 . process further Documentation Documentation Tools Tools © SAP AG 1999 SmartMart must configure the IDoc Interface for outbound processing: SmartMart defines the system which will receive IDocs and the technical parameters via the port definition.  The documentation tools inform the EDI Subsystem which IDoc types are to be recognized.  SmartMart defines QuickDeliver as a partner for message type ORDERS in the partner profiles and enters the port which has already been defined.2.

2.8 Process Flow: Receiving Data External System Send data to R/3 System transfer R/3 System Check port & partner. Generate IDoc Post document ok? No ok? No Error handling © SAP AG 1999 Receiving data from an external system and the subsequent processing in the R/3 System is called inbound processing or also inbound.  Inbound processing includes: Receiving IDoc data from an external system via an inbound port Creating the inbound IDoc Finding the correct processing type via the partner profiles Creating the application document  If an error occurs. error handling (more general: exception handling) is triggered.  (C) SAP AG BC620 8 . Exception handling is a different kind of processing and is not part of inbound processing. There is also exception handling for outbound processing but it is less important: For outbound processing you should usually presume that the data being sent is correct.

specifically for partners and messages. QuickDeliver enters SmartMart as a partner for inbound processing and the message type ORDERS.2. In addition. Partner Profiles Partner Profiles Archive IDoc ? Archive IDoc ? Check port & partner.  In the partner profiles. generate IDoc Post document Error handling R/3 System © SAP AG 1999    QuickDeliver must configure the IDoc Interface for inbound processing: The documentation tools inform the EDI Subsystem which IDoc types are to be recognized. agents responsible for error processing are entered here. QuickDeliver wishes to archive and subsequently delete inbound IDocs which have been generated. Port Definition.9 IDoc Settings: Receiving Data External System EDI Subsystem ? EDI Subsystem ? Send data to R/3 System Documentation Documentation Tools Tools Port Definition. The port name must be maintained in the port definition before IDocs can be accepted by the R/3 System. (C) SAP AG BC620 9 .  Like SmartMart.

 Known implementation areas for IDocs: ALE and EDI scenarios  The IDoc Interface facilitates both IDoc processing and flexible error/exception handling © SAP AG 1999 (C) SAP AG BC620 10 .2.10 Basic Principles: Summary  IDoc is an SAP standard for data transfer between systems.

3 IDocs in Business Processes  IDoc Record Types  IDoc and IDoc type  IDoc processing: Inbound and outbound processing © SAP AG 1999 (C) SAP AG BC620 1 .

3. you will be able to:  Explain the difference between IDocs and IDoc types  Describe the structure of an IDoc  Determine where in the business process or the process chain the IDoc was created © SAP AG 1999 (C) SAP AG BC620 2 .2 IDocs in Business Processes:Course Objectives At the conclusion of this unit.

you are responsible for configuring the IDoc Interface.3. You must therefore understand the basic principles behind the interface: the IDoc format and how to embed the interface in both outbound processing (SmartMart) and inbound processing (QuickDeliver). © SAP AG 1999 (C) SAP AG BC620 3 .3 Business scenario  As a member of the implementation team for your company (SmartMart or QuickDeliver).

however. a status confirmation message is sent. The R/3 System can also send status confirmation messages for IDocs. The R/3 System then appends the status records which were received to the corresponding outbound IDoc in the database. this is only possible via the special IDoc type SYSTAT01.  An IDoc for transmission to or from an external system. the number of status records for an IDoc increases as processing continues.  (C) SAP AG BC620 4 . However.4 IDoc Record Types Control record Data records Status records © SAP AG 1999 Each IDoc in the SAP database consists of: One control record Data records which store the application data in segments and describe the hierarchy of these segments. Status records which determine the defined processing steps for the IDoc.3. no control records or data records are sent in this case. The status information is therefore located in the data records for each IDoc!  Summary: IDocs which are transmitted between two different systems are always 'smaller' than the IDocs in the R/3 System because they do not contain status records. that is. only consists of: One control record The data records  If the external system is to inform the R/3 System of the progress of the IDocs which were sent. As a result.

(C) SAP AG BC620 5 . a 16-digit number which is assigned automatically by the system. This number is used as a unique identifier for the IDoc in the R/3 System. as well as a flag indicating whether it involves a test partner.5 Control record Control record IDoc ID Partner IDoc type and logical message External structure © SAP AG 1999      An important part of the control record is the IDoc ID. for example. these key fields determine the dependent parameters of the inbound partner profile. The control record also contains the key fields for partner profiles: Partner and logical message (3 fields each). otherwise optional) The three fields for logical messages are: Message type (corresponds to UN/EDIFACT messages if possible) Message variant (optional) Message function (optional) Other fields relate to the control record. The three key fields for the partner (recipient) are: Partner number (internal number from master data in the R/3 System) Partner type (customer. how inbound IDocs should be processed in the R/3 System.3. For inbound IDocs. for example conversion to another EDI standard via an EDI subsystem or an external EDI message archive. vendor or logical system in ALE scenarios) Partner function (important in outbound processing using Message Control. Status confirmations also refer to this number.

Segment © SAP AG 1999 Segment names are stored in the control part of a data record.. contains segment names Application data Field 1 Field 2 .  The data type of the segment fields is character. This always happens when an application reads data from an IDoc or when the application writes data to an IDoc.  If possible.6 Data Records and Segment Structures Data record Control part.  (C) SAP AG BC620 6 .. a structure is assigned to the unstructured section of the application data by applying the "network of application fields".3. ISO codes are used for coded fields. This segment is defined as a structure in the R/3 System.  As a result of the segment name being stored in the control part.

However.7 Status Record Status Record IDoc ID Status information © SAP AG 1999 The IDoc number of the IDoc to which the status record refers is an important part of the status record. the display must be programmed specifically and a link to the program must be included to table TEDE3. special messages can be displayed for the system. This is used as a basis for the exception handling.message SAPE0133 ("error during RFC with port X"): SAP: R/3 message.  The first status information during processing is taken from the status value or status. If the first three characters refer to an external system. Example . a corresponding error message can be stored in the status record via the status value "incorrect". If an error occurs during IDoc processing in the R/3 System.  More detailed information can be obtained from three fields which are used to name R/3 messages in the standard system. This allows the IDoc relevant to a status conformation message to be identified in the system and the returned status records can therefore be appended.  (C) SAP AG BC620 7 . displayed in a standard window (field STAMQU) E0: Message class as defined in table T100 (field STAMID) 133: Message number as defined in table T100 (field STAMNO). creation time and name of the program which discovered the error during IDoc processing.  Other fields in the status record include the creation date.3.

3.8 IDoc Record Types: Summary Control record IDoc ID Partner IDoc type and logical message External structure Data records Control part Application data Status records IDoc ID Status information © SAP AG 1999 (C) SAP AG BC620 8 .

If such a structure contains application data.  An IDoc type is defined by the segments. an IDoc is created (the instance of the IDoc type). represented as a segment tree E1HDDOC M 1 E1TLSUM C 1 E1HDADR C 5 E1ITDOC Elternsegment M 1 E1ITSCH E1ITSCH C 99 Kindsegment C 5 Status Records © SAP AG 1999 Each business process (for example a purchase order) usually corresponds to a certain IDoc type.  The segment hierarchy can be represented in tree form as parent and child segments.9 IDoc Types Control Record Data records. sequence and frequency of use.  Summary: IDoc types are special data structures for special applications or messages. their hierarchy.  (C) SAP AG BC620 9 . which can include the relevant data. This information is contained in the control part of the data records.3. This allows the application data to be structured.

These options are explained in the following slides.  Different options are available for both inbound and outbound processing. For the inbound direction. the external system must be assigned certain authorizations.  (C) SAP AG BC620 10 . the opposite is true. data is sent from the application to the external system via the IDoc Interface.3. Documents (IDocs and application documents) are to be created in the R/3 System. in the outbound direction. Therefore.10 Outbound and Inbound Processing SAP Application IDoc Interface/ALE Services R/3 System External System Outbound Processing © SAP AG 1999 Inbound Directions are always defined from R/3.  For inbound processing.

the application sends IDocs to the IDoc Interface via Message Control.11 Outbound Processing using Message Control SAP Application Document Message Control (MC) MC record IDoc Interface / ALE Services IDoc External System © SAP AG 1999 During outbound processing using Message Control. before being sent to the port. if required.3. The IDocs can be processed further (for example filtered) by the ALE services.  The IDoc Interface sends each IDoc to the subsequent system according to the technical port definition. Examples of various port types: External system = R/3 System: usually transactional RFC (standard ALE scenario) External system = EDI subsystem: Usually the file interface  (C) SAP AG BC620 11 .

in case the application itself did not specify the recipient.  The ALE services create one (or more) communication IDoc(s) from one master IDoc (which is transferred to function module MASTER_IDOC_DISTRIBUTE). IDoc Comm. the version can be changed here. Duplicate the IDoc. if required. These services: Filter the IDoc: Data not required for the communication is removed from the IDoc Change the (segment) version: if the recipient only recognizes an earlier version of the IDoc type. for distribution models. as later versions of IDoc types can only contain more data than former versions and never less.  (C) SAP AG BC620 12 Master IDoc .3. IDoc External System © SAP AG 1999 During direct outbound processing.12 Direct Outbound Processing using ALE SAP Application IDoc Interface / ALE Services Comm. Only communication IDocs are saved in the database. IDoc Comm. This means that less data is transported. the ALE services are always called. Determine the IDoc recipient using a maintained distribution model.

the inbound IDocs are accepted and checked.  If required.3. that is.  (C) SAP AG BC620 13 . a syntax check is performed and the system checks whether the sender is entered as a partner. The R/3 System is addressed via the port name SAP<SID> for example SAPC11 for an R/3 System called C11. the IDoc can be processed by the ALE services before being saved in the database as an inbound IDoc.  If the IDoc Interface recognizes the external system.  The IDoc is sent to the application via SAP Business Workflow according to the settings in the partner profile.13 Inbound Processing using Workflow External System IDoc IDoc Interface & ALE Services IDoc + process SAP Business Workflow Document SAP Application © SAP AG 1999 The external system sends IDocs to the R/3 System.

However.  When using an ALE service. This is the application IDoc.14 Direct Inbound Processing using ALE External System IDoc IDoc Interface & ALE Services IDoc SAP Application © SAP AG 1999 Until the partner profile settings are read. in contrast to the inbound communication IDoc.  You can also set the process code (see the Partner Profiles unit) so that the ALE services are always called during direct inbound processing. IDocs cannot be duplicated during inbound processing.3. As in the case of outbound processing.  (C) SAP AG BC620 14 . the “end result” is only ever stored in the database. these services are responsible for filtering and version changes. direct inbound processing works in the same way as inbound processing via workflow:  The IDoc is passed directly to the application function module according to the partner profile settings.

© SAP AG 1999 (C) SAP AG BC620 15 .  There are various IDoc types which are distinguished by their segments and their order.3.Only control records and data records are exchanged with external systems.15 IDocs in Business Processes:Summary  Each IDoc in the R/3 database consists of one control record and several data and status records. This information is stored in the control part of the data records.  Different processing options are available for IDocs in both inbound and outbound processing.

16IDocs in Business Processes Exercise Data for exercises: Training system: Will be announced by the instructor (for example I40) Client: 400 User: BC620-nn Password: KURS Ports: SUBSYSTEM of type “File” (default) Data Customer side: Material Vendor Purchasing organization Purchasing group Plant Vendor side: Material Sold-to party Order type Sales organization Distribution channel Division Delivering plant nn is your group number SH-100 T-BIKnn TA 1020 22 00 1100 1020 22 00 1100 SH-100 1110 SH-100 T-BILnn 1000 001 1100 SH-100 1014 1000 001 1100 Data in training system Data in IDES (C) SAP AG BC620 16 .3.

IDocs are always generated by the IDoc Interface or by the application.5 IDocs are always used for process chains. IDocs are always generated by the IDoc Interface.4 In outbound processing.2 1.2.1 1. There are basic rules for IDoc structures. the IDocs are deleted from the R/3 System.1. An external system has its own formats for IDoc data. IDoc types describe how IDocs are structured.3 1.2. IDocs are intermediate documents: When the application documents have been created.1.2 True or false: 1.2.1 True or false: 1.1. 1. There are therefore no IDocs in the external system.1. In inbound processing. (C) SAP AG BC620 17 .2 1. The differences between IDoc types involve more than the segments which they contain. Exception handling via workflow is not possible in outbound processing.Unit: IDocs in Business Processes Explain terms Define IDoc structure 1.4 1.1 1.2.3 1.1.

the IDocs are deleted from the R/3 System. There are therefore no IDocs in the external system.17IDocs in Business Processes Solutions Unit: IDocs in Business Processes 1. false: IDoc types are only defined by their segments.1. 1. IDocs are always generated by the IDoc Interface or by the application.1 IDocs are always used for process chains.2 True or false: 1.3 1.2. IDocs are always generated by the IDoc Interface. 1.4 An external system has its own formats for IDoc data. can be distinguished by the IDoc type and their contents.1. true There are basic rules for IDoc structures.2 1. true 1. false: IDocs can only be deleted from the system when they have been archived. In addition.1 In outbound processing.2. IDocs.3 In inbound processing.2.5 The differences between IDoc types involve more than the segments which they contain. "external systems" can be R/3 Systems or R/2 Systems. 1.1.3. however. The phrase “intermediate document” does not refer to the "life expectancy" of an IDoc.12 IDocs are intermediate documents: When the application documents have been created. 1. false: The IDoc format must at least be recognized by the external system.2. false: Process chains can also be used within the R/3 System (for example workflow) and can therefore be used without IDocs.4 IDoc types describe how IDocs are structured. (C) SAP AG BC620 18 . true Exception handling via workflow is not possible in outbound processing. in which case IDocs are always stored in the system.1 True or false: 1. true 1.1. false: Exception handling exists for processing errors or syntax errors when dealing with both inbound and outbound processing.

IDoc types.4 Documentation Tools  Record types. segments  Output formats © SAP AG 1999 (C) SAP AG BC620 1 .

2 Documentation Tools: Unit Objectives At the conclusion of this unit. you will be able to:  Use the documentation tools  Decide in which situations they would be useful © SAP AG 1999 (C) SAP AG BC620 2 .4.

4. (C) SAP AG BC620 3 .3 Overview Diagram (Sending Data) R/3 System Post document Archive IDoc ? Archive IDoc Generate IDoc Partner Profiles Partner Profiles Check partner. find port Port Definition Port Definition External System EDI Subsystem ? EDI Subsystem ? Transfer data. process further Documentation Tools © SAP AG 1999   SmartMart must configure the IDoc Interface for outbound processing: Using the documentation tools. SmartMart sends information about the structure of IDoc Type ORDERS01 to the EDI subsystem.

using the documentation tools. you are responsible for configuring the IDoc Interface. You must know about this function.4. © SAP AG 1999 (C) SAP AG BC620 4 . Your EDI subsystem does not yet know the structure of the IDoc type to be used.4 Business scenario  As a member of the implementation team for your company (SmartMart or QuickDeliver). The IDoc Interface can export IDoc type structures in various formats. as you can save yourself a lot of programming work in the EDI subsystem.

 As a result. you have to enter the following parameters:  The version of the external record types (as entered in the port definition)  The release of the external segment (as entered in the partner profiles)  The default values are the current release number and the relevant status record version...0 Field 3 Field 4 internal external E2. that is the structure or raster laid upon the data part of the data record. Field 1 Field 2 Release 3.  (C) SAP AG BC620 5 .001 Field 1 Field 2 © SAP AG 1999 IDoc types are distinguished by their segments.4.5 Internal and External Structures Segment E1. when running the documentation tools.  In addition to the segments. containing all the defined segment fields. in both internal (in the R/3 database) and external (as structures sent to the external system) forms.. If you change the values. The documentation tools only export the external structures in this case. “go back to the past”. containing only the segment fields defined for the specified release in the partner profile. Both have changed in different R/3 Releases. These Segments exist in both internal and external form:  Internally as a release-independent structure (SAP names begin with E1).. there are also IDoc record types.  Externally as a release-dependent structure (SAP names begin with E2).

The following display options are available:  R/3 tree display: In the case of general record types.6 Output in Various Formats I ? ? ? ? © SAP AG 1999 IDoc types. segments and record types can be displayed in user-friendly formats which can be read by other systems.4.  (C) SAP AG BC620 6 . The documentation tools can also provide information about using individual IDoc types.  The documentation goes beyond the structure: It also relates to the data elements behind the segment structure fields.  HTML file In the IDoc administration user parameters you can set whether an external browser is to be started or whether the SAP internal HTML control should be used. the "tree" has only one level because the hierarchy only exists for segments and therefore for special IDoc types.

.  (C) SAP AG BC620 7 . both for record types and IDoc types.end declarations which can be read by a parser  C-Header  Meta-IDoc. The parser has its own menu entry.7 Output in Various Formats II ? ? ? ? Begin … End XML typedef struct z2incodx000 … z2incodx000 © SAP AG 1999 Machine-readable formats are:  A simple chain of begin.4. type SYRECD01 (IDoc record types) or SYIDOC01 (IDoc types)  Meta data for IDoc types in XML format  You start the documentation tools from the initial node of the IDoc Interface from the Documentation menu.

4. External structures are always documented. © SAP AG 1999 (C) SAP AG BC620 8 .  The structure is in the structure information. so that non-R/3 Systems can quickly recognize the IDoc structure.8 Documentation Tools: Summary  The documentation tools describe both the structure and the use of different IDocs.  The output formats can be read by external systems. specifically regarding how they are exchanged with external systems.

HTM.9Documentation Tools Exercise Unit: Documentation Tools Topic: Output formats At the conclusion of these exercises.HTM can be opened via Internet Explorer. By selecting Goto → User settings. ORDERS01_I. To inform your EDI subsystem provider of this data structure.HTM and ORDERS01_D. these files are ORDERS01_F. you opt for the output format HTML page due to the convenient navigation options. you can check that all the display attributes are activated.HTM. As you wish to use the standard and have not yet extended any IDoc types. 1-1 Select Documentation → IDoc types from the initial node of the IDoc interface.4. 1-2 1-3 (C) SAP AG BC620 9 . File ORDERS01_F. When preparing for the discussion. You wish to receive all the information on the IDoc type. enter the IDoc type ORDERS01 and then select Basic type in the Development object frame. Three files are generated on your PC. you will have: • Learned about different output formats As a member of the EDI project team for your company. Save your entries and return to the initial screen. you require information on IDoc type ORDERS01 for two reasons: To prepare for a project discussion about “purchase order/order via EDI”. If you have not changed any of the settings.

5 Port Definition  Port types and when they are used  Port definition parameters  Communication with Older Releases © SAP AG 1999 (C) SAP AG BC620 1 .

you will be able to:  Decide which port types should be implemented for which external systems  Enter a port definition in the R/3 System  Determine which additional steps are required for linking to the relevant external system  Enter special settings which are required for communication with older R/3 releases and R/2 Systems © SAP AG 1999 (C) SAP AG BC620 2 .2 Port Definition: Unit Objectives At the conclusion of this unit.5.

 (C) SAP AG BC620 3 .3 Overview Diagram (Sending Data) R/3 System Post document Archive IDoc ? Archive IDoc Generate IDoc Partner Profiles Partner Profiles Check partner. find port Port Definition External System EDI Subsystem ? EDI Subsystem ? Transfer data. Both companies have R/3 Systems and must configure their IDoc Interface accordingly.5. SmartMart must configure the IDoc Interface for sending data (outbound processing or simply outbound):  SmartMart defines the system which will receive IDocs and the technical parameters via the port definition. process further Documentation Documentation Tools Tools © SAP AG 1999 The company SmartMart wishes to send purchase orders to QuickDeliver via EDI. QuickDeliver wishes to immediately post these purchase orders electronically.

you are responsible for configuring the IDoc Interface.4 Port Definition: Business Scenario  As a member of the implementation team for SmartMart.  You must decide which port type is suitable for the system of your partner company QuickDeliver.5. © SAP AG 1999 (C) SAP AG BC620 4 .

"XML": The IDocs are written in XML format in the files. the receiving system is started via RFC. status records can also be exchanged by file. As is the case with the port type "file". the external system is an R/3 System (ALE scenarios).0F). You therefore do not leave the R/3 System via a PI port. but here status records are only transferred by means of the IDoc type SYSTAT01. (C) SAP AG BC620 5 . "Transactional RFC" IDocs are sent as tables. IDocs are always exchanged by means of the CPI-C protocol in the R/2 IDoc Interface (available from R/2 Release 5. The IDoc Interface supports six different transmission methods. "Programming Interface (PI)": IDocs are sent as tables to one of the function modules defined.5 IDoc Interface: Port Types IDoc Interface IDoc/ status IDoc/ status IDoc IDoc IDoc IDoc File XML tRFC Internet CPI-C PI External System R/2 System ? © SAP AG 1999        Ports are the channels via which the IDocs are exchanged. The receiving system can read the files here. The receiving system can also be started using the synchronous RFC. Typically here. Your function module can naturally trigger or perform an external dispatch. "CPI-C" IDocs or control records are transferred according to the CPI-C protocol.2.5. "Internet": The IDocs are written in MIME format to an e-mail attachment. The external system is always an R/2 System. Besides IDocs (that is data and control records). These are the port types: "File": IDocs are written in files at an operating system level. For further information see the R/2 handbook. p53. in the way it is implemented for the IDoc Interface in the R/2 System.

you require the RFC destination.this file must be created so that the R/3 System can start the receiving system automatically (= trigger) as soon as it has generated an IDoc file. if you do enter a parameter for the inbound IDoc and status file. settings outside of the IDoc Interface must be made.  The port definition for the port type "file" includes  Name and directory of files. So that a port can be used. you can also store a function module. even if it is only used in inbound processing. as the place and name of the file are determined by the external system during inbound processing of IDocs or a status confirmation. which dynamically generates names and thus helps to prevent files from being over-written.5.script IDoc file Status report © SAP AG 1999 Data for technical linking is determined in the port definition for the IDoc Interface. as the IDoc Interface only accepts ports that it recognizes. It is important that the port exists every time. This is maintained with the transaction SM59 (TCP/IP connections).  (C) SAP AG BC620 6 . However.  Instead of the outbound file.  Name and directory of command file that is to be called from program "rfcexec" and which should start the external system . Only the outbound file is important.  If you trigger using RFC. the test tool can generate default values.6 Port Definition: Port Type "File" RFC destination (TCP/IP connection) Command file Outbound file Inbound file Status file rfcexec out. It is a setting outside of the IDoc Interface. You can also use logical file names: You should also see the F1 Help for the field.

5.script” thus contains the path and name of the file as an input value. the port and the path to the IDoc file. the external system generates an IDoc file. it therefore calls the external system. the external system must delete the IDoc file.7 Process Flow: Port Type File (with Triggering) IDoc Interface Write RFC 4 Read IDoc file Status report 3 RFC startrfc in. The call command in “out. After successful processing of the IDoc file. here “in.script”. In step 3. “out. except that here a status file instead of an IDoc file is transferred. In step 4.script”) and also the path to the IDoc file.  The status report works in exactly the same way as an inbound IDoc. the R/3 System started then processes the IDoc file and deletes it after successful processing.script” depends on the external system. In the second step.  IDoc inbound: In step 1. The “startrfc”command can be included in an executable program.  (C) SAP AG BC620 7 .script 1 IDoc file 2 rfcexec out. the program “rfcexec” (synchronous RFC) with the path to an executable program is called (here: “out.script Read Call 1 Write 2 Call 4 3 External System © SAP AG 1999 IDoc outbound: In step 1. which reads the file in step 4.  “rfcexec” and “startrfc” are example programs for the use of the RFC library and are supplied with this.script status. “startrfc” receives the logon parameter and the names of the function module to be executed. a new file is generated with the transferred IDocs by the IDoc Interface. In step 2 it starts the R/3 System in which it executes the program "startrfc". It is important that the external system logs on to an R/3 System with a user which has the corresponding authorization for creating application documents.

.  The fields are identified by means of their position in the individual records. Such a flat file therefore contains as many blank characters as possible so that the fields are in the right place.. 004000000000030702346B 3013 ORDERS01 E2EDP01005 00400000000003070230000210000000200 00400000000003070230000220000210323 E2EDPT1001 004000000000030702300002600002103BESTD E2EDPT2001 004000000000030702300002700002604This is © SAP AG 1999 The IDoc data is written in a file under the port type "XML". no structure information at all is written in the file... Thus you also speak of a "flat file". E2EDP20 .8 Port Type XML: Flat File and XML File EDI_DC40 . The individual segments are put in a row one after another as data records and are separated with carriage return.  (C) SAP AG BC620 8 . Hence the port definition and technical structure are almost identical. but in XML format.5.  Under port type "file".

.. ... .. you can display an XML file as a tree.. <E1EDP01 SEGMENT="1"><POSEX>00010 </ OS P EX><ACTION>001</ACTION><PSTYP>0</PSTYP ><MENGE>23. <E1EDPT2 SEGMENT="1"><TDLINE>This is the purchase order text.. But they are considerably different to a flat file:  Segments are enclosed by start and end tags and therefore do not need to be separated by carriage return.. As the fields are also enclosed by tags..  (C) SAP AG BC620 9 .. The SAP system IDoc structure therefore remains in the file received and can be displayed in any XMLcompatible browser.000</MENGE>.. <E1EDPT1 SEGMENT="1"><TDID>BEST</TDID> <TSSPRAS>D</TSSPRAS>. .... the segments are only ever as long as the data contained requires hence there are no "unnecessary" blank characters. ..000 </W MENG><EDATU>19990622</EDATU></E1EDP2> .  As the tags can be connected with one another in XML. </E1EDPT1> </E1EDP01> © SAP AG 1999 The segments are also written one after another in the XML file.</TDLINE>..9 Port Type XML: Flat File and XML File (2) EDI_DC40 E1EDP01 E1EDP20 E1EDPT1 E1EDPT2 <EDI_DC40 SEGMENT="1"><TABNAM><![CDAT A[EDI_DC40]]></TABNAM><MANDT>004</MAN DT><DOCNUM>0000000000307023</DOCNUM> .. <E1EDP20 SEGMENT="1"><WMENG>23.5..

Port Type tRFC RFC destination (R/3 connection) Application server for receiving system Port name (assigned automatically) © SAP AG 1999 Only the name of an existing logical RFC destination is entered in the port definition.10 Port Definition . The system then generates a name for this port which consists of an "A" and a 9 digit number.  The RFC destination itself is maintained with the transaction SM59 as the "R/3 connection".5. There you can also set whether the numbers are to be assigned internally or by an external system. The automatic number assignment requires a number range which is configured in IDoc Interface Customizing.  Alternatively to port definition in the IDoc Interface.  (C) SAP AG BC620 10 . you can create tRFC ports from ALE Customizing.

11 Process Flow: Port Type tRFC IDoc Interface RFC Interface TCP/IP RFC Interface External System © SAP AG 1999      For tRFC a system calls a function module in a second system.5. Inbound function modules in the IDoc Interface are the function modules INBOUND_IDOC_ASYNCHRONOUS (new for Release 4. The function modules are therefore inbound function modules of the respective system. Non-R/3 Systems require the R/3 RFC library.0 System to an older R/3 release. The external RFC Interface can be generated for the function module from the development environment (transaction SE37) (menu: Utilities -> RFC Interface -> Generate). If a non-R/3 System wants to be able to receive IDocs by tRFC. It follows for the IDoc data exchange that the sending system is always the active system: It calls the function module in the receiving system and transfers the IDocs as tables. For further information see the ALE documentation (under R/3 Library->CA-Business Framework) (C) SAP AG BC620 11 . it still needs a function module that is configured like INBOUND_IDOC_ASYNCHRONOUS or INBOUND_IDOC_PROCESS. Therefore if you want to send IDocs from a 4.0) and INBOUND_IDOC_PROCESS (older releases). All IDocs transferred are saved asynchronously in the database using the single COMMIT WORK command. you must call INBOUND_IDOC_PROCESS there: This is set via the port version.

The logical unit is part of the network architecture SNA and identifies computers or also programs to be started. the port definition also contains technical parameters like the buffer size of the CPI-C data buffer or a flag showing whether the R/2 System should send a confirmation of receipt. that is.2 (IDoc Interface). the R/3 System also collects the IDocs from the R/2 System under inbound processing. The exact functions and configuration of this port type can be found  In the R/2 manual S53. The logical destination is assigned a logical unit on the R/2 side in a sideinfo-file of this gateway.12 Port Definition: CPI-C (R/2 System) sideinfo-entry TXCOM entry Host on R/2 Host destination RFC destination Technical parameters Send status records? © SAP AG 1999      The logical destination and the host destination are determined in the port definition. The reason for this is that the R/2 System is always passive. The TXCOM entry refers to a gateway. Unit 8 of the manual describes in detail how the sending and receiving side of the CPI-C connection in an EDI subsystem are configured  In the R/3 OSS note 61524 and  In the R/2 OSS notes 52553 and 57014. The host destination indicates an entry in the R/3 internal table TXCOM. Besides the target system. The RFC destination is created with the transaction SM59 and contains the logon data (name. password). (C) SAP AG BC620 12 .5. but rather also technical parameters are also important for inbound processing. Note that for this port type not only the name.

The data bindings supported are:  R/3 outbound.0H.5. from R/3 Rel.0F. the communication is always started from the R/3 System. IDoc from R/2 to R/3 (R/3 receives IDocs: from R/2 Rel. 5.1)  Status report (R/3 sends exactly one status record per IDoc: from R/2 Rel.2 R/2 IDoc Interface © SAP AG 1999 The R/2 System is always passive. 5. Communication structure CPI-C TCP/IP 2.0)  R/3 inbound.0F. 3.2 protocol commands to the R/2 side (IBM mainframe)  TCP/IP protocol commands to the R/3 side (client/server systems)  The IDocs are saved synchronously in the database.13 Process Flow: Port Type CPI-C R/3 IDoc Interface 1.  (C) SAP AG BC620 13 . IDoc from R/3 to the R/2 (R/3 sends IDocs: from R/2 Rel. 3. from R/3 Rel.1)  Status report (R/3 receives exactly one status record per IDoc: from R/2 Rel. from R/3 Rel.0F. 3. Retrieve/send IDocs or receive/send status records LU 6.1)  The CPI-C protocol commands are used (Common User Programming Interface). 5. 3. from R/3 Rel. The gateway converts the CPI commands into:  LU 6. 5.

 (C) SAP AG BC620 14 .  The general settings (IDoc Administration) contain the name of the folder where mails with the inbound IDocs are saved. the port definition contains mail attributes: .the name of a folder in which IDocs to be sent can be saved in the original system for control purposes.the title of the mail in the mail header .14 Port Definition: Internet Internet destination Internet address Folder name for outbound IDocs Additional mail attributes © SAP AG 1999 The most important part of the port definition is the Internet address (IP address).an explanatory text which can be read first when receiving a mail as the mail body .5. Normal IDoc inbound processing can only be started from this folder. Together with the IDoc it is transferred via SAPconnect to the Internet gateway (or the Microsoft Exchange server).  Furthermore.

or  To the Microsoft Exchange server.  For inbound processing.  The gateway (or the Exchange server) converts the IDoc table into MIME format.  To use this port type. the following parameters must be entered:  A SAPconnect node for address type INT (Internet) must be configured (for forwarding and managing Internet messages)  The user must have a SAPoffice address for address type INT to receive IDocs  The recipient of an Internet IDoc forwards this to the dummy user EDI USER (see the Help on the application in the port definition: “Configure the SAPoffice user address for the Internet”  (C) SAP AG BC620 15 .5.15 Process Flow: Port Type Internet IDoc Interface IDoc SAPoffice/SAPconnect MIME e-mail External System © SAP AG 1999 For sending via the Internet. Internet IDocs are displayed to the relevant users as mail attachments in SAPoffice. IDocs are converted to another format (SAPoffice name: R3I): a table with 255 characters. This table is transferred by SAPconnect:  To the Internet gateway (sendmail program). the procedure is reversed.

 (C) SAP AG BC620 16 .  In this ABAP function module you can program any type of processing.16 Port Definition: PI Own function module in the R/3 System Function module: Name and description © SAP AG 1999 For a port of type "programming interface". Only the interface is standard.  The standard system includes the function module OWN_FUNCTION as an example. only enter the name of the function module to be called for outbound processing.5.

 (C) SAP AG BC620 17 .  Inbound Processing Your function module must call the SAP function module IDOC_INBOUND_ASYNCHRONOUS. which saves the IDocs in the database and triggers the event.17 Process Flow: Port Type PI IDoc Interface IDoc Own function module © SAP AG 1999 Outbound Processing The IDoc Interface calls the function module and transfers the IDoc control records in table format.5. writing status records) is programmed by the user. Further processing (reading data. This event asynchronously starts inbound processing. processing data.

 As record types in the R/2 System always have the same structure.1/2.X  For port type "tRFC".1 Field 1 Field 2 2.0/3. Structures have changed in different releases.  Example: For R/3 Release 3. The structure is covered by R/3 Release 3.X Field 1 Field 2 New field 3 3.X structure  Version 2: Structure of Release 3. the partner function was included in the control record.18 Communication with Older Releases Differences in IDoc record types Field 1 Field 3 Field 2 4.5.2 © SAP AG 1999 The IDoc record types are defined in the dictionary by their structure. a non-R/3 System must also recognize the function module to be called. as well as the correct record types: INBOUND_IDOC_ASYNCHRONOUS (new in Release 4. the version is specified in the port definition:  Version 1: Record types are transferred using the Releases 2. no version must be maintained for port type CPI-C.  To be able to communicate with earlier releases.1 (version 2). with names becoming longer and new fields being added.X  Version 3: Structure of Release 4.0/3.0) or INBOUND_IDOC_PROCESS (older releases).   (C) SAP AG BC620 18 .0.

© SAP AG 1999 (C) SAP AG BC620 19 . before a port can be used.5. In addition. users can specify the release status for the external system via the version entry. users define the target system and the technical communication parameters.19 Port Definition: Summary  IDocs or status records are always exchanged with an external system via a port.  There are six basic communication techniques for the IDoc Interface. represented by the six different port types.  Additional technical settings must also be entered (also outside R/3).  In the port definition for the IDoc Interface.

1-1 Create a new port: From the initial node of the IDoc Interface. select IDoc → Port definition. As the first test does not involve triggering. Leave the Outbound file field empty. <SID> is the 3-character system ID (for example I40) nn is the number of your group (01 to 18) (C) SAP AG BC620 20 . check the settings using the corresponding pushbutton (check icon).5. choose File and select Create. From the Outbound file tab page.20Port Definition Exercise Unit: Port Definition At the conclusion of these exercises. Save your entries. You should use the port name PORT-nn. Select the logical directory EDI_GLOBAL_PATH and a suitable function module. Ensure that the file names can be generated dynamically. you will be able to: • Create a port You are a member of the EDI project team. The decision has been made to connect the EDI subsystem to the R/3 System via the file (port type "File"). you only have to maintain the Outbound file tab page.

6
Partner Profiles

 Standard partner profiles  Checking Partner Profiles  Fast entry

© SAP AG 1999

(C) SAP AG

BC620 1

6.2
Partner Profiles: Unit Objectives

At the conclusion of this unit, you will be able to:
 Explain the purpose of partner profiles and

process codes
 Maintain partner profiles

© SAP AG 1999

(C) SAP AG

BC620 2

6.3
Overview Diagram (Sending Data)

R/3 System
Post document

Archive IDoc ? Archive IDoc ?

Generate IDoc

Partner Profiles

Check partner, find port

Port Definition Port Definition

EDI Subsystem? EDI Subsystem?

Transfer data, process further

Documentation Documentation Tools Tools

© SAP AG 1999

The company SmartMart wishes to send purchase orders to QuickDeliver via EDI. QuickDeliver wishes to immediately post these purchase orders electronically. Both companies have R/3 Systems, use EDI subsystems and must configure their IDoc Interface accordingly.  SmartMart must configure the IDoc Interface for sending data (outbound processing or simply outbound): SmartMart defines QuickDeliver as a partner for message type ORDERS in the partner profiles and enters the port which has already been defined.

(C) SAP AG

BC620 3

6.4
Partner Profiles: Business Scenario

 SmartMart must define QuickDeliver as a partner.

You have already configured a suitable port in the port definition.
 In outbound processing, QuickDeliver is the partner

for the purchase order. In outbound processing, it is the partner for the order acknowledgment.

© SAP AG 1999

(C) SAP AG

BC620 4

6.5
Partner Profiles: Fields

Partner Permitted agents General Partner Message Port IDoc type EDI structure Permitted agents Outbound Processing

Partner Application Process code Logical message

Partner Message Process code Permitted agents Inbound Processing
© SAP AG 1999

MC parameters

The IDoc partner profile is divided into four areas:  General partner profile: Contains partner data from the master data as a key (2 fields: Number and type). Additional general parameters: For example, "party to be notified" when an error occurs if no special settings have been entered (in outbound or inbound).  Outbound partner profile (general): 3 keys are used - partner (3 fields: number, type, function), logical message (3 fields: (type, code, function) and the test flag. The partner refers to the general partner profile. Additional parameters: For example, the outbound port and IDoc type. This means that the values for partner, message and test flag define the port and IDoc type in a unique way. The outbound processing values must always be maintained, regardless of the type of outbound processing used (direct or using Message Control).  Additional parameters for outbound processing under Message Control (MC): This type of outbound processing (applied in MM and SD) uses the MC key (from the condition record): Application key and output type. The partner key part consists of the partner type and function and is taken from the general partner profile. You must ensure that you enter the correct partner function, that is, the one the application uses to call Message Control. Caution: The output type has nothing to do with the logical message in the IDoc interface.  Inbound partner profile: The same 7 key fields which are included in the outbound partner profile are used in this case. The partner refers to the general partner profile. Additional parameters: For example, the process code which defines the type of inbound processing (business process). Summary: Partner, message and test flag define the business process in a unique way.

(C) SAP AG

BC620 5

6.6
Checking Partner Profiles

© SAP AG 1999

Partner profiles can be checked for consistency. This function is reached via a pushbutton from the partner profile initial screen.  You should ensure that both parts of the outbound partner profile are maintained: The "outbound parameter" (general) part and the "Message Control" part: If the Message Control part is missing, a warning is always displayed, even if this part is not required because the system cannot recognize whether or not this part is needed. If you do not require the Message Control part, you should simply ignore this warning message.

(C) SAP AG

BC620 6

the test flag is not set. the name QuickDeliver is entered as the partner number using the form in which it appears in the master data. outbound processing always takes place using Message Control (MC). The message type is to be used productively. Note: Only the key fields are considered here! (C) SAP AG BC620 7 . Additional parameters for outbound processing under MC: The partner function and message type are entered from the general outbound settings.7 Partner Profiles: Outbound Processing I SAP Application Document MCMC MC settings settings MC record Document General+outbound General+outbound IDoc Interface / ALE Services IDoc Receiving System © SAP AG 1999       The company SmartMart wishes to send purchase orders from module MM to QuickDeliver. As a result.6. The message type is ORDERS. Additional parameter: Partner function LF (vendor): This function must be entered as it refers to the corresponding key in the MC record. As a result. SmartMart must maintain the following parts of the partner profile for QuickDeliver: General partner profile: Here. In the MM module. Outbound processing (general): Partner number and partner type are entered from the general settings. MC-specific keys are the application EF (purchasing) and the output type NEW (in contrast to change messages). IDoc outbound processing must therefore be configured. The partner type is LI: This identifies QuickDeliver as a vendor in the R/3 System.

Summary: In conclusion. output type NEW and the partner QuickDeliver. OtptType : NEW Process code: ME10 Message: ORDERS MC settings Partner: QD.. which are the key fields in this case. Port: SUBSYSTEM IDoc type: ORDERS01 Output type: ORDERS Permitted agent: EDI agent for partner QuickDeliver (QD) (purchase orders) General Outbound © SAP AG 1999      As always. The appendix contains a set of common combinations of MC and partner profile fields. As a result. Appl: EF. (C) SAP AG BC620 8 . the MC record determines the IDoc type.. hence the entire outbound processing.8 Partner Profiles: Outbound Processing II Partner: QD .6. There are other dependent fields such as "permitted agents" for notifications. port and function module. as well as the outbound port. will contain the application data).. the key fields determine the contents of the other fields. Appl: EF. They determine that the IDoc type ORDERS01 is to be used (that is. when SmartMart sends an order to QuickDeliver. the partner profiles have the following effect: Message Control (MC) creates a data record containing the application EF. these key fields define the process code ME10 and the message ORDERS. MC record Partner: QD . The message ORDERS and partner QuickDeliver are assigned to the corresponding fields in the general partner profiles. In the MC settings for the partner profile. language. OtptType : NEW Object type. The process code specifies the function module which inserts the order data in the IDoc type.

Partner number and partner type are entered from the general settings. As a result. which are assigned to the corresponding fields in inbound processing. Message: ORDRSP Process code: ORDR. Summary: The IDoc type determines the inbound processing for the IDoc. order acknowledgments Inb. the test flag is not set. The process code specifies the function module which reads the data from the inbound IDoc. The message type is ORDRSP (order confirmation). these key fields uniquely determine the process code. Permitted agents: EDI agent for partner QuickDeliver.9 Partner Profiles: Inbound Processing Partner: QD. As well as these key fields. (C) SAP AG BC620 9 . the partner profiles have the following effect: In the control record. Together with the test flag (also part of the control record). IDoc inbound processing must therefore be configured.6. If QuickDeliver now sends an order acknowledgment to SmartMart. the inbound IDoc contains the partner QuickDeliver and the message ORDRSP. SmartMart must still maintain the inbound part of the partner profile for QuickDeliver. The message is to be received productively. There are other dependent fields such as recipients of notifications. Processing © SAP AG 1999      SmartMart wants to be able to receive and process EDI order acknowledgments from QuickDeliver for their purchase orders. Message: ORDRSP IDoc type: ORDERS01 IDoc Control Record Partner: QD. the process code ORDR is an important data field. As a result.

The partner profiles only contain the process codes.6. Note: Process codes are client-specific! (C) SAP AG BC620 10 . In addition. IDocs are processed in these cases. Partner profiles contain process codes for inbound and outbound processing. This process code always identifies a function module. process codes for error handling are configured in the IDoc Interface. so that all processes connected to the IDoc Interface can be processed via a process code.10 Process Codes I Partner Application Mess.type Process code Function module (writes the application Process code Example: MC parameters in partnerIDoc) data in an outbound profiles © SAP AG 1999      A process code is only another name for a process carried out by a function module or a workflow. Only one process code exists for outbound processing when Message Control (MC) is used (because the direct way simply sends an IDoc to the IDoc Interface). which do not save any work in the above sense. They were introduced for completeness. You can therefore replace an old process with a new one for all relevant partners in one single step: Assigning the new process to the existing process code. that is data is written to the IDocs or read from the IDocs. never the real name of the function module.

(C) SAP AG BC620 11 .6.11 Process Codes II Example: Inbound Partner Message Process code Process code Function module/workflow (reads data from an inbound IDoc and processes data further) © SAP AG 1999 The inbound partner profiles always contain a process code which specifies either a workflow or a function module (direct processing).  There are two types of process codes for error handling:  System: Error handling for IDoc processing (both inbound and outbound)   Process code status: Error handling for status confirmation All process codes are assigned to processes via the Control menu in the IDoc Interface.  See the online documentation for more information about process codes.

 Then choose Documentation → Process code from the initial node of the IDoc Interface. search for it via the "logical" message (for example ORDERS for a purchase order).12 Process Codes III Documentation via messages Message n m Process code © SAP AG 1999 In order to find the correct process code for your business process.  (C) SAP AG BC620 12 .6. For new definitions of business processes or IDoc types you determine new process codes or messages in the assignment table (see BC621).  There is an n:m relationship between process codes and message types.

 Other port types always include external system triggering (because the IDocs are not saved temporarily in files but transferred directly). no trigger © SAP AG 1999 The transfer time is only defined if the external system is triggered. Only outbound modes which include triggering are displayed here.  The IDoc Interface programs use sequential numbers for outbound modes: field OUTMOD has values from 1 to 4 (read from top to bottom in the diagram).  (C) SAP AG BC620 13 .6. which helps maintain data consistency. no trigger Transfer multiple IDocs + start external system (trigger) Transfer multiple IDocs.  Non-triggered data transfer includes the danger that IDoc or status files may be processed several times or not processed at all.13 Outbound Modes: Port Type File Partner profile Description Transfer single IDoc + start external system (trigger) Transfer single IDoc.

Also check the "application help" in the transaction.6.  Partner profiles can also be sent via the special IDoc type SYPART01. A partner profile for this IDoc type with the "logical" message SYPART is therefore a prerequisite.  The tree can be printed from the menu System->List.14 Partner Profiles Output Display © SAP AG 1999 Partner profiles can be displayed in the R/3 System (the same initial access as create). even for several partners.  (C) SAP AG BC620 14 . A link from the Utilities menu leads to the tree output which provides a clear means of display.

Inbound ports do not require such parameters .15 Partner Profiles: Summary  Partner profiles specify which messages are sent to which users. © SAP AG 1999 (C) SAP AG BC620 15 .their technical parameters are defined by the external sending system.  The port (the "way") is part of the outbound partner profile. Partners must be entered in the partner profile before IDocs can be sent successfully. They are used for processing data.6.  Process codes which are defined outside the partner profile are used in error handling. using which method and how they are processed. Technical communication parameters are entered in the port definition.  Process codes are also part of the partner profiles.

The actual processing of the IDoc is selected via the process code.16Partner Profiles Exercise Unit: Partner Profiles As a member of the EDI project team for your company. select the IDoc type ORDERS01. choose IDoc → Partner Profile. enter the data structure for the exchange as an IDoc type. Using the information sent to your system by the EDI subsystem in the control record. There. nn is the number of your group (01 to 18). Firstly. 1-2 From the initial node of the IDoc Interface. there can be several process codes for one message. Firstly. Check the settings you have entered by selecting Partner → Check. The process depends on the vendor and the message. The message is ORDERS. enter the header data for the vendor. 1-3 1-4 Now configure inbound processing for the order acknowledgment in Create inbound parameters. In output mode choose Send IDoc immediately and Do not start subsystem. Configure the outbound processing. Finally in this view. the correct partner profile can be determined. maintain the Outbound options: The recipient port has already been maintained as PORT-nn and represents the connection to the EDI subsystem. In MC. Enter the vendor (code LF). As outbound processing for confirmations is determined via Message Control. the process is identified by the partner function (code LF) and the application (application EF and message type NEU). Choose Create outbound parameter. 1-5 (C) SAP AG BC620 16 . As you are going to use the standard system. enter a permitted agent.6. You determine how the document data is generated as an IDoc via the process code. 1-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 been created for you. Select the most recent version of confirmation outbound processing via process code ME10. You should remember that in certain circumstances. you must also maintain the Message Control tab page. enter the company T-BILnn as the EDI vendor with whom purchase orders and order acknowledgments are to be exchanged. The application is linked to Message Control. Position the mouse on the partner type LI and choose Create. Select the process code ORDR. You should therefore select the message ORDRSP to identify the process.

(C) SAP AG BC620 17 .

7 The Test Tool Test Tool Options © SAP AG 1999 (C) SAP AG BC620 1 .

7.2
Test Tool Options

© SAP AG 1999

You always create a new test-IDoc with the test tool. However, you can use one of the IDocs available in the database as a template and edit the copy.  You can add or delete segments and therefore create your own IDoc type in an ad hoc manner.  You can change the content of every single segment field  You can change all the control record fields  There are other possibilities if you do not want to use an IDoc as the model for editing:  You can enter data in the empty IDoc type (including the control record)  You can import an IDoc from a file.  You can even create an IDoc from nothing by simply adding segments step by step.  The test tool saves the edited IDoc as a new IDoc in the database before the actual processing test begins.

(C) SAP AG

BC620 2

7.3
Test Tool Options (2)

Function Module
Direct call (inbound only) Mass test Standard processing
© SAP AG 1999

The following options are available in the test tool for both inbound and outbound processing:  Standard processing: Your test IDoc is sent for normal inbound or outbound processing.  Mass testing: Several copies of the edited IDoc are sent for processing. If the relevant flag is not set, only one copy is sent.  In addition, the following options are available for inbound processing:  Generate file: In the case of a port with type "File", an IDoc file is created during inbound processing. The test tool takes over the role of the external system. Inbound processing does not have to be triggered by the generation of the IDoc file, which means that the IDoc file is not deleted by the system and is therefore available for further tests.  Direct call of inbound function module. This allows the function module to be debugged. If this flag is not set, the IDoc is sent for standard processing, as in the outbound test.  Like the other test programs, the test tool has a special test status with which you can identify test IDocs in the monitoring programs.

(C) SAP AG

BC620 3

Generate file

7.4 Test Tool Exercise
Unit: Processing Tests Topic: Test Tool (order acknowledgment)

At the conclusion of these exercises, you will be able to: • Use the test tool • Use IDoc display to trace IDocs

As a member of your EDI project team in purchasing, you want to test the following as soon as possible: • • 1-1 Sending purchase orders Receiving order acknowledgments

Create a purchase order for methanol (material number SH-100) from the vendor TBILnn by selecting Logistics → Materials Management → Purchasing → Purchase Order → Create → Vendor Known (transaction ME21). 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). After the data has been entered successfully, 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 has been selected, an IDoc for this purchase order is generated as soon as the data is saved. Change to Purchase Order → Display. By selecting System → Links the IDoc that has just been generated is displayed. You can now use the purchase order IDoc that has just been generated as a template for the inbound order acknowledgment to be tested. 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. Select the control record (the first record) by clicking with the mouse and change the following fields: Recipient, Port: Sender, Port: Sender, Partner number: SAP<SID> PORT-nn T-BILnn

1-2

1-3

1-4

2-1 2-2

2-3

(C) SAP AG

BC620 4

you can display the IDoc which is linked to the outbound purchase order. you will see the acknowledgment number that has just been transferred. create a corresponding segment. in segment E1EDP01. qualifier 001. 2-6 2-7 Choose Standard Inbound and then Continue. field document Document item. field document item (C) SAP AG BC620 5 . in segment E1EDK02. 2-5 The acknowledgment of your vendor now has to be assigned to the item. as well as the IDoc which is linked to the inbound acknowledgment. If you double-click on the item. Partner function: Message type: Choose Continue.Sender. You can display the changed order by selecting Logistics → Materials Management → Purchasing → Purchase Order → Display. ID3) nn is the number of your exercise group (from 1 to 18) 001 Order number. <SID> is the 3-character system ID (for example. Partner type: Sender. By selecting System → Links from the item overview. Create a corresponding segment E1EDP02 directly after the item segment E1EDP01 as a subsegment. Maintain the following fields: Qualifier: Document: Document item: Choose Continue. 2-4 LI LF ORDRSP As the order acknowledgment should contain at least the order number of the vendor. The system changes your original order. Copy segment E1EDK02 and change the following fields: Qualifier: Document : 002 For example BC620Test-4711 Choose Continue to close the dialog box.

8 Message Control and IDocs  Message determination and message processing  Condition components  Dispatch times © SAP AG 1999 (C) SAP AG BC620 1 .

you will be able to:  Explain condition components  Find examples of condition components in MM Customizing  Display and process the proposed message from the MM application transaction © SAP AG 1999 (C) SAP AG BC620 2 .8.2 Message Control and IDocs:Unit Objectives At the conclusion of this unit.

A purchase order from SmartMart is firstly created as a message by the Message Control module. you are responsible for configuring the IDoc Interface. before being converted into IDoc format.8. © SAP AG 1999 (C) SAP AG BC620 3 . but wish to find out more about other Message Control functions. You know that the basic settings for this module exist in the standard SAP system.3 Business Scenario  As a member of the implementation team for SmartMart.

if the order is to be printed. Part of this record is the processing status. In the following example. 1 = successfully processed.4 Outbound Processing using Message Control SAP Application Document Find proposal Edit Process MC MC record IDoc Interface/ALE Services © SAP AG 1999       Message Control (MC) generates messages from application documents. MC searches for those which match the current application data.8. In any case. or possibly none. If supported by the application. The possible messages are defined as condition records in Customizing. From the possible messages. a special processing program is called from the IDoc Interface. If the message is to be sent as an IDoc. this slide does not show the transfer of the IDoc to an external system. which can have the following values: 0 = not yet processed. (C) SAP AG BC620 4 . 2 = processed with error. This message determination can result in several messages being found. this means that the message proposal can be edited (displayed and changed) before the purchase order is posted. the processing program sends the message to the printer. although this is also part of outbound processing. we will presume that one message was found. When creating a purchase order. this message is proposed for editing in the transaction which started MC. the message is generated and processed (if not deleted during the editing process): for example. Note: For reasons of clarity. The new message is represented by a new entry in the MC table.

Message Control allows a dispatch time flag to be set. otherwise the message remains as an MC record with processing status 0. for example IDoc © SAP AG 1999 The process diagram shows message determination.  Table TNAPR contains the processing programs (RSNASTED in the case of EDI).   (C) SAP AG BC620 5 .5 Message Control SAP Application Editing Application data Message Determination MC record Message proposal Processing (table TNAPR) Processing program.8.  The MC record refers to the document as a BOR object (BOR = Business Object Repository) which contains all the important data for the message. message editing and message processing. for example RSNASTED Output. which determines whether the message is processed immediately after the application document is created or at a later time. you must schedule report RSNAST00 as a job. In the second case. Form routine EDI_PROCESSING is accessed within this program.

If this flag is not set. Messages defined in Customizing are searched in a specified sequence. which is also used in SD price determination. (C) SAP AG BC620 6 . you should set the "exclusive” flag. for example the application EF (purchasing).6 Condition Elements SAP Application 1:n Procedure m:n Output Type n:1 Access Sequence m:n Condition Table © SAP AG 1999      Message determination uses the condition technique.8. The condition tables can be accessed according to a certain access sequence with different key fields. Several output types can belong to one procedure and several procedures can belong to one application. only the procedure for that application and the current application object (for example the document) is searched for corresponding messages. The condition elements and their hierarchy define this sequence. The messages are records in a condition table. if one application wishes to send EDI messages via Message Control. the entire access sequence is processed. Several condition tables can belong to one output type. Therefore. several messages have possibly been found. that is. The condition component "Access sequence” can be used to define whether only one message is to be found: If this is the case.

 IDocs are transferred individually from program RSNASTED when using output modes "1" and "2" (field OUTMOD in the control record). they are collected by the program RSEOUT00 (batch mode) and sent as a group. that is. The transmission media for IDoc processing with Message Control are:  "6" EDI (Electronic Data Interchange). with the form routines EDI_PROCESSING or ALE_PROCESSING.  (C) SAP AG BC620 7 .8. Instead. without distribution model  "A" ALE (Application Link Enabling).7 Message Processing: IDocs Check MC record Read partner profile Call selection module (from application) Call ALE Services Transfer according to output mode R S N A S T E D '3'/ '4' '1'/ '2' Single IDoc Multiple IDocs via RSEOUT00 © SAP AG 1999 The transmission medium is part of the condition record (the message defined in Customizing). with distribution model The EDI program for message processing is started with these parameters: RSNASTED.  IDocs are not transferred directly when using output modes "3" and "4" (field OUTMOD in the control record). that is.

To use the system resources efficiently. while the program is started automatically if "immediately" is selected. the MC dispatch time "later" (1 or 2).8.  Batch: A stack of IDocs is sent to the external system when the IDoc Interface selection program is started manually or as a batch job. This can result in large amounts of data requiring inbound processing in the EDI subsystem in a short space of time.  If an EDI subsystem is the external system and port type "file” is used. If "later" is selected. there is a third stop sign: The subsystem.  (C) SAP AG BC620 8 . the program must be started manually (for test purposes) or as a batch job (in production operation). you should select the first stop sign.  Recommended combinations of stop signs (see slide):  Real time: IDocs are sent to the external system individually when the application documents are created. Procg using MC Application Post MC VSZTP = 4 IDoc Interface OUTMOD = 1 External System Real time Post VSZTP = 1 OUTMOD = 1 Fast batch Post VSZTP = 1 OUTMOD = 3 Batch Post VSZTP = 1 OUTMOD = 4 Batch © SAP AG 1999 You should note that there are two different dispatch times for outbound processing using Message Control: one controlled by MC. the other by the IDoc Interface. Each of these times can be switched between "immediately" and "later". when it is not triggered.8 Dispatch Times in Outb.  Fast batch: IDocs are sent to the external system individually when the MC selection program is started manually or as a batch job.

 IDoc-specific message processing takes place via program RSNASTED. This sequence is defined by the condition components and their hierarchy.  Messages defined in Customizing are examined in a certain sequence to determine whether or not they apply to the current application data. © SAP AG 1999 (C) SAP AG BC620 9 .9 Summary  Message Control is important in IDoc outbound processing.  Up to three different dispatch times can be defined for outbound processing.8.

For this you create an individual output type and condition records. nn is your group number (C) SAP AG BC620 10 . You should use 6 (EDI) as the transmission medium. You must also ensure that the possible partner function AG (sold-to party) is entered for your new output type. 1-1 Create the output type ZBnn as a copy of output type BA01 in transaction NACE. 1-3 Determine your new output type in the procedure for the sales Order messages (application V1). 1-2 You must transfer the processing program and routine for your transmission medium EDI from output type BA01 .8. Go to the navigation Control for this procedure. 1-4 Now create a condition record for output type ZBnn for your partner T-BIKnn of sales organization 1020. The output type should provide the transmission medium 6 (EDI) as the default values for the condition records. you will be able to: • Create an output type • Create a condition record As a member of the EDI project team you must configure the electronic dispatch of an order acknowledgment.10 Message Control and IDocs Exercise Unit: Message Control and IDocs Topic: Condition Elements At the conclusion of these exercises.

You must fill this condition table in the last part of the exercise. you must confirm that you also want to copy all of the dependent entries. Select Output types. EN (English). to EDI.. Choose Procedures. now select the entry Partner functions. When saving. Check the entry. To add the partner function AG. which contains a condition table. The program RSNASTED and the form routine EDI_PROCESSING must be determined for the transmission medium 6 (EDI). select the application V1 (sales). 1-3 In the initial screen of the transaction NACE. You must still maintain the language field for the dependent entry for the mail title (also if you do not use the transmission medium “mail”).8. go to change mode and select BA01. for example. Enter ZBnn as the target entry. In the Default values tab page change the transmission medium.. Select the procedure V10000 (order messages).11Message Control and IDocs: Solution Unit: Message Control and IDocs Topic: Condition elements 1-1 In transaction NACE select Expert mode and choose the application V1 (sales). Note: By copying you have also transferred the access sequence of the original BA01. select New Entries and enter this function for the transmission medium 6 (EDI). Choose Edit → Copy as. select your new output type ZBnn. Save your changes and return to the initial screen of transaction NACE. if necessary. 1-2 In the output types screen. (C) SAP AG BC620 11 . Choose. In the navigation frame. In the navigation frame select the entry Processing routines by double-clicking.

here as an IDoc.In the navigation frame select the entry Control by double-clicking. in order to ensure that in determination your output type is searched every time for messages. Finally the message is sent to them. it is identical to the customer. 1-4 In the initial screen of the transaction NACE. nn is your group number (C) SAP AG BC620 12 . Position the mouse on ZBnn and select Condition records again. Save your changes and return to the initial screen of transaction NACE. Choose New Entries. select the application V1 and choose Condition records. The maintenance interface is the same as in the NACE initial access. In the present case. Make the following entries in the condition table: Customer Function Transmission medium Time Language T-BIKnn AG 6 (EDI) 4 (immediately) EN (English) You can leave the partner field empty as the partner is determined from the customer master data. Enter the sales organization 1020 in the selection screen and select continue. Note: The condition table is usually maintained in the sales master data as an order message. Save your changes and return to the initial screen of transaction NACE. Enter the following: Level (determines the order) Counter (not relevant here) CTyp (= output type) 1nn (100 + your group number) 1 ZBnn Do not enter a condition.

9
General Settings

 Number ranges  Event-receiver linkage  IDoc administration  Fast entry  Long names - short names

© SAP AG 1999

(C) SAP AG

BC620 1

9.2
General Settings: Unit Objectives

At the conclusion of this unit, you will be able to:
 Configure the general parameters in the IMG  Describe when the IDoc Administrator is notified

© SAP AG 1999

(C) SAP AG

BC620 2

9.3
Customizing using the IMG
R/3 Customizing IMG

Cross-application components

IMG documentation Project documentation

IDoc Interface

Project management

Activities

©SAP AG 1999

General parameters for the IMG can be entered via the IMG. The IMG is a set of implementation guidelines which can be used by customers to configure the R/3 System to meet their requirements ("Customizing"). The corresponding tables are maintained via activities.  By selecting the appropriate attributes, users can display only the activities which are required in each case. For example, if a customer wishes to adopt all SAP standard settings, only the activities with the attribute "required" must be executed.  The IMG node or path for the IDoc Interface is Cross-application Components ->IDoc Interface. You should read the IMG documentation, which is available for each activity (double-click on the relevant document).  You can also create your own projects from the standard IMG: Projects are a type of view of the standard IMG, which are used by different teams. The IMG offers project management functions (resource planning and so on) as well as functions for creating your own project documentation via customer notes.

(C) SAP AG

BC620 3

This is called "internal number assignment".  (C) SAP AG BC620 4 .IDocs: the IDoc IDs are taken from the interval  .4 Number Ranges IDoc Interface […] © SAP AG 1999 Number ranges are intervals of natural numbers which are assigned to objects centrally by the R/3 System.Ports: the names of the tRFC ports are defined by the interval  .  In the IDoc Interface.Mailbags: These are only used for communication with an R/2 System.9. IDocs are transmitted in mailbags  These number ranges are maintained from the IMG node for the IDoc Interface. number ranges are set for:  .

This is made possible by the workflow event concept: If IDocs are saved in the database.  To enable this new form of inbound processing to take place. the corresponding event must be actively linked to the receiver.  You must therefore activate the event-receiver linkage in the IMG for the IDoc Interface. an event is created . As a result of this step. which no longer exists in the system.9. they are first saved in the database.  (C) SAP AG BC620 5 . the function module has used the event. In a second and independent step.5 Event-Receiver Linkage IDoc Interface Processing R/3 Application © SAP AG 1999 When IDocs are received. which waits for the "receiver" in the system. The "receiver" (a function module) finds the event and triggers inbound processing. "XML". "CPI-C"). The Workflow Manager determines when the receiver starts to search for events: There is therefore an interval between the data being saved and further processing being initiated (asynchronous processing). they are processed further (for port types "file".

it is possible that the IDoc interface may call function modules.  After how many data records a COMMIT WORK is initiated. for example Message Control or application components.9.  Whether or not IDoc inbound processing is triggered synchronously (not via the event-receiver linkage) (port type File).  In the system environment. but only subsequent errors. immediately after the event of the event receiver  System parameters can be entered as "global parameters" from the initial screen of the IDoc interface by choosing Control->IDoc Administration or can also be set from the IMG node of the IDoc interface. that do not exist in the specified system (Basis system only).  (C) SAP AG BC620 6 . the higher the probability that the error messages do not refer to "real" errors. the partner-specific agent (and the message-specific agent. if required) entered in the partner profile is notified. the IDoc interface is informed whether non-Basis components exist. Otherwise. If these entries are not made.6 IDoc Administration: Global Parameters  Party to be notified (IDoc Administrator)  System environment (Basis system?)  Processing details © SAP AG 1999 © SAP AG The IDoc administrator is always notified when an error occurs during IDoc processing and no partner profile could be found.  Processing details:  The maximum number of syntax errors which can be recognized in one IDoc and therefore logged as status records. The larger this value. for example. In this case. You should also see the F1 Help function for the input fields.

 For the documentation tools.  You can enter a default development class for the development of IDocs and segments.7 IDoc Administration: User Parameters  Tests  Documentation Tools  Development © SAP AG 1999 © SAP AG User-specific parameters for the IDoc interface cannot be entered from the IMG.  The test parameter is the port proposed as standard by the test programs. Instead. Course BC621 contains more information about developing and defining IDoc types.  (C) SAP AG BC620 7 .9. you should define the default documentation output. whether the individual segment fields are also to be included in the documentation of IDoc types. for example. choose Control -> IDoc administration from the initial node of the IDoc interface.

which facilitates the maintenance of the partner profiles in the IDoc interface. the values which you have entered in the IMG for the current partner type and direction are entered as the default values. default values ("templates") are already set in the IMG .forecast/JIT delivery schedule  ORDCHG .order/sales confirmation (C) SAP AG BC620 8 . The default values are set for partner type and direction (inbound/outbound). In the IDES system.purchase order/sales order  DESADV .8 Fast entry Default values © SAP AG 1999      During fast entry of the partner profile values. According to your requirements.9. depending on the direction:  DELINS .invoice/billing document  ORDRSP .shipping notification  INVOIC . you need only select and modify these values. the following message types are maintained for the vendor or customer. If you select the fast entry option for partner profiles (via the pushbutton on the initial screen. You can also reach the transaction from the initial node of the IDoc interface. see later unit).change purchase order/sales order  ORDERS .

X Type "LongNameXYZ01" Type "Short01" © SAP AG 1999 Release 4. You should also read the online documentation.0 Release 3.0 (for example IDoc types) can have longer names than before.0 introduced the concept of the extended namespace.Short Names Release 4.9. tables which can convert the long names to short names must therefore be maintained.  This fact can lead to problems when communicating with older releases which only recogníze short names.  These tables are maintained in the IMG or from the IDoc Interface development (path for segments or IDoc types from the relevant editor: Environment -> Conversion -> <object name>). new IDoc Interface objects which were developed for Release 4. As a result.9 Long Names .  (C) SAP AG BC620 9 . If required.

 The IDoc Administrator is part of the global parameters which are maintained in IDoc Administration. user-specific parameters can be changed at any time via the control menu.9. the administrator is always notified if no partner profile is found. When exceptions occur. In addition.10 General Settings: Summary  General settings are entered via the IMG. © SAP AG 1999 (C) SAP AG BC620 10 .

1-1 Go to IDoc Interface Customizing (choose Basis Components → Basis Services → IDoc Interface) and check the following default values: Outbound Processing: Parameter Partner type Message type Partner function Basic type Application Output type Process code Inbound Processing: Parameter Partner type Message type Partner function Process code (C) SAP AG BC620 11 Value KU ORDRSP AG ORDERS01 V1 BA00 SD10 Value KU ORDERS AG ORDE .11 General Settings Exercise Unit: General Settings Topic: Fast data entry At the conclusion of these exercises. As a member of the EDI project team enter the company T-BIKnn as the EDI customer for the sales orders and order acknowledgments As you expect further EDI customers for these messages.9. you want to use corresponding proposals in Customizing. you will be able to: • Maintain the default values for fast entry.

Go to the outbound parameters for message ORDRSP.2-1 Now transfer these default values to the partner profiles of your customer. Save your entries. 2-2 From the initial node of the IDoc Interface. Choose Utilities → Fast Data Entry and enter the customer number T-BIKnn. 2-3 2-4 nn is your group number (C) SAP AG BC620 12 . The logical message is ORDRSP. Choose Utilities → Fast Data Entry again but now for inbound processing. choose IDoc → Partner Profile. Select the proposal for outbound processing. Replace output type BA00 with your output type ZBnn from the exercise in the “Message Control” unit. The logical message is ORDERS. As a result you can • • Receive sales orders from the customer Send order confirmations to this customer The corresponding master data in the SD application has already been created for you.

10 Additional Test Programs  Test layers  Test programs © SAP AG 1999 (C) SAP AG BC620 1 .

10. you will be able to:  Use special test programs and determine when to implement them during processing © SAP AG 1999 (C) SAP AG BC620 2 .2 Processing Tests: Unit Objectives At the conclusion of this unit.

The IDoc Interface test programs are to be used for this purpose and this unit contains information about using these tools. you are responsible for configuring the IDoc Interface. you wish to test data transfer.10. © SAP AG 1999 (C) SAP AG BC620 3 .3 Processing Tests: Business Scenario  As a member of the implementation team for your company (SmartMart or QuickDeliver). After tests have been completed successfully in your own system and the EDI subsystem has been connected.

including the file system.10. Both inbound and outbound processing can be tested for one IDoc (which can even be created manually). Outbound processing is on the left. the inbound test IDocs are processed directly in the application or via a workflow. The test tool (transaction WE19. also see "Statistics and Monitoring").4 Test Layers: Overview Application MC WE15 Workflow WE19 . a message status record (MC record). According to the process code (partner profile entry). All test programs write a special status. File System WE18 © SAP AG 1999       The arrows show the layers where the tests start. a complete test cycle (from outbound processing to inbound processing) can be executed. If a file port is selected in outbound processing. The other test programs require either an existing file. or a file in the file system (at the operating system level). inbound processing on the right. see corresponding unit) is the most general tool. The IDoc statistics provide an overview of all test IDocs (F5 key. WE19 WE16 WE17 External System Outbound IDoc file WE12 Inbound IDoc file Status confirm. WE18 IDoc Interface WE14. Alongside is the relevant transaction. Hence you can determine whether or not each IDoc was generated for test purposes. (C) SAP AG BC620 4 .

you can test whether an IDoc is created correctly from a generated MC record. go into debugging mode or export messages. trigger further processing manually.  Both the IDoc test (transaction WE14) and the test tool (transaction WE19) test the transfer of one or more IDocs to the specified port.10. dispatch time 1 or 2 must be configured in the message condition record: This stops message processing. which is not possible in other cases. Only these modules and messages use Message Control for IDoc outbound processing. an outbound IDoc which has not been sent to any ports must exist already (current status 30). that is. As a prerequisite for the IDoc test. Transaction WE15 does nothing but start program RSNAST00. that is. using transaction WE15: In the corresponding partner profiles.5 Test Layers: Outbound Processing Application MC MC WE15 IDoc Interface WE14. The corresponding message types are ORDERS. the processing program RSNAST00 is not started directly when the application document is created. you can. Using this method. In this case. for example. and the MC record is assigned the status 0 (not yet processed).  (C) SAP AG BC620 5 . Such an IDoc can be generated.  Note: Transaction WE15 can only be used in conjunction with moving data from the applications SD and MM. for example. ORDRSP. so that the IDocs are not forwarded immediately. There are no prerequisites for the test tool. the output mode must be entered as "collect IDocs”. WE19 External System ©SAP AG 1999 When testing from MC (transaction WE15). for example. DESADV and INVOIC.

before the IDoc is sent to the IDoc Interface. The test tool can even create inbound IDocs if necessary. which are read by WE12 and can therefore be used for further test runs.  Note: WE16 erases the inbound file after the file has been read successfully.10.  (C) SAP AG BC620 6 . This does not apply to outbound files. WE12 changes control records to create an inbound IDoc from an outbound IDoc.  There are no prerequisites for the inbound test tool: no inbound port of type "file" is needed and no files are required from the file system.  Check the online documentation (extended help) for the test tools.6 Test Layers: Inbound Processing Application Workflow WE19 IDoc Interface WE16 Outbound IDoc file WE12 Inbound IDoc file File System © SAP AG 1999 Both the modified outbound file test (transaction WE12) and the original inbound file test (WE16) test the transfer of an IDoc file via the IDoc Interface.

WE18 IDoc Interface WE16 WE17 Outbound file with SYSTAT01 WE12 Inbound file with SYSTAT01 Status confirm. a work item is generated. IDocs of this type must be present in file form. otherwise an error occurs in status processing. (C) SAP AG BC620 7 . SYSTAT01 can be used with all the inbound test programs. The IDoc display function can be used to check if the status records were written correctly to the relevant IDoc. a workflow is started: The (status) process code for this purpose in the standard system is EDIS. The test can therefore be carried out only once for each file. Transaction WE18 ("generate status file") does not need a file as it is self-generating. the status file is deleted after being read successfully.7 Test Layers: Status Confirmation Application Workflow WE19 . If an incorrect status is returned. Caution: As in the case of an original inbound IDoc. except in the case of the test tool. Status records must refer to outbound IDocs in the system. When a status record is received which indicates an error. which is processed by standard task TS300000206. Other process codes for other tasks/workflow definitions for status processing can be created via Control -> Status process code and Control -> Status maintenance from the IDoc Interface initial screen. File System WE18 © AG 1999 SAP      You test the transfer of status confirmations in file format with "process status file" (transaction WE17). The general status confirmation for all port types and directions runs via the special IDoc type SYSTAT01. This status processing therefore always takes place via workflow.10.

WE17 (status confirmation. inbound)  Processing MC record: WE15  Data transfer from the IDoc Interface to additional inbound processing: WE19  Data transfer to any port: WE14 © SAP AG 1999 (C) SAP AG BC620 8 .8 When to Test Which Function?  Data exchange with the file system: WE14 (outbound).10. WE16 (inbound).

automatic outbound processing must be stopped via the output mode from the partner profile and the dispatch time in the MC condition record.  The test tool allows general tests for inbound processing. files or existing IDocs from the database. If necessary. outbound processing and status confirmation via SYSTAT01.10.9 Processing Tests: Summary  Special test programs require MC records. © SAP AG 1999 (C) SAP AG BC620 9 .

11 A Process Chain  Send purchase order  Post standard order © SAP AG 1999 (C) SAP AG BC620 1 .

you will be able to:  Send a purchase order via IDoc  Receive a standard order via IDoc  Explain which EDI-specific master data must be maintained © SAP AG 1999 (C) SAP AG BC620 2 .11.2 A Process Chain: Unit Objectives At the conclusion of this unit.

11. © SAP AG 1999 (C) SAP AG BC620 3 . For test purposes. you are responsible for configuring the IDoc Interface.3 A Process Chain: Business Scenario  As a member of the implementation team for your company (SmartMart or QuickDeliver). IDocs are to be created by SmartMart and sent to QuickDeliver.

 The key fields in the partner profile (outbound processing using Message Control) are assigned to the corresponding key fields in the partner profile (general outbound processing). The partner profile specifies that the IDoc is immediately sent to the port. The master data for the vendor QuickDeliver therefore contains a condition record which uses the order to find the corresponding EDI message and writes an MC record. They determine the process code. process further External System = SmartMart EDI Subsystem © SAP AG 1999 For SmartMart. send to port Copy data.11.  The IDoc Interface now knows which IDoc type to generate with which function module. (C) SAP AG BC620 4 . which in turn defines the outbound processing (generating an outbound IDoc using a function module). the data flow appears as follows:  As the purchase order is created in MM. This determines the IDoc type (ORDERS01) and the port. The IDoc is created.4 Purchase Orders for SmartMart R/3 System .SmartMart Post purchase order. write MC-record Find port (type .  The key fields in the MC record are assigned to the corresponding key fields in the partner profile (outbound processing using Message Control)."File") for QuickDeliver Generate IDoc. outbound processing has to take place using Message Control.

the vendor master record must contain the partner function. function Vendor master record : Vendor account Material master record: Material name Vendor material number: Material name for vendor MC condition record with transmiss.  (C) SAP AG BC620 5 . The partner function is a required field entry in the additional outbound partner profile using Message Control (MC). medium "6" (EDI) © SAP AG 1999 Data record E1EDKA1 (PARVW = "LF"): Partner information E1EDKA1 (PARVW = “AG”): Partner information E1EDP19 (QUALF= “001”): Material number E1EDP19 (QUALF= “002”): Material number IDoc Type ORDERS01 Data record Data record Data record The MM master data must contain certain parameters which are sent to the order recipient via IDoc: Apart from the partner number and type. The recipient cannot see this value. additional conversions are required in the recipient system.  The vendor material information must contain the material name for the vendor. because the recipient determines from the contents of a segment of type E1EDP19 which material has been ordered. type. If another transmission medium is entered.  The vendor master record should contain the name which appears as the partner number in the recipient partner profiles as the "account with vendor" (field LFB1-EIKTO). If this field is not maintained.  The MC condition record must contain a transmission medium "6” (EDI).11.5 EDI-Relevant Master Data in Purchasing Vendor master record : Partner number. the IDoc Interface will not be activated. This field is compared with the partner number value in the recipient inbound partner profile.

11.6 Standard Order for QuickDeliver External System = QuickDeliver EDI Subsystem Send data to R/3 System R/3 System Determine processing for SmartMart data.  Control record fields in the inbound IDoc are assigned to the corresponding key fields in the inbound partner profile. direct processing by a function module).  Note: Do not confuse the two function modules described here: The first is called by the external system via RFC and generates the IDoc. This function module reads the order data and posts the document as a standard order in SD. the data flow appears as follows:  The external system (QuickDeliver EDI subsystem) calls the inbound function module for the port type "File" in the QuickDeliver R/3 System via RFC. generate IDoc Post standard order ok? No ok? No Generate work item © SAP AG 1999 For QuickDeliver. The IDoc is then created in the database. while the second is the application function module which reads the data in the new inbound IDoc. The inbound port is therefore defined by the external system.  The IDoc Interface recognizes the external system if the system is defined as an inbound port. They determine inbound processing (in this case. (C) SAP AG BC620 6 .

7 EDI-Specific Master Data in Sales Data record E1EDKA1 (PARVW = “AG”): Partner information Data record E1EDKA1 (PARVW = "LF"): Partner information Data record E1EDP19 (QUALF= “002”): Material number Customer master record: Partner number. type and function of the sender are assigned according to the data in the partner profile. type. The qualifier 002 in the segment shows that this is the material number for the vendor.  If the EDI subsystem does not assign the combination of customer and vendor to a sales organization via segments of type E1EDK14 (document header organizational data). function SD Customizing: Assigning customer/ vendor to sales organization Material master record: Material name IDoc Type ORDERS01 IDoc Type ORDERS01 © SAP AG 1999 The SD master data must contain EDI-specific parameters which are compared with the data from the order IDoc:  Partner number.  The material number is transferred in a segment of type E1EDP19. This data must also exist in the SD master data.11. (C) SAP AG BC620 7 . This material must exist in the material master record. you must maintain this assignment yourself using the customizing transaction (VOED).

These include partner information and transmission medium "6" in the condition record for outbound processing using Message Control (MC). © SAP AG 1999 (C) SAP AG BC620 8 .  Outbound processing using Message Control is always applied for purchase orders from the MM module.11.8 A Process Chain: Summary  Special EDI parameters must be entered in the application master data.

then the vendor (incoming order and outbound order acknowledgment) in order to act as the customer again (incoming order acknowledgment) at the end of the message chain. Change to Purchase order → Display. By selecting System → Links the IDoc that has just been generated is displayed. that is. you will be able to: • Use IDoc display to trace IDocs As a member of the EDI project team you want to simulate the message chain from the outbound purchase order via the incoming order to the sending and subsequent receiving of the order acknowledgment. As Send IDoc immediately has been set in the partner profiles. it has been written in a file. select Goto → Messages from the menu in the item overview to check the proposal for the output of the purchase order via Message Control. First.11. a file was created in which the data is correct but the control record is incorrect. 1-1 Create a purchase order for methanol (material number SH-100) from the vendor TBILnn by selecting Logistics → Materials Management → Purchasing → Purchase Order → Create → Vendor known (transaction ME21). If dispatch time 4 has been selected. After the data has been entered successfully. you take the role of the customer. BC620 9 (C) SAP AG . an IDoc for this purchase order is generated as soon as the data is saved.9Process Chain Exercise Unit: A Process Chain Topic: Send purchase order At the conclusion of these exercises. 1-2 1-3 1-4 Unit: A Process Chain Topic: Incoming order 2-1 In the previous exercise. As a member of the purchasing department. The methanol is required for plant 1100. you belong to purchasing organization 1000 and purchasing group 001. the IDoc has the status 03.

a file was created in which the data is correct but the control record is incorrect. Choose IDoc → Display IDoc or IDoc → IDoc Lists to view the IDoc which you have created. Select with the recipient partner number. destination and port. Initiate the transfer of the order IDocs by choosing Test → Outbound Processing from IDoc from the initial node of the IDoc Interface. If this IDoc has status 03. you have generated a file. therefore has not yet been sent by the SAP System. Choose Execute. The logical message is ORDERS. you can use the default values. Enter TBIKnn as the partner number. Select Test -> Inbound Processing of Modified Outbound File from the initial node of the IDoc Interface. by setting your port Port-nn for the test by choosing Goto → User settings. 2-3 The sender is customer T-BIKnn. The IDoc has the status 30. Return to the order (transaction VA03) and check the status of the ORDRSP IDoc. that is. You can set default values for source. and choose System → Links. KU as the partner type and AG as the partner function. 3-2 3-3 Unit: A Process Chain Topic: Receive order acknowledgment 4-1 In the previous exercise. For all other values. This transaction allows you to change the control record so it is BC620 10 4-2 (C) SAP AG .2-2 Select Test -> Inbound Processing Modified Outbound File from the initial node of the IDoc Interface (transaction WE12). from whom you wish to receive the order. An outbound IDoc has already been generated by Message Control for order acknowledgment. By choosing System → Links the order that has just been generated is displayed. This transaction allows you to change the control record so it is correct. matches the partner profile you created in the exercise "General Settings" for your customer T-BIKnn. 2-4 2-5 Unit: A Process Chain Topic: Send order acknowledgment 3-1 In the previous exercise you posted an order.

that is. 4-3 The sender is vendor T-BILnn. from whom you wish to receive the order acknowledgment. Choose Execute. By choosing System → Links the purchase order that has just been changed is displayed. The logical message is ORDRSP. Choose IDoc → Display IDoc or IDoc → IDoc Lists to view the IDoc which you have created. LI as the partner type and LF as the partner function. If you double-click on the item. you can use the default values. 4-4 4-5 (C) SAP AG BC620 11 .correct. matches the partner profile you created in the exercise "partner profiles" for your customer T-BILnn. you will see the acknowledgment number that has just been transferred. Enter T-BILnn as the partner number. For all other values.

12 Statistics and Monitoring  Passive and active monitoring  Work Item Analysis © SAP AG 1999 (C) SAP AG BC620 1 .

2 Statistics and Monitoring: Unit Objectives At the conclusion of this unit. you will be able to:  Decide when different tools should be implemented for IDoc monitoring  Use the individual monitoring transactions © SAP AG 1999 (C) SAP AG BC620 2 .12.

As a result.3 Business Scenario  As a member of the implementation team for your company (SmartMart or QuickDeliver). you are responsible for configuring the IDoc Interface. you must be familiar with the IDoc monitoring tools available for the IDoc Interface.12. © SAP AG 1999 (C) SAP AG BC620 3 . The exchange of IDocs between the two companies is to be monitored.

Active monitoring is scheduled as a job (from the R/3 initial screen. The individual IDocs are displayed in the IDoc list. When these values are exceeded. IDoc display allows direct access to an individual IDoc via the ID. choose System -> Services -> Jobs -> Define job).   (C) SAP AG BC620 4 . Active monitoring can therefore be seen as a configurable error handling function. responsible users are notified via work items. the IDoc Interface always notifies users actively (error handling via work items).12.  The passive monitoring tools can be ordered according to their level of detail: The IDoc statistics assign IDocs to status groups according to their current status. the IDoc Interface provides four passive programs and one active program for IDoc monitoring. Double-clicking on the relevant entry displays more details. Finally. where IDocs are selected according to values in the segment fields. Variants are created from the ABAP editor (choose Goto -> Variants). This also applies to the IDoc search. to the group "inbound error within the IDoc Interface". for example. The passive monitoring tools can be found in the IDoc menu from the IDoc Interface initial node.  Active monitoring (report RSEIDOCM) uses the status groups from IDoc statistics. In addition. It is possible to define threshold values. IDoc search Display © SAP AG 1999 When errors occur.4 Monitoring Programs: Overview Passive monitoring Active monitoring Statistics 4711 4712 4713 4718 "RSEIDOCM" List. as usual.

 The most important selection field is the date on which the control record was created.12. which allows the data flow with the EDI subsystem to be monitored. Apart from the IDoc ID.. users can make selections according to EDI-specific parameters. this works via the extended selection.  The highest number of selection fields is offered by the IDoc display function.. The IDoc statistics tool selects according to the change date. EDI References IDoc statistics IDoc list IDoc search IDoc display Active monitoring © SAP AG 1999 The monitoring programs are reports which select IDocs in the R/3 database according to certain criteria from the control record. message.5 Selection Fields for Monitoring Control record Creation date Change date Partner. In IDoc statistics. for example the transmission file in the EDI subsystem.  (C) SAP AG BC620 5 ..  All monitoring programs allow selection of IDocs according to partner and message.

choose the function "Evaluation history" in the IDoc statistics. users can only access an IDoc directly via the IDoc display function (using the IDoc ID).6 Implementing Functions Application level: Partner.12. while active monitoring selects all IDocs created during the same period. IDoc statistics gives a broad overview and is often used for presentations because of its graphical capabilities. However. This displays all status records for the IDoc. As with the remaining tools. IDoc ID IDoc display © SAP AG 1999      All monitoring functions can display an individual IDoc. You can use active monitoring as an alternative to normal exception handling if a user (employee) is only to receive a work item if a certain number of incorrect IDocs (the threshold value) are found within a specified time period. IDoc display is usually used when technical questions arise (for example problems when communicating with an EDI subsystem) The IDoc list function has less selection fields and is therefore easier to use. (C) SAP AG BC620 6 . Note that IDoc statistics selects all IDocs which have experienced a status change within the specified time period. message IDoc list Technical level: Status. To obtain statistics about "repaired" IDocs. note that normal exception handling still takes place. this function is used when application questions arise (for example how to display all IDocs of message type INVOIC). As the most selective tool. However.

for example. Qrtl. yellow or red. 2. This assignment can be changed from the initial IDoc Interface menu by choosing Control -> Maintain status values. are displayed in the IDoc list in the traffic light colors green. Qrtl. you should read the online documentation for the IDoc statistics function.  The standard R/3 System assigns a group to each status via the "qualification” (synonym for "status group”) value. Qrtl.  According to the status group the individual statuses.  (C) SAP AG BC620 7 . The traffic light color assignment for status groups can be changed by choosing Control -> Maintain status groups. 3.12.7 Status Group: Monitor/Statistics 100 80 60 40 20 0 1. It should therefore be clear in the standard system whether it concerns an error status. Qrtl. 4.  For more information about the status groups which are supplied in the standard R/3 System. transfer.or success status. 4 = "IDoc transfer successful" 13 = "Send ok" Retransmission ok 12 = "Send ok" 39 = "IDoc in target system (ALE)" © SAP AG 1999 Status values for active monitoring and statistics about status groups are combined to prevent the information becoming too complicated.

and the work item did not therefore appear in any inbox. The IDoc Interface uses them mainly for exception handling (see corresponding unit).8 Work Item Analysis  Usually refers to exception handling  Work items which exist in the system are listed Application for "lost work items".  As in IDoc statistics. you can jump to the IDoc display function.12. From the work items. if no user could be found for the work item.  The work item analysis function can be accessed by choosing Tools -> Business Workflow -> Development -> Reporting -> Work item analysis. for example the work items per task (transaction SW12_FREQ). They therefore contain the incorrect IDoc or the incorrect application document which was created from the inbound IDoc. the work item analysis function allows work items belonging to a certain task to be displayed. for example (no user selected) © SAP AG 1999 Work items are instances of defined single-step tasks. This can be useful. for example.  (C) SAP AG BC620 8 .

 Active monitoring is a function which can be individually configured for error handling or general exception handling.The least-detailed monitoring tool is the status group display under IDoc statistics.9 Statistics and Monitoring: Summary  The IDoc data flow can be monitored via four passive programs and one active program in the IDoc interface.12. © SAP AG 1999 (C) SAP AG BC620 9 .  The level of detail in the passive monitoring programs goes as far as displaying the individual IDocs.

10Statistics and Monitoring Exercise Unit: Statistics and Monitoring Topic: Passive monitoring At the conclusion of these exercises. you know that the order number is transferred in the field BELNR in segment E1EDK02 with the qualifier "001" (field QUALF). already been assigned?'' Note: Use the IDoc display function 2-1 "Which IDoc was used to send purchase order XY to vendor T-BILnn?" You have the following information: Direction Basic type Segment As a purchase order is involved. can I access the corresponding IDocs directly from my purchase order?" 4-1 "As a member of the purchasing department. the direction is "outbound". which contains a purchase order for vendor TBILnn. you will be able to: • • Use IDoc search Use IDoc display You are the EDI administrator in your company. The purchasing department has asked you the following questions: 1-1 ''Which statuses has IDoc XY. can I access the corresponding IDocs directly from my sales order?" (C) SAP AG BC620 10 .12. Note: Use the IDoc search function 3-1 "As a member of the purchasing department. You have the number of the purchase order. From the documentation. Purchase orders are sent to the EDI subsystem in your company via IDoc type ORDERS01.

Unit: Statistics and Monitoring Topic: Active monitoring • Using active monitoring 5-1 You want to trace IDocs in status 03. By selecting Refresh. Execute the work item. (C) SAP AG BC620 11 . The IDoc statistics are displayed where the current status of the report execution is displayed. 5-2 Go into the ABAP Workbench (SE38) and enter the report. Enter the following values in the selection screen: Recipient type Recipient Start/end time before batch job Critical IDoc number Status group US Your name BC620nn Enter a meaningful value 1 3 (contains status 03) 5-4 After executing the report you receive notification in the Business Workplace. Include the report RSEIDOCM. the current status is displayed.Note for exercises 3 and 4: Choose System → Links from your application document. 5-3 Choose Execute.

message number. The overview screen for the transaction is displayed.11Statistics and Monitoring: Solution Unit: Statistics and Monitoring 1-1 Search by selecting IDoc → Display IDoc and entering the direction as “outbound” and the partner number of the recipient. The number is in field BELNR of segment E1EDK02 with the qualifier "001“. The IDoc which is linked to this sales order is displayed and you can request more detailed information about the IDoc by double-clicking on the relevant entry. Apart from the status which has been reached. Select the following: Direction Basic type Segment 1 = “outbound” ORDERS01 You have the number of the purchase order. choose System → Links. that is. Search for the IDoc(s) using the IDoc search function. From the transaction overview screen. the values for code. Alternatively. determine which message has been put on hold with the status value "30". Choose System → Links. Enter the sales order number and choose Continue. Enter the purchase order number and choose Continue. find the sales order via the purchase order number from exercise 3 and the search function.12. message type and ID. 4-1 (C) SAP AG BC620 12 . The IDoc which is linked to this purchase order is displayed and you can request more detailed information about the IDoc by double-clicking with the mouse on the relevant entry. Select Logistics → Sales and Distribution → Sales → Order → Display (transaction VA03). You have already generated the purchase order IDoc in exercise 1 of the previous chapter. 1-2 2-1 3-1 Select Logistics → Materials Management → Purchasing → Purchase Order → Display (transaction ME23).

13 Workflow and IDocs  Inbound processing  Exception handling  Notification concept  Organizational structure © SAP AG 1999 (C) SAP AG BC620 1 .

you will be able to:  Explain how the agent responsible is informed if an error occurs during IDoc processing  Maintain the organizational structure © SAP AG 1999 (C) SAP AG BC620 2 .2 Workflow and IDocs: Unit Objectives At the conclusion of this unit.13.

3 Workflow and IDocs: Business Scenario  As a member of the implementation team for QuickDeliver. You must configure a party to be notified if an error occurs.13. © SAP AG 1999 (C) SAP AG BC620 3 . Inbound processing is configured using a process code as "direct via a function module". exception handling takes place by means of workflow. A purchase order from SmartMart is received by QuickDeliver as an inbound IDoc of type ORDERS01. you are responsible for configuring the IDoc interface.

forward.   Note: For reasons of clarity.  The IDoc is edited and modified if necessary before the application document is created. SAP Application © SAP AG 1999  IDoc inbound processing can include a workflow which is triggered by a process code. (C) SAP AG BC620 4 . In this case. this slide does not show the transfer of the IDoc from the external system.13.  The IDoc or application document is forwarded to other users or new (outbound) IDocs are sent.4 Inbound Processing with Workflow IDoc Interface & ALE Services IDoc + process Workflow Document Review. This workflow is defined by the user. Examples:  An application document is created automatically from the IDoc. the IDoc is edited and not the application document. although this is also part of inbound processing. using the inbound IDoc as a basis. The application document is then sent to a user for review. and so on. edit.

 (C) SAP AG BC620 5 . exception handling can also be accessed from outbound processing. It is identified by means of process codes.13.  The slide only shows exception handling being accessed from inbound processing.5 Exception Handling with Workflow R/3 System Check partner. One or more agents can be notified about the error situation.  If you set the express indicator in the process codes maintenance. the agent responsible for the corresponding task receives a message on their screen as soon as a new work item appears in their integrated inbox. The agents are defined in the IDoc Interface and in the organization model of your company. However. generate IDoc Post document ok? No ok? Express Message Error handling No © SAP AG 1999 Exception handling or error handling is always defined as a workflow.  SAP standard exception handling in the IDoc Interface always takes place using single-step tasks.

 If the status "incorrect" is assigned to the group by the external system. (C) SAP AG BC620 6 ... for example).  EDIP identifies a stack of outbound IDocs (from a batch run of report RSEOUT00). in which a processing error occurred and affected all the IDocs (a non-existent port. you must explicitly execute the change to EDIR in the IMG..with MC Syntax error in IDoc Error during IDoc processing Error while processing IDoc stack IDoc Interface IDoc External System EDIR EDIS Customer Status confirmation © SAP AG 1999 Single-step tasks are identified by (system) process codes:  The process codes EDIM and EDIN are valid for inbound and outbound processing. No IDoc could be created here. EDIN is used for outbound processing using Message Control: Using the MC record you can branch from the work item to the application document. a single-step task is addressed using the status process code EDIS.  Additional exception handling for status confirmations can be defined and identified via process codes. The corresponding single-step task can be used to correct the error and send the IDoc stack for processing again. Note: EDIR is new for the Enjoy Release and replaces the old EDIS in the standard system. you can use code EDIR to trigger outbound processing again after you have corrected the error..  EDIX identifies an IDoc which contains a syntax error.13. Additionally.6 Exceptions in Outbound Processing SAP Application or MC Document or MC record EDIM EDIN EDIX EDIO EDIP Message without IDoc without MC. . When upgrading.  EDIO identifies an IDoc affected by an error during outbound processing.

 (C) SAP AG BC620 7 .  If a status file of the external system cannot be read.7 Exceptions in Inbound Processing TXTRAW Message via IDoc External System IDoc EDIM EDIL Message without IDoc . Application documents can also be generated in this way. Special case: an exception occurs in the external system and the R/3 System is to be notified of this exception.  EDIM applies as in outbound processing. Errors which occur when posting an application document (due to incorrect data. The SAP System error message is displayed in exception handling. EDII and EDIY are the same as the outbound process codes EDIO and EDIX.error during status file Error during IDoc processing Syntax error in IDoc IDoc Interface IDoc EDII EDIY SAP Application Application IDoc with or without application document © SAP AG 1999 Exception handling via single-step tasks for inbound processing is the same as for outbound processing.13.  Any messages can be sent in text format using the IDoc type TXTRAW01. the process code EDIL is activated... for example) are sometimes handled and repaired by application-specific tasks and the corresponding process codes.

Role resolution determines the set of agents which are both allowed and possible agents. and the set of selected agents is the same as the set of permitted agents.13. All selected agents now receive the notification as a work item (as an "instance" of the workflow task) in their integrated inbox. Note: If the tasks are defined as general tasks for notification. (C) SAP AG BC620 8 . The IDocs can only be "repaired" and processed further from the integrated inbox. These agents are called the selected agents. all users are possible agents. The IDoc Interface function module for role resolution is EDI_ROLE_FOR_PROCESSING.8 Notification Concept I Organizational structure Task Possible agents Role resolution Selected agent Partner profile IDoc Interface Permitted agents © SAP AG 1999      The agent determined in the IDoc Interface is only the permitted agent of a workflow task. All "possible agents" are attached to the task itself.

the general partner profile is searched to determine a permitted agent for the partner. EDIN EDIX. and general (required entry field). EDIL Permitted agents are entered in the following partner profiles for the IDoc Interface: Inbound. When an error occurs (for example a syntax error in an inbound IDoc). EDIS. the search continues in IDoc Administration (general settings).  In all cases.9 Notification Concept II Outbound/ Inbound General General settings (IDoc Administration) General. If no entry is found. you should always enter an agent ("administrator") in the general settings.  (C) SAP AG BC620 9 . the most relevant permitted agent is determined: The search for the agent responsible for the message and partner (key fields in the profiles) therefore starts in the inbound or outbound partner profile. EDIP EDIR. but for all messages Permitted agents EDIO. outbound (optional). no users are notified! For this reason. EDIY © SAP AG 1999 EDIM.  If this search is also unsuccessful (because no general partner profile for the current partner could be found). EDII. for all partners and messages Special for partner and message Special for partner. either as a job or a department. the agent can be a single person (type US=user) or a group which must be maintained in the PD-ORG model.13.  If no agent could be found in the inbound or outbound profiles (either because no value had been entered or because no inbound or outbound partner profile could be found for the current partnermessage combination).

 You can also enter a position which corresponds to one person as a possible agent. you can do this using an organizational structure.  Further elements of the organizational structure which can be entered as "possible agents" for a standard task:  Job  User: R/3 user  Work center  (C) SAP AG BC620 10 . a general organizational unit "administrators" could exist. that is. This organizational unit (not an individual) could be entered as a possible agent in the IDoc Interface. all R/3 users are possible agents. The advantage is that notifications are tied to positions.  The organizational structure defines a responsibility hierarchy. This organizational unit can now be assigned to several persons who hold as many positions.13. If you want to restrict this number. This concept can be compared to the process code and the relevant function module/workflow.10 Notification Concept III reports to/ is superior to cost center assignment Organizational unit belongs to includes cost center assignment Cost center described by belongs to Job describes described by described by Position includes Work center holds describes holder describes Person/user Task © SAP AG 1999 Workflow auto-customizing (transaction SWU3) includes all tasks relating to the IDoc Interface as "general tasks". not to individuals whose responsibilities can change. For example.

this element must be defined.  From here. This takes place in Customizing or from the workflow area menu (Definition): Organizational plan -> Create (transaction PPOM). elements can be defined and assigned to each other or to R/3 users.13.  (C) SAP AG BC620 11 .11 Maintaining an Organizational Structure  Customizing activities  Maintenance from the Workflow menu © SAP AG 1999 If an element of the organizational structure is to be entered as a possible agent instead of a person (R/3 user).

12 Integrated Inbox SAPoffice Message Workflow Missed deadline . the work item disappears from the integrated inbox of all other selected agents. the list of work items for which you are entered as a "selected agent".. Work items are the instances of the single-step tasks.. Via Workflow.  (C) SAP AG BC620 12 . you access your "worklist".  You can edit a work item from your worklist. © SAP AG 1999 The integrated inbox can be accessed directly from the IDoc area menu (IDoc -> Integrated inbox) or via transaction SO01.13. As a result. that is.

 Errors can be caused by incorrect application data or incorrect IDoc syntax.  Workflow allows incorrect IDocs to be forwarded as work items "in a controlled manner" from an integrated inbox and even to be repaired in some cases.13 Workflow and IDocs: Summary  Normal IDoc processing via workflow is only possible for inbound processing of certain IDoc types.13. In these cases.  Exception handling always takes place via workflow. error handling is different.  Through the organizational structure. workflow allows users in a defined task area to be notified. © SAP AG 1999 (C) SAP AG BC620 13 . It is called in outbound processing in the same way as in inbound processing. not individual users whose responsibilities may change.

(C) SAP AG BC620 14 . Enter organizational unit 50010120 and select Change. you can now assign yourself as user BC620-nn of the organizational unit. 1-1 The organizational unit 50010120 ("EDI Department“) has already been created for EDI administration.14Workflow and IDocs Exercise Unit: Workflow and IDocs Topic: Organizational structure At the conclusion of these exercises. so that notifications for the individual areas of responsibility can be addressed correctly. On the next screen. Place the cursor on the required function and choose Assign holder. you should maintain the organizational model for your company. for example EDI administration and purchasing. Access the Staff assignments.13. proceed as follows: Choose Tools → Business Workflow → Development → Definition Tools → Organizational Management → Organizational Plan → Change. You should now assign your user to the organizational unit. you will be able to: • Maintain the organizational structure As a member of the EDI project team. Choose Save. To do this.

you should intentionally make one mistake so that a notification is generated. You must still enter LF as the partner function and ORDRSP for the logical message. This results in no partner profile being found and the IDoc administrator is notified. This outbound file is to be modified to an incorrect inbound file. you wish to test whether notifications about errors in the control information for inbound processing are sent to your organizational unit 50010120 (EDI department). After you have saved your entries and gone back to the previous screen via the F3 key. The sender is vendor T-BILnn. If you use change mode here. This transaction allows you to change the control record so it is correct and matches the partner profile you maintained in the exercise "partner profiles" for your vendor T-BILnn. the other was generated as a copy of the original IDoc immediately before the original was modified. a file was created in which the data is correct but the control record is incorrect. One IDoc was generated as a result of the test. Execute the work item. Enter T-BILnn as the partner number. you can change the partner type to LI.6 (C) SAP AG BC620 15 . However. Select Inbox to display the integrated inbox. nn is the number of your exercise group (from 1 to 18) 2-2 2-3 2-4 2. You should intentionally make one error in the partner type and enter US (instead of LI). In this exercise. Choose Execute. you can choose Edit → Process → Background Processing to continue inbound processing. You can display the resulting IDocs via Display IDoc or IDoc Lists (select with the partner number).5 2. But this is the organizational unit 50010120. Access the control record via the tree display for the IDoc. 2-1 This exercise continues from exercise 3 in the unit "A Process Chain" (outbound order acknowledgment). Look at the status record and the logged long text.Unit: Workflow and IDocs Topic: Notification concept As a member of the EDI project team. from whom you wish to receive the sales orders. Choose Test → Inbound Processing Modified Outbound File from the initial node of the IDoc Interface.

14 Using an EDI Subsystem  Converting to another standard  Required data in control records  More documentation © SAP AG 1999 (C) SAP AG BC620 1 .

you will be able to:  Recognize the tasks of the EDI subsystem  Describe the differences between required fields and optional fields in control records  Understand the different ways to inform the EDI subsystem about various IDoc formats © SAP AG 1999 (C) SAP AG BC620 2 .14.2 Using an EDI Subsystem: Unit Objectives At the conclusion of this unit.

The R/3 System is informed that the subsystem is a port. The format definitions for the inbound IDocs can be defined by the subsystem. (C) SAP AG BC620 3 .3 Overview Diagram (Receiving Data) EDI Subsystem? Send data to R/3 System Documentation Documentation Tools Tools R/3 System Archive IDoc? Archive IDoc? Check port & partner.14. generate IDoc Post document Port Definition. Partner Profiles Partner Profiles Error handling © SAP AG 1999   QuickDeliver must configure the IDoc Interface for inbound processing: QuickDeliver connects the EDI subsystem and enters the information about which data is to be sent. Port Definition.

4 Business Scenario  As a member of the implementation team for your company (SmartMart or QuickDeliver). you are responsible for configuring the IDoc interface. © SAP AG 1999 (C) SAP AG BC620 4 . You wish to connect your EDI subsystem.14.You must find out about the work involved in configuring the subsystem before carrying out the work.

certain statuses are expected to be sent to the R/3 System as reference points to ensure integration with the applications. is divided into outbound processing. The addresses are required by the communication module.12 uses functional and interchange acknowledgments to confirm successful data transfer between EDI systems. standard ANSI X. for example mapping. for example selecting and assigning fields. Archiving takes place in accordance with various laws and directives. These include the guidelines laid down by the relevant tax authorities. In the case of inbound processing. are mapping components (usually customerspecific). The individual criteria. This also includes the implementation of the communication protocols. The communication module is often produced by a different supplier. for example X. (C) SAP AG BC620 5 . This task is carried out by the translator as a subfunction of the EDI subsystem.25 and X. message handling.14. Physical data transfer takes place using the communication module of the EDI subsystem. the messages are separated from the transmission files and sent to the translator.5 EDI Subsystem: Responsibilities Partner profile Addresses Translator Message handling Communication Archiving Monitoring © SAP AG 1999        The most important task of the EDI subsystem is converting to or from the required EDI standard. When EDI processes are being monitored. In outbound processing. Further processing.400. the messages transferred from the translator are combined in transmission files. Status confirmations depend on the selected EDI standard: For example. Partner profiles contain the individual settings for a partner and a process. inbound processing and status confirmation.

function)(Type. An R/3 System (Release 3. message (three fields each) and test flag (1 field) must correspond to the entries in the partner profile. Inbound Processing (partner profiles) © SAP AG 1999      In inbound processing.14. The IDoc Interface checks whether the IDoc type is assigned to the message (assignments can be maintained from the initial node by selecting Development -> IDoc type/message). Processing: Control Record (Number. an EDI subsystem must send certain fields with their values for IDoc inbound processing:  Partner. This also means that the partner function value. (C) SAP AG BC620 6 .  Sender port and recipient port  IDoc type. code. structure = EDI_DC40 (external control record structure in Release 4.0). As a result. type. And so on. A complete list of fields can be found in the appendix. Inbound processing with ALE?. the IDoc Interface assigns the key fields from the partner profiles to fields in the control record.  Direction = 2 (inbound).x) would expect a different structure.6 Required Fields in IDoc Inb. The values of other fields are checked explicitly in the coding. Permitted agents. Special requirements can require additional fields:  (Customer-) extension. function) Partner Message Test? IDoc control record Partner Message Test? Process code. for example. (see course BC621 for more information)  Logical address of sender/recipient for automatic forwarding The IDoc Interface enters values for empty optional fields and checks the values. must be left empty if the corresponding field in the partner profile is also empty. which can lead to an error if the wrong value is found.

0 (version 3) can be sent to the EDI subsystem. Using SYRECD01 (record type versions 1 or 2). the new record types for Release 4.14.X and 3. "versions” 1 and 2). for example.  (C) SAP AG BC620 7 .X (that is.7 More Documentation IDoc Interface: Documentation Tools Begin … End XML typedef struct z2incodx000 … z2incodx000 © SAP AG 1999 The EDI subsystem can use a parser which "understands" the appropriate output format for the IDoc Interface.contains the format definitions of IDoc record types: It is conceivable. This means that the external formats (record types and IDoc types) can be recognized by other systems.  Metadata can also be output for XML IDocs.  C-headers fulfill the same purpose: They can be included in the corresponding C-programs in the EDI subsystem.  There are also "meta-IDocs": These are two special IDoc types which describe the external formats in their data records: The types are called  SYIDOC01 . that an EDI subsystem only recognizes record types from releases 2.contains the format definition of an IDoc type (that is record types and segments)  SYRECD01 .

14.8 Using an EDI Subsystem: Summary  The EDI subsystem is used mainly for converting the IDoc format into an EDI standard (and vice versa). © SAP AG 1999 (C) SAP AG BC620 8 .  Format definitions can be defined in the EDI subsystem in a form which can be read by other systems.  The EDI subsystem is an interface to external systems and has its own responsibilities.

14. you require information on IDoc type ORDERS01 for two reasons: 1. (C) SAP AG BC620 9 .9Using an EDI Subsystem Exercise Unit: Using an EDI Subsystem Topic: More Documentation At the conclusion of these exercises. To prepare for a project discussion about “purchase order/order via EDI”. 1-1 A machine-readable format should be generated for your subsystem provider. You decide to transfer the information on IDoc type ORDERS01 with the aid of the Transport IDoc. A partner profile with partner type LS and partner number ID3CLNT400 already exists and can be used in this exercise. To inform your EDI subsystem provider of this data structure. 1-2 Choose IDoc → Display IDoc or IDoc → IDoc lists from the initial node of the IDoc interface to view the IDoc which you have created. you will be able to: • Send a meta-IDoc As a member of the EDI project team for your company. 2. Note down the number of the IDoc generated. Search for "your" IDoc number.

15 Archiving  Archiving object IDOC  Status transfers  Archiving status © SAP AG 1999 (C) SAP AG BC620 1 .

2 Archiving: Unit Objectives At the conclusion of this unit. you will be able to:  Archive IDocs  Describe a status transfer  Configure the archiving status in the system © SAP AG 1999 (C) SAP AG BC620 2 .15.

(C) SAP AG BC620 3 .3 Overview Diagram (Sending Data) R/3 System Post document Archive IDoc? Generate IDoc Partner Profiles Partner Profiles Check partner. process further Documentation Documentation Tools Tools © SAP AG 1999    SmartMart must configure the IDoc interface for outbound processing: When communication with QuickDeliver has been tested successfully. SmartMart wishes to determine which statuses are suitable for archiving and can then be deleted from the system.15. find port Port Definition Port Definition EDI Subsystem? EDI Subsystem? Transfer data.

 However. © SAP AG 1999 (C) SAP AG BC620 4 . When configuring the IDoc Interface. you can determine which statuses can be archived. the processed IDocs should be deleted from the database. you must archive the relevant IDocs before they are deleted. The IDocs must therefore be assigned an archiving status.4 Archiving: Business Scenario  When the business process has been completed.15.

 In a second. you can see which programs you have to call. This transaction provides you with the archiving object IDOC. and define when the IDocs are generated.  (C) SAP AG BC620 5 . all IDocs which have been archived can be deleted from the R/3 database.15. Settings in ADK Customizing (Archive Development Kit. enhanced function builder application) determine whether the IDocs are exported to an external storage medium (optical disk. The programs check whether the current status can be archived. for example). As a result. A complete archiving run therefore moves the IDocs to an external storage medium and deletes the IDoc from the database. separate step.5 Archiving Object: IDOC IDoc Interface Archiving programs Possible Storage File System © SAP AG 1999 IDocs which can be archived are copied from the R/3 database to one or more archive files in a file system (at operating system level) via the archiving programs in the IDoc Interface.  The deletion job completes an archiving run.  The archiving programs in the IDoc Interface are called via the central archiving transaction (SARA). A message and time period are entered as "variants" for the programs (reports).

no further processing (deletion flag) IDoc retrieved from archive IDoc added with error 1 IDoc in target system (ALE services) Application document not created in target system (C) SAP AG BC620 6 .15. still waiting for acknowledgment (EDI subsystem) EDI subsystem control information OK (EDI subsystem) Further processing despite syntax error Syntax error in IDoc Error in ALE services IDoc is ready for dispatch (ALE services) Error. Acknowledgment positive (EDI subsystem) Funct. Acknowledgment negative (EDI subsystem) EDI subsystem triggered OK Error while triggering Send OK. Acknowledgment negative (EDI subsystem) Funct. Acknowledgment positive (EDI-Subsystem) Interch.6 Status Transfers in Outbound Processing 42 01 29 06 26 25 08 07 05 37 39 24 04 10 30 40 03 02 22 18 20 14 41 12 09 11 15 16 17 © SAP AG 1999 Selected statuses can be archived in the standard system 31 Statuses can only be assigned to an IDoc in defined combinations. This slide illustrates the permitted combinations for outbound processing: The following mean: 01 02 03 04 05 06 07 08 09 10 11 12 14 15 16 17 18 20 22 24 25 26 29 30 31 35 37 39 40 IDoc generated Error while sending data to port Data transfer to port OK Error in EDI subsystem control information Error during conversion Conversion OK Syntax error in EDI message Syntax check OK Error in interchange handling Interchange handling OK Error while sending Send OK Interch.

41 42 Application document created in target system IDoc from test transaction (C) SAP AG BC620 7 .

50 51 Application document not posted 52 Incomplete application document posted 53 Application document posted 54 Error during formal application check 56 Incorrect IDoc added 57 Test IDoc: Error during application check 60 Syntax error in IDoc 61 Further processing despite syntax error 62 IDoc sent to application 63 Error while sending IDoc to application 64 IDoc is ready to be sent to application 65 Error in ALE services 66 IDoc waiting for predecessor (serialization) 68 Error.15.7 Status Transfers in Inbound Processing 56 65 63 68 60 74 61 52 66 51 50 64 62 53 70 69 73 71 54 57 Selected statuses can be archived in the SAP standard system © SAP AG 1999  The permitted status combinations for inbound processing are displayed above. no further processing (deletion flag) 69 IDoc edited 70 Original version of edited IDoc 71 IDoc retrieved from archive 73 IDoc archived 74 IDoc created from test transaction IDoc added (C) SAP AG BC620 8 .

 This transaction can also be used to find out general information about a certain status. . .  (C) SAP AG BC620 9 .. select Control -> Status maintenance (transaction WE47) to change the attributes of an individual status. ... An example of an attribute is whether or not archiving is permitted.15.8 Status Maintenance . . © SAP AG 1999 From the initial node of the IDoc Interface.Archiving IDoc status Description Processing Direction Processing layer Effect Qualification Archiving possible excluded .

15. The archiving object is IDOC.9 Archiving: Summary  All archiving programs are addressed via the central archiving transaction SARA. The archiving run must be complete.  IDocs can only be archived if they have been assigned a status which can be archived. © SAP AG 1999 (C) SAP AG BC620 10 .  IDocs can only be deleted if they have been archived. The statuses suitable for archiving can be configured in the IDoc interface.

15. you can add upwardlycompatible extensions or define your own IDoc types. IDoc data flow is therefore defined via the partner profiles and the port definitions. In outbound processing. IDocs can be processed via workflow. The formats used for transmitting data (IDoc types) are documented. (C) SAP AG BC620 11 . Monitoring programs and statistics programs are available for the IDoc data flow. IDocs are exchanged with external systems on a partner-specific and message-specific basis. This is the subject of course BC621. Active monitoring can be used to automatically notify the agent responsible. If the IDoc types in the standard system do not meet your requirements. In inbound processing. Exception handling for incorrect IDocs always takes place via workflow.10 Course Summary SAP Application External System 1 External System 2 © SAP AG 1999         The IDoc Interface allows the exchange of business data between SAP applications and external systems. IDocs can be collected in a group or sent to the external system immediately. IDocs which have been processed completely can be archived.

16 Appendix  This section contains supplementary material to be used for reference  This material is not part of the standard course  Therefore. the instructor might not cover this during the course presentation © SAP AG 1999 (C) SAP AG BC620 1 .

g. Basic types can be modified by customers to create a new. software and communication services.4Condition component Part of the hierarchy which is examined when searching for a message. The remaining fields describe the message itself.16. exported as a print form or as an electronic message. Each IDoc always has one control record. sometimes in separate countries. if one of the data records transferred from the application matches these key fields. EDI = Electronic Data Interchange (e. Access An access identifies the document fields used by the system when searching for a condition record. upward-compatible IDoc type. The data is formatted according to specific standards. Example: the message type which is at the top of the hierarchy: when a (new) purchase order is posted. 16. as well as the structure of the IDoc itself. Data record The part of an IDoc which contains the application data.3Access sequence Sequence used by Message Control to access condition records when searching for messages. only the messages under the node for message type NEW are searched. Therefore. who may use different hardware. the message is found and can be processed (e. An IDoc usually contains more than one data record.2Appendix Glossary 16. Condition record Data record in which the key fields represent the condition under which the message is "found". documents) between business partners.g. (C) SAP AG BC620 2 . Control record The part of an IDoc which contains the data for identifying the sender and recipient. Basic type IDoc type supplied by SAP.

An example of an action is printing a document at a certain time in German.g. archiving the transferred messages. formatted according to a certain IDoc type. i.7EDI subsystem System which converts the SAP standard IDoc into an EDI standard (e. This includes descriptions of the various data configurations and the required actions.e.g. File interface Hierarchy level = port type “File” Determines the position of a segment in a tree structure. A segment carries business data in an IDoc. Various EDI standards (EDIFACT or ANSI X12) can define different EDI messages for the same business process. The action is triggered when the application transfers data which matches your configuration. a purchase order) to be handled by EDI. the various hierarchy levels. Dependencies in the application data can be represented in this tree structure. Inbound processing Mapping Message Control (C) SAP AG BC620 3 . Rules for assigning the data elements of an EDI message type to the fields of an IDoc type. SAP format in which the data for business process is to be sent. 16. IDoc Interface IDoc type Definition of IDoc types and data interchange methods (port definitions) between SAP Systems and partner systems. In addition to this task (which is carried out by the EDI subsystem converter). technical connection to the subsequent system and syntax checks for formats.5EDI message Standard format for a business process (for example. Conversion and processing of data for a business process from the time the data is received in IDoc format to the posting of the corresponding document(s) in the SAP application. 16. An EDI standard generally comprises: EDI syntax Data element service Message type service The SAP standard 'IDoc' is not yet an EDI standard. ANSI X12) and vice versa.6EDI standard General format for data to be transferred electronically. there are also administration activities. but can be compared to other EDI standards. Module designed to offer interfaces for further processing for applications. Field catalog Contains all fields which can be selected as key fields for condition tables in Message Control. e. to be considered.g. EDIFACT. e. An IDoc is a real business process. and technical tasks.16.

Contains certain IDocs to be sent for port type “File”.” Port Description of the channel used by the SAP system for communicating with the external system during electronic data interchange. which is transferred in IDoc-Format between an SAP System and an external system. a search is made for the condition records using a predefined hierarchy. In message determination.g. a notification is sent to one or more users. 16. Notification Optional segment Part of an IDoc type (standard format for data communication). Conversion and processing of SAP document data from posting a document to sending the data in IDoc format.16. Without BC620 4 Process code (C) SAP AG . Another name for a defined processing type. The selection of the port type depends on the technical configuration of the external system. The segment does not therefore have to appear in an IDoc for a specific business process. optional data about the business process. Definition from SD: “An individual within or outside of your own organization who is of commercial interest and who can be contacted in the course of a business transaction. the port type 'File' is used. which can include additional. you should assign the corresponding process code to the new processing type. If the processing type for this IDoc type is to be changed. If an error occurs (for example. In contrast. Outbound file Outbound processing Partner profile Definition of the general conditions for electronic data interchange with a business partner via the IDoc Interface: which message is sent in which direction using which method? If a partner profile does not exist.8Message determination A check to determine whether the application data matches the condition records (specified in Customizing)". an IDoc with incorrect syntax). Notifications are sent to the integrated inbox. Example: most EDI subsystems read IDocs in the form of sequential files.9Message status record= MC record. communication with a partner via the IDoc Interface is not possible. a defined IDoc type (standard format for data communication) is usually assigned to a certain process code. e. There are various technical methods for implementing this type of communication (port types). Log record for the MC table which describes the send status of a message in Message Control. Message Business process (for example. i. The users responsible are defined in the IDoc Interface or indirectly via the organization model (PD-ORG). a function module or an SAP Business Workflow task. 16.g. a purchase order).10Partner Communication partner for the IDoc Interface. one or more messages are "found" and can then be processed (e.e. sent electronically). If this is the case.

for example: "generated" or "ready for sending". The messages are EDI messages. this IDoc type must be assigned to the new processing type directly. the data can be assigned to the correct application fields. The conversion of the SAP standard IDoc into the EDI standard is carried out by an external system (EDI-subsystem). Status record Translator Transmission file Converts internal data formats (IDocs) into EDI messages and vice versa. Required segment 16. sent electronically or printed). This means that the number of status records increases as the processing continues.13Status confirmation Report from an external system about the processing status of business data received from the R/3 System in IDoc format. 16.the process code. i.e.Status record The part of an IDoc type which contains important application data and must therefore exist in an IDoc for an actual business process.Control record . Status group The status group contains several statuses ("milestones" in the process chain). A schema is searched for messages which are to be processed for the specified data configuration (e. As a result. The status confirmation is added to the IDoc in the R/3 System in the form of status records. 16. A data packet which contains the messages to be exchanged electronically. they are formatted according to an EDI standard (e.12Status Processing status of an IDoc (SAP standard format for electronic data interchange). Segment Structure which includes the application data for an IDoc from the data records. The current (processing) status is also stored in the control record for the IDoc. An IDoc has usually had several statuses. Status file File which contains the status records sent to the IDoc Interface by the EDI subsystem for outbound messages. EDIFACT).Data record . The translator is a component of the EDI subsystem. (C) SAP AG BC620 5 .g. Examples: Group 3 = outbound: IDoc in the external system Group B = inbound: IDoc sent to application One of the three record types in an IDoc (SAP standard format for electronic exchange of application data). Each status record contains a status which corresponds to one step in IDoc processing. Record type An IDoc type consists of the following three record types: .g. so that the monitoring programs only have to consider these groups and not each individual status.11Schema A group of messages. which are stored in the status records and reveal information about the IDoc history.

Important Menu Paths Archiving Administration ration → Data archiving Display IDoc IDoc initial screen: IDoc Administration IDoc initial screen: Control → IDoc Administration IDoc initial screen Tools → Business Communication Display IDoc 17IDoc → IDoc Basis IDoc statistics IDoc initial screen: IDoc statistics Maintaining an RFC destination IDoc initial screen: Maintaining archiving status IDoc initial screen: Control → Status maintenance Partner profile RFC destination IDoc initial screen: Partner profile Port definition IDoc initial screen: Port definition Processing tests IDoc initial screen: menu option according to the required function> (C) SAP AG BC620 6 .

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

Date of IDoc generation. Outbound processing mode (e. As the inbound IDoc is generated first in the database. Handling as in DOCNUM. Each value is overwritten in inbound processing. send IDocs individually. Time of IDoc generation. the ALE services are called immediately in IDoc inbound processing. R/3 release version. start subsystem). An incorrect entry causes an error.g.TEST EXPRSS Test flag. (C) SAP AG BC620 8 . Handling as in DOCNUM. An incorrect entry causes an error. IDoc ID. each value here is overwritten by the internal IDoc ID. Optional fields Field MANDT DOCREL OUTMOD DOCNUM CREDAT CRETIM Description Client in the R/3 System. Express flag: if this flag is set.

all other fields belong to Message Control (MC): Partner function LF LF LF AG AG WE WE RE Application EA EF EF V1 V1 V2 V3 V3 Message type NEU NEU NEU AN00 BA00 LAVA AUS1 RD00 X Change Message category REQOTE ORDERS ORDCHG QUOTES ORDRSP DESADV EXPINV INVOIC SD09 (invoice) SD05 Process code ME12 ME10 ME11 (C) SAP AG BC620 9 .Typical combinations of MC fields and fields from outbound partner profiles Process code and Message type are fields in the IDoc partner profiles.

trace # insert command to start EDI subsystem here echo ++ removed IDoc file $FILE from application server >> $DIRWORK/ediadm. a UNIX operating system is used.trace chmod 666 $DIRWORK/ediadm. #!/bin/sh DIRWORK=/users/ediadm cd $DIRWORK FILE='basename $1' date >> $DIRWORK/ediadm.trace (C) SAP AG BC620 10 .Example: Command file (Shellscript) .Outbound Note: in this example.trace echo ++ run external system with file $FILE >> $DIRWORK/ediadm.

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

Sign up to vote on this title
UsefulNot useful