chore(migration): 进件来源列的迁移让号，V157 改为 V158
远端同期推送了 V157__backfill_premium_service_merchant_types，同一个版本号下有两个迁移，
Flyway 直接拒绝启动（"Found more than one migration with version 157"）。按仓库惯例后到者让号：
本票的 V157__merchant_onboarding_source 改名为 V158__merchant_onboarding_source，建列语句一字未动，
文件头补了让号说明；代码与 ADR 里对编号的引用一并改到 V158。
测试库重置后全量重跑通过（455 项，仅 docs/agents/testing.md 记录的 6 项既有基线失败），
确认两套迁移（远端 V157 + 本次 V158）能一起从零重建。
| | |
|---|
| | | - [ ] 解绑不动商户端登录账号；解绑后可以重新纳管。 |
|---|
| | | |
|---|
| | | **边界与兼容** |
|---|
| | | - [ ] 迁移只新增一列（来源标记），编号取 `V157`，可重复执行。 |
|---|
| | | - [ ] 迁移只新增一列（来源标记），编号取 `V157`，可重复执行。（落地时与远端撞号，已让号改为 `V158`） |
|---|
| | | - [ ] 纳管与解绑的接口放在既有的进件查改前缀之下，沿用现有的商户结算权限码，不新增权限码、不改共享的权限映射。 |
|---|
| | | - [ ] 不新增前端路由。 |
|---|
| | | - [ ] 自助进件的既有流程与存量商户行为不受影响。 |
|---|
| | |
|---|
| | | |
|---|
| | | - `provider_huifu_id` 目前的三个写入口全部来自汇付回执（进件结果与绑卡回调）。纳管必须**新增一个写入口**。 |
|---|
| | | - 进件记录新增一列标明来源（自助进件 / 纳管），用于进度刷新区分判定依据。迁移编号取 **V157** |
|---|
| | | （当前已提交最大为 V156，动手前确认无人占号）。 |
|---|
| | | （当前已提交最大为 V156，动手前确认无人占号）。**落地时确实撞号了**：远端同期推送了 |
|---|
| | | `V157__backfill_premium_service_merchant_types`，本票让号改为 **V158**（见迁移文件头的让号说明）。 |
|---|
| | | - 进件记录的 `application_no` 与 `idempotency_key` 都是唯一键且非空，纳管生成的键必须可稳定复现 |
|---|
| | | （由汇付商户号派生），使重复纳管幂等。 |
|---|
| | | |
|---|
| | |
|---|
| | | 先只读核验通道，再建结算卡与进件记录，并跑一次进度刷新。 |
|---|
| | | |
|---|
| | | 两条路径**收敛到同一套进件记录、同一套六阶段进度、同一套收款就绪判定**，只有来源不同（进件记录的 |
|---|
| | | `source`：`self` 自助进件 / `managed` 纳管，见 `V157`）。也就是说，纳管不新造链路、不新造状态， |
|---|
| | | `source`：`self` 自助进件 / `managed` 纳管，见 `V158`）。也就是说，纳管不新造链路、不新造状态， |
|---|
| | | 只在「写入口」与「来源标记」两处新增——`provider_huifu_id` 原先三个写入口全部来自汇付回执，纳管是第四个。 |
|---|
| | | |
|---|
| | | **纳管全程只查询、不下发。** 进度刷新是纯查询；`source=managed` 的记录在刷新链路里跳过全部下发步骤 |
|---|
| | |
|---|
| | | * |
|---|
| | | * <p>为什么不新造链路：纳管产出的就是一条进件记录。它复用既有的进件记录、六阶段进度、收款能力快照 |
|---|
| | | * 与收款就绪判定，只在「写入口」和「来源标记」两处新增——{@code provider_huifu_id} 原先三个写入口 |
|---|
| | | * 全部来自汇付回执，纳管是第四个（见 V157 的 source 列）。 |
|---|
| | | * 全部来自汇付回执，纳管是第四个（见 V158 的 source 列）。 |
|---|
| | | * |
|---|
| | | * <p><b>全程只查询、不下发。</b> 外部进件商户的口径已由业务要求与自助进件保持一致，纳管只需核实； |
|---|
| | | * 而补开微信、绑人才端 AppID、改支付场景、开启延迟入账这些下发操作都不幂等（改支付场景会重建微信 |
|---|
| | |
|---|
| | | |
|---|
| | | public Map<String,Object> view(Long id) { return view(application(id)); } |
|---|
| | | |
|---|
| | | /** 进件来源标记：后台纳管进来的外部进件商户。取值与 V157 的 {@code source} 列一致。 */ |
|---|
| | | /** 进件来源标记：后台纳管进来的外部进件商户。取值与 V158 的 {@code source} 列一致。 */ |
|---|
| | | public static final String SOURCE_MANAGED = "managed"; |
|---|
| | | |
|---|
| | | /** |
|---|
| | |
|---|
| | | columns.put("store_cashier_url", "varchar(512) default null"); |
|---|
| | | // 经营详细地址：线下进件的 detail_addr 是通道必填项，与证件地址分开存。见 V155 的说明。 |
|---|
| | | columns.put("business_address", "varchar(255) default null"); |
|---|
| | | // 进件来源（自助进件 / 后台纳管）：决定进度刷新是否允许下发通道改动。见 V157 的说明。 |
|---|
| | | // 进件来源（自助进件 / 后台纳管）：决定进度刷新是否允许下发通道改动。见 V158 的说明。 |
|---|
| | | // 开发库（flyway 关闭）靠这里补列，否则纳管的 INSERT 会报 Unknown column。 |
|---|
| | | columns.put("source", "varchar(16) not null default 'self'"); |
|---|
| | | for (Map.Entry<String, String> column : columns.entrySet()) { |
|---|
| File was renamed from talent-card-server/src/main/resources/db/migration/V157__merchant_onboarding_source.sql |
| | |
|---|
| | | -- 进件来源标记：区分「商户端自助进件」与「运营在后台纳管的外部进件商户」。 |
|---|
| | | -- |
|---|
| | | -- 编号让位（2026-10-12）：本文件原为 V157，与远端已推送的 V157__backfill_premium_service_merchant_types |
|---|
| | | -- 撞号——同一个版本号有两个迁移，Flyway 会直接拒绝启动。改动只在编号与文件名，建列语句一字未动。 |
|---|
| | | -- 已经执行过原 V157 的那份测试库要按 docs/agents/testing.md 重置一次。 |
|---|
| | | -- |
|---|
| | | -- 背景：商户有两条进件路径。一条是商户在我们商户端自助进件（既有能力），另一条是商户直接在汇付侧 |
|---|
| | | -- 完成进件、需要被接进我们的商家（见 .scratch/merchant-external-onboarding/spec.md）。两条路径收敛到 |
|---|
| | | -- 同一套进件记录、分阶段进度与收款就绪判定，只有「来源」不同，所以只加这一列。 |
|---|
