@@ -363,15 +363,48 @@ litemall_region表保存了行政区域信息,包括省级、市级、县级
363363
364364* 401
365365
366- 用户可以` 删除 ` 、` 去评价 ` 、` 再次购买 `
366+ 用户可以` 删除 ` 、` 去评价 ` 、` 申请售后 ` 、 ` 再次购买 `
367367
368368* 402
369369
370- 用户可以` 删除 ` 、` 去评价 ` 、` 再次购买 `
370+ 用户可以` 删除 ` 、` 去评价 ` 、` 申请售后 ` 、 ` 再次购买 `
371371
372- #### 2.1.4.3 售后处理
372+ #### 2.1.4.3 申请售后
373373
374- 目前不支持退货售后相关业务。
374+ 当用户确认收货或者系统自动确认收货以后,订单可以申请售后。
375+ 目前仅支持订单整体售后,而不支持订单商品独立售后。
376+ 这是因为:订单存在商品售价、优惠券减免、团购减免以及物流运费属性,
377+ 如果要支持单个商品退款,那么存在一个需要解决的问题就是单个商品的
378+ 退款金额如何计算。如果开发者这里考虑清楚,也可以参考当前代码实现
379+ 订单商品独立售后
380+
381+ litemall_order表中存在` aftersale_status ` 字段,记录订单售后状态。
382+ 而具体的售后记录则是litemall_aftersale表记录。
383+
384+ 这里` type ` 字段表示当前售后类型,目前存在三种类型:
385+
386+ * 如果type=0,即“未收货退款”,通常是系统超时自动确认收货,而实际上用户没有收货,因此可以选择这个;
387+ * 如果type=1,即“无需退货退款”,通常是用户确认收货后申请售后,而管理员同意可以不需要退货,直接退款给用户;
388+ * 如果type=2,即“退货退款”,通常是用户确认收货后申请售后,管理员同意用户退货,当管理员收到货以后再退款给用户。
389+
390+ 需要注意的是:当前实现中,如果是“退货退款”类型,那么管理员在进行退款以后,系统会自动恢复货品数量。
391+ 这是因为管理员完成“退货退款”售后,说明管理员已经收到用户的退货。
392+ 开发者可以改变这里的实现逻辑,例如采用独立的退货入库流程。
393+
394+ ` status ` 字段表示当前售后状态,分别是:
395+
396+ * 如果status=0,未申请售后;
397+ * 如果status=1,用户申请售后,等待管理员审核;
398+ * 如果status=2,管理员审核通过,等待管理员退款;
399+ * 如果status=3,管理员已退款,售后完成;
400+ * 如果status=4,管理员审核不通过,售后完成;
401+ * 如果status=5,用户已取消售后,当用户在申请售后以后可以在管理员审核前申请取消。
402+
403+ 这里需要补充的是:订单litemall_order表的` aftersale_status ` 字段,和订单售后litemall_aftersale
404+ 表的` status ` 字段是完全一致的,方便前端分别查询订单状态和订单售后状态。
405+
406+ ` amount ` 字段表示当前售后退款金额,正如前面所述当前仅支持订单整体售后,因此目前设计的退款金额是
407+ 订单实际付款-订单运费。
375408
376409#### 2.1.4.4 商品评价
377410
@@ -386,11 +419,12 @@ litemall_region表保存了行政区域信息,包括省级、市级、县级
386419
387420评论表litemall_comment保存评论相关的信息,其中最关键的是` type ` 字段和` value_id ` 字段。
388421
389- 这里` type ` 字段表示当前评论类型,目前存在三种类型 :
422+ 这里` type ` 字段表示当前评论类型,目前存在两种类型 :
390423
391424* 如果type=0,则当前评论是订单商品评论,value_id是订单商品ID;
392425* 如果type=1,则当前评论是专题评论,value_id是专题ID;
393- * 如果type=2,则当前评论是订单商品评论的回复,value_id是订单商品的评论ID。
426+
427+ ` admin_content ` 字段则拥有记录管理后台管理员对用户评论的回复。
394428
395429### 2.1.6 团购设计
396430
0 commit comments