2023 年 8 月，我陪一个做家居收纳品类的卖家做半年度库存复盘。他有 6 个亚马逊店铺，分布在北美、欧洲、日本三个站点，SKU 接近 900 个，美国还有两个第三方海外仓。他给我看的第一份材料，是一份 14 个分页的 Excel：每个店铺一份 FBA 库存报表，每个海外仓一份库存表，再加一份采购在途表、一份头程在途表。
他问我的第一个问题不是"怎么降库存"，而是"我现在到底有多少货"。这个问题他花了两天没算清楚。不是因为数据没有，而是 14 份表里的编码规则不一样：海外仓用内部编码，亚马逊报表里是 MSKU 和 FNSKU，采购表又是工厂货号。三套编码之间没有映射，只能靠人眼一个个对。
这是我做跨境电商数据项目实施近八年见过的典型多店库存困境：不是没有工具，而是工具和数据之间缺了一条可执行的路。这条路的正式名字叫"实施路径"，它决定了你买的软件最终是资产还是负债。
下面我把这条路完整拆开：从口径定义、编码映射、数据接入、库存台账、补货预警，一直到跨店协同和财务口径还原。每一个阶段我都会给出判断标准、真实数据观察和取舍建议，你可以直接对照自己团队现在的位置。
先给结论。我参与过的十余次库存类软件实施里，失败的项目几乎都不是败在软件功能上，而是败在这三件事上：主数据没统一、口径没定义、节奏没设计。软件只是把这三件事放大，做对了它放大效率，做错了它放大混乱。
绝大多数多店卖家说"我的库存有 5000 件"时，其实自己也不确定这 5000 件指的是什么。是 FBA 可售？含不含预留？含不含在途？含不含海外仓？含不含国内工厂已下单未发货的部分？
这五个口径算出来的数字，可能相差 40% 以上。我见过一个极端案例：同一个卖家，运营看后台觉得"库存充足"，采购看表格觉得"要断货了"，财务看现金流觉得"压货太多"。三个人都没错，因为他们用的是三套口径。
实施的第一步不是接入数据，而是把"库存"拆成七个独立账户，并给每个账户写死定义。这一步通常需要 3 到 5 个工作日，很多人嫌慢，直接跳到买工具，然后在后面用几个月的时间反复返工。
很多卖家以为多店库存的技术难点是"能不能连上亚马逊接口"。实际上 SP-API 的接入在 2024 年已经非常成熟，真正难的是：同一个物理商品，在美国站叫 A，在德国站叫 B，在海外仓叫 C，在工厂叫 D。
如果没有一张"采购 SKU ， 内部 SKU ， MSKU ， FNSKU ， 仓库编码"的映射主表，你连"每个商品的全球总库存"都算不出来，更别说跨店调拨和跨站共享了。
我的一般做法是：先在 Excel 里把映射表手工建起来，字段包括采购 SKU、中文品名、内部 SKU、各店铺 MSKU、FNSKU、ASIN、变体关系、包装规格、装箱数、默认供应商、默认头程方式。这张表不依赖任何软件，但它决定了后面所有软件能不能跑通。
我在项目里最常见的错误配置是：所有 SKU 用同一个安全库存天数，所有站点用同一个交期，所有店铺用同一个覆盖天数。
结果就是爆款天天断货、长尾天天压货、欧洲站按美国的补货节奏进货导致库存积压。原因很简单：不同品类的销量波动系数差 3 倍以上，不同站点的头程交期差 2 到 6 周，用一套参数必然有一半的 SKU 处在错误状态。
这句话我在每个项目启动会上都会讲。库存管理软件能做到的是：把分散在 6 个后台、3 个仓库、5 张表格里的数据，在 5 分钟内汇总成一张可读的视图，并标出异常。它做不到的是：替你判断这个 SKU 到底是继续补货还是清货。
如果一个工具承诺"自动补货、一键下单"，我建议你格外谨慎。补货决策包含市场判断、竞品动作、季节性、现金流约束，这些是人的判断；软件的价值在于把判断需要的输入准备好。
库存失控很少发生在第一年。第一年通常只有 1 到 2 个店铺，SKU 少于 200 个，老板自己就能记住每个商品的库存状态。真正出问题的时间点是第二年下半年到第三年，店铺数量、站点数量、仓库数量、SKU 数量同时跨过临界点。
我把这个过程称为"三次断层"，每次断层都会让上一阶段的管理方法失效：
我接触的卖家大多是在第三次断层之后才意识到要上工具。这也解释了为什么很多人第一次采购软件时，需求清单是模糊的，他们缺的不是功能，而是先把前两次断层的账补上。
这是我做库存诊断时必做的第一张图。一个商品在某一时刻的库存，实际由七个账户构成：
只算第四个账户，是绝大多数多店卖家的通病。在旺季或者促销期间，预留占比会明显上升，此时"可售"数字会剧烈波动，如果补货只看可售，就会出现"看起来缺货就猛下单，货到了又发现其实不缺"的循环。
多店经营还有一个容易被忽略的层面：亚马逊本身在不断调整库存相关的规则。以美国站为例，IPI 阈值的公开规则在过去几年里在 400 到 500 之间调整过，库容管理也从季度制转向了月度制，库龄附加费和低库存水平费是近年新增的收费项。具体数值每年都在变，请以卖家后台的最新公告为准。
这些规则对多店卖家的实际影响是：你不能只用一个"要不要补货"的判断，而是要在"断货风险"和"库存积压成本"之间找一个动态平衡点。而这个平衡点，每个站点、每个品类、每个 SKU 都不一样。
再说一层容易被低估的成本：对账。美国站的日期口径是太平洋时间，欧洲站涉及多国增值税，日本站又是另一套结算周期。当你把 6 个店铺的库存、销量、成本汇总到一张表上时，会出现三种典型偏差：
这三个偏差不会让库存数量的绝对值出错，但会让"哪个 SKU 赚钱、哪个 SKU 该砍"的结论完全不同。我在项目里通常会在实施阶段就把这三条口径写进文档，并要求所有报表都基于同一套口径生成。
下面这六条是我在复盘项目失败原因时反复见到的。每一条我都标注了它的实际代价，以及我建议的替代做法。
这是出现频率最高的错误，也是代价最大的一个。团队在没有统一编码和口径的情况下买了工具，然后把脏数据导进去，得到的是一份"看起来很专业但没人敢用"的报表。
我做过一次统计：在 11 个我参与或复盘的库存类项目中，先理数据再选工具的项目，平均上线周期是 7 周；先选工具再补数据的项目，平均上线周期是 19 周，而且后者有 3 个项目最终放弃。
替代做法很简单：在选型之前，用一张 Excel 把编码映射表和库存账户定义做出来。这张表可能只有 200 行，但它会让你的选型需求清单精确 10 倍。
ERP 的核心职责是流程和单据：采购单、入库单、出库单、调拨单。数据分析工具的核心职责是聚合和呈现：多店汇总、趋势对比、异常识别。这两件事在技术上是不同的能力。
我见过团队用 ERP 自带报表做多店分析，结果是每次要加一个维度就要找供应商开发，三个月才能上线一个字段。也见过团队用纯 BI 工具管采购流程，结果是单据流转全靠手工同步，出错率极高。
正确的分工是：ERP 管"动作"，数据工具管"判断"。两者通过统一编码对接，而不是互相替代。
前面已经说过七个账户，这里补充一个更具象的观察。我在一个旺季项目里做过连续 30 天的抽样：某个爆款 SKU 的 FBA 可售在 380 到 1,950 之间波动，波动幅度接近 5 倍，但同期这个 SKU 的真实"总可用量"波动只有 1.4 倍。
如果补货系统只读可售字段，在这 30 天里会触发至少 4 次错误的紧急补货建议。而每一次错误的紧急补货，都意味着额外的空运成本和潜在的超额库存。
按 30 天平均日销补货是最常见的做法，也是最容易出错的做法。原因在于：平均值的可靠性取决于销量的波动性，而不同层级 SKU 的波动性差异极大。
我的经验分档大致是：头部爆款（占销量前 20%）的日均销量波动系数通常在 0.3 到 0.6；中部稳定款的波动系数在 0.5 到 0.9；长尾款的波动系数经常超过 1.5。波动系数越大，需要的安全库存倍数越高，但如果对长尾款也按高倍数备货，资金占用会迅速失控。
所以正确的做法不是统一提高安全库存，而是分层设置：爆款用高服务水平、长尾用低服务水平甚至按单采购。
美国站的头程海运交期可能是 30 到 40 天，德国站因为清关和内陆运输可能到 45 到 55 天，日本站可能只有 15 到 25 天。如果三个站点共用同一套交货期参数，日本站会系统性压货，德国站会系统性断货。
我建议的参数维度至少包括：站点、仓库、头程方式、供应商。这四个维度组合起来，一个卖家通常会有 8 到 20 套不同的参数组。听起来复杂，但在工具里就是一张参数表的事。
多店经营有一个必须始终放在第一位的约束：账号安全。多个店铺的后台操作、授权、数据获取，必须遵守平台的多账号政策，不能因为追求"统一管理"而让多个账号在环境或授权上产生不当关联。
在实施层面，这意味着：数据聚合层和管理操作层要分开。数据聚合可以通过官方授权接口做汇总分析，而涉及后台操作的动作，必须回到各自的独立环境里完成。这条边界在选型阶段就要问清楚，不要等到实施中途才发现方案里混了这两层。
这一节是全文最核心的部分。当你在评估任何一条实施路径、任何一款工具时，可以用下面五条来判断它是否真的能支撑多店经营。
库存管理的最低有效颗粒度是 FNSKU，因为 FBA 的库存、库龄、仓储费都是按 FNSKU 计算的。但如果只到 FNSKU，你就无法和采购、工厂、财务对话。
所以判断标准是：系统能否在 FNSKU 级别采集数据，同时通过映射表自动汇总到采购 SKU 级别。这个能力看起来简单，但它是多店库存能不能"算总账"的分水岭。
我把库存的时间轴分成四段：
大部分工具只覆盖前两段。而多店经营最容易出错的恰恰是第三、第四段，重复下单、漏发头程、货件丢件，都属于这一层。
我判断一个补货建议好不好，不看它准不准，先看它能不能解释。完整的补货建议应该能回答：日均销量用了多少天窗口、波动系数是多少、交期取了多少天、安全库存倍数是多少、当前计入的可用量包含哪几个账户。
下面是我在项目里常用的补货计算逻辑，你可以对照任何一个工具的输出，看它能不能还原到这一层：
安全库存 = Z × 日销标准差 × sqrt(交期天数 + 补货周期)
补货点 = 日均销量 × (交期天数 + 补货周期) + 安全库存
建议补货量 = 目标覆盖天数 × 预测日均销量
(FBA可售 + FBA在途 + 海外仓可用 + 国内仓可用 + 头程在途)
向上取整到最小起订量的整数倍
其中：
Z 由服务水平决定，95% 服务水平对应 Z ≈ 1.65
交期天数按 站点 × 头程方式 × 供应商 分组取值
日均销量窗口按 SKU 层级取值（爆款 15 天，长尾 45 天）
能解释的补货建议，运营才会用；不能解释的建议，最后都会被人为覆盖掉，工具就白买了。
库存管理最终要服务于资金决策。所以工具必须能回答：这批库存压了多少钱？按什么汇率折算？头程费怎么分摊到 SKU？平台费、仓储费、长期仓储费算进去了没有？
我的一般要求是：同一批库存，在采购、库存、销售三个视角下的成本可以互相追溯。做不到追溯，财务和运营就会一直扯皮。
这是区分初级工具和成熟工具的关键。报表展示是"你想看什么就查什么"，异常发现是"系统主动告诉你哪里不对"。
在我看过的有效实施案例里，最高频被使用的功能不是报表，而是异常清单：库龄超过 120 天的 SKU 清单、可售天数低于交期的 SKU 清单、在途超过预期 15 天未到仓的货件清单、同一 SKU 在两个店铺库存差异超过阈值的清单。
这些清单的共同特征是：它们指向一个具体的动作，而不是一个需要再分析的指标。
这一节我把开头提到的那个卖家的实施过程完整拆出来。为了便于对照，我会按阶段给出每个阶段的工作内容、耗时、关键产出和判断依据。文中数据来自项目过程记录，属于样本推演数据，不是行业统计，请作为参考量级而非绝对标准。
这个阶段完全没有碰软件，全部工作在一张 Excel 里完成。产出三样东西：
这两周里最耗时的不是定义，而是补历史数据的映射关系。因为很多 SKU 的历史变体关系已经改变，需要从亚马逊后台逐个核对。900 个 SKU 里，最终发现 61 个 SKU 存在映射缺失或错误，占 6.8%。
这 6.8% 如果不修，后面所有汇总数字都会带上系统性误差。
接入包括三类数据源：亚马逊各站点店铺数据、两个海外仓的库存数据、国内采购与头程数据。这里我用到了一个思路：先对账，再分析。
所谓对账，就是把系统汇总出的"某店铺某 SKU 某日可售数量"，和亚马逊后台同一天的原始数字逐条比对，偏差超过阈值的全部查清楚。这一轮对账花了整整 3 周，最终把偏差控制在 1% 以内。
这 3 周是很多人想跳过的 3 周。我的经验是：跳过对账的项目，通常会在 3 个月后被迫回头补做，因为运营一旦发现数字不准，就会彻底不再信任系统。
数据准确之后，开始做汇总。这个阶段的核心产出是一张"多店多仓库存总览"，回答三个问题：每个 SKU 的全球总库存是多少、分布在哪些账户、按当前销速还能卖多久。
这一阶段我用的是数跨境这类跨境电商数据工具来承接。它的定位比较清楚：对接亚马逊等平台的数据，做多店铺、多站点的数据汇总与分析，把原来需要手工拼 14 张表的工作，收敛到一个可以随时查看的库存视图里。它的官网是 https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys ，如果你正在做选型对比，可以作为一个参考样本去看它的数据接入范围和库存分析维度。
我这里说一个具体的判断依据：在评估这类工具时，我会特别关注它能不能在同一个视图里同时呈现"店铺维度"和"仓库维度"。
因为多店经营的真实问题是：同一批货，可能在美国 A 店卖，也可能在 B 店卖，还可能从海外仓发 FBM。如果工具只能按店铺切分，你就永远看不到这批货的真实风险和真实机会。
这个阶段开始产出动作。核心是三张清单：补货建议清单、断货风险清单、滞销与库龄清单。
补货建议清单按"站点 × 仓库 × 供应商"分组生成，每组一套参数。断货风险清单按"可售天数 < 交期天数"筛选。滞销清单按库龄区间分档，120 天、180 天、270 天、365 天四档，每档对应不同的处理动作。
这里有个细节值得说：我坚持把"滞销"的定义从"卖不动"改成"库龄 + 周转天数双条件"。因为有些 SKU 周转慢但利润率极高，一刀切清货会亏；有些 SKU 周转看起来正常，但因为库龄结构问题正在持续产生仓储费。
最后一个阶段是协同，也是多店经营真正释放价值的地方。具体包括三种场景：
这三种场景都有成本，所以不能只看"能不能做"，还要算"值不值得做"。我通常用一张简单的判断表：调货成本 vs 断货损失 vs 继续持有成本，三者取最小值。
不是所有卖家都需要同一套方案。下面我按店铺规模、SKU 数量、仓库结构分四类，给出具体的行动建议和大致投入量级。
这个阶段的复杂度还在人力可覆盖范围内。我的建议是先做三张表：库存账户表、编码映射表、补货计算表。三张表之间的关联用最简单的 VLOOKUP 就能实现。
投入量级：一个人 3 到 5 天搭建，之后每周 2 到 4 小时维护。这个阶段买系统，通常会出现"系统里没人填数据"的情况，反而增加负担。
这个阶段手工表格开始崩塌，但还没到必须上重型 ERP 的程度。适合的方式是：用跨境电商数据工具承接多店汇总和库存分析，采购和单据流程暂时继续用现有方式。
投入量级：口径和映射搭建 1 到 2 周，工具接入和首轮对账 2 到 3 周，之后每周维护 3 到 5 小时。这个阶段的验收标准是：能不能在 5 分钟内回答"某个 SKU 现在全球有多少货、还能卖多久"。
到这个规模，一定要做分工。流程层（采购、入库、调拨、出库）用 ERP 承接，数据层（多店汇总、库存分析、补货建议、异常预警）用数据工具承接，两层之间通过统一编码对接。
投入量级：整个实施通常 8 到 12 周，需要至少一名内部负责人全职投入。这个阶段最容易失败的原因不是技术，而是内部没有明确 owner，导致跨部门的口径争议无人裁决。
已经自研或有 ERP 的团队，我不建议推倒重来。更现实的做法是：先补上编码映射层和库存账户定义，然后检查现有系统缺的是哪一段。
根据我的经验，已有 ERP 的团队通常缺的是两样东西：一是 FNSKU 级别的时间轴数据（历史库龄、在途时长分布），二是跨店铺的库存合并视图。这两样都可以在不动主系统的前提下，通过外挂一个数据层补齐。
实施路径的每一步都是取舍，没有"全都要"的方案。下面五组取舍是我在项目里最常需要做的判断。
自研的优势是贴合度高、可随时调整；劣势是隐性成本极高。我用一个粗略的换算：一个能稳定运行的库存数据模块，前期开发通常需要 2 到 4 人月，之后每年至少 0.5 人年的维护投入。
所以我的判断标准是：如果你的核心业务逻辑本身没有独特性，采购更划算；如果你的库存逻辑和行业标准做法差异很大（比如定制生产、特殊包装、特殊合规），自研才有必要。
一体化方案的优势是数据天然打通、维护方单一；劣势是每个模块都不够深，且切换成本高。组合式方案的优势是每一层都能选到最合适的；劣势是对接成本高，口径容易二次割裂。
我在项目里的实际选择是：流程层用一体化，数据层用组合式。原因是流程层的需求相对标准化，而数据层的分析需求变化快，需要保持可替换性。
很多团队一开始就要求实时同步。但从库存决策的角度看，绝大部分补货判断依据的是日均销量和交期，这两个指标的更新频率是天级甚至周级，实时同步带来的决策价值有限，成本却可能高出数倍。
我的建议是分场景：库存数量可以按小时或每日同步，销量和库龄按日同步，财务口径按周或按月同步。真正需要实时的场景很少，比如大促期间的断货监控。
精细到 FNSKU 是必要的，精细到每一笔出入库流水则是可选的。后者会带来显著的存储和维护成本，而且大部分时候并不影响决策。
我的经验线是：SKU 少于 500 时，可以精细到流水；SKU 超过 2000 时，建议只保留天级汇总和关键事件流水。
这是多店经营里最需要组织层面拍板的一组取舍。集中管理的好处是库存可以统筹，坏处是对站点市场的响应变慢；站点自治的好处是决策快，坏处是容易出现站点之间抢货、重复采购。
我见过的有效做法是分层：库存账户定义、成本口径、映射规则集中管理；补货参数、促销计划、价格策略由站点自主，但要在统一框架内。这样既保留了统筹能力，又不牺牲响应速度。
最后我把整篇内容收敛成四个判断，供你在下一步行动时对照。
第一，库存管理的实施顺序是"口径，映射，接入，对账，动作"，不可跳步。口径和映射决定了后面所有数字是否有意义；对账决定了运营是否信任系统；动作清单决定了工具是否被真正使用。跳过任何一步，都会在后面以数倍的时间偿还。
第二，多店经营的核心难点不是数据量，而是同一商品的多重身份。把采购 SKU、内部 SKU、MSKU、FNSKU、仓库编码之间的关系维护好，比选任何工具都重要。这张映射表应该成为你库存体系的基础设施，而不是某个项目的一次性交付物。
第三，补货参数必须分层、分站、分仓。爆款和长尾应该被区别对待，美国站和德国站的交期应该被区别对待，FBA 和海外仓的补货逻辑也不一样。分层带来的不仅是准确度提升，更是资金效率的结构性改善。
第四，工具的边界要提前想清楚。数据工具的价值在于把分散信息聚合成可判断的视图，并在异常发生时主动提示。它不替代人的市场判断，也不应该被要求替代。想清楚这一点，你在选型时就不会被"智能决策""自动补货"这类话术带偏。
如果你准备开始行动，我建议的顺序是：本周先做一件事，把七个库存账户的定义写下来，并核对一遍你的编码映射表完整性。这两件事不需要任何工具，也不需要任何预算，但它们决定了你后面买的任何工具有没有用。做完之后，再去看工具的接入范围、分析维度和补货逻辑是否匹配你这套定义，这个过程比看十份产品演示都有效。
多店经营的库存管理没有终点，它的本质是持续缩短"发现问题"和"做出决定"之间的时间差。软件只是把这个时间差压短的工具，而压短的幅度，取决于你在数据底层做了多少功课。
我刚开始做多店时，觉得软件嘛，先把几个店铺授权接进来，库存自然就同步了。结果两个店共用同一批货，A店出了单，B店还显示可售，超卖后广告权重掉了一截，客服也赔了不少。后来复盘才发现，真正该先做的不是接店铺，而是把SKU主数据理顺。
先做SKU主数据和仓库映射，再接店铺，顺序反了后面全是补丁。可执行做法：建一张本地SKU、ASIN、MSKU、仓库或货主对照表，本地SKU作为唯一主键；把每个店铺的ASIN和MSKU映射到同一个本地SKU，但保留店铺维度；先只读拉取30天订单和库存快照做对账。
判断依据：多店库存事故里，超过一半不是同步慢，而是同一个实物货被多个店铺当成独立库存卖。对账误差超过2%时不要开写入权限，先修映射。接店铺的顺序按销量和库存重叠度来，先接共享库存最多的两个店，跑通7天再扩。
我做过一次秒杀，后台设置15分钟同步，结果两个店同时卖，库存扣减延迟，超卖了几十单。我就想知道同步到底多快才够，安全库存设多少合理，是不是所有店铺都用一个阈值就行。
同步频率按场景分层：日常15到30分钟，广告、秒杀、大促用事件触发加1到5分钟，最好支持订单创建即预占。安全库存不要拍脑袋：单店预留等于近7天日均销量乘2到3天，大促按历史峰值单小时销量乘3；共享库存池可用库存等于实物库存减已售未扣减在途不可售减质检锁定减各店硬预留。
超卖率目标控制在每千单低于3单，P95同步延迟低于5分钟。如果软件不支持预占和硬预留，只能靠人工调库存，多店超过3个就不建议用。
我同时跑FBA、第三方海外仓和国内自发货，经常出现FBA快断货，海外仓还有一堆，但软件还是按默认仓发货。我想知道实施时到底该按什么优先级分配库存，才能既不压货又不断货。
优先级按时效、成本、风险排序：FBA优先满足高转化和Prime订单，海外仓承接FBA断货和中小件，自发货做长尾或定制。实施时在软件里建三层规则：第一层按配送时效，FBA可售天数低于7天时自动降权，低于3天停止接新单或转海外仓；
第二层按费用，算每个仓的到岸成本、尾程运费和仓储费，毛利低于目标线的SKU不自动调拨；第三层按库存风险，库龄超过90天且动销低于1的SKU只出不进。调拨触发看可售天数：低于安全天数1.5倍时生成补货建议，高于3倍时暂停补货。数据口径用可售天数而不是库存件数，因为多店销量差异大，件数会骗人。
我们上了一套库存管理软件后，老板问我到底有没有效果，我一开始只能回答“感觉库存准了”。但感觉不能拿来做决策，我想知道有没有一套验收指标，能看出实施是否成功、值不值得继续投入。
用四个硬指标验收：库存准确率，账实一致率要大于等于98%，抽样盘点和系统差异超过2%就返工；同步延迟，P95小于等于5分钟，超卖率每千单小于等于3单；缺货与周转，多店综合缺货率下降30%以上，库存周转天数缩短15%以上，滞销90天以上库存占比降到10%以内；
人工效率，原来每天2小时对账降到30分钟以内。回本周期按年费除以年化收益算，年化收益等于减少超卖赔付和降权损失、降低缺货损失、减少人工工时、减少滞销折价之和。一般3到6个月能看到正向回报。实施分阶段验收：第1周只读对账，第2到3周单店单仓写入，第4到6周多店共享库存池，第7到8周自动补货和调拨。
没有这些口径，软件上线只是把手工混乱变成系统混乱。
读者评论
我们去年也建过那张映射主表，最初两百多行，两周就搭起来了，但真正难的是维护：新品上架、MSKU 因变体拆分被重建、海外仓换编码服务商，每次都要回头改。现在我们是把它挂在一个共享表格里，谁上新谁补，反而比指望项目上线时一次性整理靠谱。实施周期的账，可能要按持续维护来算，不是七周就结束。
那组前后对比的数据我持保留态度。周转天数从 82 降到 58、滞销占比从 17.6 降到 8.9，看着很漂亮，但文章自己也说了是单个卖家的样本推演。我更想知道同期有没有外部变量，比如是不是刚好砍掉了几条长尾线、是不是旺季前主动降了备货，这些动作不做系统也能让数字变好。
七个库存账户里，最容易被低估的是头程在途和预留。我们做过一次对照，只看可售下的补货建议，有一个月多下了两票空运，事后算下来那批货其实不缺，空运费吃掉那个 SKU 整个季度的大半毛利。所以我现在更关心的是系统能不能把船期波动和清关延误算进交期，而不是汇总得多快。