Java工程师知识树

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

原型范例：

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

Java工程师知识树

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

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

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

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

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. 待付款取消订单

说明：待付款订单取消订单分为两种情况：

在待付款订单状态下，取消订单无需客服审核。流程图如下：

2. 待发货取消订单

说明：在待发货订单状态下取消订单时，此时应根据订单此时所在的节点作出处理。

由于订单在支付完成后，发货单可能已经推送至WMS，甚至已经交接发货，状态未及时回传更新。为避免货款两失，要先暂停订单出库，在调度中心查询订单是否推送至仓库。

若尚未推送至仓库，则停止推送至仓库；若已经推送至仓库，则去wms中心去拦截，拦截成功则暂停出库。

3. 待收货/交易成功退货

说明：在用户提交退货申请后，需经过客服审核。审核通过则回到原有状态，审核通过后则进入退货流程并告知用户退回地址及收件信息，此时进入退货流程。系统生成退货入库单，当仓库收货后，进行退款。

在待收货状态下平台设计者仍需考虑退货是否全退的问题。当SKU全退时，原订单则中止进入交易关闭状态。当订单中发生部分退货时，原订单的状态不变，维持待收货或交易成功状态，同时退货的部分生成交易售后订单。剩余未退货部分仍然允许申请售后。

注意：在订单流程逆向流程中，涉及到财务数据的处理时 ，为了保证财务数据的真实性及可追溯性（这与会计数据的处理原则有关，具体问下会计或者财务同学），都不能直接在原订单状态下修改，因此在设计订单逆向流程时应注意这一点。

---