> 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/guan-li-yu-she-zhi/settings/document-processing/export/line-items-in-export.md).

# 导出中的行项目

文档获批并导出后，行项目表的处理方式取决于导出方法。本页说明哪些列会从 DocBits 导出、哪些列是必填项，以及为什么导出的行数可能少于验证界面中显示的行数。

## 两种导出方式

| 导出方法                                                                                                                                          | 表格数据的发送内容                                                                                                                              |
| --------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| **webhook**、**watcher**、**sftp**、**infor\_sftp**（JSON / XML）                                                                                  | 与验证界面中相同的表格：每一行中所有未隐藏的[表格列](/chinese/guan-li-yu-she-zhi/settings/global-settings/document-types/table-columns.md)，包括值、格式化后的值和置信度。      |
| **infor-m3-cloud**、**infor-m3-toml-cloud**、**infor-idm-**\*、**infor-gls840-onpremise**、**infor-m3-oc-charges-onpremise**（Infor ERP / SAP BOD） | 不是原始表格。DocBits 会根据表格生成**收货行**和**成本行**（见下文），并按照[导出到 Infor](/chinese/infor-ji-cheng-yu-pei-zhi/exporting-to-infor.md)中配置的映射将其映射到 BOD 字段。 |

## 收货行和成本行（Infor 导出）

ERP 发票行可以是**收货行**（结算采购订单收货），也可以是**成本行**（将金额记入带维度的总账科目）。DocBits 会针对每条发票行进行判断：

* **收货行**来自**采购订单匹配**。每条与采购订单行匹配的发票行（在 Dashboard → PO Match 中匹配，或通过 *PO auto match* 自动匹配）都会成为一条收货行，其中包含采购订单号、采购订单行、收货行，以及匹配的数量和金额。没有匹配采购订单的发票**不会生成收货行**，因此导出预览会显示 `receipt_lines: []`。这是正常情况，并非错误。
* **成本行**来自成本核算步骤（或 Auto Accounting）创建的**会计记录**，其中包含总账科目、维度、金额和每行数量。没有会计记录的发票不会生成成本行。
* **税行**根据抬头税额生成，而不是根据表格生成。

因此，对于 Infor 导出，行项目表是采购订单匹配和会计处理的\_输入\_；ERP 收到的是这两个步骤的处理结果。未匹配采购订单或未进行会计处理的行不会发送到 ERP。

{% hint style="warning" %}
要使采购订单匹配正常工作，表格必须包含默认列**物料编号、单价、数量和总金额**。如果其中任何一列被隐藏，验证界面就会显示 *Line Item Table is missing Mandatory column for PO*，并且无法生成收货行。
{% endhint %}

## 必填列和审批对话框

文档获批之前，DocBits 会检查表格：

1. 标记为 **Is Required**（设置 → 文档类型 → 表格列）的每一列，在每一行中都必须有值。
2. 每一行都必须通过**行总额检查**：在误差范围 0.02 内满足 `total = quantity × unit price + charges − discount`。未通过检查的行会被标记，并显示预期值和实际值。
3. 系统会将**行总额之和**与抬头中的净额进行比较。差异会显示为警告，但不会阻止审批。

审批对话框会列出尚未满足的项目。管理员可以在每种文档类型的设置中通过 **Skip table validation**（文档类型 → 更多设置）关闭所有表格检查；此后不再检查行总额和必填列，但仍会执行抬头检查。

有关这些消息的详细说明，请参阅：[表格提取故障排除](/chinese/gai-shu-yu-ji-chu/faq/document-processing/table-extraction-troubleshoot.md#messages-on-the-table)。

## 空表格

* **JSON / XML 导出**会发送包含 `tables: []` 的文档（或包含零行的表格）。接收系统必须能够处理空表格。
* 没有收货行且没有成本行的 **Infor 导出**只会发送抬头和税行。大多数 ERP 会拒绝没有行项目的发票；请为此类文档类型配置 Auto Accounting 或默认成本行，或者将其路由到其他导出方式。
* **没有表格的**文档类型（未配置表格）不会发送行数据；这是预期行为，例如在抬头级别进行匹配的订单确认单。

## 审批前检查

拥有 API 或 MCP 访问权限的合作伙伴和支持人员可以在文档发送之前请求其导出负载：MCP 工具 `get_export_preview(doc_id)` 会准确返回即将发送的导出内容。对于 Infor 导出，内容包括 `receipt_lines`、`cost_lines` 和 `tax_lines`；对于 JSON 导出，则包括 `tables`。当 ERP 报告缺少行时，可以使用此工具进行排查：如果 `receipt_lines` 为空，说明发票未与采购订单匹配；如果 `cost_lines` 为空，说明不存在会计记录。

## 相关页面

* [导出](/chinese/guan-li-yu-she-zhi/settings/document-processing/export.md)：导出配置和方法
* [表格列](/chinese/guan-li-yu-she-zhi/settings/global-settings/document-types/table-columns.md)
* [导出到 Infor](/chinese/infor-ji-cheng-yu-pei-zhi/exporting-to-infor.md)：收货行、成本行和税行的 BOD 字段映射


---

# 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/guan-li-yu-she-zhi/settings/document-processing/export/line-items-in-export.md?ask=<question>&goal=<user_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.