Decision
总体判断：先交付对账包，不把零开发说成页面已改
10 条全部已落到原系统页面或流程
Phase 0-3可用运营导出包快速上线
4 类统一流水、顾客明细、充值明细、退款提现
Phase 4客户坚持页面能力才开发
这次最关键的边界：客户说“开发不用改”时，能交付的是固定导出流程和财务口径；客户要“后台页面直接查、点按钮导出、首页出现消费码”，就进入开发范围。
| 阶段 | 目标 | 产出 | 是否需要开发 |
|---|---|---|---|
| Phase 0 | 锁财务口径 | 退款账期、清零依据、单位充值定义、短信状态确认 | 不需要 |
| Phase 1 | 出样表 | 交易明细、顾客明细、充值明细、退款提现清单 | 不需要 |
| Phase 2 | 抽样验收 | 3 人、1 单位、1 跨月退款、1 批回收卡 | 不需要 |
| Phase 3 | 零开发上线 | 固定导出流程、现场消费码指引、财务口径说明 | 不需要 |
| Phase 4 | 页面化增强 | 财务对账中心、退款提现导出、小程序首页码、短信找回 | 需要 |
System Map
原系统页面地图
| 业务 | 原页面 | 当前能做 | 客户需求缺口 |
|---|---|---|---|
| 消费 | 订单管理 / 消费订单 | 查消费订单，导出消费，含现金支付、补贴支付、退款金额、设备 | 不能作为单人全交易流水，不能拆单位充值消费 |
| 充值/补贴 | 报表管理 / 充值统计、补贴统计 | 按日期、部门、方式统计和导出 | 偏统计，缺逐笔卡号、操作员、资金归属 |
| 退款 | 订单管理 / 退款订单 | 查申请时间、审核时间、退款状态 | 未看到导出按钮，账期口径需改成审核/到账 |
| 提现 | 订单管理 / 提现订单 | 查提现金额、申请时间、到账时间、状态 | 未看到导出按钮 |
| 卡务 | 综合管理 / 卡片管理、卡操作日志 | 卡片导出，卡操作日志导出 | 需要和余额、最近交易时间、财务流水合并 |
| 移动端 | 小程序 / 我的、登录、修改密码 | 我的页可弹消费码；修改密码要求旧密码 | 首页没有明显消费码；没有证据证明已有忘记密码流程 |
D1
交易明细表：把 6 个页面合成一张个人全流水
客户要的不是消费订单表，而是一段时间内某个人的所有账户变动：开卡、补卡、消费、充值、补贴、退款、取现、销户、清零。
Before：原页面分散
消费订单
字段现金支付、补贴支付、退款金额、支付方式、设备、时间
覆盖消费、部分退款
充值/补贴统计
字段充值日期、部门、姓名、方式、金额
覆盖充值、补贴
退款/提现/卡操作
字段申请时间、审核时间、到账时间、卡号、操作类型
覆盖退款、取现、开卡、补卡、退卡
After：财务对账中心 / 交易明细
筛选区
条件时间、单位、部门、姓名、手机号、卡号、事项、终端、操作员
流水表
字段时间、事项、收入、支出、优惠、管理费、余额、终端、来源单号
跳转
来源消费订单、充值统计、补贴统计、退款订单、提现订单、卡操作日志
零开发交付
- 导出 6 类现有数据，合并成机场交易明细 Excel。
- 按人员/卡号/时间/事项排序，补来源单号。
- 余额字段标注为导出时快照或处理后余额。
验收
- 抽 3 人覆盖充值、消费、退款、卡操作。
- 期初 + 收入 - 支出 = 期末。
- 每条退款可追溯原订单。
D2
小程序消费码入口：从我的页前移到首页
机场收银现场的目标是减少找码时间，页面改造只是手段。
Before：路径深
打开小程序→我的页→右上角二维码→消费码弹窗
After：首页直接出示
打开首页→出示消费码→消费码弹窗
我的页→保留二维码入口
零开发交付
- 现场小程序码、台卡、手册引导。
- 如果支持 path，生成直达消费码或我的页的小程序码。
- 先把验收改成 10 秒内找到消费码。
开发边界
- 首页按钮或浮窗需要前端开发。
- 首页若没有二维码数据加载，还要联调移动端接口。
D3
顾客明细表：卡务、余额和最近交易时间合并
客户要按单位导出卡号、姓名、单位、部门、现金余额、补贴余额、卡状态、最近交易时间、启用时间。
Before：卡务视角和消费视角分离
卡片管理
有卡号、姓名、部门、手机号、发卡时间、卡状态
人员余额
有现金余额、补贴余额
消费报表
有消费次数、现金金额、补贴金额、退款金额
After：财务对账中心 / 顾客明细
筛选
条件单位、部门、卡状态、余额是否为 0、最近交易时间、启用时间
表格
字段卡号、姓名、单位、部门、现金余额、补贴余额、卡状态、最近交易时间、启用时间
跳转
动作个人交易明细、卡操作日志、卡片详情
零开发交付
- 卡片列表导出 + 人员余额导出 + 最近订单时间合并。
- 最近交易时间用订单最大支付/下单时间补齐。
验收
- 抽 1 个单位 20 人。
- 卡状态与卡片管理一致，余额与人员账户一致。
D4
充值明细表：从统计表扩展到逐笔明细
客户要按充值方式、单位和时间排序，字段包括时间、卡号、姓名、单位、部门、方式、金额、操作员。
Before：充值统计
现有字段
字段充值日期、部门、姓名、手机号、充值类型、充值方式、充值金额
问题可能是统计口径，缺卡号、操作员、批次和资金归属
After：充值统计增加明细模式
明细表
字段充值时间、卡号、姓名、单位、部门、充值来源、充值方式、金额、操作员、批次号
模式统计 / 明细切换，导出逐笔明细
零开发交付
- 先用充值统计导出。
- 逐笔字段由实施从充值订单明细导出。
- 源数据没有的卡号/操作员必须标空或说明。
验收
- 同一人同一天多笔充值不能合并。
- 线下现金充值能看到操作员。
- 单位批量充值能追批次。
D5
退款、提现增加导出：复制消费订单的导出体验
现有退款和提现列表能查，但财务要固定字段导出和导出记录。
Before：列表有，导出弱
退款订单
字段退款单号、姓名、金额、申请时间、审核人、审核时间、状态
缺口未看到导出按钮
提现订单
字段提现单号、姓名、金额、申请时间、到账时间、状态
缺口未看到导出按钮
After：导出和导出记录
列表顶部
按钮导出、导出记录
导出记录
字段文件名、状态、创建时间、完成时间、下载链接、失败原因
导出字段
字段单号、来源订单、姓名、卡号、单位、金额、申请时间、审核/到账时间、状态
零开发交付
- 实施按页面筛选条件导出退款/提现清单。
- 纳入机场财务对账包。
验收
- 页面合计与导出合计一致。
- 跨月退款按审核/到账账期输出。
D6
回收餐卡余额清零：先审批，不先做一键清零
这是资金权益处理，不是普通字段调整。没有客户确认和复核，不应直接清零。
Before：动作分散
卡片管理+卡操作日志+退款+提现
没有专门的回收卡清零审批页。
After：回收卡清零审批
上传名单→余额复核→财务审批→执行清零→卡复用
关键字段
字段卡号、姓名、清零前余额、清零后余额、原因、客户确认编号、处理人、复核人
零开发交付
- 客户提供签字或邮件确认名单。
- 实施导出清零前后对照表。
- 金额不一致的卡退回核对。
开发边界
- 批量上传、自动复核、一键清零、清零流水需要开发。
- 开发前必须先锁审批规则。
D7
单位充值消费列：不能只加列，先要分账户或分来源
如果公司现金和个人现金都进同一个现金余额池，消费时无法审计级反推来源。
Before：消费按账户类型，不按充值来源
消费订单/人员消费报表
已有现金支付、补贴支付、退款金额、支付方式
缺口不知道现金余额来自个人充值还是单位充值
After：充值来源 + 账户分池 + 消费拆分
充值
新增个人微信、个人现金、单位现金、单位补贴、批次号
消费报表
新增个人现金消费、单位充值消费、补贴消费、退款金额、实付金额
零开发交付
- 后续单位充值统一走补贴/单位账户。
- 现有消费表暂按现金支付/补贴支付归属。
- 历史数据只做批次人工推断，不承诺审计级准确。
验收
- 从切换日开始可分账。
- 单位充值余额、个人现金余额和消费扣款能对上。
D8
短信验证码找回密码：修改密码不等于找回密码
当前可见页面是登录和修改密码，修改密码要求旧密码，不能替代忘记密码。
Before：登录页和改密页
登录页
现状账号密码登录，未见忘记密码入口
修改密码
字段旧密码、新密码、确认密码
After：忘记密码闭环
登录页→忘记密码→手机号→短信验证码→新密码→登录
零开发前提
- 已有完整页面和接口，只差短信平台、模板、开关配置。
- 当前页面证据不足，不能直接宣称已上线。
验收
- 绑定手机号可收码并重置。
- 验证码过期、频繁发送、错误手机号有拦截。
D9
退款账期：建议按审核通过或到账日期
客户例子：1 月 1 日申请，2 月 1 日审核。若回写 1 月，会改变已关闭账期。
Before：页面有多个日期，口径不清
退款订单
字段申请时间、审核人、审核时间、退款状态
风险按申请日过滤会影响跨月对账
After：账期日期类型
筛选区
新增账期日期类型：申请日期、审核日期、到账日期
导出表
字段原消费时间、申请时间、审核时间、到账时间、退款入账月份
零开发交付
- 导出包按审核/到账日期入账。
- 原消费日期只保留为追溯字段。
验收
- 1 月申请、2 月审核的退款计入 2 月。
- 1 月已出报表不回写变动。
D10
现金充值公司/个人区分：现金是方式，不是归属
要区分公司充值和个人充值，必须在充值发生时记录资金归属，不能导出时猜。
Before：充值统计只看方式
充值统计
已有线上/线下、充值方式、充值类型、金额
缺口现金不说明是公司出钱还是个人出钱
After：资金归属字段
充值录入/导入
新增资金归属、单位、批次号、经办人、备注
报表
新增个人充值金额、公司充值金额、个人充值消费、单位充值消费
零开发交付
- 后续公司充值走补贴/单位账户。
- 若必须现金，使用专用操作员、专用批次、固定备注。
- 历史只辅助识别，不承诺完全准确。
验收
- 确认日后每笔现金充值都有唯一资金归属。
- 按归属汇总与充值总额一致。
Review
需要确认的 9 个问题
统一流水
接受 Excel 合并模板，还是必须后台单页查询？
组织层级
顾客明细中的单位和部门以哪一层为准？
充值明细
接受统计口径，还是必须逐笔明细？
退款账期
是否确认按审核通过或到账日期入账？
余额清零
客户能否先给书面确认名单？
单位充值
是否允许统一走补贴或单位账户？
消费码入口
本期是否接受现场二维码和手册引导？
短信找回
是否已有短信平台、模板和接口？
退款提现导出
本期接受实施导出包，还是必须加后台按钮？
Customer Wording
建议对客户回复
本次先按“快速上线、第一阶段不改代码”的方式推进：基于现有后台消费订单、充值统计、补贴统计、卡片管理、卡操作日志、退款和提现数据，整理成机场财务对账导出包，包含交易明细、顾客明细、充值明细和退款提现清单。退款账期建议按审核通过或实际到账日期进入当期，不回写已关闭账期；回收卡余额清零必须以客户书面确认名单为依据；后续单位充值建议统一进入补贴或单位账户，避免和个人现金余额混在一起。若客户确认这些口径，实施侧可以先在 1-2 天内出样表并上线使用；若客户要求系统后台新增统一交易明细页面、退款/提现导出按钮、小程序首页消费码入口或短信找回密码完整流程，则需要另拆开发任务。