AS400 / IBM iの現場で、今でも相談が多いのが締め系トラブルです。請求締め、月次締め、売上締め、在庫締めは、単にジョブが終わればよい処理ではありません。後続の請求、出荷、在庫、会計連携に影響するため、技術対応だけで進めると現場が荒れます。
この記事では、締め処理が止まった時に、保守担当者が落ち着いて確認するための現場ランブックをまとめます。
最初に確認すること
| 確認 | 見る理由 | メモ |
|---|---|---|
| どの締めか | 請求締め、月次締め、在庫締めで影響が違う | 画面名、ジョブ名、処理日を残す |
| どこで止まったか | 前処理、本処理、後続連携で対応が変わる | ジョブログとMSGWを見る |
| 再実行してよいか | 二重計上や二重送信を避ける | 業務担当者の承認を取る |
| 戻せるか | 締め後データを手で直すと危ない | バックアップ、再締め、取消手順を確認 |
| 外部連携済みか | EDIや会計連携後は社外影響が出る | 送信履歴と相手先受信状況を見る |
現場で荒れやすい判断
- エラーだけ直して再実行してよいか
- 締め済みデータをSQLで修正してよいか
- 請求書やPDFが出た後に再締めしてよいか
- EDI送信済みのデータを再送してよいか
- 業務担当者へどこまで説明してから作業するか
業務担当者への聞き方
締め処理では「直します」だけでは足りません。今どの締めが止まっているか、出荷や請求に影響するか、何時までに終わらないと困るか、再実行や戻しの承認者は誰かを確認します。ここで業務を理解せずに作業すると、技術的には復旧しても業務上は事故になります。
業務理解が必要な理由は、AS400保守で業務理解がないと設計できない理由にもまとめています。
まとめ
AS400の締め処理トラブルでは、ジョブログ、MSGW、再実行、戻し判断、業務承認をセットで確認します。締めは運用絡みの相談が多いため、コマンド操作よりも現場との確認順が重要です。
締め処理トラブルは、再実行より先に運用状態を確認する
締め系のトラブルは、プログラムだけでなく運用絡みで起きることが多いです。誰がどこまで処理したか、締め前データに戻せるか、後続の請求・在庫・売上に影響するかを確認せずに再実行すると、二重計上や不整合を作る可能性があります。
- 締め処理の実行者、実行時刻、完了状態を確認する
- ジョブログと帳票・画面上の結果を突き合わせる
- 再実行は業務責任者の承認後に行う
- 締め後データ修正の承認フロー
- 本番SQL更新の承認フロー
締め処理では、再実行できるかどうかだけでなく、売上、請求、在庫、EDIへの業務影響を確認してから判断します。
