门店上周要了20件矿泉水，这周再报20件，看起来最省事。可上周临时做了促销，仓里还剩12件；本周客流回落，重复补20件会积压。另一家门店明面上报库存12件，其中3件已留给团购订单，货架上实际能卖只有9件，若总部按“还有12”压低补货，又可能在周末断货。总部需要的不是让门店多填一张表，而是用同一商品、同一门店、同一时间的真实可用量、计划销量和可信在途，解释这次为什么补11件、为什么不是上次的20件。
以下12件、已锁3件、预计销20件、安全量5件、可信在途5件，是说明补货算法的业务示例。系统已有门店铺货上报、库存预警和周转预警等页面，但这些画面属于不同业务口径；不能把“门店上报库存”直接宣称为已自动参与智能采购计算。正式使用时，要依实际版本、租户配置和数据来源验证每一步。
门店先把库存报对：报数不是期末盘点的替代品
门店报库存至少说明门店、SKU、规格、单位、上报时间、上报人和当前数量。货架10件、后仓2件，合计12件；已被确认订单占用3件，可用于普通补货判断的只有9件。若有破损、临期或已退货待处理商品，不应混进“可售12件”。食品和日化的“件、箱、瓶”尤其要核包装关系：一箱24瓶的商品，门店报12箱与12瓶相差24倍；总部若不固定单位，补货建议再精细也会失真。
PC管理端已有“铺货上报”实拍：便利店某规格矿泉水库存数量12，并带上报日期与上报员工。它能作为核对门店报数来源的证据，不能单凭一条“12”证明今日可用库存仍为12。页面记录时间是9月14日18:27，如果总部次日中午才做采购，其间可能已经售出、退货或重新补进。运营人员应决定报数有效期，超过时限先让门店复核；零库存也要求明确上报，不能把“没填”自动解释成零。
图1：系统截图适合查报数对象、数量、时间与责任人；能否作为本轮可售库存，仍需门店核实当下状态。
门店员工常见的疑问是“早上刚收到货，下午上报能不能写新数量？”可以，但必须先完成实物验收，再确认新货进入哪个仓位和可售状态。车在路上但还没收货，属于在途，不属于门店现存；物流显示到达门口但卸货还没清点，也不能按送货单全数入库。若门店报数与系统库存不一致，应查销售漏记、破损、赠品或调拨，而不是覆盖系统数字只为生成补货建议。
图2：现存12件扣除已被订单锁定的3件，可分配量为9件；过期报数和单位错误都要先排除。
总部先筛异常报数，而不是立即按表格批量下采购单
总部拿到多门店数据后，先查“时间”和“变化”。一家日销约2件的门店从昨天12件突然变成120件，可能是箱件单位填错、重复收货，也可能是系统导入与人工上报重复。另一家本应每日上报，却连续三天没数字，不能沿用三天前的12件推断当前库存。异常应回给门店复核，并记录调整前、调整后和原因；否则采购员一旦按错误数据补货，后续很难说明是门店误报、汇总逻辑出错，还是总部手工改数。
校验并非只看“数字在0到999之间”。同商品要检查规格变更、包装换算、经营门店范围及可售状态。新品没有历史销量，不意味着可以直接补零；临期品库存多，也不一定能覆盖未来十天需求。退货待处理、质量锁定和为企业客户保留的库存，要从日常可售量中区分。集团门店若有区域仓，还要确认门店报数是店内现货还是区域仓分配给该店的额度，两者不能相加。
总部也不能要求店长为了让下次补货多一点而把库存少报。更好的管理方式是把“报数准确率”和“缺货、积压”一起复盘：频繁低报带来断货，也可能带来货架过量；频繁高报造成补货不足。只有让门店知道库存报得准会提高其补货优先级和配送稳定性，上报才不只是任务打卡。
把计划销量、已锁订单与可信在途放到同一张计算表
示例门店未来一个补货周期预计销售20件，希望周期末留下5件安全量。门店现存12件，其中3件已被团购订单锁定，可分配9件；另有5件在途且供方确认会在该周期内到店。净补货需求＝预计销售20＋安全量5－可分配9－可信在途5＝11件。这个算式没有考虑起订量、配送包装和保质期，还需要采购和运营确认，但至少能解释“为什么不是照抄上周20件”。
图3：业务示例按同一周期、同一单位算出11件；若在途无法准时到店，应重新计算，不机械扣减。
在途要分“已经下采购但还没确认交期”“供应商已发、物流可追”“已到仓待分拣”“已发往门店待签收”。四个状态不能统统算成今天能卖的5件。若只有1件明确周五前到店，另4件供应商尚未发，周末促销只应谨慎计算那1件，缺口可能增至15件。反过来，采购已下的5件若又被新建议当作未采购，系统可能再生成一次5件需求。采购员应以原采购、配送和签收记录跟踪，补货建议与在途状态一致时才确认。
系统的库存预警实拍显示某鲜品系统库存24、可用库存16、采购中12、安全库存下限30。它提醒我们“系统库存”“可用库存”“采购中”是不同列，不能简单用24＋12判定已有36可售；但这是一张企业仓商品的预警画面，不能把截图里的24自动代入前述门店矿泉水12件的计算。类似地，周转预警页面可观察销量与周转天数，用来识别卖得快、卖得慢的商品，不能替代门店当天的真实报数。
图4：真实界面将系统库存、可用库存和采购中分列；这属于企业仓口径，与门店铺货上报不能直接混算。
让补货建议有理由，也有人工修正的边界
11件是起点，不必强行成为最终采购数。供应商按整箱12件起订，采购可能买12件，并说明多出的1件预计多久卖完、是否会临期。如果门店下周有校园开学或商圈活动，运营可把预计销量从20提高到28，但要写明活动日期和依据；活动取消则把假设撤回。若供应商交期长、仓配每周只送一次，安全量可能要高于5件；高温奶保质期长和当天鲜奶过期风险不同，不能套同一备货天数。
门店还应有提出调整的渠道。店长知道隔壁工地停工，本周客流会降；总部历史销售模型未必知道。店长把建议11改为7时，应说明经营变化，不是简单拒绝总部。总部复核后保留原建议、修改值、修改人和日期，之后用真实销量验证判断。连续几次总是人工把建议翻倍，说明基础数据、季节因子或在途规则有问题，应改规则而不是指责一线“没有按系统执行”。
分店补货在总部采购之前还要合并供应商和物流约束。A店缺11件，B店缺7件，C店缺4件，合计22件；供应商起订一箱12件时，可买24件，但多出的2件应有明确承接门店。若各店不能存放，或有保质期限制，不应为了满足起订量把多余商品强塞门店。可以与供方谈分批发货、调整配送日或用另一个适销门店承接，并在采购与配送记录里说明。
门店签收以后，用缺货和积压两头检验补货结果
总部发出采购单，只能说明补货动作开始。供应商实际少送、区域仓分拣漏件、配送延迟和门店拒收都会使计划落空。门店要按实物验收数量，系统库存和门店上报数量随之更新；若购进12件实际收到10件，剩余2件是供方欠到还是配送中短少，要沿采购和出入库记录查。商品能在系统找到，不代表已经到货架上；门店实际缺货日、客户未买到的订单、临期和报损都应进入复盘。
图5：采购完成、门店签收和门店不断货是三个节点；复盘同时看缺货、剩货和损耗。
一轮试运行至少挑高频、低频和临期风险商品各一个，比较两周：按上次订货量机械补时的断货次数、期末库存和报损，与结合门店报数后的结果。若缺货从三天降为零，期末剩余却从4件变为40件，不能算成功；若库存下降但供应商晚到造成连锁断货，也不能只夸周转变快。统计周期、商品单位和门店范围要一致，避免用不同口径得出漂亮结论。只有库存上报准确、补货量可解释、到货可追、缺货和积压同步改善，才适合推广到更多商品与门店。
门店库存上报和自动补货之间，必须留一道人工确认
商猫云链可以帮助企业记录铺货库存、查看订单需求及库存、采购中的不同数字，并把采购与履约结果放回同一业务链；但POS实时销售、配方耗用、天气客流预测和门店报数自动生成采购单，并不能从上述截图直接推定已经连通。企业若要做到自动补货，先核数据来源和更新频率，明确谁批准建议、谁处理异常、何种商品必须人工审核。适合先把计算逻辑做成可复核的建议，再逐步提高自动化程度；尤其鲜品和促销品，不应让错误报数瞬间变成大量采购承诺。
门店负责真实报数和现场签收，总部运营负责销量假设与安全量，采购负责供方交期和起订量，仓配负责实际配送，财务看采购金额和损耗。职责不用复杂，但每个被修改的数量都要能回到原上报、原订单或原采购。这样总部即使没有复杂预测算法，也能用清楚的口径先减少“这家积压、那家断货”的反复补救。