この記事を読むメリット
- SAPのバックオーダーに関する基本的な仕組みとその操作イメージについて理解することができます。
SAPの販売管理モジュールでは、通常受注時に在庫の引当が可能かのチェックを行います。この際、受注の引き当ては受注順に引き当たっていくことになります。この時、在庫数量が受注入力時に不足している場合は、次回の入庫予定などをベースに納入日付が提案されます。
上記のような状態で、顧客から受注をしたものの現在庫では引き当てができず、将来の入庫を待っている状態の受注をバックオーダー(未納入受注)と呼びます。これに対して、SAPではバックオーダー処理を行うことで、それぞれの受注の優先度を加味して納期の前倒しや重要顧客向けに在庫を振り替える、といった処理を行うことができます。
本記事では、SAPでのバックオーダーの仕組みとバックオーダーへの再引当ロジックがどのように働くのかを実機画面を通じて解説していきます。
受注伝票で引き当てていた品目が、在庫不足でお客さんから要望された納期よりも1週間以上遠い日付が提案されちゃった…
1か月後納期の受注が先に登録されていて在庫が足りないよ
SAPでは、納期や出荷条件などを加味して在庫引当を調整する機能があるのじゃ!この機能を使うことで、在庫の適切な引当や納期回答につなげることができるのじゃ!
今回は、バックオーダー処理の仕組みついて解説していくぞい!
この記事のポイント
SAPでのバックオーダー処理概要
SAPでは、受注登録時点で対象品目の在庫が引当可能かが即座にチェックされます。この時、SAPは現在ある在庫の数量だけではなく、将来的に入庫予定の在庫も加味して引当処理を行います。
ただし、以下の例のような場合では、SAPでは原則として先に登録された受注伝票順に在庫が引き当たっていくため、必ずしも在庫引当はその都度適正化されるわけではありません。
この状況下では、受注003は納入希望日付が003よりも後でもよいとされている受注002に在庫引当てされてしまっています。このままでは、顧客の希望する納期よりも後になってしまい、受注キャンセルといった販売機会の喪失という事態につながってしまいます。
ここで、バックオーダー処理を手動またはJOBによる自動実行を行うことで、在庫引当がされてしまった受注の納入日付の更新を出荷優先度や条件などを加味したうえで、リバランスすることができます。
こうすることで、先ほど懸念された003の受注キャンセルといった事態を防ぐことができるのです。
では、実際に品目の引き当て状況を確認しながらバックオーダー処理を実施するとどのような画面・処理結果となるのかについて、実際の画面を通じて確認していきましょう。
実機画面を通じたバックオーダー処理イメージ
今回は、先ほどの例で紹介した形と同じ設定で処理イメージを確認していきます。
事前に在庫15PCある状態からスタートし、在庫がどの受注にも割り当たっていないことを確認してから開始します。
前提: 受注登録(T-CODE:VA01/02)
まず前提となる受注伝票をいくつか登録します。
受注1は納入日付が6/29で10PC既存の在庫に引当を行います。
なお、引き当たった状況は在庫所要量一覧の画面より確認できます。(T-CODE:MD04)
ここでは、品目「Z_BO_TEST」が受注7624に対して、在庫10PC引き当たっていることが確認できます。
続いて、上記の要領で、5PCの受注を2つ、登録します。
すると、以下のように在庫に対して受注が10PC引き当てようとして、数量がマイナスになってしまっています。この7641のようなの状態をバックオーダー(受注残)と呼びます。
この状態では、受注のキャンセルにつながらないよう、顧客に対して次回納入予定日付などを提示し、追加在庫の入荷タイミングに基づいて納期回答を行う必要があります。
バックオーダーが発生している受注は、ATP(Available-to-Promise)上は未確認数量として扱われるため、通常は次回入庫予定(例:7/10 の入庫 10PC)を基準に再引当を実施し、納入可能日を再計算します。 この際、バックオーダー処理(V_RA)や納期再調整(V_V2)を用いて、どの受注にどのタイミングで在庫を割り当てるかを調整することができます。
パターン1: 手動でのバックオーダー処理①(T-CODE: VA02)
手動で再引当を行う場合は、VA02の画面から個別に明細利用可能在庫確認をすることで、引当済数量を変更することができます。
すると下記のような画面で確認済数量に引当を行いたい数量を入力することで再引当を行うことが可能です。※今回は、V_V2やV_RAを先に実行していたため、10PC引き当てを戻します。
パターン1: 手動でのバックオーダー処理②(T-CODE: V_RA)
続いては、一覧から伝票間での在庫引当の付け替えを行える機能を利用して再引当処理をしていきます。
上記で再引当が可能な対象な伝票が一覧に表示されるので、変更したい対象の伝票を選択して再引当を実施していきます。
結果として、受注7643に引当られた5PCが引き当たっていることを確認できます。
※V_V2で受注7643→7644と7645に5PCずつ再引当したものを5PC再引当しています。
パターン2: 自動でのバックオーダー処理(T-CODE:V_V2)
最後にV_V2での自動でのバックオーダー処理について実機画面を確認していきます。
続いて画面下部についてそれぞれ入力項目を確認します。
V_V2はJOB化して実行することも多いため、ここでの受注再引当の条件設定が大事になります。
V_V2実行画面
ソート順序
再引当処理においては、このソート順序の各項目の優先度を利用して再引当処理を行います。
1: 伝票カテゴリ
伝票種別(受注伝票なのか、在庫転送オーダーを優先させるのか)をラジオボタンにて選択します。
2: 出荷優先順位
BPマスタ(得意先)に設定されている出荷優先順位をベースに対象の受注を出荷優先順に再引当します。
3: 日付
伝票日付なのか、納入日付順で近い日付のものに再引当します。
4: 伝票番号
通常は伝票番号の若い番号で昇順で再引当します。
5: 明細番号
4同様に、明細番号の若い番号で昇順で再引当します。
その他、Optionではテスト実行(Simulation)とするのか等を選択することができます。
では、まずそのままの設定で実行してみます。
受注伝票7643のほうが古い受注なので、変化なしとなるのを確認します。
再日程計画実行後(変化なしver)
実際の引当結果の画面を見てみましょう。当初引き当てられていた在庫10PCは7643に引当られた状態のまま変化なしとなっています。
では、次に最早納入日付順をソート順序として選択し、受注7644と7645の納入日付を7643よりも1日早めた形で再実行してみます。
再日程計画実行後
すると、今回は7643の引当済在庫が解除され、7644/7645に分散して割り当てが行われました。
これらを日々JOBとして1日の受注を一括で確認して再実行することがV_V2の機能となります。
さいごに
本記事では、ECC時代からのclassicなATP処理機能を紹介してきました。HANAに移行してからもFioriでの設定が必要なaATP(拡張ATP)よりも実務上はまだまだ再日程計画での業務プロセスを実施している企業も多いのではないでしょうか?実機画面を通じてSAPの再日程計画処理がどのように動いているのか少しでも皆様のお力になれれば幸いです。