CPT · 技术实施方案

流水查询三表实施方案

页面信息结构按原型,正式视觉复用系统全局样式和组件;使用现金、补贴、赠送三张原流水表,所有业务卡点已关闭。

无待确认业务卡点全局样式组件复用三表方案已锁定待开发实施

0. 已确认业务口径

普通UI
按原型信息结构,并复用系统全局样式和组件
技术前提
固定使用现金、补贴、赠送三张原流水表,查询层UNION ALL
统计汇总
只保留总入账、总出账、净变动
状态
业务卡点全部关闭,可进入开发准备
B01:删除两项数量汇总。
B02:删除发生时部门列和归属方式下拉框。
B03:流水号按账户前缀--log_id生成。
B04:业务单号按场景关联,缺失显示“--”。
B05:历史渠道/操作人不可推导时显示“未知/--”。
B06:不增加冲正关联、状态和质量字段,正负金额自然汇总。
B07:无赠送账户开关,当前版本统一展示赠送账户。
已确认:3 / 5
B01统计业务笔数怎么计算
影响同一业务可能产生现金、补贴、赠送多条流水,不去重会把一笔业务算成多笔。
建议口径按业务键去重;需要确认退款、冲正是否分别算独立业务。
B02部门发生时部门怎么保存(已确认)
可关联范围消费订单已有origin_department快照;退款可回到原消费订单。充值、提现等业务表没有部门快照。
确认口径能关联则关联;其他新流水在三表写快照;历史无法还原显示“--”,当前归属单独查询。
B03追溯三表流水号怎么展示(已确认)
影响三张表的log_id各自自增,直接展示可能出现重复流水号。
确认口径`CASH--{log_id}`、`SUBSIDY--{log_id}`、`GIFT--{log_id}`,查询层生成,不回写原表。
B04追溯业务单号怎么取(已确认)
影响现金、补贴通过scene+order_id关联业务表,赠送直接保存biz_order_no,来源不统一。
确认口径按场景关联业务单号;无法关联显示“--”,不生成假单号。
B05审计来源渠道和操作人怎么补(已确认)
影响三表字段不统一,历史数据中的渠道和操作人也不完整。
确认口径新流水写标准字段;历史能推导则映射,不能推导显示“未知/--”。
B06冲正冲正和历史异常怎么统计
影响原流水、冲正流水和历史不可拆分数据会影响总入账、总出账和净变动。
建议口径三表补关联、状态、质量字段;正反流水均展示,净变动自然抵消。
B07兼容未启用赠送账户的项目怎么展示
影响不是所有项目都具备赠送账户能力,固定展示可能产生无效筛选和错误汇总。
建议口径未启用时隐藏赠送选项,汇总只计算现金+补贴。
P01入口菜单层级和页签名称(已确认)
当前原型左侧“账户管理”高亮,顶部二级页签为“流水查询”。
确认口径在现有“账户管理”模块下新增“流水查询”Tab菜单,不新增左侧一级菜单。
P02筛选日期范围控件(已确认)
当前原型开始日期和结束日期并列,页面打开默认当天。
确认口径开始日期和结束日期默认当天,保留日期范围控件,不增加快捷日期按钮。
P03筛选人员查询输入框(已确认)
当前原型输入框占位文案为“姓名”。
确认口径人员查询只按姓名,占位文案保持“姓名”,不扩展工号或手机号。
P04筛选部门和归属方式(已确认)
当前原型“全部部门”旁提供“按发生时归属/按当前归属”切换。
确认口径两个控件都保留,默认选择“按发生时归属”。
P05筛选账户类型选项(已确认)
当前原型全部账户、现金、补贴、赠送。
确认口径保持原型名称和顺序:全部账户、现金、补贴、赠送。
P06筛选收支类型选项
当前原型全部收支类型、入账、出账。
核对建议确认使用“收支类型”,还是改成“收支方向”。
P07筛选业务单号/流水号输入框
当前原型业务单号和流水号共用一个输入框。
核对建议确认继续共用,还是拆成两个查询条件。
P08操作查询和重置按钮
当前原型蓝色“查询”和白色“重置”并列。
核对建议确认按钮顺序、重置后是否立即自动查询当天数据。
P09导出导出入口和确认弹窗
当前原型筛选区右侧“导出明细及汇总”,点击后出现范围和汇总预览。
核对建议确认按钮名称、位置和是否保留确认弹窗。
P10提示流水校验提示条
当前原型筛选区下方显示蓝色流水校验说明。
核对建议确认保留、精简或删除该提示条。
P11汇总五项统计卡片
当前原型业务笔数、账户变动条数、总入账、总出账、净变动。
核对建议确认五项全部保留、名称和排列顺序。
P12列表15个列表字段及顺序
当前原型序号至操作人共15列,操作人为最后一列。
核对建议逐列确认字段、顺序、宽度和是否需要固定关键列。
P13视觉金额正负号和颜色
当前原型入账绿色正数,出账红色负数,变化后余额加粗。
核对建议确认颜色、正负号和金额强调方式。
P14状态宽表、分页和空结果
当前原型宽表横向展示,底部分页;空结果提供重置筛选。
核对建议确认横向滚动、每页条数、分页位置和空状态文案。
P15交互行操作和详情入口(已确认)
当前原型无操作列、无查看按钮、无详情入口和详情抽屉。
确认口径保持当前变更原型,不增加行点击详情交互。

1. 结论

本方案只适用于本地钱包/访客用户,本期不新增统一流水表。继续使用 yoshop_user_balance_logyoshop_user_subsidy_logyoshop_user_gift_log,只为现金流水补充 balance_after。当前有效一卡通用户不查询、不汇总、不导出,也不参与历史回填。
识别并排除一卡通用户增加字段访客新业务写入访客历史回填开放查询与导出
一卡通配置用户身份访客流水查询现金历史回填
缺失、无效或关闭普通本地用户适用适用
缺失、无效或关闭历史曾映射用户按当前本地模式适用适用
已开启未命中当前有效映射的访客适用适用
已开启命中 business + staff_uuid/user_id 有效映射不适用禁止参与

身份判定复用现有访客财务查询和后端 UserGuard。配置缺失、无效 JSON 或关闭时按本地模式;配置开启但 business 映射冲突、数据库读取失败时停止,不能降级为访客。

2. 本期范围

本期实现
  • 访客三账户统一筛选、分页和明细
  • 期初、变动、变化后余额
  • 总入账、总出账、净变动、分账户汇总
  • 按筛选条件异步导出
  • 列表无发生时部门、操作、查看和详情入口
明确边界
  • 当前有效一卡通用户不进入本地钱包查询
  • 历史渠道/操作人不可推导时显示未知/--
  • 不增加冲正关联、状态和数据质量字段
  • 数据库版本不足通过SQL升级解决

部门筛选固定按当前部门;不统计业务笔数和账户变动条数。

3. 数据库变更

正式 SQL 放入 ai_api/db/<已确认版本号>.sql,版本号由发布计划确认。

ALTER TABLE `yoshop_user_balance_log`
  ADD COLUMN `balance_after` decimal(10,2) DEFAULT NULL
  COMMENT '变动后现金余额'
  AFTER `money`,
  ADD KEY `idx_store_user_time`
  (`store_id`, `user_id`, `create_time`, `log_id`);

首发使用 NULL。NULL 表示尚未回填或写入入口遗漏;0.00 表示真实零余额。稳定运行后再评审是否改成无默认值的 NOT NULL。

4. 访客新业务写入

事务顺序
锁访客用户 → 读期初 → 计算期末 → 更新余额 → 写流水 → 提交
统一公式
balance_after = balance_before + money
禁止行为
余额提交后再查询“当前余额”作为本条流水期末值;把一卡通用户改走本地钱包扣款

必须覆盖的访客入口

充值、后台充值、消费、退款、提现、提现失败返还、管理员调账、异常恢复、补偿任务、定时任务,以及 store/ai_api 中所有直接写 user_balance_log 的本地钱包入口。一卡通消费、退款和余额同步保持既有一卡通链路。

rg -n "user_balance_log.*insert|BalanceLog::add|new BalanceLog" \
  zhctproject/store/application \
  zhctproject/ai_api/app

5. 访客历史现金流水回填

新增 InitBalanceLogFields.php。先复用后端一卡通身份判断排除当前有效一卡通用户,再对访客反向还原。配置缺失、无效 JSON 或关闭时按本地模式;配置开启但身份数据库失败或 business 映射冲突时停止回填。

按访客 store_id + user_id 分组
cursor = yoshop_user.balance
按 create_time DESC, log_id DESC 遍历

当前流水.balance_after = cursor
cursor = cursor - 当前流水.money

只处理:

WHERE balance_after IS NULL
  AND log_id <= :cutoff_log_id

命令至少支持 check-only、dry-run、store-id、user-id、cutoff-log-id 和 page-size。当前有效一卡通用户即使存在本地历史流水也不得参与:其余额是第三方镜像,本地流水不保证完整。

6. 访客三账户统一查询

复用现有底座:GET /api/finance/visitor/flowsVisitorFlow.php 已实现身份快照、有效映射排除、高水位快照、复合游标及访客现金/补贴查询。本需求复用其身份范围与分页设计,不改变既有第三方接口契约。
统一字段现金补贴赠送
account_typecashsubsidygift
balance_beforebalance_after - moneysubsidy_balance_after - money原字段
balance_after新增字段subsidy_balance_after原字段
create_timeUnix 转 datetimeUnix 转 datetimedatetime

PC 服务只提供列表、汇总和导出,不提供详情接口;列表没有操作列或查看入口。异步导出复用 ydy_export_log

一卡通独立入口

若管理端需要查看一卡通资金记录,应读取 ydy_one_card_trade_orderydy_one_card_trade_attempt_logydy_one_card_trade_repair_log,展示第三方返回的现金/补贴前后余额、交易单号、状态和补偿记录。

7. 上线步骤

批次一:兼容 DDL

备份、只读预检后增加可空字段和索引,并回读确认实际状态。

批次二:访客代码发布

发布 store、ai_api 和受影响的 Work/定时任务代码。验证一卡通四模式身份矩阵;只要访客新流水仍有 NULL,就禁止回填。

批次三:访客维护窗口回填

暂停所有访客现金写入口、补偿与相关任务;冻结一卡通配置和映射变化,避免身份范围漂移。访客范围两次查询不再变化后记录 cutoff,先单用户、再单门店、最后分批全量。

批次四:校验与恢复

验证访客 NULL 为零、最新流水等于当前余额、相邻流水连续;同时验证有效一卡通用户未进入回填结果。通过后恢复业务并复验。

批次五:开放访客查询

后端身份过滤 → 接口 → 菜单权限 → PC 页面 → 异步导出 → 内部账号 → 正式角色。

完成口径分开记录:SQL_EXECUTED、SQL_VERIFIED、CODE_DEPLOYED、VISITOR_HISTORY_BACKFILLED、IDENTITY_MATRIX_VERIFIED、BUSINESS_SMOKE_PASSED、FEATURE_ENABLED。

8. 验收标准

  • 所有新增访客现金流水写入正确 balance_after。
  • 访客回填范围内历史现金流水无 NULL,余额链连续。
  • 访客三账户可统一筛选、分页和导出,汇总与明细一致。
  • 一卡通开启且命中有效映射的用户不进入访客查询、汇总、导出和回填。
  • 一卡通关闭时,历史映射用户仍按本地模式适用。
  • 一卡通开启但未命中映射的访客仍可使用本功能。
  • 配置开启但身份数据库失败或 business 映射冲突时停止;配置缺失、无效或关闭保持本地模式。
  • 复用既有访客身份和高水位分页设计,/api/finance/visitor/flows 第三方契约不变。
  • 充值、消费、退款、提现、补贴、赠送及一卡通四模式回归通过。

9. 回滚与停止规则

场景处理
代码异常回滚代码,保留可空字段。
回填异常停止当前批次,按批次/门店/用户/流水 ID 续跑,不全表清空。
页面异常关闭菜单或功能入口,不回退正确余额数据。
硬停止无备份、目标库不符、部分结构冲突、新代码仍写 NULL、无法真正停写。

10. 开发前待办

  1. 确认正式 SQL 的目标发布版本号。
  2. 确认维护窗口及受影响 Work/定时任务清单。
  3. 确认回填异常负责人、处理时限和是否允许部分门店先恢复。
  4. 确认稳定运行多久后评审 balance_after NOT NULL。

业务方案:已收口 当前状态:待开发准备