AIで経費申請アプリを作る｜申請・差し戻し・承認の履歴を残す

まず一つの申請と一人の承認者から始める

例では一人の従業員が複数の明細をまとめて申請し、一人の担当者が確認します。部門ごとの多段承認、予算の自動配分、振込処理まで初回に入れず、提出した明細と確認結果が対応するところまでを作ります。承認済みと支払済みは別の状態として扱い、承認操作で入金済みと表示しません。

AIには申請者が下書きを直す画面と、承認者が比較して判断する画面を分けて依頼します。申請者が自分の名前を別人へ変えて提出できないよう、本人の識別は入力欄ではなく認証された利用者から取得する設計にします。

申請の版と明細を関連付ける

申請には申請ID、申請者、対象期間、状態を持たせ、提出ごとに版番号を付けます。明細には利用日、用途、金額、通貨、領収書の参照先を保存します。承認記録は申請IDだけでなく提出版を参照し、後で金額を直しても何を承認したか分かる構成にします。

LovableのSupabase連携を使う場合は、申請者本人と割り当てられた承認者の取得範囲を明示します。他の社員の領収書を一覧の応答へ含めてから非表示にする処理ではなく、保存先から必要な記録だけ返すようにします。練習用には架空の領収書と利用者を用意します。

• Lovableの保存と権限を確認する

金額と通貨の扱いを決める

円の明細なら整数で管理し、外貨を扱う場合は通貨と小数桁の規則を合わせて保存します。日本円と米ドルの金額をそのまま足して総額として表示しません。換算が必要な業務なら、レート、適用日、換算後の通貨と端数処理を別の仕様として定義してから実装します。

金額の入力欄では空欄、ゼロ、負数、過大な値を区別します。小数が必要な構成は正確な小数型や整数単位への変換を検討し、表示のために丸めた文字列を計算へ戻さないようにします。税区分など業務ごとに決める項目を、AIが領収書の見た目から勝手に確定しない設計にします。

提出後の内容を固定して確認に回す

申請ボタンでは必要項目と領収書の状態をサーバー側で確認し、提出版を固定してから確認待ちにします。画面上のボタンを隠すだけでなく、提出済みの明細を利用者が直接更新できない条件を保存処理に入れます。申請と版の作成が片方だけ終わらないように保存の単位をそろえます。

承認者は自分に割り当てられた申請の最新提出版だけを処理します。申請が差し戻された後、古い画面から承認操作を送っても成立しないよう、期待する状態と版を照合します。判断理由、処理者、処理時刻は承認結果と一緒に保存し、後でコメントだけを取り違えないようにします。

• 申請テーブルの変更を確認する

二明細の例で承認と差し戻しを追う

架空の練習例として交通費1,200円と備品800円の二明細を作り、日本円の合計2,000円になることを照合します。領収書が必要な設定で一明細だけ未添付にした場合は、どの行を直すべきか示し、合計が出ているだけで提出を受け付けないようにします。

次に承認者が用途の確認を求めて差し戻し、申請者が説明を追加して再提出する流れを試します。最初の提出版、差し戻し理由、再提出版がそれぞれ確認できることが期待する結果です。これは実装後の確認用データであり、会社で発生した経費や製品の実測値を示すものではありません。

差し戻しと訂正の履歴を消さない

差し戻しでは提出版を直接書き換えず、再編集できる下書きへ必要な値を引き継ぎます。承認者のコメントは前の版に残し、再提出時には何を変えたかを比較できるようにします。添付の差し替えも新しい版の参照先を変え、承認済みの領収書を黙って置き換えない設計にします。

承認の取消が必要な場合は、その操作を誰に許すか、理由を必須にするかを決めます。承認済みを未申請へ戻して履歴を消すのではなく、取消の記録を追加します。連打や通信切れによる再送は同じ操作番号で照合し、同じ判断が二件の履歴として増えないようにします。

保管期間と利用量から費用を見積もる

Lovableでの制作に使う利用枠と、公開アプリのデータ保存、領収書ファイル、メール通知の費用を分けて見積もります。月の申請件数に加え、一申請の明細数、領収書の平均容量、差し戻しの回数、保管期間が必要量を左右します。過去のファイルを誰でも一括取得できる設計にしないことも確認します。

最初は一通貨、一承認者、少数の明細で動作を固め、実際に必要な承認経路だけを追加します。保存期間は会社の運用に合わせて担当者が決め、アプリ内の削除とバックアップの扱いも確認します。現行の利用枠と請求条件は各サービスの公式画面で照合します。

• 差し戻しの練習データを作る

小規模公開では一覧と履歴を照合する

公開前に申請者、承認者、無関係な利用者の三つの権限で確認します。申請者が他人の明細を開けないこと、承認者が担当外の申請を処理できないこと、古い提出版への承認が止まることを含めます。一覧の件数だけでなく、個別の履歴からどの版が現在の対象か説明できる状態にします。

障害時は新しい提出を止めても、処理中の申請と提出番号を確認できるようにします。復旧後に同じ申請を再入力する前に、保存済みかを照合します。申請の管理と会計処理への受け渡しを区別し、出力した明細がどの承認版に対応するかも記録して運用を始めます。