領収書マッチング・立替精算消込 — 35_wrk_receipt

1. 概要

焦点質問: 領収書PDFからの自動読取と立替精算STLの消込はどう動作するか？

背景・課題

立替精算の領収書・請求書は紙やPDFで届くため、手動で金額・取引先を転記しSTLと紐づける作業が煩雑だった。Gemini APIによるPDF自動解析と33_wrk_bankの立替精算STLとの自動マッチングにより、帳票との紐づけを半自動化する。

処理フロー（マトリクス）

脚注:

• ※1: 領収書消込はクレカ消込と異なり、決済ステータスを自動で消込済にしない。立替精算は実際の立替者への振込（別のタイミング）が必要なため

2. 設計判断

→ 詳細: ADR-0007 Gemini APIを領収書解析に使用する判断

3. 変更内容

3.1 スキーマ (35_wrk_receipt タブレイアウト)

データ列 (A〜R列)

GAS管理列 (マッチ結果: S〜Y列)

33_wrk_bank「立替日」列

33_wrk_bank の E列 (決済日の左隣) に「立替日」を追加。

receipt消込実行時に立替日をセット。決済日は会社精算時に手動入力。

3.2 ロジック

3.2.1 領収書PDF読み込み (Gemini API) — importReceiptPdfs()

スクリプトプロパティ:

処理ロジック:

Geminiプロンプトの主要指示:

JSON応答パース:

後処理: 同一取引先の突合補正 (postProcessReceiptData_):

全PDF読み込み後、同一取引先名のレコードを多数決で補正:

• T番号: 2件以上一致する値で少数派を上書き
• 住所: 空欄を多数派の値で補完 (空欄→多数派値のみ。既存値は変更しない)

エラーハンドリング:

3.2.2 マッチング確認 — importReceiptStatement()

マッチング対象 STL (33_wrk_bank):

マッチ成立条件 (全てAND):

マッチング優先度 (同一金額・取引先の場合):

同額・同取引先の月次SaaS で正しい月の STL を選ぶために、摘要の YYYY-MM利用分 と receipt の発生日年月を照合。

UNMATCHED時の候補表示:

マッチ不成立の場合、緩和条件で候補STLを提示する:

候補がある場合: マッチ決済ID(STL)に 候補:STL_XXXX を表示。

行の背景色:

スキップ条件 (マッチング確認):

3.2.3 消込実行 — applyReceiptSettlement()

スキップ条件 (消込実行):

33タブ更新 (STL_IDごとに合算):

同一STL_IDに対して複数の領収書がある場合、金額を合算して処理する。

35タブ更新:

ユーザーが内容確認後に手動で「消込済」に変更 → Action B で仕訳作成

3.2.4 未登録領収書→26タブ登録 — transferReceiptToAdhoc()

35タブで処理結果=「未登録」の領収書を26_bud_adhocに費用登録する機能。

フィールドマッピング:

決済手段マッピング:

重複防止: 35タブの処理結果を「26タブ登録済」に更新 (背景色 #D9D2E9 薄紫)。再実行しても重複しない。

科目名・PJ名: 空欄のまま登録。ユーザーが26タブで後入力し、「📥 単発予算の自動起票」でINV生成。

3.3 UI (メニュー)

🔍 消込・マッチング
  ├─ 💳 クレカ明細マッチング確認
  ├─ 💳 クレカ消込実行 (確認FLG=TRUE)
  ├─ ───
  ├─ 📄 領収書PDFの読み込み (Drive)
  ├─ 🧾 領収書マッチング確認
  └─ 🧾 領収書消込実行 (確認FLG=TRUE)

📝 費用登録
  └─ 📥 未登録領収書→26タブ登録

4. 影響範囲

§4 詳細関数: 502 = importReceiptPdfs / callGeminiForReceipt_ / postProcessReceiptData_、501 = importReceiptStatement / applyReceiptSettlement / transferReceiptToAdhoc

5. テスト仕様

付録

付録A: 改修ファイル一覧

付録B: ADR

• ADR-0007: Gemini APIを領収書解析に使用する判断