促销活动后台逻辑相关

新增优惠券

新增的时候，选择对应商品会自动带出对应商品的规格

所有规格都可以设置启用和禁用（由前端操作，不会请求后端相关接口）

提交时，所有规格都要提交（已经携带好对应的启用/禁用状态）

提交的规格数据：

//数组对象 {规格id,活动价格，活动数量，状态}
[{"product_sku_id":4,"promotion_price":10000,"promotion_number":10,"status":1},{"product_sku_id":5,"promotion_price":20000,"promotion_number":10,"status":2},{"product_sku_id":6,"promotion_price":10000,"promotion_number":10,"status":1}]

编辑优惠券

正常关联商品对应规格数据，但会出现商品新增了规格的情况，这里会动态查询出所有最新的规格

eg 原来3个规格并已经新增活动，编辑活动的时候出现5个规格，说明此商品追加了2个规格

编辑展示的时候是展示全量，并且与已经存在于活动规格做比对（因为已经是有数据支撑的），追加的2个规格则是空数据

提交的时候做增量保存修改

所以可能存在2部分，一部分是原量的修改，一部分是增量的追加

上下架

已经结束的活动不可操作

下架无约束，上架时，当前时间必须大于活动时间

活动新增和修改时候的事件

1活动开始时间，延迟队列，倒计时1小时的群推，如果设置过去时间（12小时内），或未来不满足大于1小时 则不会加入队列

2活动结束时间，延迟队列，结束时候更改活动状态

需要将开始时间和结束时间保存到队列里，最终消费者消费的时候需要比对数据库这2个时间，存在变化不执行逻辑。因为存在活动在中途修改的情况，会有新的消息产生，老消息直接消耗掉不执行

订单管理-后台

展示的是子订单，每个子订单为一条订单记录。

子订单可包含同一商品的不同sku

一个主订单必定会生成一个或多个（多种商品）子订单

​ 当通过主订单支付的时候，所有子订单都会变为已支付，如果订单生成，没有支付，则子订单可以挨个分开支付。

​ 主订单支付和子订单支付。

​

product_sku_original_price 追加原价字段

活动是针对sku的直接降价，优惠券是针对子订单及同一件商品的降价

关闭交易（取消订单），条件是未支付的。取消的单位是子订单，不能取消子订单中其中一件sku

分为客户端取消和管理端取消，客户端和管理端的主动取消，还有超时30分钟未支付的自动取消

取消是不需要审核的，直接变更状态

退款

​ 以子订单为单位进行退款，可以退子订单里的一件sku（也就是退部分金额），客户端申请后，由管理后台确认退款（注意退款优惠券相关机制）

促销活动的结束

走延迟队列，时间结束时，自动将活动变更为结束状态

退款文案

您的退款（取消）申请已提交——申请已提交 您的退款（取消）申请已通过——申请已通过 您申请的商品已退款（取消），您使用的优惠券等已返还到您的账户中，请查收——商品已取消 您的退款已到账，请查询到账明细——退款已到账

​