はじめに：所有権と物理在庫を分けて考える
通常の在庫は「自社の倉庫にあれば自社の資産」というシンプルな関係で成り立っています。しかし現実のビジネスでは、物理的には自社倉庫にあるが所有権はまだ仕入先にある、あるいは物理的には顧客の倉庫にあるが所有権はまだ自社にある、といった「所有権と物理位置がずれた在庫」が数多く存在します。これが預託在庫（コンサインメント在庫）です。
なぜそんな運用が広く使われるのか（why so）。仕入先預託は「自社のキャッシュアウトを使用時点まで遅らせたい」「在庫リスクを仕入先に持たせたい」というニーズから生まれ、顧客預託は「顧客に常時在庫を置いておくことで失注を防ぎたい」「使用実績に応じて請求したい」というニーズから生まれます。どちらも「在庫の物理配置」と「所有権・支払タイミング」を切り離すことで、サプライチェーン全体の効率を上げる仕組みです。
ではどうすべきか（so what）。在庫の物理位置と所有権を別々に管理し、消費・引取のタイミングで初めて所有権が移転する仕組みをシステムで支える必要があります。SAPはこのために預託在庫機能を標準で持っており、特殊在庫タイプ（K：仕入先預託、W：顧客預託）として在庫を区別します。本記事では預託在庫の基本概念、SAP標準カバー範囲、アドオン事例までを整理します。MM全体の流れはMM業務フローを参照してください。
預託在庫の2つのパターン
仕入先預託（Vendor Consignment）
仕入先が自社倉庫に在庫を置き、自社が消費・出庫した時点で初めて所有権が移転し、買掛金が発生する仕組みです。SAPでは特殊在庫タイプ「K」で表現されます。
例：自動車工場のラインサイドに、ボルトメーカーが常時1万本のボルトを置いておく。工場が組立で500本使ったら、その500本だけが買掛金として計上される。
メリットは、自社のキャッシュフローが大きく改善し、欠品リスクを仕入先に転嫁できることです。デメリットは、棚卸時に仕入先在庫と自社在庫の区別を厳密に管理する必要があり、運用負荷が増える点です。
顧客預託（Customer Consignment）
自社の在庫を顧客の倉庫に置き、顧客が使用した時点で初めて売上計上される仕組みです。SAPでは特殊在庫タイプ「W」で表現されます。
例：医療機器メーカーが病院内に手術用器具を常時配備し、手術で使用された分だけ月末に請求する。
メリットは、顧客にとって「必要なときにすぐ使える」状態を作れるため失注防止になり、自社にとっても顧客接点の維持に有効です。デメリットは、自社の倉庫から物理的に離れた場所にある在庫を、自社資産として正確に管理し続ける運用責任が残る点です。
SAP標準でカバーできる範囲
仕入先預託の標準フロー
flowchart LR A[購買発注
K指定] --> B[仕入先納品
MIGO] B --> C[預託在庫
K在庫計上] C --> D[消費転記
MB1A/MIGO] D --> E((買掛金確定
MRKO))
ポイントは、納品時点では「在庫は増えるが買掛金は立たない」ことです。買掛金は消費転記（MB1A／MIGOでの出庫）によってMRKO（消費清算）で確定します。標準カスタマイズだけでこの流れがすべて実装されており、追加開発なしで運用に乗せられます。
顧客預託の標準フロー
顧客預託も同様に、SDの預託出荷（KB：Consignment Fill-Up）と預託発行（KE：Consignment Issue）の2段階で標準サポートされています。預託出荷では物流のみ動き売上は立たず、預託発行（顧客が使用した数量を申告）で初めて請求と売上が計上されます。
標準でできること
- 仕入先預託・顧客預託それぞれの特殊在庫タイプ管理
- 預託品目専用の単価マスタ（INFORECORD）
- ロット管理との併用
- 預託在庫の在庫照会（MMBE、MB52）
- 預託在庫の棚卸（MI31などで特殊在庫指定）
- MRP上での預託在庫の取扱い（消費可能在庫としてカウント）
SAP標準でカバーできない範囲
1. 多階層の預託（預託の預託）
仕入先預託で受け取った部品を、さらに自社の協力工場に預託として渡す、という多階層の預託は標準では表現できません。階層を維持するには、独自テーブルでの管理かアドオンが必要です。
2. 預託品の複雑な単価ロジック
預託品の単価が「使用数量に応じてボリュームディスカウント」「月次累積で段階的に変動」といった複雑なルールを持つ場合、標準のINFORECORDだけでは表現できず、価格決定BAdIや独自の単価計算ロジックが必要になります。
3. 顧客側システムとの自動連携
顧客預託では、顧客倉庫での消費数量を自社SAPに反映する必要があります。顧客が手入力で送ってくれるならよいですが、IoTセンサーや顧客の在庫管理システムから自動連携したい場合は、Integration Suiteなどを使ったAPI連携アドオンが必要です。詳しくはSAP Integration Suite入門を参照してください。
4. 預託在庫の収益認識タイミング調整
会計基準（IFRS 15／ASC 606）の要件で、「使用時点」ではなく「特定のイベント発生時点」で収益認識したい場合、標準の預託発行では細かいタイミング制御ができないため、SDのアドオンで調整することがあります。
現場で頻出するアドオン事例
事例1：預託在庫アラートメール
仕入先預託の在庫が一定数を下回ったら、自動で仕入先に補充依頼メールを送るアドオン。MM側のジョブで毎朝在庫水準をチェックし、SCOTやBTPのEmail Service経由で送信します。
事例2：顧客預託の使用報告フォーム
顧客が自社ポータルから預託使用数量を入力するWebフォームを作り、入力された情報を自動でSAPの預託発行に転記するアドオン。FioriまたはBTPのSAP Buildで構築するケースが増えています。詳しくはSAP Build入門を参照してください。
事例3：預託在庫レポートの強化
標準のMB52では、預託在庫を仕入先別・顧客別に集計しにくいことがあります。CDSビューとFioriカスタムアプリで、預託在庫専用ダッシュボードを作るパターンは定番です。
事例4：消費清算の自動化
MRKO（仕入先預託の消費清算）を毎月手動で回している現場で、自動スケジューリングと例外検出を組み合わせたバッチアドオンを作ることがあります。
なぜアドオンを最小化すべきか（why so）。預託在庫まわりは会計仕訳と直結しており、改造のミスが直接決算に影響するからです。預託在庫のアドオンは「業務の利便性向上」のためだけに使い、会計ロジックそのものは標準のまま動かすのが鉄則です。
預託在庫導入時の注意点
- 預託在庫は会計上の取り扱いが通常在庫と異なるため、経理部門との事前合意が必須
- 棚卸時に「自社在庫」と「預託在庫」を混同しないよう、現場の在庫表示・ラベルを工夫する
- 仕入先・顧客との契約書に「預託在庫の所有権移転条件」を明文化する
- MRPの設定で預託在庫を消費可能在庫に含めるかどうかを必ず確認する
- 会計監査時に預託在庫の証憑を提示できる準備をしておく
よくある疑問（FAQ）
Q. 預託在庫は自社のB/Sに資産計上されますか？ A. 仕入先預託は所有権がまだ仕入先側にあるためB/S上の自社資産にはなりません。顧客預託は逆に自社資産として残ります。これが預託在庫の最大の特徴です。
Q. 預託在庫品目を通常品目として購入することもできますか？ A. できます。同じ品目コードでも、購買発注時の特殊在庫指定で区別されます。ただし運用が複雑になるため、できるだけ品目単位で運用を統一するのが望ましいです。
Q. 仕入先預託と外注加工は何が違いますか？ A. 仕入先預託は「仕入先のものを自社で消費する」のに対し、外注加工は「自社のものを仕入先で加工してもらう」関係です。在庫の所有権の方向が逆です。
Q. 預託在庫はEWMでも使えますか？ A. 使えます。EWM側でも特殊在庫タイプを引き継ぎ、ハンドリングユニットや倉庫タスクと組み合わせて管理できます。詳しくはEWM業務フローを参照してください。
Q. 顧客預託の収益認識タイミングはいつですか？ A. 標準では「預託発行（顧客が使用を申告した時点）」で売上計上されます。会計基準上の解釈は監査法人と必ず確認してください。
まとめ
- 預託在庫は「物理位置と所有権を分離する」仕組みで、仕入先預託（K）と顧客預託（W）の2種類がある
- 仕入先預託は買掛金タイミングを消費時点に遅らせ、キャッシュフローと在庫リスクを最適化
- 顧客預託は顧客の倉庫に在庫を置くことで失注を防ぎ、使用実績に応じて売上計上する
- SAP標準で発注・納品・消費・清算の一連の流れがすべてサポートされている
- 標準でカバーできないのは多階層預託・複雑な単価ロジック・顧客システム連携・収益認識タイミング調整など
- アドオンは利便性向上に限定し、会計ロジックは標準のまま動かすのが鉄則
- 経理部門・契約書・棚卸運用との整合を最初に取らないと運用が破綻する
預託在庫は「在庫の概念を所有権と物理位置に分解できる」点で、サプライチェーンの自由度を大きく広げる仕組みです。SAPの標準機能だけで多くを実現できる成熟領域なので、まずは標準の枠の中で運用を組み立てることから始めるのがおすすめです。
預託在庫を含むMM領域の業務フローをより深く理解するには、S/4HANAの全体像を先につかんでおくのが近道です。約2時間の動画で主要機能と特徴を一通り押さえられます。