归档

电商设计

指导思想

人钱物

功能架构

方案

• 自提
  所有涉及到自提的，都采用提货码模式
• 二维码扫描
  所有涉及到钱的(如优惠券，支付码)，都采用定期(如一分钟)自动失效的凭证机制
• 图库
  可用于商品，活动等。支持2级分类。回收站15天内自动删除
• 定时任务
  如商品定时上下架

交易(Trade)

业务

一个订单对应一个付款单，多个退款单，多个运单(包裹)
一个付款单多个明细，一个退款单多个明细
退换货流程和加单，退单，改单
购买的虚拟商品没有独立的列表显示，如我购买的券列表。是依附于订单

功能

下单，取消，支付，再次支付，退款，发货，退货
审核：订单，退货

方案

状态设计

说明

每个单据都有其状态。
订单：订单状态，退款退货状态和物流状态【退货单和物流单无法描述完整】。订单状态覆盖整个交易流程，有其对应行为。其他单据状态是行为的具体状态。
支付单：支付状态
退款单：退款状态

结构说明：订单状态(告知用户情况)-S外部可做的行为

交易状态

NO_CREATE_PAY[1下单未支付-S等待审核]
CLOSED_BY_(2关闭_买家卖家或平台关闭)
CLOSED_BY_EXPIRE(12关闭_超时)
WAIT_BUYER_PAY[3等待买家付款-S买家付款]
WAIT_SELLER_SEND_GOODS[4等待卖家发货-S卖家发货]
WAIT_BUYER_CONFIRM_GOODS[5等待买家确认收货-S买家确认收货]
FINISHED[6买家已收货-S退货]
CLOSED_BY_RETURN(7退货完成)
CLOSED_BY_REFUND(8退款完成)
CLOSED(9关闭)
DELETE(10删除)
CLOSED_BY_AUDIT(11关闭_审核)

退货状态(含退款状态)

BUYER_APPLY{1买家申请退货-S卖家审核}
SELLER_REFUSE[2卖家拒绝退货]
SELLER_AGREE(3卖家同意退款-S买家退货)
BUYER_RETURN(4买家已经退货-S卖家确认收货)
SELLER_RECEIVE{5卖家收货-S卖家审核货}
CLOSED(6退货关闭)
RETURN[7退货完成-S卖家退款]
REFUND(8退款完成)

物流状态

SENDING(等候发送给物流公司)
ACCEPTING(已发送给物流公司,等待接单)
ACCEPTED(物流公司已接单)
REJECTED(物流公司不接单)
PICK_UP(物流公司揽收成功)

超时处理

订单编码规则

参考
1. 订单号无重复性；
2. 如果方便客服的话，最好是“日期+自增数”样式的订单号，客服一看便知道订单是否在退货保障期限内容；
3. 订单号长度尽量保持短（10位以内），方便用户，尤其电话投诉时，长的号码报错几率高，影响客服效率；
4. 订单号尽量保持数字型(纯整数)，在数据库订单索引查询中，长整数字型的数据索引与检索效率，远远高于文本型，因此尽量避免“字母+数字字符串式”！

代付设计方案

重复支付

1. 辨识：支付公司和支付流水号不一样
2. 非首次支付成功的都退款

提货码

6位随机数字，可通过自提点位编号或者订单号来防止提货码串号。

配送方式

配送和商品是无关联的，下单时选择配送方式(虚拟商品无需物流配送)
配送方式属于包裹

发货流程

订单拆分成包裹

• 不同的商家是不同的订单
• 分类规则
  按照配送方式来分类商品集
  按照仓库来分类实物商品集
• 结构：配送方式，配送地址，商品集，仓库

平台仲裁

退换货流程关闭后(拒绝)，异议提交给平台客服仲裁

用户删除订单的处理

不是订单删除，是订单隐藏。由订单表上一个bool字段(用户删除)控制。

零费用的订单支付

订单金额是零，无需支付单

流程

交易整体

发货(包裹)

if (实物商品包裹) {
    switch (配送方式) {
        case 快递:
            商家填写物流信息(物流公司和物流单)，直接发货给买家，买家接收
        case 自提:
            商家填写物流信息，发货给自提点，通知买家自提
        case 送货:
            商家填写物流信息，发货给送货点。送货人员送货上门，买家接收
        case 现场提货:
            系统自动完成发货(无物流信息)，交易状态到第5步(等待买家收货)
    }
} else { // 虚拟商品包裹。无需物流，系统自动发货(服务也是一种虚拟商品，如手机充值/美团优惠券/家政体验券)
    switch (商户) {
        case 我方: // 如已进入我方库存美团优惠券
            从仓库获取库存商品，发货，返回结果
        case 第三方: // 如手机充值
            发送给第三方让其发货，第三方返回结果
    }
    if (多次发货失败)
        退款，取消订单
    if (发货成功)
        处理商品 // 不属于商城标准流程，特定业务自定义。如优惠券要进入我的优惠券。手机充值进入我的充值记录。
}

退款

直接退款

退货

从“6买家已收货”开始
会根据审核状态判断是否给退货。退货审核通过之后，会将退款（实付金额）按照原支付路径退回。

开发

表结构

支付成功后的处理逻辑

if (验签失败 || 支付未成功)
    return;
lock (交易) {
    if (交易状态 == 待付款) {
        订单付款完成流程
    } else if (交易状态 == 已付款) { // 
从第二笔支付成功的开始，后续重复的都做退款处理
        if (平台返回的交易流水号 != 交易流水号)
            退款平台返回的支付
    }
    return "ok"
}

营销(Marketing)

方案

详细方案

整体

• 活动和营销工具关联
  一个活动关联一种营销工具，如团购、秒杀、线下点位销售等。
  营销工具有其各自的玩法(不同的业务表支撑)，可以配置。如团购是关联商品。
• 活动可设置时间范围
• 营销工具对应平台活动(可以有多个)和商户活动。

活动

• 活动发布
  商家可以自行发布活动，只能从营销工具来创建
  平台发布的活动，商家可以报名参加(从营销工具进入，需要指定参加的商品)
• 活动页面包含：活动宣传页，活动页。同时在商品详细页也有活动说明。
• 一个商品可以参加多个活动。活动商品的购买只能从活动渠道进行(即使是从商品详细页也会引导到活动渠道)。
• 现在团购只有一个平台活动，即所有团购商品都参加了本活动。
• 结构：点位列表

优惠券使用

• 独有结构：配送方式(标准，现场自提)
• 使用方：地推活动方，商家
• 结算：按照使用的优惠券情况，和商家结算
• 商家/活动方自行负责供应链

流程

地推使用

1. 获取优惠券，点击“使用”，跳转到活动页面
2. 选择活动商品等，选择优惠券。如是明确的信息则无需选择(只有一个商品，一个点位)。支付。
   说明：本购物流程只用于营销活动，不同于标准购物流程。会有标准订单和支付单等标准购物实体。
3. 如是现场自提，支付完成后提醒去自提(提货码模式)。

商家使用

1. 用户获取优惠券(可以通过优惠券查看对应活动页面)
2. 用户到店选择好商品后，结算时打开优惠券给商家扫描。
3. 商家在用户结算时，打开商家工具扫描用户的优惠券。
4. 用户付完余款。

发布

1. 创建活动：选择几个商品，选择点位
2. 创建优惠券：类型是抵用券，创建的活动设置到对应活动

营销工具

• 营销工具：优惠券，团购，积分等
• 有任意一个不支持叠加使用，则都不能使用。

团购

同秒杀

秒杀

发布：创建秒杀活动(没有对应规则)，添加秒杀商品到活动，设置SKU的活动价和活动数量。
确保活动数量和商品SKU库存数量没有矛盾。

线下点位销售

原理同线上销售活动，区别是点位是线下物理点。
可以是多个短期活动，也可以是个长期活动。

方案1：活动主导
初始化：平台设置销售点位
参加步骤：
1. 商家打开工具，选择线下营销点，选择时间，选择商品。
2. 平台审批。

方案2：优惠券主导
初始化：平台创建线下活动
参加步骤：
1. 上架创建优惠券时选择活动

将来：
商户自行使用本工具。将自己的门店设置成销售点位...

积分

积分抵现，积分商城

优惠券

• 理解
  优惠券本质就是个活动，如全场满减的优惠券本质上等同于满减的活动。区别是要有使用凭证（所有人都可以参加，有优惠券才可以参加）。
• 优惠券可以独立使用，也可以加入到活动
• 类型

• 应用范围：平台，商户，门店
• 不支持券礼包，比如注册的时候，送的是一个礼包(内有2张优惠券A，3张优惠券B)。

用户优惠券

• 结构：来源(如行为奖励记录)，状态(未使用/使用中/已使用)。
• 使用中的用户优惠券无法使用。

生成

• 预先生成（不记名）：如要对外发布100张券，但现在已经很少这么做了，因为发不同的券不方便印刷。可以先绑定到用户，也可以直接使用（使用后绑定到用户）。
• 实时生成（记名）：如注册送优惠券

优惠码

• 本质是优惠券（类型是“优惠码”），一串数字字母是优惠券的编码。
• 只有优惠码支持免费领取（限制条件视优惠券设置）
• 领取/使用时需生成用户优惠券。

其他

用户行为及其营销奖励

支持自动失效，支持公式

行为奖励(ActionBonus)：行为编码，有效时间区间。
ActionBonusItem：奖励编号，奖励类型，数量(也可以是公式，比如金牌会员是10，银牌会员是5)。
行为奖励记录(UserActionBonus)：用户，行为奖励编号，时间。

每个用户行为都有事件发布，比如注册。
每个营销工具(优惠券，积分等)都会处理事件。比如优惠券工具会在注册时发送优惠券礼包。积分工具会在注册时加10个积分。

流程

商户发布营销工具

1. 选择平台活动 或者 新建商户活动
2. 设置营销工具对应的配置(如满100减10)
3. 选择活动商品/类目

优惠券

发布
领取
使用
结算

表结构

参考

实例分享：B2C自营电商APP的优惠券设计方案1.0

销售(Sale)

业务

一个商品一般最多两种规格
支持申请新开品牌，查看申请进度
一个商品同一时间只能属于一种初始售价的销售类型(常规/秒杀/团购)。已销售的商品不能修改本类型
商品不需要审核，上架时间到了自动上架
销售模式：如常规/团购/秒杀。不同销售模式的商品初始销售价格和销售方式都是不一样的。每个商品同时只能属于一种销售模式的实例。即每个商品只有一个初始销售价格。

功能

属性创建
品牌创建
类目创建
产品创建
商品创建：含SKU
商品上下架

方案

属性

属性名和属性值

• 支持父属性，即属性名之间有级联关系。如品牌下的型号列表
• 支持：单选，多选，文本，必选
• 淘宝参考：is_key_prop,is_sale_prop,is_enum_prop,multi,must,child_template
• 品牌是个属性

实例说明

• 叶子类目及级联关系
  
  1. 属性-品牌(PB)：属性名是品牌(PNB)，属性值是海飞丝(PVB1)，飘柔(PVB2)等
  2. 属性-型号(PM)：属性名的父属性结果是PNB+PVB1(定义到父级属性，是品牌海飞丝)；属性名是型号(PNM)，属性值是清爽型(PNM1)，去油型(PNM2)等。
• 商品的关系属性
  
  1. PB的属性结果(海飞丝)：PNB + PVB1
  2. PM的属性结果(海飞丝清爽型)：PNM + PNM1

属性和类目

属性名上关联类目，即一个属性名只能属于一个类目
自动继承父类目的属性

商品的属性来源

类目
类目下的品牌或者产品

特殊属性

品牌，产品，产品特有属性
1. 层级关系
品牌是类目的根节点，产品上级是品牌，产品特有属性上级是产品属性
2. 品牌
是个特殊的属性名(is_brand)。前端页面优先固定显示
3. 产品
归属于品牌属性。
通过属性值表的字段ProductId关联到产品表(获取默认值)。

属性结果和产品/商品/SKU

• 属性结果同时存储在两个地方：关联属性表，业务表(产品/商品/SKU(规格属性结果))的属性结果字段(json)。
• 业务表
  属性结果字段格式：属性名id1:属性值id11,属性值id12;属性名id2:属性值id2。
  例子："颜色:红,绿;尺寸:大号"
• 关联属性表（PropRelation）
  记录业务表创建时的属性结果，其实和业务表上的是一样的。只是为了更便于查询统计。
  通过“关联属性表”关联，定义一个具象的商品。
  
  1. 多选的属性，会有多条属性名一样的记录（属性值不同）
  2. 输入的属性，文本记录到文本字段

类目属性管理

1. 类目属性通过属性树来编辑管理。
2. 属性名表的父属性名编号和父属性值编号必须成对使用。也就是说第一级是属性名，第二级是属性值，以此类推。
3. 整体操作有：新增根属性名
4. 树节点的操作有：新增下级，编辑(只有属性名有)，删除。
5. 编辑点开后是新页面：有属性名内容，属性值列表。

实例：
1. 类目情况
1.1. 类目下有2个属性名，品牌(值是苹果/华为/小米)和内存(值是2G/4G)
1.2. 品牌下有3个产品属性名(父级分别是苹果/华为/小米)。(苹果)产品的值是iphone6/iphone7，(华为)产品的值是mate3/mate4，(小米)产品的值是小米5/小米6。
品牌下有个苹果品牌特有的属性名“特色”。
1.3. (苹果)产品属性(值是iphone6)下有一个产品特有的属性名“产地”(值是中国/美国)
2. 属性名树结构

品牌
    苹果
        产品
            iphone6
                产地
            iphone7
        特色
    华为
        产品
    小米
        产品
内存

产品

主要用于商品快速创建的默认值：如商品标题等通用信息，属性结果默认值(类目属性结果，属性表内的产品属性结果)。

商品销售分成档位

推广人员推广一个用户或者商品后的分成收入。

档位：一般有几个档位，如1%，5%等。
优先级：商品，类目。
可选项：是否启用销售推广功能

上下架

上架：可销售(有库存)就可以操作
下架：先退出参加的活动，方可下架

流程

商品添加

1. 选择叶子类目(无类目可以申请开通类目)
2. 选择类目下的品牌和型号(固定编码类型)。(无则可以申请开通)
3. 填写动态生成的属性
4. 填写规格
5. 填写其他
6. 添加

商户申请类目/品牌/型号

1. 商户填写申请内容
2. 平台审核

QA

• 规格和属性的区别
  说法的区别，都是属性。规格和库存有关，其他属性用于搜索和分类。
• 规格存在哪里
  规格定义都存在属性相关的表中。规格结果(X码红色)存在SKU中。
• 打包品方案
  打包品是商品，通过打包品和sku关系表，建立sku关联。即可以共用sku。
• 类目
  类目来自于平台创建和商户申请。
  是商品属性决定的事项，属性名和属性值到类目。品牌和类目是多对多。
• 店内分类
  只是用于显示用途。
• 型号，产品，sku的商户编码
  型号：iphone7 64G
  产品：对应一个特定型号(iphone7 64G)，也可以对应几个特定型号(iphone7，对应多个不同内存容量的sku)。推荐是后者。
  sku的商户编码：商户发货时使用，商户决定

表结构

商品(item)

• 基础信息：产品id，名称(45个字)，标语，关键字，品牌，是否上架，是否草稿，打包品id，基本属性列表json，图片列表，类型(实物/虚拟/服务)，是否序列产品。商品属性
• 配置：免运费，库存计数（下单，付款（点击支付时）），允许超卖，单人最大购买数量。详情样式模板。线上销售(No是线下)
• 营销：销售分成档位
• 销售：销售属性(规格)，最低售价，最高售价
• 物流：运费模板
• 保障：有发票，支持专票，允许退货，7天无理由退货，商家问题的商品是商家承担运费

商户(Seller)

业务

• 入驻流程和材料
• 销售和售后

方案

• 自营和商家区分
  自营也是个商家，但是个特殊商家（编号是0）。即自营也有商家运营系统。和平台运营系统分离。
• 商家编号规则
  商家编号是从10000开始，顺序递增
• 业务如何关联到商家
  所有业务表都有字段：商家编号

表结构

线下点位

整体

1. 商户提供商品在销售渠道(线上商城和线下点位)销售
2. 线上下单，线下营销销售(商户自己的销售点，平台提供的销售点)
3. 不支持线下下单

概念定义

场景

1 门店-销售

1. 说明
   需要商户系统支持，很难打通。不推荐使用
2. 流程
3. 角色分工

2 销售点-商户现场营销销售

1. 说明
   活动模式：推广商城下单，“优惠券-线上使用”等
   活动场地：任意场地，也可以在门店
   下单途径：在线商城
   付款方式：线上付款
   配送方式：小件现场，大件快递

2. 使用流程
   大件是标准购物流程
   小件的现场提货是一种配送方式

3. 角色分工

3 门店-商户优惠券-线上使用

1. 说明
   门店属于商户
2. 使用流程
   用户在线上商城使用优惠券下单，到门店提货
3. 角色分工

4 门店-商户优惠券-线下使用

1. 说明
   需要商户系统支持，很难打通。不推荐使用
2. 使用流程
   用户到门店下单，付款时使用优惠券
3. 角色分工

5 物流

1. 说明
   代送类似达达
   代收，服务员需提供物流点
2. 使用流程
3. 角色分工

多门店管理方案

总部：产品发布(可设置可售门店)，统一描述、统一促销，分配订单
门店(独立库存和价格)：上架商品，设置库存和价格，管理订单，发布管理本店商品

仓库管理(WMS)

业务

支持：出入库和库存管理(含序列产品)
不支持：批次和库位管理，不支持移库

出入库：实物是库存数量，序列产品是产品列表

序列产品：每个有唯一序列号的产品(实物和虚拟产品)。如电子门票，笔记本等。

方案

序列产品入库

创建入库单和入库单明细
导入产品列表到库存表(一般采用Excel导入)

出库(销售，对应包裹)

创建出库单和出库单明细
库存表调整(数量)

库存数量

入库数量是入库时决定的
锁定数量一般用于预售
可用数量=入库数量-出库数量-锁定数量

表结构

配送(Delivery)

业务

配送类型：实物配送(physical)，电子配送
订单拆分成包裹。
电子配送没有物流单。实物配送要填写物流信息。
支持单据打印：包裹商品单，物流单

方案

表结构

供应链系统(Supplier)

业务

• 目标：集成物流和仓库管理，对接商城交易
• 商城对接方案：
  
  1. 通过商城的账号密码登录
  2. 商户授权(可以手工配置)
• 发货：支持自身仓库发货，也支持供应商发货(暂不支持)
• 角色分工
  
  1. 商城：商品的库存管理，发货状态修改(可通过第三方系统调用修改))
  2. 本系统
     a. 订单发货/退货
     b. 仓库管理：含库存管理

功能

设置商城商户
出入库
库存：上商城，库存同步
订阅商城下单消息，手工/自动发货，同步到商城
退货确认，同步到商城
供应商管理
财务管理：供应商账单

资产(Finance)

数据(Data)

客户(Customer)

客服

参考

淘宝的交易相关状态

订单状态

TRADE_NO_CREATE_PAY(没有创建支付宝交易)
WAIT_BUYER_PAY(等待买家付款)
SELLER_CONSIGNED_PART(卖家部分发货)
WAIT_SELLER_SEND_GOODS(等待卖家发货,即:买家已付款)
WAIT_BUYER_CONFIRM_GOODS(等待买家确认收货,即:卖家已发货)
TRADE_BUYER_SIGNED(买家已签收,货到付款专用)
TRADE_FINISHED(交易成功)
TRADE_CLOSED(付款以后用户退款成功，交易自动关闭)
TRADE_CLOSED_BY_TAOBAO(付款以前，卖家或买家主动关闭交易)
PAY_PENDING(国际信用卡支付付款确认中)
WAIT_PRE_AUTH_CONFIRM(0元购合约中)

退款状态

WAIT_SELLER_AGREE(买家已经申请退款，等待卖家同意) WAIT_BUYER_RETURN_GOODS(卖家已经同意退款，等待买家退货)
WAIT_SELLER_CONFIRM_GOODS(买家已经退货，等待卖家确认收货)
SELLER_REFUSE_BUYER(卖家拒绝退款)
CLOSED(退款关闭)
SUCCESS(退款成功)

物流状态

CREATED(订单已创建)
RECREATED(订单重新创建)
CANCELLED(订单已取消)
CLOSED(订单关闭)
SENDING(等候发送给物流公司)
ACCEPTING(已发送给物流公司,等待接单)
ACCEPTED(物流公司已接单)
REJECTED(物流公司不接单)
PICK_UP(物流公司揽收成功)
PICK_UP_FAILED(物流公司揽收失败)
LOST(物流公司丢单)
REJECTED_BY_RECEIVER(对方拒签)
ACCEPTED_BY_RECEIVER(发货方式在线下单：对方已签收；自己联系：卖家已发货)

资料

非小型电子商务系统设计经验分享
从淘宝数据结构来看电子商务中商品属性设计
营销工具
新手如何开淘宝店
新手卖家物流选择 后台相关设置
新手卖家如何进行快速发货
新手卖家退换货订单管理
产品型号、货号、条形码有什么不同
有赞API

角色概念

供应商：生产方，相对销售方的角色
分销商：销售方，相对生产方的角色。是渠道，可以押金，进货

第三方平台

有赞-微商城
有赞-微商城营销中心
微店