quickstart.md 4.5 KB

Quickstart: 商家自配送 (029) 验证指南

Date: 2026-09-08 | 前置:data-model.md 的 SQL 已由开发者手动执行、测试库可用、应用可启动(JAVA_HOME=C:\Users\qmj\.jdks\graalvm-jdk-21.0.7)。

记住项目验证纪律:mvn compile 通过 ≠ 可部署。改完 mapper XML 需 python -c "import xml.etree.ElementTree as ET; ET.parse(...)" 校验;核心链路变更需启动冒烟。本功能无 mapper XML 变更(新表走 MyBatis-Plus BaseMapper),冒烟以接口级验证为准。

场景 1:时段判定单测(不开服务即可跑)

# ruoyi-admin 下运行 SelfDeliveryUtil 测试
mvn -pl ruoyi-admin test -Dtest=SelfDeliveryUtilTest

预期全绿,覆盖:

  • [开始,结束) 边界:18:00:00 整命中、21:00:00 整不命中
  • 按星期:周一 18:00-21:00 的配置,周二同时刻不命中
  • 多段命中:任一段命中即命中
  • 全天模式:任意时刻命中
  • 预约单跨天:预约次日 12:00 按次日的星期+时刻判定

场景 2:配置读写与权限

# 普通商家保存(token 为商家登录 token)
curl -X POST http://localhost:8080/chanting/store/saveMdSelfDeliveryHours \
  -H "token: <商家token>" -H "Content-Type: application/json" \
  -d '{"mdId":<门店id>,"enabled":true,"mode":2,"hours":[{"dayOfWeek":5,"startTime":"18:00","endTime":"21:00"}]}'
# 读取核对
curl "http://localhost:8080/chanting/store/getMdSelfDeliveryHours?mdId=<门店id>" -H "token: <商家token>"

预期:保存成功;读回一致。再用摊位主 token 对摊位 mdId 保存 → 拒绝("摊位配送方式由夜市主统一设置")。用夜市主 token 对夜市主门店行保存 → 成功,旗下摊位 getMdSelfDeliveryHours 返回夜市配置。

场景 3:下单快照 + 骑手池隔离(spec SC-001)

  1. 配置门店当天时段覆盖"现在",下一笔即时外送单(用户端 createOrder)并支付
  2. 查库:SELECT self_delivery FROM pos_order WHERE dd_id='...' → 1
  3. 骑手 token 调 GET /system/orderQsOprate/orderList?tab=newTask → 列表无此单
  4. 骑手 token 直调 GET /system/orderQsOprate/acceptOrder?id=<订单id> → 拒绝(非自配送可接单的报错)
  5. 配置时段改为已过去的时间再下一单 → self_delivery=0 且出现在 newTask 池

场景 4:预约单按预约时间判定

时段设 18:00-21:00;下午 15:00 下单预约当天 19:00 送达(delryTime)→ self_delivery=1;预约次日 12:00 → self_delivery=0。

场景 5:商家配送流转 + 结算(spec SC-002/SC-004)

对一笔 self_delivery=1 的已支付单,用商家 token:

curl -X POST http://localhost:8080/system/orderShOprate/acceptOrder?id=<id> -H "token: <商家token>"
curl -X POST http://localhost:8080/system/orderShOprate/dispatchOrder?id=<id> -H "token: <商家token>"   # 出餐
curl -X POST http://localhost:8080/system/orderShOprate/selfDeliveryComplete -H "token: <商家token>" \
  -H "Content-Type: application/json" -d '{"id":<id>}'

预期:

  • 接单/出餐不再被"等待骑手接单"拦截(现状会拦,research F2)
  • 送达后 state=3, delivery_status=3, sd_time 非空
  • 账单核对(SQL):
    • SELECT * FROM user_billing WHERE dd_id='<ddId>' AND type='5' → 一条,user_id=sh_id、amount=freight 全额、divvy=0
    • type='0' AND user_id=sh_id(商品分成)照常存在
    • 不存在 user_id 为骑手的运费分成记录
  • 夜市摊位单重复场景:type='5' 的 user_id=夜市主 userId
  • 到付单(collectPayment=1)送达后:type='3' 用户账单 payment_id=sh_id
  • 用户收到出餐/送达推送(自配论文案),骑手无任何推送

场景 6:开始配送为可选(clarify Q3)

  • 跳过 selfDeliveryStart 直接 selfDeliveryComplete → 成功,用户端状态由备餐直达已送达
  • 调用 selfDeliveryStart 后重复调用 → 拒绝(状态校验)
  • state=1(未出餐)时调 selfDeliveryComplete → 拒绝

场景 7:商家端 PC(foodie-store)

  1. 门店信息页:开关/全天/自定义星期时段编辑保存,重新进入显示一致(四语言切换文案正确)
  2. 订单列表/详情:自配送单显示"自配送"标签
  3. 摊位主登录:门店信息无自配送编辑入口

场景 8:快照不回滚(spec Edge Cases)

订单已判 self_delivery=1 后,关闭门店自配送开关 → 该单仍按自配送流转(selfDeliveryComplete 可用);之后的新单 self_delivery=0 进骑手池。