HH SaaS电商系统的销售订单设计

liaowenxiong

已于 2023-03-12 20:22:53 修改

阅读量1.8k

点赞数

文章标签：产品设计软件设计系统设计电商系统 SaaS系统

于 2020-04-13 14:25:25 首次发布

本文链接：https://blog.csdn.net/liaowenxiong/article/details/105484821

版权

文章目录

订单销售类型
订单优惠
- 优惠方式
- 子订单优惠金额
订单拆单
订单发货
销售订单拆单逻辑图
销售订单的信息结构
- 相关实体
订单运营类型（作废）
售后截止时间
订单状态
订单管理原型设计
- 买家小程序端原型
- 商家管理后台PC端订单管理原型

订单销售类型

自销订单
分销订单

具体是指“推广分销”的订单，和供货商之间不产生采购单

订单优惠

优惠方式

买家没有承担任何成本而获取到的减免就属于优惠，例如：金币、积分、优惠券（现金券、折扣券）¹
、现金红包、卖家直减²都是属于优惠方式，用来抵扣“应付金额”，被抵扣部分对买家而言属于免费部
分，买家实际并没有承担相应的成本。

子订单优惠金额

子订单优惠金额=活动优惠金额+无偿优惠券抵扣金额+有偿优惠券抵扣金额+金币（即积分）抵扣金额+直减金额（商品改价产生）。
主订单的优惠金额必须分摊到单个SKU上，这样才能算出商品的最终交易价和卖家实际收款金额。
有偿优惠券抵扣金额必须单独统计出来，退款时才能折算成金币返还给买家

订单拆单

不同店铺的订单同时提交时，系统会按店铺拆分生成多个主订单，而每个主订单又会按SKU拆分生成多个子订单，同时会生成一个“联合单号”，用来关联多个主订单
单店铺的订单提交时系统会按店铺生成一个主订单，再根据SKU的数量生成多个子订单，此时主订单号等于“联合单号”，付款时生成一笔支付单，同样与此“联合单号”关联
待付款的相关联的销售订单必须在买家端合并显示，而且只能一起付款或者一起取消，付款后相关联的订单不再合并展示

销售子单不能说成SKU，销售子单只是根据不同的SKU生成的销售订单，销售子单包含一个SKU，即销售子单与SKU是一对一的关系，即一笔销售子订单对应一个SKU，或对应一种单品，或对应一种品项，或对应一款商品。

订单发货

开通仓储系统的商家不支持在订单中直接发货，必须前往仓储中心找到相关的出库单完成“发货”操作

销售订单拆单逻辑图

在这里插入图片描述

销售订单的信息结构

在这里插入图片描述

订单运营类型（作废）

不同运营类型的订单状态和业务流程不同，有的订单需要核销功能，有的订单需要买家确认收货，有些订单需要商家确认送达，所以需要通过类型来区分和判断相关的逻辑。不同类型的订单建议设计在同套数据表中，因为在后台不同类型的订单会展示在一起。

1. 拼团型快递订单
2. 预售型快递订单
3. 常规型快递订单
4. 自提订单
5. 配送订单（即外卖订单）
6. 线上服务订单
7. 线下服务订单
8. 常规快递+线下服务订单
【途虎养车】就是典型的快递+线下服务相结合的应用，通过实物商品关联服务商品，用户下单时可以选择或不选择有关的服务，选择服务产生的订单就是快递+线下服务订单，不选择服务产生的就是快递类订单
9. 预售定制自提订单

售后截止时间

买家确认收货后，根据收货时间+7天（后台可配置）计算得到售后截止时间

订单状态

SaaS电商系统需要满足尽可能多的客户，就要满足尽可能多的商业模式，无疑就要求订单系统兼容更多的业务运营模式，而不同业务模式的订单的状态是不同的，所以系统该如何判断订单应该使用哪种状态机呢？

系统之前是通过“订单运营类型”字段来保存尽可能多的类型，然后根据不同订单运营类型设计不同的状态机，现在改成更加合理的做法，就是在销售主单增加“商品类型”、“是否预售”、“是否定制”、“交易方式”、“是否拼单”、“下单方式”6个字段，通过这6个字段进行不同的组合，每种组合会对应一种状态机，订单生成时需要保存销售订单和状态机的关联关系

下单类型：线上下单、线下开单

商品类型：实物、虚拟、服务、实物+服务

是否预售：预售、非预售

是否定制：定制、非定制

是否拼单：拼单、非拼单

交易方式：自提、配送、快递、线上、上门、到店、快递+到店、快递+上门

P.S. 虚拟商品的交易方式就是线上

订单属性组合和状态机的关系表

状态机代码	销售订单属性条件	说明
001	实物+线上下单+非预售+非定制+非拼单+快递	001的状态机对应一个根据相关的状态逻辑图写成的方法
002	实物+线上下单+预售+定制+非拼单+自提	002的状态机对应一个根据相关的状态逻辑图写成的方法
003	实物+线上下单+非预售+非定制+非拼单+自提	003的状态机对应一个根据相关的状态逻辑图写成的方法
004	实物+线上下单+非预售+非定制+非拼单+配送	004的状态机对应一个根据相关的状态逻辑图写成的方法
005	服务+线上下单+非预售+非定制+非拼单+线上	005的状态机对应一个根据相关的状态逻辑图写成的方法
006	服务+线上下单+非预售+非定制+非拼单+上门	006的状态机对应一个根据相关的状态逻辑图写成的方法
006	服务+线上线上下单+非预售+非定制+非拼单+到店	到店服务订单也使用006的状态机
007	虚拟+线上下单+非预售+非定制+非拼单+线上	007的状态机对应一个根据相关的状态逻辑图写成的方法
008	实物+线上下单+非预售+非定制+拼单+快递	008的状态机对应一个根据相关的状态逻辑图写成的方法
009	实物+线下开单+非预售+非定制+非拼单+自提	009的状态机对应一个根据相关的状态逻辑图写成的方法

销售订单和状态机的关系表

销售主单ID	状态机代码
202005267788520	001
202005267788522	002

状态机的设计

入参：销售子单ID，事件（不同事件会对应不同的修改状态的方法）

说明：根据订单ID获取当前状态和状态转变事件，根据事件参数判断要执行哪个修改状态的方法

举例：假设售后完成后执行销售订单的销售状态机，得知订单绑定的状态机代码001，系统调相关的方法，传相关参数（事件：退款，销售子单ID：xxxxxxxxxxxxx），根据销售子单ID可以获知子单当前状态为“未发货”，并且知道转变成为下个状态有2个事件：发货、退款，两个事件会对应两个方法。而当前事件为：退款，于是程序会执行“退款改状态”的方法，该方法会去获取销售子单关联的所有“退款成功”的退款单，汇总退款金额，判断退款总额是否等于子单的实付金额，相等则将子单状态转变成“退款成功”，否则状态不变。而销售子单状态一旦更新成功，需要再调修改销售主单状态的方法，也是传相关参数（事件：退款，销售主单ID：xxxxxxxxx），根据销售主单ID可以获知主订单当前状态为“等待商家发货”，并且知道转变成为下个状态有2个事件：发货、退款，而当前事件为：退款，于是程序会执行“退款改状态”的方法，该方法会去获取当前销售主单关联的全部销售子单的状态，判断是否全部为“退款成功”，是则将销售主单的状态转变成“订单关闭”，否则状态不变。

P.S. 全部从子单状态开始判断，子单状态更改成功后再修改主单的状态，从“现态”转变成“次态”往往是需要条件的。上述例子中销售主单的事件：退款，等待商家发货（现态）→订单关闭（次态）的条件：所有子单的状态为：退款成功