> For the complete documentation index, see [llms.txt](https://docs.docbits.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.docbits.com/chinese/zui-zhong-yong-hu-yu-he-zuo-huo-ban/end-user-section/purchase-order-matching/automatic-purchase-order-data-matching.md).
# 采购订单数据自动匹配
Docbits 是一款先进的系统，旨在自动将采购订单（PO）数据与收到的发票文档进行匹配。该工具专为在 ERP 系统中高效管理和处理发票数据而设计。本文档介绍 Docbits 自动匹配的基本原理，并定义成功匹配所需的具体规则。
## **Docbits 自动匹配的基本原则**
**数据提取：** Docbits 首先从数字化发票文档中提取相关数据。通常，这些数据包括每个发票行项目的项目编号、数量和单价。提取的准确性至关重要，因为它是后续匹配过程的基础。
**与采购订单数据比较：** 提取的数据会与已存储采购订单中的相应信息进行比较。Docbits 会检查项目编号、数量和价格是否与采购订单中的信息相符。要成功匹配，发票中的数据必须与采购订单中的数据一致，并符合已定义的容差范围。
**自动匹配：** Docbits 根据比较结果执行匹配。系统会验证匹配条件是否在设定的容差范围内。满足这些条件时，即视为匹配成功。
**报告：** 匹配过程完成后，Docbits 会生成显示匹配状态的报告。这些报告会说明哪些发票已成功匹配，并指出存在差异的发票。
## **匹配规则的定义**
**项目编号：** 发票上的项目编号必须与采购订单中的项目编号完全一致。项目编号不允许有偏差。
**数量：** 发票中交付货物的数量可以在预定义的容差范围内有所不同。通常，可接受 ±5% 的容差，以涵盖交付数量的细微差异。
**价格：** 价格偏差在设定的阈值内可以接受。常见的容差可能为 ±2%，以接受因舍入差异或货币波动造成的轻微价格差异。
## **匹配状态：**
* **完全匹配：** 所有数据点（项目编号、数量和价格）均在设定的容差范围内。
* **部分匹配：** 一个或多个数据点超出容差范围，但偏差较小，需要人工审核。
* **不匹配：** 一个或多个数据点存在较大偏差，需要立即更正或进一步调查。
准确定义这些规则并设置容差范围，对于提高自动匹配效率和减少人工干预至关重要。Docbits 支持灵活配置这些参数，以满足不同企业和行业的需求。
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.docbits.com/chinese/zui-zhong-yong-hu-yu-he-zuo-huo-ban/end-user-section/purchase-order-matching/automatic-purchase-order-data-matching.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
