POS Receipt & Invoice Designer

Key Features

New `pos.receipt.template` model (models.Model) with header/body/footer block fields, linked Many2one to `pos.config` for per-store resolution

Extended OWL `OrderReceipt` component + XSS-safe QWeb template so configured blocks render in your chosen order without patching core

QR code block with `@api.depends` compute generating a base64 image for loyalty URLs, feedback forms, or e-invoice payloads

Logo, social-handle, and promotional footer blocks with per-block visibility toggles

Bilingual and multilingual receipt text using Odoo's translation layer plus per-block language fields (Arabic/English, Chinese/English, etc.)

Inherited `account.move` QWeb invoice report mirroring the same branding, header/footer, and QR for print-consistent invoices

Per-store / per-POS-config templates so different outlets print different footers, promos, and compliance blocks

Configurable paper width handling for 58mm/80mm thermal roll printers and A4 invoice output

Automated action / server action hook to swap the active template on a schedule (e.g. seasonal promo footers)

`ir.model.access.csv` access rights + record rules so only authorized roles edit templates

Full template read/write over XML-RPC and JSON-RPC for headless or multi-database configuration

Field-level conditional rendering (show tax/VAT lines, fiscal position notes, or e-invoice hash only when required by your `l10n_*` localization)

RTL-aware layout so Arabic/Urdu receipts print correctly alongside Latin-script content

Live preview of the receipt/invoice template from the settings form before it reaches the printer

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Odoo.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

Odoo's Point of Sale ships a fixed receipt layout and a standard account.move invoice report, which is fine until your brand, your tax authority, or your marketing team needs more. Out of the box you can change the logo and a header/footer string in POS settings, but you cannot reorder blocks, add a loyalty or feedback QR code, print a compliant bilingual receipt, or run different footers per store. Restaurants and retailers routinely hit this wall — the ORL (OWL) receipt component and the QWeb invoice report are hard-coded, so any real change means patching core templates, which then breaks on the next upgrade. That is exactly the gap this module closes.

ECOSIRE builds a dedicated pos_receipt_designer module that introduces a configurable template model — a models.Model (e.g. pos.receipt.template) with fields for header, body, and footer blocks, logo, social/promo content, language behavior, and QR payload rules — linked by Many2one to pos.config so each store or POS session resolves its own template. On the receipt side we extend the OWL OrderReceipt component and its XSS-safe QWeb template so your configured blocks render in the exact order you set, with computed fields (@api.depends) generating the QR image (loyalty URL, feedback form, or e-invoice payload) as a base64 field. On the invoice side we inherit the account.move QWeb report to mirror the same branding, headers, and QR. Bilingual and multilingual text uses Odoo's translation layer and per-block language fields so an Arabic/English or Chinese/English receipt prints side by side. Everything is governed by proper ir.model.access.csv entries and record rules, and template data can be read or pushed through the standard XML-RPC/JSON-RPC API for headless configuration.

Because this is build-to-order, we scope to your Odoo edition and version first. The module targets Odoo 17.0, 18.0, and 19.0, and we handle the differences between them (the POS front-end moved substantially across these releases) plus Community vs Enterprise nuances — e-invoice/QR requirements and localization reports differ, and we align the design to whatever l10n_* localization you run. Nothing depends on Enterprise-only apps unless your compliance target requires it, in which case we tell you up front.

Delivery is straightforward and honest: this is not an instant apps.odoo.com download. After a short scoping call we confirm the exact receipt and invoice layouts, QR use-cases, languages, and per-store rules, then build against your version. Typical delivery is 2–4 weeks from confirmed scope. You get the installable source, a UAT pass on a staging database with a rollback plan, install and configuration on your environment, documentation, a training session, and a post-go-live support window. The full git repository is handed over to you at the end — you own the code.

What you get

Installable module source code built for your exact Odoo edition and version (17.0 / 18.0 / 19.0)

Installation and configuration on your staging and production environment

Technical documentation (models, fields, template resolution logic, QR payload configuration)

End-user guide plus a live training session for cashiers and admins

UAT on a staging database with a documented rollback plan before go-live

Post-go-live support window for defects and configuration questions

Full git repository handover — you own the code

Version-compatibility notes covering Community vs Enterprise and localization dependencies

Who this is for

Multi-outlet retailer

Runs several stores on one Odoo database and needs each `pos.config` to print its own branded footer, promo, and loyalty QR while keeping one consistent invoice layout across all outlets.

Restaurant / QSR operator

Wants a clean branded thermal receipt with a feedback or review QR, order/table details, and a social-handle footer — plus a matching A4 invoice for corporate customers.

Compliance-driven business in a bilingual or e-invoice market

Operates in a region requiring bilingual receipts (e.g. Arabic/English) and QR-based e-invoice or tax data, and needs the receipt and invoice to satisfy the local `l10n_*` and tax-authority format.

Odoo administrator / franchise IT lead

Manages templates centrally, wants clean access rights via record rules, and needs to push template configuration to many databases through the XML-RPC/JSON-RPC API rather than editing each store by hand.

How POS Receipt & Invoice Designer Compares

Criterion	ECOSIRE	Custom Build	Competitor
Receipt layout control	Full drag/configure of header, body, footer blocks per store	Whatever you build; depends on your team's OWL/QWeb skill	A few preset layouts, limited reordering
QR codes (loyalty/feedback/e-invoice)	Compute-generated QR block with configurable payload	Possible but you design the payload logic yourself	Often single fixed QR type, if any
Bilingual / multilingual receipts	Per-block language fields + Odoo translation layer, RTL-aware	Achievable with effort; RTL often missed	Rarely true side-by-side bilingual
Per-store templates	Template linked Many2one to each `pos.config`	You build the resolution logic	Usually one global template
Invoice consistency	Inherited `account.move` QWeb report matches receipt branding	You maintain both templates separately	POS-only; invoice untouched
Upgrade safety (17/18/19)	Inheritance-based, targeted to your version, support window	Risk depends on how core was patched	Depends on vendor's version cadence
Ownership & code handover	Full git repository handed to you	You own it, and you built it	Licensed binary/obfuscated; no repo
Fit to your compliance / branding	Scoped to your `l10n_*`, tax format, and brand	Exact fit but full cost and timeline on you	Generic; may not match local rules

Frequently Asked Questions about POS Receipt & Invoice Designer

How long does delivery take?

This is a build-to-order module, not an instant download. After a short scoping call to confirm your receipt/invoice layouts, QR use-cases, languages, and per-store rules, typical delivery is 2–4 weeks from confirmed scope. Tighter or larger scopes shift that estimate, and we tell you honestly before you commit.

Which Odoo versions and editions do you support?

We build for Odoo 17.0, 18.0, and 19.0, on both Community and Enterprise. The POS front-end changed significantly across these releases, so we target the module to your exact version. If your compliance goal needs an Enterprise-only or localization app, we flag that up front.

How do you handle updates and support after go-live?

Every build includes a post-go-live support window for defects and configuration questions. Because you receive the full git repository, you own the code and can maintain it yourself, or engage ECOSIRE for version upgrades and enhancements as your needs grow.

Can it print bilingual receipts and QR-based e-invoice data?

Yes. Bilingual and multilingual text uses Odoo's translation layer plus per-block language fields, and the QR block can encode a loyalty URL, a feedback form, or an e-invoice/tax payload as required by your local `l10n_*` localization. We confirm the exact format your tax authority expects during scoping.

Will this break when I upgrade Odoo?

We avoid patching core files. The module extends the OWL receipt component and inherits the `account.move` QWeb report through Odoo's standard inheritance mechanisms, which is the upgrade-safe approach. A major-version jump can still need a review, and that is exactly the kind of work the support window and git handover cover.

Can different stores print different receipts?

Yes. Templates are linked by `Many2one` to `pos.config`, so each store or POS session resolves its own header, footer, promo, and QR blocks while you keep a single consistent invoice layout across the business.

Can we configure templates programmatically across many databases?

Yes. The template model is exposed through Odoo's standard XML-RPC and JSON-RPC API, so a franchise or multi-database operator can read and push template configuration headlessly instead of editing each store's settings by hand.