京东后台参考： https://helpcenter.jd.com/Vender/question-783.html
对电商公司来讲，最核心最难做的三部分：商品、订单、库存
商品与店铺、营销、评价等相关；订单与会员、营销、支付、库存、物流等相关；库存与订单、采购、WMS、营销等相关。
一般电商业务，产品模块示意图：
商品中心主要管理SKU(最小库存单位)、SPU（标准化产品单元）、属性（关键属性、非关键属性、销售属性）、类目品牌、价格等有关商品的数据；
订单中心管理订单类型、订单状态，落下关于商品、优惠、用户、收货信息、支付信息等一系列的订单实时数据，进行库存更新、订单下发等一系列动作；
支付中心主要调用第三方支付平台接口，记录支付信息（对应订单号、支付金额等）；
会员中心主要管理用户等级、用户权益、积分、卡券等会员相关信息；调度中心主要将订单信息转化为发货通知单，调度仓库和物流进行发货；
客服中心主要管理退货退款、售后服务等操作，包括呼叫中心、在线客服等，与之对应的是工单系统，将客服任务进行队列管理，分配给相应的客服；
营销中心主要管理活动相关，优惠券、满减、专场活动、促销专区等，营销工具的开发对电商尤其重要，营销活动的滥用造成的用户疲劳，怎样推陈出新，给电商产品经理造成了很大挑战；
运营中心主要是对用户端进行页面配置（Banner、ICON、TAB）、价格管理等，一般会营销中心并入运营，作为其一部分；
评价中心管理商品评价和用户反馈，这并没有想象的那么简单，涉及到一些敏感词和敏感图片的筛选，以及回复内容管理；
店铺管理功能庞杂，相当于提供给B端用户一个Saas管理后台，提供管理商品、营销、订单一系列功能，主要针对一些有to B业务的电商开放平台；
采购中心管理SKU，当库存预警时，及时生成采购单进行入库，有供应商管理模块，主要进行供应商管理评级，发展新供应商等功能；
财务管理主要和订单、采购系统相关，数据准确性要求较高；
WMS系统（仓库管理系统）主要是入库、出库、盘点等模块，WMS主要和调度中心进行数据交互，反馈出入库状态和库存变动；
物流中心主要进行运费模板、运费管理（前端订单、真实物流成本）、物流状态保存查询（快递100、菜鸟等关联），如果是跨境电商，还涉及到和海关总署的对接，进行报关操作。
风控中心主要利用大数据进行用户信用建设、反欺诈，避免恶意评价、刷单退款等操作，构建安全的电商购物环境。
以客户下订单为例来介绍业务信息在各系统之间的流转，涉及主要的信息交互如下图所示。从用户选择商品、生成订单到订单出库、物流配送、用户签收、退货退款，信息在多系统中流转更新数据。
简单粗暴的讲，商品中心是用来管理核心的商品数据。对于使用的维度：从前端来讲，是给商品展示、订单、营销活动提供商品数据支撑，从后端来讲，商品中心给订单发货、仓库管理、供应商管理、采购提供基础数据支撑
一.商品常用概念介绍
SKU：stock keeping uint(库存量单位)，库存控制的最小可用单位。例如Iphone 7plus 128G 银色就是一个SKU，仓库管理、采购进货、库存显示的都是SKU。不同的公司都有自己的SKU编码规则，如果有自己的仓库，在商品入库时一般会打上自己的SKU码，这样整一套库存体系就会自上而下打通。
SPU：standard product unit(标准化产品单元)，是一组标准化信息的集合，例如Iphone 7plus就是一个SPU。SPU与SKU的关系有许多种，可以一对多，一对一，如下图所示。SPU信息中应该包含SPU属性、产品图片、产品描述、产品标签。SPU和SKU之间是通过规格来链接的。SPU(Iphone 7plus)通过颜色、内容关联到SKU(Iphone 7plus 128G 银色)。SPU的库存是由其对应的SKU库存共同决定的。
属性：分为关键属性、销售属性、非关键属性。关键属性是指能够唯一确定产品的属性，是必填项。例如手机的品牌、型号属于关键属性；销售属性组成SKU的特殊属性，如手机的"颜色"、"内存"；非关键属性指的是除关键属性、销售属性外的其他属性，如手机的手机接口类型。
类目：分类树，电商常用的有两层类目，前台展示类目，后端商品类目。前台类目指的是展示给消费者的类目，会根据季节、销售策略、活动进行变动；后台类目属于基础数据，不可随意变动，添加SKU时都需要选择类目，进行绑定。需要注意的是，类目树的层次不能太深，一般三层或四层，如果太深，不论对于管理还是技术性能来说，都是不利的。
商品模型变迁：
A.分类-->商品-->品牌
B.
一个分类对应若干属性，而一个属性，对应若干属性选项，而一个具体商品又对应若干属性选项（例如具体一条牛仔裤，他的裤长：7分，裤型：直筒）。
属性为什么要放到分类下面呢？如果把衣服和手机都看做一个分类的话，它们都有颜色属性，但是它们所有的具体颜色有不太相同，比如衣服的颜色种类会比较丰富而手机的颜色可能就黑白蓝等简单的几种颜色。这样做确实是增加了数据库的冗余，但是对在后台添加SKU带来了查询上的方便，提高了用户体验。
C.“颜色”和“尺寸”
不同规格的货品作为独立的商品。比如一条裤子的有L尺寸、M尺寸、一个U盘有16G还是32G的，都是同样的货品，不同规格的商品。可以认为货品和商品是一对多的关系。
“颜色”、“尺寸”我们就作为“规格”来处理，而红色、黑色；L号、M号我们视为规格的选项或者说规格值。一件货品对应若干规格，而具有某一规格值的货品就是商品。
“货品”是指一种概念物品，这种物品并不是一个具体的实物，当它具备具体的属性、价格时，才是一种实物，也就是商品。
规格参数==sku(销售属性)
二.商品基础资料设计
在添加SKU时，需要选择品牌、填写一些属性，以及关于仓库管理的基础数据（长宽高、重量、供应商等）。商品中心基础资料结构图主要如下，首先是品类管理，主要包括品牌管理(中英文名、可供品类、产地（跨境电商比较重要）)、属性管理（针对类目添加相关属性和属性值）、类目管理（后端类目树重中之重，确定时要考虑全面，属于基础数据，后续更改比较麻烦。），大致产品框架如图所示。
在添加SKU时，通过供应商去关联采购，进而影响仓库中SKU的库存。供应商在添加SKU时亦可不选择，可以在采购系统中添加关联。通过销售属性去关联SPU与SKU，同一SPU在前台显示时可以共用同一商品详情，只是通过规格属性映射到具体的SKU；
还有一个比较特殊的概念：组合SKU，主要是解决出售组合商品的问题，组合SKU的属性都继承主SKU。组合SKU的应用场景主要是添加赠品、组合售卖，与前台的商品套餐有所区别。在订单解析成发货单时，组合SKU需解析成单一SKU，方便仓库发货，更新库存。
电商产品设计：优惠券的设计和妙用
优惠券有多种分类方式，按照使用门槛、使用范围、发放主体等有不同的分类。
1.1 按照使用门槛分为现金券、满减券、折扣券。
现金券：不限制订单金额，可以直接使用。
满减券：订单金额需要满足一定的最低额度才可使用，例如：满100减10元优惠券。
1.2 按照适用范围分为：单品券、品类券、品牌券。
单品券：购买优惠券指定商品时可使用，这种优惠券一般只针对少量特殊商品可以使用。
品类券：购买优惠券指定类别的商品即可使用，除个别特殊商品。
品牌券：购买优惠券指定品牌的商品时可使用，除个别特殊商品。
一般按照品牌或者品类设置优惠券范围是比较常见的方式。
1.3 按照发放的主体分为平台优惠券和店铺优惠券
平台优惠券：优惠由平台承担，比如平台活动优惠券、平台注册的新人优惠券、平台积分兑换的优惠券。
店铺优惠券：在平台上的店铺自己发放的优惠券，比如淘宝上的店铺优惠券、京东的店铺优惠券。
平台优惠券的金额由平台承担，在店铺使用时优惠金额由平台返给店铺；店铺优惠券的成本由店铺自己承担。
优惠券周期：
生成优惠券
在生成优惠券时，主要是从优惠券信息和推广信息两方面来考虑优惠券的设计。
2.1.1 优惠券信息
优惠券名称
类型：现金券、满减券、折扣券
面值：例如10元。
使用条件：满XX元可用
使用平台：客户端、H5商城、主站、各分销渠道
有效期时间：绝对时间（时间段）、相对时间（领取之日后多少天有效）
发行量：优惠券张数（设置限额）
使用范围：平台券（全平台通用）、店铺券（仅在某店铺可用）
商品范围：全品类、限制品类、限制商品
2.1.2 推广信息
发放方式：可发放可领取、仅可发放(只能由平台发放给用户)、仅可领取（只能用户自己领取或兑换）
推广范围：免费领取、积分兑换
优惠券是否公开：设置公开后，在领券专区、商品详情页、购物车都默认展示
限领：每人仅限一张、每人每天限领一张
券领取时间：设置领取时间段（过期）
在优惠券生成之后，将优惠券显示在优惠券列表中。
发送优惠券
优惠券有主动领取和被动领取两种方式。
主动领取：
用户在店铺首页或者平台上看到优惠券，主动进行领取；用户在线下看到宣传推广；朋友圈优惠券分享链接等等。
这种发放方式需要一定的运营成本，需要打动用户，产生兴趣进行主动领取，这种方式需要做好防作弊机制，真正获取到的用户价值较高。
被动领取：
系统主动给用户发送相应的优惠券，但是这种大面积分发的方式，用户精准度低，转化率较低，只能很少促进客单量。
系统发放优惠券场景有很多种：1.用户注册；2.大促活动；3.还有客服发券，主要是售后补偿（平台责任导致售后，发券补偿客户），或者好评返现。
除了以上的方式，还有许多平台电商的一项业务：大客户团购，主要是给一些单位提供的福利卡，例如京东卡。可以通过优惠券（平台币）的形式实现，生成相应的卡密（或兑换码），制作实物卡售卖给一些公司发福利、送礼。用户输入卡密兑换之后，兑换成平台的交易币（相当于给购物卡充值），可以用来抵扣订单金额。
发送优惠券虽然在前端页面只是简单的一个交互，但是后端有大量的逻辑需要处理。
校验用户登录状态 → 优惠券信息读取（是否在有效期、是否可发放、剩余数量） → 优惠券绑定用户
优惠券核销
在用户下单时，肯定是需要系统从其账户中的优惠券选择合适的优惠券推荐给其使用的。我思考的推荐算法应该分三步：
a.从用户优惠券列表中选择出当前订单可用的优惠券（包括通用券和相应产品优惠券），主要是从有效期、商品范围等条件判断
b.若有多种可用优惠券，但是金额不同，默认选择可抵扣最高的优惠券。
c.如果金额相同，先匹配同类优惠券的优惠券，但当优惠券的额度（现金券）大于支付额度弹出提醒框，确认是否使用。
注：在用户的优惠券列表中，优惠券是否失效也是实时拉取的（失效过长应清除此优惠券），下单时优惠券选择应仅显示用户可用优惠券。
优惠券统计
主要统计优惠券的发送张数、使用张数。深度数据挖掘可以统计优惠券对应的客单价、复购率等等。
优惠券的前端展示
优惠券的前端露出窗口主要有五处：用户优惠券列表、订单提交页、购物车、商品详情页、领券中心（或优惠券分享链接）。
前端展示的难点在于商品详情页和购物车中展示可用优惠券。需要高效率的算法来计算匹配商品对应的优惠券，主要有两点好处：1.优惠券来促进用户消费；2.在用户消费时帮助用户省钱。告知用户有优惠可以享受，避免用户下单之后看到相关优惠没有享受到产生不平衡心理。
优惠券在订单中的处理
下单时优惠券的匹配在前面已经叙述过，主要是分为三步，详见2.3优惠券的核销。本节重点讲解优惠券的逆向流程。
在订单完成售后（退款或退货）时，优惠券应有一定的返还机制。
统一设置成不可返还，用了之后就不退。
订单中全部退款时，优惠券全部退还。
订单中部分退款时，普通优惠券不返还，现金券按金额比例退还。
优惠券有着一套很成熟的产品设计方案，介绍之后，再提一个目前绝大部门产品难以解决的问题：基于日常优惠券的使用情况，运营人员如何平衡发放优惠券所带来的成本增长，商品销量增长和单品毛利下降之间的矛盾？在申请促销活动经费时，怎样的数据更具说服力？
电商产品设计：促销活动解析
促销有7种：满减促销、单品促销、套装促销、赠品促销、满赠促销、多买优惠促销、定金促销。
满减促销： 购物者只要购买相应商品到规定价格即可得到一定的减价优惠。主要有两种形式：阶梯满减、每满减。阶梯满减，例：满100减10、满300减50、满500减80；每满减，例：设置每满200减20，则订单金额230元实付210元，订单金额430元实付390元。
单品促销：在特定时间内购买指定商品享受一定的价格优惠。例：促销期间商品6折，原价100元，购买时60元。
套装促销：商品组合套装以优惠价出售，例如：A商品50元，B商品80元，A+B商品套装促销价100元。
赠品促销：购买主商品之后赠送商品（可多个）。
满赠促销：有满XX元送XX商品、满满XX元加价XX元送XX商品，与赠品促销的区别在于以相应商品订单的价格来区分，可分阶设置，例如满300元送自拍杆，满500送充电宝，满1000送高端耳机等。
多买优惠促销：有M元任选N件、M件N折两种优惠形式。这个主要是参考一些线下卖场发展的促销形式。
定金促销：在商品正式售卖之前采用预付定金的促销模式，提前交定金可享受优惠价。定金预售有多种玩法：定金预购，相当于定金就已经确认订单；定金杠杆，例如定金10元可抵扣30元。
促销的后台设计
主要分为活动条件、主商品信息、赠品信息（有些无赠品）这三部分。
活动条件
主要包括促销活动名称、促销时间、限购数量、促销范围（全网、APP /微信商城）、会员级别（全员 or 新注册用户 or 某等级会员）、活动备注、活动规则。
活动规则即最核心的设置，例如：满800元减60，3件150元。
主商品信息
选择参加活动的商品，可按SPU、分类、品牌等来选择参加促销的商品。
除此之外，还要判断当前所选商品是否参与其他促销活动，与此活动由冲突。例如A商品参加4月的活动，满400元减20元；再次设置该商品参加满400减50的活动，就应与该商品已参加活动冲突，不可设置。
赠品信息
选择参加活动的赠品，赠品一般有数量限制。有两种规则，赠品全送，或在多赠品中选择几件。为减少系统复杂度，减少用户理解难度，建议采用赠品全送的规则。
另外对于满赠促销的形式，若要设置分级赠品（满300元送自拍杆，满500送充电宝，满1000送高端耳机），就需要对赠品分开进行设置。
对于后台产品来讲，重点在于设置规则之后在商品详情页、购物车的促销信息展示以及订单页面的促销活动判断逻辑。
电商后台产品设计：订单拆单
拆单也有两个层次，第一次是在提交订单后支付之前拆单，这次是拆分的订单，一次是在下单之后，发货之前，去拆分发货单（SKU层面）。
两次拆单的原则不同，第一次拆单是为了区分平台商家、方便财务结算，第二次拆单是为了按照最后的发货包裹进行拆单，如不同仓库、不同运输要求的SKU、包裹重量体积限制等因素（第二次拆单的有些步骤可以放在第一步）。
需要注意的是，若是跨境商品平台，则需要在支付前完成所有拆单步骤，因为报关需要三单对碰，订单、支付单、运单统一。
为什么要拆单
拆单，顾名思义就是客户在下单之后，为了发货和结算方便，需要对订单进行拆分。
影响拆单的因素主要有以下几点：
l 店铺商家。由于商品归属权不同，涉及到财务结算和发货的问题，店铺商家不同，需要拆分订单。例如京东自营和平台商家的商品在下单时会拆分成不同的子订单，售后入口不同。或者不同淘宝店同时下单会按照店铺进行拆单。
l 仓库。由于发货仓库不同，按照商品归属的仓库进行拆单，若有多仓有货，还应按照地域时效选择仓库进行拆单。
l 品类。由于商品属性和价值得不同，同样会产生拆单需求。例如易碎品需要特殊包装，超大物品（儿童座椅、轮胎）需要单独包装。甚至有些品类不同的商品不能放在一起，都需要来定义拆单规则。
l 物流因素。不同物流公司对单个包裹的重量或体积都有特殊要求，需要根据sku的毛重和体积计算包裹总重量和体积，超出物流公司限制的也需要拆单。
l 商品价值。这块的拆单主要是跨境海淘商品，国家政策规定：跨境电子商务零售进口商品的单次交易限值为人民币2000元，个人年度交易限值为人民币2万元。当单次购买超过2000元（单仓）之后，就需要对订单拆单。（总不能告诉用户少买点，不要超过两千吧！）
拆单流程
根据拆单的一些影响因素，需要对订单进行拆分。由于跨境电商和国内电商的区别点：
1.跨境电商一般是单品单仓，同一个SKU只在一个仓库有，而国内电商一般有多个区域仓，从时效最高的仓库发货；
2.跨境电商需要报关，必须三单统一，所以拆单只能发生在下单后、支付前，而国内电商除了平台商家不同需要在下单时就拆单，其他的拆单步骤可在下单之后再拆发货单；
3.报关限额，只有跨境电商需要考虑。
下图简单解析一下拆单的流程
拆单之后的前端显示
在提交订单之后、支付之前的拆单订单，需要即时显示给用户，若用户中断支付，再回到支付环节，就需要分开支付。用户就能知道，是不同的包裹发过来的，分属不同的子订单。
在支付之后，系统根据一些影响因素进行拆单，同一个子订单可能会对应多个物流单，在订单显示页面查看物流时，需要展示多个物流信息。但是现在多个平台只能一个订单对应一个物流单。有些订单无法通过一个包裹就能发货，在信息反馈给客户上就会有些瑕疵。
关于支付单，虽然基本所有平台都会通过合并支付的方式简化支付环节，但是不同的子订单都是可以拿到不同的支付单号的，这样就有利于售后和财务管理，对于跨境商品，还有报关的作用。
小结
拆单的系统比较复杂，要做的完全彻底，对大部分电商公司有很大的困难，这需要打通从订单系统到WMS系统的许多环节，所以需要在产品设计上进行取舍，根据平台的具体需求来确定拆单需求的优先级。
购物车的产品逻辑与妙用
购物车的妙用
购物车在实际使用中对用户来说，兼具着凑单、促销、收藏的功能。
1.1 凑单
在用户浏览详情页的时候，有两种选项：一种是立即购买，另一种是加入购物车。当用户本身需求较多，想一次购买多种商品，或者参与到优惠活动中（满减、满赠等），这时候会加入购物车进行凑单。
1.2 促销
购物车还有促销方面的功能，用于提高客单价。当有促销活动（满减、满赠）时，用户加入购物车之后，可以查看是否满足优惠条件，优惠之后的金额（不包含优惠券）。
1.3 收藏
对于大部分用户来说，购物车发挥更多的是收藏的作用：看着不错，等以后再下单。另外还有筛选的作用。譬如我网购时，会先加入购物车收藏，后面有时间在购物车中筛选之后购买。
购物车的设计
2.1 通用显示
购物车在展示时，基本的展示信息主要有：商品标题、商品图片、价格、数量、规格（颜色、尺码等）、商家（自营或店铺）、库存状态（库存紧张/缺货）等。如果是跨境商品，还需要显示税费。购物车中的商品信息在初次打开 （APP或web首次进入）或刷新时，商品信息、促销信息都同步更新。
购物车的选中策略有三种：打开是默认全选、默认全不选、云端同步选中状态（不同设备打开时继承上次选中记录）。
用户的购物车数据需要记录在数据库中，保证APP端和web端同步，下次登录后不会丢失。
2.2 离线购物车
离线购物车指的是用户在未登录状态下加入购物车，一般通过创建虚拟用户实现 。为了更好的用户体验，需要让用户在下单之前，允许未登录先将商品加入购物车。
用户登录之后，涉及到离线购物车和在线购物车合并，首先判断当前是否有离线购物车，然后将离线购物车的数据和在线购物车数据进行合并。
2.3 库存监控
由于商品库存会发生变动，为了提醒用户，也是为了促单，在库存紧张或无货的时候，会在前端给予提示。购物车更新时，去查询对应的商品库存，判断当前商品的数量，当大于0小于提醒值时，提醒用户库存不足，请尽快下单，当等于0时，提醒无货，当商品下架后，提示商品无效。
无效商品进入无效商品列表中，可批量清除。
2.4 排序分类
商品在购物车中显示有几个纬度：1.商家店铺，将店铺不同的商品分开；2.优惠不同，在购物车中将优惠活动相同的商品聚合在一起；3.加入时间，按照加入购物车的时间倒序排列，最近添加的商品排列在前。
2.4 促销信息
购物车中显示促销相关信息，类似满减、满赠、赠品信息。例如在购物车中显示满500减100，全场满减，商品的赠品有哪些。还可以引导客户去店铺领取优惠券。在购物车中展示促销信息对提高客单价有良好效果，目前最好用的购物车非京东莫属。
2.5 商品推荐
在购物车底部，是最好的商品宣传位，可以添加为商品推荐区域。至于商品推荐的内容，会根据用户数据做定向推荐，这里不做扩展。
2.6 价格监控
购物车的商品价格变动时给用户提示，譬如降价20元，会对用户的消费决策产生影响。
2.7 编辑
编辑购物车时主要可以进行的操作：删除商品、加减商品数量、更改商品规格等。
购物车的结算
在购物车选中商品时，会实时算出订单金额。在购物车中计算时，需要将优惠金额算进去，但是这部分优惠只包括满减的部分。例如商品订单1000元，但是满800减200，那购物车中显示的订单金额为800，优惠200。若是跨境商品，则需要考虑税费。
在购物车中未将优惠券的优惠金额算入，主要是因为实际场景中有多优惠券满足订单的情况，用户可根据需要自由选择相应的优惠券。
这里有个优化点，可以提示使用优惠券最多可优惠多少元。
