**平台售后模块总结
引言
不知不觉在电商平台工作半年了，半年售后订单系统模块一直饱受吐槽。
申请售后先后历经一下几个模式：
- 一笔订单只能申请一次售后，申请后不能再次申请售后
- 允许多次售后(但是只能在该笔订单没有正在处理的售后订单的情况下)，但是一笔订单的一个商品只能申请一次售后(存在一个商品购买多个的情况)
- 允许多次售后(但是只能在该笔订单没有正在处理的售后订单的情况下)，单个商品只要申请售后的数量小于或等于该商品未申请售后的数量，就可以继续售后。
修改期间我一直是实施者(纯粹的不想动脑子考虑)，按照设计文档来修改，在经历第三次修改后，我依旧发现售后订单的不合理之处。等待下一次售后修改还是趁着这次继续修改。哎，惆怅....
当前平台售后模块介绍
平台利用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 中的售后申请数量还是按照以前的逻辑，进行累加。但是每次申请售后，都将申请的零件名称、申请的数量单独记录下来。在处理售后订单的时候，售后零件的信息从这张新建的表中查询数据。其他的依旧。
在新增这张表的情况下，当前运行的系统，目前按照我所认知的情况下，无论申请多少次售后、单个零件申请多少次售后，只要他在系统中成功的申请了售后，各项数据都不会乱，都可以正常清晰的显示以及正常的处理。
结束
以上我是参照当前运营的系统进行参考和设计的，个人认知水平有限，勿喷。
