电商补货计划最容易犯的错误，是把“仓库里还有多少件”当成“未来还能卖多少天”。我在梳理库存系统时经常发现，同一款商品同时存在现货、已锁定库存、采购在途、待质检库存和不可销售库存，系统却把它们压成一个总数。结果不是补货过早、资金被占用，就是等到缺货发生后才紧急采购。补货系统真正要解决的，不是生成一个采购数量，而是把库存状态、需求预测、供应商交期、采购约束和人工判断串成一条可解释、可追踪的决策链。
电商库存场景解析：补货计划中的系统搭建怎么处理
很多企业一讨论补货系统，就先问要不要使用人工智能预测、机器学习模型或复杂的时间序列算法。在我看来，这个顺序通常反了。预测模型建立在稳定、完整且口径一致的数据上，如果连“可用库存”都没有定义清楚，再精确的模型也只是在错误数据上进行更复杂的计算。
补货系统的第一个任务，是回答三个基础问题：现在真正可以用于销售的库存有多少，未来一段时间会消耗多少，新的货物最早什么时候能够进入可销售状态。只有这三个问题有稳定答案，系统生成的补货建议才有业务意义。
我通常把补货系统拆成八个连续环节：数据采集、库存核算、需求预测、补货计算、采购约束、人工审核、采购执行和结果复盘。任何一个环节缺失，都会让系统看起来自动化，实际却依然依赖人工经验。
业务人员不会因为系统显示“建议采购 1,000 件”就自然接受这个结论。采购负责人往往会继续追问：预测销量是多少，交期取了几天，安全库存如何计算，在途订单是否已经纳入，活动订单有没有单独处理，为什么不是采购 600 件或 1,500 件。
因此，补货系统的结果页面不能只显示一个数量。至少应该同时展示当前可用库存、锁定库存、在途库存、预测需求、预计缺货日期、安全库存、供应商交期和最终建议量。建议量被修改后，还要记录修改人、修改前数量、修改后数量以及修改原因。
对于大多数中型电商企业，我不建议一开始就建设全自动采购。更稳妥的路径是先把库存状态、商品主数据、供应商交期和补货规则统一起来，再通过人工审核形成闭环，最后才逐步扩大自动化范围。
如果当前企业仍然依靠多个 Excel 表格维护补货，第一阶段的目标可以非常朴素：每天能够稳定得到一份有依据的补货清单，并且每一条建议都能追溯到库存、销量和参数。这个目标看似简单，却比直接追求复杂预测模型更容易产生真实收益。
我见过最典型的误判，是管理层看到仓库总库存还有几万件，就认为采购部门不应该继续下单。但进一步拆分后才发现，库存集中在低销量商品和错误仓库，核心 SKU 已经被订单锁定，另有一批货正在等待质检，真正能够支持未来销售的数量并不多。
这类问题通常不是仓储人员不认真，而是不同系统对库存状态的定义不同。仓库关注货物物理位置，订单系统关注订单占用，采购系统关注在途数量，财务系统关注资产价值。如果补货系统没有统一这些状态，就会出现每个部门都认为自己的数据正确，但最终补货结果仍然错误。
电商企业常常同时经营自营商城、第三方平台、直播渠道、线下门店和分销客户。总部仓库有库存，并不意味着某个区域仓或某个销售渠道可以立即使用这些库存。调拨需要时间，渠道库存可能有最低保有量，平台还可能设置独立的可售库存上限。
因此，我在做补货规则设计时，会先区分“企业库存”和“履约节点库存”。企业库存回答的是公司总共拥有多少商品，履约节点库存回答的是某个仓、某个渠道在承诺时间内能够交付多少商品。补货计划通常应该以履约节点为计算对象，而不是只看企业总库存。
历史销量不是天然可靠的预测输入。一个商品过去 30 天卖得少，可能是需求低，也可能是连续缺货导致订单根本没有被承接。一个商品过去 7 天卖得多，可能是自然增长，也可能只是一次短期直播或限时折扣。
如果系统直接对订单数量做平均，就会把促销峰值、断货低谷、退款订单和预售订单混在一起。最终生成的预测值看上去有公式、有小数点，实际上没有反映正常销售能力。
采购单上的交期通常是供应商承诺的理想时间，实际到货还要经过订单确认、生产、出库、运输、收货和质检。如果系统只使用“供应商说 7 天到货”这个静态参数，遇到节假日、产能紧张或物流拥堵时，补货建议就会系统性偏乐观。
我更倾向于把交期拆成承诺交期、历史中位交期、最长交期和交期波动四个字段。稳定供应商可以使用中位交期，波动较大的供应商则需要在安全库存或风险预警中体现延期概率，而不是简单沿用平均值。
仓库现存量是物流概念，可用库存是业务决策概念。两者之间至少还隔着订单锁定、质量状态、库存冻结、渠道分配和调拨计划。若系统把全部现存量都用于补货计算，结果往往是补货不足；若完全忽略现存量，只看销售趋势，又容易形成过量采购。
建议在系统中明确一个可计算字段，而不是让每个报表使用不同公式。一个常见的基础口径可以是：可用库存等于合格现货减去已锁定数量，再加上经过确认且能够在需求窗口内到货的在途数量。待质检、残次和未确认采购单是否计入，需要根据企业流程单独定义。
近七天平均销量的优点是简单、容易解释、上线快，但它只适合需求相对稳定且没有明显促销干扰的商品。对于季节性商品、直播商品、新品和频繁断货商品，简单平均会产生明显偏差。
更合理的做法是先判断销量数据是否可用。若近七天有三天断货，那么这七天销量低不能代表市场需求低；若其中两天有大促，那么销量高也不能直接外推到未来。系统需要给销量打标签，再决定是使用移动平均、加权平均、活动修正，还是人工录入预测。
“日均销量乘以三天”可以作为临时规则，但不应该被包装成普适算法。安全库存的本质，是为需求波动和供应波动提供缓冲。需求稳定、交期稳定的商品，不需要与高波动商品使用相同的缓冲天数。
在实际设计中，我会至少考虑销量波动、交期波动、商品缺货损失和服务水平目标。核心商品可能宁愿多承担库存资金，也不能频繁缺货；长尾商品则可能接受较低服务水平，以避免低周转库存持续积压。
一个月销几千件且需求稳定的标准品，与一个季度只卖几十件、生命周期很短的长尾商品，不应该使用同一套补货逻辑。前者适合自动生成建议，后者更适合低频审核、按单采购或人工确认。
商品分层不一定要先建立复杂的算法。企业可以先按照销量贡献、需求稳定性、缺货影响、采购周期和生命周期进行分组，再为每组设定不同的规则。分层的目的不是让报告看起来专业，而是避免低价值商品消耗大量预测和审核资源。
系统擅长重复计算，业务人员擅长理解临时变化。大促、直播、供应商停产、渠道临时放量、商品即将下架等情况，很难全部通过历史数据提前识别。因此，成熟的系统不是消灭人工，而是把人工从“搜集数据和手工计算”转移到“判断例外和调整策略”。
人工调整必须被记录，否则企业无法判断系统不准，还是业务人员没有按照建议执行。没有调整日志的系统，后续复盘只能争论谁的感觉更正确。
补货计划中的第一个参数不是安全库存，而是计划对象。系统需要明确按 SKU、仓库、渠道、供应商还是 SKU 与仓库组合生成建议。对多仓电商而言，通常不能只按 SKU 计算，否则系统无法判断库存究竟要补到哪个节点。
第二个参数是补货运行频率。日销稳定的商品可以每天运行一次，长交期商品可以按周运行，低频长尾商品则可能每两周或每月审核一次。运行频率越高，不代表决策质量越高；如果输入数据没有及时更新，只会更频繁地生成错误建议。
补货系统可以先使用可解释的基础公式，再逐步增加复杂逻辑。用于说明系统结构时，我通常采用下面的简化关系：
预计可用库存 = 当前可销售库存 + 计划窗口内确认到货量 – 计划窗口内预计需求量
理论补货量 = 目标库存 – 预计可用库存
最终建议量 = 按最小起订量、采购倍数和预算约束修正后的理论补货量
这里的“确认到货量”不能等同于所有采购在途。只有供应商已确认、交期在计划窗口内、且不存在质检或运输异常的订单，才适合进入高可信度到货量。其余在途订单可以作为风险提示，但不一定直接冲减补货建议。
“目标库存”也不是固定库存上限。它通常由覆盖周期需求、安全库存、供应商起订量和采购周期共同形成。对于有保质期的商品，还需要增加有效期和批次约束，否则系统可能为了达到目标库存而采购无法消化的数量。
在预测前，我会先对订单数据做业务标记。正常销售、活动销售、预售、补发、内部领用、异常订单和退货反向入库，应该分别处理。尤其是断货期间的销量，不能简单作为低需求样本。
一个实用方法是建立“销量可用性标签”。当某天库存为零、订单取消率异常升高或商品处于活动状态时，系统在计算基础需求时降低该天数据的权重，或者将其交给人工确认。这样做不一定立刻得到最精确的预测，却能避免明显错误进入模型。
商品分层可以采用 ABC 与波动性组合，而不是只看销售金额。高销售额但波动大的商品，可能需要活动计划和人工审核；销售额中等但缺货损失很高的商品，也应提高服务水平；低销售额且交期短的商品，则可以减少安全库存。
| 商品类型 | 典型特征 | 建议补货方式 | 人工介入重点 |
|---|---|---|---|
| 核心稳定品 | 销量高、波动低、供应商稳定 | 规则自动生成，人工抽查 | 关注服务水平和缺货风险 |
| 核心波动品 | 销量高、活动多、需求变化快 | 预测加活动修正，必须审核 | 确认活动规模和渠道分配 |
| 季节性商品 | 销量集中在特定月份或节假日 | 季节曲线加提前备货 | 确认季节结束后的退坡速度 |
| 长尾商品 | 销量低、需求间歇、库存周转慢 | 低频审核或按单采购 | 判断是否继续销售和是否停补 |
| 新品 | 缺少历史销量，运营计划变化大 | 相似品参考加人工初始参数 | 复盘首周销量和转化变化 |
我判断一个补货系统是否成熟，不会先看它是否使用了复杂模型，而会看它能不能回答一条建议的来龙去脉。系统至少应该保留建议生成时的输入快照，包括库存数量、需求预测、交期参数、活动参数、规则版本和采购约束。
如果业务人员只能看到最新结果，看不到昨天系统为什么建议补货，也看不到参数何时被修改，那么这套系统即使短期有效，也很难形成组织能力。可解释性不仅服务于使用者，也服务于后续的模型优化和责任追踪。
补货系统最容易被忽略的基础，是 SKU、仓库、渠道、供应商和包装单位之间的关系。一个商品可能按件销售、按箱采购、按托盘运输。如果系统只保存销售单位，不保存采购倍数，最终建议数量就无法直接转成采购订单。
商品主数据还需要标记商品生命周期、保质期、供应商优先级、最小起订量、采购价格和替代商品。缺少这些字段，系统无法判断某个商品应该补货、调拨、替代，还是停止采购。
库存数据中心不一定要求所有业务系统一次性重建，但必须建立统一的库存状态映射。例如，仓储系统中的“可用”、订单系统中的“已分配”、采购系统中的“已下单”和质检系统中的“待检”，都需要映射到补货系统能够理解的状态。
数据同步还要记录时间戳。库存数量如果更新时间不一致，系统可能把上午的订单数据和前一天的仓库库存拼在一起，造成短时间内的虚假缺口或虚假充足。
需求预测模块的基本功能不是展示一条曲线，而是让企业能够比较实际销量与预测销量，识别预测偏差来自需求变化、库存不足、活动干扰还是数据错误。预测值必须可以被业务人员查看和修正，但修改也要留下原因。
如果企业处于系统建设初期，我建议先实现三种预测方式：稳定品使用移动平均，活动品使用基础销量加活动修正，低频品使用人工预测或相似品参考。等数据积累后，再评估是否需要引入更复杂的模型。
规则引擎负责把业务口径变成机器可执行的判断。规则可以包括补货点、覆盖天数、安全库存、最小起订量、采购倍数、预算上限、供应商黑名单和商品停补日期。
规则必须支持版本管理。例如，某个核心 SKU 在大促前临时提高安全库存，系统应记录生效时间、失效时间和调整人，而不是永久改写原始参数。这样活动结束后，企业才能恢复正常规则并复盘参数是否合理。
审核工作台应该按风险而不是按 SKU 数量组织任务。预计三天内缺货、供应商交期波动大、库存金额高、人工调整频繁的商品，应该优先进入审核队列。
建议页面至少显示以下信息：
补货建议只有进入采购、到货和入库环节，才算完成闭环。采购订单生成后，系统应记录供应商确认时间、计划到货时间、实际到货时间和入库合格数量。
这些执行结果会反过来影响未来补货。供应商连续延期，交期参数应当被重新评估；实际到货数量长期低于采购数量，系统需要提示供货能力风险；建议经常被人工下调，则说明安全库存或需求预测可能偏高。
在本文的示例中，我会优先把九数云放在“补货数据分析和管理看板”这一层，而不是把它描述成仓储系统或采购执行系统。企业可以将订单、库存、采购和到货数据经过统一口径处理后，接入分析平台，观察缺货、库存金额、周转、预测偏差和供应商交期等指标。
这样的定位更符合实际：分析平台负责把分散数据转换成可观察的经营视图，订单、仓储和采购系统仍然负责各自的业务执行。具体数据连接方式、字段能力和授权范围，需要以九数云官网公开信息以及企业自身系统条件为准，不能把看板工具误认为完整的补货交易系统。
我建议先建立四张核心看板：库存健康度看板、补货建议看板、供应商交期看板和预测偏差看板。管理层看到的是风险趋势，库存负责人看到的是 SKU 明细，采购负责人看到的是供应商与到货计划，三类角色不应被迫使用同一张大而全的报表。
下面的案例是为了说明系统逻辑设置的情景模拟，不代表某一家企业的真实经营数据。假设某电商企业销售一款标准商品，日均正常销量为 100 件，供应商中位交期为 7 天，补货运行周期为每天一次，目标覆盖周期为 14 天。
当前仓库账面库存为 2,000 件，其中可销售库存 1,200 件，已锁定订单 300 件，待质检库存 300 件，不可售库存 200 件。采购在途 800 件，但供应商只确认其中 500 件可以在 7 天内到货，另外 300 件存在延期风险。
如果只看仓库账面库存，企业可能认为当前有 2,000 件，按照日销 100 件计算可以销售 20 天，不需要补货。但这个结论忽略了锁定订单和不可售库存，也忽略了待质检库存不能立即支持销售。
按照更严格的口径，当前可销售库存只有 1,200 件。若未来 7 天需求约为 700 件，且确认在途为 500 件，那么到货后预计可用库存约为 1,000 件。若目标覆盖 14 天，目标需求约为 1,400 件，理论上已经存在约 400 件的补货缺口。
如果企业规定采购必须按 100 件为倍数，供应商最小起订量为 500 件，那么系统不会建议采购 400 件，而会将建议量修正为 500 件。这个修正不是算法误差，而是采购约束在业务中的真实体现。
假设第 5 天到第 7 天安排一次直播活动，预计三天额外销售 450 件。如果系统仍然使用日均 100 件的平稳需求，七天需求为 700 件；加入活动后，七天需求应调整为 1,150 件。
此时，确认在途的 500 件并不能完全覆盖活动需求。系统应提高风险等级，向审核人员展示活动参数、预计消耗和预计缺货日期，而不是静默地把建议量直接改大。
如果活动尚未锁定预算、流量和投放规模，预测值也不应被当成确定事实。更合理的做法是提供保守、基准和激进三种情景，让业务人员根据活动确定性选择采购方案。
假设华东仓预计缺货，但华南仓有 600 件可销售库存，且跨仓调拨需要 2 天。若华南仓未来 14 天不会出现缺口，那么系统应优先建议调拨，而不是直接生成采购单。
这就是为什么补货系统需要同时看到多仓库存。只看单仓数据，系统会把结构性错配误判为企业总库存不足，最终增加采购金额和仓储压力。
| 计算情景 | 未来七天需求 | 可确认到货 | 预计库存变化 | 建议动作 |
|---|---|---|---|---|
| 正常销售 | 700 件 | 500 件 | 约 1,000 件可用库存 | 按目标库存评估，建议采购 500 件 |
| 叠加直播活动 | 1,150 件 | 500 件 | 预计出现明显缺口 | 提高风险等级，审核加急采购或替代方案 |
| 华南仓可调拨 | 700 件 | 500 件加调拨 400 件 | 区域库存恢复平衡 | 优先调拨，延后或减少采购 |
| 供应商延期 | 700 件 | 仅 200 件按期到货 | 预计缺货日期提前 | 触发供应商风险预警和替代采购 |
这个案例的重点不是 500 件这个结果，而是建议量会随着库存口径、活动计划、跨仓调拨和供应商交期变化而变化。系统应该保留每一次计算的条件，让使用者知道建议量为什么改变。
如果业务人员最终选择不采购，而是通过调拨解决，也应该在系统中留下决策记录。后续如果该 SKU 仍然缺货，复盘时才能区分是预测问题、调拨执行问题，还是人工判断问题。
这类商品是最适合优先自动化的对象。企业可以使用移动平均或加权平均预测需求，再结合补货点、安全库存和采购倍数生成建议。
行动上不必让采购人员逐条审核所有 SKU，可以设置金额阈值和风险阈值。低金额、低风险建议自动进入采购申请，高金额或临近缺货建议进入人工审核。
这类商品不能只依靠历史订单。系统需要接收活动日期、预计曝光、折扣幅度、渠道分配和活动库存上限。活动开始前，应至少运行保守、基准和激进三个需求情景。
行动上可以先锁定一部分安全库存，再根据活动前一到三天的真实转化和库存消耗进行第二次调整。这样比一次性按照最乐观预测大量采购更能控制积压风险。
对于交期长的商品，补货系统必须提前识别风险。不能等到库存低于补货点才下单，因为采购订单即使立刻发出，也可能无法在缺货前到货。
行动上应把交期波动纳入安全库存，同时维护替代供应商、替代商品或跨仓调拨方案。若商品缺货损失很高，可以提高服务水平；若商品生命周期短，则应谨慎增加库存缓冲。
新品不能因为没有历史销量就让系统默认需求为零。初始预测可以参考相似商品、渠道资源、预计曝光、首批订单和运营计划，但必须标记为人工输入或低置信度预测。
行动上应设置短周期复盘，例如每天或每两天检查实际销量、加购率、转化率和退货率。首批采购不宜只根据乐观预估决定，最好分成首单、补单和应急供应三个层次。
长尾商品的主要风险不是缺货，而是补货后长期无法消化。若某商品未来没有明确营销计划、采购交期较长且库存周转已经很慢，系统应优先提示停补或按单采购。
行动上可以把这类商品从自动补货池中移出，改为人工确认。系统仍然保留库存和销售监控，但不再因为短期缺货预测自动生成采购建议。
如果一个仓库缺货，另一个仓库库存过高，第一选择通常应该是调拨，而不是采购。调拨是否可行，要比较调拨时间、运输成本、目标仓需求和调出仓的安全库存。
行动上可以设定调拨优先级：同区域仓优先，调拨后仍能满足调出仓覆盖周期优先，运输时间小于采购交期优先。只有调拨无法解决时，才进入采购补货。
规则系统的优点是透明、上线快、容易被业务接受，适合稳定品和系统建设早期。它的缺点是面对季节性、活动和突发波动时反应有限，参数需要人工维护。
预测系统能够处理更复杂的需求变化，但对数据质量、历史长度和异常标记要求更高。预测结果也不一定更容易被业务接受，尤其当模型无法解释某次建议时，采购人员可能重新退回表格。
我的判断是：先用规则建立库存口径和审核闭环，再在高价值、高波动商品上增加预测能力。不要为了“智能化”在基础数据还不稳定时强行上线复杂模型。
自动采购可以缩短执行时间，减少重复操作，但错误建议的放大速度也更快。尤其是供应商交期、活动计划或商品状态发生变化时，自动下单可能造成较大的资金和库存风险。
人工审核能够处理复杂例外，但审核成本会随着 SKU 和仓库数量增加。如果所有建议都让人逐条确认，系统只是把计算工作搬到了审核页面。
比较合理的方式是风险分级。低金额、稳定需求、参数完整的建议可以自动流转；高金额、交期异常、活动影响大或预测置信度低的建议必须人工审核。
把所有仓库当成一个库存池，计算简单，但无法反映区域履约和调拨时效。每个仓库独立补货，能够更准确地控制服务水平，但可能造成多个仓库同时囤货。
如果企业仓库之间可以快速调拨，可以使用区域库存池加调拨规则；如果仓库服务范围固定、运输时间长，则应以仓库为独立补货单元。系统设计必须服从履约承诺，而不是追求模型结构简洁。
库存不是越低越好。库存降低可能减少资金占用，但也可能增加缺货、加急运输、平台处罚和客户流失。服务水平也不是越高越好，因为为了极少数缺货风险增加大量库存，可能造成长期积压。
我建议按商品的缺货成本来设置服务水平。核心引流商品、会员权益商品和替代性低的商品，可以接受更高库存；替代品多、生命周期短、毛利低的商品，则需要更谨慎地增加安全库存。
这一阶段先不要急着讨论模型。需要确定 SKU、仓库、渠道、供应商、库存状态和采购单位的统一定义，并明确每个字段的来源系统、更新时间和责任人。
建议先选取一个仓库、一个渠道和一组核心 SKU 做试点。试点不是为了证明系统能够覆盖所有场景，而是为了尽早暴露库存状态、主数据和接口同步方面的问题。
在基础数据可以稳定获取后，再上线补货点、覆盖天数、安全库存和采购倍数。此时不必追求所有商品自动化，可以先服务于销量稳定、供应商可靠的核心 SKU。
系统上线初期，建议把结果与原有人工补货并行运行两到四周。对比的不是谁给出的采购数量更大，而是建议采纳率、缺货率、人工调整率、库存金额和预测偏差。
当基础规则运行稳定后，再接入促销计划、直播计划、节假日和商品生命周期。每个活动参数都要有开始时间和结束时间，否则活动修正可能长期影响日常预测。
同时建立异常规则，例如预计三天内缺货、供应商延期超过两天、预测偏差连续超过阈值、库存金额超过预算、商品即将下架等。异常规则的价值在于把有限的人工注意力集中到真正重要的商品上。
最终闭环应当包含补货建议、审核、采购下单、供应商确认、到货入库和结果复盘。采购订单不能只是系统里的结束状态，而应当继续跟踪是否按期到货、实际到货多少以及库存是否恢复到目标水平。
在这个阶段，九数云这类分析平台可以用于管理层和业务团队的复盘。通过统一的数据模型，企业可以按时间、仓库、供应商、商品类型和活动批次观察补货结果，而不是每次临时拼接多个 Excel 文件。
上线前，首先要确认系统输入是否可信。建议逐项回答以下问题：
其次要确认系统生成的建议能否进入实际业务。公式正确但流程无法执行，仍然不能算成功。
最后要确定系统是否能够证明自己有效。不要只看库存金额下降，因为库存减少也可能是缺货造成的。
建议至少同时观察缺货率、库存周转天数、库存金额、预测偏差、供应商按期到货率、补货建议采纳率和人工调整率。指标应按商品、仓库和渠道拆分，否则总体平均值会掩盖局部问题。
补货系统最重要的价值，不是让所有库存指标都向下，而是让企业能够更早知道库存风险来自哪里。缺货是因为需求上升、库存锁定、供应商延期、区域错配，还是数据同步失败，系统都应该给出不同解释。
如果系统只能说“建议采购”，却不能说明“为什么采购、采购多少、何时到货、谁调整过”，它更像一个自动填表工具，而不是补货决策系统。
以九数云为例，我更建议将其用于跨系统数据整理、经营看板、趋势分析和复盘，而不是让分析平台承担订单、仓储和采购执行的全部职责。数据分析平台可以帮助企业看到缺货率、周转天数、预测偏差和供应商交期的变化，但真正的订单状态、库存扣减和采购入库仍应由相应业务系统负责。
这种分工能够降低项目复杂度，也便于企业先形成可见、可追溯的管理结果。分析看板不能修复错误的库存口径，但它可以更快暴露哪个仓库、哪个供应商或哪个商品分层正在制造问题。
如果企业现在还没有补货系统，我建议不要先写一份庞大的功能清单，而是从最近 30 天的真实数据开始做一次小范围诊断。
我对电商补货系统的最终判断是：先建立可信的库存事实，再建立可解释的补货规则，最后才增加预测和自动执行。企业真正需要的不是一个看起来很智能的采购按钮，而是一套能够解释库存变化、暴露风险来源、支持人工决策并持续吸收执行结果的系统。补货计划做得越复杂，越不能跳过最基础的库存口径和业务责任边界。
我以前一直把仓库现存量当成可补货库存，直到一次大促前发现某 SKU 账面还有 1200 件，系统却提示 3 天后缺货。后来我才意识到，锁定库存、质检库存和在途库存如果没有拆开，补货结果很容易失真。
这是电商补货系统最容易踩的坑：仓库里的“现存量”不等于真正可用于销售的库存。补货判断至少要区分现有可售库存、已分配库存、在途库存、待质检库存和不可售库存。
在一次脱敏项目排查中，某 SKU 的库存台账显示有 1200 件，但拆分后发现：可销售库存 760 件，已锁定未发货 260 件，待质检 100 件，残次品 80 件。真正能支撑未来销售的库存只有 760 件，而不是系统首页显示的 1200 件。
库存类型数量是否直接计入可用库存处理建议 可销售库存760是参与补货计算 已锁定库存260否先扣除已分配订单 待质检库存100谨慎计入按质检通过率和时效处理 残次库存80否进入报损或维修流程 系统可以先采用一个可解释的基础口径：预计可用库存 = 当前可销售库存 + 可确认到货的在途库存 – 已锁定订单数量 – 预计销售需求。
关键不在于公式多复杂，而在于每个数据字段由谁维护、多久同步一次、出现异常后由谁修正。我的判断是，补货项目应该先做“库存口径治理”，再做预测算法。如果基础库存仍然混在一起，算法只会更快地输出错误建议。
验收系统时，建议随机抽取 20 个 SKU，逐项核对仓库实物、订单锁定量、在途量和系统可用库存，误差如果没有稳定控制在业务可接受范围内，就不宜急着上线自动补货。
我曾经用“近 30 天销量除以 30”计算日均需求，再乘以采购周期，结果在促销结束后出现了大量积压。现在我更关注需求覆盖周期、交期波动、活动修正和采购约束，而不是只看一个平均销量。
日均销量只能作为补货计算的起点，不能直接等同于未来需求。尤其是促销、断货、季节变化或价格调整期间，历史销量本身可能已经被扭曲。一个更适合系统落地的基础框架是：建议补货量 = 目标库存 – 预计库存。目标库存通常包括预测覆盖期需求和安全库存，预计库存则要扣除锁定订单，并谨慎加入能够按时到货的在途库存。
下面是一组用于说明系统逻辑的示例数据，并非某企业真实经营数据： 参数数值 未来日均预测销量100 件 覆盖周期14 天 安全库存300 件 当前可销售库存900 件 已锁定未发货库存200 件 确认可按时到货的在途库存500 件 采购倍数100 件 按这个口径计算，目标库存为 100 × 14 + 300 = 1700 件；
预计库存为 900 + 500 – 200 = 1200 件；理论补货量为 500 件。由于采购倍数是 100 件，系统最终建议补货 500 件。但这里有一个容易被忽略的前提：500 件在途库存必须有较高概率在需求发生前入库。
如果供应商历史交期为 7 天，但近三个月实际交期在 5 至 14 天之间波动，那么这批在途库存不应无条件全部计入预计库存，而应按照到货置信度或风险等级折算。实际建设时，我建议将商品分层。销量稳定的成熟商品可以使用补货点和覆盖天数规则；促销商品要叠加活动计划；新品应允许人工录入初始预测；
滞销商品则需要设置补货冻结条件。系统不是为了替业务人员取消判断，而是把判断依据固定下来，避免每个人用一套表格和一套经验。
我参与过一次库存系统规划，业务方一开始就要求预测模型和自动采购，但项目推进后发现，连 SKU 包装单位、供应商交期和可用库存定义都没有统一。最后我们先用规则跑通流程，反而比直接做复杂模型更快看出问题。
我的判断是：大多数电商企业应先做规则引擎和数据基础，再逐步增加预测能力。原因不是预测模型没有价值，而是模型依赖稳定、完整且口径一致的数据。
如果同一个 SKU 在商品系统里按“件”管理，在采购系统里按“箱”下单，供应商最小起订量又是 20 箱，那么即使预测需求很准确，最终采购量仍可能因为单位转换错误而失控。
比较稳妥的建设顺序如下： 阶段先解决的问题建议功能不建议过早做的事 第一阶段库存是否可信库存口径、SKU 主数据、在途和锁定库存全自动下采购单 第二阶段补货是否可解释补货点、安全库存、覆盖天数、采购倍数复杂预测模型 第三阶段需求是否可预测促销修正、季节性分析、预测偏差监控不设人工审核的自动执行 第四阶段采购是否形成闭环审核、下单、到货反馈、参数复盘脱离业务流程追求智能化 规则引擎的价值在于把采购人员脑中的经验显性化。
例如，核心商品的安全库存天数设为 5 天，长尾商品设为 2 天；供应商交期超过 10 天时提高风险等级；商品处于下架计划时自动冻结补货。这些规则虽然不“炫”，却比一个无法解释的预测数字更容易被业务接受。当系统连续运行一段时间后，再观察哪些商品适合模型化。
可以重点看预测偏差、断货次数、人工调整率和交期波动，而不是只看一个预测准确率。如果某类商品每次系统建议都被人工大幅修改，说明问题可能出在活动数据、库存口径或业务规则，而不一定是模型不够复杂。
我以前遇到过系统在大促前仍按平日销量补货，活动开始后库存很快见底；也遇到过供应商延期，但系统继续把原定到货量计入库存，导致采购人员误判。现在我认为，异常处理能力比“自动生成采购建议”更能决定系统是否真正可用。
真实业务中的补货并不是每天按照同一套参数运行。大促、供应商延期、新品上市、商品下架和多仓失衡，都会让普通补货规则暂时失效，因此系统必须支持例外策略，而不是只提供一个固定公式。大促场景下，系统至少要增加活动开始时间、预计增量、活动持续天数和渠道分配量四个字段。
比如日常销量为 100 件，活动预计带来额外 80% 的需求，系统就不能继续用 100 件作为未来日均需求，而应将活动期间预测调整为约 180 件，并在活动结束后恢复或重新评估。供应商延期时，系统要重新计算预计到货时间，而不是继续沿用采购订单上的承诺日期。
建议为供应商记录承诺交期、实际交期、中位交期和延期次数。当某批在途库存无法在缺货前到达时，应从可用在途库存中剔除，并触发加急采购、替代供应商或仓间调拨建议。新品没有历史销量时，可以采用相似商品映射。
系统先选择相同品类、价格带、销售渠道和包装规格的历史商品，使用其上市初期销量作为参考，再由运营人员输入活动曝光和首批备货假设。这里不应把相似商品的历史销量直接当成新品预测，而要保留人工修正和调整原因。
异常场景系统动作人工需要确认的内容 大促临近切换活动预测参数并提高风险等级活动增量、渠道分配、活动持续时间 供应商延期重算预计到货和缺货时间是否加急、替代供应商、调拨方案 新品上市调用相似商品或人工初始预测首批备货量、销售渠道、推广计划 商品下架冻结常规补货建议清库存计划和最后采购批次 多仓库存失衡优先判断调拨而非新增采购调拨成本、时效和区域需求 还有一个经常被低估的设计点：系统必须记录人工修改前后的数量和原因。
例如系统建议采购 1000 件，业务人员改成 600 件，不能只保存最终结果，还应记录修改人、修改时间、修改原因以及后续缺货或积压结果。只有这样，企业才能判断是系统规则有问题，还是人工判断有问题。我建议把“异常处理覆盖率”和“人工调整率”纳入上线验收。
一个能处理少数标准商品、却无法应对活动和延期的系统，自动化程度看起来很高，实际仍然会把复杂工作推回 Excel。补货系统真正成熟的标志，不是完全没有人工，而是人工介入有边界、有依据、可追踪。
读者评论
文章把库存状态拆分、可用库存定义和在途库存可信度讲得比较清楚，尤其适合正在从表格管理转向系统化管理的中型电商企业。
补货建议需要可解释和可追溯，这一点很有实际价值。记录人工调整原因，确实有助于后续区分系统参数问题和执行偏差。
文中对促销、断货和长尾商品的分析较客观。不同商品采用不同规则，比单纯套用近七日销量平均更符合实际业务。
文章强调先统一库存口径、再逐步引入预测算法，路径比较稳妥。不过实际落地时，多仓调拨和数据治理往往还需要较高的协同成本。