入金管理ページを作った——スプレッドシートで金の流れを追う

振込入金の確認が手作業だった。

予約が入る。お客様が銀行振込をする。オーナーが通帳を確認する。スプレッドシートを開いて「支払済」と手入力する。お客様に「ご入金確認しました」とLINEを送る。

件数が増えると、このフローは重くなる。特にイベントの場合、複数人が同じ日に振込む。誰が入金済みで誰がまだか、スプレッドシートを見ながら確認する作業が毎回発生する。

管理画面に入金管理ページを追加した

未払い・支払済・全件の3つのビューを切り替えられる一覧表を作った。通常予約とイベント予約の両方を1画面に統合した。

並行してAPIを2本呼び出し、結果をマージする。

const [r1, r2] = await Promise.all([
  fetch(`${API}/admin_get_bookings`, {credentials:'include'}),
  fetch(`${API}/admin_get_event_bookings`, {credentials:'include'}),
]);

通常予約の行とイベント予約の行を混在させて表示する。イベント予約には🎪バッジをつけて区別できるようにした。

「支払済にする」ボタン

ボタンを押すと2つのことが起きる。

スプレッドシートの paid 列に「支払済」と書く。お客様のLINEに「ご入金を確認いたしました」メッセージを送る。

LINE送信は失敗することがある。月間送信上限（HTTP 429）に当たる可能性がある。失敗したときに「送信しました」と表示するのは不誠実だ。

pushMessage() の戻り値を確認して、成功したときだけ確認送信日時を記録するようにした。

const lineOk = lineUid ? pushMessage(lineUid, `✅ ご入金を確認いたしました...`) : true;
if (lineOk) {
  sheet.getRange(i + 1, 17).setValue(now); // pay_confirm_sent_at（送信成功時のみ記録）
}
return jsonResponse({success: true, line_ok: lineOk,
  line_warning: (!lineOk && lineUid) ? 'LINE送信に失敗しました（月間上限の可能性あり）' : null});

管理画面は line_warning があればトーストで警告を出す。「支払済にしました」と「LINE送信失敗」を同時に表示できる。

入金リマインドの送信

未払いの方への催促LINEを個別に送れるようにした。

24時間以内に同じ人に2回送ることを防ぐ仕組みが必要だった。管理者が誤操作で連打しても困る。

最後に送った日時を pay_remind_sent_at 列に記録して、前回送信からの経過時間を確認してから送る。

const lastDt = new Date(lastSent.replace(/\//g, '-').replace(' ', 'T') + '+09:00');
if ((new Date().getTime() - lastDt.getTime()) / (1000 * 60 * 60) < 24) {
  return jsonResponse({success: false, message: '前回の送信から24時間以内です（前回: ' + lastSent + '）'});
}

タイムゾーン処理が少し面倒だった。スプレッドシートに保存した yyyy/MM/dd HH:mm 形式の文字列をDateに変換するとき、+09:00 を末尾につけてJSTとして解釈させる。

未払い一覧を自分のLINEに通知する

個別の確認ではなく、未払い全件をまとめて自分のLINEに送る機能も追加した。

管理画面の「未払い一覧を自分へ通知」ボタンを押すと、未払いかつ確定済みの予約をまとめてLINEに送ってくる。

const lines = [`💳 未払い予約一覧（${unpaid.length}件）\n`];
unpaid.forEach((b, idx) => {
  lines.push(`${idx + 1}. ${b.name} 様\n   ${b.service}\n   ${b.date}\n   ID: ${b.id}`);
});

イベント予約も含める。通常予約シートだけを見ていた実装では、イベントの未払いが漏れる。両方のシートを確認してからまとめる。

こちらもLINE送信の結果を確認して、失敗したら管理画面に失敗を表示する。「送信しました」と表示されたのに届いていない、という状態を作らない。

入金管理は地味な業務機能だ。しかし売上の回収に直結するので、漏れが許されない領域でもある。手動確認の手間を減らすことと、送信結果を正確に伝えることの2つを軸に設計した。

次回は、全イベントが消えたバグの話を書く。

*シンプルシステム株式会社代表　伊藤勝彦*