Retail and F&B operators live and die by promotions, but the moment your offers get real — buy-2-get-1 on a specific category, a happy hour that only runs 4-7pm on weekdays, a mix-and-match "any 3 for the price of 2," a lunch bundle priced below the sum of its parts — Odoo's native tooling starts to fight you. Community POS ships basic price lists and a manual per-line discount button; even Enterprise's loyalty/promotions programs cover coupons and simple reward tiers but leave gaps around time-windowed pricing, category-scoped BOGO, deterministic "best offer wins" resolution, and clean stacking rules. The result is cashiers punching manual discounts (which nobody audits), promos that don't stop at their end time, and margin quietly leaking at the register.

This is a build-to-order module ECOSIRE develops and installs on your instance. At its core is a promotion.rule model (models.Model) that stores each offer as structured data: trigger conditions (product, product.category, minimum quantity, minimum subtotal), a time window (day-of-week mask plus start/end times for happy-hour), a reward definition (percentage, fixed amount, free-line, or override price for BOGO/bundle), and stacking flags. Eligibility is evaluated against the live order using computed fields (@api.depends on order lines and quantities), and a resolver applies the single best-value promotion — or the allowed combination when your stacking rules permit — so two competing offers never double-discount by accident. Everything runs inside the POS session so it works offline and re-syncs, with the reward reflected as an explicit discount line the receipt and Z-report can account for.

Technically, the module is a normal Odoo addon: a __manifest__.py declaring dependencies on point_of_sale (and pos_loyalty where we extend rather than replace it), server-side Python models plus OWL/JS extensions to the POS front-end so promotions apply on the screen in real time, and QWeb receipt templates updated to print the applied offer name and savings. Access is locked down with ir.model.access.csv and record rules so only managers create or edit rules while cashiers only consume them; an optional automated action (ir.cron/base automation) can auto-activate and expire seasonal campaigns by date. Because promotions are ordinary records, they're fully reachable over Odoo's XML-RPC/JSON-RPC API for reporting or external campaign tools. We build for your exact edition — Community or Enterprise — and target Odoo 17.0, 18.0 or 19.0, matching the POS framework version you actually run.

Delivery is build-to-order, not an instant download. It starts with a short scoping call where we capture your promotion types, category structure, stacking policy and edge cases (loyalty interaction, refunds, split payments), then we confirm scope and price in writing. From confirmed scope, typical delivery is one working week: we develop against a staging copy of your database, run UAT with your real product catalog, hand over installable source and a git repository, train your managers and cashiers, and stand by through a post-go-live support window. No fabricated benchmarks or borrowed testimonials — just a module engineered to your promotion rules and your Odoo version.