技师端 todolist.md

首页

技师注册

graph TD A[用户端申请成为技师] --> B[客服登录后台管理进行审核] B -->|审核中| C[申请页面显示正在审核] B -->|拒绝| D[可以修改个人信息重新申请] B -->|通过| E[申请页面变成切换身份进入技��端] E --> F[进入技师端] F --> G[支付宝实名认证] G --> H[上传按摩证、营业执照、健康证、身份证正反面、手持身份证,上传生活照、工作照、个人简介] H --> I[客服再次对技师进行审核] I --> J[签合同] J --> Z[初始化项目设置、接单设置默认值，后台]

接单流程（技师角度）

抢单

  1. 用户：选项目，点下单
  2. 后台：创一个不指定技师的项目订单 未支付 无技师
  3. 技师：点抢单 显示全抢单池，不可抢得置灰，可以抢单的正常显示
  4. 后台：查询某个技师抢单列表的逻辑，接单设置固定位置、距离、排班、实时位置，项目设置中性别、项目是否开通，开启抢单 关闭抢单。按照下单日期倒序排列
  5. 技师: 点击立即抢单 作出个提示 ，显示已抢单，等待反选
  6. 后台：将当前技师和订单加入抢单池，并记录状态 未反选状态
  7. 用户:实时显示所有的抢单技师，点击某个技师
  8. 后台：在抢单池中记录订单用户反选技师
  9. 用户:复用支付流程
  10. 技师:消息通知，消息通知静态页
sequenceDiagram participant Alice participant John link Alice: Dashboard @ https://dashboard.contoso.com/alice link Alice: Wiki @ https://wiki.contoso.com/alice link John: Dashboard @ https://dashboard.contoso.com/john link John: Wiki @ https://wiki.contoso.com/john Alice->>John: Hello John, how are you? John-->>Alice: Great! Alice-)John: See you later!
sequenceDiagram participant 用户 participant 后台 participant 技师 autonumber 用户->>+后台: 选项目，点下单 后台->>后台: 1创建抢单订单 后台-->>用户: 订单创建成功 后台->>技师: 显示抢单列表（通过抢单逻辑） 技师->>后台: 点击立即抢单，作出提示 后台->>后台: 2-技师抢单创建抢单池 用户->>后台: 实时显示所有的抢单技师，点击某个技师 后台->>后台: 3.用户反选技师 后台-->>用户: 订单反选成功 用户->>后台: 复用支付流程 后台->>技师: 消息通知

1.创建抢单订单

用户端:

参数:
- user_id, project_id, address_id

涉及表和关键列:

后台逻辑:

  1. 根据用户编号和地址编号查询详情数据，通过项目编号获取项目数据。
    • 用户数据存在，并且用户状态为正常(status = 1)
    • 地址数据存在
    • 项目数据存在，并且项目状态为正常(status = 1)
  2. 通过已上查询的数据，创建订单数据，要求：
    • 请自动填写相同名称的字段
    • type = 1
    • status = 0
  3. 发送异步抢单通知（比如对接极光推送）

2.技师抢单创建抢单池

参数:

涉及表和关键列:

后台逻辑:

  1. 通过编号查订单，条件是：
    • 订单数据存在，并且状态为待抢单
    • 订单没有指派技师
    • 订单类型为抢单订单
  2. 通过用户编号查技师，条件是：
    • 技师数据存在，并且技师状态为正常
  3. 通过以上数据，创建订单池，要求：
    • 请自动填写相同名称的字段
    • 订单池状态为参与抢单
  4. 发送异步抢单通知（比如对接极光推送）

3. 用户反选技师(指定抢单池)

参数:

涉及表和关键列:

后台逻辑:

  1. 通过编号查订单，条件是：
    • 订单数据存在，并且状态为待抢单
    • 订单没有指派技师
    • 订单类型为抢单订单
  2. 通过编号查技师，条件是：
    • 技师数据存在，并且技师状态为正常
  3. 通过以上数据，修改订单池，要求：
    • 技师编号来自参数
    • 订单池状态改为抢单成功
  4. 发送异步抢单通知（比如对接极光推送）

服务流程

  1. 技师:技师接单成功 显示 取消订单 开始出发,点开始出发
  2. 后台：记录技师开始出发时间，经纬度以及当前位置 订单状态变为已出发
  3. 用户:显示该订单技师已出发 取消订单
  4. 技师:点击已到达，并拍照 已到达
  5. 后台：记录技师经纬度和到达时间 订单状态改为已到达
  6. 用户:显示已到达显示服务二维码
  7. 技师:开始服务方式：扫码用户的服务二维码
  8. 后台：订单状态改为 服务中
  9. 用户:显示倒计时，结束订单 确认技师离开 再次购买 删除订单
  10. 技师: 拍单元楼上传 拍照结束 按钮
  11. 后台：订单状态改为 服务结束 已撤离
sequenceDiagram participant 用户 participant 后台 participant 技师 技师->>后台: 技师接单成功 后台->>后台: 1. 技师接单 技师-->>技师: 显示 开始出发 技师->>后台: 点开始出发 后台->>后台: 记录技师开始出发时间，经纬度以及当前位置,订单状态变为已出发[^1] 后台-->>用户: 订单状态变为已出发 技师->>后台: 点击已到达，并拍照 后台->>后台: 记录技师经纬度和到达时间,订单状态改为已到达[^2] 后台-->>用户: 订单状态改为已到达 用户-->>用户: 显示状态已到达（显示二维码页面） 技师->>用户: 扫用户的二维码 技师->>后台: 扫码发起开始服务请求 后台->>后台: 订单状态改为 服务中[^3] 用户-->>用户: 显示服务倒计时(自动跳转服务详情页面) 后台-->>用户: 订单状态改为 服务中 用户->>后台: 显示倒计时，点击结束订单 用户->>后台: 在结束订单页面，点击"确认技师离开" 后台-->>技师: 收到订单结束通知 技师->>后台: 拍照，点确认撤离 后台->>后台: 订单状态改为 服务结束[^4]

接单

  1. 用户： 指定技师下单，立即结算
  2. 后台： 创建一个新的订单
  3. 技师： 确认接单
  4. 后台： 改变订单状态为已接单
  5. 用户： 已接单
  6. 技师： 开始出发
  7. 后台： 改变订单状态为已出发
  8. 用户： 技师已出发
  9. 技师： 已到达，拍照
  10. 后台： 改变订单状态为已到达
  11. 用户： 已到达，显示二维码
  12. 技师： 扫描二维码
  13. 后台： 订单状态改为开始服务
  14. 用户： 结束订单
  15. 后台： 订单改为服务结束
  16. 用户： 确认技师离开
  17. 技师： 撤离，拍照
  18. 后台： 自动服务结束
  19. 用户： 确认技师离开
  20. 技师： 撤离，拍照
sequenceDiagram participant 用户 participant 后台 participant 技师 用户->>后台: 指定技师下单，点击立即结算 后台->>后台: 1. 创建订单 后台-->>用户: 订单创建成功 技师->>后台: 确认接单 后台->>后台: 2. 改变订单状态为已接单 后台-->>用户: 订单状态变为已接单 技师->>后台: 开始出发 后台->>后台: 3. 改变订单状态为已出发 后台-->>用户: 订单状态变为已出发 技师->>后台: 已到达，拍照 后台->>后台: 4. 改变订单状态为已到达 后台-->>用户: 订单状态变为已到达 用户->>用户: 已到达，显示二维码 技师->>用户: 扫描二维码 后台->>后台: 5. 订单状态改为服务中 后台-->>用户: 订单状态变为服务中 后台-->>技师: 订单状态变为服务中 用户->>后台: 第一种：结束订单 后台->>后台: 6. 订单改为服务结束 后台-->>技师: 订单改为服务结束 后台-->>用户: 订单状态变为服务结束 用户->>用户: 确认技师离开 用户->>后台: 技师离开 后台->>后台: 7.订单更改状态为技师离开 技师->>后台: 点击撤离，拍照 后台->>后台: 8. 第二种：服务时间结束 后台-->>用户: 服务结束 后台-->>技师: 服务结束 用户->>后台: 确认技师离开 技师->>后台: 撤离，拍照 后台->>后台: 9. 技师撤离 后台-->>用户: 技师撤离 订单完成 后台-->>技师: 技师撤离 订单完成

1. 创建订单

参数:
- user_id, project_id, address_id, coach_id, pay_type, is_balance
- user_id 通过 Auth::id() 获取

涉及表和关键列:

后台逻辑:

  1. 根据用户编号和地址编号、技师编号查询详情数据，通过项目编号获取项目数据。
    • 用户数据存在，并且用户状态为正常
    • 地址数据存在
    • 项目数据存在，并且项目状态为正常
    • 技师数据存在，并且项目状态为正常
  2. 通过已上查询的数据，创建订单数据，要求：
    • 请自动填写相同名称的字段
    • 订单类型为常规订单
    • 如果使用余额支付
      • 用户余额足够支付项目金额
        • 则订单状态为已支付
        • 否则订单状态为未支付
    • 如果使用微信支付或支付宝支付
      • 订单状态为未支付
    • 指定技师
flowchart TD A[开始] --> B[获取用户数据] B --> C{用户状态正常?} C -->|是| D[获取地址数据] C -->|否| Z[结束] D --> E[获取项目数据] E --> F{项目状态正常?} F -->|是| G[获取技师数据] F -->|否| Z G --> H{技师状态正常?} H -->|是| I[创建订单] H -->|否| Z I --> J{支付类型} J -->|余额支付| K{余额足够?} J -->|微信支付或支付宝支付| M[订单状态: 未支付] K -->|是| L[订单状态: 已支付] K -->|否| M L --> N[指定技师] M --> N N --> O[发送异步抢单通知] O --> Z[结束]
  1. 发送异步抢单通知（比如对接极光推送）

2. 改变订单状态为已接单(技师端)

参数:

涉及表和关键列:

后台逻辑:

  1. 通过编号查订单，条件是：
    • 订单数据存在，并且状态为已支付
    • 订单有指派技师，并且技师的用户编号等于参数中的用户编号
    • 订单类型为常规订单
  2. 通过用户编号查技师，条件是：
    • 技师数据存在，并且技师状态为正常
  3. 通过以上数据，修改订单数据，要求：
    • 请自动填写相同名称的字段
    • 订单状态为已接单
  4. 发送异步抢单通知（比如对接极光推送）
flowchart TD A[开始] --> B[通过编号查订单] B --> C{订单状态为已支付?} C -->|是| D{订单有指派技师?} C -->|否| Z[结束] D -->|是| E{技师用户编号匹配?} D -->|否| Z E -->|是| F[通过用户编号查技师] E -->|否| Z F --> G{技师状态为正常?} G -->|是| H[修改订单数据] G -->|否| Z H --> I[订单状态改为已接单] I --> J[发送异步抢单通知] J --> Z[结束]

3. 改变订单状态为已出发(技师端)

参数:

涉及表和关键列:

后台逻辑:

  1. 通过编号查订单，条件是：
    • 订单数据存在，并且状态为已接单
    • 订单有指派技师，并且技师的用户编号等于参数中的用户编号
  2. 通过用户编号查技师，条件是：
    • 技师数据存在，并且技师状态为正常
  3. 通过以上数据，修改订单数据，要求：
    • 请自动填写相同名称的字段
    • 订单状态为已出发
  4. 发送异步抢单通知（比如对接极光推送）
flowchart TD A[开始] --> B[通过编号查订单] B --> C{订单状态为已接单?} C -->|是| D{订单有指派技师?} C -->|否| Z[结束] D -->|是| E{技师用户编号匹配?} D -->|否| Z E -->|是| F[通过用户编号查技师] E -->|否| Z F --> G{技师状态为正常?} G -->|是| H[修改订单数据] G -->|否| Z H --> I[订单状态改为已出发] I --> J[发送异步抢单通知] J --> Z[结束]

4. 改变订单状态为已到达

参数:

后台逻辑:

  1. 通过编号查订单，条件是：
    • 订单数据存在，并且状态为已出发
    • 订单有指派技师，并且技师的用户编号等于参数中的用户编号
  2. 通过用户编号查技师，条件是：
    • 技师数据存在，并且技师状态为正常
  3. 通过以上数据，修改订单数据，要求：
    • 请自动填写相同名称的字段
    • 订单状态为已到达
  4. 发送异步抢单通知（比如对接极光推送）

5. 订单状态改为服务中(技师端)

参数:

后台逻辑:

  1. 通过编号查订单，条件是：
    • 订单数据存在，并且状态为已到达
    • 订单有指派技师，并且技师的用户编号等于参数中的用户编号
  2. 通过用户编号查技师，条件是：
    • 技师数据存在，并且技师状态为正常
  3. 通过以上数据，修改订单数据，要求：
    • 请自动填写相同名称的字段
    • 订单状态为服务中
    • 订单服务开始时间
    • 根据服务时长计算订单服务结束时间
  4. 发送异步抢单通知（比如对接极光推送）

6. 订单改为服务结束(用户端结束订单)

参数:

后台逻辑:

  1. 通过编号及用户编号查订单，条件是：
    • 订单数据存在，并且状态为服务中
    • 订单有指派技师
  2. 通过以上数据，修改订单数据，要求：
    • 订单状态为服务结束
    • 订单服务结束时间
    • 用户确认结束
  3. 发送异步抢单通知（比如对接极光推送）

7. 订单更改状态为技师离开(用户端确认技师离开)

参数:

  1. 通过编号及用户编号查订单，条件是：
    • 订单数据存在，并且状态为服务结束
    • 订单有指派技师
  2. 通过以上数据，修改订单数据，要求：
    • 订单用户确认离开
    • 订单用户确认离开时间
  3. 发送异步抢单通知（比如对接极光推送）
flowchart TD A[开始] --> B[通过编号及用户编号查订单] B --> C{订单状态为服务结束?} C -->|是| D{订单有指派技师?} C -->|否| Z[结束] D -->|是| E[修改订单数据] D -->|否| Z E --> F[订单用户确认离开] F --> G[订单用户确认离开时间] G --> H[发送异步抢单通知] H --> Z[结束]

8. 第二种：服务时间结束(后台自动服务结束)

参数:

后台逻辑:

  1. 通过编号查订单，条件是：
    • 订单数据存在，并且状态为服务中
    • 订单有指派技师
  2. 通过订单服务结束时间，判断是否结束
    • 如果服务结束时间小于等于当前时间，则订单状态为服务结束
  3. 发送异步抢单通知（比如对接极光推送）

9. 技师撤离(技师端)

参数:

  1. 通过编号查订单，条件是：
    • 订单数据存在，并且状态为服务结束
    • 订单有指派技师
    • 订单用户确认技师撤离为已确认
  2. 通过以上数据，开启事务，修改订单数据，创建收益数据
    • 修改订单数据，要求：
      • 订单状态为已撤离
      • 订单撤离时间
    • 创建收益数据，要求：
      • 收益用户为技师
      • 收益订单为当前订单
      • 收益类型为收益
      • 收益金额为订单服务金额乘以百分之50
      • 收益余额为当前技师用户金额
  3. 发送异步抢单通知（比如对接极光推送）

分帐方案优化

背景说明

分帐业务逻辑

技师上门

技师通过平台接单，到用户指定地点提供服务

  1. 如果订单上的用户是某个渠道（技师、店铺、业务员等）推广来的，则渠道获得订单项目金额（不含优惠、路费）的百分之几，推广最大2级，第一级渠道获得20%，第二级渠道获得10%
  2. 如果订单上的技师是由推荐渠道（店铺、业务员等）推荐的，则推荐渠道获得订单项目金额（不含优惠、路费）的1%。如果推荐渠道为技师，则渠道获得订单金额（不含优惠、路费）的3%，上限为1000元封顶
  3. 接单技师作为服务提供者，获得订单项目金额（不含优惠）的50%至55%，路费另算，技师获得90%，平台10%

用户到店

用户通过平台下单，选择店铺中的技师，或直接选择店铺服务项目，到店消费

  1. 用户到店核销完成，店铺获得80%，店铺线下与技师分帐
  2. 如果用户是某个渠道（技师、店铺、业务员等）推广来的，则渠道获得与店铺分帐后的20%中的10%

平台技师到店

救急订单，调技师去店铺，用户到店消费，店铺替到店客户下单

如果店铺技师不足，则店铺在平台正常下单，且技师为平台技师（非店铺自有技师），店铺创建的订单可设置报销路费或不报销路费，技师到店核销后，平台从店铺余额中扣除此订单服务费价格的10%

flowchart TD A[技师上门] --> B[用户是渠道推广] B --> C{推广级别} C -->|第一级| D[渠道获得20%] C -->|第二级| E[渠道获得10%] A --> F[技师由推荐渠道推荐] F --> G{推荐渠道类型} G -->|店铺/业务员| H[推荐渠道获得1%] G -->|技师| I[推荐渠道获得3% 上限1000元] A --> J[接单技师] J --> K[技师获得50%至55%] K --> L[路费技师获得90% 平台10%]
flowchart TD M[用户到店] --> N[订单有店铺] N --> O[店铺获得80%] O --> P[店铺线下与技师分帐] M --> Q[用户是渠道推广] Q --> R[渠道获得店铺分帐后20%中的10%]
flowchart TD S[平台技师到店] --> T[店铺技师不足] T --> U[店铺正常下单] U --> V{路费设置} V -->|报销| W[店铺订单核销后] V -->|不报销| W W --> X[平台从店铺余额中扣除10%]

程序设计

  1. 创建分帐配置表，存储各角色的分帐比例和算法
  2. 创建分帐数据表，存储每个订单的分帐结果
  3. 在订单完成时，调用分帐逻辑，计算各角色应得金额，并写入分帐数据表
  4. 考虑订单取消和退款情况，调整分帐数据

分帐配置表

字段名 类型 说明
id int 主键
role string 角色
percentage decimal 分帐比例
algorithm string 分帐算法
created_at datetime 创建时间
updated_at datetime 更新时间

分帐数据表

字段名 类型 说明
id int 主键
order_id int 订单ID
role string 角色
amount decimal 分帐金额
created_at datetime 创建时间
updated_at datetime 更新时间

分帐算法设计

技师上门分帐算法

  1. 获取订单项目金额（不含优惠、路费）
  2. 计算渠道推广分成：
    • 第一级渠道：订单项目金额 * 20%
    • 第二级渠道：订单项目金额 * 10%
  3. 计算推荐渠道分成：
    • 推荐渠道：订单项目金额 * 1%
    • 如果推荐渠道为技师：订单项目金额 * 3%，上限1000元
  4. 计算技师分成：
    • 技师：订单项目金额 * 50%至55%
    • 路费：技师获得90%，平台10%

用户到店分帐算法

  1. 获取订单项目金额（不含优惠、路费）
  2. 计算店铺分成：
    • 店铺：订单项目金额 * 80%
  3. 计算渠道推广分成：
    • 渠道：店铺分成后的20%中的10%

平台技师到店分帐算法

  1. 获取订单项目金额（不含优惠、路费）
  2. 计算分成：
    • 平台：订单项目金额 * 10%

分帐逻辑

  1. 获取订单信息，判断订单状态是否为完成
  2. 根据订单信息，获取相关角色（技师、店铺、渠道等）
  3. 根据分帐配置表，计算各角色应得金额
  4. 将计算结果写入分帐数据表
  5. 如果订单取消或退款，调整分帐数据

二、下单流程图

下单流程图

项目下单反选技师流程图

graph TD A[项目下单反选技师] --> B{是否反选技师?} B -->|没反选技师| C{有技师抢单?} B -->|反选技师| D[用户锁定技师] C -->|没有技师抢单| E{客服介入?} C -->|有技师抢单但客户没去反选| F[半小时后自动取消订单] E -->|是| G[指定可接单技师服务] E -->|否| H[半小时后自动取消订单] F --> I[技师端不显示订单] F --> J[用户端保留订单] J --> K[再次购买直接进入反选技师页面] D --> L{三分钟内付款?} L -->|是| M[正常订单流程] L -->|否| N[技师自动释放] M --> O[技师显示为忙碌中] N --> P[用户可再次锁定和付款] D --> Q[其他用户可见技师,显示已被锁] D --> R[正常订单不可选该技师] S[技师角度:被锁定] --> T{用户是否付款?} T -->|未付款| U[可抢其他订单] T -->|已付款| V[不可抢单,显示忙碌中] W[技师角度:未被锁] --> X[可抢任何订单] W --> Y[可被正常订单选择] Y --> Z[下单成功后显示忙碌中]

分帐及钱包todolist 

EntryNotFound (FileSystemError): Error: ENOENT: no such file or directory, open 'd:\didong\系统设计\详细设计\分帐及钱包todolist.md'

前端设计稿

平台审核

技师端 todolist.md

首页

技师注册

接单流程（技师角度）

分帐方案优化

二、下单流程图

下单流程图

项目下单反选技师流程图

分帐及钱包todolist
≡