Reports are one of the most common customization requests in any Odoo rollout, and one of the most commonly misfired. A manager asks for "a sales report by region", a developer builds something, and the result answers a slightly different question than the one in the manager's head. The fix is not more meetings. It is being clear, up front, about what kind of report you actually need and what it has to prove.
First, check whether you need a customization at all
Odoo ships with more reporting than most teams use. Almost every list in the system can be grouped, filtered, and switched to a pivot or graph view, and a useful combination can be saved as a favorite and shared with colleagues. Before asking for anything new, try this test: can you get the numbers you want by filtering and grouping an existing list? If yes, you need a saved view and ten minutes of training, not development.
If the answer is "almost, but the field I need is not there", that is a real gap, and it points to the first of three types of request.
The three things people mean by "report"
- Missing data. The analysis is simple, but the value you want to group or sum by does not exist on the record. Examples: a sales channel on the order, a cost center on the vendor bill, a product family that is not a category today. The customization is a field (and the rules for filling it), after which standard pivots do the reporting.
- An analytical view. The data exists but lives across several models, or needs a calculation Odoo does not do out of the box, such as margin after landed costs per customer, or collection days by salesperson. This is a proper report built on a dedicated query or computed fields.
- A printed document. Quotations, invoices, delivery slips, and statements that go to customers or authorities. Here the concern is layout, language, and legal content, not analysis.
Naming which of the three you want changes the whole request. A missing field is usually the smallest and most durable change. An analytical report needs careful definitions. A printed document needs attention to what must not be removed.
What a good report request contains
Whichever type it is, the request should answer these questions in plain language:
- Who reads it, and what decision does it support? "The sales director, weekly, to decide where to push discounts" tells a builder far more than "sales report".
- Exact definitions. Does "sales" mean confirmed orders or posted invoices? Before or after credit notes? Including tax? Which date: order, invoice, or delivery?
- Grouping and period. By region, by salesperson, by month, by quarter. Say which one is the default.
- A known answer. One figure you already trust, such as last month's total from your current spreadsheet. It becomes the acceptance test.
- Who may see it. Margin and cost reports usually should not be visible to every salesperson. Access rights are part of the requirement, not an afterthought.
- Output. On screen only, exported to Excel, or printed as PDF.
If you have an existing spreadsheet that the report replaces, attach it. A screenshot of the column headings removes more ambiguity than a page of description.
Printed documents: change the look, keep the substance
Customers often want their invoice redesigned: a new logo position, a bilingual layout, extra columns, payment instructions. That is reasonable. The risk is that a redesigned template drops content the law requires. In Saudi Arabia, for example, the e-invoicing requirements and the QR code on tax invoices come from Odoo's official ZATCA localization module. A custom layout should be built on top of that localized document, not as a replacement that quietly leaves elements out. The same caution applies to Egyptian ETA and UAE FTA requirements. When you request a new layout, say explicitly that the localization content must stay intact, and check it in the preview.
How this works on Plemo
On Plemo, a report request starts as a chat. The AI asks clarifying questions, which is where the definitions above get settled, and it narrows requests that are too broad to build well in one pass. "All our management reports" becomes a specific first report you can check. You then approve a written spec before any development starts, so the definitions are on paper before anything is built.
The change is delivered to a sandbox first. This is where the known answer earns its place: open the report, set the same period as your trusted spreadsheet, and compare. Then try the awkward cases, such as a cancelled order, a credit note, a customer in another currency, or a month with no activity. Only when the numbers reconcile does anything reach production. AI usage is credit based, so a tightly scoped report is also the cheaper one to build and revise.
Common mistakes
- Asking for everything in one report. Five focused reports are easier to verify and maintain than one with thirty columns.
- Rebuilding what a pivot already does. Custom code for a grouping that a saved filter handles adds upgrade work for no gain.
- Skipping the reconciliation. A report nobody has compared against a trusted number is a report nobody should trust.
- Forgetting who can see it. Discovering after go-live that the whole sales team can see cost prices is an avoidable conversation.
If a report depends on data your processes do not capture yet, the problem is upstream of the report, and it is worth solving there. Our custom development team can help decide which changes belong in the data model and which belong in the report itself.