order_site 文档索引
最后校准:2026-10-17,代码基线 main @ 6850bc64。
本文是 docs/ 的唯一入口。新增文档必须在上表登记状态;过期文档不再直接改写结论,统一移入 docs/archive/。
一、先记住四条口径
1. 来源只有三个,不是四个
| sourceKey |
包含的数据通道 |
说明 |
kuaishou-91 |
91 回调 + 快手 send-code |
同一个来源的两条通道:91 是订单骨架权威源,快手 send-code 是数据补全源与兜底源;共享店铺键空间与同一套匹配上下文 |
pdd |
拼多多订单同步 |
两段式 pdd_raw_orders → orders |
douyin-mashida |
抖音码速达推送 |
抖店订单、DYC 券、H5/兑换页 |
不要把 91 与快手 send-code 拆成两个来源、两个适配器或两条业务线。 代码中的唯一来源键是 kuaishou-91(apps/backend/src/services/product-match/types.ts),适配器是 adapters/kuaishou-91.ts。
2. 一个订单 = 骨架 + 买家凭证 + 一个执行载体
- 骨架:
orders + order_items
- 买家凭证:快手电子凭证(
kuaishou_industry_vouchers)或抖音券(redeem_certificates)
- 执行载体只有三种:
affiliate_dash 自动发货、work_orders 工单、manual 人工客服
- 三者业务上互斥;无自动任务且无工单的已支付订单项就是人工块,必须进入人工 case,不能静默消失
3. 成本只在一个地方改
- 商品主数据:
product_catalog
- 渠道 SKU 映射:
channel_product_mappings
- 成本金额:只在
cost_versions 改,按生效日期新增版本
- 订单/工单/人工单只保存
cost_snapshot_id,历史成本永不回写
- 自动发货、接单平台、人工客服共用同一个成本解析器;匹配不到成本进入
cost_missing,不默认 0
4. 文档状态
| 状态 |
含义 |
| 现行 |
与当前代码一致,改动代码时必须同步更新 |
| 参考 |
厂商协议、外部接口文档,按平台版本更新 |
| 历史 |
只用于追溯,不得作为实现依据;位于 docs/archive/ |
二、现行文档
SQL 草案(未接入迁移)
草案只作设计与复盘依据;接入 apps/backend/src/db/migrations/ 时再拆成 NNN_slug.sql,并先跑 npm run check:sql。
三、厂商协议与外部资料
这些目录是平台方文档或抓取资料,不作为本项目实现说明:
| 目录 |
内容 |
91卡券/ |
91 卡券公开接口、签名、加密示例(项目接入结论见 91卡券/6.开发设计.md) |
行业电子凭证/ |
快手电子凭证接口、售后、测试指南 |
发货平台-2/ |
早期发货平台协议,现行为 affiliate_dash;保留作历史接口对照 |
抖音-码速达/接口API/ |
抖音码速达出网接口 |
抖音-码速达/消息推送/ |
抖音码速达推送消息字段与签名 |
四、历史文档
五、维护规则
- 改代码影响业务口径时,先改现行文档,再提交代码。
- 文档头部必须写「状态 + 最后校准日期 + 代码基线」。
- 旧分析不要在原文件上继续堆结论;新建当期报告,旧文件移入
docs/archive/<日期>/。
- 行号只用于当期基线;跨版本引用优先写文件与函数名。
- 新增来源时只加一个
ProductMatchSourceKey + 一个适配器;91 + 快手 send-code 永远算一个 kuaishou-91。
- 成本金额只改
cost_versions,不要在多个业务表直接改价;历史订单只读 cost_snapshots。
- 报表维度统一用
canonical_product_id + shop_id + stat_date,不要直接用原始 sku_code 或 orders.total_amount。
- 新增 SQL 草案放
docs/drafts/,命名 <日期>-<主题>.sql;不得直接放进 apps/backend/src/db/migrations/(后端启动会自动迁移),接入时再拆编号并先跑 npm run check:sql。