An EDI implementation methodology

There are basically 5 phases of the project that need to be completed sequentially: Phase 1: The Assessment and Project strategy phase
Look at the business needs, map these to EDI, determine gap and implications, prototype if necessary, agree and sign-off scope

Phase 2: The Design phase

Naming standards, interface design, future flexibility, audit requirements and technical impact, DRP and archiving strategies

Phase 3: The Configuration phase

Confirm business requirements, basis config, functional config, mapping, QA and testing and sign-off

Phase 4: The Development phase

When non-standard SAP functions need to be implemented. Functional specifications, technical specifications, develop and configure, QA and testing and sign-off.

Phase 5: The Operations phase

Define support roles, capacity planning, job monitoring, failure recovery and problem resolution

Phase2 : Planning is an important first step to take in any EDI implementation. First of all an understanding of the following should be gained:

EDI; application (SAP); requirements of trading partners; requirements of EDI standards being used; and the EDI mapping tool that will be used.

The following is a list of things that should be considered during the planning phase of an EDI implementation:

identify EDI goals/requirements; identify EDI organizational structures (EDI coordinator and steering committee); train people involved in EDI; select and list trading partners;

determine public standard versions and transaction to be used with trading partner; confirm envelope selection and contents for each trading partner; confirm communication requirements for each trading partner; analyze application (SAP); consider audit and security requirements; and analyze future requirements.

Documents Mapping template - What should you be looking for when designing a scenario between 2 parties? OSS Note - How to implement EDI.

The purpose of this document is to outline the technical design of the EDI interface from SAP to the EDI subsystem.
Interface design Interface design specification - The purpose of the document is to describe the functional technical design and the physical technical design of the EDI architecture.

Phase 3 :

"Once your design has been thoroughly thought through, and project management approval has been achieved the detailed configuration can commence. Prior to this phase some configuration work may have been done to determine the best way to achieve your desired goal. To configure EDI in SAP you can utilize numerous settings and programs to configure the solution in a multitude of ways. We document a few for you to browse through below."
This section describes how to proceed with the implementation of an EDI solution. The selected EDI mapping tool will also determine the details of some of the steps that has to be followed.
Install EDI mapping tool

The selected EDI mapping tool has to be installed and tested for technical correctness.
Environment control

The selected EDI mapping tool should be set up to allow users to log onto and use the system. This steps also includes the configuration that has to be done on the EDI mapping tool for each trading partner. This step will be repeated when new trading partners are added.
EDI mapping

This step is dependent on the actual EDI mapping tool selected, but certain concepts has to be considered and followed nevertheless.

Mapping defines the relationship between an application data set and a target EDI standard, and vice versa. Mapping is usually divided into two phases: application definition and transaction mapping. In application definition, you determine what your application data set looks like. In transaction mapping, you tell the mapping tool how to map the data from application to EDI standards (and vice versa). Transaction mapping defines the relationship between data fields in your application and EDI data elements. Generic templates or mapping tool specific templates should be used for this task.
Communication

Communication involves the actual sending and receiving of data to and from your trading partners. The way communication works is dependent on the EDI mapping tool and the communication technicalities selected.
Prepare Scheduling

The scheduling requirements for EDI communication and processing as defined during the planning/design phase of the implementation should be implemented. The tools selected and the functionality they provide will determine the implementation details. This includes things like scheduling communications sessions and mapping jobs.
Documents EDI configuration guide - Details the steps to set up the stock transfer scenario in SAP. (ORDERS, ORDCHG, INVOIC, ORDRSP) Detailed configuration guide Partner configuration - How to configure certain partner scenarios Output determination - Short document briefly describing a few options for output determination configuration

Phase4 :

To do EDI IDoc development your scenario designer will need in-depth knowledge of IDoc scenario development and EDI configuration. A handy knowledge of ABAP is also required..."

1. Functional specifications need to be drawn up, by the business, describing exactly what is required by them, that is not available in the standard EDI scenarios. 2. A technical specification can then be drawn up by the EDI team. In this technical specifications the following needs to be addressed: o o o o o o New IDocs, segments, message types, process codes required; New fields added to existing IDocs; Program \ user exits \ message control for populating the fields; Inbound functional module details; EDI configuration set up requirements; and Error handling.

Once the specification is completed and confirmed by the business, programming can begin.
3. Developing an EDI scenario will include the following steps:

OUTBOUND:
o o o o o o Create Segments and IDoc type; Create Message Type and link to IDoc type; Populate IDoc using message control \ user exit or program (ABAP); Distribute IDoc using MASTER_IDOC_DISTRIBUTE; Create object type if required; Generate outbound partner profiles;

INBOUND:
o o o o Write inbound function module (FM) to process inbound IDoc (ABAP); Create process code and link to FM; Generate inbound partner profiles; and Link object type to FM for error handling.

4. QA & Testing - Including unit and string testing. Ensure a quality solution. QA done by the EDI team leader and testing done by the business owner and EDI scenario developer. 5. Sign-off by the business - Ensure the development is thoroughly tested and comprehensively documented prior to sign-off against the functional specification.

Deliverables during this stage EDI Functional Specification - For each development a detailed functional requirement document is produced and confirmed by the business. EDI \ ALE IDoc Scenario Development Guide - Details what development was done and how to configure the solution. Needs to be QA'd by someone else in the know. Test Procedures - Unit and string testing needs to be conducted on the development together with result logging and sign-off

Phase 5 :

Electronic Data Interchange is here to stay. SAP has provided many tools to ease the integration to EDI subsystems and these, together with a methodology of how to implement EDI are described in the following pages."
A definition "EDI is described as the interchange of structured data according to agreed message standards between computer systems, by electronic means. Structured data equates to a simple and direct method of presenting the data content of a document. The method of ensuring the correct interpretation of the information by the computer system is defined by the EDI standard." "EDI is a technique used to communicate business transactions between computer systems of different companies and organizations. Note that sometimes the EDI mechanism deployed at a company is often used to interface to other systems within the same organization."

Info shuttle - "I was implementing EDI at a customer and I wanted some real data to test with in Development, so I asked the Project Manager to see if he could arrange something. Literally, 20 minutes later he came back and said that there were 10 new orders in Development, together with the customer master records related to the order, the carrier vendor master record, the material master records, ... were all there. I asked him how he had done it so quickly which led me to my first exposure with Infoshuttle, a tool that does this for you using the ALE functionality. As an ALE consultant I know how to do this

stuff but I also know how long it would take to set that up. This is truly a product worth exploring in more detail." Kevin Wilson, ERPGenie.COM Founder, ALE \ EDI \ Workflow Consultant (Request Product Detail) Some thoughts

You should not to attempt to switch to a full SAP EDI implementation overnight. It takes time for people, systems, and processes to adapt to any new methodology. Implementing SAP EDI is a project in its own right and needs to be handled phase by phase as in any other information system implementation. We describe some of the issues and how to implement an SAP EDI solution in the following pages. The painful issues of implementing EDI are considered to be:

Application level configuration - Message control, partner determination, output determination Technical configuration - Just getting the systems to talk to each other. SAP, translator, modem... Testing - How do you test with someone you may never meet? How do you do your own testing without sending data to your partner? How do you differentiate between a test message and a real one? Mapping - How do you map an IDoc to an EDI message? What fields go where?

Process Separate sales and shipping When a customer places an order in the case of decentralized sales, a sales order is posted there. In the process, a purchase order is generated automatically for the main shipping system (vendor). This purchase order generates a sales order in central shipping. The local sales office can be notified through a confirmation and/or a

Message types / IDocs / scenarios ORDERS / ORDERS04 ORDCHG / ORDERS04 ORDRSP / ORDERS04 DESADV / DELVRY02 INVOIC / INVOIC02

Scenarios that must be taken into account:

shipping notification. The delivery to the customer can take place directly through the main shipping system or through the local sales office (after supply from the main shipping system). After the delivery is made, the internal billing document is passed on to the local sales office as an incoming invoice for the purchase order. Distributed credit management This scenario should be used when several local sales systems perform their credit limit checks in a central accounting system. To achieve this, the central accounting system sends a credit vector that contains all the required credit information for an account in a control area. The local checks are then performed against this credit vector. If the credit vector is outdated, a synchronous function call can be triggered to determine the current data in the central accounting system. Stock transfer of goods The requesting system (e.g. sales) generates a purchase order in the supplying system (e.g. production). This purchase order generates a sales order in the supplying system. The requesting system can be notified through a confirmation and/or a shipping notification. After the delivery is made, the billing document is passed on to the requesting system as an incoming invoice for the purchase order.

Distributed credit management Stock transfer of goods Financial Accounting Profitability Analysis CRESTA / CRESTA01

Scenarios that must be taken into account: Separate sales and shipping Financial Accounting

ORDERS / ORDERS04 ORDCHG / ORDERS04 ORDRSP / ORDERS04 DESADV / DELVRY02 INVOIC / INVOIC02

Scenarios that must be taken into account: Separate sales and shipping Financial Accounting BLAORD / BLAORD03 BLAOCH / BLAORD03 BLAREL / BLAREL02

Distributed purchasing contracts This scenario enables the distribution of contracts using local calls: A central purchasing department negotiates, records, and maintains the contracts. The contracts are distributed to the local purchasing systems, where a copy of the main contract with a reference to the original is saved. The release orders are entered in the local purchasing systems. The release order information is updated locally and sent to the main system. The release order statistics for all the purchasing systems are updated in the main system.

Scenarios that must be taken into account: Purchasing Information System Financial Accounting

Accumulated exchange of information structures

Because the structure of the information structures to exchange can be determined In contrast to the transaction-specific data exchange at single by the customer, no fixed message type exists. Instead, the message type is

document level, this scenario allows you to exchange summarized data in the information structures directly between the systems. In the process, the information structures are updated in the local systems as usual, and periodically sent to the main system via ALE. A delta data supply is generated by comparing the current dataset with the dataset from the last successful export. The participating systems must use the identical structure for all the information objects to exchange (same name, same periodicity, same characteristics, same key figures). Sales planning and rough-cut capacity planning

generated for the information structure to distribute, based on IDoc type SOPGEN01 . Scenarios that must be taken into account: Rough-cut capacity planning Purchasing Information System Sales Information System

Because the structure of the information structures to exchange can be determined by the customer, no fixed message type This scenario is used to distribute centrally calculated production or sales figures to several local R/3 Systems. The exists. Instead, the message type is generated for the information structure to scenario also supports reverse transmission of the planning data that was adjusted in the local systems back to the main distribute, based on IDoc type SOPGEN01 . system. This scenario is one concrete example of the generally available function "Accumulated exchange of information structures" Scenarios that must be taken into account: Accumulated exchange of information structures The planning situation is read synchronously

Cross-system planning situation You can use this business process when you have maintained a material in several systems and you want to perform a cross-system analysis of the requirement/stock situation for this material. Sales Information System

In this scenario, sales data (delivery note, sales order, billing document) is passed on from local sales systems to a central Sales Information System. The info structures in this main Scenarios that must be taken into account: system are updated based on this data. Because single documents are sent in this scenario, the info structures and Accumulated exchange of update rules may differ between the involved systems. information structures Purchasing Information System EKSEKS / EKSEKS01

SISCSO / SISCSO01 SISINV / SISINV01 SISDEL / SISDEL01

In this scenario, the following purchasing data is sent from Scenarios that must be taken into account: local purchasing systems to a central Purchasing Information System: Accumulated exchange of information structures Request for quotation Purchase order/contract/scheduling agreement Goods receipt Incoming invoice

The info structures in this main system are updated based on this data. Because single documents are sent in this scenario, the info structures and update rules may differ between the involved systems. Inventory Controlling Stock movements are reported by local inventory management to the main Inventory Controlling system, where they trigger updates to the information structures. INVCON / INVCON01

Scenarios that must be taken into account: Accumulated exchange of information structures

Decentralized Warehouse Management System (WMS)

DEBMAS / DEBMAS03

This scenario involves two systems: the ERP (Enterprise MATMAS / MATMAS03 Resource Planning) system, which handles functions like inventory management, purchasing, sales, and shipping, and CLFMAS / CLFMAS01 the WMS (Warehouse Management System), which takes care of the warehouse management functions. CHRMAS / CHRMAS02 CLSMAS / CLSMAS03 Inbound and outbound deliveries are replicated in the WMS by the ERP system. Goods receipts and issues are posted in BATMAS / BATMAS01 the WMS with reference to the replicated inbound and outbound deliveries. The goods receipt and goods issue postings for the inbound and outbound deliveries in the WMS MBGMCR / MBGMCR01 generate inbound/outbound delivery confirmations that are SHP_OBDLV_SAVE_REPLICA / sent to the ERP system, which then posts the stocks of the SHP_OBDLV_SAVE_REPLICA01 moved quantities. As a result, stock changes resulting from the physical goods receipts and goods issues are posted in the WMS first and then in the ERP system. These messages cause stock changes in inventory management in the ERP system. This means the physical stock placement/removal takes place before the stocks are posted. SHP_OBDLV_CONFIRM_DECENTRAL / SHP_OBDLV_CONFIRM_DECENTRAL01 SHP_IBDLV_SAVE_REPLICA / SHP_IBDLV_SAVE_REPLICA01 SHP_IBDLV_CONFIRM_DECENTRAL / SHP_IBDLV_CONFIRM_DECENTRAL01