Yards that weigh trucks live and die by the ticket. A mill buying wheat, a scrapyard taking in mixed metal, a mine dispatching ore, or an agri-processor receiving cane all pay or invoice on net weight — and in stock Odoo there is nowhere for that net weight to come from. Teams end up reading the indicator display by eye, keying figures into a spreadsheet or a paper pad, and then re-keying them into a purchase or sales order hours later. Every manual hop is a place to fat-finger a tonne, weigh the wrong vehicle, or lose the tare. Odoo Community and Enterprise both ship excellent Purchase, Sales, and Inventory apps, but neither has any concept of a weighbridge, a two-pass weighment, or an indicator serial feed — so the single most important number in the whole transaction is captured outside the system of record.

We build a dedicated weighbridge module that closes that gap. At its core is a weighbridge.ticket model (models.Model) that represents one truck visit: vehicle, product/material, driver, first-pass weight, second-pass weight, and a stored computed net_weight field driven by @api.depends so gross and tare can never drift out of sync with net. A weighbridge.device model holds the connection profile for each scale — serial (pyserial, e.g. /dev/ttyUSB0 at a defined baud/parity) or TCP/IP socket to the indicator — and the read is performed by a small hardware-facing service so the ORM stays clean. The two-pass workflow is modeled explicitly as states (draft → first_pass → second_pass → done): the operator captures gross on the loaded pass and tare on the empty pass in either order, and the module computes net automatically, with configurable rounding and unit handling (kg/t/lb) plus optional tolerance checks against expected loads.

Every weighment is tied to the transaction it belongs to. A ticket can reference a purchase.order (inbound receiving) or sale.order (outbound dispatch) via Many2one relations, so the weighed net flows into the right document instead of a spreadsheet — with optional pushes to stock moves or invoiceable quantities depending on your process. Manual overrides are allowed, because real yards need them (a jammed indicator, a re-weigh, a correction), but they are never silent: an override records the original reading, the new value, the user, and a reason on the chatter (mail.thread), giving you a defensible audit trail. Access is controlled through ir.model.access.csv and record rules so operators, weighbridge supervisors, and accounts each see the right scope, and printable tickets are generated as QWeb PDF reports with your branding, gross/tare/net, vehicle, timestamps, and signatures. Where a downstream ERP, gate system, or ANPR camera is involved, integration runs over Odoo's XML-RPC/JSON-RPC API or scheduled automated actions.

Because this is build-to-order, nothing is a black box. We start from your actual indicator make/model and connection type, your material list, and how you want net weight to land in Purchase or Sales, then we build the module against Odoo 17.0, 18.0, or 19.0 to match your environment. You get a working install on a staging database first, run it against your real scale during UAT, and go live only once the readings and tickets are correct. Typical delivery is one working week from confirmed scope, and you receive the full source, so the module is yours to run and extend.