SAPのエラーを3種類に分ける

検証環境を自分で触っていると、1日に何度もエラーで止まります。困るのは、メッセージを読んでもどこを直せばいいのか分からないときです。エラーの文面と、実際に直すべき場所が離れていることが珍しくないからです。

そこで私は、エラーを「設定不足」「データ不足」「権限不足」の3つに分けてから原因を追うようにしています。分類が決まると、次に開く画面が決まります。この記事では、BP（ビジネスパートナ）登録、支払実行、外貨評価、標準原価計算などで実際に出たエラーを例に、その切り分け方を書きます。

設定不足：「割り当てられていません」は割当テーブルを直接見る

BPを登録しようとして「グルーピング0001は得意先勘定グループに割り当てられていません」で止まったことがあります。S/4HANAでは、得意先・仕入先はBPから登録し、CVI（Customer/Vendor Integration）の仕組みで得意先マスタ・仕入先マスタが作られます。このとき、BPのグルーピングと得意先勘定グループの対応が設定されていないと、BP側は保存できても得意先側を作れません。

• BPグルーピングと得意先勘定グループの割当を確認する（カスタマイジングビュー V_TBD001、SM30でも参照できる）
• 得意先勘定グループ側の番号範囲を確認する（XDN1で番号範囲そのものが存在するか）
• BPグルーピングの番号範囲と、得意先勘定グループの番号範囲が食い違っていないかを確認する

私の環境では、勘定グループ側に番号範囲が割り当てられているのに、XDN1にその番号範囲が存在しないという状態でした。番号範囲を作っても解消せず、結局はBP作成時に選んだグルーピングと勘定グループの対応そのものを見直すことになりました。同じメッセージでも「割当が無い」「割当先の番号範囲が無い」「両者の番号範囲が違う」と原因が複数あるため、1つ直して直らなくても、隣の設定を順に見ていくのが早道です。

もう1つ、S/4HANAで増えた前提設定にも注意が必要です。外貨評価（FAGL_FCV）では、評価方法や会計原則の割当を済ませても「ECS環境を登録してください」と言われて進めません。これはS/4HANAで追加された前提で、SAPが標準で用意しているECS環境の設定をコピーして使い、あわせてECS伝票用の番号範囲も登録する必要があります。「機能が動かない＝自分の設定ミス」とは限らず、そのリリースで増えた前提設定が抜けているだけ、というケースです。

データ不足：処理は正しいのに、対象が1件も無い

2つ目は、設定も権限も問題ないのに、処理する元データが無いケースです。検証環境で自分でデータを作りながら試していると、いちばん多いのがこれでした。

例えば、日本用の支払媒体プログラム（国内DME）を実行して「レコードがありません」と出たとき。このプログラムは、支払実行（F110）が作った支払データを読んで、全銀フォーマットの振込データを作ります。つまり、前工程のF110がデータを作っていなければ、プログラム側は何もできません。

1. F110の実行日（LAUFD）と識別子（LAUFI）を控える
2. REGUH（支払データのヘッダ）とREGUP（支払対象の明細）を、その実行日・識別子で検索する
3. 0件なら支払実行そのものが対象を拾えていない。例外リストで、支払方法やハウスバンクの設定・マスタ登録漏れを確認する
4. 件数があるなら、支払媒体プログラムに渡している選択条件（支払方法やハウスバンクなど）が、そのデータと合っているかを確認する

CO-PAの明細照会（KE24）で「これらの選択条件に対する明細がありません」と出たときも同じでした。権限を疑う前に、そもそもCO-PAの明細が1件も無いという可能性があります。既存明細をコピーして試そうにも、元が0件ではコピーもできません。この場合は、KE21NでCO-PA明細を直接登録するか、販売や請求の伝票を実際に転記して明細を発生させる必要があります。

権限不足：SU53だけで判断しない

3つ目が権限です。ただし、この分類がいちばん誤判定しやすいところでもあります。メッセージに「権限がありません」と書いてあっても、ユーザの権限の話とは限らないからです。

このケースの詳細は、こちらにまとめています。CK24で「マークを行う権限がありません」と出たら

やっかいなのは、権限が原因なのにメッセージが素っ気ないケースです。処理自体は最後まで通るのにデータが作られない、という状況で、SU53にテーブル表示の権限オブジェクト（S_TABU_NAM）が出ることがありました。

もう1つ、切り分けのときに役立つ考え方があります。手を打ったあとにエラーが業務前提のエラー（さきほどのMM期間のような内容）に変われば、その手前のチェックは通過したということです。権限を検証している場面なら、そこまで到達した時点で権限は足りていると判断できます。エラーが変わったこと自体が進捗だ、と捉えると切り分けが楽になります。

エラーの言う場所と、直す場所が違うことがある

3分類でも迷うのが、エラーの指す場所と原因の場所が違うケースです。原価要素の計画（KP06）で「値xxxxxxは項目 原価要素では使用できません」と出たことがあります。入力候補に出る原価要素でも、原価要素カテゴリ（CSKB-KATYP）を確認しても弾かれる。結論から言うと、原因は原価要素マスタではなく、使っていた計画レイアウト側の制約でした。

CO計画は「計画立案者プロファイル（KP04）で、どのレイアウトを使うか」が入口になっていて、レイアウトによって入力できる項目が変わります。マスタを何度見直しても直らないときは、入力画面を規定している側（レイアウト、画面バリアント、伝票タイプなど）を疑うと抜けられます。

切り分けの順番

1. メッセージ番号を控える。長文ヘルプを読む
2. 3分類のどれかを決める。「割り当てられていません／ありません（設定名）」は設定不足、「レコードがありません／明細がありません」はデータ不足、「権限がありません」は権限不足
3. 設定不足なら、名指しされたテーブルや割当を保守する設定画面を開く。直らなければ、その設定に隣接する設定（番号範囲、割当先）を順に見る
4. データ不足なら、前工程のトランザクションと、データを保持するテーブルを直接見て件数を確認する
5. 権限不足なら、STAUTHTRACEで実際のチェックを見る。SU53だけで判断しない
6. どれにも当てはまらないときは、入力画面を規定している設定（レイアウトやバリアント）と、そもそも標準かアドオンかを疑う

なお、この記事には名前だけの用語がたくさん出てきました。最後に一覧にしておきます。

エラーが出ること自体は避けられません。ただ、「今どの分類の問題を見ているのか」をはっきりさせておくと、闇雲に設定を触る時間が減ります。検証環境を触るときは、解決した内容だけでなく「どの分類だったか」も一緒にメモしておくと、次に似たエラーが出たときの速度が変わります。