AS400 / IBM i の月次締めや請求締めが終わらない時は、通常の画面エラーより慎重に見ます。締め処理は再実行や戻しの影響が大きく、二重請求、二重更新、後続帳票の不整合につながることがあるためです。
最初に行う確認
| 確認 | 見るもの | 判断 |
|---|---|---|
| 締めジョブの状態 | WRKACTJOB / WRKJOB | 実行中、MSGW、異常終了 |
| 原因メッセージ | DSPJOBLOG | CPF/RNX/MCH/MSGWを分ける |
| 後続処理 | 対象ジョブ、ジョブ待ち行列、実行・送信履歴 | 帳票や連携が動いたか。SBMJOBは投入操作なので確認のために実行しない |
| 更新済みデータ | 対象ファイル、帳票、スプール | 途中まで更新済みか |
| 再実行可否 | 運用手順、業務担当者 | 勝手に再投入してよいか |
再実行前に必ず見ること
請求締めや月次締めは、エラーを消して再実行すればよいとは限りません。すでに一部の請求データ、売上データ、帳票、外部連携ファイルが作成されている場合、再実行で二重処理になる可能性があります。ジョブログと更新済みデータを確認してから判断します。
システム上の終了と業務上の締め完了を分ける
締めジョブが正常終了していても、月次締めや請求締めが業務上完了したとは限りません。帳票が作成された、連携ファイルが送信された、後続システムで受け付けられた、担当部門が件数と金額を確認した、という段階を分けて確認します。
| 確認段階 | 技術側の証跡 | 業務側の確認 |
|---|---|---|
| 締め処理 | ジョブ終了コード、ジョブログ、更新件数 | 対象年月・会社・部門の範囲が正しい |
| 帳票作成 | スプール、出力ファイル、作成時刻 | 請求書や一覧表の件数・合計が合う |
| 外部連携 | 送信ジョブ、送信ファイル、応答ログ | 相手側や後続システムで受信済み |
| 完了判定 | 後続ジョブまで正常終了 | 業務担当者が締め完了を承認 |
再実行を判断する前に残す記録
- 対象年月、会社・部門、処理範囲
- 正常終了した工程と、未完了の工程
- 更新件数、作成帳票、連携ファイルの有無
- 再実行で二重になる可能性があるデータ
- 再開位置、戻し方法、確認担当者と承認者
この記録がそろっていない時は、エラーだけ直して締め処理を最初から再投入しない方が安全です。技術担当者と業務担当者が同じ事実を見て、どこから再開するかを決めます。
締め処理で現場が荒れやすい判断
月次締めや請求締めは、技術的にはジョブやMSGW（メッセージ待ち）の問題に見えても、実際には運用判断で止まることが多いです。前工程のEDI、出荷確定、売上計上、返品、請求対象の確定が終わっているかを見ずに再実行すると、請求漏れや二重計上につながります。
| 判断 | 確認すること | 止める理由 |
|---|---|---|
| 後続ジョブを流してよいか | MSGW、ジョブログ、前工程の完了状態 | 未完了データを締め対象から落とさないため |
| 再実行してよいか | 処理済み区分、ワークファイル、更新件数 | 二重計上や二重請求を防ぐため |
| 業務部門へ連絡するか | 対象得意先、締め日、請求書、EDI影響 | 技術判断だけで締めを進めないため |
| 翌営業日に回すか | 請求発行、出荷、会計連携、相手先締め | 現場影響と復旧時間を比べるため |
| 戻しが必要か | バックアップ、ジャーナル、訂正伝票、赤伝 | 締め後訂正の手戻りを減らすため |
売上集計後に月次締めが止まる想定例
月次締めが途中で止まった時は、最初から全工程を再実行せず、最後に成功したステップと更新済み範囲を確認します。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| 停止点 | ジョブ名、ステップ、メッセージID、発生時刻、最後の正常処理を確認する | 最後のメッセージだけで原因を決めない |
| 更新範囲 | 対象期間、処理済み伝票、集計、帳票、外部連携の状態を確認する | 再実行で重複する範囲を明確にする |
| 再開 | 再実行可能な入口、退避・戻し、承認、後続確認を決める | 締め全体を無条件に最初から流さない |
復旧後は対象月の合計だけでなく、前月繰越、税、売掛、帳票、会計連携を照合します。暫定対応で変えたデータや設定は、戻し要否を記録します。
業務担当者への聞き方
締め処理では「直します」だけでは足りません。今どの締めが止まっているか、出荷や請求に影響するか、何時までに終わらないと困るか、再実行や戻しの承認者は誰かを確認します。ここで業務を理解せずに作業すると、技術的には復旧しても業務上は事故になります。
業務理解が必要な理由は、AS400保守で業務理解がないと設計できない理由にもまとめています。
締め後修正は、SQLの前に業務影響と戻し方を決める
請求締め、在庫締め、会計連携後のデータ修正は、単に対象レコードを直せば終わる作業ではありません。請求書、売上、在庫、EDI、会計仕訳、取引先への連絡がすでに動いている場合、1項目だけ直しても後続処理との整合が崩れることがあります。SQLで更新する前に、どの業務へ影響するか、再締めが必要か、帳票や連携データを作り直すかを先に承認します。
対象期間にジャーナル処理され、必要なレシーバーが残っていれば、DSPJRNで記録された変更を確認できます。更新前の値を復元材料にするには、更新前イメージが取得・保持されている必要があります。ジャーナル設定があるだけでは確認できるとは限りません。ただし、締め後修正では「データを戻せるか」だけでなく「戻した後にリランしてよいか」「相手先へ再送してよいか」「会計側の数字と合うか」まで確認します。現場で揉めるのは、技術的な更新方法よりも、誰が承認した修正なのかが曖昧な時です。
| 修正前に決めること | 確認する理由 | 関連ページ |
|---|---|---|
| UPDATE承認 | 対象ライブラリ・件数・WHERE条件を声に出して確認する | 本番SQL更新の承認フロー |
| 更新前データ | DSPJRNや退避ファイルで戻し材料を残す | AS400ジャーナル確認手順 |
| 復旧方針 | 戻す、作り直す、リランするのどれかを分ける | AS400データ復旧 |
| 請求差異 | 締め後修正が請求金額へ波及しないかを見る | AS400販売管理システム保守ガイド｜受注・出荷・在庫・売上・請求で見るポイント |
締め後に1伝票を直す時の判断例
請求締め後に単価誤りが見つかった場合、対象行だけを直しても会計連携や請求書と不一致になる可能性があります。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| 影響確認 | 請求書、売掛、税計算、会計連携、再発行の状態を確認する | どこまで確定済みかを業務責任者が判断する |
| 変更承認 | 修正対象キー、修正前後値、実施SQLや画面操作をレビューする | 実施者と承認者を分ける |
| 事後照合 | 対象伝票と期間合計を再計算し外部連携結果も確認する | 1件の表示だけで正常と判断しない |
戻しが必要になった時に備え、修正前データ、更新件数、実行時刻、再計算結果を同じ記録に残します。締め処理の再実行可否は技術担当だけで決めません。
締めのたびに手作業が発生する作りは、改修の判断材料になります。AS400リプレースは必要か｜IBMiを使い続ける判断と長期ロードマップで、業務・費用・保守体制を含めて継続、改修、移行を比較する観点を整理しています。