Half past six, and the orders are still in the portal
The retailer's orders drop overnight. Someone in customer services logs into the EDI web portal, opens each purchase order, and works through the lines: depot, delivery date, retailer item code, number of cases. Then they type the same thing into Sage, your ERP or the order spreadsheet that feeds the production plan.
On a normal day that is an hour. On a promotion week, or when a second retailer's orders land at the same time, it runs past the point when the planners wanted to fix the day's production. The planner waits, the line starts on yesterday's guess, and changes are made mid-shift.
Why the portal never quite joined up
Most smaller food manufacturers came to EDI because a retailer insisted, not because they chose it. The cheapest route was a web EDI service: messages arrive in a browser, and invoices and advance shipping notices are typed back the same way. It met the retailer's requirement. It never connected to anything on your side.
- Retailer item codes and your product codes are different, and the cross reference lives in someone's head or a pinned sheet.
- Each depot has its own code, delivery windows and case configuration.
- Order amendments arrive as a separate message and are easy to miss.
- Invoices and ASNs are keyed back into the portal from your system, doubling the typing.
The cost is in the morning, not the typing
Keying errors are the visible cost: the wrong depot, a case quantity entered as units, an amendment that never made it through. Each one becomes a short delivery, a rejected load or a credit claim weeks later.
The larger cost is time lost at the start of the day. Production planning, raw material calls and haulier bookings all wait for the orders to be in. When the person who does the keying is off, the whole morning slips.
How we connect the orders to your system
- We take the order messages from your EDI provider, either through its API, an SFTP drop or the mailbox it forwards to, in the format it already produces.
- A mapping table, which your team can edit, translates retailer item codes, depot codes and units into your own product codes and customers.
- Each order is validated before it posts: unknown codes, quantities well outside that depot's usual pattern, delivery dates that fall on a non-delivery day.
- Clean orders post into your ERP or order system through its API or import route. Anything that failed a check goes to an exception list with the reason shown.
- Amendments and cancellations are matched to the original order, so the latest version is the one production sees.
- Where your provider supports it, we send invoices and advance shipping notices back from your system rather than having them retyped.
| Message | Today | After |
|---|---|---|
| Purchase order | Read in portal, retyped | Posted with checks |
| Order amendment | Spotted by chance | Matched to the original |
| Advance shipping notice | Typed back into portal | Sent from despatch data |
| Invoice | Typed back into portal | Sent from your accounts data |
We do not replace your EDI provider. Retailers have approved connections with them, and changing that is a separate decision.
What your customer services team sees instead
The orders are already in the system when the team arrives, with a short list of things that need a human eye: a new depot code, an item that has been delisted, an order double the normal size. They deal with those and move on to the calls that need them.
Planners can run the production plan earlier, and the order history is in one place when a retailer queries a delivery.
When a new retailer or wholesaler moves to EDI, adding them is a mapping job rather than another portal to log into each morning. And the exception list becomes a useful record in itself: which depots keep sending codes you do not recognise, which amendments arrive after your cut-off, and where the retailer's master data and yours have drifted apart.
Is this your morning?
- Someone logs into an EDI portal and retypes orders every day.
- Order amendments have been missed and caused a short delivery.
- Production planning waits until the orders are keyed.
- Invoices are typed twice, once in accounts and once in the portal.
- Only one or two people know the retailer code cross reference.