The ordering portal and EDI feed that take your customers' orders

Two doors into the same order book. One the customers walk through with a login; one the national accounts send files through, and nobody walks through at all.

A typical business running one of these has 20 to 100 staff, a portal used by a few hundred trade accounts that places a third to a half of the order lines, and EDI with a handful of national accounts, multiples, buying groups or large contractors, that make up a large share of turnover. Several hundred portal orders a week, the EDI orders in batches each morning, and a few dozen a week still arriving as emailed PDFs from accounts that use neither. Whichever generation built it, a Classic ASP site from 2006 or an agency's portal from 2019, the job is the same and the order book fills the same way.

From the customer's side, it shows their own price for each product they are set up for, a stock traffic light, their favourites and their last order. They fill a basket, check out with a PO reference and a delivery date, and the order lands in the sales order system like any other. They can see where it is and download the invoice. On the EDI side, the files arrive, the translator maps the account's codes to ours and raises the orders, sends the acknowledgement, and later the despatch advice and the invoice in the format that account mandates. A file that fails lands in a folder, for the one person who knows what to do with it.

The rules it holds:

• Each customer sees its own price and only the product groups it has been set up for.
• An order over a customer's usual size, or with a delivery date before the cut-off, is held for the sales office to look at.
• The national accounts' product codes are mapped to ours, and the mapping has exceptions per delivery depot.
• Stock shows as traffic lights, never numbers, and the thresholds differ by product group.
• Invoices go to one account as a file per delivery and to another as one file a week.

The first portal was written in 2006 in Classic ASP by the contractor who wrote the order system. A small agency rebuilt it around 2011 in ASP.NET Web Forms, and a web agency bolted on a PHP catalogue after that. Prices and stock come across from the order system's SQL Server in a nightly copy, the EDI translator is a mapping script on the same IIS server in the office, and parts of the 2006 site are still live behind the newer pages.

Three agencies have come and gone, each leaving its own code and nobody's notes. The login works across all three through a fix nobody documented, so the checkout is left exactly as it is. It was laid out for a desktop monitor in 2012, and on a buyer's phone it shows.

The same portal built between 2016 and 2022, usually by a web agency or a freelancer, as a web system in React, Angular or Node or early .NET Core, sometimes with an ordering app for the trade buyers in React Native. A few wholesalers had a customer portal put together in Bubble instead, reading the order system through a connector someone set up. From the office it looks modern: a clean catalogue, a basket that works on a phone, stock refreshed through the day. Since 2023 some have had a reorder screen started in an AI app builder, which showed a customer's favourites and stalled at the hold rules.

Half of it never moved. The agency quoted for the catalogue and the basket but never for the EDI, so the national accounts' orders still run through the old translator script, on an old server kept alive for that alone. A later change to the new checkout let a large order skip the hold and go straight to picking, and nothing has been released since. The agency was absorbed into a bigger one, and its packages date from launch. Customers see a portal from 2019, and behind it the business is as stranded as it was with the 2011 one.

Orders around the clock without the phone ringing, and the national accounts kept.

Half the order lines never touch the sales office. The customer types the order at ten at night from their own price list, so it is right the first time, and the reps spend the day selling rather than keying. When a customer wants to know where an order is, or wants last month's invoice again, they get it themselves.

The EDI feed is the quieter dependency and the bigger one. For the national accounts EDI is a condition of supply: no feed, no listing. The feed takes their orders in whatever shape they send them, answers in the shape they demand, and gets the invoice to them in the form their system will pay. The mapping table, built up account by account over years, is what makes that work.

Systems like this stop being an asset the day a customer's audit looks at them.

The portal is what the supplier audit sees. The national account's questionnaire asks about TLS, patching and the framework the site runs on. Classic ASP and Web Forms on an IIS server in the office answer badly, and so does a 2019 portal whose packages have not been touched since launch. The Cyber Essentials assessor asks the same questions of both.

The invoice feed has a deadline. Electronic invoicing becomes mandatory for business-to-business VAT invoices from April 2029. The national accounts will expect every invoice as structured data, and so will the trade accounts on the portal, so an invoice feed that sends a file to two accounts and a PDF to everyone else has to produce them for all. In a few businesses the oldest account's files still go over a dial-up or ISDN line, which the analogue switch-off on 31 January 2027 ends sooner.

Prices and stock on the portal are last night's. The nightly copy from the order system means a customer orders at nine what sold out at eight, and the sales office phones to apologise. A price change made at ten is not on the portal until tomorrow.

Three agencies, three languages. The last agency has moved on, and a change to the checkout means finding someone who knows Classic ASP, Web Forms and PHP at once. None of the three was laid out for a phone.

The same address and the same login, with live stock behind it and feeds the accounts will accept.

Each of these rests on something the system already does.

Live prices and stock. The portal reads the order system's database as it stands, so the customer sees the stock the counter sees and today's price today. The apology calls stop.

One portal behind the same address. The three codebases replaced one screen at a time, checkout first, behind the URL the customers have bookmarked. Their login, favourites and order history come with them because all of it is in the database.

A site the questionnaire can tick. Nothing on it out of support, the server patched, the connection encrypted, and a login that passes the audit. The same answer serves Cyber Essentials.

EDI in the formats the accounts now ask for. Each feed on the transport and in the format that account now requires, the code mapping carried over intact, and the failed-file folder replaced by a screen the sales office can see and act on. Invoices go out as structured data to every business account, well ahead of April 2029.

The portal on a phone. A customer's buyer ordering from the van or the site, with the same basket.

Order status the customer can see. Picked, on the van, delivered, on their own screen, including the orders the sales office is holding and why.

The old pages are not switched off for any of this. Each new screen goes in beside them, on the same data, and the old one is removed when nothing links to it.

On the orders that do not look right, and the ones that still arrive as PDFs.

Every portal and EDI order already lands in one place with the account's history behind it, and that history is what AI works from:

Odd orders held before they are picked. The hold rule catches an order over a set size. It does not catch a code that account has never bought, a case quantity keyed as single units, or a delivery to a depot the account closed last year. AI reads each portal and EDI order against that account's history and holds the ones that do not fit, with the reason beside them, for the sales office to release or query. Across several hundred portal orders a week and each morning's EDI batch, the held list is typically a few orders a day and a few minutes to clear, and each wrong pick it stops saves a half-hour of return, re-pick and credit note.

PDF orders turned into portal orders. The accounts that use neither EDI nor the portal have buyers who email a PDF purchase order in their own layout and codes, and someone in the sales office keys it. AI reads the PDF, matches the codes from what that account has bought before, and drafts the order in the portal for the sales office to confirm. At a few dozen PDFs a week and ten minutes or so each to key and code, that is typically half a day to a day of the sales office's week.

Not worth doing: AI-written product descriptions for a trade catalogue. The customers order by code and pack size, and a trade buyer scrolls past a paragraph to the price.

The held list and the drafts both sit in the checkout and the order import, where a careless change does most harm, so AI waits until both can be changed and tried on a copy first. The assessment shows which would repay sooner on the portal and feeds as they are.

The host and the feeds both have dates, so they go first.

1. Stabilise. Source for every codebase found, the agency's included, the site on a server that is patched and encrypted, a backup restored on purpose, and a test copy of the portal running against a copy of the database. This goes first because the supplier audit is already asking, and the host is where it looks first.
2. The feeds brought up to date. The translator made to speak the transports and formats the accounts now ask for, invoices included, the mapping table carried over, and a failure screen in place of the folder. The portal pages carry on as they are.
3. Live prices and stock in place of the nightly copy. This is the stage the customers notice.
4. The checkout replaced, then the account pages, then the catalogue, each behind the same address and each priced on its own.
5. Order status and the phone layout.
6. Retire the old pages when nothing links to them. The invoice download page is usually the last to go, because the customers have bookmarked it.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a portal that means a few days with the sales office, the person who watches the EDI folder and the code, finding how the three sites share a login and what each account's feed demands, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work, what drives the price and the payment terms each have a page, and so does each technology the system is built on: Classic ASP, ASP.NET Web Forms, PHP and SQL Server, and for the newer generation React, Angular and Node, early .NET Core and React Native.