引言

不知不觉在电商平台工作半年了，半年售后订单系统模块一直饱受吐槽。

申请售后先后历经一下几个模式：

• 一笔订单只能申请一次售后，申请后不能再次申请售后
• 允许多次售后(但是只能在该笔订单没有正在处理的售后订单的情况下)，但是一笔订单的一个商品只能申请一次售后(存在一个商品购买多个的情况)
• 允许多次售后(但是只能在该笔订单没有正在处理的售后订单的情况下)，单个商品只要申请售后的数量小于或等于该商品未申请售后的数量，就可以继续售后。

修改期间我一直是实施者(纯粹的不想动脑子考虑)，按照设计文档来修改，在经历第三次修改后，我依旧发现售后订单的不合理之处。等待下一次售后修改还是趁着这次继续修改。哎，惆怅....

当前平台售后模块介绍

平台利用app进行下单，在订单表(b_order)中生成订单信息，在订单零件表(b_order_part)中存储订单零件信息。

当申请售后订单的时候,在售后订单表(b_order_after)中新增一条记录，记录相关订单信息以及申请的原因、申请退款金额。

申请的具体售后零件数量在原有的订单零件表中修改after_sale_amount(申请售后数量) 和 after_sale_status(该商品的售后数量) 属性。

订单表(b_order)

列名	类型	KEY	可否为空	注释
id	int(11) unsigned	PRI	否
num_order	varchar(20)	MUL	是	订单号码 自动生成20位
total_money	float unsigned		是	订单总金额
order_from	int(22) unsigned		是	订单来源（保险询价单/直供询价单/商城订单/发起担保交易订单）
order_brand	varchar(20)		是	汽车品牌记录字段id
order_brand_image_url	varchar(255)		是	图片地址，如果是询价单订单就是车牌照片，如果是商城订单就是默认照片。
order_content	varchar(100)		是	订单项目： 询价单就是品牌相关零件名称加起来，商城订单就是商城产品名称等。发起交易类目
num	int(11) unsigned		是	商城商品数量
payment_type	int(11)		是	支付方式：微信/支付宝/货到付款
order_status	int(11)		是	订单状态（未付款 已付款（待发货） 发货 收货（结束） 发货前售后 货后售后 售后处理完毕,失效
money_after_ft	float		是	实际退款总额
after_result_last	int(11)		是	最后一次售后状态
inquiry_id	int(10)		是	询价单主键id
logistices_money_status	int(255)		是	报价单是否包含运费，361包含 362不包含
logistices	varchar(50)		是	物流公司名称：
logistics_no	varchar(50)		是	物流公司单号：
consigner_address	varchar(255)		是	发货人地址
consigner_tel	varchar(30)		是	发货人电话
consigner	varchar(30)		是	发货联系人
consignee_address	varchar(255)		是	收货人地址
consignee_tel	varchar(30)		是	收货人电话
consignee	varchar(30)		是	收货人名称
buyer_company_id	int(11)	MUL	是	买方公司id(公司表)
buyer_company_name	varchar(50)		是	购买方公司名
buyer_id	int(11)	MUL	是	买方操作人id(用户表id)
buyer_name	varchar(50)		是	购买人姓名
saler_company_id	int(11)	MUL	是	卖方id(公司表)
saler_company_name	varchar(50)		是	卖方公司名称
saler_id	int(11)	MUL	是	卖方操作人id(用户表id)
saler_name	varchar(50)		是	卖方人
tax_in_price	int(11)		是	价格是否包含税 0为不含税 1为含税 也就是需不需要开票。
invoice_status	int(20)		是	开票状态（已经开票/未开票），首次插入时候未开票状态。
a_tax_id	int(11)		是	a_tax表外键，代表发票id
area_id	varchar(6)		是
city_id	varchar(6)		是	chen
province_id	varchar(6)		是	省份id
isdel	bit(1)		是	是否删除
create_at	datetime		是	创建时间
update_at	datetime		是	修改时间

订单零件表(b_order_part)

列名	类型	KEY	可否为空	注释
id	int(11)	PRI	否
b_offer_id	int(11)		是	报价id
offer_part_id	int(11)	MUL	是	报价零件id(报价零件表)
name	varchar(50)		是	零件名称
money	float		是	金额
quality	int(11)		是	品质
amount	int(11)		是	数量
after_sale_amount	int(11)		是	申请退款的数量。
after_sale_status	int(11)		是	售后状态 默认：无 ，申请中 拒绝 同意部分退款 同意全额退款
order_id	int(11)	MUL	是	订单ID(订单表)
isdel	bit(1)		是	0删除 1未删除
create_at	datetime		是	创建时间
update_at	datetime		是	修改时间

售后详情记录表(b_order_after)

列名	类型	KEY	可否为空	注释
id	int(10) unsigned	PRI	否
num_order_after	varchar(20)		是	售后单号 20位
order_id	int(11)	MUL	是	订单id
money_apply	float		是	申请退款金额：***
money_final	float		是	实际退款金额（）
mark	varchar(255)		是	备注(退款备注)
after_result	int(20)		是	处理结果：（未处理/拒绝退款/同意部分退款/同意全额退款）。
pl_mark	varchar(255)		是	备注（管理员处理退款时候）
recorder	varchar(20)		是	操作人
create_at	datetime		是	创建时间
update_at	datetime		是	更新时间

分析问题

在只允许订单单次售后的情况下，上面3张表可以完成所有的业务逻辑。订单展示、售后订单展示、售后零件展示等一系列操作。

但是，涉及到多次售后，甚至是单种零件的多次售后，上面3张表所搭建起来的逻辑关系就无法适应需求的变更了。

只允许单次售后的情况下，查看某个售后订单的具体售后的零部件，只要是b_order_part表中的售后状态不是无售后，就全是申请售后的零件。具体的零件、申请售后的数量，清晰明了

允许多次售后(只能在该笔订单没有正在处理的售后订单的情况下)，但是某种零件无论数量多少只允许申请一次售后的情况下。b_order_part表中只要是售后状态并且零件的状态处于未处理的情况下，都属于本次申请的售后订单。这种情况下，本次申请的零件的名称、申请售后的数量依旧清晰可见。

但是第三次修改，允许多次售后(只能在该笔订单没有正在处理的售后订单的情况下)，但是某种零件可以更具购买数量来进行多次售后，只要总共售后的数量没超出购买的数量。这种情况，售后零件名称是可以根据售后零件的状态查看出来，但是本次申请售后的数量是不清晰的，因为多次售后，现在b_order_part表中的after_sale_amount 是多次售后叠加出来的，并不是本次申请售后的数量，这样就会对售后订单的处理造成困扰，特别是管理员端售后订单显示的时候。

解决方案

我考虑了一下，在三张表的情况下，无法解决单个零件多次售后数量记录的问题。决定新增一张表来记录某次售后订单申请的零件的名称与数量，其余的不进行变动，b_order_part 中的售后申请数量还是按照以前的逻辑，进行累加。但是每次申请售后，都将申请的零件名称、申请的数量单独记录下来。在处理售后订单的时候，售后零件的信息从这张新建的表中查询数据。其他的依旧。

在新增这张表的情况下，当前运行的系统，目前按照我所认知的情况下，无论申请多少次售后、单个零件申请多少次售后，只要他在系统中成功的申请了售后，各项数据都不会乱，都可以正常清晰的显示以及正常的处理。

结束

以上我是参照当前运营的系统进行参考和设计的，个人认知水平有限，勿喷。