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 项全绿，证明行号修正未破坏既有断言。