签收不等于上架，中间那段是库存盲区

做了九年物流，见过最憋屈的一次断货，货就躺在亚马逊仓库里。几百件主力货，签收状态显示完成，促销照常开跑，开跑当天链接断货。货没事，是它还没上架。

签收那天所有人都松了口气

旺季前的主力补货，船期、约仓、签收一路顺。系统里状态跳成「已签收」，计划员把这批货从在途表挪进在库表，运营的秒杀排期就按这个数做了。没有人再看第二个字段——上架。那批货在接收池里排了三周，三周里没有一个人发现。

状态有三个，我们只看两个

一件货进亚马逊，要走过三段：在途、已签收、已上架。我们当时的库存表只建了两列，签收即视为在库。签收到上架之间，货在接收池排队，旺季这段能排两三周，表上它已经「在库」，实际一件都卖不了。运营的排期公式是「可售等于在库减待发」，输入从根上就是错的，后面怎么算都是错的。这个坑还有个放大器：签收之后的货丢了算亚马逊的，所以从风险角度大家都默认它「安全了」，安全的东西没人盯，盯着的那几天反而都花在路上。

促销照着不存在的库存开跑

中间那一格，谁的表上都没有

秒杀开跑第一天，库存告急。运营怀疑数据、计划怀疑预测、客服怀疑系统，三方找了两天的原因，最后有人想起去翻后台的入库明细：几百件，状态是处理中。货一直都在，只是躺在盲区里。秒杀的坑位费打了水漂，链接还因为断货闪了一下，评分掉了小半格，客服那几天都在处理同一个问题。事后算，如果这批货按时上架，那三周的日均销量本来能覆盖掉旺季的前半段——签收和上架之间差的三周，直接变成了三周的空窗。

把三段状态并进同一张表

整改很朴素。库存表加一列「上架率」，签收超过规定天数未上架的标红，旺季分仓取宽，计划员每天扫一遍红项。促销排期的口径从「在库」改成「已上架」，多出来的那部分一律视为不存在，哪怕它已经签收了。改完之后，「在库」这个数第一次和「能卖」对上了。

签收只是法律意义上的交接

签收证明的是从那一刻起货丢了算亚马逊的，不证明你能卖。库存表里最危险的一列，是那种看起来已经完成的状态——它让人停止追问，而货还在排队。上架率监控上线后第一个月，又抓到过两批「签收了没上架」的货，旺季的排期再没为这种事翻过车。现在我们问任何一个计划员「这批货到哪了」，回答永远是三段式：在路上、已签收、已上架——中间那段，不许跳。