客户连续下了三笔订单,分别采购不同型号的产品。
由于三笔订单的交付时间比较接近,销售人员与客户沟通后,决定将这些商品合并安排一次发货。
从物流安排来看,合并发货可能减少重复运输和包装操作,也方便客户集中接收商品。
但对于负责订单和仓库管理的员工来说,合并发货并不只是把几张订单的商品放在一起。
如果没有明确记录每张订单对应的实际发货数量,就容易出现这样的情况:
仓库确认货物已经发出,销售人员却无法判断哪张订单完成交付;客户询问其中一笔订单还有多少商品没有发货,跟单人员需要重新核对多张发货单。
尤其是不同订单包含相同产品时,如果只记录本次发货的商品总数量,就可能无法还原每张订单的实际执行情况。
因此,企业在安排多笔订单合并发货时,需要同时管理两类信息:
一类是本次实际发出了哪些商品,另一类是这些商品分别对应哪些销售订单。
以下是一个虚构的外贸业务案例,用于说明多笔订单合并发货时的核对方式。
某贸易企业与同一客户签订了三笔销售订单:
| 销售订单 | 产品型号 | 订单数量 |
|---|---|---|
| SO-001 | 产品A | 500件 |
| SO-002 | 产品A | 300件 |
| SO-003 | 产品B | 200件 |
三笔订单合计需要交付1,000件商品。
其中,产品A共800件,产品B共200件。
由于仓库备货及客户收货安排,企业计划将三笔订单中的部分商品合并发货。
本次实际准备发出的商品为:
产品A:600件。
产品B:200件。
合计:800件。
如果只查看本次发货商品汇总,可以知道产品A发出600件、产品B发出200件。
但无法直接判断产品A的600件应该计入SO-001还是SO-002。
这就是多笔订单合并发货时最需要解决的问题。
对于存在相同产品的多笔订单,仓库不能仅根据商品型号汇总数量。
例如,客户虽然在SO-001和SO-002中都订购了产品A,但两张订单可能存在不同的交付要求。
SO-001可能要求先交付400件,SO-002则允许本次交付200件。
因此,企业需要在安排合并发货之前,明确每张订单实际参与本次交付的商品和数量。
按照上面的业务案例,可以整理为:
| 销售订单 | 订单数量 | 本次计划发货 | 本次发货后待发 |
|---|---|---|---|
| SO-001(产品A) | 500件 | 400件 | 100件 |
| SO-002(产品A) | 300件 | 200件 | 100件 |
| SO-003(产品B) | 200件 | 200件 | 0件 |
| 合计 | 1,000件 | 800件 | 200件 |
通过这张表,可以明确:
SO-001本次发货400件,还有100件尚未交付。
SO-002本次发货200件,还有100件尚未交付。
SO-003本次发货200件,完成全部数量交付。
即使三笔订单使用同一次运输,也不能直接将三张订单全部标记为已完成。
企业在管理发货业务时,通常需要区分三个数据:
订单数量: 客户在销售订单中确认采购的总数量。
累计已发数量: 截至当前,企业已经根据该订单实际发出的商品数量。
剩余待发数量: 根据订单数量和已发数量计算出的尚未交付数量。
例如,某张销售订单需要500件产品。
第一次已经发货100件,本次计划再次发货300件。
如果本次300件已经完成实际发货,那么:
订单总数量:500件。
历史已发数量:100件。
本次发货数量:300件。
累计已发数量:400件。
剩余待发数量:100件。
如果系统只记录本次发货300件,却没有与之前的100件建立关联,就可能错误判断订单执行进度。
因此,合并发货核对时,不仅要查看本次发货计划,还要结合每张订单的历史发货记录。
有些企业习惯按照实际运输批次管理发货单。
例如,同一辆货车或同一个集装箱中,可能同时装载多个销售订单的商品。
这种情况下,可以将本次运输安排与具体订单明细分别记录。
例如:
本次合并发货:DN-001
发货日期:11月12日。
客户:ABC Trading。
本次发货数量:800件。
对应订单明细:
| 销售订单 | 商品 | 本次发货数量 |
|---|---|---|
| SO-001 | 产品A | 400件 |
| SO-002 | 产品A | 200件 |
| SO-003 | 产品B | 200件 |
| 合计 | — | 800件 |
这里的DN-001是为了说明业务关系而使用的虚构发货单号。
这样的记录方式,可以同时满足两个查询需求。
从发货单查看: 本次运输包含哪些商品、涉及哪些销售订单。
从销售订单查看: 这张订单参加了哪些发货批次、累计发出了多少商品。
需要注意,以上是一种多订单合并发货的数据管理思路,并不代表所有ERP系统都默认支持一张发货单直接关联多张销售订单。
如果当前系统的发货单只能对应一张销售订单,企业也可以按照实际功能保留各订单独立的发货记录,再通过统一的物流批次、装柜信息或其他业务标识进行关联管理。
关键是不能因为共用一次运输,就失去每笔订单的发货明细。
备货完成和实际发货是两个不同的业务阶段。
例如,仓库按照计划已经为三张订单准备800件商品,但在实际装车或装柜时发现,部分商品因包装问题暂时无法发出。
原计划SO-002发货200件,最终实际只发出180件。
如果系统仍然按照计划数量记录发货,就会出现账面发货数量与实际交付数量不一致的问题。
这时,本次实际发货应重新核对为:
| 销售订单 | 计划发货数量 | 实际发货数量 | 差额 |
|---|---|---|---|
| SO-001 | 400件 | 400件 | 0件 |
| SO-002 | 200件 | 180件 | 20件 |
| SO-003 | 200件 | 200件 | 0件 |
| 合计 | 800件 | 780件 | 20件 |
如果此前没有其他发货记录,则本次实际发货完成后:
SO-001剩余待发100件。
SO-002剩余待发120件。
SO-003已经完成全部数量交付。
这说明,企业不能仅凭备货完成状态判断订单已经发货。
只有按照实际出库及发货情况确认数量,才能准确更新每张订单的执行进度。
合并发货结束后,销售人员通常需要向客户反馈本次交付情况。
如果客户询问某张订单是否已经全部发出,销售人员应能够根据订单的累计发货记录回答,而不是只查看本次运输是否已经完成。
对于财务人员来说,合并发货也不意味着不同订单的合同金额和应收款可以直接合并处理。
例如,三张销售订单可能对应不同合同、不同付款安排,甚至不同交易币种。
虽然商品使用同一次运输,但财务仍需要根据合同及相关业务记录核对应收款和实际回款。
因此,企业应当区分:
物流层面的合并: 多张订单的商品共同安排一次运输。
订单层面的执行: 每张订单独立记录实际发货数量和完成情况。
财务层面的核对: 根据合同、订单及付款约定管理相关应收和回款。
只有明确这三个层面的区别,才能避免物流已经完成,但订单状态和财务记录仍然无法对应的问题。
对于需要经常合并发货的企业,可以建立一份简单的核对清单。
确认本次参与合并发货的销售订单。
核对每张订单的商品型号及数量。
检查各订单历史已发和剩余待发数量。
确认本次计划分配给各订单的发货数量。
检查仓库备货及包装是否符合要求。
确认客户是否接受本次合并交付安排。
按实际装车或装柜数量核对商品。
记录本次实际发出的产品及数量。
确认各商品对应的销售订单。
保留必要的发货单及物流资料。
更新每张订单的实际发货记录。
重新核对累计已发数量及剩余待发数量。
检查订单是否已经完成全部交付。
根据实际业务向客户反馈发货情况。
根据合同和相关业务记录核对应收及回款。
这份清单的目的,不是让仓库增加复杂的审批环节,而是减少合并发货过程中容易发生的数量和订单对应错误。
对于同时处理多个客户订单的贸易企业来说,销售订单与发货记录之间的关联非常重要。
LiangtingsERP提供客户、合同、销售订单、产品、备货及发货等相关管理模块,帮助企业统一记录订单及实际交付业务。
在销售订单管理中,可以记录客户采购的商品、数量、价格及订单执行状态。
在备货管理中,可以根据实际业务安排商品准备工作,记录相关备货情况。
在发货管理中,可以记录实际发货商品、发货数量及相关业务信息,方便查询订单执行进度。
对于需要管理采购和库存的企业,高级版还提供供应商、采购及库存等模块,可以将商品采购、库存变化和后续发货纳入同一套管理体系。
LiangtingsERP注重界面简洁、功能实用和操作简单,并支持独立部署,企业可以自行管理系统运行环境和业务数据。
需要说明的是,多张销售订单直接合并生成一张发货单、自动分摊发货数量,以及自动更新全部关联订单进度等能力,不能仅凭系统具有订单和发货模块就认定已经实现。
如果企业存在此类复杂的合并发货需求,应根据现有系统功能和实际业务流程进一步评估。
多笔销售订单合并发货,可以减少重复运输安排,但也会增加订单数量核对的复杂度。
尤其是不同订单包含相同产品时,如果只记录本次实际发出的商品总数量,就可能无法判断每张订单分别完成了多少交付。
因此,企业在管理合并发货时,需要同时保留实际发货批次和销售订单明细。
从订单数量、历史已发数量、本次实际发货数量到剩余待发数量,各项数据都应该具有明确的对应关系。
多笔订单可以合并运输,但每张订单的交付进度仍然需要分别管理。
只有这样,销售、仓库和财务人员才能围绕准确的订单及发货记录开展后续工作。