PrototypeCustom softwareAutomationWholesale and manufacturing

An order management system a UK wholesaler could test before committing to the build

Transcend Ltd, a UK wholesaler in perfumes and FMCG. February to June 2026, 5 months.

Get a plan like thisSee the proof
The home overview of the Transcend prototype: a dark dashboard with cards for active orders, revenue, estimated profit and pending actions over a chart of customer minimum order values per portal
implementation items assigned after the demo-kickoff review
13
requirements reviewed, across 17 sections
59
reviewers on Transcend's team, over preview builds
7
SKUs the system was scoped for
3,000 to 10,000

Proof

See the order management system for yourself

2 to open, 2 lines from the client.

Ask about this
Open2Said2

Open2

Said2

We need the total orders here

Anandu C Nair, Transcend, a review comment left on the orders screen of the prototype, in a message, 24 March 2026

Where is this lead time coming from. it is not getting changed even after changing it in the supplier page.

Anandu C Nair, Transcend, a review comment on the supplier page, one of the items closed in the April pull requests, in a message, 25 March 2026

Walkthrough

The two prototype passes cover the path from customer order to supplier basket and line margin. Both demos can be explored below.

A trimmed walkthrough will appear here once the approved upload is available.

Order management system at a glance

Challenge
A UK wholesaler tracked orders across sales portals, Odoo and Zoho by hand, and wanted to see a system working before committing to a build.
Solution
We built the order-to-purchase system twice, from the selling side and the buying side, against a 59-item requirement tracker.
Result
Seven reviewers checked the working screens; 13 implementation items were assigned, then reconciled through two gap-closure waves.

Inside the order management system

Second pass

  • The home overview screen: four summary cards, a panel of customer minimum order values grouped by UK and EU supplier portals, and a panel of supplier basket totals
    Overview. Where the day starts: active orders, revenue and estimated profit across all portals, customer minimum order values per portal, and the supplier baskets that are still below their minimum.
  • The customer orders screen: a search box, status and portal filters, and a table of eight orders with portal lead times, revenue, status chips and an advance-paid column
    Customer orders. Orders arrive by email and are entered here by customer, portal and EAN. Each row carries its portal lead time, revenue, a status from draft through purchasing to dispatched, and whether the advance has been paid.
  • The price lists screen: an EAN lookup box over a grid of price-list cards, each named by portal and quarter with a prepared date, an FX rate and view and copy actions
    Price lists. Each price list is held per portal, with prices and supplier availability as they stood when it was prepared. A vertical lookup by EAN finds an item across every list at once.
  • The purchasing and allocations screen: a workflow strip, tabs for orders to purchase, supplier baskets and allocations, and one order expanded to show its lines with needed quantities and split actions
    Purchasing. Order lines are allocated to suppliers from ranked offers, the purchase order is marked sent, the supplier's confirmation or rejection is entered, and the basket is watched against its minimum order value.
  • The inventory screen: cards for total SKUs, units in stock, low stock and out of stock, tabs for stock levels and receiving, and a table of products with in-stock, booked and incoming quantities
    Inventory. Stock in three states: in stock, booked against a customer order, and incoming from a supplier. Receiving goods converts incoming to booked, and every line can be traced back to the order it is held for.
  • The payments screen: cards for total revenue, total paid, outstanding and awaiting action, a list of orders awaiting final payment, and a table of every order's advance and final payment status
    Payments. Advances, final balances and invoices per order. For non-stock portals an advance is required before purchasing starts and the final payment is due before dispatch, and the screen says which orders are waiting on which.

First pass

  • The first-pass overview dashboard: cards for open orders, revenue and margin, payments pending and shipments pending, four portal tiles, a recent customer orders table and an active supplier baskets panel
    Overview. The first pass opened on the same question: open orders, revenue and margin, payments and shipments pending, and a tile per portal.
  • The first-pass customer orders screen: summary cards over a table of ten orders with portal, date, revenue, profit, margin percentage, minimum-order status, invoice state and order status
    Customer orders. Orders carried margin and minimum-order status per line from the start, which is the part the second pass kept.
  • The first-pass purchasing and allocations screen: cards for planned, ordered, confirmed and issues, and a table of allocations with EAN, product, supplier, rank, quantity, cost, margin and purchase-order status
    Purchasing. Allocations ranked by supplier offer, with the purchase-order status on every line.
  • The first-pass supplier baskets screen: cards for total baskets, minimum met, below minimum and total value, and a list of supplier baskets each with a progress bar against its minimum order value
    Supplier baskets. Each supplier basket tracked against its minimum order value, with a progress bar for what was still short.
  • The first-pass inventory screen: cards for in stock, incoming, booked and zero available, and a table of products with in-stock, incoming, booked and available quantities and the order each is booked against
    Inventory. Stock as in stock, incoming, booked and available, with the order each unit is booked against.
  • The first-pass admin screen: tabs for customers, suppliers, products, audit log and settings, and a table of 25 customer records with code, portal, currency and country columns
    Admin. Customers, suppliers, products, the audit log and settings, behind role-based access.

The order management system challenge

Transcend sells through several sales portals, each with its own price list, and buys from suppliers that set minimum order values. Orders arrived by email, purchase data lived in Odoo, sales in Zoho CRM, and profitability was tracked by hand between the two. The team wanted one dashboard that follows an order from the customer to the supplier and back, for a catalog of 3,000 to 10,000 SKUs, and wanted to see it working before committing to a build. So we built it twice, and they reviewed both.

What went into the order management system

Web appDiscovery and architecture

  1. A first pass, approached from the selling side: customer orders against price lists held per sales portal, purchasing and allocations, supplier baskets and inventory, with a role-based admin area

  2. A requirements specification and a 59-item requirement tracker across 17 sections, which Transcend's team scored the build against

  3. A second pass, with a partner team, approached from the buying side: orders to supplier, supplier baskets tracking minimum order values, allocations from ranked offers and per-line margin

More of what we built4

  1. Inventory receiving with stock held as in stock, booked and incoming, shipping and packing, payments with advances and final balances, invoicing with partial fulfilment per line

  2. Returns with reason codes and credit notes, and role-based access so a warehouse user, a buyer and an administrator each see their own surface

  3. An audit log under every action, so a change to a price list or a supplier lead time can be traced to who made it

  4. Two gap-closure waves after the review, reconciling the team's written comments against the requirement baseline

See it working, under proof

Order management system results

Seven people on Transcend's team reviewed the working system on preview builds and commented on the screens themselves. Two gap-closure waves reconciled those comments against the requirement baseline. Both passes run on sample data and are open to visit.

2 lines from the client, under proof

Done again today

What this would cost today

Done again today, work like this usually costs $2K to $6K (Operational platform build). The free plan says whether it fits before anything is priced.

  • Operational platform build

    The workflow a department runs on, built as real software with the roles, records and history it needs.

    $2K to $6K, usually fixed-price

    2 to 4 weeks

    Get a quote for this

Your project, next

Have a problem in this shape?

Say so in a few sentences. The free plan comes from the person who built this one.

Get a plan like thisBook a technical walkthrough

We usually reply within 2 business days with a free plan for what to do first. No call needed.

Both are optional. The site and every form work either way, and nothing here runs until you switch it on.

Google Analytics also receives the 17 on-site actions this site records, among them a request delivered through the form and the need, budget range and timing picked on it. Turning a category off later deletes the cookies it set on this site. Our cookie policy lists every one.