EDI IDoc Overview

UNISON

Overview of EDI and the IDoc Interface in SAP By

Emmanuel Hadzipetros

Last Revised: 4/30/2006 EDI/IDoc Overview

Page 1 of 22

UNISON

Version Control Version 1

Created By Emmanuel Hadzipetros

Last Revised: 4/30/2006 EDI/IDoc Overview

Created On 1/31/2005

Page 2 of 22

UNISON

Table of Contents EXECUTIVE SUMMARY ........................................................................................................................................................4 PURPOSE ....................................................................................................................................................................................... 4 INTENDED A UDIENCE ................................................................................................................................................................. 4 A SSUMPTIONS .............................................................................................................................................................................. 4 SCOPE ............................................................................................................................................................................................ 4 A CRONYM DEFINITIONS ............................................................................................................................................................. 4 EDI ARCHITECTURE ..............................................................................................................................................................4 IDOCS: THE HEART OF SAP’S EDI A RCHITECTURE............................................................................................................... 4 Idoc Objects............................................................................................................................................................................5 Messsage Types: ....................................................................................................................................................................5 THE SAP EDI PROCESS FLOW: A BIRD’S EYE VIEW .......................................................................................................... 10 Outbound Processing..........................................................................................................................................................11 Inbound Processing.............................................................................................................................................................17 THE HANDSHAKE: EXTERNAL SUBSYSTEM REQUIREMENTS.............................................................................................. 20 Inbound Requirements........................................................................................................................................................20 Outbound Requirements.....................................................................................................................................................22

Table of Figures Figure 1: Idoc Record Types......................................................................................................................................................... 6 Figure 2: Idoc Record Type. ......................................................................................................................................................... 7 Figure 3: The EDI process flow begins and ends in SAP...................................................................................................... 10 Figure 4: Highly simplified outbound SAP EDI architecture............................................................................................... 11 Figure 5: Output screen at header level of a purchase order. ................................................................................................ 12 Figure 6: Selection screen for program RSEOUT00.............................................................................................................. 14 Figure 7: Simplified inbound SAP EDI architecture.............................................................................................................. 17 Figure 8: Selection screen for program RBDAPP01.............................................................................................................. 19

Tables Table 1: Control record structure with Inbound values............................................................................................................ 7 Table 2: Control record structure with Outbound values......................................................................................................... 9 Table 3: Status codes that can be sent to SAP from TrustedLink detailing important milestones. ................................ 15 Table 4: The status file expected by SAP................................................................................................................................. 15 Table 5: SAP Idoc interface outbound status codes................................................................................................................ 16 Table 6: SAP Idoc interface inbound status codes.................................................................................................................. 20 Table 7: Parameters and switches for startrfc .......................................................................................................................... 21 Table 8: Required fields in inbound Control record ............................................................................................................... 22

Last Revised: 4/30/2006 EDI/IDoc Overview

Page 3 of 22

UNISON

Executive Summary Purpose The purpose of this document is to provide a high-level overview of how EDI works in SAP and to introduce some fundamental concepts about IDocs. The information presented should be used during the interface technical design process. Intended Audience The document is intended for the application architecture interface team, technical designers, technical developers and other interested parties. Assumptions The following assumptions have been made: ·

This document is for informational purposes only and does not describe any probable interface scenarios.

·

References to outbound/inbound interfaces are from an SAP perspective. An outbound interface originates in SAP and travels outbound to the existing or business partner system. An inbound interface originates in the existing or business partner system and travels inbound into the SAP system.

·

For the purposes of this document, the EDI subsystem is not relevant.

·

This document assumes a file-based EDI interface within SAP. This does not imply any architectural or design preferences.

Scope This document is for educational purposes only and contains architectural and technical details of how EDI works within SAP. Acronym Definitions Some key acronyms are translated below. · · · ·

ALE - Application Link Enabling BAPI - Business Application Programming Interface EDI – Electronic Data Interchange IDoc - Intermediate Document

EDI Architecture Idocs: The Heart of SAP’s EDI Architecture Idocs – Intermediate Documents -- facilitate the exchange of data between SAP and other non-SAP or SAP systems. They are independent of the complex structures and tables used by SAP to store application data, allowing SAP to rearrange its internal structures without affecting existing interfaces. Last Revised: 4/30/2006 EDI/IDoc Overview

Page 4 of 22

UNISON

Idocs are structured for flexibility. They encapsulate all the available data in an SAP business document or transaction and are designed to support asynchronous communication and distributed processes, rather than simply invoking functions. They communicate messages between linked systems representing specific business objects -Orders, Customer Acknowledgements, Delivery Documents, Invoices, etc. -- the very documents that anchor critical business relationships between trading partners. IDOC OBJECTS To understand Idocs, we need to distinguish between four distinct terms describing different objects: Messsage Types: The business document, encapsulated in an SAP transaction, exchanged between distributed systems and partners. Idoc Record Types: These structures form the building blocks of all Idocs and are used by the runtime system to pass Idoc data to the Idoc database (the Idoc database includes tables EDIDC, EDID4 and EDIDS). Each Idoc Record Type is defined in the following manner: ·

One control record defined by the SAP Data Dictionary structure EDI_DC40, with a record length of 524 bytes.

·

The control record is stored in table EDIDC: one for each distinct Idoc in the Idoc database. It contains control information relating to supporting configuration including, but not confined to: n n n n n

Idoc number Direction of transmission Sender and Receiver information: Port and Partner Message Type Idoc Type

·

One or more data segments defined by the SAP Data Dictionary structure EDI_DD40, with a total record length of 1,063 bytes (a 63 byte record envelope and 1,000 byte data record).

·

Idoc data is stored, segment by segment, each with its own structure, in table EDID4 in the Idoc database. Many data segments can be associated with one control record.

·

One or more status records defined by SAP Data Dictionary structure EDI_DS40, with a total record length 562 bytes.

·

Status records are stored in table EDIDS, as the Idoc achieves various milestones in its processing history. In the outbound process, status records are also generated by the EDI subsystem and transmitted back into SAP.

Last Revised: 4/30/2006 EDI/IDoc Overview

Page 5 of 22

UNISON Figure 1: Idoc Record Types.

Idoc Type A hierarchical structure that consists of one or more data segments with several data fields. Each segment is a discrete structure in the SAP data dictionary tied together to construct an Idoc type through transaction WE30 (Create, Change, Display Idoc Types). ·

Each Idoc type is defined by its segments and their properties. These are segment type / segment name, position / sequence and iteration / status. Within SAP, segment types always begin with 'E1' while externally they begin with 'E2‘. Codes for fields such as currencies, countries, units of measure, etc. are always based on ISO standards.

·

The Idoc type, with the addition of a Control Record of type EDI_DC40, is the structure that will be mapped to its corresponding EDI message in TrustedLink. The segments illustrated in Figure 2 below can be interpreted as follows n n n n n

E1HDDOC E1HDADR E1ITDOC E1ITSCH E1TLSUM

Last Revised: 4/30/2006 EDI/IDoc Overview

Document Header Header Addresses Item Details Item Schedule Trailor Section

Page 6 of 22

UNISON Figure 2: Idoc Record Type.

Idoc An instance of an Idoc Basic Type populated with data, including a Control Record, one or more Data Segments and one or more Status Records. The Idoc instance exists when it has been assigned a unique Idoc number and saved to the Idoc database. Inbound or outbound, an Idoc is always created in SAP and saved in the Idoc database. Files imported from an EDI subsystem are not IDocs: they are flat files with data mapped from an EDI message to the structure of an Idoc Basic Type. Table 1: Control record structure with Inbound values Field name

Length Description

Literal Value

Value Description

TABNAM

010

Name of table structure

EDI_DC40

MANDT DOCNUM

003 016

Client Idoc number

110

Control segment structure defined in Data Dictionary UD3 110, for Dev. SAP Idoc generated in SAP.

DOCREL STATUS DIRECT

004 002 001

SAP Release for Idoc Status of Idoc Direction

46C 64 2

OUTMOD EXPRSS TEST IdocTYP

001 001 001 030

Output mode Overriding in inbound processin Test flag Name of basic type

ORDERS05

CIMTYP

030

Name of extension type

Basic type, ie, ACLPAY02, DELVRY03, etc. Custom segment name.

MESTYP

030

Logical message type

ORDERS

Idoc Message type: ie, ORDERS, DESADV, etc.

MESCOD MESFCT STD

003 003 001

Logical message code Logical message function EDI standard, flag

Last Revised: 4/30/2006 EDI/IDoc Overview

Most recent status of Idoc. 2 = Inbound

Page 7 of 22

UNISON Field name

Length Description

Literal Value

Value Description

STDVRS STDMES SNDPOR

016 006 010

EDI standard, version and relea EDI message type Sender port, external system

850 A000000017

SNDPRT

002

Partner type of sender

KU

SNDPFC

002

Partner function of sender

SP

SNDPRN

010

Partner number of sender

100735

EDI message type. EDI file port name: Logical system for EDI subsystem. Customer partner type. Vendor = LI If present: VN (Vendor), SP (Sold-to party), BP (Bill-to party), SH (Ship-to party), etc. Partner number

SNDSAD SNDLAD

021 070

Sender address (SADR) Logical address of sender

RCVPOR

010

Receiver port (SAP System)

SAPUHD

Logical port for DEV; SAPQAS in QAS.

RCVPRT RCVPFC RCVPRN RCVSAD

002 002 027 028

Partner type of recipient Partner function of recipient Partner number of recipient Recipient address (SADR)

LS

Logical system

SAPUHD110

Logical system for Dev 110.

RCVLAD

070

Logical address of recipient

CREDAT

008

Created on

CRETIM REFINT REFGRP REFMES

006 014 014 014

Time created Reference to transfer (EDI inte Reference to message group (EDI Reference to message (EDI messa

ARCKEY SERIAL

070 020

Key for (external) message arch Serialization field

Last Revised: 4/30/2006 EDI/IDoc Overview

Partner ID for the EDI Sender from the Group Level segment of the EDI transaction.

Partner ID for the EDI Receiver from the Group Level segment of the EDI transaction.

Page 8 of 22

UNISON

Table 2: Control record structure with Outbound values Field name

Length Description

Literal Value

Value Description

TABNAM

010

Name of table structure

EDI_DC40

Control segment

MANDT DOCNUM DOCREL STATUS

003 016 004 002

Client Idoc number SAP Release for Idoc Status of Idoc

110 123456789 46C

UD3 110, for Dev. SAP Idoc number.

DIRECT OUTMOD EXPRSS TEST

001 001 001 001

Direction Output mode Overriding in inbound processin Test flag

1

1 = Outbound

IdocTYP CIMTYP MESTYP MESCOD

030 030 030 003

Name of basic type Name of extension type Logical message type Logical message code

DELVRY03 DELVRY03EXT_855 DESADV

Basic type Custom segment name. Idoc Message type

MESFCT STD STDVRS SDTEMES

003 001 016 006

Logical message function EDI standard, flag EDI standard, version and relea EDI message type

855

EDI message type

SNDPOR SNDPRT SNDPFC

010 002 002

Sender port (SAP System) Partner type of sender Partner function of sender

SAPUHD LS

Logical port Logical system

SNDPRN SNDSAD SNDLAD

010 021 070

Partner number of sender Sender address (SADR) Logical address of sender

1235455

Partner number

RCVPOR

010

Receiver port (SAP System, exte

A000000017

EDI file port name: Logical system for Tibco

RCVPRT RCVPFC

002 002

Partner type of recipient Partner function of recipient

KU SP

RCVPRN RCVSAD

027 028

Partner number of recipient Recipient address (SADR)

100374

Customer If present: VN (Vendor), SP (Sold-to party), BP (Bill-to party), SH (Ship-to party). SAP partner number.

RCVLAD

070

Logical address of recipient

CREDAT CRETIM REFINT REFGRP

008 006 014 014

Created on Time created Reference to transfer Reference to message group

REFMES ARCKEY SERIAL

014 070 020

Reference to message Key for (external) message arch Serialization field

Last Revised: 4/30/2006 EDI/IDoc Overview

Partner ID for the EDI Sender from the Group Level segment of the EDI transaction.

Partner ID for the EDI Receiver from the Group Level segment of the EDI transaction.

Page 9 of 22

UNISON

The SAP EDI Process Flow: A Bird’s Eye View A simplified schematic of the end to end EDI processing architecture is illustrated in Figure 3 below. The flow begins (outbound) and ends (inbound) with an SAP transaction. Figure 3: The EDI process flow begins and ends in SAP.

SAP EDI Architecture : 60 ,000 Feet SAP

EDI enabled business transaction

Creates Business Document

Purchase Orders Sales Orders Delivery Documents Invoices Remittances Inventory Movements etc . Creates Business Document

EDI enabled business transaction

SAP App Server

IDOC Interface IDOCs encapsulate all the data in the business docs . Standard function modules manage all interface services & processes create IDOC , import /export , system validation , partner mgmnt , error & workflow mngmnt , data & transactional processing .

EDI Subsystem

Exports IDOCs thru File /tRFC Port Import /Export and mapping between IDOCs and EDI messages , transmission services , functional acknowledgements etc . IDOC files .

E D I P A R T N E R S

Enterprise Scheduling Controlling the jobs managing the data flows .

At its most basic, the SAP EDI architecture consists of EDI-enabled applications that support automatic processing of business transactions and the Idoc interface, consisting of: ·

Idocs to structure, hold, process and move data to and from SAP business documents.

·

A sequenced set of standard function modules that are executed in a defined order. These function modules manage all the processing services required by the interface, including: n n n

n n

Inbound: RFC enabled import, callable by an external system. Outbound: RFC enabled export calling an external executable to kick off import and processing in an external EDI subsystem. Validation of control segment data including Idoc interface configuration such as logical systems, ports, partner profiles, correct sending and receiving partners, etc. Processing and posting of inbound document data to SAP transactions. Processing and extraction of outbound data from the SAP business object.

Last Revised: 4/30/2006 EDI/IDoc Overview

Page 10 of 22

UNISON n

Idoc error and status reporting, including workflow notification of failure.

·

Services such as Idoc processing, monitoring, editing, reprocessing, reporting, testing and archiving.

·

Custom programs to manage the processing, monitoring, reporting, failure and recovery of Idocs.

·

An EDI subsystem that converts Idoc files into EDI messages; manages partner transaction, transmission and security parameters ;and supports the transmission of EDI messages to and from EDI partners through standard and proprietary transport protocols such as AS2, HTTP/S, FTP, SFTP, VAN, and so on.

·

Standard and custom audit and reporting tools to keep track of Idoc/EDI Transaction status across the entire architecture.

·

An interface between SAP and the EDI subsystem.

·

An enterprise scheduling tool to automate each job step in the end-to-process.

OUTBOUND PROCESSING Figure 4: Highly simplified outbound SAP EDI architecture.

SAP EDI ARCHITECTURE : R3 - 1 SAP

EDI Subsystem

Outbound Processing Bus Doc Created /Saved

Calls startrfc to trigger receipt of status file in SAP

Begin subsystem Processing

Output Type = EDI

Confirms Part . Profile

SAP APP Server IDOC file Exported

1. Writes rec . to NAST

Run RSNAST 00

2.

Calls script on app server to trigger EDI subsystem

IDOC Created Status 30

Run RSEOUT 00

Reads File Port

File port : 1. Points the IDOC to outbound directory on SAP App Server ; 2. Names the IDOC file ; 3. Provides name and path of outbound trigger , if EDI subsystem to be automatically triggered . 4. IDOCs can be exported immediately or batched and scheduled (RSEOUT 00 ).

Last Revised: 4/30/2006 EDI/IDoc Overview

Status back to SAP

Transmission : AS 2, VAN , FTP

Status File /IDOC : To SAP from Tibco . File imported into SAP by remote call to rmtsapsts .bat , on SAP app server , which calls startrfc . Returns standard or custom SAP status codes and /or text messages .

E D I P A R T N E R S

Page 11 of 22

UNISON ·

A business document is created and saved in an EDI-enabled application, such as a Purchase Order.

·

On save, a predefined Output (SD) or Message (MM) type is created in table NAST. This record serves as a pointer between the business document and the Idoc, or print file, or whatever other output will be generated from it.

·

Output types can trigger conditional output of messages based on a hierarchy of decision structures, created through business rules in configuration. Custom Output types can be used to handle specific messaging situations. This Message Control is used in SD and MM.

·

The Output or Message Type is defined in the Output screen in the document's header through configuration, as illustrated in Figure 5. Options include: n n n n n

Output type: NEU. A standard output type for Orders that can generate a number of different media including EDI. Output Medium: print, fax, ALE, EDI, etc.; Partner Function (ie, VN for Vendor, BP for Bill-to or SH for Sold-to partners); Partner Number for the recipient of the output. Create Idoc immediately or in batch on execution of program RSNAST00, which reads NAST and calls the Idoc processing function to build the Idoc.

Figure 5: Output screen at header level of a purchase order.

Last Revised: 4/30/2006 EDI/IDoc Overview

Page 12 of 22

UNISON

·

On Save, the output is validated against Message Control in the Partner Profile. For Output type NEU to create an Idoc from the document above, the following matching parameters need to exist in the Partner Profile: n n n n n n

Partner 2071932 set up as a Partner Profile of Partner type LI (Vendor). Outbound parameters for Partner Function VN (Vendor) Message Type ORDERS. A Receiver port must exist (in Dev 110 this would be A000000017). Packet size for the Idoc file should be defined. Default is 100. Idoc basic type must be identified: ORDERS05. Message Control set for Application EF, Message Type NEU, Process Code ME10.

·

Program RSNAST00 is kicked off by the scheduler at set times for batch processing of NAST output records. RSNAST00 reads NAST, determines the output type and collects data required for the output. If EDI, it also creates and saves an Idoc in the Idoc database at status 30, ready for export to the external system.

·

RSNAST00 determines the Idoc outbound processing function module by reading the process code in Message Control in the Partner Profile for the partner. In this example, process code ME10 links to function Idoc_OUTPUT_ORDERS that collects data from the saved Purchase Order to pass to an ORDERS05 Idoc.

·

Custom coding within function module user exits is executed as part of the function’s normal processing stream. User exits are placed at strategic points along the function’s processing path to accommodate customer-specific requirements such as unique mapping or conversion issues, population of custom segments, special calculations, etc.

·

The next step depends on whether the Output Mode in the Partner Profile has been set to Transfer immediately or Collect Idocs.

·

If Transfer immediately: n

n n n

·

The Idoc is exported to a file on the SAP application server through the file port triggering the outbound script, or directly to TIBCO via ALE through the tRFC port, using function module EDI_OUTPUT_NEW. If successful, status in EDIDS is set to 03: Data passed to port OK. Another status record is saved in EDIDS for the Idoc to indicate successful triggering of the EDI subsystem (18) via a file based interface. If unsuccessful, an error status record is created in EDIDS for the Idoc, (ie, 31: Error – no further processing).

If Collect Idocs (batch processing): n n n n

The Idoc sits in the Idoc database at status 30 (Idoc ready for dispatch). Program RSEOUT00 is executed via the SAP Job Scheduler (SM36: Maestro). All Idocs that match the RSEOUT00 selection variant are collected and exported to one File on the SAP application server, using function EDI_OUTPUT_NEW. The Idoc file is passed through the file port, which triggers the EDI subsystem through a script or by an RFC call.

Last Revised: 4/30/2006 EDI/IDoc Overview

Page 13 of 22

UNISON n n n

If successful, status in EDIDC and EDIDS is set for each Idoc to 03: Data passed to port OK. Another status is saved in EDIDS for each Idoc in the file to indicate that the EDI subsystem has been triggered (18). If unsuccessful, an error status record is created in EDIDS for the Idoc, (ie, 31: Error – no further processing).

Figure 6: Selection screen for program RSEOUT00.

·

The Idoc interface determines the name and location of the Idoc file that it will export to the SAP app server through the File Port. For Dev , port is set up for: n n

n

·

Outbound path: File name: determined dynamically by function EDI_PATH_CREATE_MESTYP_DOCNUM, that saves the Idoc file as _, ie, INVOICE_00210031 (or other standard for Universal). If there are multiple Idocs in the file, the top most Idoc number will go into the file name.

The File Port also points to a batch file on the app server that triggers the external EDI system automatically -- strediout.bat. Triggering the batch file also marks the point in time at which responsibility for the Idoc is transferred from SAP to the HubTrustedLink interface.

Last Revised: 4/30/2006 EDI/IDoc Overview

Page 14 of 22

UNISON ·

The EDI subsystem can also be triggered by an RFC call through a RFC Destination configured in SM59.

·

The Idoc file is then moved into the EDI subsystem where it is routed to to the appropriate map, translated, enveloped and transmitted to the trading partner.

·

After the Idoc has been sent to the EDI trading partner (or not), the subsystem sends SAP a status file (or Idoc) with status records for each Idoc processed. Status can potentially be returned to SAP at each critical milestone in the EDI processing chain for each Idoc. The following Status Codes can be reported back to SAP:

Table 3: Status codes that can be sent to SAP from TrustedLink detailing important milestones. Status Code

Code Description

04 05

Error within control information of EDI subsystem Error during translation

06

Translation OK

07 08

Error during syntax check Syntax check OK

09 10

Error during interchange handling Interchange handling OK

11

Error during dispatch

12 13

Dispatch OK Retransmission OK

14 15

Interchange Acknowledgement positive Interchange Acknowledgement negative

16

Functional Acknowledgement positive

17 22

Functional Acknowledgement negative Dispatch OK, acknowledgement still due

23 24

Error during retransmission Control information of EDI subsystem OK

36

Electronic signature not performed (timeout)

40 41

Application document not created in receiving system Application document created in receiving system

·

The status file generated by TIBCO can write status records for multiple Idocs as well as multiple statuses for a single Idoc. The status file has the following structure:

Table 4: The status file expected by SAP. Field name

Value

Len

Description

TABNAM MANDT DOCNUM

EDI_DS40 140 00000000002062012

10 3 16

Name of table structure SAP client Idoc number

Last Revised: 4/30/2006 EDI/IDoc Overview

Page 15 of 22

UNISON Field name

Value

Len

Description

LOGDAT LOGTIM STATUS

20030219 145358 04

8 6 2

Date of status information Time of status information Status of Idoc: can be any of status in the table above

·

The EDI subsystem transfers the status file to the SAP app server and calls startrfc with the correct parameters to log in to SAP, pass the status file path and the import file port to the function EDI_STATUS_INCOMING.

·

startrfc parameters for a Dev UD3 client 110 could include: \SYS\exe\run\startrfc -3 -d UD3 -u -p -c 110 -l E -h ushsap68 -s 01 -g ushsap68 -x sapgw00 -t -F EDI_STATUS_INCOMING -E PORT= A000000017 –E PATHNAME=> %TRACE%

·

The Idoc interface opens the status file through the call to function EDI_STATUS_INCOMING and uses it to update the status segments of all Idocs within the status file.

·

On receipt of the status file: n n

·

a new status segment is written to EDIDS for the Idoc; and the control record is updated with the latest status.

All other outbound status codes generated by the Idoc interface are in Table 5.

Table 5: SAP Idoc interface outbound status codes Status Code

Description of Status

01

Idoc created

02 03

Error passing data to port Data passed to port OK

18 19

Triggering EDI subsystem OK Data transfer for test OK

20

Error triggering EDI subsystem

21 25

Error passing data for test Processing despite syntax error (outbound)

26 27

Error during syntax check of Idoc (outbound) Error in dispatch level (ALE service)

29

Error in ALE service

30 31

Idoc ready for dispatch (ALE service) Error - no further processing

32 33

Idoc was edited Original of an Idoc which was edited

34

Error in control record of Idoc

35 37

Idoc reloaded from archive Idoc added incorrectly

38

Idoc archived

Last Revised: 4/30/2006 EDI/IDoc Overview

Page 16 of 22

UNISON Status Code

Description of Status

39 40

Idoc is in the receiving system (ALE service) Application document not created in receiving system

41 42

Application document created in receiving system Idoc was created by test transaction

INBOUND PROCESSING Figure 7: Simplified inbound SAP EDI architecture.

·

The EDI subsystem receives an EDI message from a trading partner through the VAN, by FTP or AS2.

Last Revised: 4/30/2006 EDI/IDoc Overview

Page 17 of 22

UNISON ·

The message is deenveloped, converted into an Idoc and passed to an SAP Adapter that will send the Idoc into SAP either through a file and startrfc to call function EDI_DATA_INCOMING or an ALE call to function INBOUND_IDOC_PROCESS.

·

startrfc parameters for a Dev UD3 client 110 for the Idoc file would be (the Idoc filename would be passed to the script through a variable): \SYS\exe\run\startrfc -3 -d UD3 -u -p -c 110 -l E -h ushsap68 -s 01 -g ushsap68 -x sapgw00 -t -F EDI_DATA_INCOMING -E PORT= -E PATHNAME=\\\ >> %TRACE%

·

Data in the control segment of the Idoc is checked against the Partner Profile, including: n n n n n n

n

·

When these parameters have been validated, an application Idoc is written to the Idoc database, which means that an Idoc number is assigned and: n n n

·

Partner number: the SAP customer or vendor master number. Partner type: KU = Customer, LI = Vendor. Post processing permitted agent. Partner function: ie, BP = Bill-to, SH = Ship-to. Inbound Message type Inbound Process code: identifies the function module that will post the Idoc. Inbound ORDERS points to process code ORDE, which is linked to function IDOC_INPUT_ORDERS for the creation of one Sales Order per Idoc. Processing options: Trigger immediately or by background program. Processing will be by background program, scheduled in SAP but executed by .

The control segment is written to table EDIDC. The data segments are written to table EDID4 The preliminary status (50 – Idoc added) is written to a control segment in table EDIDS. Every subsequent milestone within the Idoc interface is tracked and a new status segment record with the new status written to EDIDS.

A syntax check is done, if the Syntax check flag is set in the Partner Profile. n

n

If the syntax check succeeds, a new status segment is written to EDIDS with status 64, Idoc ready to be passed to application, and processing can proceed on execution of the inbound processing program. Failure returns status 60: Error during syntax check of Idoc (inbound), written to EDIDS.

·

The Idoc file is then deleted from the app server EDI INDATA directory (if a filebased interface).

·

If the Background processing flag is set, Idocs are buffered in the system (in the Idoc database at status 64) until the program RBDABB01 is run.

Last Revised: 4/30/2006 EDI/IDoc Overview

Page 18 of 22

UNISON Figure 8: Selection screen for program RBDAPP01.

·

Variants are created for each transmission by Message Type and Idoc status at 64, or whatever else is required to narrow down the range of Idocs for processing. n n

Performance could be improved by using Parallel processing options with Server Groups. RBDABB01 can be scheduled to run at a set time or in response to an event raised outside SAP such as import of the Idoc file into the SAP app server.

·

SAP validates the incoming data with the same business rules used for online posting of the transaction. EDI automates the creation of business transactions in SAP supported by the same business rules, defined in configuration and through customization, that support an online user manually entering data into the system.

·

Results are returned to the function and a new status segment written to EDIDS. Two options: n n

Status 53: Application document posted. The Idoc successfully posted to the transaction. Status 51: Application document not posted. The Idoc failed to post to the transaction. There were one or more data errors in the Idoc or data was locked for posting.

Last Revised: 4/30/2006 EDI/IDoc Overview

Page 19 of 22

UNISON

Table 6: SAP Idoc interface inbound status codes Status Code

Description of Status

50 51

Idoc added Error: Application document not posted

52 53

Application document not fully posted Application document posted

54

Error during formal application check

55 56

Formal application check OK Idoc with errors added

57 58

Test Idoc: Error during application check Idoc-Copy from an R/2 connection

60

Error during syntax check of Idoc (inbound)

61 62

Processing despite syntax error (inbound) Idoc passed to application

63 64

Error passing Idoc to application Idoc ready to be transferred to application

65

Error in ALE service

66 68

Idoc is waiting for predecessor Idoc (serialization) Error - no further processing

69 70

Idoc was edited Original of an Idoc which was edited

71

Idoc reloaded from archive

73 74

Idoc archived Idoc was created by test transaction

The Handshake: External Subsystem Requirements A number of requirements must be met to ensure that SAP can import and export Idocs to and from the external EDI subsystem. These are summarized here. INBOUND REQUIREMENTS SAP needs the following to correctly process an inbound transmission: ·

A physical file (or ALE transfer) containing document data sent by an EDI transmission structured in the correct Idoc Type format, one Idoc per document or SAP transaction.

·

The Idoc file to be named by the external subsystem.

·

The Idoc file to be FTP’ed (or otherwise moved) from the external subsystem to the correct inbound directory on the SAP app server. These directories are client specific and include: DEV: QAS: PRD:

Last Revised: 4/30/2006 EDI/IDoc Overview

Page 20 of 22

UNISON ·

A remote call to startrfc on the SAP app server to trigger inbound Idoc processing for EDI. This SAP executable is located (in all clients and environments) at:

·

Sample call parameters for an inbound Idoc startrfc call can be found on page 18. The parameters switches for startrfc are detailed here:

Table 7: Parameters and switches for startrfc Parameter

·

Description Start rfc path

Value \\\startrfc

-3 -d

System control: log on to R3 system SAP System

UD3 (Development)

-u -p

EDI user name EDI user Password



-c

SAP client

110 (Dev)

-l -h

Language SAP application server

E ushsap68

-s -g

SAP system number SAP Gateway host

01 ushsap68

-x

SAP Gateway service

sapgw00

-t -F

Turns trace switch on. Function module for inbound messages/status

-E -E

SAP EDI port Path and file name for inbound Idoc file

EDI_DATA_INCOMING (Idoc) EDI_STATUS_INCOMING (Status file) PORT = PATHNAME=\

The external system can call startrfc from a script or batch file on the SAP app server Scripts and trace files should be stored on the SAP app servers, in the following directories: n

Scripts: DEV: = QAS: = PRD: =

n

Trace Files: DEV: = QAS: = PRD: =

Last Revised: 4/30/2006 EDI/IDoc Overview

Page 21 of 22

UNISON ·

At a minimum, the following fields need to be populated in the Control Record:

Table 8: Required fields in inbound Control record Field name

Length Description

Example of Value

TABNAM

10

Name of control record structure

EDI_DC40

MANDT DOCREL

3 4

Client SAP Release for Idoc

110 46C

DIRECT IdocTYP

1 30

Direction Name of basic type

2 SHPCON

MESTYP

30

Logical message type

DELVRY03

SNDPOR SNDPRT

10 2

Sender port (SAP System) Partner type of sender

LI (Vendor)

SNDPFC SNDPRN

2 10

Partner function of sender, if maintained in partner profile Partner number of sender: an SAP customer or vendor master number. In some cases, a dummy partner number is used. The correct SAP partner is read thru logic in an Idoc user exit.

100735

RCVPOR RCVPRT

10 2

Receiver port (the SAP System port receiving the file) Partner type of recipient

SAPUHD LS

RCVPFC RCVPRN

2 27

Partner function of recipient, if maintained in partner profile Partner number of recipient

SAPUHD

OUTBOUND REQUIREMENTS · SAP will export Idocs in a physical file containing one or more Idocs to the outbound directory on the SAP app server. These directories are client specific and include: DEV: QAS: PRD:

·

The external system will provide a batch file, script or other executable that the Idoc interface will call on export of the Idoc file. This script may kick off an FTP transport to the external environment and trigger processing and/or mapping in the external system of the Idoc file.

·

The EDI subsystem provides status reporting at agreed milestones in the EDI process flow using standard interfaces. A list of all possible statuses that the external system can return is available in Table 3 on page 15.

·

Status is communicated to SAP using the same process as described in Inbound Requirements on page 20 above.

Last Revised: 4/30/2006 EDI/IDoc Overview

Page 22 of 22