イントロダクション
Odooでは“モデル”がデータの設計図です。売上伝票や請求書、取引先などビジネスで扱うあらゆる情報はモデルに従ってデータベースに格納されます。
モデルの理解は、開発者だけでなく業務コンサルタントにとっても不可欠です。モデルはフィールドや関連、業務ロジックを決める土台であり、正しい設計がシステムの安定性と拡張性を左右します。
ここではOdooで最も重要なモデルの一つである sales.order に焦点を当てます。カスタムモジュールの作成や外部システム連携、販売プロセスの設定を行う際に必ず関わるモデルです。
sales.order モデルとは何か
sales.order は見積と受注を表すモデルです。請求や出荷の前段階として、販売取引の全情報を一元管理します。
このモデルは主に販売（Sales）アプリケーションで使用されます。
営業担当が見積を作成すると sales.order レコードが生成され、顧客の承認でドラフト（見積）から受注へと状態が変わります。同じモデルで両方の状態を持ち、state フィールドでライフサイクルを管理します。
他のモジュールはモデル継承で機能を追加します。CRMは案件との紐付けを行い、会計は請求関連のフィールドを追加、在庫は出荷日や引当情報を加えるなど、コア構造を複製せず必要な拡張だけを行います。
モデルの主要フィールド
ここからは sales.order の主要フィールドを紹介します。これらを押さえておけば見積・受注の運用や開発がスムーズになります。
1. name
型: Char。注文番号や見積番号を保持します。通常は自動採番（例: S00042）され、一覧や書類の主要な識別子として使われます。
2. state
型: Selection。見積から受注、出荷・請求完了、キャンセルまでの状態を追います。主な値は draft（見積）、sent（顧客へ送付済）、sale（受注確定）、done（出荷・請求完了）、cancel（キャンセル）。状態によって可能な操作が変わります。
3. partner_id
型: Many2one (res.partner)。顧客を示す必須フィールドです。取引先に関する処理やレポートで主要に使われます。
4. partner_invoice_id
型: Many2one (res.partner)。請求先住所。未指定の場合は partner_id が使われます。本社請求など請求先が別の場合に設定します。
5. partner_shipping_id
型: Many2one (res.partner)。納品先住所。未指定時は partner_id にフォールバック。出荷処理や配送料計算で参照されます。
6. user_id
型: Many2one (res.users)。担当営業や責任者を示します。CRMの集計やコミッション計算、アクティビティ割当で利用されます。
7. team_id
型: Many2one (crm.team)。営業チーム。メンバーをグルーピングし、チーム別のKPIやダッシュボードに反映されます。
8. date_order
型: Datetime。注文日。ドラフトでは作成日、確定後は確定日として使われ、集計や並び替えに重要です。
9. validity_date
型: Date。見積の有効期限。期限切れ後は見積が無効となる運用に使います。期間限定オファーで有用です。
10. commitment_date
型: Datetime。顧客向けの約束納期。設定すると在庫の引当や出荷予定がこの日付基準で調整されます。顧客対応で重要な項目です。
11. order_line
型: One2many (sale.order.line)。行アイテム群。製品、数量、単価、税情報がここに入るため、オーダーの実体はこのフィールドで表現されます。
12. amount_untaxed
型: Float。税抜小計。注文行から計算され、画面表示や集計用に使われます。
13. amount_tax
型: Float。税額合計。税設定に基づいて行から算出され、見積書や請求書に表示されます。
14. amount_total
型: Float。税込合計。請求や会計集計で最終的に重要となる金額です。
15. currency_id
型: Many2one (res.currency)。通貨。会社や価格表から継承されることが多く、金額フィールドはこの通貨で扱われます。
16. pricelist_id
型: Many2one (product.pricelist)。適用する価格表。行の単価算出に使われ、取引先や手動設定で切り替えられます。
17. payment_term_id
型: Many2one (account.payment.term)。支払条件（例：翌月末、前金50%）。請求作成時に引き継がれます。
18. fiscal_position_id
型: Many2one (account.fiscal.position)。税率変換や税区分のマッピングを行うためのフィールド。海外取引や特例に対応する際に設定します。
19. client_order_ref
型: Char。顧客側の発注番号や参照番号。顧客提供の注文番号を書類やレポートで表示するときに使います。
20. origin
型: Char。発生元ドキュメントの参照。例えば案件（opportunity）から生成された場合はその名前を入れてトレーサビリティを保ちます。
21. create_date
型: Datetime。レコード作成日時。Odooが自動管理し、監査や履歴確認に役立ちます。
22. write_date
型: Datetime。最終更新日時。こちらも自動管理で、いつデータが変更されたかを追跡できます。
23. note
型: Text。契約条件や社内メモなど自由記述領域。見積書や請求書に表示でき、特記事項の記録に使います。
24. require_signature
型: Boolean。True の場合、顧客の電子署名が完了しないと受注確定できません。ECやポータルでの承認フローに有効です。
25. require_payment
型: Boolean。True の場合、確定前に支払確認が必要になります。前払いやデポジット運用で使います。
26. invoice_status
型: Selection。請求状況を示します：no（未請求）、to invoice（請求準備あり）、invoiced（請求済）、upsell（追加請求あり）。
27. locked
型: Boolean。True のとき編集不可となります。受注確定や会計伝票作成時に自動でロックされることが多いです。
28. company_id
型: Many2one (res.company)。マルチカンパニー環境でどの会社に属するかを示します。表示やアクセス制御に影響します。
29. tag_ids
型: Many2many (crm.tag)。分類用タグ。フィルターやセグメント、レポートの柔軟な切り口として使えます。
30. signed_by
型: Char。署名が求められた場合の署名者名を保存します。監査証跡として有用です。
31. signed_on
型: Datetime。署名日時。署名が必要なワークフローで記録されます。
32. prepayment_percent
型: Float。前払割合。require_payment と組み合わせて前受金の比率を管理します。
業務フローでの使われ方
1. 見積から受注へ
営業が見積（ドラフト）を作り、行を追加して価格を設定し顧客へ送付。顧客が承認すると state が sale に変わり、請求や出荷処理へとつながります。
2. ECサイトと顧客ポータル
ウェブ注文はそのまま sales.order レコードとして生成されます。オンライン決済や署名を強制したい場合は require_payment / require_signature の設定で運用できます。
3. CRM からの受注作成
案件が成約すると見積が自動作成され、origin に案件名が残ります。user_id や team_id は商談管理や報酬算出に反映されます。
4. 請求処理
確定済み注文から請求書を作成します。請求書の明細は受注行から引き継がれ、支払条件や会計上の設定も注文から継承されます。invoice_status で請求の進捗を追います。
5. 出荷と約束納期
commitment_date を使って出荷スケジュールを組み、partner_shipping_id を元に配送先を決定します。納期遵守のために重要なフィールドです。
開発者による拡張方法
開発者はモデル継承やメソッド上書きなどで sales.order を拡張できます。設計パターンを正しく使うことが重要です。
モデル継承の使い方
_inherit = 'sale.order' を使って既存モデルを拡張します。フィールド追加やメソッドのオーバーライド、制約追加が可能で、変更は別モジュールにまとめることで将来のアップグレードを容易にします。
フィールドの追加
継承モデルで新しいフィールドを定義します。Char、Many2one、Boolean、Integer、Text、Selection といった適切な型を選び、マルチカンパニー環境では company-dependent な設計も検討してください。
Pythonでの拡張
action_confirm、create、write 等をオーバーライドして処理を追加できます。既存の処理は super() で呼び出しつつ、依存関係のある算出フィールド等には注意が必要です。
Odoo Studio の活用
Odoo Studio を使えばコードを書かずにフィールド追加ができます。短期的なカスタマイズには便利ですが、複雑なロジックや将来の保守性を考えるとカスタムモジュールで実装する方が堅牢です。
ベストプラクティス
- 各ステージに適切な state を使い、確認ロジックを迂回しないこと。状態管理を飛ばすと後続処理が壊れる原因になります。
- 顧客に約束した納期がある場合は commitment_date を必ず設定しましょう。出荷計画や在庫引当の精度が上がります。
- 与信や集計で会社単位の最上位取引先が必要な場合は commercial_partner_id を使うと便利です。
- API連携を作る際は XML-RPC か JSON-RPC を利用します。sales.order は外部から利用可能なので外部IDのマッピングや参照整合に注意してください。
- カスタムフィールドは
x_プレフィックスかモジュール固有のプレフィックスを付けて、将来のOdooバージョンとの衝突を避けましょう。
よくあるミス
- ロック済みの受注を無理に編集しないこと。編集が必要な場合はリビジョンを作るか正しいワークフローで対応してください。
- partner_id、partner_invoice_id、partner_shipping_id を混同しないこと。それぞれ目的が異なるため、住所が異なる場合は全て正しく設定しましょう。
action_confirmを上書きして super() を呼ばないのは危険です。他モジュールとの連携や将来のアップグレード時に不具合を招きます。- 既存データがある環境で必須のカスタムフィールドを追加する際はデフォルト値を設定しないと、バリデーションで既存レコードがエラーになることがあります。
- 通貨や価格がデフォルトと異なる場合は pricelist_id を適切に設定してください。価格ミスは請求トラブルにつながります。
まとめ
sales.order はOdooの販売プロセスの中核です。見積や受注のデータを保持し、他モジュールから拡張されることで販売業務全体を支えます。
業務要件を設計するコンサルタントでも、カスタムを作る開発者でも、sales.order の構造と特性を理解しておくことは、手戻りを減らし安定運用につながります。
Odoo導入のサポートが必要ですか？
Dasolo はOdooの導入・カスタマイズ・最適化を支援します。API連携や開発を得意とし、sales.order を含むOdooのデータ設計に深い知見を持つチームが対応します。
Odooの導入支援やカスタム開発、連携でお困りならご相談ください。 デモを予約する プロジェクトについて話し合いましょう。