SAP SD：その役割と、導入がつまずく場所

SAP SD（Sales and Distribution、販売管理）は、SAPにおける受注から入金までを担います。見積、受注、出荷、請求、そして財務への引き渡しです。S/4HANAでは、プロジェクトのスコープに影響する形で変わります。顧客はビジネスパートナーになり、与信管理はSAP Credit Managementへ移り、リベートは条件契約へ移り、請求はユニバーサルジャーナルへ直接転記されます。このガイドは、SDが何をするのか、どこでつまずくのかを知る必要がある、営業オペレーションのリード、財務コントローラー、プロジェクトマネージャーに向けたものです。後者の短い答えは、顧客マスタデータ、価格条件、利用可能性チェック、勘定決定です。この4つは、本稼働の前に実際のデータでテストしてください。

SAPの導入が一通り終わったあるロールアウトで、受注から入金までのステップは、設計どおりに構築されていました。プロセスマップ上では問題なく見えました。しかし、生産から在庫の更新がどのように入ってくるのかを、誰も確認していませんでした。

営業は顧客に5日と伝えていました。製造は、10日に近いと分かっていました。

その差が失わせたのは、遅れた納品だけではありません。信頼です。そして信頼は、設定値よりも立て直すのが難しいのです。

SDは、ロジスティクスのチェーンの最前線にあります。ドキュメントの連鎖を通じて、顧客の関心を請求書に変えます。

1. 引合：顧客が価格や納品可否を問い合わせる
2. 見積：有効期間付きの、価格と納期の正式なオファー
3. 受注：顧客がコミットし、利用可能性チェックが走り、納期が確定する
4. 出荷：倉庫がピッキングと梱包を行い、出庫で在庫が減る
5. 請求：請求書が、会計伝票とともに作成される
6. 入金：財務が、入金を未消込明細に対して消し込む

各ドキュメントは、その前のドキュメントを参照します。このドキュメントフローが、受注から入金までを追跡可能にします。連鎖がきれいなら、すべての請求書を、最初の依頼までさかのぼれます。ドキュメントが順序を飛ばして作られたり、迂回されたりすると、レポートが壊れ、紛争が続きます。

1. 01引合価格や納品可否の問い合わせ
2. 02見積有効期限付きの正式なオファー
3. 03受注利用可能性チェックで納期を確定
4. 04出荷ピッキング、梱包、出庫
5. 05請求請求書と会計伝票
6. 06入金財務が未消込明細を消し込む

すべての請求書を、最初の依頼までさかのぼって追跡できる

うまく機能すれば、この連鎖は手作業の引き継ぎをなくします。ある製造業のクライアントは、SDの稼働後に受注から入金までのサイクルを40%短縮しました。主な要因は、営業、倉庫、財務の間の引き継ぎをなくしたことです。

受注と利用可能性チェック

受注処理は、SDのコンフィグレーション作業の大半が集中する場所です。オーダータイプ、明細カテゴリ、納入日程行、そして利用可能性チェックです。

Available-to-Promise（ATP）は、最もビジネスクリティカルな部分です。要求された日付を、在庫、入庫予定、既存のコミットメントから満たせるかをチェックします。正しく設定されていれば、営業は、システムが実際にコミットできることを顧客に伝えます。誤って設定されていれば、営業は、届けられたらいいと願うことを顧客に伝えます。

冒頭のロールアウトでは、生産から在庫の更新がどのように入ってくるのかを、誰も確認していませんでした。営業は、工場が守れない納期を提示していました。

価格と条件

価格設定は、SDの設定の中で最も過小評価されています。最初の請求書の紛争が起きるまでは、単純に見えます。

SDの条件テクニックは、基本価格、顧客別の割引、数量割引、割増、運賃、税を扱います。各要素は、アクセスシーケンスを持つ条件タイプで、条件レコードが値を保持します。

私が最もよく見る価格設定の問題は、本稼働時の古い価格条件が、更新されないままになっていることです。ビジネスが割引を再交渉しても、誰もSDの条件レコードを更新せず、請求書は誤り、紛争は売掛金管理に降りかかります。

価格のガバナンスは、プロセス上の判断であり、コンフィグレーション上の判断ではありません。誰かが、条件レコードの保守を担う必要があります。

出荷

デリバリ処理は、ピッキング、梱包、出庫を扱います。出庫は決定的なイベントです。在庫の減少を転記し、デリバリを請求予定リストに載せ、実際の納品日を記録します。出荷ポイントとルートの決定が、デリバリの作成方法を制御します。複雑な流通ネットワークを持つ企業は、これをSAP Transportation Management（TM）で拡張します。

請求、勘定決定、税

請求は、デリバリを請求書に変え、会計伝票を作成します。勘定決定は、販売組織、顧客と品目の勘定設定グループ、条件タイプに基づいて、各請求明細を、収益、税、その他のG/L勘定に対応づけます。これが誤っていると、請求書は誤った勘定に転記され、財務は月末にそれを知ることになります。

税の決定も、同じくらい壊れやすいものです。顧客の税分類、品目の税分類、納品先の国や管轄に依存します。不一致があると、課税対象の販売にゼロ税の請求書が出たり、免税の販売に税がかかったりします。

与信管理

与信チェックは、顧客を与信限度額の超過に導く受注を、ブロックしたりフラグを立てたりします。限度額が保守されている場合にのみ機能します。本稼働時に設定した固定の限度額は、支払い行動と取引量が変わるにつれて、意味を失います。

限度額が顧客の通常の注文規模を下回ると、すべての注文が自動的にブロックされます。すると営業チームは、限度額の見直しを依頼するのではなく、ブロックを解除する術を覚えます。

それは与信管理ではありません。回避策です。

SDの組織構造の要素と、それぞれが何に結びつくかを示します。

構造要素	SAP SDでの目的	主な関連
販売組織	最上位の販売単位。販売条件と責任を担う	FIの会社コードに割り当てる
流通チャネル	製品が顧客に届く経路（卸売、小売、直販）	価格設定、マスタデータ、パートナー決定を制御する
製品部門	販売組織内の製品グループ	レポートと出力のための品目グルーピング
販売エリア	販売組織、流通チャネル、製品部門の組み合わせ	すべての販売伝票と顧客レコードに必須
営業所	地理的な販売単位	地域別のレポートとパートナー決定
営業グループ	営業所内のチーム	受注の担当者
出荷ポイント	商品の出荷元となる場所	SDを倉庫管理と輸送に結びつける
プラント	製造または供給を行う単位	在庫の供給元。出荷ポイントに結びつく

販売エリアが実際の運用単位です。顧客の販売データは販売エリアごとに保守され、すべての販売伝票は、いずれかの販売エリアで作成されます。多くの移行がここでつまずきます。販売エリアにきれいに対応づけられないレガシーの顧客レコードは、ロードの前に本格的な準備が必要です。

ECCから移行する場合、スコープに織り込むべきSDの変更点は次のとおりです。SAPはS/4HANAのドキュメントで、この領域を「Sales」に分類していますが、ほとんどのチームは今もSDと呼んでいます。

ECCS/4HANA

顧客ECC顧客マスタレコードS/4HANA顧客ロールを持つビジネスパートナー

与信管理ECCFI-AR-CRS/4HANASAP Credit Management（FIN-FSCM-CR）、必須

リベートECCSDのリベート処理（インデックスから再構築）S/4HANASettlement Managementの条件契約

利用可能性チェックECC基本的な製品の利用可能性チェックS/4HANA高度なATP：割当、バックオーダー、代替プラント

請求ECCFIとCOを別々に照合S/4HANAユニバーサルジャーナル（ACDOCA）の一つの明細

収益認識ECC多くのプログラムで独自の繰延ロジックS/4HANASAP Revenue Accounting and Reporting（別途ライセンス）

1. 顧客はビジネスパートナーになります。 顧客マスタデータは、顧客ロールを持つビジネスパートナーを通じて保守します。コンバージョンでは、コンバージョンの実行前に、顧客・仕入先の統合を設定しておく必要があります。
2. 与信管理はSAP Credit Managementへ移ります。 ECCの与信管理（FI-AR-CR）は、S/4HANAでは利用できません。SAP Credit Management（FIN-FSCM-CR）がその後継であり、コンバージョンでは与信データと設定を移行する必要があります。任意ではありません。
3. リベートは条件契約へ移ります。 従来のSDのリベート処理は、Settlement Management（条件契約管理）に置き換えられます。リベート条件は、インデックスから再構築されるのではなく、即座に適用されます。
4. 高度なATP。 S/4HANAの高度なATPは、製品割当、バックオーダー処理、プラントをまたぐ代替ベースの確定、出荷向けリリース、供給割当を追加します。S/4HANA Cloudでは、これらの機能は標準のライセンスに含まれます。オンプレミスでは、有効化した時点で専用のライセンスが必要です。
5. 請求はユニバーサルジャーナルへ転記されます。 FI、CO、収益性分析は、ACDOCAの一つの明細を共有します。これにより、ECCにあったFIとCOの照合作業がなくなります。その代償として、勘定決定のエラーは、誤った勘定への即時の転記になり、明細レベルで見えます。
6. 収益認識。 複数要素の契約、サブスクリプション、IFRS 15に基づく長期サービスでは、SAP Revenue Accounting and Reportingが、多くのECCプログラムが構築した独自の繰延ロジックに代わります。別ライセンスで、本稼働の前に設計する必要があります。年度末に発見するものではありません。

クリーンコアは、SDのカスタマイズの扱い方を変えます。パブリッククラウドでは、コアにカスタムコードを入れることはできません。プライベートクラウドとオンプレミスでは可能ですが、アップグレードのたびに作業が難しくなります。古い価格設定のZルーチンの大半は、標準の条件タイプ、フォーミュラ、BAdIで置き換えられます。本当に残るものは、SAP BTP上のサイドバイサイド拡張に属します。私のクリーンコアのガイドで、その判断を扱っています。

SDとMM

利用可能性チェックはMMから在庫を読み取り、出庫は在庫の動きを転記します。在庫データが誤っていれば、ATPの結果は信頼できません。在庫が実際には出荷ポイントにないために出庫が失敗すると、デリバリは完了せず、請求が止まります。両者を揃えておくには、マスタデータと規律が必要です。標準の転記を迂回する、手作業の在庫調整はしないことです。

SDとPP

受注生産のシナリオでは、受注が直接生産を動かせるため、確定した納期は、製造指図に裏づけられたコミットメントになります。品目マスタのストラテジグループが、受注と需要予測がどう相互作用するかを制御します。誤って設定すると、両者は相殺されずに加算され、計画実行は需要を過大に見積もり、過剰生産につながります。計画面については、私のSAP PPのガイドで扱っています。

SDとFI

請求伝票がインターフェースです。請求書ごとに、収益、税、顧客の未消込明細をユニバーサルジャーナルに転記する会計伝票が作成されます。顧客マスタの支払条件が、支払期日を決めます。営業が財務に伝えずに条件を交渉すると、システムは、財務が合意したことのない条件を強制します。

SDの設計がすべての収益を請求時に認識されるものとして扱い、契約が別の定めをしている場合、後からの手直しは高くつきます。設計の承認前に、収益認識を財務と合意してください。連携の財務側については、私のSAP FICOのガイドをご覧ください。

本稼働後の痛みの大半は、4つの失敗ポイントから生じます。

顧客マスタの準備不足。 すべてのフィールドが、下流で意味を持ちます。税分類がなければ、税が誤ります。支払条件がなければ、FIは支払期日を計算できません。出荷条件がなければ、デリバリのスケジューリングが壊れます。件数は計画の想定より多く、移行元のデータは想定より悪く、クレンジングには業務上の判断が必要です。早く始め、技術的なロードではなく、業務のワークストリームとして扱ってください。方法は、SAPデータ移行が失敗する理由の記事で扱っています。

価格条件が保守されない。 誰もレビューしない本稼働時の条件は、最初の1年のうちに、請求書の紛争になります。

現実から切り離された利用可能性チェック。 古いデータを読むATPは、ビジネスが守れない約束を生み出します。単体テストで使うきれいなテストデータではなく、実際の生産と在庫のシナリオで検証してください。

本稼働後に見つかる勘定決定の抜け。 実際の勘定科目表、税コード、品目グループでテストしてください。税コードが合っていないと、何が間違っているのか誰かが気づく前に、受注がブロックされたり、請求書の紛争が起きたりします。

次の表は、UATの承認前に私が確認するチェックリストです。

リスク	影響	対策
不完全な顧客マスタ	請求書のエラー、出荷の失敗、FI転記の抜け	データのワークストリームを早く始める。移行前に、販売エリアごとの必須フィールドを定義する
古くなった価格条件	請求書の紛争、誤った収益	本稼働時に、条件レコードの担当者とレビューサイクルを決める
PPまたはMMから切り離されたATP	当てにならない納期の約束	UATの承認前に、実際の計画シナリオでATPをテストする
勘定決定の抜け	収益が誤った勘定に転記される	実際の勘定科目表と、税コードの全セットでテストする
与信ブロックの解除が日常化する	統制されないエクスポージャー、売掛金の紛争	限度額のレビューを徹底する。最初の90日間は、手動の解除を追跡する
出力がテストされていない	請求書や納品書が自動送信されない	本稼働前に、すべての出力タイプを、実際の印刷とメールのルーティングでテストする
支払条件の不整合	誤った支払期日、キャッシュフロー予測のずれ	顧客データをロードする前に、営業と財務で条件を合意する

営業チームが、見直しを依頼せずに与信ブロックを日常的に解除しているなら、習慣が定着する前の最初の90日以内に是正してください。

SAP SDとは何で、何をするものですか？

SAP SD（Sales and Distribution）は、受注から入金までを管理します。引合、見積、受注、出荷、請求、そして財務会計への引き渡しです。ドキュメントフローが各ステップをその前のステップに結びつけるため、すべての請求書を最初の受注までさかのぼれます。在庫と出庫についてはMM、受注生産と利用可能性についてはPP、収益、税、売掛金についてはFIと連携します。

SAP SDの組織構造とは何ですか？

運用単位は販売エリアで、販売組織、流通チャネル、製品部門の組み合わせです。すべての販売伝票は販売エリアで作成され、顧客の販売データは販売エリアごとに保守されます。その下に、レポートと責任のための営業所と営業グループがあります。ロジスティクス側では、出荷ポイントとプラントが、商品の出荷元を決めます。構造は、顧客データをロードする前に正しく決めてください。後から変更すると、データのロードをやり直すことになるからです。

SAP SDでは、価格設定はどのように機能しますか？

価格設定は、条件テクニックを使います。各価格要素は条件タイプで、アクセスシーケンスがどの条件レコードを適用するかを決め、価格設定プロシージャが条件タイプを順序どおりに組み合わせます。価格設定の紛争の大半は、コンフィグレーションの誤りではなく、商取引条件が変わったときに条件レコードが更新されなかったことに行き着きます。

SAP S/4HANAの高度なATPとは何ですか？

高度なAvailable-to-Promise（aATP）は、S/4HANAの利用可能性チェックです。基本的な製品の利用可能性チェックに加えて、製品割当、バックオーダー処理、プラントをまたぐ代替ベースの確定、出荷向けリリース、供給割当を備えます。これらの機能はS/4HANA Cloudに含まれ、オンプレミスでは有効化した時点で専用のライセンスが必要です。供給が制約されている場合や、割当ルールが重要な場合に使ってください。安定したサプライチェーンなら、きちんと設定した基本チェックで十分なことも多くあります。

SAP SDは、財務会計とどのように連携しますか？

請求伝票を通じてです。請求伝票を会計に転送すると、収益、税、顧客の未消込明細の仕訳が作成されます。勘定決定が、販売組織、勘定設定グループ、条件タイプから、G/L勘定を決めます。税は、顧客と品目の税分類に依存します。顧客マスタの支払条件が、支払期日を設定します。IFRS 15のケースでは、SAP Revenue Accounting and Reportingが、収益を時間をかけて繰り延べ、認識します。

ECCからS/4HANAに移行すると、SAP SDでは何が変わりますか？

顧客はビジネスパートナーになります。与信管理はFI-AR-CRからSAP Credit Managementへ移り、これは必須です。リベート処理は、Settlement Managementの条件契約に置き換えられます。高度なATPが利用可能になり、請求はユニバーサルジャーナルへ転記されます。これらはすべて、早い段階でスコープに織り込んでください。それぞれにコンフィグレーション、データ移行、テストが必要だからです。

SAP SD導入で最もよくある失敗は何ですか？

繰り返し出てくるものが5つあります。顧客マスタデータを過小評価すること。本稼働後に、価格条件を担当者のいないまま放置すること。ATPを、きれいなデータだけでテストすること。勘定決定を、簡略化したデータでテストすること。出力を最初から最後まで通してテストしないこと。最後の1つは見落としやすいものです。請求書が自動で出ていかないと、誰かが手で印刷し始め、その回避策が恒久化します。