In a busy checkout, the standard Odoo POS product grid shows a product image and name on each card but not the price. Cashiers either memorize prices, keep a printed sheet at the till, or tap into a product and read the price from the order line after adding it — which slows service, invites wrong-item entries, and makes price checks for walk-up customers awkward. Odoo core has no setting to surface the price on the card itself; the POS UI (an OWL/JavaScript front end backed by pos.session data) is deliberately minimal, and the price a customer actually pays depends on the active pos.config pricelist, taxes, and the product.template/product.product list price. There is no supported click-to-configure toggle for this, so teams reach the limit of what native Odoo can do without development.

What we build is a focused POS front-end extension that renders the price on every product card in the selection grid. We patch the OWL ProductCard (and the product screen component that lays out the grid) to read the correct unit price from the loaded product and pricelist data already present in the POS session, then display it in a styled badge on the card. Because the price shown must match what lands on the order line, we resolve it through the same pricelist logic the POS uses at add-time — honoring the pos.config assigned pricelist, unit of measure, and your tax-display preference (tax-included vs tax-excluded, following the POS iface_tax_included setting). Currency formatting uses the session currency so decimals and symbols render exactly as your receipts do. The behavior is configurable: we expose settings on pos.config (for example, show/hide the badge, choose tax-in or tax-out display, and optionally show a strikethrough of the original price when a pricelist discount applies) so different registers can behave differently without code changes.

Technically this ships as a proper module with its own __manifest__.py declaring a dependency on point_of_sale, an assets bundle registered under point_of_sale.assets (or assets_backend for the config fields), OWL component patches plus QWeb template inheritance for the card markup, and any config fields added to pos.config with matching res.config.settings view inheritance and ir.model.access.csv entries. It is built cleanly for your exact Odoo series — 17.0, 18.0, or 19.0 — because the POS front end changed meaningfully across those releases (asset bundles, OWL component structure, and the store/session data model differ), and we target Community or Enterprise as you run it. No changes are made to accounting, pricing rules, or order posting — this is a display layer over data the POS already loads, so performance impact on the grid is negligible.

Delivery is build-to-order: ECOSIRE builds, installs, and supports this after you request a quotation — it is not an existing download. We start with a short scoping call to confirm your Odoo version and edition, how you want the price computed (which pricelist, tax display, multi-currency behavior), and any per-register differences. Typical delivery is one working week from confirmed scope, including UAT on a staging copy of your database before we touch production. Pricing starts from $999 (indicative, single-company base scope); multi-company setups, multiple pricelists or complex tax display rules, additional register-specific behaviors, and cross-version builds increase the quoted scope. You receive a fixed quote after the scoping call, never a surprise invoice.