SAPのATPと在庫引当を徹底解説｜在庫を奪われない方法とは？

SAP S/4HANAの在庫管理を語るとき、必ずと言っていいほど現場で聞こえてくる言葉がある。

「その在庫、誰かに使われていませんか？」
「引当されているから、他から取られることはないだろう」
「俺（私）の在庫、どこに消えた！？」

SAP S/4HANAを導入し、MM（在庫管理）モジュールを導入しても、在庫に関する混乱はなかなか消えない。
むしろ、ATP・在庫引当・引落し といった概念が正しく理解されていないと、現場は混乱し、「在庫の奪い合い」はより複雑化する。

そこで本記事では、SAP初心者でも理解できるように、SAP S/4HANAにおける、ATPと在庫引当の仕組みを徹底解説する。
また、ATPと在庫引当に関する、初心者あるあるの疑問と誤解について、Q&A形式でお届けする。

さらに、ATPロジックのカスタマイズ（パラメータ設定）、引落しの情報が格納されているテーブルまで、ATPや引当てに関するあらゆる情報を完全網羅する内容となっている。

この記事を最後まで読めば、在庫を用途別にキープするには、どのような在庫管理方式を採用するのが適切なのか、迷わず運用できるようになるはずだ。

在庫争奪戦はなぜ起きるのか

在庫を減らすのは正義

企業経営において、在庫はコストである。
保管費用、廃棄リスク、陳腐化リスクを考えれば、在庫は少なければ少ないほどよい。
この考え方は正しく、多くの企業で「在庫最小化」は絶対的な正義として語られる。

その結果、SAPではMRPを用いて必要最小限の在庫を計画し、余剰在庫を極力持たない運用が推奨される。

しかし、在庫が最小化されればされるほど、別の問題が表面化する。
それが「在庫争奪戦」である。

本来、在庫は足りている

MRPを一言で言えば、「需要に応じて製品や部品を必要な分だけ供給するためのエンジン」だ。

MRPのインプット情報は、現在の在庫数と需要数（顧客からの注文や予測に基づく生産計画など）だ。
それを元に、必要なモノを・必要な時に・必要なだけ手配するのがMRPの役割である。

この原理・原則に基づいてMRPが動けば、会社の在庫はムダなく、最小限に抑えられる。

需要数が正確なら、供給数も正確に算出される。
つまり、MRPが正しく運用されている限り、在庫は過不足なく維持されるわけだ。

だから本来、在庫を奪い合う必要なんてない。
在庫はちゃんと、足りている――

理論上は。

足りなくなる理由① 業務プロセスの問題

営業、製造、保守、プロジェクト。
それぞれの部門は、自分たちの業務を止めないために在庫を必要とする。

• 営業は「この顧客向けの在庫」を確保したい
• 製造は「生産計画通りに部品を使いたい」
• 保守は「緊急対応用に在庫を残したい」

ところが、SAP上ではそれらが同じ一般在庫として存在しているケースが多い。
業務プロセスとして「誰が優先されるのか」が明確でなければ、ATPや引当を巡って衝突が起きるのは必然である。

足りなくなる理由② 人間心理の問題

在庫争奪戦の根底には、人間心理も深く関わっている。

• 一度確保した在庫は、手放したくない
• 将来のトラブルを恐れ、「念のため」押さえておきたい
• MRPの数字よりも「自分の経験」を信じたい

この心理が、「とりあえず在庫を確保（引当）だけしておく」という行動を生む。
結果として、在庫は足りているはずなのに使えない、という矛盾した状態が発生する。

在庫の所有者

SAPの在庫管理：まず「誰の在庫か」

SAPの在庫は「二階層構造」になっていると、前回の記事で解説した。

• 一階層目：誰の在庫か（在庫の所有者）
• 一階層目：どのような在庫か（在庫の状態）

このようにSAPシステムの在庫管理は、第一階層＝「誰の在庫か」という概念が先頭にくる。
この概念があるため、在庫の所有者は明確に区別できるようになっている。

受注在庫とプロジェクト在庫

受注在庫とプロジェクト在庫は、最初から「誰のものか」が明確だ。
そのため、在庫争奪戦は起きない。

奪い合いが起きるのは一般在庫

在庫の奪い合いが起きるのは、受注在庫でもなくプロジェクト在庫でもない、一般在庫である。
自由在庫／包括在庫とも呼ばれるこの在庫は、「みんなの在庫」だ。

ここで登場するのが、ATPと在庫引当である。
これは一般在庫を「使ってよいかどうか」を制御する仕組みだ。

ATPと在庫引当

ATPとは

SAPシステムにおけるATP（Available To Promise）とは、
「在庫を期日までに約束できるか」を判定する仕組みである。

受注登録時などに、

• 現在庫（利用可能在庫）
• 引当済数量
• 将来入荷予定

などを考慮し、「この数量をこの日付で約束してよいか」を判定する。

ATPはあくまで在庫引当の可否判断のロジックであり、在庫を論理的・物理的に押さえるものではない。

引当とは

在庫引当（Reservation）とは、在庫の中から、特定の要求数量を論理的に確保（予約）することである。

重要なのは以下の点だ。

注意すべき点は、
引当は在庫を「予約」するだけで、物理的にロックするわけではない。

引落しとは

在庫「引当」に対し、在庫「引落し」という処理もある。

引落しは、実際に在庫を消費する動作を指す。

• 出庫
• 生産消費
• 出荷

これらの動作によって、在庫数量が実際に減少する。
「引当」と「引落し」は言葉が似ているので混同されがちだが、全く別物である。

ATPと引当の違い

ATPと引当は「在庫を予約する」という目的において似ているが、その柔軟性に違いがある。

また、SAPモジュール視点で見れば、ATPは受注時に語られることが多く、SD寄りの機能である。
一方、引当は製造指図登録時に実行されるため、PP寄りの機能と言える。

項目	受注時の「引当」（ATP）	製造指図の「引当」（入出庫予定）
優先順位の変更	柔軟 納期回答を再計算（V_V2等）することで、後から引当を外したり、優先順位を変えたりしやすい。	固定気味 指図に紐付いているため、基本的には指図を修正・削除しない限り引当が維持される。
引当の単位	プラント/保管場所レベル 「どの保管場所から出すか」は出荷時に決めることも多い。	保管場所レベルが強い 構成品マスタで指定された特定の棚から引き当てる意識が強い。
後続処理への連動	出荷伝票へ 受注での引当分が出荷指示に引き継がれる。	出庫（261移動）へ 引当分がそのまま製造用出庫として処理される。

SAPにおける引当とは

SAPに引当という言葉はない

SAP ECC や S/4HANA には「引当」に相当する概念や機能があるものの、実は「引当」という言葉そのものは画面上に登場しない。

我々が業務でよく使う「引当」という表現も、SAPの中では用途に応じて「Available-to-Promise（ATP）」「Reservation」「Provision」など、異なる英語の用語で表現されており、それぞれ直訳や意訳の形で画面に表示されている。

このように、英語圏では機能ごとに言葉を使い分けているが、日本では「在庫引当」という言葉が商習慣として根付いているため、こうした違いを無視して、すべてひとまとめにして「引当」と呼んでしまうケースが多い。

この用語のズレが、SAPにおける「引当」の理解を難しくしている要因のひとつである。

なお、実際に在庫消費する「引落し」は画面上で見ることができる。

引当・引落しが可能なSAPの在庫

引当・引落しができるSAPの在庫は以下の通り。

SAPの引当 ＝ 利用可能在庫確認

SAPの処理名でいうと、引当に該当する処理は「利用可能在庫確認」である。
また、利用可能在庫確認の際に使われる確認ロジックが、ATPロジックである。

ATPロジックは「確認規則」としてカスタマイズ（パラメータ設定）ができる。

SAPで引当を実行する機能

SAPシステムにおいて、在庫引当＝利用可能在庫確認が行われるのは、基本的に、受注または製造指図を登録した時である。

1. 受注伝票の登録

T-Code: VA01「受注伝票登録」で受注伝票を登録する際、利用可能在庫に対するATP計算が実行され、利用可能在庫確認（在庫引当）が成功すると、受注所要量 （Sales Requirement）が登録される。

• MD04上の表示： CusOrd（受注）
• 書き込まれるテーブル： VBBE または VBBS

2. 製造指図の登録

T-Code: CO01「製造指図登録」で製造指図を登録またはリリースした時（自動登録を含む）、
構成品目についてATP確認が実行される。

製造指図を登録すると、構成品目のために「従属所要量（Dependent Requirement）」が生成される。
ATP確認は従属所要量をベースに利用可能在庫確認を実行し、利用可能在庫を確保（引当）できると、「確認済数量」を製造指図に登録する。
また、確認済数量は「入出庫予定（Reservation）伝票」として登録される。

• MD04上の表示： Resv（入出庫予定）
• 書き込まれるテーブル： RESB

在庫不足で利用可能在庫確保ができなかった場合、MD04では不足が表示され、MRPを実行すれば、従属所要量に対する追加の手配データが作成される。

3. 手動による入出庫予定の登録

SAPシステムにおいて、在庫引当と入出庫予定は同義である。
そのため、手動で在庫引当を行いたい場合は、入出庫予定データを手動で登録することになる。

T-Code: MB21「入出庫予定登録」は、手動で入出庫予定を登録する画面だ。

• MD04上の表示： Resv（入出庫予定）
• 書き込まれるテーブル： RESB

ただし、通常の業務では、在庫引当は受注伝票や製造指図の登録時点で自動的に実行される。
そのため、あえて手動で入出庫予定を登録する運用は、一般的には想定されにくい。
あくまで、在庫引当を手動で実行する技術的な方法である。

引当の順序を変更する：aATP（バックオーダー処理）

S/4HANAにおけるバックオーダー処理（BOP: Backorder Processing）は、一言でいうと
「在庫引き当てのやり直し」を行う機能である。

基本的に引当は、受注を登録した順、すなわち「早い者勝ち」で実行するが、「より重要な顧客」や「納期が近い注文」に優先的に在庫を再引当する仕組みである。

従来の標準バックオーダー処理（SAP GUIベース）

ECC時代から存在する、シンプルに在庫を再割り当てする機能。
特定の品目に対して手動で調整したい場合などに使われる。

T-CODE	機能名	特徴・用途
V.15	バックオーダー処理	品目ごとに受注の一覧を表示し、手動で確認数量を振り替えます。
V_V2	受注の再日程計画	入庫遅延時などに、受注日順などで一括してATP確認をやり直します。バックグラウンドジョブ（プログラム：SDV03V02）で回すのが一般的です。
CO06	受注のバックオーダー処理	1つの品目に対し、受注伝票や入出庫予定を並べて、対話形式で在庫を「奪う/与える」の調整ができます。

ATPロジックのカスタマイズ

ATPロジックは、「利用可能在庫確認グループ（品目マスタ）」と「確認規則（パラメータ・カスタマイズ）」の組み合わせで制御される。

確認規則（Checking Rule）

これによって、「受注の時は『入庫予定の購買依頼』を含めるが、製造の時は『不確実なので含めない』」といった、業務シーンに応じた細かい制御が可能になっている。

確認規則のカスタマイズ（パラメータ設定）

製造オーダーのATPロジックは、主に以下のトランザクションで調整可能である。

引当を確認できる画面

SAP S/4HANAにおいて、在庫の引当状況を確認できる代表的なトランザクションコード（T-CODE）とFioriアプリを以下に整理して列挙する。

1. 在庫と所要量の全体像を確認する

まずこれを見て全体を把握する、という最も標準的な機能。

機能名	T-CODE	Fioriアプリ	特徴・用途
在庫/所要量一覧	MD04	在庫所要量一覧監視	引当だけでなく日ごとの利用可能在庫を確認できる汎用的な画面。 受注(CusOrd)や入出庫予定(Resv)が時系列で並び、最終的な利用可能数量がわかる。
利用可能在庫概要	CO09	–	品目別のATPの計算結果を詳細に確認できる。引当済み数量は「確認済」の列に表示される。
品目充足監視	–	F2101A	引当ではなく、品目別の充足状況を見る画面。 最初の不足日を確認できるので、それまでに手を打てる。

2. 伝票単位の「引当」の状態を確認する

受注や製造指図の「中身」から引当状態を見る機能。
受注／指図単位に、引当されているかを確認したい場合に使用する。

機能名	T-CODE	Fioriアプリ	特徴・用途
受注照会	VA03	–	明細の「納入日程行」タブを確認する。「確認済数量」が入っていれば、その受注による引当が成立している。
入出庫予定照会	MB23	–	入出庫予定伝票そのものを確認する。
製造指図照会	CO03	–	「構成品目」一覧で、「確認済数量」を確認する。数量が登録されていれば引当てられている。
入出庫予定一覧	MB25	–	品目、プラント、原価センタ単位で、入出庫予定をリスト化して確認できる。

3. レポート系：在庫ステータスを確認する

「引当」そのものではなく、「在庫の状態」を確認する。

機能名	T-CODE	Fioriアプリ	特徴・用途
在庫状況照会	MMBE	F1076 在庫 単一品目	SAP GUIでは最も汎用的な在庫照会画面。 「利用可能在庫」「品質検査中」「保留在庫」など様々な在庫を品目別に照会できる。
品目別倉庫在庫照会	MB52	F1595 在庫 複数品目	複数品目の在庫状態をリスト形式で確認できる。

引当の情報を持つテーブル

VA01などで登録された受注伝票の、品目引当数（利用可能確認数）や引当日（利用可能日）が記録されているテーブル。

テーブル名	説明	役割
VBBE	販販売条件: 個別レコード	引当てられている数量は「利用可能確認数量（VMENG）」で、引当日は「品目利用可能日（MBDAT）」で確認できる。
RESB	入出庫予定/従属所要量	入出庫伝票の詳細データ。引当済み数量は「利用可能在庫確認の確認済数量（VMENG）」で確認できる。

ATPと在庫引当に関する疑問と誤解のQ&A

ここからは、ATPと在庫引当によくある疑問・誤解について、Q&A形式で整理していく。

Q1: 引当可能な在庫タイプは？

A: 一般在庫のうち、在庫タイプが「利用可能在庫」の在庫のみ。

品質検査中在庫や保留在庫は引当の対象外。

Q2：引当はMRPによって実行される？

A：MRPは引当を実行しない。引当とMRPは別の機能。

MRPは引当の処理も実行していると思われがちだが、MRPが担うのは在庫過不足の計算と手配である。
引当を行う機能・タイミングは別にある。

この誤解が生まれやすい理由は、T-CODE: MD04（在庫所要量一覧）のせいだろう。

MD04は、MRPの実行結果を確認する画面として広く使われており、PPモジュールを導入した会社では、ほぼ間違いなく利用される。

MD04上では、受注在庫・プロジェクト在庫・一般在庫をそれぞれ確認できる。
その中で、一般在庫に対する引当の様子も確認できるようになっている。

「MRPの実行結果を確認する画面上で」「引当の状態を見る」という体験が、
「引当はMRPの中で実行される」という勘違いを生じさせていると思われる。

Q3：品質検査中在庫もATPに含めたい

A：標準ではATP対象外。

品質検査中在庫は、

• 出庫不可
• 引当不可
• ATP対象外

が基本である。

ATPに含めたい場合、業務上の意味を慎重に検討すべきだ。
「検査中」在庫は、文字通り品質が確保できているか・いないか、検査中の在庫である。
検査の結果、「品質NG」の結果も当然あるわけで、そのような曖昧な在庫をATPや引当を可能とすれば、業務では何が起こるだろう？

約束できないものを約束するのだから、それによって生じる問題をよく考えた方がよい。

Q4：在庫引当すれば、その在庫は他から使われない？

A：引当中在庫であっても他から使われる。引当は在庫のロックではない。

在庫引当はあくまで「在庫の予約」であり、他の受注や出庫によって奪われる可能性は普通にある。

この誤解を解くために、現実世界で例えてみよう。

在庫引当 ＝ 新幹線の「指定席予約」

在庫引当は、「新幹線の指定席予約」に例えることができる。

指定席は、

• 事前に席を予約する（＝在庫を引当する）
• 乗車時はその席に座れる（＝その在庫を使える）

という仕組みである。

しかし、自由席と指摘席は見た目が同じであり、車両の行き来も自由なので、現実には以下のようなことが起こり得る。

• 席を間違えた人が座ってしまう
• マナーの悪い人が「空いていたから」と勝手に座る
• 車掌が来るまで席が占拠される

これは、

👉 指定席を予約していても、席そのものを物理的にロックしているわけではない。

からだ。
これはSAPの在庫引当とまったく同じである。

• 在庫引当＝「在庫を使う予定」という、あくまで計画
• 他の出庫や移動によって、在庫が使われてしまう可能性はある

引当には、拘束力はない。

受注在庫・プロジェクト在庫 ＝ 新幹線の「グリーン車」

では、在庫を他から使われないようにするためにははどうすればよいのか。

それが、受注在庫 と プロジェクト在庫 である。
これは、新幹線で言えば 「グリーン車」 に相当する。

グリーン車は、

• グリーン券（＝受注／プロジェクト）が必要
• そもそもグリーン車両自体への立ち入りが制限されている
• 自由席と指定席の乗客が「空いているから」と座ることはできない

👉 物理的・論理的に、他の人が奪えない構造になっている。

SAPでも同様で、

• 一般在庫：誰でも使える
• 受注在庫／プロジェクト在庫：
  • 特定用途専用
  • 他の需要からは参照・使用できない

というレベルの違う拘束がかかる。

「引当」は在庫を守る手段ではない

新幹線の指定席予約は、座席の予約はできるが、物理的に他の人が座ることを防止できない。

SAPの在庫引当も同じだ。
在庫の予約はできるが、他の人がその在庫の出庫操作を行えば、出庫はできてしまう。

👉 在庫を本気で守りたいなら、最初から「グリーン車」を用意するべきだ。

つまり、受注在庫またはプロジェクト在庫にする

Q5：Fioriを使えば在庫管理は簡単になる？

A：UIが変わるだけで、ロジックは変わらない。

FioriはUIを改善するが、ATPや在庫引当の考え方そのものを理解していなければ混乱は解消されない。

MIGOを使えない人は、Fioriでも詰まる。

まとめ：本気で在庫を確保したいなら

SAPの在庫管理において、ATP・在庫引当は、在庫を確保（予約）するための概念・仕組みである。

しかし、これらはあくまで一般在庫を論理的に“予約”する仕組みにすぎない。

在庫を誰にも取られないよう、本気で在庫を確保したいのであれば、受注在庫やプロジェクト在庫といった、在庫の帰属先で縛るのが最適解である。

つまり、在庫争奪戦を終わらせる鍵は、SAPの機能を駆使することではなく、
「その在庫は誰のものか？」を正しく設計することにある。

ATP、在庫引当、在庫引落し・・・
これらを正しく理解し、在庫を正しく設計できたとき、在庫の奪い合いは終了し、
全体最適された在庫管理を実現できるだろう。