Data Guard

Protect data, not block operations — ORM-level document protection for Odoo 19

The Problem

Odoo lets users freely edit Sales Orders after delivery, modify Purchase Orders after receipt, reset posted invoices to draft, and reset payments to draft even within a locked fiscal period — creating silent data mismatches between your orders, warehouse, and books.

You need protection that guards the data without locking down your workflow.

Two Anchors, One Guard

Data Guard uses two different anchoring strategies tailored to how each business area actually operates:

• Sales & Purchase Orders — anchored on actual delivered / received quantity per line.
• Accounting documents — anchored on the fiscal lock date.

Daily operations stay free and unobstructed, while improper edits to completed data are blocked at the ORM level — not just hidden in the UI.

Settings

One toggle in General Settings. Enable to activate all protections. Disable temporarily for administrator-level corrections, then re-enable. No module reinstall required.

Sales & Purchase Order Protection

Protection is per-line, based on actual stock movement quantity (qty_delivered / qty_received). Only lines with qty > 0 are locked. Cancel, reset to draft, adding new lines, and editing undelivered lines remain fully available. If a warehouse return brings the qty back to zero, protection lifts automatically.

Per-line protection matrix

Stock Picking Source Enforcement

Receipts and deliveries containing storable products must originate from a Purchase Order, Sales Order, or a valid return. Manual pickings without a source document are blocked at validation — so every physical movement stays anchored to an order, which is what makes the invoiced-vs-physical gap below meaningful. Consignment receipts (with an Owner assigned) and internal transfers are exempt.

Return Limitation

Repeated returns on the same document are a common source of phantom stock and cascading data errors. Data Guard enforces two strict rules to prevent this:

Journal Entry & Invoice Protection

Posted invoices, bills, and credit notes within the fiscal lock period cannot be reset to draft. Invoices and bills also show a warning banner and list highlight when a line links to an order carrying a quantity gap (see below).

Invoiced-vs-Physical Quantity Gap

Every physical movement is anchored on an order; every anchored quantity should have a posted invoiced counterpart. The number in between is suite_qty_gap — a stored, signed quantity gap on each order line, anchored on the stock side:

• purchase.order.line: posted billed qty − qty_received
• sale.order.line: qty_invoiced_posted − qty_delivered

computed for stock-tracked products only. Posted invoices only: under Odoo 19 perpetual valuation the inventory GL entry is created “at invoicing” (when the bill is posted, not when goods move), so a draft bill posts no GL and must not close the gap — otherwise “goods shipped, bill sitting in draft” would silently read zero. The Sales side reuses Odoo’s native qty_invoiced_posted; the Purchase side has no native posted-only field, so the module builds one. Apart from that single documented exception it subtracts native fields and never re-aggregates, and never branches on the billing-control policy. The gap is a raw signed number, never summed or absolute-valued.

Severity keys on physical completion, not on quantity. A line is complete when no stock move on it is still pending (every move done or cancelled) — exactly how Odoo’s own receipt/delivery status works. Until then a gap is normal “in transit”; once complete it is structural, because only a document can still close it.

Order lists colour only the structural (red) statuses — open exposure is left uncoloured so red keeps its signal value. The order line shows the signed gap so you can pinpoint the offending line. Saved filters drive a month-end worklist: over-invoiced, received-not-billed / delivered-not-invoiced, plus an “open exposure > 30 days” ageing filter for in-transit gaps that have sat too long. The invoice or bill shows a single uniform yellow heads-up banner that fires only for a structural gap on the linked order — which another invoice on the same order may have caused — so always open the order to locate the exact line and direction. Because the invoice-side flag is non-stored, it is read on demand per displayed row and triggers no whole-database recompute on receipts, deliveries or returns. Price differences (bill price vs order price) are intentionally not checked — under AVCO/FIFO the bill price becomes cost and the stock move is re-valued, so GL and subledger stay in sync.

Payment Protection (Native Gap Fix)

Odoo 19 decoupled payments from journal entries — native lock dates do not prevent resetting a payment to draft. This module closes that gap: any non-draft, non-canceled payment within the lock period cannot be reset to draft (covers in_process, paid, and rejected states).

Bank Statement Reconciliation Guard

Deleting a reconciled bank statement transaction with the ordinary delete action only removes the line’s own journal entry — it does not undo the reconciliation. The matched payment or invoice keeps its reconciled state while its counterpart entry vanishes: the payment reverts to “in process” and is orphaned, and the invoice stays flagged as paid against a move that no longer exists. Native Odoo only blocks deleting a line inside a valid, complete statement, so a bare reconciled line slips through.

Data Guard blocks deletion of any reconciled transaction (full or partial, or one carrying an auto-generated payment) and asks you to undo the reconciliation first — the Reset button cleanly reverses the match and removes auto-generated payments. Un-reconciled lines can still be deleted freely.

Lock Date Protection & Dashboard

All five lock date fields are protected while Data Guard is enabled: fiscalyear_lock_date, tax_lock_date, sale_lock_date, purchase_lock_date, hard_lock_date.

Only users in the dedicated "Data Guard: Manager" group can modify these fields. This group is domain-neutral and independent — it is NOT inherited by any accounting or inventory role and must be assigned explicitly. A Lock Date Dashboard under Accounting > Configuration shows all current lock dates in one place; its menu is restricted to the group and nested under Accounting, so a user without accounting access never sees it.

Full Protection Summary

Key Features

• ORM-level protection — while enabled, applies to every user through UI, API calls, and imports alike; only an administrator can turn it off
• Per-line granularity — only lines with actual stock moves are locked
• Auto-unlock on return — qty back to zero lifts all protection
• Stock Picking source enforcement for storable products
• Return limitation — one return per document, no return of return
• Invoiced-vs-physical quantity gap — signed, stock-anchored, colour-coded worklist on SO/PO orders
• Bank statement reconciliation guard — can’t delete a reconciled line and orphan its payment/invoice
• Multi-company aware — each company uses its own lock date
• All 5 lock date fields protected with dedicated manager group
• Lock Date Dashboard for at-a-glance status
• Global on / off toggle in Settings
• Zero dependencies beyond native Odoo modules

Why Not Just Hide the Buttons?

Many "protection" modules simply hide UI elements with CSS or view inheritance. Users can still modify data via API calls, imports, automated actions, or developer mode. Data Guard operates at the ORM level — write(), unlink(), and action methods are intercepted before any change reaches the database, so while protection is enabled the rules hold for every user across every channel.

Turning protection off is itself an administrator action — the Settings toggle, or the suite_force_unlock context. Like any ORM-level control it can be disabled by someone with system-administrator rights; that is a deliberate, auditable escape hatch, not a loophole a regular user, an import, or an automated action can reach on its own.

Technical Notes

• No new models — pure _inherit on existing Odoo models.
• No scheduled actions, no background jobs, no performance overhead.
• Protection is synchronous and immediate on every write / unlink / action.
• Dependencies: sale_stock, purchase_stock, account, account_payment, stock (all native Odoo).
• Compatible with Odoo 19.0 Community and Enterprise.
• Emergency bypass: pass suite_force_unlock: True in ORM context.

License & support

Licensed under OPL-1 (Odoo Proprietary License v1). Maintained by SuiteState (ElectroState FZCO). For questions, bug reports, or feature requests, visit suitestate.com or contact hello@suitestate.com.