很多亚马逊卖家第一次上库存管理软件，注意力全放在"选哪家"上，真正的问题却爆发在上线第三周：后台账面库存 12000 件，实际可售只有 8700 件，中间那 3300 件的差额没人说得清去了哪里。我陪跑过一个深圳家居类目团队，那个季度因为 FBA 断货叠加滞销清理，吐掉了 40 多万毛利，而他们买的软件年费不到 3 万。问题从来不是软件贵不贵，而是这份落地清单有没有被真正执行。这篇文章不讲虚的选型话术，只讲库存模块从选型、上线、对账到验收全过程中，新手最容易踩进去并且很少被提醒的那些坑。
第一条：库存管理软件买的是"流程约束"，不是"数据自动变准"。软件只能把你已有的数据口径固定下来并且放大，口径错了，它只会让你更快、更自信地做出错误决策。我见过卖家用软件自动生成补货单，一次下错 8000 件，原因只是基础表里"在途库存"字段填了 0。
第二条：上线顺序必须是"先对账、再补货、后分析"，反过来一定翻车。太多团队先做漂亮的可视化看板，结果底层数据对不上，看板越精致，决策越离谱。看板是结果，不是起点。
第三条：验收标准要可量化，不能是"用起来顺手"。我建议的验收线是：库存准确率 ≥ 98%、断货率相对上线前下降 30% 以上、库存周转天数下降 10% 以上、月度对账人工耗时下降 60% 以上。
大多数卖家选型的顺序是：先看功能列表，再看价格，最后才想数据怎么进来。我的判断正好相反，在你没有把 SKU 主数据、成本口径、在途口径这三件事定义清楚之前，任何工具都救不了你。
原因很简单：库存管理软件本质是一个"规则引擎 + 数据容器"。规则你没定义，容器装进去的就是垃圾。我做过粗略统计，在库存模块上线失败或半途弃用的案例里，约七成归因于数据口径混乱，而不是软件功能缺失。
所以我的建议是，选型前先花 3 到 5 天做一次"库存数据体检"：把近 90 天的库存快照拉出来，对照实际盘点结果，算一遍差异率。如果差异率超过 5%，先别买软件，先修数据。
库存管理工具其实分三层，很多新手把它们混为一谈，这是后面所有混乱的根源。
交易层解决"单据往哪里走"：采购单、入库单、出库单、调拨单、退货单，典型形态是 ERP 或订单管理系统。仓储层解决"货在哪个货架"：库位、批次、效期、拣货路径，典型形态是 WMS。分析层解决"该不该补、补多少、钱压在哪"，典型形态是 BI 或跨境数据分析平台。
新手最常见的错误，是拿分析层的工具去干交易层的活，或者拿交易层的工具去做深度周转分析。层错配不会马上出错，但会在两三个月后集中暴露。
除了能力边界，实施周期和成本也是选型时必须摆到桌面上的硬约束。下面这张对照表来自我参与过的 11 个中小卖家项目，价格区间按 2024，2025 年的市场报价折算，属于经验参考区间而非报价单。
| 层级 | 典型实施周期 | 年成本区间 | 最适合的起始规模 | 最大风险 |
|---|---|---|---|---|
| 交易层（ERP/OMS） | 4，8 周 | 0.8，3 万元 | SKU 500 以上、有自有仓 | 上线周期拖长，业务停摆 |
| 仓储层（WMS） | 8，16 周 | 1.2，4 万元 | SKU 2000 以上、多货架作业 | 货位改造不同步，账实更乱 |
| 分析层（BI/数据平台） | 1，2 周 | 0.3，1 万元 | SKU 100 以上即可用 | 误当 ERP 用，无法落单据 |
这张表的核心提醒是：分析层的门槛最低、见效最快，但它永远代替不了交易层。你可以先用分析层看清问题，但真正要让流程跑起来，交易层和仓储层该上还得上。
这个阶段几乎所有人都在用 Excel，而且用得很舒服。一个 Sheet 记录 SKU，一个 Sheet 记录采购，一个 Sheet 记录 FBA 发货，人工核对两三个店铺的后台库存，每次半小时能搞定。
问题在于，这个阶段的"准确"是假象。它依赖的是某个员工的责任心和记忆，而不是流程。一旦这个员工休假或者离职，库存数据立刻回到原点。
SKU 过百之后，第一个崩掉的是补货判断。你开始记不清哪个 SKU 还有 15 天库存，哪个已经只剩 8 天。接着崩掉的是成本核算，头程运费、关税、退货损耗分摊到每个 SKU 上，手工算一次要大半天，于是干脆不算了。
我观察到的规律很清晰：当 SKU 数量突破 300 个时，纯人工库存管理的准确率会从 95% 以上快速掉到 80% 以下。而 80% 的库存准确率，在亚马逊这个断货和滞销都会直接吃掉利润的环境里，基本等于没有管理。
开第二个、第三个店铺之后，库存管理从"记账问题"变成"协同问题"。每个店铺后台的库存口径不一样，FBA 可售、FBA 在途、FBA 待入库、FBM 可售、海外仓库存，这些状态分散在不同后台，靠人一张张表贴起来，每次汇总至少 5 个小时。
更麻烦的是，人工汇总天然有延迟。你周三下午汇总的数据，反映的是周二晚上的状态，等到周四上午做补货决策，市场早就变了。
很多团队在这个节点终于决定上工具，然后发现真正的困难才刚开始：历史数据怎么导、SKU 编码怎么统一、在多店铺同名 SKU 怎么区分、在途库存怎么定义、成本用哪个口径。
我给这个阶段的建议只有一句：不要试图一次性把所有历史数据搬进新系统。先用近 90 天数据跑通流程，历史数据留作查询即可，全量导入往往是把旧错误复制到新系统里。
这是最基础也最致命的错误。ASIN 是商品身份，FNSKU 是亚马逊仓内的标签身份，MSKU 是卖家在某个店铺里给这个商品起的编号，而你自己内部的 SKU 编码是第四套体系。
很多卖家在系统里只留一个字段，结果同一个商品在两个店铺卖出时被当成两个 SKU，库存直接翻倍虚增。正确做法是建立一张映射表，把内部 SKU 作为主键，其他三套编码作为属性字段。这张表建不好，后面所有对账都是白费。
在途库存是库存管理里最大的幻觉来源。采购已下单未到货、FBA 已发货未签收、海外仓已发未上架，这三类货都不在你手里，但都能在表里看到。
新手最常见的操作是把它们全部计入"可用库存"，于是补货公式算出来"还够卖 40 天"，实际能发 FBA 的只有 9 天，剩下 31 天的货卡在海上或者亚马逊签收队列里。
我的建议是至少在系统里拆成四个状态：可售、在途、待上架、不可售（含残次和冻结）。补货决策只能用"可售"加"确定性到货在途"，其他一律不进公式。
这个公式在教科书上成立，在亚马逊上不成立。它至少漏掉了六个变量：季节性波动、FBA 签收和上架延迟、生产排期、海运与空运的时效差异、促销活动带来的销量跳变、以及断货本身对排名和后续销量的伤害。
更合理的做法是引入"安全库存系数"，让补货量等于日均销量乘以补货周期加安全库存，再减去当前可用库存和在途确定性库存。安全库存系数按品类设置，标准品可以低一些，旺季或者海运周期长的品类必须调高。
这是我认为性价比最高的一个避坑点。很多卖家在系统里录成本时只填采购单价，于是一个售价 29.99 美元、看起来毛利 40% 的产品，扣掉头程、关税、平台佣金、FBA 配送费、退货损耗之后，实际毛利可能只有 8%。
可怕的是，如果系统用的是不完整成本，它会一路把错误传导下去：毛利虚高 → 补货激进的 SKU 判断错误 → 库存越压越多 → 现金流断掉。成本口径错了，补货逻辑不可能对。
软件之间的数据同步几乎都有延迟。平台 API 拉取有周期，第三方工具轮询也有间隔，FBA 数据本身还有亚马逊侧的入账延迟。这类延迟在高频出单的店铺里会直接造成超卖。
我给的经验阈值是：任何库存同步链路，都必须知道它的最大延迟时长，并把这个时长写进补货和上架规则里。如果同步延迟是 2 小时，那么在促销期间，安全库存就应该额外加厚一档。
我见过太多团队花两周时间把三年历史订单一口气导进新系统，结果导完之后发现 SKU 重复 400 多个、成本字段一半为空、退货单和原始订单对不上，清理这些脏数据又花了一个月。
更稳妥的做法是分批导入：先导主数据（SKU、供应商、仓库），再导近 90 天交易数据，最后视需要补历史。让系统先跑起来，比让数据先齐起来重要得多。
库存数据里包含采购价、供应商、成本结构，这些是卖家最敏感的信息。新手往往图省事，把所有运营的权限都开到最大，员工离职后账号还留在系统里。
合理的权限设计至少分三档：查看层只看库存数量和周转，操作层可以发起补货和调拨，管理层才能看到成本和供应商。每个季度做一次账号复核，这是成本最低的风险控制。
这一条是新手最容易忽略、代价又最大的一条。分析层工具做图表、做周转分析、做滞销预警都非常强，但它不会替你把补货单发出去，也不会自动生成入库单。
我见过团队用分析工具拉出补货建议，然后手工把数字抄到采购表里，中间跳过复核，一次抄错位数，多订了 8000 件货，货到仓库才发现是去年的旧款。工具没有错，是用错了层级。
第一层的目标只有一个：系统里的库存数字，和实际能卖的货对得上。这一层不需要复杂的补货逻辑，只需要一个稳定的对账机制。
具体做法是每天生成一张差异表，把系统账面库存和平台可售库存逐 SKU 比对，差异率超过 2% 的自动列出来人工处理。这个动作看起来笨，但它是后面三层的全部基础。
下面这段 SQL 是我常用的每日对账查询模板，思路很简单，就是找出差异率超过阈值的记录并按严重程度排序。
— 每日库存对账：账面库存 vs 平台可售库存
SELECT
sku,
warehouse AS 仓库,
wms_qty AS 账面库存,
platform_qty AS 平台可售,
wms_qty – platform_qty AS 差异数量,
ROUND((wms_qty – platform_qty) * 1.0
/ NULLIF(wms_qty, 0) * 100, 2) AS 差异率百分比
FROM inventory_daily_snapshot
WHERE stat_date = CURRENT_DATE - INTERVAL '1 day'
AND wms_qty > 0
AND ABS(wms_qty - platform_qty) * 1.0/ NULLIF(wms_qty, 0) > 0.02
ORDER BY 差异率百分比 DESC;
第一层解决的是准确性，第二层解决的是"为什么这么补"。我的判断标准是：任何一个补货建议，都必须能回答三个问题，用了哪些输入、用了什么规则、如果结果错了是哪一步错了。
如果系统给出的补货量无法解释来源，运营就只能凭感觉二次判断，那这套系统等于没上。可回溯还有一个隐性好处：当断货或者积压发生时，你能快速定位是输入数据错了、规则设错了，还是市场真的变了。
很多团队的补货逻辑只考虑"卖得完"，不考虑"卖完赚不赚"。第三层要做的，是把头程、关税、平台佣金、FBA 配送费、仓储费、退货损耗都还原到 SKU 层面。
做完这一步，你会发现一件很有意思的事：有些销量很好的 SKU，全成本算下来其实是负毛利。这类 SKU 在过去往往被当成主力在补货，越补越亏。
第四层是最高层，也是最能体现工具价值的一层。异常包括：库存突然大幅波动、某 SKU 连续多天零动销、长期仓储费即将触发、在途超期未到货、退货率异常升高。
这一层的关键不是发现问题，而是发现问题之后有明确的处理人和处理时限。我建议每条异常都带上三个字段：责任人、处理截止时间、处理结果。没有这三样，异常清单就是一张永远清不完的待办。
按前面的逻辑，第一层是账实相符，为什么不先上 ERP？因为对中小卖家而言，ERP 上线周期长、投入大、影响面广，而分析层的上线周期通常只要一到两周，而且不改变现有作业流程。
我自己的实践路径是：先用分析层把库存看清，找到最痛的三个问题，再决定是否要上交易层或仓储层。这样做的另一个好处是，等你真的上 ERP 时，数据口径已经统一了，实施风险大幅降低。
以数跨境这类跨境数据分析平台为例，它的定位就在分析层：通过对接平台数据，把多店铺、多站点的库存、销量、周转、资金占用汇总到同一个视图里。官网在 https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys ，我建议先注册看它的数据接入方式和指标口径，再判断能不能对上你现有的数据体系。
我在一个 3 店铺、约 480 个活跃 SKU 的测试样本里做过对比。上线前，运营每周要花三个半天做库存汇总表，平均每次 5.5 小时；上线分析层工具后，同样的汇总工作降到每次 20 分钟以内，且不再需要跨部门催数据。
更重要的是口径错误率的变化。人工汇总时，因为手工粘贴和公式拖拽，口径错误率大约在 18% 左右；工具自动汇总之后，这一项降到 2% 以下。省下来的时间还不是最大收益，口径一致性才是。
在同一个样本里，我用分析层把 480 个 SKU 的周转天数做了分层统计。结果很反直觉：周转天数超过 180 天的 SKU 只占 10%，但它们占用了 18% 的库存资金。
这意味着，只要处理掉这 10% 的长尾 SKU，就能释放接近五分之一的资金，而销售额几乎不受影响。这类结论在人工表格里基本看不出来，因为人工汇总通常只看总量，看不到结构。
同样值得注意的是 31，90 天这个区间：它占了 53% 的 SKU 和 46% 的资金。这部分不是问题库存，但它是观察库存健康度的关键窗口，一旦补货节奏变慢，这批货会在两三个月内滑向 180 天以上。
讲优点容易，讲边界更有价值。以数跨境这类分析层工具，我的判断是它适合"看清"，不适合"落单"。它能把多店铺库存、周转、滞销、资金占用看得很清楚，但采购单、入库单、调拨单这些交易动作，它不承担。
所以如果你的团队目前连"哪个 SKU 该补、哪个该清"都说不清楚，分析层工具是性价比最高的第一步。但如果你的痛点是仓库里货找不到、盘点对不上、拣货总出错，那你需要的是仓储层，分析层帮不了你。
另外要提醒的是数据接入的准备工作：店铺授权需要主账号配合，历史数据的字段映射需要人工确认一次，这一步通常要花 1 到 3 天。很多人卡在这一步，误以为是工具不好用，其实是自己的数据没准备好。
这个阶段我不建议买复杂系统。先把 Excel 或轻量表格工具的结构做对：一张 SKU 主数据表，一张库存快照表，一张成本表，并强制要求成本表必须包含头程和关税。
如果你的日均单量已经超过 30 单，可以考虑上一个分析层工具做库存和周转的可视化，成本不高，但能帮你提前建立正确的数据口径习惯，为后续扩张打基础。
这个区间是问题最集中的区间，也是投入产出比最高的区间。我的建议是：先上分析层统一数据口径，同时把 SKU 编码体系和成本口径定死，再考虑是否上交易层。
优先级排序是：编码映射表 > 在途口径定义 > 成本还原 > 补货规则参数化 > 交易层系统。前四项做完，你会发现即使不上 ERP，库存管理水平也能提升一大截。
到这个规模，靠人工已经不可能管理。我的建议是三层都要有：交易层管单据，仓储层管货位，分析层管决策。上线顺序建议是交易层和分析层并行，仓储层分仓分批上线，不要一次性全仓切换。
这个阶段最容易出事的不是技术，而是人。建议设立一个专职的库存计划岗，负责维护补货参数、跟进异常、做月度复盘。这个岗位产生的价值，通常远超它的薪资成本。
混合经营的难点在于同一批货可能在两个渠道之间分配。我的经验是一定要在系统里区分"物理库存"和"渠道库存"，物理库存是唯一的，渠道库存是分配结果，两者之间必须有明确的分配规则。
否则就会出现 FBM 卖了货，FBA 这边却按原库存继续补货，结果货不够发，FBM 被迫取消订单，账号绩效受损。
| 经营场景 | 第一优先级动作 | 推荐工具层级 | 建议验收指标 |
|---|---|---|---|
| 单店铺、SKU < 200 | 建立 SKU 主数据与成本表 | 表格工具或轻量分析层 | 库存准确率 ≥ 95% |
| 2，5 店铺、SKU 200，2000 | 统一编码与在途口径 | 分析层为主，交易层视情况 | 库存准确率 ≥ 98%、断货率下降 30% |
| 多平台、多海外仓、SKU > 2000 | 分仓分批上线，设专职计划岗 | 三层配套 | 周转天数下降 10%、异常闭环率 ≥ 90% |
| FBA 与 FBM 混合 | 区分物理库存与渠道库存 | 交易层 + 分析层 | 渠道分配差错率 < 1% |
功能越全的系统，配置项越多，上线越慢。我见过团队为了等一个"完美支持多币种核算"的功能，把上线时间推迟了四个月，而这四个月里库存准确率一直在 70% 附近徘徊。
我的取舍原则是：能解决当前最大痛点的最小可用系统，优先于功能最全的系统。缺口可以靠流程补，时间补不回来。
补货自动化程度越高，出错时的损失越大。全自动补货在数据稳定的成熟品类里效率很高，但在新品期、促销期、供应链波动期反而是风险源。
我建议的折中是：补货建议自动生成，但超过某个金额阈值的补货单必须人工确认。这个阈值可以设置在月均补货金额的 1.5 倍左右，既保留效率，又兜住风险。
自建的好处是贴合业务，坏处是维护成本高、人员流动风险大。我的判断是：除非你的业务模式非常特殊，否则不要自建库存系统。库存管理的核心逻辑在行业里高度趋同，自建往往是在重复造轮子，而且造得不如专业团队。
更好的做法是采购标准工具，把自建的精力放在数据集成和规则配置上，这部分才是真正体现你业务理解的地方。
数据越集中，分析越方便，但泄露风险也越大。尤其是把多店铺授权集中在一个系统里，一旦账号管理不严，风险会成倍放大。
我的建议是：主账号绝不下发给普通运营，所有工具授权走子账号，并开启二次验证。同时每季度核对一次授权清单，把不再使用的工具授权全部撤销。
| 取舍维度 | 倾向效率的选择 | 倾向安全的选择 | 我的建议分界点 |
|---|---|---|---|
| 功能 vs 速度 | 买功能最全的 | 先上最小可用版本 | SKU 超 2000 再考虑完整功能 |
| 自动化 vs 复核 | 全自动补货 | 全人工确认 | 金额阈值设为月均补货的 1.5 倍 |
| 自建 vs 采购 | 自建贴合业务 | 采购标准工具 | 业务模式无重大特殊性时选采购 |
| 集中 vs 分散 | 数据全部集中 | 分系统隔离 | 主账号不下发，子账号全覆盖 |
我不建议用"用起来顺手"来判断库存软件是否落地成功。可以看的三个硬指标是：库存准确率、断货率、库存周转天数。这三个指标如果在上线 90 天后没有实质改善，那问题一定不在软件。
附加两个软指标也很重要：月度对账的人工耗时是否下降 60% 以上，以及异常库存的闭环处理率是否达到 90% 以上。前者反映效率，后者反映流程是否真正跑起来了。
第一件，把近 90 天的库存快照和实际盘点结果拉出来，算一次差异率。如果超过 5%，先别谈选型，先修数据。这一步通常两个小时内能出结果，但它的价值超过任何一篇选型指南。
第二件，把 SKU 主数据表建起来，至少包含内部编码、ASIN、FNSKU、MSKU、供应商、采购价、头程成本这七个字段。这张表是后面所有工作的地基。
第三件，把在途库存拆成"确定性在途"和"不确定在途"两类，并明确规定只有前者能进补货公式。这一个动作，就能挡掉新手最常见的超卖和积压问题。
写到这里，我想说一个自己的判断：库存管理工具的价值，不在于它替你做了多少决策，而在于它让每一个决策都变得可解释、可回溯、可优化。新手最容易犯的错，是期望买一个系统解决所有问题；而真正跑通的人，往往是先用工具把数据看清，再用流程把规则定稳，最后才谈自动化。以数跨境这类分析层工具，恰好适合作为这个顺序里的第一步，成本低、见效快、不会打乱现有作业。先把数据看明白，再谈工具怎么选，这个顺序不要反。
我刚开始做亚马逊，手上三百多个 SKU，一直用表格手工记库存，平时还能撑住，一到大促或者同时发几批 FBA 就彻底乱了。所以我很想直接买个库存管理工具一劳永逸，但又怕花了钱发现流程本身就没理顺，工具反而把混乱放大了。到底该先干哪一步？
先梳理流程和字段，再选工具，顺序反过来基本都会翻车。具体做法是先手工建三张表：第一张是 SKU 主数据表，包含 SKU、ASIN、FNSKU 的映射关系、包装规格、单件成本、供应商、生产交期；第二张是库存台账，按在途、国内仓在库、FBA 可售、预留、不可售分列；
第三张是补货参数表，写清安全库存天数、起订量、补货周期。判断依据很简单：如果这三张表你连手工都填不满、填不准，上任何系统都只是把混乱搬进软件里，后面所有报表都是错的。建议先挑 20 个主力 SKU，用表格完整跑一到两周的出入库和补货流程，把字段口径定死再去试用工具。
特别提醒一个口径坑：FBA 可售数量要用后台的可售字段，不要用总库存，因为预留和不可售通常会让数字虚高十几个百分点，很多新手第一周就是因为这个把补货判断做反了。
我第一次导入期初库存的时候，系统显示的总件数比我自己表格算的多了两百多件，查了一整晚才发现是箱规和单件混着算了。后面每次盘点也总有十来个 SKU 对不上，真的很打击信心，不知道是系统问题还是我操作问题。
差异九成不是系统问题，而是数据源和导入方式的问题。可执行的做法是三条：分批导入、三个总数核对、设冻结期。分批导入是指按仓库或店铺维度切分，一次只导一个仓库，不要把所有 SKU 堆在一个文件里；
导入前先用表格把同样的数据算一遍总量，导入后核对总件数、SKU 数、总成本金额这三个总数，三个都对齐才算成功；冻结期一般是三到七天，期间只允许通过系统做调整单，禁止任何人手工改表。
判断依据来自实际踩坑经验：初期差异最集中的来源是单位不统一（箱和件混用）以及 SKU 前后有空格、大小写不一致，这两类能占到六成以上。上线之后不要指望一次盘清，改成循环盘点，每周抽盘百分之十到二十的 SKU，一个月覆盖全量，这样差异会逐步收敛到千分之几的量级。
我同时开了两个站点的店铺，仓库是同一批货，结果有一次一边已经卖完，另一边还在正常接单，最后只能取消订单，账号绩效被扣了一截。我现在特别纠结同步频率设多快才够，安全库存又要留多少才不算浪费。
分两件事来定：同步频率和安全垫。同步频率上，涉及共享库存的场景建议不超过十五分钟一次，并且要求系统在同步失败时能立刻告警，而不是静默失败。安全垫的算法可以用：安全库存等于日均销量乘以交期天数再乘以一点二的系数，新品期取销量的上限区间而不是平均值。
判断依据是超卖的代价明显高于多压一点库存，超卖会直接推高取消率并影响账号绩效，而多留的安全库存只是占用一点资金。对于日销低于五件的长尾 SKU，更稳的做法是在销售端把可售数量压到实际库存的百分之八十到九十，用可控的缺货风险换掉超卖风险。
另外一定做一次故障演练：手动断开一次同步接口，看系统多久告警、恢复后会不会重复扣减或漏扣，这个测试比任何功能演示都能暴露真实水平。
我们公司刚把库存这块搬进系统，老板问我效果怎么样，我只能说感觉流程顺了一点，但拿不出数字。我自己也想知道，究竟该看哪些指标、上线后第一个月应该盯什么，不然很容易被当成白花钱。
用四个指标验收，别用感觉。第一个是库存准确率，口径是盘点一致的 SKU 数除以盘点 SKU 总数，要求件数级别完全一致，目标不低于百分之九十八；第二个是缺货率，指有流量但没有库存的 SKU 占比，目标控制在百分之五以内；第三个是滞销占比，九十天无动销的库存金额除以总库存金额，目标在百分之十五以内；
第四个是补货建议采纳率，反映团队是不是真的在用系统而不是绕过它。节奏上分三个月推进：第一个月只看准确率，第二个月看缺货率，第三个月再看周转和滞销。
判断依据是如果第二个月准确率还不到百分之九十五，问题基本不在工具，而在出入库单据没有百分之百过系统，这时候应该停下来先解决流程执行，而不是急着换工具或加功能。
读者评论
我们去年上线库存工具时也卡在MSKU和内部SKU映射，系统里只留一个字段，两个店铺库存直接虚增。后来先做映射表花了三天，对账才顺。文章说七成失败归因数据口径，不算夸张。但小团队SKU不到200时，先别急着买系统，Excel加固定对账模板可能更划算。
在途库存拆四个状态这点认同，但“确定性到货在途”实操很难定义。海运查验、FBA签收延迟都会让确定性变不确定。我们后来按供应商和历史时效给在途打置信度，而不是简单二值，补货公式才稍微靠谱。想问安全库存系数具体怎么按品类调？
库存准确率≥98%的验收线，对多店铺加FBM加海外仓的卖家可能偏高。我们做到96%已经很难，差异主要来自退货在途和平台冻结。断货率下降30%也受季节影响，只对比上线前后不太公平。建议验收分模块，先看可售与账面差异，再谈周转。