155 行
10 KiB
Markdown
155 行
10 KiB
Markdown
# 报销、发票与附件规则
|
||
|
||
本文是 hyb-oa 报销主链路的业务事实源，面向 10 人以下国内科技公司。目标是让员工少选项、财务少核错、管理员少配置。
|
||
|
||
当前报销、发票、OCR、附件、付款和导出开发以 [需求 - 报销发票 OCR 规约](./需求-报销发票OCR规约.md) 为模块级开发规约；本文保留为报销细则来源。如两者有重复，以新规约整合后的口径为准。首批发票合规以 OCR、查重和财务人工复核为主，自动验真作为后续评估项。
|
||
|
||
R5 公网验收后确认：正式发票/OCR 上传入口只接受 PDF 发票文件；图片和拍照直传不作为发票入口。附件材料仍可上传图片或 PDF，但必须与发票分离。重复票据、已使用票据和 OCR 失败必须进入可解释终态，不能长期停留在处理中。
|
||
|
||
## 总原则
|
||
|
||
- PC 与手机功能一致，只允许布局和控件形态不同。
|
||
- 普通员工看到的是“添加发票”“上传附件”“提交审批”，不看到“绑定整单”“发票池”“ERP 同步”等内部概念。
|
||
- 发票是报销凭证，附件是补充材料，二者不能混用。
|
||
- 报销上传采用材料类型先行：PDF 发票走“添加/上传 PDF 发票”入口，支付截图、订单、聊天记录、情况说明等走“上传附件/补充材料”入口，付款回单走财务付款或回单入口，不混成一个万能上传框。
|
||
- 已经报销、他人已报销、重复上传的发票不能加入新的报销单。
|
||
- 服务端必须强约束，前端只负责友好提示。
|
||
- 报销审批必须在 OA 内完成，企业微信只发送提醒和 deeplink，不作为报销审批流或财务附件主库。
|
||
- 财务台账 V1 只做付款准备、付款批次、回单留痕、AP 状态、票据/OCR 状态和代账交接摘要；真实付款继续在线下银行或既有财务流程完成，OA 不做银行直连、银行流水自动导入、ERP/总账、凭证生成、自动对账或税务申报。
|
||
|
||
## 发票状态
|
||
|
||
发票主要状态：
|
||
|
||
- `pending_ocr`：已上传，正在识别。
|
||
- `available`：可添加到报销单。
|
||
- `bound`：已添加到报销单。
|
||
- `ocr_failed`：识别失败，需要重试或人工处理。
|
||
- `archived`：已归档，不可添加；若 `archived_reason=used_complete`，视为已报销。
|
||
|
||
前端展示时使用中文业务表达：
|
||
|
||
- `pending_ocr`：识别中。
|
||
- `available`：可添加。
|
||
- `bound`：已添加。
|
||
- `ocr_failed`：识别失败。
|
||
- `archived`：已归档或已报销。
|
||
|
||
## 上传与 OCR
|
||
|
||
- 发票/OCR 上传只允许 PDF 发票文件；图片、拍照直传和 HTML `capture` 入口不作为正式发票上传方式。
|
||
- PC 票据中心、PC 报销详情、移动报销详情和企业微信 WebView 内的发票入口都必须执行 PDF-only 口径。
|
||
- 上传后页面必须显示明确状态，不应长期停留在“上传中”。
|
||
- OCR 完成后，添加发票弹窗应自动刷新并尝试添加可用发票。
|
||
- OCR 失败、重复、已使用、他人已使用都要显示可理解原因。
|
||
- 刷新按钮必须有明显反馈，不能让用户误以为没点中。
|
||
- 正式环境不得使用 `OCR_PROVIDER=mock` 处理真实票据；mock 仅用于本地或明确隔离的合成测试。
|
||
- 未配置真实 OCR 时使用 `OCR_PROVIDER=off`：PDF 直接进入 `available`，不入 OCR 队列、不生成发票代码、号码、日期、购销方或金额。员工仍可把票据添加到已有明细并提交，财务必须查看 PDF 原件人工核对。
|
||
- off 模式下文件 SHA-256 查重继续有效，依赖发票代码和号码的查重暂不可用。对当前小团队可短期接受；强制人工补录或接入腾讯 OCR 应另行规划，不能在紧急报销中临时增加门槛。
|
||
- 既有 `InvoicePool.ocr_provider` 为非空枚举且默认 `tencent`，所以 off 模式的新记录仍可能带该历史默认标记。判定是否实际调用 OCR 必须同时看 provider 配置、`ocr_attempts`、请求/完成时间和 OCR 结果，不能只看 `ocr_provider`。
|
||
|
||
## 样票脱敏和授权
|
||
|
||
真实 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` 附件下载必须填写用途并写入审计日志；普通员工不得批量下载他人报销附件。
|
||
- 报销列表只显示发票和附件的完整性摘要、缺失提示和进入详情入口；发票预览、附件查看/下载/删除、敏感材料用途填写和批量打包必须进入报销详情、详情命令区、明确命名的财务动作或授权审计路径。
|
||
- 报销页只显示付款状态、回单状态、查看付款或补回单入口；标记已付款、取消付款、批量付款和执行付款必须进入付款/财务处理详情，不能放在报销列表或普通报销详情里直接执行。
|
||
- 报销页展示项目、采购、合同、资产候选或付款记录时只显示摘要和跳转，不复制对方模块的审批、付款、合同正文下载、资产建卡或高敏附件操作。
|
||
|
||
## PC 与手机体验
|
||
|
||
PC 端：
|
||
|
||
- 适合明细编辑、批量查看、财务复核和台账导出。
|
||
- 报销详情分区展示：摘要、明细、发票、附件、审批流、预算与审核提示。
|
||
- PC 报销列表和详情遵循 [产品体验事实源](./产品设计规则.md)：业务编号、状态、申请人、金额和更新时间优先，不把 UUID 或内部状态码作为主展示；视觉与交互裁决以 `frontend-design` 为准。
|
||
|
||
手机/企业微信端：
|
||
|
||
- 适合新建、继续编辑草稿、上传 PDF 发票、补充附件、提交审批、查状态。
|
||
- 不显示桌面表格。
|
||
- 报销详情深层页隐藏底部 Tab，顶部返回清晰，底部主操作不遮挡内容；iPhone 11 等小屏下核心双按钮仍同行展示。
|
||
- 添加发票不默认聚焦搜索框，不自动弹键盘。
|
||
- 底部操作区紧凑，选中态使用品牌实心色；核心操作在 iPhone 11 等小屏上仍保持同行双按钮，不降级为单列。
|
||
|
||
## 自动化验收
|
||
|
||
每次改报销/发票/附件至少验证：
|
||
|
||
- 后端单测覆盖上传、查重、添加、移除、附件上传/下载/删除。
|
||
- 前端 `typecheck` 和 `build`。
|
||
- Playwright PC 报销详情。
|
||
- Playwright mobile/wecom UA 报销详情。
|
||
- 视觉检查无 PC 壳、无表格误入、无黑色大块导航、无“绑定整单/不绑定明细/发票池/OCR”等普通用户文案。
|