The EDI rejection over one character
One PO line rejected by a customer's automated feed over a single account-specific character, re-keyed by hand so the order can move, until it is plain that the order most theirs is the one the standard path cannot take.
The PO came in overnight from one of the larger accounts, through the feed, the way their orders always do. Most of the lines cleared and the order started to move. One line did not. It bounced, and the order sat on that line, waiting.
The line was for an item the account orders constantly. It came in under the customer’s own number for it, the one their plant’s stockroom uses, with their internal prefix and a revision suffix on the end. The item master holds the same item under the bare manufacturer number. For as long as anyone could remember, the cross-reference had caught it: the customer’s number on one side, the manufacturer number on the other, the two tied together so the line resolved on its way in. On this order it did not resolve. Some time back the customer had re-shelved the item and the suffix on their number moved a character, and the cross-reference still pointed at the old string. So the number that arrived was not the number the feed was matching against, and the line that resolved on every prior order stopped on this one. One line, held, until someone could say what it was.
The feed did not get the line wrong. It was built to take the standard order, the one where the customer’s lines resolve against the records the business keeps, and it resolved every line it was built for. To the team that runs it the rejection is not a defect. The feed checked the line against the one record it was told to check, the line failed that check, and the feed flagged it. That is the integration doing what it was configured to do, not the integration failing. The line it bounced was the one carrying the thing that makes this account this account: their own way of naming what they buy, their prefix, their revision, the number their buyers cut the PO from. The clean lines were the items the account orders the standard way. The bounced line was the item they order their way.
So the rejection went to the CSR who handles the account. She opened the line, recognized whose it was, read the customer’s number against the cross-reference, found the one element that had drifted, mapped it to the manufacturer number by hand, and released the order. The order moved. The customer never saw the bounce. Nothing about that fix changed what the feed checks against, so the next PO carried the same line, and it bounced the same way, and the same person cleared it the same way the following week.
- What the customer sent on the line: their part number, with their plant prefix and a revision suffix.
- What the item master holds: the bare manufacturer number.
- What drifted: one character in the suffix, so the cross-reference no longer matched.
Nothing about this gets fixed, because nothing about it breaks. The feed handles the standard order, which is most of the volume, so it looks like it works, and on its own terms it does. The bounce is rare enough on any one account to absorb by hand, and routine enough that writing the customer’s own number into the records as a kept reference was never anyone’s task. The order always moves in the end, so there is never the moment that forces the question. The line gets re-keyed, not resolved, and the mismatch sits exactly where it was, waiting for the next PO.
The re-key never shows up as anything but a person’s time. It is not a project and not a backlog; it is one line, opened and cleared, on an account someone already knows. So the queue of these lines reads as data that needs cleaning up, when what it actually is, is the order desk hand-carrying the account’s own way of buying past a feed that was never built to take it. The obvious move is to fix this mapping: add the customer’s number to the cross-reference, scrub the master, write the format for this account, and the bounce goes away. It goes away for this line. The customer keeps buying their own way, and the next number that drifts, a new revision, another re-shelved item, bounces the same way and routes to the same desk. The thing that does not fit is not the mapping. It is the customer.
The integration keeps doing the one thing it was built for, which is to take the order the business wishes it received, the clean one. The order it actually receives from its best accounts carries the customer’s own way of buying, and that is the one thing the standard feed cannot take. So the most account-specific order, the one that is most theirs, is the order that always needs a person, and the customer’s own intake hands that fact back to the business one rejected line at a time.
The feed takes every order except the one that carries the way this account actually buys, and that is the order the business most wanted it to take.
The feed clears every order except the one carrying the way this account actually orders, and a person carries that one across by hand each week. Which of the things customers pay the business to do gets written into the records the order runs on, and which keeps dropping to a person, is a choice the business has never actually made. That is the work the rejected line is pointing at.