ai完整信息： # 一、接口链路全貌这个接口从前端 → 后端的调用链一共 **4 层**： ``` UIX 层 : EdorInsuredDealUIX.submitDataAPIOperate() ← 接收入参、解析VO ↓ UI 层 : EdorInsuredDealUI.submitData() ← 标准化前置校验 ↓ BL 层 : EdorInsuredDealBL.submitData() ← 真正的业务大脑 ↓ 子BL : EdorGroupBL / CheckEdorInsuredList / CheckEdorInsuredListCertificates / EdorPremTryCalBL / EdorPremCalBL / newGroupInsuranceDeal ... ``` >你的入参 `Operate=CHECKLIST`，所以**所有非 CHECKLIST 分支（SELDEL/CONDEL/ALLDEL/UPLOAD/...）在本次请求里全部不执行**，整个请求最终落在 BL层的 `dealData()` 中 `else if ("CHECKLIST".equals(mOperate))` 这个分支。 --- # 二、UIX 层做了什么（`EdorInsuredDealUIX.submitDataAPIOperate`）文件：`java/com/cignacmb/gcis/pos/uix/EdorInsuredDealUIX.java` 它的职责很"薄"，就4 件事： 1. **解析入参**：用 `RestfulCommonUtil` 把 JSON 反序列化成 `EdorInsuredVO`。 2. **打包 TransferData**：把 `MissionID/SubMissionID/ActivityID/EdorAppNo/ProductTypeFlag/LCMinorFlag/IcisState/ChangeFlag/RemoveFlag/SerialNo` 等全部塞进 `TransferData`。 3. **拆 Operate**：根据 `tOperate` 决定要不要构造 `LBPOEdorInsuredListSet`（只有 `SELDEL/WhiteListID` 才走前台列表；`CHECKLIST` 时这个集合是空的，仅靠 `EdorAppNo` 查库）。 4. **调用 UI 层**：`edorInsuredDealUI.submitData(tVData, tOperate)`。 **关于 CHECKLIST 的特别说明**（line 152-177）：成功后会再做一件事——读取两个**全局静态变量**： - `CheckEdorInsuredList.getfResult()` - `CheckEdorInsuredListCertificates.getfResult()` 把它们的内容追加到返回报文里展示给前端（这就是你看到的"非阻断校验提示"和"可点击《非阻断校验提示清单》进行下载"的由来）。 --- # 三、UI 层做了什么（`EdorInsuredDealUI`）文件：`java/com/sinosoft/lis/pos/EdorInsuredDealUI.java` `EdorInsuredDealUI` 是经典的"门面层"，三步走： |步骤 | 方法 | 作用 | |---|---|---| | 1 | `getInputData` | 把 `GlobalInput` / `TransferData` / `LBPOEdorInsuredListSet` 拆出来 | | 2 | `checkData` | 校验任务是否还在、清单是否录了入；**GHB 保单跳过 listcheckflag='0' 的重复校验**（line 195） | | 3 | `dealData` | 直接 new 一个 `EdorInsuredDealBL` 调用，业务全在里面 | 关键技巧：UI 层基本不写业务，**只是为了对接 jBoss/工作流框架的 `BusinessService` 接口**。 --- # 四、BL 层 CHECKLIST 完整流程（重点）文件：`java/com/sinosoft/lis/pos/EdorInsuredDealBL.java` line 800-1196。我把整个流程拆成 **8 个步骤**，每一步都标了行号： ``` CHECKLIST 进入 │ ├─① DealLCMinor() line 803 [GHB-13799] 附属人一起变更 │ ├─② basicCheck(tVData) line 816基础业务校验 │ ├─ GHB 保单 (ProdType=04) │ │ └─ 把前台 ChangeFlag/RemoveFlag 写回 lbpoedorinsuredlist │ ├─ 新型团险 (ProdType=05) → CheckEdorInsuredList4NewGroup │ ├─ 其他 (ProdType=00/01...) │ │ ├─ CheckCustomer.checkPOSDate2/3 在途理赔非阻断提示 │ │ └─ CheckEdorInsuredList 主校验类（年龄/性别/重复/...) │ └─ CheckEdorInsuredListCertificates 证件/黑名单/受益人校验 │ ├─③ EdorGroupBL line 825 把清单按保单号分组、准备试算 │ ├─④ 非阻断手机号/银行信息校验 line 833-891 │ ├─⑤ DealEmpolyEE() line 901 员福单特殊处理（主被保人信息同步给附属人） │ ├─⑥ 分流处理 line 909 │ ├─ ProdType=05（新型团险）→ newGroupInsuranceDeal() │ ├─ 否则且非 AE → FeegateDeal() ◀ ★★★收退费比例核心 │ └─ 然后 → checkChargeType() line923 校验同单多人收费方式必须一致 │ ├─⑥点 NGB 混合支付（GHB 保单） line 928-995 ◀ ★★★ 重点 │ └─ 用 LJPAYONLIETRACE 的 PAYSTATE=2 反写支付订单号 │ ├─⑦ 公司/个人分摊金额 → 自动算比例 line 1006-1035 ◀ ★★★ 重点 │ └─ EdorPremTryCalBL / EdorPremCalBL 试算保费 │ ├─⑧ 计算公司退费金额 / 更新银行信息 line 1099-1147 │ └─⑨ NGB 涉费类保全非阻断提示 line 1166-1172 └─ 异步多线程公民网校验 line 1183-1195 ``` --- # 五、你重点要看的两块——逐行拆解 ## 🔶 重点①：GHB 混合支付（line 928-995）这段代码的本质：**GHB 方案变更里，如果某个人已经在线支付成功，要把支付信息回写到清单表**，方便后续不退重复保费。 ```java // line 928 if("GHB".equals(mProductTypeFlag)){ // ① 找出 GHB 单子里、STATE='1'（校验通过）、PERSONPAYTYPE='3'（混合支付）的被保险人 mStrBuff.append(" select distinct a.contno,a.insuredno,a.OLDINSUREDIDNO,a.INSUREDIDNO " + " from lbpoedorinsuredlist a " + " where a.edorappno='" + mEdorAppNo + "' " + " and a.GRPCONTNO='"+mGrpContNo+"' " + " and a.STATE='1' and a.PERSONPAYTYPE = '3'"); // PERSONPAYTYPE=3 表示混合支付 // ② 用团体保单号 + 身份证号去 LJPAYONLIETRACE（在线支付流水）里查 //条件：BUSSTYPE='GHB' AND PAYSTATE='2'（支付成功） mStrBuff.append(" select a.tempfeeno,a.payserialno,PAYAMOUNT from ljpayonlietrace a " + " where a.grpcontno='" + mGrpContNo + "' " + " and a.idno='" + tIdNo + "' " + " and a.busstype='GHB' and a.paystate='2' " + " order by a.SERIALNO "); // ③ 再用 tempfeeno 去 LJTEMPFEE（暂存费用）查 OtherNo（订单号）+ ReceiveserialNo mStrBuff.append(" select a.otherno,a.receiveserialno,a.MONEY from ljtempfee a " + " where a.tempfeeno='" + tTempFeeNo + "' "); // ④ 比对金额（在线支付金额 == 暂存费用金额）才算支付成功 if (new BigDecimal(tPayAmount).compareTo(new BigDecimal(tMoney)) == 0) { // ⑤ 把支付订单号回写到 lbpoedorinsuredlist update lbpoedorinsuredlist set payorderno=ReceiveserialNo, payserialno=PAYSERIALNO, cporderno=OtherNo ...; // ⑥ 把 ljpayonlietrace 的 EDORAPPNO 也补上，避免下次重复匹配 update ljpayonlietrace set EDORAPPNO=... ; } // ⑦ 中间提交一次，防止内存过大 if(tHasUpdate){ saveData(); mMMap = new MMap(); } } ``` **通俗理解：** > 这段就是"对账"——把已在线支付成功的个人，从 `ljpayonlietrace` 找出来，把对应的支付订单号、流水号反写到 `lbpoedorinsuredlist` 里，作为后续核对的依据。 --- ## 🔶 重点②：计算支付比例（核心中的核心）支付比例计算分散在 **3 个地方**，我会逐个讲清楚。 ### A) NGB 涉费类保全——按"全年保费"算比例（line 1006-1035） >适用：**收费方式 = 公司和个人分摊金额**，且 `edortype in ('NI','LC')` 的记录。 ```java // line 1009-1023 核心 SQL取出企业全年保费 / 个人全年保费 mStrBuff.append(" SELECT a.SERIALNO,a.EnterprisePremium,a.PersonalPremium " + " FROM lbpoedorinsuredlist a " + " where a.edorappno='" + mEdorAppNo + "' " + " and a.edortype in ('NI','LC') " + " and a.ReceivableType in ('公司和个人分摊金额') " + " and (a.receivablescale is null or a.receivablescale='0' ) "); for (...) { BigDecimal EnterprisePremium = new BigDecimal(tEnterprisePremium); // 企业全年保费 BigDecimal PersonalPremium = new BigDecimal(tPersonalPremium); // 个人全年保费 // ★ 关键公式： BigDecimal receivablescale = EnterprisePremium.divide( EnterprisePremium.add(PersonalPremium), 10, RoundingMode.HALF_UP); // receivablescale = 企业 / (企业 + 个人) → 保留10 位小数 update lbpoedorinsuredlist set receivablescale = ...; } ``` **通俗理解：** > 当客户在 Excel 里录了"全年公司保费"和"全年个人保费"，但没填比例，**系统自动算**：`企业 ÷ (企业+个人) = 企业占比`。注意是按"全年保费"算，不是按某次缴费。 --- ### B) 普通险种——按"缴费方式/退费方式"配置算比例（line 1477-1608，方法 `FeegateDeal`） >适用：**非 AE 项且非新型团险** 的普通险种。这里其实有3 套策略，**根据前台录入的 `ChargeType` / `PosRefundMode` 决定走哪套**： #### B-1）保全加人或 LC（line 1499-1520）：直接读 lccontplan 的 `PosRefundMode` / `EnterpriseRate` ```java // 当 edortype 不是 ZT（减人），且前台 ReceivableType 没录// 直接从 lccontpay（新单收费方式配置表）里取 if(StringUtils.isBlank(tReceivableType)){ if(!tLCContPayDB.getInfo() || "HT".equals(tedortype)){ // 没配置 → 默认"全收公司"，比例=1 update lbpoedorinsuredlist set ReceivableType='全收公司', ReceivableScale='1'; } else { //读取新单的 PremMode（收费方式）+ EnterpriseRate（公司占比） PremMode = lccontpay.PremMode; enterpriseRate = lccontpay.EnterpriseRate; // 用 ldcode 把 code 转成中文名（receivablesmode） ReceivableType = codename('receivablesmode', PremMode); update lbpoedorinsuredlist set ReceivableType='中文名', ReceivableScale=enterpriseRate; } } ``` #### B-2）保全减人且退费方式 = "按公司和个人之前缴费比例退费" 或 `PosRefundMode=4`（line 1542-1561） ```java if (("按公司和个人之前缴费比例退费".equals(tchargetype) || "4".equals(PosRefundMode)) && "ZT".equals(tedortype)) { // 公司总缴费 BigDecimal currentMoneyOnCompany = getMoneyOnCompany(contNo, insuredno, osorderFalg, payOnlineFalg); // 个人总缴费 BigDecimal currentMoneyOnPerson = getMoneyOnPerson (contNo, insuredno, osorderFalg, payOnlineFalg); // 总缴费 BigDecimal currentMoneyCount = currentMoneyOnCompany.add(currentMoneyOnPerson); if (currentMoneyCount.compareTo(BigDecimal.ZERO) <= 0) { // 没查到缴费 → 校验不通过 update lbpoedorinsuredlist set Reason='未查到缴费信息，请联系IT', state='9'; } else { // ★ 关键公式（按"之前"的历史缴费比例）： BigDecimal companyscale = currentMoneyOnCompany.divide(currentMoneyCount, 10, RoundingMode.HALF_UP); update lbpoedorinsuredlist set companyscale=companyscale; } } ``` **两个辅助方法的关键 SQL：** `getMoneyOnCompany`（line 2336-2368）： ```sql select sum(billmoney) from lcoriginalbilldetailwhere contno=? and insuredno=? and premtype <> '2' -- ← 公司部分的标志：premtype != 2 and othernotype in ('01','02'...) -- ←01=新单，02=续期，03=保全 ``` `getMoneyOnPerson`（line 2294-2327）： ```sql select sum(billmoney) from lcoriginalbilldetail where contno=? and insuredno=? and premtype = '2' -- ← 个人部分的标志：premtype = 2 and ... ; ``` **通俗理解：** > 这个策略就是"**按历史缴费比例退**"——保险公司去财务流水表里查这个人**历史上**一共交了多少钱、公司交了多少钱、个人交了多少钱，按比例算出"这次退费该退多少给公司"。 --- #### B-3) **RCP-16143（NGB 按公司和个人总保费比例退费或 SI 保全）**（line 1563-1591） > 这是**新增的 NGB 按"保费"算比例**的逻辑。 ```java if (("按公司和个人总保费比例退费".equals(tchargetype) || "5".equals(PosRefundMode)) && "ZT".equals(tedortype)) || (!"GHB".equals(mProductTypeFlag) && "SI".equals(tedortype))) { // 是否金风保单（BFPolicy 配置，CODEALIAS=JF） String isJinFeng = mExeSQL.getOneValue( "select 1 from ldcode c where c.codetype='bfPolicy' and c.CODEALIAS='JF' and c.code='" + mGrpContNo + "'"); // 公司总保费（NGB 关键方法） BigDecimal currentMoneyOnCompany = getMoneyOnCompanyOrPerson(contNo, insuredno, "1", isJinFeng); // 个人总保费 BigDecimal currentMoneyOnPerson = getMoneyOnCompanyOrPerson(contNo, insuredno, "0", isJinFeng); BigDecimal currentMoneyCount = currentMoneyOnCompany.add(currentMoneyOnPerson); if (currentMoneyCount.compareTo(BigDecimal.ZERO) <= 0) { update ... set Reason='未查到保费信息，请联系IT', state='9'; } else { BigDecimal companyscale = currentMoneyOnCompany.divide(currentMoneyCount, 10, RoundingMode.HALF_UP); if (!"SI".equals(tedortype)) { // ZT 减人：只更新退费比例 update lbpoedorinsuredlist set companyscale=companyscale; } else { // SI（特别约定/计划变更）：同时更新收退费比例（取负 = 对冲） if (companyscale.compareTo(BigDecimal.ONE) != 0) { update lbpoedorinsuredlist set CHARGETYPE='', companyscale=companyscale, RECEIVABLETYPE='', RECEIVABLESCALE=-companyscale; --负号：对冲 } else { //极端情况：全是公司付 update ... set CHARGETYPE='全退公司', companyscale='1', RECEIVABLETYPE='全收公司', RECEIVABLESCALE='-1'; } } } } ``` `getMoneyOnCompanyOrPerson`（line 2432-2472）—— 这方法是**金风保单的专用方法**： ```java private BigDecimal getMoneyOnCompanyOrPerson(String contNo, String insuredNo, String isCompany, String isJinFeng) { // ① 先看是不是金风保单（BFPolicy= JF） if ("1".equals(isJinFeng)) { //② 金风保单 →优先查 ljtempfeeriskdetail（风险保费明细，NGB 新逻辑） sql = "select sum(a.enterpriseprem) from ljtempfeeriskdetail a " + "where a.state='01' and lb.edortype='ZT' and lb.contno=? and lb.insuredno=?"; // isCompany=1 → 公司；isCompany=0 → 个人 } // ③ 非金风 OR 金风表没查到 → 兜底查 lcoriginalbilldetail（缴费流水老表） sql = "select sum(billmoney) from lcoriginalbilldetail " + " where contno=? and insuredno=? " + " and (isCompany='1' → premtype<>'2' ; isCompany='0' → premtype='2') " + " and (othernotype in ('01','02') or (othernotype='03' and lpedoritem.edorstate='00'))"; } ``` **通俗理解：** > 这是 NGB 项目的"按**新单 + 保全**总保费"算比例。金风保单有独立的 `ljtempfeeriskdetail` 表更准；其他保单走 `lcoriginalbilldetail` 兜底。SI（特别约定）这种保全会**同时改收退费**（用负号对冲），因为 SI 既收费又退费。 --- ## 🔶 重点②的延伸：line 920-925 的 `checkChargeType`——一致性校验算完比例后还要**校验**： ```java // line 920if(!"GHB".equals(mProductTypeFlag) && !"1".equals(tAEFlag)){ if(!checkChargeType()){ return false; } } ``` `checkChargeType` 做的事（line 1666-1730）： > 同一个保单号下、同一保全项下、不同被保险人的"**退费方式/退公司比例/收费方式/收公司比例**"必须一致，否则把这一条记录打成 `state='9'` + 原因 = "存在相同保全项下相同个人保单号不同被保险人设置的退费方式/比例不一致"。 --- # 六、整体流程图（一图流） ``` ┌──────────────────────────────────────────────────────────────────────┐ │ 前端调用 EdorInsuredDealUIX.submitDataAPIOperate(Operate=CHECKLIST)│ └──────────────────────────────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────────────┐ │ EdorInsuredDealUIX (UIX) │ │ - 解析 EdorInsuredVO │ │ - 打包 TransferData {MissionID, SubMissionID, ActivityID, EdorAppNo,│ │ ProductTypeFlag="NGB", SerialNoList=[272141956]}│ │ - 调 EdorInsuredDealUI.submitData(tVData, "CHECKLIST") │ └──────────────────────────────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────────────┐ │ EdorInsuredDealUI (UI门面层) │ │ - getInputData: 拆出 GlobalInput / TransferData / ListSet │ │ - checkData: 校验任务有效 + 清单非空 + (GHB跳过重复校验) │ │ - dealData: new EdorInsuredDealBL().submitData() │ └──────────────────────────────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────────────┐ │ EdorInsuredDealBL.dealData() CHECKLIST 分支 │ │ │ │ ① DealLCMinor GHB附属人一起变更 │ │ ② basicCheck → CheckEdorInsuredList/Certificates 业务基础校验 │ │ ③ EdorGroupBL 按保单号分组 │ │ ④ 非阻断手机/银行信息 │ │ ⑤ DealEmpolyEE 员福单同步主被保人信息 │ │ ⑥ FeegateDeal ★ 收退费方式/比例（普通险种） │ │ ├ 加人/LC → 读 lccontpay 新单配置 │ │ ├ ZT 减人 "按之前缴费比例退费" → getMoneyOnCompany/Person │ │ └ ZT "按总保费比例退费" + SI → getMoneyOnCompanyOrPerson (NGB) │ │ ⑥.5 GHB 混合支付 ★ LJPAYONLIETRACE 反写支付订单号 │ │ ⑦ checkChargeType 同单多人比例必须一致 │ │ ⑧ NI/LC "公司个人分摊金额" → 自动算 receivablescale │ │ ⑧.5 EdorPremTryCalBL/PremCalBL 试算保费 │ │ ⑨ updateRefundAmountOnCompany 计算公司退费金额 │ │ ⑩ NGB 非阻断提示 / 异步公民网校验 │ └──────────────────────────────────────────────────────────────────────┘ ``` --- # 七、给你的几个关键 takeaway 1. **你的入参 `ProductTypeFlag=NGB`**：注意代码里判断 GHB 的地方用的是 `if("GHB".equals(mProductTypeFlag))`。也就是说，**你这次传的 NGB 走的不是 line 928-995 那段"混合支付"特殊逻辑，而是普通 NGB 的支付比例计算逻辑**（line 1477-1608 + line 1006-1035）。 2. **`SerialNoList=[272141956]`** 在 CHECKLIST 分支里实际不参与运算——只在 `SELDEL` / `WhiteListID` 才有意义。CHECKLIST 只看 `EdorAppNo` 把整张清单全捞出来。 3. **支付比例的计算本质上就 3 个公式**： - **加保/方案变更**：`receivablescale = 企业保费 ÷ (企业保费 + 个人保费)`（按"全年"） - **减保按之前缴费比例退**：`companyscale = 公司历史缴费 ÷ (公司+个人历史缴费)`，查 `lcoriginalbilldetail.premtype` - **NGB 按总保费比例退 / SI 保全**：`companyscale = 公司总保费 ÷ (公司+个人总保费)`，金风保单走 `ljtempfeeriskdetail`，其他走 `lcoriginalbilldetail` 4. **`PERSONPAYTYPE = '3'`** 这个字段才是 GHB 真正"混合支付"的标志——GHB 保单用这个字段识别"个人已在线支付过、保全时不要再退"。 5. **NGB 涉费类保全非阻断提示**（line 2417）：当 `PRODBUSS='01'` 且 `prodtype != '04'` 且 `reason='0'`，会提示"保全变更费用为 0"——这是上线时增加的业务规则。如果你希望我进一步**深入某一段**（比如把 `FeegateDeal` 的整个分支画成时序图，或者把 GHB 混合支付涉及的表结构画出来），告诉我，我继续帮你拆。 ------------------------------------- 我来重新精确核对这几段代码，确认 NGB 混合支付、NGB 比例计算的位置，以及"期缴试算"的逻辑。关键点已定位。我再确认几个细节：`EdorPremTryCalBL` / `EdorPremCalBL` 两个类的区别、`payIntv` 和 `checkInsuPeriod` 的含义，以及 `mProductTypeFlag` 的来源，还有 NGB 混合支付是否在其它文件里。再核对两点：NGB 混合支付是否存在于其他文件，以及两个试算类的差异。已定位关键信息。最后核对两个试算类的本质差异，确认"试算"与"正式计算"的边界。三个问题我都逐一核对了代码，结论如下。 --- # 问题一：NGB 的混合支付代码到底在哪？ ## 直接结论 **在这个接口的这条链路里，没有任何 NGB 混合支付代码。** 整个 `EdorInsuredDealBL` 文件中，处理混合支付的只有一处，且条件写死了只认 GHB： ```928:933:java/com/sinosoft/lis/pos/EdorInsuredDealBL.java //GHB 且为方案变更混合支付若个人部分已经在保全时支付成功，在校验的时候需要更新支付成功的人的支付信息 if("GHB".equals(mProductTypeFlag)){ //从LBPOEdorInsuredList中获取CONTNO和INSUREDNO mStrBuff.append(" select distinct a.contno,a.insuredno,a.OLDINSUREDIDNO,a.INSUREDIDNO from lbpoedorinsuredlist a "); mStrBuff.append(" where a.edorappno='" + mEdorAppNo + "' "); mStrBuff.append(" and a.GRPCONTNO='"+mGrpContNo+"' and a.STATE='1' and a.PERSONPAYTYPE = '3'"); ``` 你这次入参 `ProductTypeFlag = "NGB"`，所以 `"GHB".equals("NGB")` 为 false，**这一整块（928-995 行）根本不会执行**。 ## 关键澄清：「混合支付」和「计算支付比例」是两回事这是你混淆的根源，必须掰开： | | 混合支付（PERSONPAYTYPE='3'） | 计算支付比例（companyscale / receivablescale） | |---|---|---| | **是什么** | 一种**付款方式**：公司出一部分、个人出一部分（线上支付） | 一个**数值比例**：公司该承担多少 | | **代码做的事** | 把"个人已在线支付成功"的记录，从 `ljpayonlietrace`（支付流水）查到支付订单号，**回写**到 `lbpoedorinsuredlist` 的 `payorderno / payserialno / cporderno` 字段 | 算出一个 0~1 之间的小数，**写入** `companyscale`（退费用）或 `receivablescale`（收费用） | | **触发条件** | `PERSONPAYTYPE = '3'` 且保单符合同（`mProductTypeFlag = "GHB"`） | 前台录了"公司和个人分摊金额" / "按公司和个人之前缴费比例退费" / "按公司和个人总保费比例退费" 等退费方式 | | **归属** | 只有 GHB 有 | NGB / 普通团险都有 | 所以：**"计算支付比例"不是"混合支付的 NGB 版本"**，它们是两个维度的东西。 > 补充：如果 NGB 业务上确实也需要"回写在线支付订单号"这类动作，它不可能在本接口（`EdorInsuredDealBL`）里，应该在受理环节 / 上传环节 / 校验环节单独处理（`PERSONPAYTYPE` 字段在 `CheckEdorInsuredList`、`EdorInsuredUploadBL`、`EdorLCInputBL` 等类里都有出现）。这点建议你到那边确认，我这个文件里确实没有。 --- # 问题二：NGB 计算比例是不是分散在两处？ ## 结论：你的理解完全正确，而且本质是"两种不同场景" NGB 的比例计算确实**不在同一个方法里**，它们是按 **保全类型** 拆开的： ### 场景 A：加人 / 方案变更（NI、LC）→ 算「**收费比例 receivablescale**」位置：**`FeegateDeal()` 方法外面**，line 1006-1035（就在 GHB 混合支付块的下方） ```1006:1035:java/com/sinosoft/lis/pos/EdorInsuredDealBL.java if(!"05".equals(mProdType) && !"1".equals(tAEFlag)){ if(!"04".equals(mProdType)){ mStrBuff = new StringBuffer(); mStrBuff.append(" SELECT a.SERIALNO,a.EnterprisePremium,a.PersonalPremium "); mStrBuff.append(" FROM lbpoedorinsuredlist a "); mStrBuff.append(" where a.edorappno='" + mEdorAppNo + "' and a.edortype in ('NI','LC') "); mStrBuff.append(" and a.ReceivableType in ('公司和个人分摊金额') and (a.receivablescale is null or a.receivablescale='0' ) "); ... BigDecimal receivablescale = EnterprisePremium.divide(EnterprisePremium.add(PersonalPremium), 10, RoundingMode.HALF_UP); // receivablescale = 企业全年保费 / (企业全年保费 + 个人全年保费) ``` - 只针对 `edortype in ('NI','LC')` - 只针对 `ReceivableType = '公司和个人分摊金额'`（白名单式硬编码） - 公式：`receivablescale = 企业全年保费 ÷ (企业全年保费 + 个人全年保费)` ### 场景 B：减人（ZT）/ SI → 算「**退费比例 companyscale**」位置：**`FeegateDeal()` 方法里面**，line 1563-1591（RCP-16143 NGB 逻辑） ```1563:1591:java/com/sinosoft/lis/pos/EdorInsuredDealBL.java //RCP-16143 （NGB） if ((("按公司和个人总保费比例退费".equals(tchargetype) || "5".equals(PosRefundMode)) && "ZT".equals(tedortype)) || (!"GHB".equals(mProductTypeFlag) && "SI".equals(tedortype))) { //是否金风保单 String isJinFeng = mExeSQL.getOneValue("select 1 from ldcode c where c.codetype = 'bfPolicy' and c.CODEALIAS = 'JF' and c.code= '" + mGrpContNo + "' and rownum = 1"); //公司总保费 BigDecimal currentMoneyOnCompany = getMoneyOnCompanyOrPerson(contNo, insuredno, "1", isJinFeng); //个人总保费 BigDecimal currentMoneyOnPerson = getMoneyOnCompanyOrPerson(contNo, insuredno, "0", isJinFeng); BigDecimal currentMoneyCount = currentMoneyOnCompany.add(currentMoneyOnPerson); ... BigDecimal companyscale = currentMoneyOnCompany.divide(currentMoneyCount, 10, RoundingMode.HALF_UP); ``` - 针对 `edortype = 'ZT'`（减人）或 `SI`（且非 GHB） - 触发条件来自 `chargetype`（前台退费方式）或 `PosRefundMode`（方案配置） - 公式：`companyscale = 公司总保费 ÷ (公司总保费 + 个人总保费)` - 金风保单走 `ljtempfeeriskdetail`，其他走 `lcoriginalbilldetail`（见 `getMoneyOnCompanyOrPerson`，line 2432-2472） ### 对比表 | 维度 | 场景 A（方法外） | 场景 B（方法内 `FeegateDeal`） | |---|---|---| | 保全类型 | NI（加人）/ LC（方案变更） | ZT（减人）/ SI | | 写入字段 | `receivablescale`（收费比例） | `companyscale`（退费比例） | | 数据来源 | 清单里已录的 `EnterprisePremium` / `PersonalPremium`（全年保费） | 去查 `lcoriginalbilldetail` 或 `ljtempfeeriskdetail`（历史缴费/总保费） | | 触发方式 | `ReceivableType='公司和个人分摊金额'` | `chargetype` / `PosRefundMode` = 4 或 5 | | 所在位置 | `FeegateDeal()` **调用之后**的独立代码块 | `FeegateDeal()` **方法内部** | **为什么这么设计？** 因为： - 加人时，清单里已经有了"企业全年保费/个人全年保费"，只需本地除一下即可； - 减人时，要退钱，必须去**财务流水表**里查这个人历史上实际交了多少钱，涉及大量 SQL 和批量查询（`BatchDataQueryDB`），所以被封装进 `FeegateDeal()`。 > 注意：`FeegateDeal()` 的方法注释虽然写的是"普通险种校验和获取收退费方式和比例"，但里面**明确包含 NGB 的逻辑**（`!"GHB".equals(mProductTypeFlag)`、`isJinFeng` 等），注释是历史遗留，别被误导。 ### 你这次请求实际走哪条？入参 `ProductType="00"`，`ProductTypeFlag="NGB"`： - `"05".equals(mProdType)` = false → 走 `else if` → **执行 `FeegateDeal()`** ✅ - `"04".equals(mProdType)` = false → **执行 line 1006-1035 的加人比例计算** ✅ - `!"GHB".equals("NGB")` = true → **执行 `checkChargeType()`** ✅ - `"GHB".equals("NGB")` = false → **跳过混合支付块** ✅ --- # 问题三：「期缴试算」逻辑详细分析位置：line 1036-1062。这是紧跟在"加人比例计算"之后的费用计算引擎选择逻辑。 ## 完整代码 ```1036:1062:java/com/sinosoft/lis/pos/EdorInsuredDealBL.java //原试算逻辑开关 String tPremTryCalFlag = mExeSQL.getOneValue("select code from ldcode where codetype='PremTryCalFlag'"); if("1".equals(tPremTryCalFlag)){ //ngb期缴走原入 String payIntv = mExeSQL.getOneValue("select payintv from lcgrpcont where grpcontno='"+mGrpContNo+"'"); String flag = mExeSQL.getOneValue("select 1 from lbpoedorinsuredlist where edorappno='"+mEdorAppNo+"' and edortype in ('NI','ZT','LC','IC','AA') "); if((!"GHB".equals(mProductTypeFlag) && !("-1".equals(payIntv) || "0".equals(payIntv) || ("12".equals(payIntv) && new EdorPubFun().checkInsuPeriod(mEdorAppNo)))) || !"1".equals(flag)){ EdorPremTryCalBL tEdorPremTryCalBL = new EdorPremTryCalBL(); if (!tEdorPremTryCalBL.submitData(tVData, "")){ buildError("dealData", "被保人保全费用计算失败!"+tEdorPremTryCalBL.getErrors().getFirstError()); return false; } }else{ EdorPremCalBL tEdorPremCalBL = new EdorPremCalBL(); if (!tEdorPremCalBL.submitData(tVData, "")){ buildError("dealData", "被保人保全费用计算失败!"+tEdorPremCalBL.getErrors().getFirstError()); return false; } } }else{ EdorPremTryCalBL tEdorPremTryCalBL = new EdorPremTryCalBL(); if (!tEdorPremTryCalBL.submitData(tVData, "")){ buildError("dealData", "被保人保全费用计算失败!"+tEdorPremTryCalBL.getErrors().getFirstError()); return false; } } ``` ## 这块是干什么的？ **一句话：这里是"选择用哪一套引擎、去算每个被保人这次保全要收/退多少钱"。** 算完的结果会写回 `lbpoedorinsuredlist.reason` 字段（就是清单页面上显示的那个"金额"列）。两个引擎都会做这个写回，例如： ```3954:3956:java/com/sinosoft/lis/pos/EdorPremTryCalBL.java mStrBuff.append("update lbpoedorinsuredlist a set reason='"+df.format(tInsuredEdorPrem)+"',substandard='Y',refundamountoncompany ='"+df.format(tInsuredCompanydEdorPrem)+"',receivablescale='"+companyRate+"'"); ...where a.edorappno ... and a.edortype = 'NI' and state = '1'"); ``` ```1458:1459:java/com/sinosoft/lis/pos/EdorPremCalBL.java mStrBuff.append(" update lbpoedorinsuredlist set reason = '"+tInsuredEdorPrem+"' where edorappno='"+mEdorAppNo+"' and insuredno = '"+tInsuredNo+"' "); mMMap.put(mStrBuff.toString(), "UPDATE"); ``` ## 三个关键要素 ### ① 总开关 `PremTryCalFlag`（配置表 ldcode） ```java String tPremTryCalFlag = mExeSQL.getOneValue("select code from ldcode where codetype='PremTryCalFlag'"); if("1".equals(tPremTryCalFlag)){ ... } else { 一律走 EdorPremTryCalBL } ``` - 开关 **不是** `'1'` → 不管三七二十一，**一律走 `EdorPremTryCalBL`（试算）**。 - 开关 **是** `'1'` → 才进入下一层 `payIntv` 判断。这是一个**灰度/回退开关**，出问题时可以通过改 `ldcode` 配置快速切回旧逻辑，不用发版。 ### ② 缴费间隔 `payIntv`（查 `lcgrpcont`） | payIntv | 含义 | |---|---| | `-1` | 趸缴（一次性交清） | | `0` | 月缴 / 不定期 | | `1` | 月缴 | | `3` | 季缴 | | `6` | 半年缴 | | `12` | 年缴 | ### ③ 保险期间是否变化 `checkInsuPeriod()` ```393:416:java/com/sinosoft/lis/pos/EdorPubFun.java public Boolean checkInsuPeriod(String tEdorAppNo) { ... tStrBuff.append(" SELECT count(*) FROM LBPOEdorInsuredList a,LCCONTPLAN b,LCGRPCONT c WHERE ... b.PERINSUPERIODFLAG IS NOT NULL AND (c.INSUPERIOD != b.PerINSUPERIOD or c.INSUPERIODFLAG != b.PERINSUPERIODFLAG ) "); tStrBuff.append(" AND a.EDORTYPE='NI' AND a.EdorAppNo='"+tEdorAppNo+"'"); ... } ``` 它的作用是：对比 `lcgrpcont`（团体保单当前的保险期间）和 `lccontplan`（方案里的保险期间配置），**判断这次保全是不是把保险期间改了**。返回 `true` 表示"变了"。 ## 选择逻辑拆解（布尔表达式）设： - `A = !"GHB".equals(mProductTypeFlag)` → 本次不是 GHB（NGB 时为 true） - `B = ("-1"||"0"||("12" && checkInsuPeriod))` → 趸缴 / 月缴0 / 年缴且保险期间变化 - `C = !"1".equals(flag)` → 清单里没有 NI/ZT/LC/IC/AA 记录条件 = `(A && !B) || C` → **走 `EdorPremTryCalBL`（试算）**；否则走 `EdorPremCalBL`（正式计算）。代入你这次场景（`ProductTypeFlag="NGB"`，`mProdType="00"`，有 NI/ZT 记录即 flag='1'）： | 保单缴费情况 | A | B | 判断 `A && !B` | 走哪个引擎 | |---|---|---|---|---| | 月缴/季缴/半年缴（payIntv=1/3/6） | true | false | true | **TryCal 试算** | | 年缴（payIntv=12）且保险期间**没变** | true | false | true | **TryCal 试算** | | 年缴（payIntv=12）且保险期间**变了** | true | true | false | **PremCal 正式计算** | | 趸缴（payIntv=-1） | true | true | false | **PremCal 正式计算** | | 月缴0（payIntv=0） | true | true | false | **PremCal 正式计算** | | GHB 保单（任意缴费方式） | false | - | false | **PremCal 正式计算** | **通俗结论：** > NGB 保单如果是**期缴**（月缴/季缴/半年缴，或者年缴且本次没动保险期间），在人员清单校验阶段就只做「**试算**」——快速估出一个金额写到清单上给客户看。 > 而**趸缴、月缴0、或年缴且改了保险期间**这几种情况，因为金额算法更复杂（涉及未到期责任分摊、退费计算），要走「**正式计算**」引擎。这也解释了为什么代码注释写 `//ngb期缴走原入`——NGB 期缴场景被单独拎出来做特殊分流。 ## 两个引擎的区别 | | `EdorPremTryCalBL` | `EdorPremCalBL` | |---|---|---| | 类注释 | "**保全费用试算**" | "**保全费用计算**" | | 文件大小 | 约 538 KB | 约 1.38 MB（近 3 倍） | | 定位 | 轻量试算 | 完整正式计算引擎 | | 内部也有趸缴分流 | 有（line 365：`calSinglePrem`） | 有（line 621：`calSinglePrem`） | | 写回 `lbpoedorinsuredlist.reason` | 会（line 631/780/3158 等） | 会（line 1458/1873/2510 等） | | 适用 | 期缴等常规场景 | 趸缴 / 保险期间变化 / GHB 等复杂场景 | > 补充：`EdorPremTryCalBL` 内部 line 365 也有一句 `if ("-1".equals(mPayIntv) || "0".equals(mPayIntv) || ("12".equals(mPayIntv) && checkInsuPeriod))` → `calSinglePrem()`，说明"趸缴/单期"在试算引擎里也有一段专门处理。两个引擎共享 `calSinglePrem` 这类基础方法，但完整度和分支覆盖不同。 ## 整段逻辑的时序位置 ``` 加人比例计算 (line 1006-1035) ↓ 【期缴试算分流】(line 1036-1062) ← 你现在看的这块 ├─ PremTryCalFlag ≠ 1 → EdorPremTryCalBL ├─ 期缴(NGB) → EdorPremTryCalBL └─ 趸缴/期间变化/GHB → EdorPremCalBL ↓ 计算公司退费 (line 1099-1147) ↓ NGB 非阻断提示 (line 1166-1172) ``` --- # 一句话总结三个问题 1. **NGB 混合支付**：本接口没有。混合支付（`PERSONPAYTYPE='3'`）只有 GHB 处理，且它是"回写支付订单号"，**≠ 计算支付比例**。 2. **NGB 比例计算**：确实分两处——`FeegateDeal()` 内算**减人退费比例**（`companyscale`），方法外算**加人收费比例**（`receivablescale`）。 3. **期缴试算**：是一个"用哪套引擎算金额"的分流开关，**期缴→试算（TryCal），趸缴/期间变化/GHB→正式计算（PremCal）**，最终都是把金额写回 `lbpoedorinsuredlist.reason`。需要我继续把 **`EdorPremTryCalBL` 内部怎么算期缴保费**（`calNIPrem` / `calZTPrem`）或者 **`getMoneyOnCompanyOrPerson` 的金风保单特殊处理**再往下拆一层吗？ ------------ 我先把这个试算类的整体结构和大纲摸清楚，再逐层深入计算逻辑。 LSP 超时，改用文本搜索提取方法结构。核心计算框架已清晰。现在深入几个关键计算方法：加人趸缴/期缴、减人退费。深入退费核心算法与期缴加人计算。再补两块：减人标准退费组装逻辑、汇总保存逻辑，以及真正算钱的公共服务类位置。期缴真正的算法在 `EdorPremService` 里。定位它的核心方法，同时看保存与费用汇总。看公共服务类的入口方法与真实费率计算的骨架。最后看真实费率计算入口 `PosCalPremBL.calPrem` 与模板分发逻辑。已经把试算引擎从入口到"真正算钱"的每一层都读完了。下面按 **执行顺序** 完整拆解。 --- # 总览：试算引擎的骨架 `EdorPremTryCalBL` 走的是标准四步式（和 `EdorPremCalBL` 一样的模板）： ```169:188:java/com/sinosoft/lis/pos/EdorPremTryCalBL.java public boolean submitData(VData cInputData, String cOperate) { if (!getInputData(cInputData, cOperate)) { return false; } if (!checkData()) { return false; } if (!dealData()) { return false; } if (!saveData()) { return false; } return true; } ``` | 步骤 | 干什么 | 关键产出 | |---|---|---| | `getInputData` | 取 `EdorAppNo / GrpContNo / ProductTypeFlag`，判断 ASO 产品 | 三个主键 + `tASOFlag` | | `checkData` | 把团单的"计算环境"全部查出来 | 缴费间隔、保险期间、退费规则、账户标记 | | `dealData` | **核心分发**：决定算哪些保全项目、走趸缴还是期缴 | 金额 | | `saveData` | `PubSubmit` 提交 `mMMap` | 落库 | 一句话：**试算 = 只把"每人该收/该退多少"算出来写回清单的 `reason` 字段，不生成正式财务数据（不写 `ljsgetendorse`）。** --- # 第一步：`checkData` 准备"计算环境" 这一步是后面所有公式的"参数仓库"，非常关键： ```236:302:java/com/sinosoft/lis/pos/EdorPremTryCalBL.java mPayIntv = tLCGrpContDB.getPayIntv(); // 缴费间隔，决定趸缴/期缴 mInsuPeriod = tLCGrpContDB.getInsuPeriod(); // 保险期间 mValDate = tLCGrpContDB.getValDate(); // 团单生效日（分母用） mEndDate = tLCGrpContDB.getEndDate(); // 团单止期（分母用） mPremCalMethod = tLCGrpContDB.getPremCalMethod();// GHB 保费计算方式 if("GHB".equals(mProductTypeFlag)){ mSumDateNumber = PubFun.calInterval(mValDate, mEndDate, "D"); // GHB 全年天数 } mClaimCode = ... // 退费计算规则码（lpedorule → ldcodeexp.edorrulecode） if ("1".equals(...)) { mGetCalMode = "1"; } // 账户型产品保全退费算法 if ("1".equals(...)) { mGetCalMode = "2"; } // 按现金价值退费 mInsuAccFlag = ... // 账户型产品标记（IC 项不参与计算） mSZYBFlag = ... // 深圳医保项目标记 mPremCalMode / mEnginArea / mEnginCost // 建工险 ``` **我们要记住几个"分母/开关"：** - `mValDate / mEndDate` → 保费按天折算时的**分母**（整个团单保障期） - `mPayIntv` → 决定走趸缴还是期缴 - `mGetCalMode`（0正常 / 1账户型 / 2现金价值）、`mInsuAccFlag`、`mSZYBFlag` → 特殊算法开关 - `mClaimCode` → 有理赔时的退费规则 --- # 第二步：`dealData` 分发 —— 先分"缴别"，再分"保全项目" ```324:384:java/com/sinosoft/lis/pos/EdorPremTryCalBL.java private boolean dealData() { if("1".equals(tASOFlag)){ return true; } // ASO 产品不算保费 // 1. 查本次受理涉及哪些保全项目 mStrBuff.append("select b.edortype,b.edortypecal from lpedorappitem b "); mStrBuff.append("where b.edortype in('NI','ZT','BE','IC','LC','RN','RD','RG','AA','PT','IR','HT') "); mStrBuff.append("and b.edorappno='"+mEdorAppNo+"'"); mSSRS = mExeSQL.execSQL(mStrBuff.toString()); if (mSSRS.MaxRow>0) { // 2. 按缴费间隔分流 if ("-1".equals(mPayIntv) || "0".equals(mPayIntv) || ("12".equals(mPayIntv) && new EdorPubFun().checkInsuPeriod(mEdorAppNo)) ) { if (!calSinglePrem()) { return false; } // 趸缴/不定期缴 } else { if (!calPeriodPrem()) { return false; } // 期缴 } } return true; } ``` ## 分发树（两棵） **A. `calSinglePrem()` —— 趸缴类**（390 行），按保全项目逐个派发： | 保全项目 | 含义 | 计算入口 | |---|---|---| | NI | 加人 | `calNISinglePrem` → `calPrem("NI")` → **`PosCalPremBL.calPrem()`** | | ZT | 减人 | `calZTSinglePrem` → `calZTStandPrem` + `calZTPrem` | | BE | 受益人变更 | `calBESinglePrem` | | IC | 重要资料变更 | `calICSinglePrem`（账户型产品跳过） | | LC | 方案变更 | `calLCSinglePrem` | | WT/CT/XT | 等待期/退保/… | `calWTSinglePrem` / `calCTSinglePrem` | | RN/RD/RG | 续保/续期/… | 各自 SinglePrem | | AA/PT/IR | 账户调整/部分领取/换人 | 各自 SinglePrem | | HT | 合同变更 | `calHTPeriodPrem` | **B. `calPeriodPrem()` —— 期缴类**（487 行），同样是按项目派发，但**多了一层 GHB 分叉**： ```494:517:java/com/sinosoft/lis/pos/EdorPremTryCalBL.java if ("NI".equals(tEdortype)) { if(... "GHB".equals(mProductTypeFlag)){ if (!calNIPeriodPremGHB(tEdorTypeCal,tEdortype)) { return false; } }else{ if (!calNIPeriodPrem(tEdorTypeCal)) { return false; } // ← NGB/普通走这里 } } else if ("ZT".equals(tEdortype)) { if(... "GHB".equals(mProductTypeFlag)){ if (!calZTPeriodPremGHB(tEdorTypeCal,tEdortype)) { return false; } }else{ if (!calZTPeriodNewPrem(tEdorTypeCal)) { return false; } // ← NGB/普通走这里 } } ``` > 这就是我们上一轮确认过的：**NGB 期缴走 `calNIPeriodPrem` / `calZTPeriodNewPrem`**，GHB 走带 `GHB` 后缀的版本。 --- # 第三步：三条"真正算钱"的路径 ## 路径 1：趸缴加人（NI）—— 从费率表算保费这是最经典的"新契约同款"算法，分两步走。 ### ① 组装被保人参数并算年龄 ```1167:1204:java/com/sinosoft/lis/pos/EdorPremTryCalBL.java Map tLBPOEdorInsuredMap = tLBPOEdorInsuredList.get(i); String tInsuredNo = tLBPOEdorInsuredMap.get("InsuredNo"); String InsuredBirthday = tLBPOEdorInsuredMap.get("InsuredBirthday"); String tEdorValDate = tLBPOEdorInsuredMap.get("EdorValDate"); String tAge = String.valueOf(PubFun.calInterval(InsuredBirthday, tEdorValDate, "Y")); // 年龄 PosCalParam tPosCalParam = new PosCalParam(); tPosCalParam.setInsuredNo(tInsuredNo); tPosCalParam.setAge(tAge); tPosCalParam.setGender(...); // 性别 tPosCalParam.setGrade(...); // 职业类别 tPosCalParam.setServerArea(...); // 服务区 tPosCalParam.setSubstandard(...); // 次标准体 tPosCalParam.setSecurityFlag(...);// 有无社保 tPosCalParam.setSalary(...); // 月薪 tPosCalParam.setPlanCode(...); // 方案编码 tPosCalParam.setEdorValDate(tEdorValDate); ... if (!mPosCalPremBL.calPrem(tPosCalParam)) { ... } // 交给 PosCalPremBL ``` ### ② `PosCalPremBL.calPrem()` 内部：先算保额，再算保费 **算保额**（按 `AmntType` 分 6 种口径）： | AmntType | 含义 | 公式 | |---|---|---| | 01 | 固定保额 | `FixedAmnt` | | 02 | 月薪倍数 | `月薪 × SalaryMult` | | 03 | 最低保额与月薪倍数取大 | `max(月薪×倍数, MinAmnt)` | | 04 | 非固定保额 | `UnfixedAmnt` | | 05 | 最高保额与月薪倍数取小 | `min(月薪×倍数, MaxAmnt)` | | 06 | 最高/最低保额区间 | 三者取中 | **算保费**（按 `ExceptPremType`）： ```360:384:java/com/sinosoft/lis/pos/PosCalPremBL.java if ("01".equals(tExceptPremType)) { // 期望保费 tPrem = new BigDecimal(tFinalValue); if ("1".equals(mPosCalParam.getmPremTryCalFlag())) { tPrem = tPrem.multiply(new BigDecimal(PubFun.calInterval(mPosCalParam.getEdorValDate(), mLCGrpContSchema.getEndDate(), "D"))) .divide(new BigDecimal(PubFun.calInterval(mLCGrpContSchema.getValDate(), mLCGrpContSchema.getEndDate(), "D")), 2, BigDecimal.ROUND_HALF_UP); } // ← 试算标记为 1 时：按剩余天数折算！ } else if ("02".equals(tExceptPremType)) { // 期望费率 tPrem = new BigDecimal(tAmnt).multiply(new BigDecimal(tFinalValue)); } else if ("04".equals(tExceptPremType)){ // 年龄保费 tPrem = calAgePrem(tSysPlanCode, tRiskCode, tDutyCode, tAge); // 查 LCContAgeDutyPrem } ``` **算年龄保费**（`calAgePrem`，年龄社保/非社保分档）： ```583:607:java/com/sinosoft/lis/pos/PosCalPremBL.java for(int k = 1 ; k <= tLCContAgeDutyPremSet.size() ; k++){ minAge = ...getBeginAge(); maxAge = ...getEndAge(); if(sysPlanCode.equals(...) && riskCode.equals(...) && dutyCode.equals(...) && iAge>=minAge && iAge<=maxAge){ if("1".equals(securityFlag)){ prem = ...getSocialPrem(); } // 社保 else { prem = ...getNotSocialPrem(); } // 非社保 break; } } ``` ### ③ 回到 `calPrem` 做"责任层折算 + 汇总" ```1214:1230:java/com/sinosoft/lis/pos/EdorPremTryCalBL.java BigDecimal tPrem = new BigDecimal(tPosPremResult.getPrem()); String PeriodPrem = tPrem.divide(new BigDecimal(mLCContPubFun.getPayYears(...)), 10, ...).toString(); BigDecimal edorprem = new BigDecimal(0); if(checkInsuPeriod(tPosPremResult.getSysPlancode())==true) { edorprem = tPrem.multiply(new BigDecimal(PubFun.calInterval(tEdorValDate, mLCGrpContSchema.getEndDate(), "D"))) .divide(new BigDecimal(PubFun.calInterval(mLCGrpContSchema.getValDate(), mLCGrpContSchema.getEndDate(), "D")),2,...); } else { edorprem = tPrem.setScale(2, RoundingMode.HALF_UP); } tPosPremResult.setPeriodPrem(PeriodPrem); tPosPremResult.setPrem(edorprem.toString()); ``` 即：**责任保费 = 标准保费 × (保全生效日→团单止期的天数 ÷ 团单起期→止期的天数)**（需要按剩余保障期折算时）。 > ⚠️ 命名陷阱：`EdorPremTryCalBL.checkInsuPeriod(splancode)`（1239 行）返回 `true` 表示"个人保险期间与团单**一致或为空**"；而 `PosCalPremBL.checkInsuPeriod()`（471 行）返回 `true` 表示"**不一致**"（见其 357 行注释 `true:不一致`）。同名反义，读代码时务必看清是哪一个。 ### ④ 汇总回写 ```1108:1117:java/com/sinosoft/lis/pos/EdorPremTryCalBL.java List tPosPremResults = tInsuredPremMap.get(tLBPOEdorInsuredMap.get("serialno")); BigDecimal tInsuredEdorPrem = new BigDecimal(0.0); // 该被保人全部责任的应收保费 for(int j=0;j paytoDateByPayObjMap = getpaytoDateByPayObjMap(...); // 3. 用 BatchDataQueryDB 一次性关联查出每责任的完整信息 String sql = "select t1.contNo,t1.insuredNo,...,t3.periodprem,t3.dutycode,... from lbpoedorinsuredlist t1 " + " left join lppol t2 ... left join lpduty t3 ... left join lcinsured d ... " + " left join lcgrpcont t6 ...left join lcprintappnt p ..."; // 4. 交给公共服务类，bud 直接在服务里更新 reason EdorPremService edorPremService = new EdorPremService(); edorPremService.calNIPrem(batchDataQueryDB, "NI", "0", mLCGrpContSchema.getValDate(), Integer.parseInt(mLCGrpContSchema.getPayIntv()), mLCGrpContSchema.getEndDate(), PubFun.parseStringDate(payToDate), tList, mEdorAppNo, mSZYBFlag); ``` `EdorPremService.calNIPrem` 只做转发： ```127:136:java/com/cignacmb/gcis/pos/service/EdorPremService.java public void calNIPrem(BatchDataQueryDB bdq, String edortype, String flag, ...) { getPosPremTempLate(bdq, edortype, flag, firstpayDate, payInterval, endDate, payToDate, buds, edorappNo, "0", null, null, null,null,null,mSZYBFlag); // "0"=收费 } ``` `getPosPremTempLate` 的 `insuredOrReturnFlag` 很关键： | 值 | 含义 | 调用方 | |---|---|---| | 0 | 收费 | `calNIPrem` | | 1 | 退费 | `calZTPrem` | | 2 | 有收有退 | `calLCPrem`（方案变更） | | 3 | 重要资料变更 | `calICPrem` | 其中还有一段"纯收费需重新算年龄"的逻辑： ```253:258:java/com/cignacmb/gcis/pos/service/EdorPremService.java if ("0".equals(insuredOrReturnFlag)) { // 如果是纯收费，则需要计算出具体年龄 age = String.valueOf(PubFun.calInterval(templateParamsVo.getAge(), templateParamsVo.getEdorValDate(), "Y")); templateParamsVo.setAge(age); } ``` > 期缴的核心是 **`payToDate`（缴至日期）**：保费 = 按 `payInterval` 从 `payToDate` 推算到保全生效日应补的期数 × 每期保费。这也是为什么代码里反复强调"非见费出单时 payToDate 要取团单层"（GCIS-13395）。 --- ## 路径 3：减人（ZT）退费 —— 按天比例退款这是三条路径里业务规则最重的。 ### ① 先按"退费原因"算每个责任的标准退费 ```1488:1537:java/com/sinosoft/lis/pos/EdorPremTryCalBL.java // 犹豫期外退保 if("01".equals(tChargeReason)) { if("1".equals(tSZYBProductNum)) { // 深圳医保：只对主责任退现价 calZTPrem = new BigDecimal(tEdorCalTBBL.getDutyCashValue(tPolNo, tDutyCode, tEdorValDate)).multiply(new BigDecimal(-1)); } else { calZTPrem = calZTPrem(tEndDate, tValDate, tPrem, tGrpEndDate, tEdorValDate); } } // 犹豫期内退保 / 解约（全额退费） else if ("02".equals(tChargeReason) || "03".equals(tChargeReason)) { String tSZYBRiskFlag = LJFinFeePubFun.getSZYBComCode(tRiskCode); if("1".equals(tSZYBRiskFlag)) { calZTPrem = calTFPrem6year(...); } else { calZTPrem = calZTPrem(tEndDate, tValDate, tPrem, tGrpEndDate, tEdorValDate); } } // 解约（不退费） else if ("04".equals(tChargeReason)) { calZTPrem = new BigDecimal(0); } else { calZTPrem = calZTPrem(tEndDate, tValDate, tPrem, tGrpEndDate, tEdorValDate); } ``` | `chargereason` | 场景 | 算法 | |---|---|---| | 01 | 犹豫期外退保 | 按天折算，或深圳医保退现价 | | 02/03 | 犹豫期内 / 解约全额退 | 按天折算（长险走 `calTFPrem6year`） | | 04 | 解约不退 | 0 | | 其他 | 默认 | 按天折算 | ### ② 核心公式 `calZTPrem`（按天折算） ```1577:1599:java/com/sinosoft/lis/pos/EdorPremTryCalBL.java private BigDecimal calZTPrem(String enddate, String valdate, String prem, String grpenddate, String edorvaldate) { BigDecimal tBigDecimal=new BigDecimal(0); BigDecimal tPrem=new BigDecimal(prem); // 责任止期 <= 保全生效日 → 已经结束，退 0 if(enddate.compareTo(edorvaldate)<=0){ return tBigDecimal; }else{ if(valdate.compareTo(edorvaldate)<=0){ // 失效日落在责任期中间：只退"保全生效日之后尚未经过"的天数 int tempDates = PubFun.calInterval(edorvaldate, enddate, "D"); tBigDecimal=tPrem.multiply(new BigDecimal(tempDates)) .divide(new BigDecimal(PubFun.calInterval(grpenddate, valdate, "D")), 2, ROUND_HALF_UP); }else{ // 责任起期 >= 保全生效日：整段全退 tBigDecimal=tPrem.multiply(new BigDecimal(PubFun.calInterval(enddate, valdate, "D"))) .divide(new BigDecimal(PubFun.calInterval(grpenddate, valdate, "D")), 2, ROUND_HALF_UP); } } return tBigDecimal; } ``` 用图表示（`个单止期` 是分母端点）： ``` 个单起期 grpValDate ──────────────── 个单止期 grpEndDate 责任起期 valDate ──── 责任止期 endDate 保全生效日 edorValDate 退费 = prem × (edorValDate → endDate 天数) / (grpEndDate → valDate 天数) ``` ### ③ 有理赔的特殊处理（02 全不退 / 03 部分退） ```1315:1361:java/com/sinosoft/lis/pos/EdorPremTryCalBL.java for (String key : calZTStandPrem.keySet()) { ... String insuredClmRule = ... // 个人层 AFTERCLMRULE if ("1".equals(clmFlag) && "03".equals(insuredClmRule)) { posPremResult.setPrem("0"); // 有理赔 + 部分退 → 该责任退 0 } else if("02".equals(insuredClmRule)){ logger.info("有理赔退费，无需处理:"+mEdorAppNo); // 全不退 → 跳过 } else if (StringUtils.isEmpty(insuredClmRule)){ if ("1".equals(noChargeFlag)) { break; } String planRule = ...; // 方案层 AFTERCLMRULE String afterClmRule = ...; // 险种层 AFTERCLMRULE（再退到 lmriskapp） if ("01".equals(planRule) && insuredClaims.containsKey(key)) { posPremResult.setPrem("0"); } else if ("03".equals(afterClmRule) && insuredClaims.containsKey(key) && set.contains(posPremResult.getRiskCode())) { posPremResult.setPrem("0"); } } } ``` 规则优先级：**个人层 → 方案层 → 险种层 → 险种基础配置（lmriskapp）**，逐级兜底。 ### ④ 汇总时扣退保手续费 ```1383:1394:java/com/sinosoft/lis/pos/EdorPremTryCalBL.java String chargeRule = ... // 险种层 CHARGERULE if(!"1".equals(noChargeFlag) && "05".equals(chargeRule)) { tBigDecimal = tBigDecimal.add( new BigDecimal(posPremResult.getPrem()) .multiply(new BigDecimal(1).subtract(new BigDecimal(tFRate))) // prem × (1 - 手续费率) .setScale(2, BigDecimal.ROUND_HALF_UP)); } else { tBigDecimal = tBigDecimal.add(new BigDecimal(posPremResult.getPrem())); } ``` 手续费率 `tFRate` 来自 `ldcodeexp(codetype='edorrulecode', codeexp='ZT')`。 --- # 第四步：结果怎么落地所有路径的最终动作都是同一句（只是条件不同）： ```java update lbpoedorinsuredlist set reason = ? where edorappno=? and contno=? and insuredno=? and edortype=? ``` 代码里直接点破了原因： ```1115:1117:java/com/sinosoft/lis/pos/EdorPremTryCalBL.java //借用reason字段存试算的金额咯，校验成功的被保人应该没有reason bdu.setField(1, tInsuredEdorPrem.toString()); bdu.setField(2, tLBPOEdorInsuredMap.get("serialno")); ``` `saveData` 只提交 `mMMap`（155 行 `mMMap` 是空的？实际试算路径全部走 BatchDataUpdateDB 直连更新，所以 `saveData` 提交的其实是空 MMap）： ```8282:8294:java/com/sinosoft/lis/pos/EdorPremTryCalBL.java private boolean saveData() { mInputData.clear(); mInputData.add(mMMap); PubSubmit tPubSubmit = new PubSubmit(); if (!tPubSubmit.submitData(mInputData, null)) { buildError("saveData", "提交数据失败！"); return false; } return true; } ``` > 这印证了"试算"的本质：**它只 UPDATE 清单表的 `reason` 展示字段，不产生 `ljsgetendorse` 等正式财务记录**。金额真正入账，是后续核保/签发环节（`EdorPremCalBL` 或财务模块）的事。 --- # 完整流程图 ``` submitData ├─ getInputData 取受理号/团单号/ProductTypeFlag，判 ASO ├─ checkData 取团单参数(PayIntv/ValDate/EndDate)、退费规则、特殊标记 ├─ dealData │ ├─ 查 lpedorappitem → 本次涉及哪些保全项目 │ └─ 按 PayIntv 分流 │ ├─ 趸缴(-1/0/12且期间变) → calSinglePrem() │ │ ├─ NI → calPrem() → PosCalPremBL.calPrem() │ │ │ ├─ 算保额(AmntType 01~06) │ │ │ ├─ 算保费(ExceptPremType 01/02/04 → calAgePrem) │ │ │ └─ 责任层按天数折算 │ │ ├─ ZT → calZTStandPrem() + calZTPrem()（按天退费） │ │ └─ 其他项目各自处理 │ └─ 期缴 → calPeriodPrem() │ ├─ NI → calNIPeriodPrem() → EdorPremService.calNIPrem() │ ├─ ZT → calZTPeriodNewPrem() → EdorPremService.calZTPrem() │ └─ (GHB 走 *GHB 后缀版本) └─ saveData 提交（试算仅更新 reason 字段） ``` --- # 三句话记忆 1. **试算不改钱，只算钱** —— 全程只 `update lbpoedorinsuredlist.reason`，不生成 `ljsgetendorse`。 2. **先分缴别、再分项目** —— 趸缴走 `PosCalPremBL`（费率表算法），期缴走 `EdorPremService`（按缴费节点分摊）。 3. **减人是唯一"按天退款"** —— `prem × 剩余天数 ÷ 责任总天数`，再叠加理赔规则和退保手续费。 --- 要不要我接着往下钻一层？两个方向可选： - **`calZTPeriodNewPrem` 的期缴退费公式**（怎么按"已缴期数"算退费，含 `ljspayperson/ljapayperson` 那些 `sumduepaymoney` 聚集）； - **`PosCalPremBL.calStandPrem()` 标保计算**（标准保费怎么由保额/费率/年龄折扣一步步推出来）。

世界偶尔 404，热爱永远在线。