SAP分析・レポーティング基礎

SAP QueryのSQVI・SQ01基本操作:Infosetを使った一覧作成とトラブル対応

SAP Queryで利用するSQVIとSQ01の役割、Infosetの準備、項目選択、選択条件、実行結果の確認、権限やデータ不整合への対応を実務手順として整理します。

SAP QueryにおけるSQVIとSQ01の役割クイックビューの試作から共有クエリの運用までの役割分担を示すSAP QueryにおけるSQVIとSQ01の役割クイックビューの試作から共有クエリの運用までの役割分担を示す試作に利用共有クエリを支える検証済み定義SQVIクイックな試作と個人用の…Infoset利用可能なデータ項目と粒度…SQ01共有クエリの管理と継続利…CertPas オリジナル図解
クイックな試作に使うSQVI、データ定義を担うInfoset、共有クエリを管理するSQ01の関係
目次
  1. SQVIとSQ01の役割を分ける
  2. Infosetを確認してデータ範囲を決める
  3. SQVIでクエリを試作する
  4. SQ01で共有クエリを管理する
  5. 選択条件と実行性能を整える
  6. 結果が空になるときの切り分け
  7. 重複行と想定外の件数を調べる
  8. 運用時の変更と保守を管理する
  9. 実務で使える確認チェックリスト

SAP Queryは、業務テーブルを直接調査する代わりに、定義済みのInfosetから必要な項目を選び、一覧や簡易レポートを作成するための仕組みです。現場では、個人用の確認を素早く行うときにSQVIを使い、複数ユーザーで利用するクエリを整備するときにSQ01を使います。設計の出発点は、欲しい一覧を先に明確にすることです。対象業務、必要な項目、抽出条件、集計の有無、出力先を決めてから画面操作に進むと、後からの作り直しを減らせます。

SQVIとSQ01の役割を分ける

SQVIはクイックビューアとして、利用者が作業用の一覧を短時間で作成・検証する場面に適しています。結合対象や選択項目を画面上で確認しながら、結果が業務要件に合うかを試せます。試作段階では、抽出件数、空欄の扱い、同じ伝票に複数明細がある場合の行数を確認します。

SQ01は、ユーザーグループやクエリ領域を意識して、継続利用するクエリを管理するための入口です。名称、説明、Infoset、選択画面、一覧レイアウトを整理し、利用者が同じ条件で再実行できる状態にします。作業用のSQVIで要件を固め、その結果をもとに共有用のSQ01へ移す流れにすると、試作と運用を分離できます。

目的主な入口実務上の位置付け
個人または小規模な確認SQVI試作、データ確認、短期利用
継続的な共有レポートSQ01クエリ管理、利用者展開、運用
データ構造の準備Infosetテーブル・結合・項目の定義
SAP Queryの空結果を切り分ける流れ最小条件での再実行からデータ、Infoset、権限の確認までを案内するSAP Queryの空結果を切り分ける流れ最小条件での再実行からデータ、Infoset、権限の確認までを案内する再実行空のままデータが存在定義が妥当結果が空クエリが行を返さない条件を最小化必須の期間や識別条件だけ…データの存在を確認関連する業務画面と照合す…Infosetを確認データソースと結合意図を…権限を確認クエリ実行権限とデータ参…CertPas オリジナル図解
SAP Queryの空結果に対し、条件を最小化し、データ、Infoset、権限を順に確認する切り分けフロー

Infosetを確認してデータ範囲を決める

Infosetは、クエリで利用できるデータ項目とデータの関係を定義する土台です。作成前に、対象のInfosetがどの業務領域を扱うか、単一テーブルを基準にしているか、複数のデータソースを結合しているかを確認します。項目名だけで判断せず、実際の値の意味、キーの粒度、明細とヘッダの関係を担当者に確認してください。

特に重要なのは、一覧の1行が何を表すかです。受注ヘッダを基準にした一覧と、受注明細を基準にした一覧では、同じ受注番号が複数行に表示されることがあります。請求や在庫のように明細が増える業務では、結合によって行数が増える可能性を把握します。件数の期待値を、既存の業務画面や検証用データと照合してから公開します。

Infosetに必要な項目がない場合は、クエリ画面で無理に補うのではなく、Infosetの設計を見直します。項目追加や結合変更は、既存のクエリ結果にも影響するため、開発・検証環境で結果を比較し、利用者と合意したうえで反映します。

SQVIでクエリを試作する

  1. SAP GUIで SQVI を起動し、クイックビュー名を入力します。名前は対象業務と用途が分かる短いものにし、個人用か検証用かを説明欄に残します。
  2. データソースとして利用するInfosetを選択します。候補が複数ある場合は、必要な項目とデータ粒度が合うものを選びます。
  3. 選択項目に、結果一覧へ表示したい項目を追加します。利用者が意味を理解できる順序に並べ、識別項目、日付、組織、数量、金額などを区分します。
  4. 選択条件に、実行時に入力させる条件を追加します。会社コード、期間、伝票番号など、件数を抑えやすい条件を優先します。
  5. 生成または実行を行い、選択画面と一覧結果を確認します。条件を狭くした検証から始め、結果件数、重複、空欄、単位、通貨を確認します。
  6. レイアウトを調整し、利用者が最初に確認する項目を左側へ配置します。並べ替えやフィルタは、利用者の業務手順に合わせて保存します。

最初から全項目を追加すると、選択画面と結果一覧が複雑になります。要件に必須の項目だけで最小構成を作り、検証後に補助項目を追加する方が、原因切り分けをしやすくなります。

SQVIで使うトランザクションの位置付けを整理したい場合は、SAPのトランザクションコード一覧も参照できます。個別のコードを暗記するより、用途と実行権限をセットで管理すると運用しやすくなります。

SQ01で共有クエリを管理する

共有用のクエリは、名称だけで用途が分かるように設計します。説明には対象業務、対象期間、基準となるデータ粒度、主要な選択条件を記載します。短い名前を付けるだけでは、似たクエリが増えたときに利用者が誤実行しやすくなります。

SQ01では、クエリ領域とユーザーグループを確認します。利用者が同じ領域を参照できること、Infosetがその領域で利用可能になっていること、実行権限とデータ参照権限が分けて確認されていることが重要です。開発・テスト・本番で同じ名称を使う場合も、移送や変更履歴を管理し、誰がいつ変更したかを追跡できるようにします。

公開前には、次の観点で受け入れ確認を行います。

  • 代表的な正常データで、期待した件数が返る
  • データが存在しない条件で、空結果を適切に扱える
  • 必須条件を未入力にしたとき、過大な検索にならない
  • 明細の重複やヘッダと明細の粒度差が説明されている
  • 金額、数量、日付、単位、通貨が業務画面と一致する
  • 利用者が必要な行だけを参照できる
  • 出力ファイルに不要な個人情報や機密情報が含まれない

選択条件と実行性能を整える

クエリの速度は、データ量だけでなく、選択条件の設計にも左右されます。期間、組織、伝票番号など、対象範囲を限定できる条件を選択画面に出し、利用者へ入力ルールを示します。大量データを扱うクエリでは、初回実行を小さな期間で行い、処理時間と結果件数を確認してから範囲を広げます。

選択条件には、必須入力として扱う条件と任意条件を区別します。必須条件は、検索対象の業務範囲を安全に限定できるものを選びます。任意条件を増やしすぎると、利用者が条件の意味を理解できず、結果の再現性も下がります。

同じ条件で実行して結果件数が毎回変わる場合は、対象データの更新、日付時刻の境界、未完了伝票の扱い、権限による可視範囲を確認します。処理時間の改善を急ぐ前に、結果が正しいかを確定させることが重要です。

結果が空になるときの切り分け

結果が空の場合は、まず選択条件を最小化し、期間と主要な識別条件だけで実行します。その条件で結果が返る場合は、追加した条件を一つずつ戻して、絞り込みの原因を特定します。日付の開始日・終了日、組織コードの入力形式、前後の空白、ステータス条件を重点的に確認します。

最小条件でも結果がない場合は、対象のInfoset、データソース、クエリ領域、ユーザー権限を確認します。参照対象の業務画面でデータが見えるかを確認し、同じユーザーでクエリを実行します。業務画面には表示されるのにクエリだけ空になる場合は、Infosetの結合条件や権限制御の違いを調査します。

権限の確認では、利用者の役割、対象組織への参照範囲、クエリを実行する権限を分けて確認します。権限エラーの調査手順は、SAPレポート権限の基本に整理されています。エラーの発生時刻、ユーザー、クエリ名、入力条件、再現手順を記録すると、管理担当者との連携が速くなります。

重複行と想定外の件数を調べる

同じ伝票番号が複数行になるときは、まず1行の意味を確認します。明細一覧であれば、同じ伝票番号が複数回出ることは正常です。ヘッダ一覧を想定しているのに行が増える場合は、結合先の明細数、関連データの有無、重複する結合条件を調べます。

検証では、伝票番号、明細番号、作成日、組織、数量など、粒度を判断できる項目を一時的に表示します。結果を少数の代表データに絞り、業務画面の明細数と照合します。重複の原因がInfosetにある場合は、クエリ側の並べ替えだけで隠さず、Infosetの設計担当者に結合の意図を確認します。

運用時の変更と保守を管理する

クエリは業務で参照される成果物として扱い、変更前に利用状況と影響範囲を確認します。項目の削除、名称変更、結合変更、選択条件の必須化は、利用者の保存バリアントや出力手順に影響します。変更内容、理由、テスト結果、承認者、反映日時を記録します。

利用者から「結果が変わった」と連絡があった場合は、最初にクエリ定義、Infoset、入力条件、データ更新時刻を比較します。次に、同じ条件を同じユーザー権限で再実行し、差分を件数・項目・対象データの順に分けて確認します。仕様変更による差分と、データや権限による差分を区別すると、不要な定義変更を避けられます。

レポート全体の設計方針や、他の分析手段との関係を整理する場合は、SAP分析・レポーティングの概要を参照してください。SAP Queryを軽量な業務一覧に使い、より大規模な分析基盤とは役割を分けると、保守範囲を明確にできます。

実務で使える確認チェックリスト

作成前

  • 一覧の1行が表す業務単位を決める
  • 必須項目と補助項目を分ける
  • 対象期間、組織、ステータスなどの条件を決める
  • 参照可能な利用者と機密項目の扱いを決める

試作時

  • SQVIでInfosetとデータ粒度を確認する
  • 少量データで結果件数を照合する
  • 空欄、重複、単位、通貨、日付を確認する
  • 実行時間と最大検索範囲を確認する

共有前

  • SQ01で名称と説明を整える
  • ユーザーグループとクエリ領域を確認する
  • 権限の異なる利用者で結果を比較する
  • 変更履歴と問い合わせ先を記録する

障害対応時

  • クエリ名、ユーザー、実行時刻、条件を記録する
  • 条件を最小化して再実行する
  • Infoset、権限、データ更新を順に確認する
  • 結果件数と代表データを業務画面と照合する

SQVIは、要件を素早く検証するための実務的な入口です。SQ01は、検証済みの定義を利用者が再現可能な形で共有するために使います。Infosetの粒度、選択条件、権限、変更履歴を一体で管理すると、単なる一覧作成から、信頼して使える業務レポートへ発展させられます。

ブログ一覧へ戻る