納品書の控えと受領書の未回収を追って、督促と保管までを回す

処理の起点を決める

Apps Script の時間主導型トリガーで、毎営業日に複数回動かします。 時間主導型トリガーは1分ごとから月1回までの頻度で設定できます。ここでは1時間ごとに動かし、フォルダに新しいPDFがあれば処理します。

トリガーの開始時刻が正確でないことに注意してください。 9時のトリガーを作ると、Apps Script は9時から10時の間の時刻を選びます。「スキャンした直後に処理される」形にはなりません。

これはこの業務では問題になりません。受領書の処理は数時間遅れても実害がないためです。むしろ、まとめて処理するほうが効率がよくなります。

未回収の一覧は、別のトリガーで毎朝1回作ります。

入力データを集める

取引先マスタに「回収方法」の欄を作ってください。 ドライバー持ち帰り、郵送、FAX、電子で、督促のタイミングも文面も変わります。電子で受領している取引先に紙の督促を送ると、信用を落とします。

データの取得方法を決める

スキャン： 複合機でまとめてスキャンし、1つのPDFとして保存します。1日分を1ファイルにしてかまいません。 分割は後段で行います。

OCR： Azure AI Document Intelligence の prebuilt-layout モデルにページを渡します。このモデルは、段落・行・単語・表・選択マークなどの構造要素を抽出します。対応するファイル形式はPDFのほか、JPEG/JPG、PNG、BMP、TIFF、HEIF の画像です。

押印の判定： レイアウトモデルは選択マークを抽出し、境界の polygon、confidence、選択の state（selected / unselected）を返します。押印欄をチェックボックスとして扱えるとは限らないので、この構成では押印欄の領域に何かが書かれているかを、抽出された単語や図形の位置で判定します。選択マークが取れる様式なら、それを使います。

手書きの受領日： レイアウトモデルは、各テキスト行が手書きスタイルかどうかを信頼度スコア付きで返します（styles の isHandwritten）。手書きと判定された行は、読み取りの精度が落ちる前提で扱います。

AIへ渡す前に整形する

1. ページの分割 … 1日分のPDFを1ページずつに分ける。1枚の受領書が1ページであることを前提にします
2. 向きの補正 … スキャンで上下逆になることがあります。レイアウトモデルはページごとに向きの角度を返すので、それを使って補正します
3. 画像サイズの確認 … Document Intelligence が扱える画像サイズは50×50ピクセルから10,000×10,000ピクセルの間です。複合機の既定の解像度で問題になることはまずありませんが、確認しておきます
4. 読み取り領域の限定 … 伝票番号と受領日と押印欄の位置は固定なので、その領域だけを見ます。全文を読む必要はありません
5. 白紙・重複の除去 … スキャンで白紙が混ざることがあります。文字が1つも検出されないページは除きます

4番目が精度を大きく上げます。 全文から「それらしい番号」を探すより、決まった位置の文字列を読むほうがずっと確実です。

AIに処理させる

OCRとAIと自前の処理で役割を分けます。

OCR（Document Intelligence）にさせること： 文字の読み取り、手書きかどうかの判定、選択マークの検出、ページの向きの検出。

自前の処理にさせること： 伝票番号での突き合わせ、未回収の抽出、督促のタイミングの判定。照合は文字列の一致であって判断ではありません。

AIにさせること：

AIに伝票番号を推測させません。 「7かもしれないし1かもしれない」という状態で確定させると、別の出荷に受領書が紐づきます。候補を挙げさせ、選ぶのは人です。

指示内容を固定する

あなたは出荷事務を支援する立場です。
OCRで読み取った受領書の情報を確認し、受領日を標準形式に直してください。

【厳守事項】
- 伝票番号を推測で確定しないでください。
  OCRが読み取れなかった桁がある場合は、slip_number を null にし、
  読み取れた部分を partial_number に入れてください。
- 受領日は、和暦・西暦・月日のみのいずれで書かれていても
  YYYY-MM-DD に直してください。年の記載がない場合は
  year_missing を true にし、年を補わないでください。
- 押印欄については、見えているものを observation に書いてください。
  「押印あり」と断定せず、何が見えるか（丸い印影、角印、サイン、空欄、
  かすれた印影）を書いてください。
- 受領日が未来の日付、または出荷日より前の日付になる場合は、
  date_anomaly を true にしてください。
- OCRの結果にない文字を補わないでください。

【OCRの読み取り結果】
{ocr_result}

【この伝票の出荷日】
{ship_date}

「年を補わない」の指示が必要です。 受領書には「9/3」としか書かれていないことがあります。出荷日から推測できそうに見えますが、年末年始をまたぐと誤ります。 年が書かれていない場合は、出荷日から機械的に補うルールを別に決め、そのルールで補ったことを記録します。

「押印あり」と断定させないことも重要です。 かすれた印影を「あり」と判定すると、後から受領の証明ができません。見えているものを書かせ、判断は人がします。

出力形式を固定する

{
  "page_no": 0,
  "slip_number": null,
  "partial_number": "",
  "number_candidates": [],
  "received_date": null,
  "year_missing": false,
  "date_anomaly": false,
  "stamp": {
    "observation": "",
    "present": "yes | no | unclear"
  },
  "handwritten_fields": [],
  "needs_review": true,
  "review_reason": ""
}

突き合わせの結果は自前の処理が作ります。

{
  "slip_number": "",
  "match_status": "matched | not_found | ambiguous",
  "ship_date": "",
  "received_date": "",
  "days_to_receive": 0,
  "stored_path": "",
  "customer_code": ""
}

match_status に ambiguous（候補が複数）を用意します。not_found と混ぜないでください。 前者は台帳にない番号、後者は似た番号が複数ある状態で、対処が違います。

システムへ連携する

販売管理システムへの書き込みは、受領日の記録だけに限定します。 システムに受領日の欄がなければ、この構成の台帳に持ち、システムには書き込みません。受領書の回収管理のために販売管理システムを改修する必要はありません。

保管は、伝票番号で探せる形にします。 ファイル名に「伝票番号_取引先コード_受領日」を入れ、ドライブの検索でそのまま出てくるようにします。日付順のフォルダに入れるだけでは、従来の紙のファイルと同じ問題が残ります。

人が確認する

全件は確認しません。条件付きの確認にします。

人が見るのは次の場合だけです。

これらに当たらないものは、そのまま記録します。 月1,200件のうち、人が見るのは数十件になります。

全件確認にしない理由は、受領書の照合が金銭の移動を伴わないためです。誤って紐づけても、後から気づいて直せます。一方、支払や請求の金額を扱う業務では全件確認が必要です（このデータベースの受領請求書の読み取りの事例では全件確認としています）。同じOCRでも、扱うものの重さで設計が変わります。

確認を速くするための設計が重要です。

• 確認画面で、受領書の画像と読み取り結果を並べて表示する
• 番号の候補を、出荷日と取引先名つきで並べる（番号だけでは選べない）
• 押印欄を拡大して表示する
• 確認が終わったら次の1件へ自動で進む

例外に対処する

記録を残す

• 受領書のスキャン画像（伝票番号で検索できる形で）
• OCRの読み取り結果（生の状態）と、手書き判定の結果
• AIが返した解釈と needs_review の理由
• 人が確認した件と、確定した内容
• 突き合わせの結果（matched / not_found / ambiguous）
• 督促の履歴（いつ、誰に、何回目か）

受領書は、取引の証憑として保存期間の定めがあります。 電子で保存する場合、電子帳簿保存法の要件（取引年月日・取引金額・取引先で検索できること）を満たす形にしてください。ファイル名に伝票番号を入れるだけでは、金額での検索ができません。 メタデータとして持たせるか、台帳と紐づけて検索できる形にします。

この点は顧問税理士に確認してください。 紙で保存を続けるか、電子に移行するかで要件が変わります。