はじめに
Odoo では“モデル”がデータの設計図です。受注や在庫移動、入出庫など業務で扱う情報はすべてモデルに保存され、データベース上でどう扱うかはモデルによって定義されます。
モデルを理解することは、開発者だけでなく機能コンサルタントにとっても必須です。フィールドや関連、ビジネスロジックの定義がそのままシステムの挙動を決めるため、設計を押さえておけばカスタマイズやトラブルシューティングが格段に楽になります。
本稿は在庫管理アプリの中でも中核をなす stock.picking に焦点を当てます。独自の倉庫機能を作る場合や外部システム連携、フロー設計のいずれでも頻繁に関わるモデルです。
stock.picking モデルとは何か
stock.picking は Odoo における“移動（トランスファ）”を表すモデルです。倉庫作業の履歴と状態を集中管理する役割を持ち、各レコードは一度に行う商品の移動（ある場所から別の場所へ）を示します。
在庫モジュール全体で幅広く使われます。入荷、出荷、社内移動はいずれも stock.picking レコードを生成します。販売から出荷指示を確定したり、仕入れで受領を登録したり、倉庫間で移動を実行するときに、このモデルが作成・更新されます。
モデル本体は stock モジュールで定義され、他のモジュールは継承で必要な機能を追加します。販売は出荷に関するフィールドを付け足し、購買は入荷ワークフロー、製造は生産に関わる動きを追加するといった具合に、核を残して拡張されます。
また mail.thread や mail.activity.mixin を継承しているため、変更履歴の追跡やチャッター（メッセージ）、作業アクティビティのスケジューリングがピッキング単位で行えます。
モデルの主要フィールド
以下は stock.picking で特に重要なフィールド群です。これらを理解しておけば、移動や倉庫作業の制御やカスタマイズがしやすくなります。
1. name
型: Char。トランスファの参照番号を格納します。通常はシーケンスで自動生成され（例: WH/OUT/00001）、フォームのヘッダや一覧で主要な識別子として利用されます。
2. origin
型: Char。元になったドキュメントの参照です。出荷なら販売注文番号、入荷なら購買注文番号といった形で、トレースとレポートに役立ちます。
3. state
型: Selection。移動の状態を示します。Draft、Waiting Another Operation、Waiting、Ready、Done、Cancelled などの値を取り、各状態が可能な操作や画面表示を制御します。関連する stock.move から状態が算出されます。
4. picking_type_id
型: Many2one (stock.picking.type)。業務タイプ（受入／出荷／社内移動など）を定義します。必須で、タイプごとにデフォルトの出発地・到着地が設定されます。
5. move_ids
型: One2many (stock.move)。個別の在庫移動行です。製品と数量がここにまとまり、予約や可用性のロジックは基本的にこのレコード群に対して動作します。
6. move_line_ids
型: One2many (stock.move.line)。詳細な作業単位を表します。ロット／シリアル管理をする際の個別ロットや実際にピッキングされた場所・箱情報はこのテーブルに保存されます。
7. location_id
型: Many2one (stock.location)。出発拠点です。どこから荷物を取るかを示します。出荷なら倉庫の在庫ロケーション、入荷ならサプライヤーロケーションが入ります。
8. location_dest_id
型: Many2one (stock.location)。到着拠点です。どこへ移すか。出荷なら顧客の受領地点、入荷なら倉庫在庫ロケーションになります。
9. partner_id
型: Many2one (res.partner)。取引先です。出荷なら顧客、入荷なら仕入先が入ります。書類上の住所や配送業者連携で使われます。
10. scheduled_date
型: Datetime。処理予定日時。ピッキングの優先度や計画に影響します。手動で設定すれば関連する各移動にも予定日が反映されます。
11. date_deadline
型: Datetime。納期や期限を示す日付。販売や購買の約束日から流れてくることが多く、遅延検出や顧客約束日の管理に使います。
12. date_done
型: Datetime。移動が確定（またはキャンセル）された日時です。読み取り専用で、ピッキング完成時に自動設定されます。
13. priority
型: Selection。優先度レベル。高優先のピッキングから在庫が引き当てられるなど、緊急対応の際に利用されます。
14. move_type
型: Selection。出荷ポリシー。部分出荷を許す「可能な限り早く」か、すべて揃ってから出す「すべて準備完了時」かを決め、処理タイミングに影響します。
15. user_id
型: Many2one (res.users)。担当者です。割当てや作業負荷の管理に使われ、作成時は通常現在ユーザーがデフォルトになります。
16. company_id
型: Many2one (res.company)。会社情報。マルチカンパニー環境ではどの会社に属する移動かを決めます。通常ピッキングタイプから継承されます。
17. group_id
型: Many2one (procurement.group)。プロキュアメントグループ。複数の動き（ピッキング）を同一の注文やプロセスでまとめる際に関連付けます。
18. backorder_id
型: Many2one (stock.picking)。一部のみ検品して残りを後処理する際の元ピッキングを指します。部分完了から生成されたバックオーダーを追跡します。
19. backorder_ids
型: One2many (stock.picking)。このピッキングから派生したバックオーダーの一覧です。部分的に検品したときの残作業を管理します。
20. return_id
型: Many2one (stock.picking)。返品として作られたピッキングであれば、元のピッキングを参照します。返品ワークフロー管理に使います。
21. note
型: Html。倉庫向けの内部メモです。取扱注意事項や梱包指示などを記載して作業者へ共有できます。
22. signature
型: Image。配達時に取得した署名を格納します。配達完了証跡として添付ファイルに保存されます。
23. is_signed
型: Boolean。署名の有無を示すフラグで、signature フィールドから計算されます。
24. owner_id
型: Many2one (res.partner)。検品時に割り当てる所有者です。委託在庫や第三者所有品を扱うときに使います。
25. package_level_ids
型: One2many (stock.package_level)。包装単位やパッケージ階層を表します。ピッキング中に梱包レベルで移動行をまとめる際に利用します。
26. create_date
型: Datetime。レコード作成日時。Odoo のベースモデルが自動管理します。
27. write_date
型: Datetime。最終更新日時。これも自動管理されます。
28. active
型: Boolean。論理削除フラグ。False にするとアーカイブ扱いになります。ベースモデル由来の共通フィールドです。
業務ワークフローでの使われ方
1. 販売と出荷
販売注文を確定すると出荷オーダー（stock.picking）が自動作成され、出荷元や品目情報をもとに倉庫担当がピッキング・梱包・検品を行います。処理は Draft → Ready → Done のように状態が遷移します。
2. 購買と入荷
購買確定で入荷ピッキングが生成され、サプライヤーから倉庫へ受領します。partner_id は仕入先を示し、検品完了で在庫数量が更新されます。
3. 社内移動
倉庫間やロケーション間の移動は internal コードのピッキングで処理されます。両方のロケーションが社内在庫である点が特徴です。
4. 返品とバックオーダー
販売返品が発生すると返品用ピッキングが作成され、return_id で元の出荷と紐づけられます。部分検品した場合は backorder_ids に残作業が生成されます。
5. 製造と生産
製造オーダーは原材料消費のためのピッキングと、完成品の入庫用ピッキングを作ります。mrp モジュールはこれらの流れに stock.picking の拡張を加えます。
開発者はどう拡張するか
開発者は複数のパターンを使って stock.picking を拡張します。Odoo のモデル継承が主要な手段です。
モデル継承の利用
_inherit = 'stock.picking' を使ってモデルを拡張します。新しいフィールドを追加したり、メソッドをオーバーライドしたり、制約を付けることができます。継承で変更を別モジュールにまとめれば、将来のアップグレードも管理しやすくなります。
フィールドの追加
継承モデルで新しい Odoo フィールドを定義します。Char、Many2one、Boolean、Integer、Text、Selection など適切な型を選び、マルチカンパニー環境では company-dependent な扱いを検討してください。
Python 側の拡張
button_validate、action_assign、_create_backorder といったメソッドをオーバーライドして独自ロジックを入れます。元の動作を呼ぶ際は super() を使い、状態遷移や移動作成の副作用に注意しましょう。
Odoo Studio の活用
Odoo Studio を使えばコードを書かずにフィールド追加や簡単なレイアウト変更ができます。ラベル追加や内部メモなど軽微なカスタマイズには便利ですが、複雑な処理や外部キャリア連携は独自モジュールで実装する方が保守性は高いです。
推奨されるベストプラクティス
- 手動でピッキングを作成する場合は必ず picking_type_id を設定してください。デフォルトのロケーションや振る舞いはこれに依存します。
- origin フィールドは元ドキュメントを追跡するために活用しましょう。レポートやデバッグ時の手がかりになります。
- API 連携を作る際、stock.picking は Odoo API を通じて完全に操作可能です。move_ids 関係を通じて移動行を作成し、ピッキングだけを作って move を空にすることは避けてください。
- スケジュール日（scheduled_date）は計画や優先度に影響します。正しく運用することで引当や作業順序の精度が上がります。
- カスタムフィールドを作るときは
x_プレフィックスかモジュール固有の接頭辞を使い、将来の Odoo 公式フィールドとの衝突を避けてください。
よくある失敗例
- picking_type_id を設定せずにピッキングを作ること。これでデフォルトロケーションが誤ったままになり、在庫移動が想定外の場所で行われる恐れがあります。
- 確認後に move_ids を安易に書き換えること。状態遷移は複雑で、移動の追加や削除が思わぬ副作用を生みます。
- 出荷で partner_id を設定し忘れること。配送業者連携や書類印刷に支障が出ます。
- button_validate をオーバーライドして super() を呼ばないこと。バックオーダー生成や他モジュールとの連携が壊れる原因になります。
- move_ids と move_line_ids が常に同期していると仮定すること。詳細作業（move_line）は予約や詳細オペレーションを行ったときに初めて生成されるため、乖離が起こり得ます。
まとめ
stock.picking は Odoo の在庫管理で中核を担うモデルです。移動・出荷・入荷の中心情報を保存し、各モジュールが必要に応じて機能を付け足します。この構造を理解すれば、設定、カスタマイズ、外部連携が格段にしやすくなります。
倉庫プロセスを設計する機能コンサルタント、あるいはカスタムモジュールを開発するエンジニアのどちらにとっても、stock.picking を正しく理解しておくことは時間の節約とミス防止につながります。
Odoo の倉庫を最適化する準備はできていますか
Dasolo は Odoo の導入、カスタマイズ、最適化を支援します。API 連携やモジュール開発を得意とし、stock.picking を含むデータ構造に精通したチームが実装をサポートします。
Odoo の導入支援、倉庫モジュールのカスタマイズ、外部システムとの連携でお困りならお気軽にご相談ください。 デモを予約する プロジェクトについてお話ししましょう。