From d7f51c5d6d2b3f9b2f61483599e30d24f2658df2 Mon Sep 17 00:00:00 2001
From: yeg <1347747024@qq.com>
Date: 星期二, 29 九月 2026 17:06:34 +0800
Subject: [PATCH] docs(huifu): 三张门店材料已被真实进件验证；补记工商四要素一字之差即驳回
---
docs/huifu/06-踩坑清单.md | 1 +
.scratch/offline-wechat-scene-switch/issues/03-enterprise-offline-store-materials-unknown.md | 12 ++++++++----
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/.scratch/offline-wechat-scene-switch/issues/03-enterprise-offline-store-materials-unknown.md b/.scratch/offline-wechat-scene-switch/issues/03-enterprise-offline-store-materials-unknown.md
index 9bbe8c1..77a4893 100644
--- a/.scratch/offline-wechat-scene-switch/issues/03-enterprise-offline-store-materials-unknown.md
+++ b/.scratch/offline-wechat-scene-switch/issues/03-enterprise-offline-store-materials-unknown.md
@@ -45,10 +45,14 @@
1. **F105 的官方定义与适用主体**：仓库内没有 F105 的官方原件条目，目前全靠这一条实测报错。
要书面确认「线下经营的门店材料就是这三张、且企业主体同样适用」，否则下次通道调整我们只能再猜一遍。
-2. **企业主体在** **`extended_material_list`** **里交这一组是否被通道承认**：官方把 F22/F24 的要求写在
- `micro_biz_type`（个人/小微）下面，企业主体那里我们按对称补齐（同一组 F-code）。若通道对企业主体
- 另有字段（官方企业在进件 `file_list` 里用的是 F49 内景 / F50 门头），要按回复改。
-3. 若通道对线下企业主体其实**不要**这一组，应把校验与下发退回「仅个人」，并在 `05` 记一条依据。
+ —— **2026-09-29 17:05 已被真实通道接受**（企业主体进件受理成功，`huifu_id 6666000245406052`，
+ 回执 `90000000 审核中`）：说明企业走 `store_header_pic` / `store_indoor_pic` / `store_cashier_desk_pic`
+ 这三个字段名是被通道认的，三张图缺一不可这条口径也对上了。**字段名这条待确认可以划掉了**；
+ 剩下的只是「F105 在官方文档里怎么定义」这种留档问题。
+2. ~~企业主体在 `extended_material_list` 里交这一组是否被通道承认~~：同日业务开通（17:05:20）与微信小程序配置
+ （17:05:31 回「成功」）都在受理/成功路径上，未再报材料问题。**同样已由这次真实进件验证。**
+3. 若通道对线下企业主体其实**不要**这一组，应把校验与下发退回「仅个人」，并在 `05` 记一条依据
+ —— 已被实测证否：企业主体确实要。
## 关联
diff --git "a/docs/huifu/06-\350\270\251\345\235\221\346\270\205\345\215\225.md" "b/docs/huifu/06-\350\270\251\345\235\221\346\270\205\345\215\225.md"
index 9468c27..967fe88 100644
--- "a/docs/huifu/06-\350\270\251\345\235\221\346\270\205\345\215\225.md"
+++ "b/docs/huifu/06-\350\270\251\345\235\221\346\270\205\345\215\225.md"
@@ -40,6 +40,7 @@
| 3 | 第一次提交进件就 500，报 `Unknown column 'license_validity_type'` | 代码 INSERT 写了这些列，V80/V99/V127/V128 都没建；此前测试用 JDBC 直接造进件记录，**绕过了真实入口** | 【实测】 |
| 4 | 个人（小微）走完进件也拿不到微信收款能力 | 门店照片（F22 门头照 / F24 内景照）**一个字段都没收**，而官方在业务开通与实名两处都点名要 | 【实测】 |
| 4b | 线下报备后进件在**第一步**就被整笔驳回：`缺失图片：F22-店铺门头照图片;F24-店铺内景图片;F105-店铺收银台` | 通道把「线下经营的门店材料」定成**一组三张**、并在进件这一步由材料校验服务逐张核对；我方只收了两张、且只对个人主体收，**第三张（F105 收银台）全仓没有任何采集口**，企业主体更是一张都不发（`extended_material_list` 的下发条件写成「仅个人」）。商户端的「重新提交」也没有那两张图的入口 | 【实测】（2026-09-29 真实驳回原文） |
+| 4c | 门店材料补齐后，进件改报 `商户注册名称、营业执照编号、法人姓名、法人证件号工商四要素验证不一致`，且**不告诉你错在哪一项** | 通道拿这四个值去比对**国家工商登记**，逐字相等才算过。实测：同样一家公司填「成都喜望**软件**有限公司」被驳、改成执照上的「成都喜望**科技**有限公司」立刻受理——**一字之差就整笔不一致**。所以「商户名称」必须照抄营业执照全称（不是品牌名/简称，也不是想当然的近似名），法人姓名与证件号同理。**测试环境用虚构/借用资料时这条永远过不了**：通道给的正路是去汇付控台「商户 → 商户进件 → 模板配置 → 进件白名单」做工商四要素加白（报错原文自己写了这个出口） | 【实测】（2026-09-29：信用代码 `91510100MA639GU63G` 同代码同法人，仅名称两字之差，先驳后过） |
| 5 | 已拿到真实汇付号的存量个人进件一次业务开通都没做过，也没有补图入口 | 分阶段模型下重复提交不新建进件，商户没有别的补图入口（开发库实测 10 条全部 `business_open_status=not_started`） | 【实测】 |
| 6 | 商户端换账号登录，进件页把**上一个账号**的身份证号、银行卡号预填进来 | 草稿存在固定全局 key，uni storage 不分账号，`restoreDraft()` 不校验归属 | 【实测】 |
| 7 | 进件能过、商户建得出来，但平台对它调 config/open/query 一律 `20002 数据权限认证失败` | 20002 与层级无关；改 `head_office_flag`+`head_huifu_id` 建成平台下级**实测无效**，还额外被索要 F725/F726/F727 | 【实测】 |
--
Gitblit v1.7.1