--- title: "Odooカスタマイズの実装手順：継承モジュールの書き方とOdoo 20への追従" url: "https://www.issoh.co.jp/tech/details/18966/" published: 2026-10-27 updated: 2026-10-27 categories: ["業務システム"] publisher: "株式会社一創" --- # Odooカスタマイズの実装手順：継承モジュールの書き方とOdoo 20への追従 Odooのカスタマイズは、標準のソースを書き換えず、既存のモデルや画面を継承する自作モジュールを足して行います。この記事では、受注に「金額しきい値を超えたら承認が要る」ルールを足す例で、`_inherit`によるモデル継承、受注確定のフック上書き、XPathによるビュー継承、テストまでをコード付きで説明する記事です。後半では、Odoo 20.0でアクセス権の定義ファイルが`ir.access.csv`へ変わった点と、版を上げるときの移行スクリプトの書き方を扱います。数値と仕様は2026年10月27日時点の公式ドキュメントとGitHubのソースで確かめたものです。 ## まとめ：Odooカスタマイズは継承で差分だけを足し、版移行の手順まで先に組む Pythonでカスタマイズするなら、提供形態はOdoo.shかオンプレミスに限られます。Odoo OnlineにはPythonを含む自作モジュールを入れられません。モジュールでは、既存モデルは`_inherit`だけで拡張し、標準メソッドは中身を丸ごと書き換えず、`super()`を呼ぶ小さなフックを上書きします。画面はXPathで差分だけを足します。 Odoo 20.0では、19.0までの`ir.model.access.csv`と`ir.rule`が`ir.access`に統合されました。19.0以前に書いたモジュールは、`odoo-bin upgrade_code`で変換してから差分を目で確かめます。項目名を変えるときは`migrations`フォルダの移行スクリプトでデータを引き継ぎます。設定とStudioで済む要件にはコードを書かない。これが版移行の費用を抑える一番の手です。 ## Odooカスタマイズの手段の切り分けとPythonで書くべき範囲 手段は設定、Studio、カスタムモジュールの3段階です。料金プランと提供形態の比較は[Odooとは？オープンソースERPの機能・料金・Community版との違いとOdoo 20の要点](https://www.issoh.co.jp/tech/details/10519/)で整理しているので、ここではコードを書くかどうかの線引きだけを扱います。 ### Pythonのカスタムモジュールが要る業務要件と提供形態の制約 コードが要るのは、標準の処理の途中に業務ルールを差し込みたいときです。受注確定の前に独自の検査を入れる、他システムと受け渡す項目を足す、といった要件がこれに当たります。項目や画面の配置を変えるだけならStudioで足ります。 公式の[Upgrade a customized database](https://www.odoo.com/documentation/20.0/developer/howtos/upgrade%5Fcustom%5Fdb.html)は、Odoo OnlineではPythonを含むカスタムモジュールのインストールを認めていないと明記しています。コードを書く前提なら、Odoo.shかオンプレミスを最初から選ぶ必要があります。オンプレミスの20.0は、[Source install](https://www.odoo.com/documentation/20.0/administration/on%5Fpremise/source.html)のとおりPython 3.12以上とPostgreSQL 16以上が前提です。 ### コードを書く前に標準機能で足りるかを確かめる購買の二段階承認の例 承認ルールは標準に入っていることがあります。購買には二段階承認の設定があり、20.0のソースでは会社ごとの金額しきい値`po_double_validation_amount`の既定値が5000です。購買の承認ならモジュールを書く理由はありません。 公式の移行手順も、版を上げる前に自作機能を標準と突き合わせ、重なるものは消すよう求めています。カスタマイズの量は、そのまま版移行の作業量になります。この記事の承認ルールは受注側の例として書いていますが、実案件では先に標準設定とApps Storeを確かめてください。 ## カスタムモジュールの構成と\_\_manifest\_\_.pyに書く依存関係の決め方 モジュールは`__manifest__.py`を持つPythonパッケージです。`--addons-path`に置いたフォルダから読み込まれます。 ### 受注承認モジュールのディレクトリ構成とマニフェストの依存関係・版指定 受注承認モジュールの構成と、\_\_manifest\_\_.pyのdepends・data・versionの書き方は次のとおりです。`depends`には拡張する標準モジュールを書きます。`sale`を指定すれば、依存先の`sales_team`も先に読み込まれます。 ``` issoh_sale_approval/ ├── __init__.py ├── __manifest__.py ├── models/ │ ├── __init__.py │ ├── res_company.py │ └── sale_order.py ├── views/ │ └── sale_order_views.xml └── tests/ ├── __init__.py └── test_sale_approval.py # __manifest__.py { "name": "Sale Approval Threshold", "version": "20.0.1.0.0", "depends": ["sale"], "author": "Your Company", "license": "LGPL-3", "data": [ "views/sale_order_views.xml", ], } ``` [Module Manifests](https://www.odoo.com/documentation/20.0/developer/reference/backend/module.html)によると、`data`のファイルはインストール時と更新時に必ず読まれ、`license`の既定値はLGPL-3です。`data`は書いた順に読み込まれるため、参照される側のファイルを先に並べます。`version`は移行スクリプトのフォルダ名と対応するので、`20.0.1.0.0`のように本体の版を含めた形で書いておくと後で迷いません。 ### \_inheritだけの拡張と\_name併用の新モデル、\_inherits委譲の違い [ORM APIの継承と拡張](https://www.odoo.com/documentation/20.0/developer/reference/backend/orm.html#inheritance-and-extension)には3つの方式があります。実務で使うのはほぼ1つ目です。 | 書き方 | 結果 | 使う場面 | | ---------------- | ------------- | ------------- | | \_inheritだけ | 既存モデルをその場で拡張 | 項目追加・処理の上書き | | \_nameと\_inherit | 既存を土台に別モデルを作る | 似た台帳を別テーブルで持つ | | \_inherits | 親レコードへ項目を委譲 | 原則使わない | `_inherits`について、公式は「おおむね実装されている程度なので、できれば避ける」と書き、連鎖させた場合の動作は保証しないとしています。委譲ではメソッドは継承されず項目だけが見える点も、想定外の不具合の元になります。 ## 受注に承認ステップを足すモデル継承とフック上書きの実装コード ここからは、受注金額が会社ごとのしきい値以上なら、営業マネージャーの承認が無いと確定できないようにします。 ### 会社ごとのしきい値を持つ計算項目をstore付きで定義する手順 `res.company`にしきい値を、`sale.order`に「承認が要るか」と「承認者」を足します。20.0の公式チュートリアルにならい、`_inherit`はリストで書いています。 ``` # models/res_company.py from odoo import fields, models class ResCompany(models.Model): _inherit = ["res.company"] sale_approval_threshold = fields.Monetary( string="受注承認のしきい値", currency_field="currency_id", default=1000000, ) # models/sale_order.py from odoo import api, fields, models from odoo.exceptions import AccessError, UserError class SaleOrder(models.Model): _inherit = ["sale.order"] approval_required = fields.Boolean( compute="_compute_approval_required", store=True, ) approved_by_id = fields.Many2one( "res.users", string="承認者", copy=False, readonly=True, ) @api.depends("amount_total", "company_id.sale_approval_threshold") def _compute_approval_required(self): for order in self: threshold = order.company_id.sale_approval_threshold order.approval_required = bool(threshold) and order.amount_total >= threshold def action_approve(self): if not self.env.user.has_group("sales_team.group_sale_manager"): raise AccessError(self.env._("受注の承認は営業マネージャーだけが行えます。")) self.write({"approved_by_id": self.env.user.id}) def _confirmation_error_message(self): error = super()._confirmation_error_message() if error: return error if self.approval_required and not self.approved_by_id: return self.env._("しきい値以上の受注です。承認を受けてから確定してください。") return False @api.ondelete(at_uninstall=False) def _unlink_except_approved(self): if any(order.approved_by_id for order in self): raise UserError(self.env._("承認済みの見積は削除できません。")) ``` `store=True`にすると一覧で絞り込みや並べ替えができます。`@api.depends`に`company_id.sale_approval_threshold`まで書くのは、しきい値を変えたときに既存の受注も再計算させるためです。`amount_total`は受注の通貨建てなので、外貨の受注がある会社では会社通貨へ換算した値で比べる処理に直してください。 ### 受注確定処理全体ではなく検査フックだけを上書きする理由と影響範囲 20.0の[sale\_order.py](https://github.com/odoo/odoo/blob/20.0/addons/sale/models/sale%5Forder.py)を読むと、`action_confirm`は受注ごとに`_confirmation_error_message()`を呼び、文字列が返れば`UserError`で止める作りです。検査を足すだけなら、このフックを上書きするのが一番小さな変更になります。 `action_confirm`そのものを上書きすると、ロックやメール送信を含む確定処理全体の前後に自分のコードが挟まります。版が上がって標準の処理順が変わったとき、影響を受ける範囲が広い。公式チュートリアルも、上書きでは必ず`super()`を呼び、親と同じ型の値を返すよう求めています。 ### 削除の禁止をunlink上書きでなく@api.ondeleteで書く理由と注意点 削除を止めたいとき、`unlink`を上書きして例外を出す書き方は避けます。[ORM API](https://www.odoo.com/documentation/20.0/developer/reference/backend/orm.html)は、`unlink`の上書きはモジュールのアンインストール時にも例外を出し、データが残ってDBの整合が崩れると説明しています。 `@api.ondelete(at_uninstall=False)`なら、アンインストール中は検査が走りません。標準の`sale.order`も同じ方式で、送信済みや確定済みの受注の削除を`_unlink_except_draft_or_cancel`で止めています。メソッド名は`_unlink_except_`か`_unlink_if_`で始めるのが慣例です。 ## ビュー継承でフォームに承認ボタンと項目を足すXPathの書き方 画面は標準のフォームを書き換えず、差分だけを持つ継承ビューで足します。after・inside・attributesで挿入位置や属性変更を指定します。 ### ビュー継承のinherit\_idとpositionによる挿入位置・属性変更の指定 受注フォーム`sale.view_order_form`のヘッダーに承認ボタンを、支払条件の下に承認者を足す継承ビューです。 ``` sale.order.form.approval sale.order