Problem: Required document types not supported

What is the problem?

You may require more document types to be returned than your trading partner can produce - or vice-versa.

For example, the customer has one computer system for receipting stock, so requires Delivery Notes of some kind, and another system for processing Invoices. The supplier may be able to return Invoices but cannot return a suitable Delivery Note. Another example, of an increasingly common situation, is that the customer wants specific Order Status responses, but the supplier’s ERP system is very limited in what information it can produce, and when.

What solutions are there to this problem?

There are two solutions, which should both be available at reasonable prices from your EDI service provider, as well as the ordinary electronic integrations.

1. The EDI service provider generates the “missing” document type(s) out of another document that the constrained trading partner can provide.

Generating a document (such as a Delivery Note or an Order Confirmation) from another document is generally a straightforward task. All that is required in this case is that all of the necessary information for the missing document is contained in the available one. The main limitation is likely to be around when the extra document is required – a good EDI service provider will be able to delay transmissions to an agreed schedule, where appropriate.

Pros: This is a standard format transformation, and will be no more expensive than a standard integration.

Cons: There can be unwanted delays - even the best EDI service provider will be unable to make the required document available to the recipient any sooner than they receive the trigger document themselves.

2. The EDI service provider generates the “missing” document type(s) by combining information sourced from multiple documents.

Consider the case of a Customer who wants to receive not only an Invoice document on despatch, but also an Order status response at key stages of supply, such as Order Accepted, In Manufacture, Ready for Despatch etc. The customer may need many details from the Order on each status update. The Supplier’s ERP system can only generate a simple list of Orders that have reached the status of In Manufacture, and eventually an Invoice.

As not all of the necessary information for the Order Status Update messages is available in a single document, the process requirements are more complex. Still, a flexible EDI service provider can solve the problem for the trading partners by storing data from the Order, and using the arrival of a daily In Manufacture list to trigger the creation of appropriate Order Status Update messages as necessary.

When the supplier sends the Invoice, this first triggers the final Order Status Update message, before the Invoice is passed on. If the EDI service provider has a good structured approach to flexible integrations, then the cost of providing these extra message types need not be excessive.

Pros: Almost anything can be achieved with this approach without any changes being required to either of the trading parties’ own computer systems or processes.

Cons: There are inevitably some costs, however efficient the EDI provider. Also, the accuracy of the status in this example is not as precise as the customer might ideally like.