SAP FI BAdI実装ガイド｜会計伝票・支払・税計算の代表BAdIと拡張ポイント

はじめに

SAPのFI（財務会計）モジュールは、企業のすべての金額が最終的に集まる「数字の出口」です。会計伝票の起票から、支払処理、税計算、月次決算まで、ほんのわずかなロジックの誤りが決算修正や監査指摘につながる、もっともシビアな領域でもあります。だからこそFIには、各国・各業界・各監査要件に合わせた個別ロジックを差し込む必要が常に発生します。

なぜFIでアドオンが避けられないのか（why so）。会計基準は国ごとに異なり、税法は毎年変わり、グループ内の連結ルールは企業ごとに違うからです。標準コードを書き換えればアップグレードのたびに再修正が必要になり、保守コストが跳ね上がります。

ではどうすべきか（so what）。標準コードに触らず、決められた拡張点だけにカスタムロジックを差し込むBAdIを正しく使うことが答えです。本記事ではFI領域で頻出するBAdIと使いどころを、業務観点から整理します。BAdIの基本やSE18/SE19の操作はMM BAdI実装ガイドで詳しく解説しているので、初学者はそちらを先に読むことをおすすめします。SD領域についてはSD BAdI実装ガイドを参照してください。FI業務全体の流れはFI業務フローで確認できます。

FIにおけるBAdIの位置づけ

FIには伝統的にBTE（Business Transaction Events、SWF5）という拡張機構もあり、BAdIとBTEのどちらを使うかを判断する場面が頻繁にあります。歴史的にはBTEが先にあり、BAdIが後発として整備されました。

なぜ機構が複数残っているのか（why so）。FIは歴史が長く、各時代の拡張機構が互換性のために残されているためです。so what：FIで拡張要件を受けたら、まずSubstitution/Validationで実現できないかを最初に検討するのが鉄則です。コーディング不要なら保守コストはほぼゼロで済みます。それでも要件を満たせない場合に初めてBAdIやBTEに進みます。

業務領域別の代表BAdI

FIの業務領域ごとに、よく使われるBAdIを整理します。

会計伝票登録

AC_DOCUMENTは特に強力で、SD/MMから連動して生成される会計伝票にも介入できます。たとえばSD請求伝票から起票される売上仕訳に、特別な利益センタや顧客グループ分類を自動付与する、といった用途で使われます。

支払処理（F110自動支払）

支払処理は1日あたり数千件を扱うバッチ処理になるため、BAdI内で重い外部呼び出しを行うと処理時間が爆発します。なぜ気をつけるべきか：F110はバッチウィンドウが厳しい業務で、性能劣化がそのまま夜間運用の破綻につながるからです。F110系BAdIには「軽量・冪等・例外を握りつぶさない」の3原則を必ず守る必要があります。

税計算

各国の電子インボイス義務化やVAT改正のたびに、税コード判定ロジックは見直しを迫られます。BAdIで切り出しておくと、改正時の影響範囲をBAdI実装内に閉じ込められます。

BAdI実装の流れ（FI特有の注意点）

実装手順自体は他モジュールと共通ですが、FI特有の注意点があります。

flowchart LR
  A[要件分析] --> B[Substitution/
Validation検討]
  B -->|不可| C[BAdI/BTE探索
SE18]
  B -->|可能| Z[完了]
  C --> D[実装作成
SE19]
  D --> E[テスト
STVARV含む]
  E --> F[移送]

FIでは「テストデータの作り方」が他モジュールより難しく、月締め前後・期末・税率改定タイミングなど、ボーダー条件のテストケースを最初に洗い出すことが極めて重要です。なぜか：FIのバグは決算で発覚するため、発見が遅れがちで修正コストが甚大になるからです。

Clean Core時代のFI拡張

S/4HANAではFIの拡張は「Clean Core」の発想に従い、原則として外側に出すことが推奨されています。具体的には次の優先順位です。

1. Key User ExtensibilityでカスタムCDSビューやカスタムフィールドを追加
2. それでも不可能ならDeveloper Extensibility（ABAP Cloud）でクラウド対応BAdIに実装
3. ロジックが大きい場合はBTPのCAPアプリにSide-by-Sideで切り出す

なぜFIで特にClean Coreが重視されるか。FIはS/4HANAアップグレード時に最も影響を受けるモジュールであり、コア改造が残ると毎回のアップグレードで膨大なリグレッションテストが必要になるためです。Clean Core戦略の全体像はClean Core戦略で解説しています。

よくある疑問（FAQ）

Q. SubstitutionとBAdIはどちらを優先すべきですか？ A. Substitutionが使える要件なら必ずSubstitutionを優先します。コードを書かない分、保守コストが圧倒的に低いためです。

Q. BTEとBAdIはどう使い分けますか？ A. SAP標準でBAdIが用意されている場合はBAdIを優先します。BTEは「BAdIが用意されていない伝票連動処理」に限って使うのが安全です。

Q. AC_DOCUMENT BAdIで明細を追加すると貸借が崩れませんか？ A. 崩れます。追加した金額分だけ反対側の仕訳明細も同時に追加する必要があります。常に貸借一致を保つロジックが実装の責任です。

Q. F110支払BAdIでDB更新してもよいですか？ A. 原則NGです。F110の処理単位は大きく、ロールバックが発生すると整合性が崩れます。更新が必要な場合は別途RFCやイベントで非同期処理にします。

Q. 税計算BAdIは外部税エンジンとの連携でしか使えませんか？ A. いいえ。社内独自の税分類ルールにも使えます。ただし外部税エンジン連携は最も典型的な用途です。

ABAPの基礎を体系的に押さえたい人へ

FIの拡張はBAdIだけでなくSubstitution/ValidationやBTEなど系統が多く、それぞれにABAPコードを書く場面が出てきます。SELECT・内部テーブル・MESSAGE・例外処理といったABAPの基本動作が頭に入っていないと、どこに何を書くべきかの判断が難しくなりがちです。

「FIの業務知識はあるけれどABAP側はふわっとしている」という方には、アレグス株式会社・久米正通氏の『SAP ABAPプログラミング入門』のような体系的な1冊をおすすめします。AIに細切れに聞くのも手ですが、最初に全体構造を入れておくと質問の精度がぐっと上がります。

まとめ

• FIではBAdI・BTE・Substitution/Validationが併存するが、まずSubstitutionから検討するのが鉄則
• 会計伝票はAC_DOCUMENT、支払はF110系BAdI、税計算はBADI_TAX_TRIGGERが代表的
• F110系BAdIは性能と冪等性が命、月締めバッチを破綻させない設計が必須
• FI拡張は決算に直結するためテスト設計の難易度が高い、ボーダー条件の洗い出しを最優先
• S/4HANAではClean Coreの発想で、Key User Extensibility→ABAP Cloud→Side-by-Sideの順に優先する

FIの拡張は「正しさ」と「アップグレード耐性」のバランスで判断する技術です。BAdIを使うこと自体が目的ではなく、業務要件をもっとも軽く・もっとも安全に実装する手段として使うのが正しい姿勢です。

FI領域のBAdI実装に必要なABAPスキルを体系的に固めるなら、ABAPの基礎からRAP・OData・UI5 Fioriまでカバーした実践講座がおすすめです。全335レクチャーでClean Core時代の拡張開発に必要な技術を一気に習得できます。