后台系统：订单管理.pdfVIP

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