司机订单系统（Field Order Platform）

先还原了原表单的真实结构，方案基于表单实际字段设计，而不是泛泛而谈。

这套结构在 Google 表单里带来的实际问题

• 录入慢、易错：几十个 SKU 平铺成长表格，1–6 的数量要靠数格子勾选，手机上滑动多页容易漏勾、错勾；总箱数靠人工心算，经常和明细对不上。
• 门店信息无法复用：Site ID / Store Name / Authorized By 每次手打，同一家店在不同司机、不同次录入中可能出现好几种写法，销售和仓库对不上账。
• 结果孤立、无法流转：表单提交后落到一张 Google Sheet，销售要看「今天有哪些新单」、仓库要看「按 SKU 汇总要备多少货」，都得自己在表格里筛选、透视，没有角色化视图，也没有状态跟踪（提交→确认→拣货→出库）。
• 缺少库存/停货联动：像「B&J VANILLA - OUT OF STOCK」这种停售信息只能写死在选项文字里，改一次要编辑表单本身，司机也可能看漏继续下单。
• 司机是在门店现场作业：大概率是边和店主聊边录单，网络可能不稳，Google 表单弱网下体验差、容易漏提交。
• 任何人拿到链接都能看：Google 表单本身不做企业内部登录隔离，跟这次要做「先登录才能看内容」的要求正好相反（见第 04 节）。

产品要服务四类人，各自要的是完全不同的界面，而不是同一张表单的不同权限。

这个规模（20+ 内部用户、每天大概率 <200 单）不需要重型自建后端，选型原则是「团队能自己维护、上线快、按需付费」。

关于数据库选型：直接用 PG，而不是自己再挑一个

Supabase 底层就是标准的 PostgreSQL——不是一个自己发明的私有数据库。这意味着：

• 你可以用任何 PG 工具直接连接管理：psql、DBeaver、TablePlus，或者像现在这样让 AI 通过 SQL/Migration 工具直接读写表结构和数据（这次会话里已经连了 Supabase 的管理工具，能直接建表、跑迁移、查日志）。
• 数据不会被"锁死"在某个专有格式里——真出问题了，标准的 pg_dump 就能把全部数据导出，换到任何一台 PG 主机上都能跑起来。
• 比起自己找一台服务器装 PG 再手工搭 Auth/Realtime/权限系统，Supabase 帮你把这些"标配"功能直接建在同一个 PG 实例上，团队不用额外招人维护基础设施，AI 管理数据库的能力完全不受影响。

企业内部工具，未登录不可见任何业务内容；登录一次后设备保持 30 天免登录，30 天后强制重新登录。

访问控制：先登录，才有首页

产品不存在"公开首页"——应用启动时先检查本地是否有有效登录态：

会话保持 30 天，之后强制重新登录

三端共享同一个 Supabase（PG）后端，靠角色和 Realtime 订阅区分视图，而不是三套独立系统。

flowchart TB
  subgraph Client["客户端"]
    D["司机端 H5/PWA
录单 · 离线草稿 · 复制上次订单"]
    S["销售看板
今日订单 · 按线路/门店筛选 · 导出"]
    W["仓库看板
SKU 汇总拣货单 · 出库状态"]
    A["管理后台
商品目录 · 线路 · 账号"]
  end

  subgraph Supabase["Supabase（标准 PostgreSQL）"]
    Auth["Auth
角色: driver / sales / warehouse / admin
Session Time-box: 30 天"]
    DB[("Postgres
orders · order_items · products · customers")]
    RLS["Row Level Security
按角色隔离数据访问"]
    RT["Realtime
订单变更实时推送"]
    EF["Edge Functions
提交校验 · 通知触发 · 汇总计算"]
  end

  subgraph Notify["通知"]
    TW["Twilio SMS"]
    Mail["邮件(Resend/SendGrid)"]
  end

  D -- 登录(30天会话) --> Auth
  S -- 登录(30天会话) --> Auth
  W -- 登录(30天会话) --> Auth
  A -- 登录(30天会话) --> Auth
  Auth --> RLS --> DB
  S -- 订阅 --> RT
  W -- 订阅 --> RT
  DB --> RT
  DB --> EF
  EF --> TW
  EF --> Mail
  A --> DB
  D -.本地草稿.-> LocalDB[("IndexedDB
离线队列")]
  LocalDB -. 恢复网络后同步 .-> DB

提交订单的实时流转

sequenceDiagram
  participant Dr as 司机
  participant App as PWA(离线队列)
  participant DB as Supabase DB
  participant EF as Edge Function
  participant Sa as 销售看板
  participant Wh as 仓库看板

  Dr->>App: 选门店/线路，勾选商品数量
  App->>App: 本地校验(总箱数自动核对)
  App->>DB: 提交订单(在线) / 存入本地队列(离线)
  DB->>EF: 触发 on-insert
  EF->>Sa: Realtime 推送（带门店照片缩略图，如有）
  EF->>Wh: Realtime 推送，加入拣货汇总
  Wh->>DB: 更新状态: 已拣货/已出库
  DB->>Sa: 状态变更实时同步
  DB->>Dr: 司机端可查看自己订单状态

对照原表单字段整理出的核心表，商品目录和线路独立维护，避免像现在这样写死在表单选项里。这一版按最新沟通加入了客户分级定价、PLMA 货架陈列、门店照片三块新能力。

订单与商品

erDiagram
  USERS ||--o{ ORDERS : creates
  ROUTES ||--o{ CUSTOMERS : covers
  ROUTES ||--o{ USERS : assigned_to
  CUSTOMERS ||--o{ ORDERS : places
  ORDERS ||--|{ ORDER_ITEMS : contains
  PRODUCTS ||--o{ ORDER_ITEMS : referenced_by
  CATEGORIES ||--o{ PRODUCTS : groups

  USERS {
    uuid id
    text full_name
    text role "driver/sales/warehouse/admin"
    uuid route_id
    timestamp last_login_at
  }
  ROUTES {
    uuid id
    text name "Sydney North 等 8 条"
  }
  CUSTOMERS {
    uuid id
    text site_id "8 位数字，如 1500 8888"
    text store_name
    text suburb "如 Burwood，司机端只看这个，不看大区域"
    text authorized_by
    text tier "定价等级 A/B/C"
    text chain_name "7-Eleven/BP/EG…，独立门店为空"
    uuid route_id
  }
  ORDERS {
    uuid id
    text order_type "TIO/Suggested/PLMA"
    uuid customer_id
    uuid driver_id
    date required_delivery_day
    text comments
    text status "submitted/picking/fulfilled"
    int total_boxes "PLMA 记录固定为 0，不含商品"
    numeric total_price "按客户等级自动算出；PLMA 记录固定为 0"
    uuid freezer_size_id "仅 PLMA 订单"
    jsonb photo_urls "门店照片，可拍多张，选填"
    timestamp created_at
  }
  ORDER_ITEMS {
    uuid id
    uuid order_id
    uuid product_id
    int quantity
    numeric unit_price "下单那一刻按等级算出并留痕"
  }
  CATEGORIES {
    uuid id
    text name "Impulse/B&J/Multi Pack…"
  }
  PRODUCTS {
    uuid id
    uuid category_id
    text sku_name
    bool is_active
    bool out_of_stock "司机端不展示这个 SKU"
    bool low_stock "司机端正常展示 + 库存紧张标记"
    bool on_promotion "所有端都展示的促销标记"
    numeric base_price "当前生效价"
    numeric scheduled_price "排期改价：新价格，未到日期前不生效"
    date scheduled_effective_date "到这天自动把 scheduled_price 转正为 base_price"
    text stock_source "manual / feed，标记是手动维护还是来自库存系统自动同步"
  }

定价分级与 PLMA 货架陈列

erDiagram
  CUSTOMERS ||--o{ ORDERS : places
  PRODUCTS ||--o{ TIER_PRICES : "has price per tier"
  FREEZER_SIZES ||--o{ PLANOGRAMS : "default for"
  PLANOGRAMS }o--o{ CHAINS : "override for"

  TIER_PRICES {
    uuid id
    uuid product_id
    text tier "A/B/C"
    numeric unit_price "= base_price × 等级折扣"
  }
  FREEZER_SIZES {
    uuid id
    text label "12 Basket / 18 Basket / 24 Basket"
    int basket_count
  }
  PLANOGRAMS {
    uuid id
    uuid freezer_size_id
    text scope "default / chain / customer"
    text chain_name "命中连锁总部标准时使用"
    uuid customer_id "极少数门店级专属覆盖"
    jsonb image_urls "一组参考图，宽冰柜可以传多张"
  }

取用逻辑（从精确到粗略）：先查这家门店本身是否有专属陈列（scope=customer，极少数）→ 再查所属连锁总部是否有统一标准（scope=chain，比如 7-Eleven/BP/EG）→ 都没有就用这个冰柜规格的默认陈列（scope=default）。私人独立经营的门店基本都落在"默认陈列"这一档。

这是司机每天要用几十次的工具，体验差一点，一天下来就是几十分钟的浪费和几个错单。

门店信息：司机端从简，销售/管理端从全

同一份客户数据，不同角色看到的详略程度不一样：

定价：按客户等级自动算，司机不用管价格

每个 SKU 维护一个基础价（Base Price），客户按等级分为 A/B/C（比如 A = 连锁总部直营价、B = 加盟商价、C = 独立门店价，具体等级口径和折扣比例由你们定）。司机选好商品数量后，系统按这家店当前的等级自动算出单价、小计、总金额，提交前就能看到"这一单大概多少钱"——不需要司机记价目表，也不会有人手动改错价。

价格改在哪、什么时候生效：Admin 后台的 Products 页面里，改基础价和 A/B/C 三档等级价都在同一处（不需要跳到另一个页面）。改价支持排期生效：不填生效日期就立刻生效；填一个未来日期，系统会先把新价格记成"待生效"，当前价格照常使用，直到那天到了才自动切换成新价——不需要销售/仓库记着"哪天该改价"，也不会有人提前手动改早了。不管是立即生效还是排期生效，都不会改动已经下单的历史订单：每笔订单在提交那一刻就把当时算出的单价留痕存进订单明细里，之后价目表再怎么调，已提交（哪怕还没出库）的订单金额都不会跟着变，避免和财务对不上账。

促销 / 库存紧张 / 缺货：三个独立标记，各端展示规则不同

「谁来维护」这一列刻意留了两条路：第一期管理员在后台手动打标，如果后续你们有独立的库存管理系统或 ERP，可以配一个定时任务自动把库存状态同步过来覆盖这三个标记——架构上两者共存，自动同步的结果始终可以被管理员手动改一次覆盖掉。

移动端细节：司机全程用手机操作

司机端不是"缩小版网页"，是要按手机原生使用习惯专门打磨的几个细节：

• 点击区域不小于 36～44px：数量加减按钮、分类标签、下拉建议项这些高频点击的元素，按钮做小了在颠簸的送货车上、或者一手拿货一手点屏幕时特别容易点错，宁可界面稍微占地方一点。
• 输入框字号不低于 16px：iOS Safari 有个特性——输入框字号小于 16px，点进去输入时整个页面会被系统自动放大，反而更难操作，所以所有输入框统一按 16px 起步。
• 数字对齐：价格、数量这些要一眼扫的数字用等宽数字排版，金额变化时不会因为数字宽度不一而"跳来跳去"。
• 底部安全区适配：新一点的 iPhone 底部有 Home 指示条，提交按钮这类固定在底部的操作栏要预留出这块安全区，不然按钮会被系统手势条遮住一部分。

PLMA：一个独立的两步流程，不是订单流程的延伸

PLMA 替换了原来的「New Customer First Order」，是和普通订单完全分开的一件事——司机不需要在选完 PLMA 后再走一遍选商品、算金额那一套。具体是两步：

点「拍照」之后：系统先记录这次陈列巡检（门店、冰柜规格、用的是哪张陈列图、备注），同时立刻唤起相机。拍完的照片会显示成一个小图集，司机可以继续追加拍多张、也可以删掉拍糊的重拍——不限制只能拍一张，宽冰柜经常需要分几张才能拍全。确认没问题后点 「完成」，结束这次巡检并跳回最开始的订单信息页，可以直接开始录下一单。这条记录不含商品明细和金额，因为它本来就不是一张订货单。

素材规范：司机是在手机小屏幕上看陈列图，要求统一比例和清晰度——建议 4:3、长边至少 1600px，避免有的图糊、有的图上文字小到看不清。一个规格的冰柜允许挂多张参考图：24 Basket 这类比较宽的冰柜，一张照片经常拍不全，管理后台支持给同一个"规格 + 连锁"组合传多张图（拍不同角度/分段），不强求塞进一张里。

门店照片：辅助销售远程跟进

普通订单（Turn In Order / Suggested Order）提交后，司机可以选择性拍一张或多张店内照片，同样支持追加拍摄和删除重拍，上传后销售在订单详情里就能看到，用来远程判断这家店是否需要人工跟进——纯辅助决策，不是必填项，不会拖慢司机的录单速度。PLMA 的拍照则是流程本身的最后一步（见上），不是"提交后可选"。

存储成本控制：照片在司机手机端上传前先压缩到合理分辨率（例如长边压到 1600px 左右、JPEG 有损压缩），避免原图直接上传占用过多 Supabase Storage 空间；管理后台提供"清理旧照片"功能，可设置「每家店只保留最近 N 次（默认 3 次）」，一键清掉更早的历史照片，不需要逐条手动删。

其他值得做的小功能

• 「复制上次订单」：同一家店上次订过什么，司机一键带入再改数量，减少重复劳动。
• 仓库拣货单按 SKU 自动汇总：不需要仓库自己在几十条订单里手动加总每个 SKU 的数量。
• 司机签到/定位（可选）：如果后续要做拜访轨迹分析，可以在提交订单时顺带记录 GPS，一开始不做，留好数据库字段即可。

全部通过 Supabase Row Level Security 在数据库层实现，前端不需要额外写权限判断逻辑。

建议 6～8 周内分阶段上线，先让司机端可用并跑通与仓库/销售的通知闭环，管理后台和离线能力可以在第二阶段补齐。

这个规模大概率在各服务的免费或最低付费档位内。

• 数据迁移：现有 Google Sheet 里的历史订单和门店名单建议先清洗一遍（同一门店的多种写法归一化），再导入新系统的 customers 表，否则新系统会继承旧数据的脏乱。
• 司机的接受度：现场录单的人对「更好用」比「更多功能」敏感得多，第一版司机端建议克制，只做「比表单快」这一件事，复制上次订单/搜索/离线是优先级最高的三个点。
• 过渡期双系统：不建议一刀切停用 Google 表单，建议灰度 1～2 周，期间新旧系统并行，确认新系统单据和仓库实际出库对得上账后再全量切换。
• 30 天会话的边界情况：司机换手机/清了浏览器数据会立刻要求重新登录（这是预期行为，不是 bug）；管理员账号建议单独设置更短的会话或二次确认，避免管理端设备丢失后被长期滥用。
• 8 位 Site ID 唯一性：批量 Excel 导入客户主数据时要做 Site ID 唯一性校验，防止同一个编号被两个门店误用，导致订单、价格、陈列图全部串店。

以下几项在这版沟通中已经有明确结论，不再是悬而未决的风险，写在这里是为了留一个记录：停售权威来源——已定为 Admin 唯一编辑权限（见第 08 节）；价格生效时间点——已定为"下单留痕，历史订单不受后续改价影响"（见第 07 节）；陈列图素材质量与多图、门店照片压缩与保留策略——已定为统一规格 + 后台一键清理（见第 07 节）。