|
|
@@ -20,17 +20,27 @@ Q1:退货需不需要减库存
|
|
|
领劵问题
|
|
|
|
|
|
TODO:
|
|
|
- !.发货清单, 以人分组 勾选货物 形成单子,导出excel
|
|
|
- √.确认收货给积分, 入积分删掉了
|
|
|
- !.团购
|
|
|
+ !.短信验证码+用户主动发验证码,服务接收处理
|
|
|
!.统计
|
|
|
+ √.发货清单, 以人分组 勾选货物 形成单子,导出excel
|
|
|
+ √.收藏店铺/商品: 有条件查询 名称 收藏时间 商品:浏览数
|
|
|
+ √.确认收货给积分, 入积分删掉了
|
|
|
+ √.团购
|
|
|
√.收藏
|
|
|
√.优惠券领取时需要复制,而不是关联
|
|
|
+ √.售后列表:将不同状态分出
|
|
|
+ √.取消订单
|
|
|
+ !.中台:post方法的请求加上loading
|
|
|
+
|
|
|
+ +.退货:考虑多次退货/款的问题
|
|
|
+ +.商品评价
|
|
|
+ +.中台管理:订单管理: 列表: 因为售后和订单详情是拆开且互不影响的. 导致
|
|
|
+ e.g.:1.有的货物在发货前,申请退货,但是订单详情的标识并没有变.仍然可以发货
|
|
|
+ A: 在订单详情查询时,对每个货物进行售后记录的查询,并对每个商品进行标注.让前端进行处理
|
|
|
|
|
|
-.商品详情分享: 返现至我的资产:对商品设置是否返现,返多少 (必须直接买,添加购物车都不行)
|
|
|
- -.其他分享:转首页
|
|
|
- -.发起团购分享: 加团页
|
|
|
|
|
|
+ 定时任务相关:研究mq的死信队列
|
|
|
-.优惠券状态:定时任务
|
|
|
-.未支付订单关闭:定时任务
|
|
|
--.我的资产,提现至微信零钱
|
|
|
@@ -42,3 +52,81 @@ TODO:
|
|
|
退款/货,选择货物后,走 /point/v1/api/afterSale/cgfr 接口查询该商品金额明细,允许输入金额,存在money字段中进行提交
|
|
|
|
|
|
|
|
|
+团购:
|
|
|
+ ※团购不用券,要多少就得交多少
|
|
|
+ 步骤:
|
|
|
+ 1.对规格的设置:
|
|
|
+ 设置该规格是否可以团购
|
|
|
+ 填写团购价
|
|
|
+ 多少人成团
|
|
|
+ 2.用户在页面上选择规格下单时,如果是可以团购的商品,就可以看见团购的按钮(立即团购)
|
|
|
+ 3.商品指定团购页面: 我要开团 下面有 已经开团没满人的 团列表,可以参团
|
|
|
+ 4.开团: 下单->交钱->成功开团: 分享页面
|
|
|
+ 5.参团: 下单->交钱->参团: 等待 接团单
|
|
|
+ 6.团没成功->退钱->团取消掉
|
|
|
+ 7.拼团成功->团单状态改变->发货
|
|
|
+
|
|
|
+ √表:
|
|
|
+ 1.修改规格
|
|
|
+ 2.添加 团表: shop,goods,goodsSpec,,time,
|
|
|
+ 3.修改订单,订单详情=> 添加type(订单类型,默认 常规单;) group(所属团)
|
|
|
+
|
|
|
+ 页面:
|
|
|
+ 1.修改后台页面=>规格, 添加是否团购,团购加个,人数限制
|
|
|
+ 2.商品详情页面添加 立即团购按钮,跳转至团购页
|
|
|
+ 3.新增 团购页: 我要开团(按钮) , 下面列表显示这个商品开的团 可以参团
|
|
|
+ 4.参团/开团 =>选择购买规格,数量 =>进入订单提交(有团购标识) =>下单,付款 ;后续内容就和正常购买一样了
|
|
|
+ 5.商家订单页: 需要标注是否是团购,且团购是否满足发货条件,控制填单号
|
|
|
+
|
|
|
+ 逻辑:
|
|
|
+ 1.不需要改,添加字段不影响逻辑
|
|
|
+ ×2.页面的问题
|
|
|
+ ×3.页面的问题
|
|
|
+
|
|
|
+ ※有关金额问题需要重新计算,因为使用的是不是售价,而是团购价
|
|
|
+ ※有关购买流程的计算部分需要重写,将计算金额的方法统一起来,方便以后改
|
|
|
+
|
|
|
+ 3.1.进入下单页面前,需要检查,如果有团id, 检查当前团是否满足参团条件.不满足则提示
|
|
|
+ 4.修改下单逻辑,如果是团购,需要将 团购类型及团id补全
|
|
|
+ 5.支付完订单后,检查是否满足团购条件:
|
|
|
+ 如果是团长开团,则只存在标识,没有团id:
|
|
|
+ 需要生成团信息,然后将id拿回来补全
|
|
|
+ 如果是团员,则用传来的团id补全
|
|
|
+
|
|
|
+ 1.人数够不够;
|
|
|
+ 2.每个人是否交钱了;
|
|
|
+ √6.满足条件,修改 团 状态为已结束;商家可以发货
|
|
|
+ 7.在团结束前,如果退团,则需要 进行整单取消, 在退货流程中, 如果是团购单,则需要到指定团,将对应的团员修改成退团的状态
|
|
|
+
|
|
|
+ 问题:
|
|
|
+ Q1:因为是先付款,再成团.数据流向也是一样的.但是在支付时,前后端各自处理自己的回调.没有办法实时,准确的获得团id,如果延时大,则无法进入团购分享页.
|
|
|
+ A:先如此处理,等之后需要将 团数据生成时机和订单生成时机进行处理,让支付后一定有团id,保证准确,实时可以跳转至分享页
|
|
|
+
|
|
|
+ 订单详情页,金额问题
|
|
|
+
|
|
|
+
|
|
|
+去下单,生成key
|
|
|
+ util.trade.checkCanBuy 添加接收参数 type, group 为团购的标识并存起来=> 返回key
|
|
|
+进入订单页:
|
|
|
+ 用key取出存的内容,整理数据格式, 计算价格时,需要用不同的价格进行计算
|
|
|
+去支付:
|
|
|
+ 计算部分重新写到util里,生成分单也是
|
|
|
+
|
|
|
+
|
|
|
+统计:
|
|
|
+ // 待办
|
|
|
+ 未付款数, 未发货数, 未处理售后数, 库存警告
|
|
|
+
|
|
|
+ // 统计
|
|
|
+ 平台店铺数量,平台下单总量
|
|
|
+
|
|
|
+ 今日/本周/本月/年度销售额,
|
|
|
+ 今日/本周/本月/年度下单数,
|
|
|
+ 今日/本周/本月/年度付款数,
|
|
|
+ 今日/本周/本月/年度退货数,
|
|
|
+ 今日/本周/本月/年度退款数,
|
|
|
+ 今日/本周/本月/年度换货数,
|
|
|
+
|
|
|
+ 本周下单数,
|
|
|
+ 本周售后数
|
|
|
+
|
