Odoo ERP for Building Materials and Concrete Producers

Why generic ERP misprices heavy products

Building materials cost little per tonne but a lot to move. A generic ERP posts freight as a cost of sale after the fact, which means a plant can sell out its order book and still lose money on any job beyond a certain haul radius. Layer on bulk units of measure that convert between tonnes, cubic metres and pieces, mix designs adjusted for moisture, and quantities confirmed by a weighbridge instead of a picker, and the standard configuration starts spitting out numbers nobody believes. Once UoM, analytic costing and delivery flows are built for bulk, though, Odoo handles all of this well.

Does anyone know your margin per delivered job?

Product cost is known, freight arrives as a monthly invoice from the hauliers, and plant overhead gets spread evenly across every tonne. On the margin report, a job at the far edge of the delivery radius, or one with split loads and multiple returns to the same site, looks no different from a short local run.

We set up each job as its own analytic account, so material, plant time, haulage and any returned or wasted product all post against the same object. Delivery cost gets captured per load, tied to the vehicle and distance; landed cost folds inbound freight into purchased cement and aggregate; and margin gets reported both per job and per delivery radius. That lets sales spot when a quote needs a delivery surcharge before it is ever accepted.

Are tonnes, cubic metres and bags fighting each other in stock?

Aggregate gets bought by the tonne, batched by weight, sold by the cubic metre and reported in bags. The conversions sit in a spreadsheet built around a density figure nobody has revisited in years, so book stock drifts away from the yard survey and month-end adjustments turn into a routine chore.

Odoo lets each product carry its own purchase unit, stock unit and sales unit with defined conversion factors, so tonnes turn into cubic metres the same way on every document. We set the reference unit per product category, attach density and moisture attributes to the product itself, and reconcile book stock against periodic yard surveys using a documented adjustment reason rather than a quiet correction.

Is weighbridge data being retyped into the ERP?

Trucks get weighed in and out at the gate, tickets print, and someone types the net weights into the system later that day. Any typing error flows straight into invoicing and stock, disputes over delivered quantity get settled from paper records, and the ticket number never links back to the order.

We integrate the weighbridge directly, so gross, tare and net weights post against the Odoo delivery order and carry the ticket number as a reference, while the sales order line updates to the actual delivered quantity before invoicing happens. Odoo Barcode, or a screen facing the driver, confirms the load at the gate, and invoices get raised from measured weight, so a customer dispute gets answered with a linked record instead of a trip to the filing cabinet.

What we implement for building materials producers

• Odoo MRP configured for mix designs and batching recipes, including moisture and admixture variants, with yield and consumption variance reported per batch.
• Bulk units of measure configured across purchase, stock and sales, along with density attributes and reconciliation of book stock against yard surveys.
• Integration with the weighbridge and batching plant, deliveries linked to tickets, invoicing on actual weight, and driver confirmation right at the gate.
• Odoo Accounting set up with analytic accounts per job and per plant, landed cost applied to inbound cement and aggregate, and delivered margin tracked by radius.