The Generations of SAP EDI

[Kevin England]

When SAP first burst onto the scene in the USA in the 1990s, Europeans consultants flocked to America to work on projects with early adopters of the software, such as Georgia Pacific and Colgate-Palmolive.  Billing out at $200+ per hour, these Europeans were the only people with any experience in the product, the Europeans having adopted this German software way ahead of the Americans.  Conference rooms filled with ABAP programmers and functional consultants speaking English with Dutch, French, and Australian accents.  A project needed a disparate staff, someone who understood the sales and distribution (SD) module, one who knew plant maintenance (PM), yet another who understood production planning (PP), each of which has its own complex set of rules to map business requirements into the system.

Americans soon gained their own SAP experience having worked on these projects side-by-side with the Europeans.  Many employees jumped ship, opting to join the legions of contractors who were making $100-$200 per hour working as configuration experts, basis administrators, and ABAP programmers.  Making a salary somewhat in the range of a professional tennis player, the newly-rich bought houses, picked up the tab at upscale restaurants, spent cash on cigars and martinis until the cigar bars were run out of business by no smoking regulations.

As rare were these skills, even more rare were those SAP consultants who knew how connect the SAP system to EDI translators, the document translation and transfer system by which different companies exchange transactional documents using a common format.

Gentran was one of the EDI subsystems.  Sterling Software Gentran is still around, having been bought by IBM.  It is one of the most widely sold EDI translators and works well with SAP.

Computer programmers and architects now talk about service-oriented architecture, Java Spring beans and Hibernate, Ruby, Python, and mobile app development.  This is what interests them.  An EDI flat file coming from what at first glance appears to be a mainframe would put them to sleep with boredom.  But the old-fashioned EDI technology is still operating at full bore, having proven itself as a reliable system with which to deliver the enormous amounts of transactional business documents generated by the largest corporations.

What is EDI?  EDI is a transactional document sent over private networks (It does not usually use the Internet.) from one company to another.  These are designed based upon an agreed set of standards, which in the USA is ANSI X12 for the most part.  Using EDI you can send an advance ship notice (EDI document 856), invoice (819), sales order (850), update prices (879), request a quote (840), and more.  In this way, big companies connect their computers without having to sit down and program some kind of interface together.  It was loosely coupled before the term “loosely coupled” was developed.  

SAP supports EDI through something called ALE (application layer interface). ALE was supposed to be a way for one SAP data system to send data to another, but its main function is EDI.  When you create a shipping document in SAP, the SD module copies that data into a table called an IDOC.  The IDOC document has the same logical structure as the EDI document.  There are the header and detail lines, although the EDI document contains totals and subtotals as well, so that one can verify that it is complete and correct. 

This system is highly adaptable to differing customer requirements. You can add your own logic to the SAP ABAP code that populates the IDOC.  These are called CMODS (customer modifications).  You can change the mapping from the IDOC to the EDI translator.  You would do either of these if: (a) you need a data field which is not in the IDOC already or (b) you are creating a brand new EDI message that does not already exist in SAP.

Consultants used to spend months figuring out how to map SAP data fields to IDOC data fields and from there to the EDI translator.  That is not necessary anymore. All of that information is well-documented now.  You can look it up on the Internet. 

As old as it is, who is to say whether EDI will keeps its position in the long run or be replaced by some kind of startup-dot-com app run from a cell phone.  The old system is in place; it works; it’s dependable.  Why would you want to take that apart?

The Europeans have gone home now, billing rates have fallen.  SAP is available on the cloud.  Consulting firms have figured out how to install the product and do so with minimal disruption to the business, less risk, and in less time.

Much has changed in the 15 years since over-confident Andersen Consulting consultants, run amok, decided to modify the core code of SAP (Never do that.) driving the pharmaceutical company FoxMeyer into bankruptcy when the system fell apart at launch, unable to take orders, shutting down the business–permanently.  Whirlpool too found itself in the embarrassing spotlight when its brand new SAP system and its problems were documented in The Wall Street Journal.  Another SAP customer, Owens Corning fell into and then emerged from bankruptcy like FoxMeyer.  Their problems had nothing to do with SAP; they were driven into bankruptcy by asbestos litigation, whose army of litigants were encouraged to file suit by personal injury attorneys, a legal mess that is still churning away, with no end in sight.

If your company can’t “speak EDI” then you run the risk of being left out of the loop for participating in valuable and profitable inter-company opportunities. Download the free Idhasoft eBook, ”Streamlining Electronic Data Interchange  Design and Implementation.”