订单售后表数据结构设计
一、主要业务点
1、申请售后对象:订单为单位,不能选择数量(必填)、订单中某个商品为对象,可选择数量(选填)
2、用户申请售后时机:已支付未发货/已收货(必填)、除退款后任何情况都可以申请售后(一种商品仅
能申请一次 特殊商品不可申请售后)
3、售后流程:用户申请/取消<-->平台通过/拒绝<-->供应商通过/拒绝<-->财务通过/拒绝
4、缺货流程:全部缺货/更换供应商 部分缺货,部分商品更换供应商,或修改商品sku但订单总价不变
二、售后流程:
a) 用户退换货流程
a1) 用户申请退换货,流程跳转到b
a2) 用户撤销申请,流程结束
b) 平台流程
b1) 平台客服通过退换货,流程跳转到c
b2) 平台客服拒绝退换货,流程跳转到a,用户再次审核(特殊商品限定申请规则和次数)
c) 供应商流程:物流流程加入主要是防止已发货的订单被退款
c1) 供应商通过退换货,流程跳转到d
c2) 供应商拒绝退换货,流程跳转到b
d) 财务流程
d1) 财务通过-->退款,流程结束
d2) 财务拒绝,流程跳转到c
三、用户申请售后填写项目:
第一步:
1、服务类型:换货、退货
2、申请数量:可小于购买数量
3、申请凭证:有发票、无发票(非必填,无发票需要扣除相应税点)
4、检测报告:已有检测报告、尚无检测报告
5、问题描述
6、上传图片:最多三张、每张不超过5张,支持JPG、BMP、PNG(非必填)
第二步(大部分信息可从购买信息中取默认值):
1、商品返回方式:送货至自提点/快递/上门取件
联系人、联系电话、上门取件还需填写取件地址、取件时间等
2、确认收货信息(售后处理完成后商品返还):收货地址(省市区、街道、详细地址)
四、其它注意事项
1、退换货的运费问题
a) 订单未发货时取消退运费
c) 订单已发货后退换货不退运费
2、售后流程反复
a)、用户申请后,自己取消,再申请
b)、用户申请后,被平台驳回,用户再申请
c)、平台通过后,被供应商驳回,平台驳回到用户端或再次审核通过
d)、供应商通过后,被财务驳回,供应商再审核
3、用户取消售后申请场景
a )用户申请后,又取消了申请
b) 平台同意后,用户取消了申请
c) 供应商同意后,用户取消了申请
d) 财务退款后,用户不能取消申请
4、其它
a) 售后最小单位是商品,而非订单
b) 售后可以选择商品数量,比如购买了5个商品,只需要退换货其中的2个(可能有质量问题或已损坏
)
五、数据表的设计
1、售后流水信息表
编号、售后单号、订单号、用户编号、商品编号、商品数量、操作类型(用户申请、平台审核通过、平台
审核拒绝、供应商审核通过、供应商审核拒绝、财务审核通过、财务审核拒绝)、申请原因、业务操作人编号(
用户申请为用户编号、平台审核为平台审核操作人编号)、操作时间、业务操作描述(如用户申请原因、客服拒
绝原因)、备注
2、售后流水信息表(用户查看)对于当前售后状态的动态跟踪显示
说明:用户需要看到售后的审核流水概况,比如审核通过,系统内部流程可能流转了平台、供应商、财务
等,但是对于用户看到的就是审核通过
表结构:编号、服务单号、操作人、操作时间、操作描述
3、订单售后信息表
说明:订单和售后之间的联系描述
表结构:售后单号、订单号、商品编号(SKU)、商品数量、状态(如审核通过、审核不通过等)、内部
状态(用户审核通过、平台审核不通过等)、申请人编号、申请时间、问题描述、审核人编号、审核人业务类型
、审核留言、审核时间
4、售后日志表
说明:每次退款无论成败都记录流水日志
表结构:编号、日志编号、退款金额、退款原因、退款状态(是否成功)、操作人、操作时间
注意事项:
1、重新申请售后会生成一个新的售后单
2、根据售后单去查询运维、用户的审核状态和流程
六、退款信息
1、每次退款无论成败都记录流水日志,日志表
2、代码结构
1、退款业务单独建个类,封装微信、支付宝等退款逻辑,对外提供单一接口
2、可快速禁用接口退款功能,恢复线下退款功能
3、退款失败可能情
1、 账户余额不足
2、退款金额大于订单金额
原文https://blog.csdn.net/HaoYu1098/article/details/81630299