订单管理记录了所有的交易数据，在后台系统设计工作中是非常重要的一环。
订单管理是后台系统中较为重要的一部分，它记录了所有的交易数据，可以对订单进行监控和操作，与用户、运营、财务等都有着密切的关系。以下就来总结一下后台系统中订单管理的设计。
一般来说，订单管理后台的操作用户都是公司内部人员，但需要支持的实际上还有C端用户的需求。所以在设计时，订单管理系统需要包括两部分的内容：
一是要能够与C端用户在整个订单流程中各个场景的操作相对应；
另一个是要能满足公司内部相关部门的需求，包括财务、采购、运营等。
一、订单流程
首先，在设计后台前，需要明确的就是C端用户的操作场景以及在该场景中后台需要支持的操作。如下图所示，是一个简单的订单运转流程：
当然，在实际业务中，订单流程远没这么简单。比如在用户结算付款/取消订单/退款/退货流程中，可能还会涉及到满减、满赠、优惠券、打折、积分抵扣等情况，这种订单金额不仅仅只包含了商品金额，一般来说，订单金额=商品金额+运费-优惠-积分抵扣等。
所以，在用户结算时，就会涉及到不同模块和数据的交互（一般来说，满减满赠或者运营活动相关的数据，都是有单独的表记录的），反之，取消订单/退款/退货也是如此。
二、订单状态
明确了订单流程之后，就可以知道从订单创建到交易完成这整个过程中所包含的状态。
从上图可知，整个流程可分为未付款、已付款待发货、已发货和已收货四个阶段。而涉及到的模块主要有支付和库存。以下就来介绍一下订单在各个阶段所涉及到的内容：
三、订单列表设计
上面概述了订单运转流程及主要状态，那么，现在就来说一下订单列表的设计。
首先，列表即是数据的展现。而数据的展现又来自于实际的需求，除了上述所说的状态及操作外。还有一个重要因素就是订单信息，信息的详细与否直接关系到订单的跟踪以及后续数据的分析。对于整个系统来说，数据是极为重要的部分吗，所以在设计字段信息时，需要尽可能的全面。
1. 从内容上来说，订单的信息主要包括商品信息、支付信息、物流信息等，如下图所示：
补充：在实际公司业务中，可能还会涉及到向经销商直接供货的情况，可能是线上，也可能是线下，但即使是线下，订单也是需要进入到系统的，因此在设计时，需要实现了解业务操作的细节；如果是线下订单，需要考虑订单的创建人可能会是哪些角色，不同角色创建的订单流程也会有所不同。
2. 从结构上来说，订单页面其实也就是个列表页，主要包括搜索区、列表区和操作区。
1)搜索区域
在订单列表中，因为涉及到的信息和状态比较多，所以为了提高工作效率，需要将常用的重要的条件作为筛选项，以便于快速查找。
一般情况下，搜索区域主要包括：订单编号、订单状态、付款状态、退款状态、交易时间、支付渠道、平台、区域等，根据业务范围而定，当然，显示哪些条件，还要看权限等级。
2)列表区域
前面已经介绍了订单详情，包含的信息较多，所以后台列表中不可能直接显示订单相关的所有字段，此时就需要有所取舍，选择比较重要的字段比如订单编号、支付流水号、订单状态、退款状态等信息。而剩余的其他信息，可以通过下级页面或自定义菜单来显示。
这里需要特别注意的就是订单的状态和操作，在设计前，需要对业务流程相当熟悉，明确场景中的每种状态以及各状态下的操作权限。
3)操作区域
对于订单的操作，基本上就是一些确认、审核、锁单、跟进、退款等。
四、其他因素
1. 订单是否需要拆分：比如OTA中的订单系统，一张订单可能会被拆分为酒店子订单和各种单项子订单，而这些子订单有可能是由不同的人去处理，而且有的时候是需要支持客服人员可以在订单中继续增加子订单的，电商平台也一样，通常都会包含一个主订单号和多个子订单号，这时就需要考虑在退货/退款时是否支持根据子订单的维度退款；
2. 订单的取消：除了用户，内部人员在哪些情况下可以主动取消订单，而该种情况下取消订单，流程该如何操作，又该给用户怎样的反馈；
3. 产品/商品来源：在用户下单前，是否已有库存，当然，在一般的电商系统中，基本上都是已经有库存才可以售卖的，但比如在OTA这样的订单系统中，产品即服务，是具有不确定性的，所以在生成订单的时候，同时要根据其子订单生成对应的供应商订单，用户下单后，企业再去向供应商下单预订，其实就比较类似于代售的情况；
4. 订单生成规则：一般情况下，商品的来源和渠道各不相同，很多时候为了便于区分，可能就需要在订单的生成规则里加入一些特殊的字符进行标识；
5. 活动订单：当平台在做活动时，商品的价格一般都会出现大的波动，那么就需要考虑此时下的订单是否需要单独管理；
6. 订单数据问题：在实际运转中，可能还会出现不同表的订单时间不一致、数据延时、订单重复、漏单等情况，这些都需要引起重视，及时优化程序；
7. 权限问题：不同部门、不同级别的账号，会拥有不同的数据权限和操作权限。
版权声明：版权归原作者所有，如有侵权请联系我们予以删除！转载只为传递更多网络信息。
