導入
Odooでは、業務で扱うあらゆるデータ（発注書、請求書、在庫情報など）が“モデル”という単位で定義され、データベースに格納されます。モデルはデータの構造や関係性、保存の仕組みを決める設計図です。
モデルの理解は、開発者だけでなく業務設計者にも不可欠です。Odooのデータアーキテクチャはモデルが基礎になっており、フィールドやリレーション、業務ロジックの定義はすべてここで行われます。
この記事は、Odooで最も重要なモデルの一つであるpurchase.orderに焦点を当てています。カスタムモジュール作成、外部システム連携、調達フローの設定など、さまざまな場面でこのモデルに触れることになります。
purchase.order モデルとは何か
purchase.orderは、見積依頼（RFQ）や発注書を表すモデルです。入荷や仕入請求に至るまでの調達トランザクションをここで管理し、受領や仕入伝票に連携されます。
Purchaseアプリでの典型的な流れはこうです：購買担当がRFQ（下書き）を作成し、品目と数量を追加してベンダーへ送信します。ベンダーが受諾するか承認が行われると、レコードは下書きから確定（purchase）へ移行します。同一モデルでRFQと確定済発注を保持し、stateフィールドがライフサイクルを管理します。
Odooの他モジュールは継承を通じてこのモデルを拡張します。Inventoryは入荷やピッキングのロジックを追加し、Accountingは仕入請求に関わるフィールドをつなぎます。ManufacturingはBOM（部品表）から発注を生成するなど、コア構造を重複させずに必要な機能だけを追加します。
モデル内の主要フィールド
ここからは、purchase.orderで特に重要なフィールドを紹介します。これらを押さえておけば発注周りの作業やカスタマイズがスムーズになります。
1. name
タイプ: Char。発注番号や参照番号を保持します（例：PO00042）。通常自動採番され、一覧や印刷書類で主要な識別子として使われます。
2. state
タイプ: Selection。発注の状態を管理します。主な値は draft（RFQ）, sent（ベンダー送付済）, to approve（承認待ち）, purchase（確定）, done（受領・請求処理完了）, cancel（キャンセル）です。状態に応じて利用できる操作が変わります。
3. partner_id
タイプ: Many2one (res.partner)。取引先（仕入先）を指します。必須フィールドで、ベンダー関連のロジックや集計に使われます。
4. partner_ref
タイプ: Char。仕入先側の参照番号（サプライヤーPO番号など）を保存します。受領や請求書との照合や、書類表示に便利です。
5. date_order
タイプ: Datetime。発注日を示します。下書きでは作成日、確定済みでは確定日が入ります。レポートやデフォルトの納期計算に使われます。
6. date_approve
タイプ: Datetime。承認・確定日です。purchase状態に移る際に設定され、監査やレポートで参照されます（読み取り専用）。
7. order_line
タイプ: One2many (purchase.order.line)。発注の明細行群。各行に商品、数量、単価、税が入り、発注の実務的な中身を表します。
8. amount_untaxed
タイプ: Float。税抜小計。明細から計算され、表示や集計で使われます。
9. amount_tax
タイプ: Float。税額合計。税設定に基づき明細から算出され、発注書や請求書に表示されます。
10. amount_total
タイプ: Float。税込合計。請求・支払・レポートの主要な金額です。
11. currency_id
タイプ: Many2one (res.currency)。通貨を示します。通常は会社または仕入先に基づき設定され、金額関連フィールドはこの通貨で扱われます。
12. origin
タイプ: Char。発注の発生元を記録します。例えば販売注文や製造指示から自動生成された場合、その参照名が入ります。追跡性確保に役立ちます。
13. dest_address_id
タイプ: Many2one (res.partner)。納品先住所。未設定なら会社住所が使われます。ドロップシッピングでは顧客住所を入れてベンダーへ直送します。
14. priority
タイプ: Selection。通常/緊急といった優先度を示します。並び替えや強調表示に使われ、緊急扱いのフローを別にする場合があります。
15. invoice_status
タイプ: Selection。請求の進捗を示します：no（未請求）、to invoice（請求待ち）、invoiced（請求済み）。請求書作成ボタンの表示制御に関わります。
16. invoice_count
タイプ: Integer。関連する仕入伝票の件数を保持する算出フィールド。画面表示や伝票一覧を開くために使います。
17. invoice_ids
タイプ: One2many (account.move)。紐づく仕入伝票のレコード群。三者照合（発注・入荷・請求）や支払管理に使います。
18. picking_ids
タイプ: One2many (stock.picking)。関連する入庫／出庫伝票。Inventoryと連携してピッキングや入庫処理を管理します。
19. picking_count
タイプ: Integer。関連ピッキング件数の算出フィールド。画面から入庫一覧へ遷移する際に利用されます。
20. create_date
タイプ: Datetime。レコード作成日時。Odooが自動管理し、監査や稼働分析に使います。
21. write_date
タイプ: Datetime。最終更新日時。こちらも自動管理で、いつ情報が更新されたかを追跡できます。
22. notes
タイプ: Text。取引条件や社内メモなどの長文フィールド。発注書に表示したり、ベンダーへの特記事項を記載します。
23. company_id
タイプ: Many2one (res.company)。マルチカンパニー環境ではどの会社の発注かを示します。可視性やアクセスに影響します。
24. user_id
タイプ: Many2one (res.users)。発注担当者や責任者。承認ワークフローやアクティビティ割り当てに使います。
25. fiscal_position_id
タイプ: Many2one (account.fiscal.position)。税区分のマッピング用。国や特別な税制のある仕入先向けに適用されます。
26. payment_term_id
タイプ: Many2one (account.payment.term)。支払条件（例：翌月末、前受け50%など）。仕入伝票作成時に引き継がれます。
27. display_name
タイプ: Char。表示用名称。発注番号と仕入先情報を組み合わせた見やすいラベルで、Many2oneの候補表示などに使われます（読み取り専用）。
28. active
タイプ: Boolean。アーカイブ用フラグ。Falseにすると一覧から隠れますが削除されず履歴は残ります。
ビジネスのワークフローでの活用例
1. RFQ（見積依頼）から発注へ
購買担当が下書きでRFQを作り、明細を追加してベンダーへ送信します。ベンダーの承諾や内部承認により注文が確定（state = purchase）し、その後入荷や仕入伝票の作成へと進みます。
2. ベンダーからの入荷（受領）
入荷時は発注から受領伝票（ピッキング）を作成します。picking_idsが関連づけられ、受領数量が在庫へ反映され、仕入単価が商品コストに反映されます。
3. 仕入伝票（ベンダー請求）の作成
確定済み発注から仕入伝票を作成します。請求書行は発注の明細から引き継がれ、支払条件や税区分も発注の設定を基に適用されます。invoice_statusで進捗を追えます。
4. ドロップシッピング（直送）
販売がトリガーで発注が発生する場合、originに販売注文が記録され、dest_address_idは顧客住所になります。これにより仕入先が直接顧客へ出荷でき、販売と調達をつなぐ役割を果たします。
5. 製造（MRP）との連携
製造オーダーが部品を必要とする場面では、原材料を調達するために発注が生成されます。originが製造オーダーを指すことでトレーサビリティが保たれ、調達から生産までの一連の流れを管理します。
開発者による拡張方法
開発者は複数のパターンでpurchase.orderを拡張できます。Odooのモデル継承が基本の手段です。
モデル継承の使い方
_inherit = 'purchase.order'を使って既存モデルを拡張します。新しいフィールド追加、メソッドのオーバーライド、制約の追加などが可能で、カスタムモジュールとして分離しておくとアップグレード時に管理しやすくなります。
フィールド追加の注意点
継承モデルに新しいフィールドを定義します。Char、Many2one、Boolean、Integer、Text、Selectionなど適切な型を選び、マルチカンパニー対応が必要ならcompany-dependentな設計を検討してください。
Python側の拡張
button_confirmやcreate、writeなどをオーバーライドして業務ロジックを差し込みます。既存処理はsuper()で呼び出し、計算フィールドの依存関係に注意して副作用を避けてください。
Odoo Studioの活用
Odoo Studioならコードを書かずにフィールド追加が可能で、短期的な調整には便利です。ただし複雑なロジックや将来的なメンテナンス性を考えるとカスタムモジュールによる実装が望ましいです。purchase.orderはXML-RPC／JSON-RPCでAPI公開されており、外部連携も可能です。
運用のベストプラクティス
- 各段階に適切なstateを設定し、状態を飛ばしたり確認プロセスをバイパスしないこと。
- ベンダー側の参照番号（partner_ref）は必ず記録しましょう。入荷や請求とのマッチングが容易になります。
- originフィールドを活用して発注の起点を残しましょう。ドロップシップや製造連携での追跡に不可欠です。
- API連携を行う際はXML-RPC/JSON-RPCを使い、外部IDやマッピングを慎重に扱ってください。
- カスタムフィールドは競合を避けるためにモジュール固有のプレフィックス（通常はx_またはモジュール名ベース）を用いるのが安全です。
よくあるミスと落とし穴
- 確定済み発注を状態確認せずに直接修正すること。確定後は変更制約があるため、新規作成や所定のワークフローを使って対応すべきです。
- partner_idとdest_address_idを混同する誤り。前者は仕入先、後者は納品先（ドロップシップ時は顧客）です。
- button_confirmをオーバーライドしてsuper()を呼ばない実装。これにより他モジュールや将来のアップデートで連携が壊れる恐れがあります。
- 必須のカスタムフィールドをデフォルトなしで追加すること。既存データに対して検証エラーが発生し、アップグレード時に問題になります。
- マルチ通貨を扱う場合にcurrency_idを設定し忘れること。通貨不一致はコストや請求計算を狂わせる原因になります。
まとめ
purchase.orderはOdooの購買領域の中核です。RFQや確定発注を保存し、他モジュールからの拡張点として機能します。フィールドや拡張の仕組みを理解すれば、設定・カスタマイズ・連携が効率的に行えます。
業務設計担当者も開発者も、purchase.orderの仕組みをしっかり押さえておけば手戻りやミスを減らせます。
Odoo の導入支援が必要ですか？
DasoloはOdooの導入・カスタマイズ・最適化を支援する会社です。API連携や開発を得意とし、purchase.orderのようなコアモデルの取り扱い経験が豊富なチームが対応します。
Odooの導入支援、カスタムモジュール作成、外部連携が必要ならご相談ください。 デモを予約する プロジェクトについてご相談しましょう。