はじめに
SAPのSDモジュール（販売管理）は、受注・出荷・請求という企業の売上サイクルの中心を担う領域です。顧客ごとの価格ルール、業界特有の出荷要件、請求書の特殊フォーマットなど、SD領域は標準機能だけでは吸収しきれない要件が特に集中しやすい場所でもあります。なぜなら、販売業務は顧客との接点であり、顧客ごとの個別要求が直接システム要件として持ち込まれるからです。逆に言えば、ここをアドオンで吸収できないと、現場オペレーションが標準機能から逸脱し、Excel運用や手作業が生まれてしまいます。
そこで使われるのがBAdI（Business Add-In）です。BAdIは標準プログラムのソースコードを変更せずに、決められた拡張ポイントにカスタムロジックを差し込めるオブジェクト指向型の仕組みです。MM BAdI実装ガイドではMM領域の代表BAdIを扱いましたが、本記事ではSD領域に絞り、販売伝票・出荷伝票・請求伝票それぞれで頻出するBAdIと、SD特有の拡張手段であるVOFMルーチンとの使い分け、さらにClean Core時代における考え方までまとめて解説します。対象業務の全体像はSD業務フローを合わせて参照してください。
SD拡張ポイントの全体像
SD領域の拡張は、大きく「BAdI」「VOFMルーチン」「User Exit（MV45AFZZなど）」の3系統に分かれます。まずは業務フローと拡張ポイントの対応関係を押さえます。
flowchart LR A["受注
VA01"] --> B(("BADI_SD_
SALES")) B --> C["出荷
VL01N"] C --> D(("BADI_LE_
SHIPMENT")) D --> E["請求
VF01"] E --> F(("SD_BILLING_
ITEM")) F --> G["会計連携
FI"]
主要な拡張ポイントを表に整理します。
| 業務 | 代表BAdI / 拡張 | 用途 |
|---|---|---|
| 受注（VA01/VA02） | BADI_SD_SALES / BADI_SD_SALES_BASIC | 販売伝票の項目制御・デフォルト値・バリデーション |
| 受注（従来系） | MV45AFZZ（User Exit） | 伝票保存前チェック、項目コピー制御 |
| 価格決定 | VOFM要件・計算式ルーチン | 条件種別ごとの適用条件・計算ロジック |
| 出荷（VL01N） | BADI_LE_SHIPMENT / LE_SHP_DELIVERY_PROC | 出荷伝票の項目制御・ピッキング連携 |
| 出荷モニタ | BADI_SD_DELIVERY_MONITOR | 出荷ワークリストの表示拡張 |
| 請求（VF01） | SD_BILLING_ITEM / SD_CIN_LV60AU02 | 請求明細の項目変更・税計算・会計連携 |
| 与信管理 | BADI_SD_CM_CREDIT_CHECK | カスタム与信チェックロジック |
SDではBAdIとVOFMルーチンの使い分けが最大のポイントです。BAdIは伝票データ全般の制御に、VOFMは価格・出力・データ転送など条件テクニックに紐づく細かいルーチンに使います。混在させると保守が難しくなるため、プロジェクト初期に方針を決めておくことが重要です。
代表BAdI その1：BADI_SD_SALES（販売伝票）
受注処理の拡張で最も使われるBAdIがBADI_SD_SALESです。VA01/VA02/VA03で販売伝票を登録・変更・表示するたびに呼び出され、ヘッダ・明細・スケジュール行の各レベルで処理を差し込めます。なぜ販売伝票に拡張が集中するかというと、受注は顧客との契約条件が確定する最初のポイントであり、ここで入力ミスや条件漏れが発生すると、出荷・請求まで芋づる式に誤りが伝播するからです。逆に言えば、受注時点でバリデーションを効かせておけば、後工程での手戻りを大幅に削減できます。
Enhancement Spot: ES_BADI_SD_SALES 対象Tコード: VA01, VA02, VA03 多重実装: 可（フィルタ値なし）
| メソッド | 処理タイミング | 用途 |
|---|---|---|
| CHECK_HEADER_DATA | ヘッダチェック時 | ヘッダ項目のバリデーション |
| CHECK_ITEM_DATA | 明細チェック時 | 明細項目のバリデーション |
| SAVE_DOCUMENT | 保存直前 | 保存前の最終チェック・カスタム項目セット |
| SAVE_DOCUMENT_PREPARE | 保存準備時 | 保存前のデータ整形 |
活用シーン：
- 受注金額が与信限度額を超える場合にカスタム条件で警告する
- 特定の販売組織で出荷ブロックを自動設定する
- 顧客マスタのカスタム項目と販売伝票の整合性をチェックする
- 明細の納入日が営業日カレンダーに合致しない場合にエラーを出す
注意点として、従来からのUser Exit（MV45AFZZのUSEREXIT_SAVE_DOCUMENT_PREPAREなど）と処理タイミングが重複することがあります。既存プロジェクトでMV45AFZZに処理が集中している場合、新規要件もそちらに追加したくなりがちですが、新規開発はBAdIに寄せ、MV45AFZZは凍結するのが原則です。混在管理を避け、Clean Core観点からもBAdIを優先してください。
代表BAdI その2：BADI_SD_SALES_BASIC（販売伝票の基礎データ制御）
BADI_SD_SALES_BASICは、販売伝票の項目コピー制御やデフォルト値設定に特化したBAdIです。BADI_SD_SALESが「チェック・保存」中心なのに対し、こちらは「入力補助・初期値」を担当します。
対象: 販売伝票の入力補助処理 多重実装: 可
代表的な用途は以下です。
- 顧客マスタの値を販売伝票の特殊項目に自動コピーする
- 品目マスタのカスタム項目を明細にデフォルトセットする
- 過去の受注実績から納入日のデフォルトを計算する
- 特定のオーダタイプで支払条件を強制上書きする
実装時は、他のBAdI（BADI_SD_SALES）との順序を意識する必要があります。初期値設定→バリデーションという順で動くため、BADI_SD_SALES_BASICで設定した値をBADI_SD_SALESでチェックする設計が自然です。順序を逆にすると、チェック時点でまだ値がセットされておらず、意図しないエラーを引き起こします。
代表BAdI その3：BADI_SD_DELIVERY_MONITOR / LE_SHP_DELIVERY_PROC（出荷）
出荷処理の拡張はSD-LE（Logistics Execution）領域で提供され、VL01NやVL02Nなどの出荷伝票処理に関わります。
LE_SHP_DELIVERY_PROC Enhancement Spot: ES_LE_SHP_DELIVERY_PROC 対象Tコード: VL01N, VL02N, VL03N 多重実装: 可
| メソッド | 処理タイミング | 用途 |
|---|---|---|
| HEADER_DATA_UPDATE | ヘッダ更新時 | ヘッダ項目の補完・チェック |
| ITEM_DATA_UPDATE | 明細更新時 | 明細項目の補完・ピッキング数量調整 |
| SAVE_DOCUMENT_PREPARE | 保存前 | 保存前のバリデーション |
| DELIVERY_FINAL_CHECK | 保存直前 | 最終チェック |
活用シーン：
- 出荷数量が受注数量を上回る場合にエラーを出す
- 特定のプラントで出荷時に品質ステータスを必須チェックする
- 顧客ごとの納品書フォーマット切替のためのカスタム項目を設定する
- 納品日が顧客希望日より遅れる場合にフラグを立てる
BADI_SD_DELIVERY_MONITORは出荷モニタ（VL10系）のワークリストを拡張するBAdIで、画面表示のカスタマイズに使います。なぜ必要かというと、出荷担当者は1日に数百件の納品伝票をさばくため、ワークリスト画面に必要な情報が揃っていないと、別画面への遷移が発生して生産性が激減するからです。逆にここを拡張すれば、現場の出荷業務は標準画面だけで完結します。
代表BAdI その4：SD_BILLING_ITEM（請求）
請求伝票の明細レベルでデータを操作するBAdIです。VF01/VF02/VF04などの請求処理で呼び出されます。
対象: 請求伝票明細の処理 対象Tコード: VF01, VF02, VF04
請求は会計連携の入口であり、ここでの誤りはFI（財務会計）側の仕訳誤りに直結します。そのため、請求BAdIには「会計側で弾かれる前にSD側で止める」という防波堤の役割が期待されます。
活用シーン：
- 請求明細に特殊な原価センタを自動セットする
- 特定の明細カテゴリで売上勘定を上書きする
- 顧客グループごとの手数料を追加明細として自動生成する
- インターカンパニー請求で通貨換算レートを独自ロジックで算出する
関連するBAdIとしてSD_CIN_LV60AU02（インド税制向け）やRV_INVOICE_PRINT_ITEM（請求書印刷の項目制御）があります。海外拠点や出力フォーマットに関わる要件はこれらの専用BAdIを使うのが定石です。
また、請求処理の中で特に注意すべきはSD→FI転送時のAC_DOCUMENT系BAdIです。BADI_SD_AC_DOCUMENT_ERPを使えば、SDから生成される会計伝票の勘定コードや原価センタを最後に書き換えられます。ただし、SDとFIの整合性を崩すとあとで修正が非常に困難になるため、利用は慎重に判断してください。
代表BAdI その5：BADI_SD_CM_CREDIT_CHECK（与信チェック）
標準の与信管理だけでは表現しきれない、企業独自の与信判断ロジックを実装するBAdIです。たとえば「過去6ヶ月の入金遅延回数が3回以上なら新規受注をブロック」「子会社間取引では与信枠を無視」といった要件はこのBAdIで実装します。
与信チェックはSD→FI-ARをまたぐ判断であり、BAdIを使わずに外部システムで判断させる設計にすると、リアルタイムでの受注ブロックができず機会損失や過剰与信を招きます。だからこそ、与信ロジックはSAP内部に持たせ、受注登録のその場で判定結果を返す設計が望まれます。
VOFMルーチンとBAdIの使い分け
SD領域特有の話題として、VOFM（Formula and Requirements）ルーチンがあります。VOFMは条件テクニックに紐づく小さなABAPルーチンを管理する仕組みで、以下の用途で使われます。
| VOFMカテゴリ | 用途 |
|---|---|
| 要件（Requirements） | 条件種別の適用要否判定 |
| 計算式（Formulas） | 価格計算・金額算出ロジック |
| データ転送（Data Transfer） | 見積→受注→出荷→請求間の項目コピー制御 |
| 出力要件 | 出力制御の条件判定 |
VOFMルーチンは伝統的な手続き型で、BAdIほど整理された仕組みではありませんが、価格決定や出力制御の細かい分岐はVOFMの方が適しているケースが多いです。伝票全体の制御はBAdI、条件テクニック内部の細かな判定はVOFMという棲み分けを意識してください。
実装手順（SE18 / SE19）
BAdI実装の基本的な流れは次のとおりです。
- SE18でBAdI定義を検索し、対象のEnhancement SpotとBAdI定義名を特定する
- 対象BAdIのインターフェース・メソッド一覧・多重実装可否・フィルタ値の有無を確認する
- SE19で「Classic BAdI」または「New BAdI」を選択し、実装名を入力して作成する
- 実装クラスが自動生成されるので、対象メソッドをダブルクリックして実装する
- 実装をアクティブ化し、実際のトランザクションで動作確認する
ポイントは、SE18で探す際に「CL_EXITHANDLER=>GET_INSTANCE」や「GET BADI」ステートメントを標準プログラム側でも確認しておくことです。BAdIが呼び出されるタイミングと引数の中身を正確に把握しておくと、後のデバッグがスムーズになります。
デバッグ方法
BAdIのデバッグでよく使うアプローチは3つあります。
- 実装クラスのメソッドに直接ブレークポイントを設定する（最も確実）
- SE24で実装クラスを開き、静的ブレークポイントを入れる
- 標準プログラム内のGET BADI / CALL BADI箇所にブレークを打ち、インスタンス生成を追跡する
特にSD領域では、受注登録トランザクション（VA01）は画面遷移が多く、同じBAdIメソッドが1回の操作で複数回呼び出されることがあります。どのタイミングで呼ばれているかを正確に把握するには、コールスタックを確認する癖をつけてください。デバッガの基本操作はABAPデバッグで整理していますので、あわせて参照してください。
また、テーブルSXS_INTERやSXC_EXITを使うと、BAdI実装の有効/無効や実装名を一覧で確認できます。「実装したのに動かない」問題の9割はフィルタ値か有効化フラグが原因なので、まずここを疑うのが近道です。
Clean Core時代のBAdI
S/4HANAとCloud ERPの普及により、SAPは「Clean Core」戦略を推進しています。これは標準コアを改変せず、拡張は決められた出口（Released API・Released BAdI・キーユーザー拡張）からのみ行うという思想です。
S/4HANAにおけるSD拡張の選択肢は以下のようになります。
| 拡張手段 | 対象 | 特徴 |
|---|---|---|
| キーユーザー拡張（Adaptation Transport Organizer） | クラウド/オンプレ両対応 | 画面項目追加・簡易ロジック・ノーコード寄り |
| Released BAdI（SAP Cloud ABAP） | クラウド/オンプレ両対応 | アップグレード保証あり、推奨される出口 |
| Classic BAdI（従来型） | オンプレのみ | 従来通りSE18/SE19で利用可、Cloudでは不可 |
| User Exit（MV45AFZZ等） | オンプレのみ | 非推奨、新規使用は避ける |
RAP（ABAP RESTful Application Programming Model）で構築された新しいFioriアプリでは、従来のBADI_SD_SALESのようなDynproベースのBAdIは呼ばれないケースがあります。Fiori版の受注アプリを使うプロジェクトでは、対応するRelease BAdIが別途提供されていないか必ず確認してください。確認を怠ると、「オンライン受注アプリだけBAdIが効かない」という致命的な漏れを生みます。
よくある疑問（FAQ）
Q1. BADI_SD_SALESとMV45AFZZはどちらを使うべきか？
新規開発はBADI_SD_SALESを使ってください。MV45AFZZはUser Exitで手続き型、複数要件を混在管理するとソースが肥大化します。BAdIなら実装クラスを分けられ、責務を分離できます。既存のMV45AFZZが動いているシステムでも、新規要件はBAdI側に寄せるのが定石です。
Q2. 受注保存時に会計伝票の勘定を変えたい。どのBAdI？
SD→FI転送時はBADI_SD_AC_DOCUMENT_ERPで会計伝票の勘定・原価センタを書き換えられます。ただし、SD側とFI側で整合性が崩れるリスクが高いため、勘定決定（VKOA）のカスタマイジングで対応できないか先に検討してください。
Q3. 与信チェックをカスタムにしたい
BADI_SD_CM_CREDIT_CHECKを使います。S/4HANAではSAP Credit Management（FIN-FSCM-CR）が標準になっており、BAdIの仕様や名称が異なる場合があるため、対象バージョンで必ず確認してください。
Q4. BAdIとVOFMの使い分けの目安は？
伝票単位の項目制御・バリデーション・保存制御はBAdI、条件テクニック（価格・出力・与信）内部の細かい計算・判定ロジックはVOFMです。迷ったら「条件テクニックに紐づくかどうか」で判断してください。
Q5. BAdIが実行されない
フィルタ値、実装の有効化フラグ、そもそも該当BAdIが該当Tコードから呼ばれているかの3点を確認します。標準プログラム内でGET BADIをgrepして呼び出し箇所を特定するのが確実です。MM BAdI実装ガイドにも同様のトラブルシュート手順をまとめているので参考にしてください。
Q6. S/4HANA Cloudでも同じBAdIは使えるか？
使えません。Cloud環境ではClassic BAdIは利用不可で、Released BAdIまたはキーユーザー拡張のみが使えます。Cloud移行を見据えるなら、最初からReleased BAdIだけで設計することを推奨します。
SDのBAdIを書く前にABAPを腰を据えて学びたい人へ
SD領域の拡張はBAdIだけでなくVOFMやMV45AFZZのようなUser Exitも絡むため、ABAPの読み書きが一定レベルでできることが前提になります。クラス・メソッド・FORMルーチン・内部テーブル・MESSAGEのあたりを一度きちんと押さえておくと、既存コードを開いたときの理解度が大きく変わります。
ABAPの基礎を1冊で整理したい場合は、アレグス株式会社・久米正通氏の『SAP ABAPプログラミング入門』が手堅い選択肢です。SDの業務知識と並行してこの本を進めておくと、BAdI実装時に手が止まる回数が目に見えて減ります。
まとめ
- SD領域の拡張はBAdI・VOFMルーチン・User Exit（MV45AFZZ）の3系統で、新規開発はBAdIに寄せるのが原則
- 受注の中心BAdIはBADI_SD_SALES（チェック系）とBADI_SD_SALES_BASIC（初期値系）で役割を分担する
- 出荷はLE_SHP_DELIVERY_PROCで明細・ヘッダの項目制御、BADI_SD_DELIVERY_MONITORで出荷モニタ画面を拡張する
- 請求はSD_BILLING_ITEMで明細制御、BADI_SD_AC_DOCUMENT_ERPでSD→FI転送時の会計伝票を調整する
- 与信管理の独自ロジックはBADI_SD_CM_CREDIT_CHECKで、受注登録のその場で判定結果を返す設計にする
- 価格決定や出力制御など条件テクニック内部の細かい判定はVOFMルーチンを使い、BAdIと役割分担する
- BAdI実装はSE18（定義確認）とSE19（実装作成）で行い、デバッグは実装クラスへの直接ブレークが最短
- Clean Core時代はReleased BAdIとキーユーザー拡張を優先し、Classic BAdIとUser Exitの新規使用を避ける
- Fioriアプリ利用時は従来型BAdIが呼ばれないケースがあるため、Released BAdIの有無を必ず確認する
SD領域のBAdI実装力をさらに磨くなら、ABAPのオブジェクト指向からRAP・OData・UI5 Fioriまでを一貫して学べる実践講座で基盤を固めるのが効果的です。全335レクチャーでClean Core時代の拡張開発に必要なスキルを体系的に習得できます。