eMAG大单要不要接？先算清这批现货到底有多少能承诺

平台观察

2026-11-09

263

可真正要算的不是仓库里有多少件，而是从今天起到交付日，哪些货已经不能再自由支配。

10月中旬，离eMAG已经公布的2026 Black Friday还有不到三周。这个时候，如果一个买家突然问：“能不能一次拿800件？”卖家很容易被这个数字吸引。后台明明还有1200件库存，800件听起来也没超过库存，似乎只要点头就行。

eMAG大单库存分配：现货、订单与零售需求的取舍（原创专题配图）

eMAG大单库存分配：现货、订单与零售需求的取舍

可真正要算的不是仓库里有多少件，而是从今天起到交付日，哪些货已经不能再自由支配。

这件事对还有正常零售订单的卖家尤其重要。大单本身没有错，错的是把“仓库有货”“系统显示有库存”和“我现在可以向一个新买家承诺这么多货”当成了同一件事。

先别急着答应，800件现在到底是什么

第一步不是算利润，而是给这条消息定性。

如果买家只是询问“800件能不能做”，它就是询问。买家还没有形成一个已经成立的订单，卖家也还没有因为这条消息就应该把800件从正式可售库存里永久划走。

如果买家进一步提出了采购数量、交付日期、变体、发货地等条件，甚至给出了采购文件，但卖家还没有接受，这仍然应该作为“未成立请求”单独管理。它可以进入内部测算，但不要和已经发生的订单占用混在一起。

真正需要单独拿出来的是已经成立的订单。只要一笔eMAG订单已经进入平台的订单处理流程，就不能再用“这个买家只是来问价”的逻辑处理。已有订单该履行就履行，不能因为后来出现一笔看起来利润更高的大单，就把原来订单的货挪走，更不能把卖家取消当成给大客户腾库存的工具。

eMAG目前的订单体系本身就区分新订单、处理中、已完成、卖家取消、自动取消以及异常关闭等状态。卖家取消订单也会进入账户表现的考量范围。换句话说，大单判断应该发生在“自由库存”这一层，而不是拿已经承担履约责任的库存重新分配。

这也是为什么第一张内部表里，最好把“询问数量”“未成立请求”“已成立订单”分成三个不同字段。800件可以先算，但它不能因为写进表格，就自动变成800件已经锁定的货。

仓库里的1200件，可能只有900件真的能拿来谈

库存盘点最容易出错的地方，是把几个不同口径的数字连续相减。

假设这是一个用于演算的场景：同一发货地实际盘点有1200件货，其中80件处于隔离或质量检查状态，暂时不能作为合格可售实物；120件已经对应eMAG现有订单；另外100件已经承诺给其他渠道的确定性需求。

那么眼下可以自由讨论的大致库存是：

1200－80－120－100＝900件。

这里有一个很重要的前提：1200件是“实际盘点的物理库存”。

如果你的ERP里显示的900件已经是扣掉订单占用、隔离库存后的“可售库存”，就不能再把120件、100件和80件重复扣一次。库存模型最怕的不是复杂，而是同一批货在不同系统里被扣两遍，最后得出一个看起来非常安全、实际却不存在的库存数字。

还有三个条件必须同时对上：销售单位、发货地、要货时间。

如果商品以2件套销售，买家说要300套，需要占用的是600件单品库存，而不是300件。如果买家只接受黑色版本，那么红色和蓝色的库存不能拿来凑数。如果买家要求从罗马尼亚仓发货，而你手里的500件是在中国仓，那么这500件不能因为“全球库存总数够”就直接算进这笔大单。

要货时间同样不能模糊。今天仓库里能出库的货，和预计十天后才到仓的货，是两个数字。

因此更实用的口径应该是：

可承诺自由库存 = 同一发货地、同一销售单位、在要求日期前能够实际出库的合格可售实物 − 已成立订单占用 − 其他已经确认的实际承诺。

隔离货不要先算进去再扣一次；已经被系统的“可售库存”排除的订单，也不要重复扣。

别只问“大单能拿多少”，还要问这几天零售会卖多少

假设清完库存以后，900件确实属于自由库存。

买家现在要800件。看上去只差100件，似乎很好判断。但如果这800件要在未来10天内交付，真正的竞争对象不是另外一个批发商，而是这10天里本来就可能发生的普通零售订单。

普通零售需求不能凭感觉估一个“每天大概20件”。最好直接拿自己的eMAG订单记录，按同一SKU、同一变体、同一发货地和相近的销售环境去看。大促、季节变化、广告投放或者价格调整明显不同的时间段，也不要硬混在一起。

还是用假设数字来算。假设卖家根据自己的历史订单记录判断，未来10天普通零售大约有180件需求，同时决定保留20件库存缓冲。

那么，单纯从“不能影响这10天普通零售”的角度看，大单最多只能拿：

900－180－20＝700件。

这时候买家如果问800件，问题已经很清楚了：不是仓库没有800件，而是其中有一部分已经属于未来10天普通零售需求和库存安全空间。

需求预测如果不是180，而是120件，那么同样口径下可讨论的大单上限会变成760件；如果普通零售需求更接近260件，上限就会降到620件。

所以这里没有一个适用于所有eMAG卖家的“库存留多少才安全”的固定比例。真正有意义的是，把自己的SKU、自己的发货地、自己的销售时间窗口放进去。

更麻烦的是，需求并不总是平均发生。过去十天卖180件，不代表接下来十天每天恰好卖18件。库存模型最好同时看一个偏低情景和一个偏高情景。尤其在大促前后，平均数很容易把风险藏起来。

大单每件赚得少一点，也可能值得；但多拿几十件，结论会突然反过来

库存确定以后，才轮到利润。

大单不能只看销售额。普通零售一件卖得贵，大单一件卖得便宜，但大单省下了一部分拣货、包装、配送等订单级成本，最终谁贡献更多，要把成本放到同一口径里。

下面还是一个纯演算假设，不代表eMAG固定费率。

假设同一批货的单位商品成本统一按28欧元计算。普通零售每件实际净销售额60欧元，随这笔零售订单新增的渠道、支付、配送、包装等可变费用合计15欧元，那么普通零售的单位贡献是17欧元。

如果大单价格折让后，每件实际净销售额只有52欧元，但集中履约让随单新增费用降到11欧元，那么大单单位贡献就是13欧元。

也就是说，大单每件反而比普通零售少贡献4欧元。

这是不是就应该拒绝？还不能这么快判断。

还是900件自由库存、未来10天普通零售需求180件、缓冲20件的假设。为了让比较口径一致，下面三个方案都把20件作为硬性期末缓冲，不把它释放后再卖掉。这样，900件库存只能在“大单数量、实际零售销量、20件期末库存”之间分配。

按前面的纯演算假设，大单单位贡献为13欧元，普通零售单位贡献为17欧元。700件大单时，零售可以卖180件，期末保留20件，贡献为700×13＋180×17＝12160欧元。760件大单时，为了仍然留下20件，零售销量只能降到120件，贡献为760×13＋120×17＝11920欧元。800件大单时，零售销量进一步降到80件，期末仍保留20件，贡献为800×13＋80×17＝11760欧元。

三个方案的库存都完整对上了：700＋180＋20＝900，760＋120＋20＝900，800＋80＋20＝900。区别不再是“有没有释放20件缓冲”，而纯粹是大单拿得越多，挤掉了多少普通零售销量。在这个假设里，大单每件贡献比普通零售少4欧元，所以从700件提高到760件，相当于用60件、每件17欧元贡献的零售销量换成60件、每件13欧元贡献的大单，窗口贡献减少240欧元；从760件提高到800件，又减少160欧元。于是，在坚持20件期末缓冲的前提下，700件方案的短期贡献最高，760件和800件并不会因为“卖给大客户更多”而自动更划算。

这是不是就应该拒绝更大的数量？还不能这么快判断。这里的结论只针对这组假设：普通零售单位贡献高于大单，而且未来10天确实有180件有依据的零售需求。如果大单价格、履约成本或普通零售需求发生变化，结果也会跟着变化。若确实存在慢销尾货，大单还能减少后续库存积压，那么尾货处置价值可以作为另一项增量收益单独加入，不能偷偷塞进上面的单位贡献里。反过来，如果大单单位贡献更高，也可以重新比较它多占库存所带来的增量收益，但仍应先固定期末缓冲，再判断究竟挤掉多少正常零售。

但这些都建立在真实价格和真实履约成本已经知道的前提下。现在只是询问，报价、付款方式、交付方式和实际费用都还未知，就不要为了让模型“算出一个漂亮结果”而自行填一个看似合理的数字。

固定仓租、已经发生的人员工资、已经支付的系统费用，也不要为了大单再完整摊一次。真正影响“大单和普通零售谁更划算”的，是两条路径之间新增的成本和收入差异。

尾货也要算进去：小心为了保零售，最后留下一堆卖不动的货

库存分配还有另一面。

如果这款商品本身周转很快，普通零售需求有充分历史依据，那么给大单留出较大的零售库存空间很合理。

但如果它是季节性园艺用品、某个即将换代的3C配件，或者某个颜色本来就卖得慢，库存留下来并不天然等于资产。大单如果能一次性消化一部分尾部库存，即使单位贡献稍低，也可能值得重新评估。

这里尤其要看“剩下多少”和“剩下什么”。

同一个SKU有100件尾货，和同一个SKU只剩100件热门变体，商业价值完全不同。前者可能是压货，后者可能是下一周正常零售最需要的货。

因此，大单之后的剩余库存最好再拆一次：有多少可以继续正常卖，有多少属于慢变体，有多少需要等补货才能重新形成完整商品组合。不能只看一个总件数。

如果剩余库存会落到一个明显的慢销尾部，而大单又能在同一时间窗口把它们整体消化，那么“大单单位贡献略低”未必是坏消息；如果剩下的恰好是核心畅销变体，那就完全是另一笔账。

在途货不是今天的库存，补货日期也不是一句“供应商说快到了”

最容易被大单谈判带偏的，还有那批“已经在路上”的货。

假设另外还有200件正在从供应商发来，对方说预计7天到仓，而大单要求10天内交付。不能在900件自由库存上直接加200，告诉自己“其实有1100件”。

今天能承诺的仍然是900件。

那200件只能进入另一个时间轴：预计什么时候到仓，什么时候完成验收，什么时候进入可售状态，什么时候真正能从对应发货地出库。只要其中任何一个节点还没有可靠依据，就不能把它当作今天已经可发的货。

如果供应商只是说“已经生产好了”，那就更不能算。生产完成不等于已经到仓，到仓也不等于已经完成可销售准备。

补货日期可以用来做情景分析，却不应该拿来替代现货。

比如大单要货日是第10天，补货预计第7天到，那么可以进一步研究第7天以后这批新增库存能覆盖多少普通零售需求；如果补货日期只是一个没有确认依据的口头预计，就把它标成未知。库存模型里宁可出现一个“未知”，也不要出现一个虚假的安全垫。

如果货在FBE，别把“仓库有货”理解成“卖家可以随意改这笔货怎么分”

FBE又会让这个判断多一层。

eMAG公开资料显示，FBE由eMAG负责仓储以及订单处理、拣货、包装、配送、退货等环节。对于已经进入FBE履约链路的库存，卖家面对的不是普通自发货仓库那种“今天想怎么分就怎么分”的简单场景。

公开API文档目前还区分了FBE订单和卖家履约订单：FBE订单与卖家履约订单在订单编辑权限上并不相同，文档显示可编辑订单与FBE订单的处理边界也不同。因此，一笔大批量询问如果未来真的进入eMAG订单流程，不能想当然地认为“先接下来，之后再改数量”一定可行，尤其不能把普通自发货订单的操作习惯套到FBE订单上。

如果FBE库存同时服务多个市场，也要把共享库存池一起看。eMAG公开的FBE资料说明，其仓储可以支持罗马尼亚、保加利亚和匈牙利的订单履约。此时你不能只拿某一个站点的零售销量当需求基线，因为同一批实物可能同时承担多个市场的销售。

至于所谓“特殊B2B大单入口”，公开资料没有提供足够依据让卖家把它当成一个可以先锁货、后议价、再绕开普通订单流程的标准功能。没有核实到的特殊按钮，就不要放进库存模型里；更不要因为买家采购量大，就把eMAG正常订单和平台外导流混成一套流程。