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

IDoc Has Left The Building

SAP IDocs are a tried and true interface methodology.  But as with any interfacing technology the most brittle component is the connection between the two systems (in the case, SAP and the subsystem).  In scenarios where SAP is sending IDocs to a subsystem via the transactional RFC, one question is paramount:

How do you know when an Outbound IDoc has physically left SAP?

It’s a simple fact that if your subsystem never receives an IDoc from SAP, the subsystem will not be able to route or process the IDoc.   I have always gone by the notion that once the subsystem has successfully received the IDoc, the subsystem now has all the responsibility to process and route the IDoc, but before that time, SAP has the responsibility to ensure that the IDoc is fully dispatched.  The subsystem should have processes in place to determine if the IDoc has been received at the target system successfully or not.  In this blog I will focus on the handshake between SAP and the subsystem.  This will entail Outbound IDoc status and a couple of batch jobs that should be setup to ensure a better chance of a successful handoff between SAP and the subsystem.

[Read more...]

The Ergonomic User Interface

Every Monday morning I hop on a plane, arrive at my destination city, pick up a rental car, and drive to my client’s site.  The car rental company gives me a different make and model car every week.  And yet, somehow, I am successfully able to open the car, adjust the seat and mirrors, start the car, shift gears, and drive.  I can also operate the radio, air conditioning, heat, windshield wipers, and headlights.

Now, put me behind a keyboard in front of a computer application which I have never seen before. My user experience is all over the map – somewhere in the continuum between most excellent and very poor.  Some application user interfaces are extremely intuitive, well-designed and easy to navigate, logically follow the business process flow, and provide real meaningful help when needed.  Other application user interfaces are extremely difficult to navigate, are not intuitive, do not follow a logical business process flow, and offer little or no meaningful help. And sometimes in these difficult user interfaces, not only has the location of the steering wheel been moved to a totally unsuspecting location, but its appearance has been changed so that, even when I see it, I do not even recognize it as being the application’s steering wheel.

A well-engineered user interface is no accident.  It doesn’t just magically happen.  It must be woven into the fabric of the design and the code; and it should never be shoe-horned into the application as an after-thought.   It takes a lot of up front planning, designing, testing, functional effort and technical effort to produce a really good application user interface.  And yes, designing, building, testing, and implementing a good user interface for your application will extend the delivery time of whatever it is that you are building.

Why is a well-designed and ergonomic user interface so important?  You could have built the best application ever developed.  But if it is unusable, it will never get very far.   Countless hours are lost every day as thousands of frustrated users spend extra time and effort wrestling with poorly designed user interfaces, rather than focusing on their jobs.  And when the frustration levels reach a certain trigger point, the users will seek out and find alternative ways to perform their duties.

Here are a few examples of some very interesting user interface experiences that I have personally encountered.

[Read more...]

BD53 Doesn’t Play Well With Others

I recently posted a blog about how to implement field-level IDOC reduction for the HRMD_A message type.  In short, the standard SAP transaction to reduce IDOC segments and fields (transaction BD53) can’t be used because the field-level reduction is ignored by SAP.  My solution leveraged TVARV as a repository for the fields to clear.  Read the whole solution here. A colleague of mine was very quick to point out that instead of using TVARV as the method for controlling which fields are cleared, I should have continued to leverage transaction BD53 for the IDOC reduction maintenance and changed my code to look up field level reductions in table TBD24.

What a great idea!  Too bad I hate this suggestion… and it’s all SAP’s fault!!

[Read more...]

How To Implement Field-Level HRMD_A Reduction

I love ALE.  It is super-powerful and, once you get the hang of it, is a snap to configure.  Recently, I was setting up an HRMD_A interface for my client.  Everything was going smoothly until I ran into a requirement to filter out the social security number (PERID), birthdate (GBDAT), and gender (GESCH) for privacy reasons.  All of these fields are in segment E1P0002.  Initially, I thought that this requirement was easy enough to accomplish.  I just created a IDOC reduction in transaction BD53 and filtered out the three fields.  I soon found out that while entire segments were getting reduced from the IDOC as configured, the individually reduced fields were still showing up in the IDOC.  What’s going on?!?
[Read more...]

Changing The Function Interface of Web Service Enabled Functions

Today, I got an email from one of my co-workers at my client with a very good question.  This developer had created an ABAP function to return SAP data.  Then, he exposed this function as a web service. Due to changes in functional scope, he had to change the function interface.  After he made all his changes and unit tested the ABAP code, he was surprised to find that his web service was still adhering to the old function interface.  He tried deleting and recreating the web service, but ran in to problems.  He was stuck in a pickle and needed a little push in the right direction.

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

DataXstream Press Release – Xstream Connector from DataXstream Certified by SAP

Williamsburg, VA: February 20th 2009

Xstream Connector from DataXstream Certified by SAP
SAP has formally certified DataXstream’s Xstream Connector product and Cforia’s connector integration.  This is the culmination of extensive joint development by the two companies and provides customers with a standard, repeatable and fully supported mechanism to transfer data from SAP to Cforia’s application.

The Xstream Connector provides a packaged software solution that can be installed at a client site and have fully functional connectivity and data transfer established between an SAP system and Cforia in less than a day.  Delivered via the SAP AAK (Add-on Assembly Kit) the Xstream Connector uses standard SAP messaging and output control techniques to seamlessly move data from SAP to Cforia in near real-time.
The Xstream Connector contributes to the shortening of overall Cforia implementation timelines allowing SAP customers to rapidly reap the benefits of enhanced work flows focused on driving cash flow optimization.

About DataXstream, LLC
Since 1996 DataXstream has been providing world class integration and infrastructure consulting services to companies running SAP.  DataXstream specializes at integrating heterogeneous platform landscapes to deliver seamless business solutions.
In recent years the DataXstream portfolio has expanded to include software development and certification for SAP complimentary products.
DataXstream is a preferred vendor and referral partner for SAP.

About Cforia Software, Inc
Cforia Software, Inc. (Cash Flow Optimized, Real-time Information Access) develops solutions that enhance cash flow management.  Cforia’s software products extend the functionality of accounting systems like SAP, Oracle, PeopleSoft and JD Edwards.  Cforia’s customers are found in North America and Europe.

DataXstream Announces Virtual Integration Infrastructure at SAP® TechEd 2008 Las Vegas

Customers Can Integrate Now with Virtual Integration Infrastructure from DataXstream

LAS VEGAS, NV – Sept. 9, 2008

DataXstream today announced at SAP® TechEd 2008 Las Vegas availability of its Virtual Integration Infrastructure (VII): a powerful integration platform delivered as a utility service.  DataXstream VII provides simplicity and affordability by pairing a comprehensive hosted integration platform with DataXstream’s deep integration experience.

“This is a great opportunity for DataXstream to maximize the value we bring to customers,” said Tim Yates, DataXstream CEO.  “Our Virtual Integration Infrastructure allows us to implement full-functioned, end-to-end enterprise application integration (EAI) infrastructure in a matter of weeks.  With DataXstream VII we free customers from the burdens of implementing and managing integration scenarios.  We enable their IT resources to focus on activities that provide greatest business impact.”

The Virtual Integration Infrastructure (VII) by DataXstream is the world’s first offering in the burgeoning Middleware-As-A-Service (MAAS) market.  By leveraging the first full-functioned EAI platform available as a service, DataXstream delivers world-class integration capabilities at a fraction of the cost and time of a traditional implementation.  This type of utility based computing in the cloud is gaining momentum because it lowers development and support costs while meeting business requirements.    MAAS is especially suitable for organizations that would not like to maintain an in-house data movement and transformation infrastructure.

In addition to a world-class technical solution, the VII platform is supported by DataXstream’s deep integration expertise.  DataXstream integration specialists work with customers every step of the way—interface design, build, implementation, and support—to ensure integration scenarios not only fulfill the business needs for system integration, but do so in a cost-effective, robust, and secure manner.

“DataXstream VII scales with you,” said Craig Stasila, principal technical architect.  “Our support team monitors system usage and availability to ensure that you have the resources you need, when you need them.”

DataXstream’s utility pricing means you only pay for the resources you use–similar to your mobile telephone bill.  All inclusive pricing means an end to up-front software costs and maintenance fees, the overhead of server maintenance, hardware and operating system support, and the ever-increasing heating and cooling requirements of a modern IT infrastructure.  DataXstream VII offers a real cost savings over any alternatives.

SAP TechEd 2008 is SAP’s largest ecosystem education event of the year, which is being held Sept. 8-12. DataXstream is exhibiting at TechEd in booth 23.

About DataXstream, LLC
Since 1996 DataXstream has been providing world class integration and infrastructure consulting services to companies running SAP solutions.  DataXstream specializes at integrating heterogeneous platform landscapes to deliver seamless business solutions.

In recent years the DataXstream portfolio has expanded to include software development and integration of products complementary to SAP applications.

DataXstream is a participant in the SAP Referral program.

SAP and all SAP logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries.
All other product and service names mentioned are the trademarks of their respective companies.