【SAP】販売伝票のユーザEXIT 概要編(Userexit for SalesOrder document Overview)

こんにちは。
今回は、SDの販売伝票におけるユーザEXIT(イグジット)の情報をまとめました。
ユーザEXITはコンサルや担当者の知恵袋的な脳内情報しかない場合が多く、いつも現場で苦戦することが多いため自分の脳内整理を含めてまとめてみました。今回は「販売伝票のユーザEXITではだいたいこういうことができる」ということをわかっていただくための内容にしています。参考になりましたら幸いです。

※実装方法を知りたい方はこちらをどうぞ。
【SAP】販売伝票のユーザEXIT 実装編

ユーザEXITとは

伝票登録・編集等のSAP標準のトランザクション処理の内部で定義されている、独自のABAPロジックを追加することができるサブルーチンのことです。

ユーザEXITは顧客独自要件の実現可能手段としては古くからあり、現在は、ビジネスアドイン(BAdI)、カスタマーEXIT、拡張ポイント(ENHANCEMENT POINT)（そしてアドオンプログラム）などのより新しい技術で独自要件実現をすることが主流となっています。しかし、SDの販売・請求は例外的に知名度・技術的な難易度の低さから、ユーザEXITによる実装が選択される場合が多いようです。

ユーザEXITのメリット

・ユーザEXITによる追加ロジックは、サポート対象外になる「モディフィケーション」には該当しない。 不確定な内容なので取り消します。
※ただし、元となるSAP標準ロジックが変更になることで、ユーザEXITに影響が出る可能性がある。
・独自要件が多く発生する、販売伝票登録・変更処理において顧客の独自要件に合致する値チェックや値設定ロジックを実装することが可能
・画面項目値の取得が簡単であること、ABAPでコードが書けDBアクセスもできる、など開発障壁自体は低い

ユーザEXITのデメリット

SAP標準ロジックの合間に動くという特徴があり、アドオンプログラムよりも自由度が低くなります。これらに合致しない要件の実装を行う場合は、設計や開発に多くの工数を要する可能性が高くなります。

・各ユーザEXITが呼び出される場所・処理順・回数は決まっていて変更できない
・適切に動くかどうかは実装し動作確認してみないとわからない場合が多く、特に設計段階ではわからないことが多い。設計・実装の工数は、実装内容よりもより多くの工数をバッファとして考慮しておく必要がある
・顧客要件が複雑な場合、ユーザEXITでの実装がアドオンPGMでの実装以上に難易度が高くなる可能性がある（体験談）
・実行者により画面操作の順番が変わることがあると、想定していたユーザEXITが動かなかったり、想定していないユーザEXITが動いたりと思わぬ動作になる場合がある
・SAPからの公式情報が少なすぎる

ユーザEXITでの実装内容が軽微な内容となる場合や設計と開発を兼任するなどの場合はそれほど問題にならない場合が多いのですが、昨今はSDのFit&GapのGap部分を全部Exitで実装、とする場合が多くなっていることで実装内容の肥大化、設計者と開発者が別の場所にいることによって仕様確認に時間がかかるようになったことが、難易度向上、作業工数増加の一因になっているように感じます。

販売伝票のユーザEXITの確認方法

トランザクション：SPROから「SAP完全版IMG」を押下後、以下のパスからIMGアクティビティ文書を参照すると、各ユーザEXITが割り当てられているインクルードやその役割が確認できます。

販売管理>システム調整>ユーザExit(販売)>ユーザExit:販売伝票処理
Sales and Distribution>System Adaptation>User Exits>User Exits In Sales Document Processing(英語版)

プログラム

対象のユーザEXITのルーチンが実装されているインクルードプログラム。開発時はABAPエディタでこのインクルードプログラムを変更して処理を実装する。SDのユーザーEXITは、MV45AFZB・MV45AFZZなどのいくつかのインクルードプログラムに分かれて登録されている。

ユーザーEXIT名

インクルードプログラム内でのユーザEXITに該当するサブルーチンの名称（ユーザEXITの名称＝サブルーチン名称）。

説明

このユーザEXITでどのような処理ができるかを記述した内容。SAP標準ロジックのどの箇所から呼び出されるかといった情報も記載されている。どこから呼び出されるかわかったところで、その呼び出し元がどのタイミングで呼び出されるかはデバッグモードなどで確認する必要がある。

ユーザEXITでできる内容

私が設計や実装を経験した、また参画したプロジェクトで利用を確認した、ユーザEXITとその説明を以下に箇条書きしておきます。
※上述のアクティビティ文書にはより多くのユーザEXITの記述があります。

販売伝票ヘッダ(VBAK)項目関連

値設定 USEREXIT_MOVE_FIELD_TO_VBAK

値チェック USEREXIT_CHECK_VBAK

販売伝票明細(VBAP)項目関連

値設定 USEREXIT_MOVE_FIELD_TO_VBAP

値チェック USEREXIT_CHECK_VBAP

販売伝票納入日程行(VBEP)関連

値設定 USEREXIT_MOVE_FIELD_TO_VBEP

値チェック USEREXIT_CHECK_VBKD

販売伝票ビジネスデータ(VBKD)関連

値設定 USEREXIT_MOVE_FIELD_TO_VBKD

値チェック USEREXIT_CHECK_VBKD

画面項目属性値変更

画面項目属性を変更 USEREXIT_FIELD_MODIFICATION ※昨今はS/4HANAの場合、ScreenPersonaでの対応が増えつつある

決定要素用構造への値設定

価格などの決定要素用構造へのSAP標準ロジックによる値設定値変更および、決定要素項目に独自追加した項目への値設定

価格決定ヘッダ USEREXIT_PRICING_PREPARE_TKOMK

価格決定明細 USEREXIT_PRICING_PREPARE_TKOMP

品目変換ヘッダ USEREXIT_MOVE_FIELD_TO_KOMKD

品目変換明細 USEREXIT_MOVE_FIELD_TO_KOMPD

品目制限ヘッダ USEREXIT_MOVE_FIELD_TO_KOMKG

品目制限明細 USEREXIT_MOVE_FIELD_TO_KOMPG

後続処理に値を設定する処理

仕入先直送伝票登録後に連動して自動登録される購買伝票の各項目への値設定処理 USEREXIT_MOVE_FIELD_TO_ME_REQ

プラントや明細カテゴリを独自ロジックで決定する場合

USEREXIT_SOURCE_DETERMINATION ※ここに記述していないと、SAP標準の決定方法で決定しようとする

伝票保存前処理

保存ボタンを押下して（他ユーザEXIT処理後に）実行される処理 USEREXIT_SAVE_DOCUMENT_PREPARE
この処理で特殊なグローバル項目への値設定や、エラーメッセージを表示することで伝票保存処理を中止することが可能

伝票保存後の内部処理

販売伝票データが作成され、データベースコミット前の状態で動く処理 USEREXIT_SAVE_DOCUMENT
登録時に採番された伝票番号などを別DBに設定するなどの用途に絞られる。
このユーザEXITでエラー処理を起こすとデータベースコミットが中断され処理が終了するため、エラー処理は実装不可。

「あれっ？」と思った方もいらっしゃると思いますが、取引先機能(VBPA)用のユーザEXITはありません。
取引先機能（取引先機能タブ画面）にしか存在しない請求先や支払人などを利用・チェック・値設定するなどの独自処理をユーザEXITで実装する場合は、ヘッダや明細レベルでのユーザEXITにて記述することになります。

まとめ

SDの販売伝票のユーザEXITについて以下のことを説明しました。
・ユーザEXITとは何か
・販売伝票のユーザEXITでできることの概要

実装に必要なTIPSなどは次回の実装編にてまとめます。今回の内容は以上となります。ありがとうございました。