开单升单逻辑说明.md 7.32 KB

Edit Raw Blame History


开单升单逻辑说明文档
概述
升单是指已经开过会员再次消费的情况。系统会根据当前开单的品项类型和会员历史开单记录，自动判断是否为升单，并标记升单类型。
升单类型字段

F_UpgradeLifeBeauty：升生美（再次开单时，包含生美品项的订单）
F_UpgradeTechBeauty：升科美（再次开单时，包含科美品项的订单）
F_UpgradeMedicalBeauty：升医美（再次开单时，包含医美品项的订单）


升单判断逻辑
1. 升医美（UpgradeMedicalBeauty）
判断条件（需同时满足）：


✅ 当前开单包含医美品项


检查当前开单的品项明细中，是否有品项分类（lq_xmzl.qt2）为"医美"的记录

✅ 之前有医美类型的开单记录


查询该会员（kdhy）在当前开单之前的所有有效开单品项明细
筛选条件：


F_IsEffective = 1（品项明细有效）
ItemCategory = "医美"（品项分类为医美）
ActualPrice > 0（实际价格大于0）
Px != "61"（排除女神卡）


✅ 当前开单的医美品项实付业绩 >= 1000元


计算当前开单中所有医美品项的 actualPrice 总和
必须 >= 1000元


代码位置：LqKdKdjlbService.cs 第856-864行

代码逻辑：
//判断升医美：当前开单包含医美品项 + 之前有医美类型的开单记录 + 实付业绩>=1000
if (hasMedicalItemInCurrentBilling && hasPreviousMedicalBilling && MedicalItemInCurrentBillingAmount >= 1000)
{
    entity.UpgradeMedicalBeauty = "是";
}
else
{
    entity.UpgradeMedicalBeauty = "否";
}


2. 升科美（UpgradeTechBeauty）
判断条件（需同时满足）：


✅ 当前开单包含科美品项


检查当前开单的品项明细中，是否有品项分类为"科美"的记录

✅ 之前有科美类型的开单记录


查询该会员在当前开单之前的所有有效开单品项明细
筛选条件：


F_IsEffective = 1
ItemCategory = "科美"
ActualPrice > 0
Px != "61"（排除女神卡）


代码位置：LqKdKdjlbService.cs 第866-874行

代码逻辑：
//判断升科美：当前开单包含科美品项 + 之前有科美类型的开单记录
if (hasTechItemInCurrentBilling && hasPreviousTechBilling)
{
    entity.UpgradeTechBeauty = "是";
}
else
{
    entity.UpgradeTechBeauty = "否";
}


3. 升生美（UpgradeLifeBeauty）
判断条件（需同时满足）：


✅ 当前开单包含生美品项


检查当前开单的品项明细中，是否有品项分类为"生美"的记录

✅ 之前有生美类型的开单记录


查询该会员在当前开单之前的所有有效开单品项明细
筛选条件：


F_IsEffective = 1
ItemCategory = "生美"
ActualPrice > 0
Px != "61"（排除女神卡）


代码位置：LqKdKdjlbService.cs 第876-884行

代码逻辑：
//判断升生美：当前开单包含生美品项 + 之前有生美类型的开单记录
if (hasLifeItemInCurrentBilling && hasPreviousLifeBilling)
{
    entity.UpgradeLifeBeauty = "是";
}
else
{
    entity.UpgradeLifeBeauty = "否";
}


关键代码位置
新增开单（Create方法）

文件：netcore/src/Modularity/Extend/NCC.Extend/LqKdKdjlbService.cs
方法：Create（第799-884行）
逻辑：在创建新开单时，自动判断并设置升单类型字段

更新开单（Update方法）

文件：netcore/src/Modularity/Extend/NCC.Extend/LqKdKdjlbService.cs
方法：Update（第1190-1220行）
⚠️ 注意：Update方法中的升单判断逻辑存在Bug（见下方说明）

批量处理历史数据

文件：netcore/src/Modularity/Extend/NCC.Extend/LqKdKdjlbService.cs
方法：BatchProcessHistoricalUpgradeTypes（第4220-4398行）
逻辑：批量更新历史开单记录的升单类型字段


⚠️ 发现的Bug
Update方法中的字段赋值错误
位置：LqKdKdjlbService.cs 第1192-1220行

问题：


第1195行：判断升医美，但赋值给了 UpgradeLifeBeauty（应该是 UpgradeMedicalBeauty）
第1215行：判断升生美，但赋值给了 UpgradeMedicalBeauty（应该是 UpgradeLifeBeauty）


错误代码：
// 第1192-1200行：判断升医美，但赋值错误
var isMedicalProject = hasMedicalItemInCurrentBilling && await _db.Queryable<LqKdPxmxEntity>()...
if (isMedicalProject && MedicalItemInCurrentBillingAmount >= 1000)
{
    entity.UpgradeLifeBeauty = "是";  // ❌ 错误：应该是 UpgradeMedicalBeauty
}

// 第1212-1220行：判断升生美，但赋值错误
var isLifeProject = hasLifeItemInCurrentBilling && await _db.Queryable<LqKdPxmxEntity>()...
if (isLifeProject)
{
    entity.UpgradeMedicalBeauty = "是";  // ❌ 错误：应该是 UpgradeLifeBeauty
}


正确代码应该是：
// 升医美
if (isMedicalProject && MedicalItemInCurrentBillingAmount >= 1000)
{
    entity.UpgradeMedicalBeauty = "是";  // ✅ 正确
}

// 升生美
if (isLifeProject)
{
    entity.UpgradeLifeBeauty = "是";  // ✅ 正确
}


数据来源说明
品项分类获取

表：lq_xmzl（项目资料表）
字段：qt2（品项分类：生美/科美/医美）
关联：通过 lq_kd_pxmx.px = lq_xmzl.F_Id 关联

历史开单记录查询

表：lq_kd_pxmx（开单品项明细表）
筛选条件：


MemberId = 当前会员ID
F_IsEffective = 1（有效）
ItemCategory = 对应类型（生美/科美/医美）
ActualPrice > 0（实际价格大于0）
Px != "61"（排除女神卡）
Glkdbh != 当前开单ID（排除当前开单本身，仅查询历史记录）


升单判断流程图
升医美流程
开始
  ↓
当前开单是否包含医美品项？
  ↓ 是
之前是否有医美类型的开单记录？
  ↓ 是
当前开单医美品项实付业绩 >= 1000元？
  ↓ 是
标记为：升医美 = "是"
  ↓
结束

升科美流程
开始
  ↓
当前开单是否包含科美品项？
  ↓ 是
之前是否有科美类型的开单记录？
  ↓ 是
标记为：升科美 = "是"
  ↓
结束

升生美流程
开始
  ↓
当前开单是否包含生美品项？
  ↓ 是
之前是否有生美类型的开单记录？
  ↓ 是
标记为：升生美 = "是"
  ↓
结束


注意事项

升单判断是独立的：一个开单可以同时标记为升医美、升科美、升生美（如果同时满足条件）
时间顺序很重要：判断"之前是否有开单记录"时，是基于开单日期（kdrq）来判断的，必须是当前开单日期之前的记录
排除女神卡：所有升单判断都排除品项ID为"61"的女神卡
有效记录：只统计有效的开单记录和品项明细（F_IsEffective = 1）
医美升单特殊要求：升医美除了需要满足前两个条件外，还需要当前开单的医美品项实付业绩 >= 1000元


修复建议
建议修复 Update 方法中的字段赋值错误，确保：


升医美 → 赋值给 UpgradeMedicalBeauty
升科美 → 赋值给 UpgradeTechBeauty
升生美 → 赋值给 UpgradeLifeBeauty