hyb-oa/docs/报销发票附件规则.md

# 报销、发票与附件规则

本文是 hyb-oa 报销主链路的业务事实源，面向 10 人以下国内科技公司。目标是让员工少选项、财务少核错、管理员少配置。

当前报销、发票、OCR、附件、付款和导出开发以 [需求 - 报销发票 OCR 规约](./需求-报销发票OCR规约.md) 为模块级开发规约；本文保留为报销细则来源。如两者有重复，以新规约整合后的口径为准。首批发票合规以 OCR、查重和财务人工复核为主，自动验真作为后续评估项。

R5 公网验收后确认：正式发票/OCR 上传入口只接受 PDF 发票文件；图片和拍照直传不作为发票入口。附件材料仍可上传图片或 PDF，但必须与发票分离。重复票据、已使用票据和 OCR 失败必须进入可解释终态，不能长期停留在处理中。

## 业务编号（本地候选，尚未线上启用）

面向不足10人的团队，新规则采用“类型前缀＋必要期间＋流水”。报销按月，如 `BX-202609-0001`；付款批次按年，如 `PB-2026-0001`，报销付款与本金还款共用PB。借款、还款申请、采购、盘点及自动项目号分别为JK、HK、CG、PD、PRJ年度号。新固定资产用 `FA-0001` 永久递增，电子资产保留既有EA分类前缀并永久递增。正式合同、员工和外部原始编号不改。

已有单号、草稿、审批、付款材料及资产标签全部保留。切换前尚未编号的采购草稿和历史缺号报销沿用旧规则；采购仍在首次提交时取号。新批次可关联旧号报销，逐项显示来源原号。付款批次编号与实际付款日期分别展示，年中新序列的0001不表示公司当年实际第一笔付款。

四位是最小宽度，超过9999继续扩位。取消或删除会留下空号，不回收已发号码；号码也不等于业务数量或总账凭证号。跨月审批、跨年付款不换号。只有迁移和兼容代码部署、独立复核及切换授权齐备后才受控启用；本地验证不表示现有线上编号已改变。

## 总原则

- PC 与手机功能一致，只允许布局和控件形态不同。
- 普通员工看到的是“添加发票”“上传附件”“提交审批”，不看到“绑定整单”“发票池”“ERP 同步”等内部概念。
- 发票是报销凭证，附件是补充材料，二者不能混用。
- 报销上传采用材料类型先行：PDF 发票走“添加/上传 PDF 发票”入口，支付截图、订单、聊天记录、情况说明等走“上传附件/补充材料”入口，付款回单走财务付款或回单入口，不混成一个万能上传框。
- 已经报销、他人已报销、重复上传的发票不能加入新的报销单。
- 服务端必须强约束，前端只负责友好提示。
- 报销审批必须在 OA 内完成，企业微信只发送提醒和 deeplink，不作为报销审批流或财务附件主库。
- 财务台账 V1 只做付款准备、付款批次、回单留痕、AP 状态、票据/OCR 状态和代账交接摘要；真实付款继续在线下银行或既有财务流程完成，OA 不做银行直连、银行流水自动导入、ERP/总账、凭证生成、自动对账或税务申报。

## 退回后的修改与删除

- 退回单优先直接修改后重新提交，不要求重新录入已有内容。
- 报销人或合法提交人在有删除权限时，可删除草稿及退回单；界面只做一次后果确认，不要求填写理由。审批中、已批准、付款处理中、已付款不能通过此入口删除。
- 从未提交的草稿沿用删除；有流程历史的草稿及退回单删除后从日常列表移除，但保留单据、明细、审批历史、附件及删除审计。旧链接只对原有权人员展示只读历史，不增加读取权限。
- 删除时解除本单有效发票占用，符合条件的票据可用于新单；旧单保留当时关联票据的 PDF 凭证引用及摘要，不跟随新单修改。此前已经释放且缺少关联证据的历史票据不猜测补回。
- 删除不代表撤销付款，也不删除真实发票原件。该能力须随对应候选发布才在生产生效。

## 发票状态

发票主要状态：

- `pending_ocr`：已上传，正在识别。
- `available`：可添加到报销单。
- `bound`：已添加到报销单。
- `ocr_failed`：识别失败，需要重试或人工处理。
- `archived`：已归档，不可添加；若 `archived_reason=used_complete`，视为已报销。

前端展示时使用中文业务表达：

- `pending_ocr`：识别中。
- `available`：可添加。
- `bound`：已添加。
- `ocr_failed`：识别失败。
- `archived`：已归档或已报销。

## 上传与 OCR

- 发票/OCR 上传只允许 PDF 发票文件；图片、拍照直传和 HTML `capture` 入口不作为正式发票上传方式。
- 单个正式发票 PDF 不能超过 7 MiB，每份文件第一页只能包含一张票据；超过限制、多票混贴或不支持的票种在进入报销前返回可理解失败，不进入无限重试。
- PC 票据中心、PC 报销详情、移动报销详情和企业微信 WebView 内的发票入口都必须执行 PDF-only 口径。
- 上传后页面必须显示明确状态，不应长期停留在“上传中”。
- OCR 完成后，添加发票弹窗应自动刷新并尝试添加可用发票。
- OCR 失败、重复、已使用、他人已使用都要显示可理解原因。
- 刷新按钮必须有明显反馈，不能让用户误以为没点中。
- 正式环境不得使用 `OCR_PROVIDER=mock` 处理真实票据；mock 仅用于本地或明确隔离的合成测试。
- 腾讯真实 OCR 统一使用通用票据识别高级版 `RecognizeGeneralInvoice`，当前正式范围仅为住宿 VAT/电子普通发票和电子发票（铁路电子客票）。铁路电子客票不伪造发票代码或销售方；无代码票据仅在已知安全票种内启用发票号码查重。
- 腾讯 OCR 持久化结果只保留票种、发票号码/代码、日期、金额、购销方和 PDF 传输模式等业务必需字段；不得保存腾讯原始响应、乘车人姓名、证件号、完整票面字段、切图、二维码、印章或字段坐标。命中旧版腾讯缓存时也必须先按同一白名单压缩。
- 资源包耗尽、欠费、计费异常、服务未开通、凭证/权限错误和无效文件属于配置、额度或输入终态，不得伪装成票据内容质量问题，也不得对同一文件无限重试。
- 未配置真实 OCR 时使用 `OCR_PROVIDER=off`：PDF 直接进入 `available`，不入 OCR 队列、不生成发票代码、号码、日期、购销方或金额。员工仍可把票据添加到已有明细并提交，财务必须查看 PDF 原件人工核对。
- off 模式下文件 SHA-256 查重继续有效，依赖发票代码和号码的查重暂不可用。对当前小团队可短期接受；强制人工补录或接入腾讯 OCR 应另行规划，不能在紧急报销中临时增加门槛。
- 既有 `InvoicePool.ocr_provider` 为非空枚举且默认 `tencent`，所以 off 模式的新记录仍可能带该历史默认标记。判定是否实际调用 OCR 必须同时看 provider 配置、`ocr_attempts`、请求/完成时间和 OCR 结果，不能只看 `ocr_provider`。
- 报销提交时必须把“已关联正式 PDF”和“具有可自动比较的票面金额”分开判断。金额已识别的票据可参加自动合计；没有任何 OCR 请求、尝试、完成或错误事实且金额为空的票据视为未执行 OCR，允许提交并持续标记为“需财务查看原件人工核对”。
- 已发生 OCR 请求、尝试、完成或错误事实但金额仍为空，属于金额识别失败，不得伪装成“缺少发票”或直接放行；员工应重试识别或联系财务处理。
- 同一明细只要包含未执行 OCR 的无金额票据，自动金额合计即不完整。即使同时存在有金额票据，也不得只用已知部分判断申报超额；整条明细转为财务人工核对。只有全部关联票据都有金额时，系统才执行申报金额与票面合计的自动比较。

## 样票脱敏和授权

真实 OCR、批量样票回归和供应商能力验证只能使用已授权样票。仓库只保存规则、摘要、命令和证据路径，不保存真实票据原件。

样票进入测试前必须确认：

- 样票来源、用途、授权人和有效期已在仓库外安全位置登记；Issue CSV 只记录授权摘要或外部登记位置。
- 原始发票、支付截图、订单、合同和聊天记录不得提交到 git；需要长期保留时放在受控对象存储或本地安全目录。
- 脱敏样票必须去除或遮盖不参与测试的公司抬头、税号、地址电话、开户行账号、个人姓名、手机号、身份证、银行卡、二维码和完整业务备注。
- 如果 OCR 测试必须保留发票代码、号码、金额、日期等字段，应只保留验证所需最小字段，并在报告中写明保留原因。
- 证据报告只能记录文件别名、格式、大小、样本类别、OCR 状态、字段命中摘要和失败原因，不记录完整票面图片或敏感字段明文。
- `artifacts/`、`output/` 和 Playwright 截图不得包含未经脱敏的真实票面；如工具自动生成了敏感截图，先删除或移出仓库外安全位置，再回填摘要。
- 无授权样票时，真实 OCR 回归只能标记为 `SKIP`，不得用 mock、截图或口头描述替代真实样票结论。

样票引用建议使用稳定别名，例如 `SAMPLE-PDF-VAT-001`、`SAMPLE-IMG-VAT-001`。别名和真实文件名的映射放在仓库外，Issue CSV `Notes` 只写别名、结论和证据路径。

## 查重规则

公司级查重优先级：

- 相同 `file_sha256`。
- OCR 后相同 `invoice_code + invoice_number`。
- 后续支持数电票号码时，应加入同等优先级的唯一识别字段。

不可添加场景：

- 同一公司已有相同可用发票。
- 同一公司已有相同发票正在识别。
- 同一公司已有相同发票识别失败。
- 同一公司已有相同发票被其他人上传。
- 同一公司已有相同发票处于 `bound` 或已完成报销归档。

普通流程不开放“强制重复添加”。管理员例外处理必须保留审计字段和原因。

## 添加到报销单

服务端必须校验：

- 当前用户有发票上传/报销编辑权限。
- 发票属于报销单申请人或可被当前角色合法处理。
- 发票状态为可添加。
- 发票未被其他报销单、差旅单或归档流程占用。
- `linkedItemId` 若传入，必须属于当前报销单。
- 草稿或驳回单中，已添加但尚未选择明细的发票可以直接选择本单明细。该动作必须由服务端在一个事务内校验报销参与人、单据状态、发票归属和明细归属，只更新明细关联；不得要求员工先移除再重新添加，也不得让发票短暂回到可添加状态。

明细匹配规则：

- 报销单只有一条明细时，自动添加到该明细。
- 多条明细时，优先按发票金额唯一匹配。
- 无法唯一匹配但发票金额存在时，自动创建新明细。
- 发票金额缺失时，阻断自动创建并提示需要先处理发票信息。

## 移除与删除

- 草稿和驳回状态允许移除发票，移除后发票回到可用状态。
- 审批中使用撤回，不提供删除。
- 已提交后的报销单原则上不物理删除；业务不再继续用取消，已支付或已归档后只允许按权限追加修正或作废留痕。
- 已通过、已支付、已归档的报销单不允许普通用户删除。
- 删除草稿时，已添加发票应释放为可用，附件随报销单删除。

## 附件材料

附件用于支付截图、合同、订单、聊天记录、情况说明等非发票材料。

规则：

- 支持 PDF、JPG、PNG、WEBP。
- 支持多文件上传。
- 不参与发票 OCR。
- 不参与发票查重。
- 上传前必须明确附件类型或用途，例如支付截图、订单、聊天记录、情况说明、验收材料；不能把 PDF 发票、付款回单、合同正文和资产材料都作为普通附件混传。
- 草稿和驳回状态可上传、查看、删除。
- 提交后审批人和财务可查看。
- 默认治理标签为“已通过 / 内部 / 补充材料 / 标准下载”；若附件实际属于合同、报价、验收、付款证明或其他敏感材料，应按对应业务对象上传，不要混在普通报销补充材料里。
- 报销附件可以保存业务办理所需原文，但只限报销人、审批人、财务和被授权角色按职责查看；自动化报告、企业微信消息、聊天和 AI/Codex 处理只能使用脱敏摘要或别名。
- 敏感或 `reason_required` 附件下载必须填写用途并写入审计日志；普通员工不得批量下载他人报销附件。
- 报销列表只显示发票和附件的完整性摘要、缺失提示和进入详情入口；发票预览、附件查看/下载/删除、敏感材料用途填写和批量打包必须进入报销详情、详情命令区、明确命名的财务动作或授权审计路径。
- 报销页只显示付款状态、回单状态、查看付款或补回单入口；标记已付款、取消付款、批量付款和执行付款必须进入付款/财务处理详情，不能放在报销列表或普通报销详情里直接执行。
- 报销页展示项目、采购、合同、资产候选或付款记录时只显示摘要和跳转，不复制对方模块的审批、付款、合同正文下载、资产建卡或高敏附件操作。

## 付款批次核对与银行回单

- 普通报销详情显示“报销事由”；差旅报销详情以“出差事由”为唯一主事由，不在同一区域重复显示普通报销事由。
- 一张报销进入付款批次后，处理进度中只显示一个“查看所在付款批次”入口：待复核时归在“付款复核”，复核后、付款失败、付款完成或复核后取消时归在“付款完成”；无付款批次读取权限的员工不显示入口。
- 付款批次详情按报销单分组，先显示报销单摘要，再显示费用类型、发生日期、说明、金额和明细小计，最后显示脱敏收款信息与付款结果。费用明细只用于复核，不改写冻结的批次付款金额；二者不一致时提示返回原报销单核对。
- 付款批次列表不加载费用明细、回单文件名或其他高敏材料，只在授权详情中按需读取。
- PDF、JPG、PNG、WEBP 银行回单可在付款批次详情中在线查看。在线查看由系统记录固定用途“付款批次内在线预览”并写审计，不要求用户重复填写。
- 本期报销回单自动核验仅支持可从原件提取文字、且同时满足正式回单、明确成功和字段匹配等检查的 PDF。JPG、PNG、WEBP 和没有可提取文字的扫描件 PDF 仍可上传、在线查看及提取 OCR 字段；财务须核对完整原件并录入付款依据，再由另一名符合本单独立性要求的人员复核，才能继续登记付款。没有合格独立复核人时保持待核对；人工核对不能覆盖已知的非最终说明或其他阻断条件。
- 回单下载到本地仍要求填写用途并写下载审计；治理标签使用“下载需说明用途”。在线查看和下载都必须重新检查权限、部门范围、作废/隔离状态、大小、存储对象和实际文件内容，不直接暴露存储路径。
- 付款核验分别判断凭证性质、字段和交易归属。载明“不作为最终依据”或仅表示提交、受理的回执不能用于登记付款完成，即使金额、账号和成功字样能识别；公司收到款项的借入回单也不能证明公司已经还款。机器无法判断凭证性质时，应核对完整原件，不能默认按正式付款回单处理。
- 正式回单没有“交易成功”字样，但原件明确记录本公司已经发生的支出时，财务可选择“正式回单记载公司已记账支出”，填写票面记账日期和依据说明，再由本批次适用的确认人核对。不要补写银行未记载的成功状态；非最终说明、方向矛盾、归属不清或重复交易不能通过此方式绕过。核验确认本身不登记付款，最终登记仍须重验；旧核验缺少凭证性质时须在详情中显式更新并重新核对。

## 差旅实报实销与支付证明

首笔差旅报销按“实报实销明细—正式票据—个人支付证明”和“包干补助—天数—单价”分别复核。

- 火车票和住宿费必须拆成不同明细，分别选择生产已有的“火车票”和“住宿费”费用类型，填写发生日期、个人实际支付的合规金额和事由。
- 火车电子票据、住宿电子普通发票等正式票据必须使用官方 PDF，从对应明细的发票入口上传并绑定；发票截图、支付截图或拍照图片不得冒充正式发票。
- 火车票和住宿费均必须提供个人支付截图。支付截图属于整张报销单的补充附件，不绑定到发票记录；文件名或附件说明必须能对应到具体费用明细。
- 支付截图保留商户、金额、支付时间和支付成功状态即可；银行卡号、支付账号、订单号等与审批无关的信息应先遮挡，不要求员工提供完整支付账户或银行流水。
- 明细金额以员工个人实际支付的合规金额为准；需要发票的明细金额不得高于该明细关联发票的票面合计，超出时系统阻断提交。优惠券、多人合并开票、部分自费等导致申报金额低于票面合计时，必须在明细说明中写明差异。
- 已退款、公司直接支付或由他人承担的金额不得重复报销。发生部分退款时，只能申报扣除退款后的个人实际承担金额，并附情况说明。
- 确实无法提供支付截图时，员工必须上传情况说明；财务可以退回补充，也可以在有其他充分证据时例外接受并留痕。不得伪造、补造或借用他人支付凭证。
- OCR 只辅助识别发票字段、匹配和查重，不判断支付真实性、费用合理性或发票法律状态。财务复核时必须同时查看明细金额、PDF 原件和个人支付证明；三者不一致时退回更正或补充说明。
- 每张有效发票应关联到一条明确费用明细。一条明细只表达同一费用类型和同一笔业务支出；不同类型或彼此独立的支出应拆分，采购物品还应是一件或一批同类物品。连续跨天或跨期的同一笔业务支出（如多晚住宿、月度通讯费、按服务期计费）可以作为一条明细，并在说明中写清起止日期。
- 票据—明细门禁启用后，已添加发票未选择明细、需票明细没有关联正式 PDF、已尝试 OCR 但票面金额仍无法识别，或在全部关联票据金额完整时申报金额高于票面合计，均阻断提交。未执行 OCR 的无金额 PDF 允许提交，但员工提交反馈和审批详情必须明确提示财务查看原件人工核对；两项包干补助不参加票据与票面比较。关闭门禁不会删除或解绑已经建立的关联关系。
- 财务付款凭证号、付款日期、付款渠道和付款回单属于审批通过后的财务处理，不是员工提交报销时填写的个人支付证明。

### 差旅补助规定

- 伙食补助费为 100 元/人/天，市内交通补助费为 80 元/人/天，均按符合条件的出差自然日包干发放，不要求发票。
- 出发日和返回日均计 1 天，当天往返计 1 天；因个人原因延长的行程天数不计补助。
- 领取伙食补助后，个人餐费不得另行报销；领取市内交通补助后，出差期间公交、地铁、出租车、网约车等市内交通费用不得另行报销。
- 公司或其他单位已直接承担相应餐食或车辆费用的，不重复领取对应补助。
- 城际交通、住宿以及其他经批准的必要差旅费用凭有效材料实报实销。城际大巴费用使用“大巴车票”费用类型，不得填写为“市内交通补助费”。
- 当前系统不自动计算补助天数。员工应为两项补助分别建立明细，金额填写 `符合条件的天数 × 对应单价` 的总额，并在说明中写明日期范围、天数、单价、算式及不计补助的情况；主管和财务据此复核。
- 在系统具备数量/天数乘算能力前，不配置 100 元或 80 元的单条费用上限。现有按日单位只作展示，直接配置会把多日补助误判为超标。

## PC 与手机体验

小团队填报与提交规则：

- 普通报销明细金额必须大于 0；差旅或模板可以生成零金额草稿占位，但补齐正金额前不能提交。
- 报销总额由服务端按明细汇总，PC、手机和打印页只展示该权威总额，不提供手工填写总额。
- 提交事务必须重新读取全部明细并重算总额，再据此执行预算检查、审批规则选择和工作流快照。
- 费用日期默认可追溯 365 天，部署时可调整为 180 天；超过期限或跨自然年度只提示员工与财务确认，不自动阻断，也不增加“历史费用补报”标签。
- 详情显示整单发票数、补充附件数和每条明细的发票关联状态；未逐条关联发票先提示补充关联或无票说明，不取代现有整单票据门禁。
- `assets` 类明细只触发人工资产登记提醒。报销完成后由管理员核对并手动建卡，系统不因报销提交、审批或付款自动创建资产卡。

PC 端：

- 适合明细编辑、批量查看、财务复核和台账导出。
- 报销详情分区展示：摘要、明细、发票、附件、审批流、预算与审核提示。
- PC 报销列表和详情遵循 [产品体验事实源](./产品设计规则.md)：业务编号、状态、申请人、金额和更新时间优先，不把 UUID 或内部状态码作为主展示；视觉与交互裁决以 `frontend-design` 为准。

手机/企业微信端：

- 适合新建、继续编辑草稿、上传 PDF 发票、补充附件、提交审批、查状态。
- 不显示桌面表格。
- 报销详情深层页隐藏底部 Tab，顶部返回清晰，底部主操作不遮挡内容；iPhone 11 等小屏下核心双按钮仍同行展示。
- 添加发票不默认聚焦搜索框，不自动弹键盘。
- 底部操作区紧凑，选中态使用品牌实心色；核心操作在 iPhone 11 等小屏上仍保持同行双按钮，不降级为单列。

## 自动化验收

每次改报销/发票/附件至少验证：

- 后端单测覆盖上传、查重、添加、移除、附件上传/下载/删除。
- 前端 `typecheck` 和 `build`。
- Playwright PC 报销详情。
- Playwright mobile/wecom UA 报销详情。
- 视觉检查无 PC 壳、无表格误入、无黑色大块导航、无“绑定整单/不绑定明细/发票池/OCR”等普通用户文案。