交付出件箱

← 返回出件箱

4 家早期门店「结算记录补录」· 现状研究与方案(未动任何数据)

dev2 · 2026-08-20 · 全部为生产库只读查询结果 · 未执行任何写操作

一、要解决什么

4 家门店入驻早于结算签约流程:资料线下给的(门头/营业执照/收款授权证书/仪器照片)、
钱也付了(有付款截图)、机构管理里已建档已开通。缺的是结算侧的流程和记录。

长官明确:不能让他们重走一遍签约 —— 会重复开席位。

二、🔴 研究中发现的头号问题:两套 ID 对不上

代码里模型注释写死「PK = organizations.id · 1:1」
(settlement/backend/app/models/settlement.py::OrgSignupProfile)。

但生产实测不是这样:

organizations           id 范围 1 ~ 16       (15 家)
org_signup_profiles  org_id 范围 10000000+  (7 条)
按 ID 关联 → 7 条档案在机构表里一条都找不到(org_exists 全为 0)

只有按公司名才能对上:

结算 org_id	公司名	机构表真实 id
10000000	测试机构有限公司	9
10000001	杭州医瞳眼健康科技有限公司	11
10000002	杭州高达视光技术有限公司	12
10000003	金堂丽睛眼科诊所有限公司	14
10000004	微信支付测试公司	16

⚠️ 补录必须先定死用哪个 ID。用错 = 资料挂到错的机构上,且生产数据改错不可逆。
这条必须先向核心方/root 问清:10000000 号段是有意设计,还是历史遗留。

三、补一家完整记录 = 写 4 张表

用杭州高达(已开通样板) 反推,一家齐全的记录长这样:

① `org_signup_profiles`(签约档案)

字段	样板值	补录来源
`org_id`	10000002	🔴 待定(见第二节)
`channel_id`	有	要指定归属渠道
`status`	已开通	直接给终态
`license_company_name`	杭州高达视光技术有限公司	营业执照
`address`	有	线下资料
`license_file_keys`	2 张	线下照片,需上传
`storefront_file_keys`	1 张	门头照
`optometrist_file_keys`	1 张	收款授权证书
`equipment_file_keys`	3 张	仪器照
`activated_seat_count`	1	实际开通席位数
`service_start_at / end_at`	2026-08-07 / 2027-08-07	服务期

② `store_service_orders`(服务订单)

order_no=SVC20260807001 · order_type=首次开通 · seat_count=1 · service_days=365
amount_due=2380.00 · payment_method=线下转账 · status=已完成
created_terminal=platform_mobile · source_channel_id=有

③ `payment_vouchers`(付款凭证)

payment_no=PAY202608010 · payer_name=杭州高达眼视光中心 · submitted_amount=2380.00
status=已确认到账 · voucher_file_key=有(付款截图) · purchase_seat_count=1

④ `payment_confirmations`(到账确认)

confirmed_amount=2380.00 · confirmed_by=4(操作人) · confirmed_at=日期 · result=confirmed

附件怎么存

file_key 形如
store-signup-files/<org_id>/license/<uuid>-<原文件名>.jpg,
后端 STORAGE_BACKEND=local|oss 开关决定落本地还是 OSS。
⇒ 照片必须先按这个规则上传到存储,拿到 key 才能写库,不能只往库里塞路径。

四、山东靓目现状(举例)

organizations: id=3 · 山东靓目医疗服务有限公司 · 周丽 / 15668271344 · is_active=t · 建于 2026-08-05
结算侧:       org_signup_profiles 0 条 · store_service_orders 0 条 · payment_vouchers 0 条

⇒ 结算侧完全空白,四张表都要从零补。

五、三种做法对比

方案	怎么做	优点	缺点
A. 后台代填	用平台端现成的「编辑资料」代填	零开发、有审计、走正规通路	🔴 走不通:代填只能改已存在的档案,建不了新档案;这 4 家连档案都没有
B. 一次性补录脚本	写脚本按样板插 4 张表 + 传附件	可 review、可预演、有留痕、可重复执行	要开发 + 发版
C. 手工 SQL	`sudo db-prod` 直接 INSERT	快	🔴 无 review、无留痕、附件还是得另传、错了不可逆 —— 不建议

我的建议:B。理由:4 家 × 4 张表 × 十几个字段 + 附件,手写 SQL 出错概率高;
脚本能先在 test 上跑一遍验证,生产再跑,且能把"已存在就跳过"写成幂等。

六、动手前必须先定的 5 件事

🔴 org_id 用哪套(1~16 还是 10000000+)—— 最关键,要问核心方/root
4 家分别是哪几家(长官说会告知)
每家的归属渠道(channel_id 必填,决定分成算给谁)
每家的成交信息:席位数、成交金额、付款日期、服务起止日
附件文件:长官手里的照片需要给到,按 file_key 规则上传

七、我的执行纪律

本次研究全程只读,未对生产写入任何数据
按自定纪律:改生产数据前先 SELECT 命中行给长官过目,长官点头才执行
能走脚本发版就不用 db-prod 抄近路(有 MR 留痕、可回滚、可 review)

云机环境 · 非验收证据。