ARTICLE · 1160681
AI 报销助手 v2.1:员工连“传发票”都不用点了
财务效率 · 版本更新
9 月发那篇报销助手的时候，我留了个尾巴：员工还是得自己溜进金蝶，点一下「上传发票」，拿到发票云那个流水号，后面的活才交给 AI。当时我在文末写了句「这一步必须人工」。
这版把这个尾巴也掐了。员工连"传发票"都不用点了——发票发到对话框，剩下的全在服务端跑完。
这一版改了什么 👇
① 服务端上传发票：把"员工手动传"这一步换成 AI 自己传，还能拿到真流水号② 非发票文件自动进附件：行程单、说明材料不用你选，识别不出是发票就自动分流③ 项目名称不用填了：不合并生成明细时，金蝶会沿用申请单上的费用项目④ 顺手做了个网页版，申请单后面一个按钮（还在内测，见第 05 节）
更新只要一句话
已装过 把技能主页链接再发给 WorkBuddy 一次，说「更新这个技能」
没装过 直接装最新版，历史版本的那点手工步骤你不用经历
账号配置 不用重填，还是原来那份
01
上次的尾巴：为什么要员工自己传一次票
先说清楚这件事为什么难，不然你会觉得"传个文件而已有什么好写的"。
金蝶报销单上有个「收票信息」区，里面挂的不是发票照片，而是一张叫收票单的记录。这张记录上有个关键字段：发票云流水号。它的作用是防重复报销——发票云靠这个号，钉住"这张票已经被谁报过了"，一张票只能用一次。
而这个流水号，只在"采集那一刻"产生。我们实测过好几条歪路，全都不行：
所以 9 月那版只能退一步：让员工自己在金蝶里把票传一次，拿到号，剩下的识别、挂票、对金额、提交才由 AI 接手。这不是偷懒，是当时真的找不到替代路径。
02
破掉它的关键：那个按钮，本质是一次 HTTP 调用
转折点是一个很朴素的想法：员工在金蝶里点那个「上传发票」按钮时，金蝶到底干了什么？
那个弹出来让你传票的窗口，是金蝶的「发票助手」客户端。我把它拆开看了一眼——它是个 Electron 应用，说白了就是个套了外壳的网页，里面的代码是可读的。
读下来发现：它在本地啥也没干，就是拿着你的登录凭证，往发票云发了一个 HTTP 请求，把文件传上去。请求路径长这样：
POST https://api.piaozone.com/m4/fpzs/expense/upload?userKey=...
（multipart 上传，文件字段名就叫 file）
那就意味着：这个请求，服务端自己也能发。不需要开客户端、不需要员工动手。
剩下的就是验证。我用一张真发票跑了一遍，结果：
✅ 实测：服务端上传，拿号成功
返回 「查验成功」，发票号、不含税金额、税额、价税合计、购销方全对；顺带拿到 33 位流水号，还附了税局查验结果和发票原件的预览地址。
有意思的是，这个接口自带识别——你上传一张图，它把票面上的字段全给你结构化吐回来。所以连 OCR 都不用自己做，识别这一步白捡。
那"手填流水号"算不算绕过风控？
这是我自己最警惕的一点，也专门验了。不算。因为我们不是编一个号填进去，而是先用真发票走了一遍真实查验通道拿到号，再把这个真号落进收票单。
最硬的证据是这条：我在服务端上传拿到流水号之后，让人在金蝶界面上正常点了一遍「发票导入单据」，它生成的收票单上那个流水号，和我服务端拿到的一模一样，一个字符都不差。也就是说，金蝶认的就是这个号——上传的成果被它直接采用了。发票云的防重、查验机制照常生效。
一句红线：只有走真实查验通道拿到的号才允许手填。凭空编一个号，仍然是提交闸门要拦下来的东西。这个判据已经写进代码里了——拿不到真号，程序直接拒绝建票，不给你"凑合一下"的选项。
03
插曲：一个错别字，卡了我们两个月
既然要往下挖接口，就绕不开一个挡在前面两个月的老问题：发票云的生产接口连不上。
当时的现象和结论是这样的：域名在公网 DNS 里查不到记录，手动把 IP 绑到 hosts 之后，TCP 能连上，但 TLS 握手阶段被直接掐断。于是我们很自然地得出了一个看起来相当专业的判断：
这几条我都写进过文档，还当成待办在推。
后来去读客户端代码（就是上面那个 Electron 应用），翻它自己往哪发请求，才发现全篇写的是——
客户端里：api.piaozone.com（piaozone，一个 z）我们配置里：api.piazzone.com（piazzone 写成了 piazzzone，多了一个 z）
对，就是多打了一个字母。整条误会链是这么来的：
① 域名不存在 → 所以 DNS 当然查不到，我们却当成"域名没记录，要绑 hosts"
② 手动绑了 hosts → TCP 能通，但 TLS 握手时报的还是那个错名字
③ 服务器不认这个名字 → 直接把连接掐断，我们读成了"被墙 / 有白名单"
把域名改对一个字母，接口当场就通了，"查验成功"几秒钟就回来。跟墙没关系，跟白名单没关系，跟 IT 也没关系。
💡 这件事给我两个教训，也顺手做进了代码：一是 排错时先怀疑自己的配置，别急着怀疑网络和墙——「看起来最像技术难题的那个原因」，往往最贵；二是 现在这个模块只要遇到 SSL/TLS 类失败，会主动提示你先核对域名拼写，别让下一个人再花两个月。
（顺便一提：那台服务器上两个域名指向同一个 IP，"另一个也能用"这个旧结论也是错的。这个错别字当时被当成"按 SNI 拦截"写进了文档，现在全部订正了。）
04
顺手改的三处，都是被真实使用反馈逼出来的
① 项目名称不用填了
上一版建收票单时，会要一个"发票明细项目名称"（就是发票上那栏 *交通运输服务*客运服务费）。发票云不返回这个字段，所以当时是硬性要求的。
后来用户一句话点醒我：「不合并生成费用明细的话，金蝶会沿用申请单上的名称，并不是必须填的吧。」——对了。现在已经改成可选，留空就走金蝶自己的口径，不再为难人。
② 非发票文件自动进附件，不用你选
报销时你手上通常不止有发票：行程单、说明、扫描件，一堆东西。以前得你自己判断"哪个该进收票信息、哪个该进附件"——填错就是金额对不上、被驳回。
现在不用管了：一股脑传进去，系统自己分流。判据也简单——发票云的识别结果就是最好的分类器：
🔀 自动分流规则
▪ 识别成功（拿到流水号）→ 进「收票信息」，参与金额校验▪ 识别不出是发票 → 自动挂到「附件」，不参与金额▪ 网络/配置类错误 → 不悄悄转附件，直接报错告诉你（最后一条是刻意的：如果把网络故障也当成"已当附件传好"，你会以为办完了，其实什么都没发生。）
③ 一条口径说明：报销额可以大于申请额
顺便把一条容易误伤的规则写清楚：金蝶里「报销金额超出申请金额」并不必然报错。我们实测把一张"申请 10 元"的单改成报销 43.72（两张发票的合计），写入成功、业务校验也过。
所以现在的处理是提醒而不是硬拦：发票合计 ≥ 申请金额时，让你自己选按哪个口径报；发票合计 < 申请金额时，按发票金额报并告诉你差额。真正会被拦死的是另一条——报销金额大于发票合计，那是财务红线，提交前必查。
05
顺带做了个网页版（还在内测）
既然整条链路都是接口，那它就不一定非得在对话框里跑。所以我们顺手做了个网页版：
「申请单」页 列出已审核的申请单，每行一个「下推报销单」按钮
「报销单」页 状态统计 + 列表（暂存/审核中/已审核）+ 办理区
办理动作 拖入发票（可多选，自动分流）→ 按发票合计对齐金额 → 体检 → 提交
点完「下推」会自动跳到报销单页并打开那张新单，接着上传发票就行。整个办理过程一个字段都不用填——组织、金额、发票信息全是系统填的。
⚠ 如实说明：网页版目前只在本地内测，还没做公网部署。要不要开放、怎么保证安全，我还在权衡——它写的是金蝶的业务数据，和看报表不是一回事。等想清楚了再说，不着急上线。
06
更新它
已经装过这个技能的：把下面那个链接再发给 WorkBuddy 一次，说一句「把这个技能更新一下」就行。账号配置不用动，还是原来那份。
没装过的直接装最新版，前面那些"员工还得自己传票"的麻烦你不用经历。
🔗 技能主页（复制发给 WorkBuddy 即可）
https://skillhub.cn/skills/kingdee-expense-flow
或者在 WorkBuddy「专家技能连接器」的「技能」里搜「金蝶云星空报销助手」，点更新 / 安装。版本号：2.1.0。
07
最后
9 月那篇我说"员工还得自己传一次票，这一步必须人工"。当时我以为那是金蝶的限制，是绕不过去的。
现在回头看，那个"必须人工"其实有两层：一层是真的（流水号只能采集时产生），另一层是我们自己没往下挖——没去问一句"那个按钮究竟调了什么接口"。挖下去才发现，所谓"客户端才能做的事"，很多时候只是一次谁都能发的 HTTP 请求。
至于那个错别字，写完这篇我也贴在这儿了，不打算藏。做工具这件事，坑不丢人，把坑当成特性写进文档才丢人。
金蝶云星空报销助手 · v2.1.0
复制链接发给 WorkBuddy，或在「专家技能连接器」搜「金蝶云星空报销助手」
https://skillhub.cn/skills/kingdee-expense-flow
顺手说一句：如果你在用这个技能，遇到任何一处"它怎么不顺手"，都欢迎直接说。第 04 节那三处改动，全都是被真实使用反馈逼出来的。