> 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/workflow/cards-overview/and/compare-with-purchase-order/promised-delivery-date-for-line-items-in-table-with-promised-delivery-date.md).
# 行项目表中的承诺交货日期
## 用途：
此工作流卡用于通过比较运算符和可配置的容差规则，验证**行项目的承诺交货日期**是否符合**采购订单上的承诺交货日期**。它支持工作流自动识别符合要求、提前或延迟的交货日期，并据此采取相应操作。
## 卡片组件：
1. **运算符**
* **说明：**\
定义如何将行项目的承诺交货日期与采购订单的承诺交货日期进行比较。
* **选项：**
* **等于 (=)：** 行项目日期必须位于容差范围内。
* **不等于 (≠)：** 行项目日期必须位于容差范围外。
* **大于 (>)：** 行项目日期必须晚于容差范围。
* **大于或等于 (≥)：** 行项目日期必须在容差范围的起始日期当天或之后。
* **小于 (<)：** 行项目日期必须早于容差范围。
* **小于或等于 (≤)：** 行项目日期必须在容差范围的结束日期当天或之前。
2. **容差天数**
* **说明：**\
指定用于计算采购订单承诺交货日期前后可接受容差范围的天数。
* **详情：**\
此值为整数，用于定义验证时采购订单日期前后各计入多少天。
3. **允许的容差天数**
* **说明：**\
定义计算容差天数时计入哪些星期几。
* **详情：**\
用户可以选择特定的星期几（例如，星期一至星期五）。计算容差范围时只计入所选日期。
### 功能：
* **条件评估：** 系统根据配置的**容差天数**和**允许的容差天数**，围绕采购订单的承诺交货日期计算容差范围。\
随后，系统使用所选运算符，将每个行项目的承诺交货日期与该范围进行比较。
* 操作执行：
* **条件为真：** 如果交货日期差异处于容差范围内，并且符合运算符设定的条件，工作流将继续。
* **条件为假：** 如果不满足条件，工作流将不会继续。
### 设置和配置：
* 选择合适的比较运算符。
* 输入容差天数。
* 选择应计入容差天数的星期几。
### 结论：
**与采购订单比较 – 行项目的承诺交货日期**工作流卡提供了一种灵活的方式来执行交货日期规则。结合运算符和按星期几计算的容差处理，它能够精准验证交货承诺，同时减少人工检查和异常情况。
---
# 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/workflow/cards-overview/and/compare-with-purchase-order/promised-delivery-date-for-line-items-in-table-with-promised-delivery-date.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.
.png?alt=media)