Simplify EDI Challenges with Aayu Technologies: MFT and EDI Solutions

Electronic Data Interchange (EDI) is now an integral part of any business, whether online or offline. Unfortunately, despite its maturity of nearly 70 years, EDI remains cryptic, un-intuitive and downright challenging to a majority of the masses - and that is fine, because EDI is indeed complex:

The term EDI itself is used hazily to describe two different “levels” of “granularity” in B2B document exchange; transmission scope (EDIINT) and content scope (the “EDI” family of document types, such as X12 and EDIFACT). If you fail to properly identify which “level” your partner or vendor (or EDI provider) is talking about, your EDI integration could very easily end up either crippled or overwhelming.
EDI, in its content-scoped meaning, is a very compact form of exchanging common business documents - under a schema agreed upon by the sender and the receiver. Due to this compactness and lack of a visible structure (unlike JSON, XML etc.), EDI documents are often not human-readable or easily understandable. This means that specialized software are required for parsing, generating, viewing and manipulating EDI files - and this adds another layer of complexity (and cost) to the already-complex workflow of the business.

Luckily, these EDI challenges can be easily addressed by means of a well-designed toolkit and workflow which could tightly integrate with your business systems. Once it is in place and functional, you can literally forget about it and continue with business as usual - no more EDI challenges to ruin your day.

We at Aayu Technologies offer such a comprehensive suite of EDI products; the MFT Gateway, MFTG, which handles EDI transmissions over AS2 and SFTP protocols, and the EDI Generator, EDIG, which handles EDI content.

When it comes to tackling EDI challenges in domain-specific workflows such as retail (PO, invoice, ASN, etc.) and shipping (load tender, LT response, invoice, etc.), these two gateways complement each other. You may think of it like package delivery; MFTG (the delivery service) will simply dispatch the package handed over to it (from vendor to consumer), and EDIG (the consumer) will know how to make sense of and use the delivered item. Additionally, because they can operate independently as well, they offer even more possibilities;

MFTG can transmit literally anything (even a videoclip or a regulatory submission), and EDIG can process literally any EDI document (as long as the specification or schema is available) - even including generic documents that are originating or being exchanged outside of MFTG. But of course, the real power comes in when the two platforms operate in unison.

Let’s assume you are supplying goods to Walmart, which involves a typical set of EDI challenges:

WM sends you a PO (purchase order; X12 850) in EDI X12 format, outlining the items and quantities that it wishes to purchase from you. For this, WM expects that you host an AS2 server (endpoint) in the public internet to which WM can connect and upload the PO. When done, your AS2 server will decode the AS2 envelope and expose the PO to you, as a file.
You read the PO. Unless you are an X12 wizard, you would have to utilize an X12 viewer (interpreter) software to see it in a legible format.
You consult with your production or warehousing, to determine which parts of the PO can be fulfilled/delivered on time.
You compose a PO ACK (acknowledgement; X12 855) including the deliverable item details. This is even more challenging than step 2, because you have to adhere to X12 standard and also to a handful of additional requirements and constraints imposed by WM’s X12 855 specification.
You send the PO ACK to WM, over AS2. For this you need an AS2 client to envelope the PO ACK into an AS2 message, and upload it to WM’s AS2 server.
You prepare the shipment of goods.
You compose an ASN (ship notice; X12 856) to WM; including details of shipment structure, markings/identifiers, and delivery details. Similar to step 4 but much more challenging from EDI perspective - because of the hierarchical nature of the shipment structure, and levels of nested detail.
You send the ASN to WM, similar to step 5.
After the shipment is dispatched, you prepare an INV invoice, (X12 810) with details of goods sold, pricing, due date, taxes, discounts, etc. EDI-level complexity lies somewhere between the PO ACK and the ASN.
You send the INV to WM, similar to step 5.

While the above may look like a formidable EDI challenge, it becomes very simple and straightforward with the Aayu workflow in place!

Going with the same numbering,

Automated! MFTG will accept all inbound docs, including WM POs, and automatically forward copies of them to EDIG - and also to any other destinations as you prefer.
Simplified! EDIG has an intuitive, paper-like PO viewer where you can read or print the PO in its natural form.
Manual step. (If you have set up an integration with your supply chain management system, you can even automate this!)
Simplified! EDIG allows you to easily generate the PO ACK from the original PO, make any adjustments using an intuitive editor (right off your browser!), and submit it to WM. EDIG will automatically convert it into X12 format compatible with WM systems, and even run a validation cycle to ensure that the whole document is in good shape.
Automated! EDIG will hand-over the file to MFTG, which will automatically envelope and transmit it to WM.
Manual step.
Simplified! EDIG also allows you to easily generate an ASN from the original PO, populate it using an online editor, and submit it to WM - automatically converted and validated, just like the PO ACK.
Automated! Just like step 5.
Simplified! Much like in steps 4 and 7; generate, fine-tune, compose, validate and send your INV out.
Automated! Just like steps 5 and 8.

This is just one EDI challenge that Aayu’s MFTG-EDIG combo can solve on your behalf. With the ability to connect with any AS2 system and converse with any X12-based business partner, the Aayu solution stack will simplify and streamline your business workflow like never before.