> 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/validation-screen/header-field-check.md).

# 页眉字段检查：数据来源

了解页眉字段的值来自哪里，以及它是如何生成的——此处说明验证屏幕上的“页眉字段检查”。

验证屏幕上的 **页眉字段检查** 按钮位于 **保存** 旁边。点击后会打开报告 *每个值来自哪里？*：对于每个页眉字段，报告都会显示文档上的原始内容、值在处理过程中经历的变化、DocBits 当前显示的内容以及原因。

本页说明值是如何生成的，以及每种来源代表什么。无需具备专业知识。

{% hint style="info" %}
页眉字段检查属于 **分析** 模块。如果按钮显示为灰色，管理员可以在 **设置 › 角色** 中为你的角色授予相应权限。
{% endhint %}

## 值始终按以下顺序生成

| 步骤        | 发生的情况                              |
| --------- | ---------------------------------- |
| **1. 读取** | 从文档中读取值——通过训练规则、AI，或直接从电子发票读取。     |
| **2. 转换** | 客户的脚本和转换规则会更改读取到的值，例如缩短、添加内容或调整格式。 |
| **3. 查找** | 在主数据中搜索该值。如果找到记录，主数据记录会替换读取到的值。    |
| **4. 显示** | 用户只会看到结果。页眉字段检查会显示处理过程中发生的变化。      |

步骤 2 和步骤 3 并非每次都会执行，但执行时会改变值。大多数反馈的问题都出在这两个步骤。

## 来源——每种来源的含义

这些图标与报告 **操作** 列以及顶部筛选栏中的图标相同。

### 训练规则

DocBits 会记住此类文档中的字段位置，因为有人曾在该位置标记过字段。

* **示例：** 供应商“Bornemann”——始终位于左上方的同一位置。
* **如果值有误：** 在文档上标记正确位置并保存，规则便会从中学习。

### AI

没有固定模式。AI 会像人一样读取文档，并自行判断哪些文本属于哪个字段。

* **示例：** 发票日期、金额、付款条件。
* **如果值有误：** 更正该值。可在 **设置 › OCR 页眉字段** 中启用或停用此功能。

### 电子发票

对于 XRechnung 或 ZUGFeRD，无需识别任何内容：该值本身就是文档中的数据字段，会直接读取。

* **示例：** 从发送方的 XML 字段读取发票编号。
* **如果值有误：** 错误来自发送方。DocBits 会准确显示该值来自哪个 XML 字段。

### 脚本 / 转换规则

读取完成后，客户逻辑会介入并重塑该值。文档内容不变，但值会改变。

* **示例：** `1001 / LS 206776` 变为 `1001`。
* **如果值有误：** 不要在文档上查找原因。请检查 **设置 › 脚本** 或 **转换规则**。

### 主数据

在你自己的数据（例如订单、供应商）中搜索读取到的值。匹配成功后，会用匹配项替换该值，并连带带入其他字段。

* **示例：** `1001` 匹配到订单 `06O051001`，随后供应商和采购方信息也会从该订单带入。
* **如果值有误：** 检查 **设置 › 查找配置**。其中说明了搜索是精确匹配，还是也接受部分匹配。

### 计算

不是读取出来的值，而是根据其他字段计算得出。

* **示例：** 根据发票日期和付款条件计算到期日。
* **如果值有误：** 通常是用于计算的某个字段有误。

### 条形码

从文档上的条形码或二维码读取。

* **示例：** 发票编号编码在二维码中。
* **如果值有误：** 检查文档类型的条形码设置。

## 最容易被误解的一点

{% hint style="warning" %}
当字段突然出现一个文档上看不到的值时，几乎从来不是 AI 导致的，而是步骤 2 或步骤 3。最常见的原因是主数据匹配也接受部分匹配：`1001` 匹配到 `06O051001`，随后供应商也会随匹配到的订单一起改变。
{% endhint %}

在报告中，此类字段会标为红色。**操作** 列会显示主数据记录，并附带红色的 *仅部分匹配* 标记，同时高亮显示匹配到的值部分。

## 阅读报告

* 顶部的 **状态标记** 会统计值从文档中原样读取、在处理过程中发生变化，或未按显示内容出现在文档中的字段。点击标记可仅显示相应字段；再次点击可显示全部字段。
* **来源筛选器：** 图标行会显示所有提取方式。点击某个图标，仅显示经过该方式处理的字段。
* **操作：** 显示值经历的每个步骤，以及对应来源的图标。当前值的来源步骤会高亮显示。将鼠标悬停在步骤上，可查看该步骤执行的操作及值的变化。
* **原因：** 显示字段的状态。点击 (i) 图标可了解该值形成的原因。
* 长值会缩短显示为 …；将鼠标悬停即可查看完整值。


---

# 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/validation-screen/header-field-check.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.