hyb-oa/.trellis/tasks/09-08-reimbursement-payment-closeout/prd.md

报销付款与银行制单业务闭环

Goal

2026-09-10 本轮批准范围

本轮报销/付款体验全部完成并合并验证后再部署，不等待项目所有存量技术债。付款三项为中文文件名、下载免手填理由、操作卡下方处理进度；退回留痕删除由 09-04 task 独立交付，共同验收。已发布的发票优先录入保留回归，不重复实施。本段覆盖下方历史 R8 的“制单下载必须原因”；不覆盖回单下载、完整账号查看或取消原因策略。真实付款仍由业务人员执行。

2026-09-09 真人反馈后的后续验收增量

当前业务事实：用户反馈独立付款复核后，已成功下载银行制单且文件内容没有问题；未据此确认网银付款或回单登记完成。以下付款体验取向已获用户采纳，报销状态与录入改动的综合实施/测试方案见 design.md 最新阶段，待整体方案确认后执行，不继承上次部署授权。

后续确认：用户选择“添加发票→我的发票弹窗→选择旧票/上传并自动 OCR→添加到报销单→自动生成明细并关联”的默认路径。无需再手工建立明细后关联；已有明细入口直接加票，正常页面只展示发票摘要而非关联状态。真实腾讯 OCR 默认可用是业务要求，不是尚待选择是否启用的产品选项；是否配置正确/识别成功仍需执行端验证。此轮授权是更新规划，不表示已实施、已部署或取得新的生产配置/票据发送授权。详细合同归 08-29 发票 task，退回删除与付款三项保持已确认方向。

• 下载文件名统一为“报销制单_批次号.xls”，例如报销制单_PB-20260909-001.xls；保留唯一批次号，不放姓名/金额/账户信息，不改变 BIFF8 内容、工作表、模板和列格式。
• 首次和再次下载均不强制手填用途；敏感文件确认保留，再次下载明确提醒重复导入/重复付款风险。保留权限、已复核状态、独立复核约束及完整下载审计，系统用途不得伪装为用户填写原因；查看完整账号、作废回单、取消批次等理由要求不变。
• 桌面付款详情右侧为操作卡片、处理进度卡片，左侧为概要和单据明细；小屏操作与进度相邻且可达，避免横向溢出。不改流程含义，不将文件下载次数等同银行付款结果。
• 交付需包含相关真实后端端到端验证和部署后验证，不将员工/经理的正式业务操作作为发现基础功能缺陷的默认验收方法。银行实付、真实单据业务判断仍由业务人员负责，代理不得代付或伪造回单。

以业务结果为目标：已审批未付款的 0014 完成付款准备、独立付款复核、按用户模板生成建行制单、银行付款及回单登记；三张退回报销由本人修改重提，实际审批后再进入付款，不让两条业务线互相等待。

2026-09-08 首轮为规划；用户随后明确批准检查并按指南更新 Trellis、多角度审查修订计划，以及完成影响这些业务的技术债务。当前执行范围为本地技术审查、针对性合成验证和已定位阻断的最小修复；不改变既有人工制单/网银流程。未批准生产数据回填、真实账号解密、真实提交/审批/组批/导出/付款、部署或外部通知。此前财务直接经理单字段修正已完成，不重复操作。

已核实依据

• 截图显示 0014 待组批且被三项阻断：归属人缺公司主体、收款银行缺失、收款账号缺失。截图不是完整 readiness 通过证明，不凭页面人员名称替代写入前 owner_id 核实。
• 最新只读结果：一个启用未归档主体、一条匹配该主体的启用建行付款账户，密文字段非空；解密可用性未验证。公司付款账户不等于个人收款账户，不重复创建已有账户。
• 用户确认 E1/E3/E5/E6 为 smoke 账号，排除在业务回填范围外。只先准备 0014 归属人的单字段主体修正，不批量回填所有员工。
• input/制单模板.xls 与 server/src/assets/payment-order/ccb-payment-order-template.xls 字节完全一致，SHA-256 为 72e83ab6b7cd71263ca00196746de896e02a02390bab5c896dabd76421e40c0e。
• 两份已填写的工资、公积金制单样例均为 BIFF8，三个工作表、15 列，表头与模板完全一致。只提取结构，不复制样例的户名、账号、金额或联系人；样例用途不构成新增工资/公积金业务范围。
• 当前源码已经包含付款复核后下载银行制单功能。制单路由、生成器、Python 填表脚本、内置模板及付款页面与生产基线 f223bfb 的 Git 内容无差异；这证明基线包含能力，不证明运行时依赖、真实数据或企业网银导入已通过。
• AP 修订已由用户复核，未提交部署；58dcee0 不含撤销 CEO 台账授权的最新修订，不能用作该修复的最终候选。

Scope

2026-09-08 追加授权与结果：用户批准仅补 0014 归属人的所属主体。已于北京时间 22:30 完成 majianyong 的 legal_entity_id 空值到唯一启用未归档主体的条件更新（1 行），提交后独立连接回读匹配。此项覆盖首轮“主体回填未授权”的历史状态；个人收款银行/账号仍待授权管理员在系统维护，本次未查验或写入银行资料，未证明完整 readiness 已通过，其他生产业务动作及部署仍未授权。

0014 付款前置资料、既有付款复核与 BIFF8 制单、人工银行付款及回单闭环；三张退回报销本人重提；AP 发布作为独立关联任务。当前获批交付为规划修订、业务相关技术审查及最小本地修复，真实业务动作另批。

Requirements

• R1：业务优先；不要求 0014 等三张退回单，不要求三张退回单等 AP 发布。不让 R1 门禁、58 条红项或合同测试成为本 task 的扩修前置。
• R2：生产补数据前核对唯一业务记录、原值和目标。只准备 0014 归属人的 legal_entity_id 空值到获批主体的修正；非空或身份不符停止，执行另批并回读。唯一启用主体不代替业务归属批准。
• R3：真实收款开户行与账号由具备 employee.bank.manage 的授权人员直接录系统；现有真实账号由 wangshunli 管理员维护，普通 finance 不因制单需要新增维护权限。非建行停止，不发聊天、不填样例或占位账号。
• R4：付款账户解密检查与真实制单均在获准范围内执行；明文只在必要进程内存/实际交付文件出现，不输出日志、Trellis 或完整快照。解密可用性与真实银行账户正确性分别确认，不能互相替代。
• R5：财务用真实身份重新检查 0014 待组批状态，通过实际 readiness 后创建批次。已有批次占用、部门开关、收付款资料等阻断按实际返回逐项处理，不把某三项补齐称为所有检查通过。
• R6：报销审批和付款复核是两道不同业务动作。wangzhiling 制单，具备权限且不是制单人的实际人员复核；majianyong 为已有 ceo 业务复核人候选，须满足系统当前条件，不伪造账号或绕过独立复核。复核人同时为受益人的治理边界沿既有获批规则，不在本轮擅自加层或宣称不存在风险。
• R7：仅 reviewed 的合格报销银行付款批次由财务生成 BIFF8 .xls。沿用精确模板、15 列与三个工作表，账号和行别代码保持文本，行别为 01，金额两位小数，用途为报销款，备注关联单号，客户流水号可追溯且不重复；不改为 xlsx/CSV，不套用样例里的真实数据。
• R7a：详情页复核通过、可制单、未生成且无回单时，唯一主动作优先“下载银行制单”；生成后切换“上传银行回单”，重下载进入更多。未生成但已人工付款仍可从更多直接上传，已有回单优先登记完成；资料不完整、非银行或回单状态未知时不错误引导下载/付款。桌面和移动端使用同一动作模型，不改变列表页主动作或增加自动付款。
• R8：制单下载需要原因并写导出审计/次数，不是纯只读；重下载不等于新增银行付款。未复核、旧快照缺失、非建行、解密/依赖/模板失败不得生成部分文件，不用手填绕过本轮制单验收。
• R9：生成 .xls 不等于付款成功。由授权银行操作人导入网银、核对对象/笔数/金额、按银行流程批准执行；银行返回结果与回单核对后才在系统登记。失败/部分成功分别处理，不能整批提前标已付；单据状态、付款记录与回单一致才算闭环。
• R10：三张 rejected 各自核实退回原因、参与人和实际修改结果，由 majianyong 本人重提；不代维护、不复制绕过、不提前承诺所有审批必过。由实际分配的审批人处理，通过后进入后续批次，不重复纳入 0014 当前批次。
• R11：复用已有制单功能。用户已授权本地修复影响这些业务的技术债，先复现再做最小修复；若涉及新增业务语义、权限放宽、状态机重构或生产写入，重新交审，不先重构、升级业务依赖或新增付款模块。

Acceptance Criteria

• 0014 的实际归属人、当前阻断和允许操作范围已核实；主体及真实收款资料按授权补齐，实际待组批可选，未触碰 smoke 账号。
• 付款账户及收款资料通过必要的受控校验；完整账号不进入聊天、日志、任务或普通接口。
• 实际财务创建批次、非制单人完成所需复核；未复核不能下载制单，真实复核结果有记录。
• 财务下载的 .xls 与用户空白模板结构一致，账号/01 不丢前导零，金额、条目与批准批次一致，失败不产出部分文件；真实文件不提交仓库。
• 网银实际导入和业务核对通过，执行结果与银行回单核验后才登记付款；没有银行结果时仅标“已制单/待付款”。
• 三张退回单逐张有实际重提结果或明确阻断，未完成的不虚报收口；审批完成与最终付款分别计进度。
• AP 修订按独立候选与发布授权处理；业务任务不冒充发布完成，不启用暂停事项。

Out of Scope

不批量关联全员主体，不开发新员工自动关联，不扩工资/公积金/差旅付款，不新增银行直连或自动划款，不放宽 CCB/复核/资料守卫，不扩六个 view_all，不修 58 条、合同阶段 B 或启用 R1，不代发消息、不代替真人业务审批。

Test Plan

• 本轮：原件结构/模板摘要比对、源码流程核对、task validate、Trellis governance、git diff --check；不生成真实制单，不执行业务操作。
• 执行阶段：复用 paymentOrderXls 与 paymentBatches.reimbursement 定向单测，以及真实付款页面对应的合成浏览器用例，检查 reviewed 守卫、导出权限、模板格式、账号文本和失败无部分输出；先发现具体缺口再补测试，不重跑无关完整红项。
• 生产与银行验收：在分别获准后核对数据原值/回读、实际财务身份操作、网银导入反馈及付款回单，未执行项不抵扣为通过。真实导出包含审计写入，不能标为只读。

执行边界

本次技术审查沿用既有“付款复核通过后，财务主动点击下载银行制单，再由授权银行操作人导入网银”的方式；不新增自动下载或自动付款。不重复索取本地技术审查/修复授权；各项生产写入、真实账号解密、导出、付款和发布仍分别获批。