423 行
29 KiB
Markdown
423 行
29 KiB
Markdown
# 需求 - 报销发票 OCR 规约
|
||
|
||
**版本**：1.0
|
||
**日期**：2026-05-09
|
||
**状态**：模块级开发规约
|
||
**补充口径**：财务台账 V1 只做付款准备、付款批次、回单留痕、AP 状态、票据/OCR 状态和代账交接摘要；不做银行直连真实支付、银行流水自动导入、ERP/总账、凭证生成、自动对账、税务申报或完整财务软件。
|
||
**上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
|
||
**细则来源**：[报销、发票与附件规则](./报销发票附件规则.md)
|
||
|
||
本规约细化报销、发票、OCR、附件、查重、财务复核、付款和导出的产品要求。后续报销主链路开发必须先从本规约拆分 Trellis task，再进入技术方案和代码实现。
|
||
|
||
---
|
||
|
||
## 1. 模块目标与边界
|
||
|
||
### 1.1 目标
|
||
|
||
- 员工能在 PC、手机和企业微信入口快速创建报销、上传发票和附件、提交审批。
|
||
- 系统负责 OCR 识别、发票查重、发票与明细匹配、审批流接入、付款批次和回单留痕。
|
||
- 财务能复核发票、处理重复例外、在线下完成付款后标记付款、维护回单和导出财务/代账交接摘要。
|
||
- 报销审批必须进入 OA 统一审批中心，正式记录以 OA 为准。
|
||
|
||
### 1.2 暂不做范围
|
||
|
||
- 不使用企业微信原生审批处理报销。
|
||
- 不接入飞书报销、飞书审批或飞书文档归档。
|
||
- 首批不做银行自动付款、企业卡自动对账、ERP 自动入账。
|
||
- 首批不做银行直连真实支付、银行流水自动导入、ERP/总账、凭证生成、自动对账、税务申报或完整财务软件。
|
||
- 首批不做复杂预算占用和多币种核算。
|
||
- 首批不把企业微信文件作为发票或附件长期主库。
|
||
- 报销单、发票原件、附件、银行回单、付款资料和代账交接资料不上传到企业微信原生审批或企业微信附件；企业微信只做脱敏提醒和 OA deeplink。
|
||
|
||
---
|
||
|
||
## 2. 角色与入口
|
||
|
||
### 2.1 角色
|
||
|
||
| 角色 | 可做动作 | 权限边界 |
|
||
| --- | --- | --- |
|
||
| 员工/申请人 | 创建草稿、上传发票、上传附件、编辑明细、提交审批、查看自己的报销状态 | 只能操作本人可见的报销单和本人上传或授权使用的发票 |
|
||
| 审批人 | 查看待审批任务、查看发票和附件摘要，在待我审批/审批详情中通过、驳回、退回、转审 | 只能处理分配给自己的 OA 审批任务；报销列表和普通报销详情不直接放审批动作 |
|
||
| 财务 | 查看审批通过的报销、复核发票、处理重复例外、在线下付款后标记付款、维护回单、导出交接摘要 | 不默认拥有系统管理权限；例外动作必须审计 |
|
||
| 财务主管 | 审核高风险或大额报销、审批重复例外、复核付款批次 | 权限应通过角色配置，不硬编码到个人 |
|
||
| 管理员 | 维护费用类型、项目、部门、OCR 配置、权限和基础字典 | `admin` 不代表业务审批权，不能绕过流程直接替员工完成正式审批 |
|
||
|
||
### 2.2 入口
|
||
|
||
| 入口 | 适用场景 | 要求 |
|
||
| --- | --- | --- |
|
||
| PC 报销列表/详情 | 明细编辑、批量查看、财务复核、导出 | 可查看完整字段、审批历史、发票和附件 |
|
||
| 手机报销页 | 上传 PDF 发票、继续草稿、补充附件、提交审批、查状态 | 不使用桌面宽表，操作路径短 |
|
||
| 企业微信自建应用 | 手机工作台入口和消息 deeplink | 默认进入 OA 移动端，审批动作仍在 OA 内完成 |
|
||
| 票据或发票添加弹窗 | 从报销草稿中添加发票 | 普通员工只看到“添加发票”，不暴露“发票池”等内部概念 |
|
||
| 财务导出页 | 财务按期间、人员、项目、状态导出 | 导出前必须校验财务权限 |
|
||
|
||
报销审批动作集中在 `待我审批`、审批详情或移动审批详情执行。报销列表和普通报销详情只显示审批状态、当前节点、历史、`查看处理`、`查看进度`、`补材料` 或进入审批任务入口，不直接放 `通过`、`驳回`、`退回`、`转审`。
|
||
|
||
---
|
||
|
||
## 3. 报销单对象与字段
|
||
|
||
| 字段 | 含义 | 必填规则 |
|
||
| --- | --- | --- |
|
||
| 报销单号 | OA 生成的唯一业务编号 | 提交前或首次保存时生成，必须唯一 |
|
||
| 申请人 | 创建报销单的人 | 必填 |
|
||
| 实际报销人 | 款项实际归属人员 | 默认等于申请人，可按权限调整 |
|
||
| 部门 | 申请人或实际报销人所属部门 | 必填或由系统带出 |
|
||
| 项目 | 关联项目、合同或内部事项 | 项目费用建议必填 |
|
||
| 费用明细 | 费用类型、日期、金额、说明、关联发票 | 至少一条有效明细 |
|
||
| 报销总金额 | 明细金额合计 | 系统计算，用户不可直接篡改 |
|
||
| 发生日期 | 费用发生日期或期间 | 明细级必填 |
|
||
| 说明 | 报销原因、用途、备注 | 按费用类型决定是否必填 |
|
||
| 发票 | 增值税发票、数电票、普通发票等凭证 | 需报销发票的费用必填 |
|
||
| 附件 | 支付截图、订单、合同、聊天记录、情况说明等 | 按费用类型或审批要求决定 |
|
||
| 审批状态 | 草稿、审批中、已通过等 | 系统维护 |
|
||
| 付款状态 | 未付款、已付款、无需付款等 | 财务维护 |
|
||
| 审批历史 | 提交、通过、驳回、退回、转审等记录 | 系统维护 |
|
||
|
||
---
|
||
|
||
## 3.5 费用类型与材料要求矩阵
|
||
|
||
以下规则是 10 人以下公司试运行建议值，不等于最终公司财务制度。正式上线前可由管理员按公司制度配置，后续实现不得把阈值和材料要求硬编码在业务逻辑中。
|
||
|
||
| 费用类型 | 是否必须发票 | 是否必须附件 | 是否建议关联项目 | 试运行审批提示 | 常见附件 |
|
||
| --- | --- | --- | --- | --- | --- |
|
||
| 交通 | 是，打车或公共交通票据 | 金额 `>200` 元建议补充行程说明 | 项目出行建议关联 | 单笔 `>500` 元提示主管关注合理性 | 行程单、支付截图 |
|
||
| 餐费 | 是 | 金额 `>200` 元需说明参与人或事由 | 项目餐费建议关联 | 单笔 `>500` 元进入费用高风险提示 | 支付截图、事由说明 |
|
||
| 招待 | 是 | 是 | 必须关联客户、项目或事项 | 默认提示主管和老板关注，`>1000` 元建议老板审批 | 招待对象、事由说明、支付截图 |
|
||
| 办公采购 | 是 | 金额 `>500` 元需订单或验收材料 | 建议关联部门或项目 | 按采购金额进入审批规则矩阵 | 订单、收货/验收截图 |
|
||
| 硬件 | 是 | 是 | 建议关联资产或项目 | `>1000` 元建议老板审批并登记资产 | 订单、验收、资产信息 |
|
||
| 软件订阅 | 是 | 是 | 项目软件建议关联项目 | 周期性订阅需写明周期和使用人 | 订单、订阅截图、合同或报价 |
|
||
| 快递 | 是或按实际票据 | 金额 `>100` 元建议补充寄件说明 | 项目快递建议关联 | 金额较小可走主管审批 | 运单、支付截图 |
|
||
| 项目材料 | 是 | 是 | 必须关联项目 | 按采购或费用金额审批 | 订单、验收、项目说明 |
|
||
| 差旅预留 | 是，交通/住宿等票据 | 是 | 必须关联出差或项目 | 首批只保留字段和入口，完整差旅单后续拆分 | 行程单、酒店水单、出差说明 |
|
||
|
||
提交前应根据费用类型做预检：发票、附件、项目、说明和金额阈值缺失时给出可操作提示。普通员工只看到业务语言，不展示内部规则码。
|
||
|
||
### 3.6 BIZ8 费用提示轻量规则
|
||
|
||
BIZ8 阶段的费用提示只作为填报辅助和审批关注提醒，不扩展为重预算控制、ERP 校验或自动财务判断。系统可以提示“建议补充说明、建议关联项目、金额超出费用标准、财务需重点复核”，但不得把轻量提示误写成公司正式财务制度。
|
||
|
||
规则边界：
|
||
|
||
| 类型 | 作用 | 是否阻断提交 |
|
||
| --- | --- | --- |
|
||
| 材料提示 | 按费用类型提示发票、附件、说明或项目是否建议补充 | 不阻断；除非对应费用类型已配置为必填 |
|
||
| 金额提示 | 金额超过试运行建议值时提醒申请人和审批人关注合理性 | 不阻断；只进入提示或人工复核 |
|
||
| 费用标准 `warn` | 已配置费用标准且 `control_mode=warn` 时展示超标说明 | 不阻断；提交后可生成待复核风险项 |
|
||
| 费用标准 `block` | 已配置费用标准且 `control_mode=block` 时阻断不合规提交 | 可阻断；必须显示可理解原因 |
|
||
| 预算提示 | 仅展示预算池、预警或超用风险 | 不等同正式预算控制；重预算冻结项不得在 BIZ8 内启动 |
|
||
|
||
用户提示要求：
|
||
|
||
- 普通员工看到业务语言，例如“建议补充行程说明”“建议关联项目”“当前金额超出交通费参考标准”，不展示内部规则码。
|
||
- 审批人和财务看到提示来源、费用类型、金额、参考上限和是否需要人工复核。
|
||
- 费用提示不能自动通过、自动驳回或自动改审批链；正式审批仍以统一审批中心为准。
|
||
- 规则来源必须可配置或可追溯，不得把试运行建议金额硬编码成最终制度。
|
||
- 若规则缺失，系统可以提示“未配置费用标准”，不能把缺配置解释为审批通过或预算通过。
|
||
|
||
---
|
||
|
||
## 4. 状态模型
|
||
|
||
### 4.1 报销状态
|
||
|
||
| 状态 | 含义 | 主要动作 |
|
||
| --- | --- | --- |
|
||
| 草稿 | 员工编辑中，未提交 | 编辑、上传、删除草稿、提交 |
|
||
| 审批中 | 已提交 OA 审批 | 审批人处理；申请人按规则撤回 |
|
||
| 已通过 | 审批完成，等待财务后处理 | 财务复核、付款标记、导出 |
|
||
| 已驳回 | 审批否决 | 查看原因、复制重提或新建 |
|
||
| 已退回 | 需要申请人修改 | 修改后重提、撤回 |
|
||
| 已付款 | 财务已完成付款 | 查看、导出；普通用户不可修改 |
|
||
| 已完成 | 报销归档完成 | 查看、归档、导出 |
|
||
|
||
### 4.2 发票状态
|
||
|
||
| 状态 | 含义 | 前端展示 |
|
||
| --- | --- | --- |
|
||
| `pending_ocr` | 已上传，正在识别 | 识别中 |
|
||
| `available` | 可加入报销单 | 可添加 |
|
||
| `bound` | 已加入报销单或明细 | 已添加 |
|
||
| `ocr_failed` | 识别失败，需要重试或人工处理 | 识别失败 |
|
||
| `archived` | 已归档，不可再添加 | 已归档或已报销 |
|
||
|
||
### 4.3 附件状态
|
||
|
||
| 状态 | 含义 | 规则 |
|
||
| --- | --- | --- |
|
||
| 已上传 | 文件已存储并关联报销单 | 草稿和退回态可删除 |
|
||
| 已提交 | 报销提交后随单据进入审批 | 审批人和财务可查看 |
|
||
| 已归档 | 报销完成后归档 | 普通员工不可删除 |
|
||
|
||
附件不是发票，不参与 OCR，不参与发票查重。
|
||
|
||
---
|
||
|
||
## 5. 发票与明细关系
|
||
|
||
### 5.1 匹配规则
|
||
|
||
- 报销单只有一条明细时，发票自动加入该明细。
|
||
- 报销单有多条明细时，优先按发票金额唯一匹配明细金额。
|
||
- 票据—明细门禁关闭时，金额无法唯一匹配但发票金额存在可沿用自动创建明细的兼容路径，并提示用户确认费用类型和说明；门禁开启后必须由员工明确选择已有明细，不再静默自动创建。
|
||
- 发票金额缺失时，不自动创建明细，提示用户先补全发票信息或手工创建明细。
|
||
- 一张发票可按业务规则关联一条或多条明细；首批优先支持一张发票绑定一条明细，复杂拆分后续单独设计。
|
||
|
||
### 5.2 校验规则
|
||
|
||
- 报销总金额必须等于有效明细金额合计。
|
||
- 发票金额与对应明细金额不一致时，应提示用户确认差额原因。
|
||
- 无发票费用必须有业务规则允许，并通过附件或说明补足依据。
|
||
- 已归档或已报销的发票不能再加入新的报销单。
|
||
|
||
---
|
||
|
||
## 6. OCR 规则
|
||
|
||
### 6.1 上传与识别
|
||
|
||
- 产品长期目标允许按 OCR provider 能力扩展图片和 PDF 发票识别。
|
||
- 当前试运行验收只开放 PDF 发票进入 OCR；图片文件按普通附件材料处理，不进入发票 OCR 或发票查重。
|
||
- 上传成功后必须展示明确状态，不允许长期停留在“上传中”。
|
||
- OCR 识别字段至少包括：发票代码、发票号码、数电票号码或等效唯一号、金额、税额、价税合计、开票日期、销方、购方。
|
||
- OCR 完成后，添加发票区域自动刷新，并尝试按规则加入报销明细。
|
||
- OCR 失败时保留失败原因，允许重试和人工修正。
|
||
|
||
### 6.2 人工修正
|
||
|
||
- 申请人可在草稿或退回态修正自己发票的识别结果。
|
||
- 财务可在复核阶段修正关键字段。
|
||
- 修正发票代码、号码、金额、开票日期等关键字段必须写入审计日志。
|
||
- 修正后必须重新触发查重校验。
|
||
|
||
### 6.3 当前试运行 PDF-only 与后续图片能力口径
|
||
|
||
- PDF 发票是当前试运行、R7E 和 live OCR 的验收基线。
|
||
- 图片 OCR 不作为当前验收项，后续如启动必须另拆 P2/UX Issue，并补充样票、隐私处理、provider 能力和回归口径。
|
||
- 图片材料可作为支付截图、订单、说明等普通附件上传；附件不参与 OCR，不参与发票查重。
|
||
- PDF 可按 provider 能力直接识别或先转图片后识别，但这属于服务端实现细节，不暴露给普通用户。
|
||
- 多页 PDF 首批按一份文件处理；若包含多张发票，后续单独拆分能力。
|
||
- 文件原件必须保留，OCR 结果只是结构化识别数据。
|
||
|
||
### 6.3.1 BIZ8 图片 OCR 可行性设计
|
||
|
||
BIZ8 阶段的图片 OCR 结论是“技术可行，但当前不开放为正式能力”。国内主流 OCR provider 已支持图片或 PDF 发票识别，例如腾讯云 `VatInvoiceOCR` 支持 `PNG/JPG/JPEG/PDF` 并通过 `IsPdf` 区分 PDF，阿里云 `RecognizeInvoice` 支持图片、PDF、OFD 等格式，百度智能云增值税发票识别支持 `image/url/pdf_file/ofd_file` 输入。以上只作为 provider 能力调研依据，不改变 hyb-oa 当前 PDF-only 验收口径。
|
||
|
||
启动图片 OCR 前必须满足以下条件：
|
||
|
||
| 条件 | 要求 |
|
||
| --- | --- |
|
||
| 样票授权 | 先完成脱敏样票授权，仓库不得提交真实票据原件、身份证号、手机号、银行卡或公司敏感报价 |
|
||
| provider 选择 | 优先复用现有腾讯云 OCR SDK 和字段归一化链路；阿里云或百度只作为后续替代方案，需另写 SDK、计费、字段映射和回滚说明 |
|
||
| 入口控制 | 不恢复拍照直传或 HTML `capture` 作为默认发票入口；若试验图片发票，必须使用明确的受控入口、feature flag 和可回滚配置 |
|
||
| 文件规则 | 图片发票只允许明确白名单格式，文件大小、分辨率、页数和错误提示必须与 provider 限制一致 |
|
||
| 字段规则 | 识别后仍按发票代码、发票号码、数电票号码、金额、开票日期、销方、购方等统一字段进入查重和人工复核 |
|
||
| 审计规则 | 图片 OCR 结果、失败原因、人工修正、重复例外、附件下载和敏感操作继续写审计摘要 |
|
||
| 验收规则 | mock OCR、真实 provider、pending、失败重试和人工复核结论分开记录；无授权样票时只能 SKIP 真实图片 OCR，不得标记 PASS |
|
||
|
||
推荐技术路径：
|
||
|
||
1. 保持 PDF-only 上传校验和现有页面文案不变。
|
||
2. 在非生产环境用脱敏样票验证现有腾讯云 `image_native` 分支和字段归一化结果。
|
||
3. 若真实图片样票通过率和失败可解释性达标，再另开 BIZ8 后续行或 BIZ9 开发入口。
|
||
4. 开发时只放开发票图片入口，不改变附件图片作为普通材料的规则。
|
||
5. 回滚时关闭 feature flag、恢复 PDF-only allowlist，已上传图片发票按识别失败或人工复核记录处理，不自动转为附件。
|
||
|
||
参考链接：
|
||
|
||
- 腾讯云增值税发票识别：https://cloud.tencent.com/document/api/866/36210
|
||
- 阿里云增值税发票识别：https://help.aliyun.com/zh/ocr/developer-reference/api-ocr-api-2021-07-07-recognizeinvoice
|
||
- 百度智能云增值税发票识别：https://cloud.baidu.com/doc/OCR/s/nk3h7xy2t
|
||
|
||
### 6.4 发票合规与人工复核
|
||
|
||
首批发票合规采用 `OCR + 查重 + 财务人工复核`。不接自动验真接口，不依赖新增付费服务或第三方验真能力；自动验真进入后续 backlog。
|
||
|
||
| 校验项 | 首批规则 | 异常处理 |
|
||
| --- | --- | --- |
|
||
| 公司抬头 | OCR 识别购方名称后与公司抬头或可报销抬头清单比对 | 不一致时提示申请人确认，提交后财务重点复核 |
|
||
| 税号 | OCR 识别购方税号后与公司税号比对 | 不一致时提示并进入财务人工复核 |
|
||
| 发票代码+号码 | 用于传统发票唯一性判断 | 缺失时允许人工补录，补录后重新查重 |
|
||
| 数电票号码 | 用于数电票唯一性判断 | 缺失时允许人工补录，补录后重新查重 |
|
||
| 价税合计 | 用于明细匹配和金额校验 | 与明细不一致时提示差额原因 |
|
||
| 开票日期 | 用于期间筛选和超期提示 | 超过公司允许周期时提示财务关注 |
|
||
| 销方信息 | 作为财务复核参考 | 异常供应商由财务人工判断 |
|
||
| 红冲/作废 | 首批由财务人工标记 | 标记后不可进入普通报销流程 |
|
||
|
||
人工复核状态建议使用：`待复核`、`人工通过`、`人工驳回`、`例外通过`。人工复核必须记录复核人、复核时间、复核结论和原因；关键字段被修正后必须重新查重。
|
||
|
||
---
|
||
|
||
## 7. 查重规则
|
||
|
||
### 7.1 查重维度
|
||
|
||
公司级查重按以下优先级执行：
|
||
|
||
1. 文件 `file_sha256` 相同。
|
||
2. OCR 后 `invoice_code + invoice_number` 相同。
|
||
3. 数电票号码或其他官方唯一号码相同。
|
||
4. 后续接入电子发票验真时，使用官方验真结果补充判断。
|
||
|
||
### 7.2 不可添加场景
|
||
|
||
- 同一公司已有相同可用发票。
|
||
- 同一公司已有相同发票正在识别。
|
||
- 同一公司已有相同发票识别失败。
|
||
- 同一公司已有相同发票被他人上传。
|
||
- 同一公司已有相同发票处于已添加、已归档或已报销状态。
|
||
- 发票已经被其他报销单、差旅单或归档流程占用。
|
||
|
||
### 7.3 重复例外
|
||
|
||
- 普通员工不能强制添加重复发票。
|
||
- 确需例外时，只能由授权财务或财务主管处理。
|
||
- 例外必须记录原报销单号、重复原因、处理人、处理时间和附件依据。
|
||
- 例外处理不得绕过 OA 审批和财务复核。
|
||
|
||
---
|
||
|
||
## 8. 附件规则
|
||
|
||
附件用于补充业务事实，包括支付截图、订单、合同、聊天记录、情况说明、验收材料等。
|
||
|
||
- 发票/OCR 上传仅支持 PDF；附件材料可继续支持 PDF、JPG、PNG、WEBP。
|
||
- 支持多文件上传。
|
||
- 不参与 OCR。
|
||
- 不参与发票查重。
|
||
- 上传材料必须先明确类型：PDF 发票走发票/OCR 入口，支付截图、订单、聊天记录、情况说明、验收材料走普通附件入口，付款回单走财务回单入口；不同类型适用不同校验、权限、审计和展示位置，不使用万能附件入口混收。
|
||
- 草稿和已退回状态允许上传、查看、删除。
|
||
- 审批中、已通过、已付款、已完成状态原则上不允许普通员工删除。
|
||
- 审批人和财务在处理报销时可查看附件。
|
||
- 涉密合同正文、敏感报价、身份证、银行卡等高敏材料不得随意进入公网 OA；确需上传时必须另行定义脱敏和权限规则。
|
||
|
||
---
|
||
|
||
## 9. 财务动作
|
||
|
||
| 动作 | 前置条件 | 结果 |
|
||
| --- | --- | --- |
|
||
| 财务复核 | 报销已通过或进入财务复核节点 | 检查发票、附件、金额、项目和审批历史 |
|
||
| 重复例外 | 发现重复但业务确需报销 | 记录原单号、原因和处理人，写入审计 |
|
||
| 付款标记 | 审批通过且复核通过，且线下银行或既有财务流程已完成付款 | 写入付款批次号、付款时间、付款人、付款备注、回单摘要和状态 |
|
||
| 取消付款标记 | 发现误操作且有权限 | 必须填写原因并审计，首批可只允许管理员或财务主管 |
|
||
| 导出 | 有财务导出权限 | 按期间、人员、项目、状态导出报销和发票摘要 |
|
||
|
||
报销付款相关动作集中在 `付款`、财务处理详情或付款批次详情执行。报销列表和普通报销详情只显示付款状态、回单状态、`查看付款`、`补回单` 或进入付款记录入口，不直接放 `标记已付款`、`取消付款`、`批量付款`、`执行付款`；付款动作前必须核对金额、报销对象、线下付款说明、发票/附件证据和回单要求。
|
||
|
||
报销页的跨模块关联采用“摘要 + 跳转”：可以展示项目、采购/费用申请、合同、资产候选和付款记录的编号、名称、状态、金额/数量、负责人、证据完整性和下一步，但不在报销页复制项目管理、采购审批、合同正文下载、资产建卡或付款处理流程。需要处理时跳转到对应模块详情、审批任务或财务处理页。
|
||
|
||
导出字段至少包括：报销单号、申请人、实际报销人、部门、项目、费用类型、明细金额、发票号码、开票日期、审批状态、付款状态、提交时间、通过时间、付款批次号、付款时间、付款人、付款备注、回单状态、导出批次号、导出人、导出时间。导出是代账交接和审计摘要，不代表 OA 已生成会计凭证或写入总账。
|
||
|
||
### 9.1 电子档案与归档包
|
||
|
||
报销进入已付款或已完成后，应形成可追溯归档包。归档包不是新入口，而是报销详情、财务导出和后续审计必须能串起来的数据集合。
|
||
|
||
| 归档内容 | 要求 |
|
||
| --- | --- |
|
||
| 报销单快照 | 包含报销单号、申请人、实际报销人、部门、项目、明细、金额、状态和提交时间 |
|
||
| 发票原件 | 保留上传的 PDF 原件，不以 OCR 结果替代原件 |
|
||
| OCR 结果 | 保留识别字段、识别状态、失败原因和人工修正记录 |
|
||
| 附件 | 保留支付截图、订单、合同、聊天记录、情况说明等非发票材料 |
|
||
| 审批历史 | 保留提交、通过、驳回、退回、撤回、转审和处理意见 |
|
||
| 付款记录 | 保留付款批次号、付款人、付款时间、付款备注、回单摘要和取消付款原因 |
|
||
| 导出记录 | 保留导出批次号、导出人、导出时间、筛选条件和导出摘要 |
|
||
| 审计日志 | 保留重复例外、人工复核、附件下载、字段修正、权限变更等敏感动作 |
|
||
|
||
归档后普通员工不可修改核心字段。确需财务修正时，必须追加修正记录，不覆盖原始归档事实。
|
||
|
||
报销删除、撤回、取消、作废和归档语义遵循产品体验事实源：草稿可删除；审批中按规则撤回；业务不继续报销用取消；已支付、已归档或需要冲销留痕的异常对象用作废或追加修正记录，不物理删除；所有非草稿终止动作保留原因、操作者、时间和审计。
|
||
|
||
---
|
||
|
||
## 10. 异常规则
|
||
|
||
| 异常 | 处理规则 | 用户提示 |
|
||
| --- | --- | --- |
|
||
| 无发票 | 按费用类型判断是否允许；不允许则阻断提交 | “该费用类型需要添加发票” |
|
||
| 重复发票 | 普通流程阻断；财务例外需留痕 | “该发票已存在或已报销，不能重复添加” |
|
||
| 他人上传发票 | 阻断普通员工使用 | “该发票已被其他人员上传，请联系财务确认” |
|
||
| 金额不一致 | 提示差额，必要时阻断提交 | “发票金额与明细金额不一致，请确认” |
|
||
| OCR 失败 | 允许重试或人工录入；提交前必须满足关键字段要求 | “识别失败，请重试或手工补全信息” |
|
||
| 识别中提交 | 若关键字段未完成，不允许提交 | “发票仍在识别中，请稍后再提交” |
|
||
| 附件缺失 | 按费用类型、金额或审批要求判断 | “请补充必要附件” |
|
||
| 已付款后修改 | 普通用户不可修改；财务修正必须审计 | “已付款报销单不可修改” |
|
||
| 银行/ERP 未接入 | 页面不得显示自动支付、自动入账或已同步完成 | “请在线下银行完成付款后回填回单；代账交接按导出摘要处理” |
|
||
| 文件上传失败 | 不生成空附件或空发票记录 | “上传失败，请重新上传” |
|
||
| 通知失败 | 不影响报销提交或审批结果 | 管理员在通知记录中查看失败原因 |
|
||
|
||
---
|
||
|
||
## 11. 审批与通知边界
|
||
|
||
- 报销提交后进入 OA 统一审批中心。
|
||
- 审批动作包括通过、驳回、退回、撤回、转审和查看历史，规则以 [需求 - 统一审批中心规约](./需求-统一审批中心规约.md) 为准。
|
||
- 报销审批链、直属主管、老板/总经理、自审禁止、`manager`、`ceo`、`admin` 的角色口径，以统一审批中心规约为准；本规约不重复维护第二套审批事实源。
|
||
- 企业微信消息只包含脱敏标题、报销单号、状态和 OA deeplink。
|
||
- 消息中不得包含完整发票图片、合同正文、银行卡、身份证、敏感报价或大段说明。
|
||
- 企业微信原生审批不承载报销审批或报销附件；审批人点击企业微信消息后必须回 OA 按 OA 权限查看和处理。
|
||
- 企业微信通知失败不阻断报销提交、审批或付款标记。
|
||
|
||
---
|
||
|
||
## 12. 验收场景
|
||
|
||
### 12.1 验收数据集
|
||
|
||
后续拆开发 Issue 和自动化测试时，优先使用以下固定样例，避免每次临时造数导致验收口径漂移。
|
||
|
||
| 数据 ID | 角色/对象 | 样例数据 | 用途 |
|
||
| --- | --- | --- | --- |
|
||
| U001 | 员工张三 | 普通员工，部门为研发部，直属主管为李四 | 创建报销、查看本人单据 |
|
||
| U002 | 主管李四 | 研发主管，具备审批张三单据权限 | 主管审批、退回、驳回、转审 |
|
||
| U003 | 财务王五 | 财务角色，具备人工复核、付款、导出权限 | 发票人工复核、重复例外、付款导出 |
|
||
| U004 | 老板赵六 | 总经理角色，处理大额和高风险事项 | 大额报销、采购和合同最终审批 |
|
||
| R001 | 交通费 | 100 元，发票完整，单明细 | 低金额报销直达主管审批 |
|
||
| R002 | 办公采购 | 2000 元，含订单附件，关联项目 | 主管 + 财务复核场景 |
|
||
| R003 | 硬件采购 | 6000 元，含发票和验收附件 | 主管 + 老板 + 财务复核场景 |
|
||
| INV001 | 正常发票 | 抬头税号匹配，金额 100 元，未重复 | OCR、查重、自动匹配 |
|
||
| INV002 | 重复发票 | 与已报销发票号码相同 | 重复阻断和财务例外 |
|
||
| INV003 | 异常发票 | 抬头或税号不匹配 | 人工复核和驳回 |
|
||
| FILE001 | OCR 失败文件 | 无法识别 PDF 或未来图片 OCR 样本 | 失败重试和人工补录 |
|
||
| ATT001 | 支付截图 | 非发票附件 | 附件上传、查看、归档 |
|
||
|
||
| 场景 | 步骤 | 预期结果 |
|
||
| --- | --- | --- |
|
||
| 上传 OCR 并添加 | 员工创建草稿，上传 PDF 发票，等待 OCR 完成 | 发票从识别中变为可添加或已添加，识别字段可查看 |
|
||
| PDF 上传 | 员工上传 PDF 发票 | 文件保留，OCR 状态明确，失败时可重试或人工修正 |
|
||
| 单明细自动匹配 | 草稿只有一条明细，添加发票 | 发票自动绑定该明细 |
|
||
| 多明细金额匹配 | 草稿有多条明细，发票金额唯一匹配其中一条 | 发票自动绑定匹配明细 |
|
||
| 无法匹配创建明细 | 发票金额存在但无唯一明细 | 系统创建新明细或提示用户确认 |
|
||
| 提交审批 | 员工补齐明细、发票、附件后提交 | 报销进入 OA 审批中，生成审批历史和待办 |
|
||
| 审批通过到付款 | 审批人通过，财务复核，线下付款后标记付款 | 报销状态进入已通过或已付款，付款和回单记录可追溯 |
|
||
| 财务导出 | 财务按期间和状态导出 | 导出包含报销、发票、审批、付款和回单摘要字段，不生成总账凭证 |
|
||
| 重复阻断 | 员工上传已报销发票 | 系统阻断添加并显示可理解原因 |
|
||
| 重复例外 | 财务主管处理特殊重复票据 | 记录原单号、原因、处理人和审计日志 |
|
||
| OCR 失败处理 | 上传无法识别文件 | 显示失败原因，允许重试或人工补全 |
|
||
| 附件上传查看 | 员工上传支付截图，审批人查看 | 附件不参与 OCR 和查重，审批人可查看 |
|
||
| 移动端上传 | 企业微信或手机浏览器上传发票和附件 | 移动端无桌面宽表，上传、OCR、提交路径可用 |
|
||
|
||
---
|
||
|
||
## 13. 后续开发拆分建议
|
||
|
||
后续实现时建议按以下 Issue 拆分：
|
||
|
||
- A1：报销单字段与状态收口，覆盖草稿、提交、退回、驳回、已通过、已付款、已完成。
|
||
- A2：发票上传、OCR 状态刷新和失败重试。
|
||
- A3：发票查重与重复例外处理，覆盖 `file_sha256`、发票代码号码、数电票号码。
|
||
- A4：发票与明细自动匹配、金额不一致提示和人工修正。
|
||
- A5：附件上传、查看、删除和归档权限。
|
||
- A6：报销接入统一审批中心，覆盖 PC、移动端、企业微信 deeplink。
|
||
- A7：财务复核、付款批次、线下付款后的付款标记、回单留痕、取消付款标记和导出。
|
||
- A8：报销主链路回归脚本和 Playwright PC/移动/企业微信 UA 验证。
|
||
- A9：费用类型与材料要求矩阵落地，覆盖提交前预检和员工可理解提示。
|
||
- A10：发票合规与人工复核落地，覆盖抬头税号、数电票号码、红冲/作废人工标记。
|
||
- A11：电子档案归档包落地，覆盖报销单快照、发票原件、OCR 结果、附件、审批、付款、导出和审计追溯。
|
||
|
||
涉及发票唯一性、付款状态、审批状态机、财务权限或文件存储规则的 Issue，必须在技术方案中写明回滚策略、数据修复策略和回归范围。
|