Odoo Modules — Complete Object Reference¶

2026-04-28

Purpose: Every Odoo module, every model it owns, what each model is, and its relevance to the SA governance system (x_actor_id / x_sa_id stamping). Includes all core and optional modules available in Odoo 18 Enterprise and Community.

Last updated: 2026-04-23 Companion doc: GOVERNED_OBJECTS.md — detailed stamp implementation notes for objects already in our workflow.

Status Legend¶

Symbol	Meaning
✅	Already stamped in this codebase
🔴	Should be stamped — high priority
🟡	Should be stamped — medium priority
🟢	Could be stamped — low priority / future
⚙️	No stamp needed — config, infrastructure, or inherited from parent
🏭	Relevant to manufacturing workflow
📡	Relevant to IoT workflow

Module Index¶

Base & Core
Sales
CRM
Accounting & Finance
Inventory & Warehouse
Manufacturing (MRP)
Quality Control
Product Lifecycle Management (PLM)
Maintenance
Repairs
Field Service
IoT
Point of Sale (POS)
Purchase
Fleet
Human Resources (HR)
Payroll
Recruitment
Appraisals
Time Off (Leave)
Attendances
Expenses
Project
Timesheets
Planning
Helpdesk
Rental
Subscription (Native Odoo)
eCommerce & Website
Blog
Live Chat
Email Marketing (Mass Mailing)
SMS Marketing
Social Media
Events
Surveys
eLearning
Sign
Documents
VoIP
Discuss (Messaging)
Lunch
Referrals
Barcode
Accounting Localisations
Complete Object Table

1. Base & Core¶

The base module is the foundation of every Odoo installation. Its models are present in every database regardless of which apps are installed.

`res.partner` ✅¶

The universal contact record. Represents people, companies, customers, suppliers, and system users. Every monetary transaction, communication, and governance stamp traces back to a res.partner. This is the most important model in Odoo. Already stamped in this codebase — see partner_ext.py.

`res.company` ⚙️¶

Multi-company tenant. Each Odoo company is a separate organisational unit with its own chart of accounts, warehouses, and users. In this codebase, company_id is the coarse multi-tenant boundary; ov.serviced_account provides the fine-grained governance layer within a company. Root SAs are auto-created from res.company records.

`res.users` ⚙️¶

Odoo login identity. Every person who logs into the Odoo backend or portal is a res.users record linked to a res.partner. In this system, abs.employee represents field agents as free-seat identities outside res.users. Portal customers have res.users records with group_portal.

`res.country` / `res.country.state` ⚙️¶

Geographic reference data. Countries and states/provinces. Used on addresses. Config data — no stamp needed.

`res.currency` ⚙️¶

Currency master. Stores exchange rates and currency definitions. Config data.

`res.lang` ⚙️¶

Language definitions. Controls UI language and date/number formatting. Config data.

`ir.config_parameter` ⚙️¶

System parameters. Key-value store for system-wide settings (e.g. web.base.url). Used in this codebase for portal session storage (legacy). Config/infrastructure.

`ir.rule` ⚙️¶

Record access rules. Defines which records each user group can read/write. The right long-term home for SA-level visibility enforcement. No stamp needed on this model itself.

`ir.model.access` ⚙️¶

Model-level access control. Grants or denies CRUD permissions per group on each model. Config infrastructure.

`ir.attachment` 🟢¶

File attachments. Every file uploaded and attached to an Odoo record lives here. If agents upload site photos or customer documents during an SA-governed interaction, stamping the attachment enables "show all files uploaded by SA X". Low priority today.

`ir.cron` ⚙️¶

Scheduled jobs. Background tasks that run on a timer. Infrastructure.

`ir.sequence` ⚙️¶

Auto-numbering sequences. Generates reference numbers (SO001, INV002, etc.). Infrastructure.

2. Sales¶

Module name: sale / sale_management

`sale.order` ✅¶

Sales order / quotation. The primary commercial document. Fully described in GOVERNED_OBJECTS.md. Already stamped with x_actor_id, x_sa_id, x_sales_rep_id, x_outlet_id, x_channel_partner_id, and approval workflow fields.

`sale.order.line` ⚙️¶

Order line. Single product line within a sale.order. Inherits SA context from parent order. No independent stamp needed.

`sale.report` ⚙️¶

Sales analysis view. A PostgreSQL view (not a real table) used for the Sales Analysis report. Not a transactional object — no stamp.

`sale.payment.provider.onboarding.wizard` ⚙️¶

Setup wizard. One-time onboarding helper. No stamp.

3. CRM¶

Module name: crm

`crm.lead` ✅¶

Lead / opportunity. The sales pipeline object. Fully stamped — x_actor_id + x_sa_id. See crm_lead_ext.py.

`crm.stage` ⚙️¶

Pipeline stage. Configuration — New, Qualified, Proposal, Won, Lost. Shared config, no stamp.

`crm.team` ⚙️¶

Sales team. Groups salespeople. Config data. SA structure replaces the team grouping function in this system.

`crm.team.member` ⚙️¶

Team membership. Links res.users to a crm.team. Config, no stamp.

`crm.activity.type` ⚙️¶

Activity type. Defines categories of follow-up activities (call, email, meeting). Config.

`crm.tag` ⚙️¶

Lead tag. Classification tags applied to leads. Config/reference data.

`crm.lost.reason` ⚙️¶

Lost reason. Why an opportunity was lost. Reference data.

4. Accounting & Finance¶

Module name: account / account_accountant

`account.move` 🔴¶

Invoice / credit note / vendor bill / journal entry. The central accounting document. Every revenue event — when an agent sells and invoices a customer — creates an account.move. Currently not stamped. Full reasoning in GOVERNED_OBJECTS.md. This is a high-priority gap.

`account.move.line` ⚙️¶

Journal entry line. A single debit or credit line within an account.move. Inherits context from the parent move. No independent stamp.

`account.payment` 🟡¶

Registered payment. Represents money received or sent — cash, bank transfer, mobile money. Created when an agent manually registers a payment or when a payment gateway webhook confirms. Should carry x_sa_id to enable per-SA collections reporting.

`account.payment.term` ⚙️¶

Payment schedule / terms. Config — "Net 30 days", "50% upfront, 50% on delivery". No stamp.

`account.payment.term.line` ⚙️¶

Payment term line. A single instalment rule within a payment term. Config.

`account.journal` ⚙️¶

Accounting journal. Groups entries by type (Sales, Bank, Cash, Miscellaneous). Config.

`account.account` ⚙️¶

Chart of accounts entry. Each account in the company's chart of accounts. Config.

`account.account.type` ⚙️¶

Account type. Receivable, payable, expense, income, etc. Config.

`account.tax` ⚙️¶

Tax definition. VAT, withholding tax, etc. Config/reference data.

`account.tax.group` ⚙️¶

Tax group. Groups taxes for display on invoices. Config.

`account.fiscal.position` ⚙️¶

Fiscal position. Maps taxes and accounts per country/customer category. Config.

`account.analytic.account` 🟡¶

Analytic account. Tracks costs and revenues by business dimension (project, cost centre, territory). If one analytic account is created per SA, this becomes the financial reporting anchor for each SA — enabling P&L per SA without custom reports.

`account.analytic.line` 🟡¶

Analytic entry line. A single revenue or cost allocation to an analytic account. If analytic accounts are SA-aligned, stamping analytic lines enables precise per-SA financial reporting.

`account.analytic.plan` ⚙️¶

Analytic plan. Groups analytic accounts into a plan dimension (projects, departments, etc.). Config.

`account.bank.statement` ⚙️¶

Bank statement. Represents an imported bank statement for reconciliation. System/accounting infrastructure.

`account.bank.statement.line` ⚙️¶

Bank statement line. A single transaction line from a bank statement. Infrastructure.

`account.reconcile.model` ⚙️¶

Reconciliation rule. Automatic matching rules for bank statement lines to journal entries. Config.

`account.incoterms` ⚙️¶

International trade terms. EXW, FOB, CIF, etc. Reference data.

`account.cash.rounding` ⚙️¶

Cash rounding. Rules for rounding invoice totals to nearest coin denomination. Config.

5. Inventory & Warehouse¶

Module name: stock / inventory

`stock.picking` 🟡¶

Delivery order / receipt / internal transfer. The logistics document that governs the movement of physical goods. When a solar kit is delivered to a customer, a stock.picking is validated. Stamping it answers "how many deliveries did SA X make this quarter?"

`stock.move` ⚙️¶

Stock movement line. A single product quantity moved between locations within a stock.picking. Inherits context from the parent picking. No independent stamp.

`stock.move.line` ⚙️¶

Detailed move line. Detailed lot/serial tracking at the move level. Inherits from stock.move. No stamp.

`stock.lot` 🟡¶

Serial number / lot. The permanent identity record of a physical unit when serial tracking is enabled. A solar kit's serial number is a stock.lot. Stamping links a serial number to the SA under which it was deployed. Coordinate with ov.asset to avoid double-stamping — ov.asset is likely the correct governance wrapper; stock.lot is the underlying identity.

`stock.quant` ⚙️¶

On-hand stock quantity. Odoo's internal ledger of available stock at each location. System-maintained. No stamp.

`stock.location` ⚙️¶

Storage location. Defines physical or virtual locations: warehouses, shelves, customer locations, virtual/adjustment locations. Config/master data. No stamp.

`stock.warehouse` ⚙️¶

Warehouse definition. A warehouse or distribution centre with routes, picking types, and locations. Config.

`stock.route` ⚙️¶

Stock route. Defines how products flow through the warehouse (Buy → Receive → Store → Deliver). Config.

`stock.rule` ⚙️¶

Reorder / procurement rule. Triggers automatic replenishment when stock falls below a minimum. Config.

`stock.warehouse.orderpoint` 🟢¶

Reorder rule. Minimum/maximum stock level per product per location. Triggers automatic purchase or manufacturing orders. Low priority for SA stamping.

`stock.scrap` 🟢¶

Scrap / disposal record. Writes off damaged or end-of-life units from inventory. In a solar business, this represents a decommissioned kit. Low priority today — add when asset decommissioning workflow is built.

`stock.backorder.confirmation` ⚙️¶

Backorder wizard. Transient wizard for handling partial deliveries. Not a persistent record.

`stock.picking.type` ⚙️¶

Operation type. Defines categories of transfers (receipts, deliveries, internal). Config.

`stock.valuation.layer` ⚙️¶

Inventory valuation layer. Financial valuation record for each stock movement (AVCO, FIFO). Accounting infrastructure.

`stock.landed.cost` 🟢¶

Landed cost. Distributes additional costs (freight, customs) across received goods to adjust their valuation. Low priority for SA stamping.

6. Manufacturing (MRP)¶

Module name: mrp

Manufacturing is highly relevant to a hardware business (solar kits, batteries, meters). Even if Omnivoltaic does not manufacture in-house, understanding MRP objects is important for kit assembly, BOM management, and production tracking.

`mrp.production` 🟡¶

Manufacturing order (MO). The core document of the manufacturing module. Represents an instruction to produce a quantity of a finished product from its components. When a kit is assembled from parts (chassis + battery + controller + cable), a manufacturing order is created.

Key fields: - product_id — what is being produced - bom_id — Bill of Materials driving the production - qty_producing — quantity currently being manufactured - state — draft → confirmed → progress → to_close → done / cancel - workcenter_id — where production happens - date_planned_start / date_planned_finished - lot_producing_id → stock.lot — the serial number of the finished unit

SA governance relevance: If production orders are tied to SA-specific customer contracts (e.g. "assemble 20 kits for SA Togo Q2"), stamping the MO enables per-SA production tracking and delivery pipeline visibility. Medium priority.

`mrp.bom` ⚙️¶

Bill of Materials (BOM). Defines what components and operations are needed to produce one unit of a product. A solar kit BOM might list: 1× solar panel, 1× battery, 1× charge controller, 2× cables.

BOM types: - normal — standard production BOM - phantom — kit BOM (used for packing / bundling without a production order) - subcontract — components sent to a supplier for assembly

No stamp needed — this is a product template definition, not a transaction record.

`mrp.bom.line` ⚙️¶

BOM component line. A single component within a mrp.bom. Defines product, quantity, unit of measure, and optional routing step. Config/template data.

`mrp.bom.byproduct` ⚙️¶

BOM by-product. A secondary output of a manufacturing process (e.g. scrap material recovered during assembly). Config.

`mrp.routing.workcenter` ⚙️¶

Routing / work centre operation. Defines a step in the production process performed at a specific work centre (e.g. "Step 1: Weld frame at Work Centre A — 30 min"). Config.

`mrp.workcenter` ⚙️¶

Work centre. A machine, workstation, or production area with a defined capacity and cost. Examples: "Assembly Line 1", "Quality Inspection Bay", "Packaging Station". Config/master data.

`mrp.workcenter.productivity` 🟢¶

Work centre downtime / productivity log. Records periods when a work centre was blocked, producing, or down. Operational log — low priority for SA stamping.

`mrp.workorder` 🟡¶

Work order. A step-by-step production task within a manufacturing order. Each mrp.workorder is assigned to a work centre and tracks time, quantity, and completion. If a technician (agent) performs assembly work under an SA contract, stamping work orders enables per-SA labour tracking.

`mrp.unbuild` 🟢¶

Unbuilding order. Reverses a manufacturing order — breaks a finished product back into its components. Relevant for kit returns and refurbishment workflows. Low priority for SA stamping.

`stock.warn.insufficient.qty.unbuild` ⚙️¶

Wizard. Warning dialog for insufficient stock during unbuilding. Transient. No stamp.

7. Quality Control¶

Module name: quality / quality_control

Quality control integrates with manufacturing, inventory, and maintenance. It ensures that products and processes meet defined standards before goods are released.

`quality.point` ⚙️¶

Control point. Defines where in the process a quality check must be performed — on receipts, during manufacturing, before delivery, etc. Also defines what type of check (pass/fail, measure, take photo). Config/template.

`quality.check` 🟡¶

Quality check instance. A single quality check performed at a control point — the actual result record. When a technician inspects a solar kit before delivery, a quality.check is created with the result (pass/fail, measured value, photo).

SA governance relevance: If kits are inspected before delivery to a specific SA's customers, stamping the quality check record links inspection results to the SA context. Useful for per-SA quality reports ("failure rate for SA Togo vs SA Kenya").

`quality.alert` 🟡¶

Quality alert. A non-conformance report raised when a quality issue is found. Can trigger corrective actions. If a technician reports a field defect under an SA, the alert should carry the SA context.

`quality.alert.stage` ⚙️¶

Alert pipeline stage. New, In Progress, Solved, etc. Config.

`quality.tag` ⚙️¶

Quality tag. Labels for classifying quality alerts. Config/reference data.

8. Product Lifecycle Management (PLM)¶

Module name: mrp_plm

PLM manages product design changes and engineering change orders (ECOs).

`mrp.eco` 🟢¶

Engineering Change Order (ECO). Tracks a proposed change to a product's BOM, routing, or specifications. Goes through an approval workflow before the change is applied.

SA governance relevance: Low priority. PLM is primarily an R&D / product management concern. If SA-specific product variants are developed (e.g. a kit specifically designed for a country's grid standards), an ECO could carry SA context. Future consideration.

`mrp.eco.type` ⚙️¶

ECO type. Categories of change orders (design, engineering, regulation). Config.

`mrp.eco.stage` ⚙️¶

ECO stage. Pipeline stages for ECOs (New → Under Review → Approved → Applied). Config.

`mrp.eco.tag` ⚙️¶

ECO tag. Classification labels. Reference data.

`product.template.attribute.value` ⚙️¶

Product attribute value. Defines variant dimensions (colour: Red/Blue, size: S/M/L). Config.

9. Maintenance¶

Module name: maintenance

Maintenance tracks equipment upkeep, failure history, and preventive maintenance schedules. Highly relevant to a solar hardware business where physical assets (kits, batteries, inverters) need scheduled servicing.

`maintenance.equipment` 🟡¶

Equipment record. Represents a physical machine, vehicle, or asset being maintained. In the solar context, this could represent an installed solar system at a customer site.

Key fields: - name — equipment name / reference - partner_id — customer/location where equipment is installed - maintenance_team_id - technician_user_id — assigned technician - serial_no — serial number (links to physical unit) - category_id — equipment category - maintenance_ids — linked maintenance requests

SA governance relevance: If maintenance equipment represents installed kits under an SA, stamping equipment records enables per-SA asset health reporting. Coordinate with ov.asset which is the current governance wrapper for physical units — avoid duplication.

`maintenance.equipment.category` ⚙️¶

Equipment category. Solar Panel, Battery, Inverter, Meter, Full Kit, etc. Config/reference.

`maintenance.request` 🟡¶

Maintenance request. A request to perform maintenance on a piece of equipment — either reactive (breakdown reported) or preventive (scheduled service). Created by field agents or automatically triggered by a maintenance schedule.

Key fields: - name — description of the issue - equipment_id — the equipment being serviced - maintenance_type — corrective (breakdown) or preventive (scheduled) - stage_id — current stage in maintenance pipeline - user_id — assigned technician - partner_id — customer/site - schedule_date — planned date - kanban_state — ready / blocked / normal

SA governance relevance: When a field technician (abs.employee) handles a maintenance job under an SA context, the request should carry {actor, sa} to enable per-SA maintenance reports ("how many corrective requests did SA X have this month?").

`maintenance.stage` ⚙️¶

Maintenance pipeline stage. New, In Progress, Repaired, Scrapped. Config.

`maintenance.team` ⚙️¶

Maintenance team. Groups technicians by specialisation or region. Config.

10. Repairs¶

Module name: repair

Repairs manages the return, diagnosis, repair, and return of customer-owned items. Distinct from Maintenance (which tracks preventive upkeep of company equipment) — Repairs handles customer returns.

`repair.order` 🟡¶

Repair order. Represents the full lifecycle of a customer return — receipt of broken item, diagnosis, parts used, labour, and return to customer (or disposal). In a solar business, this handles battery replacements, controller failures, and kit refurbishments.

Key fields: - name — repair order reference - product_id — item being repaired - lot_id → stock.lot — serial number of the unit - partner_id — customer who owns the item - state — draft → confirmed → under_repair → done → cancel - invoice_id — invoice for parts/labour charged to customer - move_id — stock movement for parts consumed

SA governance relevance: When a customer under an SA sends in a broken kit, the repair order should carry {actor, sa} to attribute it to the correct SA for warranty reporting and per-SA repair cost analysis.

`repair.line` ⚙️¶

Repair parts line. Components consumed during the repair. Inherits context from parent repair order. No independent stamp.

`repair.fee` ⚙️¶

Repair service charge line. Labour or service fee line on a repair order. Inherits from parent. No stamp.

11. Field Service¶

Module name: industry_fsm (Field Service Management)

Field Service manages on-site service interventions — scheduling technicians for customer visits, tracking time spent, and closing out tasks with invoicing.

`project.task` (FSM mode) 🟡¶

Field service task / work order. In FSM mode, project tasks become field service work orders with additional fields for on-site tracking. An agent visits a customer's site, starts a timer, records what was done, and marks the task as done.

Key fields: - partner_id — customer / installation site - user_ids — assigned technician(s) - planned_date_begin / date_deadline - fsm_done — whether the field task is completed - timesheet_ids — time logged on-site - sale_order_id — linked order (for invoicing)

SA governance relevance: Every field visit is an SA-governed activity. Stamping FSM tasks enables per-SA service operations reporting — visits scheduled, time on-site, tasks completed.

`project.project` (FSM mode) ⚙️¶

FSM project. The FSM module creates a default project per company. Config/infrastructure.

12. IoT¶

Module name: iot

The IoT module connects physical IoT boxes and devices (sensors, scanners, printers, scales, screens) to Odoo. IoT boxes are Raspberry Pi units that bridge physical hardware to Odoo's event system.

`iot.box` 📡 🟢¶

IoT Box. Represents a physical IoT gateway device (a Raspberry Pi running the Odoo IoT image). Each box has a unique identifier, a local IP, and an SSL tunnel to the Odoo server.

Key fields: - name — human-readable box name (e.g. "Outlet Lomé Scanner") - identifier — unique hardware ID - ip — local network IP address - ip_url — URL to access the box locally - drivers_auto_update — whether to auto-update IoT drivers - device_ids — all devices connected to this box

SA governance relevance: In a solar / energy business, IoT boxes could be deployed at service outlets. An IoT box stamped with x_sa_id would allow "show all IoT devices at outlets belonging to SA X". Low priority today but relevant if outlet-level hardware monitoring is implemented.

`iot.device` 📡 🟢¶

IoT Device. Represents a peripheral connected to an IoT box — a barcode scanner, card reader, receipt printer, customer screen, weight scale, or any other USB/serial device.

Key fields: - name — device display name - identifier — unique hardware ID - type — printer, display, scale, scanner, camera, device - connection — serial, usb, bluetooth, wifi, hdmi - iot_id → iot.box — the IoT box this device is connected to - keyboard_layout — for keyboard/scanner devices - display_url — for customer display screens

SA governance relevance: Devices at an outlet under an SA. Low priority today.

`iot.trigger` 📡 ⚙️¶

IoT Trigger. Maps a device action (e.g. barcode scanner scan) to an Odoo action (e.g. validate a picking, mark a quality check as done). Configuration linking hardware events to software actions.

`iot.channel` 📡 ⚙️¶

IoT Communication Channel. The WebSocket channel through which the Odoo server pushes commands to IoT boxes and receives events from them. Infrastructure.

IoT use cases in solar/energy context:

Use Case	IoT Device	Odoo Integration
Customer check-in at outlet	Barcode / QR scanner	Scan customer card → open `sales.session`
Kit serial registration	Barcode scanner	Scan kit serial → link to `stock.lot` / `ov.asset`
Receipt printing	Thermal printer	Print payment receipt from `account.payment`
Payment terminal	Card reader / NFC	Trigger Lipay / mobile money payment flow
Customer display	HDMI display	Show order total and payment confirmation
Weight verification	Scale	Verify package weight before dispatch
Energy meter reading	Serial sensor	Log meter reading to `account.analytic.line`

13. Point of Sale (POS)¶

Module name: point_of_sale

POS is Odoo's retail sales module — a browser-based cashier interface that works offline and syncs when online. Integrates deeply with IoT for scanners and printers.

`pos.config` ⚙️¶

POS configuration. Defines a POS setup — which journal, which products, which payment methods, which printers. One config per register/outlet. Config/master.

`pos.session` 🟡¶

POS session. A cashier session from open to close. Tracks all transactions, payments, and cash movements during a single shift.

Key fields: - config_id — which POS configuration - user_id — cashier who opened the session - state — new → opening_control → opened → closing_control → closed - start_at / stop_at — session duration - order_ids — all orders in this session

SA governance relevance: If POS is used at outlets belonging to SAs, each session should be attributed to the SA. Compare with the custom sales.session model — if POS replaces custom sessions, the SA stamp must move to pos.session.

`pos.order` 🟡¶

POS sale transaction. An individual customer sale at the point of sale. The POS equivalent of sale.order. Contains lines, payments, and customer reference.

Key fields: - session_id → pos.session - partner_id — customer (optional in POS — can be anonymous) - state — draft → paid → posted → invoiced - lines → pos.order.line - payment_ids → pos.payment - account_move — linked invoice if invoiced

SA governance relevance: POS orders at SA-governed outlets should carry {actor, sa}.

`pos.order.line` ⚙️¶

POS order line. A single product in a POS order. Inherits from parent order. No stamp.

`pos.payment` ⚙️¶

POS payment. Records a payment method and amount within a POS order. Inherits context from parent order. No stamp.

`pos.payment.method` ⚙️¶

POS payment method. Defines accepted payment methods (cash, card, mobile money, Lipay). Config.

`pos.category` ⚙️¶

POS product category. Visual grouping of products on the POS screen. Config.

`pos.note` ⚙️¶

Order note. Free-text notes added to a POS order line. Config/reference.

14. Purchase¶

Module name: purchase

`purchase.order` 🟢¶

Purchase order. An order placed to a supplier for goods or services. Generates a vendor receipt (stock.picking) and a vendor bill (account.move). Low priority for SA stamping unless channel partners place orders on behalf of SAs.

`purchase.order.line` ⚙️¶

PO line. A single product line within a purchase.order. Inherits from parent. No stamp.

`purchase.report` ⚙️¶

Purchase analysis view. PostgreSQL view for purchase analytics. Not a real table.

`purchase.bill.union` ⚙️¶

Purchase/Bill view. A UI helper combining POs and bills. Not a real table.

15. Fleet¶

Module name: fleet

Fleet manages company vehicles — cars, motorcycles, trucks — with fuel logs, service records, contracts, and cost tracking.

`fleet.vehicle` 🟢¶

Vehicle record. Represents a company vehicle. In a solar field operations context, vehicles are used by field agents for customer site visits. If vehicles are assigned per SA team, stamping enables per-SA transport cost tracking.

Key fields: - name — licence plate - model_id — vehicle model - driver_id → res.partner — assigned driver - company_id - state_id — New / Used / Registered / Downgraded / Written Off - acquisition_date - odometer — current mileage

`fleet.vehicle.model` ⚙️¶

Vehicle model. Toyota Corolla, Honda CG125, etc. Reference data.

`fleet.vehicle.model.brand` ⚙️¶

Vehicle brand. Toyota, Honda, Yamaha, etc. Reference data.

`fleet.vehicle.log.fuel` 🟢¶

Fuel log. Records a fuel fill-up with date, litres, cost, and mileage. Tracks fuel consumption per vehicle. SA governance relevance: low — relevant if per-SA transport costs are tracked.

`fleet.vehicle.log.services` 🟢¶

Service log. Records a vehicle service event (oil change, tyre replacement, etc.). Same SA relevance as fuel log.

`fleet.vehicle.log.contract` 🟢¶

Vehicle contract. Insurance, lease, or maintenance contract for a vehicle. Low priority.

`fleet.vehicle.cost` ⚙️¶

Cost entry. A computed/aggregated cost record for a vehicle. Not directly created by users.

`fleet.vehicle.state` ⚙️¶

Vehicle state. New / Used / Registered / Written Off. Config/reference.

`fleet.service.type` ⚙️¶

Service type. Categories of vehicle services. Config.

16. Human Resources (HR)¶

Module name: hr

`hr.employee` ⚙️¶

Native Odoo employee. Full employee record linked to res.users. Manages payroll, contracts, attendance, leave, and appraisals. In this system, abs.employee is used for free-seat field agents to avoid licensing costs. hr.employee may exist for Omnivoltaic internal staff only.

`hr.employee.public` ⚙️¶

Public employee view. A restricted view of hr.employee fields visible to all employees. Not a separate table — a view model.

`hr.department` ⚙️¶

Department. Organisational grouping of employees (Sales, Operations, Finance, IT). Config.

`hr.job` ⚙️¶

Job position. A role/title within the company (Sales Representative, Field Technician, Finance Manager). Config/reference.

`hr.work.location` ⚙️¶

Work location. Office, home, field, warehouse. Reference data.

17. Payroll¶

Module name: hr_payroll

`hr.payslip` 🟢¶

Payslip. Monthly salary calculation for an employee. Contains gross, deductions, net pay, and contributions. Low relevance to SA governance today — internal HR.

`hr.payslip.line` ⚙️¶

Payslip line. A single salary rule result on a payslip (basic salary, bonus, tax, CNSS, etc.). Inherits from payslip.

`hr.payslip.run` ⚙️¶

Payslip batch. Groups multiple payslips processed together (e.g. "February 2026 Payroll").

`hr.contract` ⚙️¶

Employment contract. Defines salary structure, start/end date, and work schedule. Config.

`hr.salary.rule` ⚙️¶

Salary rule. Calculation formula for a payslip component (basic × 0.07 for pension, etc.). Config.

`hr.salary.structure` ⚙️¶

Salary structure. Groups salary rules for a category of employees. Config.

18. Recruitment¶

Module name: hr_recruitment

`hr.applicant` 🟢¶

Job applicant. A candidate application for an open position. Tracks the hiring pipeline from application to offer. Low SA governance relevance today. Relevant if channel partners recruit agents on behalf of an SA.

`hr.applicant.category` ⚙️¶

Applicant tag. Labels for classifying applicants. Config.

`hr.recruitment.stage` ⚙️¶

Recruitment stage. New → Screen → Interview → Offer → Hired / Refused. Config.

`hr.recruitment.source` ⚙️¶

Recruitment source. Where the applicant came from (LinkedIn, Referral, Website, etc.). Config.

19. Appraisals¶

Module name: hr_appraisal

`hr.appraisal` 🟢¶

Employee appraisal. Periodic performance review. Links to an employee and contains goals, ratings, and feedback. Low SA governance relevance — internal HR.

`hr.appraisal.goal` ⚙️¶

Appraisal goal. A specific objective set during an appraisal. Config/template.

`hr.appraisal.note` ⚙️¶

Appraisal note. Free-text observation during the review process.

20. Time Off (Leave)¶

Module name: hr_holidays

`hr.leave` ⚙️¶

Leave request. An absence request by an employee — annual leave, sick leave, unpaid, etc. Internal HR process. No SA governance relevance.

`hr.leave.allocation` ⚙️¶

Leave allocation. Grants an employee a number of leave days of a specific type. HR config.

`hr.leave.type` ⚙️¶

Leave type. Annual Leave, Sick Leave, Maternity Leave, etc. Config.

`hr.leave.accrual.plan` ⚙️¶

Accrual plan. Rules for how leave days accumulate over time. Config.

21. Attendances¶

Module name: hr_attendance

`hr.attendance` 🟢¶

Attendance record. Clock-in/clock-out record for an employee. Tracks actual hours worked. If field agents clock in at outlets, the attendance record could carry the outlet and SA context for per-SA labour hours reporting. Low priority today.

Key fields: - employee_id - check_in / check_out - worked_hours (computed)

22. Expenses¶

Module name: hr_expense

`hr.expense` 🟢¶

Expense claim. A single business expense submitted by an employee for reimbursement — fuel, accommodation, mobile data, tools. If field agents submit expenses tied to SA activities, the SA stamp enables per-SA cost reporting.

`hr.expense.sheet` ⚙️¶

Expense report. A batch of expense claims submitted together for approval and reimbursement. Inherits SA context from individual expenses if stamped.

23. Project¶

Module name: project

`project.project` ⚙️¶

Project. Groups tasks under a single initiative. Optionally linked to a customer and billed via timesheets. Config/organisational — no stamp needed unless SA-specific projects are tracked.

`project.task` 🟢¶

Task. An individual work item within a project. Carries assignee, deadline, stage, and timesheet lines. When used in Field Service mode, becomes a field work order. Low priority for standalone SA stamping — FSM mode stamps are higher priority.

`project.task.type` ⚙️¶

Task stage. New, In Progress, Done, Cancelled. Config (kanban columns).

`project.tags` ⚙️¶

Task tag. Classification labels. Config.

`project.milestone` ⚙️¶

Project milestone. A deadline checkpoint within a project. Config.

24. Timesheets¶

Module name: hr_timesheet

`account.analytic.line` (timesheet) 🟡¶

Timesheet entry. In timesheet context, account.analytic.line records time spent by an employee on a project/task. The same model also stores analytic costs and revenues. If technicians log time on SA-specific jobs, stamping timesheet entries enables per-SA labour cost reporting.

25. Planning¶

Module name: planning

`planning.slot` 🟡¶

Shift / planning slot. A scheduled shift for an employee at a specific time and location. Used for workforce planning and scheduling. If agents are scheduled for SA-specific activities (outlet shifts, site visits), stamping the slot enables per-SA staffing reports.

Key fields: - resource_id — the employee - role_id — planning role (Sales Agent, Technician, etc.) - start_datetime / end_datetime - company_id - sale_line_id — linked to a sale order line (for billable planning)

`planning.role` ⚙️¶

Planning role. Job role used for shift assignment (Sales, Technician, Driver). Config.

26. Helpdesk¶

Module name: helpdesk

`helpdesk.ticket` 🔴¶

Support ticket. Fully described in GOVERNED_OBJECTS.md. High priority — both agents and customers create tickets; neither is currently SA-stamped.

`helpdesk.stage` ⚙️¶

Ticket pipeline stage. New, In Progress, Solved, Closed. Config.

`helpdesk.team` ⚙️¶

Support team. Groups agents and defines SLAs and escalation. Config. Could be aligned 1:1 with SAs in the future.

`helpdesk.sla` ⚙️¶

SLA policy. Service Level Agreement rules — response time, resolution time per priority. Config.

`helpdesk.sla.status` ⚙️¶

SLA status. Per-ticket SLA tracking record (met / failed). System-maintained.

`helpdesk.tag` ⚙️¶

Ticket tag. Classification labels for tickets. Config.

27. Rental¶

Module name: sale_renting

`sale.order` (rental) ✅¶

Rental order. In Odoo 16+, rentals use sale.order with is_rental_order = True. The same stamp fields that cover sale.order apply to rental orders. Already covered.

`rental.order.line` ⚙️¶

Rental line. A sale.order.line with rental-specific fields (pickup date, return date, duration). Inherits from parent order.

28. Subscription (Native Odoo)¶

Module name: sale_subscription

In Odoo 16/17/18, subscriptions are implemented as recurring sale.order records rather than a separate model. The sale.order already carries the SA stamp. No additional objects.

`sale.order` (subscription) ✅¶

Recurring orders share the sale.order model with subscription_state field: - upsell — ready for upselling - churned — cancelled - in_progress — active - paused — temporarily paused

Already stamped via sale_order_ext.py.

29. eCommerce & Website¶

Module name: website / website_sale

`website` ⚙️¶

Website record. Represents the Odoo website instance — domain, theme, languages. Config.

`website.page` ⚙️¶

Web page. A page on the website with URL, content, SEO settings, and publish state. Content management — no SA stamp needed unless SA-specific landing pages are tracked.

`website.menu` ⚙️¶

Navigation menu item. Config.

`website.visitor` 🟢¶

Anonymous / identified website visitor. Tracks visitor sessions, page views, and lead generation on the website. If website visitors are attributed to specific SA referral campaigns, this could carry SA context. Low priority.

`website.track` ⚙️¶

Page view tracking record. A single page view event. Infrastructure.

30. Blog¶

Module name: website_blog

Already partially implemented in this codebase — blog.py controller serves blog content via /api/bff/articles.

`blog.post` ✅ (via API)¶

Blog article / post. A published article with title, body, cover image, and category. The /api/bff/articles BFF endpoint wraps blog.post for the frontend.

`blog.blog` ⚙️¶

Blog / publication. The parent category grouping blog posts (e.g. "News", "Technical Tips"). Config.

`blog.tag` ⚙️¶

Blog tag. Classification labels. Config.

`article.collection` ✅ (custom)¶

Custom article collection. The codebase adds a custom article.collection model (managed via article_collection.py) for curated content sets. Exposed via /api/bff/article-collections.

31. Live Chat¶

Module name: im_livechat

`mail.channel` 🟢¶

Live chat conversation / channel. Represents a real-time chat session between a customer and a support agent, or an internal channel. When used for customer support, the conversation should be attributable to an SA. Low priority — stamp the parent helpdesk.ticket instead.

`im_livechat.channel` ⚙️¶

Live chat configuration. Defines a chat widget for a website — which team handles it, which bot responds first. Config.

`chatbot.script` ⚙️¶

Chatbot script. Automated conversation flow. Config.

32. Email Marketing (Mass Mailing)¶

Module name: mass_mailing

`mailing.mailing` 🟢¶

Mass mailing campaign. An email blast sent to a mailing list or a filtered partner set. If SA-specific customer communication campaigns are run (e.g. "Send renewal reminder to all active subscriptions under SA Togo"), the campaign should carry SA context for attribution.

`mailing.contact` ⚙️¶

Mailing contact. A recipient in a mailing list. Separate from res.partner — contains only name and email. Reference data.

`mailing.list` ⚙️¶

Mailing list. A named group of mailing contacts. Config.

`mailing.trace` ⚙️¶

Delivery trace. Records whether a specific email was sent, opened, clicked, or bounced. System-maintained analytics.

33. SMS Marketing¶

Module name: sms / mass_mailing_sms

`sms.sms` 🟢¶

SMS message record. A single outgoing SMS. If agents or the system send SMS messages to customers under an SA (e.g. payment reminders, subscription renewal alerts), the SA context is useful for per-SA communication auditing.

`sms.template` ⚙️¶

SMS template. Reusable SMS message template with dynamic fields. Config.

`mailing.mailing` (SMS type) 🟢¶

SMS campaign. Mass SMS blast. Same governance relevance as email campaigns.

Module name: social

`social.post` 🟢¶

Social media post. Content scheduled or published on a social account (Facebook, Twitter/X, LinkedIn, Instagram, YouTube). Low SA governance relevance unless SA-specific social accounts are managed.

`social.account` ⚙️¶

Social media account. Connected platform account. Config.

`social.stream` ⚙️¶

Social media stream. A monitored feed (mentions, comments, messages). Config.

`social.stream.post` ⚙️¶

Stream post. A captured post from a monitored social stream. System-maintained.

`social.live.post` ⚙️¶

Scheduled post status. Tracks the publish status per platform per social.post. System.

35. Events¶

Module name: event

`event.event` 🟢¶

Event. A physical or virtual event — product launch, training, customer day, installation workshop. If SA-specific customer events are organised (e.g. "SA Togo Customer Training Day"), stamping the event enables per-SA event attribution.

Key fields: - name - date_begin / date_end - company_id - organizer_id → res.partner - seats_max / seats_available - registration_ids - tag_ids

`event.registration` 🟢¶

Event registration. A customer's sign-up for an event. If the registrant is a customer under an SA, this should carry SA context for post-event follow-up attribution.

`event.stage` ⚙️¶

Event pipeline stage. New → Confirmed → Ended / Cancelled. Config.

`event.tag` ⚙️¶

Event tag. Classification labels. Config.

`event.tag.category` ⚙️¶

Event tag category. Groups event tags. Config.

36. Surveys¶

Module name: survey

`survey.survey` ⚙️¶

Survey / questionnaire. A form with questions for collecting feedback or data. Config/template.

`survey.question` ⚙️¶

Survey question. An individual question within a survey. Config.

`survey.user_input` 🟢¶

Survey response (session). A customer's completed survey response. If SA-specific customer satisfaction surveys are run, stamping responses enables per-SA NPS or satisfaction reporting.

`survey.user_input.line` ⚙️¶

Survey answer line. A single answer to a single question. Inherits from parent response.

37. eLearning¶

Module name: slides

`slide.channel` ⚙️¶

eLearning course. A course with slides, videos, and quizzes. Config/content management.

`slide.slide` ⚙️¶

Course content (slide). A single content item (article, video, PDF, quiz) within a course. Config/content.

`slide.channel.partner` 🟢¶

Course enrolment. Records that a partner is enrolled in a course. If SA members are trained via eLearning, enrolments could carry SA context for training compliance reporting per SA.

`slide.tag` ⚙️¶

Course tag. Classification labels. Config.

38. Sign¶

Module name: sign

`sign.request` 🟡¶

Document signing request. Sends a document for electronic signature — contracts, agreements, delivery confirmations. When an agent gets a customer to sign a solar subscription contract under an SA, the signing request should carry SA context.

Key fields: - template_id → sign.template - request_item_ids — signatories - state — sent → signed / cancelled - reference - validity

`sign.request.item` ⚙️¶

Signing party. A single signatory in a sign.request. Tracks whether they have signed, when, and from which IP. Inherits from parent request.

`sign.template` ⚙️¶

Document template. A PDF with field placeholders for signatures, dates, names, etc. Config.

39. Documents¶

Module name: documents

`documents.document` 🟡¶

Document record. A managed file in the Odoo Documents app — PDFs, spreadsheets, images, contracts, certificates. When an agent uploads a customer document (ID copy, site photo, inspection report) under an SA, the document should carry SA context.

Key fields: - name - folder_id - partner_id — linked contact - owner_id → res.users - type — url / binary - attachment_id → ir.attachment - tag_ids

`documents.folder` ⚙️¶

Document folder. Hierarchical folder structure for organising documents. Config.

`documents.tag` ⚙️¶

Document tag. Classification labels. Config.

`documents.share` ⚙️¶

Document share link. A time-limited public or restricted sharing URL for a document. Infrastructure.

40. VoIP¶

Module name: voip

`voip.phonecall` 🟢¶

Phone call record. Logs an outgoing or incoming call — duration, direction, caller, and linked Odoo record. If agents make customer calls under an SA context, the call log should carry x_sa_id for per-SA communication tracking.

`voip.call.list` ⚙️¶

Call list. A pre-scheduled list of contacts to call (call campaign). Config.

41. Discuss (Messaging)¶

Module name: mail / discuss

`mail.message` ⚙️¶

Message / chatter entry. Every chatter note, email, and notification. SA context is on the parent document. Stamping messages directly is redundant and expensive at scale.

`mail.activity` 🟡¶

Scheduled activity. A to-do item on a document — call, email, meeting, upload document. If an agent schedules a follow-up activity under an SA context, stamping it enables per-SA activity pipeline reports without joining through the parent document.

`mail.activity.type` ⚙️¶

Activity type. Call, Email, Meeting, Document Upload, Sign, etc. Config.

`mail.thread` ⚙️¶

Mixin, not a model. mail.thread is a Python mixin class that adds chatter, followers, and activity capabilities to any model. It is not a database table.

`res.partner` (followers) ⚙️¶

Document follower. The mail.followers model records which partners follow a document for notifications. Infrastructure — no stamp.

`mail.channel` 🟢¶

Direct message / group channel. A persistent conversation between users or with a customer. Low priority for SA stamping.

42. Lunch¶

Module name: lunch

`lunch.order` ⚙️¶

Lunch order. An employee's daily lunch order from a provider. Internal HR benefit — no SA governance relevance.

`lunch.product` ⚙️¶

Lunch item. A food item available for ordering. Config.

`lunch.supplier` ⚙️¶

Lunch provider. A restaurant or catering company. Config.

`lunch.location` ⚙️¶

Lunch location. Canteen or delivery point. Config.

43. Referrals¶

Module name: hr_referral

`hr.applicant` (referral) ⚙️¶

Referred job applicant. An applicant referred by a current employee. Tracks the referral source for reward programmes. Internal HR — no SA governance relevance.

44. Barcode¶

Module name: stock_barcode

Barcode is an interface overlay on Inventory operations, not a separate model. It adds QR/barcode scanning capability to stock pickings and inventory adjustments. No distinct models — uses stock.picking, stock.move.line, stock.quant, and stock.lot.

IoT connection: Barcode scanners connected via IoT boxes power the barcode scanning interface. When a technician scans a kit's serial at an outlet, the IoT box sends the scan to Odoo's barcode module, which creates or validates a stock.move.line or stock.lot record.

45. Accounting Localisations¶

Module name: l10n_*

Localisation modules add country-specific charts of accounts, tax configurations, and reporting formats. Examples: l10n_tg (Togo), l10n_ke (Kenya), l10n_gh (Ghana), l10n_fr (France).

These modules do not introduce transaction models — they add configuration records (account.account, account.tax, account.fiscal.position) specific to local regulations.

No SA stamp needed on localisation config data.

46. Complete Object Table¶

#	Model	Module	SA Stamp
1	`res.partner`	base	✅
2	`res.company`	base	⚙️
3	`res.users`	base	⚙️
4	`res.country`	base	⚙️
5	`res.currency`	base	⚙️
6	`ir.attachment`	base	🟢
7	`ir.config_parameter`	base	⚙️
8	`ir.rule`	base	⚙️
9	`sale.order`	sale	✅
10	`sale.order.line`	sale	⚙️
11	`crm.lead`	crm	✅
12	`crm.team`	crm	⚙️
13	`crm.stage`	crm	⚙️
14	`crm.tag`	crm	⚙️
15	`account.move`	account	🔴
16	`account.move.line`	account	⚙️
17	`account.payment`	account	🟡
18	`account.journal`	account	⚙️
19	`account.account`	account	⚙️
20	`account.tax`	account	⚙️
21	`account.analytic.account`	account	🟡
22	`account.analytic.line`	account	🟡
23	`account.bank.statement`	account	⚙️
24	`stock.picking`	stock	🟡
25	`stock.move`	stock	⚙️
26	`stock.lot`	stock	🟡
27	`stock.quant`	stock	⚙️
28	`stock.location`	stock	⚙️
29	`stock.warehouse`	stock	⚙️
30	`stock.scrap`	stock	🟢
31	`mrp.production`	mrp	🟡
32	`mrp.bom`	mrp	⚙️
33	`mrp.bom.line`	mrp	⚙️
34	`mrp.workcenter`	mrp	⚙️
35	`mrp.workorder`	mrp	🟡
36	`mrp.unbuild`	mrp	🟢
37	`quality.check`	quality	🟡
38	`quality.alert`	quality	🟡
39	`quality.point`	quality	⚙️
40	`mrp.eco`	mrp_plm	🟢
41	`maintenance.equipment`	maintenance	🟡
42	`maintenance.request`	maintenance	🟡
43	`repair.order`	repair	🟡
44	`project.task` (FSM)	industry_fsm	🟡
45	`iot.box`	iot	🟢
46	`iot.device`	iot	🟢
47	`iot.trigger`	iot	⚙️
48	`pos.session`	point_of_sale	🟡
49	`pos.order`	point_of_sale	🟡
50	`pos.order.line`	point_of_sale	⚙️
51	`pos.payment`	point_of_sale	⚙️
52	`purchase.order`	purchase	🟢
53	`purchase.order.line`	purchase	⚙️
54	`fleet.vehicle`	fleet	🟢
55	`fleet.vehicle.log.fuel`	fleet	🟢
56	`fleet.vehicle.log.services`	fleet	🟢
57	`hr.employee`	hr	⚙️
58	`hr.department`	hr	⚙️
59	`hr.payslip`	hr_payroll	🟢
60	`hr.contract`	hr_payroll	⚙️
61	`hr.applicant`	hr_recruitment	🟢
62	`hr.appraisal`	hr_appraisal	🟢
63	`hr.leave`	hr_holidays	⚙️
64	`hr.attendance`	hr_attendance	🟢
65	`hr.expense`	hr_expense	🟢
66	`hr.expense.sheet`	hr_expense	⚙️
67	`project.project`	project	⚙️
68	`project.task`	project	🟢
69	`project.milestone`	project	⚙️
70	`account.analytic.line` (timesheet)	hr_timesheet	🟡
71	`planning.slot`	planning	🟡
72	`helpdesk.ticket`	helpdesk	🔴
73	`helpdesk.team`	helpdesk	⚙️
74	`helpdesk.sla`	helpdesk	⚙️
75	`mail.activity`	mail	🟡
76	`mail.message`	mail	⚙️
77	`sign.request`	sign	🟡
78	`sign.template`	sign	⚙️
79	`documents.document`	documents	🟡
80	`documents.folder`	documents	⚙️
81	`mailing.mailing`	mass_mailing	🟢
82	`sms.sms`	sms	🟢
83	`event.event`	event	🟢
84	`event.registration`	event	🟢
85	`survey.user_input`	survey	🟢
86	`slide.channel.partner`	slides	🟢
87	`website.visitor`	website	🟢
88	`voip.phonecall`	voip	🟢
89	`social.post`	social	🟢
90	`product.template`	product	✅
91	`product.product`	product	⚙️
92	`product.category`	product	⚙️
93	`product.pricelist`	product	⚙️
94	`abs.employee`	custom	⚙️ (IS the actor)
95	`abs.subscription`	custom	✅
96	`sales.session`	custom	🐛 (wrong name in _GOVERNED_MODELS)
97	`payment.attempt`	custom	✅
98	`payment.request`	custom	🔴
99	`ov.serviced_account`	custom	⚙️ (IS the anchor)
100	`ov.membership`	custom	⚙️ (IS the relationship)
101	`ov.asset`	custom	✅
102	`ov.outlet`	custom	⚙️

Odoo Modules — Complete Object Reference¶

Status Legend¶

Module Index¶

1. Base & Core¶

res.partner ✅¶

res.company ⚙️¶

res.users ⚙️¶

res.country / res.country.state ⚙️¶

res.currency ⚙️¶

res.lang ⚙️¶

ir.config_parameter ⚙️¶

ir.rule ⚙️¶

ir.model.access ⚙️¶

ir.attachment 🟢¶

ir.cron ⚙️¶

ir.sequence ⚙️¶

2. Sales¶

sale.order ✅¶

sale.order.line ⚙️¶

sale.report ⚙️¶

sale.payment.provider.onboarding.wizard ⚙️¶

3. CRM¶

crm.lead ✅¶

crm.stage ⚙️¶

crm.team ⚙️¶

crm.team.member ⚙️¶

crm.activity.type ⚙️¶

crm.tag ⚙️¶

crm.lost.reason ⚙️¶

4. Accounting & Finance¶

account.move 🔴¶

account.move.line ⚙️¶

account.payment 🟡¶

account.payment.term ⚙️¶

account.payment.term.line ⚙️¶

account.journal ⚙️¶

account.account ⚙️¶

account.account.type ⚙️¶

account.tax ⚙️¶

account.tax.group ⚙️¶

account.fiscal.position ⚙️¶

account.analytic.account 🟡¶

account.analytic.line 🟡¶

account.analytic.plan ⚙️¶

account.bank.statement ⚙️¶

account.bank.statement.line ⚙️¶

account.reconcile.model ⚙️¶

account.incoterms ⚙️¶

account.cash.rounding ⚙️¶