科研費自動化プロジェクト

概要

領収書をOCRして, 科研用の処理を自動化するシステム 科研の処理は, 物品購入以外にも出張資料や, 業務委託などもありますが, まずは物品購入処理の自動化をここで目指します.

1. 領収書からの項目と金額, 日時並びに利用者の読み込み
2. 利用者の記載がない場合は, 別途入力させた上で, 利用する科研費の選択
3. 項目ごとに, メーカー, 品名, 型番, 金額, 個数を読み込む
4. 品名, メーカー, 型番, 金額, 想定費目をUIに表示させる.
5. ユーザーが上記のUIを確認し, 追加入力+訂正

処理概要

graph TD;
	ファイル入力 --> 書類判定;

	subgraph 書類判定
	書類{種類};
	書類 --[領収書]--> 立替処理の候補作成;
	書類 --[納品書]--> 業者払い処理の候補作成;
	end

	書類判定 --> 項目処理;

	subgraph 項目処理
		候補アイテム --> 価格{価格};
		価格 --[1万未満]--> 消耗品;
		価格 --[1万以上,20万未満]--> 用品;
		価格 --[20万以上]--> 用品;
	end

	項目処理 --> 研究者番号取得;

	subgraph 研究者番号取得
		氏名
		氏名-->名前DB{名前DB};
		名前DB--[照合なし]-->Cinii{CiNii};
		Cinii--[照合なし]-->H[手入力];
		名前DB--[照合あり]-->研究者番号表示;
		Cinii--[照合あり]-->研究者番号表示;
		H-->研究者番号表示;
	end

	研究者番号取得-->課題情報取得

	subgraph 課題情報取得
		研究者番号-->KAKEN{KAKEN DB};
		KAKEN --[候補なし]-->H2[手入力];
		KAKEN --[候補あり]-->P{プルダウンで選択};
		P --[候補なし]-->H2;
		P --[候補あり]-->課題決定;
		課題決定-->課題情報表示
	end

Loading

補足

• 書籍, ライセンス料金（業務委託）については, 現行では触れないこととします.
• 領収書か請求書と, 科研の処理が１対１対応している事が望ましいとします.
• 購入に際して, 金額の確認が不充分な場合があるので, 単一PDFに対して, 複数の出力を許容します.
• 上記の姿勢から, 複数PDFに対して, 単一の出力は現状許容しない方向で検討しています.

load map

• 先ずは, 生協の請求書のスキャンとヨドバシの領収書データに対応する
• localでデモのjsonファイルから, 処理に必要なjsonファイルを作成する.
• 上記に合致したUIを作る.
• DBをKakenDBから取得したい
• OCRのapiと接続する
• ローカルにおくDBなどをサーバーサイドへ移行
• 科研の新システムが公開され次第, 出力をそちらに対応させる

OCR関連

OCRは現在 Gemini Flash Latestを利用しています. Promptは以下

• 単価はGeminiが判断できました.
• 現在は内税表記のみを対象としています.

領収書か納品書の情報を解析し、購入項目ごとに以下の形式でJSONに構造化してください.
ただし、以下の処理を施してください.
+ 金額の部分はカンマがあれば除いてください
+ 金額が0の項目は無視してください

{
  "title": "領収書タイトル",
  "issuer": "発行者情報",
  "receiver_group": "受領者所属",
  "receiver_group": "受領者氏名(敬称、空白は除く)",
  "total_amount": "合計金額",
  "payment_date": "支払日",
  "items": [
    {
      "product_name": "製品名(型番は抜く) ",
      "provider": "メーカー",
      "model": "型番"
      "unite_price": "単価",
      "total_price": "金額"
      "number": "個数",
      "delivery_date": "発送日"
    },
    ...
  ]
}

DB関連

DBの構成案は以下です.

• APRS.dbとして仮置きしてます

table: resarch_projects

CREATE TABLE research_projects (
    ID INTEGER PRIMARY KEY AUTOINCREMENT,
    AN TEXT NOT NULL,
    AT TEXT NOT NULL,
    PI INTEGER NOT NULL,
    CI INTEGER
);

• 若手や学振のように, 単独の研究用の科研費があるので, 分担者はNULLを許容します.
• 分担者は, 利用者が分担者の場合の利用を想定する. 複数いる場合は, 人数分レコードを増やす.
• 初期は手入力で行ってもらってもいいですが, ご入力をさける為, KAKEN apiの利用を念頭に置きたいと考えています.

resarcher_numbers

CREATE TABLE resarcher_numbers (
    RN INTEGER PRIMARY KEY,
    Name TEXT NOT NULL
);

• 可能ならば, Kaken apiを利用して, 研究者番号から検索をかけたい.
• OCRの混乱回避のため, 姓名は区別して登録しない方向で検討
• アルファベットの場合は, 姓名の最初を大文字とし, 空白は利用しない方向で検討
• ミドルネームなどは, 書類上対応しない方向で検討
• 苗字のみの書類は, 対応しない方向で検討

科研費の処理系

• すべて内税で処理
• １万円未満は, 消耗品を候補とします.
• 1万円以上, 20万円未満は, 用品を候補とします.
• 20万円以上は, 備品として処理します.
• 実際は, 金額だけではなく, 使い切りのものは消耗品, 什器は備品となるので, その都度選べるようにしたいです.

Discussion

UI

• UIに処理上のエラーがある場合は, ダイアログメッセージを出したいです.

• UIに提出できない状況である場合は, 警告をだしたいです.

• 分担の場合は, 代表者の表示もした方がよい気がしますが, 分担でない場合は, いちいち表示させたくないと感じています. UIの設計にいいアイディアはありますか?

OCR

• 生協とヨドバシは内税表記なので問題ないですが, 外税表記の対応は要件等となります.
• AIに金額を含めた項目判定を載せてもいいかもしれませんが, 例外処理は事務と事前にかけあってほしいので, 丁寧に対応しすぎない方がいいかもしれません.

DB

• sqlite3でもいいですか.
• アルファベット表記の対応はこれでいいでしょうか.
• 苗字のみの領収書は, 手書きを除いて少ない気がしますが, 苗字のみの対応も必要でしょうか.