SAP IDOCs for Customer Number with different Sales Organizations to different External Partnerships

Have you ever implemented an outbound  EDI process from SAP for a single customer number where the customer has multiple EDI trading by Sales Organization or Division?  It can be done.  In order to accomplish this you will need to create separate output types for each Sales Organization/Division and then set up the Access Sequence/Output Determination in order to create the IDOC for each partnership.  You can then use the Message Variant and/or Message Function fields of the Partner Profile to differentiate between the two Sales Organizations/Divisions.  Finally, you would set up your EDI Mapping to look at the Partner Profile fields in order to route it to the correct partnership.  Let’s take a closer look at this process.

Let’s say that Customer 15 in your SAP system buys products from your company.  It sends inbound EDI Orders to you using three different partner IDs because they have 3 internal divisions and they want all transactions to be separate.  You want to keep all sales data for this customer under one customer number in your SAP system and just separate them by a different division.  You are required to send out EDI invoices to this customer, but they must go to the correct EDI Partner ID.  Let’s say you would normally use the Standard SAP Output Type RD00 and  Access Sequence 0003 (Sales Org, Distribution Channel, Division, Customer Number) for producing your INVOIC IDOCs. [Read more...]

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

Let’s say you are receiving EDI ANSI X12 850 Sales Orders from you customers that need to be uploaded into your SAP System using the ORDERS05 IDOC.  Most customers will have their own internal customer numbers that they send in their EDI transmissions to represent the Sold-To and Ship-To partners.

How do you convert these external customer numbers into your internal SAP customer numbers?

Some may hard code these conversions into their EDI maps.  This approach can be very high maintenance as customers can add new ship-to locations or reorganize their internal numbers which would require changes to your maps.

Others may set up a cross reference table within their EDI translation table to perform the conversion.  This works well at times, but then you are at the mercy of your EDI group to update the table with any new additions or changes to existing entries. [Read more...]

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

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

SAP TechEd 09 Demo Jam Liveblog Recap

This blog is a recap of the liveblog of the  SAP TechEd 09 conference Demo Jam. To read in chronological order, start from the bottom and work your way up.

[Read more...]

SAP TechEd 09 Keynote Address Liveblog

Liveblogging SAP TechEd 09

Are you stuck in your cube while Bob from BASIS is heading to SAP TechEd 09 in sunny Phoenix?  Are you afraid that you’ll miss out on all the sun and fun?  While we can’t send the sun, we’ll try to bring you the fun.  DataXstream will be liveblogging at SAP TechEd 09.

Head over to live.dataxstream.com on Tuesday, October 13, 2009 to get up to second updates from the show.  We will be getting our liveblog on starting at 8am PDT (that’s 11am for you right-coasters) for the general keynote session.  We’ll also be liveblogging from SAP TechEd 09 Demo Jam at 8pm PDT on Tuesday.  The Demo Jam promises to be a great time, so plan to join us online after you put the kiddies to bed!

This is our first foray into liveblogging.  Hopefully it will go off without too many technical glitches.  We hope you’ll enjoy following the events with us!

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