hyb-oa/.trellis/tasks/08-02-corporate-bank-account-payment-order/prd.md

企业银行账户与付款制单

Goal

为财务付款批次提供受控的公司付款账户、员工收款银行标识和企业网银 BIFF8 .xls 制单能力，使付款复核看到的收款账户与实际导出的账户同源，同时避免完整银行账号在普通页面、日志、审计或服务器文件中泄露。

Background

• 用户提供的空白银行制单模板为传统 BIFF8 .xls，包含三个工作表；第一个工作表有 15 列表头，另两个工作表为空。
• 银行导入合同明确要求 .xls，不再把 .xlsx 或 CSV 作为首版候选。
• 模板必填字段为序号、付款方账号、付款方名称、收款方行别代码、收款方账号、收款方名称、金额和用途。
• 当前系统只有员工开户银行自由文本和加密账号；没有规范化银行标识、公司付款账户模型或银行制单导出。
• 当前付款批次快照只冻结收款人姓名、开户银行和脱敏尾号。历史兼容路径可用于展示，但不得用于真实划款制单。
• MVP 采用每个法人主体仅一条启用的公司付款账户；数据模型仍应允许将来存在历史账户或多账户，不把账号直接堆到 LegalEntity。
• 当前公司付款账户与员工工资卡均为中国建设银行；首版生产场景限定为建行本行转账。

Scope

• 建立法人主体维度的受控企业银行账户、规范化银行机构和员工收款资料维护能力。
• 在新建银行付款批次中冻结公司付款账户与员工收款账户，普通页面与 API 仅展示脱敏摘要。
• 为符合条件的已复核建行批次生成确定性的 BIFF8 .xls 制单文件，并记录带原因的逐次审计。
• 保留历史批次和异常场景的人工付款、上传回单与登记完成路径；不连接银行、不自动提交或放款。
• 生产银行资料写入、部署、公网验证和企业网银导入不属于本次代码实施授权范围。

Requirements

R1 公司付款账户

• 新建隶属于法人主体的付款账户资料，至少包含账户名称、加密账号、规范化银行标识、银行显示名称、启用/归档状态及审计字段。
• MVP 对同一法人主体只允许一条启用记录；更换账户不得覆盖历史记录。
• 普通页面默认只展示开户行和脱敏尾号；完整账号不得随列表或普通详情响应返回。
• 公司付款账户不得放入 .env、Feature Flag、普通 JSON 偏好或明文配置值。
• 公司付款账户维护的主要风险是误操作、制单失效、错误公司账户出款和缺少及时知情，不将其描述为改变收款人的欺诈路径，也不为 MVP 增加审批流或双人确认。
• 公司付款账户新增、变更、停用仅授权 finance_mgr 与 admin；当前没有 active finance_mgr 时由 admin 维护。
• finance 只能读取公司付款账户的开户行与脱敏尾号并在授权状态下制单，不得新增、修改、停用或归档付款账户。
• finance、finance_mgr 与 admin 仅可通过独立“查看完整账号”动作填写原因后查看公司付款账户完整账号；每次查看必须先写脱敏审计，普通查询永不返回完整账号。
• hr、manager、ceo 与 system_admin 不获得公司付款账户主数据读取或维护权限；付款批次合法复核人仅可在该批次中看到冻结的付款账户脱敏尾号。admin 的全权限作为受控管理入口保留。
• 新增、变更、停用付款账户除写审计外，还必须即时通知所有 active admin 与 ceo；通知只含法人主体、动作、操作者、时间和脱敏尾号，不含完整账号或密文。

R2 员工收款银行标识

• 员工收款资料增加从受控选项选择的规范化银行标识，不依赖“建设银行/建行/某某分行”等自由文本比较，也不直接保存“本行/他行”这种相对关系。
• 在人员档案提供“收款信息”入口：HR 与 admin 可维护规范化开户银行和账号；finance、finance_mgr 只读，不能编辑。
• 员工本人可查看自己的开户银行和脱敏尾号，但不直接查看完整账号、不自助修改；HR/admin/finance/finance_mgr 默认同样只看脱敏尾号。
• HR、admin、finance 与 finance_mgr 查看员工完整账号时必须通过独立动作填写原因并先写查看审计；现有默认返回完整账号的敏感资料读取路径必须收紧为默认脱敏。
• 首版仅支持规范化标识为 CCB 的公司付款账户和员工收款账户；双方均为建行时生成字符串 01 并保留前导零。
• 任一批次项的收款银行不是建行时，拒绝整份制单并列出对应员工及处理建议；不得生成 02、不得跳过该项、不得生成部分文件。
• employee.bank.manage 继续只授予 HR 与 admin，不得为了财务制单便利把该权限授予 finance、finance_mgr 或 system_admin。
• 真实资金欺诈的关键路径是“修改收款账号 -> 制单导出 -> 向错误受益人付款”；员工收款资料维护与财务制单必须保持角色分离。

R3 可追溯收款快照

• 创建付款批次时直接复制员工已有的银行账号密文进入内部快照，不执行“解密后再加密”。
• 复核页面的脱敏尾号与制单导出的完整账号必须来自同一份批次快照。
• 员工资料在批次创建后发生变化，不得静默改变已复核批次的制单内容。
• 缺少加密账号快照的历史批次一律禁止制单导出，不允许实时回查员工资料兜底，并返回明确错误。
• 普通付款 DTO、AP 页面、日志和审计不得返回密文、完整账号或原始快照。
• 付款批次快照同时冻结所选公司付款账户的身份与脱敏尾号；付款复核页面应显示该脱敏尾号，使复核人能回答“从哪个账户付、付给谁、付多少”。

R4 银行制单导出

• 从符合状态与权限要求的付款批次生成与受控空白原模板视觉和结构一致的 BIFF8 .xls；不得重建一个仅字段相同但丢失列宽、行高、字体、底色、边框或对齐的工作簿。
• 银行制单是推荐的效率工具而非付款完成硬门禁；旧快照、格式异常或人工付款场景仍可通过线下转账、上传回单和登记完成闭环，银行回单继续是银行渠道付款完成的证据门禁。
• 新批次已复核、资料完整且尚未制单时，顶部主动作显示“下载银行制单”；首次制单后主动作切换为“上传银行回单”，重新下载进入“更多”。已经人工付款的用户可直接在回单区域上传，不被制单状态阻断。
• 批次详情显示是否已生成制单；处理进度在未制单时显示“等待财务线下付款并上传回单”，制单后显示“已生成银行制单，等待付款完成并上传回单”。
• 仅 reviewed（待财务付款）批次允许制单；draft、failed、cancelled 与 executed 均禁止制单。
• reviewed 状态允许因文件丢失或本地操作失败重复导出，每次仍须填写原因并独立审计；重新下载前必须明确提示“重新下载不会作废之前的文件。如果上一份已在网银导入，请勿重复提交。”重复导出的业务字段必须来自同一冻结快照，不允许临时覆盖账号、金额或用途。
• executed 后不得重新生成可导入网银的指令文件；付款归档依赖银行回单与付款台账，避免把归档需要和可重复付款指令混为一体。
• 原样保留三个工作表、15 列顺序与表头，以及原模板的列宽、表头/数据行行高、字体、加粗、底色、边框、对齐、换行和单元格内富文本分段；必填表头的首个 * 保持原模板红色，其余文字保持原模板黑色和字体属性。不得把格式伪装成 .xls 扩展名。
• 仓库可提交一份经脱敏检查、仅含空白表头和预格式化空行的受控模板资产；运行时只读取该固定资产，不接受用户上传模板或请求指定路径。模板哈希漂移时制单失败关闭。
• 模板预置数据行不足时，新行必须复制首个数据行的样式和行高；金额列仅覆盖为数值类型与 0.00 格式，不改变其他视觉属性。
• 用途固定为“报销款”；客户方流水号格式为 <付款批次编号>-R<三位行序号>，例如 PB-20260803-001-R001；备注写对应报销单编号；开户行名称取冻结快照；付款凭证号不进入制单。
• 批次项必须使用显式、稳定且带唯一兜底键的排序，禁止依赖数据库自然顺序；同一批次重复导出时每项的行序号和客户流水号必须不变。
• 客户方流水号由单一生成函数负责，并在写文件前校验长度、字符集和批次内唯一性；不允许静默截断或分散内联拼接。首轮验证若证明银行只接受纯数字，应只调整该生成函数与对应合同。
• 付款方账号、收款方账号、联行号、客户流水号、手机号、行别代码和短信通知标志七列必须以字符串单元格写入，禁止数值类型推断；短信通知标志首版写字符串 0。
• 金额首版按数值写入并设置两位小数格式，必须无科学计数法和精度损失；若银行安全导入验证明确拒绝，再改为两位小数字符串。
• 收款人名称、用途与备注中文不得乱码。
• 收款方联行号首版固定留空；首次安全验证使用字符串 01、建行虚构账号和空联行号，覆盖真实生产主场景。跨行 02 与联行号留待支持非建行员工时另立增量任务。
• 导出文件通过响应直接下载，不持久化到服务器存储，不记录原始制单内容；只有脱敏空白模板资产可以进入 Git。
• 完整账号只可通过子进程标准输入传给固定填充器，不得进入命令行参数、环境变量、日志或错误输出；生成的二进制只从标准输出返回，并设置明确的大小上限。
• 导出使用独立权限、必填原因和逐次审计；审计只记录操作人、批次、笔数、合计金额及原因，不记录完整账号。
• 旧快照批次、非银行渠道、缺少付款账户、缺少员工银行标识或账号、公司或员工银行不是建行的批次必须在导出前一次性列出不可制单原因。

R5 本地与人工验证

• 使用合成数据生成 .xls，再用独立解析验证工作表、表头、字段类型、中文、金额和模板视觉签名；至少覆盖列宽、行高、字体、加粗、底色、边框、对齐和表头富文本分段，逐段断言必填星号红色、其余文字黑色。
• 独立解析器及版本必须进入可复现的测试环境，不能依赖某台开发机偶然安装的 xlrd。
• 至少使用 Excel 或 WPS 人工打开一次，确认中文和账号显示。
• 只有企业网银存在明确的“仅校验、不提交”环节时，才允许用完全虚构数据做最终格式确认；否则不进行生产网银试验。

R6 依赖安全

• BIFF8 生成依赖必须在设计阶段确定受支持版本、来源、锁定和完整性校验方式；CI 与生产镜像必须使用同一份带哈希的固定 Python requirements。
• 不得静默接受已知高危依赖告警；若只能使用存在已知解析漏洞的版本，必须证明运行路径只生成、不解析不可信输入，并单独获得风险例外批准。

Test Plan

• 验证 Prisma schema 与迁移，检查单一 active 付款账户约束和存量数据兼容边界。
• 运行公司付款账户、员工敏感资料、付款批次、个人资料和 BIFF8 生成服务的聚焦测试及服务端全量测试。
• 使用合成数据生成 BIFF8 文件，并由固定版本 xlrd 独立读回工作表、表头、字段类型、金额与中文。
• 运行前端 TypeScript 检查和生产构建，核对权限可见性、默认脱敏、带原因 reveal、制单与人工付款动作。
• 执行权限、状态机、迁移、密文流和普通 API DTO 的只读复核，并运行 Trellis、流程、文档、敏感内容与 diff 门禁。
• Excel/WPS 人工打开、生产网银仅校验、公网部署与真实银行资料配置分别作为需额外授权的上线验收，不纳入本地自动化通过声明。

Acceptance Criteria

• 管理入口可为法人主体建立、启用、停用和归档公司付款账户，默认仅显示开户行与脱敏尾号。
• 只有 finance_mgr 与 admin 能维护公司付款账户；finance 只能看脱敏信息和执行授权制单，HR/经理/CEO/system_admin 无主数据访问权。
• finance、finance_mgr 与 admin 查看公司完整账号时必须填写原因并留下成功查看审计，普通列表和详情响应不含完整账号。
• 公司付款账户新增、变更或停用后，active admin 与 CEO 收到不含完整账号的即时通知，并存在脱敏审计。
• 同一法人主体无法同时存在两条启用的付款账户，历史账户不会被覆盖。
• 员工收款资料通过受控选项维护规范化银行标识；公司和员工均为 CCB 时生成字符串 01，任一非建行项导致整批制单失败且不遗漏任何付款项。
• 员工本人可核对自己的开户银行和脱敏尾号；HR/admin 可维护，finance/finance_mgr 只读，所有授权完整账号查看均要求原因并留审计。
• finance、finance_mgr 与 system_admin 均不能修改员工收款账号或银行标识，现有 HR/财务职责分离没有被放宽。
• 新付款批次冻结加密完整账号；普通 API 与页面只返回脱敏信息。
• 修改员工收款资料后，既有批次的复核尾号和制单内容保持不变。
• 付款复核页面同时显示冻结的公司付款账户脱敏尾号、收款人、收款账户尾号和金额。
• 历史批次制单请求被明确拒绝，且不会实时读取当前员工完整账号。
• 未制单批次、已制单批次和人工付款路径均可按既定主动作/次动作继续，制单状态不是上传回单或登记付款完成的硬门禁。
• 批次详情和处理进度能区分“未生成制单”与“已生成制单待回单”，便于观察实际使用覆盖率。
• 授权财务人员填写原因后可下载符合模板的 BIFF8 .xls，下载行为留下脱敏审计。
• Excel 打开生成文件时，原模板列宽、行高、字体、加粗、底色、边框、对齐和换行保持不变；超过三笔时新增行仍复制相同数据行样式。
• 所有必填表头逐段保留原模板富文本：首个星号红色、其余文字黑色；客户流水号使用 批次号-R三位行号，不存在两个无标签 001 连续造成的误读。
• 重新下载前展示重复付款风险原文；每次重导独立记录原因，但不会宣称旧文件已失效。
• 只有 reviewed 批次可制单；同一 reviewed 批次可带新原因重导，其他四种状态均被明确拒绝。
• 批次进入 executed 后无法重新生成银行制单，银行回单与付款台账仍可用于归档核验。
• 七个标识/开关字段读回均为字符串，长账号无精度丢失，01 不丢前导零，短信标志精确为字符串 0。
• 批次项按显式确定性顺序生成；同一冻结批次重复导出时，每张报销的行号、客户流水号和业务内容逐项一致。
• 客户流水号的长度、字符集与唯一性校验失败时制单被明确阻断，不发生截断、替换或自动降级。
• 金额读回值精确到两位小数且无科学计数法；数值/字符串类型最终以安全银行验证结果固化。
• 使用字符串 01、建行合成账号和空联行号完成本地验证；合成非建行项证明整批失败且不会生成部分文件。
• 缺失资料或状态不合格时，页面一次性说明全部阻塞项及处理方式。
• 自动化、本地人工打开和可选网银校验均使用合成数据，不触发真实付款。
• 模板哈希漂移、Python 或固定依赖缺失、填充器失败时返回固定安全错误，stderr、日志和测试证据均不含完整账号或原始 payload，人工付款路径不受影响。

Out of Scope

• 工资代发、供应商付款、跨境付款和多币种制单。
• 银行 API 直连、自动提交付款、自动放款或自动复核。
• 首版支持多个同时启用的公司付款账户。
• 非建行、跨行 02、联行号维护和混合银行批次制单。
• 为历史付款批次补写或回填完整账号快照。
• 将真实账号、含业务数据的模板或生成的制单文件提交到仓库；经检查的脱敏空白模板资产除外。