SAP EDI EDPAR Table Walkthrough – How to Cross Reference SAP Customer Number to External Customer Number (Part 1)

When creating IDOCs in SAP to send Invoices to customers via EDI you will likely have to send the customers their internal partner numbers on the EDI ANSI X12 810 Invoice Document.  In almost all cases this will not be the same as the SAP partner numbers.  So how can we set up a cross reference of SAP and external partner numbers?  Well, the answer is simple because SAP has set up a utility to handle this for you.  All you need to do is populate the EDPAR table in SAP using the VOE4 transaction.  Once this is completed the IDOC_OUTPUT_INVOIC function module will read the EDPAR table when the Invoice document output is processed and populate the LIFNR element of the E1EDKA1 or E1EDPA1 segments of the INVOIC IDOC with the external partner number.  Entries in EDPAR can be set up for multiple partners including the Sold-to, Ship-to, and Bill-To numbers so that external customer number cross-references can be passed on the IDOC if needed.

Let’s look at how this process works.  Let’s say we have created an invoice document in SAP.  In this case, the Sold-to, Ship-to, and Bill-to partners are all SAP customer number 15.  If we want to create an INVOIC02 IDOC on which the external customer numbers are populated for all three of these partners we would have to set up three EDPAR entries as displayed on the below screen shot.  The Customer field will contain the SAP partner number (Sold-to, Ship-to, Bill-to).  The Ext. Function field will contain the Partner Function (SP = Sold-to, SH = Ship-to, BP = Bill-to).  The External Partner field will contain the external partner number that the customer is expecting on the EDI file.  And the Int. no. field will contain the SAP partner number (Same as the Customer field).

[Read more...]

EDI Consulting

What is EDI?

The basic concept of EDI is to convert data from one format to another.  There are several  standards that are used, with the most used being ANSI X12 (American Standard) and EDIFACT (European Standard).  Most conversion work is done with canned EDI software.  An example of this is Sterling Commerce’s Gentran and GIS packages.  The packages can be used to convert a flat file format into an EDI standard file which removes all blank spaces and uses standard codes and qualifiers to distinguish field values.  The packages also includes utilities to pull the files from server locations or adapters that link up with customer systems (ex: SAP adapter to pull/push IDOCs from SAP).  These packages can also link to customers/vendors through a VAN (Value Added Networks) or direct connections (ex: FTP).

Why choose DataXstream?

Need an EDI Consultant?  If so, DataXstream is an excellent choice to perform customer EDI work because we  have a wide variety of talents, allowing us to complete the best possible project.  We have extensive SAP PI expertise and Datastage TX experience, and we have worked with other EDI packages.  We have also had the opportunity to work with Gentran products, including: Gentran for Unix, Gentran for Windows,  GIS for Unix, and GIS for AS400. 

DataXstream’s Expertise

DataXstream has the capabilities to set up the end-to-end interfaces in their entirety in SAP.  We have personnel that can configure SAP to create the IDOCs.  Additionally, we are able to configure Gentran systems and develop the maps that are used to convert the IDOC flat files to the standard EDI format.  DataXstream also has resources that can develop interfaces in Datastage TX and SAP PI.  These can also be used to convert SAP IDOCs to EDI standard files.

Most of this information is related to SAP since that is DataXstream’s area of expertise.  The canned packages can also be used to convert flat files from Legacy systems or other resources to EDI Standard format.  They can also be used to convert EDI standard files to emails.



SAP Standard Sale Area Cross Reference For Inbound IDOC Processing

Cross Reference To SAP Sales Area From External Customer Number – SAP EDSDC Table

If you have ever converted an external file into a SAP Sales Document IDOC (ex: ORDERS05) you may have hard coded the E1EDK14 segments of the IDOC which specify Sales Area and order type for the SAP Sales Document.  However, these segments are not required if you populate the E1EDKA1-LIFNR segment of the IDOC with the External Customer Number and populate the EDSDC table with the Sales Area and Order Type for the customer.  Your SAP system contains a standard utility that converts the External Customer Number to the Sales Area values and Order Type value contained in this table.

Sales Area Cross Reference From IDOCs ORDERS05 and DELFOR02

This utility is available in the standard SAP package to convert External Customer Number to SAP Sales Area when processing inbound IDOCs (ex: ORDERS05, DELFOR02) from non-SAP systems.  It eliminates the need to add E1EDK14 segments to the IDOC as it populates the Sales Organization, Distribution Channel, Division, and Sales Document Type using the entries in the EDSDC table which is populated using transaction VOE2.  In order for this process to work, you must have the Customers External number populated in the E1EDKA1-LIFNR field of the IDOC where E1EDKA1-PARVW is ‘AG’ and the EDPAR Customer Conversion table set up to convert the Customer External number to the SAP Customer number.  See my blog ‘SAP EDPAR Table – External Customer Number cross reference to SAP Customer Number’ for instructions on the External Customer Conversion.  By properly doing this, the standard SAP function module will use the EDSDC table to convert the External Customer Number to the SAP Sales Area and Document Type.  The following instructions will explain how to populate the inbound IDOC and the EDSDC table.

[Read more...]

A Single Mistake Can Cost You $$$$$

While working with a client on developing EDI-856 transactions with one of their trading partners, an error occurred that cost my client thousands of dollars in charge back fines.

In their SAP environment they produce a single DESADV IDoc per order/purchase order.  This could amount to several hundred DESADV IDocs being generated.  The initial development was a 1 to 1 translation in that each DESADV IDoc that was produced would be translated into a single EDI-856 document.

SAP EDI Idoc List Screen

Because of a single data error, due to department procedures not being followed in the warehouse in the closing of orders, the bad data element resulted and was repeated throughout all of the DESADV IDocs that were generated.  Translation of the IDocs was successful because this error was not conceived at the point of map development.  The hundreds of translated documents were sent to the trading partner and subsequently resulted in failed documents.

Because the trading partner generated a charge back for each document sent, my client was billed thousands of dollars in charge back fines.  This simple example shows how a single error repeated in each document can turn out to be a very costly problem.

I hope to show you in the next few postings how to bundle the IDocs together to:

  • Bundle and reduce the number of IDocs being translated
  • Reduce the number of EDI documents being sent to the trading partner
  • Minimize the charge back cost, should and error occur