POS Customer Data Checks

POS Customer Data Checks applies customer requirements to the sale being processed. For example, a routine cash sale can allow an anonymous customer while an invoice sale requires a named customer and an email address. Cashiers can correct missing details, review possible duplicate contacts, and continue through the normal Odoo POS payment flow. Managers configure the rules and review exceptions.

This guide was checked against the Odoo 19 source for module corvus_pos_customer_data_guard, release 19.0.1.0.1. It is a source-reviewed guide; the steps and expected results below were not exercised in a running Odoo database during this review.

Before you start

• Use an Odoo installation that supports custom server addons, such as Odoo.sh or private/on-premise hosting. This addon is not compatible with Odoo Online.
• Install the native Point of Sale addon (point_of_sale) and configure a POS, products, and payment methods. No other paid Corvus addon is required.
• The server also needs the Python package xlsxwriter for XLSX exports. Ask the administrator responsible for your Odoo hosting to check this dependency.
• Use a staging database with fictional contacts and test payment methods to verify your rules before applying them to a live POS.
• Back up the database and filestore before installation or an upgrade. Install POS Customer Data Checks from Apps after the addon is available on the server. After an upgrade, refresh POS assets and open a fresh session once queued orders have been accounted for.

Who does what

Role	Tasks in this addon
POS user / cashier	Follows customer identification and correction prompts at checkout; sees the policies available for the POS.
POS manager	Creates and updates policies, configures the POS, reviews and resolves exceptions, and runs reports and exports. Manager approval is subject to server checks for the exact request and the policy's permitted approval group.
Odoo administrator	Installs or upgrades the addon and manages native Odoo access, companies, and server dependencies.

Policy and exception access follows allowed-company rules. Cashiers do not receive access to the exception or approval ledgers. Exception snapshots are retained as an audit trail: managers resolve them through the workflow rather than editing or deleting the original facts.

Set up a policy and POS

1. As a POS manager, open Point of Sale → Configuration → Customer Data Policies and create a policy. Give it a descriptive name, select its company, and keep it active. Restrict Point of Sale Configurations when the rule should apply only to selected POS configurations; an empty selection covers the company's POS configurations.
2. Set Priority. A larger number is considered first. If several policies match, only the first is selected; equal priorities are ordered by record ID. Use distinct priorities when precedence matters.
3. On Triggers, choose the relevant conditions: minimum/maximum order total, invoice or non-invoice, sale or refund, payment methods, products, product categories, pricelists, customer tags, or customer type. Configured condition types must all match. Within payment, product, category, or tag selections, a matching item is sufficient. Amount bounds use the absolute order total, including refunds; a maximum of zero means no upper limit.
4. Choose the customer requirement: Anonymous Allowed, Walk-in or Named, or Named Customer. A named-customer rule does not accept the POS's configured walk-in contact. Anonymous permission does not cancel required-field checks, so leave required fields empty for a truly anonymous policy.
5. On Required Customer Fields, select only the information needed for this policy: name, phone, email, VAT / Tax ID, street, street 2, city, ZIP, country, state, company type, company name, or barcode. Add a short reason cashiers can understand. Configure duplicate checking and manager override only where appropriate to your process.
6. Select Offline Mode: Block, Allow Pending Verification, or Manager Emergency. See the offline section below before choosing.
7. Save and use Test Policy Preview to inspect the priority, customer rule, offline mode, and required-field summary. This button displays a configuration summary; it does not simulate a basket or prove that a transaction will match the policy.
8. Open Point of Sale → Configuration → Point of Sale, select the POS, and find Customer Data Guard. Enable it and select Default Customer Policy. The default must belong to the POS company and include that POS in its scope if restricted. It is a fallback when no policy matches, so make it a deliberate baseline rather than relying on its trigger settings to exclude sales.
9. Optionally select a Walk-in Customer. Use a shared contact or one belonging to the POS company. Set Duplicate Suggestion Limit from 1 to 10, choose the default offline behavior, and save. The form also provides Show Checkout Status.
10. Open a fresh POS session and run the fictional scenario below. With the guard disabled, or with no matching policy and no eligible default, the addon returns a pass result.

Cashier workflow

1. Build the basket and select the appropriate invoice option and payment method. The addon checks customer requirements before payment/order validation; changes to the basket, customer, invoice option, or payment methods can trigger re-evaluation.
2. When identification is required, use the native customer selection flow to choose the correct customer. When an existing customer has missing or invalid required details, follow Fix Customer Data.
3. Enter the requested corrections. The dialog focuses on the configured missing or invalid fields. Email, phone, and VAT checks are basic format checks; passing them does not prove that the contact or tax identifier is real or legally valid.
4. Choose Save and Recheck. If Likely existing customers appears, compare the masked candidate details and match reason. Select a candidate and choose Use Existing Customer, or choose Keep this customer when you have confirmed the corrected contact is distinct. Duplicate matching uses normalized email, phone, VAT, or barcode values among the required fields; it is not a fuzzy search across all customer data. The addon does not merge contacts automatically.
5. Complete the normal POS payment process once the check passes. If the rule cannot be satisfied, involve a POS manager. When permitted by the policy, Manager Override asks for a reason, but it does not provide a separate manager sign-in screen. The server requires an authenticated manager different from the session's cashier. Ask your deployment administrator how that separate manager authorization is made available; do not assume this button alone gives an ordinary cashier a working approval path.

Offline checkout and reconnect

Mode	What the source implements for incomplete data
Block	The offline checkout check stops and asks for a connection.
Allow Pending Verification	Checkout can continue with a pending-verification request for server review after reconnect.
Manager Emergency	The offline client requires the current authenticated manager flag and a reason. A claim without a matching authenticated server approval is preserved as unverified, not recorded as a verified manager emergency.

Local offline checks cannot replace the server's full evaluation. On synchronization, the server evaluates the saved native POS order. An incomplete draft may be rejected, while an already-paid order is retained with the appropriate exception record. Block mode is therefore not a promise that every paid order received by the server will be rejected. Repeated identical synchronization is handled without creating the same audit event again; conflicting replay content is recorded as policy drift.

Keep browser data intact until all queued paid orders are confirmed synchronized. After reconnect, a manager should review the exception queue and the native order's invoice outcome. The addon records whether an invoice exists; resolving an exception does not create or repair an invoice.

Manager follow-up and reporting

1. Open Point of Sale → Orders → Customer Data Exceptions. Use Open, Overrides, or Pending/Offline filters, or group by type, POS, policy, state, or month.
2. Open a record and inspect its linked order and customer, missing/invalid field classes, offline mode, cashier action, invoice outcome, and immutable policy snapshot. Review the Manager Decision / Resolution tab where relevant.
3. Carry out any needed customer or order follow-up through the appropriate native Odoo record. When review is complete, click Resolve. The action records the manager and resolution time; the normal button uses the note “Reviewed by manager.” It does not edit the original snapshot or automatically correct the customer.
4. Open Point of Sale → Reporting → POS Customer Data Quality for the exception list, form, pivot, and graph views. These views analyze recorded exceptions, not a completeness score for every contact in the database.
5. For a file, open Point of Sale → Reporting → Customer Completeness Export. The dialog title is Customer Completeness & Exception Analysis. Select the company, date range, optional POS, and export format, then choose Export CSV/XLSX or Compliance PDF. The output includes exception rows and checked orders without a primary exception, identified by Row Kind. It omits raw customer contact values and includes order, policy, outcome, and resolution information. The period and displayed timestamps use the running user's timezone; exceptions are selected by their recorded date and other included orders by their order date.

Try it with fictional data

Use an isolated staging POS with no competing policies and no live payment provider. This is a suggested acceptance exercise, not a test result from this review.

1. Create a low-priority policy named Training — Ordinary Sale: priority 10, No Invoice, Sale, Anonymous Allowed, no required fields, and Block offline mode. Use it as the POS default.
2. Create Training — Invoice Email: priority 100, Invoice Requested, Sale, Named Customer, required Name and Email, and Block offline mode. Scope both policies to the training POS and company.
3. Create a fictional contact Mira Example without an email. Build a small test basket without an invoice and without a customer. Expected: the ordinary-sale policy does not require customer identification. Other native Odoo checks still apply.
4. Request an invoice and select Mira Example. Expected: the higher-priority invoice policy requires an email and prevents a normal complete validation until the requirement is addressed or an authorized exception path is used.
5. Enter mira.example@example.test in the correction flow and recheck. Expected: this addon's basic email format check passes, and its missing-email condition clears. Complete only a staging payment if you want to verify the whole native transaction.
6. While still online, prepare and select another incomplete fictional contact for a new invoice basket, then disconnect before validation. Expected with Block: checkout asks for a connection. Reconnect and correct the data. Do not clear browser storage as a troubleshooting step.

For pending or emergency modes, run a separate staging exercise with the manager who will own follow-up, then inspect the resulting order and exception after reconnect. Verify the recorded outcome rather than assuming approval or successful invoicing.

Troubleshooting

Symptom	What to check
No customer prompt appears	Confirm the guard is enabled, the policy is active, the company and POS scope match, and no higher-priority rule wins. Review the fallback policy and open a fresh POS session after changes.
Unexpected rule applies	Check all trigger conditions, priority, and the default policy. The default can apply when none of the trigger-based policies match.
Customer data remains incomplete	Complete the fields named by the dialog. A configured walk-in contact cannot satisfy Named Customer. Required email, phone, or VAT values can also fail basic format checks.
“Customer verification requires a connection.”	Reconnect the POS. The matching offline behavior is Block; preserve queued orders and browser data.
Possible duplicate appears	Review the masked candidate and choose the correct contact. This is a warning signal, not proof of identity or an automatic merge.
Manager approval fails	Confirm a separate authenticated POS manager is authorizing the exact unchanged request, with a reason and the policy's permitted group. Do not treat a local offline manager claim as server approval.
Exception or export menu is unavailable	Confirm POS manager access and the allowed company/POS scope.
Paid order has a customer-data exception	Review the native paid order, missing data, cashier action, and invoice outcome. Complete follow-up, then resolve the exception; do not delete the retained audit record.

Limitations and version coverage

The addon does not provide KYC, identity-document verification, SMS/email OTP, external address or phone validation, credit-limit/debt controls, automatic contact merging, marketing-consent management, or a universal legal/tax compliance guarantee. It complements normal Odoo checkout and invoicing; native transaction requirements still apply.

The product versions in scope are 15, 16, 18, 19, and 20. This page's field labels, menu paths, and workflow details were inspected only in the Odoo 19 source. Parity, installation, browser behavior, and runtime acceptance on the other versions were not verified for this guide. Use the package for your exact Odoo major version and check its corresponding instructions before deployment.

Demo and support

The manifest's Live Test link points to a video: watch the product demonstration. Its exact URL is source-confirmed; playback was not checked in this review. It is not an interactive test database.

View the Odoo 19 purchase listing, verified to resolve to POS Customer Data Checks on 28 October 2026. For product support, contact Corvus Nexus or email support@corvusnexus.com. Include your Odoo version and edition, module version, role, POS configuration, connectivity state, and sanitized reproduction steps when reporting an issue.

Interactive Live Test entry

Open the Odoo 19 Live Test selection. The catalogue entry and selection-link format were checked on 28 October 2026. No demo was launched and no customer workflow was tested for this guide. Review the selected module and Odoo version before continuing.