How should a bill of materials be stored in a Birmingham manufacturing system?

As a recursive relationship with its own table rather than as nested data in a column. An assembly contains components, some of which are assemblies, and the questions asked of it are recursive too - the total cost of this product, everywhere this part is used, what is affected if this supplier fails. Those are answerable with a recursive query against a parent-child table and effectively unanswerable against a JSON column. Depth and quantity per level both have to be explicit, because a part appearing twice at different depths is normal.

Our quantities are in different units and the totals are wrong.

Then the unit is not stored next to the quantity, or there is a conversion happening implicitly somewhere. Every quantity needs its unit on the same row, conversions need to be data rather than code, and anything derived needs to record which unit it was calculated in. Metres and millimetres differing by a factor of a thousand is the version that gets caught; kilograms against pounds is the version that produces a plausible wrong answer and survives for years.

The business runs on a spreadsheet one person maintains. Can that be migrated?

Yes, and the work is mostly understanding rather than importing. A spreadsheet that has run a business for fifteen years contains rules nobody has written down - a colour that means something, a column that is only used for one customer, a formula with an exception in row 400. The import is a week; extracting the rules is the project. We do that by reconciling against the spreadsheet rather than replacing it, until the two agree on every row.

Can you integrate with our ERP without replacing it?

That is the usual and better arrangement. The ERP keeps ownership of parts, prices and stock; the application reads what it needs on a schedule and records when each figure was last true. What matters is deciding which system owns each field, because two systems both believing they own a price is the cause of most integration pain rather than the protocol.

Laravel in Birmingham

Laravel development for Birmingham manufacturers and distributors

A Laravel development company for Birmingham manufacturers and distributors. Bills of materials that are recursive, units of measure that cannot be assumed, and a spreadsheet one person maintains.

Updated November 4, 2026

Birmingham's industrial businesses have the kind of data that rewards a proper schema and punishes a hasty one.

A consumer application has orders and products. A manufacturer has assemblies containing assemblies, parts with alternates, quantities in units that are not all the same, suppliers with lead times, and a price that depends on volume and on when you asked. None of that is difficult individually. It is unforgiving of shortcuts, because the shortcuts become wrong answers in a quotation rather than a slow page.

A Birmingham bill of materials is recursive, and the questions are too

The first design decision on these systems is how the product structure is stored, and the wrong answer is seductive because it looks simpler.

Nesting the structure inside a JSON column works for displaying one product. It fails the moment somebody asks a question in the other direction - where is this part used, what does this assembly actually cost including everything below it, which products are affected if this supplier stops delivering. Those are the questions the business cares about, and they need a parent-child table with explicit quantity per level and a recursive query over it.

The detail that catches people is that the same part can appear at several depths with different quantities, so a flat count is wrong and the arithmetic has to walk the tree. That is a solved problem in SQL and an unsolvable one in a column of nested text.

Units are data in Laravel, not a convention

The second recurring defect in Birmingham systems is quieter and more expensive.

A quantity without its unit on the same row is an invitation. Somebody will write a total that adds metres to millimetres, and the version that differs by a factor of a thousand gets caught in testing. The dangerous one is kilograms against pounds, or litres against gallons, because the result is plausible and nobody checks a plausible number.

So the unit lives beside the quantity, conversion factors are rows rather than constants in code, and anything calculated records the unit it was calculated in. This is the same discipline as storing money as integers and it is ignored for the same reason, which is that it looks like unnecessary ceremony right up until an invoice is wrong.

The Birmingham spreadsheet is the specification

Almost every Birmingham engagement of this kind has a spreadsheet at the centre of it, maintained by one person, holding fifteen years of accumulated business rules that exist nowhere else.

Importing the rows takes a week. Extracting the rules takes the project. A column used only for one customer, a cell colour that means "check with the works manager", a formula with a hard-coded exception for a product discontinued in 2017 - these are the actual requirements, and none of them are in any document.

The approach that works is to run the new system alongside the spreadsheet and reconcile, row by row, until they agree. Disagreements are findings rather than bugs. It is slower than a cut-over and it is the only version where the business keeps trusting its own numbers.

Quoting from a Birmingham bill of materials

Once the product structure is modelled properly, the quote becomes a roll-up through it, and that is where the commercial logic lives.

Each level contributes materials, labour and an overhead, and the total is the sum walked up the tree. The decisions that have to be explicit are the ones estimators currently hold in their heads: whether margin is applied per level or once at the top, which costs are per unit and which are per batch, and what happens to a part with no current price.

The requirement that shapes the schema is reproducibility. A quote sent in March has to be explainable in September, after material prices have moved and the product structure has been revised. So the quote stores the resolved figures and a reference to the versions it used - the structure version and the price list version - rather than recalculating from current data when somebody opens it.

Without that, every historical quote silently becomes a different number, and the first customer to hold a printed copy next to the screen ends the conversation about whether the system is trusted.

Lead times, and the Birmingham promise date

The question a customer actually asks is when they will have it, and in a manufacturing business that is a calculation rather than a field somebody types.

It depends on stock for the parts that are held, supplier lead time for the ones that are not, the longest path through the assembly rather than the sum of its parts, available capacity in the relevant week, and the works calendar including the shutdown nobody remembered. Any of those being wrong makes the date wrong.

Treating it as a field means somebody guesses, usually generously, and the business either disappoints customers or carries a reputation for being slow when it is not.

Treating it as a derivation means the inputs have to exist as data - which is the real work, and the reason this is a project rather than a feature. Supplier lead times maintained rather than remembered, capacity expressed in something countable, and the calendar in a table.

The honest part is what the interface says when the inputs are missing. A date calculated from incomplete data presented as a promise is worse than a range, and a range is worse than saying which part is holding it up.

Commercially

Scope fixed in writing before work starts, priced per project. The country-level ground - UK data protection, e-invoicing where it applies, invoicing in pounds - is on the United Kingdom market page.

Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in pounds by bank transfer, with no Turkish VAT under the export-of-services exemption.