6.8 KiB
业务闭环方案（规划，未实施）
1. 复用而非重建
现有入口是付款页面的待组批、付款批次、复核及“下载银行制单”。后端 POST /api/payment-batches/:id/payment-order 要求财务角色与 payment.order.export，批次 reviewed，完整且可用的同源收付款快照。生成成功会更新导出计数和审计；不能把这个 POST 当作生产只读预检。
代码入口：server/src/routes/paymentBatches.js、server/src/services/paymentOrderXls.js、server/src/scripts/fill-payment-order-template.py、client/src/pages/PaymentBatchesPage.tsx。历史范围见 archive/2026-08/08-02-corporate-bank-account-payment-order，本 task 不重开已完成实现。
2. 模板映射
| 列 | 模板字段 | 报销付款来源/行为 |
|---|---|---|
| 1 | 序号 | 稳定排序的批次行号，文本 |
| 2–3 | 付款方账号/账户名称 | 复核批次冻结的公司付款账户 |
| 4 | 收款方行别代码 | CCB 本行固定文本 01，不生成他行 02 |
| 5–7 | 收款账号/名称/开户行名称 | 同一批次的收款快照 |
| 8 | 收款方联行号 | 沿现有本行制单合同留空 |
| 9 | 客户方流水号 | 批次号+行号，稳定、唯一并满足长度限制 |
| 10 | 金额 | 已批准批次项金额，数值且两位小数 |
| 11 | 用途 | 报销款，不复制工资/公积金用途 |
| 12 | 备注 | 报销单号 |
| 13–15 | 短信标志/手机/附加信息 | 0、不通知，后两列空；不读样例手机号 |
用户三个 input 文档的表头完全一致，空白模板与内置模板相同，账号列为文本。检查原件只提取结构与摘要，原件不改、不重新保存、不复制真实行到测试夹具。工资及公积金样例仅用于确定文件格式，不暗中扩为新业务。
3. 两条业务线
A：0014 当前已审批待付款 → 核定归属/主体 → 管理员直接维护真实 CCB 收款资料 → 财务重查 readiness → 财务组批 → 独立付款复核 → 财务下载 .xls → 授权人员网银导入核对并付款 → 回单与实际结果匹配 → 系统登记。
B：三张 rejected → 本人逐张修改 → 本人重提 → 实际审批人处理 → 通过后进入下一批付款。不等 A 或 AP 发布；未通过不能直接放入付款批次。
4. 停止条件与授权
- 身份、单号、原值不一致，或收付款资料非 CCB：停止对应操作，不按名字/唯一主体猜值。
- 生产 legal_entity_id 修正：单人单字段、前置锁定和原值检查、条件写入、提交后独立回读；须单独授权。失败不自动反复重试，回退另批。
- 银行真实资料由管理员/获授权维护人直接在系统录入；不让财务通过聊天转交卡号给执行端。
- 解密/生成真实制单涉及敏感数据；按明确范围批准，只输出脱敏验收结果。正式下载由财务操作且保留审计，不用管理员或伪身份抵扣。
- 已存在批次、复核不通过、资料变动或旧快照缺失：核实实际状态，不删批次或改数据库状态绕过。是否重建批次另行决定。
- 银行导入失败、部分成功或回单未核对：不标全批成功，不因重下载重复付款。
5. AP 发布独立处理
AP task 保留原实施写入面和已通过用户复核。提交/推送后冻结包含 CEO 撤权的完整新 SHA，重新核对发布所需时效、回滚制品和生产漂移；旧 58dcee0 不再是正确候选。没有新发布授权就不部署，不能因业务急付款而默认豁免门禁。
6. 验证层级
- 首轮规划完成静态源码与原件结构检查；用户追加技术审查/修复授权后运行定向合成测试，并在当前生产容器以独立合成密钥和纯合成资料验证制单运行环境。后者不访问数据库、不用真实密钥、不读取真实银行卡、不调用正式导出接口、不落制单文件。
- 执行阶段先用合成收付款数据核验模板、BIFF8、金额与文本类型、未复核拒绝、非建行拒绝、重下载与审计、付款角色分离；已有测试能复用则不另造。
- 获准核实生产模板摘要、Python/固定依赖等运行前提时，不顺手触发真实导出；代码基线存在功能不等于生产运行时可用。
- 真实财务路径、银行导入结果与最终回单属于业务验收，合成测试不能抵扣；分别记录未执行/通过/阻断，不提前全绿。
7. 八角度复核与修订
| 角度 | 审查结论 | 处理 |
|---|---|---|
| 业务优先级 | 已审批 0014 和退回三单是不同状态，不互等 | 维持两条业务线，不把 AP/门禁作为重提前置 |
| 角色职责 | 财务可制单不等于可改员工银行卡；admin 通配也不替代制单路由的财务角色要求 | 管理员录资料，真实财务组批/导出，非制单人复核；不加权限 |
| 资料与隐私 | 付款方账户已有，但个人收款资料和所属主体缺失仍是真实阻断 | 按原值另批补 0014 归属人，不批量关联 smoke；敏感资料不进聊天 |
| 财务操作顺序 | 当前详情页未制单先把上传回单作为主动作，下载藏在更多，与原银行制单合同及本轮顺序冲突 | 最小修复动作模型：首次下载→上传回单→登记完成；人工上传保留在更多，不添加硬门禁 |
| 格式兼容 | 原件和内置模板一致；既有测试只验文件头、行数、总额等，缺少独立逐列读回 | 新增 xlrd 对生成文件的表头、列宽、工作表、前导零文本、金额与用途/备注读回断言 |
| 运行环境 | 本地普通 Python 可能无 BIFF8 依赖，不能据此推断生产缺失 | 使用既有固定 venv；生产容器合成生成/独立读回 PASS，不安装新依赖，不改生产 |
| 失败与重试 | 下载有审计写入；导出不等于付款，网络失败后的重下载也不能重复银行划款 | 补下载原因/取消零请求、文件成功下载、重下载警示、失败不推进状态、手工回单入口测试 |
| 发布与实际付款 | 当前正确 AP 修订与本轮界面补丁都未部署；银行文件“验证”和真正导入可能不分离 | 新候选另批；只有网银明确支持不提交的校验模式才做真实文件格式校验，否则不为测试上传文件，实际付款须按业务批准办理 |
本轮界面修复仅改变已选付款详情的动作优先级，继续使用既有按钮/更多/移动端固定操作区，不重画页面、不调整角色、审批、付款状态机、数据快照或后台接口。保留现金/历史批次人工付款、已有回单直接登记及回单查询失败时不冒充空状态的行为。
报销主体和收款资料应在组批前补齐，因为批次冻结的是当时的账户快照；生成文件不能静默取之后变更的个人账号替换已复核快照。已有批次若需取消/重建，重新交审，不直接更新旧快照。