刘泉佳
|
ffc2f6eea2
|
fix: A301-3 报文取数按契约修正——awrp_src_code=分摊结算单号拼接,seq/e_corebillno=结算单id
|
2026-09-29 10:48:50 +08:00 |
|
刘泉佳
|
9cf42b4105
|
feat: 收款流水列表补充收款金额区间与认领人筛选(认领人经认领记录参数化两段查询过滤)
|
2026-09-29 10:28:27 +08:00 |
|
b2894lxlx
|
087f361a8b
|
✨ 组织类型改业务字典,并完善金蝶部门代码与MK再提交
组织类型翻译切换为 organization_type;新增金蝶部门代码字段;流程已结束或已通过时强制新建MK表单实例。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-09-29 03:15:26 +08:00 |
|
b2894lxlx
|
32cff235e0
|
🐛 修复审核通过后再提交未新建MK流程实例的问题
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-09-29 02:44:48 +08:00 |
|
b2894lxlx
|
fc1e9a95de
|
mk调试
|
2026-09-29 02:23:59 +08:00 |
|
b2894lxlx
|
beb0850644
|
✨ 解耦MK表单实例与业务ID,公开页按formInstanceId反查业务数据
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-09-29 02:23:19 +08:00 |
|
刘泉佳
|
4c32cb9046
|
docs: 新增预付款申请A103-3金蝶链路补齐方案
覆盖三项改造:e_bebank_number 与 A103-1 统一取联行号、A103-2 消失解锁兜底(ADR-0005)、
回写任务开关默认策略;含状态机全景、时序图、配置汇总与联调验证要点
|
2026-09-29 01:51:07 +08:00 |
|
刘泉佳
|
846f080343
|
fix: 金蝶付款结果回写开关注释纠正且环境配置默认开启
PaymentKingdeeResultTask 注释写「默认开启」与 @Value 兜底默认 false 矛盾,注释纠正为代码兜底关闭;
Nacos 三套配置(blade-dev/blade-prod/third-party-api)syncEnabled 默认改 true,按环境显式开启回写任务
|
2026-09-29 01:50:53 +08:00 |
|
刘泉佳
|
2079da6195
|
feat: 付款申请新增金蝶单据消失解锁兜底(A103-2连续两轮查询消失)
金蝶侧反审核删除付款申请单后,本地停留已生成/付款中且状态门禁禁止重推,单据卡死。
按 ADR-0005 新增 unlockBill():置生成失败、清空金蝶单据内码/编号(日志留档)、不自动重推;
A103-2 定时回写对已推送单据连续两轮未查得(Redis 计数,TTL 覆盖三个回写周期)触发解锁;
failed 单据不参与计数,Redis 异常放弃判定,重推链 A103-2 勾稽预检兜底防重复单据;
B901 UNLOCK 回调后续接入复用同一 unlockBill()
|
2026-09-29 01:50:36 +08:00 |
|
刘泉佳
|
f4f4360e5a
|
feat: 预付款推送金蝶往来银行编码改取客商收款账户联行号
A103-3 分录 e_bebank_number 原取银行名称字段,与 A103-1 口径不一致;
统一改取付款申请所选客商收款账户(blade_customer_receipt_account)联行号,未维护即拦截推送
|
2026-09-29 01:48:04 +08:00 |
|
刘泉佳
|
e7d16eeb74
|
feat: 认领记录列表支持按流水推送状态筛选
|
2026-09-29 01:32:09 +08:00 |
|
刘泉佳
|
79abfa966b
|
feat: 收款流水分页查询补充常用筛选条件(推送状态/金蝶回写状态/明细流水号)
|
2026-09-29 01:25:31 +08:00 |
|
刘泉佳
|
2e91e112ff
|
feat: 收款认领本地化,认领完成才推金蝶——A301-3定时+手动双入口按流水归集推送
- 认领只落本地:claim() 删除事务内同步推送,认领上限/认领完成口径改为公告未认领金额
- 推送闸门:认领完成且未推送过才可推;推送前重查A301-2最新公告对账,不一致拦截并提示差额
- 按流水归集:一条流水一张金蝶收款单,分录取全部有效分摊行;awrp_src_code 上移至流水、重试复用防重试双单
- 已推送终态闸门禁止二次推送;推送失败落 push_status/push_fail_reason 可重试,本地认领不回滚
- 定时任务 ReceiptClaimPushTask(thirdParty.bfi.receiptClaimPush.*,按认领人分组重查公告)+ 手动按钮 POST /receipt-flow/push-kingdee
- A301-1 回写轮询对象改流水并级联刷新认领主单冗余字段;作废仍不触发推送
- 认领链路批量化:结算单锁行/认领额聚合/汇总刷新改 IN 批量,候选单列表消除每页200次N+1,同步留痕 Db.saveBatch
|
2026-09-29 01:02:54 +08:00 |
|
刘泉佳
|
98614a25cc
|
perf: 结算单收款汇总批量化——refreshPaymentSummaries 固定数次批量查询替代逐单N+1,calculatePaymentSummary 拆纯计算重载保持口径一致
|
2026-09-29 01:02:33 +08:00 |
|
刘泉佳
|
f97237afe5
|
docs: 收款认领推送金蝶重构设计与业务流程文档、幂等变更SQL、集成语境术语
|
2026-09-29 01:02:14 +08:00 |
|
刘泉佳
|
cf6db499de
|
fix: A301-3 收款认领结果推送接口金蝶字段
|
2026-09-28 18:57:42 +08:00 |
|
刘泉佳
|
bdae054b0b
|
fix: 修复收款流水同步与认领推送问题
|
2026-09-28 18:40:05 +08:00 |
|
刘泉佳
|
145cb57e00
|
fix: 修复收款流水同步与认领推送问题
|
2026-09-28 17:54:43 +08:00 |
|
刘泉佳
|
0b88d05e93
|
docs: 收款流水同步方法增加详细日志和注释说明
|
2026-09-28 16:04:43 +08:00 |
|
刘泉佳
|
978caa640a
|
perf: 收款流水同步改为批量查询与批量保存(N+1→批量)
|
2026-09-28 15:59:39 +08:00 |
|
刘泉佳
|
4d62bb6df7
|
feat: A301-2 认领公告查询接口适配新参数(billstatus/modifytimeS/modifytimeE),时间窗口配置化(Nacos thirdParty.bfi.claimAnnounce.months,默认6个月)
|
2026-09-28 15:49:53 +08:00 |
|
刘泉佳
|
85b703b7d5
|
docs: 补充KingdeeReceiptFlow实体字段说明注释
|
2026-09-28 15:17:18 +08:00 |
|
刘泉佳
|
f292bb28a0
|
fix: 开户银行.编码(行号)
|
2026-09-28 14:40:10 +08:00 |
|
刘泉佳
|
f901ad3ff5
|
fix: 合并附件上传分支的编译报错
|
2026-09-28 10:54:45 +08:00 |
|
刘泉佳
|
a2abb3f921
|
Merge remote-tracking branch 'origin/feature/kingdee-attachment-sync' into feature/payment-apply-bfi-sync
# Conflicts:
# blade-common/src/main/java/org/springblade/common/feign/CustomFeignLogger.java
# blade-service/blade-transport/src/main/java/org/springblade/transport/service/impl/FormalSettlementServiceImpl.java
# blade-service/blade-transport/src/main/java/org/springblade/transport/service/impl/InvoiceApplicationServiceImpl.java
# blade-service/blade-transport/src/main/java/org/springblade/transport/service/impl/InvoiceReceiptServiceImpl.java
# blade-service/blade-transport/src/main/java/org/springblade/transport/service/impl/PaymentApplicationServiceImpl.java
# blade-service/blade-transport/src/main/java/org/springblade/transport/support/KingdeeApBillSyncSupport.java
# blade-service/blade-transport/src/main/java/org/springblade/transport/support/KingdeeArBillSyncSupport.java
|
2026-09-28 10:50:09 +08:00 |
|
刘泉佳
|
15532feb81
|
Merge branch 'fix/a801-3-writeback-dedup-key' into feature/payment-apply-bfi-sync
|
2026-09-28 09:27:58 +08:00 |
|
刘泉佳
|
7e76964a76
|
feat: 金蝶定时同步加single-flight分布式锁,多副本与手动触发共用一道闸(付款结果回写/应收勾稽/开票结果/收票结果/客商同步)
- 新增 KingdeeSyncLockSupport:零等待tryLock+租约可配+租户隔离,未启用blade.lock.enabled时降级并告警
- 各同步方法拆为锁壳+executeXxxSync主体,锁在service层保证手动触发端点与定时任务行为一致
- 租约配置:thirdParty.bfi.{payResult|arResult|invoiceResult|receivedInvoice|customer}.lockLeaseSeconds,默认1800秒
|
2026-09-28 00:52:12 +08:00 |
|
刘泉佳
|
8b98e33daa
|
fix: 修复A801-3收票单定时回写按发票号匹配防重键导致回写失效
回写查询集与命中查找改用收票登记id(String.valueOf(receipt.getId())),
与A303-2落库的awrp_src_code及243d5be已修复的推送预检/A302-6路径同源;
原按发票号匹配永远查不到TMS自推单据,异常回收/指定补偿/单号补登全部静默失效。
同步修正queryReceivedInvoiceBySrcCodes过时javadoc(发票号码→收票登记id)。
|
2026-09-28 00:44:10 +08:00 |
|
b2894lxlx
|
247440288b
|
🐛 修复运单计划-1占位,并对账导入失败明细按原表全量列导出
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-09-27 23:16:17 +08:00 |
|
b2894lxlx
|
eef9d7ad9d
|
✨ 完善运单导入配载标识、导入状态与凭证文件夹统计
记录配载标识号并在同批次多运单时生成配载单,导入状态与运单状态对齐,凭证按车牌文件夹统计并支持压缩包重传匹配。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-09-27 22:54:30 +08:00 |
|
刘泉佳
|
2f5bb4a5a8
|
📝 新增金蝶附件上传下载链路梳理文档(A902上传+A801-2下载+对应关系核对)
|
2026-09-27 22:40:21 +08:00 |
|
刘泉佳
|
4e2f565d2f
|
fix: 金蝶附件同步失败转成功时显式置空失败原因,修复updateById忽略null字段导致历史失败原因残留
|
2026-09-27 22:38:14 +08:00 |
|
b2894lxlx
|
f3a614ffe9
|
Merge branch 'master' of https://git.websoft.top/b2894lxlx/tms-erp-api
|
2026-09-27 21:27:14 +08:00 |
|
b2894lxlx
|
1185c9792c
|
🐛 修复车务非必填-1占位落库,并完善总单分段调度与运单导入
上一段运单完成到达后才可调度且不超过到达量;车务多模块保存/列表/导出将-1归一为null;同步网关大报文限制与导入校验能力。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-09-27 21:26:54 +08:00 |
|
刘泉佳
|
a3f1e07b2f
|
feat: 金蝶票池发票文件下载(A801-2):按发票号镜像优先/实时回源定位,后端流式代理供前端查看下载
|
2026-09-27 21:17:52 +08:00 |
|
b2894lxlx
|
0c52797c31
|
Merge remote-tracking branch 'websoft/fix/issue-2-10-import-batch-rollback'
|
2026-09-27 13:03:12 +08:00 |
|
weicw-dshsa
|
c86c5ff968
|
🔀 合并 fix/issue-2-10-import-batch-rollback
导入链路整批修复(issues #2-#10 + 违章/记录类/台账类/运输对账等):
- 所有批量导入改为「任一行失败即整批回滚」
- 失败明细返回原表全量并逐列标红(不再只给错误行)
- 读取阶段异常兜底,不再暴露 HTTP 500 技术文案
- 空表提示改为「未读取到数据行,请确认表头下方已填写内容」
- 修复常用货物型号必填漏校验、运输对账动态费用列静默转 0、
失败明细行号错位等
详见该分支 16 个提交。
|
2026-09-26 15:30:04 +08:00 |
|
weicw-dshsa
|
4ccc28e991
|
🐛 修复三处导入校验缺陷与失败明细行号错位
对全仓 31 处导入入口做了一次「导入校验 vs 新增/编辑校验」的一致性审计,
以下三处是审计中严重度最高的、且业务口径无歧义的缺陷:
1) 常用货物:型号必填只在新增/编辑生效,导入侧被放过
submit(CommonCargo) 走 validate(cargo, requireModel=true),而导入调
submit(cargo, false) —— 页面上存不进去的数据(型号为空)却能通过导入写进库。
CommonCargoExcel 的「型号」列也没标 *,用户按模板填根本不知道它必填。
改法:去掉 requireModel 开关(该参数已成死参数,留着只会让两边再次分叉),
导入与新增/编辑共用同一个 validate;模板表头改 *型号。
2) 运输对账:动态费用列填非数字被静默改成 0.00
VehicleReconciliationFeeReader / CargoReconciliationFeeReader 的 decimal()
在 catch (NumberFormatException) 后直接返回 ZERO —— 「一百元」变成 0.00 存进
feeItemsJson,参与结算金额与自动匹配,属静默写脏数据。
改法:抛新增的 ImportCellReadException(blade-common),带上行号/列名/原值,
由既有读取阶段兜底导出原表全量明细。
3) 运输计划:文案「数量/里程必须为正数」与规则不符
条件只判 < 0(0 是合法值),新增/编辑侧的文案是「不能小于0」。统一为「不能小于0」。
顺带修掉一个更基础的错位:
ImportFailureExcelUtil.readFailureRowIndex 直接拿
ExcelDataConvertException.getRowIndex() 当失败明细的行下标,但前者是
【绝对 0 基行号】(表头=0),后者只对数据行计数。错误恰好落在最后一行时
靠 clamping 侥幸正确,落在首行就会把原因标到下一行 —— 实测首行出错时原因
被标到了第 3 行(应为第 2 行)。现统一换算(-1)并把两类异常收口到
readFailureExcelRowIndex。
验证:
- mvn clean install -DskipTests 通过。
- 全套 16 个导入回归脚本 469 项断言全绿,其中:
- 运单核对新增用例 04(首行读取失败须标在第 2 行)、05(动态费用列填中文
必须报错),运单核对套件 28 项全绿;
- 常用货物新增用例 08(型号为空须整批回滚),套件 29 项全绿;
- 读取失败套件 4 项全绿,证明行号修正未破坏既有断言。
|
2026-09-26 12:45:17 +08:00 |
|
weicw-dshsa
|
9bf7fdfe99
|
⚡ 空表导入提示改为「未读取到数据行,请确认表头下方已填写内容」
原提示「导入数据不能为空」在用户上传「只有表头、未填数据行」的文件时容易误解
(文件并非空文件,只是没填内容)。全项目 27 个模块、30 处统一替换该文案。
验证:mvn install -DskipTests 通过;空表上传返回新文案;
13 个导入回归脚本 383 项断言全绿。
|
2026-09-26 11:50:57 +08:00 |
|
weicw-dshsa
|
2d185f0de6
|
🐛 导入单元格无法转换时改为返回可读失败明细,兜底 26 个导入接口
问题(用户实测反馈):金额列填「一万二千元」这类无法转换的内容时,EasyExcel 在
ExcelUtil.read(...) 阶段就抛 ExcelDataConvertException,根本走不到行级校验;
控制器只 catch ImportFailureException,异常穿透到全局处理器,用户看到的是
HTTP 500 + 「Convert data ... to class java.math.BigDecimal error」这类技术文案,
且完全拿不到失败明细。
影响面:全部 27 个导入接口(读阶段的 ExcelUtil.read 都在 try 内、只 catch
ImportFailureException),非维修记录独有。
改动:
- ImportFailureExcelUtil 新增三个能力(blade-common,公共层一次覆盖各模块):
1) describeReadFailure:把 ExcelDataConvertException 转成
「第N行「列名」格式不正确:<原值>」,列名按列序号反查 @ExcelProperty;
2) readRawRows:以原始文本(Map)方式重读文件,不做类型转换因此绝不抛异常,
用于拿回「原表全部行」;
3) exportReadFailure:一站式兜底(重读 → 导出全量行 + 仅出错行带原因 +
按列标红),返回 false 表示非转换类异常,调用方继续抛出保持原行为。
- 26 个导入控制器在现有 catch 之后追加 catch(Exception) 兜底,未改动原有
行级校验与整批回滚逻辑。
验证:
- 实测维修记录/费用项/币种汇率三个模块:HTTP 500→200,返回全量明细,
文案如「第5行「费用」格式不正确:一万二千元」(行号经单行/四行文件双向校准)。
- 既有回归无退化:记录类 80/80、台账 32/32、港口码头 45/45、货物类型 24/24、
费用项 20/20、币种汇率 25/25。
- 新增 scripts/api-read-failure-test.sh(4 断言)固化该场景。
|
2026-09-26 11:37:07 +08:00 |
|
weicw-dshsa
|
be02a5e942
|
🐛 修复运输对账导入无回滚与运输计划明细不全(批次4)
本批是 16 个模块收尾,两个特殊模块:
1) 运输对账(importVehicles / importCargoes)——最严重的一例:
既无 setRollbackOnly 也不抛异常。方法开头 resetExternal(id) 清空既有外部账单,
循环末尾无条件插入本批正确行,然后 return failures。一旦有失败行:
旧外部账单已被清空、新账单只插入了部分——数据损坏且不可恢复。
改法:任一行失败时抛 ImportFailureException(rows),让 resetExternal 清空
与本批插入在同一事务内一起回滚。另把失败原因写回原行(异常携带原表 rows,
只写 Vehicle/CargoReconciliationFailureExcel 副本会丢原因)。
控制器改 catch 异常导出原表全量(用 export 保留按列标红)。
2) 运输计划(importTransportPlan)——失败明细只返回 errorMap.values()(仅错误行)。
改为抛 ImportFailureException(data) 携带原表全量;控制器 catch 后导出。
验证:mvn install -DskipTests 通过;全项目 12 个导入回归脚本 379 项断言全绿。
全项目已无 TransactionAspectSupport...setRollbackOnly() 调用残留。
注:运输对账需先建对账草稿(多张前置表)才能端到端回归,
本批仅完成代码改造与编译验证,回归用例待补(见后续说明)。
|
2026-09-26 11:10:37 +08:00 |
|
weicw-dshsa
|
962bcc7879
|
🐛 台账/主数据类导入(4 个模块)失败明细返回全量原表
覆盖:设备台账 / 保养计划(blade-transport)、铁路站点 / 机场主数据(blade-system)。
问题同前两批:收集 errorList 后 setRollbackOnly 并 return,控制器据此导出
「仅错误行」——失败明细不是原表全量,用户无法对照原表修正。
改动(同构):
- 服务层:抛 ImportFailureException(data),明细携带原表全部行;
回滚由异常触发(替代 setRollbackOnly)。注意 blade-system 的两个模块
用的是静态导入 TransactionAspectSupport,模式略有差异。
- 控制器:catch 异常取 getFailureList() 导出(用 export 保留按列标红),
补上传文件校验。
验证:mvn install -DskipTests 通过;台账回归 32/32,记录类回归 80/80。
|
2026-09-26 10:58:15 +08:00 |
|
weicw-dshsa
|
96010cf542
|
🐛 记录类导入(第二批 4 个模块)失败明细返回全量原表
覆盖:里程记录 / 油电记录 / 其他费用记录 / 运输变更记录。
问题同第一批:收集 errorList 后 setRollbackOnly 并 return,控制器据此导出
「仅错误行」——失败明细不是原表全量,用户无法对照原表修正。
改动(同构):
- 服务层:抛 ImportFailureException(data),明细携带原表全部行;
回滚由异常触发(替代 setRollbackOnly)。
- 控制器:catch 异常取 getFailureList() 导出(用 export 保留按列标红),
补上传文件校验。
验证:mvn install -DskipTests 通过;记录类回归 80/80
(10 模块 × 2 用例,含第一批 6 个模块的回归确认)。
|
2026-09-26 10:52:02 +08:00 |
|
weicw-dshsa
|
f24209fa8e
|
🐛 记录类导入(6 个模块)失败明细返回全量原表
问题:这 6 个模块(事故记录/年检记录/ETC记录/保险记录/维修记录/换胎记录)
在收集 errorList 后 setRollbackOnly 并 return,控制器据此导出「仅错误行」——
失败明细不是原表全量,用户看不到哪几行是对的、不便对照原表修正。
改动(6 个模块同构处理):
- 服务层:改为抛 ImportFailureException(data),明细携带**原表全部行**;
整批回滚由异常触发(替代 setRollbackOnly,语义不变)。
- 控制器:catch 异常后取 getFailureList() 导出,并补上传文件校验。
用 export(...) 保留按列标红(exportFailureReasonOnly 会丢失该能力)。
验证:mvn install -DskipTests 通过;记录类回归 48/48
(scripts/api-records-import-test.sh,6 模块 × 2 用例)。
标志性断言:3 行正确 + 第 4 行错 → 明细返回全部 4 行、仅第 4 行带原因、
库中零写入;全部正确 → 正常入库。
|
2026-09-26 10:46:39 +08:00 |
|
weicw-dshsa
|
81824b5062
|
🐛 违章记录导入失败明细返回全量原表
问题:importViolationRecord 收集 errorList 后 setRollbackOnly 并 return,
控制器据此导出「仅错误行」——失败明细不是原表全量,用户看不到哪几行是对的、
也不便对照原表修正(用户反馈:违章记录没有返回全量表格)。
改动:
- 服务层:改为抛 ImportFailureException(data),明细携带**原表全部行**;
整批回滚由异常触发(替代 setRollbackOnly,语义不变)。
- 控制器:catch 异常后取 getFailureList() 导出,并补上传文件校验。
用 export(...) 而非 exportFailureReasonOnly(...):后者会把 markErrorColumns
置 false、只标红失败原因列,导致「按列标红」能力丢失(实测 5 个既有用例
标红列变空);export(...) 同时保留全量行与按列标红。
验证:mvn install -DskipTests 通过;违章记录回归 40/40
(既有 9 用例,标红列断言全绿:03 类型 / 04 事项 / 05 事项 / 06 类型 / 08 车牌号/船号);
用户实际上传文件实测:失败明细返回全量 5 行、仅错误行带原因、标红[车船类型,状态]、
库中零写入。其余 8 个导入模块回归 187 项全绿,无连带影响。
|
2026-09-26 10:30:39 +08:00 |
|
b2894lxlx
|
e09380e902
|
🐛 MK流程结束直接同步客商审核通过并完善异常日志
流程状态30时不再校验复评,避免卡在审核中;同步失败补充明确错误日志。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-09-25 17:45:14 +08:00 |
|
b2894lxlx
|
feb0ce8ee2
|
mk调试
|
2026-09-25 15:21:22 +08:00 |
|
weicw-dshsa
|
f2b6ca2834
|
🐛 行政区划导入补事务实现整批回滚,缓存清理移到成功路径
问题:RegionServiceImpl.importRegion 是唯一没有 @Transactional 的导入板块,
循环内吞掉异常后正常 return,已落库行直接提交。且 cacheChanged 标志导致
「先清缓存、再提交事务」:循环内已有行 submit 成功 → 后面行失败 → 方法
正常返回 → 惰性树缓存被清/重算成失败批次的中间状态,库回滚后缓存脏掉。
改动:
- 服务层:补 @Transactional(rollbackFor = Exception.class);错误收集完后
抛 ImportFailureException(org.springblade.common.excel)触发整批回滚。
- 缓存语义重构:submit 拆出 clearCache 参数(公开 submit(region) 行为不变,
手工新增仍即时清缓存);导入路径传 false 不逐行清缓存,
统一移到方法末尾成功路径上——异常抛出后不可达,失败批次缓存保持原状。
- 控制器:改 catch 异常导出(exportFailureReasonOnly)+ 补上传文件校验。
验证:mvn install -DskipTests 通过;行政区划回归 25/25
(tests/fixtures/region/),Redis 断言覆盖:成功路径缓存被清、
失败路径缓存键原样保留、基线行不被失败批次污染。
|
2026-09-25 08:20:06 +08:00 |
|
weicw-dshsa
|
c5e5433dc8
|
🐛 修复运单管理导入未整批回滚
问题:WaybillServiceImpl.importWaybill 虽有 @Transactional,但循环内吞掉
异常后正常 return,Spring 照常提交——失败行之前的正确行已落库。
本票回滚边界比其它板块宽:submit 虽只写运单主表,但 carrierJson 构造、
多个宽容日期解析都在循环内,失败原因需覆盖;关联表写入在 import-batch
链路,不在本票范围。
改动:
- 服务层:错误收集完后抛 ImportFailureException(org.springblade.common.excel)
触发整批回滚。catch 里原本就把原因写在原行对象上,无需额外处理。
- 控制器:改 catch 异常导出(exportFailureReasonOnly)+ 补上传文件校验。
验证:mvn install -DskipTests 通过;运单管理回归 19/19
(tests/fixtures/waybill-import/manage-excel/,含 02_一行错误多行正确_应零写入)。
既有 import-batch 链路的 *.json 与 excel/ 用例未改动。
|
2026-09-25 08:20:06 +08:00 |
|
weicw-dshsa
|
a8808942a3
|
🐛 修复评分量化表导入未整批回滚(按评定表分组粒度)
问题:CreditScoreQuantificationServiceImpl.importCreditScoreQuantification
循环单位是「评定表名称」分组(每分组一次 submit,写主表+项目+选项等多表),
异常被 catch 吞掉后正常 return,Spring 照常提交——失败分组之前的
正确分组已经落库。
改动:
- 服务层:任一分组失败、errorList 非空时抛 ImportFailureException
(org.springblade.common.excel)触发整批回滚,失败分组之前已 submit
的正确分组一起退掉。失败明细粒度保留既有行为:覆盖失败分组的全部行。
「评定表名称」为空的行不走 submit、保持早退标错路径。
- 控制器:改 catch 异常导出(exportFailureReasonOnly)+ 补上传文件校验。
验证:mvn install -DskipTests 通过;评分量化表回归 15/15
(tests/fixtures/credit-score/,含 02_后组失败前组正确_应零写入)。
另确认既有语义:与库中重名的分组走覆盖式更新(saveOrUpdate),非错误。
|
2026-09-25 08:20:06 +08:00 |
|