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.
SAP Standard Customer Cross Reference For Inbound IDOC Processing
Converting External Customer Number To Internal Customer Number – SAP EDPAR Table
Have you ever had a project where you are converting a customer file into an SAP Sales Document IDOC (ex: ORDERS05) and the customer file contains their Internal Customer Number? So you need to determine what the SAP Customer Number will be on the IDOC. If you are not familiar with the SAP interface process you may hardcode the SAP Customer Number or create external tables in your third party mapping software to accomplish this conversion process. However, this involves customer specific logic or updating the tables with your SAP Customer Numbers and having a process to maintain this table as new SAP Customer Numbers are created. There is a much easier way to perform this conversion with no additional coding as it is a standard SAP utility.
Customer Conversion For IDOCS ORDERS05 and DELFOR02
This utility is available in the standard SAP package to convert External Customer Numbers to SAP Customer numbers (Sold-To, Ship-To, etc.) when processing inbound IDOCs (ex: ORDERS05, DELFOR02) from non-SAP systems. When working with data that will be imported into SAP via IDOC format the data usually contain your customers external sold-to and ship-to numbers and not the associated SAP customer numbers. Therefore, you would need to convert this External Customer Number to your internal SAP Customer Number. Instead of creating cross-reference tables or conversion routines in your third-party translation software you can populate the E1EDKA1-LIFNR field of the inbound IDOC with the External Customer Number and use transaction VOE4 to populate the EDPAR table. By properly doing this, the standard SAP function module will use the EDPAR table values to convert the External Customer Number to the SAP Customer number. The following instructions will explain how to populate the inbound IDOC and the EDPAR table.
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.
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.
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
