Transcend, second pass
An order-to-purchase system built twice for a UK wholesaler and reviewed line by line by their own team.
Transcend Ltd, a UK wholesaler in perfumes and FMCG. February to June 2026.
An order desk built twice, from both sides of the trade
Transcend sells perfume and FMCG wholesale from the UK, with price lists held per sales portal and supplier minimums tracked by hand. We built the order-to-purchase system twice, once from the selling side and once from the buying side with supplier baskets and margin per line.
Transcend in figures
- 59requirements reviewed, across 17 sections
- 7reviewers on Transcend's team, over preview builds
- 3,000 to 10,000SKUs the system was scoped for
- 2gap-closure waves after the review
The situation
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 catalogue 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 we built
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
A requirements specification and a 59-item requirement tracker across 17 sections, which Transcend's team scored the build against
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
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
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
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
Two gap-closure waves after the review, reconciling the team's written comments against the requirement baseline and closing the gaps in order
The screens
Sample data.
Overview, second pass
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.
Customer orders, second pass
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.
Price lists, second pass
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.
Purchasing, second pass
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.
Inventory, second pass
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.
Payments, second pass
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.
Overview, first pass
The first pass opened on the same question: open orders, revenue and margin, payments and shipments pending, and a tile per portal.
Customer orders, first pass
Orders carried margin and minimum-order status per line from the start, which is the part the second pass kept.
Purchasing, first pass
Allocations ranked by supplier offer, with the purchase-order status on every line.
Supplier baskets, first pass
Each supplier basket tracked against its minimum order value, with a progress bar for what was still short.
Inventory, first pass
Stock as in stock, incoming, booked and available, with the order each unit is booked against.
Admin, first pass
Customers, suppliers, products, the audit log and settings, behind role-based access.
What changed
Seven people on Transcend's team reviewed the working system on preview builds and commented on the screens themselves, which turned a scope discussion into a line-by-line one, and the 13 implementation items agreed at the demo kickoff were closed in order. Both passes run on sample data and are open to visit.
Along the way
Scope agreed: a Zoho and Odoo orchestration dashboard for the order-to-purchase flow, with the first pass built the same month
Requirements specification published, with the requirement tracker the team scored the build against
Demo kickoff with Transcend: the implementation items agreed, from overview filters and price-list ranking to partial fulfilment and returns
Transcend's team reviewed the preview builds and left written comments on the supplier and price-list screens
The gap-closure waves reconciled the feedback against the requirement baseline; the last demo build shipped on 28 April
Revision discussion with Transcend's leadership in May, and the last meeting in June
Try it
Transcend, first pass
An order-to-purchase system built twice for a UK wholesaler and reviewed line by line by their own team.
Read next
A prototype we built for wholesale order desks
Order emails that turn themselves into quotations
An email becomes order lines against a catalogue, stock moves to reserved, and a quotation drafts itself. 3 quantities per stock item: on hand, available and reserved.
Our own product, built for the cafe we own in Islamabad
The operations system behind a cafe, from tills to loyalty
A point of sale with a barista queue, void reversals that leave a trail, stock tied to recipes, shifts and loyalty, on one PostgreSQL schema. 20 tables in one PostgreSQL schema, from orders to loyalty.
A prototype we built for a manufacturing prospect
A spreadsheet that checks itself before it reaches the marketplace
Workbook upload, validation rules, transforms, reports and notifications, with a simulated marketplace upload as the worked example, built in February 2026 for a prospect whose order workbooks were rejected by hand. 5 required fields checked on every row: order, customer, mobile, city and quantity.
Elsewhere on the site
Related
- PracticeThe Build practiceWhat the practice covers, what it costs to start, and the work behind it.
- The workDemosThe demos you can open now: the two that run in your browser, the hosted prototypes, a walkthrough on video and a live cafe site.
- The workThe five practicesBuild, Automate, Data, Growth and Talent: what each one covers, the work behind it, and what it costs.
Where to next
Have a problem in this shape?
Say so in a few sentences. The reply comes from the person who built this one.