Retailers and grocers live or die by their labels. Odoo core ships a basic "Print Labels" action on product.template that pushes a fixed 2x7 or 4x7 QWeb sheet of name-price-barcode tags, but it runs out of road fast: you cannot brand the layout, you cannot add a shelf-edge or price-tag format, you cannot generate EAN-13 embedded-price barcodes for weighed items, and there is no clean way to fire a batch of the right labels straight off an incoming purchase receipt. Teams end up exporting to spreadsheets, wrestling with third-party label software, or reprinting the whole product list just to relabel one shelf — every one of those is a place where prices drift out of sync with the POS.

POS Barcode & Label Printing Studio is a module we build to close that gap on your catalog and your hardware. At its core is a label.template model (models.Model) that stores reusable layouts — element positions, fonts, which fields to show (list_price, barcode, name, default_code, UoM, currency), and the physical media size — rendered through parameterized QWeb reports so the same template drives a 40x30mm price tag, a 100x50mm shelf-edge strip, or an A4 sheet of die-cut labels. Barcodes are generated server-side (Code128, EAN-13, EAN-8) with proper check-digit computation, and for weighed goods we implement the EAN-13 embedded-price convention (2 prefix + PLU + weight/price payload + check digit) so a scale-printed sticker scans correctly at the register. A compute layer (@api.depends on price and currency) keeps the printed price bound to the same field the POS reads, so a label can never quietly show a stale figure.

Operationally, the module adds a "Print Labels" server action wired into the product.template/product.product list view and, on request, onto the stock.picking receipt flow — select an incoming PO's move lines and print exactly the received quantities in one pass, no manual counting. A wizard lets the operator pick the template, quantity-per-product (or "one per unit received"), and the target printer size before rendering. We support multiple label printers and media sizes by mapping each label.template to a paper format and, where you use dedicated thermal units (Zebra/TSC/Brother), routing through your print server or ESC/POS/ZPL path rather than the browser dialog. Access is locked down with ir.model.access.csv plus record rules so only authorized roles can edit templates or trigger bulk runs, and an optional automated action can queue a relabel batch whenever a price changes. Everything is reachable over Odoo's XML-RPC/JSON-RPC API too, so an external scale, WMS, or scheduled job can request labels programmatically.

Because this is build-to-order, nothing is pre-listed on apps.odoo.com — we scope it to your exact label stock, printer models, barcode conventions, and Odoo edition first. After a short scoping call we confirm the template set, the media sizes, and whether you need the PO-receipt and price-change triggers, then build against your target version (17.0, 18.0, or 19.0) on a staging database. Typical delivery is one working week from confirmed scope. You get the installable source, a UAT pass on staging with a rollback plan, install and configuration on your environment, documentation, a training session, and a post-go-live support window — all delivered and maintained by ECOSIRE. Community and Enterprise are both supported; we flag anything that depends on Enterprise-only stock or barcode features during scoping so there are no surprises.