Skip to main content

POS Barcode Aliases

Purpose​

POS Barcode Aliases connects Multiple Product Barcodes to Odoo Point of Sale. Cashiers can scan a product's effective alternative codes. A packaging alias supplies its configured quantity converted into the product unit. The integration preserves native barcode lookup before attempting the alias fallback.

This is a helper addon with no standalone application, configuration menu, or alias-maintenance screen. Maintain aliases through the base addon in Inventory; use them through the normal POS product screen.

Before you start​

Use the bridge matching your Odoo major version. It depends on corvus_product_barcode_alias and point_of_sale and is marked for automatic installation when its dependencies are installed. The manifest declares no Enterprise-only dependency. Confirm that your administrator has installed the matching bridge and its POS assets.

The product must be enabled for sale and available in POS, and must meet the POS configuration's product/category restrictions. Each alias must belong to the POS company, be active, and be within its effective dates. Configure packaging quantity and a convertible unit in the base addon before opening POS.

The workflow is source-reviewed for 19.0, with selected version differences below. No live POS session or physical scanner was tested for this guide.

Access and roles​

POS users can load the bridge's restricted alias payload when they can read the POS configuration and its company is active for them. Alias and product access rules still apply. The payload contains the normalized lookup code, product relation, packaging flag, converted quantity, and priority. Vendor details, manager notes, conflict text, and audit data are excluded.

Cashiers do not gain alias-editing rights. An Inventory Administrator maintains the aliases and resolves conflicts through the base addon.

Setup and workflow​

  1. In Inventory, create an active alias for an eligible product and the same company as the intended POS. Check its effective dates. For an identity code, leave packaging details unset; for a packaging code, supply the required quantity and unit.
  2. Open or reload the normal POS interface after changing alias configuration so it can load the applicable data. The 19.0 bridge filters aliases when POS data is loaded. Do not assume a long-running browser session immediately receives every back-office change.
  3. Scan the product's ordinary barcode to confirm the native product selection, then scan its alternative code. If native lookup has no match, the bridge normalizes the scan and searches loaded aliases. A single permitted product is the expected result.
  4. Inspect the order line. An identity alias adds the product through the normal POS add-product flow. A packaging alias supplies its converted quantity, so a six-unit package should add six product units when configured accordingly. Review the quantity before continuing the normal sale workflow.
  5. If the scan is ambiguous, stop and ask an Inventory Administrator to inspect the code in the base addon's conflict tools. In 19.0 the product screen shows “This barcode alias is ambiguous. Ask an Inventory Administrator to resolve it.” A code with no eligible match follows the normal not-found notification path.

Product search also includes alias matching through version-specific POS search extensions. Search behavior and product loading are separate from physically scanning a code, so check both in your own version when preparing a rollout.

Practice scenario​

In an authorised test database, give fictional product “Cedar Tea 250 g” an Internal alias CEDAR-TEA. Mark the product available in POS and use the POS company on the alias. Open a test POS interface, scan the native barcode, remove that test line, and scan CEDAR-TEA. The source-derived expectation is the same product selection. Repeat with a correctly configured packaging alias and inspect its quantity without completing a payment. This scenario was not executed.

Troubleshooting and limitations​

For an unrecognised code, check the bridge installation, POS assets, product eligibility, company, alias state, and effective dates, then reload the POS data. Category restrictions can prevent a valid Inventory alias from being loaded into a particular POS.

The bridge resolves only the aliases it has loaded. It does not expose manager-only maintenance data or remove product restrictions. It contains no separate per-scan server usage-count call, so the base addon's usage count is not a cashier scan audit. Offline operation and immediate expiry of aliases already loaded in a browser are not established by this review.

Qualified catalogue versions are 15.0, 16.0, 18.0, 19.0, and 20.0. A 17.0 source package exists but is not a qualified live-demo pair in this batch. Versions 15–17 use older POS loading/search integrations. Version 18 includes descendants of configured POS categories in its alias-loading filter, whereas the inspected 19.0 filter uses the configured category IDs directly. Version 20 adds a forced alias refresh on reconnect and removal of ineligible cached aliases; it also adapts product additions to the newer POS workflow. Use the build for your major version.

  • Multiple Product Barcodes covers setup, permissions, imports, replacement, and conflict resolution.
  • Live Test selector — Odoo 19 is confirmed as a qualified module/version pair in the current public catalogue; no demo was launched for this review.
  • Corvus app catalogue: select your exact version and confirm the base addon and bridge package requirements. A direct purchase page was not verified.