Problem: Missing Details on Returned Documents

What is the problem?

One trading partner may not be able to import or export all of the data that is present on the inbound document, and which is required on the return documents. As a result, they cannot include those values on returned documents. For example, a customer may provide the Order Date on the Purchase Order, and require it back on the Invoice, but the supplier’s system does not store that value – or perhaps stores it but does not include it on the exported Invoice. Another common example is that for many customers the Invoice needs at line level to contain the original Purchase Order line number as well as the Product Code and Quantity. Maintaining Order line numbers throughout the processing steps is often a problem for supplier’s ERP systems

What solutions are there to this problem?

There is no all-encompassing standards-based ideal solution to this. Let’s face it, whatever the pressures are for conformity to a single standard business document, in the real world business processes do change. It is probably always going to be possible for new data requirements to emerge. New fields may be introduced – or existing fields will be put to new uses, or have to contain larger amounts of data than had previously been catered for. While XML-based formats are more flexible than some other standards in catering for new data elements, some data conversion will still be required somewhere in the data exchange if a new data item is to actually be used. There are therefore only two ways to resolve such situations if you want to trade electronically.

1. One or other party adapts its systems

The problem can often be resolved by one or other trading partner adapting their computer systems. However, in many cases it may be difficult, and may not be cost-effective to alter your entire computer systems for what may be just a small proportion of your turnover. If the requirement is unusual, then it may not even be a requirement for long.

Pros: Can enhance the usefulness of the relevant computer system.

Cons: May require significant effort, and there may be substantial costs in developing a change and supporting it. The change may complicate your computer systems for ever, but the requirement may turn out to be short lived.

2. The EDI service provider stores and then adds the values for you

If your documents pass through a flexible EDI service provider, they can solve the problem for the trading partners by storing data and adding it when required. For example, the necessary details from the Purchase Order are stored before the Purchase Order is passed on, and then a lookup is performed when the Invoice comes back from the supplier. The relevant values are then added in, before sending the Invoice on to the customer. This is a good example of a genuine value-add service – and it need not be expensive. Depending upon the complexity of the requirement, the cost of providing this extra service need be no more than the equivalent of say one extra trading connection if the EDI service provider has a good structured approach to flexible integrations.

Pros: Can provide the necessary flexibility without changing either parties’ computer systems.

Cons: There will inevitably be some cost, but it will probably be cheaper than adapting computer systems.