过去三个月，我帮四家跨境电商卖家做过采购补货诊断，他们用的 ERP 分别来自不同厂商，年费从几千到几十万不等。有意思的是，这四家的问题几乎一模一样：系统里补货建议每天在生成，仓库里却是一边断货、一边堆货。我把他们的数据拉出来对齐后才发现，问题不在 ERP 的功能清单上，而在补货规则本身，固定补货点、只算账面库存、多平台共用一个库存池、补货公式里没有 MOQ 和交期波动。
这篇文章就把这些误区逐个拆开，讲清楚每一处该怎么在方案设计阶段就定下来，而不是等系统上线后再打补丁。
我在做 ERP 选型顾问的那几年，最常听到的一句话是"你们这个系统补货不准"。但把需求文档和实际配置对比之后，十次里有八次是同一个结论：系统忠实地执行了一套本身就错的规则。ERP 不会替你判断什么样的补货策略合理，它只会把你写进去的参数算得又快又准。
2022 年我参与过一个家居类目卖家的 ERP 替换项目。原系统和新系统的功能对比表列了 47 项，新系统在 41 项上持平或更优，剩下的 6 项也都是边缘功能。上线三个月后，采购负责人的反馈是"跟以前一样乱"。
我们做了一次回溯：新系统生成的补货建议，有 62% 被采购人工修改过。修改的原因集中在三类，系统不知道这个 SKU 下个月要参加平台大促、系统不知道供应商这个月产能排满了、系统不知道有一批货已经在海上漂着。这三类都是规则和数据问题，没有一类是功能缺失。
后来我形成了一个判断习惯：当一个团队说"ERP 补货不准"时，先不要看功能清单，先看三件事，主数据里有多少字段是空的、补货参数分了几层、异常有没有闭环。这三件事决定了 80% 的结果。
主数据质量指的是 SKU 的采购交期、供应商的 MOQ、仓库的上架周期这些字段是否真实维护。我见过太多企业，SKU 主数据里的"采购提前期"字段全部填 30 天，因为当年初始化时随手填的，三年没人改过。
参数分层指的是补货规则能不能按 SKU、仓库、渠道、季节分别配置。如果整个店铺只有一套补货天数，那系统再强也只能算出一个粗糙的结果。
异常闭环指的是当补货建议被推翻、交期被延误、质检不合格时，有没有人记录原因、有没有人复盘。没有闭环的系统，错误会一直重复。
我给企业做诊断时常用一个测试：随便挑一个补货建议，问采购负责人"这个数字是怎么来的"。能一路答到"因为 A 仓库 B 渠道的这个 SKU 用了 C 参数组，参数组里的安全库存是按 95% 服务水平算的"，说明方案设计是清楚的；答不出，说明规则是散的。
这个测试看起来简单，但我做过的项目里，第一次能通过的比例不到三成。剩下的七成，问题都出在方案设计阶段没有把规则显性化。
抽象地讲误区容易变成空话，我更愿意从具体的现场讲起。下面三个场景来自我参与过的脱敏案例，姓名和数值做过处理，但业务逻辑是原样的。
一家做 3C 配件的卖家，月销大约 40 万美元，SKU 数 380 个，主要走东南亚两个平台。他们的 ERP 每天自动跑补货，采购单也自动生成，但运营反馈"缺货从来没断过"。
我们把采购单和入库记录对齐之后发现，系统在做补货计算时，只扣了"可用库存"，没有把"已下单未到货"的在途数量算进去。结果是同一个 SKU 在一周内被重复建议采购了三次，采购员以为系统算过，照单全下。
更麻烦的是，这三批货到货时间集中在同一周，仓库爆仓，第二批和第三批被压在码头，上架又晚了十天。断货没解决，反而多压了三个月的库存。这个案例里，ERP 的每一个动作都是"正确"的，错的是补货公式漏了一个变量。
第二家是做户外用品的，同时运营三个平台加一个独立站，海外仓在美国东岸和西岸各一个。他们的库存是集中管理的，所有渠道共用一个可用库存数字。
问题出在平台规则差异上。A 平台的订单取消率高、退货窗口长，实际占用库存的时间比 B 平台长得多；西岸仓到 A 平台买家的妥投时效比东岸仓快两天，系统却按平均时效分配。结果是 A 平台经常超卖被处罚，B 平台同时留着两个月的货。
这家企业的负责人一开始认为是"库存同步不及时"，我们排查后发现同步是实时的，问题在同步之后没有分配规则。把所有库存加总成一个数字，再让所有渠道去抢，这本身就是个错误的方案设计。
第三家是做家居装饰的，旺季在大促前两个月就开始备货。他们的考核指标是"缺货率"，采购团队的 KPI 直接挂在这个数字上。
结果可以预见：采购团队为了保证不缺货，把安全库存系数一路往上调。大促期间确实没怎么断货，但大促结束后，长尾 SKU 的库存金额从 62 万美元涨到 138 万美元，周转天数从 68 天涨到 121 天。
这家企业的问题不在执行，而在考核。当组织只用一个指标考核时，所有人都会朝那个指标的最优解走，哪怕它损害整体。采购补货天生是个多目标问题，单指标考核必然导致失衡。
这是我在中小卖家里见到频率最高的误区，没有之一。表现形式很简单：整个店铺所有 SKU 用同一个补货天数，比如 30 天，库存低于 30 天销量就触发补货。
为什么大家会这么做？因为简单、好解释、ERP 初始化时最容易配。一个新店铺刚起步，SKU 不多，用一套参数确实能跑起来。问题在于店铺长大之后，这套参数没有人回来改。
我见过一个卖家，SKU 从 30 个长到 1200 个，补货参数还是最初那套 30 天。结果就是快消品经常断货，慢消品长期压货，而系统本身没有任何判断能力。
固定补货点假设了两件事：需求是稳定的，交期是稳定的。这两个假设在跨境电商场景里几乎都不成立。
需求侧，一个 SKU 的日销可能在 5 件到 80 件之间波动，黑五当天能到 300 件；交期侧，海运可能 25 天也可能 40 天，清关可能 2 天也可能 12 天。把这两个波动源都抹平成一个固定天数，等于主动放弃了对不确定性的管理。
更隐蔽的是活动节奏。平台大促的备货周期通常要提前 45 到 60 天，而固定补货点不知道什么叫"大促"，它只会在活动前两周照常建议一个正常量。
参数分层不是越细越好，我通常建议从三个维度切分：SKU 分层（按 ABC 分类或销售额贡献）、仓库分层（按头程时效和成本）、渠道分层（按平台规则差异）。三个维度交叉后形成参数组，通常 8 到 20 组就能覆盖绝大多数 SKU。
安全库存的本质是对不确定性的缓冲，它应该跟需求波动和交期波动挂钩，而不是拍一个固定天数。一个常用的工程化写法是对提前期内的需求波动做统计：
# 安全库存的工程化计算（简化版） 输入：历史日销序列、采购提前期序列、目标服务水平 def safety_stock(daily_sales, lead_time_days, service_level=0.95): 日销标准差（建议用近 90 天，剔除断货期数据） sigma_d = std(daily_sales) 提前期均值与标准差 lt_mean = mean(lead_time_days) lt_sigma = std(lead_time_days) 服务水平对应的 z 值，0.90 -> 1.28，0.95 -> 1.65，0.98 -> 2.05 z = norm_ppf(service_level) 需求波动 + 交期波动的合成 combined = sqrt(lt_mean * sigma_d 2 + mean(daily_sales) 2 * lt_sigma ** 2) return z * combined
这段代码的关键在最后一行：它同时考虑了需求波动和交期波动，而不是只算一个"日均销量乘周期"。很多 ERP 内置的安全库存公式只算前者，交期波动大的品类会系统性低估。
参数配好不是终点。我建议的节奏是：A 类 SKU 每月复盘一次，B 类每季度，C 类每半年。复盘的内容不是"调高还是调低"，而是看三类信号，断货次数、滞销天数、被人工推翻的补货建议比例。
这是错误后果最直接的一类。补货计算的分子分母里，如果库存口径是错的，后面的参数调得再精细也没有意义。
重复采购的场景我在前面已经讲过。虚假缺货更隐蔽：系统显示某 SKU 可用库存为 0，触发补货，但实际上有 200 件在海外仓等待上架，只是还没走完质检流程。采购照单下单，两个月后这 200 件上架了，再加上新到的 500 件，仓库直接爆掉。
还有一种情况是锁定库存没有区分。多平台卖家经常遇到：库存被某个平台的未发货订单锁定了，但系统在计算补货时用的还是含锁定量的总数，导致实际可卖的比系统认为的少。
问题的根源在于很多 ERP 的库存表只有一个"库存数量"字段。一个数字无法同时表达"能卖"、"不能卖但会到"、"已经被人要了"这三种状态。方案设计阶段如果不把这个颗粒度定下来，后面只能靠人工在 Excel 里补。
我通常建议至少把库存拆成六种状态，并要求 ERP 在补货计算时明确每一类的加减关系：
这六种状态里，最容易漏的是退货在途和待上架。前者因为"可能会再卖出去"，后者因为"已经在仓库里了"，都很容易被当成可用库存，但两者的时间属性完全不同。
方案设计阶段，我建议用下面这份清单去核对 ERP 的库存模块。任何一项答"否"，都意味着补货计算会有系统性偏差：
| 检查项 | 合格标准 | 常见问题 |
|---|---|---|
| 库存状态字段 | 至少 6 个独立状态，支持自定义扩展 | 只有"库存数"和"可用数"两个 |
| 在途关联 | 在途与采购单、入库单双向可查 | 在途是个手工填的数字 |
| 锁定逻辑 | 订单生成即锁定，取消即释放 | 出库时才扣减，中间有时间窗 |
| 退货在途折算 | 按 SKU 历史可再售率折算 | 全额计入或完全不计入 |
| 异常库存隔离 | 异常库存在补货计算中完全排除 | 混在可用库存里 |
把库存同步做好只是第一步，把库存分配好才是难点。我在前面场景二里提到的超卖与积压并存，根源就在这里。
一家卖家同时运营四个渠道，库存集中在一个数字里。运营 A 看到库存充足就加大投放，运营 B 看到同样充足也跟着推，两个渠道同时起量，库存被瞬间抢空，两边都超卖。
反过来也成立：某个慢渠道因为历史原因占了很大比例的安全库存，系统就不敢给快渠道放开，快渠道持续缺货，慢渠道的货慢慢变成滞销。
ERP 产品讲库存时，几乎都强调"实时同步"、"一键同步"。同步解决的是数据一致性问题，不解决分配问题。同步告诉所有人现在有多少货，分配决定这货该给谁。
分配之所以难，是因为不同渠道、不同仓库之间的库存不是等价物。东岸仓的货发西岸买家要多两天，A 平台的退货率比 B 平台高 8 个百分点，FBA 仓的补货限制比第三方海外仓严格得多。这些差异不体现在数量上，但体现在价值上。
我的建议是三步走。第一步做库存池分组，把物理仓和逻辑渠道对应起来，比如"东岸仓-FBA"、"东岸仓-独立站"、"西岸仓-平台A"各成一组，组内库存可共享，跨组共享需要规则审批。
第二步定渠道优先级。同一库存池内的多个渠道，按毛利贡献、退货率、履约时效打分排序，分配给高优先级渠道的库存比例更高。这个优先级不是永久的，旺季前可以临时调整。
第三步加缓冲规则。每个池子保留一定比例的"机动库存"，不参与任何渠道的自动分配，专门用于应对大促、爆款、平台活动。缓冲比例建议从 5% 起，根据历史超卖率调整。
这是最容易被忽略、后果也最直接的一类。系统在干净的数学环境里算出"应该补 320 件"，但供应商说"我们这个款 MOQ 是 500，而且这个月排期满了"。
我在一家做宠物用品的卖家那里看到过极端案例：系统连续 5 天给同一个 SKU 生成补货建议，数量分别是 280、310、295、330、305 件，采购全部退回，因为供应商的起订量是 1000 件，而且这款的最小包装单位是 500。系统完全不知道这些约束。
采购员每天的精力都花在把系统建议改成能落地的数字上。当系统生成的建议有六成需要人工改写时，系统就从一个效率工具变成了一个负担。
供应商约束至少有四类需要进入补货模型，但大多数 ERP 的供应商主数据只有基础联系信息：
这四类约束里，MOQ 和阶梯价是硬约束，交期波动是软约束但影响最大。方案设计时至少要保证硬约束能在采购申请环节被自动校验。
我建议在供应商主数据里至少补上这几个字段，并在采购申请提交时做强校验：
# 供应商主数据建议字段（示意结构）
supplier:
supplier_id: "SUP-0231"
name: "深圳某电子厂"
moq: 500 # 最小起订量
order_multiple: 500 # 下单倍数，通常等于最小包装
lead_time_p50: 22 # 交期中位数（天）
lead_time_p90: 38 # 应答 90% 情况的交期
price_tiers: # 阶梯价
qty: 500
unit_price: 12.80
qty: 2000
unit_price: 11.60
qty: 5000
unit_price: 10.90
payment_term: 30 # 账期（天）
peak_capacity_note: "Q4 需提前 60 天锁产能"
有了这些字段，ERP 在生成补货建议时就可以做一次"可行性修正"。修正的顺序建议是：先按 MOQ 向上取整，再按阶梯价评估是否值得合并批次，最后按 p90 交期而不是 p50 交期做时间倒排。
我遇到过一家做手机壳的卖家，某 SKU 日销 18 件，供应商 MOQ 1000 件。按净需求算，补 400 件就够覆盖到下个采购周期；但 MOQ 卡着，只能买 1000 件。
买 1000 件意味着这批货能卖 55 天，加上头程 30 天，实际库存覆盖周期接近 85 天。这个 SKU 的款式生命周期只有 4 个月，等货卖到一半，新款已经上市，剩下的 500 件直接变成清仓货。
正确处理方式有两种：一是跟供应商谈把 MOQ 降到 500，用单价略高换取更低库存风险；二是把这个 SKU 的补货周期拉长到 60 天一批，接受一定缺货风险换取不压货。两条路的取舍取决于毛利和款式生命周期，但无论走哪条，系统都必须先知道 MOQ 这个约束存在。
指标设计错误是方案设计里最隐蔽的一类。它不会在系统上线当天暴露，而是会在 3 到 6 个月后以库存结构恶化的形式出现。
我在前面场景三里提到的家居卖家就是典型：缺货率从 8.2% 降到 3.1%，看起来成绩显著，但同期库存周转天数从 68 天涨到 121 天，滞销库存金额翻了一倍多。财务的现金流压力比之前更大。
更麻烦的是这种恶化有滞后性。采购团队在上半年做出成绩，奖金已经发了，问题在下半年才显现，责任归属变得模糊。
缺货率是个好指标，但它只衡量了"没货卖"的成本，没有衡量"货卖不掉"的成本。在跨境电商里，后者的成本往往更高：仓储费、资金占用、清仓折价、甚至销毁费用。
更深一层的原因是，缺货率的改善比周转天数的改善更容易被感知。运营每天都能看到缺货告警，但滞销是慢慢积累的，没有人会为一个"还没发生"的损失报警。
我建议采购补货的考核至少用五个指标组合，并且明确各自的权重和观测频率：
| 指标 | 衡量什么 | 建议频率 | 常见异常信号 |
|---|---|---|---|
| 缺货率 | 需求未被满足的比例 | 周 | 连续两周低于 2% 需警惕过度备货 |
| 库存周转天数 | 资金周转效率 | 月 | 环比上升超过 20% 需要归因 |
| 滞销库存占比 | 超过设定天数未动销的库存金额占比 | 月 | 超过 15% 触发清仓评估 |
| 售罄率 | 新品或活动款的销售进度 | 周（新品期） | 低于计划进度 30% 需调整补货 |
| 现货履约率 | 订单中现货直发的比例 | 周 | 低于 85% 说明库存结构不匹配 |
这五个指标要放在同一张看板上联动观察。缺货率降但周转升，说明是拿库存换的；周转降但售罄率也降，说明是卖库存而不是卖货。组合起来看，才不会被单一数字误导。
采购补货从来不是一个人的事。谁提需求、谁审批、谁改交期、谁处理到货异常，如果不提前定清楚，ERP 上线后只会把原来的扯皮搬到系统里。
我见过最混乱的一个项目：补货建议由系统自动生成，采购员可以改数量，运营主管可以改优先级，仓库可以改预期上架时间，销售可以临时插单。四个角色都能改，但没有任何修改记录，出了问题谁都说不清。
另一个常见问题是异常处理没有责任人。供应商交期延误了，采购说"我已经通知运营了"，运营说"我以为采购会跟进"，仓库说"货没到我也没办法"。一个延误在三个部门之间转了五天，没人真正负责。
很多 ERP 采购模块提供了完整的表单，采购申请单、采购订单、入库单、质检单都有，但表单之间的流转依赖人工推动，没有状态机、没有超时提醒、没有升级机制。
表单解决"记录问题"，工作流解决"推进问题"。方案设计时如果只画表单不画流程，系统就只是一个电子化的记录本。
我建议把采购异常定义成一个标准的闭环流程，五个步骤缺一不可：
这五步里，最容易被省略的是第五步。没有复盘，同样的异常会以同样的方式重复发生，团队会逐渐把异常当成常态。
前面六个误区有一个共同点：它们都表现为"规则问题"，但很多规则问题的根因其实是数据问题，数据拿不到、对不上、口径不一致。这一节我用数跨境（https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）来说明数据层该怎么搭。
我做过一个统计：在我参与的 12 个补货诊断项目里，有 9 个项目的第一个障碍不是"不会算"，而是"数据凑不齐"。历史销量在平台后台，库存分布在 ERP，在途在采购的 Excel，头程时效在货代的邮件里。
数据分散带来的直接后果是口径打架。运营说的"月销"是发货口径，财务说的"月销"是回款口径，采购认为的"月销"是出库口径，三个数字差 15% 到 20%。用哪个数去算补货，结果完全不一样。
数跨境的定位是跨境电商的数据分析与决策支持层，它不做 ERP 的交易动作，而是把多平台、多店铺、多仓的数据汇聚到同一个数据层，再做清洗、口径统一和看板呈现。在采购补货这条链路里，它承担的是"让补货决策有统一数据源"的角色。
具体来说，它解决三个问题。第一是平台数据接入，把各平台的销量、订单、退货、广告数据拉到同一个视图里，避免人工导出再拼接。第二是口径统一，同一套 SKU 编码规则下，销量、库存、在途的统计口径在一次配置后固定下来，所有人都看同一个数字。第三是库存健康看板，把缺货、周转、滞销、售罄这几组指标做联动呈现，让前面第七节讲的组合指标真正能落地。
我的使用建议是把它放在 ERP 的上游：用数跨境这类数据层做"看什么、怎么算"的判断，用 ERP 做"下单、入库、核销"的执行。两者分工清楚，比试图在 ERP 里硬塞分析功能要现实得多。
我通常建议最少搭四张看板，按使用频率从高到低排：
这四张看板的更新频率不同，前两张建议日更，后两张周更。频率定得太高会让数据团队疲于奔命，太低又失去预警价值。
我跟踪过一家 300+ SKU 的卖家，他们在接入统一数据层前后的补货相关人工耗时变化比较有代表性。需要说明的是，这是单一脱敏样本的观测数据，不同团队差异会很大，仅供参考量级。
误区是一样的，但不同规模的团队能承受的改造幅度完全不同。我按三个阶段给建议，你可以先找到自己的位置。
这个阶段最大的风险是"过度设计"。我见过 SKU 只有 80 个的卖家花三个月做参数分层，结果市场已经变了。建议的顺序是：先把库存状态拆清楚（第六节的六种状态），再把 MOQ 字段维护起来，其他都可以先简化。
具体动作上，先用一张 Excel 把每个 SKU 的采购交期、MOQ、当前在途、锁定库存维护起来，每周更新一次。补货参数先按 ABC 分三档，不要做太细。等 SKU 超过 300 个，再考虑上数据层。
这个阶段通常已经有 ERP，问题从"没有工具"变成"工具用不好"。我建议把精力集中在两件事上：一是库存池分组，二是异常闭环。
库存池分组能直接解决多平台超卖和积压并存，投入产出比最高。异常闭环则是为了让问题不再重复，这个阶段的团队往往已经积累了不少"只有老员工知道"的处理经验，需要把它显性化到系统里。
这个阶段也是引入数据层比较合适的时机，因为 SKU 数和平台数都上来了，人工对数的边际成本开始变得不可接受。
这个阶段的补货已经不是单纯的补货问题，而是产销协同问题。建议把补货纳入 S&OP（销售与运营计划）的节奏里，按月做需求评审、按周做补货执行。
参数分层要做到四层以上：SKU × 仓库 × 渠道 × 季节。安全库存要用服务水平驱动，而不是拍天数。供应商约束要全部进系统，包括阶梯价和产能窗口。
这个阶段还有一个常被忽略的动作：建立补货策略的 A/B 验证机制。选 20 到 30 个 SKU 做新策略试点，跑满两个补货周期再对比，比一次性全量切换安全得多。
讲了这么多"该怎么做"，最后必须落到"什么时候不该这么做"。补货方案设计本质上是一系列取舍，没有全局最优解。
提高服务水平能降低缺货，代价是更多库存和更高资金占用。服务水平的边际成本是递增的：从 90% 提到 95%，安全库存大概要多三成；从 95% 提到 99%，再要多六成以上。
我的判断原则是按 SKU 毛利分层。高毛利爆款值得把服务水平提到 97% 以上，因为一次断货损失的利润远大于多备货的成本；低毛利长尾 SKU 建议控制在 90% 左右，接受一定缺货，把资金留给更值得的 SKU。
集中采购能拿到更好的阶梯价和更强的议价能力，但库存风险集中；分散备货灵活，但单价高、管理成本高，且容易在多个仓之间形成新的积压。
我的判断原则是看两个变量：SKU 的需求稳定性和供应商的产能弹性。需求稳定且供应商产能紧张，建议集中锁量；需求波动大且供应商产能弹性好，建议分散小批量。
经常有卖家问我"要不要自己开发一套补货系统"。我的建议是看有没有三条以上的特殊规则是市面产品无法配置的。如果没有，自研的维护成本会远超预期，一个补货算法的维护，需要的不只是开发，还有持续的数据治理和业务迭代。
如果确实有三条以上特殊规则，也建议先用数据层做验证，把规则跑通、验证收益之后再考虑系统化。直接上自研系统的项目，我见过太多在第二年被搁置。
这是最根本的取舍。我的判断始终是：如果现有的规则本身是错的，先做规则；如果规则是对的但没有工具承载，先上系统。
判断规则对不对，可以用第一节那个测试：随便挑一个补货建议，能不能追溯到具体参数组和计算逻辑。能追溯到，说明规则是清楚的，上系统能放大收益；追溯不到，上系统只会把混乱自动化。
回到开头那句话：ERP 不会替你判断什么样的补货策略是合理的。它只会把你写进去的规则算得又快又准。如果你的规则本身有问题，ERP 上线后你得到的只是一个更快产生错误答案的系统。
我把这篇文章里的六个误区再压缩成一句话：固定参数、单一口径、共享库存池、忽略约束、单指标考核、无异常闭环，这六件事决定了补货结果的上限，而它们全部发生在系统配置之前。
如果你现在正准备上 ERP，或者刚上完 ERP 发现补货还是乱，我建议按下面的顺序做一遍：先做第一节那个追溯测试，看能不能说清一个补货建议的来源；再按第四节那份清单核对库存状态字段是否齐全；然后用第七节的五指标看板检查考核是否失衡；最后用第八节的五步闭环检查异常处理是否有责任人。
这四步做完，你大概率会发现真正需要改的不是系统，而是方案设计本身。改完之后再回头看 ERP 配置，路会清楚很多，先有规则，再有系统，最后才是参数调优，这个顺序反过来做，成本会高出一个量级。
我上ERP的时候，服务商让我给每个SKU填一个补货点，我图省事就按日均销量乘采购周期填了一遍。结果大促前照样断货，淡季又压了一堆货。后来才发现，同一个公式放在交期稳定的标品和交期飘忽的定制品上，效果完全相反。
固定补货点只在需求平稳、交期稳定的情况下勉强可用，一旦需求波动或交期波动就会被击穿。可执行做法是分三层参数：第一层按动销分档，A类高频动销品用周颗粒度预测，C类长尾用固定批量、降低复查频率；
第二层安全库存不要只乘平均交期，要把需求波动和交期波动都放进去，常用公式是安全库存 = Z × √(交期 × 需求方差 + 日均需求² × 交期方差)，Z由目标服务水平决定，95%服务水平对应Z约1.65，可查正态分布表；
第三层给参数设复查周期，A类每两周、B类每月、C类每季度复盘一次，并在ERP里保留参数变更日志。判断依据：如果某SKU近12周出现3次以上缺货且都发生在交期延误之后，问题在交期方差而不在补货点本身，应该先治理供应商交期，再动参数。大促和平台活动期要单独建一套活动参数，不要用日常参数硬顶。
做多平台的时候我最崩溃的一次是，ERP里显示某SKU还有800件，A平台订单下过来却提示库存不足，同时B平台还在继续超卖。查了半天才发现，那800件里有一部分已经被另一个平台的订单锁定，还有一部分是质检不合格待处理，真正能卖的没几件。
问题出在库存状态切得太粗。至少要拆成四类口径并在ERP里分别建字段：账面库存（仓库实际在库数量）、锁定或预留库存（已被订单、活动、调拨占用）、可用库存（账面减锁定减冻结不良）、在途库存（已下采购单未入库，且要区分正常在途和延期在途）。
补货计算的分子应该用“可用库存 + 可承诺在途 – 已承诺未发需求”，而不是账面库存。可执行做法：第一步，把采购单、入库单、质检单、上架单做成一条可追溯链路，每张采购单能查到当前状态（已下单、已发货、在途、已到港、清关中、已入库、已上架），在途数量只有在供应商确认发货后才计入；
第二步，质检未通过、待返修、待销毁的数量单独建状态，不计入可用；第三步，做一张库存状态对账表，每天比对账面、锁定、可用三个口径的差额，差额突然放大说明有单据卡在中间流程没走完。判断依据：如果某SKU长期出现可用库存为正但订单发不出，先查锁定单据有没有释放，再查是否有未完成的入库单挂在中间状态。
我们有速卖通、Shopee、Lazada几个店，还有国内仓和海外仓，一开始图省事把所有库存并到一个池子里同步出去。结果旺季A平台一天爆单超卖，B平台的货在仓里躺了两个月。后来才意识到，不同平台仓的补货逻辑根本不是一回事。
不能简单共用一个池子。判断依据是这三个维度是否一致：库存所在地（国内仓、海外仓、平台仓）、履约时效承诺（平台仓通常有硬性时效）、成本结构（头程、仓储费、退件成本）。只要有一个维度不同，就应该分成独立库存池，再做分配规则。
可执行做法：第一步，按“仓库 × 平台 × 履约方式”建库存池，每个池子有独立补货参数和补货责任人；第二步，给共用实物库存设分配优先级和缓冲，比如给时效最硬的平台仓预留安全缓冲，其余按近30天动销比例动态分配；
第三步，在ERP里配置跨池调拨规则，明确什么情况下把库存从A池调到B池、由谁审批、调拨在途算哪个池；第四步，做分池库存健康看板，同时看每个池的缺货天数、售罄率、周转天数，而不是只看总库存。
判断依据：如果某个池子的库存周转明显慢于其他池、但总库存看起来正常，说明分配规则偏了，要回到优先级和缓冲系数上调整，而不是继续加总库存。
我们系统算出来某个SKU建议补120件，结果供应商说MOQ是500件，量大才有折扣，还只有两个交期档位。采购同事直接把单子改成500件，旺季过了还在清库存。我就想，ERP里的补货建议到底该怎么和供应商的实际条件对上。
补货不是纯数学题，建议数量必须过一遍供应商约束校验，否则采购要么改单要么拒单，方案就废了。可执行做法分四步：第一，把供应商主数据建全，至少包含MOQ、阶梯价区间、标准交期和交期波动范围、账期、是否支持拆单、是否有备选供应商；
第二，在采购申请环节做约束校验，当建议量低于MOQ时不要自动上调到MOQ，而是让系统提示三个选项，上调到MOQ并给出预计周转天数、按MOQ下单但合并未来数周需求降低下单频次、拆单给备选供应商，由采购按库存健康情况选择；
第三，把阶梯价和交期一起进决策，算单位持有成本加采购成本后的综合成本，而不是只看单价；第四，对长交期、高MOQ的SKU单独设策略，比如按季度集中下单、设置更保守的安全库存上限，而不是跟着公式每周跑。
判断依据：如果某SKU的采购单被人工修改的比例长期很高，说明约束字段没建全或参数不切实际，这时应该先修数据再谈自动化补货。落地建议是先挑一个仓库、一组20到30个SKU试点跑两个补货周期，把参数、约束、异常处理都走通，再推广到全店。
读者评论
三个案例里最戳我的是场景二，多平台共用一个库存池。我们做独立站加两个平台，也是实时同步库存，但退货占用时间不同，导致一个渠道老超卖另一个压货。文里说的同步之后没有分配规则，确实说到根子上了，这个在方案设计阶段不解决，上线后基本改不动。
安全库存那段代码挺实在的，把交期波动也算进去了。很多ERP内置公式确实只算需求波动，我们海运品类交期从25天到40天都有可能，按固定提前期算安全库存一直偏低，断货反复出现。不过实际落地时历史交期数据很难维护准确，这块主数据才是最难的。
作者说采购补货是多目标问题，单指标考核必然失衡，这点深有同感。我们团队以前只考核缺货率，结果库存越备越多，周转一路恶化。后来加了滞销库存和周转天数一起看才稍微好转。但多指标之后又容易互相甩锅，所以异常闭环那部分比参数分层还关键。