电商后台产品经理——订单中心
电商后台系统中，订单中心是一个枢纽部分。它涵盖了用户信息以及订单流程中的各项信息，所以订单中心的设计格外重要。在这里，我们先了解一下什么是订单以及它的基础知识。
订单中心是一个电商后台系统的枢纽，在这订单这一环节上需要读取多个模块的数据和信息进行加工处理，并流向下一环节；因此订单模块对一电商系统来说，重要性不言而喻。
同时，订单是一个公司生存甚至盈利的核心，而电商系统中的订单系统则是支撑订单处理的载体，因此订单系统的设计则十分重要。
一、订单架构要了解订单系统，首先我们要从订单系统的信息架构上去认识订单系统，从而对订单系统建立整体认知；
二、订单状态定义：为适应组织分工的需求和提升效率，系统将整个交易业务流程拆分成若干个可控的环节。
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 类目管理定义：运营人员对商品类目进行维护管理的功能，主要包含新增、修改、移动、删除，查看这五大基础功能。
这里以前台类目管理为例：
原型范例：
需要说明的是：在涉及到类目的删除，移动时在该类目下没有商品挂在，否则将会影响前端商品的展示。
本文讲述了电商后台中商品中心的核心框架，下文将继续更新商品中心的相关模块，欢迎关注~
本文由 @老猫丶 原创发布于人人都是产品经理。未经许可，禁止转载。
