通过你自己的 REST API 检查并分流供应商发票

通过你自己的 REST API 检查并分流供应商发票

一个 n8n 工作流，检查一张供应商发票，并把它送到该去的地方。一个 webhook 接收发票文件的名字。你的提取服务读取文档，工作流再把结果和你的供应商清单、未结采购订单做比较。然后它入账、开审核工单或通知应付账款，并用结果回答 webhook。

这个工作流只有规则和分流，别的都没有。里面没有 AI 模型，也没有账务系统。每个外部系统都是对你自己的 API 发出的普通 HTTP 请求，所以你要提供这个 API，或者把每个请求换成你自己系统的节点。

包里有什么

• workflow.json：n8n 导出的工作流，18 个节点，其中 16 个会运行，两个是便签。里面没有任何凭据。
• README.md：这份设置说明，压缩包里的是英文版。

我们相对原来的副本改了什么

• 两个 Config 节点里的地址 https://api.your-company.example 现在是 https://<YOUR_API_HOST>。
• 两张便签不再写模板作者的名字，也不再链接到它的网站。它们也不再说提取这一步可以调用 base/llm/complete 上的模型，因为这一步调用的是 base/documents/extract。便签现在说明节点做什么，并让你保存后点 Publish，而不是“Activate”。
• 别的都没改。规则、阈值和分流都和原来一样。

开始之前

• 一个 n8n，n8n Cloud 或你自己的服务器都行。原来的便签要求 n8n 1.100 或更高版本。
• 一个能回答下面六个路径的 API，或者能连到你自己系统的其他 n8n 节点。
• 一条邮箱规则、一个 Drive 监视器或一个上传表单，能向 webhook 发一个 POST。
• 几张用来试验的发票。

工作流调用的路径

每个路径都是对 Config 里的 base 地址发出的。这些节点没有设置认证，请按你的 API 的要求给每个节点加上。

• POST /documents/extract，请求体是 { "file_name": "...", "mime": "application/pdf" }。它必须回答 { "fields": { supplier, invoice_no, date, trn, subtotal, vat, total, currency, confidence, line_items: [{ amount }] } }。
• GET /accounting/suppliers。它必须回答 { "rows": [{ supplier_name, trn, approved_limit_aed }] }。
• GET /accounting/purchase_orders。它必须回答 { "rows": [{ po_number, supplier, amount }] }。
• POST /accounting/bills，带上检查过的发票。它必须回答 { "bill_id": "..." }。
• POST /review/queue，带上文件、状态和原因。它必须回答 { "ticket": "..." }。
• POST /alerts，带上一个频道和一段文字。任何回答都行。

设置

1. 在 n8n 里新建一个工作流，打开它的菜单，选 Import from File，选中 workflow.json。
2. 打开 Config，把 base 里的 <YOUR_API_HOST> 换成你的 API 的主机。检查 auto_approve_limit、ap_channel 和 total_tolerance。Config (errors) 里的 base 也同样处理。
3. 给六个 HTTP Request 节点各自加上你的 API 需要的认证，或者把它们换成你自己系统的节点。
4. 打开 Code 节点 Validate: TRN, duplicate, totals, PO match, limit，检查规则。增值税率是 5%，TRN 必须是 15 位数字，置信度下限是 0.9，限额以 AED 计。
5. 保存，点画布顶部的 Publish（或按 Shift+P），然后复制 Webhook 的地址。把你的邮箱或上传表单指向它。拿到这个地址的人都能向它发请求，所以请保密。
6. 在工作流设置里，选这个工作流作为错误工作流，这样 Error trigger 才会在运行失败时发警报。
7. 发一张干净的发票和一张总额有误的发票，各读一下回答。

一次运行的过程

1. Webhook: invoice received (email, drive or upload) 接收一个请求体里带 file_name 的 POST。
2. Config 加上 base 地址、自动批准的限额、警报频道和总额的容差。
3. AI: extract fields from document 把文件名发到你的提取路径，取回各个字段。
4. Accounting: supplier master 和 Accounting: open purchase orders 取回两份清单，Merge lookups 把它们合在一起。
5. Validate: TRN, duplicate, totals, PO match, limit 运行下面列出的规则，设出一个状态和一串原因。
6. Route by status 把 AUTO_APPROVE 送到 Accounting: post bill，把 REVIEW 送到 Review queue: human check，把 REJECT 送到 Slack: rejected, AP notified。
7. Outcome 做出一个简短的回答，里面有状态、原因，以及账单 ID、工单或警报标记。
8. Respond 200 (invoice handled) 把它返回给调用方。

任何一步失败时，Error trigger 会启动 Config (errors) 和 Alert ops (Slack)，后者向 /alerts 发一条消息。

规则和它们的代码：

• V-00：缺少供应商或发票号。审核。
• V-01：之前见过同一个供应商和同一个发票号。拒绝。
• V-02：供应商不在主数据里。审核。
• V-03 和 V-04：TRN 不是 15 位，或和主数据不一致。拒绝。
• V-05：明细行加起来和小计不符，超出容差。审核。
• V-06：总额不是小计加 5%，超出容差。审核。
• V-07：提取的置信度低于 0.9。审核。
• V-08：总额超过自动批准的限额，又没有匹配的采购订单。审核。
• V-09：总额超过这个供应商自己的限额，又没有匹配的采购订单。审核。

改变样子

• 限额和警报频道：Config。
• 任何规则、增值税率、TRN 的长度或置信度下限：Code 节点 Validate: TRN, duplicate, totals, PO match, limit。
• 路径和它们背后的系统：HTTP Request 节点，或者替换它们的你自己的节点。
• 调用方收到什么：Outcome 和 Respond 200 (invoice handled)。
• 失败发到哪里：Alert ops (Slack)。

值得知道的

• 未运行：Mindket 没有调用过任何 API。它在自己的机器上用示例发票运行了校验代码，并核对了上面的每条规则。
• 这里没有任何东西会自己提取内容。提取路径只收到一个文件名和固定的 application/pdf 类型，所以你的服务必须能按名字找到文件，而且每个文件都被当作 PDF。
• TRN 的长度、增值税率和 AED 限额都写在代码里。依赖这些检查之前，请按你所在的国家改掉它们。
• 重复检查把清单放在工作流的静态数据里。按 n8n 的文档，手动运行工作流时静态数据不会保存，只有由触发器或 webhook 运行的已发布工作流才会保存。这份清单也从不缩短。
• 送去审核的发票算作已见过。修好之后再发一次，会被当作重复而拒绝，所以请在你的审核队列里改正它。
• webhook 没有认证。知道地址的人都能发文件名，让账单被入账，所以请保护它。
• 每条规则都通过时，账单是自动入账的。请先在测试系统上试。
• 错误工作流的设置：n8n 的文档把错误工作流描述为以 Error Trigger 开头的工作流，没有说工作流能不能指定自己。请让一次运行失败来测试。
• 你的数据：文件名和发票字段只会发到你放在 base 里的那个 API。
• 凭据：JSON 里没有任何凭据。