AS400月次締め・請求締めが終わらない時の確認手順｜夜間バッチ・ジョブログ・再実行判断

AS400 / IBM i の月次締めや請求締めが終わらない時は、通常の画面エラーより慎重に見ます。締め処理は再実行や戻しの影響が大きく、二重請求、二重更新、後続帳票の不整合につながることがあるためです。

最初に行う確認
再実行前に必ず見ること
夜間バッチと業務影響を分ける
システム上の終了と業務上の締め完了を分ける
再実行を判断する前に残す記録
Codexで調査メモを作る時
締め処理で現場が荒れやすい判断
締めトラブルで残す連絡メモ
売上集計後に月次締めが止まる想定例
業務担当者への聞き方
締め処理トラブルは、再実行より先に運用状態を確認する
SQLで直す前に止まる
締め後修正は、SQLの前に業務影響と戻し方を決める
締め後に1伝票を直す時の判断例
月次締め・請求締めとあわせて確認したい手順

最初に行う確認

確認	見るもの	判断
締めジョブの状態	WRKACTJOB / WRKJOB	実行中、MSGW、異常終了
原因メッセージ	DSPJOBLOG	CPF/RNX/MCH/MSGWを分ける
後続処理	対象ジョブ、ジョブ待ち行列、実行・送信履歴	帳票や連携が動いたか。SBMJOBは投入操作なので確認のために実行しない
更新済みデータ	対象ファイル、帳票、スプール	途中まで更新済みか
再実行可否	運用手順、業務担当者	勝手に再投入してよいか

再実行前に必ず見ること

請求締めや月次締めは、エラーを消して再実行すればよいとは限りません。すでに一部の請求データ、売上データ、帳票、外部連携ファイルが作成されている場合、再実行で二重処理になる可能性があります。ジョブログと更新済みデータを確認してから判断します。

夜間バッチと業務影響を分ける

月次締めは夜間バッチに組み込まれていることも多いため、止まったジョブだけでなく、後続ジョブや帳票出力も確認します。夜間バッチ全体の見方はAS400夜間バッチ障害対応フロー、本番初動はAS400本番障害の初動チェックリストに整理しています。

システム上の終了と業務上の締め完了を分ける

締めジョブが正常終了していても、月次締めや請求締めが業務上完了したとは限りません。帳票が作成された、連携ファイルが送信された、後続システムで受け付けられた、担当部門が件数と金額を確認した、という段階を分けて確認します。

確認段階	技術側の証跡	業務側の確認
締め処理	ジョブ終了コード、ジョブログ、更新件数	対象年月・会社・部門の範囲が正しい
帳票作成	スプール、出力ファイル、作成時刻	請求書や一覧表の件数・合計が合う
外部連携	送信ジョブ、送信ファイル、応答ログ	相手側や後続システムで受信済み
完了判定	後続ジョブまで正常終了	業務担当者が締め完了を承認

再実行を判断する前に残す記録

対象年月、会社・部門、処理範囲
正常終了した工程と、未完了の工程
更新件数、作成帳票、連携ファイルの有無
再実行で二重になる可能性があるデータ
再開位置、戻し方法、確認担当者と承認者

この記録がそろっていない時は、エラーだけ直して締め処理を最初から再投入しない方が安全です。技術担当者と業務担当者が同じ事実を見て、どこから再開するかを決めます。

Codexで調査メモを作る時

Codexには、匿名化したジョブログ、締め処理名、後続ジョブ、確認済みファイルを渡すと、再実行前の確認観点を整理しやすくなります。本番データや取引先名は伏せ、判断は人が行います。

締め処理で現場が荒れやすい判断

月次締めや請求締めは、技術的にはジョブやMSGW（メッセージ応答待ち）の問題に見えても、実際には運用判断で止まることが多いです。前工程のEDI、出荷確定、売上計上、返品、請求対象の確定が終わっているかを見ずに再実行すると、請求漏れや二重計上につながります。

判断	確認すること	止める理由
後続ジョブを流してよいか	MSGW、ジョブログ、前工程の完了状態	未完了データを締め対象から落とさないため
再実行してよいか	処理済み区分、ワークファイル、更新件数	二重計上や二重請求を防ぐため
業務部門へ連絡するか	対象得意先、締め日、請求書、EDI影響	技術判断だけで締めを進めないため
翌営業日に回すか	請求発行、出荷、会計連携、相手先締め	現場影響と復旧時間を比べるため
戻しが必要か	バックアップ、ジャーナル、訂正伝票、赤伝	締め後訂正の手戻りを減らすため

締めトラブルで残す連絡メモ

止まったジョブ名、時刻、MSGW/ジョブログの内容
締め対象日、対象得意先、対象会社、対象部門
前工程のEDI、出荷、売上、返品、請求の完了状態
再実行した場合の更新件数と二重処理リスク
業務担当者、承認者、相手先連絡の有無

売上集計後に月次締めが止まる想定例

月次締めが途中で止まった時は、最初から全工程を再実行せず、最後に成功したステップと更新済み範囲を確認します。

確認点	確認内容	判断
停止点	ジョブ名、ステップ、メッセージID、発生時刻、最後の正常処理を確認する	最後のメッセージだけで原因を決めない
更新範囲	対象期間、処理済み伝票、集計、帳票、外部連携の状態を確認する	再実行で重複する範囲を明確にする
再開	再実行可能な入口、退避・戻し、承認、後続確認を決める	締め全体を無条件に最初から流さない

復旧後は対象月の合計だけでなく、前月繰越、税、売掛、帳票、会計連携を照合します。暫定対応で変えたデータや設定は、戻し要否を記録します。

業務担当者への聞き方

締め処理では「直します」だけでは足りません。今どの締めが止まっているか、出荷や請求に影響するか、何時までに終わらないと困るか、再実行や戻しの承認者は誰かを確認します。ここで業務を理解せずに作業すると、技術的には復旧しても業務上は事故になります。

業務理解が必要な理由は、AS400保守で業務理解がないと設計できない理由にもまとめています。

締め処理トラブルは、再実行より先に運用状態を確認する

締め系のトラブルは、プログラムだけでなく運用絡みで起きることが多いです。誰がどこまで処理したか、締め前データに戻せるか、後続の請求・在庫・売上に影響するかを確認せずに再実行すると、二重計上や不整合を作る可能性があります。

締め処理の実行者、実行時刻、完了状態を確認する
ジョブログと帳票・画面上の結果を突き合わせる
再実行は業務責任者の承認後に行う
締め後データ修正の承認フロー
本番SQL更新の承認フロー

締め処理では、再実行できるかどうかだけでなく、売上、請求、在庫、EDIへの業務影響を確認してから判断します。

SQLで直す前に止まる

締め後データをSQLで直すと、画面上は合っても、締め履歴、連携済みデータ、帳票、監査証跡が合わなくなることがあります。作業者、承認者、対象件数、更新前後の値、戻し手順を残してから進めます。

締めトラブルの初動は、AS400締め処理トラブルの現場ランブックも確認してください。

締め後修正は、SQLの前に業務影響と戻し方を決める

請求締め、在庫締め、会計連携後のデータ修正は、単に対象レコードを直せば終わる作業ではありません。請求書、売上、在庫、EDI、会計仕訳、取引先への連絡がすでに動いている場合、1項目だけ直しても後続処理との整合が崩れることがあります。SQLで更新する前に、どの業務へ影響するか、再締めが必要か、帳票や連携データを作り直すかを先に承認します。

ジャーナルが設定されているファイルであれば、DSPJRN で更新前後を確認し、更新前レコードを復元材料として使える場合があります。ただし、締め後修正では「データを戻せるか」だけでなく「戻した後にリランしてよいか」「相手先へ再送してよいか」「会計側の数字と合うか」まで確認します。現場で揉めるのは、技術的な更新方法よりも、誰が承認した修正なのかが曖昧な時です。

修正前に決めること	確認する理由	関連ページ
UPDATE承認	対象ライブラリ・件数・WHERE条件を声に出して確認する	本番SQL更新の承認フロー
更新前データ	DSPJRNや退避ファイルで戻し材料を残す	AS400ジャーナル確認手順
復旧方針	戻す、作り直す、リランするのどれかを分ける	AS400データ復旧
請求差異	締め後修正が請求金額へ波及しないかを見る	AS400販売管理システム保守ガイド｜受注・出荷・在庫・売上・請求で見るポイント

締め後に1伝票を直す時の判断例

請求締め後に単価誤りが見つかった場合、対象行だけを直しても会計連携や請求書と不一致になる可能性があります。

確認点	確認内容	判断
影響確認	請求書、売掛、税計算、会計連携、再発行の状態を確認する	どこまで確定済みかを業務責任者が判断する
変更承認	修正対象キー、修正前後値、実施SQLや画面操作をレビューする	実施者と承認者を分ける
事後照合	対象伝票と期間合計を再計算し外部連携結果も確認する	1件の表示だけで正常と判断しない

戻しが必要になった時に備え、修正前データ、更新件数、実行時刻、再計算結果を同じ記録に残します。締め処理の再実行可否は技術担当だけで決めません。

締めのたびに手作業が発生する作りは、改修の判断材料になります。AS400リプレースは必要か｜IBMiを使い続ける判断と長期ロードマップに、その手間を年間の費用として説明する考え方を書いています。