ManoMano一单多包裹，发货回传为何不能只留一个单号？

先认清买家说的“一单”包含什么

家居园艺商品很容易形成不同形状的包裹。长杆工具、卷管器、零配件，可能在一次购买中出现，却不适合放进同一个纸箱。拿这种组合说明，一笔订单可以对应几种SKU，也可以发成多个包裹；订单件数、商品数量和箱数是三项需要分别记录的信息。

ManoMano的法国站包裹追踪帮助明确介绍，体积较大的商品可能分多个包裹发出，且不会在同一时刻送达。买家收到第一批纸箱后，可以查看内容与箱面标识，确认预计总箱数，官方用“Colis 1/3”说明三箱中的第一箱。

家居园艺订单可能按商品形状分箱准备。

还有一种表面相似的情况：买家在平台一起买了多种商品，实际涉及不同商家。法国站配送方式说明指出，不同商家各自安排配送方式、费用和时间，所以购物过程中会出现多个承运商和运输安排。客服接到“一单少一箱”的问询，应先确认缺的是本店商品，还是另外一家商家的货。

英国站修改订单帮助也说明，新增商品来自不同卖家时，会形成独立订单。对卖家来说，找到本店对应的订单参考号，再查看这笔订单的商品明细，能把责任范围落到具体商品。买家的购物印象可以帮助了解情况，仓库与平台记录仍要沿相应订单分别核对。

确认同一笔卖家订单之后，再找各包裹属于什么商品。有的订单是多个独立商品分箱，有的则是一件大件产品本身需要几箱。先问清这一点，后面谈数量、追踪与缺件才会使用同一个口径。客服若把“收到一箱”直接写成“收到一件”，可能从第一条记录就错过实际的装箱方式。

接口回传要保留每个包裹里的商品

在ManoMano Partners API公开文档中，Create shippings明确支持同一订单存在多个包裹时，在请求内容里添加各包裹的追踪信息，以及里面装了哪些商品。这个结构的价值，是把原来的一项订单发货记录展开成可核对的包裹与商品关系。

当前示例为每条发货信息列出承运商carrier、订单参考号order_reference、卖家合同编号seller_contract_id，以及tracking_number和tracking_url；products则列出包裹中的seller_sku和quantity。运营不必手写接口，但向工具服务商说明问题时，应该能问清这些信息是否都被保留。

官方请求示例中的两个包裹采用同一个订单参考号与合同编号，各自有不同追踪号，并列出不同的商品组合。它表达的是同一订单下的多条发货信息，并非把两个箱子的号码拼成一个长字符串。若对接工具只有一个订单级追踪栏，第二个号码从哪里写入、怎样回传，便是需要查明的具体问题。

可以用一组自拟商品来理解：一箱装两件小工具，另一箱装一件卷管器。每箱需要对应自己的追踪信息和商品数量，查小工具时找到第一箱，查卷管器时找到第二箱。这样的记录既方便仓库核对，也让客服能够回答买家问的是哪件商品、它位于哪个包裹。

订单参考号还要与卖家合同编号一起对应。公开接口的发货信息同时包含这两项，工具里的本地订单编号不能自行替代平台参考号。多个渠道或合同一起处理时，应让维护人员确认数据关联采用哪项编号，避免包裹已经发出，回传却指向了另外一组订单资料。

箱数增加，不应把售出的商品数量也改大

仓库装箱资料可以先把“每箱装什么”写清，再与订单中售出的数量对应。例如买家购买四件同款商品，实际装成两箱，每箱两件，两箱所列商品数量合起来应解释原来售出的四件。若回传时每箱都套用整笔订单的四件，数据表达的总数就变成了八件。

逐包记录箱内商品，核对SKU与实际数量。

反过来，订单里有几种商品共用一箱，仍应保留箱内各SKU的数量。一箱里同时有手套和连接件，只有一条追踪号可以说明包裹去哪了，却无法单独说明每种商品装了多少。发货资料中的products正是用来保留这种商品信息，维护人员可以拿实际装箱记录与工具生成的数据逐项对照。

一件大件产品分成三箱，又是另一种数量关系。商品仍是一件，纸箱数量是三箱。平台买家帮助允许认识这种分箱场景，但接口数量字段的填写仍要根据工具如何表达这一SKU的分包来确认，不能直接把每个箱子都当作一件独立售出商品。仓库先给出真实箱数及内容，对接人员再确认对应方式，才不会把包裹数量误写为商品销量。

实物分包时，也可以让箱面编号与装箱资料采用相同顺序。官方给买家的“1/3”检查方法，需要包装中存在可以辨认的箱数信息。卖家使用自己的仓库编号时，应能回到这笔订单解释第一箱、第二箱各有什么，让买家接收到的标识与客服查询到的资料相连。

若某个SKU在不同箱里出现，客服核对时还要把这些箱一起找到。买家说只收到一部分，可能是同款数量尚未齐，也可能是另一种商品未到。先查看订单购买数量，再汇集对应包裹的实际送达情况，比仅凭订单状态回答“已经发货”更贴近买家要确认的东西。

批量发送完成，还需要查看平台返回的处理结果

Create shippings的当前公开说明规定，每个请求最多包含50条shipment，即发货记录。对于一单多包的业务，统计批量数量时，应检查工具发送的发货条目，而不能只数这一批有多少订单。一笔订单有多条发货信息，就会占用多条记录的数量。

实际对接时，可以拿一批分包订单核对三处：仓库生成了多少个包裹，工具准备了多少条发货信息，哪些商品和追踪号位于各条信息里。三处数量不同，并不都表示错误，但差异必须能由实际的合包、分包或工具表达方式解释。只看界面上“本批订单数”，不足以知道每个包裹是否都进入了回传。

公开文档为全部操作成功提供204响应示例，同时也列出207 Multi-Status以及逐项result、error等内容。收到混合结果时，维护人员需要继续看具体记录，而不能把“请求已经返回”写成整批发货均已完成。文档里的示例只是字段展示，实际错误应依据该次平台返回来判断。

排查可以从平台订单参考号与合同编号定位，再核对相关订单所有包裹的处理情况。若只确认第一条追踪信息已进入平台，就把整笔分包订单划为完成，另一条信息的问题可能继续留在队列里。需要关注的是尚未确认的具体资料，以及它关联哪些商品，而不是重复发送整批记录。

仓库保存的装箱结果、工具实际提交的内容、平台返回的处理结果，分别说明实物、回传与接收这三个环节。把它们对应起来后，才适合修正错填的SKU、漏掉的包裹或错误的订单关联。出现不明结果时，先查当前平台记录，再决定如何补充处理，能避免把同一组资料反复提交而增加排查难度。

订单显示已发出，买家仍可能只收到第一箱

ManoMano公开接口说明，创建发货信息后，相关订单状态会变为SHIPPED。法国站买家帮助则把“Expédiée”解释为订单已交给承运商；“Livrée”在承运商确认送达之后更新。仓库完成交接和买家收到全部货物之间，还有各个包裹实际运输的过程。

因此，买家询问第二箱时，客服应继续查第二箱的追踪信息。第一箱送达可以说明那一箱的进度，第二箱仍需要自己的运输记录。官方帮助已经说明分箱不一定同时到达，订单界面中的简短状态，不能单独回答本次购买的每一个包装箱现在在哪里。

分箱送达时，应分别确认各箱进度与内容。

法国站帮助列出的发货信息包括承运商、追踪链接与预计交货日期，买家既能通过邮件查看，也能在账户中打开相应购买记录查看。卖家可以先了解买家看到了哪个号码、哪一箱的预计时间，再对照自身记录。若卖家已经有两个号码，买家只知道一个，问题可能在信息传递或查询范围，需要沿两边资料继续确认。

邮件和账户信息也适合一起检查。买家没有找到通知时，官方建议查看垃圾邮件；账户中则有相应订单状态与运输详情。客服提供帮助时，可以指向买家已有的查询入口，再说明有关商品对应的包裹。只转发仓库内部编号，买家未必能够在承运商网站找到那一箱。

在预计期限尚未超过、仍有纸箱待送达的情况下，官方买家帮助建议继续等待。这个建议有明确的前提：确实属于分箱配送，尚未收到全部货物，交货期限也尚未超过。客服应先核对箱数和时间，再解释当前进度。缺少这些信息，只给买家一句“还有包裹没到”，仍然没有回答其实际疑问。

分包信息要跟到交付，也要跟到缺件问询

收到货物后，箱数与内容可以帮助区分后续问题。买家只收到两箱，而装箱资料显示共三箱，应先找到未到的第三箱；买家已收到三箱，却发现其中某件商品没有，则要继续查看装箱内容与订单购买资料。两个问题需要找的记录不同，客服可以从实物接收情况开始识别。

对需要组装的大件商品，几块板材、配件包与说明资料在不同纸箱里的安排，也应该能从仓库记录中解释。这是卖家整理交付资料时的工作判断，并不意味着每种商品都需要同样的箱数。了解自己怎样装箱，才能在买家描述某个部件时，找到可能对应的箱子并进一步核实。

法国站追踪帮助还提醒，承运商可能通过邮件、短信或电话与买家约定交付。大件分包时，客服掌握各箱的承运商和联系方式来源，便更容易解释哪一项通知与当前包裹有关。预约安排、已经交接的箱子和尚未送达的箱子，应沿各自的实际进度查看。

使用对接工具的卖家，也值得确认维护的是哪一版订单接口。ManoMano公开文档已将旧XML订单接口标为2025年3月31日结束生命周期，并要求迁移至REST订单接口。本篇多包裹结构来自当前REST的Create shippings，查看旧教程或工具设置时，应先核对所采用的接口，避免拿旧字段解释新的回传方式。

一单多包的核对结果应该足够具体：本店卖出了哪些商品，分成几箱，各箱采用什么追踪号，平台是否接收了相应发货资料，哪些箱子已经送达。实物与记录能逐箱对应，买家问起缺少的商品时，卖家才能找到可以继续处理的那一箱。

声明：本文系作者独立观点，不代表ESG跨境立场。文中涉及的平台规则、费率及出海政策具有时效性，实际运营请以平台官方最新公布为准。如有版权争议、内容勘误或业务交流，欢迎随时与我们联系。