您的采购到付款 - 发票处理 data 模板

Coupa

采购到付款 - 发票处理属性 (21) 采购到付款 - 发票处理活动 (14) 提取指南 (3)

您的采购到付款 - 发票处理 data 模板

此模板将引导您了解有效分析 Coupa 内发票处理所需的关键 data 点。它概述了需要收集的重要属性以及要在 event log 中跟踪的关键活动。此外，您还将找到有关从 Coupa 系统中提取这些 data 的实用指南，确保您的 Process Mining 旅程顺畅开启。

建议收集的属性
需要追踪的关键活动
Coupa 数据提取指南

不熟悉事件日志？了解如何创建流程挖掘事件日志.

下载模板

采购到付款 - 发票处理属性

这些是建议包含在您的 event log 中的 data 字段，以便对“采购到付款”发票处理进行全面分析。

3 必填 6 推荐 12 可选

	名称	描述
	Event 时间 EventTime	指示特定活动或事件发生的精确时间戳。
描述 “事件时间”（Event Time）即 timestamp，记录了执行活动的准确日期和时间。它是流程日志的时间基础，为每个 case 的所有 event 按时间顺序进行排列。该属性对于 Process Mining 中所有基于时间的分析都至关重要。它用于计算活动之间的周期时间、识别瓶颈持续时长、衡量等待时间，并分析不同时间段的流程绩效。准确的 timestamp 对于构建真实的流程模型和推导有意义的绩效 KPI 至关重要。为何重要它提供了计算所有耗时、周期时间和等待时间所需的时间顺序 data，这些是绩效分析的基础。获取方式这些 data 捕获自 Coupa 中发票对象的审计追踪或历史日志中。每个记录的操作或状态变更都会有一个相关的 timestamp。示例 2023-10-26T10:00:00Z2023-11-05T14:32:15Z2023-11-15T09:01:45Z
	发票编号 InvoiceNumber	供应商发票的唯一标识符。这是在整个生命周期内跟踪发票的主键。
描述发票编号是供应商为发票单据分配的唯一参考。在 Process Mining 中，它作为 case ID，链接了从接收、验证到审批和最终付款的所有相关活动。按发票编号分析流程可以实现每张发票旅程的完整端到端视图。这有助于识别处理路径的差异、准确测量周期时间，并精确定位哪些发票遇到了延迟、挂起或异常。它是深入了解发票处理绩效的基础属性。为何重要它是连接单张发票所有 event 的核心 case 标识符，从而实现连贯的端到端流程分析。获取方式这是 Coupa 发票对象上的一个主要字段。可以在 UI 的发票标头明细中或通过 Invoices API 找到。示例 INV-2023-00123785549-APO45001-INV
	活动 ActivityName	发票处理生命周期中发生的特定业务 event 或任务的名称。
描述活动名称描述了发票处理 workflow 中的一个步骤，例如“发票已创建”、“发票已发送审批”或“已执行付款”。每个活动代表发票状态或所有权发生变化的特定时间点。在 Process Mining 中，活动序列形成了流程流向图。分析这些活动有助于可视化实际流程、识别常用路径和罕见路径、检测活动耗时过长的瓶颈，并发现重工循环等违规或低效步骤。为何重要此属性对于构建流程图至关重要，可实现实际发票处理 workflow 的可视化和分析。获取方式此属性通常源自 Coupa 发票模块中的 event logs、审计追踪或状态变更。它通常需要将状态变更或特定用户操作映射到定义的活动名称。示例发票已提交处理发票已审批发票已设置暂缓已执行付款
	付款到期日 PaymentDueDate	为避免逾期，发票必须支付的日期。
描述付款到期日是根据发票日期和商定的付款条款计算的重要日期。它代表了向供应商付款的最后期限。此属性是衡量准时付款绩效的基准。通过将其与实际付款执行日期进行比较，直接用于计算“准时付款率”KPI。分析与该日期的偏差有助于识别导致付款延迟的系统性问题，并评估对供应商关系和潜在滞纳金的影响。为何重要它是衡量及时付款绩效的主要基准，对于管理供应商关系和避免罚款至关重要。获取方式此日期通常由 Coupa 根据“发票日期”和“付款条款”字段计算得出，应可在发票记录中找到。示例 2023-11-302023-12-152024-01-10
	供应商名称 VendorName	提交发票的供应商名称。
描述供应商名称标识了采购货物或服务的业务伙伴。这是分析付款绩效和关系的关键上下文 data。此属性允许按供应商细分发票流程。它有助于回答“哪些供应商的发票处理时间最长？”或“我们是否始终准时向某些战略供应商付款？”等问题。按供应商分析对于“供应商付款及时性”dashboard 以及有效管理供应商关系至关重要。为何重要它允许按供应商对流程进行细分和分析，这是管理供应商关系和识别供应商特定问题的关键。获取方式此信息是 Coupa 核心发票 data 的一部分，链接自供应商 (Supplier/Vendor) 对象。示例全球办公用品Tech Solutions Inc.创意营销代理机构
	发票总金额 InvoiceTotalAmount	发票的总金额，包括税费和其他费用。
描述此属性代表发票应付总额。它是广泛分析中使用的基础财务 data 点。根据发票金额分析流程可以揭示重要的模式。例如，高额发票可能遵循不同的、更严格的审批路径，从而可能导致更长的周期时间。它还用于评估流程低效带来的财务影响，例如当前被冻结或延迟的发票价值。为何重要它提供了关键的财务背景，支持分析流程行为如何随发票金额而变化，以及延误带来的财务影响。获取方式这是 Coupa 发票对象上的一个标准字段，通常名为“总计”或“总金额”。示例 1500.75250.0012345.50
	发票状态 InvoiceStatus	发票在其处理 workflow 中的当前状态。
描述发票状态提供了发票在任何给定时间点的快照，例如“待审批”、“已批准”、“挂起”或“已支付”。此属性是动态的，并随着发票在流程中的移动而变化。这是诸如“发票处理吞吐量与状态”等运营监控 dashboard 的关键属性。它允许跟踪当前未结发票的库存及其在不同阶段的分布。分析随时间变化的状态转换也是获取“活动名称”属性的主要来源。为何重要它提供了发票在 Workflow 中所处位置的实时视图，这对于运营 Dashboard 和状态追踪至关重要。获取方式这是 Coupa 发票对象上的一个主要状态字段。示例待审批已批准已作废已付款
	用户 User	执行该活动的内部用户或系统代理。
描述此属性标识了负责执行特定流程步骤（如批准发票或解除挂起）的个人或自动化系统。通常由用户 ID、姓名或电子邮件表示。按用户分析流程是了解团队绩效、工作量分配和识别培训机会的关键。这对于瓶颈分析至关重要，因为它可以揭示延迟是否集中在特定的审批人或团队。它还有助于区分人工活动和自动化活动。为何重要它支持工作量分析，精准定位由特定用户或团队造成的瓶颈，并有助于评估用户绩效和合规性。获取方式用户信息通常记录在 Coupa 发票的审计追踪或历史记录中，并与所采取的每项操作相关联。示例 john.doe@company.comjane.smithSystem.Automation
	采购订单号 PurchaseOrderNumber	该发票结算所对应的采购订单 (PO) 标识符。
描述采购订单编号将发票与原始采购单据链接起来。这种关联是 PO 匹配流程的基础，也是许多组织在发票验证中的关键步骤。在 Process Mining 中，此属性对于分析 PO 匹配和差异解决过程至关重要。它允许过滤与特定 PO 相关的发票，对于“PO 匹配差异概览”dashboard 必不可少。无 PO 编号的发票比例过高可能表明存在违规采购或非合规采购。为何重要它将发票与采购流程联系起来，支持对 PO 匹配效率和差异处理的分析。获取方式这是 Coupa 发票行对象上的一个标准字段，用于将发票行与 PO 行相关联。示例 PO4500123PO4500456PO4500789
	付款条款 PaymentTerms	约定的发票付款条款，例如“Net 30”或“2% 10, Net 30”。
描述付款条款定义了支付供应商的规则，包括到期日和任何可用的提前付款折扣。这些信息通常在供应商主数据中建立并应用于发票。此属性对于计算付款到期日以及识别提前付款折扣机会至关重要。它是“提前付款折扣跟踪”dashboard 及相关 KPI 的直接输入。通过付款条款进行分析可以揭示某些条款是否与付款延迟相关。为何重要它是计算付款截止日期和识别早期付款折扣机会的基础，直接影响营运资金。获取方式这是 Coupa 中的标准字段，通常从供应商记录默认填充到发票上。示例净 30 天净 60 天2% 10，净30
	公司代码 CompanyCode	负责该发票的法律实体或公司的标识符。
描述公司代码代表大型组织内的特定法律实体。出于财务会计和报告目的，发票会根据公司代码进行记账。此属性对于按法律实体过滤和细分流程分析至关重要。它允许比较业务不同部门的流程绩效，例如回答“美国实体的发票审批流程是否与德国实体不同？”等问题。这对于大型跨国组织尤为关键。为何重要它支持在组织内的不同法律实体或业务单元之间进行流程比较和绩效基准测试。获取方式这是 Coupa 发票对象上的一个基本会计字段，通常是财务过账所必需的。示例 1000US01DE01
	最后数据更新 LastDataUpdate	用于标识该事件数据最近一次从源系统刷新的时间戳。
描述此属性记录了 data 上次提取并加载到 Process Mining 工具的时间。它提供了分析新鲜度的背景信息，对于理解 dashboard 中呈现的洞察的时效性至关重要。了解上次 data 更新时间对于运营监控用例非常重要。它通过明确信息的最新程度来帮助用户信任 data，并确保决策不是基于过时的流程视图做出的。为何重要它提供了关于流程 data 及时性和相关性的关键背景，确保用户了解分析的时效性。获取方式此 timestamp 是在 data 提取和转换 (ETL) 过程中生成并添加到数据集中的。示例 2024-05-20T04:00:00Z2024-05-19T04:00:00Z
	发票处理周期 InvoiceCycleTime	从发票的第一项活动（如发票创建）到最后一项支付活动所经历的总时长。
描述 “发票周期时间”是一个关键绩效指标，用于衡量发票处理生命周期的端到端持续时间。计算方法是最后一个重要 event（如“已执行付款”）与第一个 event（如“创建发票”或“收到发票”）的 timestamp 之差。这一计算指标是“发票周期时间分析 Dashboard”的基石。它提供了对整体流程效率的高级衡量。按供应商、金额或公司代码进行分解，可以揭示低效的根源并帮助确定改进工作的优先级。为何重要这是衡量整体流程速度和效率的主要 KPI，直接反映了处理一张发票所需的时间。获取方式此属性是在 Process Mining 工具中通过计算每个 case（发票编号）的 event 时间最大值与最小值之差得出的。示例 15天4小时32天1小时5天8小时
	发票日期 InvoiceDate	供应商发票单据上的日期。
描述发票日期是供应商分配给发票的日期。它通常标志着支付生命周期的正式开始，并根据付款条款作为计算付款到期日的基础。此属性是许多周期时间计算的关键起点。它是计算付款到期日和确定是否有资格获得提前付款折扣的重要输入。分析发票日期与录入系统日期之间的差值，可以揭示发票提交或接收过程中的延迟。为何重要它是用于计算付款截止日期的主要日期，也是衡量付款及时性和获取折扣的关键参考点。获取方式这是 Coupa 发票对象上的一个标准必填字段。示例 2023-10-152023-11-012023-12-20
	折扣已获得 EarlyPaymentDiscountCaptured	一个标志，指示是否成功获得了可用的早期付款折扣。
描述此属性是一个布尔值，指示组织是否在付款条款定义的折扣期内成功支付了发票，例如在“10天内支付享2%折扣，30天内支付全额”条款下在10天内完成支付。它是“提前付款折扣跟踪”dashboard 及相关 KPI 的核心指标。分析此标志为 false 的情况有助于识别错失的节支机会。这使得企业能够调查为何符合折扣条件的发票处理不够迅速，并实施变更以获取更多折扣，从而优化营运资金。为何重要它直接衡量了高效发票处理带来的财务收益，并有助于识别错失的节约机会。获取方式这是一个计算属性。其逻辑包括检查付款日期是否落在“付款条款”定义的折扣期内，以及是否实际应用了折扣。示例 truefalse
	拒绝原因 RejectionReason	发票在审批过程中被拒绝时提供的原因。
描述当审批人拒绝发票时，他们通常会提供拒绝原因，例如“金额不正确”或“重复发票”。此属性捕获了该自由文本或代码化的原因。这些 data 对于审批延迟和重工的根本原因分析非常有价值。通过分析不同拒绝原因出现的频率，组织可以识别上游流程中的系统性问题，例如 PO 准确性或供应商开票习惯问题。此信息为“发票审批瓶颈分析”dashboard 提供支持。为何重要它提供了关于发票被拒根本原因的直接见解，有助于识别流程改进领域并减少返工。获取方式当用户在审批 workflow 中执行“拒绝”操作时会捕获此信息。它通常存储在备注或审计追踪中。示例数量错误价格与 PO 不符重复提交发票
	是否已自动化 IsAutomated	一个标志，指示活动是由自动化系统还是由人工用户执行。
描述此布尔属性用于区分由系统自动化执行的任务（如自动 PO 匹配或系统生成的过账）与由用户手动执行的任务。分析此属性有助于量化发票处理 workflow 中的自动化水平。它用于衡量自动化计划的成效，识别剩余的可自动化人工干预点，并比较自动化活动与人工活动的效率及错误率。这是了解流程真实成本和效率的关键。为何重要它有助于衡量流程中的自动化水平，识别进一步自动化的机会，并评估现有机器人的影响。获取方式这通常通过检查与活动关联的“用户”是系统/服务账户还是人工用户账户来得出。示例 truefalse
	是否按时付款 IsOnTimePayment	一个布尔值标志，指示发票是否在截止日期当天或之前支付。
描述此计算属性为每张发票提供了一个简单的支付及时性（真或假）指标。它是通过比较“已执行付款”活动的 timestamp 与“付款到期日”得出的。如果付款 timestamp 在到期日或之前，则值为 true。此标志简化了“准时付款率”KPI 的计算。它允许进行简单的过滤和细分，以分析逾期付款的特征，例如导致延迟的常见供应商、部门或发票金额。为何重要它简化了付款绩效分析，是计算关键的“及时付款率”KPI 的基础。获取方式这是一个计算属性。逻辑为：“实际付款日期”<=“付款到期日”。这在 Process Mining 工具中实现。示例 truefalse
	暂挂原因 HoldReason	发票被挂起或被阻止付款的具体原因。
描述 “暂缓原因”（Hold Reason）解释了为什么发票被阻止进入付款环节。示例包括“数量不匹配”或“等待收货”。此信息对于了解付款延误的原因至关重要。该属性是“付款拦截根本原因分析 Dashboard”的关键。通过对不同暂缓原因的发生频率进行分类和统计，企业可以识别出破坏付款流程的最常见问题，从而开展针对性改进，预防未来的暂缓并加速付款。为何重要它解释了付款延误的原因，从而支持针对性的根本原因分析，以减少付款拦截的频率和持续时间。获取方式在 Coupa 中挂起发票时，通常会选择或输入一个原因。此 data 与发票的挂起状态相关联。示例 PO 价格不符等待收货重复发票
	源系统 SourceSystem	从中提取 event data 的原始系统。
描述源系统属性标识了记录发票处理活动的应用程序或平台。虽然主要系统是 Coupa，但发票或相关 data 可能源自其他集成系统，如 ERP 或供应商门户。在复杂的 IT 环境中，这些信息对于了解不同系统如何对整体流程做出贡献非常有价值。它有助于诊断 data 质量问题、了解系统交接并分析跨多个应用程序的流程。为何重要它明确了 data 的来源，这对于排查故障以及分析涉及多个集成系统的流程至关重要。获取方式这通常是在 data 提取期间添加的静态值，用于识别 data 的来源。对于 Coupa，这将设置为“Coupa”。示例 CoupaSAP S/4HANAOracle Fusion
	货币 CurrencyCode	发票金额的 ISO 货币代码。
描述货币代码指定了发票财务价值的货币单位，例如 USD、EUR 或 GBP。这对于在全球运营并处理多种货币发票的组织来说至关重要。在分析中，此属性是正确解读和汇总财务 data 的必要条件。Dashboard 和 KPI 必须过滤或转换货币，以提供有意义的财务摘要。它能防止错误地汇总不同货币的数值，并允许进行特定货币的流程分析。为何重要它通过为多币种环境下的所有货币价值提供必要的背景信息，确保财务分析和报告的准确性。获取方式这是 Coupa 发票对象上的一个标准字段，通常链接到供应商或在发票本身上指定。示例美元EURGBP

必填推荐可选

采购到付款 - 发票处理活动

为确保流程发现与分析准确，建议在事件日志中记录以下关键步骤与里程碑。

5 推荐 9 可选

	活动	描述
	发票已入账待付	已批准的发票被标记为待支付，其财务明细通常会过账到外部 ERP 系统。这通常根据集成状态标志或发票主要状态的变化来推断。
为何重要这一里程碑代表了从应付账款 (AP) 处理到财务或付款职能部门的交接。此点之前的延迟会影响 AP 效率，而此点之后的延迟则会影响财务和供应商关系。获取方式这通常通过状态更改为“批准支付”或“已导出”标志设为 true 来推断。此信息可在发票标头对象中找到。捕获检测发票状态变更为“批准付款”或设置了导出标志时的 timestamp。事件类型 inferred
	发票已创建	此活动标志着在 Coupa 系统中最初创建的发票记录。当一个新的发票对象被实例化时（无论是通过手动录入、集成供应商网络如 Coupa 供应商门户，还是通过自动 OCR 扫描），都会捕获该 event。
为何重要作为发票生命周期的起点，此活动对于衡量总的端到端处理时间至关重要。它为所有后续的周期时间和吞吐量分析提供了基准。获取方式这是一个明确的 event，从发票记录的创建 timestamp 中捕获。在 Coupa 的 data 模型中，这对应于发票标头对象上的“created-at”timestamp。捕获使用发票记录的创建 timestamp。事件类型 explicit
	发票已发送审批	标志着发票在通过初步检查后，进入正式审批 Workflow 的时间点。通常根据状态变更为“待一个或多个审批人处理”推导得出。
为何重要此活动是衡量审批周期时间的起点。它对于分析审批层级中的瓶颈至关重要，并为“发票审批瓶颈分析”dashboard 提供支持。获取方式根据发票状态变更为“待审批”或类似状态推导得出。发票审批历史中第一条审批记录的创建也标志着该 event。捕获捕捉发票状态变更为“待审批”或第一条审批记录创建时的 timestamp。事件类型 inferred
	发票已审批	此活动表示发票已成功通过审批 workflow 中所有必需的步骤。当最后一位必需的审批人采取肯定的操作时，会从审批历史记录中捕获该活动。
为何重要这一关键里程碑标志着审批周期的结束，并解锁发票以进入付款处理环节。这对于衡量审批时长和整体流程效率至关重要。获取方式这是一个明确的 event，从审批历史日志或发票标头状态更改为“已批准”中捕获。日志中的最终审批操作提供了一个精确的 timestamp。捕获捕捉审批历史中最后一次审批操作的 timestamp。事件类型 explicit
	已执行付款	此活动标志着流程的最后一步，即执行付款并发送给供应商。这是从 Coupa Payments 或集成支付系统中相关付款记录的状态中捕获的。
为何重要作为流程的明确终点，此活动对于计算完整的端到端周期时间以及衡量“及时付款率”KPI 至关重要。获取方式此 event 根据与发票关联的付款记录推断得出。“已支付”、“已完成”状态或已填写的“付款日期”字段均表示已执行。捕获使用与发票关联的付款记录中的“付款日期”。事件类型 inferred
	付款已安排	发票已包含在计划于未来日期执行的付款批次中。通过发票与系统中的付款运行或付款批次对象相关联来推断此 event。
为何重要此活动提供了对流程最后阶段的透明度，区分了发票已就绪待付与实际启动支付之间的差别。这有助于现金流预测。获取方式根据包含发票 ID 的付款记录或批处理记录的创建情况推导得出。付款对象上的“计划付款日期”提供了相关的时间点。捕获使用与发票关联的付款批次记录的创建日期。事件类型 inferred
	发票已与采购订单匹配	此活动表示系统已成功将发票行与相应的采购订单行进行匹配。该 event 根据发票匹配状态字段的变化推断得出，表明已针对 PO 成功验证。
为何重要成功的自动匹配是流程健康、零干预的关键指标。跟踪此活动有助于衡量自动化效果和直通处理率。获取方式根据发票匹配状态字段变更为“已匹配”状态推导得出。Coupa 的发票对象包含指示 PO 匹配尝试结果的标志和状态。捕获检测发票的 PO 匹配状态变更为“已匹配”（Matched）时的 timestamp。事件类型 inferred
	发票已作废	发票已被取消，将不再处理或支付。这是发票的一个明确的终止状态变更，直接从系统的状态字段中捕获。
为何重要这代表了流程的另一种非成功终点。分析发票作废的原因可以揭示采购或供应商沟通中的上游问题。获取方式这是在发票状态更改为“作废”时捕获的明确 event。这是 Coupa 发票管理中的一个标准状态。捕获捕捉发票状态更新为“作废”（Voided）时的 timestamp。事件类型 explicit
	发票已拒绝	审批人正式拒绝了该发票，停止了其在 Workflow 中的进度。这是记录在发票审批历史中的明确操作，包含谁在何时拒绝的详细信息。
为何重要拒绝会导致重工并显著增加周期时间。分析拒绝的频率和原因对于流程改进至关重要，也是计算“一次性审批通过率”KPI 所必需的。获取方式这是一个记录在发票审批历史日志中的明确 event。每个审批步骤都有一个包含状态、timestamp 和审批人操作的记录。捕获从审批历史记录中过滤出“拒绝”（reject 或 rejected）操作。事件类型 explicit
	发票已提交处理	代表将新创建的发票正式提交到处理 workflow 中。这通常由用户在输入并验证所有初始 data 后触发。当发票状态从草稿状态更改为已提交状态时，会从审计追踪中捕获此 event。
为何重要此活动区分了 data 录入时间与实际处理时间。分析从“发票已创建”到此 event 之间的时间跨度，有助于识别初始 data 处理阶段的延迟。获取方式跟踪发票状态从“草稿”或“新建”到“已提交”或“待审批”的变化。这可以在 Coupa 的发票历史或审计日志表中找到。捕获捕捉发票状态首次变更为“已提交”（submitted）时的 timestamp。事件类型 explicit
	发票已设置暂缓	代表对发票采取的挂起操作，以防止其被支付。这是一个明确的 event，通常记录在发票的历史记录或审计追踪中，且往往附带相关原因。
为何重要此活动等同于付款冻结，是导致付款延迟的主要原因。跟踪何时挂起是分析其根本原因和时长的第一步，旨在支持“付款冻结率”KPI。获取方式这是一个在发票历史记录或审计日志中发现的明确 event。Coupa 会记录用户或系统的操作，包括挂起操作。捕获从发票历史记录中过滤出“设置暂缓”（hold placed）或类似的系统 event。事件类型 explicit
	差异处理已开始	代表开始人工干预以解决 PO 匹配差异。此活动难以直接捕获，通常是根据标记不匹配后的第一个用户操作（如添加备注或编辑发票）推断出来的。
为何重要跟踪从识别差异到开始解决之间的时间，有助于突出分配或处理异常时的延迟。这是“PO 匹配差异概览”dashboard 的关键部分。获取方式这在获取上具有挑战性，可能需要高级推断。它可以通过查找匹配状态显示失败后，与发票相关的第一个用户评论、编辑或任务分配的 timestamp 来得出。捕获查找“发现匹配差异”event 后的第一个由用户发起的变更 event。事件类型 inferred
	已释放发票暂停	发票上之前设置的暂缓已被移除，允许其继续进行付款流程。与设置暂缓一样，这也是记录在发票审计轨迹中的明确操作。
为何重要从挂起到释放之间的时间对于“平均付款冻结时长”KPI 至关重要。此活动标志着延迟的结束，分析其触发因素可以发现实现快速解决的机会。获取方式这是一个在发票历史记录或审计日志中发现的明确 event。它被记录为独立的用户或系统操作。捕获从发票历史记录中过滤出“解除暂缓”（hold released）或类似的系统 event。事件类型 explicit
	识别到匹配差异	当自动化系统因数量、价格或其他明细不一致而导致发票与采购订单匹配失败时发生。这可以从发票状态转变为需要人工干预的状态（如“未匹配”或“不匹配”）来推断。
为何重要此活动是异常处理的入口点，也是延迟的常见来源。分析其频率和根本原因对于提高首次匹配率和减轻人工工作量至关重要。获取方式根据发票的匹配状态推导得出。“未匹配”、“不匹配”或类似状态表示存在需要人工审核的差异。这在发票对象中进行跟踪。捕获检测 PO 匹配状态变更为指示失败的值时的 timestamp。事件类型 inferred

推荐可选

提取指南

如何从Coupa获取数据

步骤

前提条件：确保您的 Coupa 用户账号拥有允许创建、编辑和调度报告的权限角色。您还需要访问以下 Coupa data 对象：Invoice Header、Invoice Audit Trail、Approval 和 Payment Information。
进入报告模块：登录 Coupa 实例并导航至“报告”部分。通常位于主菜单或专门的分析选项卡下。
创建核心发票报告：点击“创建报告”。选择 Invoice Header 作为主要 data 源。此报告将成为多个基于状态活动的分析基础。请为其命名，例如“ProcessMind - 发票主数据”。
添加关联数据对象：在报告生成器中，将 Invoice Header 对象与关联对象连接以丰富 data。添加 Supplier、Created By User 和 Updated By User 以获取供应商和用户信息。这对于填充推荐属性至关重要。
创建特定事件报告：由于事件日志的特殊性，您无法通过单一报告生成所有必需行。您必须创建多个报告来捕捉不同类型的 event，稍后再进行合并。
- 报告 A：发票状态事件：基于 Invoice Audit Trail 对象并关联 Invoice Header 创建报告。通过过滤审计轨迹中的特定状态更改，该报告将捕捉“Invoice Created”、“Invoice Submitted”、“Invoice Hold Placed”、“Invoice Hold Released”和“Invoice Voided”等活动。
- 报告 B：审批事件：基于 Approval 对象并关联 Invoice Header 创建报告。该报告将捕捉“Invoice Sent for Approval”、“Invoice Approved”和“Invoice Rejected”等活动。
- 报告 C：付款事件：基于 Payment Information 对象并关联 Invoice Header 创建报告。这将捕捉“Payment Scheduled”和“Payment Executed”事件。
配置各报告列：为您创建的每个报告添加必要的列。您需要手动将 Coupa 字段映射到所需的事件日志 Schema。例如，在“审批事件”报告中，添加 Approval > Created At 并重命名为 EventTime，添加一个文本为“Invoice Approved”的自定义列并命名为 ActivityName，并添加 Invoice Header > Invoice Number 作为 InvoiceNumber。
定义报告过滤器：在每个报告的过滤器部分，添加日期过滤器以限制 data 量。建议针对 Invoice Header > Created At 过滤过去 3 到 6 个月的 data。如有需要，还可添加特定公司代码或法律实体的过滤器。
运行并导出报告：分别保存并运行每个报告。将每个报告的结果导出为 CSV 文件。验证每个文件中的 data 是否正确，且包含您配置的列。
调度导出任务：确认报告无误后，将其设置为定期运行（如每日）。配置计划任务，将 CSV 文件导出至指定位置（建议使用 SFTP 服务器），以便自动检索。
合并与转换数据：使用外部脚本（如 Python、PowerShell）或 ETL 工具执行最终的 data 转换。该脚本必须：
- 从 SFTP 服务器下载所有 CSV 文件。
- 标准化所有文件的列名，以匹配事件日志 Schema（InvoiceNumber、ActivityName、EventTime 等）。
- 将来自各个文件的所有行合并到一个统一的事件日志文件中。
最终格式化与上传：确保最终合并的文件保存为 UTF-8 编码的 CSV。该文件现在可以上传至 ProcessMind 应用进行分析。

配置

核心数据对象：数据提取依赖于几个必须可访问的 Coupa 核心对象。包括：Invoice Header、Invoice Audit Trail、Approval、Payment Information 以及 Supplier。
日期范围过滤：为了平衡性能与 data 量，应用日期过滤至关重要。对于初步分析，建议针对 Invoice Header > Created At 设置 3 到 6 个月的滚动周期过滤。
必要过滤器：请务必按“公司代码”或“法律实体”进行过滤，确保 data 与所分析的业务单元相关。您可能还希望排除某些发票状态（如“草稿”），如果它们与流程无关。
报告计划任务：Coupa 支持按日、周或月调度报告。对于 Process Mining，建议进行每日导出以保持分析的实时性。建议配置导出功能，将 CSV 文件发送至 SFTP 服务器以实现自动化。
用户权限：配置和运行这些报告的用户账号必须拥有创建和调度报告的权限角色，并对上述所有 data 对象拥有只读权限。

a 查询示例 config

// This is a configuration guide for creating multiple Coupa reports. These reports must be combined externally to form the final event log.

// --- Report 1: Invoice Creation Event ---
// Primary Object: Invoice Header
// Columns:
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Invoice Created' (Static Value)
//   'EventTime' = Invoice Header > Created At
//   'User' = Invoice Header > Created By > Login
//   'VendorName' = Invoice Header > Supplier > Name
//   'InvoiceTotalAmount' = Invoice Header > Total
//   'PaymentDueDate' = Invoice Header > Payment Due Date
//   'PurchaseOrderNumber' = Invoice Header > PO Number
//   'InvoiceStatus' = Invoice Header > Status

// --- Report 2: Invoice Status Change Events ---
// Primary Object: Invoice Audit Trail
// Joined Object: Invoice Header (on Invoice ID)
// Columns:
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = CASE WHEN (Field Name = 'status' AND Old Value = 'new' AND New Value = 'pending_approval') THEN 'Invoice Submitted for Processing' WHEN (Field Name = 'po_match_status' AND New Value = 'matched') THEN 'Invoice Matched to PO' WHEN (Field Name = 'po_match_status' AND New Value = 'unmatched') THEN 'Matching Discrepancy Identified' WHEN (Field Name = 'status' AND New Value = 'on_hold') THEN 'Invoice Hold Placed' WHEN (Field Name = 'status' AND Old Value = 'on_hold') THEN 'Invoice Hold Released' WHEN (Field Name = 'exported' AND New Value = 't') THEN 'Invoice Posted for Payment' WHEN (Field Name = 'status' AND New Value = 'voided') THEN 'Invoice Voided' END
//   'EventTime' = Invoice Audit Trail > Created At
//   'User' = Invoice Audit Trail > Updated By > Login
//   'VendorName', 'InvoiceTotalAmount', etc. from joined Invoice Header.
// Filters:
//   Field Name IN ('status', 'po_match_status', 'exported')

// --- Report 3: Invoice Approval Events ---
// Primary Object: Approval
// Joined Object: Invoice Header (on Invoice ID)
// This report will create multiple rows from one source object. This logic needs to be applied in the external transformation script.
// Logic Block 1: Invoice Sent for Approval (First Approver Record for the Invoice)
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Invoice Sent for Approval'
//   'EventTime' = MIN(Approval > Created At) GROUP BY InvoiceNumber
//   'User' = Approver associated with the MIN(Created At) timestamp.
// Logic Block 2: Invoice Rejected
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Invoice Rejected'
//   'EventTime' = Approval > Created At
//   'User' = Approval > Approver > Login
//   Filter: Approval > Status = 'rejected'
// Logic Block 3: Invoice Approved (Final Approver Record)
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Invoice Approved'
//   'EventTime' = MAX(Approval > Created At) where Status is 'approved'
//   'User' = Approver associated with the MAX(Created At) timestamp.

// --- Report 4: Discrepancy Resolution Event ---
// Primary Object: Invoice Audit Trail
// Joined Object: Invoice Header (on Invoice ID)
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Discrepancy Resolution Started'
//   'EventTime' = Invoice Audit Trail > Created At
//   'User' = Invoice Audit Trail > Updated By > Login
// Filter:
//   This event is difficult. A common proxy is the first user comment or field change after the PO match status changes to 'unmatched'.
//   Logic: Find the MIN(Created At) from the audit trail where the timestamp is greater than the timestamp of the 'Matching Discrepancy Identified' event.

// --- Report 5: Payment Events ---
// Primary Object: Payment Information
// Joined Object: Invoice Header (on Invoice ID)
// Logic Block 1: Payment Scheduled
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Payment Scheduled'
//   'EventTime' = Payment Information > Payment Date
//   'User' = 'System'
// Logic Block 2: Payment Executed
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Payment Executed'
//   'EventTime' = Payment Information > Paid At
//   'User' = 'System'
// Filter:
//   Payment Information > Paid At IS NOT NULL

步骤

生成 Coupa API Key：以管理员身份登录您的 Coupa 实例。导航至 Setup > Company Setup > API Keys。创建一个新的 API Key。确保该 Key 拥有以下范围的只读权限：core.invoice.read、core.user.read、core.supplier.read、core.approval.read 和 core.payment.read。
搭建 Python 环境：确保安装了 Python 3.6 或更高版本。创建一个新的项目目录并使用 pip 安装必要的库：pip install requests pandas。
配置 Python 脚本：创建一个新的 Python 文件（例如 extract_coupa_invoices.py）。将提供的脚本复制到此文件中。将 YOUR_COUPE_INSTANCE_URL、YOUR_API_KEY 和 START_DATE 占位符替换为您具体的实例详细信息和所需的提取起始日期。
执行脚本：在终端中使用命令 python extract_coupa_invoices.py 运行脚本。脚本将开始从 Coupa API 获取 data。
监控提取进度：脚本将在控制台打印进度更新，显示已处理的发票数量。由于 API 频率限制，根据日期范围和 data 量的大小，这可能需要较长时间。
理解核心逻辑：脚本首先查询 /api/invoices 终端，以获取在指定日期范围内更新的所有发票列表。它会自动处理分页以获取所有记录。
处理每张发票：对于检索到的每张发票，脚本会根据可用的 timestamp 和相关 data 生成多个事件日志条目。例如，created-at 用于“Invoice Created”，submitted-at 用于“Invoice Submitted for Processing”。
获取审批详情：为了捕捉审批和拒绝 event，脚本会为每张发票向 /api/invoices/{invoice_id}/approvals 终端发起二次 API 调用。然后处理该列表以创建“Invoice Sent for Approval”、“Invoice Approved”和“Invoice Rejected”活动。
获取付款详情：如果需要付款信息，脚本会查询 /api/payments 终端，并通过发票 ID 进行过滤，以查找与“Payment Scheduled”和“Payment Executed”相关的付款记录。
转换与汇总数据：所有生成的 event 都会收集到一个字典列表中。每个字典代表最终事件日志中的一行。
创建事件日志文件：处理完所有发票后，脚本会将汇总后的 data 转换为 pandas DataFrame。然后将该 DataFrame 保存为同名目录下的 CSV 文件 coupa_invoice_event_log.csv，即可上传至 ProcessMind。

配置

API Key 权限：API Key 必须至少拥有对 Coupa 中 Invoices、Approvals、Users、Suppliers 和 Payments 对象的只读访问权限。权限不足将导致脚本报错或 data 采集不完整。
日期范围：脚本使用 updated-at[gt] 过滤器，仅抓取自指定 START_DATE 以来新建或变更的发票。首次提取时，建议选择 3-6 个月的时间段，以平衡 data 量与性能。对于后续的增量加载，请将 START_DATE 设置为上次成功提取的 timestamp。
API 频率限制：Coupa 对其 API 实施频率限制。提供的脚本在处理每张发票之间包含了 time.sleep(0.5) 调用，以防止超出限制。您可能需要根据具体的 Coupa 实例配置调整此数值。
自定义字段：此提取脚本仅包含 Coupa 标准字段。如果您的组织在发票上使用了分析所需的自定义字段，则需要修改脚本以解析 API 响应中的 custom-fields 元素，并将其作为列添加到输出中。

a 查询示例 python

import requests
import pandas as pd
import time
import os
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Coupa instance URL (e.g., class="hl-string">'https://mycompany.coupahost.com')
COUPE_INSTANCE_URL = class="hl-string">'YOUR_COUPE_INSTANCE_URL' 
class=class="hl-string">"hl-comment"># Replace with your Coupa API Key
API_KEY = class="hl-string">'YOUR_API_KEY'
class=class="hl-string">"hl-comment"># Set the start date for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">'2023-01-01' 

class=class="hl-string">"hl-comment"># --- API Setup ---
API_BASE_URL = fclass="hl-string">"{COUPE_INSTANCE_URL}/api"
HEADERS = {
    class="hl-string">'Accept': class="hl-string">'application/json',
    class="hl-string">'X-COUPA-API-KEY': API_KEY
}

class=class="hl-string">"hl-comment"># --- Event Log Storage ---
event_log_records = []

def get_paginated_data(endpoint_url, params=None):
    class="hl-string">"""Fetches all pages of data from a Coupa API endpoint."""
    all_data = []
    url = fclass="hl-string">"{API_BASE_URL}/{endpoint_url}"
    
    class=class="hl-string">"hl-comment"># Coupa uses offset-based pagination, 50 is a common limit
    offset = 0
    while True:
        paginated_params = params.copy() if params else {}
        paginated_params[class="hl-string">'offset'] = offset
        paginated_params[class="hl-string">'limit'] = 50
        
        try:
            response = requests.get(url, headers=HEADERS, params=paginated_params)
            response.raise_for_status()
            data = response.json()
            if not data: class=class="hl-string">"hl-comment"># Break if the page is empty
                break
            all_data.extend(data)
            offset += len(data)
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {url}: {e}")
            break
    return all_data

def add_event(invoice, activity_name, event_time, user_info=None):
    class="hl-string">"""Helper function to create and add an event record."""
    if not event_time:
        return class=class="hl-string">"hl-comment"># Do not add events without a timestamp

    record = {
        class="hl-string">'InvoiceNumber': invoice.get(class="hl-string">'invoice-number'),
        class="hl-string">'ActivityName': activity_name,
        class="hl-string">'EventTime': event_time,
        class="hl-string">'User': user_info.get(class="hl-string">'login') if user_info else None,
        class="hl-string">'VendorName': invoice.get(class="hl-string">'supplier', {}).get(class="hl-string">'name'),
        class="hl-string">'InvoiceTotalAmount': invoice.get(class="hl-string">'total-with-taxes'),
        class="hl-string">'PaymentDueDate': invoice.get(class="hl-string">'payment-date'),
        class="hl-string">'PurchaseOrderNumber': invoice.get(class="hl-string">'purchase-order', {}).get(class="hl-string">'number') if invoice.get(class="hl-string">'purchase-order') else None,
        class="hl-string">'InvoiceStatus': invoice.get(class="hl-string">'status')
    }
    event_log_records.append(record)

def main():
    class="hl-string">"""Main extraction function."""
    print(class="hl-string">"Starting Coupa invoice data extraction...")
    
    class=class="hl-string">"hl-comment"># Fetch all invoices updated since the start date
    invoice_params = {class="hl-string">'updated-at[gt]': START_DATE}
    invoices = get_paginated_data(class="hl-string">'invoices', invoice_params)
    print(fclass="hl-string">"Found {len(invoices)} invoices to process.")

    for i, invoice in enumerate(invoices):
        print(fclass="hl-string">"Processing invoice {i+1}/{len(invoices)}: {invoice.get('invoice-number')}")
        invoice_id = invoice.get(class="hl-string">'id')

        class=class="hl-string">"hl-comment"># Activity: Invoice Created
        add_event(invoice, class="hl-string">'Invoice Created', invoice.get(class="hl-string">'created-at'), invoice.get(class="hl-string">'created-by'))

        class=class="hl-string">"hl-comment"># Activity: Invoice Submitted for Processing
        add_event(invoice, class="hl-string">'Invoice Submitted for Processing', invoice.get(class="hl-string">'submitted-at'), invoice.get(class="hl-string">'submitted-by'))

        class=class="hl-string">"hl-comment"># Activities related to matching status
        if invoice.get(class="hl-string">'po-match-status') == class="hl-string">'matched':
            add_event(invoice, class="hl-string">'Invoice Matched to PO', invoice.get(class="hl-string">'updated-at'), invoice.get(class="hl-string">'updated-by'))
        elif invoice.get(class="hl-string">'po-match-status') in [class="hl-string">'unmatched', class="hl-string">'mismatched']:
            add_event(invoice, class="hl-string">'Matching Discrepancy Identified', invoice.get(class="hl-string">'updated-at'), invoice.get(class="hl-string">'updated-by'))
            class=class="hl-string">"hl-comment"># Inference for Discrepancy Resolution Started is complex. We approximate it as the next update.
            class=class="hl-string">"hl-comment"># A more robust solution would track status changes over time.
            add_event(invoice, class="hl-string">'Discrepancy Resolution Started', invoice.get(class="hl-string">'updated-at'), invoice.get(class="hl-string">'updated-by'))

        class=class="hl-string">"hl-comment"># Activities from Approvals endpoint
        approvals = get_paginated_data(fclass="hl-string">'invoices/{invoice_id}/approvals')
        if approvals:
            class=class="hl-string">"hl-comment"># Sent for Approval is often the creation of the first approval object
            first_approval = approvals[0]
            add_event(invoice, class="hl-string">'Invoice Sent for Approval', first_approval.get(class="hl-string">'created-at'), first_approval.get(class="hl-string">'created-by'))
            
            for approval in approvals:
                approver = approval.get(class="hl-string">'approver')
                if approval.get(class="hl-string">'status') == class="hl-string">'approved':
                    add_event(invoice, class="hl-string">'Invoice Approved', approval.get(class="hl-string">'updated-at'), approver)
                elif approval.get(class="hl-string">'status') == class="hl-string">'rejected':
                    add_event(invoice, class="hl-string">'Invoice Rejected', approval.get(class="hl-string">'updated-at'), approver)

        class=class="hl-string">"hl-comment"># Activities based on status and flags
        if invoice.get(class="hl-string">'on-hold'):
            class=class="hl-string">"hl-comment"># This timestamp is an approximation, representing the last update time when the hold was active.
            add_event(invoice, class="hl-string">'Invoice Hold Placed', invoice.get(class="hl-string">'updated-at'), invoice.get(class="hl-string">'updated-by'))
        class=class="hl-string">"hl-comment"># We canclass="hl-string">'t reliably detect 'Hold Released' without historical data, so we omit it for accuracy.

        if invoice.get(class="hl-string">'exported') == True:
            add_event(invoice, class="hl-string">'Invoice Posted for Payment', invoice.get(class="hl-string">'updated-at'), invoice.get(class="hl-string">'updated-by'))

        if invoice.get(class="hl-string">'status') == class="hl-string">'void':
            add_event(invoice, class="hl-string">'Invoice Voided', invoice.get(class="hl-string">'updated-at'), invoice.get(class="hl-string">'updated-by'))
        
        class=class="hl-string">"hl-comment"># Activities from Payments endpoint
        payments = get_paginated_data(class="hl-string">'payments', {class="hl-string">'invoice-id': invoice_id})
        for payment in payments:
            add_event(invoice, class="hl-string">'Payment Scheduled', payment.get(class="hl-string">'created-at'), payment.get(class="hl-string">'created-by'))
            if payment.get(class="hl-string">'payment-date'):
                add_event(invoice, class="hl-string">'Payment Executed', payment.get(class="hl-string">'payment-date'), payment.get(class="hl-string">'updated-by'))

        class=class="hl-string">"hl-comment"># A short delay to respect API rate limits
        time.sleep(0.5)

    if not event_log_records:
        print(class="hl-string">"No events were generated. Exiting.")
        return

    class=class="hl-string">"hl-comment"># Create DataFrame and save to CSV
    df = pd.DataFrame(event_log_records)
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
    df = df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'])
    
    output_filename = class="hl-string">'coupa_invoice_event_log.csv'
    df.to_csv(output_filename, index=False, encoding=class="hl-string">'utf-8')
    print(fclass="hl-string">"Extraction complete. Event log saved to {os.path.abspath(output_filename)}")

if __name__ == class="hl-string">'__main__':
    main()

步骤

前提条件：确保您的 Coupa 用户账号拥有允许创建、编辑和调度报告的权限角色。您还需要访问以下 Coupa data 对象：Invoice Header、Invoice Audit Trail、Approval 和 Payment Information。
进入报告模块：登录 Coupa 实例并导航至“报告”部分。通常位于主菜单或专门的分析选项卡下。
创建核心发票报告：点击“创建报告”。选择 Invoice Header 作为主要 data 源。此报告将成为多个基于状态活动的分析基础。请为其命名，例如“ProcessMind - 发票主数据”。
添加关联数据对象：在报告生成器中，将 Invoice Header 对象与关联对象连接以丰富 data。添加 Supplier、Created By User 和 Updated By User 以获取供应商和用户信息。这对于填充推荐属性至关重要。
创建特定事件报告：由于事件日志的特殊性，您无法通过单一报告生成所有必需行。您必须创建多个报告来捕捉不同类型的 event，稍后再进行合并。
- 报告 A：发票状态事件：基于 Invoice Audit Trail 对象并关联 Invoice Header 创建报告。通过过滤审计轨迹中的特定状态更改，该报告将捕捉“Invoice Created”、“Invoice Submitted”、“Invoice Hold Placed”、“Invoice Hold Released”和“Invoice Voided”等活动。
- 报告 B：审批事件：基于 Approval 对象并关联 Invoice Header 创建报告。该报告将捕捉“Invoice Sent for Approval”、“Invoice Approved”和“Invoice Rejected”等活动。
- 报告 C：付款事件：基于 Payment Information 对象并关联 Invoice Header 创建报告。这将捕捉“Payment Scheduled”和“Payment Executed”事件。
配置各报告列：为您创建的每个报告添加必要的列。您需要手动将 Coupa 字段映射到所需的事件日志 Schema。例如，在“审批事件”报告中，添加 Approval > Created At 并重命名为 EventTime，添加一个文本为“Invoice Approved”的自定义列并命名为 ActivityName，并添加 Invoice Header > Invoice Number 作为 InvoiceNumber。
定义报告过滤器：在每个报告的过滤器部分，添加日期过滤器以限制 data 量。建议针对 Invoice Header > Created At 过滤过去 3 到 6 个月的 data。如有需要，还可添加特定公司代码或法律实体的过滤器。
运行并导出报告：分别保存并运行每个报告。将每个报告的结果导出为 CSV 文件。验证每个文件中的 data 是否正确，且包含您配置的列。
调度导出任务：确认报告无误后，将其设置为定期运行（如每日）。配置计划任务，将 CSV 文件导出至指定位置（建议使用 SFTP 服务器），以便自动检索。
合并与转换数据：使用外部脚本（如 Python、PowerShell）或 ETL 工具执行最终的 data 转换。该脚本必须：
- 从 SFTP 服务器下载所有 CSV 文件。
- 标准化所有文件的列名，以匹配事件日志 Schema（InvoiceNumber、ActivityName、EventTime 等）。
- 将来自各个文件的所有行合并到一个统一的事件日志文件中。
最终格式化与上传：确保最终合并的文件保存为 UTF-8 编码的 CSV。该文件现在可以上传至 ProcessMind 应用进行分析。

配置

核心数据对象：数据提取依赖于几个必须可访问的 Coupa 核心对象。包括：Invoice Header、Invoice Audit Trail、Approval、Payment Information 以及 Supplier。
日期范围过滤：为了平衡性能与 data 量，应用日期过滤至关重要。对于初步分析，建议针对 Invoice Header > Created At 设置 3 到 6 个月的滚动周期过滤。
必要过滤器：请务必按“公司代码”或“法律实体”进行过滤，确保 data 与所分析的业务单元相关。您可能还希望排除某些发票状态（如“草稿”），如果它们与流程无关。
报告计划任务：Coupa 支持按日、周或月调度报告。对于 Process Mining，建议进行每日导出以保持分析的实时性。建议配置导出功能，将 CSV 文件发送至 SFTP 服务器以实现自动化。
用户权限：配置和运行这些报告的用户账号必须拥有创建和调度报告的权限角色，并对上述所有 data 对象拥有只读权限。

a 查询示例 config

// This is a configuration guide for creating multiple Coupa reports. These reports must be combined externally to form the final event log.

// --- Report 1: Invoice Creation Event ---
// Primary Object: Invoice Header
// Columns:
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Invoice Created' (Static Value)
//   'EventTime' = Invoice Header > Created At
//   'User' = Invoice Header > Created By > Login
//   'VendorName' = Invoice Header > Supplier > Name
//   'InvoiceTotalAmount' = Invoice Header > Total
//   'PaymentDueDate' = Invoice Header > Payment Due Date
//   'PurchaseOrderNumber' = Invoice Header > PO Number
//   'InvoiceStatus' = Invoice Header > Status

// --- Report 2: Invoice Status Change Events ---
// Primary Object: Invoice Audit Trail
// Joined Object: Invoice Header (on Invoice ID)
// Columns:
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = CASE WHEN (Field Name = 'status' AND Old Value = 'new' AND New Value = 'pending_approval') THEN 'Invoice Submitted for Processing' WHEN (Field Name = 'po_match_status' AND New Value = 'matched') THEN 'Invoice Matched to PO' WHEN (Field Name = 'po_match_status' AND New Value = 'unmatched') THEN 'Matching Discrepancy Identified' WHEN (Field Name = 'status' AND New Value = 'on_hold') THEN 'Invoice Hold Placed' WHEN (Field Name = 'status' AND Old Value = 'on_hold') THEN 'Invoice Hold Released' WHEN (Field Name = 'exported' AND New Value = 't') THEN 'Invoice Posted for Payment' WHEN (Field Name = 'status' AND New Value = 'voided') THEN 'Invoice Voided' END
//   'EventTime' = Invoice Audit Trail > Created At
//   'User' = Invoice Audit Trail > Updated By > Login
//   'VendorName', 'InvoiceTotalAmount', etc. from joined Invoice Header.
// Filters:
//   Field Name IN ('status', 'po_match_status', 'exported')

// --- Report 3: Invoice Approval Events ---
// Primary Object: Approval
// Joined Object: Invoice Header (on Invoice ID)
// This report will create multiple rows from one source object. This logic needs to be applied in the external transformation script.
// Logic Block 1: Invoice Sent for Approval (First Approver Record for the Invoice)
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Invoice Sent for Approval'
//   'EventTime' = MIN(Approval > Created At) GROUP BY InvoiceNumber
//   'User' = Approver associated with the MIN(Created At) timestamp.
// Logic Block 2: Invoice Rejected
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Invoice Rejected'
//   'EventTime' = Approval > Created At
//   'User' = Approval > Approver > Login
//   Filter: Approval > Status = 'rejected'
// Logic Block 3: Invoice Approved (Final Approver Record)
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Invoice Approved'
//   'EventTime' = MAX(Approval > Created At) where Status is 'approved'
//   'User' = Approver associated with the MAX(Created At) timestamp.

// --- Report 4: Discrepancy Resolution Event ---
// Primary Object: Invoice Audit Trail
// Joined Object: Invoice Header (on Invoice ID)
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Discrepancy Resolution Started'
//   'EventTime' = Invoice Audit Trail > Created At
//   'User' = Invoice Audit Trail > Updated By > Login
// Filter:
//   This event is difficult. A common proxy is the first user comment or field change after the PO match status changes to 'unmatched'.
//   Logic: Find the MIN(Created At) from the audit trail where the timestamp is greater than the timestamp of the 'Matching Discrepancy Identified' event.

// --- Report 5: Payment Events ---
// Primary Object: Payment Information
// Joined Object: Invoice Header (on Invoice ID)
// Logic Block 1: Payment Scheduled
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Payment Scheduled'
//   'EventTime' = Payment Information > Payment Date
//   'User' = 'System'
// Logic Block 2: Payment Executed
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Payment Executed'
//   'EventTime' = Payment Information > Paid At
//   'User' = 'System'
// Filter:
//   Payment Information > Paid At IS NOT NULL

您的采购到付款 - 发票处理 data 模板

您的采购到付款 - 发票处理 data 模板

采购到付款 - 发票处理属性

采购到付款 - 发票处理活动

提取指南

Coupa 计划报告与 CSV 数据导出

步骤

配置

a 查询示例 config

使用 Coupa REST API 进行提取的 Python 脚本

步骤

配置

a 查询示例 python

通过计划任务 SFTP 自动导出 Coupa 数据

步骤

配置

a 查询示例 config

准备好开始了吗？

释放极致效率：立即优化您的 P2P 发票处理

您的采购到付款 - 发票处理 data 模板

您的采购到付款 - 发票处理 data 模板

采购到付款 - 发票处理属性

采购到付款 - 发票处理活动

提取指南

Coupa 计划报告与 CSV 数据导出

步骤

配置

a 查询示例 config

使用 Coupa REST API 进行提取的 Python 脚本

步骤

配置

a 查询示例 python

通过计划任务 SFTP 自动导出 Coupa 数据

步骤

配置

a 查询示例 config

我们重视您的隐私

准备好开始了吗？

释放极致效率：立即优化您的 P2P 发票处理