> 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/condition-cards-complete-guide.md).

# 条件卡片 - 完整指南

## 条件卡片 - 完整指南

\*\*涵盖：\*\*剩余的 31 个条件卡片

***

本页中的条件卡片位于工作流构建器的 **When** 和 **And** 组中，用于决定是否运行 Then 操作：

<figure><img src="https://1870485400-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlPczlNw8zzYNLfjfispX%2Fuploads%2Fgit-blob-11ce06578b5d0bd3c75de5b078b38ce1a85ef74e%2Fworkflow_designer_cards.png?alt=media" alt="工作流构建器画布，包含 When、And 和 Then 卡片组"><figcaption><p>通过 <strong>Add Card</strong> 将条件卡片添加到 <strong>When</strong> 和 <strong>And</strong> 组。</p></figcaption></figure>

***

### 📌 版本信息

\*\*状态：\*\*大多数条件卡片都很稳定，采用单版本或双版本结构。\*\*版本模式：\*\*大多数卡片遵循 v1 → v2 模式（添加 i18n 支持）。\*\*多版本示例：\*\*CONDITION\_DECISION\_TREE\_DATA（v2-v3）

\*\*注意：\*\*某些采购订单比较条件卡片有多个版本。请参考本指南了解当前行为，并参考下方发行说明了解已发布的变更。

📖 [产品发行说明](/chinese/gai-shu-yu-ji-chu/release-notes.md) | [采购订单匹配指南](/chinese/guan-li-yu-she-zhi/workflow/cards-overview/po-matching-complete-guide.md)

***

## 文档状态与状态条件

### 卡片：CONDITION\_DOC\_STATUS\_IS\_ISNOT / 文档状态检查

#### 用途

检查文档是否处于特定状态

#### 使用场景

* 审批前
* 工作流的特定阶段
* 基于状态进行路由

#### 文档状态类型

```
- Upload：正在上传
- OCR：正在扫描
- Classification：类型检测
- Ready for Validation：等待验证
- Workflow：处理中
- Pending Approval：需要审批
- Pending Second Approval：需要二次审批
- Auto Accounting：自动记账
- Export：正在导出
- Error：发生问题
```

#### 工作方式

```
当前状态: "Pending Approval"
    ↓
检查: 状态是否 = "Pending Approval"?
    ↓
是 → 继续执行操作
否 → 停止或执行其他操作
```

#### 示例

```
条件: "文档状态是否为 Pending Approval?"
    ↓
如果是: 创建审批任务
如果否: 执行其他操作
```

#### 参数

```
运算符: IS / IS NOT
状态: [选择状态]
```

***

### 卡片：CONDITION\_DOC\_STATUS\_IS\_ISNOT\_IN\_LIST

#### 用途

检查状态是否与列表中的任一状态匹配

#### 使用场景

* 有多个有效状态时
* 对状态使用 OR 逻辑

#### 示例

```
条件: "状态是否为以下之一: [Pending Approval, Pending Second Approval, Workflow]?"
    ↓
如果状态与任一项匹配: 继续
如果不匹配: 停止
```

***

### 卡片：CONDITION\_DOC\_TYPE\_IS\_ISNOT / 文档类型检查 <a href="#condition-doc-type-is-isnot" id="condition-doc-type-is-isnot"></a>

#### 用途

检查文档是否为特定类型

#### 文档类型

```
- 发票
- 贷项通知单
- 采购订单
- 交货单
- ASN (Advanced Ship Notice)
- 收货单
- 退货单
- 自定义类型
```

#### 工作方式

```
文档类型: "Invoice"
    ↓
检查: 类型是否 = "Invoice"?
    ↓
是 → 按发票处理
否 → 采用其他方式处理
```

#### 示例

```
条件: "文档类型是否为 Invoice?"
    ↓
如果是: 检查采购订单匹配情况
如果否: 跳过采购订单验证
```

***

### 卡片：CONDITION\_DOC\_TYPE\_IS\_ISNOT\_LIST

#### 用途

检查类型是否与列表中的任一类型匹配

#### 示例

```
条件: "类型是否为以下之一: [Invoice, Credit Note]?"
    ↓
是: 处理财务文档
否: 跳过财务检查
```

***

### 卡片：CONDITION\_SUB\_ORG\_IS\_ISNOT / 子组织检查

#### 用途

检查哪个组织或部门拥有该文档

#### 组织

```
- 财务部
- 采购部
- 仓库
- 制造部
- 质量控制部
- 配送部
- 区域办公室
```

#### 示例

```
文档所属组织: "Berlin Office"
    ↓
检查: 子组织是否 = "Berlin Office"?
    ↓
是: 分配给柏林团队
否: 检查其他办公室
```

***

### 卡片：CONDITION\_PURCHASE\_ORDER\_IMPORT / 采购订单导入检查

#### 用途

检查采购订单是新导入的还是已存在的

#### 工作方式

```
采购订单状态: "Newly Imported" (首次遇到此采购订单)
    ↓
检查: 是否为新导入的采购订单?
    ↓
是: 执行初始验证
否: 使用缓存的采购订单数据
```

#### 使用场景

* 对新采购订单进行不同处理
* 跳过已知采购订单的验证
* 跟踪首次出现的供应商

***

## 受派人条件

### 卡片：CONDITION\_USER\_IS\_ISNOT / 用户检查

#### 用途

检查文档是否分配给特定用户

#### 工作方式

```
分配给: "John Smith"
    ↓
检查: 是否分配给 "John Smith"?
    ↓
是: 继续
否: 停止
```

#### 示例

```
条件: 是否满足 "Assigned to IS 'Finance Manager'"?
    ↓
如果是: 创建审批任务
如果否: 跳过审批
```

***

### 卡片：CONDITION\_USER\_IS\_ISNOT\_IN\_LIST

#### 用途

检查文档是否分配给列表中的任一用户

#### 示例

```
条件: "是否分配给以下人员之一: [John, Sarah, Mike]?"
    ↓
是: 继续
否: 停止
```

***

### 卡片：CONDITION\_GROUP\_IS\_ISNOT / 用户组检查

#### 用途

检查文档是否分配给特定用户组

#### 示例

```
分配给: "Finance Team" (10 名成员)
    ↓
检查: 是否分配给 Finance Team?
    ↓
是: 按组处理
否: 检查其他组
```

***

### 卡片：CONDITION\_GROUP\_IS\_ISNOT\_IN\_LIST

#### 用途

检查文档是否分配给列表中的任一用户组

#### 示例

```
条件: "是否分配给以下组之一: [Finance, Procurement, Quality]?"
    ↓
是: 继续
否: 停止
```

***

## 日期与时间条件

### 卡片：CONDITION\_TIME\_IS\_ISNOT\_BETWEEN / 日期范围检查

#### 用途

检查日期是否介于两个日期之间

#### 工作方式

```
文档日期: 2025-10-23
    ↓
检查: 日期是否介于 2025-10-01 和 2025-10-31 之间?
    ↓
是 (十月) → 继续
否 (其他月份) → 停止
```

#### 计算

```
公式:
  开始日期 ≤ 文档日期 ≤ 结束日期?

示例:
  2025-01-01 ≤ 2025-10-23 ≤ 2025-10-31?
  是 ✅ 在范围内
```

#### 使用场景

* 检查日期是否处于财务期间
* 检查是否在截止日期范围内
* 检查是否在促销期内

#### 示例

```
条件: "文档日期是否介于十月 1 日和十月 31 日之间?"
    ↓
如果是: 十月发票 (按月处理)
如果否: 其他月份的发票
```

#### 参数

```
开始日期: [选择或输入]
结束日期: [选择或输入]
日期字段: [要检查的字段]
```

***

### 卡片：CONDITION\_TODAY\_IS\_ISNOT / 今日检查

#### 用途

检查今天的日期是否符合条件

#### 工作方式

```
今天: 2025-10-23
    ↓
检查: 今天是否 > 2025-10-31?
    ↓
否 → 截止日期尚未到
是 → 已过截止日期 (逾期)
```

#### 使用场景

```
今天是否已过截止日期? → 发票已逾期
今天是否已过促销日期? → 促销已结束
今天是否在本季度内? → 用于季度报告
```

#### 示例

```
条件: "今天是否晚于发票到期日?"
    ↓
如果是: 发票已逾期，升级处理
如果否: 发票仍在截止日期内
```

***

### 卡片：CONDITION\_CONFIRMED\_DELIVERY\_ACCEPTED\_DATE\_IN\_CALENDAR\_MASTER\_DATA

#### 用途

检查交付日期是否与日历中已批准的交付日期匹配

#### 工作方式

```
发票上的交货日期: 2025-10-25
    ↓
检查主日历: 2025-10-25 是否可接受?
    ↓
(主日历中列有可接受的日期)
    ↓
是: 日期可接受
否: 日期不在批准列表中
```

#### 使用场景

* 验证交付日期是否符合约定
* 对照节假日日历进行检查
* 对照合同约定日期进行验证

#### 示例

```
供应商承诺日期: 2025-10-25
发票显示的交货日期: 2025-10-25
检查主日历: 2025-10-25 是否为有效交货日期?
    ↓
是: 交货日期可接受 ✅
```

***

## 逻辑条件

### 卡片：CONDITION\_DECISION\_TREE\_DATA / 决策表返回值

#### 用途

检查决策表是否返回值

#### 工作方式

```
运行决策表
    ↓
是否返回值?
    ↓
是: 数据可供后续卡片使用
否: 没有匹配结果
```

#### 使用场景

* 使用决策表结果前
* 作为门控条件
* 检查是否有可用的路由

#### 示例

```
决策表: "Route by supplier"
    ↓
条件: "决策表是否返回数据?"
    ↓
如果是: 使用返回值进行路由
如果否: 使用默认路由
```

***

### 卡片：CONDITION\_CONTINUE\_CHANCE / 随机概率

#### 用途

按指定概率继续

#### 工作方式

```
概率: 50%
    ↓
掷骰子
    ↓
随机概率: 50% 是，50% 否
```

#### 使用场景

* A/B 测试工作流
* 抽样处理文档
* 随机质量检查

#### 示例

```
条件: "是否以 10% 的概率继续?"
    ↓
90% 的文档: 在此处停止
10% 的文档: 继续进行详细审核
```

#### 计算

```
如果概率 = 50%:
  - 50% 的文档继续
  - 50% 的文档停止

如果概率 = 10%:
  - 10% 继续 (每 10 份文档中 1 份)
  - 90% 停止
```

***

### 卡片：CONDITION\_MODULE\_IS\_ISNOT\_ACTIVE / 功能检查

#### 用途

检查特定模块或功能是否已启用

#### 模块

```
- 采购订单匹配
- 自动会计处理
- OCR
- 文档分类
- 供应商管理
- 自定义模块
```

#### 工作方式

```
模块: "PO Matching"
    ↓
是否已启用 PO Matching?
    ↓
是: 执行采购订单匹配验证
否: 跳过采购订单检查
```

#### 使用场景

* 依赖特定功能的工作流
* 可选处理
* 检查已授权的功能是否处于启用状态

***

### 卡片：CONDITION\_HTTPS\_REQUEST\_STATUS / 请求结果检查 <a href="#condition-https-request-status" id="condition-https-request-status"></a>

#### 用途

检查 HTTPS 请求是否成功

#### 状态码

```
200-299: ✅ 成功
300-399: ↪️ 重定向
400-499: ❌ 客户端错误
500-599: ❌ 服务器错误
```

#### 工作方式

```
发送 HTTPS 请求
    ↓
接收响应代码
    ↓
检查: 请求是否成功 (200)?
    ↓
是: 使用响应数据继续处理
否: 进行错误处理
```

#### 示例

```
向 API 发送定价请求
    ↓
条件: "请求是否返回 200 (成功)?"
    ↓
如果是: 使用返回的价格
如果否: 使用备用价格
```

***

### 卡片：CONDITION\_SUPPLIER\_STATUS\_IS\_ISNOT / 供应商状态检查 <a href="#condition-supplier-status-is-isnot" id="condition-supplier-status-is-isnot"></a>

#### 用途

检查系统中的供应商状态

#### 供应商状态

```
✅ ACTIVE: 可以开展业务
⚠️ ON HOLD: 暂时受限
❌ INACTIVE: 不再开展业务
⚠️ CONDITIONAL: 仅适用于特定商品
```

#### 工作方式

```
供应商: ABC Corp
数据库中的状态: ACTIVE
    ↓
检查: 状态是否为 ACTIVE?
    ↓
是: 正常处理
否: 标记以供审核
```

#### 示例

```
来自 ABC Corp 的发票
    ↓
条件: "供应商状态是否为 ACTIVE?"
    ↓
如果是: 正常处理
如果否: 阻止处理或升级处理
```

***

### 卡片：CONDITION\_SPECIFY\_SUPPLIER\_TYPE

#### 用途

指定或检查供应商类型

#### 供应商类型

```
- 优选供应商
- 标准供应商
- 临时采购
- 框架协议
- 战略合作伙伴
```

#### 工作方式

```
供应商类型: "Preferred"
    ↓
检查: 是否为优选供应商?
    ↓
是: 应用优选供应商折扣
否: 使用标准定价
```

***

## 决策流示例

### 流程 1：基于状态的处理

```
文档到达
    ↓
检查: 状态 = "Ready for Validation"?
    ↓
是: 验证文档
    ↓
检查: 状态 = "Pending Approval"?
    ↓
是: 创建审批任务
    ↓
检查: 状态 = "Error"?
    ↓
是: 升级给经理处理
```

### 流程 2：基于供应商的处理

```
发票到达
    ↓
检查: 供应商状态是否为 ACTIVE?
    ↓
否: 阻止处理并升级处理
    ↓
是: 检查: 供应商是否为优选供应商?
    ↓
是: 快速审批
否: 标准审批
```

### 流程 3：基于金额并检查日期

```
发票到达
    ↓
检查: 金额 > €10,000?
    ↓
是: 检查: 日期是否在十月 (财政期间) 内?
    ↓
是: 分配给财务总监
否: 分配给财务经理
```

***

## 条件卡片对比

| 卡片                                          | 检查内容    | 运算符           | 用途      |
| ------------------------------------------- | ------- | ------------- | ------- |
| CONDITION\_DOC\_STATUS\_IS\_ISNOT           | 文档状态    | IS / IS NOT   | 阶段检查    |
| CONDITION\_DOC\_STATUS\_IS\_ISNOT\_IN\_LIST | 列表中的状态  | IN / NOT IN   | 多个状态    |
| CONDITION\_DOC\_TYPE\_IS\_ISNOT             | 文档类型    | IS / IS NOT   | 类型筛选    |
| CONDITION\_DOC\_TYPE\_IS\_ISNOT\_LIST       | 列表中的类型  | IN / NOT IN   | 多种类型    |
| CONDITION\_SUB\_ORG\_IS\_ISNOT              | 组织      | IS / IS NOT   | 部门检查    |
| CONDITION\_USER\_IS\_ISNOT                  | 受派用户    | IS / IS NOT   | 用户检查    |
| CONDITION\_USER\_IS\_ISNOT\_IN\_LIST        | 列表中的用户  | IN / NOT IN   | 多个用户    |
| CONDITION\_GROUP\_IS\_ISNOT                 | 受派用户组   | IS / IS NOT   | 用户组检查   |
| CONDITION\_GROUP\_IS\_ISNOT\_IN\_LIST       | 列表中的用户组 | IN / NOT IN   | 多个用户组   |
| CONDITION\_TIME\_IS\_ISNOT\_BETWEEN         | 日期范围    | BETWEEN       | 日期区间    |
| CONDITION\_TODAY\_IS\_ISNOT                 | 今天的日期   | IS / IS NOT   | 今日检查    |
| CONDITION\_DECISION\_TREE\_DATA             | 决策表返回值  | HAS / HAS NOT | 决策表结果检查 |
| CONDITION\_CONTINUE\_CHANCE                 | 概率      | CHANCE        | 随机门控    |
| CONDITION\_MODULE\_IS\_ISNOT\_ACTIVE        | 功能是否启用  | IS / IS NOT   | 功能检查    |
| CONDITION\_HTTPS\_REQUEST\_STATUS           | 请求结果    | STATUS        | 响应检查    |
| CONDITION\_SUPPLIER\_STATUS\_IS\_ISNOT      | 供应商状态   | IS / IS NOT   | 供应商检查   |

***

## 条件最佳实践

✅ **建议：**

* 使用具体的条件
* 使用样例测试逻辑
* 按逻辑顺序排列条件
* 为所有路径设置后备处理
* 记录复杂逻辑

❌ **避免：**

* 创建循环条件（A 依赖 B，B 又依赖 A）
* 让条件过于复杂
* 忽略边缘情况
* 假定字段始终有值
* 创建不可能成立的条件

***

## 组合多个条件

```
条件 1: 类型 = Invoice?
    AND
条件 2: 金额 > €5000?
    AND
条件 3: 供应商状态 = Active?
    ↓
全部为真 → 处理
部分为假 → 停止
```

***

## 相关卡片

* **CONDITION\_DOC\_FIELD\_CONTAINS** - 字段内容检查
* **CONDITION\_COMPARE\_TWO\_DOCFIELD\_VALUES** - 字段比较
* **CONDITION\_CHECKBOX\_IS** - 复选框检查


---

# 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/condition-cards-complete-guide.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.
