Retailer purchase orders arrive. NetSuite sales orders are created against the right subsidiary and customer. Acknowledgements, despatch advice and invoices fire back out to each retailer's own rules, without anyone touching a spreadsheet or rekeying a line.
Supply Lens translates retailer purchase orders into NetSuite sales orders and returns every required response document to the trading partner automatically. NetSuite stays the system of record and each retailer gets documents built to their own rules.
Supply Lens has existing configurations for the major UK and Irish retail EDI networks. New trading partners are added as required, with each retailer's document rules, codes and compliance requirements handled individually. The retailer side does not change because the ERP behind it is NetSuite.
Once the core PO to order flow is live, Supply Lens can activate additional handling depending on your retailer requirements and how NetSuite is set up.
Every retailer has its own codes, document formats, timing rules and compliance requirements. Supply Lens is configured per trading partner rather than forced into one template, and the NetSuite side is mapped once.
GLN, supplier codes, buyer identifiers and network routing captured per retailer. Each partner is isolated so a change to one does not affect another.
Retailer EAN, buyer article number or internal code mapped to your NetSuite item, at line level and per retailer. Unmapped codes go to the exception queue.
Each retailer becomes a NetSuite customer with depots and stores as ship-to addresses. Where a retailer is served from more than one entity, the subsidiary is decided per depot or product range.
Which documents fire, when, in what format and with which mandatory fields: configured per trading partner, with the retailer's PO reference carried on every one.
Every retailer has their own quirks, and NetSuite adds a few of its own. These are the four we hear about most, in the words customers use.
Unrecognised codes go to an exception queue with the full PO context. Your team resolves and re-triggers. Nothing is dropped silently and the retailer gets a timely acknowledgement either way.
Depot and store code changes trigger exception flags before a sales order is written. Supply Lens catches the mismatch rather than posting against a stale NetSuite address.
Documents are built from the NetSuite item fulfilment, not from the original order. The retailer receives an accurate despatch advice and an invoice for what actually shipped.
Subsidiary is decided at PO ingestion, per retailer, depot or range, so the sales order, fulfilment and invoice all sit in the entity that supplied the goods.
EDI onboarding is more involved than a standard API integration. Document specs, code lists and compliance rules all need to be in place before go-live, and the NetSuite customer and item structure needs agreeing. Supply Lens manages the process.
Tell us which retailers you trade with and how your NetSuite entities are set up. Twenty minutes is usually enough to size the work.