SAP ABAP/PI Developer Position

Location: US-Multiple Locations

DataXstream, an SAP focused organization, has experienced significant growth over the last 2 years.  We are currently seeking an SAP ABAP/PI Developer to add to the team.  This role will be critical and will include a diverse set of responsibilities over multiple areas of the business:

Technical Qualifications:

  • 7+ years of experience in ABAP/PI/XI Programming is required
  • Experience with EDI strategy and tools
  • Understanding of Object Oriented concepts
  • Experience with Data Dictionary, Function Modules (Remote Enabled), BAPIs, Web Services
  • Experience creating/modifying Adobe Forms
  • Proficiency with ALE/IDocs including error handling is desirable
  • Experience working with SAP ECC 6.0
  • Programming experience in various modules – MM, SD, FI
  • Work will primarily be remote, but could be potential for periodic travel to client sites

Additional Qualifications:

  • US citizens and those authorized to work in the US are encouraged to apply. We are unable to sponsor H1b candidates at this time.
  • Sharp, energetic consultants with an understanding of business processes
  • Self-starter
  • Ability to work both individually and as part of a team
  1. (required)
  2. (required)
  3. (valid email required)
  4. (required)
  5. (required)
  6. (required)
  7. (required)
  8. (required)
  9. (required)
  10. Captcha
  11. *By submitting this form you are agreeing to receive periodic communications from DataXstream. DataXstream will not share, sell or provide any of said information to a third-party for any reason. You can unsubscribe at any time by following the unsubscribe link at the bottom of all emails or sending an email to with the subject line “unsubscribe”.

cforms contact form by delicious:days


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 Data Migration – The Data Migration Plan (Part 2)

If you are responsible for the success of data migration, you will want to build a detailed plan that will walk you through all of the three phases of data migration: pre-data migration preparation, the data migration itself, and post-data migration cleanup.  I like my data migration plan to contain detailed steps that ensure that I don’t forget anything.  Each step lists a specific named responsible person along with their area of responsibility and contact information.  Unless I am responsible for executing the task myself, I prefer the named person to be a client employee (i.e. the business owner of the process) rather than a project consultant.    This is where the responsibility should be, and it requires that the business process owners actually participate in the activity rather than sit on the sidelines and watch.

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

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

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

Changing SAP IDOCs Status In Mass / Mass Deletion Of IDOCs

Mass Change of SAP IDOC Status

From time to time it becomes necessary to change the status of SAP IDOCs in SAP. The most common scenario is the requirement to mark SAP IDOCs for deletion. There is no good way to mass mark IDOCs for deletion via the standard IDOC processing transaction BD87. However there is a program that will let you change status.


CAUTION: This program should be used with great care and consideration. Improper use of this program can result in data consistency issues. Make sure you know what you are deleting, why you are deleting it, and what is required to correctly update you system after deleting.

[Read more...]

Are You Managing Your Change Pointers Properly Part 5 – Going Forward

In my last post, I discussed a collaborative effort with functional business owners to devise and execute a proper cleanup plan.  I also discussed a functional review of the configuration to make sure that change pointers are being created only when needed.

So now that you have achieved control over your change pointer data, how do you make sure that it does not go out of control again?

[Read more...]