 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
|
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
|
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 |
|