G/L勘定移行でエラー・ダンプが発生したときの切り分け方
Migration CockpitでG/L勘定を移行していると、ファイルのアップロード、内部ジョブ、シミュレーションなど、異なる段階でエラーが発生することがあります。
今回の検証でも、
- XMLファイルの形式エラー
- 内部ジョブの失敗とABAPダンプ
- 特定のG/L勘定だけがシミュレーションエラー
という複数の問題が続けて発生しました。
この記事では、これらを一つの原因として扱わず、「どの処理段階で止まったのか」を基準に、実機でどのように切り分けたかを整理します。
根本原因まで一次証拠で確認できなかった箇所については、確認できた事実と推測を分けて記載します。
検証情報
| 項目 | 内容 |
|---|---|
| SAP製品 | SAP S/4HANA 2025 |
| 導入形態 | On-Premise |
| UI | SAP GUI for HTML / Fiori |
| 検証日 | 2026-07-23～2026-07-25 |
| 対象領域 | FI 財務会計 / データ移行 |
| 主なT-code / App | Migration Cockpit / ST22 |
| 検証レベル | 実機確認済 |
会社コードZ091、勘定コード表ZJP1、G/L勘定823100などは、今回の検証環境で使用した値です。
今回発生した3種類の問題
最初に、今回発生した問題を処理段階ごとに整理します。
| 発生段階 | 実機で確認した現象 | 主な確認先 |
|---|---|---|
| ファイル読込 | XMLファイル形式エラー | Migration Cockpit |
| ジョブ実行 | アクティビティ失敗、ABAPダンプ | Migration Cockpit / ST22 |
| シミュレーション | 特定のG/L勘定だけエラー | Migration Cockpit / 補正XML |
同じ移行作業の中で連続して発生しましたが、原因まで同じとは限りません。
筆者判断: 今回は、直前のエラーとの因果関係を決めつけず、「どこまで処理が進んだか」を確認して調査対象を切り替えました。
1. XMLアップロード時にファイル形式エラー
G/L勘定拡張用のXMLファイルをMigration Cockpitへアップロードしたところ、ファイルチェックでエラーになりました。
実機確認: 画面には次の内容が表示されました。
- 「アップロードファイルの形式が正しくありません」
- 「ファイルには1行だけが含まれています」
この時点では、G/L勘定の各データをシミュレーションする段階まで進んでいません。
SAP一般仕様: XMLテンプレートファイルをMigration Cockpitへアップロードすると、システムはファイル内のデータを検証します。検証が正常に完了すると、そのデータが対象Migration Objectのステージングテーブルへ転送されます。
したがって、まず「ファイルを正常に読み込めていない」のか、「読込後のデータ処理でエラーになっている」のかを分けて考えます。
初回XMLと修正版XMLを比較
実際に使用した初回ファイルと修正版ファイルを比較しました。
確認できた内容は次のとおりです。
- 93件のデータセル値は一致
- 初回ファイルはLF改行
- 修正版ファイルはCRLF改行
- XML宣言などファイル形式上の差異がある
修正版では、最初に表示されていたファイル形式エラーから先の処理へ進みました。
ただし、LFからCRLFへ変わったことだけをもって、改行コードが原因だったとは断定できません。
実機から確認できたのは、「両ファイルに形式上の差異があり、データセル値には変更がなかった」というところまでです。
2. 修正版では別のジョブエラーが発生
修正版XMLを使用すると、今度は別のエラーが発生しました。
実機確認: Migration Cockpitでは、ジョブ
/1LT/MC_M03_GL_ACC_EXT_FP 07554300
の問題により、アクティビティが失敗したことを確認しました。
最初のファイル形式エラーとは異なり、今回はMigration Cockpit内部の処理まで進んだ後に失敗しています。
そこで、XML形式エラーの続きと決めつけず、技術エラーとしてST22を確認しました。
3. ST22でABAPダンプを確認
ST22で該当するABAPダンプを確認しました。
実機確認: ST22の実行時エラー一覧では、次の情報を確認できました。
- Runtime Error：
ITAB_LINE_NOT_FOUND - Exception：
CX_SY_ITAB_LINE_NOT_FOUND - Program：
/LTB/CL_MC_XML_XLS============CP
別添のダンプ詳細記録には、メソッドEXTRACT_COLUMN_DESCRで内部テーブルLT_VALUEのインデックス1へのアクセスに失敗したことが記録されていました。これらの詳細は図3の一覧画面には表示されていません。
Migration Cockpit上ではアクティビティ失敗までしか分かりませんでしたが、ST22ではABAP側でどの処理が失敗していたかをさらに確認できました。
一方、このダンプからXMLのどの記述が根本原因だったかまでは確認できませんでした。
初回XMLと修正版XMLの形式差が、このダンプを直接発生させたという因果関係も確認できていません。
筆者判断: ST22は、技術エラーの発生箇所を掘り下げる材料として有効です。ただし、ダンプに表示されたABAP上の失敗箇所と、業務上の根本原因を同一視しない方が安全です。
4. 次は823100だけがシミュレーションエラー
別の段階では、Migration Cockpitのシミュレーションで特定のG/L勘定だけがエラーになりました。
実機確認: シミュレーション結果では、
- G/L勘定
823100：エラー - G/L勘定
892000：正常終了
となっていました。
同じ一覧で正常終了するレコードが存在するため、ここではMigration Cockpit全体ではなく、エラーとなった823100の入力データへ調査対象を絞りました。
SAP一般仕様: Migration Cockpitには、本移行前に移行処理をシミュレーションし、その処理状況を確認する機能があります。
5. 823100の補正前後を比較
実際に使用した補正前XMLと補正後XMLについて、823100のデータを比較しました。
会社コードデータで確認できた内容は次のとおりです。
| 項目 | 補正前 | 補正後 |
|---|---|---|
| 勘定コード表 | ZJP1 | ZJP1 |
| G/L勘定 | 823100 | 823100 |
| 会社コード | Z091 | Z091 |
| 勘定通貨 | JPY | JPY |
| 税カテゴリ | - | - |
| Sort Key | 008 | 008 |
| 項目ステータスグループ | G003 | G003 |
| 元帳グループ固有消込 | X | 空欄 |
一般データと管理領域データについても、確認した823100の値に変更はありませんでした。
今回比較できた範囲では、「元帳グループ固有消込」がXから空欄へ変更されています。
SAP一般仕様: 元帳グループ別の消込は、すべてのG/L勘定へ無条件に設定できる機能ではなく、勘定の種類などに適用条件があります。
ただし、今回の823100について、シミュレーションエラーの詳細メッセージ原文は一次証拠として確認できていません。
そのため、
「元帳グループ固有消込がXだったことが、823100のエラー原因だった」
とは断定しません。
実機で確認できた事実は次の3点です。
823100がシミュレーションでエラーになった- 補正前後で「元帳グループ固有消込」が
Xから空欄へ変更された - 再処理後に
823100が正常終了した
筆者判断: 補正前後の入力データを比較すると、調査対象を絞り込みやすくなります。ただし、「変更した項目」と「エラー原因が確定した項目」は分けて扱う必要があります。
6. 補正後に正常終了まで確認
補正したXMLを再度Migration Cockpitへ取り込みました。
実機では、補正ファイルが「ステージングテーブルへデータ転送済」となったことを確認した後、処理を継続しました。
最終的に823100は、
- 移行済
- 正常終了
となりました。
これにより、今回の検証環境では補正後のデータでMigration Cockpitの処理を完了できたことを確認できました。
筆者判断: トラブル対応は、ファイルや値を変更した時点ではなく、再処理後に期待した完了状態になったことを確認するまで追う方が確実です。
Migration Cockpitのエラーをどう切り分けるか
今回の実機検証から、確認順序を次のように整理しました。
1. どの処理段階で止まったか確認する
まず、次のどこで問題が起きているかを確認します。
- ファイルアップロード／検証
- ステージングテーブルへの転送
- 内部ジョブ
- シミュレーション
- 移行
エラーメッセージだけでなく、処理がどこまで進んだかを見ることで調査範囲を絞ります。
2. Migration Cockpitのメッセージを確認する
対象レコード、ステータス、ジョブなど、Migration Cockpit上で確認できる情報を押さえます。
特定のレコードだけがエラーになっている場合は、システム全体の問題と決めつけず、そのレコードの入力データも確認します。
3. 技術エラーならST22まで確認する
内部ジョブが失敗している場合は、必要に応じてST22でABAPダンプを確認します。
ここでは「どこで技術的に失敗したか」と「なぜその状態になったか」を分けて考えます。
4. データエラーなら補正前後を比較する
対象レコードについて、
- どの項目を変更したか
- 変更していない項目は何か
- 補正後に結果がどう変わったか
を比較します。
5. 再処理後の正常終了まで確認する
修正しただけで終了せず、シミュレーションや移行のステータスを再確認します。
今回のように複数種類のエラーが続いた場合、「Migration Cockpitでエラーが出た」と一括りにせず、処理段階ごとに切り分けることで調査しやすくなります。
原因を断定できない場合も記録に残す
今回、ST22のダンプではABAP上の失敗箇所まで確認できましたが、XMLのどの形式差が直接原因だったかまでは確定できませんでした。
823100についても、補正前後の差分とその後の正常終了は確認できましたが、その差分をエラー原因と断定できる一次証拠までは揃っていません。
トラブルシューティングでは、
- 実際に発生した現象
- 調査で確認した事実
- 原因として考えていること
- 実際に変更した内容
- 再実行した結果
を分けて残しておくと、後から検証しやすくなります。
「直ったから原因も確定した」と扱わないことも、今回の検証で重要だったポイントです。
まとめ
今回のG/L勘定移行では、XMLファイル形式エラー、内部ジョブの失敗とABAPダンプ、特定G/L勘定のシミュレーションエラーという、異なる段階の問題が発生しました。
実機検証から整理できたポイントは次の3つです。
- エラーを一括りにせず、どの処理段階で止まったかを確認する
- 技術エラーとデータエラーで確認する情報を切り替える
- 原因を推測で断定せず、補正後の正常終了まで確認する
エラーが連続しても、すべてが同じ原因とは限りません。
Migration Cockpitの処理状況、ST22のダンプ、投入データの差分を使い分けながら、確認できた事実を積み重ねて切り分けることが重要です。
