CA210 - EDI Interface.pdf

Full text

(1)CA210 EDI Interface. CA210 EDI Interface  SAP AG 1999. System R/3 Release 4.6B September 2000 Mat. No.: 5004 1963.

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

(3) The R/3 Integration Model. FI. SD. Financial Accounting. Sales & Distribution. CO. MM. Materials PP Mgmt Production Planning. QM. Quality Mgmt. Controlling. AM. R/3. Asset Mgmt. Client / Server ABAP PM. Plant Maintenance. HR. Human Resources. PS. WF. Project System. Workflow. IS. Industry Solutions.  SAP AG 1999. SAP's R/3 System has set new norms for standard software that can be universally implemented. R/3 uses advanced development techniques to achieve comprehensive integration of business administration and data processing. R/3 combines state-of-the-art technology with comprehensive business administration functionality to provide a fully integrated business solution for your company..

(4) Business Integration Technologies I Level 3. Level 2 BC600. 2 days. SAP Business Workflow - Introduction. BC095. 3 days. Business Integration Technology BC400. 5 days. BC601 Build and Use SAP Business Workflow. 5 days. BC615. 3 days BC670 2 days Programming Display Functionality 3 days. Data Archiving. ABAP Workbench Concepts and Tools BC410 5 days ABAP Workbench Programming User Dialogs (Level 3).  SAP AG 1999. 3 days. SAP Business Workflow - Programming. SAP ArchiveLink. BC660. BC610. BC440 5 days Developing Internet Applications. BC680. Workflow. Archiving. 2 days. Data Retention Tool (DART). R/3 Web Connection.

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

(6) Course Prerequisites. Level 2 course in a revelent application EDI knowledge is strongly recommended.  SAP AG 1999.

(7) Target Group. Audience: Project team EDI analysts responsible for implementing EDI. Duration: 4 days.  SAP AG 1999. Notes to the user The training materials are not teach-yourself programs. They complement the course instructor's explanations. Your material includes space for noting additional information..

(8) Course Overview. Contents: Course Goals Course Objectives Course Content Course Overview Diagram Main Business Scenario Course Introduction.  SAP AG 1999. © SAP AG. CA210. 1-1.

(9) Course Goals. This course will prepare you to: Explain the possibilities offered by the IDoc Interface for electronic data interchange Configure the system to handle the IDoc interface.  SAP AG 1999. © SAP AG. CA210. 1-2.

(10) Course Objectives. At the conclusion of this course, you will be able to: Configure the IDoc interface Trace the processing of IDocs within the system Find out the correct IDoc types for your business processes..  SAP AG 1999. © SAP AG. CA210. 1-3.

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

(12) Course Overview Diagram (1). Course Overview. 1. Workflow and IDocs. 8. IDocs in the Business Process. 2. SD EDI Application Requirements. 9. General Settings. 3. Inbound Invoice Processing. 10. Port Definitions. 4. Payment/Remittance Process. 11. Partner Profiles. 5. Price Catalog, Inventory Advice. 12. MM EDI Application Requirements. 6. Test of Processing. 13. Message Control & IDocs. 7. Documentation Tools. 14.  SAP AG 1999. © SAP AG. CA210. 1-5.

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

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

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

(16) Introduction: Topic Objectives. At the conclusion of this topic you will be able to: Indicate where the EDI interface is located in the SAP system Describe the overview of the EDI interface Define the general concept of the IDoc.  SAP AG 1999. © SAP AG. CA210. 1-9.

(17) EDI Standards in the World EANCOM GENCOD TRADACOMS UCS II, WINS SEDAS. EDIFICE EIAJ EDIFER. 2 X1 HL7. T C FA I ED. EDIFICE ELFE. CEFIC. PHOENIX ARUA GALIA ODETTE VDA BAI, BAI2 MultiCash S.W.I.F.T. HBCI. ATA SPEC2000 AECMA SPEC2000M  SAP AG 1999. EANCOM GENCOD TRADACOMS UCS II, WINS SEDAS. IBUs and SBUs clockwise: SAP Consumer Products SAP Insurance SAP Public Sector SAP Telecommunications SAP Chemicals SAP Pharmaceuticals SAP Retail SAP Banking SAP Mill Products SAP Aerospace & Defense SAP Media SAP Automotive SAP Health Care SAP Service Provider SAP Utilities SAP Oil & Gas SAP Engineering & Construction SAP High Tech & Electronics. © SAP AG. CA210. 1-10.

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

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

(20) IDoc Applications WWW message. Internet Intranet. R/2 System ICR/OCR Document ALE. IDoc EDI EDI Message Message. R/3 System Electronic Form. Workflow. Forms Feed Flows.  SAP AG 1999. Examples of systems/applications which use IDocs: ALE. Application Link Enabling. EDI. Electronic Data Interchange. ICR. Intelligent Character Recognition. OCR. Online Character Recognition. WWW. World Wide Web. © SAP AG. CA210. 1-13.

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

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

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

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

(25) IDoc Topics: Outbound R/3 R/3 System System Create application document. Message Control. Partner Profile General Settings. Create IDoc Archive IDocs ?. Check Partner, find Port. EDI Subsystem ?. Receive Data do further processing. Port Description, Partner Profile. Documentation Tools. External External System System.  SAP AG 1999. Smartmart must setup its interface for outbound processing. Via the Port description, SmartMart defines the systems to receive IDocs, and the technical communication parameters. Smartmart defines NOE Food Company as a partner for the message type ORDERS in the Partner Profiles. Here, Smartmart enters the port it had defined earlier. Outbound IDocs created in the R/3 system shall be archived and deleted in the system. The Documentation tools tell the EDI Subsystem which IDoc types it must understand.. © SAP AG. CA210. 1-18.

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

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

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

(29) Introduction: Unit Summary. You are now able to: Indicate where the EDI interface is located in the SAP system Describe the overview of the EDI interface Define the general concept of the IDoc.  SAP AG 1999. © SAP AG. CA210. 1-22.

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

(31) IDocs in the Business Process: Unit Objectives. At the conclusion of this unit you will be able to: Define the difference between IDoc and IDoc type Describe the general structure of an IDoc Point out where in the (business) process chain the IDoc is created.  SAP AG 1999. © SAP AG. CA210. 2-2.

(32) IDocs in the Business Process: Course Overview Diagram (1). Course Overview. 1. IDocs in the Business Process 2. Workflow and IDocs. 8. SD EDI Application Requirements. 9. General Settings. 3. Inbound Invoice Processing. 10. Port Definitions. 4. Payment/Remittance Process. 11. Partner Profiles. 5. Price Catalog, Inventory Advice. 12. MM EDI Application Requirements. 6. Test of Processing. 13. Message Control & IDocs. 7. Documentation Tools. 14.  SAP AG 1999. © SAP AG. CA210. 2-3.

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

(34) IDoc Concept, Technical. EDI subsystem. EDI message. SAP System R/3. IDoc. SAP document. Proper interface between application and EDI subsystem Basic support for application API for development easy to use. Real-time EDI Independent of EDI standards Independent of trading partners  SAP AG 1999. The interface with the applications is given by: the IDoc data structure (this is the IDoc type) the API (application programming interface) to create, read and process IDocs The data flow is triggered from the source by RFC (Remote Function Call). This guarantees realtime processing. An IDoc type is dependent on the logical message (business document) only, but independent of a specific EDI standard for that logical message. The IDoc is independent of trading partners, this means: all data from the master records and the SAP document is filled into the IDoc the mapping - selection of data to be transmitted - is defined a the EDI subsystem only. © SAP AG. CA210. 2-5.

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

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

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

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

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

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

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

(42) IDoc Record Types: Summary. Control record. IDoc-ID Partner IDoc-Type and logical message External structure. Data records Control area. Status records. Application data. IDoc-ID Status information.  SAP AG 1999. In summary: the IDoc consists of three record types. The control record contains information about the type of message be exchanged, and to whom it is being sent/received. The data records hold the application data. The status records represent the life-cycle or major milestones of the IDoc's life.. © SAP AG. CA210. 2-13.

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

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

(45) Outbound Processing via Message Control. SAP application Document. Message control (NAST) NAST record. IDoc Interface/ALE Services IDoc. External System.  SAP AG 1999. SAP applications can create IDocs directly or via message control. When message control is involved, there is the possibility that it can be further processed (i.e., filtered) by the ALE services before it is passed to the port. The IDoc Interface passes every IDoc to the chosen port, according to the technical port description. Examples for Port types are: External System = R/3 System: Common is the transactional RFC (Standard ALE scenario) External System = EDI Subsystem: Common is the file interface.. © SAP AG. CA210. 2-16.

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

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

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

(49) IDocs in the Business Process: Unit Summary. You are now able to: Define the difference between IDoc and IDoc type Describe the general structure of an IDoc Point out where in the (business) process chain the IDoc is created.  SAP AG 1999. © SAP AG. CA210. 2-20.

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

(51) Exercises Unit: IDocs in the Business Process. At the conclusion of these exercises, you will be able to: Describe what is meant by an IDoc type Indicate how IDoc types are used in SAP IDocs are used to move data into and out of the SAP system. It is therefore necessary to understand what their components are and how they are used in the SAP system.. 1-1. What is an IDoc type? ___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________. 1-2. What are the three records types within the Intermediate Document? ___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________. 1-3. Which IDoc record type contains the data which is used to determine the partner profile information and the direction the data is to travel (into/out of SAP)? ___________________________________________________________________. 1-4. The ____________________ is the main key that links the three record types within an IDoc.. 1-5. Are different IDoc types used for inbound messages as opposed to outbound messages? ___________________________________________________________________. 1-6. What is the difference between an IDoc type and an IDoc? ___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________. © SAP AG. CA210. 2-22.

(52) 1-7. True/False: Status records are sent out of the SAP system? ___________________________________________________________________. 1-8. The rule-based condition technique used to output IDocs is called: Workflow Management Message Control Intermediate Document None of the above. 1-9. The rule-based inbound processing technique is called: Output Determination Partner Profiles Workflow Management None of the above. 1-10. Does SAP have a different IDoc type for each transaction or document in R/3? ___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________. © SAP AG. CA210. 2-23.

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

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

(55) General Settings: Unit Objectives. At the conclusion of this unit, you will be able to: State which parameters can be customized Determine the time when the IDoc administrator is notified.  SAP AG 1999. © SAP AG. CA210. 3-2.

(56) General Settings: Course Overview Diagram (1). Course Overview. 1. Workflow and IDocs. 8. IDocs in the Business Process. 2. SD EDI Application Requirements. 9. Genera Generall Settings. 3. Inbound Invoice Processing. 10. Port Definitions. 4. Payment/Remittance Process. 11. Partner Profiles. 5. Price Catalog, Inventory Advice. 12. MM EDI Application Requirements. 6. Test of Processing. 13. Message Control & IDocs. 7. Documentation Tools. 14.  SAP AG 1999. © SAP AG. CA210. 3-3.

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

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

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

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

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

(62) Replace Process Technology with Workflow. Only necessary when upgrading from 2.1/2.2 IMG Activities: Change exception handling Change inbound processing.  SAP AG 1999. Please note the IMG documentation of the individual activities.. © SAP AG. CA210. 3-9.

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

(64) Delete Process Technology from System. Remove unnecessary process codes from system IMG Activity: Delete process technology in EDI processing in logistics Trial run Final run.  SAP AG 1999. © SAP AG. CA210. 3-11.

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

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

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

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

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

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

(71) General Settings: Unit Summary. You are now be able to: State which parameters can be customized Determine the time when the IDoc administrator is notified.  SAP AG 1999. © SAP AG. CA210. 3-18.

(72) Exercises Unit: General Settings Topic: Customizing in the IMG At the conclusion of these exercises, you will be able to: • Describe what IDoc customizing is done in the IMG for general settings IDocs are used to move data into and out of the SAP system. It is therefore necessary to understand what the general customizing is for IDoc processing no matter which direction IDocs are going. This setup is also independent of the use of the IDoc (EDI, ALE, Internet).. 1-1. How many different number ranges can be set up for IDoc processing and what are they? ____________________________________________________________ ____________________________________________________________. 1-2. How many different number ranges are used for numbering IDocs? ____________________________________________________________ ____________________________________________________________. 1-3. What is the event receiver linkage? ____________________________________________________________ ____________________________________________________________ ____________________________________________________________. 1-4. Which port type does not make use of the event receiver linkage? ____________________________________________________________ ____________________________________________________________. 1-5. Why is the IDoc Administrator important? ____________________________________________________________ ____________________________________________________________. © SAP AG. CA210. 3-19.

(73) 1-6. When must the configuration for replacing the process technology with Business Workflow be done? ____________________________________________________________ ____________________________________________________________. 1-7. What is the advantage of using templates for partner profiles? ____________________________________________________________ ____________________________________________________________ ____________________________________________________________ ____________________________________________________________. 1-8. True or False: 1-8-1 Releases of SAP older than 4.0x can understand the long names of Logical Messages, Basic IDoc Types, Extensions, IDoc Types, and Segments? ______________________________________________________ ______________________________________________________. © SAP AG. CA210. 3-20.

(74) Exercises Unit: General Settings Topic: User parameters At the conclusion of these exercises, will be able to: • Configure the system for the IDoc user parameters. It is necessary to set up the user parameters for testing of IDoc processing in the system.. 2-1. Configure the IDoc administration user parameters. Select: Output as C header file, and Test using file interface. 2-1-1 For Test using file interface use Group## for the Testport. 2-1-2 For Output as C header file use C:\Temp\ for the local directory and a local file w/o extension name of IDoc.. © SAP AG. CA210. 3-21.

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

(76) Solutions Unit: General Settings Topic: User Parameters. 2-1. From the SAP Easy Acces menu, open folders Tools → Business Communication → IDoc → IDoc Basis → Control. Double-click "IDoc administration". Select the [Display <>Change] button and click on the Test tab. 2-1-1 For Test using file interface use enter your Group## in the TestPort field. 2-1-2 Select Documentation tab and enter the following information for C-Header output: C-header output Field Name. Input Data. Local directory. C:\temp\. Local file w/o extension. IDOC. 2-1-2-2 Press the Save icon. 2-1-2-3 Return to the SAP Easy Access menu by selecting the [Back] button.. © SAP AG. CA210. 3-23.

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

(78) Port Definitions: Unit Objectives. At the conclusion of this unit, you will be able to: Decide which port type to use for which system Define the port description in the R/3 system Configure the settings necessary for a specific port type Configure your R/3 system for communication with releases earlier than 4.x.  SAP AG 1999. © SAP AG. CA210. 4-2.

(79) Port Definitions: Course Overview Diagram (1). Course Overview. 1. Workflow and IDocs. 8. IDocs in the Business Process. 2. SD EDI Application Requirements. 9. General Settings. 3. Inbound Invoice Processing. 10. Po Porrtt Definitions. 4. Payment/Remittance Process. 11. Partner Profiles. 5. Price Catalog, Inventory Advice. 12. MM EDI Application Requirements. 6. Test of Processing. 13. Message Control & IDocs. 7. Documentation Tools. 14.  SAP AG 1999. © SAP AG. CA210. 4-3.

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

(81) Port Definitions: Business Scenario. As a member of the integration team of your company, SmartMart, you are responsible for setting up the IDoc interface. SmartMart uses an EDI subsystem. You must decide which port type is adequate for your EDI subsystem..  SAP AG 1999. © SAP AG. CA210. 4-5.

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

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

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

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

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

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

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

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

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

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

(92) Ports and Port Types. IDoc Interface IDoc. IDoc. Port 1 (e.g. Type “file”). Port 2 (e.g. Type “file”). External System 1. IDoc. Port 3 (e.g. Type “tRFC”). External System 2.  SAP AG 1999. © SAP AG. CA210. 4-16.

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

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

(95) Solutions Unit: Port Definition Topic: Create a File Port. 1-1. From the SAP Easy Acces menu, open folders Tools → Business Communication → IDoc → IDoc Basis → IDoc Double-click "Port Definition". 1-1-1 Select or open File folder and the Create icon. 1-1-2 Enter the following information: New Entries: Overview of Created Entries Field Name. Input Data. Port. Group##. Description. Port for group ##. Select the IDoc record types SAP Release 4.x radio button under Version. 1-2 1-2-1 Select Outbound file tab. 1-2-2 Enter the following information: Parameters for Outbound File. Field Name. Input Data. Directory. \usr\sap\<SID>\SYS\global\. Function module. EDI_PATH_CREATE_USERNAME. Outbound file. Blank. Select the Physical directory radio button. © SAP AG. CA210. 4-19.

(96) 1-3 1-3-1 Select Outbound:Trigger tab. 1-3-2 Enter the following information: Parameters for Outbound: Trigger Field Name. Input Data. RFC Destination. SERVER_EXEC. Directory. \usr\sap\<SID>\SYS\global\. Command File. Converter_start. 1-4 1-4-1 Select Inbound file tab. 1-4-2 Enter the following information: Parameters for Inbound File Field Name. Input Data. Directory. \usr\sap\<SID>\SYS\global\. Function module. Blank. Inbound file. Inbound. 1-5 1-5-1 Select the Status file tab. 1-5-2 Enter the following information:. Parameters for Status File Field Name. Input Data. Directory. \usr\sap\<SID>\SYS\global\. Function module. Blank. Status file. Status. 1-5-3 Press Save icon. 1-5-4 Note the newly created Port name. _________________________________________________________ © SAP AG. CA210. 4-20.

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

(98) Partner Profiles: Unit Objectives. At the conclusion of this unit, you will be able to: Explain the purpose of the process code and the partner profiles Execute the partner profile transaction.  SAP AG 1999. © SAP AG. CA210. 5-2.

(99) Partner Profiles: Course Overview Diagram (1). Course Overview. 1. Workflow and IDocs. 8. IDocs in the Business Process. 2. SD EDI Application Requirements. 9. General Settings. 3. Inbound Invoice Processing. 10. Port Definitions. 4. Payment/Remittance Process. 11. Partner Profiles. 5. Price Catalog, Inventory Advice. 12. MM EDI Application Requirements. 6. Test of Processing. 13. Message Control & IDocs. 7. Documentation Tools. 14.  SAP AG 1999. © SAP AG. CA210. 5-3.

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

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

No results found