b2894lxlx/tms-erp-api
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
592 Commits 4 Branches 0 Tags
751b246d8ebcdc5a5837cd8bb74dc905efde4ef3
Commit Graph

592 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
weicw-dshsa 4de1ea5209 🐛 修 code-review 指出的三处问题：车牌匹配、提交人姓名为空、分页写法 
1) **车牌匹配漏了规范化兜底（最严重）**
   DriverWaybillServiceImpl.assertCertified 把 splitPlates 返回的**规范化**车牌
   直接与 plate_no 原始列做精确 IN。库中存在带间隔符/横线/大小写差异的车牌时
   会命中 0 行，导致「名下无可用车辆」→ **已认证的司机被误判为未认证而拒绝接单**，
   与本次改造的核心验收「已认证的车重新提交后仍可正常接单」相悖。
   DriverCertServiceImpl.findByPlateWithinBound 同样问题：先精确 IN 取候选再规范化
   filter，而 filter 只能收窄不能放宽，漏掉的候选永远找不回来（等于没做规范化匹配）。

   改法：把「精确 IN 或 规范化后相等」抽成 VehiclePlateSupport.applyPlateMatch，
   三处调用点（含原先自己实现的 DriverAppServiceImpl.myVehicles）统一使用。
   并加测试断言 SQL 表达式覆盖 Java 侧剔除的全部字符、且必须带 OR 兜底，
   防止两边日后悄悄分叉。

2) **审核详情的提交人姓名恒为空**：CertAuditDetailVO.submitUserName 声明了却从未赋值，
   违反「VO 展示字段须由服务端用 UserCache 填好」的规范。已补。

3) **分页未走项目统一写法**：原用 Page.of 手搓，全模块无先例。改为
   Controller 收 Query + Condition.getPage(query)，与 AccidentRecordController 等一致。
   Query 绑定的正是 current/size，故三端契约不受影响。

顺带删除无任何调用者的 ICertAuditService.getRecordOrNull（推测性抽象 + 纯转发）。

82 个测试通过。
 2026-10-02 17:30:48 +08:00
weicw-dshsa 0309d26184 ✅ 权限表达式抽为共享常量并补可求值性测试 
@PreAuth 里的 SpEL 字符串由框架在**请求时**求值，root object 是 AuthFun。
函数名写错既不过编译期、也不在启动期暴露，只会在真实调用时抛异常
（表现为接口 500）——正好是最难在开发阶段发现的一类错。

故把两个表达式抽到 CertAuditPermissions，并在测试中用与框架相同的
SpelExpressionParser + AuthFun 作为 root object 实际解析求值，覆盖：
- 只授司机菜单 / 只授车辆菜单 / 两个都没有；
- 只有查看权限、没有审核按钮权限时必须拒绝（能看≠能审）；
- 表达式必须引用票 01 建的真实菜单码，且不得再出现角色名判断。

顺带消除控制器里与共享常量重复的两份字符串。

6 个新用例；全模块 79 个测试通过。
 2026-10-02 17:08:22 +08:00
weicw-dshsa 60c1d626a2 🐛 认证审核接口改用菜单权限码，并补回被漏掉的审核岗位 
原写法 @PreAuth("hasAnyRole('administrator','admin')") 有两个实际缺陷：

1. 库中**并不存在 admin 角色**（实查 blade_role：超级管理员 administrator、
   运管 yunguan、财务 caiwu、录单员 ludan…），该分支永远不成立；
2. 真正承担认证审核的「运管」岗位**被排除在外**——即审核功能上线后没人能审。

改为按本项目的权限模型走菜单码（票 01 已建好这四个码）：
  cert_certification_audit_driver / _vehicle（列表与详情）
  cert_certification_audit_driver_audit / _vehicle_audit（审核动作）

用 SpEL 而非 @PreAuth(menu = "...")，是因为同一组接口由 bizType 区分同时服务
司机与车辆两侧，单值 menu 表达不了「二者之一」。

已核对框架实现：AuthAspect 把 value 交给 SpEL 求值，root object 即 AuthFun，
而 hasMenu 是它的公开方法，故该表达式可用；menu() 非空时才会先行校验。

73 个测试通过。
 2026-10-02 17:05:42 +08:00
weicw-dshsa d61f1bcae4 ♻️ 门槛里的启用判断改用 BladeConstant.DB_STATUS_NORMAL 
原先写死 Integer.valueOf(1)，虽然值与常量一致，但读代码的人无从判断
「1 到底是启用还是别的什么」。改用框架常量后语义自明，
将来若有人改动状态取值也不会遗漏此处。

已核对：车辆表 status 实际取值为 1（18 辆）与 2（2 辆），
BladeConstant.DB_STATUS_NORMAL 确为 1，判断逻辑未变。
73 个测试通过。
 2026-10-02 17:01:34 +08:00
weicw-dshsa f351bad545 ✨ 接单叠加认证可用性门槛，带开关可快速回退 
在原有运营状态（启用/停用）之上叠加一层「是否已认证」：
- 车辆：启用 且 存在生效快照；司机：存在生效快照。

判据是**生效快照指针**而非「最新提交状态」展示缓存，这一区别正是本改造的核心：
司机重新提交认证会把展示缓存变成「审核中」，若照它判定，司机一提交就接不了单
——那恰恰是本次改造要消除的问题。生效快照只在审核通过时切换，故曾通过即持续可用。

两个开关默认开启，可通过配置关闭以便线上快速回退到改造前行为：
  transport.certification.vehicle-gate-enabled / driver-gate-enabled

门槛落在 DriverWaybillServiceImpl.accept()：司机本人与名下**任一**车辆满足即可。
运营状态优先于认证——停用的车即便已认证也不可用（认证只叠加不覆盖）。

顺带消除第三份重复的车牌匹配实现：DriverWaybillServiceImpl 里的
splitPlates/normalizePlate 与 VehiclePlateSupport 逐行相同，改为委托同一实现。

10 个门槛用例（含「重新提交后仍可用」「停用车即便已认证也不可用」）
与全模块 73 个测试通过：mvn -o test -pl blade-service/blade-transport -am
 2026-10-02 16:46:04 +08:00
weicw-dshsa 6831ba6fca ✅ 补个人认证「提交→审核→生效」闭环测试 
司机认证最关键的一条业务闭环，单看提交侧或审核侧都验证不到：
提交之后司机侧查到的必须仍是旧生效值（否则等于提交即自动认证），
审核通过之后才变成新值（否则认证永远不生效）。

用内存 Map 承接记录读写，让提交服务与审核服务真实共享同一份状态，
避免两边各自 mock 成「恰好一致」——那种测试对集成缺陷是盲的。

5 个用例覆盖：
- 提交后仍是旧值、审核通过后才变新值；
- 驳回后生效值不变（已认证司机不会被驳回下线）；
- 从未认证时审核前查不到生效值；
- 连续提交两次只剩一条待审，且被作废的那条不能再被审核；
- 已通过的记录不可再审（防止把生效快照改坏）。

全模块 63 个测试通过：mvn -o test -pl blade-service/blade-transport -am
 2026-10-02 16:36:41 +08:00
weicw-dshsa 2edbacf838 ✨ 小程序证件 OCR 薄适配层，含类型映射 
小程序按既有契约 POST {imageUrl, type, side?} 到 /driver/auth/ocr，
后端转调已有的百度 OCR 能力（recognizeUrl）。

映射的必要性在于两侧命名对「行驶证」和「驾驶证」的用词正好相反：
  驾驶证 —— 小程序传 driver，后端 OCR 用 driving_license
  行驶证 —— 小程序传 vehicle，后端 OCR 用 vehicle_license
把入参直接透传下游，调用方不会收到任何错误，只会拿到另一种证件的字段，
问题要到人工核对时才发现。故用显式白名单逐一对应。

采用白名单而非「透传 + 兜底为通用识别」，是因为从业资格证没有对应的百度接口：
静默降级成通用文字识别会让前端以为识别成功，实际拿到一堆通用文本。
该类型明确报错并提示手动填写。

正反面：小程序目前不传 side，按 front 处理（正页是常用场景）。

10 个映射用例覆盖五个小程序类型、后端既有命名、大小写/分隔符变体、
未知类型、空值、不支持类型与 side 归一化。
全模块 58 个测试通过：mvn -o test -pl blade-service/blade-transport -am
 2026-10-02 16:31:42 +08:00
weicw-dshsa 5747975152 ✨ 管理端认证审核接口，并弃用旧车辆审核入口 
审核作用于**一条认证记录**，不是车辆行或司机行。两条路径的差别是本次改造的关键：
- 通过：记录转已通过 + 写审核人/审核时间，并把该对象的生效快照指针**切换**到它
  （切换而非追加，故一个对象至多一条生效快照）；
- 驳回：记录转已驳回并留原因，生效快照指针**一个字都不动**。

因此「已认证的车被驳回」不会掉出可用池，只是这次提交没被采纳。

已终态（已通过/已驳回/已作废）的记录拒绝再次审核。理由：若允许，
把指针指着的那条「已通过」改成「已驳回」，生效值就凭空消失了。

审核详情同时返回待审快照与当前生效值两侧，供审核页做字段级 diff
（这正是「看出司机改了什么」的实质要求），并附 certified 标记，
便于前端提示「本次驳回不影响该对象继续使用」。

旧接口 POST /transport-vehicle/audit-certification 置为 @Deprecated 并加告警日志：
它作用于车辆行且原地覆盖，在生效值/待审值分离后语义已不成立。
保留而不删除是为了避免小程序历史版本或其它系统 404；它只写展示缓存，
不再影响可用性判定（可用性只看 effective_cert_record_id）。

修复过程中被测试抓到两个真实问题：
1. 通过路径原先对同一行连发两次 UPDATE（先切指针、再刷展示缓存），
   合并为一次，消除了「后写覆盖先写」的可能；
2. 新增 EffectivePointerUpdateSqlTest，直接断言 MyBatis-Plus 生成的 UPDATE SET 片段：
   指针列必须被「值非 null 才写」的 if 包住——驳回传 null 因此物理上碰不到它。
   把「靠约定」变成「靠语句」，若有人给该字段加 ALWAYS 策略，测试立刻变红。

13 个审核用例 + 全模块 48 个测试通过：mvn -o test -pl blade-service/blade-transport -am
 2026-10-02 16:26:20 +08:00
weicw-dshsa 63762b9dd0 ✨ 司机端认证提交与记录查询接口（车辆/个人） 
实现司机在小程序上提交认证、查看生效值与认证记录的能力。

提交链路的结构性保证（这是本次改造的核心约束「提交审核不影响车辆正常使用」）：
- 提交只产生一条新的待审记录，**绝不修改 effective_cert_record_id**，
  因此已认证的车重新提交后依然可用；待审内容在审核通过前只存在于记录表里；
- 同对象至多一条待审：落新记录前先把前一条待审转已作废，
  且只动作待审——已通过/已驳回是终态，尤其不碰生效快照指着的那条；
- 新记录状态显式设为待审：框架会把空 status 静默填成 1，而 1 在本表是「已通过」，
  不显式设置会让一次提交凭空变成审核通过；
- 新记录清空驳回原因，避免出现「审核中」却带着上一次驳回文案。

越权校验：司机只能提交/查看本人及本人绑定车辆的认证（复用 VehiclePlateSupport），
不可查看者返回业务异常而不是空列表——空列表会被误读成「没有记录」。

新增：
- DriverAuthController（/driver/auth/**，兼容 /blade-transport/driver/auth/**）
- IDriverCertService / DriverCertServiceImpl
- PersonCertSubmitRequest / VehicleCertSubmitRequest
- TransportCertRecordVO.statusText（状态文案统一在 Wrapper 翻译，四端一套说法）
- IDriverAppService.currentDriverEntity()（认证写入需要司机实体）

17 个用例覆盖票 02 的三条验收点与不变式（含「重新提交后生效值仍是旧的」）。
全模块 33 个测试通过：mvn -o test -pl blade-service/blade-transport -am
 2026-10-02 16:17:06 +08:00
weicw-dshsa e891100a23 ✨ 认证记录状态机规则集中为 CertificationRuleSupport 并补测试 
把「什么状态能做什么」从持久化里拎出来单独验证。这几条规则是认证改造的地基，
改坏的后果都是线上事故，故先锁住行为再写业务：

- prepareForSubmit：新提交一律待审，并清空驳回原因（否则会继承上一次的驳回文案，
  出现「审核中」却带着驳回原因的自相矛盾状态）；
- supersedeIfPending：再次提交只作废前一条待审，已通过/已驳回/已作废都是终态不碰
  ——尤其是不得改动已通过的记录，它可能正被生效快照指针指着；
- isCertified：唯一判据是生效快照指针，故「曾通过即永久保持」；
- isAuditable：只有待审可审，终态再审会把生效快照改坏；
- statusText：四种状态各一个中文说法，与列注释、前端文案保持一致。

TransportCertRecord.REJECT_REASON_MAX_LENGTH 与 reject_reason 列宽（200）对齐。
9 个用例覆盖上述规则与边界（null、未知状态、超长原因）。

可离线执行：mvn -o test -pl blade-service/blade-transport -am
 2026-10-02 16:10:34 +08:00
weicw-dshsa 8a2d83b3cd ♻️ 车牌软关联逻辑抽为 VehiclePlateSupport 并补测试 
司机 driving_vehicle 与车辆表 plate_no 之间没有外键，只有文本关联，且库中存在
间隔符/横线/大小写差异，一个字段还可能并列多辆车。认证提交的越权校验
（只能操作本人绑定车辆）依赖这套匹配：漏判会让司机改不了自己的车，
误判会让司机改到别人的车，故先把规则集中并锁住行为。

- 新增 VehiclePlateSupport：splitPlates / normalize / isBound；
  isBound 对空值一律判不绑定（不能因为双方都为空就放行，那等于越权）。
- DriverAppServiceImpl 原先自己实现了一份 splitPlates/normalizePlate，
  改为委托同一个实现，避免两处口径分叉。
- 6 个用例覆盖分隔符变体、去重、规范化、脏数据与绑定判定。

可离线执行：mvn -o test -pl blade-service/blade-transport -am
 2026-10-02 16:08:47 +08:00
weicw-dshsa 9f3914463e ✅ blade-transport 引入 JUnit 5 测试基础设施 
本模块此前没有可自动执行的测试：无 src/test 目录、pom 无测试依赖、
父 pom 无 surefire、全仓 0 个 @Test（仅有的 6 个 *Test.java 实际是 main() 手跑脚本）。
而认证改造的提交/审核链路带状态机语义（同对象至多一条待审、提交不得修改生效快照等），
必须用可重复执行的单元测试守住，否则只能靠人肉 review。

- blade-transport/pom.xml 增加 spring-boot-starter-test（test scope，版本由 blade-bom 管理）；
- 加一个基础设施自检用例，确认 JUnit 5 在本模块能被发现并执行。

可离线执行：mvn -o test -pl blade-service/blade-transport -am
 2026-10-02 16:03:50 +08:00
weicw-dshsa 36d23cb426 📝 认证记录相关文件去掉外部文档引用，注释改为自解释 
前一次提交的注释大量引用本仓库之外、同事看不到的东西：
docs/adr/0001、docs/adr/0002、GLOSSARY.md、.scratch/ 下的 spec 与 ticket 编号、
以及 ADR-0002 / D10 / 不变式 I1~I3 这类代号。这些都在另一个 git 仓库
（weicw/tms-erp）里，单独 checkout 本仓库的人根本找不到，只会困惑。

改为把结论直接写在注释里：
- 生效快照指针为何「一经设置永不回退」（原来只写「见 ADR-0002」）；
- 为何 redis 状态字段不能用 0 兜底；
- 为何生成列要排除 is_deleted、为何 tenant_id 必须 NOT NULL；
- changeStatus 为何被禁用（原来写「破坏 I3 的留痕」）。

顺带对齐本仓库的既有排版习惯：
- 横幅破折号由 77 个改为 30 个（与 blade_annual_inspection_record.sql 等一致）；
- 去掉 SQL 注释里的 markdown 粗体（本目录无其他脚本这么写）。

仅注释变更：SQL 的 diff 已逐行核对，非注释行改动为 0，DDL 一字未动；
迁移重跑仍 exit 0，audit-migrations 通过，mvn clean compile 成功。
 2026-10-02 15:47:39 +08:00
weicw-dshsa 87f4c3a830 ✨ 新增认证记录不可变快照数据模型与迁移脚本 
按 ADR-0001/0002 建立司机与车辆共用的认证记录表 blade_transport_cert_record
（biz_type 区分、载荷存 JSON、检索字段提升为真实列），并为司机/车辆表补生效快照指针。

不变式结构性保证：
- I1 同对象至多一条待审：生成列 pending_biz_id + 唯一索引，数据库层拦截；
  生成列同时排除 is_deleted，避免逻辑删除的待审记录永久占用唯一键。
- I3 快照不可变：snapshot_json 等 5 列标 FieldStrategy.NEVER，永不进入 UPDATE。
- status 承载审核状态（0审核中/1已通过/2已驳回/3已作废），新增时必须显式设置：
  框架 resolveEntity 会把 null 的 status 静默填成 1（即「已通过」），
  且继承来的 changeStatus 可直接写 status，两条通道均已封堵。

其他：司机表补身份证有效期三列并订正排序规则为 utf8mb4_general_ci
（原先为 0900_ai_ci，与车辆表 JOIN 已发生过 Illegal mix of collations）；
生效快照指针加 @JsonProperty(READ_ONLY)，防止以 /submit 请求体自行「认证」自己；
同步基线建表脚本与认证审核菜单/权限码。本票不含任何业务接口。
 2026-10-02 14:40:56 +08:00
刘泉佳 08d9a87e29 feat: A303-1 开票申请推送特殊票种映射（运费票送E04、其余送00非特殊票种），hsbz统一按不含税口径送0（金蝶联调反馈） 2026-10-02 00:17:32 +08:00
刘泉佳 048bcaf8ad feat: 客商提审接入国资委黑名单校验（A801-5） 
- submitApproval 前置实时查询金蝶黑名单（enable=1），按统一社会信用代码大写精确匹配
- 禁止交易类（A）硬拦截报错并提示失信类别与列入事由；风险警示类（B）默认放行告警，thirdparty.bfi.blacklist.blockRiskWarning=true 时一并拦截
- 黑名单查询异常不阻断准入，记 error 日志放行（金蝶可用性口径待联调确认）
 2026-10-01 23:47:49 +08:00
刘泉佳 cc54b4ca91 feat: BFI 新增 A801-5 黑名单查询接口对接 
- GET /ierp/kapi/v2/awrp/bdm/bdm_blacklist_config/blacklistquery，enable 使用状态参数，URL 经 thirdParty.bfi.blacklistQueryUrl 可配
- 返回字段保留金蝶原名（number 企业税号、awrp_combofield 失信类别 A 禁止交易类/B 风险警示类等）
- 规格来源为接口文档 xlsx（apifox 无此接口，xlsx 示例为 A801-1 错拷不可信），契约形态按 GET+query param 实现，联调若为 rim 形态仅需调整 BfiServiceImpl 单方法
 2026-10-01 23:47:33 +08:00
刘泉佳 b7beb949fb perf: 分录拆分补齐上下文缓存消除N+1，联调详细日志 
N+1 治理（复用 KingdeeSyncContext 全批档案缓存，批量同步不因拆分逻辑增加重复查询）：
- 合同计费方案解析按合同id缓存（BillingPlanInfo：计费单位+费用归类一次解析全批复用），
  消除批量同步逐单重复解析同一合同计费方案JSON（此前计费单位/归类各解析一次）
- 货物费用行按结算明细id上下文缓存（含空行占位，仅补查缺失明细），多结算单单据
  （收票登记分摊多结算单）跨结算单一次预查，逐结算单解析命中缓存
- 结算合计费用项按结算单id上下文缓存，多笔收票登记分摊同一结算单不再重复查询
- KingdeeSyncContext 新增 billingPlanCache/detailFeeCache/summaryFeeCache 组件

联调详细日志：
- 逐费用项归类明细（同单去重）：费用项->费用大类/税率+归类来源（计费方案规则/费用项档案/
  名称特征兜底/交叉补齐）；来源为名称兜底或税率未识别时升级 warn 提示补配置
- 分录生成日志增加费用项构成（运输费:100.00 + 装卸费:50.00）、货物、车号
- 货物费用行批量查询打印缓存命中/补查行数
 2026-10-01 23:15:40 +08:00
刘泉佳 5d1c01e15e feat: 金蝶应付/应收单分录按费用大类×税率拆分，一车多货再按货物拆分 
结算明细（一个运单）不再整行一条分录，改为按货物费用行费用项拆分归集：
- 费用大类拆分：运输费大类费用一行、装卸大类费用一行（费用类型/费用项名称归类）
- 税率拆分：同大类税率不同（合同计费方案规则税率，费用项档案兜底）再按税率拆多行
- 一车多货：明细下多行货物费用行时再按货物拆分
- 结算合计手工费用项保持每行一条；无有效货物费用项的明细兜底整行一条（历史数据）
- 含税金额按费用项归集，不含税按行内含税占比分摊（末项兜差额）；运费（freightAmount）
  在费用项JSON无运费项时并入运输费大类（与页面合计口径一致）
- 分录标识：未拆分保持单据号，拆分行取 单据号-费用大类-税率（-货物）保证候选键唯一
- 计量单位：费用项/费用大类匹配计费方案计费单位；非运输费大类缺配置兜底运费单位并告警
- A102-2/A302-2/A303-2 同源共用本解析；费用项档案经 ISysClient.getFeeItems 加载并入同步上下文缓存
 2026-10-01 22:52:07 +08:00
刘泉佳 d78757b64c fix: A303-1 开票申请推送放开上游来源单据字段，awrp_src_con_no 传首张结算单金蝶应收单编号（金蝶确认单据编号口径，取 A302-4 查询结果） 2026-10-01 22:23:41 +08:00
刘泉佳 ab64d28251 fix: A301-3 认领推送核心单据编号改传结算单金蝶单据id（星瀚内码），本地结算单id金蝶无法识别；缺id时推送前置拦截 2026-10-01 20:09:10 +08:00
刘泉佳 984fbd07fd fix: 金蝶推送组织编码改取部门金蝶组织编码(kingdeeDeptCode) 2026-10-01 14:41:57 +08:00
刘泉佳 4b3edf977c Merge remote-tracking branch 'refs/remotes/origin/master' into feature/payment-apply-bfi-sync 
# Conflicts:
#	blade-service/blade-transport/src/main/java/org/springblade/transport/service/impl/CustomerArchiveServiceImpl.java
 2026-10-01 13:47:00 +08:00
刘泉佳 27756ba964 fix: A303-2 收票单新增，付款方式固定现购 2026-09-30 18:21:43 +08:00
刘泉佳 454209511b chore: 补充金蝶收票单结果回写定时任务日志与方法说明 2026-09-30 15:16:09 +08:00
刘泉佳 f8bd66aafb docs: BFI接口编号补充名称标注，新增定时任务逻辑全梳理文档 2026-09-30 15:01:57 +08:00
刘泉佳 86e26bf3c9 perf: 金蝶应收单勾稽明细查询与回写改分批执行并补充日志说明 2026-09-30 14:57:50 +08:00
b2894lxlx a5e89aa6dc ✨ 各业务模块列表与导出补齐创建人及创建时间 
统一 VO/Wrapper/ExportExcel 返回并填充 createUserName，导出同步展示创建人、创建时间。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-30 14:22:39 +08:00
刘泉佳 2f6619d443 feat: 开票结果回写落库发票文件地址并支持正式结算单详情查看下载 
- A303-5 VO 补数电 PDF/XML 直链字段，回写落库四个发票文件地址（板式文件/预览图/数电PDF/数电XML）
- 已落库但缺地址的历史记录由回写任务字段级补空，不覆盖已有值
- 正式结算单详情新增 issuedInvoices：经结算单-开票申请关联查出回写发票，只读不参与匹配金额
- 新增建表补丁 blade_invoice_application_invoice_urls_20260930.sql
- 同步更新金蝶附件上传下载链路梳理文档（新增 3.4 销项直链节）
 2026-09-30 14:15:58 +08:00
b2894lxlx 2f4513d501 📝 新增指定账号各业务模块创建量统计 SQL 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-29 21:42:34 +08:00
b2894lxlx 0e75780908 🐛 超管默认不限组织范围，并修复司机同步初始密码不合规 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-29 21:41:52 +08:00
刘泉佳 2cd86b1fe8 fix: 预付款申请，入参调整 2026-09-29 17:41:48 +08:00
刘泉佳 73293a4ea5 docs: 补充推送金蝶付款申请必填字段注释 2026-09-29 16:50:25 +08:00
刘泉佳 952b735a53 fix: 付款管理列表结算单号查询兼容预结算单号 2026-09-29 16:02:11 +08:00
刘泉佳 a9eb1d82d4 feat: 收款认领推送金蝶定时任务增加single-flight分布式锁及Nacos配置 2026-09-29 12:12:59 +08:00
刘泉佳 78e7ee7239 fix: 金蝶客商数据定时同步 2026-09-29 12:05:42 +08:00
刘泉佳 82fab4b76a feat: 已推送金蝶的认领不允许作废——后端硬校验拦截，列表带出流水推送状态 2026-09-29 11:58:20 +08:00
刘泉佳 331ea0466f feat: 定时推送按认领人串行处理——查完该认领人公告并推完名下流水再轮到下一个 2026-09-29 11:52:42 +08:00
刘泉佳 fe7a940201 fix: A301-3 成功响应 number 为空，金蝶收款单号取回执 keys.awrp_src_code；A301-1 回写命中后以真实收款单号覆盖占位 2026-09-29 11:25:58 +08:00
刘泉佳 15599e894d chore: 保留 buildKingdeeBillNo 冲单号方法，作废调用点注释保留待后续迭代 2026-09-29 11:18:48 +08:00
刘泉佳 c8b2b701a3 fix: 作废认领不再生成本地KDCX冲单——金蝶单号/状态保留原值，接口改无返回 2026-09-29 11:15:57 +08:00
刘泉佳 175dd52d33 fix: A301-3 分录按契约改为单条——e_receivableamt=全部未推送金额，seq/e_corebillno=第一张结算单id 2026-09-29 11:10:41 +08:00
刘泉佳 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