``# 退款架构

一、退款界面的显示

调用BuyerApplyRedundTag来获取当前订单的明细以及进行应该显示商品的过滤：

1. 参数：

   接收ordersn参数和skuid参数，其中skuid参数非必传

2. 返回值：Map

   A. 此map一个key为order：

      OrderDetail ： 订单的明细，由IOrderQuery接口得到的
      此对象的productList对象是用来显示在退款界面中的“本次退款的商品”
   

   B. 此Map中的一个Key为original_way

      字串，标明是否可以原路退回，如果为"yes"为支持，否则为不支持。
   

   C. key为 return_money

   Double，可退的金额
   

   D. key为 return_point

   Integer，可退的积分
   

3. 业务逻辑

   A:根据业务情况重新构造此list：

    取消订单时，不允许单个商品退款，所以不传skuid，直接显示为此订单的全部商品
   
    退货时，是按商品退款，所以传递skuid，对productList进行重新构造，只有当前sku
   

   B:计算退款金额

     直接使用成交价（订单在下单时会计算好）
   

   C:计算是否支持原路退回

     调用IPaymentMethodManager得到PayMethod中的is_retrace 来判断
   

4. 界面显示逻辑

   1.如果是在线支付，且支付方式支持原路退回，则原路退回，否则需要选择退款方式。
   2.如果是积分兑换商品，则要添加退还积分输入框。
   

二、退款单保存

1. skuid参数与退款单商品的形成逻辑

   BuyerRefundApply对象中skuid如果为null（没有传递），则表明是全部商品退款。
   如果传递了skuid，则表明是此货品退款
   

2. 入库

   循环订单的productList对象，比对product_id和refund对象的sku_id
   成功后，拼装RefundGoods对象，使用上步得到的refund_sn，存入数据库
   

3. 订单及售后状态流程图

三、退款/退货审核

1.逻辑处理：

   1.此处理包含退货审核逻辑
   2.如果是审核退款，且订单的支付方式支持原路退回，则调用IOrderPayManager接口的退款方法原路退回
     否则直接更改退款单的退款（货）状态为已成功，接下来需要财务手工退款
   3.商家审核取消订单退款申请，需修改订单表中service_status的状态，如审核货品退款申请则修改货品的
     service_status状态，是否可以再次申请售后由此状态判断
   4.发送售后变更消息

2.订单及售后状态流程图

说明：
1、因需求为：买家申请取消订单时，如果卖家审核拒绝则不能再次取消订单。
逻辑规则：通过订单的售后状态判断是否可以取消订单：为NOT_APPLY时才允许取消订单操作。
2、因需求为：买家对货品申请售后，如果卖家审核拒绝则不能再次申请售后。
逻辑规则：通过货品的售后状态判断是否可以申请售后：为NOT_APPLY时才允许申请售后操作。

四、财务手工退款

1. 逻辑处理：

1. 当无法进行原路退回（自动退款）时财务可以手工标记为已退款。
2. 财务退款不需要自动退款，不会发生这样的情况，如果是可以原路退回，商家一同意就可以退回了。

2.订单及售后状态流程图