技师端 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