The problem this app solves

An ordinary walk-in sale and an invoice or refund do not always need the same customer information. Collecting everything at every checkout slows the cashier down, while collecting too little can leave a later correction queue for the office.

Apply conditional data policies to the sale and show only the missing or invalid fields. Cashiers can resolve duplicate signals without automatic merging, and permitted manager exceptions remain connected to the exact checkout context.

Features that support your daily work

• Conditional rules. Prioritize policies by POS, company, amount, invoice/refund state, payment method, product, pricelist, customer tag, and customer type.
• Only missing fields. The native customer flow opens a touch-friendly correction dialog with the configured missing or invalid fields and its reason.
• Duplicate-safe choice. Normalized phone, email, VAT, and barcode signals show masked candidates so the cashier can select an existing contact without auto-merging.
• Server-enforced. Policy evaluation, company scope, correction whitelist, manager approval, replay detection, and immutable audit fields are checked on the server.
• Paid offline safety. Block, Pending Verification, and Manager Emergency outcomes preserve paid orders and create truthful follow-up exceptions for reconnect.
• Operational reporting. Manager-only queue, pivot/graph views, sanitized PDF, and CSV/XLSX analysis show missing-field classes, overrides, offline state, and resolution.

A practical example

Illustrative workflow — the available actions depend on your configuration.

A policy allows an anonymous cash sale but requires tax details for an invoice. When invoicing is selected, the cashier sees the missing fields, checks any duplicate candidates and corrects the customer or requests an authorized exception.

How a guarded checkout works

1. A manager enables the guard and prioritizes ordinary-cash, invoice/card, and refund policies.
2. The cashier completes a lightweight anonymous or walk-in cash sale where allowed.
3. A triggered sale asks for a customer and opens Fix Customer Data with only missing or invalid fields.
4. A duplicate signal shows masked candidates; the cashier selects an existing contact or confirms a distinct record.
5. A different authenticated manager can approve the exact exception, leaving an immutable audit trail.
6. Paid offline orders synchronize safely and create pending or drift follow-up instead of being discarded.

Built for controlled operations

Find policies under Point of Sale → Configuration → Customer Data Policies, exceptions under Point of Sale → Orders → Customer Data Exceptions, and reporting under Point of Sale → Reporting.

The release includes a compliance PDF plus access-safe CSV/XLSX analysis. Raw phone, email, VAT, and address values are intentionally omitted.

See the workflow in Odoo

Explore the screens in sequence, from configuration to daily work and reporting. Each image includes a caption explaining its place in the workflow.

Customer Data Policies list with prioritized rules Customer Data Policy form with triggers and required fields Manager Customer Data Exceptions queue Immutable customer-data exception detail and audit snapshot Customer Completeness and Exception Analysis export wizard Customer-data exception rows used by the compliance analysis export

Compatibility and deployment

Odoo series: 15.0 Edition: Community and Enterprise

Dependency: point_of_sale

Deployment: Odoo.sh and private/on-premise hosting. Not compatible with Odoo Online.

No other paid Corvus Nexus module is required. Use the package built for your exact Odoo series.

Deliberate limits

• No KYC or identity-document verification
• No SMS/email OTP or external validation API
• No credit-limit or debt-collection control
• No automatic contact merge
• No universal legal/tax compliance guarantee
• No marketing-consent platform