Edi

Cogent IBS Inc. 2008. All Rights reserved. 1 1

Multiple ways of handling inbound EDI transactions

By Pramod Veguru

Cogent IBS Inc. 2008. All Rights reserved. 2

Session Summary Electronic Data Interchange (EDI) is about doing business and carrying out transactions with your trading partners electronically. On SAP side, EDI is handled through IDocs. When the data comes into SAP, it is called inbound transaction. When the data goes out of SAP, it is called outbound transaction. We will talk in detail about some common inbound EDI scenarios that are handled in SAP with the examples and solutions.

Assumptions:

The audience is familiar with basic SAP terms (like sales order, function module, application).


What we will cover…   Overview of EDI

  Benefits of EDI

  Most common EDI example


EDI – An Overview

Electronic Data Interchange (EDI) is about doing business and carrying out transactions with your trading partners electronically. EDI covers most things that are traditionally done using paper-based communication.

In the U.S., the most commonly used standard is ANSI X12, coordinated by the American National Standards Institute (ANSI). While in Europe, it is the Electronic Data Interchange for Administration, Commerce, and Transportation (EDIFACT) standard.

(Source: www.erpgenie.com)


Benefits of EDI include:   Reduced cycle time

  Increased productivity

  Reduced costs

  Improved accuracy

  Improved business relationships

  Enhanced customer service

  Increased sales

  Minimized paper use and storage

(Source: www.disa.org)


Most common EDI cycle example:   Customer transmits EDI 850 (purchase order)

  Supplier transmits EDI 997 (functional acknowledgement)

  Supplier transmits EDI 856 (advance ship notice)

  Customer transmits EDI 997 (functional acknowledgement)

  Supplier transmits EDI 810 (electronic invoice)

  Customer transmits EDI 997 (functional acknowledgement)

  Customer transmits EDI 820 (Electronic Funds Transfer) Payment

(Source: www.erpgenie.com)


What we will cover…   What is Inbound EDI?

  Example of an Inbound EDI data

  Inbound EDI explained

  Example of an Inbound EDI data how it looks after it came into SAP

  Transactions that are used in SAP to view inbound EDI data

  Finally how it looks after posting to an application


Inbound EDI

(Source: ALE, EDI and IDoc Technologies for SAP by Arvind Nagpal and John Pitlak)


How an inbound EDI data looks? ISA*00* *00* *08*9252671859 *01*007233224P *060311*0800*U*00401*000001117*0*P*>~ GS*PO*9252671859*007233224P*20060311*0800*1117*X*004010VICS~ ST*850*0001~ BEG*00*SA*0005911468**20060310~ REF*DP*638~ REF*IA*606461432~ ITD***0**0**30*****Terms Net 30 DATE OF INVOICE MUST NOT PRECEDE DATE OF SHIPMENT~ DTM*037*20060318~ DTM*038*20060326~ TD5**92*ALL FOB ORIGIN AND OR DESTINATION ORDERS MUST BE ROUTED CONFIRMED AT~ TD5**92*https www.nexnet.navy.mil fastweb OR CALL 1-800-423-4171~ CTB*AA*P.O IS SUBJECT TO TERMS & CONDITIONS IN PUB. 61 ONLINE AT WWW.NAVY NEX.COM~ N1*ST* WC Retail Dist Ctr*92*995~ N3*CALL1-800-423-4171 OR LOGIN AT*WWW.NEXNET.AVY.MIL/FASTWEB/~ N4*CHINO*CA*917109704~ N1*BT**92*995~ N2*NEXCOM WEST COAST~ N3*PO BOX 368150~ N4*SAN DIEGO*CA*921368150~ PO1**8*EA*7.5*WE*UP*076501619317*VA*5315M700~ PID*F*08***COLLAPSIBLE LANTERN~ PO4*1~ PO1**372*EA*2.35*WE*UP*076501000351*VA*5103B164T~ PID*F*08***PROPANE 16.4 OZ~ PO4*1~ CTT*2~ SE*25*0001~ GE*1*1117~ IEA*1*000001117~


Inbound EDI explained… The EDI transmission is received. The documents are deposited in a common repository for the subsystem. This part of the process is not part of the SAP EDI architecture.

  The EDI document is converted into an IDoc. The EDI-specific headers and trailers are stripped off, and the document is converted into an IDoc format suitable for SAP applications. The process is carried out at the EDI subsystem level.

  The IDoc is transferred to the SAP layer. The subsystem starts an inbound program in the SAP layer. This program reads the IDoc file and creates an IDoc in the SAP repository for further processing.


Inbound EDI explained…

  The IDoc received from the subsystem is passed to a posting program. This program creates an application document such as a sales order, purchase order acknowledgment, invoice, or shipment notice. The application document is created.

  The application document can be viewed. The application document created via EDI is the same as any document created manually in the system: The document can be viewed using standard application transactions. For example, if an incoming sales order was created via EDI, you could view the sales order document via transaction VA03.


What we will cover…   Inbound Scenario-1

Regular or Direct posting

  Partner profiel set-up

  Inbound EDI configuration

  BD87 transaction overview


Scenario:1 (Regular posting)

EDI-850 data comes in and converts into Idoc. Before the Idoc conversion takes place, we need to make sure ‘Partner profile’ is set-up in WE20 transaction


Scenario:1 (Regular posting) explained…

Click the ‘save’ button. Partner profile is created. Now we need to enter the details that is required to process EDI-850.



This tab may be filled if workflow functionality is desired:



Inbound Processing Settings:

Transaction code: WEDI



Inbound Processing Settings:

Transaction code: BD51



Inbound Processing Settings: Transaction code: BD51



Inbound Processing Settings: Transaction code: WE57



Processing Inbound IDocs:



Processing Inbound IDocs that could not post successfully



Custom Functionality

  Technical aspects of Custom Functionality

  Explained in detail by taking a custom IDoc processing function module as an example


Scenario:2 (Custom Functionality)

Client may request custom functionality based on many reasons:

1.  Standard SAP functionality is not enough or not available

2.  More flexibility in processing EDI messages so that processing method can be changed easily in future

One way of accomplishing custom functionality desired by the client is through developing a whole new IDoc processing function module in SE37 transaction.



Any IDoc processing function module interface will have these internal tables:

  Internal table for storing IDoc control record data

  Internal table for storing IDoc data

  Internal table for storing IDoc status record data

If additional functionality is desired (for example, workflow), it is defined in the interface.



First, all the parameters are ‘initialized’.

  This is generally the case with IDoc processing functional modules.

  This is to avoid any ‘clearing’ data problems which happens when the IDocs are processed in batch using BD87 transaction.



All custom IDoc processing function modules will need to read the IDoc data



Custom IDoc processing function modules generally rely on:

  Calling standard function modules/BAPIs for posting to the application

  Using BDC recording for posting

  Updating any custom tables

  Or Just reading the data and sending it as email to the required person



Custom IDoc processing function modules will need to update the status records of the IDoc by populating the internal table that is used for storing status records. As mentioned before, this internal table is defined in the interface.



Sometimes it is required not to post the IDoc to the application depending on certain criteria. In these cases, the IDoc may be simply purged (Error – No further processing).



IDoc extension

  Difference between IDoc extension and developing new IDocs

  IDoc extension explained

  Transactions used for extending IDocs

  Handling extended IDocs

  Tips on effectively extending IDocs


Scenario:3 IDoc Extension

Extending versus Developing New IDocs:

  After careful analysis of the IDoc process and its documentation, you might conclude that the standard basic IDoc type meets most of your requirements. In this case, you can simply extend the basic IDoc type.

  If the basic IDoc type does not meet your requirements at all, you create a new basic IDoc type from scratch.

  For example, if you are implementing an EDI document not sufficiently supported by SAP, you might need to develop a basic IDoc type from scratch.


Scenario:3 IDoc Extension explained…

Extending IDocs:

  Your business partner sends you additional information or expects additional information on an EDI document. For example, your customers expect an invoice number and date on an advance shipment notice transaction.

  You are interfacing with legacy systems using IDocs.

  IDoc extension is achieved using transactions WE30 and WE31



Handling IDoc extension:

  If the IDoc is only extended (by adding segments), the desired functionality can be achieved through userexits which are found in standard SAP function modules

  If the IDoc is developed from scratch, a whole new custom function module may be required.

Caution! Because developing new IDocs is considered a modification and, therefore, is not supported in an upgrade you have to review and test your process again after you upgrade.



Some things to keep in mind while doing IDoc extension:

  Avoid having too many mandatory segments.

  Create segments that can be reused by other IDocs.

  Organize the document to contain header information, detail information, and summary information. This technique is commonly used for SAP documents.

  Use industry standards for your data elements whenever possible.

(Source: ALE, EDI and IDoc technologies for SAP by Arvind Nagpal and John Pitlak)


Session Takeaways

o  Depending on the requirement of the customer, SAP has many ways to solve the tasks. The discussed ones are some common ways.

Additional helpful tips include:

o  We can also use programs like ‘RC1_IDOC_SET_STATUS’ to change the status of the posted IDoc to ’64’ and reprocess it into SAP using BD87 if the customer wants to reprocess for any reason.

o  We can use WE19 to make up IDoc and post IDoc for testing purposes if the translator is not available or installed yet.


Wrap-up

o  Using EDI in a business process will ensure speed, reduced paper costs, data accuracy and enhanced business relations

o  SAP has its way of handling EDI messages using concepts like IDocs and configuration in transactions like WEDI

o  There are many ways of handling inbound EDI transactions. It can be standard functionality provided by SAP or a complete customized functionality as required by the client.

o  In either case, there are tools and technology available on SAP to handle the tasks successfully. Most common methods are covered in this presentation.

o  …………


References

o  www.erpgenie.com

o  www.disa.org

o  ALE, EDI and IDOC Technologies 2nd Edition by Arvind Nagpal and John Pitlak


Thanks to Cogent IBS!


Q&A

Cogent IBS Inc. 2008. All Rights reserved. 58 58

About Cogent IBS, Inc.

Cogent Integrated Business Solutions, Inc. is an SAP focused consulting services company based out of Troy, Michigan, USA.

CogSAP’08 is a Cogent IBS, Inc. professional development event conducted exclusively for its employees.

No part of this presentation may be published or transmitted in any form without the express permission of Cogent IBS, Inc.

Edi

Documents

Transcript of Edi