EDI IDoc Overview

UNISON

Last Revised: 4/30/2006 EDI/IDoc Overview Page 1 of 22

Overview of EDI and the IDoc Interface

in SAP By

Emmanuel Hadzipetros

UNISON


Version Control

Version Created By Created On 1 Emmanuel Hadzipetros 1/31/2005

UNISON


Table of Contents

EXECUTIVE SUMMARY ........................................................................................................................................................4

PURPOSE ....................................................................................................................................................................................... 4 INTENDED AUDIENCE ................................................................................................................................................................. 4 ASSUMPTIONS .............................................................................................................................................................................. 4 SCOPE ............................................................................................................................................................................................ 4 ACRONYM DEFINITIONS ............................................................................................................................................................. 4

EDI ARCHITECTURE ..............................................................................................................................................................4

IDOCS: THE HEART OF SAP’S EDI ARCHITECTURE............................................................................................................... 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

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.

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 Idoc number n Direction of transmission n Sender and Receiver information: Port and Partner n Message Type n 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.

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 E1HDDOC Document Header n E1HDADR Header Addresses n E1ITDOC Item Details n E1ITSCH Item Schedule n E1TLSUM Trailor Section

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 Control segment structure defined in Data Dictionary

MANDT 003 Client 110 UD3 110, for Dev.

DOCNUM 016 Idoc number SAP Idoc generated in SAP.

DOCREL 004 SAP Release for Idoc 46C

STATUS 002 Status of Idoc 64 Most recent status of Idoc.

DIRECT 001 Direction 2 2 = Inbound

OUTMOD 001 Output mode

EXPRSS 001 Overriding in inbound processin

TEST 001 Test flag

IdocTYP 030 Name of basic type ORDERS05 Basic type, ie, ACLPAY02, DELVRY03, etc.

CIMTYP 030 Name of extension type Custom segment name.

MESTYP 030 Logical message type ORDERS Idoc Message type: ie, ORDERS, DESADV, etc.

MESCOD 003 Logical message code

MESFCT 003 Logical message function

STD 001 EDI standard, flag

UNISON



STDVRS 016 EDI standard, version and relea

STDMES 006 EDI message type 850 EDI message type.

SNDPOR 010 Sender port, external system A000000017 EDI file port name: Logical system for EDI subsystem.

SNDPRT 002 Partner type of sender KU Customer partner type. Vendor = LI

SNDPFC 002 Partner function of sender SP If present: VN (Vendor), SP (Sold-to party), BP (Bill-to party), SH (Ship-to party), etc.

SNDPRN 010 Partner number of sender 100735 Partner number

SNDSAD 021 Sender address (SADR)

SNDLAD 070 Logical address of sender Partner ID for the EDI Sender from the Group Level segment of the EDI transaction.

RCVPOR 010 Receiver port (SAP System) SAPUHD Logical port for DEV; SAPQAS in QAS.

RCVPRT 002 Partner type of recipient LS Logical system

RCVPFC 002 Partner function of recipient

RCVPRN 027 Partner number of recipient SAPUHD110 Logical system for Dev 110.

RCVSAD 028 Recipient address (SADR)

RCVLAD 070 Logical address of recipient Partner ID for the EDI Receiver from the Group Level segment of the EDI transaction.

CREDAT 008 Created on

CRETIM 006 Time created

REFINT 014 Reference to transfer (EDI inte

REFGRP 014 Reference to message group (EDI

REFMES 014 Reference to message (EDI messa

ARCKEY 070 Key for (external) message arch

SERIAL 020 Serialization field

UNISON


Table 2: Control record structure with Outbound values


TABNAM 010 Name of table structure EDI_DC40 Control segment

MANDT 003 Client 110 UD3 110, for Dev.

DOCNUM 016 Idoc number 123456789 SAP Idoc number.


STATUS 002 Status of Idoc

DIRECT 001 Direction 1 1 = Outbound

OUTMOD 001 Output mode

EXPRSS 001 Overriding in inbound processin

TEST 001 Test flag

IdocTYP 030 Name of basic type DELVRY03 Basic type

CIMTYP 030 Name of extension type DELVRY03EXT_855 Custom segment name.

MESTYP 030 Logical message type DESADV Idoc Message type

MESCOD 003 Logical message code

MESFCT 003 Logical message function

STD 001 EDI standard, flag

STDVRS 016 EDI standard, version and relea

SDTEMES 006 EDI message type 855 EDI message type

SNDPOR 010 Sender port (SAP System) SAPUHD Logical port

SNDPRT 002 Partner type of sender LS Logical system

SNDPFC 002 Partner function of sender

SNDPRN 010 Partner number of sender 1235455 Partner number

SNDSAD 021 Sender address (SADR)

SNDLAD 070 Logical address of sender Partner ID for the EDI Sender from the Group Level segment of the EDI transaction.

RCVPOR 010 Receiver port (SAP System, exte A000000017 EDI file port name: Logical system for Tibco

RCVPRT 002 Partner type of recipient KU Customer

RCVPFC 002 Partner function of recipient SP If present: VN (Vendor), SP (Sold-to party), BP (Bill-to party), SH (Ship-to party).

RCVPRN 027 Partner number of recipient 100374 SAP partner number.

RCVSAD 028 Recipient address (SADR)

RCVLAD 070 Logical address of recipient Partner ID for the EDI Receiver from the Group Level segment of the EDI transaction.

CREDAT 008 Created on

CRETIM 006 Time created

REFINT 014 Reference to transfer

REFGRP 014 Reference to message group

REFMES 014 Reference to message

ARCKEY 070 Key for (external) message arch

SERIAL 020 Serialization field

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 Subsystem

Purchase OrdersSales OrdersDelivery DocumentsInvoicesRemittancesInventory Movementsetc .

Exports IDOCsthru File /tRFC

Port

IDOC files .EDI enabledbusiness

transaction

Creates BusinessDocument

IDOC InterfaceIDOCs encapsulate

all the data in thebusiness docs .

Standard function modules manage all

interface services& processescreate IDOC , import /export ,

system validation ,partner mgmnt , error & workflow

mngmnt , data& transactional

processing .

Creates BusinessDocument

EDI enabledbusiness

transaction

SAP App Server

Import /Export andmapping betweenIDOCs and EDI

messages ,transmission

services , functionalacknowledgements

etc .

EDI

PARTNERS

Enterprise SchedulingControlling 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 Inbound: RFC enabled import, callable by an external system. n Outbound: RFC enabled export calling an external executable to kick off import

and processing in an external EDI subsystem. n Validation of control segment data including Idoc interface configuration such

as logical systems, ports, partner profiles, correct sending and receiving partners, etc.

n Processing and posting of inbound document data to SAP transactions. n Processing and extraction of outbound data from the SAP business object.

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

Outbound Processing

SAP

Bus DocCreated /Saved

EDI Subsystem

Output Type =EDI

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

Reads File Port

IDOC fileExported

SAP APP Server

Calls script onapp server totrigger EDIsubsystem

1.

2.

Begin subsystemProcessing

Transmission :AS 2, VAN ,

FTP

EDI

PARTNERS

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 .

Confirms Part . Profile

Run RSNAST 00

Run RSEOUT 00

IDOC CreatedStatus 30

Writes rec . toNAST

Status backto SAP

Calls startrfc to trigger receipt of status file in SAP

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 Output type: NEU. A standard output type for Orders that can generate a number of different media including EDI.

n Output Medium: print, fax, ALE, EDI, etc.; n Partner Function (ie, VN for Vendor, BP for Bill-to or SH for Sold-to partners); n Partner Number for the recipient of the output. n 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.

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 Partner 2071932 set up as a Partner Profile of Partner type LI (Vendor). n Outbound parameters for Partner Function VN (Vendor) Message Type ORDERS. n A Receiver port must exist (in Dev 110 this would be A000000017). n Packet size for the Idoc file should be defined. Default is 100. n Idoc basic type must be identified: ORDERS05. n 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 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.

n If successful, status in EDIDS is set to 03: Data passed to port OK. n Another status record is saved in EDIDS for the Idoc to indicate successful

triggering of the EDI subsystem (18) via a file based interface. n 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 The Idoc sits in the Idoc database at status 30 (Idoc ready for dispatch). n Program RSEOUT00 is executed via the SAP Job Scheduler (SM36: Maestro). n 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. n The Idoc file is passed through the file port, which triggers the EDI subsystem

through a script or by an RFC call.

UNISON


n If successful, status in EDIDC and EDIDS is set for each Idoc to 03: Data passed to port OK.

n Another status is saved in EDIDS for each Idoc in the file to indicate that the EDI subsystem has been triggered (18).

n 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 <port name> is set up for:

n Outbound path: <file path> n File name: determined dynamically by function

EDI_PATH_CREATE_MESTYP_DOCNUM, that saves the Idoc file as <MESSAGETYPE>_<IdocNUMBER>, ie, INVOICE_00210031 (or other standard for Universal).

n 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 Hub-TrustedLink interface.

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 Error within control information of EDI subsystem

05 Error during translation

06 Translation OK

07 Error during syntax check

08 Syntax check OK

09 Error during interchange handling

10 Interchange handling OK

11 Error during dispatch

12 Dispatch OK

13 Retransmission OK

14 Interchange Acknowledgement positive

15 Interchange Acknowledgement negative

16 Functional Acknowledgement positive

17 Functional Acknowledgement negative

22 Dispatch OK, acknowledgement still due

23 Error during retransmission

24 Control information of EDI subsystem OK

36 Electronic signature not performed (timeout)

40 Application document not created in receiving system

41 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 EDI_DS40 10 Name of table structure

MANDT 140 3 SAP client

DOCNUM 00000000002062012 16 Idoc number

UNISON


Field name Value Len Description

LOGDAT 20030219 8 Date of status information

LOGTIM 145358 6 Time of status information

STATUS 04 2 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:

<path for startrfc>\SYS\exe\run\startrfc -3 -d UD3 -u <username>

-p <password> -c 110 -l E -h ushsap68 -s 01 -g ushsap68 -x sapgw00

-t -F EDI_STATUS_INCOMING -E PORT= A000000017 –E PATHNAME=<status file 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 a new status segment is written to EDIDS for the Idoc; and n 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 Error passing data to port

03 Data passed to port OK

18 Triggering EDI subsystem OK

19 Data transfer for test OK

20 Error triggering EDI subsystem

21 Error passing data for test

25 Processing despite syntax error (outbound)

26 Error during syntax check of Idoc (outbound)

27 Error in dispatch level (ALE service)

29 Error in ALE service

30 Idoc ready for dispatch (ALE service)

31 Error - no further processing

32 Idoc was edited

33 Original of an Idoc which was edited

34 Error in control record of Idoc

35 Idoc reloaded from archive

37 Idoc added incorrectly

38 Idoc archived

UNISON



39 Idoc is in the receiving system (ALE service)

40 Application document not created in receiving system

41 Application document created in receiving system

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

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

<pathname>\SYS\exe\run\startrfc -3 -d UD3 -u <username> -p <password> -c 110 -l E -h ushsap68 -s 01 -g ushsap68 -x sapgw00 -t -F EDI_DATA_INCOMING -E PORT=<portname> -E PATHNAME=\\<pathname>\<filename> >> %TRACE%

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

n Partner number: the SAP customer or vendor master number. n Partner type: KU = Customer, LI = Vendor. n Post processing permitted agent. n Partner function: ie, BP = Bill-to, SH = Ship-to. n Inbound Message type n 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.

n Processing options: Trigger immediately or by background program. Processing will be by background program, scheduled in SAP but executed by <skedular>.

· 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 The control segment is written to table EDIDC. n The data segments are written to table EDID4 n 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 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.

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

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 Performance could be improved by using Parallel processing options with Server Groups.

n 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 Status 53: Application document posted. The Idoc successfully posted to the transaction.

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

UNISON


Table 6: SAP Idoc interface inbound status codes


50 Idoc added

51 Error: Application document not posted

52 Application document not fully posted

53 Application document posted

54 Error during formal application check

55 Formal application check OK

56 Idoc with errors added

57 Test Idoc: Error during application check

58 Idoc-Copy from an R/2 connection

60 Error during syntax check of Idoc (inbound)

61 Processing despite syntax error (inbound)

62 Idoc passed to application

63 Error passing Idoc to application

64 Idoc ready to be transferred to application

65 Error in ALE service

66 Idoc is waiting for predecessor Idoc (serialization)

68 Error - no further processing

69 Idoc was edited

70 Original of an Idoc which was edited

71 Idoc reloaded from archive

73 Idoc archived

74 Idoc 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: <pathname>

QAS: <pathname>

PRD: <pathname>

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 Value

Start rfc path \\<pathname>\startrfc

-3 System control: log on to R3 system

-d SAP System UD3 (Development)

-u EDI user name <username>

-p EDI user Password <password>

-c SAP client 110 (Dev)

-l Language E

-h SAP application server ushsap68

-s SAP system number 01

-g SAP Gateway host ushsap68

-x SAP Gateway service sapgw00

-t Turns trace switch on.

-F Function module for inbound messages/status EDI_DATA_INCOMING (Idoc) EDI_STATUS_INCOMING (Status file)

-E SAP EDI port PORT = <portname>

-E Path and file name for inbound Idoc file PATHNAME=<patname>\<filename>

· 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: =<pathname> QAS: =<pathname> PRD: =<pathname>

n Trace Files: DEV: =<pathname>

QAS: =<pathname>

PRD: =<pathname>

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 3 Client 110


DIRECT 1 Direction 2

IdocTYP 30 Name of basic type SHPCON

MESTYP 30 Logical message type DELVRY03

SNDPOR 10 Sender port (SAP System) <portname>

SNDPRT 2 Partner type of sender LI (Vendor)

SNDPFC 2 Partner function of sender, if maintained in partner profile

SNDPRN 10 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 10 Receiver port (the SAP System port receiving the file) SAPUHD

RCVPRT 2 Partner type of recipient LS

RCVPFC 2 Partner function of recipient, if maintained in partner profile

RCVPRN 27 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: <pathname>

QAS: <pathname>

PRD: <pathname>

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