Ænðr E. FeldstrawToday I spent time chasing errors in the processing of an inbound #EDI document. It contained multiple sales orders with a very short turn-around time. In those situations, having the processor help you find the error quickly is of the essence. Our #ERP's EDI processor failed to do so. It merely indicated there was a problem at all.
Overall, this #EDI document didn't look any different from others we received the same day via the same channel. To solve the problem I started with the divide-and-rule technique. The document contained 13 sales orders. I split the document into 13 separate documents. Each of them to be processed separately. Hoping that if 1 or 2 of them failed, the rest would succeed. That worked, and this time the processor could tell us the problem: the ship-to address name was too long. Easily fixed.
The problem is that for this #EDI #tradingpartner, the segment N102 (the ship-to address name in this case) can contain up to 60 characters. While our #ERP has reserved only 50 characters. So every time a valid EDI document comes in, it can trigger this same problem.
One would think that our #EDI processor could be configured to automatically chop the remainder. One would be right. But that will work the same way for all address names, which is not always a good choice, because the input is mostly freeform. Thus, manual correction is needed.
I see potential here for a linguistic #AI, one that understands natural human language. It could be added to the process if this particular problem occurs. And it should provide suggestions instead of corrections.