Most Odoo-run eCommerce teams hit the same wall the moment a product ships in more than one way. Odoo's product.packaging model captures a qty per pack for inventory and purchasing, but the website product page has no native mechanism to surface those packaging choices to a shopper, let them pick one, and price accordingly. So customers who want a single unit, a retail case, a full pallet, or a gift-wrapped presentation all land on the same "Add to Cart" button — and your team fields the "which pack size is this?" emails, corrects orders by hand, and eats the margin on mis-picked packaging. Odoo core out of the box simply does not expose packaging as a customer-facing selection on the storefront, and the standard website_sale variant/attribute flow was never designed to model packaging economics (price-per-pack, minimum order quantity, step rounding).

ECOSIRE builds a made-to-order module that turns packaging into a first-class option on your website. On the product page we render a QWeb/OWL selector — radio cards, a dropdown, or image swatches to your design — driven by the packaging records you already maintain, extended with the website-facing fields your catalog needs: display label, description, image, minimum/step quantity, lead-time note, and a per-packaging price rule. When the shopper selects an option, the choice is carried through the website_sale add-to-cart controller and written onto the sale.order.line, so the selected packaging appears in the cart summary, the quotation, the delivery order, and the invoice PDF. Quantities are validated and rounded to the packaging qty (a "sold in cases of 12" rule enforced client-side in OWL and re-checked server-side), and the unit price is derived through a compute method that respects your pricelists, taxes and currency.

Technically this is a clean, upgrade-safe extension rather than a core patch. We add fields to product.packaging (or a dedicated website.packaging.option link model where a product needs website-only packaging that shouldn't affect purchasing), guard everything with ir.model.access.csv plus record rules for multi-website/multi-company isolation, and expose the selector through inherited website templates so a theme upgrade won't wipe it. Pricing logic lives in @api.depends compute methods with stored fields where performance matters; the add-to-cart path is a controller extension of WebsiteSale so it degrades gracefully if JavaScript is disabled. The same packaging selection is exposed on the JSON-RPC/XML-RPC API, so headless frontends, marketplace connectors, or a mobile app can read and set it exactly as the website does. We target Odoo 17.0, 18.0 and 19.0, and note Community vs Enterprise differences during scoping (for example, whether you rely on Enterprise-only delivery or subscription flows that the packaging choice must feed).

Because this is build-to-order, delivery follows a short, predictable path: a scoping call to lock the packaging data model, selector UX, and pricing rules; a fixed written quote; then a build on a staging copy of your database with UAT before we touch production. Typical delivery is one working week from confirmed scope, depending on how many products carry packaging, your pricing complexity, and integration touchpoints. Pricing starts from $999 (indicative, single-company base scope); multi-company or multi-website isolation, heavy pricelist/tax logic, marketplace or ERP integration of the packaging field, and large catalog data migration increase the quoted scope.