# 腾讯云通用票据识别接入 ERP 实录：一个接口覆盖数电票、铁路客票与航空行程单

>面向场景：小微制造业 / 商贸企业的财务与仓管岗位，每天要处理数电票、增值税发票、铁路客票、航空行程单、机动车销售发票等一堆票据，人工逐张录入又慢又容易错。本文记录我们把「拍照 → 自动识别 → 写入 ERP 单据」这条链路跑通的过程，包括选型理由、五个关键实现点和三个踩过的坑。

本文的票据识别基于 **腾讯云智能结构化 OCR**（`RecognizeGeneralInvoice` 高级版）实现，覆盖数电票、增值税发票、铁路客票、航空行程单、机动车销售发票等票种。
## 一、问题：票据类型太杂，录票是最没价值又最容易错的工作

先说清楚痛点，不然选型容易走偏。
我们服务的是制造业和商贸流通企业，票据来源大致分三类：

| | | |
|:-:|:-:|:-:|
|票据来源|典型票种|特点|
|采购与费用报销|数电票（全电发票）、增值税专票/普票|票面规整，字段多|
|员工差旅|铁路客票、航空运输电子客票行程单、出租车票|版式差异大，票种分散|
|固定资产与车辆|机动车销售统一发票、二手车销售发票|频率低但字段特殊|
人工录入每张票大约要 30–60 秒，且**错误率不低**——尤其是税号、金额小写、明细行这几处。对一个月要录几百张票的小企业来说，这是一块纯粹的时间损耗。
更麻烦的是**票种分散**：如果按票种分别调不同接口，前端就得先让用户选「这是一张什么票」。用户不一定选得对，选错就识别失败，体验很差。
## 二、选型：为什么最终用 `RecognizeGeneralInvoice`

腾讯云 OCR 提供了好几个发票类接口，我们实际对比过三个：

| | | | |
|:-:|:-:|:-:|:-:|
|接口|覆盖票种|PDF 支持|单图多票|
|`VatInvoiceOCR`（增值税发票识别）|专票、普票、电子专票/普票|❌|❌|
|`InvoiceGeneralOCR`（通用机打发票识别）|机打发票等|❌|❌|
|**`RecognizeGeneralInvoice`（通用票据识别 · 高级版）**|数电票、铁路客票、航空行程单、机动车/二手车发票、定额发票等|✅|✅|
**决定性理由是两条：**
1. **一个接口覆盖多票种，前端不需要让用户选票种。** 用户只管拍照上传，识别交给服务端分流。这一个改变直接砍掉了「选错票种导致识别失败」这类客诉。

1. **支持 PDF + 支持单图多票。** 数电票现在很多是 PDF 下发；而实务中经常出现「一张 A4 上贴了两三张票」的情况，高级版能一次返回多张票据结果，这个能力在批量报销场景里非常关键。

官方接口要点（`2018-11-19` 版本，请求域名 `ocr.tencentcloudapi.com`）：
- `ImageBase64` 与 `ImageUrl` **必须提供其一**；两个都传时**只使用 `ImageUrl`**（这点容易踩，见第 5 节坑 2）

- 支持格式：PNG / JPG / JPEG / PDF，**不支持 GIF**

- 限制：Base64 编码后 **≤ 10M**，单边像素 **20–10000px**，图片下载时间不超过 3 秒

- **识别 PDF 必须显式传 `IsPdf = true`**，`PdfPageNumber` 仅在此时有效（默认第 1 页）

- `Types` 可以指定票据类型列表；**留空则识别全部类型**——我们希望「用户不用管是什么票」，所以固定不传

- 默认频率限制：**10 次/秒**

## 三、整体链路

```

```设计上有一条原则贯穿始终：**识别结果只落草稿，不做全自动过账。** 原因在第六节说。
## 四、五个关键实现点

### 4.1 采集端：三种来源统一成一种上传格式

小程序端要覆盖三种取图路径，但**上传时统一成 Base64**，服务端就不用关心图从哪来：
```

```>注意 `chooseMedia` 的 `mediaType` 里**不要指望能选到 PDF**——PDF 必须走 `chooseMessageFile`，这是微信侧的接口分工，不是配置问题。

### 4.2 传输：PDF 一定要显式声明

服务端构造请求时，PDF 与图片的差异就在 `IsPdf` 一个参数上，但漏了它 PDF 就识别不出来：
```

```**为什么固定不传 `Types`：** 一旦指定类型，接口就按该类型处理图片，传错等于白调。我们宁可让引擎自己分流。
### 4.3 解析：返回的是「票据数组」，不是单个对象

高级版一次调用可能返回多张票据（一张图贴了多张票的情形），所以解析逻辑必须按数组处理，不能假设只有一张。
结构上，返回体里是票据项列表，每项包含票据类型标识与该张票的字段集合。解析时要做两件事：
1. **先取票据张数**，张数为 0 就直接提示用户重拍（而不是抛异常）

1. **按票据类型分支取字段**——不同票种的字段名不一样，用同一套 key 硬取必然拿空

我们用 `JavaScriptSerializer` 把 JSON 转成字典逐层取，好处是不依赖强类型模型：新增票种时不用改代码结构，只改映射表（见 4.4）。
```

```>小提醒：厂商会调整返回字段的命名与层级。**别把字段名硬编码散落在各处**，用一个「解析入口」函数统一取，字段名变了只改一处。

### 4.4 别名映射：整个链路里最容易被忽略、但最关键的一步

**这是我想重点讲的一点。**
OCR 返回的明细字段名，和 ERP 单据里的字段名，**大概率不是同一个词**。举几个我们实际遇到的：

| | |
|:-:|:-:|
|OCR 返回名|ERP 单据字段|
|交货数量|数量|
|单价（含税）|单价|
|金额|金额|
|货物或应税劳务、服务名称|商品名称|
如果直接在代码里写 `data["数量"]`，那换个票种、换个供应商模板就取不到值，只能不停加 `if`。
**我们的做法是：服务端维护一张别名映射表（`detailDisplayNames`），把 OCR 的明细名称映射到 ERP 标准字段名。**
带来的好处很实际：
- **前端不用改**：映射在服务端，票种新增或字段名变化时前端零改动

- **一份映射，多处复用**：识别结果直接映射成标准结构，写入单据的逻辑不用为每个票种写一遍

- **可运维**：映射表可以做成配置，出现新字段名不用发版

```

```>为什么不直接让用户对着 OCR 原文改？因为下游是 ERP 单据，字段名必须是系统认识的标准名。**映射层就是「机器语言」与「业务语言」之间的翻译器**，这一层不建，后面每一处调用都要各自翻译一次。

### 4.5 写入 ERP：先落草稿，键名与客户端严格对齐

识别结果最终要写进 ERP 单据。这里有个容易出错的点：**保存负载的键名必须与客户端（CS 端）保持完全一致**，否则数据会静默丢失。
我们用的结构与客户端对齐，分三层：
```

```**为什么键名必须对齐**：这是既有的数据契约，Web 端与桌面端共用同一套保存逻辑。任何一处拼写差异都不会报错，只会表现为「保存成功但字段是空的」——排查起来非常费时。
所以我们的流程是：
```

```## 五、三个踩过的坑

### 坑 1：图片识别正常，PDF 一上传就 HTTP 500，而且服务端连日志都没有

这是最费时间的一个。
**现象**：图片链路完全正常，换 PDF 必挂，返回 HTTP 500，而且**服务端日志里什么都没记**。
**排查过程**（记下来，这套路径可以复用）：

| | | |
|:-:|:-:|:-:|
|步骤|假设|结论|
|1|PDF 太大|换一个几十 KB 的单页 PDF，**照样挂** → 排除体积|
|2|PDF 格式/加密问题|换成标准未加密 PDF，**照样挂** → 排除格式|
|3|OCR 侧失败|直接调接口验证，**OCR 正常返回了结构** → 排除供应商侧|
|4|那就落在「回传」环节|请求进来了、OCR 也返回了，但客户端拿到 500 —— **问题在服务端把结果序列化回前端这一步**|
**关键判断依据**：**服务端一条日志都没有**。这说明请求根本没走到业务代码里，是在更外层的处理管线就炸了。如果是业务代码抛异常，至少会留下一条记录。这一条线索就把排查范围从「整条链路」缩到了「入口/出口的框架层」。
**根因方向**：后端用的是 ASMX / WebService 那条链路，**.NET 对 JSON 序列化有默认长度上限**。图片识别的结果小，正常回传；PDF 识别出来的结构化内容往往更大（多页、多明细行），**一旦超过默认上限，序列化阶段直接失败**，表现出来就是 500 ＋ 无日志。
**解决方向**（两条任选，或叠加）：
1. 在 `web.config` 里调高 JSON 序列化的长度上限：

```

```1. 改传输策略：PDF 识别结果不一次性回传，改为**服务端落库 + 前端按需拉取**，绕开单次响应体积限制。

**经验总结**：遇到「**不报错、不写日志、直接 500**」的情况，先怀疑**框架层的默认限制**（序列化上限、请求体上限、超时），而不是先去查业务逻辑。业务逻辑出错通常会留痕。
### 坑 2：提交上去 `fileBase64` 是空的

**现象**：小程序端明确拿到了图片，但服务端收到的 `fileBase64` 是空值。
这类问题的排查清单（按出现频率排序）：
1. **Base64 带了 Data URL 前缀**
	小程序侧拿到的可能是 `data:image/jpeg;base64,xxxx` 形式，**前缀必须剥掉**再作为 `ImageBase64` 传，否则：- 传给 OCR：解码失败
	- 存到服务端：前 20 多个字符都是前缀，真正的数据被挤掉
	```
	```

1. **字段名拼写/大小写不一致**：服务端按 `fileBase64` 取，前端传的是 `file_base64` 或 `FileBase64`——大小写敏感的场景下直接取空。

1. **请求被截断**：体积超限时部分网关会截断请求体，表现为「拿到了对象但字段为空」。

**建议**：服务端收到后**第一件事就是校验长度并记日志**（`fileBase64.Length`），这样一眼就能区分「没传到」和「传了但内容有问题」。
### 坑 3：手机原图超限 + 批量上传撞限流

两个都是上线后才暴露的问题：
**体积问题**：官方限制是 Base64 编码后不超过 10M。手机原图动辄 3–8MB，**Base64 编码后还要再膨胀约 1/3**，很轻松就超了。
处理方式：上传前先压缩，长边压到 2000px 左右、JPEG 质量 80% 上下。对票据识别来说这个分辨率完全够用（反而比原图更快更稳）。
**限流问题**：接口默认 **10 次/秒**。用户一次性选 20 张票上传，如果并发直接打满就可能被限流拒绝。
处理方式：客户端做**串行队列 + 失败重试**，一张一张来。用户体验上表现为进度条慢慢走，比一堆失败提示好得多。
## 六、边界：识别不是 100%，所以不做全自动过账

必须说清楚这一点，否则容易给出错误预期。
**识别会有误差的地方**：
- 明细行里 **数量 × 单价 = 金额** 三者不总能对上（尤其是折扣票、多税率票）

- 税率、税额在小数位上可能出现偏差

- 手写体、盖章遮挡、折叠票据的字段可能缺失

**我们的处理策略**：
1. **识别结果只落草稿**，人工在界面上确认后再保存。不做「自动生成并直接过账」。

1. **做一致性校验**：写入前用「数量 × 单价 ≈ 金额」做一次自检，明显对不上的行高亮提示，让人重点核对。

1. **缺字段不阻断**：某个字段没识别出来就留空，让人来补，而不是直接报错让整张票作废——重拍一张的时间成本比补一个字段高得多。

这个取舍的价值观是：**系统能做的是把「录入 30 秒」压缩成「核对 5 秒」，而不是取代人的判断。** 财务数据出错的代价远高于多花那几秒。
## 七、效果

跑通之后，实际改善主要有三点：

| | | |
|:-:|:-:|:-:|
|环节|之前|之后|
|用户操作|选票种 → 逐字段手填|拍照/选文件 → 自动带出字段|
|单票耗时|约 30–60 秒|约 5 秒核对|
|票种适配|每类票单独对接|一个接口覆盖，前端不用选票种|
**一个接口覆盖多票种**这一点，长期价值比省下的录入时间更大——它让「新增一种票据」从一件开发任务变成了配置工作。

面向场景：小微制造业 / 商贸企业的财务与仓管岗位，每天要处理数电票、增值税发票、铁路客票、航空行程单、机动车销售发票等一堆票据，人工逐张录入又慢又容易错。本文记录我们把「拍照 → 自动识别 → 写入 ERP 单据」这条链路跑通的过程，包括选型理由、五个关键实现点和三个踩过的坑。

腾讯云通用票据识别接入 ERP 实录：一个接口覆盖数电票、铁路客票与航空行程单

技术

云计算

人工智能

后端

腾讯云通用票据识别OCR接入ERP全记录：一接口覆盖数电票、铁路客票、航空行程单，拍照自动识别写入单据，录票从30秒降至5秒。详解选型理由、五个关键实现点及PDF序列化、Base64空值、图片超限三大坑，助力制造业/商贸企业财务高效处理多票种录入。

智能结构化

代码解释

JSON

2026上云采购 | AI焕新·智启新局

vtiv

文字识别限时特惠，新用户0.7折起


热销域名限时优惠，新客首年免费！


domain

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

腾讯云通用票据识别接入 ERP 实录：一个接口覆盖数电票、铁路客票与航空行程单-腾讯云开发者社区-腾讯云

腾讯云通用票据识别接入 ERP 实录：一个接口覆盖数电票、铁路客票与航空行程单

腾讯云通用票据识别接入 ERP 实录：一个接口覆盖数电票、铁路客票与航空行程单

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐