| | |
|---|
| | | # 线下报备下企业主体是否也要门头照/内景照（需汇付确认） |
|---|
| | | # 线下报备下企业主体是否也要门店材料（已有实测答案） |
|---|
| | | |
|---|
| | | Status: needs-info |
|---|
| | | Status: ready-for-agent ｜ 2026-09-29 用真实驳回回答，同日实现 |
|---|
| | | |
|---|
| | | ## 现象 |
|---|
| | | ## 结论 |
|---|
| | | |
|---|
| | | 2026-09-24 把进件场景切成 `scene_type=OFFLINE` 之后，**个人（小微）主体**的门店材料要求是清楚的 |
|---|
| | | （F22 门头照 + F24 内景照，语义从「店铺首页截图」改为「实体门头照」），但**企业（含个体工商户）主体** |
|---|
| | | 要不要同样交这两张图，目前**没有任何依据**： |
|---|
| | | **要，而且是一组三张**：门头照（F22）、内景照（F24）、**收银台（F105）**；**企业与个人主体都要交**。 |
|---|
| | | 通道把这一组当「线下经营的门店材料」，在**进件这一步**（不是业务开通、也不是实名）就由 |
|---|
| | | 「商户材料校验服务」按 F-code 逐张核对，缺一张整笔驳回。 |
|---|
| | | |
|---|
| | | - 线上口径下企业从来不需要（代码里 `individualMerchant` 为真才下发 `extended_material_list`， |
|---|
| | | 商户端也只有 `merchantType == 'individual'` 才要求上传），这一条是既有实现，不是这次新加的。 |
|---|
| | | - 线上官方口径只写了「企业使用 fee_rule_id 代替 mcc」，没有提经营场所材料； |
|---|
| | | 线下场景按「有实体经营场所」报备，**很可能会索要门店材料**，但仓库里没有官方原文可依。 |
|---|
| | | 依据是通道自己的驳回原文（2026-09-29，商户端进件被驳后停在待审页的那句话）： |
|---|
| | | |
|---|
| | | ## 影响 |
|---|
| | | ``` |
|---|
| | | 调用商户材料校验服务返回，校验失败 缺失图片：F22-店铺门头照图片;F24-店铺内景图片;F105-店铺收银台 |
|---|
| | | ``` |
|---|
| | | |
|---|
| | | 如果通道对线下企业主体索要 F22/F24，那么企业商户的进件会被驳，而我们的进件表单根本没采集这两张图 → |
|---|
| | | 商户必须重新提交一遍（这正是「提交时校验比通道驳回后再补」要避免的那种返工）。 |
|---|
| | | 两条辅助证据： |
|---|
| | | |
|---|
| | | ## 需要什么 |
|---|
| | | - 更早一次（2026-09-09，个人主体、两张图一张都没收）的驳回用的是**字段名**版本： |
|---|
| | | `【store_header_pic-线下经营-门头照】文件缺失;【store_indoor_pic-线下经营-内景照】文件缺失;【store_cashier_desk_pic-线下经营-收银台】文件缺失;` |
|---|
| | | —— `store_header_pic` 正是我方个人进件请求里已在用的那个字段名，所以另两个字段名就是 |
|---|
| | | `store_indoor_pic` / `store_cashier_desk_pic`（本次实现用的就是这一对）。 |
|---|
| | | - 官方《商户业务开通》文档里，`micro_biz_type` 的说明只点了前两张 |
|---|
| | | （「需要提供 F22：店铺门头照图片；F24：店铺内景图片，补充资料填写在 extended_material_list 对象中」）， |
|---|
| | | **F105 在仓库内的官方原件里查不到**——它只出现在通道的运行时报错里。这是本次唯一一条 |
|---|
| | | 「无法用官方原件对齐、只能按实测报错实现」的地方。 |
|---|
| | | |
|---|
| | | 向汇付确认（书面最好）：**线下场景（1/2/3）下企业主体进件需要哪些经营场所材料**？ |
|---|
| | | - 若需要 F22/F24：企业路径要补采集（后端校验 + 商户端表单 + 落库 + 进件请求下发）， |
|---|
| | | 与个人路径对齐；`extended_material_list` 的下发条件从「仅个人」改为「个人 + 企业」。 |
|---|
| | | - 若不需要：在 `05` 里记一条「线下企业不需门店材料（依据：汇付 ×× 回复）」，免得下一个人再问一遍。 |
|---|
| | | 驳回信息的**落库位置**（判它来自哪一步的判据）：`reject_reason` 里是我们原样存的通道文案、**没有前缀**。 |
|---|
| | | `applyOnboardingResult()`（进件递交）写的是无前缀文案；`advanceBusinessOpen` / `advanceWechatConfig` |
|---|
| | | 写的是「商户业务开通失败：…」/「微信商户配置失败：…」。所以这条驳回来自**进件递交**，不是业务开通。 |
|---|
| | | |
|---|
| | | ## 因此改动（本仓，同日） |
|---|
| | | |
|---|
| | | - 商户端表单：三类主体（企业/个体工商户/个人）在第一步都采集三张图，缺任一张在本地就拦住； |
|---|
| | | 个人主体原先只有两张，**收银台是新加的入口**；企业主体原先一张都没有。 |
|---|
| | | - 服务端：请求加 `storeCashierUrl`；校验改成三张、不分主体；落库 `store_cashier_url`（迁移 `V156` |
|---|
| | | + `MerchantOnboardingSchemaInitializer`）； |
|---|
| | | 进件请求发 `store_header_pic` / `store_indoor_pic` / `store_cashier_desk_pic`（企业与个人两条网关都发）； |
|---|
| | | 业务开通的 `extended_material_list` 改成**两类主体都发** F22/F24/F105。 |
|---|
| | | - 重提补齐（`supplyMissingOnboardingMaterials`）把收银台一并纳入，并且不再只对个人主体生效—— |
|---|
| | | 已提交但停在某个阶段的存量的进件走这条路补图。 |
|---|
| | | - 后台进件详情的「门店照片」区补一列「店铺收银台」。 |
|---|
| | | |
|---|
| | | ## 还需要向汇付确认的（不影响本次上线，但别让它再咬一次） |
|---|
| | | |
|---|
| | | 1. **F105 的官方定义与适用主体**：仓库内没有 F105 的官方原件条目，目前全靠这一条实测报错。 |
|---|
| | | 要书面确认「线下经营的门店材料就是这三张、且企业主体同样适用」，否则下次通道调整我们只能再猜一遍。 |
|---|
| | | 2. **企业主体在** **`extended_material_list`** **里交这一组是否被通道承认**：官方把 F22/F24 的要求写在 |
|---|
| | | `micro_biz_type`（个人/小微）下面，企业主体那里我们按对称补齐（同一组 F-code）。若通道对企业主体 |
|---|
| | | 另有字段（官方企业在进件 `file_list` 里用的是 F49 内景 / F50 门头），要按回复改。 |
|---|
| | | 3. 若通道对线下企业主体其实**不要**这一组，应把校验与下发退回「仅个人」，并在 `05` 记一条依据。 |
|---|
| | | |
|---|
| | | ## 关联 |
|---|
| | | |
|---|
| | | - 代码位置：`HuifuMerchantBusinessOpenGateway`（`extended_material_list` 的下发条件）、 |
|---|
| | | `MerchantSettlementService`（个人主体的两张图校验）、`merchant-onboarding.uvue`（表单）。 |
|---|
| | | - 置信度约定见 `docs/huifu/README.md`：拿到回复前，这条只能标【待确认】。 |
|---|
| | | - 代码：`MerchantSettlementService`（三张图校验、落库、`advanceBusinessOpen` 的材料闸门）、 |
|---|
| | | `HuifuIndividualOnboardingGateway` / `HuifuEnterpriseOnboardingGateway`（进件 `store_*_pic`）、 |
|---|
| | | `HuifuMerchantBusinessOpenGateway`（`extended_material_list`）、`merchant-onboarding.uvue`（表单）。 |
|---|
| | | - 台账：`docs/huifu/02-进件与收款能力.md`（门店材料一段）、`docs/huifu/06-踩坑清单.md` 第 4b 条、 |
|---|
| | | `docs/huifu/08-上线与环境.md` §4A 验收项。 |
|---|
| | | - 置信度约定见 `docs/huifu/README.md`：本条属【实测】（真实回执原文），F105 的官方口径仍为【待确认】。 |
|---|
