月度考核业务逻辑

摘要

#	大纲项	一句话表达
1	一、核心目标	30天内完成规定去平业绩的P5/P6/P7用户获得团队收益，否则停发以激励产能提升。
2	二、核心概念	P5/P6/P7分别需完成≥1500/3500/7000 USDT新增去平业绩，以支付时间计30天为一个周期。
3	三、月度考核执行流程	日均执行的脚本查询待考核用户，统计去平业绩，与标准比对后判定通过/未通过并存储结果。
4	四、升级时的考核处理	升级用户自动通过当期考核，重置新等级的新周期；V8+无需考核则删除周期记录。
5	五、团队收益发放中的考核应用	普通用户无需考核，V8/V9必发，P5/P6/P7需通过当期月度考核才能发放团队收益。
6	六、业务流程时间线	Day 0升级开始30天周期，Day 31结算判定，Day 31-59为延期期继续考核，Day 60进入下一周期。
7	七、多次考核与失败处理	未通过在29天延期期内可继续考核累积失败次数，超期进入新周期重新开始，升级会中断当期并重置周期。

一、核心目标

月度考核是针对P5/P6/P7等级用户（Level=2/3/4）的收益激励制度。

核心逻辑：用户需要在30天内完成一定金额的新增去平业绩，才能获得团队收益；否则停发团队收益以激励产能提升。

考核结果	后续处理
考核通过	用户可以正常获得团队收益 ✓
考核未通过	用户停发团队收益，激励产能提升 ✗

二、核心概念

用户等级与考核标准

等级	代码	名称	考核要求	说明
1	Level=1	普通用户	无	不需考核
2	Level=2	P5	新增去平业绩 ≥ 1500 USDT	需月度考核
3	Level=3	P6	新增去平业绩 ≥ 3500 USDT	需月度考核
4	Level=4	P7	新增去平业绩 ≥ 7000 USDT	需月度考核
5	Level=5	V8	无	不需考核，必发
6	Level=6	V9	无	不需考核，必发

考核周期的时间点

考核周期为30天，包含以下关键时间节点：

时间点	含义	说明
kaohe_start	考核周期开始	升级当天0点或下一周期开始
kaohe_end	考核周期结束	start + 30天（统计截止）
kaohe_oper_start	结算判定时间	等于kaohe_end，第31天开始执行考核脚本
next_pre_start	下期预计开始	若本期通过，进入新周期
next_pre_end	下期预计结束	下期周期的结束时间

考核标准对照（基于 month_delta）：

P5 (Level=2)：≥ 1500 USDT
P6 (Level=3)：≥ 3500 USDT
P7 (Level=4)：≥ 7000 USDT

时间线示意：

Day 0（升级当天）
  ↓ 初始化 30 天考核周期
Day 1-30（考核周期内）
  ↓ 统计去平业绩
Day 31（结算日）
  ↓ 执行考核脚本 → 判定通过/未通过
Day 31+（进入新周期或延期）

去平业绩的定义

去平指在关系链中等级上升的节点。统计规则如下：

直接去平：下单人的直推上级等级 < 下单人等级 → 该上级为去平角色，其订单计入考核业绩
直推人必算：即使直推人等级不高，其作为直推人身份，下单金额也计入被推荐人的考核业绩
统计范围：
- 只统计 gid=2 或 3（新增理财hash交易订单）
- 时间范围：kaohe_start ≤ pay_time < kaohe_end
- 支付状态：state=2（已支付）、status=1（启用）、expired=1（未过期）

三、月度考核执行流程

执行时机

每日 00:00 执行（Crontab）
命令：php yii invest/month-kaohe/do
日志：backend/web/logs/console/invest-month-kaohe-console.log

执行步骤

Step 1：获取待考核用户

查询符合以下条件的用户：

kaohe_oper_start ≤ 当前时间（已到考核结算时间）
status = 1（考核周期有效）
level IN (2,3,4)（P5/P6/P7用户）

输出统计：考核系统总人数、本期实际考核用户数、每个用户的考核周期范围。

Step 2：查询有效订单

建立有效订单映射表（基础数据）：

游标分页查询 FtgInvestJoinOrder（每批2000条）
过滤条件：state=2、status=1、expired=1、person_stage<364、gid IN(2,3)

Step 3：统计去平业绩

对每个升级订单执行以下逻辑：

验证 order_id 是否在有效订单集合中
解析 all_relations 关系链
遍历关系链中的每个节点，判断是否为去平角色
累加去平业绩（使用 bcadd，保留6位小数）

核心算法：基于 all_relations 链的等级逐层比对，找出真正产生等级提升的节点。

Step 4：结果判定

将统计的去平业绩与考核标准比对：

等级	标准金额	结果
P5(L=2)	≥ 1500 USDT	通过(pass=2) / 未通过(pass=1)
P6(L=3)	≥ 3500 USDT	通过(pass=2) / 未通过(pass=1)
P7(L=4)	≥ 7000 USDT	通过(pass=2) / 未通过(pass=1)

使用 bccomp(考核业绩, 标准金额, 6) 进行精确比较。

Step 5：结果存储

写入 FtgInvestJoinNewP567kaohe 表（考核结果）
写入 FtgInvestJoinNewP567kaohePeriodLog 表（历史日志）
更新 FtgInvestJoinNewP567kaohePeriod 表（周期主表）

Step 6：执行统计

输出以下统计信息：

考核系统用户总人数 / 有效用户人数
本期实际考核用户数
实际通过人数 / 实际未通过人数
本次执行时间（秒）
有效订单总数
关系链订单总数
CPU计算次数

按等级分类（P5/P6/P7）：
  - 考核人数
  - 通过人数
  - 未通过人数

四、升级时的考核处理

业务逻辑

当用户因业绩达标而升级时：

入口：FtgInvestUpgradeService::updateYejiAndUpgrade()
流程：批量计算用户等级并执行升级
触发：对升级用户调用 MonthKaoheService::upgradeUserMonthKaohe()
结果：重置考核周期、设置新的考核目标

升级路径与处理方式

路径1：普通用户升至P5（1→2）

初始化新的30天考核周期：

kaohe_start = 今天0点
kaohe_end = 今天0点 + 30天
kaohe_oper_start = kaohe_end
next_pre_start = kaohe_end
next_pre_end = next_pre_start + 30天
pass = 1（初始状态：未通过）

意义：新获得P5资格的用户获得第一个30天的考核周期。

路径2：P5升至P6 或 P6升至P7（2→3 或 3→4）

处理三个步骤：

备份当期：将当前周期备份到历史日志表，标记 pass=2（因升级通过）
重置周期：创建新等级的新周期，重新30天
更新结果表：设置考核结果表 pass=2

意义：

升级优先级高于考核周期（即使考核未结束也可升级）
升级自动通过当期考核（鼓励产能提升）
进入新等级后重新开始30天考核周期

路径3：P7升至V8（4→5）

处理三个步骤：

备份当期：将当前周期备份到历史日志表，标记 pass=2（因升级通过）
删除周期记录：删除 FtgInvestJoinNewP567kaohePeriod 记录
更新结果表：设置考核结果表 pass=2

意义：

V8及以上用户不需要月度考核
享受终身分润发放权利
删除周期记录，不再需要考核管理

五、团队收益发放中的考核应用

执行时机

每天 07:00 执行（Crontab）
命令：php yii invest/income-team/send
日志：backend/web/logs/console/invest-income-team-console.log

发放条件判定逻辑

等级5、6（V8/V9）

条件：无需考核行为：必发团队收益 ✓

等级1（普通用户）

检查项目（不检查业绩，不检查月度考核）：

检查项	条件	失败原因
有效订单	state=2, status=1, expired=1, person_stage<days	无订单 ✗
业绩标准	无要求	跳过 ✓
月度考核	无要求	跳过 ✓
分润开关	t_in == 2	关闭 ✗

判定结果：有效订单和分润开关都通过 → 发放 ✓；任一项未通过 → 停发 ✗

等级2、3、4（P5/P6/P7）

优先检查：是否在免考核期？

YES → 直接发放 ✓
NO → 进行四项检查

四项检查内容：

检查项	条件	失败原因
有效订单	state=2, status=1, expired=1, person_stage<days	无订单 ✗
业绩标准	个人/团队业绩符合等级要求	不符 ✗
月度考核	MonthKaoheService::isMonthKaohePass()=true	未通过 ✗
分润开关	t_in == 2	关闭 ✗

判定结果：四项全部通过 → 发放 ✓；任一项未通过 → 停发 ✗

停发原因分类

对于P5/P6/P7用户，停发的四个主要原因：

原因代码	原因描述	说明
1	无订单	用户没有有效订单
2	业绩不符	个人或团队业绩未达标
3	月度考核	考核未通过（考核机制体现）
4	分润开关	用户关闭了分润

六、业务流程时间线

完整的30天周期流程

Day 0（升级当天）
├─ 订单支付成功
├─ 业绩累计 → 触发升级判断
├─ FtgInvestUpgradeService::updateYejiAndUpgrade()
└─ MonthKaoheService::upgradeUserMonthKaohe()
   ├─ 初始化考核周期
   ├─ kaohe_start = 今天0点
   ├─ kaohe_end = 今天0点 + 30天
   └─ kaohe_oper_start = kaohe_end

Day 1-29（考核周期内）
└─ 用户在关系链中产生的订单 → 统计为"去平业绩"

Day 30（考核周期结束）
└─ 这是最后统计去平业绩的一天

Day 31（结算日，关键时刻）
├─ 00:00 执行考核脚本 → MonthKaoheController::actionDo()
│  ├─ 查询条件：kaohe_oper_start ≤ 当前时间
│  ├─ 统计用户考核周期内的去平业绩
│  ├─ 与标准比对
│  └─ 写入考核结果（pass=1 or pass=2）
│
├─ 07:00 执行团队收益发放 → IncomeTeamController::actionSend()
│  ├─ MonthKaoheService::isMonthKaohePass($uid)
│  ├─ 查询考核结果
│  └─ 判断是否发放团队收益
│
└─ 用户进入新的30天考核周期（next_pre_start）

Day 32-60
└─ 下一个考核周期的进行

Day 60-61
└─ 下一个考核周期的结算

关键时间数学关系

时间段	说明
Day 0 - Day 30	第1个考核周期（30天）
Day 31 - Day 59	延期考核期（29天，机会期）
Day 60+	第2个考核周期开始
总计	Day 0-59共59天

七、多次考核与失败处理

考核通过的流程

触发条件：用户去平业绩 ≥ 考核标准

处理步骤：

更新考核结果表
- FtgInvestJoinNewP567kaohe.pass = 2
备份当期周期到历史日志
- FtgInvestJoinNewP567kaohePeriodLog
- pass = 2（通过）
- pass_end = 当前日期
- detail = 本期考核详情
重置为下一个周期
- kaohe_start = 通过当天0点（可能小于30天）
- kaohe_end = next_pre_end（下期计划结束）
- kaohe_oper_start = kaohe_end（下次结算时间）
- fail_cnt = 0（重置失败次数）
- pass = 1（新周期重置为未通过）

考核未通过的两种情况

情况1：延期考核期内（Day 31-59）

触发条件：

去平业绩 < 考核标准
距离 kaohe_oper_start < 29天
用户仍有继续考核的机会

处理方式：

pass = 1（保持未通过）
fail_cnt += 1（失败次数+1）
today_kaohe_detail = 本次考核数据

结果：

用户继续处于 pass=1 状态
MonthKaoheService::isMonthKaohePass() 返回 false
团队收益继续停发
等待下一个考核日期重新考核

示例数据变化：

时间	fail_cnt	状态	发放
Day 31	1	第一次未通过	停发 ✗
Day 40	2	第二次未通过	停发 ✗
Day 50	3	第三次未通过	停发 ✗
Day 60	4	第四次未通过 → 进入情况2	停发 ✗

情况2：已超过29天延期期（Day 60+）

触发条件：

去平业绩 < 考核标准
距离 kaohe_oper_start ≥ 29天
已给足30+29=59天的机会，必须进入新周期

处理方式：

Step 1：备份到历史日志表
  pass = 1（最终未通过）
  pass_end = 0（不设置通过时间，表示未通过）
  detail = 最后一次考核数据

Step 2：重置周期进入下一个循环
  level = 当前等级（保持）
  pass = 1（重置为未通过）
  fail_cnt = 0（重置失败次数）
  kaohe_start = 今天0点
  kaohe_end = next_pre_end（原计划的下期结束）
  next_pre_end += 30天（继续推进）
  today_kaohe_detail = []（清空本期详情）

结果：

第1个考核周期正式关闭，进入历史
用户进入第2个考核周期
仍然是 pass=1 状态，需要新一轮通过考核
用户获得新的30天机会

升级中断考核的处理

场景：用户在考核周期内或延期期间升级

处理逻辑：根据升级路径，升级会中断当前考核周期

升级路径	处理方式
1→2（普通→P5）	创建新的30天周期，pass=1
2→3（P5→P6）	备份当期到日志（pass=2），创建新周期
3→4（P6→P7）	备份当期到日志（pass=2），创建新周期
4→5（P7→V8）	备份当期到日志（pass=2），删除周期

结果：升级用户自动通过当期考核，进入新等级的新周期。

考核逻辑决策树

执行考核脚本 actionDo()
  │
  ├─ 查询待考核用户
  ├─ 统计去平业绩
  └─ 调用 updateUserKaoheRes() 处理结果
      │
      ├─ 考核通过？(pass=2)
      │  ├─ YES → 【通过逻辑】
      │  │  ├─ 更新考核结果表：pass=2
      │  │  ├─ 备份到历史日志：pass=2, pass_end=当前日期
      │  │  └─ 重置为下一周期：fail_cnt=0, pass=1
      │  │
      │  └─ NO → 【未通过逻辑】
      │     │
      │     ├─ 距离 kaohe_oper_start < 29天？
      │     │  ├─ YES → 【情况1：延期考核】
      │     │  │  ├─ pass = 1
      │     │  │  ├─ fail_cnt += 1 🔴
      │     │  │  ├─ today_kaohe_detail = 本次数据
      │     │  │  └─ 等待下一个考核日
      │     │  │
      │     │  └─ NO → 【情况2：进入新周期】
      │     │     ├─ 备份到历史日志：pass=1, pass_end=0
      │     │     ├─ 重置周期：fail_cnt=0, pass=1
      │     │     ├─ kaohe_start = 今天0点
      │     │     ├─ kaohe_end = next_pre_end
      │     │     └─ next_pre_end += 30天
      │     │
      │     └─ 更新考核结果表：pass=1（无论哪种情况）

文档版本：v2.0
简化说明：精简了原文档结构，保留核心业务逻辑，便于快速理解和查阅
更新日期：2026-05-29

月度考核业务逻辑 ​

摘要 ​

一、核心目标 ​

二、核心概念 ​

用户等级与考核标准 ​

考核周期的时间点 ​

去平业绩的定义 ​

三、月度考核执行流程 ​

执行时机 ​

执行步骤 ​

Step 1：获取待考核用户 ​

Step 2：查询有效订单 ​

Step 3：统计去平业绩 ​

Step 4：结果判定 ​

Step 5：结果存储 ​

Step 6：执行统计 ​

四、升级时的考核处理 ​

业务逻辑 ​

升级路径与处理方式 ​

路径1：普通用户升至P5（1→2） ​

路径2：P5升至P6 或 P6升至P7（2→3 或 3→4） ​

路径3：P7升至V8（4→5） ​

五、团队收益发放中的考核应用 ​

执行时机 ​

发放条件判定逻辑 ​

等级5、6（V8/V9） ​

等级1（普通用户） ​

等级2、3、4（P5/P6/P7） ​

停发原因分类 ​

六、业务流程时间线 ​

完整的30天周期流程 ​

关键时间数学关系 ​

七、多次考核与失败处理 ​

考核通过的流程 ​

考核未通过的两种情况 ​

情况1：延期考核期内（Day 31-59） ​

情况2：已超过29天延期期（Day 60+） ​

升级中断考核的处理 ​

考核逻辑决策树 ​

月度考核业务逻辑

摘要

一、核心目标

二、核心概念

用户等级与考核标准

考核周期的时间点

去平业绩的定义

三、月度考核执行流程

执行时机

执行步骤

Step 1：获取待考核用户

Step 2：查询有效订单

Step 3：统计去平业绩

Step 4：结果判定

Step 5：结果存储

Step 6：执行统计

四、升级时的考核处理

业务逻辑

升级路径与处理方式

路径1：普通用户升至P5（1→2）

路径2：P5升至P6 或 P6升至P7（2→3 或 3→4）

路径3：P7升至V8（4→5）

五、团队收益发放中的考核应用

执行时机

发放条件判定逻辑

等级5、6（V8/V9）

等级1（普通用户）

等级2、3、4（P5/P6/P7）

停发原因分类

六、业务流程时间线

完整的30天周期流程

关键时间数学关系

七、多次考核与失败处理

考核通过的流程

考核未通过的两种情况

情况1：延期考核期内（Day 31-59）

情况2：已超过29天延期期（Day 60+）

升级中断考核的处理

考核逻辑决策树