Multiple Ways of Handling Inbound EDI Transactions: by Pramod Veguru

Multiple
ways of handling inbound EDI transactions

By Pramod Veguru
Cogent IBS Inc. 2008. All Rights reserved.
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
5
(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.
10

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.
11
12
13
14
15
What we will cover

Inbound Scenario-1
Regular or Direct posting

Partner profiel set-up Inbound EDI configuration BD87 transaction overview
16
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
17
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.
18

This tab may be filled if workflow functionality is desired:
19

Inbound Processing Settings: Transaction code: WEDI
20

Inbound Processing Settings: Transaction code: BD51
21

Inbound Processing Settings: Transaction code: BD51
22

Inbound Processing Settings: Transaction code: WE57
23
24

25

26

27

28
29

30

Processing Inbound IDocs:
31

Processing Inbound IDocs that could not post successfully
32

Processing Inbound IDocs that could not post successfully
33
What we will cover

Inbound Scenario-2
Custom Functionality
Technical aspects of Custom Functionality Explained in detail by taking a custom IDoc processing function
module as an example
34
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.
35

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.
36
37

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.
38
39

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

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
41
42
43

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

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).
45
What we will cover

Inbound Scenario-3
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
46
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.
47
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
48
49
50

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 function module may be required.
If the IDoc is developed from scratch, a whole new custom
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.
51

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

53
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.
54
References
o www.erpgenie.com o www.disa.org o ALE, EDI and IDOC Technologies 2nd Edition by Arvind Nagpal
and John Pitlak
55
Thanks to Cogent IBS!
56
Q&A
57
About Cogent IBS, Inc. Cogent Integrated Business Solutions, Inc. is an SAP focused consulting services company based out of Troy, Michigan, USA. CogSAP08 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.
58

Multiple Ways of Handling Inbound EDI Transactions: by Pramod Veguru

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Multiple Ways of Handling Inbound EDI Transactions: by Pramod Veguru

Uploaded by

Copyright:

Available Formats

Multiple

ways of handling inbound EDI transactions

Cogent IBS Inc. 2008. All Rights reserved.

Cogent IBS Inc. 2008. All Rights reserved.

What we will cover

Cogent IBS Inc. 2008. All Rights reserved.

Cogent IBS Inc. 2008. All Rights reserved.

Benefits of EDI include:

Most common EDI cycle example:

What we will cover

Cogent IBS Inc. 2008. All Rights reserved.

How an inbound EDI data looks?

Inbound EDI explained

Inbound EDI explained

Cogent IBS Inc. 2008. All Rights reserved.

Inbound EDI explained

Cogent IBS Inc. 2008. All Rights reserved.

Inbound EDI explained

Cogent IBS Inc. 2008. All Rights reserved.

Inbound EDI explained

Cogent IBS Inc. 2008. All Rights reserved.

Inbound EDI explained

Cogent IBS Inc. 2008. All Rights reserved.

What we will cover

Regular or Direct posting

Cogent IBS Inc. 2008. All Rights reserved.

Scenario:1 (Regular posting)

Cogent IBS Inc. 2008. All Rights reserved.

Scenario:1 (Regular posting) explained

Cogent IBS Inc. 2008. All Rights reserved.

Scenario:1 (Regular posting) explained

Cogent IBS Inc. 2008. All Rights reserved.

Scenario:1 (Regular posting) explained

Cogent IBS Inc. 2008. All Rights reserved.

Scenario:1 (Regular posting) explained

Cogent IBS Inc. 2008. All Rights reserved.

Scenario:1 (Regular posting) explained

Cogent IBS Inc. 2008. All Rights reserved.

Scenario:1 (Regular posting) explained

Cogent IBS Inc. 2008. All Rights reserved.

Scenario:1 (Regular posting) explained

Cogent IBS Inc. 2008. All Rights reserved.

Scenario:1 (Regular posting) explained

Cogent IBS Inc. 2008. All Rights reserved.

Scenario:1 (Regular posting) explained

Cogent IBS Inc. 2008. All Rights reserved.

Scenario:1 (Regular posting) explained

Cogent IBS Inc. 2008. All Rights reserved.

Scenario:1 (Regular posting) explained

Cogent IBS Inc. 2008. All Rights reserved.

Scenario:1 (Regular posting) explained

Cogent IBS Inc. 2008. All Rights reserved.

Scenario:1 (Regular posting) explained

Cogent IBS Inc. 2008. All Rights reserved.

Scenario:1 (Regular posting) explained

Cogent IBS Inc. 2008. All Rights reserved.

Scenario:1 (Regular posting) explained

Cogent IBS Inc. 2008. All Rights reserved.

Scenario:1 (Regular posting) explained

Cogent IBS Inc. 2008. All Rights reserved.

What we will cover

Cogent IBS Inc. 2008. All Rights reserved.

Scenario:2 (Custom Functionality)