SAP出力・印刷管理
SAP Smart Forms 基礎：フォームペインタとドライバプログラムの実装・トラブルシューティング
SAP Smart Formsの構成、フォームペインタ、ドライバプログラム、出力制御、印刷トラブルの確認手順を実務向けに整理します。
SAP Smart Formsは、帳票のレイアウトとABAPによるデータ取得処理を分離して管理できるSAPの帳票出力技術です。請求書、納品書、発注書、ラベルなど、業務データを定型帳票として出力する場面で利用されます。実装では、フォーム側の定義だけでなく、ドライバプログラム、出力制御、印刷先、スプールの各層を分けて確認することが重要です。
この記事では、既存フォームの構造を読み解く手順、新規または変更時の基本的な作業、出力されない場合の切り分けを、SAP GUIを使う運用担当者とABAP開発者の両方が確認できる形でまとめます。
SAP Smart Formsの全体構成
Smart Formsの処理は、主に次の流れで構成されます。
- 業務トランザクションが出力対象データを確定する
- 出力制御がフォーム名、出力タイミング、出力先などを決定する
- ドライバプログラムが業務データを読み込み、フォームへ渡す
- フォームがページ、ウィンドウ、テキスト、テーブルを組み立てる
- スプールを経由して、指定した出力デバイスへ送信する
フォーム単体には、データベースから業務データを取得する処理を集中させません。帳票に必要なヘッダ、明細、金額、住所などをドライバプログラム側で準備し、生成された汎用関数モジュールを呼び出して渡す構成が基本です。
出力全体の位置関係を確認するときは、SAP出力・印刷管理の全体像も参照してください。Smart Formsだけでなく、出力制御、スプール、出力デバイスまで含めて調査できます。
フォームペインタで確認する項目
SAP GUIのトランザクションSMARTFORMSでフォーム名を指定すると、フォームペインタを開いて定義を確認できます。既存フォームを調査するときは、最初に次のノードを上から順に確認します。
- Global Settings：フォームインターフェース、グローバル定義、初期化処理
- Pages and Windows：ページ構成、メインウィンドウ、サブウィンドウ
- Program Lines：フォーム内で実行する補助的な処理
- Text：固定文言、テキストモジュール、変数の出力
- Template：固定行列のレイアウト
- Table：明細行、ヘッダ、フッタ、イベント処理
ページには、次ページへ継続するメインウィンドウと、ページごとに固定位置へ出力するサブウィンドウを配置します。明細が複数ページにまたがる帳票では、明細用のテーブルとメインウィンドウの関係を確認してください。住所や会社情報のように各ページで同じ位置へ出す内容は、通常サブウィンドウで管理します。
テキスト内の&変数名&形式の値は、フォームインターフェースやグローバル定義で利用可能な項目として準備します。値が空になる場合は、レイアウトではなく、インターフェースへの受け渡し、初期化、条件ノードの順に確認します。
フォームインターフェースとドライバプログラム
ドライバプログラムは、選択画面や出力制御から受け取ったキーを使い、帳票に必要なデータを取得します。その後、Smart Formsの関数モジュールを呼び出します。フォーム名から生成された関数モジュール名を直接固定記述せず、SSF_FUNCTION_MODULE_NAMEでフォーム名から関数モジュール名を取得する構成が一般的です。
処理の基本的な順序は次のとおりです。
- 出力対象の伝票番号や業務キーを受け取る
- ヘッダと明細のデータを読み込む
SSF_FUNCTION_MODULE_NAMEでフォームの関数モジュール名を取得する- フォームインターフェースに合わせてパラメータを渡す
- フォーム関数モジュールを呼び出す
- 戻り値のスプール情報や出力結果を処理する
フォームインターフェースを変更した場合は、呼び出し元のドライバプログラムも同時に確認します。構造の項目名、内部テーブルの行型、必須値、通貨や単位の扱いが一致していることが必要です。データが取得できていても、フォーム側のフィールドへ渡していなければ帳票には表示されません。
デバッグでは、フォーム呼び出し直前にヘッダと明細の内容を確認し、フォーム内の条件ノードへ進む値も確認します。ブレークポイントをドライバプログラムに置くと、データ取得とフォーム呼び出しを分離して調べられます。
出力制御とフォームの割り当て
Smart Formsが正しく有効化されていても、出力制御側で別のフォームが割り当てられていると、想定した帳票は生成されません。出力タイプ、アプリケーション、条件レコード、処理コード、印刷プログラム、フォーム名を一つの流れとして確認します。
出力制御の調査では、まず対象伝票に出力レコードが作成されているかを確認します。次に、処理ステータス、処理時刻、出力媒体、論理システムや出力デバイスを確認します。出力タイプの設定を確認する場合は、SAP出力決定（NAST）の基礎を参照すると、条件レコードから処理までの関係を整理できます。
フォーム名を変更した場合は、開発環境での有効化だけでなく、対象システムへの移送、出力タイプの割り当て、条件レコード、プリンタ設定まで確認します。変更が一部の伝票だけに反映されない場合は、組織、販売エリア、購買組織、出力媒体などの条件差を比較します。
印刷されない場合の切り分け
帳票が出力されないときは、フォームペインタだけを調べず、次の順序で層を分けて確認します。
- 対象伝票に出力レコードが存在するか
- 出力レコードが処理可能なステータスか
- ドライバプログラムが呼び出されているか
- フォーム関数モジュールが正常終了しているか
- スプールが作成されているか
- スプールの出力デバイスが正しいか
- 出力デバイスからプリンタまたは外部出力先へ送信されているか
スプールが存在する場合、フォーム生成までは進んでいる可能性が高いため、出力デバイス、アクセス方法、ホストスプーラ、プリンタ側の状態を調べます。スプールがない場合は、出力制御、処理プログラム、権限、フォーム呼び出しの例外を確認します。
スプール番号が分かる場合は、出力要求の属性、ページ数、作成者、出力デバイス、ステータスを記録します。SAPスプール管理の基礎では、スプールと出力要求を分けた確認手順を整理しています。
フォームレイアウトの不具合
文字切れ、改ページ、重複表示、空白ページなどのレイアウト不具合は、ウィンドウの種類、ページ条件、テーブルイベント、段落書式を順番に調べます。
明細の末尾が次ページへ正しく送られない場合は、メインウィンドウ内のテーブル処理とページ継続設定を確認します。固定位置のサブウィンドウに大量の明細を配置すると、領域不足や重なりが起きやすいため、繰り返し行はテーブルとメインウィンドウで設計します。
文字化けや記号の崩れがある場合は、出力形式、デバイスタイプ、フォント、コードページ、プリンタ側の設定を確認します。画面上のプレビューが正常でも、実プリンタへの出力で問題が出る場合は、フォーム定義だけでなく出力デバイス設定も対象にします。出力デバイスの設定は、SAP出力デバイス設定（SPAD）の基礎で確認できます。
Smart Forms変更時の運用手順
変更前に、対象フォーム、ドライバプログラム、出力タイプ、利用する出力デバイス、代表的なテスト伝票を一覧化します。フォームだけを変更する場合でも、インターフェース、条件ノード、テキストモジュール、ページ構成への影響を確認します。
実装後は、次のテストを分けて実施します。
- 明細が1行の帳票
- 複数ページになる帳票
- 条件により任意項目が空になる帳票
- 長い品名や住所を含む帳票
- 通貨、数量、単位、小数桁を含む帳票
- 画面プレビューと実プリンタ出力
- 再処理した出力と新規作成した出力
テスト結果には、伝票番号、出力タイプ、フォーム名、スプール番号、出力デバイス、実行日時を記録します。これらを残すと、開発環境と本番環境の差分や、出力制御とプリンタ設定のどの層で問題が発生したかを追跡しやすくなります。
フォーム名、テキストモジュール、スタイル、ドライバプログラムは、変更管理の単位を分けて記録します。移送後はフォームの有効化、生成処理、出力タイプの割り当て、条件レコード、出力デバイスを順に確認します。
Smart FormsとAdobe Formsの使い分け
既存のSAP ERP帳票を保守する現場では、Smart Formsの資産を継続利用する場面があります。一方、複雑なPDFフォーム、電子署名、可変レイアウト、外部データとの連携などが要件になる場合は、別のフォーム技術を検討します。
判断では、既存フォームの量、現在のドライバプログラム、帳票の出力形式、プリンタ要件、保守担当者のスキル、移行テストの範囲を確認します。技術名だけで選択せず、出力媒体と運用監視まで含めて比較してください。SAP Smart FormsとAdobe Formsの比較では、設計と運用の観点を並べて整理しています。
Smart Formsの基本操作を理解するには、フォームペインタ、フォームインターフェース、ドライバプログラム、出力制御、スプールを別々の責任範囲として捉えることが有効です。障害発生時も、この境界に沿って確認すると原因箇所を絞り込めます。