去年Q4，一个做家居收纳的卖家朋友在群里发了张截图：同一天，亚马逊美国站和Shopee马来站同时卖爆了一款折叠收纳箱。运营在群里@采购说"赶紧补"，采购回了一句"上周刚下过3000个的单"，仓库说"到了800个，还在质检区没上架"。三个小时后，两个平台都超卖，亚马逊那批订单被记了取消率。事后复盘，采购确实下了3000个，但那是分两批，第一批800个到仓在质检，第二批2200个还在头程船上。

而系统里的"可用库存"把在途的2200个也算了进去，运营看到的数字是"还有2200个能卖"。

这不是某个ERP的Bug，这是流程设计问题。补货这件事，真正难的地方从来不是"算得准不准"，而是系统里那个数字到底代表什么。这篇文章我会把跨境采购补货的流程拆到字段级别，讲清楚每个节点该有什么输入、什么状态、谁负责、出错怎么办，以及什么规模的团队该做到哪一步。

一、先给结论：补货补的不是货，是库存口径

我先说一个可能不太讨喜的结论：80%的补货事故，不是预测算法不够聪明，而是库存口径没有分层。很多团队花大价钱上"智能补货"，结果连"在途"和"可售"都没分开，算法再准也是往一个错误的池子里倒水。

1. 三个必须记住的"不等于"

补货建议不等于采购订单，采购订单不等于可售库存，可售库存不等于你能卖出去的库存。这三句话听着像废话，但我见过太多团队把它们混成一锅粥。

"补货建议"是一条系统根据规则生成的待决策信息，它可以被运营改、被采购否、被审批驳回。它本质上是一个提案，不是承诺。

"采购订单"是对供应商的资金承诺。订单一旦发出，钱和货就开始动了，但这时候货还不能卖，它可能还在供应商产线上，可能在海运柜子里，可能在清关。

"可售库存"是能立即响应平台订单的实物。它必须扣掉平台侧已经锁定但未发货的部分，扣掉质检未完成的部分，扣掉次品和待处理品。

把这三者当同一件事的团队，早晚会遇到我开头讲的那个场景。

2. 流程设计的正确顺序

我自己的经验顺序是：先定口径，再定触发规则，再定审批权限，最后才是选系统。很多人是反过来的，先买系统，然后被系统的默认逻辑牵着走，最后发现改不动，只能让业务迁就软件。

口径决定了你所有报表的地基。触发规则决定了补货的节奏和频率。审批权限决定了响应速度和人祸的概率。系统只是把前三件事固化下来、自动化执行。

3. 为什么我愿意先花两周只做口径

我在2023年帮一个做3C配件的团队梳理过一次补货流程。他们当时日均400多单，十几个店铺横跨四个平台，用某款主流的免费ERP。我做的第一件事不是看补货建议准不准，而是把他们的库存表拉出来，问了一句："这个'可用库存'里面，包含了在途吗？"

运营说包含，采购说不包含，仓管说"我看的是另一个页面"。三个人三个答案。这就是根因。我们花了将近两周，只做一件事：把库存拆成七个独立口径，写进文档，让所有人对着同一套定义说话。改完之后，他们那个月的紧急空运补货次数从9次降到3次，不是算法变聪明了，是决策用的数字终于对了。

二、背景和真实场景：跨境补货为什么天然比国内复杂

国内电商的补货逻辑相对单纯：卖得快就补，供应商在隔壁省，三五天到货，实在不行发顺丰。跨境电商把这条链路拉长到了几十天，还叠加了多平台、多店铺、多币种、多头程。复杂度不是线性增长的，是乘出来的。

1. 多平台多店铺的SKU映射是第一道坎

你有一个内部SKU叫"收纳箱-大号-灰"，它在亚马逊美国站叫一个ASIN，在Shopee马来站是另一个Item ID，在TikTok Shop又是另一个商品ID，在独立站可能还是你自己的编码。这四个东西在平台上互不相识，但它们在物理上是同一批货。

如果ERP没有做SKU映射，补货就会变成一场灾难：你可能对同一个实物SKU下两次单，因为系统看到的是两个"不同"的商品都在低库存。

我的判断是，SKU映射必须是主数据治理的第一优先级，甚至优先于补货规则本身。映射表没建好，后面的所有规则都是在沙滩上盖楼。

2. 长交期让"在途"从配角变成主角

国内补货，在途可能只占库存的5%，几乎可以忽略。跨境不一样。海运头程30到45天，加上供应商备货12到20天，一个采购订单从下达到可售，60天是常态。

这意味着在一个健康的跨境库存结构里，在途部分往往占到总库存的40%以上。在途不是边角料，它是主菜。你把主菜忽略掉，补货判断必然是错的。

3. 三个角色的目标天然冲突

运营的目标是不断货，所以他们倾向于多补、早补。采购的目标是拿到好价格和低运费，所以他们倾向于凑整、凑MOQ、凑整柜。财务的目标是低资金占用和高周转，所以他们倾向于少补、晚补。

这三个目标没有谁对谁错，冲突是结构性的。流程设计的作用，不是消灭冲突，而是给冲突一个可追溯的裁决机制。谁提出、谁审批、依据是什么、事后怎么复盘，这些必须落到单据上，而不是停留在微信群里。

4. 我见过的一次典型翻车全过程

一个做宠物用品的团队，旺季前运营预估某款猫爬架会爆，提了5000个的补货需求。采购觉得MOQ是3000，凑到6000单价更低，于是下了6000。审批是老板在群里回了个"OK"。货分三批到，第一批2000个到仓，质检发现有一批次品率偏高，扣了300个。仓库把这批货入了库，但系统里没有"待质检"这个状态，直接进了可售。

结果旺季没爆，实际销量只有预期的六成。6000个货，卖到第三个月还剩2800个，资金压了近40万。事后没人能说清是谁的判断出了问题，因为整个链路只有微信聊天记录，没有单据留痕。

这个案例里，真正的问题不是"补多了"，而是"补多的原因无法复盘"。是预测错了？是MOQ凑单错了？还是审批环节没有人质疑？如果这三个问题有答案，下一次就能改进。没有答案，下一次还会犯。

三、拆解常见误区：我见过的七种"看起来能用"的补货流程

下面这七条，都是我在实际项目里见过的真实做法。它们共同的特点是：在小规模下能跑，一旦订单量上来或者平台变多，立刻崩盘。

1. 误区一：把低库存预警当补货建议

最常见的做法是设一条线，比如库存低于100就报警。这只能叫"提醒"，不叫"建议"。因为它没有回答两个关键问题：补多少？什么时候到？

一个真正的补货建议至少要包含：建议补货数量、建议下单日期、预计到仓日期、覆盖天数、以及这个建议是基于哪些假设算出来的。没有这些，运营看到报警还是得自己拍脑袋。

2. 误区二：一张库存表走天下

很多团队只有一张"库存"表，一个数字。这个数字在不同场景下被赋予不同含义：运营看它决定要不要促销，采购看它决定要不要下单，财务看它算资金占用。一个数字服务三种目的，必然出问题。

正确做法是分层。我建议至少拆成：可售库存、平台锁定库存、国内在途、头程在途、海外仓在途、待质检库存、次品库存、在途采购未发货。这八个口径各自有明确物理含义，不能互相替代。

3. 误区三：在途算进可售

这是导致超卖的头号原因。在途的货，可能在海上翻柜，可能被海关扣，可能供应商临时缺货。把它当可售，等于把不确定性当成确定性。

我的规则很简单：只有完成质检、入到可售仓位、且未被平台订单锁定的数量，才能作为可售库存。其他一律不进。

4. 误区四：审批流为了"可控"设成一人拍板

另一个极端是，为了响应速度，所有采购申请都由老板一个人拍。这在日单量一两百的时候勉强能转，到五百单以后就是瓶颈，老板出差三天，采购全线停摆。

合理的做法是分档：小额、常规品类走自动或一级审批；大额、新品类、新供应商走多级审批；紧急采购走特殊通道但必须有事后追认。

5. 误区五：迷信"智能补货"黑盒

很多ERP会宣传"AI智能补货，一键生成"。我的态度是：算法可以辅助，但不能是黑盒。如果系统给出的建议数量你无法解释它是怎么算出来的，那你在出问题的时候就没有任何调整依据。

好的补货建议应该能展开：日均销量用的哪个时间窗口、交期用的哪个值、安全库存怎么来的、有没有考虑活动系数。这些参数必须可见、可改、可回溯。

6. 误区六：不处理部分到货和分批入库

采购6000个，供应商分三批发。这是跨境常态，不是异常。但很多流程只设计了"一次到货、一次入库"，遇到分批就手动改数据，改着改着账就乱了。

正确的设计是：采购订单是一个容器，可以关联多张入库单。每张入库单独立质检、独立入账，采购订单的状态是"部分到货"，直到全部到齐或明确关闭。

7. 误区七：不留痕，复盘无依据

最隐蔽也最致命的一条。人工调整补货建议，改了但没记谁改的、为什么改；紧急采购走了特批，但没记审批人；供应商延期了，但没记实际到货日。三个月后想复盘，什么都查不到。

我的要求是：任何对系统建议的人工修改，都必须强制填写原因，并记录操作人和时间。字段就三样：修改前、修改后、原因。三个字段，能救你未来无数次的扯皮。

四、专业判断逻辑：四段式补货流程模型

我把采购补货拆成四层：信号层、决策层、执行层、回写层。这个模型的好处是，每一层都可以独立检查、独立优化，出问题时能快速定位是哪一层断了。

1. 信号层：补货信号从哪里来

信号层要回答的是"什么时候该看一眼"。常见信号有六种：可售库存低于安全库存、可售天数低于阈值、平台活动备货计划、预售订单累积、季节性周期到达、供应商涨价或停产预警。

大部分团队只做了第一种。我的建议是至少加上"可售天数"这个信号，因为它比绝对库存量更能反映真实紧迫度。同样是100个库存，日销5个和日销50个，紧迫程度差十倍。

2. 决策层：补货建议怎么算、怎么改

决策层是补货建议的核心。它需要一组输入字段，我列一下我实际用过的字段清单：日均销量（含最近7天、30天、90天三个窗口）、销量波动系数、供应商交期（含备货天数和头程天数）、安全库存天数、现有可售库存、平台锁定库存、在途数量、次品库存、MOQ、装箱数、目标覆盖天数、活动系数、资金预算上限。

建议数量的基本逻辑可以写成这样：

// 补货建议计算伪代码（简化版）
function calcReplenishment(sku) {

const dailySales7 = sku.sales.last7Days / 7;

const dailySales30 = sku.sales.last30Days / 30;

const dailySales90 = sku.sales.last90Days / 90;

// 加权日均，近期权重更高，但抑制短期波动

const weightedDaily =

dailySales7 * 0.5 + dailySales30 * 0.3 + dailySales90 * 0.2;

// 波动系数：用30天标准差 / 均值，限制在 0.8 ~ 1.5 之间

const volatility = clamp(

sku.sales.stdDev30 / (dailySales30 || 1),

0.8,

5
);

const leadTimeDays =

sku.supplier.productionDays + sku.logistics.transitDays;

const targetCoverage =

sku.strategy.baseCoverDays * sku.seasonFactor * sku.campaignFactor;

// 真正需要覆盖的天数 = 目标覆盖 + 交期，再乘以波动系数

const neededQty =

weightedDaily * (targetCoverage + leadTimeDays) * volatility;

// 净需求 = 需求 - 已有可售 - 在途 - 待质检

const netNeed =

neededQty -

sku.stock.available -

sku.stock.inTransit -

sku.stock.pendingQC;

// 向上取整到 MOQ 的倍数

const suggested = roundUpToMoq(Math.max(0, netNeed), sku.supplier.moq);

return {

suggestedQty: suggested,

coverDays: targetCoverage,

assumptions: { weightedDaily, volatility, leadTimeDays },

};

}

这段伪代码里我想强调两点。第一，在途和待质检必须从需求里扣掉，否则你会重复下单。第二，波动系数必须有限制区间，不然一款突然爆单的商品会算出天文数字的补货量。

人工可以调整建议，但必须留痕。这是我前面说的三个字段：修改前、修改后、原因。

3. 执行层：从申请单到采购单的状态机

执行层是把决策变成单据。我建议至少定义这几个状态：草稿、待审批、已驳回、已批准、已转采购单、部分到货、全部到货、已关闭、已取消。

状态之间的流转必须有明确触发条件，不能靠人工随意改。下面是我用过的状态机定义：

{
"stateMachine": "purchase_request",

"initialState": "draft",

"states": [

{ "key": "draft",          "label": "草稿",       "editable": true },

{ "key": "pending_approval","label": "待审批",     "editable": false },

{ "key": "rejected",       "label": "已驳回",     "editable": true },

{ "key": "approved",       "label": "已批准",     "editable": false },

{ "key": "converted",      "label": "已转采购单", "editable": false },

{ "key": "partial_received","label": "部分到货",  "editable": false },

{ "key": "fully_received", "label": "全部到货",   "editable": false },

{ "key": "closed",         "label": "已关闭",     "editable": false },

{ "key": "cancelled",      "label": "已取消",     "editable": false }

],

"transitions": [

{ "from": "draft",           "to": "pending_approval", "action": "submit",

"guard": "qty > 0 && targetWarehouse != null" },

{ "from": "pending_approval","to": "approved",         "action": "approve",

"guard": "approver.role in ['purchaser_lead','finance','owner']" },

{ "from": "pending_approval","to": "rejected",         "action": "reject",

"require": "rejectReason" },

{ "from": "approved",        "to": "converted",        "action": "createPO",

"require": "supplierId && unitPrice" },

{ "from": "converted",       "to": "partial_received", "action": "receivePartial" },

{ "from": "partial_received","to": "fully_received",   "action": "receiveFinal" },

{ "from": "partial_received","to": "closed",           "action": "closeShort",

"require": "closeReason" }

]

}

这里有个容易被忽略的状态："部分到货后关闭"。供应商缺货，只发了80%，剩下的不发了，这时候你必须有一个明确的收口动作，不能让它永远挂在"部分到货"里。挂着的单据会污染所有在途统计。

4. 回写层：到货质检入库与平台同步

回写层是补货流程真正产生价值的环节，库存数字终于变了。但这里也是最容易出错的地方。

我的建议是：入库分成两步，质检入待检区，质检合格才入可售区。这两步可以在一张入库单上体现，但库存口径必须变两次。少发、多发、错发、破损都要走独立异常单，不能直接改数量。

平台同步要注意延迟。大多数平台的库存同步是分钟级甚至更慢，做促销前必须预留缓冲。我的经验是，大促前把可售库存按95%计算，留5%的缓冲防止超卖。

5. 每一层必须有的字段清单

五、具体案例与数据观察：以数跨境跑一遍真实链路

前面讲的是方法论，这一节讲落地。我在2024年做过一次实验：拿一个做户外用品的卖家数据，用数跨境（https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）搭建库存分层和补货看板，把整套流程从口径定义跑到异常复盘。

1. 为什么我坚持先有数据底座，再谈补货规则

很多卖家一上来就想在ERP里配补货规则，结果配完发现数据源本身是脏的：同一个SKU在两个平台的名字不一样、头程费用分摊规则不统一、退货数据没有回写到库存。规则再漂亮，喂进去的是脏数据，出来的也是脏建议。

我在这件事上的判断很明确：补货规则是上层建筑，数据口径是地基。地基没打好之前，任何规则都是临时补丁。数跨境这类跨境数据工具的价值，恰恰在于它把多平台的订单、库存、费用先统一到一套口径里，然后再让你在上面做分析和规则。

2. 用数跨境做库存分层看板的思路

我的做法分三步。第一步，接入平台数据，把多店铺的商品映射到内部SKU。第二步，定义七个库存口径，并把可售天数、日均销量、交期这些派生字段算出来。第三步，把补货建议作为一个视图呈现，而不是一个自动动作，先让人看，让人判断，跑顺了再考虑自动化。

这个顺序很关键。直接上自动化，你会失去对规则的手感；先跑人工看板，你能发现规则哪里不贴合业务，然后再把规则固化下来。

3. 一次模拟推演：从口径统一到指标改善

下面这组数字是我基于该卖家三个月的真实数据做的情景模拟，不是精确统计，但方向是可信的。核心变化不是算法升级，而是口径拆分加上补货建议可见化。

口径拆分完成后，最直接的变化是运营不再问"到底还有多少货"。因为看板上有七个数字，每个都有明确含义，运营自己就能判断。第二个变化是采购的紧急单变少了，因为建议里已经扣掉了在途，重复下单的情况大幅减少。

第三个变化比较隐蔽：财务开始参与补货讨论。因为看板上有了资金占用和库龄分布，财务第一次能用量化方式表达"这批货压太久了"，而不是笼统地说"少补点"。

4. 数据观察：滞销金额的SKU集中度

我在多个卖家的数据里反复看到一个规律：滞销库存金额高度集中在少数SKU上。通常前5%的SKU贡献了40%左右的滞销金额，前20%贡献超过四分之三。

这个规律的实践意义是：你不需要对所有SKU做精细的补货优化，你只需要盯住那20%。剩下80%的SKU用统一的保守规则跑就够了。这是典型的帕累托场景，也是资源有限时最划算的投入方向。

5. 我在这件事上踩过的坑

第一个坑是太早上自动化。我一开始就把建议数量直接写进采购单模板，结果运营发现建议不对也不改，直接提交，错误被放大了。后来改成"建议只是建议，必须人工确认"，反而准确率提高了。

第二个坑是忽略了退货。跨境退货周期长，退回的货可能一个月后才重新入库。如果退货库存没有单独的"退货在途"口径，你会高估短缺程度，多补一批。

第三个坑是跨币种。采购用人民币，平台结算用美元，汇率波动会让资金占用报表失真。后来我统一按采购时点的汇率锁定，不做实时重估，只做期末调整，报表才稳定下来。

六、不同情况下的行动建议

流程设计没有标准答案，只有匹配。下面我按日订单规模、经营模式、履约模式三个维度给出建议，你可以对号入座。

1. 按日订单规模分档

日订单50单以下：不要上复杂系统。用一张表格把库存拆成可售、在途、待检三个口径，每周更新两次。补货靠人工判断，但每次下单必须记录：下单日、数量、预计到仓日、依据。有记录就够了。

日订单50到200单：开始需要固定规则。设置可售天数阈值，比如低于交期天数的1.5倍就触发补货建议。审批设一级，金额超过一定阈值升二级。这个阶段的关键是把"每周看一次"变成"每天看一次"。

日订单200到800单：必须处理分批到货和在途分层。采购订单和入库单要解耦，一个订单可以关联多张入库单。同时要开始做SKU级的安全库存差异化，不能所有SKU一个参数。

日订单800单以上：主数据治理成为瓶颈。SKU映射、供应商主数据、仓库主数据必须有专人维护。这时候补货规则应该模块化，不同品类、不同供应商、不同履约模式走不同规则集。

2. 按经营模式分

铺货模式：SKU多、单品销量低、生命周期短，建议用简化的统一规则，重点控制"总资金占用上限"，而不是精细化每个SKU的补货量。

精铺模式：SKU中等、部分爆款，建议做分层管理：爆款做精细补货，长尾用统一规则。这个模式最需要"可售天数"这个指标。

精品模式：SKU少、单品销量大、断货损失高，建议做多级安全库存和活动备货计划，交期要精确到周，最好有备选供应商。

品牌模式：除了补货，还要考虑新品导入、老品退市、季节性周期。建议按生命周期阶段设定不同的补货策略。

3. 按履约模式分

国内直发：交期短，但单个包裹成本高，补货频率可以高一些，库存压力小。重点是控制每单履约成本。

海外仓：补货批次少、单批量大，一次判断错误代价很高。必须做在途分层和海外仓到国内仓的二次在途跟踪。

平台仓（如FBA）：补货受平台入仓规则限制，需要预留入仓预约和上架时间。库存口径要把"已发货未入仓"和"已入仓未上架"分开。

4. 一张行动清单

七、不同情况下的取舍

流程设计的本质是做取舍。下面这五组取舍，我几乎在每个项目里都会遇到。

1. 算法精度 vs 人工可控

算法越复杂，精度可能越高，但可解释性越差。我的取舍原则是：在团队还没有形成对补货规则的手感之前，宁可要一个简单但完全透明的规则。等团队跑顺了，再逐步引入更复杂的参数。

具体来说，初期用"日均销量 × 覆盖天数 + 交期"就够了，不要一上来就上机器学习预测。因为一旦出问题，你需要能定位是哪个参数错了，而不是面对一个黑盒。

2. 共享库存池 vs 店铺独立库存

共享库存池的好处是利用率高，多个店铺共用一批货。坏处是容易超卖，因为各平台的同步有延迟。

我的建议是：如果平台同步能做到分钟级，且你愿意留5%到10%的缓冲，可以共享；如果同步延迟超过15分钟，或者你在做大促，建议按店铺或按平台分配独立库存池。

这个取舍没有绝对正确答案，取决于你能承受的超卖代价。超卖在亚马逊上会影响账号健康，代价很高，我倾向于保守。

3. 集中仓 vs 分仓

集中仓管理简单、库存利用率高，但配送时效差。分仓时效好，但库存被分散，每个仓都要留安全库存，总库存上升。

我的经验数字：每增加一个仓，总安全库存大约上升15%到25%。所以只有当单个仓的辐射范围和时效问题严重到影响转化率时，分仓才划算。不要为了"看起来专业"而分仓。

4. 审批严格 vs 响应速度

审批越严，人祸越少，但响应越慢。跨境的交期本来就长，审批再拖三天，等于把交期又拉长了。

我的建议是分层：常规采购、老供应商、金额在预算内，走自动或一级审批；新供应商、新品类、超预算、紧急空运，走多级审批。同时给紧急采购设一条快车道，但必须有事后追认机制。

5. 自建 vs SaaS vs 表格

表格适合日单50以下，成本低、灵活。SaaS ERP适合日单50到1000，把流程固化下来，省人力。自建或深度定制适合有特殊业务逻辑的团队，比如自研产品、自营海外仓。

这里我要提醒一句关于"免费ERP"的取舍。免费通常意味着功能有边界，比如订单量、店铺数、账号数、API调用次数的限制，或者高级功能（如在途分层、审批流、报表导出）需要付费。用免费版跑通流程没问题，但你要提前确认清楚限制在哪，别等业务量上来才发现要整体迁移，迁移成本远高于当初直接付费。

6. 我自己的取舍原则

总结下来，我在做补货流程设计时的取舍原则是三条：口径清晰优先于算法先进；人工留痕优先于自动化省事；响应速度优先于绝对零风险。这三条不一定适合所有人，但对我接触过的中小跨境团队，命中率比较高。

// 采购入库回写时的库存口径更新规则（示意配置）
{

"onReceiving": [

{ "step": 1, "action": "increaseStock",

"bucket": "pending_qc", "qty": "receivedQty" },

{ "step": 2, "action": "runQc",

"passQty": "qcPassQty", "failQty": "qcFailQty" },

{ "step": 3, "action": "transferStock",

"from": "pending_qc", "to": "available", "qty": "qcPassQty" },

{ "step": 4, "action": "transferStock",

"from": "pending_qc", "to": "defective", "qty": "qcFailQty" },

{ "step": 5, "action": "syncToPlatform",

"platforms": ["amazon", "shopee", "tiktok_shop"],

"bufferRatio": 0.95 },

{ "step": 6, "action": "updatePurchaseOrder",

"statusRule": "receivedQty >= orderedQty ? 'fully_received' : 'partial_received'" }

]

}

这份配置里有两个细节值得注意。一是质检合格和次品分两条路径走，绝不混在一起。二是同步到平台时留了95%的缓冲，剩下5%用于抵御同步延迟带来的超卖风险。

八、一页采购补货SOP自查清单与下一步

最后给你一份可以直接拿去用的自查清单。我建议你把它打印出来，和运营、采购、仓管坐在一起，逐条过一遍，哪条答不上来就说明那里有漏洞。

1. 十二个自查问题

1. 你们系统里的"可用库存"，是否已经扣除了平台锁定、在途、待质检、次品四个部分？
2. 在途是否按节点分层（已下单未发货、已发货未到仓、头程中、待质检）？
3. 内部SKU与各平台商品ID是否有完整的映射表，谁负责维护？
4. 补货建议里是否包含了交期和波动系数？参数是否可见可改？
5. 人工修改补货建议时，是否强制填写原因并记录操作人和时间？
6. 采购申请单是否包含目标仓、需求日期、紧急原因三个字段？
7. 审批是否有金额分档？紧急采购是否有专用通道和事后追认？
8. 采购订单能否关联多张入库单，支持分批到货？
9. 是否存在"部分到货后关闭"这个状态，用来收口缺货订单？
10. 质检不合格的货是否有独立流程，是否从可售口径中剔除？
11. 退货、换货、再售是否有独立库存口径，是否会重复触发补货？
12. 每月是否有固定的复盘动作，指标包括缺货率、周转天数、紧急采购占比、滞销金额占比？

2. 落地顺序建议

如果你是第一次系统梳理这块流程，我建议按这个顺序走：第一周只做库存口径拆分，输出一份定义文档，让所有人签字确认。第二周把补货建议的计算逻辑写清楚，哪怕先用表格手工算。第三周梳理采购申请到入库的单据流转，把状态机画出来。第四周再去看系统能不能支持，不能支持的地方列成需求清单。

这个顺序的核心逻辑是：先想清楚，再选工具。反过来做，你会花大量时间在"怎么让系统适应我的业务"上，而这件事的成本远高于"先定义清楚业务"。

3. 下一步你可以做什么

如果你现在就想动手，我建议从最小切口开始：挑一个最近三个月出过问题的SKU，把它从补货信号到最终入库的全过程还原一遍，看是哪一层断了。是信号层没看到低库存？是决策层没扣在途？是执行层没有分批到货？还是回写层质检结果没进库存？

找到那个断点，先修一个。一个SKU跑通之后，再复制规则到同类SKU。这比一次性重构整个体系要现实得多，也更容易在团队里形成共识。

如果你已经在用某个ERP但流程还是很乱，可以先把这篇文章里的十二个自查问题过一遍，把答不上来的挑出来。如果发现是数据口径的问题，先解决数据层，把多平台的订单、库存、费用统一到一套口径，再谈补货规则。我前面提到的数跨境，可以作为这类数据整合和库存分层看板的一个起点，官网在 https://shukuajing.jiushuyun.com/?utm_source=seo&utm;

_plan=est&utm;_unit=gys，你可以先注册看看它的数据维度能不能覆盖你的平台组合，再去决定要不要动规则层。

最后回到我自己的判断：跨境的采购补货，本质上不是一道算法题，而是一道"定义题"和"协同题"。定义清楚每个数字的含义，设计好每个角色的动作和权限，剩下的才是工具的事。把这两件事做扎实，哪怕你用的还是表格和免费ERP，补货也不会失控；反过来，口径没理清就上高级系统，只是把混乱电子化了而已。

免费注册

咨询方案

扫码咨询方案