SAP出力・印刷管理
SAPスプール管理の基礎：SP01での確認と印刷トラブルシューティング
SAPのスプールリクエストをSP01で確認し、出力先・状態・権限・印刷経路を切り分ける実務手順を解説します。不要スプールの整理や再出力、SPADとの連携も説明します。
SAPスプール管理の全体像
SAPのスプールは、帳票や一覧をすぐにプリンターへ送るのではなく、いったん出力データとしてシステム内に保持する仕組みです。ユーザーが実行した帳票、バックグラウンドジョブが作成した帳票、アプリケーションから依頼された印刷データは、スプールリクエストとして確認できます。運用では、作成されたか、正しい出力先が設定されているか、出力済みか、印刷処理で停止しているかを順番に確認します。
スプール管理は帳票アプリケーションだけの作業ではありません。帳票を生成するABAPプログラム、出力条件を決めるアプリケーション設定、出力デバイス、ホストスプール、プリンターまでが一つの経路を構成します。帳票設計の範囲は出力・印刷管理の全体像で整理し、スプールではその後段にあるデータと出力処理を中心に調べます。
スプールリクエストと出力リクエスト
スプールリクエストは、SAPが生成した出力データを管理する単位です。出力属性には、作成者、作成日時、タイトル、ページ数、出力デバイス、出力形式、保持期間などが含まれます。出力リクエストは、スプールデータを実際の出力先へ送る処理の記録です。スプールが存在していても出力リクエストが作成されていない場合、プリンターには到達しません。
この二つを分けて確認すると、帳票生成の問題と印刷経路の問題を切り離せます。スプール自体がない場合は、帳票プログラム、ジョブ、出力条件、権限を調べます。スプールがあり出力処理だけが止まっている場合は、出力デバイスやホスト側の印刷処理を調べます。
SP01でスプールを確認する手順
SAP GUIからトランザクションSP01を開き、対象ユーザー、作成日時、スプール番号、タイトルなどで検索します。運用担当者が別ユーザーのスプールを確認する場合は、対象範囲を明確にしてから検索条件を設定します。期間を広く取りすぎると大量の結果になり、対象リクエストの特定に時間がかかります。
検索結果では、次の項目を確認します。
- スプール番号と作成者
- 作成日時とタイトル
- ページ数または出力データの有無
- 出力デバイス
- 出力済みかどうか
- 出力リクエストの状態
- 保持期限や削除予定
対象行を選択して内容を表示すると、帳票のレイアウトやデータ欠落も確認できます。プレビューが正常であれば、帳票生成とスプールデータの作成は完了しています。プレビュー自体が空白、途中で切れている、文字化けしている場合は、印刷先より前の帳票生成または出力形式を調べます。
検索条件を保存する場合は、日常監視用と障害調査用を分けます。日常監視では直近の未出力データを対象にし、障害調査ではスプール番号やジョブログに記録された作成時刻を使います。大量の古いスプールを一度に表示する運用は、検索性能と確認精度の両面で避けます。
スプールが作成されない場合の切り分け
帳票を実行した後にSP01で該当データが見つからない場合は、まず処理自体が完了したかを確認します。オンライン処理なら画面上のメッセージ、バックグラウンド処理ならSM37のジョブログとジョブステップを確認します。ジョブが異常終了している場合、スプールの調査より先にABAPダンプ、権限エラー、選択条件、アプリケーションログを確認します。
帳票生成が成功している場合は、出力設定を調べます。出力条件が成立していない、出力媒体が画面やファイルになっている、ユーザーの既定出力デバイスが未設定である、といった状態では期待したスプールが作成されません。販売・購買・請求などの業務処理から自動出力される帳票では、出力決定とメッセージ処理の確認が重要です。出力条件の考え方は出力決定とNASTの基礎を参照してください。
帳票フォーム側の問題も切り分けます。Smart Formsを使用する処理ではフォーム名、言語、スタイル、プリンター設定、呼び出しプログラムの戻り値を確認します。フォームの構造やテスト方法はSmart Formsの基礎で扱っています。Adobe Formsでも、フォーム生成処理とスプール出力は別の工程としてログを確認します。
権限エラーが疑われる場合は、対象ユーザーの権限チェック結果と、実行時に表示されたメッセージを記録します。ユーザーに広い権限を追加する前に、処理に必要な権限オブジェクト、活動、対象組織値を確認し、最小限の変更で再テストします。
印刷されないスプールの調査
SP01でスプールを確認でき、プレビューも正常なのに印刷されない場合は、出力デバイスから先を調べます。最初に、対象スプールに指定された出力デバイスが業務上正しいか確認します。テスト用プリンター、停止中のデバイス、廃止済みの論理出力先が指定されていると、スプールは正常でも印刷されません。
次にSPADで出力デバイスの定義を確認します。デバイスの短い名称、出力先、アクセス方法、ホストプリンター、デバイスタイプ、接続先ホストを記録し、同じ用途の正常なデバイスと比較します。出力デバイスの登録と基本確認はSPADによる出力デバイス設定にまとめています。
調査では、次の順序で範囲を狭めます。
- SP01で出力デバイスが正しいか確認する
- 出力リクエストの状態とエラーテキストを確認する
- SPADでデバイスが有効か、接続情報が正しいか確認する
- SAPホスト上の印刷処理と関連ログを確認する
- 必要に応じてネットワーク、プリントサーバー、物理プリンターを確認する
SAP側で出力リクエストが保留されている場合は、エラーの発生箇所を特定してから再出力します。プリンター側だけが停止している場合は、同じ出力デバイスに対する小さなテスト出力で復旧を確認します。元の帳票を何度も再送すると二重印刷が発生するため、再出力前に既にプリンターへ送信されていないことを確認します。
スプールの再出力と削除
再出力は、元のスプールデータが完全であり、出力先と部数が正しいことを確認してから実行します。再出力前に、業務担当者へ二重印刷の可能性を伝え、必要なページ範囲や部数を確認します。請求書、納品書、会計帳票などは、再出力が業務上の正式な再発行に該当することがあるため、業務ルールに従います。
削除では、保持期間、監査要件、再出力の必要性を確認します。個別削除を急いで実行するより、システムで定めた保持方針と定期的な整理ジョブを使う方が運用しやすくなります。削除対象には、出力済みで再利用の必要がないもの、テスト出力、期限を過ぎた一時データを含めます。未出力、エラー、業務上保管が必要なスプールは対象から分けます。
大量のスプールが蓄積している場合は、削除前に件数、最古の作成日、作成ユーザー、出力状態、ディスク使用量を記録します。削除後にSP01の検索結果とシステムのファイル領域を確認し、期待した範囲だけが整理されたことを確認します。定期処理が失敗している場合は、ジョブログ、バリアント、実行ユーザー、権限、実行時間を調べます。
日常運用で見る監視ポイント
日常監視では、未出力スプールの件数、エラー状態の出力リクエスト、特定デバイスへの集中、急激な作成件数の増加を確認します。単純な件数だけで判断せず、通常日の傾向、月末や締め処理のピーク、業務上の大量出力予定を合わせて評価します。
監視項目には担当者と対応期限を設定します。たとえば、未出力が一定時間を超えたら出力デバイスを確認し、エラー状態ならエラーテキストとホスト側ログを保存します。同じエラーが繰り返される場合は、スプール番号、ユーザー、帳票名、出力デバイス、発生時刻、再現条件を一つの記録にまとめます。
出力管理全体では、フォーム生成、出力決定、スプール作成、出力デバイス、プリンターという工程を分けて監視します。どの工程で停止したかを記録できると、アプリケーション担当、SAP Basis担当、ネットワーク担当、プリンター管理担当の引き継ぎが明確になります。
トラブルシューティングの実務チェックリスト
障害受付時は、まず帳票名、実行ユーザー、実行日時、対象伝票、出力デバイス、期待する出力形式、画面またはジョブのメッセージを取得します。印刷されないという結果だけでは、スプール未作成、出力リクエスト停止、ホスト側エラー、プリンター停止を区別できません。
次の記録を残すと、再調査が容易になります。
- SP01の検索条件と対象スプール番号
- スプールのプレビュー結果
- 出力リクエストの状態とエラーテキスト
- SPADで確認した出力デバイス情報
- ジョブ名、ジョブ番号、ジョブログ
- SAP側とプリンター側で実施した再出力の時刻
- 再発防止のために変更した設定と承認者
設定変更後は、対象ユーザーと同じ条件でテストし、スプール作成、プレビュー、出力リクエスト、物理印刷までを確認します。変更前後の設定値を保存し、障害が解消しない場合に元の状態へ戻せるようにします。帳票の内容が正しいことと、出力が一度だけ行われたことを業務担当者にも確認してもらいます。
まとめ
SAPのスプール管理では、SP01でスプールの存在と内容を確認し、出力リクエスト、SPADの出力デバイス、ホスト側印刷処理の順に調査します。スプールがない場合は帳票生成、ジョブ、出力条件、権限を確認し、スプールがある場合は出力先と出力状態を確認します。
再出力と削除は、出力済みかどうか、業務上の保管要件、二重印刷の可能性を確認してから実施します。スプール番号、エラーテキスト、出力デバイス、発生時刻を記録する運用を定着させると、印刷トラブルの切り分けと担当間の連携を効率化できます。