diff --git a/.trellis/spec/hyb-oa/backend-fastify-prisma.md b/.trellis/spec/hyb-oa/backend-fastify-prisma.md index 865beae4..47aa54c3 100644 --- a/.trellis/spec/hyb-oa/backend-fastify-prisma.md +++ b/.trellis/spec/hyb-oa/backend-fastify-prisma.md @@ -18,6 +18,107 @@ QA script patterns over new abstractions. ## Common Checks +### Receipt OCR Matching Service Boundary + +- Failed evidence persistence is not OCR failure. In a separate bounded transaction, + lock the batch then conditionally update the attachment by version/SHA/processing + and active governance predicates. Persist only allowlisted system_failed, + key_failed or snapshot_failed states; never an exception message or OCR payload. + A failed fallback write returns failure_recording_failed, not a claimed durable + failure. Do not automatically retry cloud calls or overwrite a newer job/void. +- System failure states do not permit ordinary OCR retry or manual proposals. + Administrator recovery requires fixing the prerequisite and a separately + authorized version-bound requeue; no bulk reset or silent cloud retransmission. + +- Bank reimbursement execute calls claimVerifiedReceipts inside the existing + payment transaction after batch/source locks. Receipt existence alone never + permits registration. Existing non-bank and travel-history paths are not + silently converted into the reimbursement BankSlipOCR contract. +- Claims reference the exact approved manual proposal. A unique transaction-alias + table reserves both original and corrected identities against one claim. + Original-reference reuse, concurrent manual/automatic claims and changed current + manual-reviewer roles/participants fail closed; aliases and payment roll back + together. Keep the migration's existing-claim alias backfill. +- GET receipt-readiness uses RepeatableRead READ ONLY with the explicit readOnly + service mode: no FOR UPDATE/SHARE, advisory locks or inserts. It is a UI hint; + execution always repeats the locked validation. Never pass readOnly from user + input into payment execution. + +- Manual persistence uses a separate proposal tied to original verification, SHA + and incremented attachment version. Save and review audit share the transaction; + only id/status/version leave mutation endpoints. Association-ready means + unchanged item association, not independent approval; manual approval does + not itself record payment. Rejected proposals remain immutable history and + manual rejection permits explicit OCR retry. +- Manual endpoints preserve finance management or manager/ceo review permission, + source-department and feature gates. Persistence locks batch, claim advisory, + then attachment, rechecks original and corrected transaction claims, and rejects + stale version/source or self-review. Approval revalidates matching; execute must + still revalidate and claim in the actual payment transaction. + +- Manual proposal preparation in paymentReceiptManualReview is not authorization: + corrections or unavailable OCR require independent review; unchanged exact-match + item association does not. Preserve original evidence, changed-field provenance, + and original transaction fingerprints for persistent duplicate checks. +- Never rewrite original failed/pending transactions into successful evidence, + including conflicting status aliases. Original cross-page duplicate identities + remain blocked even when manual fields change the reference or payer account. + Internal normalized accounts must not be serialized into API responses. +- Independent exception review requires explicit review permission and manager/ceo + business role, outside maker, proposer and every source owner/submitter. Missing + identity fails closed. Pure helper validation does not replace route scope, + transaction/version guards, audit or execute-time revalidation. + +- OCR upload/retry eligibility requires reimbursement plus a pending/failed bank + item. The worker rechecks under the batch lock before reading storage or calling + cloud OCR; out-of-scope queued receipts return to legacy without transmission. + Cash and travel attachment storage is not permission to send them to BankSlipOCR. +- New eligible receipt uploads queue in the attachment/audit transaction; legacy attachments + are not automatically sent to cloud OCR. cron and pg-boss share DB claiming; + the dedicated `payment.receipt.ocr` queue disables automatic retries. +- `POST /payment-batches/:id/receipt-attachments/:attachmentId/ocr-retry` requires + finance management, feature/department and batch-state gates plus an integer + `expectedVersion`. Version/state rejection uses + `payment_batch.receipt_retry_unavailable`, not a generic unexplained failure. + Requeue and audit commit together. Processing is eligible only after 15 minutes; + queued/matched are not eligible. No amount/plaintext or OCR call in this route. +- Attachment GET exposes `ocrState/ocrVersion/ocrStartedAt/ocrRetryAvailable`; + the same eligibility function is used on retry. Eligibility is not permission: + callers still need authorized editable batch context. + +- Persistence: `storeReceiptRecognition(tx, config, { batchId, attachmentId, + sourceSha256, expectedVersion, recognition })` locks batch then attachment, + rejects voided/changed/superseded input, and writes encrypted allowlisted evidence. + Future scheduling/correction must increment the attachment version under the same locks. +- `claimVerifiedReceipts(tx, config, batch)` requires a locked current batch and + the same transaction as payment recording. Revalidate latest evidence and frozen + data, then claim unique transaction fingerprint and item. Never call in a separate + committed transaction or consider it complete HTTP authorization by itself. +- Claim lock namespace is `ADVISORY_LOCK_NAMESPACES.paymentReceiptClaims` (1002). + With Prisma, project an integer from `pg_advisory_xact_lock`; selecting its void + return directly can fail with P2010. Do not remove serialization to hide that failure. +- Different fingerprint key IDs in historical claims block registration until an + explicitly reviewed key migration; key rotation must not defeat deduplication. + DB validation: `RUN_ISOLATED_DB_TEST=1 node scripts/qa/test-payment-receipt-db.cjs`. + +- Internal services: `normalizeBankSlip(fields)`, `matchBankSlip(receipt, candidates)` + in paymentReceiptMatching and `recognizePaymentReceipt({ buffer, mimeType, config })` + in paymentReceiptOcr. These helpers are not themselves payment authorization. +- BankSlipOCR keys vary by layout; support known aliases, reject conflicting or + repeated semantic keys as ambiguous, never silently pick the first transaction. + Currency/account/principal matching is per item, not against the batch total. +- Normalize money with strict grouping/precision and integer minor units; preserve + account leading zeroes. Masked accounts and non-final transaction states cannot + establish a match. OCR matching never establishes bank authenticity. +- Process all PDF pages, retain expected/processed counts, and never accept a + partially failed response as a complete receipt. Provider errors are sanitized; + no raw response or public receipt URL. Normalized accounts remain internal + sensitive data, not API/log payloads. +- Unit contracts: paymentReceiptMatching.test.js and paymentReceiptOcr.test.js. + Their passing does not prove persistent duplicate prevention, independent + manual review, source-state revalidation, or execute transaction safety; those + gates require separate database/HTTP acceptance before wiring payment writes. + - `cd server && node --check src/routes/reimbursements.js` - `cd server && node --check src/routes/workflow.js` - `cd server && ./scripts/regression-workflow-actions.sh` diff --git a/.trellis/spec/hyb-oa/frontend-react-vite-design.md b/.trellis/spec/hyb-oa/frontend-react-vite-design.md index 68fd2ece..71a498c7 100644 --- a/.trellis/spec/hyb-oa/frontend-react-vite-design.md +++ b/.trellis/spec/hyb-oa/frontend-react-vite-design.md @@ -1,5 +1,21 @@ # Frontend React / Vite / Design +## Receipt Verification Dialog + +- Reuse the receipt card and existing Dialog/Input/Button patterns. No separate + receipt center. Show original and proposed summaries; account fields remain masked. + Original-file preview keeps its existing authorized path. +- Unchanged association submits page/item only. Corrections submit changed fields + only; never round-trip account masks as bank accounts. Unedited fields are merged + against the server's version-bound original evidence, not a client snapshot. +- Detail query keys include actor/batch/attachment and forward AbortSignal. Disable + background form refetch; explicit refresh clears selections, corrections and reason. + Identity or batch switches close the dialog, and unmounted mutation callbacks must + not refresh another identity's screen. +- Backend canReview is an eligibility projection, not authorization. Hide review + actions when false; actual review still checks role, permission and all participants. + Save/review never call payment execution or upload. + ## Source Of Truth Frontend visual and interaction design uses the installed `frontend-design` diff --git a/.trellis/tasks/09-08-reimbursement-payment-closeout/design.md b/.trellis/tasks/09-08-reimbursement-payment-closeout/design.md index 95b93e67..e176acc6 100644 --- a/.trellis/tasks/09-08-reimbursement-payment-closeout/design.md +++ b/.trellis/tasks/09-08-reimbursement-payment-closeout/design.md @@ -1,4 +1,58 @@ -# 业务闭环方案（规划，未实施） +# 业务闭环方案（分阶段实施，发布状态见执行记录） + +## 2026-09-13 回单核对增量设计 + +### 2026-09-14 人工核验执行细化 + +最终占用实施：PaymentReceiptClaim补具体人工提案外键，另增交易身份别名唯一表，原/新身份均绑定同一个claim及item。自动和人工路径共用事务advisory锁；别名与claim一起回滚，登记前再次检查人工原证据、提案版本、当前审核人角色/权限及全部参与人关系。银行渠道只核银行项，不把现金历史强改为银行。占用服务、execute及UI readiness已接线并完成本地定向验证；不允许通过测试mock绕过业务门禁。整批独立复核及生产验收仍未完成。 + +页面接线：沿既有回单卡打开核验对话框，不新建中心。只读详情返回版本、页数、逐页识别摘要及人工提案摘要，账号始终掩码；原件继续用既有受控预览。默认保留识别字段，只选对应付款明细；更正时仅提交有变化的字段，服务端在当前版本原证据上合并，不让前端回传掩码覆盖完整账号。未知/失败/处理中状态不默认成功，修改内容与复核理由不入普通日志。详情查询绑定当前身份并传AbortSignal，切账号/批次关闭对话框，不共享上一身份数据。页面操作不调用execute。 + +持久化顺序：新增独立人工提案表，绑定原verification、附件SHA和递增版本，原证据不覆盖。保存更正为pending_review；仅消歧为association_ready，不冒充独立审核通过。复核只能处理当前版本pending_review，拒绝为rejected、批准为approved；更正内容整包加密，API仅安全摘要。保存与决定均与审计同事务，审核前重建匹配并检查当前交易占用。此表不是paid或claim凭证，后续execute需重新核版本、提案和原/新指纹。新增迁移只在一次性数据库验证；生产不执行，存在提案后不得删表回退，前向修复为默认。 + +execute接线的硬约束：人工提案先获批不等于已占用银行交易；两个批次先后核验通过仍须在登记时串行化重查。若更正了可识别的原付款账号/参考，最终登记除保存新指纹外还需持久保留原身份的唯一占用关系，不能只在提案时查一次原claim，否则以后使用原参考的另一回单可能绕过重复检测。最终claim须关联具体人工提案版本/批准记录，不仅引用原OCR结果。此部分已通过具体提案外键及交易身份别名实现，并验证登记事务回滚与自动/人工竞争；不代表生产已启用。 + +先实现内部人工提案校验，不先开付款旁路。输入为服务端读取的原识别证据、冻结候选以及逐页人工字段和明细选择；页数完整、每页唯一明细、交易身份唯一，金额/币种/完整账号仍重新精确匹配。只做同额消歧且未改识别事实的关联不增加日常审批；任何字段更正或OCR不可用均进入独立复核。原证据的明确失败/处理中不能由人工改成成功；状态别名冲突中出现失败/处理中也保留否决线索。 + +人工提案保留原证据引用及规范化字段来源，内部敏感结果必须加密后落库，不能直接序列化为API响应。纯函数结果不构成授权或付款凭证；后续事务接口须校验当前附件版本/SHA、审批角色与非经办/非申请人身份，审计与提案同事务落库。未接这些接口和前端前，execute不接半成品门禁，不部署。 + +此节为已采纳方向的技术拆解，未改变运行时。旧制单与布局内容作为历史阶段保留；不把旧“未实施”标题当成当前全部功能状态。 + +### 接入与边界 + +2026-09-14接线更新：新上传与附件记录同事务置queued，启动路径在jobsEnabled下分别接cron/pgboss独立回单tick；历史legacy不自动处理。显式重试采用expectedVersion CAS（批次→附件锁），已排队/已匹配不重排，processing达到15分钟或legacy/ocr_failed/needs_review才可重试，递增版本使旧结果立即失效并写审计。读取接口投影状态/版本/开始时间和同源重试资格，不返回规范化账号；PC/手机沿原回单卡片展示及5秒有界到终态轮询。该段替代下方历史“未接线”描述，不表示人工核验或execute守卫已经接入。 + +后台单次执行器采用数据库queued/processing状态及版本化领取，既有附件默认legacy不自动重识别；claim在短事务内完成，文件读取和外调在事务外，结果另起事务核版本。进程中断留下processing供后续明确重试，不能在不知道腾讯是否已处理时无限自动重传。最终cron/pgboss只作为唤醒机制，数据库领取是共同排他事实源；调度与上传入队尚未接线。 + +- 复用paymentBatches回单上传/预览/作废/execute入口及现有权限、部门范围、制单人和复核人分离规则，不新建回单中心。 +- 专用BankSlipOCR适配，不调用发票落库/绑定/归档业务。复用腾讯SDK配置与有界后台作业机制前，先核实现有队列的任务隔离和幂等合同。 +- 官方腾讯SDK确认交易金额/币种/账号/流水/手续费/日期等字段及PDF逐页请求；不承诺所有建行版式都有明确成功状态、置信度或流水。WEBP等已接受文件需安全转换或标待核验，不将旧上传格式悄悄禁用。 +- 原始文件保持私有；腾讯请求走服务端受控传输，不建公开下载URL。只持久化必要规范化字段，账户加密及交易身份带密钥摘要方案须结合既有加密合同细化；日志只留原因码和请求标识，不保存整个OCR响应。 + +### 核验模型与一致性 + +2026-09-13 持久化实施：PaymentReceiptVerification绑定附件SHA、receipt_ocr_version与页数，规范化白名单字段整包加密；PaymentReceiptMatch按页关联batch item；PaymentReceiptClaim以HMAC(CCB域、付款账号、交易参考)为主键且item唯一。指纹使用现有fieldEncryptionKey并存key ID；若历史claim使用其他key ID则阻断，必须另审密钥轮换迁移，禁止换密钥绕过去重。流水号优先、凭证号为备选，缺失/冲突待核验；这不是银行验真。 + +storeReceiptRecognition由已授权内部调用方在事务内调用，锁批次后锁附件，再核状态/批次关联/SHA/版本；晚到作业不能恢复作废或新版核验。未来重试/人工更正须先在同锁序下递增receipt_ocr_version。claimVerifiedReceipts要求调用方先锁批次，随后固定命名空间1002的事务advisory锁串行化占用，再锁附件；重新解密核验当前冻结付款数据，只接受最新同版本有效完整结果。claim与最终登记必须同事务提交/回滚，数据库双唯一约束为最后保护。 + +迁移为新增三个表及附件默认0版本列，不回填历史paid核验结果、不删除业务资料。回退空的新结构可仅在隔离环境或另批操作下逆向删除；一旦生成证据/claim，生产不允许直接删表或退无门禁旧应用继续登记，需保持写入隔离并前向修复/兼容修订。当前服务未接路由、队列及人工复核，数据库测试通过不代表授权/公网业务链通过。 + +- 文件安全治理与交易核验必须独立；现有governance_status=approved不表示金额/付款已核验。另建核验版本、处理状态、页/交易记录及付款明细关联，不复用附件标签表示业务放行。 +- 区分等待识别、处理中、待核验、匹配、不符、识别失败；多页完整性、页内交易数量及未知格式均显式处理。晚到作业需比对版本和作废状态，不复活过期证据。 +- 金额用精确十进制或最小货币单位比较；不合并同人多单。账户身份和交易币种/本金为必要证据，编号和日期用于消歧但不能覆盖硬性不符。 +- 重复交易以银行/付款账户/交易身份建立持久化占用和事务约束；哈希相同不足以判断全部重复，换文件/重传也不能重复登记。同额歧义进入人工关联而非按列表顺序猜。 +- 上传和OCR不写paid。execute在现有锁/事务边界重新核有效证据、匹配版本、来源单状态/金额、重复交易占用，再允许现有登记流程；前端禁用不代替后端守卫。 +- 人工更正保留字段来源和历史；确需OCR故障例外时采用独立非经办复核，不免除明确不符/重复/失败交易约束。具体接口/权限与数据约束在实施前补齐，不能先发布可绕过的临时入口。 + +### 历史与发布 + +已executed/已付款不重开、不自动回填“已核验”。尚未登记的旧批次不能仅因旧附件存在绕过新门禁，需适用新核验或明确受控人工核验。迁移采用附加结构，不删除原件或改历史金额。 + +本增量会增加登记安全门：旧镜像可能忽略核验结果，回退不能只以schema兼容判安全。发布前必须冻结新候选、核备份/迁移/回退策略；已产生核验数据后禁止未经评估直接退旧版继续登记。 + +### 已读取的外部依据与自限 + +2026-09-13腾讯云官方Python SDK：ocr/v20181119/ocr_client.py的BankSlipOCR及models.py的BankSlipOCRRequest/Response。支持银行回单字段识别和PdfPageNumber逐页请求；它不是银行交易查询或验真接口。链接：https://github.com/TencentCloud/tencentcloud-sdk-python/tree/master/tencentcloud/ocr/v20181119 。未取得可靠建行验真或国内产品详细规则资料，不虚构行业强制规则；真实建行样式与外调效果仍待专门授权验证。 ## 2026-09-11 已批准备注增量 diff --git a/.trellis/tasks/09-08-reimbursement-payment-closeout/implement.md b/.trellis/tasks/09-08-reimbursement-payment-closeout/implement.md index 4e1bc834..b31db4ac 100644 --- a/.trellis/tasks/09-08-reimbursement-payment-closeout/implement.md +++ b/.trellis/tasks/09-08-reimbursement-payment-closeout/implement.md @@ -1,5 +1,275 @@ # 执行顺序（本地技术审查/修复已批准，真实业务动作另批） +## 2026-09-15 本地提交授权 + +用户对33路径一笔本地提交明确回复“是”。提交前实际HEAD为229867f5，真实暂存区为空，R3清单33份中仅本implement.md有已披露的复核/样本/发布准备记录差异，其余32份内容与冻结摘要一致。只按R3 manifest.files逐路径暂存；排除的09-04两份文档及统一审批中心文档不纳入，不提交artifacts或workspace。此次授权不包含推送、部署、归档或更改分支；实际提交SHA以git回执为准，不预先声称成功。 + +## 2026-09-14 提交清单与发布执行方案（待授权） + +再次核对R3后：仅本implement.md因外部复核结论、生产只读/样本记录增加而不同；其余32份冻结文件零漂移。产品代码仍为已独立审过的R3，不因事实记录更新冒称源码重验。本轮未再次访问生产、发送OCR、提交或推送。 + +### 提交合同 + +建议一笔：fix: 增加回单核对与付款登记门禁（09-08-reimbursement-payment-closeout）。 + +范围严格采用R3 manifest.files的33个路径：2份模块spec、当前task的prd/design/implement、5份client文件、隔离DB脚本、3份附加迁移及schema、3份常量/原因文件（含服务端夹具）、job接线与worker、付款路由、5份服务和相关后端测试。精确名单以manifest为准，implement使用本次事实记录更新版；实际提交前再次逐路径核对，禁止git add .。 + +排除09-04的design.md/implement.md及docs/需求-统一审批中心规约.md；artifacts内原件检查工具、发布包和日志不混入源码提交；workspace日志不提交。不得根据detached HEAD自动切分支、改远端、amend或归档任务。用户批准提交后只提交，不默认推送/部署；提交完成记录实际SHA及相对R3仅文档差异。 + +### 发布门禁与验证步骤 + +1. 提交后若另获推送/发布授权，固定实际候选SHA、树和三份迁移清单；已有生产版本229867f5和元数据只是观察时事实，发布前重查版本/迁移/磁盘/备份时点与完整性/独立回滚镜像，不沿用旧容量或例外。使用existing数据模式，不跑初始化seed。 +2. 未决事项逐项交代：生产密钥高熵来源未有生成记录；一份真实逐笔单页样本成功，不证明多笔/汇总模型；当前无reviewed/failed报销批次，不证明未来人工例外一定有合格复核人；真实JWT浏览器DB同链未测。不得把单页通过描述成全面生产验收。若当前使用情形必须依赖未验证的模型或没有合格例外复核人，暂停相应上线决定，不靠默认放行。 +3. 部署动作会执行已审附加迁移，并在应用启动时创建/调度payment.receipt.ocr队列；这些不是只读检查，必须包含在明确发布授权中。若生产版本或迁移前提变化，停止重新核对，不盲目应用旧候选。 +4. 上线后首先验公网ready/build、容器健康、迁移成功；受控只读核验pgboss队列/调度已注册及周期任务完成记录/失败统计，跨至少两个已配置周期观察。空队列成功tick只能证明调度及空轮询可用，不能说真实回单已消费。无允许的排队回单时不伪造paid或自动重排旧附件；真实端到端任务需另获明确样本/云调用与测试写入授权，禁止以财务实际付款探路。 +5. 执行端检查桌面/手机已构建页面、失败状态提示和权限拒绝；不要求员工做软件回归。没有对生产附件操作的授权不上传、作废、人工复核或登记付款。单元/合成HTTP/browser证据如实复用，不冒充生产真实认证链。 +6. 发现新队列启动失败、迁移失败、健康异常或错误增加即停止继续放行。先冻结进一步业务动作、保存脱敏故障证据，再按独立授权处理恢复。全局JOBS_ENABLED会影响其他任务，不作为无条件回退开关；不删除claim/alias/人工证据，不降级为仅附件存在即可登记。旧镜像忽略门禁，不能自动以镜像回退宣称安全恢复。 + +### 人工例外的人员安排 + +按实际批次列制单人、提案人、所有来源owner/submitter，再从在职且具manager/ceo角色和payment.batch.review权限者排除这些人。不得把普通付款复核人直接视为回单例外复核人；本人报销且仅本人持CEO时可能无人合格。无人合格即报告业务阻断，由用户另行决定职责安排，不加通配、不摘审批角色、不自动改账号关系。当前无需让任何员工提前操作或等待测试。 + +完成状态：提交/发布方案已准备，R3内容复核通过，真实一份逐笔样本匹配通过；提交、推送、部署和上线消费验收均尚未完成。 + +## 2026-09-14 一份历史已付款回单受控样本 + +用户明确授权一份已付款历史回单、最多一页一次腾讯调用，仅回传状态与匹配结论。选择此前已确认的历史单笔批次及报销，对象须唯一、executed/paid、附件approved且未归档，生产版本仍229867f5；不扩大搜索其他原件。先在RepeatableRead READ ONLY事务读取必要的冻结快照/原单金额及附件引用，退出事务后在生产容器内存读原件并核大小/SHA/单页，解密冻结账号只用于内存精确比较，不回传账号或金额。 + +实际2026-09-14T13:58:05.284Z完成，externalCalls=1，使用R3冻结matching源码（SHA256 9a1a42d0ec5a9a60ce7de1a58f1ef505e88526d0515e4a854fd617c2107d5fb8）在内存执行：normalizedTransactionStatus=success；amount/currency/payerAccount/payeeAccount/reference均可解析，normalizationIssues=[]，matchStatus=matched，matchReasons=[]，receiptMatchesSourceAmount=true。原件及原响应未保存到开发机或新文件，未写paid/claim/附件状态，未新增OCR重试。 + +证据artifacts/qa-layout/receipt-release-preconditions/sample-result.json；受控脚本check-sample.mjs只留安全结果，传输/执行结果不明时明确UNKNOWN_DO_NOT_RETRY，不自动重发。该样本证明当前冻结匹配器适配这一份真实单页逐笔回单，不证明多笔批次/汇总回单模型，不能称银行验真或到账证明；也不证明新worker在生产消费，因为它未部署。 + +发布前剩余：多笔形态如需宣称支持需另取授权样本；高熵密钥来源及真实JWT浏览器DB同链仍未验证，例外独立复核人须按实际来源/提案人判定。当前无待登记reviewed/failed批次，不伪造真人付款来验。未提交/推送/部署、不覆盖R3包；提交范围与发布/上线队列验证仍另行授权。 + +## 2026-09-14 发布前受控元数据检查 + +用户“执行”后按已说明边界开展一次生产只读元数据检查；未发送真实回单、未读账号/原件、未改配置或业务数据，不执行部署。使用既有SSH别名和systemd Compose身份，运行内存脚本；数据库RepeatableRead READ ONLY、statement_timeout10s、有界100条，仅回传聚合资格/配置存在性。证据artifacts/qa-layout/receipt-release-preconditions/result.json，观察时间2026-09-14T13:49:50.438Z。 + +结果PASS_METADATA_ONLY：生产BUILD_SHA仍229867f5fd4223d6efadb543a134696f65095763，OCR_PROVIDER=tencent、JOB_DRIVER=pgboss、JOBS_ENABLED=true，腾讯凭据字段与加密密钥已配置。未输出值，配置存在不证明权限/解密可用或高熵来源。 + +新增paymentReceiptOcrJob.js在线上不存在，符合未部署事实；不能将jobsEnabled说成新回单队列已消费，queueConsumptionTested=false。当前reviewed/failed报销批次0，因此没有本轮待登记对象可验证例外复核人，也没有这些批次的legacy附件恢复对象；不据此宣称没有其他未付款/草稿报销或所有报销已完成。历史“唯一待登记批次”记录不沿用。 + +真实回单状态/逐笔或汇总形态仍未核验。既有脱敏历史证据只能证明一次单页OCR调用及金额匹配，不能替代新模型。下一受控样本建议限定已登记历史回单一份、最多一页/一次腾讯调用、仅回传字段存在性与规范化状态及匹配布尔值，不改原件/paid/claim，不留原响应；样本对象和调用范围明确后再执行，不将本轮元数据读取扩大为任意原件读取。密钥生成来源需依据受控生成记录，不通过读取密钥猜测熵。 + +本轮不动R3冻结包、不新增产品源码，未提交/推送/部署。仍需受控样本验证、新版本部署后的队列检查及发布时重新核生产资源/备份/回滚制品；本次结果不构成发布放行。 + +## 2026-09-14 R3独立复核通过与发布说明 + +用户独立只读结论：R3包完整性及内容通过，无阻断项；A1/A2/错误分类成立。适用manifest a415ccde2121d927d3aea77d54cba584ef30bd1cda691a1c4fa2d9d9b4f4b74a、树a972f00b80b78ae6cff66cff154b149e854145ce。记录前重新核对33份工作源码零漂移；本节是复核后发布说明增补，形成task文档差异，冻结sources/README/manifest/证据不覆盖。reviewer未重跑产品测试，不新增独立测试通过计数；内容通过不等于生产已可用或获得发布授权。 + +### 发布说明必须保留的边界 + +- 系统失败禁止普通重试仅适用于已成功落库的system_failed/key_failed/snapshot_failed。若失败状态本身也写不进去，附件可能仍为processing，15分钟后现有超时分支允许人工重试，可能再次发送OCR。超时不证明故障已修复；管理员应先查安全告警与系统前置，财务不要反复重试。此例外不称为自动重试，也不宣称已彻底禁止故障后的云重传。 +- 当前没有管理员重排队路由或脚本。“联系管理员”首先是诊断并修复密钥/快照/数据库等前置，不代表有现成恢复按钮。修复前置后，在批次仍可编辑、有权限及真实数据/云操作授权的条件下，可重新上传同一份原回单作为新附件进行识别；旧失败附件保留作证，不删除、不伪造新回单，也不重新银行付款。重复交易守卫照常执行；如系统判多笔/歧义不能强行绕过。直接数据库重排队只能另批受控方案，不作为现成能力承诺。 +- 全人工录入是「原件留存 + 经办录入 + 独立人员复核」，不是机器核实内容一致，更不是银行验真或到账证明。 +- 批次级横幅/readiness/execute在缺有效证据时仍可能提示人工核验，与系统失败附件卡不一致。以附件系统失败提示为准，不尝试禁用的核验入口；这是已知非阻断体验问题，留原任务后续小修，不另建任务。 +- 批次离开可编辑状态后附件可能保留processing展示；越界queued清理会消耗一个tick。二者作为已知非阻断限制保留，不解释为付款已失败或实际已执行。 + +### 其他发现的明确处置 + +1. 登记事务的employees/employee_roles FOR SHARE：本版暂保留，保障当前资格重验；优化须有并发撤权验证，不能为了缩锁面删除安全保证。 +2. claim RESTRICT与批次item Cascade：当前无删批次路径，本版保留证据保护；未来清理/纠错需专门设计，不顺手改级联删除。 +3. manual_rejected后先重做OCR：本版保留并披露额外云调用，后续在原任务评估可复用原证据的修订提案，不静默改当前状态机。 +4. key_id明文摘要：仅在高熵随机32字节密钥前提下接受设计；生产密钥生成来源仍待受控核实，不能把“代码校验32字节”说成已证明高熵。不读取或展示密钥，不批准轮换。 + +### 发布前顺序与未覆盖 + +先准备明确范围的受控核验方案，另获生产/真实回单/腾讯调用授权后核实：逐笔或汇总回单模型与状态、实际OCR provider和job消费、合格独立复核人、legacy未付回单路径及高熵密钥来源。财务创建、CEO复核批次不代表该CEO可复核本人报销的人工回单例外。真实JWT+浏览器+DB同链、断电/断网仍未测；软件本地验证由执行端承担，不让员工反复探路。 + +随后冻结待提交范围并按授权提交推送，刷新生产版本/迁移/磁盘/备份完整性/独立回滚制品，另批新候选发布；不得沿用旧发布例外。新门禁证据写入后不能以仅退旧镜像恢复安全语义。当前未提交、未推送、未部署、未连生产，仍不是任务整体完成。 + +## 2026-09-14 A2与错误分类实施 + +用户批准按修订合同执行。利用已有varchar状态字段持久记录system_failed/key_failed/snapshot_failed，不新增迁移、不储存异常原文。证据事务失败后另开maxWait5s/timeout10s事务，先锁批次，再按附件id/批次/SHA/版本/processing/未归档/approved进行条件更新（UPDATE取得附件行锁）；批次不可编辑或条件失效返回discarded。回写也失败明确failure_recording_failed，日志保留安全outcome，不宣称已落库。没有把数据库整体故障伪装为可可靠持久化。 + +缺密钥在读文件/云调用前拦住并尝试写key_failed。密钥轮换、业务/银行不支持、身份不全有独立原因码，前后端及夹具同步；batchCandidates显式核密钥，避免通用crypto错误绕过原因映射。系统失败无普通重新识别/人工录入资格；页面指向管理员并阻断登记，不自动重传。管理员恢复须修好前置后另批按版本重排队，本轮不提供无门禁“解除失败”按钮，也未执行生产回填。全人工路径是经办录入与独立人员复核，不是机器核实原件内容。 + +验证：后端8文件412/412；隔离Postgres及HTTP36项通过并清理，新增缺密钥零文件/云调用、真实SQL除零导致证据事务中止后独立事务持久写system_failed。job单测新增安全分类、回写失败及旧版本条件不命中。测试覆盖不等于实际断网/断电实验；尚未验证真实生产worker及真实回单状态。前端最终构建与新增双端错误提示验收进行中，结果在交审包记录，不提前宣称通过。 + +最终前端build/typecheck通过（PWA115）；桌面1440/手机390共16项浏览器通过、零重试，含三类系统失败无重传/无核验/无付款动作及原人工关联更正/复核/OCR重试回归。预览已停止。严格原因码检查发现动态查表无法静态登记，改为四个字面量分支后重验，不把脚本退出0误认JSON pass=false通过。R3入口artifacts/qa-layout/receipt-verification-review-20260914-r3/README.md；旧包不覆盖，未提交/推送/部署。最终路由映射改为等价静态分支后重跑八文件；DB36证据来自该机械调整之前，其事务/job输入未变化，明确复用，不新增DB通过计数。 + +## 2026-09-14 外部六项复核归属与后续修订合同 + +收到用户只读内容复核：A1发送范围、A2落库失败悬挂为阻断，其余六项为建议及未覆盖项。现场以SHA核对：被描述的7处漂移精确对应原manifest afc15486f000f6edac6724b313a55734a914474527a49455a632d57de4c42929、树5f58dc07f8b2e1d127f7fe3ca5d0561201532d67；R2 manifest 214be14fed3e1c0588f7b60e8450c656237e2487424e1096a618849fe9e2f762、树e1a9c52f40a421c2952ff4a7e53ee90483ea4871当时33份源码零漂移。不能根据目录称呼/mtime把这份结论错绑R2，也不把R2自检当外部通过。此记录写入后工作树文档自然不同于R2，旧包均不覆盖。 + +A1本地修复与402/34验证仍成立，新增范围闸待独立内容复核。A2确认尚未修复：持久化事务异常会留下processing，仅返回persistence_failed，不具备持久的失败分类。本次只核验审查对象并细化处理合同，没有宣称新增代码或测试通过；不为了目录改名生成无代码变化的R3。 + +下一修订顺序： +1. 在原证据事务回滚后，以独立有界事务、批次→附件锁和版本/SHA/processing条件写安全失败分类；晚到失败不覆盖重试、作废、已完成或人工结果。数据库整体不可用时不能保证回写，输出安全失败告警并明确回写未完成，不返回已持久化成功。 +2. 系统/密钥/银行快照问题与OCR识别失败分开；识别失败可以人工例外，系统失败引导管理员，不把无证据的失败伪装为可直接人工核验。不得自动循环发送腾讯，修复系统前不能用“重新识别”掩盖故障。 +3. 为密钥不可用/轮换、银行或业务不支持、参与身份缺失补独立原因解释，前后端与原因码夹具同步；保留匹配问题的原通用提示。 +4. 补持久化抛错、回写抛错、晚到旧版本、作废竞争、错误分类和零重传测试；实际数据库故障注入及页面失败提示验证后冻结R3，提供相对R2及原包的追溯，不继承旧包审查通过。 + +其他备注处置：HR行锁不能在无并发替代方案下直接删除，保留登记时当前资格保证；RESTRICT是证据保护，不改为级联删除，未来删批次另审；人工否决后重发OCR作为后续体验项记录，不顺带改状态机；密钥高熵来源在发布前受控核验，不读取或展示密钥；全人工例外必须描述为“原件留存、经办录入与独立人员复核”，不是机器验证内容一致、银行验真或到账证明。 + +外部未覆盖项继续保留：真实逐笔/汇总回单形态与状态、运行中worker、legacy未付回单恢复、合格例外复核人、真实JWT浏览器DB同链。不能将曾成功调用腾讯或本金字段匹配扩成完整真实回单模型已验证。生产/云读取、角色更改、提交推送及部署仍未执行。 + +## 2026-09-14 交审后主会话发现：OCR发送范围 + +用户批准继续既定范围。六项主会话检查发现上传统一queued，retry及worker没有银行报销范围门，非银行/历史差旅回单可能在付款守卫拒绝前已发送云端。这是本地源码路径发现，未证明生产发生外传；原冻结包不改，包完整性PASS不覆盖此行为。 + +修正范围：上传仅待登记银行报销入队；retry同样限制；worker在批次锁内重查，不合范围的旧queued恢复legacy，不读文件、不调用云端。保留现金/差旅附件保存与既有付款路径。补上传/retry/worker反例及银行正例，定向回归后重新提供增量交审证据；不改角色、迁移或生产配置。 + +最终验证：八文件402/402同轮通过；真实一次性Postgres及HTTP34项通过，新增现金/差旅/已登记项的worker零读取零云调用检查，清理完成。语法、diff及Trellis治理通过。上传/查询响应也同步关闭非范围重试资格。前端源码没改，原16项浏览器与build只作为复用证据，本轮未重跑；真实JWT浏览器DB同链仍未完成。 + +执行命令：server下沿上一轮八文件npm test命令（使用既有PAYMENT_ORDER_PYTHON_BIN）；根目录RUN_ISOLATED_DB_TEST=1 node scripts/qa/test-payment-receipt-db.cjs。首轮定向131/131及中途DB31项为过程记录，最终402/34取代，不相加。原包不覆盖；R2交审入口artifacts/qa-layout/receipt-verification-review-20260914-r2/README.md，含整批及相对原包的增量补丁、脱敏单测日志和隔离DB回执。整批独立内容审查、提交推送和受控生产核验仍待完成。 + +## 2026-09-14 整批交审准备 + +用户同意下一步，继续本地交审与发布前提准备；不是生产访问、真实回单发送、迁移或发布授权。官方task指针仍为本09-08任务，注入的09-04流程状态不改变执行合同。 + +交审包入口：artifacts/qa-layout/receipt-verification-review-20260914/README.md。以当前HEAD为基线，冻结本任务tracked及新增文件的补丁、逐文件摘要与重放树；排除09-04的design/implement及统一审批中心文档。使用临时index，不改变真实暂存区、HEAD、远端，不生成提交。包内不复制真实票据、OCR响应或银行资料。 + +本轮仅修正文档当前状态，不修改产品源码，不重复计入上一轮398/31/16项验证。inline模式下不派实现/检查代理，整批独立复核标为待外部只读复核，不以主会话准备材料代替独立结论。交审重点和发布前受控检查见包内README；先交审，发现项闭合后再申请有明确范围的生产核验，最后另批候选发布。 + +## 2026-09-14 最终输入验证与交审边界 + +本节更新下列历史阶段的“尚未接线/待重跑”状态，不抹去中间失败及分轮记录。最终银行候选过滤只处理银行项；补现金/银行混合历史回归，现金项不要求银行快照或占用。 + +- 后端八文件同轮398/398通过：付款路由119、匹配40、OCR9、核验证据20、人工核验39、OCR任务8、pgboss3、错误原因160。沿用既有BIFF8 Python环境，没有新增云调用。 +- 一次性真实Postgres与真实Fastify HTTP共31项通过，含提案、独立复核、只读资格检查、登记、重复拦截、来源金额变化全事务回滚以及混合渠道；容器和临时数据清理完成。认证是合成actor夹具，不是正式JWT登录。 +- 最终前端build（含typecheck）通过，PWA115项；最终构建浏览器16/16同轮通过、零重试，覆盖桌面/窄屏核验及登记状态。浏览器API/auth为mock，不将它和另一组真实DB HTTP证据合称真实登录浏览器全链。 +- 最终浏览器输出为artifacts/qa-layout/receipt-execution-gate-final-ui；本轮自有预览进程已停止。Prisma、语法、严格原因码、process baseline、Trellis治理及diff检查通过；源码输入未变的检查复用，不增加一次通过计数。 + +交审重点：整个回单增量的角色/参与人隔离、原证据不可覆盖、异步版本竞争、原/新交易身份占用、最终付款事务、掩码与密文边界、双端动作及新增迁移兼容性。既有局部复核不能替代整批独立只读复核；当前inline主会话自检完成，独立复核仍待完成，不宣称已放行。 + +发布前仍需另批受控核验真实回单交易状态、运行中的OCR/job配置及例外可用的独立复核人，再刷新生产版本/迁移/磁盘/备份/独立回滚制品证据。真实样本不能自动匹配且无合格独立复核人时，应报告业务阻断，不能改为通配或本人批准。已有paid历史不重开；占用/别名/人工证据写入后旧应用不识别新门禁，不得声称只退镜像即可安全回退。 + +| 代码 | 发布 | 业务验收 | 等谁 | +| --- | --- | --- | --- | +| 自动/人工核验到付款登记已接通，本地定向验证通过 | 未提交、未推送、未部署，生产迁移未执行 | 合成隔离链通过；新增门禁尚无生产验收，不替代既有真实付款事实 | 整批独立只读复核；生产/云核验及发布另行授权 | + +## 2026-09-14 付款登记最终门禁与交易别名占用 + +已接execute：仅银行渠道报销项消费有效OCR/人工证据；保持原批次复核、来源行锁、金额/状态检查和事务边界。补PaymentReceiptClaim.manual_proposal_id与原/新交易身份唯一别名表，同namespace1002锁串行化；最终登记、claim、别名同事务。人工更正的原参考也被占用，另一文件/批次换回原参考不能复用；审核人当前在职/角色/复核权限和所有来源owner/submitter再次验证。不改变既有非银行/差旅历史处理，不重开已付款；新增migration只在一次性DB验证，生产未执行。 + +新增只读receipt-readiness，以RepeatableRead无行锁/无claim写入重新计算回单资格；前端绑定身份、批次和附件版本/状态，查询成功ready才显示登记动作，加载/错误/未匹配均不放行，可重新核对或查看详情。它不是付款授权，execute仍加锁重验。已登记批次不显示“尚未登记”或“当前渠道不需银行回单”等矛盾说明。 + +后端8文件397/397通过；其中原正例因没有核验证据首轮7项失败，补明确verifiedReceipt合成冻结快照和真实纯匹配服务生成的证据，未mock最终claim放行；另补无证据、旧版本、错金额、作废、重复、只读readiness零占用和实际execute占用用例。旧差旅历史不并入新报销OCR规则。Prisma validate/generate、语法和diff通过。 + +真实一次性Postgres30项通过，包含新增原/新别名原子回滚、双身份唯一及幂等、当前角色/参与人变更拒绝、自动与人工并发仅一个claim。新增真实Fastify路由+真实DB链：提交人工核验→ready=false/execute409→独立复核→只读ready=true零占用→execute写paid及具体提案claim→重放409；来源金额变化使claim/alias/付款整体回滚。身份为显式合成actor fixture，不冒充正式JWT登录；邮件/IM/ERP全关闭，无云调用、无生产访问，容器/tmpfs已清理。 + +测试过程保留：首轮HTTP集成夹具把featureFlag.flag_key写成key，验证失败后修正；随后一次Docker子命令失败未定位（原输出只有行号），补安全operation/exit诊断及“容器已不存在时不覆盖原异常”的清理处理后完整重跑30项通过，不把未知原因说成已定位。DB脚本出口只有安全结果，没有原票据/账号/原始payload。 + +浏览器第一轮12/12通过（1440/390未核验不得登记、人工关联/更正、独立复核、重试，加非银行路径与查询失败），API/auth为mock，真实DB HTTP另行验证，不宣称同一浏览器完整真实JWT链。最终文案后需以最后构建再跑对应浏览器集合。整个OCR增量仍待独立只读复核及发布前受控样本/运行前提验证；真实样本交易状态值未在本轮读取，不假定都能自动匹配，缺独立合格复核人的例外不得靠通配自审。未提交/推送/部署，不沿用旧发布授权。 + +## 2026-09-14 核验详情与双端操作页面接入 + +新增GET manual-verification，沿既有登录/批次读取/功能和来源部门守卫，RepeatableRead只读事务内核附件版本/SHA；只返回规范化摘要、掩码账号、提案更正字段与说明，不返回密文包/原响应/完整账号。canReview由同一独立复核规则按全部来源参与人计算，仍非写入授权。保存支持只提交字段差异，服务端从绑定原证据补齐其他字段；不让客户端回传掩码账号覆盖真实账号。 + +沿回单卡“核验详情”打开既有Dialog风格组件，按页展示原识别和人工结果。仅选对应明细不重填字段和理由；更正只提交非空改动字段并要求说明；原状态不明不默认成功。独立审批人查看更正并复核，不合格账号只见等待说明。详情身份/批次/附件query key加signal，关闭后台表单刷新；切身份/批次关闭，卸载后的变更回调不刷新新身份页面。上传/在线查看/下载保留，人工保存/复核均零execute请求。未使用新视觉体系，沿现有组件和样式。 + +验证：8文件391/391同轮通过，真实隔离Postgres24项通过并清理（新增只读详情事务与掩码检查）；真实DB仍为服务级测试，HTTP为Fastify注入+mockDB。前端初次typecheck因三个未使用参数失败，改用明确_unused参数后最终typecheck通过；build/PWA115项通过，最终固定源码又运行npx vite build后进行浏览器验收。1440/390的仅关联、字段更正、独立复核、OCR失败重试共8/8同轮通过、零重试，保存载荷无账号重填且上传/execute计数为零。测试API/auth为mock，不宣称生产或真实认证整链。 + +浏览器命令：client下E2E_BASE_URL=http://127.0.0.1:4188 npx playwright test tests/e2e/system-action-confirmation.spec.ts --grep '回单人工核验|回单独立复核|回单OCR失败' --workers=1 --retries=0 --reporter=list --output=../artifacts/qa-layout/receipt-manual-detail-ui。server八文件联合命令同上一节并新增断言到现有路由文件。根目录RUN_ISOLATED_DB_TEST=1 node scripts/qa/test-payment-receipt-db.cjs。diff与Trellis治理通过；旧punycode/Browserslist/NO_COLOR警告未扩修。 + +仍未完成：execute最终事务消费自动/人工证据、人工更正前后交易身份持久唯一占用、具体提案关联、来源金额/状态及当前审批资格重验，以及真实DB HTTP/双端全链和整个增量独立只读复核。此次inline主执行自检，不继承前轮局部review结论。页面完成不代表最终付款门禁启用；未部署、未提交/推送、未连生产或调用真实OCR，不重开已付款。下一步直接完成登记门禁与整链，不让员工承担软件QA。 + +## 2026-09-14 人工保存与独立复核事务接入 + +实际task指针仍为09-08；注入09-04状态未作为换任务依据。新增PaymentReceiptManualProposal附加迁移及内部持久化服务，绑定原verification、SHA和递增版本，原记录保留。内容及理由加密；只关联未改事实为association_ready、系统关联理由，不要求二次录入或审批；更正为pending_review。原/新指纹和明细已有claim时拒绝，未知密钥轮换拒绝。复核重验原件版本/匹配/占用以及全部source owner/submitter，审批者不得为制单人/提案人/申请参与人；批准manual_approved、拒绝manual_rejected，均不写paid。拒绝记录保留，允许显式OCR重试取得新版本。 + +接入两个受控POST：receipt-attachments/:attachmentId/manual-verification与manual-verification/:proposalId/review；沿既有登录、财务管理或manager/ceo复核角色权限、开关与来源部门守卫，服务内再次锁批次→claim advisory→附件。保存/决定/版本/审计同事务；响应只有id/status/version，未知内部错误不透出原payload。新增四项注册错误说明并前后端对齐。前端只补新状态文案，人工表单/核验详情还未接。 + +验证：8文件387/387同轮通过（付款路由109、manual39、verification19、matching40、job8、OCR9、pgboss3、错误原因160）。一次性Postgres全迁移22项通过、容器/tmpfs清理完成，新增保存/审计回滚、并发版本、加密安全摘要、自审拒绝、独立复核仅一次且不付款、原指纹跨批不可改掉、SHA变化拒绝、拒绝留痕及显式重试、审计FK失败全回滚、同额消歧无需重填。HTTP测试为Fastify注入+模拟DB，真实DB测试为服务层，不冒充真实DB HTTP或浏览器全链。 + +命令：server下PAYMENT_ORDER_PYTHON_BIN=/tmp/hyb-oa-biff8-test-venv/bin/python npm test -- tests/unit/routes/paymentBatches.reimbursement.test.js tests/unit/services/paymentReceiptMatching.test.js tests/unit/services/paymentReceiptOcr.test.js tests/unit/services/paymentReceiptVerification.test.js tests/unit/services/paymentReceiptManualReview.test.js tests/unit/services/paymentReceiptOcrJob.test.js tests/unit/jobs/pgBossJobs.test.js tests/unit/scripts/error-reason-client.test.js；根目录RUN_ISOLATED_DB_TEST=1 node scripts/qa/test-payment-receipt-db.cjs。Prisma validate/generate、node --check、错误原因strict、process baseline、diff通过。旧SDK punycode警告未扩修。 + +最终补验：保存递增与复核读取的整数上界分开，最后有效版本仍可复核、不溢出；付款路由109/109再次通过，真实DB完整重跑23项通过并清理，包含最终整数版本回归。之前387为修正上界前联合运行，未变输入复用、不增加累计通过数。前端npm run typecheck及npm run build（含116项PWA预缓存）通过；Trellis治理和最终diff通过。旧Browserslist提示未扩修。 + +当前主线仍未完成：受控核验详情/人工表单/审核页面、execute对自动/人工证据同事务最终重验与claim、真实DB HTTP和双端整链验收。本轮新增事务/接口待独立只读复核；不继承上一轮纯函数局部复核通过。无生产访问、无真实云调用、无提交/推送/部署；不提前发布门禁，不让员工试错。 + +## 2026-09-14 人工提案内部校验（接口未接入） + +当前继续原09-08，未新建task。新增paymentReceiptManualReview内部服务：完整页数/逐页关联、逐项精确金额币种和完整账号匹配、同额消歧、字段更正来源清单、原交易指纹保留。只关联且事实未变不额外复核；字段更正、缺字段或OCR故障须独立复核。新增身份守卫要求既有manager/ceo业务角色加复核权限，排除制单人、提案人以及所有报销归属人和提交人；未知身份拒绝，admin通配不能代替业务角色或绕过自审。 + +规范化保留失败/处理中别名冲突的否决线索，人工不得改为成功。只读复核发现原跨页重复可改参考后变成普通更正，已补原指纹重复硬阻断，增加改参考/付款账号不能掩盖重复的用例。原指纹返回仅供未来事务内跨批占用检查，不是公开API字段；规范化账号仍限内部加密存储。 + +验证：8文件联合362/362通过；修复复核finding后两文件79/79（manual39、matching40），其余输入未变，不宣称365同轮。运行server下npm test -- tests/unit/services/paymentReceiptManualReview.test.js tests/unit/services/paymentReceiptMatching.test.js；联合付款回归使用已登记PAYMENT_ORDER_PYTHON_BIN。RUN_ISOLATED_DB_TEST=1 node scripts/qa/test-payment-receipt-db.cjs的13项通过并清理完成，无生产/腾讯调用。node --check、git diff --check、Trellis治理通过。数据库检查仍针对既有OCR/claim服务，不冒充人工提案落库测试。 + +独立只读复核补记：本轮manual helper、状态别名否决和对应测试在修复后复核通过，无新增finding。reviewer报告79项内存断言通过，非Vitest，不与主执行79/79累加；未审整个OCR增量/HTTP/事务接线，不以本次局部复核抵扣最终全量复核。 + +未完成：人工提案持久化/版本与SHA/audit事务、跨批原指纹检查、受控接口及前端、execute同事务接线、完整HTTP和双端验收、整个增量独立复核、授权发布。当前不改变线上付款流程、不重开已付款、不提交/推送/部署。下一步按上述顺序接人工提案与复核事务，再接登记门禁，不单独部署此内部helper。 + +## 2026-09-14 上传入队、调度与重试接入 + +已按批准接入新上传receipt_ocr_state=queued（与附件/审计同事务），既有附件仍legacy不自动外发。cron及pgboss均唤醒共同DB领取器；pgboss独立payment.receipt.ocr队列、retryLimit=0，不借发票落库链。上传/重试接口不在HTTP请求内调用腾讯，失败不反复外发；off/mock配置禁止回退真实腾讯调用。 + +重试POST receipt-attachments/:attachmentId/ocr-retry要求财务管理权限、功能/来源部门、可编辑批次、有效未作废回单及expectedVersion。queued/matched不重排，processing满15分钟才允许显式重试，失败/待核验/legacy可重试；同事务递增版本及写重试审计，双击/并发旧版本409。前端从服务端接收资格布尔值和状态/版本，桌面手机保留原布局，展示识别状态和“重新识别”，queued/processing按5秒刷新。不返回OCR明文；重试不上传新文件、不登记付款。 + +验证：7文件联合324/324（付款路由91、verification19、matching40、job8、OCR7、pgboss3、错误原因156）；之后补off/mock禁止真实外调两项，OCR文件9/9，去重总326，不宣称326同轮。Prisma schema前轮已验证且本轮未改；typecheck/build/PWA、错误原因strict、process baseline、Trellis和diff通过。13项一次性Postgres检查通过，含并发重试仅一个版本成功；容器/tmpfs清理完成。本轮无生产访问或真实OCR外调。 + +双端页面：初次dev服务1440用例在login-identifier出现前超时、390通过，不算该轮全绿；使用本轮已通过build的preview，不改断言/超时，1440/390同轮2/2通过、零自动重试。证明识别失败→重试→queued、按钮消失，重试一次且付款登记/上传请求零次；API mock，不冒充真实认证/后端整链。两组证据分别为artifacts/qa-layout/receipt-ocr-retry-ui与receipt-ocr-retry-built-ui。首轮付款测试缺BIFF8解释器导致两例409，恢复已登记解释器配置后原84与新增7路由全部通过；新增重试测试首轮漏认证头，补合成认证头而非放宽鉴权。 + +仍未交付：人工更正/消歧及独立例外、execute接核验claim同事务、核验结果详情与完整HTTP/双端闭环、独立只读复核和授权部署。因此不把当前匹配文案或已接队列当作付款核验门禁已经启用。下一步重点完成异常处理与登记门禁后一次交付，未提交/推送/部署。 + +## 2026-09-13 实施第三段：后台单次识别执行器 + +新增claimReceiptJob/runReceiptOcrOnce，仅处理显式queued、未作废且治理approved、批次reviewed/failed的回单。锁序为批次→附件，SKIP LOCKED使两个worker只能一个取得任务；领取时版本递增，旧匹配立即失效。真实文件读取前限制大小，完整性检查失败不向腾讯发送；无自动重试，返回只含安全状态。结果落库复用批次/附件/版本守卫，晚到结果discarded，持久化异常保留persistence_failed而不伪报OCR成功。 + +迁移新增receipt_ocr_state默认legacy及started_at：既有附件不会自动被外发。新上传入队、cron/pgboss调度、停机超时后的人工重试及页面尚未接入，当前executor未自动启动；processing失败不能静默重传，后续提供显式重试并递增版本。未改变生产或实际上传行为。 + +验证：四文件同轮69/69单测通过；Prisma generate/validate通过。一次性Postgres全迁移及12项检查通过，新增并发worker单次领取/旧证据失效，以及文件错误零外调且失败状态真实持久化；容器/tmpfs已清理。执行命令为server下npm test -- tests/unit/services/paymentReceiptMatching.test.js tests/unit/services/paymentReceiptOcr.test.js tests/unit/services/paymentReceiptVerification.test.js tests/unit/services/paymentReceiptOcrJob.test.js，以及RUN_ISOLATED_DB_TEST=1 node scripts/qa/test-payment-receipt-db.cjs。非HTTP/浏览器验收，无腾讯/生产调用，未独立复核。 + +下一步仍需调度/上传入队和重试、人工核验、execute API接线、错误解释与双端页面，再完整验收；69/12不替代这些未执行项。产品入口不得在人工异常处置未完整时先发布强门禁。当前未提交/部署，用户已批准同范围不重复索取实施授权。 + +## 2026-09-13 实施第二段：持久化与事务占用守卫 + +新增三张核验/页匹配/交易占用表、附件OCR版本列和附加迁移；规范化白名单字段加密存储、无原始响应。storeReceiptRecognition在批次/附件锁内检查版本与SHA；claimVerifiedReceipts在调用方事务内重验附件治理、来源版本、完整页数、冻结金额/账号与持久化匹配指纹，跨批/并发重复用advisory锁和数据库唯一约束共同防护。key ID变化阻断，不允许轮换加密密钥绕过去重；后续密钥迁移另审。 + +最终63项单测（matching40、OCR7、verification16）同轮通过，之前47/62为子集不累加。Prisma generate/validate及服务语法通过；生成使用现有链接node_modules，不修改其他工作树源码。RUN_ISOLATED_DB_TEST=1 node scripts/qa/test-payment-receipt-db.cjs在一次性Postgres16中重放全部迁移，10项检查通过：迁移、事务回滚、幂等、跨批重复、并发重复、作废、晚到作业、SHA变化、版本失效、数据库唯一约束。退出后容器/tmpfs清理完成，无生产访问/云调用/真实文件，非HTTP测试。 + +中间失败保留事实：首轮数据库失败只有通用错误，补安全code/行号后定位Prisma P2010；直接选择pg_advisory_xact_lock的void返回不兼容，将结果投影为整数后数据库通过。未取消锁、增超时或降低断言。随后补版本与过期结果守卫后按最终输入再次跑完整10项，最终结果才作为当前验收。 + +仍待：队列/上传实际接入、权限受控人工核验与独立例外、execute路由同事务调用、错误原因客户端映射、页面、HTTP/双端完整场景与独立只读复核。当前新守卫是未接入产品入口的服务，不能声称线上已启用；未提交/推送/生产迁移/部署，不归档任务。下一步从队列版本化调度和路由接线继续，不重复当前测试通过计数。 + +## 2026-09-13 实施第一段：OCR适配与纯匹配服务 + +用户授权继续完成，沿当前09-08任务实施，无生产访问/外调/写入。本段新增paymentReceiptMatching与paymentReceiptOcr及对应两个单测文件；既有09-04发布记录、根checkout治理改动保留，不混提交。 + +- 字段别名覆盖真实样本返回的“小写金额/币别/付款人账号/收款人账号/凭证号/单据状态”；测试仅用合成字段值。金额严格千分位和两位小数，BigInt最小单位字符串比较，不使用parseFloat或去掉所有非数字来猜值；账号保留前导零，掩码不作完整账号匹配。 +- 别名冲突、重复字段（可能页内多笔）、缺失或歧义保持待核验；同人同额候选不自动选第一条、不比较批次合计。受理/处理中/状态不明不能被认作成功；显式失败/撤销/冲正/退汇返回不匹配。 +- 专用BankSlipOCR适配只在调用时创建客户端，默认有界30秒请求、不自动重试；PDF逐页处理并记录预期/实际页数，后页失败保留失败状态；5MiB原件/7MiB编码/20页为当前技术安全上限，超限进入待核验而非拒收附件。WEBP在内存转换PNG，校验实际格式及像素/多帧限制，不暴露URL或保存原始响应。 +- 纯服务返回的规范化账号/交易参考仅为内部敏感输入，禁止直接作为API响应或日志；匹配结果仅包含状态/候选ID/原因。matched不表示银行验真，也未包含跨批数据库去重、源单复核或交易占用，不可直接替换execute门禁。 + +验证：首次新测试因模块尚不存在而收集失败（不是40项断言已跑红）；实现后matching 40/40，适配加入后两个文件同轮47/47。命令为server下npm test -- tests/unit/services/paymentReceiptMatching.test.js tests/unit/services/paymentReceiptOcr.test.js；两个服务node --check和git diff --check通过。SDK加载产生既有punycode弃用警告，不影响通过；本轮全mock客户端，没有追加真实腾讯调用。 + +尚未完成：持久化schema/迁移和加密/交易去重约束、后台作业及晚到取消、权限受控人工核验、execute事务门禁、页面、隔离数据库/HTTP/浏览器整链及独立复核。当前产品入口尚未接入新服务，没有给线上系统宣称已核回单。下一步从核验持久化/事务合同接续，不重复请求已批准同范围授权；提交/推送/生产迁移/部署仍另批。 + +## 2026-09-13 权限调整后真实回单OCR复验 + +用户告知已添加权限并明确要求重试。对同一限定单页回单执行两次BankSlipOCR：13:32:13Z接口成功，返回17字段，但初版探针仅按“交易金额”读取而未取得金额，故当次金额核对为null，不能算失败金额或全量识别失败；13:32:53Z仅扩展探针金额别名和安全字段名诊断后，识别“小写金额”成功，回单/冻结付款明细/源报销单金额三者一致。返回字段包含付款人账号、收款人账号、币别、凭证号、单据状态等；本次未比较账号值、未解释状态值、未核凭证去重或银行验真，不能把字段名称存在当成内容已核对。 + +两次各1请求，无自动重试，均仅内存读取原件/响应，不保存字段值或原始响应、不改付款记录；旧授权错误回执保留。证据为receipt-ocr-retry-result.json、receipt-ocr-field-diagnostic.json。BankSlipOCR实际字段有版式差异，正式适配须覆盖别名并保留未知/歧义待核验，不能使用初版fields白名单布尔值判定回单缺字段。本轮仅诊断脚本调整，不是产品接入或部署。 + +用户扩大了云权限，成功只说明当前调用获准，不证明新增权限全部必要。建议管理员保留既有发票功能所需权限和本次BankSlipOCR最小授权，移除无关新增权限后再验证；执行端未读取或修改CAM策略。下一步实施字段规范化/交易匹配与安全登记门禁，已有paid历史不重开。 + +## 2026-09-13 获批真实回单OCR试验：授权门阻断 + +用户明确授权读取刚上传的目标付款回单并发送腾讯BankSlipOCR，仅反馈字段/金额匹配，不展示账号/正文、不修改付款记录。沿此前已核单号/批次限定唯一明细与唯一未归档且治理approved的回单；事务RepeatableRead READ ONLY、10秒语句超时、ROLLBACK。真实文件仅在生产进程内存读取，核大小/SHA/PDF签名和单页，未下载到开发机、未保存原始响应。 + +12:02:14Z生产229867f5回读batch=executed、报销=paid且paid_at非空，批次明细金额与源报销金额一致；仅此目标单据，不代表三张重提单已独立核验。回单1页且完整性检查通过，已有腾讯凭据和SDK具备BankSlipOCR方法。 + +调用BankSlipOCR一次，返回AuthFailure.UnauthorizedOperation，试验PAUSED，未取得识别结果、未核回单金额。不能将凭据存在/发票OCR可用解释为回单API已获授权；不自行放宽CAM策略、不换凭据或回退调用其他OCR绕过拒绝，也不重复重试。 + +待腾讯云管理员核查当前调用身份对ocr:BankSlipOCR的最小调用权限及该服务开通状态；本轮只证明服务返回授权错误，不断言是欠费、未开通或某条CAM规则的具体原因。修复后可按同一限定样本复验，不改OA付款流程或历史paid状态。执行脚本try-receipt-ocr.py及receipt-ocr-result.json在既有finance-owner-release证据目录，Python/内嵌Node语法检查通过。没有生产业务写入、部署、云权限写入或自动补审计事件。 + +## 2026-09-13 回单自动核对接续 + +用户采纳“自动识别与匹配、正常不加负担、异常待核验”的方案。本轮复用09-08更新PRD/design/实施清单，官方current已切换并回读；保留09-04未提交发布记录及根checkout其他改动，不混入当前任务。当前只完成规划与接口调查，运行时代码、迁移、测试和部署尚未实施。 + +- [x] 确认当前上传只保存附件及审计、登记要求有效回单存在并比较源单/批次金额；没有回单金额解析或匹配。 +- [x] 固定已批准范围、异常保存/阻断边界、腾讯专用识别与真实数据外发授权边界；明确不以OCR代替验真。 +- [ ] 细化核验数据结构/索引、页级作业幂等、敏感字段加密和交易去重、人工核验资格；先审既有队列/付款事务/加密合同，不复用发票业务写入路径。 +- [ ] 先写金额、账户、币种、交易状态、重复、同额歧义、多页漏页及人工来源的失败测试，再实现纯规范化/匹配服务。 +- [ ] 接入专用Tencent/mock适配与隔离作业、附加迁移和权限受控核验接口，处理作废/重试/晚到作业及并发占用。 +- [ ] execute增加服务端核验门禁；覆盖非本人独立复核、普通理由不能绕过、历史已付款不改及旧未登记批次不豁免。 +- [ ] 现有付款详情显示处理结果与异常入口，正常不多确认；仅维护已有样式，桌面/手机及批次多笔回归。 +- [ ] 本地单测、一次性Postgres/HTTP/浏览器全链与独立只读review；真实OCR与合成结果分别报告。 +- [ ] 更新业务事实源与稳定spec，冻结审核输入；提交/推送/生产迁移/部署另批。真实回单外调及实际付款不在本轮自动操作范围。 + +下一步是数据/匹配合同与失败测试，不继续调整制单备注、不新建任务、不重跑或重复计数上轮519项单测。现有09-04发布验收不作为新回单核验通过证据。 + ## 本轮复核输入与提交准备（未提交） 用户批准整理两笔独立改动的复核/提交方案。基线均为5d8cdf12；01为制单备注5文件，02为UI布局11文件，路径无重叠。仅生成补丁、摘要清单并用临时索引验证顺序合并，不改变实际HEAD/index，不创建commit，不推送或部署。复核入口位于layout副本的artifacts/qa-layout/review-preparation/README.md；临时合并树不是发布候选commit。既有验证按输入不变复用，本轮不新增测试通过计数；UI补跑外层143、网银导入未验证、未独立复核等边界保留。提交前须核对冻结摘要，发布前还需验证合并后的实际候选，不能把单包测试冒充集成验收。 diff --git a/.trellis/tasks/09-08-reimbursement-payment-closeout/prd.md b/.trellis/tasks/09-08-reimbursement-payment-closeout/prd.md index 1b266ffe..b8710e11 100644 --- a/.trellis/tasks/09-08-reimbursement-payment-closeout/prd.md +++ b/.trellis/tasks/09-08-reimbursement-payment-closeout/prd.md @@ -1,5 +1,23 @@ # 报销付款与银行制单业务闭环 +## 2026-09-13 银行回单自动核对（本地实施及定向验证完成，待整批独立复核与发布） + +用户反馈已完成一次付款及回单上传，暂未发现问题，三张退回报销已重提；此为业务反馈，尚未独立回读生产付款登记状态。既有回单仅附件安全/存在性检查，付款登记比较报销金额与冻结批次明细金额，不核验回单内交易。本增量复用本任务，不重开任务、不追改已付款历史。 + +目标：财务上传建行回单，系统自动识别并匹配对应付款明细；正常不重复填写/关联/审批，异常才处理。一个报销单对应一笔转账，批次可多单，PDF可多页多笔。回单识别/匹配不等于银行验真或到账证明，不做银企直连、其他银行适配、部分付款、退款。 + +验收要求： +- 文件通过既有安全检查后保存；内容不匹配或OCR失败不拒收原件、不自动登记付款。作废/隔离回单不得作为有效付款证据。 +- 自动核对每笔交易本金及币种、付款与收款账户，对照组批冻结信息并保留原报销金额一致性守卫；手续费不计入本金。不得只比批次总额或姓名/账号尾号。 +- 成功回单、受理凭证、失败记录分开；状态不明不能推断成功。流水号等交易身份用于重复使用检测，文件哈希仅辅助。 +- 报销编号/日期仅辅助匹配；同人同金额多笔不猜关联，PDF任何页未处理不得宣称整个文件核验完成。 +- 信息唯一匹配后显示“回单信息匹配”，保留财务付款登记动作，不自动改paid、不增加日常二次审批。 +- 识别不清/缺字段/匹配不唯一为待核验；有权人员可查看原件、修正识别字段或选择明细，保留原识别结果、修改来源与审计。不能把人工更正伪装成自动通过。 +- 确认金额/账户不符、失败交易或重复使用必须阻止对应登记；普通理由不可绕过。OCR不可用的人工例外须有记录的独立复核，不能默认放行或借admin通配自审。 +- 本地合成测试覆盖正常、跨批重复、错金额/币种/账户、受理/失败、缺字段、同额歧义、多页漏页、作废、OCR失败及并发登记；执行端承担软件回归。 + +生产迁移、真实回单读取及发送腾讯、生产配置、部署和真实付款另行授权。已有发票OCR授权不自动涵盖银行回单，原件/账号/原始OCR响应不进聊天或测试夹具。 + ## Goal ### 2026-09-12 制单备注与编号解释（自解释方案已批准，增量未部署） diff --git a/client/src/api/errorReasons.ts b/client/src/api/errorReasons.ts index 1f223ba9..6452361c 100644 --- a/client/src/api/errorReasons.ts +++ b/client/src/api/errorReasons.ts @@ -70,6 +70,15 @@ export const ERROR_REASON_MESSAGES: Record = { "payment_batch.invalid_identifier": "付款记录标识已失效，请刷新后重新选择。", "payment_batch.invalid_input": "付款操作内容不完整或格式不正确，请核对页面必填项后重试。", "payment_batch.bank_receipt_required": "银行付款登记前必须上传有效银行回单，请先补充回单。", + "payment_batch.receipt_retry_unavailable": "回单状态已变化或仍在识别，请刷新后查看；处理中超过15分钟仍未完成时可重试。", + "payment_batch.receipt_independent_review_required": "回单人工核验需要独立审批人复核；制单人、核验人及报销归属人或提交人不能自审。", + "payment_batch.receipt_transaction_reused": "回单交易已被使用或存在重复，请核对原回单；不能通过修改参考号重复登记。", + "payment_batch.receipt_manual_state_changed": "回单或核验版本已变化，请刷新后重新查看当前状态。", + "payment_batch.receipt_manual_verification_required": "回单信息尚不能确认与付款一致，请核对全部页、交易状态、金额、币种及收付款账号；不要直接登记付款。", + "payment_batch.receipt_key_unavailable": "回单核验密钥不可用，请联系管理员修复；不要重复识别或登记付款。", + "payment_batch.receipt_key_rotation_required": "回单交易记录使用的密钥版本不一致，请管理员完成受控密钥迁移；人工核验不能绕过。", + "payment_batch.receipt_snapshot_unsupported": "付款业务或银行快照不支持回单核验，请联系管理员核实；不要重复识别。", + "payment_batch.receipt_identity_unresolved": "无法完整确认报销参与人身份，请管理员核实人员关系后再复核；不能自行批准。", "payment_batch.department_unavailable": "当前单据所属部门暂不能使用付款批次，请联系管理员确认处理方式。", "payment_batch.source_not_found": "部分来源单据已不存在或不可用，请刷新后重新选择。", "payment_batch.daily_sequence_exhausted": "今日付款批次编号已用完，请联系管理员处理，勿重复提交。", diff --git a/client/src/api/paymentBatches.ts b/client/src/api/paymentBatches.ts index 27a2fd6c..d129fa7a 100644 --- a/client/src/api/paymentBatches.ts +++ b/client/src/api/paymentBatches.ts @@ -118,6 +118,12 @@ export type PaymentBatchCandidatesResponse = { }; export type PaymentBatchReceiptAttachment = { + ocrState?: "legacy" | "queued" | "processing" | "ocr_failed" | "needs_review" | "matched" + | "pending_review" | "association_ready" | "manual_approved" | "manual_rejected" + | "system_failed" | "key_failed" | "snapshot_failed"; + ocrVersion?: number; + ocrStartedAt?: string | null; + ocrRetryAvailable?: boolean; id: string; originalName: string; mimeType: string; @@ -276,3 +282,65 @@ export async function voidPaymentBatchReceiptAttachment(batchId: string, attachm { method: "POST", body: JSON.stringify({ reason }) }, ); } + +export async function retryPaymentBatchReceiptOcr(batchId: string, attachmentId: string, expectedVersion: number) { + return apiRequestData<{ item: { id: string; ocrState: string; ocrVersion: number } }>( + `/api/payment-batches/${batchId}/receipt-attachments/${attachmentId}/ocr-retry`, + { method: "POST", body: JSON.stringify({ expectedVersion }) }, + ); +} + +export type ReceiptVerificationPage = { + pageNumber: number; + amount: string | null; + currency: string | null; + payerAccountMasked: string | null; + payeeAccountMasked: string | null; + transactionStatus: string | null; + reference: string | null; + itemId?: string; +}; + +export type ReceiptVerificationDetail = { + canReview?: boolean; + version: number; + state: string; + pagesExpected: number; + pages: ReceiptVerificationPage[]; + proposal: null | { + id: string; status: string; proposedBy: string; reviewedBy: string | null; reason: string; + changedFields: { pageNumber: number; fields: string[] }[]; + pages: ReceiptVerificationPage[]; + }; +}; + +export function fetchReceiptVerification(batchId: string, attachmentId: string, signal?: AbortSignal) { + return apiRequestData<{ item: ReceiptVerificationDetail }>( + `/api/payment-batches/${batchId}/receipt-attachments/${attachmentId}/manual-verification`, { signal }, + ); +} + +export function fetchReceiptReadiness(batchId: string, signal?: AbortSignal) { + return apiRequestData<{ item: { ready: boolean } }>( + `/api/payment-batches/${batchId}/receipt-readiness`, { signal }, + ); +} + +export function saveReceiptVerification(batchId: string, attachmentId: string, body: { + expectedVersion: number; reason?: string; + pages: { pageNumber: number; itemId: string; fields?: { Name: string; Value: string }[] }[]; +}) { + return apiRequestData<{ item: { id: string; status: string; version: number } }>( + `/api/payment-batches/${batchId}/receipt-attachments/${attachmentId}/manual-verification`, + { method: "POST", body: JSON.stringify(body) }, + ); +} + +export function reviewReceiptVerification(batchId: string, attachmentId: string, proposalId: string, body: { + expectedVersion: number; decision: "approve" | "reject"; reason: string; +}) { + return apiRequestData<{ item: { id: string; status: string; version: number } }>( + `/api/payment-batches/${batchId}/receipt-attachments/${attachmentId}/manual-verification/${proposalId}/review`, + { method: "POST", body: JSON.stringify(body) }, + ); +} diff --git a/client/src/components/common/PaymentReceiptVerificationDialog.tsx b/client/src/components/common/PaymentReceiptVerificationDialog.tsx new file mode 100644 index 00000000..ff28f18d --- /dev/null +++ b/client/src/components/common/PaymentReceiptVerificationDialog.tsx @@ -0,0 +1,160 @@ +import { useEffect, useRef, useState } from "react"; +import { useMutation, useQuery } from "@tanstack/react-query"; +import { + fetchReceiptVerification, saveReceiptVerification, reviewReceiptVerification, + type ReceiptVerificationPage, +} from "../../api/paymentBatches"; +import { resolveErrorMessage } from "../../lib/resolveErrorMessage"; +import { Dialog, DialogContent, DialogDescription, DialogFooter, DialogHeader, DialogTitle } from "../ui/dialog"; +import { Button } from "../ui/button"; +import { Input } from "../ui/input"; +import { Textarea } from "../ui/textarea"; + +const FIELD_NAMES = ["小写金额", "币别", "付款人账号", "收款人账号", "凭证号", "单据状态"] as const; +const CHANGE_LABELS: Record = { + amount: "金额", currency: "币种", payerAccount: "付款账号", payeeAccount: "收款账号", + reference: "交易参考", transactionStatus: "交易状态", +}; + +function PageFacts({ page }: { page?: ReceiptVerificationPage }) { + return
+
金额：{page?.amount ?? "未识别"} · 币种：{page?.currency ?? "未识别"}
+
付款账号：{page?.payerAccountMasked ?? "未识别"}
+
收款账号：{page?.payeeAccountMasked ?? "未识别"}
+
交易参考：{page?.reference ?? "未识别"}
+
状态：{{ success: "成功", failed: "失败", pending: "受理或处理中" }[page?.transactionStatus ?? ""] ?? "未确认"}
+
; +} + +type Props = { + actorId: string; batchId: string; attachmentId: string; makerId: string | null; + canManage: boolean; canReview: boolean; + items: { id: string; label: string }[]; + onClose: () => void; onChanged: () => void; +}; + +export function PaymentReceiptVerificationDialog(props: Props) { + const mounted = useRef(true); + useEffect(() => { mounted.current = true; return () => { mounted.current = false; }; }, []); + const [selections, setSelections] = useState>({}); + const [editing, setEditing] = useState>({}); + const [changes, setChanges] = useState>>({}); + const [reason, setReason] = useState(""); + const query = useQuery({ + queryKey: ["receipt-verification", props.actorId, props.batchId, props.attachmentId], + queryFn: ({ signal }) => fetchReceiptVerification(props.batchId, props.attachmentId, signal), + enabled: Boolean(props.actorId), staleTime: 0, gcTime: 0, + refetchOnWindowFocus: false, refetchOnReconnect: false, retry: false, + }); + const detail = query.data?.item; + const changed = () => { + if (!mounted.current) return; + props.onChanged(); + props.onClose(); + }; + const save = useMutation({ + mutationFn: () => saveReceiptVerification(props.batchId, props.attachmentId, { + expectedVersion: detail!.version, ...(reason.trim() ? { reason: reason.trim() } : {}), + pages: Array.from({ length: detail!.pagesExpected }, (_unused, index) => { + const pageNumber = index + 1; + const fields = Object.entries(changes[pageNumber] ?? {}).filter(([, value]) => value.trim()) + .map(([Name, Value]) => ({ Name, Value })); + return { pageNumber, itemId: selections[pageNumber] ?? "", ...(fields.length ? { fields } : {}) }; + }), + }), + onSuccess: changed, + }); + const review = useMutation({ + mutationFn: (decision: "approve" | "reject") => reviewReceiptVerification( + props.batchId, props.attachmentId, detail!.proposal!.id, + { expectedVersion: detail!.version, decision, reason: reason.trim() }, + ), + onSuccess: changed, + }); + const busy = save.isPending || review.isPending; + const pageCount = detail && Number.isInteger(detail.pagesExpected) && detail.pagesExpected > 0 && + detail.pagesExpected <= 20 ? detail.pagesExpected : 0; + const editable = props.canManage && detail && ["needs_review", "ocr_failed"].includes(detail.state) && !query.isError; + const reviewable = props.canReview && detail?.canReview === true && detail?.proposal?.status === "pending_review" && + props.actorId !== detail.proposal.proposedBy && props.actorId !== props.makerId && !query.isError; + const complete = pageCount > 0 && Array.from({ length: pageCount }, (_unused, index) => selections[index + 1]).every(Boolean); + const hasCorrections = Object.values(changes).some((fields) => Object.values(fields).some((value) => value.trim())); + const error = query.error ?? save.error ?? review.error; + return { if (!open && !busy) props.onClose(); }}> + + + 回单核验 + 核对原回单与付款明细。账号仅显示掩码；需要核对完整内容时请使用回单“在线查看”。核验不代表银行验真，也不会自动登记付款。 + + {query.isPending ?

正在加载核验信息…

: null} + {error ?
+

{resolveErrorMessage(error)}

+ +
: null} + {detail && !pageCount ?

尚无完整页数，请先重新识别或上传可读取的原回单。

: null} + {Array.from({ length: pageCount }, (_unused, index) => index + 1).map((pageNumber) => { + const original = detail?.pages.find((page) => page.pageNumber === pageNumber); + const proposed = detail?.proposal?.pages.find((page) => page.pageNumber === pageNumber); + return
+

第{pageNumber}页 · 原识别结果

+ + {proposed ?
+

人工核验结果

+ +

对应明细：{props.items.find((item) => item.id === proposed.itemId)?.label ?? "当前明细不可用"}

+

更正字段：{detail?.proposal?.changedFields.find((entry) => entry.pageNumber === pageNumber)?.fields.map((field) => CHANGE_LABELS[field] ?? "字段").join("、") || "未更正，仅关联"}

+
: null} + {editable ? <> + + + {editing[pageNumber] ?
+

只填写要更正的字段，其他字段保留原识别值。更正后需要独立复核。

+ {FIELD_NAMES.map((name) => )} +
: null} + : null} +
; + })} + {detail?.proposal ?

核验说明：{detail.proposal.reason}

: null} + {detail?.proposal?.status === "pending_review" && !reviewable ? +

等待有资格的独立审批人复核；经办人和报销参与人不能自审。

: null} + {editable || reviewable ?