MAS-162: 銀行CSV合算マッチング（複数STL→1明細）

概要

目的

まとめ振込（月額給与3ヶ月分、社保2件分等）で1つの銀行明細に複数STLが対応するケースを自動候補提案する。

実装済みの設計判断（2026-04-16 実装時の知見）

マッチング優先順位

重要: Pass 2（合算厳密）→ Pass 2.5（合算ソフト）→ Pass 3（単一候補）の順で実行する。理由: 合算は金額完全一致のため信頼度が高い。Pass 3 を先にすると、合算対象のSTLが個別に消費されてしまう。Pass 2.5 は Pass 2 で不成立だった場合のフォールバックで、口座振替割引等の少額差を救済する (PR #465 で追加)。

Pass 2.5 ソフト合算 (PR #465 追加)

契機

社会保険料 (厚年金 + 健保) の口座振替で、銀行引落額 149,950 円 と STL 合計 150,950 円 (74,575 + 76,375) が ちょうど 1,000 円 ずれて合算候補に提案されない事象を観測。口座振替割引と推測。Pass 2 (±1 円厳密) では救済不可だったため、Pass 2.5 として実装。

実装

findComboGroup_(candidates, txAmt, txType, txYm, tolerance) に許容誤差 tolerance (円) を引数化リファクタ。

UI 表示

注意事項

• 必ず Pass 2 の後に実行する: 厳密一致が優先。±1 円で合致するケースを Pass 2.5 が先取りしてはいけない。
• 差額の妥当性は人間判断: 1,000 円の差は口座振替割引で説明可能だが、5,000 円の差は調査要 (摘要欄不一致・別案件混入の可能性)。
• Pass 3 (単一候補) との優先順位: Pass 2.5 が候補を出した場合は Pass 3 をスキップ (combo 変数にヒット結果が残るため)。

取引先別グルーピング

全STLの合計ではなく、同一取引先内でグルーピングしてから合計を照合する。

理由: 異なる取引先のSTLが偶然合計一致する誤マッチを防止。

部分集合の探索方式

同一取引先の全件合計 ≠ 銀行金額のケースが頻出する（例: 4ヶ月分のSTLがあるが振込は3ヶ月分）。以下の3方式で順に探索:

1. 全件合計一致: 同一取引先の全STL合計が銀行金額と一致
2. 貪欲法: 日付昇順にSTLを1件ずつ加算し、ちょうど一致したら採用
3. 同一金額N件: 同一金額のSTLが N件あり、N × 単価 = 銀行金額 で件数マッチ

STLロック

合算マッチ成功時に candidates[ci].matched = true でロックする。これがないと次の銀行明細で同じSTLが再利用される。

処理順序のソート

銀行明細を勘定日の昇順で処理する。行の並び順ではなく内部的にソートし、書き込みは元の行番号に行う。

理由: 古い銀行明細が古いSTLに優先マッチし、日付的な整合性を維持。

Date オブジェクトのソート注意

STLの dueDate が Date オブジェクトの場合、String() でタイムゾーン付き文字列になりソート順が壊れる。Utils.parseDateToYm() で YYYY-MM 形式に統一してからソートすること。

エッジケース

関連ドキュメント

変更履歴