EDI Subsystem

The EDI subsystem carries out the task of converting an EDI document in a standard EDI format to an IDoc file, and vice versa. SAP does not supply the EDI subsystem because several EDI standards are in existence and each standard has multiple versions. To further complicate the process, these standards are still evolving. Hence, this task is best carried out by EDI vendors, who stay current with the standards.

EDI vendors have developed translators to help with the conversion of application−specific messages IDocs, in the case of SAPto standard EDI format. Any translator software product is completely independent of the SAP software and resides outside the SAP system.

The translator can be installed on the same hardware as the SAP system, or it can stand alone on another computer. The operating system environment of the EDI subsystem can be different than the SAP operating system environment. If the SAP system is installed on a UNIX platform, the subsystem can reside on a separate platform that operates on, for example, Windows NT.

SAP certifies several EDI subsystems for compatibility with the EDI interface. The IDoc interface has changed with every release . For this reason, the certification is applicable only for a specific release of SAP.

The subsystem has several responsibilities in the EDI process chain.

Data Mapping

Within the framework of SAP EDI, the conversion of a business document in IDoc format to an EDI standard format (and vice versa) is the most important task performed by a subsystem. This process is resource intensive and, hence, is better done at the subsystem level than within SAP.

The following conversions and translations are carried out by the subsystem.
  1. Creating a control record for each inbound IDoc. An inbound IDoc must have a control record.The EDI subsystem builds the control record using the information stored in its local repository or from the SAP repository.
  2. Removing the control record during the outbound process. The control record in the IDoc file is used by the subsystem for housekeeping functions, such as locating the trading partner profile. The data on the control record is not needed for translating the content of the EDI documents.
  3. Translating data from IDoc format to EDI format. For an outbound transaction, the EDIsubsystem converts data in the IDoc format to a suitable EDI format.
  4. Translating data from EDI format to IDoc format. For an inbound transaction, the EDI subsystem converts data in the standard EDI format to IDoc format.
  5. Bundling and unbundling IDocs. If several IDocs are passed to the EDI subsystem in one file, thesubsystem separates them into individual documents. Similarly, on the inbound process the subsystem can bundle multiple IDocs into a single file to improve performance.
Maintaining the Partner Profile

A partner is defined as the business partner with whom you conduct business and exchange EDI documents. These partners are not necessarily the same as the partners in the partner profile of SAP.
In SAP, the partner profile maintains parameters specific to the IDoc process, and in the subsystem the partner profile maintains parameters specific to the EDI process.

Some attributes in a partner profile are
  1. A unique partner number
  2. The partner type (Customer, Vendor)
  3. The standard used (EDIFACT, ANSI X12, and so on)
  4. The version of the EDI standard
  5. The EDI message exchanged (850, 860, ORDERS, ORDCHG)
  6. A functional acknowledgment flag
Triggering the Inbound Process

After receiving an inbound EDI transmission and creating an IDoc file, the subsystem is often responsible for triggering the inbound process. SAP provides a program named startrfc to start any RFC−enabled function module from the operating system level. For the EDI process, the subsystem uses the start rfc program to trigger the function module EDI_DATA_INCOMING.

Reporting Process Status to SAP

In an outbound process, after an IDoc has been transferred from SAP to the subsystem, SAP loses control over the process. However, SAP maintains visibility into the process by requiring the subsystem to report on the status of the process. SAP provides a file interface for the subsystem to send a status report at every milestone.

When the subsystem has status information to send to SAP, it creates a status file and uses the startrfc program to trigger the SAP system. The status file contains the IDoc number, which is used to identify the IDoc to which the status record is to be attached. The startrfc program calls the EDI_STATUS_INCOMING function module to start the processing of the status file in SAP.

Status 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 Acknowledgment positive
15 Interchange Acknowledgment negative
16 Functional Acknowledgment positive
17 Functional Acknowledgment negative
22 Dispatch OK, Acknowledgment still due
23 Error during retransmission
24 Control information of EDI subsystem OK
36 Electronic signature not performed (timeout)

Related Posts

EDI inbound process overview
EDI inbound process via work flow
EDI outbound process part one and two
Outbound process with message control

MYsap crm business scenarios and sap solutions

No comments :

Post a Comment