html: embed_local_images: false embed_svg: true offline: false toc: true

print_background: true export_on_save:

html: true

技师端 todolist.md

首页

上下班
实时刷新定位技师经纬度
简单版的个人信息
- --Marked-- 工作照、星星等级、昵称、简介
- 个人信息修改的静态页
- 昵称、手机号（可修改）、身份证、身份证正反面、手持身份证、营业执照、健康证、按摩证、合同
- 跳转到一个升星规则静态页面
- 预览个人主页静态页
昵称固定位置所属店铺星星等级（可跳转星星规则静态页）工作状态简介资质审核状态已完成订单数目取消掉打卡定位
简介的接单设置信息
- 接单时间（排班，讨论）接单距离固定接单位置
- 修改接单设置静态页
- 接单时间（排班，讨论）客户性别接单距离固定接单位置
简洁版项目设置
- 五大类平台定好的项目
- 项目名称时长价格
- 跳转到项目设置静态页
- 展示五个项目的简洁版的信息，每个项目��以进行设置（漏了一个静态页UI）
- 跳转到单个项目设置的静态页
- 项目价格项目名称时长以及项目简单介绍
- 设置的信息
  - 服务客户服务性别代金卷设置（10 20 30 50）免路费设置（单程、双程、全免）
- 项目描述：时长等等，预约须知
我的订单
- 待抢订单待接订单
- 可以跳转到订单列表静态页
- 补充抢单逻辑全部显示抢单池数据，分两类可抢订单排在上面不可抢订单排在下面

技师注册

第一步：用户端申请成为技师填写基本的个人信息
第二步：客服登录后台管理进行审核
- 审核中：申请页面显示正在审核
- 拒绝：可以修改个人信息重新申请
- 通过：申请页面变成切换身份进入技师端
第三步：进入技师端进行支付宝实名认证、上传按摩证、营业执照、健康证、身份证正反面、手持身份证
第四步：客服再次对技师进行审核

第五步：签合同、生活照、工作照、个人简介

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

接单流程（技师角度）

抢单

用户：选项目，点下单
后台：创一个不指定技师的项目订单未支付无技师
技师：点抢单显示全抢单池，不可抢得置灰，可以抢单的正常显示
后台：查询某个技师抢单列表的逻辑，接单设置固定位置、距离、排班、实时位置，项目设置中性别、项目是否开通，开启抢单关闭抢单。按照下单日期倒序排列
技师: 点击立即抢单作出个提示，显示已抢单，等待反选
后台：将当前技师和订单加入抢单池，并记录状态未反选状态
用户:实时显示所有的抢单技师，点击某个技师
后台：在抢单池中记录订单用户反选技师
用户:复用支付流程

技师:消息通知，消息通知静态页

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

涉及表和关键列:

订单表：service_order
- 必填字段：id,order_sn, user_id, user_name,mobile, address,real_address,address_lng,address_lat, adcode, project_id, project_name, project_sub_title,project_icon,service_price, type,status, created_at, updated_at
- 订单类型字段： type
- 0：正常订单
- 1：抢单订单
- 状态机字段：status
- 0：待抢单
用户表： member_user
用户地址表： member_address
项目表： service_project

后台逻辑:

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

2.技师抢单创建抢单池

参数:

user_id, order_id, coach_id
user_id 通过 Auth::id() 获取

涉及表和关键列:

抢单池：service_order_grab
- 必填字段：id, order_id, coach_id, status, created_at, updated_at
- 状态字段：status
- 0：参与抢单
- 1：抢单成功
- 2：抢单失败
订单：service_order
- 必填字段：id,type,status
- 订单类型字段： type
- 0：正常订单
- 1：抢单订单
- 状态字段：status
- 0：待抢单
技师：coach_users
- 字段：user_id, status
- 状态字段：status
- 0：禁用
- 1：正常

后台逻辑:

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

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

参数:

user_id, order_id, coach_id
user_id 通过 Auth::id() 获取

涉及表和关键列:

抢单池：service_order_grab_pool
- 必填字段：id, order_id, coach_id, status, created_at, updated_at
- 状态字段：status
- 0：参与抢单
- 1：抢单成功
- 2：抢单失败
订单：service_order
- 必填字段：id,type,status
- 订单类型字段： type
- 0：正常订单
- 1：抢单订单
- 状态字段：status
- 0：待抢单

后台逻辑:

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

服务流程

技师:技师接单成功显示取消订单开始出发,点开始出发
后台：记录技师开始出发时间，经纬度以及当前位置订单状态变为已出发
用户:显示该订单技师已出发取消订单
技师:点击已到达，并拍照已到达
后台：记录技师经纬度和到达时间订单状态改为已到达
用户:显示已到达显示服务二维码
技师:开始服务方式：扫码用户的服务二维码
后台：订单状态改为服务中
用户:显示倒计时，结束订单确认技师离开再次购买删除订单
技师: 拍单元楼上传拍照结束按钮

后台：订单状态改为服务结束已撤离

sequenceDiagram
participant 用户
participant 后台
participant 技师

技师->>后台: 技师接单成功
后台->>后台: 1. 技师接单
技师-->>技师: 显示 开始出发
技师->>后台: 点开始出发
后台->>后台: 记录技师开始出发时间，经纬度以及当前位置,订单状态变为已出发[^1]
后台-->>用户: 订单状态变为已出发

技师->>后台: 点击已到达，并拍照
后台->>后台: 记录技师经纬度和到达时间,订单状态改为已到达[^2]
后台-->>用户: 订单状态改为已到达

用户-->>用户: 显示状态已到达（显示二维码页面）
技师->>用户: 扫用户的二维码
技师->>后台: 扫码发起开始服务请求
后台->>后台: 订单状态改为 服务中[^3]
用户-->>用户: 显示服务倒计时(自动跳转服务详情页面)

后台-->>用户: 订单状态改为 服务中

用户->>后台: 显示倒计时，点击结束订单
用户->>后台: 在结束订单页面，点击"确认技师离开"
后台-->>技师: 收到订单结束通知
技师->>后台: 拍照，点确认撤离
后台->>后台: 订单状态改为 服务结束[^4]

接单

用户：指定技师下单，立即结算
后台：创建一个新的订单
技师：确认接单
后台：改变订单状态为已接单
用户：已接单
技师：开始出发
后台：改变订单状态为已出发
用户：技师已出发
技师：已到达，拍照
后台：改变订单状态为已到达
用户：已到达，显示二维码
技师：扫描二维码
后台：订单状态改为开始服务
用户：结束订单
后台：订单改为服务结束
用户：确认技师离开
技师：撤离，拍照
后台：自动服务结束
用户：确认技师离开

技师：撤离，拍照

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() 获取

涉及表和关键列:

订单表：service_order
- 必填字段：id,order_sn, user_id, user_name,mobile, address,real_address,address_lng,address_lat, adcode, project_id, project_name, project_sub_title,project_icon,service_price, coach_id, pay_type, type,status, created_at, updated_at
- 订单类型字段： type
- 0：正常订单
- 1：抢单订单
- 状态机字段：status
- 0：待抢单
- 支付类型字段：pay_type
- 0：余额支付
- 1：微信支付
- 2：支付宝支付
- 订单类型：type
- 0：常规订单
- 1：抢单订单
用户表： member_user
- 字段：balance, status
- 状态字段：status
- 0：禁用
- 1：正常
用户地址表： member_address
项目表： service_project
- 字段：id, status
- 状态字段：status
- 0：禁用
- 1：正常
技师表：coach_users
- 字段：user_id, status
- 状态字段：status
- 0：禁用
- 1：正常

后台逻辑:

根据用户编号和地址编号、技师编号查询详情数据，通过项目编号获取项目数据。
- 用户数据存在，并且用户状态为正常
- 地址数据存在
- 项目数据存在，并且项目状态为正常
- 技师数据存在，并且项目状态为正常

通过已上查询的数据，创建订单数据，要求：

请自动填写相同名称的字段
订单类型为常规订单
如果使用余额支付
- 用户余额足够支付项目金额
- 则订单状态为已支付
- 否则订单状态为未支付
如果使用微信支付或支付宝支付
- 订单状态为未支付

指定技师

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[结束]

发送异步抢单通知（比如对接极光推送）

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

参数:

user_id, order_id
user_id 通过 Auth::id() 获取

涉及表和关键列:

订单：service_order
- 必填字段：id,status,coach_id
- 状态字段：status
- 0：未支付
- 1：已支付
- 2：已接单
技师：coach_users
- 字段：user_id, status
- 状态字段：status
- 0：禁用
- 1：正常

后台逻辑:

通过编号查订单，条件是：
- 订单数据存在，并且状态为已支付
- 订单有指派技师，并且技师的用户编号等于参数中的用户编号
- 订单类型为常规订单
通过用户编号查技师，条件是：
- 技师数据存在，并且技师状态为正常
通过以上数据，修改订单数据，要求：
- 请自动填写相同名称的字段
- 订单状态为已接单

发送异步抢单通知（比如对接极光推送）

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. 改变订单状态为已出发(技师端)

参数:

user_id, order_id
user_id 通过 Auth::id() 获取

涉及表和关键列:

订单：service_order
- 必填字段：id,status,coach_id
- 状态字段：status
- 0：未支付
- 1：已支付
- 2：已接单
- 3：已出发
技师：coach_users
- 字段：user_id, status
- 状态字段：status
- 0：禁用
- 1：正常

后台逻辑:

通过编号查订单，条件是：
- 订单数据存在，并且状态为已接单
- 订单有指派技师，并且技师的用户编号等于参数中的用户编号
通过用户编号查技师，条件是：
- 技师数据存在，并且技师状态为正常
通过以上数据，修改订单数据，要求：
- 请自动填写相同名称的字段
- 订单状态为已出发

发送异步抢单通知（比如对接极光推送）

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. 改变订单状态为已到达

参数:

user_id, order_id
user_id 通过 Auth::id() 获取 涉及表和关键列:
订单：service_order
- 必填字段：id,status,coach_id
- 状态字段：status
- 0：未支付
- 1：已支付
- 2：已接单
- 3：已出发
- 4：已到达
技师：coach_users
- 字段：user_id, status
- 状态字段：status
- 0：禁用
- 1：正常

后台逻辑:

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

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

参数:

user_id, order_id
user_id 通过 Auth::id() 获取 涉及表和关键列:
订单：service_order
- 必填字段：id,status,coach_id，time_long
- 状态字段：status
- 0：未支付
- 1：已支付
- 2：已接单
- 3：已出发
- 4：已到达
- 5：服务中
技师：coach_users
- 字段：user_id, status
- 状态字段：status
- 0：禁用
- 1：正常

后台逻辑:

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

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

参数:

user_id, order_id
user_id 通过 Auth::id() 获取 涉及表和关键列:
订单：service_order
- 必填字段：id, status, coach_id, user_end
- 状态字段：status
- 0：未支付
- 1：已支付
- 2：已接单
- 3：已出发
- 4：已到达
- 5：服务中
- 6：服务结束
- 状态字段：user_end
- 0：未结束
- 1：结束

后台逻辑:

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

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

参数:

user_id, order_id
user_id 通过 Auth::id() 获取 涉及表和关键列:
订单：service_order
- 必填字段：id,user_confirm_leave,user_confirm_leave_time
- 用户确认技师撤离字段：user_confirm_leave
- 0：未确认
- 1：已确认
- 状态字段：status
- 0：未支付
- 1：已支付
- 2：已接单
- 3：已出发
- 4：已到达
- 5：服务中
- 6：服务结束 后台逻辑:
通过编号及用户编号查订单，条件是：
- 订单数据存在，并且状态为服务结束
- 订单有指派技师
通过以上数据，修改订单数据，要求：
- 订单用户确认离开
- 订单用户确认离开时间

发送异步抢单通知（比如对接极光推送）

flowchart TD
A[开始] --> B[通过编号及用户编号查订单]
B --> C{订单状态为服务结束?}
C -->|是| D{订单有指派技师?}
C -->|否| Z[结束]
D -->|是| E[修改订单数据]
D -->|否| Z
E --> F[订单用户确认离开]
F --> G[订单用户确认离开时间]
G --> H[发送异步抢单通知]
H --> Z[结束]

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

参数:

order_id 涉及表和关键列:
订单：service_order
- 必填字段：id, end_time
- 用户确认技师撤离字段：user_confirm_leave
- 0：未确认
- 1：已确认
- 状态字段：status
- 0：未支付
- 1：已支付
- 2：已接单
- 3：已出发
- 4：已到达
- 5：服务中
- 6：服务结束
- 7：已撤离
- 8：已评价
- 9：已取消(退款中)
- 10: 已退款

后台逻辑:

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

9. 技师撤离(技师端)

参数:

user_id, order_id
user_id 通过 Auth::id() 获取 涉及表和关键列:
订单：service_order
- 必填字段：id,status,coach_id, user_confirm_leave, leave_time, service_price
- 状态字段：status
- 0：未支付
- 1：已支付
- 2：已接单
- 3：已出发
- 4：已到达
- 5：服务中
- 6：服务结束
- 7：已撤离
- 用户确认技师撤离字段：user_confirm_leave
- 0：未确认
- 1：已确认
收益：member_benefit
- 必填字段：order_id, user_id, benefit, balance, type, created_at, updated_at
- 类型字段：type
- 1：支付
- 2：退款
- 3：扣除
- 4：提现
- 5：返还
- 6：收益
- 8：赠送
- 9：路费
用户：member_users
- 必填字段：id, balance
- 余额字段：balance 后台逻辑:
通过编号查订单，条件是：
- 订单数据存在，并且状态为服务结束
- 订单有指派技师
- 订单用户确认技师撤离为已确认
通过以上数据，开启事务，修改订单数据，创建收益数据
- 修改订单数据，要求：
  - 订单状态为已撤离
  - 订单撤离时间
- 创建收益数据，要求：
  - 收益用户为技师
  - 收益订单为当前订单
  - 收益类型为收益
  - 收益金额为订单服务金额乘以百分之50
  - 收益余额为当前技师用户金额
发送异步抢单通知（比如对接极光推送）

分帐方案优化

背景说明

平台作为服务商，为技师提供订单服务，技师为服务提供者，用户为服务接受者。业务员主要负责推广渠道，渠道用于推广用户，也可以推荐技师加入平台。
店铺是一个综合服务门店：
- 店铺入驻平台，需支付入驻费
- 店铺可以推荐用户下载APP，获取推广费
- 店铺可以推荐技师加入平台，获取推荐费
- 店铺是一个线下服务场所，用户在平台下单后，可以选择到店服务或上门服务
代理基于店铺，代理的业绩基于店铺的业绩，代理的业绩分成基于店铺营业额，代理的业绩提成基于店铺利润
需要设计一个分帐方案，技师、业务员、渠道、店铺、代理和平台之间如何分帐，每种角色的分帐算法不同，分帐基于订单金额或剩余利润
订单完成时，通过平台设置的角色分帐算法和比例，自动计算出每个角色应得的金额，并生成按角色分类的分帐数据表
一个订单上，每个角色可能同时存在，也可能不存在，角色之间是相加关系，不是相乘关系
分帐方案需要灵活，比例需要有配置的地方，方便后续调整
分帐方案需要考虑订单取消、退款情况

分帐业务逻辑

技师上门

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

如果订单上的用户是某个渠道（技师、店铺、业务员等）推广来的，则渠道获得订单项目金额（不含优惠、路费）的百分之几，推广最大2级，第一级渠道获得20%，第二级渠道获得10%

如果订单上的技师是由推荐渠道（店铺、业务员等）推荐的，则推荐渠道获得订单项目金额（不含优惠、路费）的1%。如果推荐渠道为技师，则渠道获得订单金额（不含优惠、路费）的3%，上限为1000元封顶

接单技师作为服务提供者，获得订单项目金额（不含优惠）的50%至55%，路费另算，技师获得90%，平台10%

用户到店

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

用户到店核销完成，店铺获得80%，店铺线下与技师分帐

如果用户是某个渠道（技师、店铺、业务员等）推广来的，则渠道获得与店铺分帐后的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%]

程序设计

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

分帐配置表

字段名	类型	说明
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	更新时间

分帐算法设计

技师上门分帐算法

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

用户到店分帐算法

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

平台技师到店分帐算法

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

分帐逻辑

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

app技师端.md 30 KB

History Raw

html: true

技师端 todolist.md

首页

技师注册

接单流程（技师角度）

抢单

1.创建抢单订单

2.技师抢单创建抢单池

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

服务流程

接单

1. 创建订单

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

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

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

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

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

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

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

9. 技师撤离(技师端)

分帐方案优化

背景说明

分帐业务逻辑

技师上门

用户到店

平台技师到店

程序设计

分帐配置表

分帐数据表

分帐算法设计

技师上门分帐算法

用户到店分帐算法

平台技师到店分帐算法

分帐逻辑

二、下单流程图

分帐及钱包todolist

前端设计稿

平台审核

app技师端.md 30 KB History Raw

html: true

技师端 todolist.md

首页

技师注册

接单流程（技师角度）

抢单

1.创建抢单订单

2.技师抢单创建抢单池

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

服务流程

接单

1. 创建订单

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

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

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

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

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

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

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

9. 技师撤离(技师端)

分帐方案优化

背景说明

分帐业务逻辑

技师上门

用户到店

平台技师到店

程序设计

分帐配置表

分帐数据表

分帐算法设计

技师上门分帐算法

用户到店分帐算法

平台技师到店分帐算法

分帐逻辑

二、下单流程图

分帐及钱包todolist

前端设计稿

平台审核

app技师端.md 30 KB

History Raw