电商库存操作手册：缺货预警对应的新手避坑步骤
库存预警显示“可售库存只剩 20 件”，不一定代表今天就该补 20 件，也不一定意味着商品真的快卖完了：这 20 件可能包含已付款未出库订单，近两天的销量可能又被一次直播活动放大，供应商的交期也可能从平时的 7 天延长到 15 天。缺货预警不是一个孤立的库存数字，而是一项由库存口径、需求变化、补货时间和执行动作共同决定的经营判断。我在梳理电商库存问题时，通常先不看系统弹出的红色提示，而是追问：这条预警使用了什么库存口径、覆盖多长时间、依据哪些订单和交期，以及谁需要在什么时候采取什么动作。
新手最容易把“库存预警”理解成“库存低了，马上采购”。但一条能指导行动的预警，至少需要回答三件事：预计什么时候会卖完，补货最晚什么时候必须下单，以及如果现在补货，是否会带来过量库存或资金压力。缺少任意一项，预警都可能只是提醒，不足以直接成为采购指令。
我建议先把预警拆成“现状、风险、动作”三层。现状描述库存和订单，风险判断在补货到仓之前会不会断货，动作则明确采购量、责任人和复核时间。比如“可售库存 50 件”是现状；“按近 14 天日均销量估算，约 5 天后库存不足”是风险；“今天确认供应商交期，明天下午前决定是否下单”才是动作。
库存数字只能说明某个时点的状态，不能独立证明应该采购多少。采购数量还取决于到货周期、在途货量、已承诺订单、促销计划、商品生命周期和最低起订量。把这些条件放进同一套判断逻辑，预警才有机会从“看见问题”变成“降低缺货概率”。
我通常按“口径，速度，时间，覆盖，动作”顺序排查，而不是先套复杂公式。这个顺序的好处是先排除数据错误，再讨论需求预测；否则，库存口径错了，后面的精确计算只是把错误算得更精致。
如果团队刚开始建立预警，不必一次引入复杂预测模型。先做到数据口径一致、每天能查到风险商品、每条预警都有人处理，通常比堆叠更多指标更有价值。系统能报出风险，但不能替团队确认供应商是否真的能按时发货。
在实际运营中，同一商品可能同时出现在平台店铺、仓库、采购单、第三方仓配系统和财务报表里。每个位置显示的数字看似都叫“库存”，含义却可能不同：仓库实物数、系统账面数、可售数、锁定数、在途数和预计到货数并不能直接相加。
举例来说，仓库实物有 120 件，其中 25 件已被订单占用，10 件正在质检，另有 40 件采购在途。若平台显示的 120 件没有及时扣除已占用订单，运营人员可能以为还有充足货量；如果采购人员又把在途 40 件全部当成确定到货，补货决策还会进一步偏低。
我会把库存拆成几个可解释的量，而不是把它们压成一个“库存总数”。简单的可用库存口径可以写成：可用库存 = 可售实物库存 − 已分配未发货数量 − 其他不可售占用数量。如果在途库存预计未来到货，还应单独列示，并标注预计到货日期和可信程度，不要无条件算进当前可售库存。
一款日常销量稳定的商品，每天上午更新一次库存可能够用；一款正在直播间销售、短时间订单集中涌入的商品，每日更新一次就可能太慢。相反，一款每月只卖几件的长尾商品，即使实时刷新，也未必需要每天由采购人员手动处理。
库存预警需要匹配商品的销售速度和渠道变化。多个平台共用一个仓时，单平台库存看起来充足，不代表全渠道库存充足；平台订单与仓库出库数据不同步时，库存还可能出现短时虚高。新手应先问“数据多久刷新一次、刷新前后是否可能产生订单”，再判断提醒频率是否合理。
缺货直接造成的影响是订单无法履约，但经营损失还可能包括广告费用浪费、活动资源位利用率下降、消费者转向替代商品、客服解释成本上升，以及补货后库存积压的反向风险。并非每个商品断货一天的损失都相同，因此不能只按销量给所有商品设同一个预警阈值。
我会优先识别“缺货后果”和“补货难度”同时偏高的商品。例如，一款高销量、交期长、替代性低的核心商品，值得较早预警；一款低销量、容易替代、供应商随时可补的小配件，则可以采用较低库存和人工复核策略。预警的价值在于把注意力放到值得处理的风险上，而不是制造更多红点。
给所有商品设相同的“低于 50 件就采购”阈值，操作简单，却忽略了商品销量差异。一款日销 2 件的商品，50 件库存足以覆盖很长时间；一款日销 80 件的商品，50 件可能连一天都撑不住。固定件数适合极少数销量、交期都非常稳定的品类，不应直接推广到全店。
更实用的初始判断是库存覆盖天数：库存覆盖天数 = 可用库存 ÷ 预估日均销量。例如可用库存 90 件，近期平稳日均销量 15 件，覆盖约 6 天。若补货实际需要 12 天，这个商品就有交期风险；若补货只需 2 天，结论则完全不同。
覆盖天数不是预测本身，而是一个便于比较的筛选指标。日均销量应考虑统计窗口、促销影响和近期趋势；如果商品刚上新，历史数据不足，就需要结合类似款、推广计划和人工复核，不应把短期销量直接外推成长期需求。
七天窗口反应快，但波动可能很大；九十天窗口更平滑，却可能滞后于最近的增长或下滑。只用一个窗口，容易在“大促后销量回落”时继续高估需求，也容易在新品起量时低估需求。
我建议至少并排观察短、中两个窗口，例如近 7 天和近 28 天，并标记大促、直播、断货、降价和广告投放变化。短期销量显著高于中期，先判断是持续增长还是一次性事件；短期销量低于中期，也要确认是否曾经缺货，因为缺货期间的成交数据会把真实需求压低。
销售记录不等于需求记录。商品没有库存时，实际成交下降，并不意味着消费者需求同步消失。对反复断货的商品，应结合加购、收藏、缺货前销量、客服咨询和替代品变化判断，避免用被供给限制的销量低估补货需求。
合同写“7 天交货”，未必意味着从下单当天起 7 天内货物已经可以销售。下单确认、排产、生产、发运、运输、收货、质检和上架都需要时间。若只算运输天数或供应商口头承诺，常常会漏掉流程中的隐性等待。
我会按供应商和商品记录实际下单日期、发货日期、仓库签收日期以及质检完成日期，分别看平均值和较慢情况下的交期。对于波动大的供应商，补货判断不应只按平均数制定。关键商品可以用交期区间或偏保守的交期估计；普通商品则可采用更经济的安全库存，并接受一定程度的缺货风险。
库存过多并非没有成本。货物可能过季、跌价、损坏或占用现金，也可能挤压新品和高周转商品的采购预算。若品类有保质期、款式迭代快、价格波动大，过量补货带来的损失甚至比短时缺货更难弥补。
在促销前补货时，我会把“促销需求”和“常态需求”分开测算。活动销量不能未经调整就并入未来日均销量，否则活动结束后库存容易高估。更稳妥的方式是单独记录活动预测、活动结束后的回落假设、未售库存处置方式，并为预测偏差准备可调整的采购节奏。
系统可以根据设置好的规则计算风险，但如果商品编码不一致、退货回库延迟、渠道库存未汇总或在途状态长期不更新，输出结果就会受到输入数据限制。预警颜色越醒目，不代表数据越准确。对新接入的数据源，我会先抽查订单、库存变动和采购到货记录是否能相互对上。
正确的做法不是因噎废食地拒绝自动化，而是设定“自动筛查、人工处理异常”的边界。对数据稳定、销量规律的商品，可以自动生成建议；对新品、活动品、长交期品和异常波动品，则保留人工确认。自动化应减少重复核对，不应取消关键判断。
需求口径最好与采购决策的时间范围对应。日常商品可以查看滚动 28 天销量，同时用近 7 天检查趋势；促销商品则把活动订单和常态订单拆开。若跨渠道销售，还要统一商品规格、套装换算和退货规则，否则“销量”可能把不同单位混在一起。
对有明显星期效应的商品，可以比较同一星期几的销量；对季节品，需参考去年同期并检查今年的价格、流量和供给变化。历史同期不是直接复制的答案，而是用于提示季节性。新品没有足够历史记录时，要把预测不确定性写明，并通过小批量补货、缩短复核周期来控制风险。
补货提前期应覆盖采购决策到商品重新可售的全过程。可按采购审批、供应商备货、生产或拣货、运输、收货、质检和上架分别记录天数。这样做不仅能算补货周期，也能发现真正的瓶颈：如果大部分等待发生在内部审批，单纯催供应商并不能缩短缺货时间。
建议对每个关键供应商维护一段时间的实际交期记录，而不是只记“最快一次”。对交期稳定的供应商，可用典型交期；对波动明显的供应商，可用更保守的交期区间，或针对高风险商品增加缓冲。这个缓冲应有原因和复核周期，不能因为过去发生过一次延误，就永久堆高所有商品库存。
一个常见的启发式计算是：再订货点 = 交期内预计需求 + 安全库存。若日均需求为 20 件，实际补货周期为 10 天，期间预计需求约 200 件；如果根据需求波动和交期风险留出 50 件安全库存，再订货点约为 250 件。这里的数字是示例，不代表某个行业通用参数。
安全库存不是越多越好。设置过低，交期或销量一有变化就容易断货；设置过高，则现金和仓储空间被占用。更合理的方式是按商品重要性和不确定性分层，并定期复核：销量越稳定、供应越可靠，缓冲可以相对小；需求波动大、补货难、缺货影响大的商品，才更有理由提高缓冲。
如果团队的数据不足，不必伪装成精确的统计模型。可以先用“稳定、一般、高波动”分类，对应不同的复核频率和缓冲策略；积累实际销量和交期后，再逐步用历史偏差优化参数。写清楚这是建议基准还是经数据校准的参数，比给出一个看似精确的小数更负责任。
再订货点回答“什么时候要处理”，不直接回答“订多少”。一个便于执行的估算方式是：建议采购量 = 目标库存 − 当前可用库存 − 可信在途库存 + 已确认的额外需求。目标库存可以依据补货周期内需求、复核周期和缓冲计算。
“可信在途库存”需要谨慎定义。如果采购单已确认、供应商已排产且物流状态可靠，可以纳入；如果只是口头承诺或订单尚未审批，应单独显示，不要把它当成确定供给。否则系统看似库存充足，实际货物仍可能没有进入生产或运输。
采购建议还要经过整箱数、最低起订量、预算、库容和商品保质期等限制。计算结果为 73 件，若供应商必须按 100 件一箱发货，决策应明确说明多出的 27 件如何消化，而不是静默向上取整。条件不满足时，可以拆分批次、协商混装或调整采购时间。
每个商品都按相同频率人工审查，成本很高。我会结合销售贡献、缺货影响、供应风险和生命周期做分类。高贡献、长交期、缺货影响大的商品应高频监控；长尾低销量商品可采用较低频率和批量复核；临近下架或清仓商品则应优先控制新增库存。
ABC 分类可以用于初步识别销售贡献，但不能单独决定补货策略。一个销售额不高但缺货会影响套装销售的配件，可能仍然关键；一个销售额高但供应极稳定、替代容易的商品，风险处理方式也未必与核心爆款相同。分类是分配注意力的工具，不是自动下结论的标签。
下面以一家多渠道经营的家居用品商家为情景案例。为避免把示例误当成某个商家的真实经营数据，所有数值均为样本推演数据，只用于演示判断过程，不代表九数云的客户数据，也不是行业平均水平。实际使用时，应替换成店铺订单、仓库库存、采购单和供应商交付记录。
情景中的商品 A 是一款日常畅销收纳用品。仓库账面 460 件，已有 70 件订单待出库，15 件处于质检冻结，系统显示采购在途 180 件。近 28 天平均日销量约 28 件，近 7 天平均日销量约 36 件，其中 3 天受促销带动；供应商合同交期 8 天，但最近几批从下单到可售分别用了 9、11、13 天。
如果只拿 460 件账面库存除以 28 件日销量，覆盖时间约 16 天，看起来暂时安全。但扣除待发订单和冻结库存后，可用库存是 375 件；若 180 件在途尚未确认到货时间，也不能无条件算作可用供给。再用更接近近期的销量观察，库存风险就明显高于账面数字呈现的状态。
在这类排查里，我会把订单明细、商品维度库存、采购单状态和供应商交期整理到同一个分析视图。以九数云为例，实际搭建时可以围绕数据表、商品编码和日期字段组织分析，先确认不同来源能否按商品和时间关联，再制作库存、销量、在途和预警的视图。具体连接方式与可用功能应以产品当前支持情况和企业数据权限为准。
第一张视图不必复杂，至少显示商品、仓库、可用库存、待发订单、冻结库存、可信在途、近 7 天销量、近 28 天销量、实际交期和预计覆盖天数。第二张视图可以展示预警处理状态，例如待核实、待采购决策、已下单、在途跟踪和已关闭。这样团队才能知道红色提示是否已经有人处理，而不仅是每天重复看到同一条提醒。
对商品 A，分析时先把账面数 460 件拆成实际状态，再把近 7 天促销销量与近 28 天常态数据对照，最后把最近三批实际交期放进补货判断。若在途 180 件尚未出货，就记录为“已下单、交付风险待确认”；若已发运并有可靠到货日期，则单列预计到货，不与仓库现货混算。
一张分析看板的价值不在颜色，而在于能否推动下一个动作。预警字段可以包含风险等级、缺货预计日期、预计到货日期、剩余安全天数、处理人、最近处理时间和处理结论。比如商品 A 的处理结论可能是“供应商确认排产，预计 6 天后发货；现有库存覆盖约 10 天；两天后复核物流状态”。
团队还应记录预警是否准确。商品后来没有缺货，不一定说明预警错了；可能是临时调货、销售回落或供应提前到货。相反，商品实际断货，也要判断是预测偏差、数据延迟、采购审批慢还是供应商违约。只有把结果和原因记录下来，参数才有改进依据。
如果只在报表中展示“库存低于阈值”，管理者很难知道风险究竟来自需求激增、库存锁定、供应延误还是数据接口异常。通过九数云这类分析工具整理来源数据的意义，是让不同角色查看同一口径的过程信息；它不能代替仓库盘点、供应商确认和采购审批。
在这个情景里，我不会直接说“商品 A 应采购多少件”，因为还缺少未来活动计划、在途到货可信度、最低起订量和可用预算等条件。能做出的专业判断是：当前可用库存应按 375 件核算；促销销量不能直接延伸为长期日均需求；实际交期比合同承诺更长且有波动；180 件在途需要核实状态后再纳入供给计划。
这类判断比输出一个看似精确的采购数量更有用。采购建议必须附上前提，例如“若在途货物确认在 6 天内到仓，且活动后日均销量回落至 28 件，可暂缓新增采购并在两天后复核”；若在途货物无法确认或销量持续高于基线，处理方案就应相应调整。
这是最适合提前处理的状态。先核对可用库存和在途，再向供应商确认是否已排产、是否已发货以及预计可售日期。若当前可用库存覆盖时间小于实际补货周期，就应尽快做采购或替代方案判断，不要等待平台库存变成零才启动审批。
如果货物已在途且状态可靠，可以先设置复核时间，确认物流没有异常；如果供应商还未确认排产，则按较保守的供给情景准备补货方案。必要时评估跨仓调拨、渠道限售或替代商品引导，但这些动作也有成本，不能只看能否暂时延长库存天数。
先看增长来自自然需求、价格变化、广告、达人内容、直播活动还是平台活动。若订单主要来自短时投放，活动结束后需求可能回落；如果搜索、加购和多个渠道订单同步增长，持续性可能更强。新手应尽量把“已发生的销量”与“未来计划中的流量”分开。
尚不能判断持续性的商品，可以采用小批量、分批到货或提高复核频率的方式降低两头风险。采购动作不必只有“完全不买”和“一次买足”两个选项。与供应商协商锁产能、分批交货、预留补单能力，可能比盲目大批量采购更适合波动中的需求。
这时应重点管理供给风险，而不是频繁修改销量预测。先统计最近若干批次从下单到可售的完整周期，识别延误发生在哪一段；再与供应商约定交期确认节点和异常升级方式。对于关键商品，可考虑备用供应商、替代规格或合理的安全库存。
如果第二来源价格明显更高，不代表一定要转单。可以把备用供给限定在紧急情景，或用小比例采购验证质量和履约能力。选择时比较的不只是采购单价，还包括断货损失、质量一致性、最低起订量、运输时间和切换成本。
这类商品的决策方向通常与常规畅销品相反。预警出现时，先检查剩余销售窗口、促销计划、退货风险和供应商是否允许取消订单，避免因为“库存低”机械补货。若剩余库存预计足以覆盖销售窗口，就应优先降低新增采购和清理慢动库存。
但也不能只因为商品准备下架就忽略已承诺订单、售后换货和配套商品需求。补货量可能需要覆盖已付款订单和售后责任，却不一定需要恢复到常规安全库存。退出计划应该设置明确截止日期，并跟踪尾货处置，不让旧规则继续触发采购。
新品预警最大的难题不是公式，而是预测依据不足。可以参考相似商品、售价、推广预算、首发渠道和供应商交期，先做低、中、高三种需求情景，并标注每种情景的假设。首批采购的目标通常是验证市场和供应链，而不是证明预测模型有多精确。
新品上市后，应缩短复核周期，观察实际转化、退款、评价和补货周期。若数据快速累积，再逐步调整安全库存；若销量达不到预期，应及时暂停追加采购。对新品来说，分批决策比一次性追求库存充足更能控制预测错误的代价。
先确认库存分配规则、各平台占用更新时间和仓库回传速度。若系统只能定时同步，就要根据高峰订单速度留出同步缓冲，必要时设置渠道库存上限。一个平台显示的可售库存不应被误认为全渠道都能使用的自由库存。
如果各平台商品编码、规格或套装关系不统一，应优先处理主数据映射。比如一个套装消耗两个单品库存，却只按一个商品编码统计，库存预警就可能低估真实消耗。出现库存负数、超卖或平台间长期对不上时，应先排查数据和分配规则，不要通过临时加库存掩盖问题。
增加安全库存能缓冲需求波动和交期延误，但会增加资金占用、仓储费用和跌价风险。减少安全库存能释放现金，却要求供应链稳定、库存数据可靠、补货响应迅速。决策时应把商品毛利、缺货损失、库存贬值速度和资金成本放在一起，而不是把“库存越低越好”或“缺货绝不能发生”当成统一原则。
对高毛利、缺货影响大的核心商品，较高的服务保障可能值得投入；对生命周期短、价格变化快的商品，过高库存可能不划算。若团队还没有可靠的缺货损失估算，可以先按商品分层试行不同缓冲，再比较实际缺货次数、积压天数和资金占用变化，不必一开始追求全店统一的最优值。
自动预警适合重复、规则明确、数据质量较好的场景。它可以减少人工筛选商品的时间，但对新品、促销、供应商异常和生命周期变化，仍需要人判断。完全手工容易漏报，完全自动又可能放大数据错误，比较稳妥的设计是让机器负责发现异常，让负责人处理例外。
自动化程度应随着数据成熟度提高。刚接入时，先让报表与人工台账并行一段时间，抽查关键商品和采购记录；确认库存口径、刷新延迟和订单状态稳定后，再自动生成建议。涉及大额采购、易过期商品或不可撤销订单时，保留审批环节通常更合理。
全店统一规则更容易培训和维护，但可能忽视商品差异；每个商品单独设阈值，判断更细，却带来大量维护工作和规则失控。建议先建立少量可解释的商品类型，例如稳定畅销、活动波动、长交期、新品和清仓，再为每类制定基础逻辑，并只对关键例外做个性化调整。
规则还要有复核周期。若一个商品从常规销售转为季节爆发，原来的参数就不再适用；若供应商改善交期，过高的缓冲可能持续占用资金。应记录规则修改日期、修改依据和负责人，避免预警阈值变成没人知道为何存在的历史遗留设置。
当库存数据分散在多张表、多个平台和不同系统时，数据分析工具可以帮助统一观察维度、制作风险视图和跟踪趋势。以九数云为例，可以把它作为业务数据分析与可视化的考察对象，重点评估数据连接、字段整理、报表维护、权限管理和团队使用习惯；是否适合企业，还要结合实际数据源、部署要求和当前产品能力逐项验证。
工具选型时，我会先拿一个真实且范围有限的问题做试点：例如跟踪 20 个高风险商品，核对库存口径、更新频率、预警处理时间和复盘记录。不要只看演示页面是否好看，也要检查商品编码是否能匹配、异常数据是否能追溯、业务人员能否理解指标，以及报表由谁维护。
如果企业库存规模小、单仓经营且采购交期短，维护复杂分析系统可能不划算；如果多渠道、多仓、商品量大，手工汇总已经经常错过处理时间，建立统一分析视图的价值就会更明显。工具投入应由业务复杂度和错误成本决定，而不是由功能数量决定。
日常操作不必复杂，但每一步都要有明确输入和输出。建议团队按固定顺序处理，减少同一条预警在运营、采购和仓库之间反复转发却没有结论的情况。
对紧急商品，可以设置单独的升级条件，例如预计库存覆盖时间小于最短补货周期时，当天必须确认处理负责人。具体阈值应结合企业交期和业务节奏，不要机械套用某个天数。最关键的是升级规则要让相关人员看得懂，也能在真正触发时找到决策人。
只看“本周发生几次缺货”不足以判断预警系统是否有效。还要看预警提前量、误报率、漏报率、库存准确率、供应商实际交期、紧急采购比例和滞销库存变化。每个指标都需要统一定义，否则不同部门会用不同口径解释同一个结果。
指标复盘要能追到原因。预警提前量缩短，可能是需求突然增长，也可能是库存数据刷新变慢；紧急采购增加，可能是采购审批拖延，也可能是供应商交期恶化。不要看到单项指标变差就直接改阈值，应先抽样查看具体商品的时间线和操作记录。
对于刚开始做库存预警的团队，我建议从范围小、风险清楚的商品开始，不要一上来给全店上规则。下面的启动安排用于建立基本闭环，时长和分工可按团队规模调整。
试点期间，建议把预警结论分成“确认风险、数据待核实、无需采购、需要采购、持续观察”几类。这样能避免所有异常最终都变成采购单，也能让管理者看到团队正在处理哪些风险、哪些仍缺少证据。
最简记录可以包括商品、触发时间、当时库存口径、销量窗口、实际交期、风险判断、处理动作、负责人、计划完成时间和最终结果。若预警后来被证明不准确，也要保存原因，例如活动结束导致销量回落、在途提前到货或仓库库存数据未及时更新。
这份记录不只是为了追责，而是为了减少重复犯错。若同一供应商连续几次交期超出承诺，团队可以调整交期假设；若某类促销经常产生短期峰值，需求分析就应单独处理活动数据；若大量预警来自库存状态不同步，优先改善数据链路可能比增加安全库存更有效。
缺货预警的核心，不是让所有商品都拥有一个看起来精准的安全库存数字，而是让团队知道哪些数字可信、哪些风险值得优先处理，以及判断错误时会付出什么代价。我更愿意先把库存口径、实际交期和处理责任做扎实，再逐步增加预测复杂度。因为一套简单但能复盘的规则，通常比一套无人理解、数据不稳的复杂模型更能保护经营结果。
下一步可以从少量高风险商品开始：核对一次库存口径，整理最近几批真实交期，计算当前覆盖天数，并给每条预警指定负责人和复核时间。等试点跑通后，再扩展到更多商品和渠道。预警系统真正落地的标志，不是报表上出现了多少红色提示，而是团队能在商品断货之前解释风险、采取行动，并在事后知道下一次该改哪里。
我刚接手店铺库存，看到可售库存低于 100 件就想设预警，但不同商品补货周期差很多。爆款补货要一周，长尾商品可能一个月都卖不动，我该怎么设一个不容易误报、也不容易漏报的预警线？
预警线不宜直接套用固定件数，更实用的起点是“补货周期内预计销量＋安全库存”。例如某商品日均销量 18 件，供应商从下单到入仓平均需要 5 天，安全库存暂定 30 件，则预警线为 18×5＋30＝120 件。这里的 30 件是应对销量波动和到货延迟的缓冲，不是所有商品都适用的标准答案。
日均销量建议先看近 14 至 28 天，并剔除断货日：断货期间销量低，不代表需求低。若近期开过促销，可单独记录促销日销量，不要直接把峰值外推到每天。新手可先每周复核一次预警商品，记录实际到货天数和预警时的可售库存，连续积累 4 周后再调整参数。
我发现后台显示还有几十件库存，但顾客下单时却提示缺货；有时仓库说货还在路上，运营又把它算进可售数量。我分不清哪些库存应该参与预警，怕重复扣减或把不能卖的货算进去，有没有一套核对顺序？
先统一口径：可售库存通常从实物库存出发，扣除已分配给订单的数量、质检不合格品和明确冻结的库存。举例：仓内实物 100 件，其中残次 6 件、已付款待发货 20 件、活动锁定 12 件，则当前可售为 62 件。注意确认“已付款待发货”是否已在系统占用；若已占用，就不能在计算公式里再扣一次。
在途货不要和现货混成一个数字。只有供应商已确认发货、数量和预计到仓时间可信，且能赶在缺货前入仓时，才适合用于补货判断；未发货采购单应单独展示。每天固定一个时间核对仓库实物、订单占用和系统库存，差异超过设定值时先查原因，再改预警参数，避免用错误库存掩盖账实不符。
我同时在几个渠道卖同一款商品，仓库里看着还有货，但不同平台的订单几乎同时进来，偶尔会多卖几件。有人建议多留安全库存，也有人说把同步频率调高就行，我该先改库存缓冲还是先查系统同步？
先查“订单占用到渠道库存扣减”的链路和延迟，再决定缓冲量。假设仓库可售 15 件，两个渠道在同步间隔内各自仍显示 15 件，理论上可能同时接单超过实物库存；此时单纯提高预警线并不能阻止超卖。应优先确认订单创建后是否立即锁定库存、取消订单后是否及时释放，以及库存更新失败有没有告警。
在同步机制稳定前，可为共享库存设置临时缓冲，例如实物可售 15 件、保留 3 件不对外销售，则渠道总可售不超过 12 件。缓冲应结合高峰期订单速度和同步延迟复盘：记录峰值时段的订单数、库存回写耗时及超卖次数，连续观察一至两周后再调整。若延迟仍频繁出现，先修同步流程，不要长期靠压低可售量解决。
我第一次收到库存预警时，马上催供应商加单，后来才发现仓库还有一批货没上架，导致短期囤货太多。现在我想要一套从收到提醒到决定补货的步骤，尤其是不确定销量突然上涨是真需求还是活动造成时，该怎么判断？
建议按“验库存，验需求，验到货，做决策”处理，而不是看到提醒就下单。先核对仓内实物、待上架货和订单占用；再查看近 7 天销量是否由促销、达人带货或单日异常拉高；随后向供应商确认可供数量与实际交期。每一步都记下核对时间和数据来源，避免不同岗位拿着不同口径讨论。
例如预警显示只够卖 4 天，但供应商交期是 6 天，且活动刚结束，先用日常销量重算需求，再比较加急成本与缺货损失。若供应商交期不确定，可拆成小批补货并设置二次确认点；若是促销带来的短时峰值，则不要按峰值销量一次性备满。
处理结束后记录“预警时库存、实际到货天数、缺货天数和剩余库存”，下次用结果校准参数。
读者评论
把可售库存和在途库存分开看这点很实用，尤其是已付款未发货、质检冻结的货，确实容易让系统库存显得比实际宽裕。建议再补充一下退货回库未完成质检时怎么计数。
近7天销量遇到直播或促销很容易失真，文章建议和近28天对照，比直接套一个日均值稳妥。不过新品数据少时，类似款的参考范围也需要标明不确定性。
实际交期不只包括供应商发货，收货、质检和上架也会耗时，这个提醒很容易被忽略。把每个环节的日期记录下来，才能判断延误到底发生在哪一步。