从一枚码，
到一条可审计的数据链。
能力的价值不在于功能数量，而在于每个环节是否留下可核查的记录。 本页说明六项核心能力、七个环节各自的输入与系统行为， 以及六类终端的数据边界——包括它们看不到什么。
- CODING
- 33 位 Ecode 物品编码，按租户隔离码段
- GRANULARITY
- 单品码 → 盒码 → 箱码，三级绑定
- INTERFACE
- RESTful API + 事件回调
六项能力，各自的输入与产出
下面这张表刻意写成「输入 → 处理 → 产出」的形式，而不是功能清单。 因为采购决策真正要判断的是：这项能力吃进什么数据、吐出什么结果、失败时怎么办。
| 能力 | 输入 | 系统行为 | 产出 / 失败处理 |
|---|---|---|---|
| Ecode 备案与码段 | 产品信息、企业资质、申请数量 | 提交备案 → 审核 → 申请码段 → 下载码包 → 回传出厂流向 | 可用码段与回执；审核驳回时返回具体缺项 |
| 生产赋码与绑定 | 批次、SKU、尺码、码段 | 按批次分配码 → 单品码绑定盒/箱码 → 校验唯一性 | 绑定关系表；重复码或跨租户码直接拦截 |
| 质检归档 | 检测结论、报告附件、检测机构、时间 | 写入批次档案 → 与码关联 → 生成时间轴节点 | 家长端可见的质检记录；缺报告时该节点标记为未完成 |
| 仓储与出入库 | PDA 扫码记录、库位、单据 | 校验码状态 → 原子扣减库存 → 写流水 | 实时库存与流水；重复出库请求被幂等拦截 |
| 流向与窜货预警 | 经销商授权区域、扫码位置与频次 | 比对授权 → 跨区聚合 → 触发风控规则 | 预警清单；误判可由企业确认后撤销 |
| 家长端查验 | 扫码的码值、时间、渠道 | 验签 → 查批次 → 判定首查 / 重复查 → 返回档案 | 溯源页与防伪提示；无效码返回明确失败原因 |
七个环节，谁在操作、系统做什么
全链路的完整性依赖一个硬约束：上一环节没有完成记录，下一环节不允许通过。 这不是流程装饰，而是让「缺一环」在系统里显形。
| 环节 | 操作方 | 关键动作 | 前置校验 |
|---|---|---|---|
| 01 备案 | 企业 / 平台 | 产品在 Ecode 体系备案，取得专属码段 | 企业资质与产品信息完整 |
| 02 赋码 | 产线 | 单品码与盒码、箱码逐级绑定 | 码段有效、未被使用、属于本租户 |
| 03 质检 | 品控 | 质检结论与报告写入批次档案 | 批次存在且已赋码 |
| 04 仓储 | 仓库 | 入库、出库扫码，库存原子扣减 | 码状态为「已质检」 |
| 05 流通 | 经销 / 服务点 | 收货登记，流向与授权区域比对 | 出库记录存在且单据匹配 |
| 06 发放 | 学校 / 服务点 | 订单交付到校，发放记录关联学生或班级 | 订单与发货批次一致 |
| 07 查验 | 家长 / 监管 | 扫码查看防伪结果、质检结论与时间轴 | 码已激活且未失效 |
为什么强调顺序：很多追溯系统做成了「填表」—— 数据填了就算有了。平台的判断标准是「上游有记录、下游才放行」， 这样一条链才可能在被追问时经得起核对。
六端协同：也包括它们看不到什么
权限设计的诚实做法，是把「不开放的部分」也写清楚。 以下边界来自平台的租户与角色模型，而不是事后补的说明。
| 终端 | 使用方 | 主要任务 | 不可见范围 |
|---|---|---|---|
| 平台总后台 | 平台运营方 | 租户入驻、套餐计费、运营分析、系统配置 | 租户业务明细按授权脱敏查看 |
| 企业管理后台 | 校服企业 | 产品、溯源码、订单、库存、经销商、质检 | 其他企业的任何业务数据 |
| PDA 扫码端 | 产线 / 仓库 | 赋码、绑定、出入库、盘点 | 财务与客户资料 |
| 溯源 H5 | 公开访问 | 扫码查验、查看批次与质检信息 | 企业内部经营数据与学生个人信息 |
| 微信小程序 | 家长 | 查验、防伪提示、补订校服 | 同上；补订仅限本人订单 |
| 监管端门户 | 教育 / 市场监管 | 辖区订单、质量数据、风险事件处置 | 企业成本、客户名单等经营信息 |
数据模型：码是主键，批次是骨
追溯系统的数据结构决定了它能回答什么问题。平台以溯源码为主键， 向上挂批次与产品，向下挂流转事件，横向关联租户与角色。
// 一次查验背后的主要关联（示意，非完整表结构） trace_code 码值 · 状态 · 租户 · 批次 · 绑定箱码 ├─ batch 批次号 · SKU · 尺码 · 生产日期 · 产线 │ ├─ quality 检测结论 · 报告附件 · 机构 · 检测时间 │ └─ product 产品名称 · Ecode 备案号 · 执行标准 ├─ flow_event 事件类型 · 操作方 · 时间 · 位置 · 单据号 └─ scan_log 扫码时间 · 渠道 · 设备 · 结果判定
这个结构带来两个直接好处：查一件衣服，能拿到它的全部履历； 查一个批次，能反推所有受影响的码，召回范围可以被精确计算而不是估计。
开放接口：让数据回到业务系统里
追溯数据如果只能在本平台里看，价值会被打折。平台提供 RESTful 接口与事件回调， 供企业 ERP、学校管理系统或监管业务系统按需取用。
- 鉴权：基于租户的令牌鉴权，令牌绑定租户与角色范围，越权请求直接拒绝。
- 查询：按码、按批次、按订单查询追溯详情与流转记录。
- 回传：企业可将自有系统的发货、签收记录回传，保持数据同源。
- 回调：风险事件、码状态变更可订阅事件通知，不必轮询。
- 限流：按租户设定调用配额，避免单一方拖垮整体服务。
接口文档：完整字段与示例在接入时提供，并随版本更新。 如需评估对接工作量，可在演示阶段直接获取接口清单。