Odoo Functional Certification common mistakes
Odoo Functional Certification · Understand the traps and how to avoid them.
Treating every CRM record as an opportunity: the candidate states that marking an opportunity as 'Won' generates a quotation or a sales order, and describes the Lead-to-Opportunity conversion as an automatic stage change rather than an explicit action.
The CRM pipeline kanban looks like a simple stage list, so candidates assume the stages drive downstream documents the way a status field might in another ERP. In practice a lead becomes an opportunity only through the explicit convert action (or when the Leads feature is disabled, in which case records are opportunities from the start), and nothing is created in Sales until the user clicks 'New Quotation' on the opportunity.
What to do instead
Enable the 'Leads' setting, create one lead, convert it to an opportunity, then use 'New Quotation' from the opportunity and follow the link back. Note on the record which step creates a res.partner, which creates a quotation, and which changes nothing but the stage.
Reading the Invoicing Policy from the wrong place: the candidate changes a setting under Sales or Accounting and expects confirming a quotation to create an invoice, then is surprised that 'Create Invoice' is greyed out on a confirmed order.
Invoicing Policy (Ordered quantities vs Delivered quantities) lives on the product, with an override on the order line, not in a global Sales setting. With 'Delivered quantities' nothing is invoiceable until the delivery is validated, so the invoiceable quantity on a freshly confirmed order is zero.
What to do instead
Set the policy on the product's Sales tab, confirm one order with each policy, and inspect the 'Invoiceable Quantity' column after confirming versus after validating the delivery. Remember the policy can also be overridden per line and per customer.
Assuming a confirmed Purchase Order produces a vendor bill, or that a vendor bill can always be matched to a receipt regardless of configuration: the candidate bills an order whose goods have not been received and expects the system to block, or the reverse.
Bill Control is a per-product (Purchase tab) configuration with received-quantities as the stricter option, and 3-way matching is a Purchase setting that must be enabled. Without those, the system happily lets you bill ordered quantities, so behaviour differs between databases and candidates generalise from one demo.
What to do instead
Reproduce both cases: bill a PO with 'Ordered quantities' and then with 'Received quantities' before and after validating the receipt. Record which field on the product controls it and which setting enables 3-way matching.
Confusing On Hand with Available/Forecasted: the candidate reports that stock is available to sell because the On Hand figure is positive, and is confused when a delivery cannot be reserved or shows a negative forecast.
Available subtracts reserved outgoing quantity from On Hand, and Forecasted additionally includes incoming moves and planned consumption. The product form shows several numbers with similar names, and candidates read the most prominent one.
What to do instead
On one product, create a confirmed sales order for part of the stock, then compare On Hand, Available, and Forecasted on the product and in the stock report; add a confirmed PO and observe the forecast change before any receipt exists.
Treating a draft invoice and a posted invoice as interchangeable: the candidate tries to edit or delete a posted invoice, or expects a journal entry to exist for an invoice that has only been saved in draft.
In Odoo the accounting impact is created at posting time, and posted entries are immutable by design to preserve the audit trail. Candidates coming from tools where saving and accounting are the same step assume the journal entry appears immediately.
What to do instead
Create a customer invoice, inspect the absence of a journal entry, post it, then attempt an edit and record the exact error; finally use 'Reset to Draft' to show the only supported reversal path. Also note that cancellation creates a reversing entry rather than deleting.
Assuming components are consumed the moment a Manufacturing Order is confirmed, or that changing the produced quantity is impossible: the candidate expects stock of the finished good to increase on confirmation and is surprised that consumption is recorded later.
Confirmation reserves components; actual consumption and finished-good receipt happen when the order is marked done (or through the consumption wizard). Because the confirmation dialog looks like the final step, candidates collapse the two phases into one.
What to do instead
Run a two-unit MO end to end: confirm, check the reservation on the components, then mark done with a different produced quantity and observe the resulting backorder. Write down at which click the finished good enters stock.
Expecting timesheets to be billable by default: the candidate logs hours on a project, then cannot find them on any invoice and concludes that timesheet invoicing is broken.
Two independent things must be true: the Timesheets feature must be enabled, and the project must be configured as billable and linked to a sales order line with a timesheet-based invoicing policy. Logging time alone creates no billable amount.
What to do instead
Enable Timesheets, set the project's billing to a timesheet-based policy tied to a confirmed sales order, log two hours, then invoice from the sales order and from the project. Note where the invoiced quantity comes from and what happens to hours logged on a non-billable project.
Assuming a product with 'Sales' checked is automatically visible and correctly priced in the shop: the candidate changes the sales price and then cannot explain why the storefront still shows a different figure or the product is missing.
Website visibility requires the product to be published in addition to being sellable, and a website-specific price set on the eCommerce tab overrides the general sales price on that website. Variants with inactive attributes also fail to appear.
What to do instead
Publish a product, set a distinct website price, then change the general sales price and observe which value the shop displays. Unpublish the product and check whether a direct URL still resolves.
Treating an employee as a system user, or requesting leave without an allocation: the candidate creates an employee and expects them to log in, and submits a leave request that is refused for insufficient balance.
Employees and users are separate records linked by a user field; no login exists until a user is created and linked. Leave balances come from allocations or from the accrual plan, so a request without an allocation has nothing to draw from even if the request itself is valid.
What to do instead
Create an employee without a user and try to log in as them, then link a user and repeat. In Time Off, submit a request before and after creating an allocation for the same leave type and compare what the validation does.
Assuming every setting can be switched back off: the candidate enables a feature such as multi-currency, units of measure, or multi-company during practice, then cannot untick it on the exam database and misreads the greyed-out checkbox as a bug or as still being active.
Odoo locks certain settings once dependent records exist, to protect data integrity, and the checkbox then stays ticked and read-only. The settings screen gives no separate warning, so the visual state is easy to misinterpret.
What to do instead
On a throwaway database, enable a locking setting, create a dependent record, and observe the field becoming read-only; note which settings are reversible and which are not, and confirm state by checking the resulting menu or field rather than the checkbox.