Skip to Content

Five Things You Will Never Hear From EDI Lovers

I used to loathe EDI (electronic data interchange).  Its promise to totally automate the  industrial supply chain with “hands free” computer-to-computer  interchange of key business documents seemed to threaten the fundamental existence of b2b2dot0.  We had a bit of drama at  b2b2dot0 last week that…once again…reinforced the fact that while  hype may make our job difficult, reality presents our opportunities. 

What happened last week? 

Our  service was accused of committing THE cardinal sin of a  Software-as-a-Service provider.  One of our client’s customers filed a  support ticket telling us that she couldn’t find the ETA (estimated time  of arrival) of a part number that she was 100% certain she had placed  an order for. 

Not good! 

Our CTO, Adrian Zehnder, jumped  in to do the detective work.  Since we don’t store ANY business data on  our service (we retrieve it in real time from SAP whenever we need it),  we knew we couldn’t have lost it.  That left only one  other explanation, the order wasn’t in SAP.  Further research confirmed  that this particular order was placed via EDI and the status check was  performed before it had a chance to get posted to SAP.  The customer’s  expectations for real time status, literally minutes after having submitted the order, clashed with the batch nature of EDI transactions…and that got me to thinking.  What other “dirty little secrets” does EDI have?

Here are my top five.

  1. EDI isn’t collaborative, it’s tyrannical – Walmart doesn’t “suggest” that their suppliers “should consider” using EDI.  They must…at their expense, and with penalties if they get it wrong.  Here is an entire website devoted to helping you deal with the “daunting task” of working with  Walmart.  Walmart accrues all of the benefits while their suppliers kill  each other to bear the costs.  How exactly do we expect “totalitarian  communication channels” to support “collaborative supply chains”?
  2. EDI isn’t electronic, it’s manual – Every supplier I talk to  tells me that close to 100% of the EDI orders they receive have to be  reviewed by human beings.  In fact, one chip manufacturer told me that   there were 90+ ways that each inbound order could be defective…bad  product data, new ship-to location, unrealistic delivery date, bad  pricing info, etc., etc. etc.!.  
  3. EDI isn’t real time, it’s batch – (it has to be because of all of the manual interventions required…see #2 above).  Batch processing is totally doomed in our Blackberry, Twitter obsessed society.  Witness our support  incident from last week where our desk tapping distributor is up in arms  when he can’t get the status of an EDI order that he just placed!  
  4. “EDI standards” is an oxymoron – The joke is that if a  standard doesn’t work for you create a new one.  Basically, if you’re a  supplier, no matter how you look at it, each integration with a new  customer is a new adventure.  Also, the standards, as incomplete (or  over-complete) as they are, don’t even attempt to deal with  “non-document oriented” business transactions.  Today’s purchasing  managers want to know inventory positions or available-to-promise dates,  current pricing, anticipated shipping charges, etc.  Those real time  calculations will never be available through EDI, which leads me to my  fifth, and probably most powerful dirty little secret of the EDI  industry…
  5. EDI isn’t for amateurs, it’s for professionals – There is a  HUGE self-sustaining industry that has been built around selling EDI  software, managed services, consulting, programming etc.  It’s not going  away any time soon, even though in most supply chains, the benefits are  elusive at best.  In fact, if you’re an EDI programmer at a mid-level  supplier, you’ve probably created a tenured position for yourself.  What you do is so complicated and volatile,  that your management can’t afford to let you go.  Congratulations!

In the end, I actually respect EDI and clearly believe it’s an  important industry initiative.  I simply believe that it shouldn’t be  portrayed as the “be-all and end-all” for the supply chain’s  communication challenges.  I also believe that the internet can add way  more value to the EDI community than a cheap alternative to proprietary  value-added-networks (VANS), but that’s another rant that I won’t get  into today 🙂

For today, I’ll simply leave you with one thought:

In  spite of what everyone around you is telling you, maybe you should  listen to your instincts when they suggest that the complicated  solutions may not be real solutions after all.


You must be Logged on to comment or reply to a post.
  • Hi Sam
    You might shown all your emotional here.
    the special character is a grey area for all software products.
    How SAP has defining the new rules for many business customers.Nowadays Even every product companies started to instruct their customers DO THIS and NOT DO THIS.
    Accept GOOD ,escalate the BAD and ADHERE and understand others limitations for smooth operations.
    EDI is also one of the renowned middle application around the globe.


  • Hello Sam

    Being responsible for SAP-PI and EDI Implementation/Support at Lindt & Sprüngli (International) AG here are my replies to your “Top Fives”:

    (1) “EDI isn’t collaborative, it’s tyrannical”
    Asda UK (Walmart) is only one out of many customers of Lindt UK who demanded for EDI trading. Given the high volumes of purchase orders I am sure that Lindt UK is more than happy that most of its customers order already via EDI. In return, whenever they save an invoices in SAP they know it will be immediately transferred to the customer via EDI.

    Talking about collaboration one big customer of Lindt UK provides them once a week with their sales data and approximate sales forcast (PPRHDR, TRADACOMS93). These data help Lindt UK in their demand forcasting.

    Talking about tyranny another big customer “urged” Lindt UK to send twice a week a PRICAT message containing the basic product prize and packsize (consumer units per case). As a result the debit notes sent per e-mail by the customer dropped substantially which means that more invoices will be paid in due time.

    (2) “EDI isn’t electronic, it’s manual”
    The data information exchange between Lindt CH and its logistics partner in Germany (for the Export business) is almost 100% based on EDI. In contrast, other Lindt companies (<> CH) delivering stock transfers to the warehouse are not yet integrated and therefore cause lot of manual work at the the goods receipt (GR) and GR posting.

    A big customer of Lindt CH sends most but not all of its purchase orders via EDI (for unknown reasons). The manually created sales orders are error-prone because sometimes they are missing essential references (e.g. PO item numbers) due to additional changes transmitted via phone/fax.

    (3) “EDI isn’t real time, it’s batch”
    With respect to EDI architecture at Lindt this statement is nonsense:
    “EDI at Lindt is real time in both directions!”

    We have a very simple EDI setup looking like this:
    SAP R/3 <-> SAP-PI (with EDI Converter AddOn) <-> ODEX <-> Clearing Center (Multilateral, CH)

    Every outbound message (e.g. DESADV, INVOIC) arrives at the clearing center within 60-120 seconds.
    Every inbound message (e.g. ORDERS) arrives at SAP R/3 within 60-120 seconds.
    Our clearing centers forward messages in both directions immediately.

    (4) “EDI standards is an oxymoron”
    Here I have to agree – partially.
    For all TRADACOMS customers of Lindt UK we have a single ORDHDR and a single INVFIL mapping based on the TRADACOMS 1993 standard.
    For every EDIFACT/EANCOM customer (not only Lindt UK, but other Lindt companies as well) we have a different EDIFACT/EANCOM ORDERS mapping.

    At Lindt CH we use a billing service (Six Paynet) for sending and receiving electronic invoices. As a result we do not need any mappings here but can forward e.g. the inbound invoices (as IDocs) immediately to the R/3 system.

    (5) “EDI isn’t for amateurs, it’s for professionals”
    Correct. But do you have amateurs doing the Controlling at b2b2dot0???
    The great thing about EDI is that you need to have high affinity to both the technical stuff and the business processes. Otherwise you will not be able to translate business documents into EDI messages and vice versa.

    When I started at Lindt 3 years ago I had hardly any knowledge about IDocs, SAP-PI, XML/XSLT and virtually no knowledge about EDI. It took me about 18 months to come to terms with all topics. In the meantime all the Lindt companies for which I have done EDI implementations have grasped what can be done via EDI and how fast we can implement it using our middleware SAP-PI.
    Nowadays I am overwhelmed with requests by all the Lindt companies for new EDI implementations.

    However, for me the greatest benefit of EDI (besides cost saving, process acceleration, etc.) is “error detection” in master data and processes.
    Example 1:
    Goods Receipt IDocs (DESADV sent back by warehouse after receiving stock transfers) fail if the item in the stock transfer purchase order does not have a storage location => Error cause: assignment of default storage location in the material master data.

    Example 2: We changed the processing of EDI ORDERS messages that items could only be ordered by the EAN and no longer by their SAP material number. The ORDERS IDocs failed if the EAN was assigned accidentially to multiple SAP material => Error cause: Duplicated EAN in material master data

    I do not want to keep quiet about the big efforts for the initial EDI implementations. However, the more EDI interfaces you have in place the faster you can implement new ones by reusing or Copy&Paste.

    Best Regards,

    • Hi Uwe,
      Thank you for your thoughtful and detail response and for being an able representative of your fellow EDI lovers!  There is no doubt that the Consumer Products vertical is one of the most mature EDI industries and derives incredible business and process value everyday.  Your company in particular seems very advanced in it’s implementation.  Frankly, I would hope that to be true after the enormous investments that have been made.

      I especially like your point about the value of EDI in “error detection”, and would like to challenge it if you don’t mind.  After the error is detected, who is notified and who has the responsibility for fixing it…the sender or the receiver?  I’m especially curious about your second scenario…the EDI Order scenario which is near and dear to my heart.  In a “web order” scenario, bad data is edited at the point of entry, not upon receipt of the message.  This puts the responsibility on the sender to correct his data immediately.  Assuming that there was an agreement that that was going to occur in advance, that is a collaborative approach.  In the EDI order scenario, I see customer service representatives correcting the orders on behalf of their clients (as a service to them) which never really cleans up the data.

      I have focused my comments on customer/supplier interactions.  I think the EDI story is much different when discussing cross functional communications.


      • Hello Sam

        Please excuse for the delay in my response but I had to catch up two forthcoming Going-Live sessions (Invoice related EDI interface for Lindt Sweden and “the full monty” for a customer of Lindt AU [Fully Monty = ORDERS, CONTRL, ORDRSP, DESADV, INVOIC]).

        In case of the “EDI Orders scenario” error correction depends on who is making the mistake(s).
        Before Going-Live with EDI ordering our customer service has to ensure that the ordering customer has the correct EANs (or, to be more precise, GTINs) for all sold products.
        On the other hand, the customer has to provide us with a complete list of all their stores and warehouses, i.e. the corresponding GLNs.

        If we sell new products to an existing EDI customer the EDI relevant product data have to be forwarded to the customer BEFORE the first EDI orders for these products arrive.
        If a customer has a new store/warehouse we are always informed IN ADVANCE so that our customer service can create a new debitor with the GLN.

        I regard this as true collaboration. Both partners are aware that data (products vs. stores/warehouses) have to be exchanged in advance before using them in the EDI process itself.

        Here is another example where EDI proves its capability for “error detection”. Regularly we receive inbound invoices from suppliers for which the (INVOIC) IDoc processing fails due to wrong or missing references to our original purchase order.
        Why are these essential references are missing?
        Apparently the manually (i.e. fax, mail, phone) transmitted purchase orders miss these references (because the people are not aware of their importance) or the supplier makes mistakes when creating the sales order in their system.

        My conclusion out of this is that the manual ordering process is – by default – error-prone. Since most of our suppliers are capable of EDI we should switch from manual to EDI ordering thereby eliminating a major source of errors in the entire process.

        Taking this example one step further such suppliers are usually able to send DESADV messages as well. We have a current project with a big supplier where we use the DESADV (including the external SSCC of the supplier) to create an inbound delivery. When the goods arrive at the warehouse the people just scan the pallets and forward them directly to the storage locations with relabelling them with Lindt-internal SSCC. If the DESADV contains the correct references (the purchase order data which we sent via EDI) then the system can automatically post the goods receipt (GR) onto the purchase orders.

        I could continue with many more examples but I would like stress another important feature of EDI:
        EDI is fun because you are always talking to a professional at the other end of the interface (otherwise that person would not work in the EDI business). An extreme example was one customer of Lindt UK who fulfilled all prerequisites for quick implementation of EDI trading:
        – the customer had the correct GTINs of our products
        – Lindt UK had maintained all stores/warehouses of this customer in SAP-SD
        – the customer had full control over their flexible EDI environment (as we do)

        (1) First e-mail contact on Monday. Establishment of the EDI connection (with the help of our excellent clearing center Multilateral) on the same day.
        (2) Quick and proficient testing of ORDERS and INVOIC by both Lindt UK and the customer
        (3) Going-Live with EDI ordering and invoicing on Tuesday, i.e. the entire implementation was done in 2 days

        Finally, when it comes to troubleshooting I always tell my colleagues at Lindt:
        First check every possibility where WE (= Lindt) could have made mistake. If we cannot blame ourselves for the error THEN the last resort is to contact the EDI partner.
        There are very few situations in which I can immediately spot the error on the other side.

        Best Regards, 

        • Error correction:
          “When the goods arrive at the warehouse the people just scan the pallets and forward them directly to the storage locations WITHOUT relabelling them with Lindt-internal SSCC.”
        • Hi Uwe,
          You are describing such a nice place (and nice way) of working.  I’m sure you will be receiving many applications for employment 🙂

          You are an excellent advocate for the benefits of electronic communication between trading partners..of which phone, fax and email are clearly not.

          I would like to point out (in a self serving manner) that a web channel provides all of the same benefits that you claim for EDI.  It has the added advantage that the less sophisticated members of the supply chain can easily participate as well.

          Thanks again for your sharing your experiences and insights.  I know that have proven quite valuable to me and I hope for some of the other readers as well.


          • Hello Sam

            To make you even more jealous:
            Lindt is indeed an exciting industrial environement, you will find our delicious chocolates and pralines in every coffee corner of the Lindt premises and my office is just a stone’s throw away from the “beaches” at Kilchberg (Lake of Zürich) where I daily go for swimming during summer times.

            I fully agree with you that (classic) EDI is not the sole solution for exchanging business documents. Web channels like those offered by b2b2dot0 are particularly suited for companies which cannot afford their own EDI environment.
            However, the things happening behind the scene of your web channel (e.g. forwarding the entered data as business document into an integrated SAP system) is nothing else but EDI.

            In the project for Lindt Sweden we receive inbound invoices as tab-delimited files and we send XML files (Supplier master data & invoice receipt) as XML = EDI.

            To call an integration EDI there is no need to use message types like EDIFACT/EANCOM, TRADACOMS,  or ANSI.X12 although I clearly prefer to use these highly structured message types. Using a brillant (freeware !!!) tool like EDI Notepad ( makes reading such message a piece of cake.

            Lindt CH had had EDI already in place a long time before I joined the company. However, 3 years ago Lindt CH decided to make an investment in EDI (by employing me and by using SAP-PI as middleware). Since then the EDI business has “exploded” (in terms increasing number of messages sent and received) and I have no doubt that this decision has generated a positive ROI (in terms of cost savings) from the first year on. These cost savings to never decrease but just pile up with every new integration.

            One major question is: Should we make EDI in-house or use an EDI service provider (like b2b2dot0)? There is no general answer to this question but it clearly depends on the company. In case of Lindt I would clearly say that the in-house solution is more suitable for the rather decentralized organization of the Lindt companies.

            Finally (once again), on my e-mails you will find the following job description (or title):
            “Senior SAP-PI Consultant & EDI Operations”

            However, my understanding of my position is a different one: I am an “Information Gatekeeper” and “Knowledge Broker”
            When a Lindt company wants to implement a new interface which is already in place at many other Lindt companies then I can reuse and share my experience and knowledge with this Lindt company trying to avoid the mistakes we made in the past and implement a good solution based on our “lessons learnt”.


            PS: EDI = Fun !!!

  • I received this message offline and thought it was worth sharing.  I like the airline reservation analogy.  They get the fact that “non-professionals” want to buy airline tickets.

    Thanks Michael for your comments.


    Remember when airlines first introduced the web-bookings? In the beginning, this new tool was mainly used by travel agents; it was way too complicated for end customers, who were also not used using the internet. A similar situation we see currently in the EDI community; providing efficient tools for Community Enablement goes beyond EDI and technical standards. Soon, noone will care about the standard (like we dont care about http/s or xml or web services when booking a flight), since it will be just encapsulated. Intelligent appilications help smoothening the business transactions. As always, intelligence is never with a standard but with apps addressing the business issue. IMHO the EDI community is at the beginning of a self-enablement process – similar to the travel agents after introduction of web-bookings. I agree with your #5, however, it becomes less and less relevant. Warm greetings from Switzerland, Michael.