全体の流れ
申込画面お客様のスマホ
紹介QR・リンク（?ref=紹介ID）
紹介QR・リンク（?ref=紹介ID）
決済代行カード・QR決済
本番で接続。入金を通知
本番で接続。入金を通知
⇄
サーバー（API）入力の検査・申込の登録
入金の反映・報酬の計算
入金の反映・報酬の計算
データベースお客様・契約・入金・報酬・フォロー記録
⇄
パートナー画面担当ユーザー・入金状況
報酬・フォロー・紹介QR
報酬・フォロー・紹介QR
本部管理画面契約一覧・入金・通知
月次の報酬計算
月次の報酬計算
画面は会長の画面設計をそのまま使い、計算と保存をサーバー側に移しています。金額の計算は必ずサーバーで行い、画面側では計算しません。
進め方（段階）
今回のデモ
スマホ版はブラウザの中だけで動作（サーバーなし）。PC版はSQLiteのデータベースで動作。費用0円
スマホ版はブラウザの中だけで動作（サーバーなし）。PC版はSQLiteのデータベースで動作。費用0円
当面の受付（月末〜）
今あるGoogleフォームで申込を受付。システムの完成まではこちらでつなぐ
今あるGoogleフォームで申込を受付。システムの完成まではこちらでつなぐ
テスト稼働
PostgreSQL（Supabase無料枠など）に載せ替え。アカウントは会社名義。費用0円〜
PostgreSQL（Supabase無料枠など）に載せ替え。アカウントは会社名義。費用0円〜
本番
PostgreSQLのまま本番化を推奨（移行が要らず安全・安価）。SQL Serverが必要な理由があればそちらへ
PostgreSQLのまま本番化を推奨（移行が要らず安全・安価）。SQL Serverが必要な理由があればそちらへ
データベース構築の考え方レポート（2026-11-07）の方針に沿っています。テーブルは標準的なSQLの範囲で定義しており、SQLiteからPostgreSQLへの載せ替えを前提にしています。
設計で気をつけたこと
- カード番号を持たない：申込画面からサーバーへカード番号を送らない。本番は決済代行のトークン決済
- 体調チェックの回答を保存しない：「すべて該当なしで通過した」ことと同意日時だけを記録。個々の回答（要配慮個人情報）はデータベースに入れない
- 報酬は入金済みだけ：その月の入金が確認できたユーザーだけを計算。契約から24か月で対象外
- 報酬率は設定表で管理：基準額30,000円・継続販売10%・営業20%はプログラムに直書きせず、settingsテーブルで変更できる
- 計算し直せる：同じ月を計算し直すと結果が置き換わる（二重計上しない）
- フォローの記録：「気になる点あり」は本部への通知として記録
デモでやっていないこと（本番までに作るもの）
- 決済代行との接続（継続課金・入金通知・失敗時と解約の処理）
- ログインと権限（パートナーは自分の担当分だけを見られるように）
- 確認メールの送信、フォローの自動スケジュール（毎日の処理）
- 在庫・ロット管理（デモの在庫画面は固定表示）
- 会社ごとのデータの分け方（お客様と契約する会社が複数になる場合）
- バックアップ・監視・操作の記録
本番の前に決めること
- 商品・販売方法の法務確認（薬機法・特定商取引法・景品表示法など）と、規約・表示の確定
- 決済代行の選定と審査
- 報酬の基準額30,000円が税込か税抜か
- お客様と契約する会社、決済代行の契約者、個人情報の管理者をどの会社にするか
- サーバー・データベースのアカウント（会社名義）