SAP IDocとは？構造・ステータス監視・エラー対応を実務で理解する

SAPシステム間のデータ連携で、受注、出荷、請求、品目、取引先などの情報を非同期で受け渡す仕組みとしてIDocが使われます。連携が止まったときは、送信元の業務処理だけを見るのではなく、IDocのステータス、基本情報、セグメント、ポート、パートナープロファイル、後続処理を順番に確認します。この記事では、SAP ERPやSAP S/4HANAでIDocを運用する担当者が、監視と障害対応に必要な範囲をまとめます。

01IDocとは

IDocは、SAPシステムと別のSAPシステム、または外部システムの間で業務データを交換するための構造化されたデータ形式です。正式にはIntermediate Documentと呼ばれます。連携元で作成されたIDocは、送信処理、通信処理、受信処理、アプリケーション登録という段階を経て、受信側の業務データになります。

IDocは、同期的な画面処理ではなく非同期連携で使われる点が重要です。送信側の伝票登録が完了していても、受信側の登録が完了したとは限りません。受信側でエラーになったIDocは、原因を解消してから再処理します。

SAPの業務領域では、FI、MM、SD、PP、EWMなどのデータ連携にIDocが利用されます。たとえば、購買発注、入出庫、請求、受注、出荷、品目マスタ、得意先マスタなどが代表例です。どの業務で利用されているかを先に確認すると、エラーの影響範囲を判断しやすくなります。

SAPの用語や関連機能の位置付けを広く確認したい場合は、SAPモジュールの概要も参照してください。

02IDocの構造

IDocは、コントロールレコード、データレコード、ステータスレコードという3つの情報群で構成されます。

基本タイプは、IDocのセグメント構造を定義します。メッセージタイプは、受け渡す業務上の意味を表します。たとえば、同じ基本タイプを拡張して、独自セグメントを追加する構成もあります。実際の連携では、基本タイプとメッセージタイプの組み合わせを確認します。

データレコードには、ヘッダ、明細、パートナ、数量、金額などのセグメントが階層的に格納されます。エラー調査では、エラーメッセージに表示されたセグメントだけでなく、親セグメントや関連するコード値も確認してください。外部システムの値がSAP側のコード体系と一致しない場合、変換やカスタマイズの問題が原因になります。

IDocの表示では、トランザクションコードWE02またはWE05を使います。IDoc番号、作成日時、メッセージタイプ、ステータス、送信元、受信先などを条件にして対象を絞り込みます。大量件数の環境では、作成日時とステータスを組み合わせて検索し、一覧をダウンロードして傾向を確認します。

03送受信設定の確認

IDoc連携の設定は、複数の定義が連動しています。障害時には、次の順序で確認すると切り分けが安定します。

1. メッセージタイプと基本タイプが業務要件に合っているか確認する。
2. 送信元と受信先の論理システムを確認する。
3. パートナープロファイルをWE20で確認する。
4. ポート定義をWE21で確認する。
5. 送信または受信のプロセスコードを確認する。
6. 必要なフィルタ、変換、拡張セグメントの定義を確認する。
7. RFC接続やtRFCの状態を確認する。

WE20では、パートナータイプ、パートナー番号、送信側または受信側のパラメータ、メッセージタイプ、処理コード、ポートなどを確認します。受信側の処理コードが誤っていると、IDoc自体は届いていてもアプリケーション伝票が作成されません。

ポートは、IDocをどの通信先へ渡すかを定義します。RFCポートを使う構成では、接続先システム、RFC宛先、ログオン情報、ネットワーク到達性も確認対象です。RFCの接続先に関する基礎は、RFCの仕組みと確認ポイントで整理しています。

開発・検証環境では、テストデータの作成や再送を行う前に、対象IDocの業務影響を確認します。WE19を使ったテストでは、本番データをそのまま複製せず、個人情報や金額などを適切に扱った検証用データを使用します。

04IDocステータスの読み方

IDocステータスは、処理がどこまで進んだかを示す運用上の手掛かりです。ステータス番号だけで判断せず、ステータスレコードの日時、メッセージテキスト、処理対象の伝票番号を合わせて見ます。

実際の運用では、ステータスの流れが連携方式や処理タイミングによって異なります。重要なのは、最終ステータスだけでなく履歴を見ることです。たとえば、受信直後は正常でも、後続のアプリケーション処理でエラーになっている場合があります。

ステータス51では、画面に表示されたメッセージクラス、番号、変数値を記録します。メッセージ本文だけでなく、会社コード、プラント、販売組織、勘定、品目、得意先などの値が原因特定に役立ちます。ステータス64のIDocが滞留している場合は、バックグラウンド処理、処理モード、ジョブ実行状況を確認します。

05IDoc監視の実務手順

日次監視では、まずWE02またはWE05で、直近の作成日時とエラー系ステータスを条件に検索します。監視対象は件数だけでなく、同じメッセージタイプや同じ取引先に集中していないかを確認します。一定時間内に成功件数が急減した場合も、ステータスエラーが表示されていなくても調査対象になります。

次の項目を監視表に記録すると、担当者間で引き継ぎやすくなります。

• IDoc番号
• 作成日時と最終ステータス日時
• 送信元と受信先
• メッセージタイプと基本タイプ
• ステータス番号とメッセージ本文
• 関連する業務伝票番号
• 対応担当者と再処理結果

送信側でIDocが作成されない場合は、業務トランザクションの出力条件、変更ポインタ、連携対象フラグ、コミット処理を調べます。IDocが作成済みで送信されない場合は、ポート、RFC、tRFC、送信ジョブ、送信側のステータスを調べます。受信済みで登録されない場合は、受信パートナープロファイル、処理コード、マスタデータ、業務チェックを調べます。

RFC通信の滞留が疑われるときは、SM58でtRFCの状態を確認します。ネットワーク障害や接続先停止の場合、同じIDocを繰り返し再送すると重複登録のリスクがあるため、接続復旧と処理履歴を確認してから再送します。

06IDocエラーの切り分け

IDocエラーは、通信層、IDoc定義、データ内容、アプリケーション設定、マスタデータの5つに分類すると整理しやすくなります。

通信層のエラー

RFC宛先に接続できない、ポートが不正、認証情報が無効、接続先サービスが停止しているといった状態です。送信側のステータス、SM58のtRFCエントリ、RFC接続テストの結果を突き合わせます。接続先のホスト名やシステム番号を変更した直後は、変更管理の記録も確認します。

IDoc定義のエラー

基本タイプ、拡張、メッセージタイプ、セグメント構造が送受信側で一致していない状態です。拡張セグメントを追加した場合は、送受信側の定義、移送状況、処理コードの割り当てを確認します。

データ内容のエラー

日付、数量、通貨、単位、コード値、文字長、必須項目などが業務ルールに合わない状態です。エラーになった項目の値をセグメントで確認し、外部システムの変換処理とSAP側の許容値を照合します。

アプリケーション設定とマスタデータのエラー

会社コード、プラント、販売組織、購買組織、品目、得意先、仕入先、勘定などの設定不足が代表例です。IDocだけを修正するのではなく、対象組織のカスタマイズとマスタデータの有効期間を確認します。

07IDocの再処理

再処理は、エラー原因を解消した後に実施します。受信IDocの再処理にはBD87を使い、対象IDocを指定してエラー内容を確認し、再処理対象を選択します。複数件をまとめて処理する場合は、同じ原因のIDocに限定し、処理前後の件数を記録します。

再処理前に、次の点を確認してください。

• 元の業務伝票がすでに登録されていないか
• 再処理によって重複登録が起きないか
• エラー原因の設定やマスタを修正済みか
• 対象期間と対象組織が正しいか
• 再処理後のステータスを確認できる担当者がいるか

業務伝票がすでに作成されている場合は、同じIDocを再処理せず、関連伝票と後続処理を確認します。数量や金額に影響するIDocでは、再処理の前後で伝票状態と会計影響を照合します。

一時的な接続障害と、恒久的なデータ不備は別々に扱います。接続復旧後に安全に再送できるものと、データ補正や業務承認が必要なものを分け、対応履歴に判断理由を残します。

08運用設計のポイント

IDoc監視を安定させるには、エラーを見つけるだけでなく、誰が、いつまでに、どの条件で再処理するかを決めておきます。メッセージタイプごとに業務オーナー、技術担当、マスタ担当を定義し、エラー分類ごとのエスカレーション先を用意します。

監視では、失敗件数、未処理件数、処理時間、同一エラーの連続発生を指標にします。業務の締め時間や出荷カットオフなど、業務上の期限も監視条件に含めます。単純な件数しきい値だけでは、少数でも重大なエラーを見落とす可能性があります。

移送を伴う変更では、基本タイプ、拡張、メッセージタイプ、処理コード、パートナープロファイル、変換処理を変更単位として記録します。変更後は、正常系だけでなく必須項目不足、コード不正、通信停止などの異常系も確認します。

IDocの滞留や業務ジョブの異常を広く確認する場合は、SAP Basisのシステム運用も役立ちます。IDocがトランスポートで移送される設定変更に関係する場合は、トランスポート管理の基本と変更履歴を合わせて確認します。

09まとめ

IDocの障害対応では、まずIDoc番号とステータス履歴を確定し、次に基本タイプ、メッセージタイプ、パートナープロファイル、ポート、処理コード、データ内容を順番に確認します。エラーを解消してからBD87で再処理し、重複登録と業務影響を確認して完了とします。

日常運用では、WE02またはWE05による監視、SM58によるtRFC確認、BD87による再処理、設定変更の記録を一つの運用手順にまとめることが重要です。ステータス番号だけで判断せず、IDocの履歴と関連する業務伝票を突き合わせることで、通信障害と業務データ不備を効率よく分離できます。