SCM 智能供应链系统功能与使用说明（运营版）

适用对象：运营、采购、跟单、仓库、业务负责人和新同事
文档目标：用业务语言说明“系统能做什么、每天怎么用、为什么可信、未来会发展到哪里”。
核验日期：2026-08-13。系统实际数据以页面显示的最新成功批次、更新时间和权限范围为准。

快速阅读建议：第一次了解先读第 1、2、4、7 节；准备实际操作再读第 5、6、8 节；关注建设方向直接读第 9 节。

1. 先用一句话理解系统

这套系统把销量、库存、FBA 在途、本地可调拨、采购未入库、物流、产品生命周期等信息汇总到同一条决策链上，帮助运营回答三个问题：

1. 长期够不够：是否需要采购或生产，建议准备多少。
2. 短期来不来得及：海外库存是否可能断货，国内现有库存要不要立刻发 FBA。
3. 依据是否可信：销量、库存、采购、物流和到货日期来自哪里，当前是否完整、新鲜、可复核。

系统不是简单地给出一个“建议数量”，而是把建议量、原因、原始数据、时间节点、异常提示和后续结果尽量放在同一条可追溯链路里。

2. 运营最需要记住的结论

• 日常工作的第一入口是“备货”页面，先看顶部行动队列，再进入 SKU 详情核对。
• 需要发货 和需要采购 是两类不同动作：前者解决近期海外断货，后者解决更长周期的库存缺口，数量不能相加。
• “需复核”表示当前决策存在需要人工确认的 PO、到货日期、数据缺口或国内无货等边界，不代表系统已经自动修改建议。
• 页面主要结果来自后台完整批次，不是打开页面时临时拼接，因此可筛选、可导出、可回看更新时间。
• 长期采购时间轴、智能补货和 Amazon 核验都有明确隔离边界；在证据不足时，它们不会静默覆盖正式备货结果。
• 任何建议都不是“已执行”：系统不会因为展示建议量就自动下采购单、自动发货或自动改变 Amazon 库存。

3. 功能状态图例

4. 每天怎么用：运营最短工作路径

4.1 每日巡检，建议 10～15 分钟完成

1. 从钉钉日报或“备货”首页进入当天重点。
2. 先确认页面的最新批次、同步时间和异常提示；数据过旧或被阻断时，先不要直接执行数量。
3. 按顺序处理顶部行动队列：
   • 需要发货（红色）：国内当前有可发库存，优先判断能否赶上断货日。
   • 需复核（蓝色）：先核对 PO、预计到货日、国内无货或关键数据缺口。
   • 需要采购（黄色）：查看长期缺口和建议生产 / 采购量。
4. 点击 SKU 打开详情，核对销量、FBA、本地库存、在途、采购未入库、生命周期和风险原因。
5. 涉及到货时间时，再看“长期采购”时间轴；涉及已发货件时，再看“物流跟踪”。
6. 需要跨部门协同时，导出当前筛选结果或进入采购合同、生产单、报价模块继续处理。

同一 SKU 可能同时命中发货、复核、采购，顶部数量不能直接相加。页面会给出主动作和其他动作，运营应分别处理。

4.2 每周复盘

1. 用“销量核对”抽查重点 SKU 的卡片销量和销量明细是否一致。
2. 检查新品、在售、停售的生命周期是否正确，尤其关注停售但仍有库存的 SKU。
3. 查看长期采购时间轴中的到货断档、逾期 PO、日期不明供给和潜在积压。
4. 查看物流跟踪中的失败、超时未更新、待积加确认和已完成货件。
5. 在“结果复盘”中观察建议、执行动作和实际结果的关系，为规则或模型优化提供证据。

4.3 看到异常时怎么处理

先不要只凭页面数字判断“算法错了”，按下面顺序核对：

1. 记下 SKU、站点、店铺、页面批次和更新时间。
2. 判断问题属于销量、库存 / 供给、日期、站点归属还是页面展示。
3. 销量问题进入“销量核对”；FBA 货件问题进入详情或“物流跟踪”；PO 问题查看采购未入库明细和 ETA。
4. 看清楚原始数量、本次计入数量、未计入数量和具体排除原因。
5. 页面提示数据缺口、来源过期或需要复核时，保留提示并提交核查，不用猜测值替代。

5. 核心页面与功能

5.1 备货首页：把风险转成行动

状态：正式使用 | 入口：顶部导航“备货”，路径 /

主要回答：今天哪些 SKU 要先处理，应该发货、复核还是采购。

运营可以：

• 按行动、预警、店铺、站点、生命周期、组别和商品信息筛选。
• 查看 FBA 可售、可售天数、综合日均、FBA 在途、本地可调拨和采购未入库。
• 查看正式建议生产 / 采购量和短期发 FBA 动作。
• 打开详情核对原因、原始明细和时间节点。
• 批量选择并导出当前筛选结果。
• 快速识别停售但仍有库存、无销量观察和数据缺口记录。

顶部三个行动队列的含义：

注意：采购未入库会参与长期供给，但不参与短期发出；90 天以上库龄库存只做提示，不从可用供给中扣减。

5.2 SKU 详情：回答“为什么是这个建议”

状态：正式使用 | 入口：在备货列表、钉钉日报或大屏中点击 SKU

详情采用“结论优先、依据逐层展开”的方式，主要展示：

• 商品身份：SKU、MSKU、ASIN、站点、店铺、图片和品类。
• 正式结论：建议生产 / 采购、短期发出、覆盖天数、预警等级和生命周期。
• 销量依据：综合日均、销量趋势、销量窗口和异常提示。
• 供给依据：FBA 可售、预留、在途、本地可调拨、采购未入库、AWD 等。
• 时间依据：缺货风险日、预计到货 / 可售日、断档区间和未来库存水位。
• 原始明细：PO、FBA 货件、仓库和来源状态，便于逐项对账。
• EU/UK 说明：专属供给与共有池分开展示，避免重复计算。

详情中的“建议发出 N 套”表示国内当前可执行的模拟动作，不表示已经发货；浅蓝色“若今日下单”曲线也只是假设场景，不是已下采购单。

5.3 长期采购：按到货时间判断“够不够”

状态：并列参考 | 入口：顶部导航“长期采购”，路径 /replenishment-timeline

正式备货先回答总量是否存在缺口；长期采购时间轴进一步回答这些供给在正确日期到达后，是否仍会出现断货。

主要能力：

• 按预计可用日期放入 PO、FBA 在途和其他已确认供给。
• 展示未来库存水位、最早风险日、最大缺口和假设下单后的变化。
• 区分有效日期内供给、逾期供给、日期不明供给和计划期外供给。
• 展示正式建议与时间轴建议的差异，并允许提交“结果合理 / 结果有问题”反馈。
• 在 EU/UK 场景复用正式共有池分配结果，不自行猜测第二套归属。

运营使用原则：

• 正式建议仍是主结论，时间轴是第二意见。
• 时间轴结果显示“需要复核”时，先查看风险原因和依据，不把它理解为正式建议已经错误。
• 到货日期缺失、数据过期、店铺时区不明或供给不守恒时，系统会阻断或隐藏不可靠曲线。

5.4 短期发 FBA：判断“来不来得及”

状态：正式使用，展示在备货卡片和详情中

短期模块只看海外近期缺口、国内现有可发库存和物流时效，不把采购未入库、本地待调拨等长期供给混进期初 FBA 库存。

系统会给出：

• 预计断货日和短期缺口。
• 国内当前可发量、国内是否不足。
• 建议线路和预计可售区间。
• “及时衔接 / 存在风险 / 仅能缓解 / 短期效益有限”等动作等级。
• 补发后预计避免或减少多少天缺货，或降低多少峰值缺口。

业务理解：总供给未来可能够，不等于近期一定来得及；短期模块专门识别“数量够但到货太晚”的断档。

5.5 物流跟踪：看货件现在走到哪里

状态：正式使用的独立参考层 | 入口：顶部导航“物流跟踪”→“货件跟踪”，路径 /logistics/shipments

主要能力：

• 按 FBA 货件号、TMS 货件号、客户参考号或 SKU 搜索。
• 查看 TMS 物流轨迹、当前物理节点、同步状态和更新时间。
• 查看同一货件的 FBA 发货量、收货量、地址、备注和产品明细。
• 筛选待积加确认、同步失败、超过更新阈值和已完成货件。
• 对具备权限的角色记录人工追踪状态；单票同步仅管理员可执行。

物流跟踪不会回写备货数量，不会改变 FBA 在途、长期采购时间轴或正式建议。它的作用是让运营知道“货在哪”，并为到货风险提供独立证据。

5.6 头程时效配置：把线路经验变成可计算依据

状态：正式使用，受权限控制 | 入口：物流跟踪分组，路径 /logistics/fba-route-times

这里维护区域、站点、线路、生效期和运输时效。短期发 FBA 会在查询时使用这些配置估算最早 / 最晚可售日期，但不会改写历史备货批次。

运营关注：线路停用、生效期和时效区间是否符合当前实际；配置有审计记录，不建议用临时口头经验覆盖正式线路数据。

5.7 数据总览与运营大屏

状态：正式使用的汇总视图 | 入口：专用大屏 /big-screen，运营详细数据 /big-screen-ops

主要用于日会、周会和管理巡检：

• 今天先盯哪个区域。
• 哪些 SKU 需要优先采购或本地发出。
• 当前同步和数据新鲜度是否正常。
• 高风险、库存偏高、停售异常等指标如何分布。

大屏复用正式备货结果，不另建一套算法。数据异常或批次不完整时会进入受保护状态，只能参考，不应据此直接执行。

5.8 钉钉日报：把重点风险推到人

状态：正式使用的消息入口 | 入口：从钉钉日报消息打开专用页面

日报用于快速浏览授权范围内的销量、库存、供应链状态和重点 SKU，并可直接打开同一套 SKU 详情。

使用建议：

• 日报适合发现重点，不替代备货页的完整筛选和对账。
• 风险明细可按订阅标签收窄；总体销量和库存看板仍按用户授权范围统计。
• 原消息会话失效时，应从最新钉钉消息重新进入，不要保存旧会话链接长期使用。

5.9 采购合同、生产单与报价

状态：正式使用，受角色权限控制 | 入口：顶部导航“采购合同”，路径 /contracts

主要能力：

• 导入生产单 Excel，解析商品、数量、包装和生产单号。
• 管理生产单、人工报价和采购合同。
• 把生产单明细带入合同，减少重复录入。
• 新建、编辑、复制、作废和导出合同。
• 保存相关图片和操作记录，形成可追踪的跟单链路。

该模块把“系统建议采购”继续连接到业务单据，但不会仅凭建议量自动生成或发送真实采购订单，仍需要人员确认。

5.10 销量核对：回答“卡片销量为什么不一致”

状态：正式使用的对账工具 | 入口：路径 /sales-check

主要能力：

• 按 SKU、MSKU、ASIN 或商品信息搜索。
• 对比当前已发布备货批次中的销量快照和基于本地销量明细的即时重算值。
• 查看销量来源、时间窗口和差异原因。
• 判断问题来自同步、销量源口径还是备货批次尚未刷新。

“卡片快照值”和“即时重算值”属于不同时间截点，出现差异时先看批次与更新时间，不应直接把其中一个认定为错误。

5.11 产品生命周期：让不同阶段使用不同策略

状态：正式使用

生命周期按“SKU + 站点”维护：

修改生命周期会影响后续完整批次，不等于当前页面立即完成全部重新计算。运营应确认站点粒度，避免把一个站点的停售误用于另一个站点。

5.12 Amazon 独立库存核验

状态：受控验证 | 入口：独立路径 /amazon-replenishment，是否可见取决于当前部署与权限

当前定位是用 Amazon SP-API 的库存和 Listing 数据独立核验积加，不替代现有备货页。

已确定边界：

• Amazon 数据使用独立表和独立页面，不混写正式积加备货结果。
• 库存必须由可售 /inbound 报表与 reserved 明细报表组合核验，不能用单一报表假装完整库存。
• Pan-EU 共享库存要按主抓取店铺去重，避免多店铺重复累计。
• 首期不接销量、订单、采购、调拨、供应商库存、PII 或 RDT。
• 缺少来源的字段必须显示数据缺口，不能把“未知”伪装成可信的 0。

运营应把它理解为“第二数据源对账页”。是否可用于某店铺，要先看授权、最新成功批次和数据缺口状态。

5.13 智能补货工作台与结果复盘

状态：受控验证；正式备货继续受保护 | 运营入口：/smart-replenishment/workbench、/smart-replenishment/outcome-review

工作台用于观察智能建议、解释依据和运行状态；结果复盘用于把“当时建议了什么、后来做了什么、最终结果怎样”放在同一条时间线上。

系统还具备模型对比、评估、质量门禁、发布预检、审批、审计和回滚能力，其中多数管理页面仅管理员可见。

当前最重要的边界：

• 规则基线仍是正式主线，AI 模型是 challenger/shadow。
• 某次预测看起来更准，不等于已经通过稳定性和业务价值门禁。
• Gate 不通过时保持正式基线，不把试验结果写入正式备货表。
• 未来即使进入小范围试点，也必须有明确范围、回滚点、评估证据和授权。

5.14 图片搜索：统一查找商品与业务图片

状态：正式使用的辅助工具 | 入口：路径 /image-search

主要能力：

• 上传一张图片进行以图搜图，也可不传图片直接浏览。
• 按 SKU、客户 SKU、工厂 SKU、品名、材质、颜色、包装说明、合同号、交期等条件组合查询。
• 汇总报价图、合同图、生产单图和备货商品主图。
• 维护业务分类和标签，支持批量标注。

它适合找图、核对商品身份和整理资料，不参与备货数量计算。

5.15 用户、店铺范围与系统管理

状态：正式使用，关键操作受管理员权限控制

管理模块包括：

• 用户管理 /users：维护账号、显示名、角色和钉钉身份等信息。
• 店铺关联 /shops：控制用户可查看的店铺范围，业务页面按授权范围裁剪数据。
• 系统设置 /system：查看积加 /Amazon 配置状态、补货参数、同步状态和近期运行记录。
• 操作日志 /operation-logs：核对关键配置或业务操作由谁在何时执行。

运营通常只需要知道自己的角色和店铺范围。手动同步、停止任务、修改凭据或补货参数会影响运行状态，应由有权限人员按内部流程执行，不应作为普通排查的第一步。

6. 关键口径：运营如何读懂数字

6.1 长期建议生产 / 采购量

可以简化理解为：

目标库存 = 综合日均销量 × 目标天数
长期建议量 = 目标库存 - 当前可用长期供给

目标天数由采购 / 生产交期、安全天数和补货周期组成。长期供给会综合 FBA、本地可调拨、在途、采购未入库、调拨和 AWD 等来源，但每个来源都有归属、日期和完整性规则。

6.2 短期发出量

可以简化理解为：

短期所需量 = 近期库存曲线中的最大缺口
建议发出量 = 短期所需量 与 国内当前可发库存 两者取较小值

它解决的是海外近期断货，不等于长期建议量，也不包含未来采购未入库。

6.3 长期采购时间轴建议

时间轴不是把所有供给简单相加，而是按预计可用日期放入未来库存曲线，再观察新单最早可用日之后出现的最大缺口。

因此可能出现：

• 总供给看起来够，但到货太晚，时间轴仍建议采购。
• 总供给很多，但大部分在计划期后到达，只能提示潜在积压，不能提前抵扣。
• PO 有数量但无可靠 ETA，只能进入复核，不能猜一个日期。

6.4 EU/UK 共有池

• UK 和 EU 的需求、FBA 可售、FBA 在途等专属供给分开计算。
• 本地可调拨和采购未入库可作为共有池展示原值。
• 算法先按两边实际正缺口分配 Local，再分配 PO，每个组件只消耗一次。
• 页面看到 UK、EU 都显示共有池原值，不代表可以把两个页面上的数再次相加。

7. 为什么这套系统具有可行性

系统的可行性不依赖“相信某个算法”，而依赖以下可复核机制。

7.1 数据链路可追踪

积加 / Amazon / TMS / 人工业务资料
        ↓
本地快照、同步记录与来源状态
        ↓
库存与供给统一口径
        ↓
完整批次预计算 / 时间轴净算 / 独立验证
        ↓
备货、详情、大屏、日报、物流和复盘页面

运营看到的不只是一个最终数，还能继续查看批次、更新时间、来源明细、计入 / 未计入原因和风险标记。

7.2 正式结果与试验结果隔离

• 正式备货、时间轴参考、Amazon 核验和 AI 预测分别保存和展示。
• 试验结果不能因为“模型已运行”就覆盖正式建议。
• 物流跟踪只提供物流证据，不回写备货数量。
• 结果复盘使用独立数据层，不改变当时的正式决策。

这种隔离让系统可以持续升级，同时保护当前运营工作流。

7.3 证据不足时宁可阻断

系统对缺 ETA、来源过期、站点归属不唯一、EU/UK 分配不守恒、时区未知、报表缺失等问题采取提示、复核或阻断，而不是自动填一个看似完整的数字。

这会让部分记录暂时不能直接执行，但比错误采购、重复备货或错站点发货更安全。

7.4 有权限、审计与回滚边界

• 用户只能查看授权店铺范围内的数据。
• 系统设置、操作日志、模型发布和部分物流操作受角色控制。
• 生命周期、合同、配置、人工状态和模型发布链路保留审计信息。
• 智能补货的受控试点要求 Gate、范围和回滚点，不允许无边界切换。

7.5 运营反馈可以进入下一轮改进

时间轴允许对最新结果标记合理或有问题；结果变化后旧反馈保留为历史，不会冒充对新结果的确认。结果复盘进一步把建议、执行和实际结果连接起来，使后续优化建立在真实业务结果上。

8. 当前边界与注意事项

1. 备货页面读取后台预计算批次，不是实时直连外部系统；先看最新成功时间。
2. 数据缺口提示不是装饰。缺来源、缺日期或来源过期时，不应忽略提示直接执行。
3. 采购未入库属于长期供给参考，命中相关 PO 时必须人工复核，避免重复采购。
4. 90 天以上库龄库存当前只提示、不扣减；停售库存仍需单独清理。
5. 时间轴是并列参考，不替代正式建议；浅蓝假设曲线不代表真实在途。
6. 物流跟踪不改变备货公式；TMS 状态和积加库存属于不同证据层。
7. Amazon 首期是独立核验链路，缺失的销量、订单和采购信息不能用 0 代替真实未知。
8. AI 目前保持 shadow/ 受控验证；准确率提升必须在独立窗口、稳定性和业务价值上重复成立。
9. 页面建议不会自动完成采购、发货或合同审批，真实业务动作仍由有权限人员确认。

9. 未来规划：从“看见风险”到“验证结果”

未来规划不以堆页面为目标，而以“减少漏单、重复采购、断货和无效沟通”为目标。每个阶段都要通过业务验收后再进入下一阶段。

阶段一：巩固日常运营闭环

目标：让运营每天能稳定完成“发现问题 → 查看依据 → 分派动作 → 跟踪结果”。

重点：

• 继续提高销量、库存、PO、FBA 和物流数据的新鲜度与完整性。
• 统一备货、日报、大屏和详情中的行动口径与文案。
• 完善头程时效、物流轨迹和备货详情的关联。
• 把异常原因进一步收敛成可执行的运营检查项。

验收标准：重点 SKU 能明确回答“谁处理、处理什么、依据是什么、最晚什么时候处理”。

阶段二：增强按时间决策的长期采购

目标：从“总量够不够”升级到“每批货能否在正确日期接上”。

重点：

• 持续验证长期采购时间轴的自然批次稳定性。
• 完善 PO ETA、FBA 预计可售日、促销计划、MOQ/ 箱规和供应商交期证据。
• 让时间轴差异、风险原因和人工反馈更容易汇总。
• 对数据不完整的来源继续 fail closed，不用猜测日期放大覆盖率。

验收标准：在一组稳定样本中，时间轴建议能比静态总量更早识别真实断档，并且不会引入重复供给或错误日期。

阶段三：建立结果复盘与责任闭环

目标：不仅知道系统建议了什么，还能回答建议是否被执行、执行后是否减少断货或积压。

重点：

• 把正式建议、时间轴建议、人工动作、生产 / 发货事实和最终销量库存串联。
• 建立可复核的行动状态、异常原因和业务结果指标。
• 形成按 SKU、站点、团队和周期查看的复盘视图。
• 用真实结果校正规则、数据质量和运营流程，而不是只看模型离线分数。

验收标准：任一重点 SKU 都能重放“当时依据 → 决策 → 执行 → 结果”的完整链路。

阶段四：推进 AI 与多数据源增强

目标：在不破坏正式基线的前提下，让系统更早识别需求变化和数据偏差。

重点：

• AI 预测继续以独立窗口和稳定性 Gate 验证，不因单次改善切换正式 Provider。
• Amazon 数据继续作为第二来源核验积加，先保证授权、双报表 join 和 Pan-EU 去重可靠。
• 有真实未来活动、价格或广告排期后，再评估这些因素是否对预测有稳定增益。
• 只有在准确性、偏差、覆盖率、业务价值和回滚能力都通过后，才讨论小范围正式试点。

验收标准：候选能力在独立样本上重复改善，并能量化减少缺货、过量采购或资金占用；失败时可自动保留 / 回退到规则基线。

10. 未来不会改变的原则

• 正式业务口径必须可解释、可对账、可回退。
• 数据证据优先于模型判断，未知不能伪装成 0。
• 总供给与到货时间分开，长期采购与短期发货分开。
• UK/EU 专属供给分开、共有池只扣一次。
• 新能力先并列验证，达到门禁后再小范围试点。
• 所有自动化都要保留异常停止、人工查看和基线兜底能力。

11. 新同事快速上手清单

第一天建议完成以下操作：

• 登录后确认自己能看到正确的店铺范围。
• 在“备货”页分别筛选一次需要发货、需复核、需要采购。
• 打开一条 SKU 详情，找到销量、库存、PO、FBA 和生命周期。
• 在“长期采购”中看懂正式建议与时间轴参考建议的区别。
• 在“物流跟踪”中搜索一个 FBA 货件号并查看时间轴。
• 在“销量核对”中抽查一个 SKU 的快照值和即时重算值。
• 了解数据缺口、更新时间和需要复核提示的处理方式。
• 确认自己没有权限的设置或发布操作应交给哪个角色处理。

12. 常见问题

Q1：页面为什么不是实时数字？

备货主结果来自后台完整批次。这样可以保证同一批结果可筛选、导出和追溯，也避免页面每次打开都用不同时间截点的数据临时计算。判断是否可用时先看最新成功时间。

Q2：为什么有采购未入库，系统还提示需要采购？

采购未入库会进入长期供给，但还要看数量归属、ETA、目标库存和时间轴断档。页面命中已有 PO 时会提示复核，运营应核对计入量、未计入量和日期，避免重复采购。

Q3：FBA 在途数量够，为什么还提示短期风险？

数量够不代表到货来得及。短期模块会看预计可售日和断货日之间是否有空档；日期不明或到货太晚的在途不能提前填补近期缺口。

Q4：正式建议和时间轴建议不一样，听哪个？

正式建议是当前主结论；时间轴是按到货日期重算的并列参考。先查看差异原因和风险依据，必要时提交反馈或人工复核，不能把两个数量相加。

Q5：系统有 AI，是否已经自动替代人工？

没有。当前 AI 主要用于 shadow 预测、对比和结果复盘。正式基线受保护，只有候选在独立样本、稳定性、业务价值和回滚门禁上全部通过，才可能进入有明确范围的小试点。

Q6：系统为什么有时宁可显示“数据不足”？

因为补货错误可能直接造成缺货、重复采购或资金占用。缺日期、缺来源或归属不唯一时保留“未知 / 需复核”，比制造一个看似完整但无法对账的数字更安全。

13. 运营需要知道的正式资料入口

• 补货公式：replenishment-calculation-formula.md
• EU/UK 共有池：eu-uk-replenishment-caliber.md
• 采购未入库规则：replenishment-po-supply-rules.md
• 生命周期规则：replenishment-lifecycle-rules.md
• 长期采购时间轴：replenishment-time-phased-netting-design.md
• 物流跟踪：tms-logistics-tracking.md
• Amazon 独立核验：amazon/README.md
• 智能补货计划边界：intelligent-replenishment/plan-control-manual.md

这套系统的价值不是替运营“拍脑袋做决定”，而是把散落在不同系统和表格里的事实整理成可执行、可解释、可追踪的供应链决策。运营仍掌握最终业务动作，但不再需要从零拼接每个数字。