电商后台产品经理——订单中心

电商后台系统中，订单中心是一个枢纽部分。它涵盖了用户信息以及订单流程中的各项信息，所以订单中心的设计格外重要。在这里，我们先了解一下什么是订单以及它的基础知识。

订单中心是一个电商后台系统的枢纽，在这订单这一环节上需要读取多个模块的数据和信息进行加工处理，并流向下一环节；因此订单模块对一电商系统来说，重要性不言而喻。

同时，订单是一个公司生存甚至盈利的核心，而电商系统中的订单系统则是支撑订单处理的载体，因此订单系统的设计则十分重要。

一、订单架构

要了解订单系统，首先我们要从订单系统的信息架构上去认识订单系统，从而对订单系统建立整体认知；

二、订单状态

定义：为适应组织分工的需求和提升效率，系统将整个交易业务流程拆分成若干个可控的环节。

1. 订单正向状态待付款：用户提交订单后，尚未付款，等待用户支付，由于待付款订单会锁定库存，所以会设置超时自动取消功能。待发货：用户付款之后等待商家发货。待收货：商家以发货，等待用户收货。已完成：用户确认收货后，订单交易完成。已取消：付款之前取消订单。超时未付款或用户取消订单都会产生这种订单状态。售后中：用户在付款后发货前申请退款，或商家发货后用户申请退，换货。 2. 订单售后状态待审核：用户提交退换货申请后，等待审核的状态，在用户已付款待发货的状态下，订单尚未推送至仓库或在仓库拦截发货成功，系统可直接审核通过。当审核不通过时，回转至正常流程中。待退货入库：退货申请审核通过之后，等待用户退货入库。待退款：退货入库成功后，等待退款给用户。待换货入库：换货申请审核通过，等待用户换货入库。换货出库中: 换货入库之后，生成换货出库单，订单出库。售后成功：当退货，退款成功之后，流转至售后成功状态，退货，退款的售后成功在主流程下属于交易关闭。 3. 订单下单流程图

1.在订单过程中进行安全校验，主要是为了检测用户是否在黑名单上，用户购买行为是否正常等，当检测到不正常时终止下单；

2.从商品中心获取商品信息（SKU，规格，价格等）

3.从营销中心获取商品，订单促销信息（优惠券,促销活动）,判断是否满足优惠条件，计算出优惠金额。

4.在会员中心获取会员权益，例如平台抵扣积分，优惠券折扣条件等。

5.在调度中心检验销售层库存，按照调度规则锁定区域库存。

6.根据拆单规则（商家，仓库，订单类型等）将订单拆分成若干个子订单，根据运费模板计算运费，根据商品金额，运费，优惠金额计算应付金额（实付款）。

三、优惠分摊

定义：是指在实际销售中将订单的优惠去分摊到每一件SKU中去结算。

订单实付金额=商品金额（SKU金额总计）+运费-总优惠金额

总优惠金额=促销活动优惠金额+优惠券优惠金额+虚拟币抵扣金额

按照商品比例分摊。

案例：

订单中有甲乙两店的商品A、B、C、D、E 包邮。商品A，D参加跨店满200减40的活动（活动1），商品B，C参加满100减10的活动（活动2）另外用户还使用了100元现金券。

订单优惠金额=40+10+100=150元.

依据优惠分摊原则：则各项的优惠金额为：

四、订单拆分

定义：为了方便订单的发货与结算，系统依据一定的规则（物流、仓库等因素）将用户订单拆分成若干个发货单。

不同店铺：在电商平台类架构下，由于商品归属权不同，涉及财务结算和物流发货的问题，需要根据店铺归属问题对订单进行拆单。例如淘宝，天猫的商品在下单时会将订单根据不同店铺进行拆分成若干个子订单。

不同仓库：若同一订单分散在不同仓库，则应按照仓库归属进行拆分订单。当一件商品在多个仓库有货时，应根据物流的区域的时效选择仓库进行拆单。

不同品类：由于商品的属性不同一样会产生拆单需求，例如易碎品需要特殊包装，超大物品（钢琴，座椅）需要单独包装。有些商品不能放在一起，同样需要拆单。

物流因素：不同物流公司对单个包裹的重量或体积都有特殊要求，需要根据SKU的毛重和体积来计算包裹的总重量和体积，超出物流公司限制的也需要拆单。

商品价值：根据商品价值需要拆单的主要涉及海淘和跨境的商品；国家对每笔跨境订单有单次限额，对年度跨境商品订单总金额也有限制，当单次购买金额超过限制金额时，也需要对订单进行拆单。

本期先写到这里，未完待续~，如有疑问欢迎交流哦~

本文由 @老猫丶 原创发布于人人都是产品经理。未经许可，禁止转载。

电商后台产品经理——商品中心（一）

商品中心，对于前段而言，它是承担了商品的数据，订单，营销活动的数据中心；在后端而言，商品中心则是运营者管理维护商品的地方。

商品中心，在电子商务公司一般是后台管理商品的地方。在前端而言，是商家为了展示商品信息给用户的地方，它是承担了商品的数据，订单，营销活动的数据中心。在后端而言，商品中心则是运营者管理维护商品的地方，因此从商品的上传到发货，退货，整个闭环都离不开商品中心的支撑，因此商品中心的重要性毋庸置疑。

本文将从三大模块去讲述商品中心的设计。

一、基本概念

在设计商品中心这一模块前，我们先弄清楚，电商后台常用的一些关键词，有助于我们对业务的理解。

（1）SPU：（stanrdard Product Unit，即标准化产品单元），是一组标准化的信息集合，例如：“iphone 8”就是一个SPU。

（2）SKU：（Stock Keeping Uint，即库存量单位），库存控制的最小可用单位。例如：“iphone8plus256G金色”就是一个SKU。

（3）前台类目（分类）：前台类目是为了方便用户筛选查找商品而设置的功能，运营可根据运营需求灵活调整前台类目，用户通过前台类目查找相应的商品时，自动从后台类目中检索相应的商品。

（4）后台类目：是为了方便运营者管理商品的库存，sku，商品规格属性的一个分类管理功能模块。后台类目与前台类目相互映射，后台类目一般不轻易变动。

（5）属性：商品属性是描述商品信息的一组值，通过这类值我们可以建立起对一件商品的基本认知。

属性分为关键属性，销售属性，非关键属性。关键属性属于是指能够唯一确定产品的属性，是必填项，例如手机的屏幕尺寸，型号属于关键属性。销售属性是组成SKU的特殊属性，或称为“规格属性”，例如手机的颜色，内存。非关键属性是指除了关键属性，销售属性外的其它属性，如手机的手机接口类型。非关键属性不一定是必填项，可根据运营需求设置。

二、功能架构

在了解完电商平台的基本术语之后，我们则可以根据平台自身的业务需求商品中心了，后台的基本功能大致有四类——增、改、查、删。因此我们理解该基本功能之后，对商品中心的基本功能就有了大致理解。

在理解这一点的基础上，我们需要理解我们平台的管理者和运营者对商品中心的功能需求：我们可以用简单的用例图的形式将运营人员的功能画出来，便于分析。

根据以上用例图则可以画出商品中心的信息架构图：

三、功能设计

在收集完公司的业务需求之后，我们就可以开始设计每一项功能：

3.1 发布商品

定义：发布商品是运营者在平台库中录入商品数据的基础功能，发布的商品审核通过后则可以直接在前台展示给消费者，在一些平台商家发布的商品需要经过平台的审核才能在前台显示，若需要平台审核，则在商品发布之后再商品中心则需要展示商品审核的状态，以方便运营者知晓商品审核的动态。

需要注意的是:商品的上架和发布需要注意区分，有的平台发布之后则直接展示在前台，用户直接可以在前台展示，有的平台则需要在发布商品过审后需要点击上架后才能展示在前端，这里需要根据自身的业务需求去做设计处理。

3.2 商品审核

定义：商品审核功能是保证商品质量并确保商品合规性的重要措施。审核的对象包含但商家上架的商品，平台自营的商品。审核包含商品性质的合规性，内容的规范性。审核包含商品上传的前置审核，上架后的审核。

前置审核的结果分为通过与未通过两种，审核未通过需返回不通过原因，便于商家或商品发布者修改。后置审核的结果为两种，下架和不做处理。后置审核的一般使用场景较少，本模块着重讲商品的前置审核。

商品发布提交后，商品则在平台方的商品中心展示待审核的商品：

商品审核结果有两种：一种结果是不通过，一种是通过。

审核通过时在在售商品列表，审核不通过时在待售商品列表中未通过状态之列里，审核不通过时后台商品审核人员需要输入商品审核不通过的原因，以便于商家修改。在商品审核不通过时，在该商品的详情里需记录商品的审核记录。在商品审核结束后平台应及时通知商家运营者，以根据审核结果调整。

3.3 商品下架

定义：商品下架是运营者对在售的商品进行移除的功能，在平台方若下架商家商品则需要对下架说明原因。下架的商品则需要在商品中心有单独的区域展示，若是平台的商品下架则需对此功能做权限设置，并且在点击下架时需做二次确认。

3.4 商品修改

定义：商品的修改则在商品列表中添加修改的入口，可以将常用的使用频次较高的功能在从商品修改页面中单独分离出来以保证商品运营人员管理的高效性，例如商品的价格修改，排序修改等等。

3.5 类目管理

定义：运营人员对商品类目进行维护管理的功能，主要包含新增、修改、移动、删除，查看这五大基础功能。

这里以前台类目管理为例：

原型范例：

需要说明的是：在涉及到类目的删除，移动时在该类目下没有商品挂在，否则将会影响前端商品的展示。

本文讲述了电商后台中商品中心的核心框架，下文将继续更新商品中心的相关模块，欢迎关注~

本文由 @老猫丶 原创发布于人人都是产品经理。未经许可，禁止转载。

电商后台设计：系统消息

电商后台系统中，消息系统是一个必不可少的功能模块，其核心是帮助后台人员及时了解业务消息，保障业务正常运行。本文作者以此为出发点，详细的概述了电商后台中的系统消息的设计思路，与大家分享。

后台系统是一个庞大的功能体系，及时的了解每个功能的使用状况，保障业务正常进行是每个系统的重点。通常系统内会开发大量的监控功能(可视化的报表和非可视化的报表)来对这些业务进行监控，同时通知相应的负责人以及时了解业务和服务器状况。

常见的一些监控功能，如账号异常(账号异地登录、账号多次密码输入错误)、运营通知(活动上架、活动下架)、订单异常（订单堆积、派单堆积）、服务器异常（服务器宕机、CPU过载）、脚本异常（脚本卡死、进程过多）等等。

今天带大家来设计一个系统消息通知模块，通过简单的设置，完成个性化的消息发送，并且减轻后期代码的维护工作。首先我们来看看常见消息发送功能是如何实现的以及它们的优缺点。

01 实现方式1.1 直接触发

直接触发是将消息发送的逻辑和具体的业务代码逻辑写在一起，当满足条件时，触发消息发送功能。

优点：开发简单，如果功能封装好后，代码粘过来，十分钟功能基本就能完成；消息发送比较及时，消息发送逻辑和业务逻辑在一起，满足条件就会立即触发。缺点：后期如果需要添加、编辑或删除接收人信息，就需要修改代码，维护起来比较麻烦。熟悉代码的人可能几分钟就搞定了，新人估计就得看半天代码了。

我参与过多个系统的开发，发现这么干的人还是挺多的。总结一下应该有以下几个原因：

写起来简单，因为发送逻辑一般都是封装好的，只需要粘代码，修改一下发送参数就完事一般后台业务系统比较多，使用的编程语言比较多，各语言之间相互调用需要配置基础服务，成本太大消息通知通常属于系统基础功能，产品经理基本上不会去关注，也就不会去统一规划这个功能，技术就自己随意发挥了^_^ 1.2 消息池

通过将所有消息先收集到一个消息池(如Mysql、Redis、Kafka等)中，然后再统一通过系统调度将消息发送给接收人。

优点：功能模块化，可以做到统一管理，代码的调用可以更简洁，后期维护成本可以降到最低。缺点：消息会有延迟，消息池它是一个异步发送方式，消息的生产和发送是两个相互独立的过程；需要开发配置内容页面，开发量稍微大一点，但是后期能减轻更多的维护成本，我认为是非常值得的。 02 消息池模型

系统规划的目的就是让功能结构清晰，后期维护更轻松，所以上面第一种的实现方式就不讲了，主要讨论一下消息池功能是如何实现的。先来看一下消息池功能的模型图：

上面的模型主要分四层：

消息来源: 消息来源从开发角度来说，也称为消息生产者，它主要是指消息的生成方式和位置。在庞大的后台系统中，技术架构会划分出多个业务模块，各自的的业务模块都由不同的开发人员维护，不同的业务组使用的语言也各不相同，所以在完成相同功能时，书写方式也是各不相同，这个是没有办法统一的。消息池: 主要作用是存储要发送内容信息，如消息内容，发送时间等。市面上常见的软件有Mysql、Redis、Kafka、RabbitMQ等。所以对消息数据的存储我们是可以做到统一的。消息分发：主要作用是获取待发送的消息列表，并根据已设置的接收人信息，找到具体的接收人并发送消息。技术上通常会启动相应的任务程序持续的监控消息池，当消息池中有需要发送的数据，就执行相应业务逻辑。接收人: 具体的消息接收人，接收人的接收方式有手机、邮箱或站内信。 03 功能分析

设计具体功能前先来分析一下消息通知都涉及哪些功能。

3.1 消息类型

在系统运行过程中，会涉及到许多业务功能的监控，如订单业务中，订单支付是否有未成功、订单分配是否有堆积的情况、派单功能是有堆积情况；再如运营业务中，商品运营活动已经设置上线时间，到点上线后需要及时通知运营人员上线是否成功，避免影响活动效果。

为了能够及时让维护人员了解问题，通常都对消息进行归类，如账号异常、服务器警告、数据库异常、运营通知、订单异常、脚本异常等。

3.2 紧急程度

系统中对于不同类型的消息，根据重要程度会划分出不同的级别。如系统每日报表任务，由于数据量比较大，要求并不是很高，延迟一天通常都可以接受， 所以都是晚上3 ~ 5点之间由脚本自动运行导出后放在服务器上，第二天早上8点发系统通知，再由需求人自行导出就可以了，这类消息属于一般程度；

但是对于服务器宕机这种情况，就必须立即通知负责人进行处理，以免给企业带来更多的损失，这类消息属于紧急程度。

3.3 接收方式

消息接收方式通常就三种：站内信、手机短信、邮箱。不同的接收方式作用有所不同：

站内信：站内信是系统内部功能，研发人员可以随意设置，消息内容可以写的比较详细；但是时效性比较差，取决于接收人什么时候登陆系统。邮箱：消息内容可以写的比较详细，时效性也比较差，但是邮件确实必发的功能，因为可以作为尽职调查的凭证。手机短信：短信功能一般都由第三放平台提供，所以发送内容长度有所限制，内容需要简洁，最大特点就是及时。 3.4 发送时间

对于系统中的消息，比较紧急的如订单支付异常、数据库宕机异常它们需要及时发送，还有一些不重要的，比如上面说的各种任务报表，晚上3、4点生成好后，系统也不会发送消息，一般会设置好时间，等到早上8、9点才会开始发送通知，还有一些任务需要每个几小时就得发送一次。

3.5 唯一标示

唯一标示主要用于代码开发。在测试环境和正式生产环境由于测试导致数据库ID不一致，所以开发时没有办法通过对应的ID调用消息，就需要设计一个唯一标识符供开发人员使用，一般标示符命名根据具体的业务点来命名。

3.6 消息接收人

由于员工岗位的变动，后台需要设置相应的接收人维护界面，可以自由的添加、删除多个消息接收人。

04 原型设计

系统消息基本就上面这些功能，有需要的可以自己再扩展。下面给出部分原型设计图：

功能整理：

消息设置列表：

消息表单设置页：

接收人列表：

05 使用方法

功能我们设计好了，如何在业务中使用，我简单说一下：

需要各业务平台封装消息池调用功能,并开放一个接口，用来创建具体消息内容在需要发送消息的业务里，调用上面的消息创建接口消息模块启动任务(如crontab、监听)监控消息池，如果有待发送消息，获取并组织消息内容，完成消息发送。

其中1、2两步需要在各自业务平台完成，第1步封装成公共功能，只用开发一次，第2步根据业务需要自行调用，就一行代码，是不是很简洁。剩余所有的功能都集中在消息模块，维护起来就比较方便了。

以上就是系统消息模块的设计，欢迎下方留言交流！

作者：JackLiu；个人微信公众号: 扬帆去远航（ID:Jackai_liu)

本文由 @Jack 原创发布于人人都是产品经理，未经作者许可，禁止转载。

。