跨境电商场景下，订单正向流程产品该怎么设计？

在跨境电商业务场景下，订单的产生是常见的环节之一，那么在这一场景下，订单模块该如何搭建相应的设计策略？过程中又有哪些细节事项需要注意？一起来看看作者的分析和解答。

一旦发生交易，就会产生订单。在所有涉及到订单的系统中，订单模块往往是最核心的部分。本文以跨境电商为业务背景，讲解一下订单模块的产品设计。

一、订单下载

对于跨境卖家而言，对于订单下载肯定不陌生，也就是常说的“抓单”，将第三方平台的订单同步到自己系统。抓单需要考虑2个问题。

1. 抓什么状态的订单？
2. 抓多长时间的订单？

订单有未付款、已付款、已发货、签收、退款等等状态。以海运为例，如果是直发，走海运从国内发货到美国签收，可能需要40-50天。这样就意味着订单状态从发货到签收，也需要40-50天。假设公司每天到美国有5W单，那么到了50天后就会有250万单，为了同步状态，难道每天去遍历几百万条数据？

所以有一种处理方式就是只会同步几个状态，最常见就是同步未付款、已付款、已发货3个状态。只要发货，在卖家端的操作就已经完结了。后续客户的售后操作，就会形成新的售后订单，按照依旧按照上述逻辑去同步状态。

二、订单预占

成功抓单后，订单就预占中央库存的库存。

中央库存不是一个系统，甚至页面都没有。理解理解中央库存是一个调度模块。抓单后，订单通过调度系统指派那个仓库发货出库。

最简单的中央库存模型就是公司有N个仓库，这N各仓库的库存统一起来就是一个中央库存。此时对中央库存的预占只是增加了中央库存的锁定层，仓库的实物层并没有受影响。

三、拆合单策略

1. 合单

合单的本质就是为了减少履约成本，最直观的就是体现在运费上。用户下了3个订单，公司一次性给用户发了，就节省了2次的运费。

最常见的合单规则就是同一个客户，在同一个店铺，收货地址相同的订单合并。

按理来说不同的店铺的订单应该也可以合并。因为第三方平台有防关联政策，如果一个卖家注册多个账号在平台卖货。系统检测到的话就会封号，所以合单一般都不回跨店铺。

订单的合并条件还有更多，如下图所示：

合单功能比较简单，重点是合单后的处理。

如果2个订单合单了，且2个订单已经匹配了仓库，合并后根据“就近就全”原则，是否需要重新匹配仓库？

如果2个订单手动合单了，且2个订单已经匹配了物流，合单后是否需要根据“匹配物流”策略，重新匹配物流？

2. 拆单

上面说了合并是为了减少履约成本，拆单就是增加了履约成本，那么为什么还需要拆单呢？因为在实际的工作场景中有很多不得不拆单的情况。常见的拆单策略有：

• 用户部分退款，剩余部分优先发货；
• 订单货品缺货，将缺货部分拆出；
• 多个仓库发货，按照不同仓库拆分；
• 按照商品体积拆分；
• 按照商品属性拆分；
• ……

拆分的订单也需要考虑是否需要重新寻仓和匹配物流。

一些人搞不懂ERP拆单和仓库拆包之间的关系，拆单可以理解为将销售单拆分成N个，拆包理解为将销售单拆分为多个包裹（包括也可以理解为运单）。

小结：

订单的拆单和合单需要考虑订单的成本、销售额、优惠等金额的计算，还需要考虑赠品。这一块的计算规则稍微复杂一点，我放在营销模块去讲。

需要注意的是自动拆单合单策略需要放在寻仓、分配物流这些策略前面，因为拆单和合单需要重新寻仓和分配物流。

四、寻仓

寻仓就是系统找到最合适的仓库，所以寻仓的核心逻辑就一句话：“就近就全”原则。

找到距离用户最近的仓库，且仓库当前的可用库存可以满足订单。这里就引申了一个问题，寻仓，寻哪些仓库？比如用户的收货地址是美国，寻欧洲的仓显然就不合理，所以寻哪些仓库也就需要根据用户的收货地址做配置。

如果公司有成品仓库和半成品仓库，用户下单购买了半成品，那么寻成品仓显然不合理，所以寻仓也需要根据用户中商品的属性进行配置。

结合以上的描述，那么我们可以把寻仓功能做成策略，进行配置，如下图所示（仅供参考）：

看到一个友商的产品设计，非常类似，就截图过来了。从上图可以看出，首先配置一些“满足条件”，这些条件有收获地址，货品分类等等，满足条件后去执行指定的仓库，仓库可以配置多个。

“就全”怎么理解呢？就是一个订单尽量由一个仓库发货，避免多个仓库发货吧订单拆分成多个包裹。试想一下用户下单，结果一个订单收到了5-8个包裹，体验非常不好，而且公司要付出的运费也高。

但是这里有一种特殊情况，举个栗子说明。如：用户下单，收货地址为深圳，系统检索了整个华南地区的仓库，没有一个仓库可以完全满足。但是在西藏的一个仓库可以满足订单，那么此时应该是华南地区的多个仓库

那么是在华南地区拆分成多个包裹发货，还是在西藏发货，这个就要看公司策略了。

五、仓库预占

当寻仓完成之后，就预占仓库的库存，将中央库存预占的库存下推给仓库，逻辑如下图所示：

六、分配物流

分配物流就是给订单匹配一个发货方式用于发货，分配物流的核心逻辑与寻仓一致，也是一个句话：“选择满足发货方式中最便宜的物流”。

作为跨境卖家，通常会对接很多物流公司。作为卖家出于节省成本的考虑，肯定会选择满足订单履约，且最便宜的物流。

具体的物流模块的产品设计我就不赘述了，内容太多。感兴趣可以去看我之前写的文章《ERP-物流模块设计》。

七、订单审核

订单审核的页面如下（仅供参考）：

审单就是人工在对订单进行确认，因为在实际的工作情况中有非常多的特殊情况，如：用户修改地址，用户的一些特殊备注等等。

在审核页面也可以手动对订单进行拆分、合单、改物流、改备注等操作。

在审核通过之后，订单就会下推到WMS系统，仓库进行拣货出库。但是在根据不同的业务发货方式也不同，常见的有3种发货方式，如下：

• 仓库发货：订单下推到自己公司仓库，仓库拣货出库。
• 虚拟发货：订单是虚拟产品，人工标记发货。
• 代销发货：将下单下推给供应商或者合作方，由他们发货。

竟然有审核操作，那么也有审单策略。如果每天5W单，审单就2个人，那么每天的工作怎么做都做不完。所以就需要做一个自动审单的策略，将一些常规的订单自动审核通过，一些不常规的订单拦截由人工审核。

自动审单策略的界面如下（仅供参考）：

八、自动拦截策略

设置一些规则，将满足规则的订单标记为异常订单，这里先说一下WMS的异常单，因为WMS的异常单与ERP的异常单会有关联。

在WMS常见的异常原因有：缺货、收货地址变更、退款、部分退款、物流方式变更、取消发货、备注变更、发货超时、打包时错货/少货/次品等等

不同的异常原因后续的处理流程不同。

订单退款和取消发货，订单就已经结束了发货流程。

部分取消发货，通常是将订单打回上游系统，上游系统拆单后重新下推到仓库。

其它的异常原因，本质就是订单进行挂起，订单不会进入下一个环节。

那么在ERP的异常订单也是同理，设置一些策略，订单满足策略就标记异常。异常策略如下（仅供参考）：

这里只需要主要一个点，如果ERP的订单下推到了WMS，在ERP标记异常的订单，相应WMS的订单是否也需要标记异常？在WMS标记异常，相应ERP的订单是否需要标记异常？

如果在WMS标记的异常订单，相应ERP的订单也标记异常，那么在ERP是否可以手动解除异常？

总结

以上就是整篇文章的内容，希望能够对你有所帮助。