入金消込マクロが止まるとき｜取得・照合・更新・通知の確認表
Excelの入金消込マクロが、直してもまた止まる。消し込めるはずの入金が残ったときは、全件をすぐに再実行せず、止まった回の記録から一件を追います。確認するのは、データの取得、注文との照合、注文の入金状態の更新、通知の送信です。
途中で止まっても、注文の更新までは終わっていることがあります。どこまで完了したかが分かれば、調査する箇所と、やり直してよい処理を絞れます。
止まった回の入力とログを残す
マクロを再び動かす前に、その回で使った入金明細と注文一覧、処理ログ、エラー画面を上書きされない場所へ保存します。実行した時刻と、使ったマクロのファイル名・版も添えておきます。最新の明細で置き換えると、止まったときの入力を確かめられなくなります。
その中から、消し込めるはずなのに残っている入金を一件選び、対応する注文の候補を探します。入金は明細の取引番号、注文は注文IDで区別します。明細に取引番号がなければ、保存した元ファイルと該当行を控えます。金額や振込名義だけでは、別の取引と見分けられない場合があります。
残っている記録で、止まった箇所を絞る
保存した入力とログを、注文の管理画面や通知履歴と照らし合わせます。記録がない処理は、未実行と決めずに結果不明として扱います。
| 見えている症状 | 照らし合わせる記録 | 次に調べること |
|---|---|---|
| 対象の入金・注文が入力にない | 元の明細・注文一覧と、マクロの入力ファイル。対象期間、件数、該当行 | 元データにもないのか、取得・取り込みの途中で抜けたのかを分ける |
| 入金はあるが、注文を一つに特定できない | 入金の取引番号・名義・金額と、候補の注文ID・支払予定 | 識別情報の不足、表記の差、複数候補のどれが残っているかを調べる |
| 対応する注文は決まったが、未入金のまま | 照合結果の注文ID、更新ログ、管理画面を再表示した結果 | 更新先の注文IDと保存後の状態を確認し、ログとのずれを調べる |
| 注文は入金済みだが、通知できたか分からない | 注文IDと更新履歴、通知の送信履歴・エラー記録 | 同じ注文の通知が送信済みか未送信かを別に確かめる。不明なら保留する |
照合できないことは、顧客の未払いの証拠にはなりません。金額の過不足や手数料差額、同名の複数候補も、自動で補正・確定せず、人が確認する対象に残します。
同じ金額の注文が二つある場合
以下は説明用の架空例です。処理前には、次の記録があるとします。
- 注文 EX-O101：12,000円。入金予定。
- 注文 EX-O102：12,000円。入金予定。
- 入金 EX-P501：12,000円。担当者の確認記録で、EX-O101への支払いと特定済み。
EX-P501は入金を、EX-O101とEX-O102は注文を区別する番号です。同額の注文があるため、12,000円で検索して先頭の行を更新する方法では対象を決められません。確認できた注文IDを、照合結果から更新先まで引き継ぎます。
この入金の処理中にマクロが止まり、管理画面ではEX-O101が入金済みで、EX-P501との対応も保存されていたとします。一方、通知の送信履歴を確認できません。
この場合に残す結果は「EX-O101の更新は完了、通知は不明」です。更新をやり直したり、不明な通知を未送信として送り直したりはしません。EX-O102についても、この入金を理由に状態を変える根拠はありません。
不具合がある部分に絞って直し方を選ぶ
列の位置や日付形式の違いで対象行を読めていないと確認できたなら、入力形式をそろえるか、VBAの読み取り部分に絞って修正を依頼します。照合に必要な情報が足りない場合は、番号や確認方法を先に整理します。
銀行明細を取得する段階だけで失敗しているなら、明細の取得サービスや取り込み方法の変更を比較します。取得手段を変えても、注文の照合や更新の不具合は別に残ります。画面操作を自動化するRPAも、同じ画面や入力条件に依存するなら、置き換えるだけで安定するとは限りません。
照合条件や更新方法を既存システムの標準機能・入金消込の専用サービスで扱えるなら、同じ失敗例で試す方法もあります。固有の注文更新や通知処理に問題が残る場合は、その部分の修正・再開発を検討します。最初から全体を作り直す前提にせず、確認できた不具合に合わせて範囲を決めます。
修正担当に渡す資料と、再実行前の確認
修正担当には、一件の入金から注文の結果まで追える資料を渡します。氏名や口座番号などは仮の値に置き換え、同じものには同じ値を使って対応関係を残します。
- 止まった回の代表的な入力と、期待する注文ID・更新結果・通知内容
- 実際の結果、エラー内容、該当するログ
- 更新と通知それぞれの「完了確認済み／結果不明／未処理確認済み」
- 今回直す範囲と、修正後に確認する動き
動作確認は入力のコピーを使い、銀行への接続、本番の注文更新、実際のメール送信を行わないテスト環境で実施します。通知は、送信予定を残すテスト用の記録で確かめます。
1回目は、未処理と確認できた更新・通知だけを対象にし、注文の更新結果と通知予定が期待どおり一度だけ記録されることを確かめます。2回目は完了状態を残して同じ入力を使い、完了済みの更新や通知予定が追加されないことを確認します。結果不明の処理は、どちらの回も保留のままにします。
再実行の対象は、更新・通知のそれぞれで未処理と確認できたものだけに絞ります。結果不明は人が確認するまで保留し、完了済みの処理が繰り返されないと確かめられない間は、再実行しません。