实现腾讯通用票据OCR安全适配（07-28-travel-reimbursement-guide）
这个提交包含在：
+15
@@ -49,6 +49,21 @@
|
||||
- OAOPS1 期间请用真实业务数据完成报销、采购/费用、合同台账和项目关联；遇到提交、审批、付款、导出或权限阻断时，记录页面、步骤和影响等级，让管理员当天建修复合同或暂停对应流程。
|
||||
- OALAUNCH1 收口期内，请把真实业务问题按“阻断 / 非阻断 / 建议”告诉管理员；不要只在聊天里说“系统有问题”。阻断包括无法提交、无法审批、付款/AP 无法闭环、越权可见、合同或资产敏感信息泄露、备份恢复或导出证据缺失。
|
||||
|
||||
### 差旅报销一页指南（火车票 + 住宿费）
|
||||
|
||||
1. 从企业微信工作台进入海音达工作台，打开 `报销`，新建报销单。
|
||||
2. 把费用拆成两条明细，不要合并填写：
|
||||
- 火车票：费用类型选“火车票”，填写乘车日期、个人实际支付的合规金额和事由，例如“项目出差往返高铁”。
|
||||
- 住宿费：费用类型选“住宿费”，填写实际住宿日期、个人实际支付的合规金额和事由，例如“项目出差住宿”。
|
||||
3. 在每条明细的“添加发票”入口上传对应的官方 PDF：火车电子票据 PDF 绑定火车票明细，住宿电子普通发票 PDF 绑定住宿费明细。每个 PDF 只放一张票据、只识别第一页，单个文件不能超过 7 MiB；图片、照片和支付截图不能当作正式发票上传。
|
||||
4. 火车票和住宿费都必须另附个人支付截图。支付截图通过整张报销单的“上传附件 / 补充材料”入口上传，并在文件名或说明中写清对应“火车票”还是“住宿费”。
|
||||
5. 支付截图应看得出商户、金额、支付时间和支付成功状态；银行卡号、支付账号、订单号等与复核无关的信息先遮挡。
|
||||
6. 明细金额填写个人实际支付的合规金额，原则上不得超过有效发票金额。使用优惠券、多人合并开票、部分自费或发票金额与实际支付金额不一致时，必须在明细说明中写清原因。
|
||||
7. 已退款、公司直接支付或他人承担的金额不能再次报销。确实无法提供支付截图时，上传情况说明，由财务决定退回还是例外接受，不得补造凭证。
|
||||
8. 提交前逐项检查：两条明细、两份对应 PDF、两类支付证明和金额说明都已齐全。提交后由直属主管审批、财务复核；实际付款和付款回单由财务处理，员工不预填。
|
||||
|
||||
OCR 会辅助识别发票字段和查重，但不代表系统已经确认费用真实合规。财务仍会同时核对明细金额、PDF 原件和个人支付证明；三者不一致时会退回补充或更正。
|
||||
|
||||
## 7. 入职 / 离职时你会看到什么
|
||||
- 入职时 HR 会优先在企业微信/人事助手维护人员资料，OA 后续同步生成账号、角色和绑定。
|
||||
- 离职前需要归还固定资产，并交接自己负责或保管的电子资料、系统、代码仓库和备份资产；企业微信和 OA 的账号状态会按流程同步停用或禁用。
|
||||
|
||||
+18
@@ -38,12 +38,16 @@ R5 公网验收后确认：正式发票/OCR 上传入口只接受 PDF 发票文
|
||||
## 上传与 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`。
|
||||
@@ -127,6 +131,20 @@ R5 公网验收后确认：正式发票/OCR 上传入口只接受 PDF 发票文
|
||||
- 报销页只显示付款状态、回单状态、查看付款或补回单入口；标记已付款、取消付款、批量付款和执行付款必须进入付款/财务处理详情，不能放在报销列表或普通报销详情里直接执行。
|
||||
- 报销页展示项目、采购、合同、资产候选或付款记录时只显示摘要和跳转，不复制对方模块的审批、付款、合同正文下载、资产建卡或高敏附件操作。
|
||||
|
||||
## 差旅实报实销与支付证明
|
||||
|
||||
首笔差旅报销按“明细—正式发票—个人支付证明”三方对应复核，当前火车票和住宿费执行以下规则：
|
||||
|
||||
- 火车票和住宿费必须拆成不同明细，分别选择生产已有的“火车票”和“住宿费”费用类型，填写发生日期、个人实际支付的合规金额和事由。
|
||||
- 火车电子票据、住宿电子普通发票等正式票据必须使用官方 PDF，从对应明细的发票入口上传并绑定；发票截图、支付截图或拍照图片不得冒充正式发票。
|
||||
- 火车票和住宿费均必须提供个人支付截图。支付截图属于整张报销单的补充附件，不绑定到发票记录；文件名或附件说明必须能对应到具体费用明细。
|
||||
- 支付截图保留商户、金额、支付时间和支付成功状态即可；银行卡号、支付账号、订单号等与审批无关的信息应先遮挡，不要求员工提供完整支付账户或银行流水。
|
||||
- 明细金额以员工个人实际支付的合规金额为准，原则上不得超过有效发票金额。优惠券、多人合并开票、部分自费、票面金额与实付金额不一致等情况必须在明细说明中写明差异。
|
||||
- 已退款、公司直接支付或由他人承担的金额不得重复报销。发生部分退款时，只能申报扣除退款后的个人实际承担金额，并附情况说明。
|
||||
- 确实无法提供支付截图时，员工必须上传情况说明；财务可以退回补充，也可以在有其他充分证据时例外接受并留痕。不得伪造、补造或借用他人支付凭证。
|
||||
- OCR 只辅助识别发票字段、匹配和查重，不判断支付真实性、费用合理性或发票法律状态。财务复核时必须同时查看明细金额、PDF 原件和个人支付证明；三者不一致时退回更正或补充说明。
|
||||
- 财务付款凭证号、付款日期、付款渠道和付款回单属于审批通过后的财务处理，不是员工提交报销时填写的个人支付证明。
|
||||
|
||||
## PC 与手机体验
|
||||
|
||||
PC 端：
|
||||
|
||||
在新工单中引用
屏蔽一个用户