EDI/IDoc: How is an EDI project carried out?

Note Number Released on Release 0047071 29.01.1997

Symptom How should you go about an EDI project? What steps are required? Additional key words IDoc, EDI, EDIFACT, ANSI X12, ODETTE, VDA Cause and preconditions Solution When executing an EDI project, different aspects must be considered. The expense for such a project must be determined on an individual basis, as such projects are customer-specific and require a lot of consultation. The following aspects are involved in an EDI project: 1. Selection of business partners You must choose the business partners involved in the EDI. The EDI standard to be used and the messages to be exchanged must be the same for all partners. 1. Selection of the EDI Subsystem An EDI Subsystem (translator, converter) is required to convert the SAP format IDoc into the message format of an EDI Standard. You must select a corresponding product. The IDoc interface is open, so that various EDI Subsystems can be added. SAP does not offer any EDI subsystem itself! Within our Authentication Program (Complementary Software Program CSP), SAP has certified some of these systems. Please note here, that this is a purely technical and functional authentication of the interface. That is, we test whether IDocs can be sent and received and whether a status report is created for sent IDocs. The authentication is not a business-based, functional test. 1. Implementation of the EDI procedure You are recommended here to follow four steps: a. Complete implementation of the SAP application b. Internal SAP test of the IDoc interface c. Test the IDoc interface with the EDI Subsystem d. Start production In particular the internal SAP test of the IDoc interface great attention is be dedicated since he allows in a very early stage to recognize errors and lacks of implementation. Complete implementation of SAP application Before you start implementing the EDI or IDoc functionality, the affected SAP applications must be implemented and their functionality must be available. Internal SAP test of the IDoc interface The test is made up of a combination of the technical, functional test as well as the business-based, functional test. Technical, functional test

Here, you should test whether IDocs from the SAP application are created and that they can be transferred to the file system (Outbound processing). Furthermore, you should test whether IDocs are copied in the file system and can be processed by the SAP application (Inbound processing). The individual steps can be supported with test tools: Output: Test from the NAST record (message control for MM and SD) with transaction WE15. An application document must previously be created in the application. Output: Test from the IDoc with transaction WE14. An application document must previously be created in the application. Inbox: Test from a formally correct inbound file with transaction WE16. The file can be made available first, or must be manually created with an editor in the usual way. Inbox: Test from an outbound file with transaction WE12. The file comes from one of the two named output tests. Inbox: Test from IDoc, including manual creation of the IDocs, with transaction WE19 (only from Release 3.1). Business-based, functional test For the created output IDocs, you must check that the IDoc contains all the data that was agreed on with the partner. This means that the data must be checked and compared field by field. If differences are found, proceed as follows: Can the data be produced by maintaining the basic data (customer, vendor, material or information record)? Can the data be produced by additional input in the transactions for the documents (purchase order, order, etc)? Is the corresponding application function that processes this data available at all? You should, of course, proceed int he same way for incoming IDocs. However, this check can be made using the SAP application. This decides, whether the data is sufficient to create or change an application document. Exceptions which cause notification via the SAP Business Workflow are triggered if necessary. In the tests, you should also check that these notifications reach the correct people. Once the tests described here have been completed and were successful, you can start connecting the EDI subsystem. Test the IDoc interface with the EDI Subsystem With the EDI Subsystem, you must conduct both local and remote tests. Local test In the local test of outgoing messages, you must ensure that the EDI messages created from the IDocs are in accordance with your partner. Via transaction WE17, you should also test that the status report of the EDI subsystem contains the required information on the initial IDocs and that exceptions are forwarded to the correct people. For incoming messages, you should check that the IDocs created from these messages can be processed by the SAP application. That is, the corresponding application documents can be created or changed. Remote test With the remote teset, you should pay attention to the communication with the partner as well as the processing of the messages by the respective partner system. Please note, that many EDI standards allow messages to be transferred in a test mode. Thus, you can test the chain of processing, transmission and further processing and distinguish these messages from "productive" messages at the same time. The test mode is indicated in the IDoc in the control record in the field TEST. In the EDI standard EDIFACT, this is made clear in the service segment UNB, data element 0035, and in the EDI standard ANSI X12, in the service segment ISA, data element I14. For SAP, it is entered in the partner profile for output. In the input, it is the key field of the partner profile, so that the business processes can also be controlled by this. Start production The productive phase of the EDI application may only be started if the tests were completed successfully. The tests here represent the minimum requirements for a successful EDI project. Further information can be obtained from the National Standardization Office (in Germany, the DIN) or through your EDI consulting partner.

Source code corrections Related notes

0032121 EDI/IDoc: Workflow in the EDI and IDoc basis 0041365 EDI/IDoc: Certified EDI subsystems for 3.0 and 3.1 0044416 EDI/IDoc: Messages from IDoc processing 0114714 EDI/IDoc: Certified EDI subsystems for 4.x 0116610 EDI/IDoc: Notifications from IDoc processing