新增个人贷款申请

2026-08-10 17:28:50 +08:00 · 2026-08-10 17:28:50 +08:00 · ac7d7dd3ad
parent 03fc69cd2b
commit ac7d7dd3ad
1 changed files with 260 additions and 2 deletions
--- a/缺失的后端接口.md
+++ b/缺失的后端接口.md
@ -1106,12 +1106,15 @@
    上传,`enterpriseAccountOpenApplicationFileBtoList.fileType` 现有已知编码为
    12营业执照/01法人身份证正面/02法人身份证反面,均未覆盖该新影像类型,前端暂用占位编码 `'14'`,
    需后端确认真实编码或另行分配。
-102. **`enterprise-open-application/create`、`update` 请求体无 `verifyCode` 字段**:原型新增
+102. ~~**`enterprise-open-application/create`、`update` 请求体无 `verifyCode` 字段**:原型新增
    "短信认证"环节(手机号+验证码+发送按钮),但两个接口的 Bto(`CreateEnterpriseAccountOpenBto`/
    `UpdateEnterpriseAccountOpenApplicationBto`)均无 `verifyCode` 字段。前端已完整实现发送
    验证码 UI 交互(复用 `POST /api/auth/send-sms-code`,`businessType` 约定传
    `'WALLET_ENTERPRISE_OPEN'`)并将 `verifyCode` 一并放入提交 payload,但该字段实际不会被
-    后端接收/校验,验证码环节当前只是前端展示效果,需后端补充该字段后才能真正生效。
+    后端接收/校验,验证码环节当前只是前端展示效果,需后端补充该字段后才能真正生效。~~
    **2026-08-08 更新:按需求已去除整个短信验证码校验/发送流程**,页面仅保留"手机号"采集字段
    (对应 `mobilePhone`),提交 payload 不再携带 `verifyCode`,本条缺口已随功能移除而失效,
    不再需要后端补充该字段。
 103. **受益人"实际控制信息"二级面板的"控制内容"(`actCtrlType`)后端未提供任何枚举——2026-07-28
    第二轮补充**:原型截图(截图4)对"控制内容"展示为下拉框样式,但未展示任何可选项,swagger 该
    字段(`actCtrlType`)是纯自由文本,无 `$ref` 枚举。前端改用 `a-auto-complete` 自由输入组合框
@ -1566,5 +1569,260 @@ INSERT INTO "SFT"."AUTH__ROLE_PERMISSION" ("ID", "ROLE_ID", "PERMISSION_ID") VAL
     参数可以覆盖这个行为,必须让后端加上真正的 `fileName`/`fileExt` 请求字段,或者让后端的
     存储逻辑去解析 `fileBase64` 前缀/内容魔数,前端单方面无法解决。
 ---
 ## Part 20:企业开户移动端H5确认页(`fryl_h5` 新增页面)+ 管理后台"邀请扫码办理"入口 —— 2026-08-07 补充
 > 参照个人开户H5确认页(`docs/superpowers/specs/2026-07-27-personal-open-mobile-h5-design.md`)的模式,
 > 本次为企业开户新增了对应的移动端H5确认页(`fryl_h5/src/views/EnterpriseOpenMobile.vue`,路由
 > `/mobile/enterprise-open`),并给管理后台 `EnterpriseOpenForm.vue` 补上了此前完全没有的"确认弹窗
 > (保存/取消/邀请扫码办理)+ 二维码展示"入口(仿 `PersonalOpenForm.vue`,新增环境变量
 > `VITE_H5_QRCODE_PATH_ENTERPRISE=/mobile/enterprise-open`)。与个人开户不同,企业开户的真实后端
 > **没有**匿名的 `mobile/draft-detail` 查询接口,只有语义完全不同的 `enterprise-open-application/
 > confirm` 提交接口,以下登记本次由此产生的契约缺口。**mock-server 本次完全未改动**(用户明确决定
 > 不在 mock 层实现,H5 页面仅能连真实后端环境验证完整流程)。顺带修复了 `.env.development` 里
 > `VITE_H5_QRCODE_BASE_URL` 一行此前被意外写成 `npmhttp://www.baidu.com`(缺少变量名前缀,推测是
 > 之前某次操作误把 shell 命令输出写入了文件)的问题,已恢复为正确的 `VITE_H5_QRCODE_BASE_URL=
 > http://www.baidu.com`。
 124. ~~**`enterprise-open-application/mobile/draft-detail` 是前端本次假设新增的接口,真实后端尚未
     提供**~~——**2026-08-07 更新:后端已实际提供该接口,以下为实测确认的真实响应字段**:
     `POST /api/wallet-management/enterprise-open-application/mobile/draft-detail`(请求
     `{applicationNo}`),真实响应示例:
     ```json
     {
       "applicationNo": "ENT20260731171909379B",
       "applicationStatus": "APPLY_FAILED",
       "bankCardNumber": "5566552255888",
       "certificateNumber": "91330109MAE1U3RH6G",
       "channelName": "巽平",
       "channelNo": "1021",
       "enterpriseName": "杭州维毅信息科技有限公司",
       "id": 601,
       "mobilePhoneMask": "13333333333"
     }
     ```
     确认字段:`applicationNo`/`applicationStatus`/`bankCardNumber`/`certificateNumber`/
     `channelName`(见第125条,已确认真实提供)/`channelNo`/`enterpriseName`/`id`(数字主键,
     供 confirm 提交使用)。**与前端此前假设不一致的地方**:(1)**没有独立的明文手机号字段
     `mobilePhone`**,只有 `mobilePhoneMask` 一个手机号相关字段(与个人开户
     `MobileDraftDetailVo` 同时提供 `mobilePhone`+`mobilePhoneMask` 两个字段的模式不同);
     (2)**`mobilePhoneMask` 实测返回的是完整11位手机号(`13333333333`),并未真正打掩码**——
     字段名带"Mask"但取值未脱敏,不确定是后端当前测试环境的临时行为还是长期如此,需要后端确认
     生产环境是否会返回真正打码的值,若是,发验证码环节仍可用该字段(短信网关侵入式发码不需要
     依赖前端展示态的手机号是否打码),但"信息核对"步骤给客户展示的手机号届时会变成打码后的
     值,不影响功能但需知悉。原始记录(前端假设,已被本条实测覆盖,仅作历史参考)见下方保留的
     原文。~~原假设响应字段:`id`(数字主键,供 confirm 提交使用)/`applicationNo`/
     `enterpriseName`/`channelNo`/`channelName`/`certificateNumber`/`bankCardNumber`/
     `mobilePhone`/`mobilePhoneMask`/`applicationStatus`。~~
 125. ~~**假设新增字段 `channelName`(渠道名称),`EnterpriseAccountOpenApplicationDetailVo`/`ListVo`
     均无此字段**~~——**2026-08-07 更新:已通过第124条实测响应确认,后端确实在此接口里额外返回
     了 `channelName`(示例值"巽平")**,证实了前端"draft-detail 接口内部会做一次
     `channelNo → CoreEnterpriseVo.channelName` 关联查询"的假设是可行的。"办理渠道"展示
     `"{channelName}(线上)"` 的逻辑不变。
 126. **"业务类型"展示字段无任何对应后端概念**:企业开户申请相关 Vo 全文搜索均无"业务类型"字段,
     前端固定展示文案"稠州企业开户"(纯UI常量,不来自任何接口),与截图保持一致。
 127. **发验证码复用个人开户H5确认页在用的通用接口,而非企业开户专属接口**:
     `POST /api/wallet-management/personal-opening/mobile/send-verify-code/general` 的 swagger
     `description` 明确写"个人开户移动端H5确认页使用的通用短信验证码发送接口",但请求体字段
     (`channelNo`/`tradeNo`/`tradeType`/`mobile`/`cardNo`/`cardName`/`idNo`)均为向凡荣e链221506
     短信接口的通用透传参数,技术上不依赖"个人开户"这一业务身份。企业开户H5确认页"手机验证"步骤
     直接复用该接口(`mobile`/`cardNo`/`idNo` 取企业开户假设新增接口返回的
     `mobilePhoneMask`(**2026-08-07更新:该接口无独立明文手机号字段,详见第124条实测记录,
     `mobile` 参数与展示用的掩码手机号取同一个字段**)/`bankCardNumber`/`certificateNumber`,`cardName` 取 `enterpriseName`——企业银行账号的户名
     通常即企业名称,与个人开户场景"卡户名取客户姓名"的处理思路一致;`tradeNo`/`tradeType` 固定值
     沿用个人开户2026-08-06已修正的正确取值 `'221506'`/`'0'`,不重复使用本文档第114条记录的
     修正前错误值)。**需要后端确认是否允许企业开户场景复用该接口**,若不允许,需另外提供企业
     开户专属的发码接口。
 128. **`enterprise-open-application/confirm` 接口的匿名可访问性未经真实后端环境验证**:该接口
     summary 写"申请人扫码核实信息后点击确认,提交凡荣e链",语义上应是给未登录的扫码客户调用的
     匿名接口,但该接口目前在管理后台侧代码里从未被调用过(此前完全没有二维码入口),也从未在
     mock-server 中实现,无法判断真实后端 Spring Security 是否已将其配置为免鉴权(与本文档记录的
     `face-recognize`/`upload-file` 匿名可行性风险属于同一类问题)。企业开户H5"手机验证"步骤提交
     按钮直接调用该接口且不带 `Authorization` 头,若后端未开放匿名访问,会返回401,需要后端配合
     确认。
 129. **`confirm` 接口的 `confirmBto.id` 依赖第124条假设接口提供,且与已知的 `id` 缺口(第23条)
     本质是同一个问题的延伸**:`confirm` 接口要求传数字主键 `confirmBto.id`,但目前
     `EnterpriseAccountOpenApplicationListVo`/`DetailVo` 均不返回 `id` 字段(第23条已登记的老缺口)。
     本次假设新增的 `mobile/draft-detail` 接口(第124条)里包含 `id` 字段用于承接这个需求,一旦
     该假设接口本身无法落地,`confirm` 提交步骤也会因缺少 `id` 来源而无法工作。
 130. **前端bug(不是后端契约问题,记录仅为避免回归)—— 2026-08-07 修复:发验证码时 `mobile`
     参数传空**:`EnterpriseOpenMobile.vue` 给 `EnterpriseSmsVerifyStep` 传参时,`mobile` 一直
     取 `draftDetail?.mobilePhone`,但如第124条实测记录,真实接口根本不返回 `mobilePhone` 这个
     字段,导致 `send-verify-code/general` 请求体里 `mobile` 始终是空字符串,发验证码环节实际
     不可用(后端多半会因手机号为空而发送失败或报错,取决于短信网关侵入式校验的严格程度)。
     已修复为 `mobile`/`mobile-phone-mask` 两个 prop 统一取同一个 `mobilePhoneMask` 字段。
 131. **企业开户H5"相关协议"步骤按产品要求对齐个人开户H5的"协议模板下载+自动填充+上传"机制
     —— 2026-08-07 补充**:产品要求企业开户H5确认页"相关协议"步骤与个人开户H5(见Part 19)
     保持一致:用户勾选两个协议 checkbox 后,前端自动在《用户支付服务协议》PDF模板末页的空白
     签名区域填入信息、调用通用文件上传接口拿到文件编号,提交时随 `confirm` 一起传给后端。
     与个人开户的关键差异及新增契约缺口:
     1. **填入PDF签名区块的是企业名称+统一社会信用代码,不是法人代表姓名/身份证号**(产品
        明确要求,已与最初按"法人客户信息"理解的方案区分开)。这两个字段(`enterpriseName`/
        `certificateNumber`)第124条实测记录里已确认真实存在,不需要为此新增假设字段。
     2. **`fillPayAgreementPdf()`(`agreementPdfFill.js`)直接复用个人开户已有的实现,不新建
        企业专属版本**:该函数形参名 `customerName`/`certificateNumber` 是通用命名,企业场景
        直接把 `enterpriseName` 当作 `customerName` 参数传入即可复用同一份PDF坐标测量/Canvas
        渲染逻辑,不需要重新测量模板坐标(模板文件本身不区分个人/企业开户场景)。
     3. **`fetchBankAgreementApi`/`uploadFileApi` 两个通用接口原样复制到 `enterpriseOpen.js`
        (与第127条"发验证码复用个人开户通用接口"同一处理思路)**:`bank-agreement/base64` 与
        `customer-info/personal/upload-file`(该接口尽管路径带"personal",但管理后台企业开户
        表单的 `LicenseUpload.vue`/`BeneficiaryProofUpload.vue` 等已经在用同一个接口上传企业
        影像资料,证明该接口本身不区分个人/企业客户,可放心复用)均未修改调用方式。
     4. **`confirm` 接口新增顶层字段 `payAgreementFileNo`(前端假设,待后端确认)**:与第126条
        记录的现状一致,`confirm` 目前请求体只有 `{channelNo, verifyCode, confirmBto:{id,
        applicationStatus, confirmTime}}`,没有字段可以承载协议PDF文件编号。前端参照个人开户
        `mobile/submit` 新增 `payAgreementFileNo` 字段的先例(见第116条),在 `confirm` 请求体
        **顶层**(与 `channelNo`/`verifyCode` 同级,不放进 `confirmBto`)新增同名字段
        `payAgreementFileNo`。需要后端确认:(1)字段名/位置是否与实际预期一致;(2)是否必填;
        (3)拿到该文件编号后的实际用途(是否需要真正归档校验,还是仅留痕)。
     5. **mock-server 依旧未同步改动**:与 Part 20 开头声明一致,企业开户H5全流程仅能连真实
        后端环境验证,本次改动不例外。
 ---
 ## Part 22:企业开户申请"开户银行/网点"字段"快速"录入方式改为动态字典驱动 —— 2026-08-07 补充
 132. **新增动态字典类型 `kaihuhang`(开户行),用法与第122条"job"/第24条"industry_type"完全
     一致**:`BankSelector.vue`"快速"录入方式原来是前端硬编码10家常见银行名称的下拉框
     (`COMMON_BANK_NAMES`),按产品要求改用 `DictSelect.vue`(`dict-type-code="kaihuhang"`,
     普通字典单层,非级联)。**关键行为(2026-08-07 二次修正后的最终版本)**:提交给
     `enterprise-open-application/create`/`update` 的字段映射为 `bankName` = 选中字典项的
     `itemLabel`(中文银行名称,如"中国工商银行"),`bankNo` = 该字典项的 `itemValue`(联行号/
     银行编码,如`"102100099996"`)——即字典项的"标签"对应 `bankName`,"值"对应 `bankNo`,
     产品已用真实示例("中国工商银行"对应`"102100099996"`)明确确认,与本条最初记录的
     "`bankName`=`itemValue`"版本相反,已按此修正。`DictSelect.vue` 的 v-model 只对外暴露
     `itemValue`,不含 `itemLabel`,`BankSelector.vue` 为此直接复用全局 `useDictStore()` 按
     `dictTypeCode` 取原始字典项列表在选中变化时反查 `itemLabel`(会走 store 内部缓存,不会
     与 `DictSelect` 内部重复发请求)。"详细"/"手动"两种录入方式不受影响。
     **`kaihuhang` 这个字典类型目前后端不存在**,需要后端/管理员在真实环境的"动态字典管理"
     模块新建该字典类型及字典项数据(mock 已在 `mock-server/db/seedBaseConfig.js` 补充等价的
      演示数据;除中国工商银行的`"102100099996"`系用户确认的真实示例外,其余9条联行号编码均为
      仅供本地演示的占位值,不代表真实联行号,后端/产品配置真实数据时不需要照抄)。
 ---
 ## Part 23:基础配置 —— 动态字典管理"字典项维护"页面标签唯一性 + 按标签维护接口 —— 2026-08-08 补充
 133. **同一动态字典类型(`dictTypeCode`)下,字典项标签(`itemLabel`)不能重复,需要后端在
     `dict-item/create`/`dict-item/update` 接口中增加此项校验**:唯一性范围是**整个字典类型下的
     所有字典项**,不区分层级/父节点(即级联字典下,即使两个字典项的父节点不同,标签也不能相同)。
     - `dict-item/create`(`CreateDictItemBto`):同一 `dictTypeCode` 下新增字典项时,若
       `itemLabel` 与该字典类型下已存在的任意字典项(含不同父节点、不同层级)重复,应拒绝创建并
       返回明确的 `message`。
     - `dict-item/update`:修改字典项标签时,若新 `itemLabel` 与该 `dictTypeCode` 下除自身外的
       其他任意字典项重复,应拒绝更新并返回明确的 `message`。
     前端已在 `DictItemTree.vue` 的新增/编辑弹窗中同步加上客户端唯一性校验(基于当前页面已加载的
     整棵字典项树做重复标签检测,编辑时排除自身),但客户端校验无法覆盖并发新增等场景,仍需后端
     兜底校验,且后端是唯一权威的数据一致性保障。
 134. **需要后端新增"根据字典项标签更新/删除字典项"的接口**:目前 `dict-item/update`/
     `dict-item/delete` 均要求传入字典项的数字主键 `id`,而该 `id` 字段实际上依赖
     `dict-items/list`/`dict-items/tree` 接口"swagger 未声明但实测会返回"的额外字段(见 14.2 节
     说明),不是标准契约,存在后续版本被无声移除导致前端功能回退的风险。鉴于第 133 条一旦落地,
     `itemLabel` 在同一 `dictTypeCode` 下具备唯一性,可作为稳定的业务标识定位记录,建议后端新增
     以下两个接口,使前端可以不再依赖未声明的 `id` 字段完成修改/删除:
     - `POST /api/dict-management/dict-item/update-by-label`:Body 建议为
       `{dictTypeCode, itemLabel, newItemLabel?, itemValue, parentId, sortOrder, status, remark}`,
       按 `dictTypeCode + itemLabel` 定位待更新的字典项;`newItemLabel` 为空表示不修改标签,不为空
       则按新标签更新(仍需满足第 133 条的唯一性校验,且校验时应排除自身)。
     - `POST /api/dict-management/dict-item/delete-by-label`:Body 建议为
       `{dictTypeCode, itemLabel}`,按 `dictTypeCode + itemLabel` 定位待删除的字典项。
     待后端提供后前端会评估是否将 `DictItemTree.vue` 的修改/删除逻辑迁移到新接口,以摆脱对未声明
     `id` 字段的依赖;在后端提供新接口前,前端暂继续使用现有的 `id` 定位方式。
 ---
 ## Part 24:授信管理 —— 个人贷款申请表单按最新原型截图改造 —— 2026-08-10 补充
 135. **贷款产品(`loanProductCode`)"选择"弹窗现状(呼应第28条)**:`PersonalLoanForm.vue` 新增
     `LoanProductPicker.vue` 弹窗,尝试调用假定契约 `POST /api/credit-apply/loan-product/list`
     (`src/api/credit.js` 的 `fetchLoanProductListApi`)——**该接口后端目前不存在**,调用会失败;
     弹窗内在列表查询区下方常驻提供"手动输入产品编号"入口,不依赖该接口也能完成选择。建议后端
     补充贷款产品字典/列表查询接口,响应结构参考 `{total,page,pageSize,records:[{productCode,
     productName}]}`,届时前端列表区自然可用,无需再改动组件结构。
 136. **贷款申请人钱包"选择"后自动回填字段的数据来源与已知缺口**:`WalletAccountPicker.vue` 选中
     的 `WalletAccountVo` 只有 `id/customerId/accountNo/accountType/accountName/
     accountRelation/customerNo/accountStatus/mainAccountNo/openDate`,不含证件号码/手机号/
     户籍地址;这些字段实际来自额外发起的 `POST /api/customer-info/personal/detail`(按
     `customerId` 查询)返回的 `IndividualCustomerDetailVo.certificateNumber/mobilePhone/
     certificateAddress`。`CreatePersonalLoanApplicationDraftBto`/`UpdatePersonalLoanApplicationBto`
     仍不支持提交 `accountNo`/`customerId`(与第27条一致),前端选择钱包后只在页面展示账号与
     `wallet-account/detail` 查到的主账户余额,不随表单提交。
 137. **新增"证件号码"字段无处提交**:个人贷款申请页面新增了"证件号码"展示框(选择钱包后从上一条
     的个人客户详情自动回显 `certificateNumber`,允许人工修改),但
     `CreatePersonalLoanApplicationDraftBto`/`UpdatePersonalLoanApplicationBto` 均无对应字段,
     该值只用于页面展示/人工核对,不随表单提交,建议后端评估是否需要为该 Bto 补充该字段。
 138. **"经营证明"影像 `fileType` 约定与"下载模板"按钮缺口**:个人贷款申请"影像资料"区块原
     "营业执照(选填)"改造为"经营证明"(改为必填展示),提交 `LoanApplicationImageBto.fileType`
     时固定传字符串 `"17"`(业务方指定的既有编码,非 swagger `description` 中列出的"身份证正面/
     身份证反面/营业执照/其他"字面枚举,需后端确认该编码含义,并评估后续是否需要将其文档化为正式
     枚举值)。同一区块新增的"下载模板"按钮当前**禁用占位**(无对应后端接口),建议参考已有的
     `GET /api/customer-info/bank-agreement/base64` 模式,补充一个"经营证明空白模板"下载接口。
 139. **行政区划五级级联(村/居委会)级别支持范围待后端书面确认**:`GET /api/base-config/
     administrative-division/children` 的 swagger `description` 只写明 `level` 取值
     "1=省 2=地市 3=区县 4=乡镇/街道",未列出 `level=5`(村/居委会);个人贷款申请"户籍/常住地市"
     五级级联组件 `AdministrativeDivisionCascader.vue` 按产品要求实现为查询 `level` 可传到 5,
     若某一级(如某乡镇)查询返回空列表,组件会将其就地降级为叶子节点直接可选,不强行要求凑满5级,
     不会阻断功能;但若后端实际完全不支持 `level=5`(直接报错而非返回空数组),该级联会在4级(乡镇)
     处报错,需后端明确 `level=5` 是否受支持并补充到接口文档,前端将按明确结果调整。
 140. **"经营实体(企业)"区块新增"经营企业"选择弹窗与"证件号码/与经营企业关系/企业类型"三个字段均
     无处提交**:2026-08-10 按第二张原型截图重做该区块,新增①"经营企业"选择弹窗(复用
     `WalletAccountPicker.vue` 第二个实例,选中企业钱包账户后用其 `customerId` 调用
     `POST /api/enterprise-customer/detail` 取 `EnterpriseCustomerDetailVo`,回填
     `enterpriseName`(`CreatePersonalLoanApplicationDraftBto` 已有字段,可正常提交)与
     `certificateNumber`(企业统一社会信用代码,仅展示);②"证件号码"展示框(即上述
     `certificateNumber`,不可提交);③"与经营企业关系"下拉(业务方直接指定5个固定选项:法定代表人/
     股东/合伙人/承包人/实控人,`src/constants/creditEnums.js` 的 `ENTERPRISE_RELATION_OPTIONS`,
     未在 swagger 中定义);④"企业类型"下拉。**②③④三个字段 `CreatePersonalLoanApplicationDraftBto`/
     `UpdatePersonalLoanApplicationBto` 均无对应位置**,只在页面展示/人工核对,不随表单提交,建议
     后端评估是否需要补充。"经营实体(企业)"开关本身也只做前端显隐控制(关闭时不提交
     `enterpriseName`/`businessStartDate`/`businessScope`),Bto 无对应布尔字段。
 141. **"企业类型"下拉使用的动态字典类型 `qiyeleixing` 后端可能尚不存在**:与第132条"kaihuhang"
     字典类型同类情况,`PersonalLoanForm.vue` 的"企业类型"字段用 `DictSelect.vue` +
     `dict-type-code="qiyeleixing"` 实现,若该字典类型尚未在"基础配置 > 动态字典管理"创建,下拉会
     渲染为空选项(不报错,只是无可选项),需要后端/管理员在真实环境补充该字典类型及字典项数据。
 142. **经营范围最少10个汉字的校验规则纯前端本地实现**:`handleSubmit` 中按正则
     `/[\u4e00-\u9fa5]/g` 统计汉字数量,少于10个时阻断提交并提示,与截图"请输入经营范围,至少10个
     汉字"的常驻红字提示一致;`CreatePersonalLoanApplicationDraftBto` 未对 `businessScope` 声明
     任何长度约束,该规则是否需要后端接口层同步校验,由后端评估。
 143. **"影像资料"新增"人脸识别信息"上传项**:复用已有 `FacePhotoUpload.vue`(调用
     `/api/customer-info/personal/face-recognize` 做人脸与证件号码/姓名比对识别),`idNo` 取本页
     "证件号码"展示字段(`certificateNumber`,选择钱包后自动回显,详见第137条已知缺口)、`name` 取
     `form.customerName`;提交给 `loanApplicationImageBtoList` 的 `fileType` 按业务方指定传固定
     字符串 `"04"`(非 swagger `description` 中列出的"身份证正面/身份证反面/营业执照/其他"字面
     枚举,与 `FacePhotoUpload.vue` 在个人开户场景使用的 `fileType='04'` 编码一致,但那是
     `upload-file` 接口自己的文件分类参数,与本处 `LoanApplicationImageBto.fileType` 是两个不同
     命名空间的字段,取值恰好相同,需后端确认该编码含义并评估是否需要将其文档化为正式枚举值)。
     由于"证件号码"字段在选择钱包前为空,人脸识别所需的 `idNo`/`name` 可能暂缺,此时会与
     `IdCardUpload.vue`/`LicenseUpload.vue` 等其它影像上传项一样提示"请先选择所属渠道"/在
     `FacePhotoUpload.vue` 内部提示"请先选择客户"(未选择钱包/证件号码为空时的等价文案)。
 144. **`POST /api/wallet-account/page` 请求体的 `accountType` 字段复用为"客户类型"过滤参数
     (`PERSONAL`个人钱包/`ENTERPRISE`企业钱包),业务口头确认,非 swagger 文档化契约**:该字段在
     响应 `WalletAccountVo.accountType` 里代表"账户子类型"(`AccountTypeEnum`:
     A1主账户/A2/A3/A6保证金/A7分户),但在**查询入参**场景,业务确认可传 `PERSONAL`/`ENTERPRISE`
     按客户类型过滤(swagger 对请求体该字段未声明枚举,系纯 `string`)。`WalletAccountPicker.vue`
     据此新增 `customerType` prop:设置为 `'PERSONAL'`/`'ENTERPRISE'` 时固定按该值过滤并隐藏原有的
     "账户类型(A1~A7)"筛选框(同一请求只有一个 `accountType` 字段,两种过滤语义不能同时生效);
     不设置时保持原有行为不变。个人贷款申请页面"贷款申请人钱包"(`customerType="PERSONAL"`)与
     "经营企业"(`customerType="ENTERPRISE"`)两个选择弹窗已按此改造,商户管理/发票管理/支付管理
     现有的其它 `WalletAccountPicker` 调用点未传该 prop,行为不受影响,后续如有类似"按客户类型
     限定钱包"需求可直接复用。建议后端在 swagger 中把该字段的合法取值(`AccountTypeEnum` A1~A7 +
     `PERSONAL`/`ENTERPRISE` 是否共用同一枚举,还是查询/响应实际是两个语义不同的字段但恰好同名)
     书面明确,避免后续维护者误解。
 145. **个人贷款申请"确认"新增二次确认弹窗(保存/取消/扫码确认)+ 前端拼接二维码**:仿
     `PersonalOpenForm.vue`/`EnterpriseOpenForm.vue` 同款模式("确认"按钮先做前置校验,校验通过后
     只弹二次确认弹窗,不发请求;"保存"/"扫码确认"共用同一次真实 `personal-loan-application/
     create`/`update` 提交,区别仅在成功后是否切到二维码态;"取消"只关弹窗不发请求)。二维码内容
     是前端拼接的 H5 URL:`${VITE_H5_QRCODE_BASE_URL}${VITE_H5_QRCODE_PATH_LOAN}
     ?loanApplicationId=<创建/修改成功返回的申请单号>`(新增 `buildLoanApplicationQrCodeUrl`,
     `src/utils/qrCode.js`),已在 `.env.development`/`.env.production`/`.env.development.local`
     补充 `VITE_H5_QRCODE_PATH_LOAN=/mobile/loan-application`,域名复用既有的
     `VITE_H5_QRCODE_BASE_URL`(生产域名尚未确定时同样靠代码内 `|| 'https://example.com'` 兜底,
     不阻断柜员操作)。**扫码后走向的移动端 H5 确认页(短信验证码+人脸识别,对应
     `POST /api/credit-apply/loan-application/confirm`)不在本项目前端实现范围**(与第19条一致),
     本次改动只负责柜员端生成并展示二维码内容,不做轮询/倒计时(与个人/企业开户的既定处理方式
     一致,提交成功后也不提供"刷新申请状态"入口,如需查看最新状态需回到列表页重新查询)。