20 KiB
报销付款与银行制单业务闭环
2026-09-15 六项统一收口合同（本轮最新）
用户采纳后续六项并要求一次规划、连续推进，非必要不提问。复用本任务承接报销付款闭环的统一协调，具体实施仍归已有模块task，不创建新总控系统或每个修复一个task。此增量是后续批准范围，历史阶段的未部署描述不代表当前状态。
目标是让员工按正常业务流程独立办完，让系统异常可解释、数据可恢复、交付状态可信；不是以一次提交囊括全部历史技术债。范围：22个活跃task的代码/发布/业务验收/等待项对账；四类报销付款待办与退回通知；数据库+附件+应用配对恢复；10-05错误豁免模块治理；新回单自然消费验收；密钥来源和人工例外职责核实。
共同验收：
- 对账区分代码包含、局部已发布、任务全量验收完成，不因Git祖先关系自动勾完PRD；没有证据标待核，不让过期文字驱动重复开发。
- 待办计数/列表/责任人/动作/处理后消失一致；通知失败不改变审批事实，站内待办不依赖企业微信成功；普通账号与身份切换不串数据。
- 配对恢复在批准的隔离目标使用同一manifest，数据库、附件引用/摘要、应用只读检查均分开报结果；源备份不改，缺失件不可按“可能是测试”自行删除。
- 错误治理先覆盖高频已启用业务操作，每项有注册原因码、客户端提示和行为断言；延期按项/模块说明原因和复验点，不统一改日期。
- 当前已通过的真实单页回单隔离队列证据不重做；生产自然业务出现后执行端只读观察，不制造真实付款、重传历史或要求员工代做软件回归。
- 密钥生成来源目前未知，用户不知道内容/时间/方式；先查非敏感部署证据，查不到如实记录，并列保管/恢复证据风险，不读取值、不查可能含Secret的shell历史、不轮换、不继续追问用户。
默认自主执行本地对账、明确范围内修复、合成验证、文档与证据整理。提交/推送/部署、新生产配置或数据写入、真实原件额外外调、恢复真实备份到具体隔离目标仍按明确范围另批；旧授权不无限继承。将需要批准的操作集中成一次清单，非实质变化不反复确认。等待真实业务或批准不阻塞其他可做模块，也不能伪称全部完成。
2026-09-15 后续收口范围
用户要求自主继续后续本地任务。本轮完成正式认证浏览器验证后，继续修复回单系统失败横幅与卡片引导矛盾，并将现有受控恢复路径写入操作手册。保持现有布局、权限、付款门禁和状态机；不新增管理员一键重排队或自动重传。失败前提由管理员定位修复，另获原件重传授权后由有上传权限的人员重新上传，旧失败证据保留。无法修复快照等前提时停止，不以重上传承诺恢复成功。
验收包括三种系统失败在桌面/手机均不引导不可用的核验详情，不出现普通重试/登记旁路；记录回写失败超时例外、恢复边界与真实队列/复核人待核事实。此范围不授权新的生产配置写入、云调用、提交、推送或部署。
2026-09-15 上线后隔离全链验证增量
用户同意先准备正式登录浏览器全链，复用本任务，不重新部署或让员工测试。已上线8d08d46d不因下述测试准备回退；管理员恢复出口/横幅统一和人员安排仍另按原任务后续阶段实施，本轮不混入产品改动。
验收：一次性Postgres及本地独立存储、随机合成账号/密码/密钥，通过实际auth路由和JWT cookie进入浏览器；同一浏览器上传合成回单，经真实附件存储和job版本状态流程至核对结果，财务明确登记，在同一数据库验证paid、claim及审计。浏览器不得mock付款/auth/readiness/核验业务API，不得直接注入employee或用预签token代替登录。仅外部腾讯响应可替换为明确标识的合成provider边界，不能声称这证明真实云调用。
反例至少包括错金额不得登记、系统保存失败没有重试/人工旁路、账号切换隔离及重复交易拒绝；复用既有单测并逐项区分哪些在浏览器全链覆盖。日志不含随机口令/JWT/完整账号或原payload；关闭邮件/企微/ERP等外部副作用、只监听loopback，测试失败仍清理本轮自有资源。真实票据/腾讯调用/生产写入须另批，不自动读取input或.env里的生产配置。
2026-09-13 银行回单自动核对（本地实施及定向验证完成，待整批独立复核与发布）
用户反馈已完成一次付款及回单上传，暂未发现问题，三张退回报销已重提；此为业务反馈，尚未独立回读生产付款登记状态。既有回单仅附件安全/存在性检查，付款登记比较报销金额与冻结批次明细金额，不核验回单内交易。本增量复用本任务，不重开任务、不追改已付款历史。
目标：财务上传建行回单，系统自动识别并匹配对应付款明细；正常不重复填写/关联/审批，异常才处理。一个报销单对应一笔转账，批次可多单，PDF可多页多笔。回单识别/匹配不等于银行验真或到账证明，不做银企直连、其他银行适配、部分付款、退款。
验收要求：
- 文件通过既有安全检查后保存；内容不匹配或OCR失败不拒收原件、不自动登记付款。作废/隔离回单不得作为有效付款证据。
- 自动核对每笔交易本金及币种、付款与收款账户，对照组批冻结信息并保留原报销金额一致性守卫；手续费不计入本金。不得只比批次总额或姓名/账号尾号。
- 成功回单、受理凭证、失败记录分开；状态不明不能推断成功。流水号等交易身份用于重复使用检测，文件哈希仅辅助。
- 报销编号/日期仅辅助匹配；同人同金额多笔不猜关联，PDF任何页未处理不得宣称整个文件核验完成。
- 信息唯一匹配后显示“回单信息匹配”，保留财务付款登记动作，不自动改paid、不增加日常二次审批。
- 识别不清/缺字段/匹配不唯一为待核验；有权人员可查看原件、修正识别字段或选择明细，保留原识别结果、修改来源与审计。不能把人工更正伪装成自动通过。
- 确认金额/账户不符、失败交易或重复使用必须阻止对应登记；普通理由不可绕过。OCR不可用的人工例外须有记录的独立复核，不能默认放行或借admin通配自审。
- 本地合成测试覆盖正常、跨批重复、错金额/币种/账户、受理/失败、缺字段、同额歧义、多页漏页、作废、OCR失败及并发登记；执行端承担软件回归。
生产迁移、真实回单读取及发送腾讯、生产配置、部署和真实付款另行授权。已有发票OCR授权不自动涵盖银行回单，原件/账号/原始OCR响应不进聊天或测试夹具。
Goal
2026-09-12 制单备注与编号解释（自解释方案已批准，增量未部署）
- 最新确认覆盖此前仅编号方案：用途继续为“报销款”；每行备注为“报销款 ”＋完整报销编号，例如“报销款 BX-20260828-0014”。收款人姓名仍单独来自冻结快照，不在备注重复。这是产品选择，不冒充行业调研结论。增量实施与验证记录归当前09-04任务，不另建task。
- 现有一单一行保持，不按收款人合并转账；同一批次同一收款人的多张单仍逐行对应完整编号。缺少姓名或单号继续整批拒绝，不猜测、不截断。
- 保留BIFF8模板、15列、用途、金额、账号文本、客户流水号、排序、权限/复核/审计与下载行为；不修改历史文件、历史单号、计数器或生产配置，不新增迁移。
- 编号只标识创建顺序，不表示此前单据已经报销/付款。BX当前生成器优先既有序列配置，回退resetPeriod=none；PB按日三位流水，从001起。不能把讨论中的“若按日则0001起”直接改成重置生产BX或将PB扩位；周期变化另行确认。本轮仅解释并保留现状，生产具体BX序列配置未查询。
- 固定空模板未提供备注长度上限；本轮验证完整文字写入/读回，不自造银行限制，不做字符截断。实际网银导入及长备注限制仍未验证。
- 验收：合成收款人与提交人不同、同收款人多单、一单一行、长姓名/编号不丢失、缺失输入拒绝及BIFF8逐列读回；编号单测回归。生产测试账号治理暂停，不并入本轮。
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 守卫、导出权限、模板格式、账号文本和失败无部分输出；先发现具体缺口再补测试，不重跑无关完整红项。
- 生产与银行验收：在分别获准后核对数据原值/回读、实际财务身份操作、网银导入反馈及付款回单，未执行项不抵扣为通过。真实导出包含审计写入，不能标为只读。
执行边界
本次技术审查沿用既有“付款复核通过后，财务主动点击下载银行制单，再由授权银行操作人导入网银”的方式；不新增自动下载或自动付款。不重复索取本地技术审查/修复授权；各项生产写入、真实账号解密、导出、付款和发布仍分别获批。