概要
Odooではデータの枠組みを“モデル”が担います。受注や請求、顧客情報のような業務データはすべてモデルに従って保存・管理され、画面表示やレポート、API連携の基盤になります。
モデルの理解は、システム設計やカスタマイズを行う上で不可欠です。フィールド定義、他モデルとの関連、保存時や更新時のビジネスロジックはすべてここで決まります。
ここでは、Odoo運用で最も頻繁に関わるモデルの一つであるres.partnerに焦点を当てます。カスタム開発、外部システム連携、ワークフロー設定のいずれでも、このモデルを操作する機会が多くあります。
res.partnerモデルとは何か
res.partnerは顧客、仕入先、取引先、法人・個人を表すモデルです。企業に関する住所や連絡先、税情報など当該パーティーに関する基本データが一元管理されています。
ほぼすべての主要モジュールから参照される共通基盤です。販売、CRM、請求、購買、ECなどで同じパートナー情報が使われ、たとえば受注で顧客を作成するとres.partnerのレコードが生成・参照されます。
ベースモジュールで定義され、他モジュールは継承して必要なフィールドやロジックを追加します。CRMならリード関連、会計なら与信や支払条件など、コア構造を重複させずに機能を付け足せます。
モデルで覚えておくべき主要フィールド
以下はres.partnerで頻繁に使われる主要フィールドです。これらを押さえておくとコンタクト管理や連携作業がスムーズになります。
1. name
型: Char。レコードの表示名です。法人なら会社名、個人なら氏名が入り、多くのビューや参照で主識別子として使われます。
2. create_date
型: Datetime。レコード作成日時。Odooが自動で管理するため、監査や作成時刻の抽出に便利です。
3. write_date
型: Datetime。最終更新日時。自動管理され、データの更新履歴や同期判定に役立ちます。
4. email
型: Char。主要なメールアドレス。通知や請求書送付、ポータルログインに使われ、可能な範囲で形式チェックが行われます。
5. phone
型: Char。代表電話番号。連絡先画面に表示され、電話対応や通知フローで使用されます。
6. mobile
型: Char。携帯番号。SMS送信や緊急連絡先として別途管理する場合に使います。
7. street
型: Char。住所の1行目。請求書や配送伝票に使われる標準的な住所ブロックの一部です。
8. street2
型: Char。住所の2行目。マンション名や部屋番号など詳細情報を格納します。
9. city
型: Char。市区町村。国ごとに住所フォーマットが異なる点に注意します。
10. zip
型: Char。郵便番号。配送計算や住所検証で使用されます。
11. state_id
型: Many2one (res.country.state)。都道府県や州を参照。country_idでフィルタされ、国によっては未使用のケースもあります。
12. country_id
型: Many2one (res.country)。国情報。住所書式や税制、ローカライズ挙動に影響します。
13. is_company
型: Boolean。レコードが会社か個人かを示します。会社は子連絡先を持て、個人はparent_idで会社に紐づけられます。
14. parent_id
型: Many2one (res.partner)。個人の所属企業を指すリンク。親から一部フィールドを継承でき、会社―担当者の階層管理に使われます。
15. child_ids
型: One2many (res.partner)。parent_idの逆参照。会社からその会社に属する連絡先一覧へ遷移できます。
16. company_id
型: Many2one (res.company)。マルチカンパニー環境でそのパートナーが属する会社を示します。表示制御やアクセスに影響します。
17. vat
型: Char。法人番号やVAT番号など納税者番号。国別フォーマットで検証され、請求や法令対応で重要です。
18. customer_rank
型: Integer。顧客ステータスの指標。売上があると自動で増え、顧客リストのフィルタや優先度判定に使えます。
19. supplier_rank
型: Integer。仕入先ステータス。購買や請求が発生すると増加し、ベンダー特定の助けになります。
20. user_id
型: Many2one (res.users)。担当営業や責任者。CRMや活動割当、レポート集計で参照されます。
21. type
型: Selection。子連絡先の住所種別（連絡先／請求／配送／その他）。伝票でどの住所を使うかを決める重要なフィールドです。
22. ref
型: Char。社内参照や外部システムのIDマッピング用コード。重複検出や連携で有用です。
23. website
型: Char。ウェブサイトURL。コンタクト画面やEC関連で表示・利用されます。
24. comment
型: Html。内部メモ。営業メモや特記事項を保持し、社内ユーザーのみが参照します。
25. active
型: Boolean。ソフト削除フラグ。Falseにするとデフォルト表示から隠れアーカイブ扱いになります（物理削除はされません）。
26. lang
型: Selection。優先言語。送信するメールや帳票の言語選択に使われ、親から継承されることもあります。
27. image_1920
型: Binary。パートナーの画像やロゴ。フォームやレポート、ウェブ表示用に複数サイズで保持されます。
28. category_id
型: Many2many (res.partner.category)。タグや分類。セグメント分けやマーケティング用フィルタに柔軟に使えます。
業務フローでの実務利用例
1. 販売・CRMでの使い方
営業が見積を作る際、顧客はres.partnerから選ばれます。リードや案件、受注が同一のパートナーレコードを参照し、customer_rankやuser_idが報告や担当割当を左右します。
2. 請求処理
請求書や支払伝票はパートナーの請求先情報を参照します。vatは税計算に使われ、与信や支払条件もパートナーに紐づけるのが一般的です。
3. 購買・仕入管理
発注や仕入請求は仕入先パートナーを参照します。supplier_rankでアクティブなベンダーを見つけ、buyer_idで仕入担当者を割り当てられます。
4. ECサイトとポータル
サイト登録や注文で顧客パートナーが自動作成され、注文管理やポータルアクセスに使われます。住所・連絡先情報はこのレコードから取得されます。
5. マルチカンパニー／連結運用
マルチカンパニーでは同一の実体が会社ごとに別パートナーとして存在する場合があります。company_idや社内ルールでデータ共有の仕組みを制御します。
開発者はこのモデルをどう拡張するか
開発者は複数のパターンでres.partnerを拡張します。モデル継承が基本手法です。
モデル継承の基本
モデルを拡張するには _inherit = 'res.partner' を使います。新しいフィールドの追加、既存メソッドのオーバーライド、制約の追加などを別モジュールで管理することで将来のアップグレード性を保てます。
フィールド追加のポイント
継承モデルで新しいOdooフィールドを定義します。Char、Many2one、Boolean、Integer、Text、Selectionなど適切な型を選び、マルチカンパニーではcompany-dependent設定を検討してください。
Pythonでの拡張
create、write、unlinkなどをオーバーライドしてビジネスロジックを組み込みます。既存処理は super() で呼び出し、計算フィールドや依存関係には注意を払ってください。
Odoo Studioの活用
Odoo Studioならコード不要でフィールド追加が可能です。手軽ですが、複雑なロジックや将来の保守性を考えるとカスタムモジュールの方が安全な場合があります。
実務で使えるベストプラクティス
- 会社―担当者の階層は正しく運用する
- まず会社レコードを作成し、その下にparent_idで担当者を追加する運用にすると継承や住所の一貫性が保ちやすくなります。
- top-levelの集約には commercial_partner_id を使う
- 与信やレポートで最上位の法人単位が必要な場合、commercial_partner_idを利用してグルーピングすると処理が簡潔になります。
- カスタムフィールドは命名規則を守る
よくあるミス
- 外部依存や将来の互換性を考え、カスタムフィールドはモジュールプレフィックスか
x_プレフィックスを使って衝突を避けましょう。 - 重複パートナーを作ってしまう
- 既存レコードを検索せずに新規作成してしまうこと。メールの正規化（email_normalized）やrefをキーにして重複チェックを入れましょう。
- parent_idとcompany_idの混同
- parent_idは担当者と会社の親子関係、company_idはレコードが所属するOdooの会社（複数会社運用）を示します。この違いを誤ると表示やアクセス制御で問題になります。
まとめと次の一手
typeを設定し忘れる
子連絡先のtypeを正しく設定しないと請求先・配送先が間違って選ばれることがあります。書類用の住所種別は必ず確認してください。
super()を呼ばないオーバーライド
コアメソッドを上書きしてsuper()を呼ばないと、他モジュールや将来のアップグレードで動作が壊れる可能性があります。
必須カスタムフィールドにデフォルトを入れない 既存データに対して必須化した場合、既存レコードがバリデーションで弾かれることがあります。既存データを考慮したマイグレーションを行ってください。 res.partnerはOdooの中心的なモデルです。顧客・取引先・仕入先を一元管理することで、設定やカスタマイズ、外部連携の土台が整います。フィールドの役割や拡張方法を理解すれば効率的な運用が可能です。