Analysts and finance teams on Odoo constantly hit the same wall: the reporting they actually need spans several models — sale orders joined to invoices joined to stock moves joined to analytic lines — but Odoo's native pivot, list, and graph views only report on one model at a time. The out-of-the-box workarounds are painful: build a fragile computed model, wire up dozens of related/compute fields, export to a spreadsheet and reconcile by hand, or push everything into an external BI tool and re-implement your access rules there. Meanwhile the SQL that answers the question already exists in someone's psql session — it just has nowhere to live inside Odoo where the business can safely use it.

The SQL BI View Editor closes that gap. We build a module that lets your team define a business intelligence dataset as a SQL statement and register it as a first-class, read-only Odoo model backed by a real PostgreSQL view. Under the hood each definition maps to a models.Model with _auto = False whose init() runs a CREATE OR REPLACE VIEW for standard (always-live) views, or a CREATE MATERIALIZED VIEW with a scheduled REFRESH for heavy aggregations that you would rather compute on a cron. The declared columns become proper Odoo fields — Integer, Float, Char, Many2one, Date, Datetime, Selection — so the dataset instantly gains pivot, graph, list, and search views, group_by/measure behaviour, and XLSX export, with no bespoke reporting UI to maintain.

Governance is built in, because a raw SQL surface inside an ERP is a liability if it is ungoverned. Every generated model ships with ir.model.access.csv entries and optional ir.rule record rules so a view can be scoped by company, department, or user group, and multi-company datasets respect company_id filtering. Definitions are edited by a restricted authoring group only; the resulting views are read-only to everyone else. We validate each statement against a SELECT-only allowlist so authors cannot smuggle DML into a definition, register the view against the correct database cursor, and (for materialized views) create the supporting indexes and a REFRESH MATERIALIZED VIEW CONCURRENTLY-safe unique index where the workload calls for it. Refreshes can be triggered by ir.cron, by an automated action, or on demand from a button. Because the datasets are ordinary models, they are reachable over XML-RPC/JSON-RPC and can feed a downstream BI/dashboard tool through Odoo's own authenticated API rather than a direct database connection.

Delivery is build-to-order: this is not an existing apps.odoo.com download. We start with a short scoping call to inventory the reports you need, the source models and joins involved, your Community-vs-Enterprise edition, target version (17.0, 18.0, or 19.0), and multi-company/localization requirements. We then build your version of the module, prove it on a staging database with your data volumes, run UAT with your analysts, and deploy with a rollback plan. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope); the number and complexity of source views, multi-company/record-rule depth, materialized-refresh scheduling, and data-migration or historical-backfill volume increase the quoted scope. You receive a fixed quote after the scoping call.