odoo-domain-playbookslisted

Customizing or extending a STANDARD Odoo business app — sale (quotation → order → delivery → invoice), stock / inventory (pickings, moves, reservation, lots), account / accounting (invoices, bills, taxes, posting), mrp / manufacturing (BoM, production, components), purchase (RFQ → PO → receipt → bill), or hr (employees, time-off). Use whenever the work touches one of these domains, even if the user doesn't say the word "skill" — any time you'd otherwise GUESS which method to override, which hook builds the next document, or how the sale→stock→account chain fires. Also holds COUNTRY/REGIME playbooks — currently Vietnamese accounting compliance (VAS, TT200→TT99 2026, e-invoice, VAT/CIT calendar, statutory reports). Each app here is a STARTING MAP of the key models, the methods to read first, and the right extension hook — NOT ground truth. Confirm every name against the running instance with the `odoo-introspect` skill before you write a line.
tuanle96/odoo-ai-skills · ★ 4 · AI & Automation · score 62

Install: claude install-skill tuanle96/odoo-ai-skills

# Odoo domain playbooks **Version floor: Odoo 17 / 18, through Odoo 19 (current LTS).** Method and field names below are the v17/18 standard; v16 and earlier differ (notably the v17 `stock.move.line` field rename — see `references/stock.md`), and v18.1 → 19 renamed several APIs (`check_access`/`has_access`, `_read_group`/`formatted_read_group`, `aggregator`, `record.env.*`) — confirm against the instance and `version-matrix.md`. A playbook is a **map, not the territory.** These "standard" apps are not one fixed thing — what exists in *this* database depends entirely on which modules are installed: - `sale` alone has no delivery; `sale_stock` adds the stock chain; `sale_management` adds templates/optional products. The procurement methods you want to hook **only exist with `sale_stock`**. - `account` localizations (`l10n_*`) heavily extend `_post` and add country-specific constraints — your override lands *among* them, at an MRO layer you can't guess. - `mrp` vs `mrp_workorder`, `purchase` vs `purchase_stock` — same story: different methods, different entry points. So the playbook tells you **where to look and what to read** — never what to type from memory. The field list, the MRO, the real `super()` chain, and the cross-model flow exist only in the running registry. ## The universal move (before customizing ANY app) **Step 0 — is it already native?** If the change *adds* behavior (a field, wizard, report, cron, automation) or *overrides* a flow method, first check what