xParse单据勾稽台

仓库三张单据的数字对不上，我做了个网页自动勾稽

螺纹钢短了 0.8 吨。验收单上签了字，货已经上架，月底算账才发现，供应商那边不认了。

做仓储系统交付那几年，这种场面见过不少。入库单管收货、出库单管发料、盘点单管对账，三张单记同一批货，走三个流程。单号不一样，格式不一样，列名也不一样：入库单写「应收／实收」，出库单写「现存／本次出／结存」，盘点单写「账面／实盘」。仓管员只能把单子摊在桌上，一行行比。对漏一处，后面全跟着错。

比赛开放选题之后，我把这件一直想做的事做了出来，名字叫单据勾稽台。三张单拍下来拖进网页，它按物料编码并成一本台账，逐项比数量，把对不上的地方挑出来。

在线体验：单据勾稽台 · TextIn xParse

它做什么

仓管员把三张单拍下来拖进页面。xParse 把每张单读成带表格结构的数据，工具按物料编码把三张单并成一条台账，逐项比较应收与实收、本次出库与结存、账面与实盘。四种差分开报：入库短了报短尺，出库超了报超发，账实不符报盘盈亏，两本账不符报两账差。正常清零的、库存偏低的、单号缺失的另外列，不跟异常混在一起。结论按「需处理 → 待确认 → 通过」排序，每条带单据名和行号，点开能回到原件那行核对

和进销存软件的区别

仓库里装的进销存软件管的是「这张单怎么录进去」。我要解决的是「这几张单之间对不对得上」，两本账的差落不到任何一张单内部，只看盘点单，只知道账实差了 8 把；三张单放一起，才知道这 8 把已经发出去、实物还在客户手上。出库单说发出去了，盘点说实物没动。这两条得一起看，缺一条都会得出错误处置。

怎么搭的

工具是一个 HTML 文件，CSS 和 JavaScript 都写在里面。没有后端，没有构建步骤，双击就能跑。选单文件不是为了炫技，仓库现场的电脑装什么浏览器、能不能连外网都不确定，一个文件拷过去就能开，省掉部署环节。解析走 xParse 的同步接口，浏览器直连api.textin.com，上传的单据不经任何第三方服务器，解析完就从内存释放。

POST https://api.textin.com/api/v1/xparse/parse/sync x-ti-app-id: <App ID> x-ti-secret-code: <Secret Code> Content-Type: multipart/form-data ​ file: 单据文件 config: {"capabilities":{"include_table_structure":true,"title_tree":true, "include_hierarchy":true,"include_inline_objects":true}}

config 里include_table_structure是关键开关。不开这个拿不到表格，而工具读的正是返回 markdown 里的<table>块。

表格不是普通 HTML 表格

这点一开始想错了，我以为拿回来的就是普通 HTML 表格。xParse 返回的表格元素走table_structure.cells[]，每个单元格带row、col、coordinates，知道这件事之后，才能把每条差异定位到具体哪一行，做到单元格级溯源。

数字会被拆成两截

实测里出现过60 %(3 /5和YC -2026 -0319，同一张单上的编号被当成两个值。清洗放在取数之前、合并之前，先去掉数字中间的空格和逗号，42 . 5还原成 42.5。少了这一步，同一张单上的编号会被当成两笔货，后面的合并全部错位。

最费时间的是一个静默失败

把密钥写进代码的时候，对象用了secret这个键名，读取的地方写的却是sec：

const __K = {app: XPARSE_KEY.app, secret: XPARSE_KEY.secret}; if(!__K.app || !__K.sec){ toast('请先配置密钥'); return; } // __K.sec 永远是 undefined

结果每次上传文件都在这里返回了，请求根本没发出去。没有报错，没有异常，日志只打两行就停住。这种坑最难查，因为表面上看「密钥都在代码里写着」，不像有问题。最后把判断条件拆成单项布尔值打印出来才定位到：secVal有 32 位字符串，notSec却是true。同一个值既存在又不存在，只能是属性名写错了。

一处设计上的取舍

结存不从流水反推。入库会分批，也可能有跨期没入账的条目，用出入库流水反推结存，差额来自反推口径，跟单据本身对不上，人去查反而更费劲。工具把出库单上那一列当锚点，比的是「出库单结存 vs 盘点账面」。盘点单自己再比「账面 vs 实盘」。两本账的差和盘盈亏分开报，混成一个结论，处理人就不知道该找谁。

用起来是什么样

点「载入内置示例」，页面在几秒内读出三张单：入库单 6 行明细、出库单 5 行、盘点单 5 行，合计 16 行、5 个物料。勾稽给出 14 项结论：6 项通过、5 项需处理、3 项待确认。

拿活动扳手举例。出库单上现存 0、本次出 8、结存 −8，结存成了负数，工具报出库超发 8 把。盘点单上账面 0、实盘 8，账面上没有这批货，工具报盘盈 8 把。两本账一比，差 +8。只看出库单会以为发多了，只看盘点单会以为凭空多出来一批货，两条放一起才对上：「货发出去了，回单还没签」。

再看螺纹钢，同一个物料报出三条不一样的结论：

三处差异性质不同。合并成一句「螺纹钢有问题」，处理人就不知道该找谁。第一处要走索赔，第三处要走内部审批，流程完全不一样。

实测数据

2026 年 10 月，用一份仿真单据文件跑真实接口：

元素类型分布：Header6 个、NarrativeText15 个、Table9 个、Image3 个。9 个表格里，真正参与勾稽的是 3 张数据表，其余是签字栏和备注区，靠表头是否含「物料编码」或「品名规格」加「单位」筛掉。

在线体验

单据勾稽台 · TextIn xParse

打开就能用，密钥已经内置，不用注册也不用填。想试自己的单据，直接拖进去。不想消耗解析额度，点「载入内置示例」也能看到完整效果，示例是真实解析结果，不是写死的假数据。

它做不到什么

工具算的是单据表面上的数字，不构成财务结论，也不构成法律结论。单据本身印错了数字，工具照印出来的算，判断不出「这张单本身是错的」。同一物料有多个批次或多个货位时，工具按物料编码合并，不区分批次。单据被遮挡、折叠、扫描质量差导致识别出错时，工具不会判断自己认错没有。这几种情况得人工核。工具能省掉的是逐行对照的机械劳动，不是判断责任。

最后

整个作品是一个 HTML 文件，无后端无依赖，浏览器直连 xParse。造素材、写代码、跑验证都在 WorkBuddy 会话里完成，素材是用 Chromium 打印功能合成的 3 页仿真单据，含表头、审批签字栏、质检意见和备注行。有做仓储系统的朋友或者对单据勾稽这类场景有兴趣的，欢迎评论区聊聊。

#TextIn 、#AI数据层基础设施；