yml2213
|
c8b7e80979
|
perf(template): 补模板证据日期/覆盖索引,预览降到秒级
|
2026-10-26 16:43:56 +08:00 |
|
zhaoxing
|
7743d2019c
|
fix:优化再拼一次bug,优化打手端移动端拼单列表显示
|
2026-10-26 16:36:26 +08:00 |
|
yml2213
|
2b967ddd4c
|
feat(cost-center): 商品初始化/回填增加时间范围,默认最近 30 天
- 接单模板初始化预览/执行支持 dateFrom/dateTo,只使用范围内工单证据;
范围外模板不再先建商品
- 按工单回填商品支持时间范围;人工商品归一 UI 传时间范围
- 模板初始化重置只清理范围内导入映射/订单项,避免误伤范围外数据
- 初始化/回填默认最近 30 天,自动发货仍固定 30 天
- 文档更新初始化口径与页面操作
|
2026-10-26 16:26:48 +08:00 |
|
yml2213
|
288a0526ad
|
perf(cost-center): 建索引后立即刷新统计信息
|
2026-10-26 16:08:06 +08:00 |
|
yml2213
|
25012c30f4
|
perf(cost-center): 商品页跳过无关 affiliate 聚合并补部分索引
|
2026-10-26 16:04:52 +08:00 |
|
yml2213
|
f0dda3842b
|
test(worker): 校验拼单验收统一收口函数的寄卖钩子
|
2026-10-26 15:51:38 +08:00 |
|
yml2213
|
6dc1e7e727
|
fix(scheduler): 成本财务同步默认回退最近 7 天,避免小库语句超时
|
2026-10-26 15:49:51 +08:00 |
|
zhaoxing
|
2bfcdd5b1f
|
Merge branch 'dev1023' into dev
|
2026-10-26 15:26:43 +08:00 |
|
yml2213
|
6b0078f680
|
fix(finance): 收口快手退款路由并修复销售事实变更后的总账同步
- 平台退款路由从通用订单路径改为
POST /api/v1/admin/kuaishou-industry/orders/:orderId/refunds/approve-and-record,
服务改名 approveAndRecordKuaishouRefund,明确仅快手 91
- 总账同步改为未关账期间按日整体重建销售凭证,解决收入回填/退款重算后
旧凭证金额不更新的问题;删除与重建放在同一事务,已关账期间保持不动
- 文档明确 revenue:backfill 是存量订单退款的前置条件:
revenue_amount_fen=0 会导致退款登记按钮置灰
- 本地生产副本已执行 revenue:backfill:375,447 行全部回填,
order 375483 可退金额恢复为 237.00 元
验证:backend check 844(840 pass / 4 skip);frontend check 172 + build;
集成测试通过(代录、总账平衡、关账阻断、对账)。
|
2026-10-26 13:48:53 +08:00 |
|
yml2213
|
62763ddf0c
|
feat(finance): 支持代录指定客服账户,并上线影子总账/对账/关账/快手平台退款
- 人工确认履约:管理员/财务/运营可传 fundAccountId / creditOwnerAdminUserId
指定客服备用金/积分账户;客服仍强制本人账户
- 新增迁移 112:finance_accounts / journal_entries / journal_lines /
periods / reconciliations / reconciliation_items,种子 11 个科目
- 影子总账:销售事实按日生成收入/退款/成本凭证,支持手工凭证、试算平衡;
不接管钱包余额;总账同步接入定时任务与退款重算
- 期间关账/反关账:关账先补凭证并校验试算平衡,closed 期间禁止新增凭证
- 平台对账:JSON 账单导入,按 provider + platform_order_id 匹配订单/退款,
标记 matched/amount_mismatch/missing_order/missing_refund/duplicate
- 平台退款:快手行业(91)同意退款 API 接入,成功后落 source=platform;
抖音/拼多多返回 501,保留手工退款
- 新增后台「财务 → 总账与对账」页面(总账/期间/对账三个 Tab)
- 集成测试扩展到代录、总账平衡、关账阻断、手工凭证、对账匹配
验证:backend check 844(840 pass / 4 skip);frontend check 172 + build;
迁移 112 在 scratch 库全量执行并重跑幂等;本地生产副本已升级到 112,
销售事实同步 56 条凭证,借贷合计 1,885,351,864 = 1,885,351,864。
|
2026-10-26 13:32:47 +08:00 |
|
yml2213
|
a3e2bdb7c4
|
feat(finance): 人工成本单事务/幂等 + 配置自动匹配 + 缺成本监控
- 确认履约改为单事务:锁订单项 → 复查快照 → 扣积分/备用金 → 写成本快照;
快照失败整体回滚,不再出现「钱扣了、成本没记」
- manual_case 的 subject_id 统一为 order_item_id,新增订单项级唯一索引(迁移 111),
消除 manual_expenses.id / platform_credit_entries.id 跨表撞车
- 人工 SKU 匹配增加 sku_code / sku_name 兜底;保存配置立即回填最近 30 天,
定时任务按窗口 rematch,确认时再按 SKU 兜底匹配
- 新增 manual_cost_missing 异常队列:从首次人工配置起算,确认履约立即收口
- 补单元测试与真实 PostgreSQL 集成测试(并发、重复、强制快照失败回滚、双资金链路)
- 校准财务文档并新增上线初始化/验收手册(历史人工不补录,只保证配置后的新单)
验证:backend typecheck/lint/format/check:sql/test 843(839 pass / 4 skip);
frontend typecheck/lint/test 172;迁移 111 在 scratch 库全量执行 + 重跑幂等。
|
2026-10-26 13:04:51 +08:00 |
|
zhaoxing
|
2c9f741873
|
fix:撤单之后 重新指派给你同一个打手 同一个订单 不显示订单号不显示任何信息
|
2026-10-26 12:41:07 +08:00 |
|
zhaoxing
|
6a5a8d70b0
|
feat:拼单订单新增一个取消部分的按钮功能,点击之后,打手进行中和待接单的都会取消订单
|
2026-10-26 12:15:52 +08:00 |
|
yml2213
|
73908119dc
|
style(backend): 修复 4 个文件的 Prettier 格式告警
仅按仓库 Prettier 规则换行/去多余空行,无逻辑变更:
- routes/admin/cost-center-catalog.ts
- services/cost-center/affiliate-dash-prices-baseline.ts
- services/cost-center/affiliate-product-service.ts
- services/cost-center/product-catalog-service.ts
验证:backend format:check / typecheck / lint / check:sql 通过,
tests 833 pass(3 skipped);frontend format:check 通过。
|
2026-10-26 12:13:08 +08:00 |
|
yml2213
|
31a8b6fc65
|
Merge branch 'dev1023' into dev
解决 9 个冲突文件,并修复合并后遗留问题:
- 大厅候选集:采用 FIFO 窗口 + 全部置顶单 UNION(列表与抢单/拼单复核同源)
- 拼单份额:采用多次参与模型(每次参与 INSERT 新份额、requestId 幂等),
取消后可重新参与;移除 HEAD 已废弃的单行 rejoin 逻辑与对应测试
- 工单迁移与成本中心 103–108 编号撞车:合并重写为
109_work_order_share_participation / 110_work_order_hall_and_shop_indexes;
临时库全量执行与重跑幂等验证通过(10 列、唯一键已删、7 个索引)
- 实时补丁:保留个性化字段、置顶重排、分页总数同步;补回 orderTimelineVisible 类型
- 打手大厅:保留 memo 组件化,移植「再拼一次」多份额按钮逻辑
- 全项目表格统一 PercentTable:WorkerOrderShareTable 改造
验证:backend typecheck/lint/check:sql/test(833 pass)、
frontend typecheck/lint/test(172 pass)/build 全绿。
|
2026-10-26 12:10:53 +08:00 |
|
zhaoxing
|
42961dd789
|
fix:打手端/我的订单/验收:验收视频和验收图片至少上传一个就好了,其他逻辑按照上传图片走
|
2026-10-25 16:48:26 +08:00 |
|
zhaoxing
|
60fe00b28c
|
fix:打手端/我的订单/验收:验收视频和验收图片至少上传一个就好了,其他逻辑按照上传图片走
|
2026-10-25 16:45:38 +08:00 |
|
yml2213
|
12f370de15
|
feat(cost-center): 将统计与自动发货同步统一收敛至最近一个月并自愈历史非标SKU
- 范围收敛:将财务日期范围默认窗口、自动发货履约任务扫描、成本快照重算及定时任务默认窗口统一收敛为最近一个月(30 天),不再扫描混乱的历史遗留数据
- 脏数据清洗与自愈:在自动发货同步与基线导入时自动识别并清理历史把中文名当做 SKU 插入的 21 个非标脏商品,将关联的 116 个订单项平滑重定向至标准 38 款基线商品
- 标准提取:从履约任务 context_json 中按优先级提取标准上游 sku,通过正则仅允许合规英数标识符入库,避免中文名称污染商品目录
- 界面对齐:前端销售毛利概览默认查询最近 30 天,自动发货与目录改价追溯生效时间默认设置为近一个月(30 天前)
- 验证方式:全量单测 783 项通过、tsc 0 error、容器内执行同步后脏商品归零且销售事实精准重算
|
2026-10-25 16:24:50 +08:00 |
|
yml2213
|
e61d003342
|
fix(cost-center): 将自动发货价格基线转为内建常量并修复参数类型
- 提取并内建 38 条自动发货采购成本基线常量,消除生产镜像缺失 scripts 目录的 ENOENT 问题
- 在 jsonb_build_object 中增加 $5::text 类型显式强转,避免 Postgres 参数类型推断错误
- 增加同生效日期的版本就地更新逻辑,保障基线可重复无损导入
- 验证方式:npm run typecheck、npm test、生产镜像容器内真实触发导入接口返回 200
|
2026-10-25 16:03:16 +08:00 |
|
yml2213
|
b7ad69831a
|
feat(cost-center): 统一商品成本中心为全系统唯一标准价格源并闭环改价与工单同步
- 核心架构:将商品与成本中心确立为全系统唯一标准价格源,接单模板价格在接单平台禁止编辑并提示收敛至成本中心,后端 saveAdminWorkProductRule 严格拦截价格篡改
- 改价与同步:标准商品目录与自动发货专属面板提供统一改价弹窗,支持追溯/立即生效/指定时间;改价后自动或手动将新价格同步至接单大厅待抢单工单,保持下游业务一致
- 缺陷修复:修复 cost_versions 追溯改价时因同生效时间违反 chk_cost_versions_period 检查约束及 uq_cost_versions_scope 唯一索引冲突的问题,采用 active 版本就地更新机制
- 分类树优化:工单二级分类树限定仅在工单来源展示,自动发货与人工客服彻底隐藏分类树并重置过滤条件
- 验证方式:通过后端 784 项全量测试、前后端 tsc 类型检查及前端生产构建打包
|
2026-10-25 15:21:34 +08:00 |
|
zhaoxing
|
d787d3c364
|
feat:抢单大厅数据排列优化
|
2026-10-25 14:41:13 +08:00 |
|
yml2213
|
88ba87efff
|
feat(cost-center): 总览统计支持按来源收敛
页面顶部的 6 张统计卡原本是全局口径:选了「自动发货」,商品数还是 2017、
异常数还是 108,314,和下面的列表对不上。
- overview 接口接受 scope(all / affiliate_dash / work_order / manual);
- 商品、映射、成本项、生效版本、待处理异常、未映射订单项全部按来源过滤:
商品看 canonical_sku 前缀(aff: / tpl:+wo: / man:),
成本项与版本看 cost_model,异常与未映射订单项看 order_items.fulfillment_mode;
- 额外返回 productTotalCount(全局商品数),供「全部」徽标使用,
避免切到单一来源后「全部」也被算成 49。
实测四种口径:
all 商品 2017 / 映射 4897 / 成本项 3 / 版本 712 / 异常 108314 / 未映射 53901
affiliate_dash 商品 49 / 映射 0 / 成本项 1 / 版本 0 / 异常 53204 / 未映射 0
work_order 商品 773 / 映射 4897 / 成本项 1 / 版本 711 / 异常 1209 / 未映射 0
manual 商品 1195 / 映射 0 / 成本项 1 / 版本 1 / 异常 0 / 未映射 0
|
2026-10-25 13:55:25 +08:00 |
|
zhaoxing
|
9c620d39cb
|
feat:拼单明细管理加一个撤份额的功能,指定数量
|
2026-10-25 13:44:34 +08:00 |
|
yml2213
|
39fe448b48
|
feat(cost-exceptions): 支持 --days=0 一次性归档
一次性清理需要「不按时间过滤」的语义,但 CLI 把 days 下限钳在 1:
本地库的 15.2 万条 resolved 异常是 17 小时前重建生成的,
--days=1 一条都命中不了,只能手写 SQL。
- --days=0 表示不过滤时间,归档全部已处理行(open 仍不归档);
- 执行时打印一次性清理提示,避免日常误用;
- 记录 2026-10-25 的实际清理结果:151,939 行 / 152 批 / 3.9 秒,
热表 260,253 → 108,314(全为 open),VACUUM FULL 后 155 MB → 51 MB,
归档表 61 MB,主键重叠 0 条。
验证:--days=0 --dry-run 返回 retentionDays=0、archivableRows=0(已清空)。
|
2026-10-25 13:34:09 +08:00 |
|
yml2213
|
ccc71e0aab
|
Merge branch 'main' into dev
|
2026-10-25 13:33:05 +08:00 |
|
yml2213
|
2fb7aae13f
|
feat(auth): 登录态改为滑动续期(后台 24h/7d,打手 7d/30d)
|
2026-10-25 13:28:58 +08:00 |
|
yml2213
|
81edf530db
|
fix(worker-platform): 拼单取消后可重入,大厅置顶始终优先
|
2026-10-25 13:08:19 +08:00 |
|
zhaoxing
|
a7a8634a96
|
feat:加一个网站发布公告会弹出来点确定我已知晓的弹窗;mock数据自动匹配接单模板;本地访问模式修改
|
2026-10-25 12:27:32 +08:00 |
|
yml2213
|
d90c066888
|
feat(cost-center): 成本异常 60 天归档
cost_exceptions 只增不减:本地快照 260,253 行(resolved 151,939 / open 108,314),
已处理的行只是审计痕迹,留在热表会拖慢「状态 + 时间」分页,并让唯一索引持续膨胀。
- 迁移 108:新增 cost_exceptions_archive(保留原 id 与时间字段,加 archived_at),
热表补部分索引 idx_cost_exceptions_archivable
(COALESCE(resolved_at, created_at)) WHERE status <> 'open',让每日任务不扫全表;
- cost-exception-archive-service:只归档 status <> 'open' 且超期的行,每批 1000 行,
DELETE ... RETURNING + INSERT 在同一语句内完成,单批原子,不存在「删了没归档」;
- data-retention 每日任务接入;保留期走 COST_EXCEPTION_RETENTION_DAYS(默认 60);
- 新增 npm run cost-exceptions:archive(--dry-run / --days / --batch-size)。
为什么 open 行不归档:open 是待办队列,超期不等于已解决,归档等于把问题藏起来。
验证:
- 3 条 resolved 回拨到 90 天前 → 归档 3 条,热表 resolved 151,939 → 151,936;
- 1 条 open 回拨到 90 天前 → 仍在热表,未被归档;
- 归档表保留原 id 与时间,archived_at 记录归档时刻;
- 恢复测试数据后计数回到 151,939 / 108,314。
|
2026-10-25 12:09:20 +08:00 |
|
yml2213
|
fcd9b607d4
|
refactor(cost-center): 共享层按职责拆为四个模块
cost-center-shared.ts 804 行同时装枚举、行类型、映射、归一化,任何一处改动都会
让 8 个引用方重新编译。按职责拆开,本文件退化为统一出口(export *):
- cost-center-constants.ts 131 枚举、常量、SQL 片段
- cost-center-types.ts 220 行结构与 DTO 类型
- cost-center-mappers.ts 250 行映射与口径判断(含 CostPreview)
- cost-center-normalizers.ts 254 入参归一化与断言
同时消掉一个类型环:CostPreview 用 ReturnType<typeof mapProduct> 反推 mapper 的
返回类型,导致 types → mappers → types 互指;CostPreview 随 mapper 一起放进
mappers,依赖恢复单向。
出口保持向后兼容,8 个引用方无需改动;71 个导出逐一比对无缺失。
验证:typecheck / lint / 773 测试通过。
|
2026-10-25 12:02:36 +08:00 |
|
yml2213
|
ad1e1bc884
|
perf(db): 收入口径回填改为分批脚本
迁移 104 里对 order_items 的全表 UPDATE 实测 34.4 秒(375,447 行),
远超默认语句超时 15s,单事务迁移会拖住启动甚至直接失败。
- 104 只保留 DDL 与索引/约束,删除全表 UPDATE;
- 新增 scripts/backfill-revenue-basis.ts:按 id 分批、幂等、支持
--dry-run / --batch-size / --max-batches(kebab 与 camel 两种写法);
- package.json 增加 revenue:backfill;
- migrate.ts 启动时做一次带索引计数,仍有 unknown 时打印告警并给出命令,
不阻塞启动;
- 文档补充回填步骤与「不执行的后果」。
验证:
- 实测 37.5 万行全表更新 34.4s → 脚本按批执行,单批 5000 行;
- 功能验证:单条订单项置 unknown → 脚本回填 → 金额与 basis 恢复正确;
- 启动告警验证:保留 1 条 unknown 重启 → 日志出现告警;回填后计数归零;
- 全新库从 102 迁移到 107 仍成功(2s)。
|
2026-10-25 12:02:26 +08:00 |
|
yml2213
|
f10fefc303
|
refactor(cost-center): 拆分模板引导与成本解析服务
两个千行级服务按「变化原因」拆开,函数体逐字保留:
template-bootstrap-service.ts 1407 行 →
- template-bootstrap-service.ts 745 preview/apply、映射计划、模板商品编码
- affiliate-product-service.ts 199 自动发货商品同步与 SKU 回填
- work-order-product-service.ts 467 接单平台商品回填与模板发单金额同步
cost-definition-service.ts 1382 行 →
- cost-definition-service.ts 727 成本项/成本版本/成本异常 CRUD
- cost-resolution-service.ts 680 预览、解析上下文、快照生成
依赖方向是单向的:CRUD 依赖解析层的 4 个校验/取值函数,解析层不反向依赖;
rebuildFactsForRange 因跨文件复用改为导出。
验证:9 个导出函数全部保留(无丢失),typecheck / lint / 773 测试通过。
|
2026-10-25 11:49:27 +08:00 |
|
yml2213
|
b033746172
|
refactor(admin): 成本中心路由按域拆分
cost-center.ts 从 898 行、48 个端点拆成 4 个子路由 + 54 行入口:
- cost-center-catalog 商品主数据、渠道映射、模板/自动发货/接单平台回填
- cost-center-cost 成本项、成本版本、快照、异常
- cost-center-manual 人工履约 SKU 配置
- cost-center-credits 客服平台积分钱包
入口只保留角色校验、overview/options 与挂载顺序;子路由路径仍是完整路径,
不需要再加前缀。
验证:
- 静态核对:拆分前后 (method, path) 集合完全一致,48 → 48;
- 运行时核对:遍历 Express router stack,仍注册 48 条 /cost-center 路由;
- 端点正文逐字保留,只有 import 与文件边界变化。
|
2026-10-25 11:49:21 +08:00 |
|
yml2213
|
26c70143db
|
refactor(admin): 路由请求助手去重
finance / fund / cost-center 三个路由文件各自复制了 sessionOf / idOf / bodyOf,
语义相同写法不同。统一到 routes/admin/request-helpers.ts,路由文件只保留业务
差异(fund.ts 的 accountIdOf / expenseIdOf)。
无行为变更:typecheck、lint、773 个测试全部通过。
|
2026-10-25 11:38:19 +08:00 |
|
yml2213
|
472769a977
|
refactor(db): 财务迁移收敛为 103–107
把 103–112 十个迁移收敛为五个,删除在「生产 102 → 当前」路径上的空操作与补丁:
- 108(下线人工支出登记)与 109(隔离历史快照主体)在生产库和重建库上都是空操作,
口径注释并入 104;
- 111 是给 104 自身种子打的补丁,合并后 104 直接写入 active 0 元占位;
- 112 的 cost_exceptions.resolution_note 并入 104,退款表独立为 106;
- 106(备用金编号可读化)与 110(积分钱包)合并为 107(人工履约资金层);
- 107(履约方式列)并入 105,履约方式本就是销售事实的维度键。
配套调整:
- check-sql-guard 改为以 main 为基线校验迁移字节,删除 103–114 的永久豁免;
未合并分支上的新迁移仍可重写,已发布迁移不可修改。
- 本地库原地改造脚本移入 docs/archive,禁止对新环境执行。
验证:清掉 schema_migrations 里 103–112 的记录后重跑,升级结果与全新构建的
schema 完全一致(pg_dump --schema-only 仅随机 token 不同),种子数据一致;
升级前后业务数据量不变(成本版本 713 → 712,差异来自删除占位草稿)。
|
2026-10-25 11:38:12 +08:00 |
|
yml2213
|
465a9f65dc
|
Merge remote-tracking branch 'gitea-aliyun/main' into dev
|
2026-10-25 11:14:12 +08:00 |
|
yml2213
|
7824170d3c
|
fix(finance): 支持生产快照升级并修复成本回填
修复生产 101 到 112 的迁移兼容问题;接单商品回填改为分批执行;修正未验收工单成本快照的 order_id/order_item_id 映射;更新本地生产快照数据基线。
|
2026-10-25 11:10:33 +08:00 |
|
yml2213
|
7fdef88ba6
|
perf(worker-hall): 优化百单大厅加载与渲染性能
|
2026-10-24 20:41:58 +08:00 |
|
yml2213
|
790de676c6
|
feat(admin): 收口人工履约入口并修复履约筛选
|
2026-10-24 17:42:07 +08:00 |
|
yml2213
|
faf56e567e
|
feat(finance): P2 手动退款登记与成本异常闭环
- 迁移 112:order_refunds(订单项级退款,整单拆多条共享 batch_no,source/external_ref 预留平台 API)+ cost_exceptions.resolution_note
- 新服务 order-refund-service:整单/指定商品退款、可退金额校验、撤销、全额退完同步 pay_status
- 销售事实改为按有效退款记录冲减;无记录时仍兼容 pay_status=refunded 的历史全额退款
- 订单详情新增退款登记与退款记录表,商品明细显示收入/已退/可退
- 全额退款自动关闭该订单项成本异常并写处理备注;成本异常处理改为带备注弹窗
- 财务事件 UNION 接入退款记录,文档同步 P2 状态与 API
|
2026-10-24 17:18:51 +08:00 |
|
yml2213
|
a78cc1f984
|
feat(finance): P1 人工商品归一,按内部 SKU 生成 man 商品并回填
- 新服务 manual-product-normalization-service:skuNick → outSkuSn → sku_code 兜底,按内部 SKU 生成 man:<sku> 商品
- 订单项按 id 分批(2 万/批)回填,避免 15s 语句超时;同步补齐人工成本快照的商品维度
- 新增 POST /cost-center/manual-products/normalize(支持 dryRun/日期窗口),成本中心「标准商品」加「归一人工商品」按钮
- 每日 cost_finance_sync 接入最近 N 天的增量归一
- 渠道映射未归一队列增加人工单提示:人工单不能用平台 sku_code 建映射
- 文档同步:P1 标记完成,补充归一接口契约与销售事实重算结果
|
2026-10-24 16:54:55 +08:00 |
|
yml2213
|
e5122d116a
|
feat(cost-center): 渠道映射改为诊断优先,新增未归一队列
- 顶部统计卡:标准商品 / 映射 / 未归一订单项 / 未归一 SKU 组
- 新增「未归一」队列:按来源+店铺+平台SKU+履约方式聚合,行内建映射并预填
- 目录表从 7 列精简到 4 列,匹配方式移入展开明细
- 回填订单项后自动把已归一的 product_mapping_missing 异常收口
- 新增 /cost-center/mappings/diagnostics 与 /mappings/unmapped,按履约方式拆分聚合避免全表扫描
|
2026-10-24 16:36:16 +08:00 |
|
zhaoxing
|
0ee5554f57
|
add:新增验证视频可选上传功能
|
2026-10-24 16:12:56 +08:00 |
|
yml2213
|
956ef5d695
|
refactor(cost-center): 精简成本中心,人工成本以 SKU 配置为唯一真源
- 删除「成本项目」「成本版本」「成本预览」三个 Tab:成本项只有 3 条系统内置,版本金额只是快照挂载点
- 新增只读「发单价格」面板,仅在接单平台来源显示,改价仍走接单模板后同步
- 成本预览改为弹窗,从成本异常行和订单详情「查成本」进入;人工单显示 SKU 配置成本并禁止生成快照
- 成本异常新增按原因聚合摘要接口,列表支持 reason/since 筛选,默认只看近 24 小时
- 迁移 111:把 sys_manual_service 的历史 ¥88 全局版本清零;预估同步与成本缺失判定排除 manual_actual
|
2026-10-24 16:07:25 +08:00 |
|
yml2213
|
a96229a106
|
feat(finance): 完善客服钱包与人工履约成本流水
|
2026-10-24 14:34:28 +08:00 |
|
yml2213
|
f0f8c92e67
|
fix(finance): 客服可读取自己的积分钱包
|
2026-10-24 13:47:53 +08:00 |
|
zhaoxing
|
25756901cc
|
add:新增同一个工单同一人可以多次拼单:抢单大厅优化
|
2026-10-24 13:44:34 +08:00 |
|
 yml2213andClaude Opus 4.5
|
0a743f00b1
|
feat(finance): 客服端「我的备用金」改为「我的钱包」,四平台并列
客服原来只能看到备用金现金,平台积分藏在 Tab 里且是空的。
现在四个钱包并列展示:南航积分 / 乐玩积分 / ROCK 积分 / 备用金现金。
后端:
- 客服查询积分账户时自动补建三个空账户,保证四个钱包始终并列展示,
不会出现「点了没反应」的空白卡片。
前端:
- 标题「我的备用金」→「我的钱包」,菜单同步改名。
- 顶部四张卡:三个积分平台各一张(显示积分余额 + 折合金额 + 换算率标签),
备用金现金一张。余额为 0 时置灰。
- 四个钱包卡片与备用金账户解耦:没开通备用金账户的客服也能看到积分钱包,
只是现金卡显示「尚未开通备用金账户」。
- Tab 调整为「积分流水 / 备用金流水 / 我的支出」,积分流水独立展示
(平台、类型、变动、余额、折合金额、备注、时间)。
- 备用金账户详情卡(账户编号、责任主管、状态、登记支出、缴回备用金)
仍然只在有账户时显示。
校验:后端 765 项 / 0 失败,前端 143 项全通过(含 lint、tsc -b、build)。
Co-Authored-By: Claude Opus 4.5 (1M context) <noreply@anthropic.com>
|
2026-10-24 13:36:38 +08:00 |
|
 yml2213andClaude Opus 4.5
|
d07d88e25c
|
feat(finance): 积分钱包操作 + 客服「确认履约」闭环
把「配置 → 待办 → 确认履约 → 扣额度 → 写成本快照」整条链路打通,
客服点一下就完成履约,不需要填复杂的东西。
积分钱包(P1.3):
- platform-credit-service.ts:充值 / 调整 / 消耗 / 流水查询。
- 三平台积分互不通用,每客服每平台一个账户;余额只能由流水产生,
消耗不足直接拒绝(409),不允许负余额,与备用金口径一致。
- 换算率按平台:南航、乐玩 1 积分 = 1 分,ROCK 1 积分 = 1 元。
- 充值 / 调整只对 admin/operator/finance 开放;客服只能看自己的钱包。
- 备用金现金不在这里,走现有 fund_* 链路。
确认履约(P1.4):
- manual-fulfillment-service.ts:待办列表 + 确认履约。
- 待办口径:order_items.fulfillment_mode='manual' 且已配 fulfillment_config_id。
人工单**不建 fulfillment_tasks**——那是自动发货通道的体系,人工单历来不走它
(本地 102,955 个人工单的任务行数为 0)。
- 「已履约」判定:该订单项存在有效 manual_case 成本快照。
- 固定成本(消耗积分 > 0)→ 零输入;成本不固定(= 0)→ 只填实际成本金额。
- 确认时:积分平台扣积分钱包、备用金现金走 writeFundExpense,
随后写 actual 成本快照(主体 = 积分流水 id 或备用金支出单 id)。
- 渠道与消耗积分永远提前配好,客服不选;重复履约直接拒绝。
前端:
- 新增「人工履约」页(客服菜单):待确认 / 已履约 / 全部,确认履约弹窗。
- 备用金页新增「平台积分」Tab(客服端与管理端各一份):
余额卡片、积分流水、管理员充值与调整。
E2E 实测:配置 ROCK 100 积分 → 成本 ¥100.00(1 积分 = 1 元);充值 5000 积分
= ¥5000;确认履约后积分 5000 → 4900,成本快照 actual ¥100.00 写入;
重复履约被拒绝。测试数据已清理,登记表保留 357 条扫描结果供运营使用。
校验:后端 765 项 / 0 失败,前端 143 项全通过(含 tsc -b 与 build)。
Co-Authored-By: Claude Opus 4.5 (1M context) <noreply@anthropic.com>
|
2026-10-24 13:21:34 +08:00 |
|
 yml2213andClaude Opus 4.5
|
4bcb4e6b57
|
feat(finance): 人工履约 SKU 配置清单 + 四钱包(南航/乐玩/ROCK积分 + 备用金现金)
客服人工履约有四个钱包,成本与渠道在后台配置好,客服确认履约时零输入。
口径(2026-10-24 确认):
- 四个钱包:南航积分 / 乐玩积分 / ROCK 积分 / 备用金现金。三平台积分互不通用,
每客服每平台一个积分账户;现金复用现有 fund_accounts / fund_entries。
- 积分换算率按平台不同:南航 1 积分 = 1 分,乐玩 1 积分 = 1 分,
ROCK 1 积分 = 1 元(100 分)。真源是履约档案 config_json.rechargeUnitPriceFen。
- 积分是货币,幸运币是商品;消耗积分与成本金额按换算率一一对应。
- 配置主键是**内部 SKU**(快手 spec_json.skuNick / 拼多多 spec_json.outSkuSn),
不是商品标题(标题是引流)。同名 SKU 算同一商品,跨渠道共用一份配置。
- 配置链路没有匹配引擎、没有打分:扫描 → 配置 → 重新匹配。
10 月口径下人工单 17,469 单 / 357 个内部 SKU,Top 50 覆盖 88% 单量。
更早的老单没配置意义,不纳入统计口径。
- 消耗积分填 0 = 成本不固定,客服在确认履约时手填实际成本;
渠道始终提前配好,客服不选。
迁移 110:
- manual_sku_registry:扫描到的内部 SKU 登记表(统计 + 配置状态)。
- manual_fulfillment_configs:内部 SKU → 渠道 + 消耗积分 + 成本模式。
- platform_credit_accounts / platform_credit_entries:三平台积分钱包与流水。
- order_items.fulfillment_config_id:订单项挂配置,重新匹配时回填。
- 4 条 manual_* 履约档案(manual_dispatch 执行器 + config_json 区分平台)。
不复用 kuaishou_ct_assisted / kuaishou_feifei——那是已下线的历史自动发货通道。
性能:spec_json->>'skuNick' 无索引时扫描 2.4s / 回填 5.4s;
新增 idx_order_items_manual_internal_sku 表达式索引后回填降到 1.7s。
后端:manual-fulfillment-config-service.ts(扫描/清单/配置CRUD/重新匹配),
成本中心挂 7 个接口。
前端:成本中心新增「人工 SKU 配置」Tab(扫描、清单、配置弹窗、重新匹配)。
校验:后端 765 项 / 0 失败(含 check:sql 迁移护栏),前端 143 项全通过;
E2E 实测扫描 357 个 SKU、配置四平台换算正确、重新匹配回填 7,604 个订单项;
本地库迁移 110 执行后数据量与改造前一致。
Co-Authored-By: Claude Opus 4.5 (1M context) <noreply@anthropic.com>
|
2026-10-24 13:12:46 +08:00 |
|