SAP and EDI: The key to production and automated ordering
EDI stands for Electronic Data Interchange. In SAP, EDI exchanges business application documents with an external partner’s system. EDI is the backbone of huge parts of the world economy. Every time you buy a packet of pasta, or a loaf of bread, EDI messages are sent flying through the supply chain to replace items to keep up with supply and demand.
Understanding EDI is crucial to getting the most out of your SAP system, particularly if you operate in the FMCG industry. In this blog post Robert MacDonald covers the most important aspects, including:
What is EDI?
Electronic Data Interchange (EDI) is the concept of exchanging data electronically. This specifically relates to sending business documents between trading partners.
EDI transmits an electronic form of conventional business documents, like a purchase order or invoice. Since the seventies, businesses have realised that there are economies of scale in using technology to do what it is good at, to allow people to get on with what they are good at. Repeatable tasks with minimised data errors have a real impact on the bottom line of any production business using SAP.
EDI does not specify a particular format or connection method. Data can be written in any format on any medium or sent over any protocol when both trading partners agree to use the same ones. There are practical conventions and industry standards, which vary by industry and by region.
EDI has a mailbox style of delivery. It is comparable to individual messages being sent and received by the different parties. Those messages usually represent a traditional business document, like a purchase order or an invoice.
EDI in the economy
“EDI offers considerable scope for cost-saving and improving competitiveness. It is a development which no business can afford to ignore.” – The Rt. Hon Lord Young of Graffham, Secretary of State for Trade and Industry. September 1988, The EDI Handbook, Mike Grifkins and David Hitchcock.Â
Predictions made on the game-changing potential of EDI have turned out to be correct. Every major supermarket in the UK mandates EDI communication. In other sectors discounts are offered for using EDI. As a result, it is impossible for producers to compete without it.
Manually processing orders and business paperwork is not feasible in 2020. The 1990s was the real growth period for EDI. Processes that are not already using EDI are being rapidly automated today.
Usage of EDI for SAP customers
Growing businesses hit a need to work with EDI sooner rather than later, and for many, that means setting up their ERP system to receive electronic purchase orders and send advanced shipment notifications and invoices back to customers.
For SAP customers, EDI messages can map into IDocs and posted directly into SAP ERP or S/4HANA. EDI is seen in the SAP world using third-party middleware. For example, VANs with SAP integrations, SAP’s own integration products (SAP Process Orchestration etc.) or SAP Cloud Platform integration. Additionally, even direct reading of flat files from the SAP application server is not uncommon.
Formats for EDI messages
Two trading partners agree on the EDI formats. Theoretically, any format can be agreed for EDI and they often are. However, there are standards often seen across an industry or a region.
Standard formats describe the physical structure of the messages that are transmitted. The computer then reads them at either end. Subsequently, they are further mapped to the current data structure being used by the systems at each trading partner.
TRADACOMS
TRADACOMS was an early format for EDI, that hasn’t been developed since 1995 and was formally deprecated by GS1 UK in July 2017. It remains widely used in the UK retail sector, but in recent years several major retailers have been pushing their suppliers to switch to a newer standard.
EDIFACT
UN/EDIFACT is the most widely used standard worldwide. Industry-specific subsets are used and as a result, it is not used in its purest form. GS1 offers EANCOM which is a subset of EDIFACT, focusing on messages used in business applications for the physical flow of goods.
EDIFACT stands for EDI for Administration Commerce and Transport. GS1 is a global organisation that creates and maintains standards for business communication. They are the standard body behind retail barcodes that we all see and use every day, as well as defining standards for EDI communication.
This is the standard example EDIFACT document for an EDI purchase order.
The first and last line mark the start and the end of the interchange. The 001934-figure checked to ensure the complete interchange is there, and that the end matches the start. ORDERS is the EDIFACT code for a purchase order, and the information in the middle contains the details you would expect to see on a purchase order in a computer-readable format.
EDIFACT is the standard worldwide, on the other hand TRADACOMS maintains an important position in the UK. What about North America? In the US the most common standard is ANSI X12. This is similar to EDIFACT in appearance but has additional message identifications for healthcare data. X12 is available to implement HIPPA-compliant exchange of healthcare data with appropriate encryption and identification in place.
Â
Comparison of formats for common transactional documents
All of the formats used have the ability to represent relevant business documents, at least those needed for the specific business interactions that are happening between the trading partners. Many documents are specialist, but some common for retail and FMCG manufacturing in the UK are as follows.
| Business Document | EANCOM (UN/EDIFACT) Standard | TRADACOMS Transaction | ASC X12 |
| Purchase Order | ORDERS | ORDHDR THE ORDER FILE | 850 |
| Purchase Order Acknowledgement | ORDRSP | ACKHDR THE ACKNOWLEDGEMENT OF ORDER FILE | 855 |
| Advanced Shipping Notice (ASN) or Despatch Advice Notice | DESADV | DELHDR THE DELIVERY NOTIFICATON FILE | 856 |
| Invoice | INVOIC | INVFIL THE INVOICE FILE | 810 |
It is not only transaction data that can be exchanged with EDI. There are also master data standards, for example to exchange pricing or product information between suppliers and customers.
Â
This is all a bit old-fashioned, what is wrong with XML?
The older EDI formats were optimised for small file size, with single-character delimiters. Specifically, the symbols you see between segments above, and the + symbols to separate fields. Some fields are fixed width and others rely on the segment and field separators to be read.
Since the modern internet has grown in popularity, XML has become the new format of choice for many communications. JSON is another modern alternative that retains a precise computer-readable structure. It is designed to be readable by humans. In other words – it is more user friendly.
Electronic Data Interchange as a concept can use any format, so hypothetically you could make your own XML or JSON format like with any other API or interface. In practice, there are standards for XML in EDI such as cXML (commercial XML) and GS1 XML.
XML standards are the fastest growing and most actively developed in the EDI world. For example, GS1 have stated that they will continue to support their EANCOM (EDIFACT) standard for as long as necessary and will respond to customer demand for changes, but they will focus new development in GS1 XML.
Communication methods
So, you have a message format agreed with the trading partner, how do physically send it?
Several protocols are in widespread use for EDI to work over the internet. SFTP is commonly seen with the messages placed onto a remote SFTP server or made available for download. AS2 is a protocol specific to EDI which works over HTTPS, and the newer AS3 and AS4 protocols make use of modern SOAP message packaging.
The communication method used for EDI must be reliable, due to the business-critical nature of the sent messages. When considering communication protocol, a technical indication the messaged has been received is potentially important. Additionally, a functional indication that the business transaction has been accepted would be a response message. This would take the form of a Purchase Order Acknowledgement (ORDRSP or 855 in EANCOM or ASC X12, respectively).
| Communication Method | Underlying Technologies | Standard Since | Comments |
| AS2 (Applicability Statement 2) | HTTPS | 2002 | Â |
| AS4 (Applicability Statement 4) | HTTPS with SOAP envelopes and X.509 security | 2013 | Current standard |
| X.400 | Can run over the internet, or separately | 1984 | Commonly used. Phasing out. |
| Value Added Networks (VAN) | Historically separate networks, latterly offers services over the internet | Pre-internet | Current standard. Still adding value in the internet era with mapping and converting of diverse standards for customers. |
| SSH File Transfer Protocol (SFTP) | TCP/IP (Internet) | 1997, latest version 2006 | Current standard |
| FTP | TCP/IP (Internet) | Historical | Â |
Â
Value Added Networks (VANs)
EDI has used Value Added Networks (VANs) since the seventies. They were essential before the modern internet facilitated modern communication methods on HTTP(S) and FTP connections.
The internet could have meant the end for the VANs, but they have embraced the internet age. VANs now operate entirely or partially on the internet. They provide value by allowing their customers to support trading partners with the huge variety of different message formats and communication methods that exist.
Modern VANs will usually provide a standard API for common ERP packages, for example into SAP ERP or SAP S/4HANA, with or without the need for middleware. Use of a VAN means an organisation has only one connection and standard to maintain for all their trading partners.
VANs advertise how many major customers they have on their networks for out-of-the box integration. Finding a VAN that covers as many customers as possible is very beneficial for a supplier, as it reduces the amount of VANs needed.
VANs offer monitoring services so that their customers can see that their messages are getting through. They also offer service-level agreements to ensure availability for trading partners to send messages at any time, and queues for when an on-premises ERP system is down for maintenance.
VANs will charge a fee for their services, often charged for message or data throughput. Many organisations use a VAN for many of their customers to minimise integration efforts, whilst investing in a direct connection to high-volume customers to minimise VAN costs.
SAP EDI software
IDoc or Intermediate Document posts business documents (invoices, purchase orders) into SAP from an EDI. IDoc is SAP’s message format for EDI messages.
All EDI message formats can be converted to IDoc. VAN or middleware like SAP Process Integration, SAP Process Orchestration, or SAP Cloud Platform Integration for example, do this. Posting IDocs directly into SAP ERP or SAP S/4HANA without middleware is possible. Also, they need to be supplied in a suitable format by the VAN.
SAP EDI at Absoft
At Absoft, for our SAP Managed Service customers in manufacturing, food, and beverage, run critical 24/7 EDI interfaces. We do this with and without SAP middleware and VAN networks. Read more about optimal operations for EDI in SAP, including end-to-end monitoring that reaches far outside the SAP applications, here.Â
When building new interfaces, Absoft specialises in resilient interfaces without complex and expensive middleware, by making expert use of the application server in ERP and S/4 and our expert SAP operations function.
Article by:Â Robert MacDonald, Innovation and Technology Manager
Bob is responsible for bringing the latest SAP technology to Absoft and its customers across industry sectors. From a technical background, he specialises in identifying efficiencies in running SAP through automation, monitoring and optimisation. He has worked on supporting, implementing and upgrading SAP for over 10 years, and is now launching the newest innovations in automation.
