Purchase¶

1. Purpose¶

Purchase manages buying: what the business orders from vendors, at what price, when it is expected, what actually arrived, and what is therefore owed. It produces the purchase order a vendor works from, the receipt the warehouse checks goods against, and the vendor bill accounting pays.

This is the module where NestERP adds the most control, because purchasing is where money leaves the business with the least natural friction. Core Odoo lets one person raise and confirm a purchase order alone.

2. Features¶

Requests for quotation, sent to vendors, converted to purchase orders on confirmation
Order lines with product, quantity, unit price, tax, unit of measure and expected date
Vendor pricelists, with minimum quantities and lead times feeding the expected date
Automatic receipt creation on confirmation (purchase_stock)
Three-way matching — order against receipt against bill
Partial receipts and backorders
Bill creation directly from the purchase order, inheriting quantities and prices
Purchase agreements and blanket orders
Reordering rules that generate replenishment purchase orders from stock levels
Vendor management with per-vendor products, prices and lead times
Purchase reporting by vendor, product, buyer and period

3. Where to find it¶

Menu: Purchase → Orders / Products / Reporting / Configuration
Technical names: purchase, purchase_stock
Tier: Odoo core (Community Edition)
Available in: Odoo 17 and 18. Our Odoo 16 line carries no purchase customisation.

4. Modules used¶

Module	Tier	Why it is needed
`purchase`	Odoo core	Requests for quotation, purchase orders, vendor management
`purchase_stock`	Odoo core	Links purchase orders to warehouse receipts
`stock`	Odoo core	Receiving the goods
`account`	Odoo core	Vendor bills and payment
`multi_branch_base`	Third-party (vendor to confirm)	Branch separation of purchase documents

NestERP custom modules that build on Purchase¶

Module	Odoo version	What it adds
`purchase_multi_approval`	17 · 18	Multi-stage approval workflow — see below
`purchase_date_override`	17 · 18	Control over purchase document dates
`mtewele_report_theme`	17	Client-branded purchase and stock report layouts
`thalia_mgmt_dashboard_v17`	17	Purchase figures in the consolidated management dashboard

The approval workflow¶

purchase_multi_approval exists because core Odoo Community has no meaningful purchase approval chain. It routes every purchase order through three stages:

Officer → Procurement Manager → Accountant

The chain applies to all purchase orders. There is no value threshold below which approval is skipped.
The order cannot proceed to receipt or billing until the chain completes.
Email notification at each stage exists as a stub and is not fully wired.

This is a client-specific control, not an Odoo feature

Built for Mtewele General Traders and carried into the NestERP stack. Verified on Odoo 18 during the v18 upgrade, which needed two fixes: tree → list in view definitions, and removal of a Print Labels button on the picking view.

5. Configuration¶

Prerequisite — products, taxes and vendors must exist first. A purchase order inherits price and tax from the product and the vendor pricelist.
Enable the features needed — Purchase → Configuration → Settings: Purchase Agreements, Vendor Price Lists, Receipt Reminder, and the Bill Control policy.
Set Bill Control — On ordered quantities allows billing what was ordered; On received quantities only allows billing what actually arrived. For clients who want tight control, received quantities is the safer default.
Set the purchase lead times — per vendor and per product, so expected dates mean something.
Create vendors as contacts, with their payment terms and currency.
Add vendor pricelists on each purchased product — vendor, price, minimum quantity, delay.
Configure the receipt operation type and warehouse steps (see Inventory).
Configure the approval chain in purchase_multi_approval — assign the users or groups holding Officer, Procurement Manager and Accountant roles.

Configuration traps

Bill Control on ordered quantities lets accounting pay for goods that never arrived. It is the default in some configurations and worth checking deliberately.
Without vendor lead times, every expected date is today, and the receipt reminder becomes noise.
The approval chain has no threshold. Every order, however small, needs three approvals. That is by design, but it is an operational load a client must accept — and it is the first thing they will ask to change.
Approval emails are stubbed. Approvers must check the system; they will not reliably be told. Flag this in any handover.

6. How it's used¶

Purchase to payment¶

Officer — Purchase → Orders → Requests for Quotation → New. Selects the vendor, adds products and quantities.
Officer — sends the RFQ to the vendor and submits it into the approval chain.
Procurement Manager — reviews and approves.
Accountant — gives the final approval. Only now can the order proceed.
Officer — Confirm Order. The receipt is created automatically.
Storekeeper — receives the goods and validates the receipt, entering actual quantities. Short deliveries create a backorder (see Inventory).
Accountant — Create Bill from the purchase order, checks it against the receipt, and confirms.
Accountant — registers the outgoing payment.

Replenishment¶

System — reordering rules generate draft purchase orders when stock falls below the minimum.
Officer — reviews, adjusts quantities, and submits into the same approval chain.

Screenshots needed

Save to docs/assets/purchase/: RFQ list · purchase order awaiting approval, showing the approval state · the approval history / tracking · a validated receipt · a vendor bill created from the order · vendor pricelist on a product.

7. Access rights¶

Group	Can do
Purchase / User	Create requests for quotation and purchase orders
Purchase / Administrator	All of the above, plus configuration, agreements and vendor pricelists
Approval roles (`purchase_multi_approval`)	Officer, Procurement Manager and Accountant each approve their own stage

The approval roles are the operative permission here: purchase rights alone no longer let a user push an order through to receipt.

8. Version differences (16 / 17 / 18)¶

Odoo 16Odoo 17Odoo 18

Not applicable. The Odoo 16 line of NestERP carries no purchase customisation, and purchase is not a dependency of any Odoo 16 module in our stack.

attrs and states removed from views.
purchase_multi_approval and purchase_date_override both run here.
The version of the Thalia reference instance.

<tree> elements superseded by <list> — one of the two fixes purchase_multi_approval needed on 18.
A Print Labels button on the picking view was removed upstream; the reference to it had to be dropped from our module. Verified working on 18 afterwards.
purchase_date_override installed on 18 with no code changes.

9. Known limitations¶

Core Odoo Community has no purchase approval chain. Ours is custom, and its behaviour is therefore ours to maintain.
No value thresholds in the approval chain — a stationery order and a vehicle purchase follow the same three approvals.
Approval notification emails are not fully implemented. Approvers must monitor the system.
No vendor scorecard or supplier performance rating in Community.
No purchase requisition module separate from RFQ; departmental requests are not modelled in core.
No tender or competitive bid comparison beyond purchase agreements.

Needs verification on the Thalia live instance

Whether purchase_multi_approval is installed and active there, or only at Mtewele
The Bill Control setting — ordered or received quantities
Which users hold the Officer, Procurement Manager and Accountant approval roles
Whether approval emails fire at all in the live configuration
Whether vendor pricelists and lead times are maintained
What purchase_date_override actually changes, confirmed against its code
Whether reordering rules are generating purchase orders automatically