Add to Technorati Favorites The EDI Mapper: Some times you can process EDI too fast, Nice Problem to Have

Friday, November 16, 2007

Some times you can process EDI too fast, Nice Problem to Have

A client rang me this week with what I believe to be a first in terms of customer requests for us. His problem was that we were processing the EDI invoices TOO FAST. I guess sometimes speed isn't everything.

This was however a genuine business problem as follows. The sender of the invoice issues the invoice upon dispatch of the goods, not an uncommon practice. Both parties are linked via our FREE AS2 service. When the invoice is issued it is placed in the AS2 outbox, received by our service, translated and sent via AS2 to the recipient. The whole process takes less than 1 minute from the time the invoice is issued, to the time it is received by the recipient. The recipient then loads the invoice in to their system (all automated) and it is immediately rejected because the goods have not been received by the warehouse. Hardly surprising because the goods have just left the loading bay at the supplier and still have hours of road time before they will arrive.

It's good to be able to have a laugh at work and the client and I found this quite amusing (maybe we're just a bit sad), but it is worth noting that no matter how efficient and fast we make the technology it still has to take the actual business practice in to account.

There are many resolutions to the problem. The first would be for the invoice issuer to delay sending the invoice until the following day. The second would be for us, as the central hub service, to stall the invoices until the following day. This was the option that was taken as our systems were easier to configure than any one Else's. The recipient could delay processing invoices until the following day as another option.

However the best solution would be for the invoice to be raised not upon dispatch, but upon receipt of an electronic Goods receipt Note (GRN), sent by the recipient of the goods when they are received in to the warehouse. This would be electronic trading haven, you could even make the invoice match the GRN, so that there would be no chance of the invoice being refused by the recipient. There is a flaw in this process though. If the recipients systems and/or the senders systems cannot process a GRN they will have to alter their ERP systems, which has a cost. It might be possible to cost justify but it is a major change of business process and proper thought must be put to the business/profit advantage to be gained. Too many times we see technologists come up with a great technology solution to a problem without thought to the true business benefit.

For these customers the simple solution worked best. We have other customers using the GRN process and they have established a huge cost reduction by doing this. Luckily with SaaS it is easy for one system to accommodate both customers, so both customers get the electronic trading that their business justifies.

No comments: