はじめに
SAPのPP（生産計画）モジュールは、計画から製造指図、実績確認、完成入庫までの「ものづくりの流れ」を司る領域です。製造業の現場には業界ごと・工場ごとに固有のルールがあり、ライン構成や材料引当のロジックは標準機能だけでは表現しきれないことがしばしばあります。なぜなら、製造業の競争力はオペレーションの細部に宿り、その細部こそが企業ごとに異なるからです。
ではどうすべきか（so what）。標準機能でカバーできる骨格は崩さず、現場固有の判断ロジックだけをBAdIで差し込むのが正攻法です。本記事ではPP領域の代表BAdIを業務別に整理します。基本操作はMM BAdI実装ガイドを、業務全体像はPP業務フローを参照してください。他モジュールについてはSD・FI・COBAdI実装ガイドがあります。
業務領域別の代表BAdI
製造指図（CO01/CO02）
| BAdI名 | 拡張ポイント | 典型的な用途 |
|---|---|---|
| WORKORDER_UPDATE | 指図登録・変更時 | 指図番号体系のチェック、独自項目の整合性検証 |
| WORKORDER_GOODSMVT | 指図関連の在庫転記 | 自動転記時の保管場所決定 |
| BADI_ALM_OL_AUTH | 指図権限チェック | プラント×指図種類の細粒度権限 |
WORKORDER_UPDATEは特に頻出で、指図ヘッダ・コンポーネント・操作のいずれの変更時にも呼ばれます。なぜここに独自ロジックを入れるか：製造業ごとに「これがないと指図を動かしてはいけない」という事前条件が独自に存在するからです。
MRP（資材所要量計画）
| BAdI名 | 拡張ポイント | 典型的な用途 |
|---|---|---|
| MD_PLDORD_CHANGE | 計画指図変更時 | 計画指図の優先度・納期再計算 |
| MD_ADD_ELEMENTS | MRP要素の追加 | MRP結果に独自の仮想在庫要素を追加 |
| MD_PURREQ_CHANGE | 計画購買依頼の変更 | 自動採番の購買依頼に独自属性付与 |
MRPは計画ロジックの中核であり、ここをむやみに改造するとリスケジュール時の挙動が予測不能になります。MRPのBAdI実装は「副作用を生まない」「計算結果に依存しない」が必須条件です。
実績確認（CO11N）
| BAdI名 | 拡張ポイント | 典型的な用途 |
|---|---|---|
| CONFPP_POSTING_DATA | 確認データ転記 | 工数・歩留まり実績の補正 |
| WORKORDER_CONFIRM_UPDATE | 確認反映 | MES連携で受け取った実績の書き込み |
確認BAdIはMES（製造実行システム）連携の接点として最重要です。MES側で計測した実績をSAPに書き戻す際、単位変換・損失計上・歩留まり計算を経由するために使われます。
バックフラッシュ・在庫転記
WORKORDER_GOODSMVTは、製造完了時に消費・入庫を一括転記するバックフラッシュ処理にも介入できます。保管場所の動的決定や、品質検査ロットの自動生成などに使われます。
BAdI実装の流れ
flowchart LR A[要件分析] --> B[標準カスタマイズ
BOM/作業手順] B -->|不可| C[BAdI探索
SE18] C --> D[実装
SE19] D --> E[単体テスト] E --> F[ライン統合テスト] F --> G[移送] B -->|可| Z[完了]
PPでは「単体テストがほぼ無意味」と言われるほど、ラインを通した統合テストが重要です。why so：BOM・作業手順・在庫・MRP・確認のすべてが連鎖するため、単一テーブルだけ見ても挙動が確認できないからです。so what：必ずテスト工場（テストプラント）を用意し、計画から完成入庫までを一気通貫で流す検証が必須になります。
Clean Core時代のPP拡張
S/4HANAでは生産系オブジェクトにもAPIが整備されつつあり、Side-by-Sideでの拡張が現実的になっています。新規開発の優先順位は次のとおりです。
- Key User Extensibilityでカスタムフィールドと拡張CDS
- ABAP Cloud対応BAdIで実装（旧来のBAdIから移行が必要なケースあり）
- 大規模なロジックはBTPのCAPアプリでSide-by-Sideに切り出し、Event MeshやIntegration Suiteで連携
なぜPPでもClean Coreが重要か。製造業はライン稼働に直結するため、アップグレード時のリグレッションが現場停止に直結するからです。コア改造を避け、外側に切り出しておくことで、SAPのアップグレードと工場の稼働を独立に管理できます。
ユースケース3例
ユースケース1：受注連動での指図番号体系
受注番号の一部を製造指図番号に組み込みたい要件は、WORKORDER_UPDATEで指図登録時にチェック・補完を行います。標準のNumber Rangeでは表現できない命名規則を実装できます。
ユースケース2：MES実績の歩留まり補正
MES側で測定された歩留まりが、SAP側の標準歩留まりとずれる場合、CONFPP_POSTING_DATAで補正ロジックを適用します。月次で集計される製造原価の精度に直結します。
ユースケース3：MRP結果への外部需要追加
販売予測システムから取り込んだ需要を、MRP結果に仮想要素として追加するケースではMD_ADD_ELEMENTSを使います。標準のPIR（販売実績計画）では表現しきれないユースケースで重宝されます。
よくある疑問（FAQ）
Q. WORKORDER_UPDATEの中でDB更新してもよいですか？ A. 同一トランザクション内のDB更新は避け、必要なら独自項目はWORKORDER_UPDATEで設定するだけにとどめます。別テーブルへの書き込みはCOMMIT後の処理に分離します。
Q. MRPのBAdIで外部システムを呼び出すのは現実的ですか？ A. 性能が厳しいため非推奨です。MRPは数万件の処理を回すため、BAdI内の同期RFC呼び出しは破綻のもとです。必要なら事前にデータをキャッシュテーブルに用意します。
Q. 確認BAdIで歩留まり計算を変えると、原価計算とずれませんか？ A. ずれます。確認BAdIで補正する場合は、必ずCO側の評価ロジックと整合を取った設計にします。
Q. PPでもSubstitutionに相当する機構はありますか？ A. PPには標準のSubstitution機構はありません。代わりにBOM・作業手順のカスタマイズと、BAdIの組み合わせで対応します。
Q. テスト用のテストプラントは必須ですか？ A. 強く推奨されます。BAdI改修のたびに本番プラントで試すのは現実的ではなく、影響範囲も読みづらいためです。
ABAPの基本動作を一度整理しておきたい人へ
PPのBAdIは製造指図・MRP・確認といったトランザクション量が多いオブジェクトを扱うため、ABAPの内部テーブル操作・SELECTの書き方・例外処理の作法がそのまま品質に効いてきます。BAdIの記事や事例を読み漁る前に、ABAP本体の語彙を一度押さえておくと理解の早さが変わります。
特にPPのBAdIは製造指図・BOM・作業手順を横断する処理が多く、内部テーブルのループやBAPI呼び出しを書く頻度が高めです。だからこそ、文法とABAPディクショナリの基本がひと通り頭に入っているかどうかで、着手時の迷いの量がまったく変わってきます。
体系的に1冊やるなら、アレグス株式会社・久米正通氏の『SAP ABAPプログラミング入門』は最初の1〜2ヶ月で何度も開き直すことになる種類の本です。PPの業務知識と並行して読んでおくと、この記事で紹介したBAdIに着手するときの心理的ハードルがぐっと下がります。
まとめ
- PPの拡張はBOM・作業手順などの標準カスタマイズを優先し、BAdIは現場固有判断ロジックに限定する
- 製造指図はWORKORDER_UPDATE、MRPはMD_PLDORD_CHANGE、確認はCONFPP_POSTING_DATAが代表的
- MRPのBAdIは副作用ゼロが必須、外部呼び出しは性能面でNG
- 確認BAdIはMES連携の接点であり、補正ロジックはCO側との整合が必要
- テストはライン全体での統合検証が必須、テストプラントの用意が運用品質を決める
- S/4HANAではABAP Cloud対応BAdIへの移行とSide-by-Side化が新規開発の前提
PPのBAdIは「現場の独自ルールを標準業務フローに自然に溶け込ませる」ための道具です。書きすぎず、テストを尽くし、現場の声に応えながらも保守可能性を守るバランス感覚こそが、PP拡張開発の要です。
PP領域のBAdI実装に必要なABAPスキルを底上げするなら、ABAPの基礎からRAP・OData・UI5 Fioriまでカバーした実践講座で体系的に学ぶのが近道です。全335レクチャーでClean Core時代の拡張開発スキルを一気に習得できます。