> 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/po-matching-complete-guide.md). # 采购订单匹配卡片 - 完整指南 ## 采购订单（PO）匹配卡片 - 完整指南 \*\*状态：\*\*涵盖 15 张 PO 比较卡片及其详细计算 *** 本页介绍的 PO 比较卡片应添加到工作流构建器的 **And** 组中——它们会在 Then 操作运行之前，将发票数据与匹配的采购订单进行比较：
工作流构建器画布，包含 When、And 和 Then 卡片组

通过 Add Card 将 PO 比较卡片添加到 And 组。

*** ### 📌 版本信息 **演进最充分的卡片：** CONDITION\_DOC\_TO\_PO\_UNIT\_PRICE（5 个版本，最新为 v5） **其他复杂卡片：** CONDITION\_OC\_TO\_PO\_ITEMS（v4）、CONDITION\_LESS\_THAN\_TOLERANCE\_AS\_VALUE\_OF\_ORDERED\_QUANTITY（v4） **主要模式：** * \*\*v2 → v3+：\*\*增加容差参数，实现灵活匹配 * \*\*v3 → v4：\*\*增加比较模式参数 * \*\*v4 → v5：\*\*增强容差设置，支持多种单位（%、EUR、$ 等） 📖 [完整版本历史](https://github.com/Fellow-Consulting-AG/docbits/tree/main/readme/administration-and-setup/changelog/release.md#-po-comparison--validation-cards) | [卡片版本数据库](https://github.com/Fellow-Consulting-AG/docbits/tree/main/readme/DocFlow/docs/card_version.md) *** ### 了解 PO 匹配 收到发票后，应将其与之前下达的采购订单（PO）进行匹配。PO 匹配卡片会自动检查发票数据是否与 PO 数据相符。 **整体流程：** ``` 采购订单已下达 发票已到达 采购订单匹配 决策 (€100) → (€103) → (检查是否 → 批准/拒绝 数量: 100 数量: 100 在容差范围内) ``` *** ## 1. 采购订单完整匹配 ### 用途 检查整张发票是否与 PO 完全匹配，或是否在容差范围内 ### 适用场景 * 批准发票之前 * 作为初步质量检查 * 尽早发现问题 ### 工作原理 系统会比较： * 发票数量与 PO 数量 * 发票价格与 PO 价格 * 发票行项目与 PO 行项目 * 发票总额与 PO 总额 ### 结果 * **TRUE**（完整匹配）：所有内容均匹配，可以继续 * **FALSE**（不匹配）：存在不匹配项，需要审核 ### 示例 ``` 采购订单： - Item ABC：数量 100，单价 €50 = €5000 - Item XYZ：数量 50，单价 €20 = €1000 - 总计：€6000 发票： - Item ABC：数量 100，单价 €50 = €5000 - Item XYZ：数量 50，单价 €20 = €1000 - 总计：€6000 结果：✅ 完全匹配 ``` *** ## 2. 单价比较（文档与 PO） ### 用途 比较发票上的单价与 PO 上的单价 ### 参数 * **单价容差**：允许的差异上限 * **容差类型**：百分比（%）或绝对金额（€/$） * **运算符**：等于、大于、小于等 ### 工作原理（百分比容差） **公式：** ``` 偏差百分比 = |(发票价格 - 采购订单价格)| / 采购订单价格 × 100 检查：偏差百分比是否 ≤ 容差百分比？ ``` **分步示例：** ``` 步骤 1：获取价格 采购订单单价: €100.00 发票单价: €103.00 步骤 2：计算差值 差值 = |€103.00 - €100.00| = €3.00 步骤 3：计算百分比 百分比 = (€3.00 / €100.00) × 100 = 3% 步骤 4：检查容差（允许 5%） 3% ≤ 5% 吗？是 ✅ 结果：通过 - 在容差范围内 ``` ### 实际示例 #### 示例 1：小幅涨价（接受） ``` 采购订单价格: €50.00 发票价格: €51.50 容差: ±3% 计算： 偏差 = |(€51.50 - €50.00)| / €50.00 × 100 偏差 = €1.50 / €50.00 × 100 = 3% 3% ≤ 3% 吗？是 ✅ 接受 ``` #### 示例 2：大幅涨价（拒绝） ``` 采购订单价格: €50.00 发票价格: €55.00 容差: ±3% 计算： 偏差 = |(€55.00 - €50.00)| / €50.00 × 100 偏差 = €5.00 / €50.00 × 100 = 10% 10% ≤ 3% 吗？否 ❌ 拒绝 - 需要审核 ``` #### 示例 3：折扣（同样会检查） ``` 采购订单价格: €100.00 发票价格: €97.00 容差: ±5% 计算： 偏差 = |(€97.00 - €100.00)| / €100.00 × 100 偏差 = €3.00 / €100.00 × 100 = 3% 3% ≤ 5% 吗？是 ✅ 接受（折扣在容差范围内） ``` #### 示例 4：绝对金额容差 ``` 采购订单价格: €10.00 发票价格: €10.50 容差: ±€1.00（绝对值，不是百分比） 计算： 偏差 = |€10.50 - €10.00| = €0.50 €0.50 ≤ €1.00 吗？是 ✅ 接受 ``` ### 如何处理结果 **如果通过 ✅：** * 继续进行下一项检查 * 或批准发票 * 或继续导出 **如果未通过 ❌：** * 标记为需要人工审核 * 向供应商询问原因 * 联系采购团队 * 如果可以接受，则附注后批准 *** ## 3. 数量比较 ### 用途 检查订购数量是否与发票数量相符 ### 参数 * **容差**：允许的数量或百分比差异 * **运算符**：等于、大于、小于 * **数量类型**：已订购、已收货、未完成 ### 计算示例 **百分比容差：** ``` 公式： 数量偏差百分比 = |(发票数量 - 采购订单数量)| / 采购订单数量 × 100 示例： 采购订单数量: 100 件 发票数量: 103 件 容差: ±5% 偏差 = |(103 - 100)| / 100 × 100 偏差 = 3 / 100 × 100 = 3% 3% ≤ 5% 吗？是 ✅ 接受 ``` **绝对容差：** ``` 公式： 数量偏差 = |发票数量 - 采购订单数量| 示例： 采购订单数量: 100 件 发票数量: 102 件 容差: ±5 件 偏差 = |102 - 100| = 2 件 2 件 ≤ 5 件吗？是 ✅ 接受 ``` ### 实际场景 #### 超量交付（交付量超过订购量） ``` 订购数量: 100 件 开票数量: 110 件 容差: ±5% 偏差 = |(110-100)|/100 × 100 = 10% 10% ≤ 5% 吗？否 ❌ 决策：联系供应商 - 交付数量超过订购数量 可能原因：供应商出错，或此前已收到部分货物 ``` #### 未足量交付（交付量少于订购量） ``` 订购数量: 100 件 开票数量: 95 件 容差: ±5% 偏差 = |(95-100)|/100 × 100 = 5% 5% ≤ 5% 吗？是 ✅ 决策：接受 - 在容差范围内 可能原因：分批交付，其余货物将随后送达 ``` *** ## 4. 数量差异对应的合并价格 ### 用途 数量存在差异时，计算总价差异是否可以接受 ### 重要原因 ``` 场景：你订购了 100 件，但收到了 110 件 - 数量超出 10%（不利） - 但是：你只需为多出的 10% 付款 - 综合影响可能可以接受 ``` ### 计算 **公式：** ``` 综合偏差 = 数量偏差 × 价格偏差 如果两者都在容差范围内，综合偏差通常可以接受 ``` **示例：** ``` 采购订单： - 单价: €100 - 数量: 100 - 总额: €10,000 发票： - 单价: €102（高出 2%） - 数量: 105（高出 5%） - 总额: €10,710 分析： - 价格偏差：2% ✅ - 数量偏差：5% ✅ - 综合影响：1.02 × 1.05 = 1.071 = 总额增加 7.1% 综合偏差可以接受吗？通常可以 ✅ ``` *** ## 5. 行项目 ID / 供应商行项目编号比较 ### 用途 检查发票中的行项目是否与 PO 中的行项目相符 ### 工作原理 **精确匹配（最简单）：** ``` 采购订单行项目 ID: ABC-123 发票行项目 ID: ABC-123 结果: ✅ 匹配 ``` **供应商行项目编号（更常见）：** ``` 采购订单行项目: ABC-123（我们的内部代码） 供应商行项目: SUPP-456（供应商为同一商品使用的代码） 系统会将二者匹配为同一商品 结果: ✅ 匹配 ``` ### 场景：如果不匹配怎么办？ ``` 采购订单行项目：ABC-123 (Copper Wire, 2mm) 发票行项目：ABC-124 (Steel Wire, 2mm) 结果：❌ 不匹配 处理措施： 1. 这是替代品吗？请与采购部门确认 2. 这是错误吗？请联系供应商 3. 描述是否相似？请手动验证 ``` *** ## 6. 订单类型验证 ### 用途 验证采购订单类型是否正确 ### 订单类型 * **标准订单**：常规采购 * **加急订单**：紧急订单，可能包含溢价 * **框架协议**：长期合同 * **总括订单**：开放式合同 * **寄售**：使用后才付款 ### 检查示例 ``` 采购订单类型: 标准订单 发票订单类型: 标准订单 结果: ✅ 匹配 如果不匹配：可能会影响条款、付款和定价 ``` *** ## 7. 交付日期验证 ### 用途 检查交付日期是否与 PO 中承诺的日期相符 ### 计算 **延迟交付：** ``` 公式： 延迟天数 = 发票交付日期 - 采购订单承诺日期 示例： 采购订单承诺日期: 2025-10-15 实际交付日期: 2025-10-22 延迟天数 = 7 天 如果容差为 ±3 天： 7 ≤ 3 吗？否 ❌ 延迟 ``` **提前交付：** ``` 公式： 提前天数 = 采购订单承诺日期 - 发票交付日期 示例： 采购订单承诺日期: 2025-10-15 实际交付日期: 2025-10-10 提前天数 = 5 天 提前交付通常可以接受 ✅ 除非你需要在特定时间收到货物 ``` ### 容差设置 ``` ±3 天：允许提前或延迟 3 天 ±5 天：允许最多 5 天的偏差 0 天：必须完全一致 ``` *** ## 8. 费用验证（税费、运费等） ### 用途 检查附加费用（税费、运费、手续费）是否与 PO 相符 ### 常见费用 ``` - 运费: €50 - 搬运费: €10 - 包装费: €5 - 保险费: €15 - 税费: €300 ``` ### 计算 **示例：运费检查** ``` 采购订单运费: €50.00 发票运费: €51.00 容差: ±3% 偏差 = |€51.00 - €50.00| / €50.00 × 100 = 2% 2% ≤ 3% 吗？是 ✅ 接受 ``` **示例：多项费用** ``` 采购订单费用总额： - 运费: €50 - 税费: €300 - 搬运费: €10 总额: €360 发票费用总额： - 运费: €50 - 税费: €312（11% 税率） - 搬运费: €10 总额: €372 差额: €12 检查是否在容差范围内 ✅ 或需要关注 ❌ ``` *** ## 9. 税费验证 ### 用途 验证税额计算是否正确 ### 计算 **公式：** ``` 税额 = 小计 × 税率 示例： 小计: €1000 税率: 19% 预期税额: €1000 × 0.19 = €190 发票税额: €190 是否匹配？是 ✅ ``` **常见问题：** ``` 1. 税率发生变化（按地区划分） 2. 计税金额错误（折扣前/折扣后） 3. 存在多种税率（部分商品适用 7%，其他商品适用 19%） 4. 免税商品（0% 税率） ``` **示例：多税率计税** ``` 商品 A: €100 @ 19% 税率 = €119 商品 B: €100 @ 7% 税率 = €107 商品 C: €100 @ 0% 税率 = €100 总额: €326 发票显示 €325（相差 €1） 检查：在容差范围内还是需要处理？ ``` *** ## 10. 设施/成本中心匹配 ### 用途 确保发票对应正确的设施/成本中心 ### 示例 ``` 采购订单对应： - 设施: Berlin Plant - 成本中心: CC-2025 发票应包含： - 设施: Berlin Plant ✅ - 成本中心: CC-2025 ✅ 如果设施不同：可能需要不同的审批 ``` *** ## 11. 供应商状态验证 ### 用途 检查供应商是否仍处于已批准/有效状态 ### 状态类型 ``` ✅ 有效：已批准，可以开展业务 ⚠️ 暂停：暂时受限 ❌ 无效：不再开展业务 ⚠️ 有条件：仅适用于特定商品 ``` ### 检查示例 ``` 供应商: ABC Corp 数据库中的状态: 有效 创建采购订单时的状态: 有效 发票到达时的状态: 无效 警报：供应商状态已更改！请调查原因。 ``` *** ## 应使用哪种容差？ ### 严格容差（风险较低，人工工作较多） ``` 适用于： - 高价值商品 - 必须精确匹配的商品 - 受监管行业 设置： - 单价: ±1% - 数量: ±1% - 交付日期: ±1 天 - 费用: ±1% ``` ### 中等容差（平衡） ``` 适用于： - 大多数商业交易 - 标准商品 - 常规采购 设置： - 单价: ±3-5% - 数量: ±3-5% - 交付日期: ±3 天 - 费用: ±5% ``` ### 宽松容差（风险较高，人工工作较少） ``` 适用于： - 低价值商品 - 大宗采购 - 允许灵活处理的供应商协议 设置： - 单价: ±10% - 数量: ±10% - 交付日期: ±7 天 - 费用: ±10% ``` *** ## PO 匹配工作流示例 ``` 发票到达 ↓ 条件："Is amount > €5000?"（金额是否 > €5000？）→ YES（是） ↓ 检查：是否完全匹配？→ NO（否）（价格相差 10%） ↓ 检查：单价是否在 5% 范围内？→ NO（否）（相差 12%） ↓ 检查：数量是否在 5% 范围内？→ YES（是）（相差 2%） ↓ 决定：FAIL（失败）- 价格差异过大 ↓ 标记为：手动审核 / 采购员审批 ↓ 等待：采购员评论 ↓ 如果已批准：继续导出 如果已拒绝：退回供应商 ``` *** ## PO 匹配故障排除 ### “未找到 PO” ``` 原因：发票中的采购订单编号在系统中不存在 修复方法： 1. 核对采购订单编号的拼写 2. 检查采购订单是否已创建 3. 确认采购订单属于正确的组织 4. 向供应商索取采购订单参考编号 ``` ### “行项目不匹配” ``` 原因：发票中的商品与采购订单中的商品不同 可能原因： 1. 采购部门批准了替代商品 2. 同一商品使用了不同的商品编号 3. 供应商出错 修复方法：联系采购部门或供应商 ``` ### “价格高于 PO” ``` 原因：发票价格 > 采购订单价格 可能原因： 1. 价格上涨已获批准 2. 供应商出错 3. 币种不同 4. 包含了额外服务 修复方法：向采购部门核实 ``` ### “交付日期错误” ``` 原因：发票日期晚于承诺交付日期 可能原因： 1. 货运延迟 2. 收货日期与发票日期不同 3. 分批交付 修复方法：检查运输单据或联系供应商 ``` *** ## 汇总表 | 卡片 | 检查内容 | 主要计算 | 常见容差 | | ------ | -------- | -------- | ------ | | 完整匹配 | 所有内容 | 所有检查 | 不定 | | 单价 | 单位价格 | % 或 € 差异 | ±3-5% | | 数量 | 订购数量 | % 或数量差异 | ±3-5% | | 合并价格 | 数量变化后的总价 | 数量 × 价格 | ±5-10% | | 行项目 ID | 行项目是否正确 | 字符串匹配 | 精确 | | 订单类型 | 采购类型 | 字符串匹配 | 精确 | | 交付日期 | 到货时间 | 天数差异 | ±3 天 | | 费用 | 额外费用 | % 或 € 差异 | ±5% | | 税费 | 税额 | 税率计算 | ±1% | | 设施 | 成本中心 | 字符串匹配 | 精确 | | 供应商 | 是否已批准？ | 状态检查 | 仅限有效 | *** ## 相关文档 * 有关完整工作流，请参阅“发票验证”指南 * 有关按行业推荐的数值，请参阅“容差设置” * 有关失败时的处理方式，请参阅“异常处理” * 有关具体容差政策，请联系采购团队 --- # 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/po-matching-complete-guide.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.