yml2213
|
861524a91a
|
docs(finance): 校准代录与本地迁移基线到 112
|
2026-10-26 13:33:25 +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
|
f0eb8a5e05
|
docs(finance): 补充责任主管前置与客服账户初始化步骤
|
2026-10-26 13:05:46 +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 |
|
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 |
|
yml2213
|
55a3e0df9c
|
refactor(admin-ui): 成本中心导航收敛为 4 个固定 Tab
原结构是「4 个来源 Tab(内容只有一句提示语)× 6 个内容 Tab」,
且来源 Tab 会增删内容 Tab:选「自动发货」后标准商品/渠道映射/发单价格直接消失,
切换来源还会强制跳转。用户反馈「逻辑不顺、很多 tab 没必要」。
- 来源改为工具栏 Segmented:只筛数据,不改变导航;Tab 永远 4 个
标准商品 / 渠道映射 / 成本配置 / 成本异常;
- 自动发货 SKU、发单价格、人工 SKU 配置合并为「成本配置」,
选「全部」时给三个入口卡片,选具体来源时直接渲染对应面板;
- 自动发货 SKU 原本是标准商品的同数据子集(同一个接口 + carrierType),
合并后不再有重复入口;
- 渠道映射在自动发货/人工来源下改为说明性提示,不再展示空表;
- 异常徽标改用当前来源的计数,不再出现「徽标 10 万、列表几百条」;
- refreshAll 改为按 queryKey 前缀失效,修好漏刷
(诊断、未归一队列、人工 SKU 等 5 个查询);
- 删除 Context 里 12 个从未被读取的字段(products/versions/exceptions 等
空数组与 loading 常量),注释改为与实现一致;
- 「生效发单价格」改名「生效成本版本」——它统计的是全部 active 版本,
按来源过滤后叫发单价格会误导。
验证:后端 786 测试、前端 lint/typecheck/test/build 通过。
|
2026-10-25 13:55:36 +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
|
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
|
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
|
0099597b0d
|
docs: 迁移编号同步为 103–107 并校准分支状态
- 全量替换文档里的旧迁移编号:106→107、107→105、108/109/111→104、112→106、110→107;
- 删除 113/114 的残留引用(这两个编号从未落地);
- 分支状态校准为 `dev @ 465a9f65 + 迁移收敛`,本地库按「清 103–112 记录后重跑」对齐;
- 成本中心与履约模型 §一 重写迁移基线表,§八 改为迁移基线与本地库同步;
- 归档原地改造脚本的索引补登记。
|
2026-10-25 11:38:18 +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
|
7824170d3c
|
fix(finance): 支持生产快照升级并修复成本回填
修复生产 101 到 112 的迁移兼容问题;接单商品回填改为分批执行;修正未验收工单成本快照的 order_id/order_item_id 映射;更新本地生产快照数据基线。
|
2026-10-25 11:10:33 +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 |
|
 yml2213andClaude Opus 4.5
|
fb679d76f6
|
refactor(finance): 人工成本收敛为「人工录单 → 扣备用金 → 写快照」
公司人工支出登记单与审批报销状态机整链下线,人工成本只留一条链路。
口径调整(2026-10-23 确认):
- 历史人工支出找不回来,直接放弃:不补录、不做样本校准、不做均价估算,
只保证上线后的新单不丢。
- 人工成本逐单按实际金额,从客服备用金扣款,客服只能用本人账户;
没有登记单、没有审批、没有报销,录入即计入毛利。
后端:
- 新增 services/finance/manual-order-cost-service.ts:扣备用金 + 写 actual
成本快照,同一事务,余额不足直接拒绝不允许负余额。
- 成本快照主体从「人工支出登记单 id」改为「客服备用金支出单 id」
(subject_type='manual_case',subject_id=manual_expenses.id)。
- 删除 services/finance/manual-expense-service.ts(1263 行)与
routes/admin/finance.ts 下 /finance/manual-expenses* 全套接口。
前端:
- 删除 AdminManualExpensePage.tsx(778 行)与 /admin/manual-expenses 菜单页。
- ManualOrderCostModal 去掉「提交审核 / 立即计入成本」开关,录入即生效。
- 新增 services/admin/manual-order-cost.ts。
迁移:
- 106_manual_expense_records.sql → 106_fund_account_no_readable.sql,
只保留备用金账户编号可读化。
- 108_drop_manual_expense_records.sql:删除 manual_expense_records 与
manual_expense_events 两张表。
- 109_isolate_legacy_manual_snapshots.sql:把来源为旧登记链的历史孤儿快照
subject_id 改为负数,与 manual_expenses.id 彻底隔离。
踩坑修复(E2E 实测发现):主体 id 换空间后与历史孤儿快照撞唯一索引
uq_cost_snapshots_active_subject_item,INSERT ... ON CONFLICT DO NOTHING
静默跳过,导致「钱从备用金扣了、成本快照却没写成」。修法是迁移 109 隔离
legacy 主体 + 后端快照写失败必须抛错回滚(409),杜绝账实不符。
文档:现行 5 篇 + README 基线校准为 dev @ 43f402cf + 迁移 103–109,
修正已删除的旧迁移号,删除「人工支出登记 + 审批 + 报销」口径,
已作废 DDL 草案移入 docs/archive/2026-10-23/。
校验:后端 765 项 / 0 失败(含 check:sql 迁移护栏),前端 143 项全通过;
E2E 实测两笔同订单项各自独立主体、余额扣减与快照金额一一对应;
本地库迁移 108/109 执行后数据量与改造前完全一致。
Co-Authored-By: Claude Opus 4.5 (1M context) <noreply@anthropic.com>
|
2026-10-24 11:31:29 +08:00 |
|
yml2213
|
43f402cf72
|
docs(finance): 现行财务文档收敛为 5 篇,履约口径只定义一次
原 9 篇 3,647 行,履约分类口径在总纲、模型文档、交接总结里重复三遍,
且仍留着"三块履约""按小时人工成本"等已作废表述。本次收敛为 5 篇
1,778 行:
- 财务与履约口径总纲-2026-10-23.md(300 行):唯一口径来源
七条硬口径、三个正交维度、真实履约构成、成本模型规则、人工全覆盖、
实施顺序、进度、验收 SQL、防回归清单
- 成本中心与履约模型.md(471 行):数据模型、迁移 103–107、履约回填、
销售事实、本地库原地改造、索引与性能
- 成本中心API契约.md(270 行):字段替换总表、枚举、前后端模块边界
- 人工支出与备用金.md(218 行):人工支出登记字段/状态机/权限 +
客服备用金台账
- 财务系统集成方案.md:复式总账层(未实施)
旧的 4 篇(成本中心与三块履约模型、人工支出登记落地方案、
客服备用金台账实施方案、财务履约改造交接总结)移入
docs/archive/2026-10-23/ 并加归档提示。
履约分类判定 SQL 只在总纲保留一份,其它文档改为链接。
|
2026-10-23 16:06:40 +08:00 |
|
zhaoxing
|
1d5615f1ae
|
add:新增同一个工单同一人可以多次拼单
|
2026-10-23 15:14:07 +08:00 |
|
yml2213
|
7557de6d60
|
docs: 校正分支提交数表述
|
2026-10-23 13:36:47 +08:00 |
|
yml2213
|
b629cd27d8
|
docs: 记录 P0 履约事实落地结果
|
2026-10-23 13:36:25 +08:00 |
|
yml2213
|
fb80cad695
|
docs: 统一财务与履约口径并新增总纲
|
2026-10-23 13:17:30 +08:00 |
|
yml2213
|
fac34c8420
|
feat(fund): 备用金账户编号改为带用户名的可读编号
|
2026-10-23 11:57:39 +08:00 |
|
yml2213
|
a7f60414a4
|
fix(finance): 客服只能使用自己的备用金账户
|
2026-10-23 11:44:04 +08:00 |
|
yml2213
|
2aeb789e20
|
feat(finance): 人工支出改为从客服备用金扣款
|
2026-10-23 11:31:47 +08:00 |
|
yml2213
|
74b62f3494
|
feat(finance): 订单页人工录单按单实际金额计入成本
|
2026-10-22 19:48:56 +08:00 |
|
yml2213
|
7c8832078f
|
feat(finance): 接单模板发单金额落规则级成本版本
此前接单平台成本版本只有 sys_work_order_reward 的全局 0 元占位,662 个模板的发单金额从未进入 cost_versions。\n\n现在为 662 个模板各生成一条规则级版本:634 条固定发单金额 + 28 条按件单价;全局 0 元版本仅作“按工单实际结算”占位。成本版本页新增“用户实付均价”和“平均实发/项”,支持按模板名称/规则键搜索,按商品筛选也能命中规则版本。\n\n历史工单快照关联到对应模板版本;模板保存时自动同步单条成本版本;删除模板会先把历史版本脱钩停用,保留快照可追溯。\n\n新增迁移 112 覆盖索引,用户实付聚合从约 1.1s 降到约 150ms。
|
2026-10-22 19:29:53 +08:00 |
|
yml2213
|
72e1141c8a
|
feat(finance): 补齐自动发货与接单平台成本和对账
自动发货:价格导入支持 --effective-from,把首次基线版本回填到历史起点;41,676 个订单项全部归一并生成采购成本快照,缺失 0。\n\n接单平台:新增按工单 product_rule_id 回填商品的接口与按钮,长尾项按 provider+shop_id+sku_code+normalized_sku_name 补建 wo: 商品和 sku_code_name 渠道映射;118,053 个订单项全部归一。\n\n成本:已验收工单按 reward_amount 写 actual;未验收但已确定报酬的工单写 estimated,验收后升级。全量 95,870 actual + 21,217 estimated,actual 与 reward 0 差异。\n\n剩余 966 条取消/零报酬工单保留在成本异常队列,不自动记 0;人工块未改动。\n\n实测自动发货与接单平台未归一收入均为 0;整体未归一 79.67% 降至 57.54%,全部来自人工块。
|
2026-10-22 18:59:53 +08:00 |
|
yml2213
|
54d2eb2f59
|
feat(finance): 自动发货订单项按上游 SKU 直接归一
自动发货只有 affiliate-dash 单一上游渠道,订单项直接按 fulfillment_tasks.context_json.skuCode 归一为 aff:<skuCode>,不写 channel_product_mappings。\n\n新增 /cost-center/affiliate-products/backfill:按 order_item_id 取最新任务 SKU 回填 canonical_product_id,只更新有变化的订单项,并自动重算受影响日期的销售事实;返回 updatedCount/skippedCount/remainingCount。\n\n自动发货 SKU 列表改为实时统计履约任务数与最近履约时间,不读会被价格导入覆盖的 attributes_json。\n\n本地实测 41,676 个订单项全部归一,自动发货未归一收入 5,089,712.26 元降至 0;整体未归一占比 79.67% 降至 60.47%。
|
2026-10-22 18:41:31 +08:00 |
|
yml2213
|
0889235870
|
feat(finance): 完成成本快照运行层、销售事实与人工支出登记
迁移 108-111:快照业务时间与预估转实际、销售事实表、系统成本项、公司人工支出登记。接单平台按工单实际 reward 入账;人工支出支持登记/审批/驳回/报销并写 actual 快照。新增销售毛利页、人工支出页与订单入口。
|
2026-10-22 16:41:03 +08:00 |
|
yml2213
|
aee0e4d1d2
|
docs: 同步财务进度、成本中心迁移号与 feat 分支状态
|
2026-10-22 15:19:53 +08:00 |
|
yml2213
|
78580c6165
|
feat(cost-center): 成本项编码改系统自动生成,补自动发货价格导入脚本
- 新建成本项目不再手填编码:后端按成本类型生成基础编码(auto_purchase /
work_order_reward / manual_service / platform_fee / payment_fee /
after_sales_loss / shipping_other / other_cost),重复时追加 _2、_3;
接口显式传 code 时仍优先使用,兼容脚本导入
- 前端移除编码输入框,改为说明提示,创建成功提示展示生成的编码
- 新增 scripts/sync-affiliate-dash-prices.ts + scripts/data/affiliate-dash-prices.json:
按上游 38 条自动发货价格补建 aff:<sku> 商品,并按 cost_amount(分)生成
scope=product 的按件成本版本;价格变化时停用旧版本再插新版本
- 自动发货商品同步与价格导入的 attributes_json 改为合并,避免互相覆盖
|
2026-10-22 15:07:29 +08:00 |
|
yml2213
|
b520a078b0
|
feat(cost-center): 商品与成本按履约载体分区,补充分页与删除能力
- 新增迁移 107_product_catalog_carrier:product_catalog 增加 carrier_type,
自动发货只认 fulfillment_tasks.executor_key='affiliate_dash' 的履约证据
(28 个上游 SKU),接单模板商品统一归为 work_order(662 个)
- 页面按「全部 / 自动发货 / 接单平台 / 人工客服 / 共用成本」分区;
自动发货只展示自动发货 SKU 列表与采购成本,不展示商品目录/渠道映射
- 新增「同步自动发货商品」接口与按钮,按 aff:<skuCode> 幂等补建
- 列表统一接入公共分页 buildAdminTablePagination,支持 10/20/50/100 每页条数
- 标准商品、自动发货 SKU、渠道映射、成本项目、成本版本支持删除,
带引用保护(映射/版本/快照/订单/接单规则)与生效版本先停用约束
|
2026-10-22 14:05:34 +08:00 |
|
yml2213
|
8f3babdabe
|
chore(db): 成本中心迁移重编号到 main 之后(103–106),check:sql 允许纯重编号
|
2026-10-22 12:42:59 +08:00 |
|
yml2213
|
3e73289e31
|
merge: 合并 main 到 feat/cost-center-wip(同步抖音券、设备认证与图标等最新改动)
|
2026-10-22 12:40:18 +08:00 |
|
yml2213
|
33b220ae10
|
fix(dcauth): order_site 白名单补充生产域名 ks.khhao.com
|
2026-10-22 10:04:05 +08:00 |
|
yml2213
|
ef36453694
|
feat(dcauth): 移除机器码,改用纯设备码认证
- DCAuth 协议升级到 v2,签名原文只含设备码;客户端 2.0.0,旧版本返回 426
- 删除客户端机器码采集、后端 machine_code_* 字段与日志、后台机器码展示
- 102 迁移在生产执行前直接改为无机器码结构;SQL 守卫仅放行该文件
- Mock 短信不启用每日限额;修复慢电脑首次启动的协议转发竞态
- 新增 macOS DCAuth.app 打包脚本,注册 dcauth:// 协议,浏览器可直接唤起
|
2026-10-21 20:46:25 +08:00 |
|
yml2213
|
040100f290
|
feat(dcauth): 新增后台手机号与设备认证登录
登录链路改为账号密码 + 短信验证码 + DCAuth 设备签名,并新增后台手机号绑定、
登录日志、设备绑定与重置接口。
|
2026-10-21 20:46:24 +08:00 |
|
yml2213
|
111bc76357
|
feat(cost-center): 成本中心与商品映射开发草案 (含文档与订单页调整 WIP)
|
2026-10-20 10:01:52 +08:00 |
|
yml2213
|
7542d547bf
|
feat: 新增客服备用金台账与后台用户中文显示名
- 新增备用金账户、流水、支出、对账与权限
- 后台用户支持中文显示名并同步备用金姓名
- 审计、登录记录、任务及工单操作人优先展示中文名
- 补充备用金与人工支出方案文档
|
2026-10-18 13:55:24 +08:00 |
|
yml2213
|
7bacb7d5eb
|
docs: 重构项目文档并补充三块载体、成本中心与人工支出方案
合并本轮全部文档改动(原 5 个 docs 提交压成 1 个)。
口径与索引:
- 新增 docs/README.md 文档总索引:三来源口径(91 + 快手 send-code = kuaishou-91)、
「一个订单 = 骨架 + 买家凭证 + 一个执行载体」、成本只改一处、文档状态机
- 过期阶段文档移入 docs/archive/2026-10-08/(保留内容,不删除)
分析报告:
- docs/项目全量分析报告-2026-10-17.md:架构、五条业务链路、P0/P1/P2 风险与改进路线
- docs/载体判定与成本中心落地-复核与草案-2026-10-17.md:生产只读克隆量化、上一轮结论复核与 4 处修正
方案文档:
- docs/成本中心与三块履约模型.md:三块执行载体、标准商品、成本版本与快照、人工支出登记
- docs/财务系统集成方案.md:复式记账模型、分录表、分期落地
- docs/影子总账说明.md:影子期与转正期的边界、对账与转正标准
SQL 草案(docs/drafts/,未接入迁移):
- 载体判定与人工块量化.sql:量化查询、carrier_type 判定与回填、守恒校验
- 成本中心与销售事实-DDL草案.sql:product_catalog / channel_product_mappings /
cost_items / cost_versions / cost_snapshots / cost_exceptions / sales_daily_facts
- 人工支出登记-DDL草案.sql:manual_fulfillment_cases / manual_expense_records / manual_expense_events
业务口径确认(2026-10-17):
- 收入 = 用户实付(orders.total_amount),与快手 paymentFen 数据核验 100% 一致
- 打手报酬 = 支出/成本(最终提现打款),按总额法
- 人工块以「支出可追溯」为先,SLA 监管延后
- 退款/仲裁暂未接入,先预留字段与反向冲正关系
三份草案已在一次性沙箱库按依赖顺序零错误应用(10 张新表、27 个 CHECK 约束)。
|
2026-10-17 22:03:03 +08:00 |
|
yml2213
|
6850bc64ff
|
feat(work-order): 发布并核销支持抖音券(按来源分流,抖音走 DYC 券核销)
|
2026-10-15 13:22:18 +08:00 |
|
yml2213
|
10464fea89
|
refactor(product-match): 抽离接单模板匹配引擎(来源适配器/引擎/价格收口 + 后台按订单项试匹配)
新增 services/product-match:来源适配器(kuaishou-91 合成 91+快手 / pdd / douyin-mashida)+ 平台无关匹配上下文 + 条件打分引擎(并列最高=ambiguous 不猜、逐维诊断)+ 价格数量拼单唯一实现。
- 商店键命名空间化(kuaishou:/pdd:/douyin:),店铺为可选作用域:留空即可按订单信息匹配
- 抖音匹配文本只取内部 SKU,引流标题只进 promoTitle,itemTitle 恒空(修复 0.85 元误命中碎梦浮光珍宝礼盒、拼单未开)
- work-product-match-mappers 改为门面(签名不变),work-order-pricing 改为转发
- 新增后台「按订单项试匹配」接口与面板:走发单同一套链路,返回模板/数量/单价/总额/拼单
- 生产样本回放:91/PDD 6000 条决策 0 差异;抖音 5 条全为修正
设计见 docs/接单模板匹配引擎重构设计.md
|
2026-10-14 15:58:21 +08:00 |
|
yml2213
|
2d02630eea
|
docs(mashida): 更新 ngrok 亚太区域与固定静态域名说明
|
2026-10-10 20:22:48 +08:00 |
|
yml2213
|
10d1449b8d
|
docs(douyin-mashida): 09 重写为「一条链接闭环 + 复用 affiliate_dash」
按纠偏后的实现改写:目标流程(一条链接 → 输 UID → 二维码 → 扫码绑定 → 比对 UID → 完成)、
为什么复用 affiliate_dash 而不另建执行器、为什么未命中必须显式回落人工(漏单风险)、
为什么链接必须是路径式且只有一个(老订单的 /redeem 链接保留可用)、商品图来源与降级、
配置项表(含「保存接口必须带全量配置」的注意点)、以及下一步(真正的发货与冲正)。
|
2026-10-09 16:13:53 +08:00 |
|
yml2213
|
f32e76f843
|
docs(douyin-mashida): 新增皮肤领取流程设计文档 + 联调清单补充
- `09-皮肤领取流程.md`:为什么改(固定链接/输订单号的问题)、新流程图、
为什么链接必须是路径式(# 是打手页)、商品图怎么来(内部 SKU → 英文 sku → 图片,
复用权威映射表 + 漏图守卫测试)、配置项表、兼容性(旧链接保留)、下一步(真正发货)
- `08-公网联调.md`:联调 checklist 补「皮肤领取页两项配置」(含 `#` 告警)、
把「手机打开链接」改为买家领取链接并补任务/token 与四表对账
|
2026-10-09 15:07:03 +08:00 |
|
yml2213
|
f72eeb7648
|
docs(douyin-mashida): 记录「平台会改写券码」这个坑与核销实测结论
- 07 §4.11:新增「平台会改写我们提交的券码」——实测 3 笔里 2 笔被平台改名,
连带 10017 核销码不匹配(且要 ~10.5s 才返回,会伪装成网关超时);
写明处理方式(回查落库 + 核销用平台券码 + 失败自愈 + 超时 20s)
- 00 总览:实测结论表补上「核销成功」「平台改写券码」「order.message 已调用」
|
2026-10-09 14:09:05 +08:00 |
|
yml2213
|
d12dce7575
|
docs(douyin-mashida): 记录商品展示口径(内部 SKU 为主)
新增 §4.10:说明 code=内部 SKU / product_name=引流标题的区别,
以及三个界面(后台列表、后台详情、兑换中心)统一以内部 SKU 为主的展示规则,
并注明实现只对 douyin_mashida 生效、不影响其它平台。
|
2026-10-09 13:31:51 +08:00 |
|
yml2213
|
3505ca4e05
|
docs(douyin-mashida): 补平台真实推送的实测形态
订阅生效后一笔真实付款的推送原文(来源 IP、耗时、字段值):
- p_id/s_ids 是 19 位裸数字,pay_time 是秒级 —— 与 §4.1 精度修复、§4.8 双形态解析相互印证
- 记录文档未覆盖的 pay_type=8,代码不依赖该字段
- 端到端:付款 12:55:05 → 推送 12:55:11 → 建单+发券+syncV2 完成 12:55:12
|
2026-10-09 12:57:09 +08:00 |
|
yml2213
|
5c13d9221f
|
docs(douyin-mashida): 回填真实联调实测结论与推送订阅步骤
- 08-公网联调:新增「必须做:订阅推送」一节 —— 只填 uid/secret 平台不会推消息,
必须调 message.config 配置 message_url/topics/status;含脚本用法、实测返回、
域名变更后需重订阅、平台不补推历史订单等注意事项;排错表补两行
- 07-最小接入实现说明:新增三条实测结论
§4.8 pay_time 有 Integer 与 "YYYY-MM-DD HH:mm:ss" 两种形态(及 epoch 0 表示"无")
§4.9 文档示例值不能照抄(真实 shop_id / 子单号可能是字符串且等于父单号)
§4.10 平台推送是订阅制、不补推历史订单
- 00-总览:补「真实平台实测结论」表,并把 subscribe 脚本纳入清单
|
2026-10-09 12:43:58 +08:00 |
|
yml2213
|
d9848aaef3
|
docs(douyin-mashida): 接入分析、实现说明与公网联调文档
- 00-总览:进度索引(闭环落点 / 代码清单 / 配置项 / 上线步骤 / 缺口 / 待实测点)
- 04-结合本项目的深度分析:深读平台文档后与仓库既有实现的对应关系
- 05-最小接入方案分析:实施方案与取舍(本期只做抖音、不做打手、不做多平台)
- 06-待确认问题清单:已答复项与"边做边测"项
- 07-最小接入实现说明:实现要点、上线三步、两个必须记住的坑
(19 位订单号 JSON.parse 丢精度 / 验签必须用 body 原文)
- 08-公网联调:ngrok 隧道 + 一键切地址 + 前置自检 + 联调 checklist + 排错表
|
2026-10-09 12:01:49 +08:00 |
|