Retail and wholesale teams running Odoo Point of Sale hit a wall the moment they need to sell one product in more than one unit. Odoo's core POS is built around a single sale unit per product: the register shows the product, adds a quantity, and prices it at the product's base UoM. But real counters sell water by the bottle and by the 24-pack, cheese by the piece and by the kilo, hardware by the each and by the carton. Native Odoo forces a workaround — separate product variants, duplicate SKUs, or manual price math at the till — and every workaround fragments inventory, breaks reporting, and slows down the line. The uom.uom and uom.category framework exists in the backend, but the POS session simply doesn't expose it at point of sale.

This is a build-to-order module that ECOSIRE designs and develops for your specific catalog and register workflow. On the data side we extend product.template/product.product to declare which UoMs a product can be sold in (constrained to a single uom.category so conversions stay mathematically valid), with per-UoM pricing that either derives from the base price via the standard conversion factor or is overridden through a dedicated price model resolved against the customer's pricelist. On the POS side we ship a front-end extension (OWL components and a patched PosStore/order-line model in Odoo 17/18/19, replacing the legacy Backbone POS in older lines) that adds a UoM selector to each order line, recomputes unit price and line total live as the cashier switches units, and writes the chosen UoM back onto the pos.order.line so it flows correctly into stock moves and invoicing.

Technically, everything is wired to keep a single source of truth for inventory. When a line is sold in a non-base unit, the module converts the quantity to the product's base UoM before the stock.move is created, so one physical stock pool is decremented no matter which unit was rung up — no duplicate SKUs, no drift between the shop-floor count and the accounting count. We load the allowed UoMs and conversion factors into the POS session via the standard _loader_params/load_pos_data hooks so the register works offline, add ir.model.access.csv entries and record rules for any new models, and surface the sold unit on receipts through QWeb and in POS reporting so margin-by-unit is auditable. The build is delivered as a clean, versioned addon with its own __manifest__.py, pinned to your exact Odoo 17.0, 18.0, or 19.0 line and validated against Community or Enterprise as you run it.

Delivery is build-to-order, not an instant download. After a short scoping call we confirm your UoM categories, pricing rules, receipt and reporting needs, and target Odoo version, then send a fixed quote and a UAT plan. Typical delivery is 2–4 weeks from confirmed scope, ending with installation on your staging environment, user acceptance testing, a rollback plan, and a supported go-live. Pricing starts from $249 (indicative, single-company base scope); multi-company registers, custom per-UoM pricelist logic, barcode-per-unit scanning, and integration with existing inventory or loyalty customizations increase the quoted scope.