Getting delivery and freight into the cost of each product

The price on a purchase order is rarely the whole cost of the stock it brings in. Delivery and freight arrive on top of the supplier’s invoice, and if those charges never reach the cost of each unit, the margin figures overstate what’s actually being made.

One of our customers came to us with this. They’re a drinks producer — production outsourced, finished goods batch-tracked, stock in third-party warehouses, selling direct through Shopify, through a trade portal and on wholesale email orders. They buy from UK and overseas suppliers, and before Workhorse the operation ran on an off-the-shelf inventory app and spreadsheets — and in practice, the costs were being reconciled by hand. When we wrote their functional requirements document, cost went into it: they wanted cost allocated per product, so the margin figures could be trusted.

What the standard platform does

Workhorse purchase orders carry an additional-costs figure as standard. When the order completes, that figure is apportioned across the items on the order and added into each product’s cost, so margin reporting runs on the landed cost rather than the invoice price. None of that needed building — it’s standard behaviour.

What they needed beyond it

The standard field holds a single amount per purchase order. Their costs come in pieces — a delivery charge, a freight invoice, sometimes more than one of each — and the record needs to show what each cost was, not just what they came to.

Where configuration got to

Configuration is settings-level work, part of every implementation. Here it added a costs list to purchase orders — a small child record, one line per cost, a description and an amount — and switched off direct entry on the standard field, so the total could only come from the list. Fields, forms, a new record type: all settings.

Where configuration stopped

There’s no setting that adds up a list of lines and writes the total into another field. That’s where development started, and it amounted to two functions: one that sums the cost lines into the standard additional-costs field whenever the record saves, and a variant of the copy-purchase-order function so a copied order behaves the same way. That was the whole of the development.

Everything downstream of that field is untouched. The apportioning on completion, the product costs, the margin reporting — all standard, running as it runs for every other customer. Put £300 of costs against an order of 100 units and £3 lands in the cost of each one.

How it was priced

This wasn’t sold as a separate development project. It was scoped during the functional requirements stage and covered by an amount added to the implementation fee, agreed in writing before anything was built.

None of this is an argument for building, either. A business content with a single figure per purchase order doesn’t need any of it — the standard field does the work, and most of our customers use it as it comes. The development happened because the itemisation mattered to this one.

That’s how configuration and customisation divide up in practice. Configuration shapes the records,forms and workflows the platform already has. Customisation is written where settings can’t reach, and when it’s scoped properly it stays a small, clearly defined piece of work while the rest of the system — batch tracking included — stays standard.

‍