采购到付款 (P2P) — 采购申请数据模板

Coupa

← 返回改进指南

采购到付款 - 采购申请属性 (22) 采购到付款 - 采购申请活动 (12) 提取指南 (3)

采购到付款 (P2P) — 采购申请数据模板

这份全面的 data 模板为您收集分析采购到付款申请流程所需的信息提供了结构化方法。它概述了构建稳健 event log 所需的基本属性和活动。您还可以在其中找到从 Coupa 系统中高效提取这些 data 的指南。

全面分析的推荐属性
建议重点跟踪的关键流程活动
实用的数据提取指南

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

下载模板

采购到付款 - 采购申请属性

这些是建议包含在 event log 中的 data 字段，用于对您的采购到付款申请流程进行全面分析。

5 必填 5 推荐 12 可选

	名称	描述
	Event 时间 EventTime	活动发生的精确日期和时间。
描述 Event Time（即时间戳）记录了采购申请活动被记录的精确时刻。此数据对于按时间顺序排列事件以构建流程流至关重要。它是所有基于时间的分析的基础，包括计算周期时间、通过衡量活动间的耗时来识别瓶颈，以及了解不同时段的流程绩效。准确且细致的时间戳是进行有意义流程分析的核心。为何重要此 timestamp 对于正确排列 event 顺序以及计算所有基于持续时间的指标（如周期时间和瓶颈）至关重要。获取方式此信息捕获在 Coupa 中每项申请的审计跟踪或历史记录中，通常作为每项操作的“created_at”或“updated_at”字段。示例 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:22:05Z
	活动名称 ActivityName	采购申请在某一时间点发生的具体业务活动或 event 的名称。
描述此属性记录采购申请生命周期中的各个步骤，例如“申请已创建”、“审批步骤已通过”和“申请已寻源”。每项活动代表申请过程中的一个特定里程碑或动作。分析这些活动的顺序和频率是 Process Mining 的基础，因为它支持流程图的可视化、识别常见路径并检测与标准程序的偏差。为何重要它定义了流程图中的步骤，让采购申请流的可视化和分析成为可能。获取方式这通常源自 Coupa 系统内的 event log、状态变更记录或审计跟踪。可能需要从状态字段或操作代码进行映射。示例已创建招聘需求招聘需求已提交审批步骤已通过采购申请已拒绝采购订单已创建
	采购请购ID PurchaseRequisitionId	每项采购申请的唯一标识符，作为流程的主要 case 标识符。
描述采购申请 ID 是连接单个商品或服务请求相关所有活动的核心 key。每项申请在创建时都会分配一个唯一的 ID，并在其整个生命周期内保持不变。这实现了对申请的端到端跟踪，从最初的创建和提交，到所有审批或拒绝步骤，再到最终的寻源和关闭。在 Process Mining 中，每个 event log 条目都与此 ID 绑定，从而能够重建每个 case 的完整路径。为何重要这是连接所有流程步骤的核心 Case ID，支持对申请从开始到结束的生命周期进行完整分析。获取方式这是在 Coupa 申请模块及相关 data 导出中发现的主键字段。示例 PR-102934PR-102935PR-102936
	最后数据更新 LastDataUpdate	用于指示数据上次从源系统刷新的时间戳。
描述此属性记录了最近一次从 Coupa 提取 data 的日期和时间。它提供了被分析 data 新鲜度的透明度。了解 data 的近时性对于用户理解洞察是反映当前运营状态还是早期状态至关重要，这对于监控持续运营的仪表板尤为重要。为何重要告知用户数据的新鲜程度，确保他们了解分析的时间范围，并基于最新信息做出决策。获取方式此 timestamp 在成功完成 data 提取运行后由 data 流水线或 ETL 工具生成并添加。示例 2024-05-21T02:00:00Z
	源系统 SourceSystem	标识数据的来源系统。
描述此属性指定流程 data 来源的记录系统。在此分析中，该值将始终为“Coupa”。包含此字段是一项最佳实践，尤其是在可能合并来自多个系统 data 的环境中。它提供了关于 data 血缘的基本背景，并有助于管理 data 治理和质量规则。为何重要提供清晰的 data 血缘，这对于 data 治理以及混合来自多个企业系统的 data 时至关重要。获取方式这通常是在 Data 提取和转换过程中添加的静态值，用于标记数据集的来源。示例 Coupa
	审批人 Approver	负责审批活动的用户或小组。
描述此属性标识分配给审批步骤的具体个人或审批组。它填入“审批步骤开始”、“审批步骤通过”和“审批步骤拒绝”等活动。按审批人分析 data 是构建“审批人绩效和负载”仪表板的关键，有助于测量个人审批时间、识别由特定审批人造成的瓶颈并评估工作量分配。为何重要对于分析审批人绩效、负载平衡以及识别与特定个人或审批组相关的瓶颈至关重要。获取方式此信息位于 Coupa 中与每项申请相关的审批链详情中，可能需要与 User data 进行关联。示例 David Miller二级财务审批人Susan Chen
	总金额 TotalAmount	采购申请的总金额。
描述此属性代表申请中请求的所有商品服务的总成本。金额是流程分析中的关键因素，因为它通常会影响审批工作流的复杂程度；高价值申请通常需要更多审批步骤。按价值区间（如 <$1000, $1000-$10000）分析流程指标，可以揭示流程如何处理具有不同财务意义的申请。为何重要有助于分析不同金额申请的流程差异，因为高额申请通常会触发更复杂的审批 Workflow。获取方式这是 Coupa 申请对象表头上的标准字段，通常命名为“total”或“total_amount”。示例 500.0012550.7599.99
	请求人 Requester	创建并提交采购申请的员工。
描述此属性标识发起请求的个人。按申请人分析 data 有助于发现与特定用户相关的模式（如高修订率或频繁被拒），这可能表明需要额外的培训。它还用于分析不同用户或用户组的申请量和流程行为。为何重要支持按用户分析流程行为，有助于识别培训需求并了解不同个体与流程的交互方式。获取方式 Coupa 中申请对象的标准字段，通常链接到用户对象，名为 'requester' 或 'created_by'。示例爱丽丝·约翰逊Bob SmithCharlie Brown
	部门 Department	承担该申请费用的业务部门或成本中心。
描述 “部门”属性将每项申请链接到特定的组织单元或成本中心。这是对比分析的关键维度。它允许按部门对仪表板和 KPI 进行过滤和切片，使管理人员能够比较组织不同部门的审批周期、拒绝率和合规性。这有助于发现特定部门的问题或最佳实践。为何重要支持在不同业务部门之间比较周期时间和驳回率等流程 KPI，从而突出改进领域。获取方式这是 Coupa 申请对象上的标准字段，通常与申请人的用户配置文件关联，或在申请行项目上指定。示例市场营销IT运维设施研发
	采购申请状态 RequisitionStatus	采购申请的当前或最终状态。
描述此属性表示 data 提取时的申请总体状态或其最终结果。常见状态包括“待审批”、“已批准”、“已拒绝”、“已撤回”和“已关闭”。这是过滤和分析的关键维度，用于计算批准率和拒绝率、监控未结申请的当前工作量，以及了解请求的最终处理结果。为何重要对于了解申请结果、计算批准和驳回率以及监控进行中申请的当前状态至关重要。获取方式这是 Coupa 采购申请对象上的标准字段，通常命名为“status”或“state”。示例待审批已批准已驳回已撤回已结案
	供应商名称 SupplierName	为该申请选定的供应商或厂商名称。
描述此属性标识所申请商品或服务的意向供应商。供应商可以由申请人指定，或在寻源过程中稍后添加。按供应商分析流程指标有助于评估供应商绩效，并识别与某些供应商的互动是否导致了更长的周期或其他流程效率低下。它为采购战略和供应商关系管理提供了重要背景。为何重要支持根据选定供应商进行流程绩效分析，为寻源策略和供应商管理提供参考。获取方式此信息可在 Coupa 的 Requisition Line 对象中找到，通常显示为“supplier”或“vendor”字段。示例订书针戴尔科技 (Dell Technologies)埃森哲 (Accenture)CDW
	品类 Commodity	所申请商品或服务的高级类别。
描述 “商品”属性为申请单上的项目提供标准化的分类，如“办公用品”、“计算机硬件”或“营销服务”。这允许根据所购物品分析采购模式和流程变体。某些商品可能有专门的审批要求或寻源策略，按商品分析流程有助于优化不同支出类别的采购。为何重要有助于分析支出类别，并了解流程行为（如审批时间）是否随所购商品或服务类型的不同而变化。获取方式这是 Coupa 中的标准字段，通常在申请行项目级别可用，可能需要聚合到表头级别。示例办公用品电脑硬件营销服务差旅
	审批工作流路径 ApprovalWorkflowPath	应用于该申请的特定审批链或 Workflow 模板的标识符。
描述此属性标识申请应遵循的预定义审批序列。它由业务规则决定，通常基于金额、部门和申请类型等因素。分析此属性是“申请政策合规”仪表板的核心。通过将实际的审批序列与分配的工作流路径进行对比，可以检测偏差、衡量一致率并识别未管理的异常。为何重要支持合规性分析，允许对预期和实际审批步骤进行比较，从而发现流程偏差。获取方式请参阅 Coupa 文档。这通常派生自为该申请触发的审批链名称或 Workflow 规则名称。示例标准审批 <$5kIT 硬件审批 >$10k资本支出 CFO 审查
	审批步骤耗时 ApprovalStepDuration	申请在单个审批步骤中等待的时间。
描述此计算指标测量“审批步骤开始”活动与其对应的“审批步骤通过”或“审批步骤拒绝”活动之间的时间间隔。它分离出审批链中每个不同阶段的等待时间。这对于“关键审批步骤瓶颈”仪表板至关重要，因为它能精准定位到底是哪些审批人或审批阶段导致了整个流程中最严重的延迟。为何重要通过测量每个具体步骤的等待时间（而非仅看总周期时间），精准定位审批工作流中的具体瓶颈。获取方式在 Process Mining 工具中通过计算“审批步骤已开始”与后续最终审批事件（通过/驳回）之间的时间差得出。示例 1.2 天4 小时3.8 天
	审批步骤计数 ApprovalStepCount	申请经历的审批步骤总数。
描述此计算属性统计每项申请中不同“审批步骤已通过”活动的数量。它有助于量化每个 case 审批工作流的复杂程度。这是“平均审批步数”KPI 的基础，可用于识别遵循异常漫长或复杂审批路径的申请，这可能意味着需要简化工作流。为何重要量化每项采购申请审批工作流的复杂程度，有助于识别需要精简的过于复杂的路径。获取方式此指标在 Process Mining 工具中通过统计每个 Case ID 出现“审批步骤已通过”的次数来计算。示例 253
	已修订 IsAmended	一个布尔标志，如果申请在初始提交后经过一次或多次修改，则为 true。
描述此计算属性是一个简单的标记 (True/False)，表示给定 case 是否发生了“申请已修订”活动。它通过允许用户轻松隔离需要更改的申请，简化了分析和过滤。这用于计算申请修订率 KPI，并为“申请修订量”仪表板提供支持，有助于识别返工的根本原因并提高一次性通过率。为何重要简化了修订率 KPI 的计算，并允许轻松区分需要返工的 case 和不需要返工的 case。获取方式这是在 Process Mining 工具中通过检查每个 case 的 event log 中是否存在“申请已修订”活动来计算的。示例 truefalse
	拒绝原因 RejectionReason	审批人在拒绝申请或审批步骤时提供的理由。
描述当审批人拒绝申请时，通常会提供理由。此属性捕获这些文字说明。分析拒绝原因可以为申请失败的原因提供直接的定性反馈。这种洞察对于根本原因分析非常有价值，有助于识别编码错误、预算不足或理由不充分等常见问题，进而通过培训或流程改进来解决这些问题。为何重要提供对流程失败根本原因的直接洞察，有助于确定需要进行用户培训或流程说明的环节。获取方式此信息通常捕获在申请审批历史中与“已拒绝”状态变更相关的评论或注释字段中。示例成本中心有误超出本季度预算重复请求提供的理由不充分
	申请单类型 RequisitionType	采购申请的类别或类型，例如“资本支出”、“运营支出”或“软件”。
描述采购申请类型是一种分类，有助于根据业务目的或采购性质对申请进行归类。此属性对于合规分析以及了解不同类型的请求在流程中的流转方式非常有价值。例如，资本支出请求可能比标准运营请求遵循更严格、更长的审批路径。按申请类型分析流程可以为流程优化提供宝贵的洞察。为何重要支持按申请的业务目的进行细分分析，因为不同类型的申请可能对应不同的流程和政策。获取方式这可能是 Coupa 申请对象上的自定义或标准分类字段。示例资本支出运营支出IT硬件专业服务
	紧急程度 UrgencyLevel	表示采购申请紧急程度的分类，例如“高”、“中”或“低”。
描述 “紧急程度”通常映射到优先级字段，允许申请人标记需要加急处理的请求。此属性对于“紧急申请处理时间”仪表板至关重要。通过比较高紧急度申请与标准申请的周期时间，企业可以评估其优先级机制是否有效，以及紧急业务需求是否得到了及时的满足。为何重要支持分析紧急请求是否比标准请求处理得更快，从而验证优先级政策的有效性。获取方式这可能是 Coupa 申请对象上的标准或自定义字段。请咨询 Coupa 文档或系统配置。示例高中低
	货币 Currency	采购申请总额的货币代码。
描述此属性指定了申请总额所使用的货币（如 USD, EUR, GBP）。这对于任何财务分析都是必不可少的背景信息，尤其是对于在多货币环境下运行的跨国组织。它确保货币价值得到正确解释，并支持在财务报表和仪表板中进行适当的转换和聚合。为何重要为“总额”属性提供必要的背景，确保在多货币环境下的财务分析准确无误。获取方式这是 Coupa 申请对象上的标准字段，通常命名为“currency_code”或类似名称。示例美元EURGBP
	采购申请审批周期 RequisitionApprovalCycleTime	从申请首次提交到获得最终批准所经过的总时间。
描述这是一个计算指标，用于测量核心审批流程的持续时间。它通过计算每个 case 的“申请已提交”活动与“申请已通过”活动之间的时间差得出。这是该流程最重要的 KPI 之一，因为它直接量化了审批工作流的效率。它被用于多个仪表板，以跟踪绩效、识别瓶颈并衡量流程改进措施的效果。为何重要这是衡量流程效率的主要 KPI。它量化了审批所需的时间，对于识别瓶颈至关重要。获取方式此指标在 Process Mining 工具中通过从“申请已通过”的 timestamp 中减去“申请已提交”的 timestamp 来计算。示例 2.5 天8 小时15.2 天
	采购订单ID PurchaseOrderId	根据获批申请创建的采购订单标识符。
描述一旦采购申请获得完全批准并完成寻源，通常会创建一个采购订单。此属性存储生成的 PO 的 ID。它是连接上游申请流程和下游采购订单流程的关键纽带，支持计算“从申请批准到 PO 创建的时间”这一 KPI，并允许对整个采购到付款周期进行更广泛的端到端分析。为何重要将采购申请链接到后续的采购订单，从而能够分析交接时间，并提供更广泛的端到端 P2P 视角。获取方式这是 Coupa 申请对象上的标准字段，在 PO 创建后会自动填充。示例 PO-45000123PO-45000124PO-45000125

必填推荐可选

采购到付款 - 采购申请活动

这些是需要在 event log 中捕获的关键流程步骤和里程碑，以便准确发现您的采购到付款申请 workflow。

6 推荐 6 可选

	活动	描述
	已创建招聘需求	用户发起一项新的采购申请并将其保存为草稿。这是每个申请 case 的起点，通常根据申请记录本身的创建时间戳推断得出。
为何重要此活动标志着申请生命周期的开始。分析从创建到提交的时间可以揭示由用户困惑或系统复杂性导致的延迟。获取方式该 event 是从给定采购申请 ID 的“requisition_headers”表的“created-at”timestamp 中捕获的。捕获使用申请表头记录的创建 timestamp。事件类型 inferred
	招聘需求已提交	申请人正式将完成的申请提交至审批工作流。通过观察系统的审计日志或历史表中申请状态从“草稿”变为“待审批”，可以推断出该 event。
为何重要提交会触发审批流程，使其成为衡量“平均申请审批周期时间”KPI 的关键里程碑。此点之前的延迟通常与用户有关，而此点之后的延迟则与流程有关。获取方式从 'requisition_headers' 表的状态变更（特别是当 'status' 字段变为 'pending_approval' 时）推断得出。此变更的时间戳可在相关的审计追踪中找到。捕获识别申请状态首次变更为 'pending_approval'（待审批）时的时间戳。事件类型 inferred
	采购申请已关闭	申请正式关闭，表示不再对其采取进一步行动。这可能发生在 PO 创建并履行后，或者申请在获批后但在订购前被取消。
为何重要此活动作为申请生命周期的明确终点。它确保 case 有清晰的结论，防止它们在流程分析中无限期地显示为“活动中”。获取方式当 'status' 字段更新为 'closed' 时，从 'requisition_headers' 表的状态变更推断得出。时间戳记录在相关的审计追踪中。捕获识别申请的整体状态变更为 'closed'（已关闭）时的时间戳。事件类型 inferred
	采购申请已批准	申请已成功通过审批工作流中的所有必要步骤。这是根据申请表头的整体状态变为“已批准”推断出来的。
为何重要这是一个成功的关键里程碑，标志着审批周期的结束。达到此活动的时间是首要 KPI，并作为下游采购操作的触发器。获取方式当 'status' 字段更新为 'approved' 时，从 'requisition_headers' 表的状态变更推断得出。时间戳记录在相关的审计追踪中。捕获识别申请的整体状态变更为 'approved'（已批准）时的时间戳。事件类型 inferred
	采购申请已拒绝	申请在审批过程中被最终拒绝，不会转换为采购订单。这是根据申请表头的整体状态变为“已拒绝”推断出来的。
为何重要此活动代表流程中的最终失败。分析这些 event 是降低“申请拒绝率”并识别根本原因（如违反政策或预算问题）的关键。获取方式当 'status' 字段更新为 'rejected' 时，从 'requisition_headers' 表的状态变更推断得出。时间戳记录在相关的审计追踪中。捕获识别申请的整体状态变更为 'rejected'（已驳回）时的时间戳。事件类型 inferred
	采购订单已创建	根据已批准申请的信息成功生成采购订单 (PO)。当创建的 PO 记录引用了源申请 ID 时，即可判定该事件已发生。
为何重要这是申请流程的主要成功结果，标志着向采购到付款下一阶段的移交。分析从“申请已批准”到此 event 的时间，可以发现执行中的任何延迟。获取方式从 'purchase_orders' 表中创建的记录推断得出，该记录包含对原始 'requisition_headers' 或 'requisition_lines' ID 的引用。捕获使用链接到申请 ID 的 PO 记录的“created-at”timestamp。事件类型 inferred
	审批步骤已开始	一项审批任务已分配给特定审批人或审批组，申请正等待处理。当与申请关联的审批记录以“待处理”状态创建时，即可推断该事件发生。
为何重要这标志着特定审批等待时间的开始。测量此活动与相应的“审批步骤已通过/已拒绝”之间的时间间隔，有助于识别审批链中的具体瓶颈。获取方式从与申请关联的 'approvals' 表记录的创建时间戳推断得出，其中审批人的操作状态为“待处理”或等效状态。捕获使用审批链中个人待审批记录的创建 timestamp。事件类型 inferred
	审批步骤已通过	Workflow 中的某位审批人批准了该申请。这是系统记录的明确操作，带有特定时间戳和用户信息。
为何重要此活动提供对审批流程流转的细粒度洞察。聚合这些步骤有助于计算“每步审批的平均等待时间”并分析审批人的绩效。获取方式捕捉自 'approvals' 表或其审计追踪中记录的明确“批准”操作，并关联到特定的申请和审批人。捕获过滤申请审批历史中的“批准”事件。事件类型 explicit
	审批步骤已驳回	Workflow 中的某位审批人在其环节驳回了申请，通常会将其退回给申请人进行修改。这是 Coupa 记录的明确操作。
为何重要任何步骤的拒绝都会导致返工并延长周期。分析拒绝发生的地点和原因对于流程改进和用户培训至关重要。获取方式捕捉自 'approvals' 表或其审计追踪中记录的明确“驳回”操作，并关联到特定的申请和审批人。捕获过滤申请审批历史中的“驳回”事件。事件类型 explicit
	采购申请已修订	申请在提交后由申请人或其他授权用户进行编辑。Coupa 会将其明确记录为新版本或审计条目，通常会重置部分或全部审批工作流。
为何重要跟踪修订是了解流程返工和低效的关键。大量的修订可能意味着初始要求不明确或采购政策复杂，从而影响“申请修订率”KPI。获取方式这是从与“requisition_headers”表关联的审计跟踪表中捕获的，这些表记录了版本变更或具体的“编辑”操作。捕获在提交后的采购申请历史日志中查找明确的“编辑”或“更新” event。事件类型 explicit
	采购申请已寻源	获批的申请被发送到寻源 event（如 RFQ 或竞价），而不是立即转换为采购订单。当申请链接到寻源 event 对象时，即可推断出该 event。
为何重要此活动揭示了采购流程中一条重要的备选路径。它将简单采购与更复杂的战略寻源活动区分开来，从而实现更精细的周期分析。获取方式通过检测到状态变更为 'sourcing'，或识别出在 'requisition_lines' 表与寻源事件表之间创建的链接来推断。捕获检查状态是否变更为 'sourcing'，或是否创建了指向寻源事件 ID 的链接。事件类型 inferred
	采购申请已撤回	原始申请人在最终获批前取消了申请。这是一种由用户驱动的明确操作，会终止该申请的流程。
为何重要撤回可能意味着业务需求变更、重复请求或用户规避流程。跟踪撤回有助于了解需求信号的波动以及潜在的流程遵循问题。获取方式根据审计追踪中记录的明确用户操作，从 'requisition_headers' 表的状态变更为 'withdrawn'（或类似状态）推断得出。捕获识别申请状态变更为 'withdrawn'（已撤回）时的时间戳。事件类型 inferred

推荐可选

提取指南

如何从Coupa获取数据

步骤

登录 Coupa：使用具有创建和调度报表权限的用户账号访问您的 Coupa 实例。
导航至报表模块：前往“Setup”选项卡并找到“Reporting”部分。选择“Reports”打开报表达板。
创建新的自定义报表：点击“Create”按钮开始构建新报表。选择“Custom Report”作为类型。
定义报表数据源：在报表构建器中，您必须选择并关联多个数据源以收集所需信息。以 'Requisition Headers' 作为主要来源，然后添加以下关联对象：
- 'Approvals'：获取每个审批步骤的详细信息，包括审批人、状态和时间戳。
- 'Requisition Lines'：汇总总额并获取行项目详情。
- 'Purchase Order Headers'：识别申请何时转换为 PO。
- 'Users'：提取申请人和审批人的全名及部门详情。
配置报表列：将必要的字段从可用数据源拖放到报表布局中。这是最关键的一步，因为这些列将用于生成事件日志。至少应包含以下字段：
- 来自 Requisition Headers：Requisition #、Created At、Submitted At、Updated At、Status、Created by (Login ID)、Total、Sourced Externally?。
- 来自 Users（申请人）：Full Name、Department Name。
- 来自 Approvals：Created At、Updated At、Status、Approver (Login ID)。
- 来自 Purchase Order Headers：PO Number、Created At。
设置报表过滤器：应用过滤器来界定提取范围。常用且有效的过滤器是使用 'Requisition Headers - Created At' 并设置动态日期范围（例如“最近 90 天”）。如有需要，您也可以按特定公司代码进行过滤。
调度报表：导航到报表构建器中的“Schedule”选项卡。定义报表运行频率，如每日或每周。建议设定在业务低峰时段。
配置交付方式：指定交付方法。如需自动化，请选择“SFTP”并提供服务器凭据和目标目录。或者，您也可以发送到电子邮箱。选择“CSV”作为文件格式。
保存并启用：保存报表并确保调度已激活。首份报表将在下一个预定时间运行。
转换数据：生成的 CSV 是扁平文件，而非事件日志。您必须使用外部脚本（如 Python）或 ETL 工具处理此文件。脚本需要对数据进行转置，为每个活动创建独立行（例如：使用 Created At 列创建“申请已创建”行，为每个审批步骤创建一行，以及使用 PO Created At 列创建“采购订单已创建”行）。
生成最终事件日志：转换脚本应输出一个包含所需列的最终 CSV 文件：PurchaseRequisitionId、ActivityName、EventTime、SourceSystem、LastDataUpdate 以及其他建议属性。该文件现在即可上传。

配置

主要数据源：报表必须通过关联多个 Coupa 对象来构建。关键来源包括 'Requisition Headers'、'Approvals'、'Requisition Lines' 和 'Purchase Order Headers'。
日期范围筛选：应用日期过滤器以限制数据量至关重要。建议初步设定基于 'Requisition Headers - Created At' 的最近 3-6 个月的滚动窗口。
增量加载：为了进行持续分析，请将报表设置为每日运行，并提取前一天（例如“昨天”）的数据以实现增量加载。
交付配置：将交付方式配置为 SFTP 服务器，以便与您的数据管道进行稳健的自动化集成。请确保目标服务器安全且存储空间充足。
所需权限：配置报表的用户账号需要具备管理员或报表专用权限，以便创建、调度和访问所有必需的数据对象（申请、PO、审批、用户）。

a 查询示例 config

This extraction is configured within the Coupa UI and does not use a direct script. The following outlines the objects and fields required to build the report, which is then transformed into an event log.

**Data Sources (Objects to Join):**
1.  `Requisition Headers` (Primary)
2.  `Approvals` (Joined on Requisition Header ID)
3.  `Users` (Joined from `Requisition Headers` for Requester details)
4.  `Users` (Joined from `Approvals` for Approver details)
5.  `Purchase Order Headers` (Joined on Requisition Header ID)

**Report Columns Configuration (Fields to Select):**

*   **For 'Requisition Created' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Requisition #` -> Maps to `PurchaseRequisitionId`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For 'Requisition Submitted' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Submitted At` -> Maps to `EventTime`

*   **For 'Requisition Amended' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime` (Logic must be applied to identify updates after submission)

*   **For 'Approval Step Started' event:**
    *   Source Object: `Approvals`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For 'Approval Step Approved' / 'Approval Step Rejected' events:**
    *   Source Object: `Approvals`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Status` -> Used to determine `ActivityName` ('Approved' or 'Rejected')

*   **For 'Requisition Withdrawn' / 'Requisition Approved' / 'Requisition Rejected' / 'Requisition Closed' events:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Status` -> Used to determine `ActivityName`

*   **For 'Requisition Sourced' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Sourced Externally?` -> Used in logic to identify this event

*   **For 'Purchase Order Created' event:**
    *   Source Object: `Purchase Order Headers`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For General Attributes:**
    *   `Requisition Headers | Requisition #` -> `PurchaseRequisitionId`
    *   `Requisition Headers | Status` -> `RequisitionStatus`
    *   `Requisition Headers | Created By (Full Name)` -> `Requester`
    *   `Requisition Headers | Account Department` -> `Department`
    *   `Requisition Headers | Total` -> `TotalAmount`
    *   `Approvals | Approver (Full Name)` -> `Approver`

步骤

前提条件：确保已安装 Python 3 环境。在终端或命令提示符中运行 pip install pandas requests 以安装 pandas 和 requests 库。
获取 Coupa API 密钥：以管理员身份登录您的 Coupa 实例。导航至 Setup > Company Setup > API Keys。创建一个新的 API 密钥，并至少授予以下范围的读取权限：core.purchase_order.read、core.requisition.read 和 core.user.read。
配置脚本：创建一个新的 Python 文件（例如 extract_coupa_reqs.py）。将提供的 Python 脚本复制到该文件中。将 COUPA_INSTANCE_URL 替换为您公司的 Coupa URL（例如 https://yourcompany.coupahost.com），并将 API_KEY 替换为您在上一步获取的密钥。
设置提取参数：在脚本的 main 部分，调整 START_DATE 和 END_DATE 变量以定义数据提取的时间窗口。这将根据创建日期过滤申请。
执行脚本：在终端使用命令 python extract_coupa_reqs.py 运行脚本。脚本将连接到 Coupa API 抓取数据，并在控制台中显示进度更新。
处理 API 分页：脚本包含自动处理 API 分页的功能。它将以每页 50 条记录的块为单位获取数据，直到检索完指定日期范围内的所有申请。
处理申请数据：对于抓取的每个申请表头，脚本会生成“申请已创建”和“申请已提交”事件。随后，它会进行额外的 API 调用以检索关联的审批和采购订单数据。
生成活动事件：脚本处理审批记录，生成“审批步骤已开始”、“审批步骤已通过”和“审批步骤已驳回”事件。它还会检查申请的最终状态和相关数据，以生成如“申请已批准”、“采购订单已创建”和“申请已撤回”等事件。
检测修改记录：脚本会检查每项申请的 version 属性。如果版本大于 1，则表示有过修改。脚本将使用新版本的 updated-at 时间戳创建“申请已修改”事件。
汇编事件日志：所有生成的事件都会收集到一个结构化列表中。每个事件都包含 PurchaseRequisitionId、ActivityName、EventTime 等必需属性，以及 Requester 和 TotalAmount 等建议属性。
导出为 CSV：处理完所有申请后，脚本会将最终事件列表转换为 pandas DataFrame，并保存为同目录下的 coupa_requisition_event_log.csv 文件。该文件格式已针对 ProcessMind 直接上传进行了优化。

配置

API 密钥权限：用于提取的 API 密钥必须拥有对 Coupa 中 requisition_headers、requisition_lines、approvals、purchase_orders 和 users 对象的读取权限。若无这些权限，脚本将运行失败或返回不完整的数据。
日期范围：脚本根据申请创建日期 (created-at) 使用日期范围过滤器。建议按 3 到 6 个月的周期分块提取数据，以避免运行时间过长和潜在的 API 超时。请相应调整 START_DATE 和 END_DATE 变量。
状态过滤：提供的脚本会获取所有状态的采购申请。为了进行更具针对性的分析，您可以在初始 API 调用的 params 字典中添加 status 参数，以定位 approved、pending_approval 或 ordered 等特定状态。
分页限制：脚本硬编码为每次 API 调用获取 50 条记录 (limit=50)。这是与 Coupa API 配合良好的标准值。增加该值不一定能提升性能，反而可能增加复杂查询的超时风险。
性能考量：脚本会为每项采购申请进行多次 API 调用（表头、审批、PO 各一次）。提取数千条申请的数据可能耗时较长，并可能受 Coupa API 速率限制的影响。建议在业务非高峰时段运行此脚本。

a 查询示例 python

import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Coupa instance URL and API Key
COUPA_INSTANCE_URL = class="hl-string">"https://[your_instance].coupahost.com"
API_KEY = class="hl-string">"[your_api_key]"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

def get_coupa_data(endpoint, params={}):
    class="hl-string">"""Fetches paginated data from a Coupa API endpoint."""
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json",
        class="hl-string">"X-COUPA-API-KEY": API_KEY
    }
    
    all_records = []
    offset = 0
    limit = 50
    
    while True:
        paginated_params = params.copy()
        paginated_params[class="hl-string">'offset'] = offset
        paginated_params[class="hl-string">'limit'] = limit
        
        try:
            response = requests.get(fclass="hl-string">"{COUPA_INSTANCE_URL}{endpoint}", headers=headers, params=paginated_params)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an exception for 4xx/5xx errors
            data = response.json()
            
            if not data:
                break
                
            all_records.extend(data)
            offset += limit
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {endpoint}: {e}")
            break
            
    return all_records

def main(start_date, end_date):
    class="hl-string">"""Main function to extract, transform, and save the event log.""" 
    print(class="hl-string">"Starting Coupa Requisition data extraction...")
    
    event_log = []
    current_time_utc = datetime.now(timezone.utc).isoformat()

    class=class="hl-string">"hl-comment"># 1. Fetch Requisition Headers within the date range
    req_params = {
        class="hl-string">"created-at[gt]": start_date,
        class="hl-string">"created-at[lt]": end_date,
        class="hl-string">"fields": class="hl-string">'["id", "created-at", "submitted-at", "updated-at", "version", "status", "total", "requester", "currency", "sourcing-event-id"]'
    }
    requisition_headers = get_coupa_data(class="hl-string">"/api/requisition_headers", req_params)
    print(fclass="hl-string">"Found {len(requisition_headers)} requisitions to process.")

    for i, header in enumerate(requisition_headers):
        print(fclass="hl-string">"Processing requisition {i+1}/{len(requisition_headers)}: ID {header['id']}")
        
        class=class="hl-string">"hl-comment"># Common attributes for all events of this case
        case_id = str(header[class="hl-string">'id'])
        total_amount = header.get(class="hl-string">'total', {}).get(class="hl-string">'total')
        requester_name = fclass="hl-string">"{header.get('requester', {}).get('firstname', '')} {header.get('requester', {}).get('lastname', '')}".strip()
        department_name = header.get(class="hl-string">'requester', {}).get(class="hl-string">'department', {}).get(class="hl-string">'name')

        base_event = {
            class="hl-string">"PurchaseRequisitionId": case_id,
            class="hl-string">"TotalAmount": total_amount,
            class="hl-string">"Requester": requester_name,
            class="hl-string">"Department": department_name,
            class="hl-string">"Approver": None,
            class="hl-string">"SourceSystem": class="hl-string">"Coupa",
            class="hl-string">"LastDataUpdate": current_time_utc
        }

        class=class="hl-string">"hl-comment"># Activity: Requisition Created
        event_log.append({
            **base_event,
            class="hl-string">"ActivityName": class="hl-string">"Requisition Created",
            class="hl-string">"EventTime": header[class="hl-string">'created-at'],
            class="hl-string">"RequisitionStatus": class="hl-string">"draft"
        })

        class=class="hl-string">"hl-comment"># Activity: Requisition Submitted
        if header.get(class="hl-string">'submitted-at'):
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Submitted",
                class="hl-string">"EventTime": header[class="hl-string">'submitted-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval"
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Amended
        if header.get(class="hl-string">'version') and int(header[class="hl-string">'version']) > 1:
             event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Amended",
                class="hl-string">"EventTime": header[class="hl-string">'updated-at'], class=class="hl-string">"hl-comment"># Timestamp of the new version
                class="hl-string">"RequisitionStatus": header[class="hl-string">'status']
            })

        class=class="hl-string">"hl-comment"># 2. Fetch Approvals for this requisition
        approval_params = {
            class="hl-string">"approvable-id": header[class="hl-string">'id'],
            class="hl-string">"approvable-type": class="hl-string">"RequisitionHeader"
        }
        approvals = get_coupa_data(class="hl-string">"/api/approvals", approval_params)

        for approval in approvals:
            approver = approval.get(class="hl-string">'approver', {}).get(class="hl-string">'fullname')
            approval_status = approval[class="hl-string">'status']

            class=class="hl-string">"hl-comment"># Activity: Approval Step Started
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Approval Step Started",
                class="hl-string">"EventTime": approval[class="hl-string">'created-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                class="hl-string">"Approver": approver
            })

            if approval_status == class="hl-string">'approved':
                class=class="hl-string">"hl-comment"># Activity: Approval Step Approved
                event_log.append({
                    **base_event,
                    class="hl-string">"ActivityName": class="hl-string">"Approval Step Approved",
                    class="hl-string">"EventTime": approval[class="hl-string">'updated-at'],
                    class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                    class="hl-string">"Approver": approver
                })
            elif approval_status == class="hl-string">'rejected':
                class=class="hl-string">"hl-comment"># Activity: Approval Step Rejected
                event_log.append({
                    **base_event,
                    class="hl-string">"ActivityName": class="hl-string">"Approval Step Rejected",
                    class="hl-string">"EventTime": approval[class="hl-string">'updated-at'],
                    class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                    class="hl-string">"Approver": approver
                })
        
        class=class="hl-string">"hl-comment"># 3. Handle final status and related events
        final_status_event_time = header[class="hl-string">'updated-at']
        final_status = header[class="hl-string">'status']

        if final_status == class="hl-string">'approved':
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Approved",
                class="hl-string">"EventTime": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        elif final_status == class="hl-string">'rejected':
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Rejected",
                class="hl-string">"EventTime": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        elif final_status == class="hl-string">'withdrawn':
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Withdrawn",
                class="hl-string">"EventTime": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        elif final_status == class="hl-string">'closed':
             event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Closed",
                class="hl-string">"EventTime": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Sourced
        if header.get(class="hl-string">'sourcing-event-id'):
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Sourced",
                class="hl-string">"EventTime": final_status_event_time, class=class="hl-string">"hl-comment"># Assumes status update time reflects sourcing
                class="hl-string">"RequisitionStatus": final_status
            })

        class=class="hl-string">"hl-comment"># 4. Fetch Purchase Orders to detect PO Creation
        po_params = {class="hl-string">"requisition-header-id": header[class="hl-string">'id']}
        purchase_orders = get_coupa_data(class="hl-string">"/api/purchase_orders", po_params)

        for po in purchase_orders:
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Purchase Order Created",
                class="hl-string">"EventTime": po[class="hl-string">'created-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"ordered" 
            })

    class=class="hl-string">"hl-comment"># 5. Create and save the DataFrame
    if not event_log:
        print(class="hl-string">"No events were generated. The output file will be empty.")
        return

    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">"PurchaseRequisitionId", class="hl-string">"EventTime"])
    df.to_csv(class="hl-string">"coupa_requisition_event_log.csv", index=False)
    print(class="hl-string">"\nExtraction complete. Event log saved to coupa_requisition_event_log.csv")

if __name__ == class="hl-string">"__main__":
    class=class="hl-string">"hl-comment"># Define the extraction period. Format: YYYY-MM-DDTHH:MM:SSZ
    START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
    END_DATE = class="hl-string">"2023-06-30T23:59:59Z"
    main(START_DATE, END_DATE)

步骤

登录 Coupa：使用具有创建和调度报表权限的用户账号访问您的 Coupa 实例。
导航至报表模块：前往“Setup”选项卡并找到“Reporting”部分。选择“Reports”打开报表达板。
创建新的自定义报表：点击“Create”按钮开始构建新报表。选择“Custom Report”作为类型。
定义报表数据源：在报表构建器中，您必须选择并关联多个数据源以收集所需信息。以 'Requisition Headers' 作为主要来源，然后添加以下关联对象：
- 'Approvals'：获取每个审批步骤的详细信息，包括审批人、状态和时间戳。
- 'Requisition Lines'：汇总总额并获取行项目详情。
- 'Purchase Order Headers'：识别申请何时转换为 PO。
- 'Users'：提取申请人和审批人的全名及部门详情。
配置报表列：将必要的字段从可用数据源拖放到报表布局中。这是最关键的一步，因为这些列将用于生成事件日志。至少应包含以下字段：
- 来自 Requisition Headers：Requisition #、Created At、Submitted At、Updated At、Status、Created by (Login ID)、Total、Sourced Externally?。
- 来自 Users（申请人）：Full Name、Department Name。
- 来自 Approvals：Created At、Updated At、Status、Approver (Login ID)。
- 来自 Purchase Order Headers：PO Number、Created At。
设置报表过滤器：应用过滤器来界定提取范围。常用且有效的过滤器是使用 'Requisition Headers - Created At' 并设置动态日期范围（例如“最近 90 天”）。如有需要，您也可以按特定公司代码进行过滤。
调度报表：导航到报表构建器中的“Schedule”选项卡。定义报表运行频率，如每日或每周。建议设定在业务低峰时段。
配置交付方式：指定交付方法。如需自动化，请选择“SFTP”并提供服务器凭据和目标目录。或者，您也可以发送到电子邮箱。选择“CSV”作为文件格式。
保存并启用：保存报表并确保调度已激活。首份报表将在下一个预定时间运行。
转换数据：生成的 CSV 是扁平文件，而非事件日志。您必须使用外部脚本（如 Python）或 ETL 工具处理此文件。脚本需要对数据进行转置，为每个活动创建独立行（例如：使用 Created At 列创建“申请已创建”行，为每个审批步骤创建一行，以及使用 PO Created At 列创建“采购订单已创建”行）。
生成最终事件日志：转换脚本应输出一个包含所需列的最终 CSV 文件：PurchaseRequisitionId、ActivityName、EventTime、SourceSystem、LastDataUpdate 以及其他建议属性。该文件现在即可上传。

配置

主要数据源：报表必须通过关联多个 Coupa 对象来构建。关键来源包括 'Requisition Headers'、'Approvals'、'Requisition Lines' 和 'Purchase Order Headers'。
日期范围筛选：应用日期过滤器以限制数据量至关重要。建议初步设定基于 'Requisition Headers - Created At' 的最近 3-6 个月的滚动窗口。
增量加载：为了进行持续分析，请将报表设置为每日运行，并提取前一天（例如“昨天”）的数据以实现增量加载。
交付配置：将交付方式配置为 SFTP 服务器，以便与您的数据管道进行稳健的自动化集成。请确保目标服务器安全且存储空间充足。
所需权限：配置报表的用户账号需要具备管理员或报表专用权限，以便创建、调度和访问所有必需的数据对象（申请、PO、审批、用户）。

a 查询示例 config

This extraction is configured within the Coupa UI and does not use a direct script. The following outlines the objects and fields required to build the report, which is then transformed into an event log.

**Data Sources (Objects to Join):**
1.  `Requisition Headers` (Primary)
2.  `Approvals` (Joined on Requisition Header ID)
3.  `Users` (Joined from `Requisition Headers` for Requester details)
4.  `Users` (Joined from `Approvals` for Approver details)
5.  `Purchase Order Headers` (Joined on Requisition Header ID)

**Report Columns Configuration (Fields to Select):**

*   **For 'Requisition Created' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Requisition #` -> Maps to `PurchaseRequisitionId`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For 'Requisition Submitted' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Submitted At` -> Maps to `EventTime`

*   **For 'Requisition Amended' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime` (Logic must be applied to identify updates after submission)

*   **For 'Approval Step Started' event:**
    *   Source Object: `Approvals`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For 'Approval Step Approved' / 'Approval Step Rejected' events:**
    *   Source Object: `Approvals`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Status` -> Used to determine `ActivityName` ('Approved' or 'Rejected')

*   **For 'Requisition Withdrawn' / 'Requisition Approved' / 'Requisition Rejected' / 'Requisition Closed' events:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Status` -> Used to determine `ActivityName`

*   **For 'Requisition Sourced' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Sourced Externally?` -> Used in logic to identify this event

*   **For 'Purchase Order Created' event:**
    *   Source Object: `Purchase Order Headers`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For General Attributes:**
    *   `Requisition Headers | Requisition #` -> `PurchaseRequisitionId`
    *   `Requisition Headers | Status` -> `RequisitionStatus`
    *   `Requisition Headers | Created By (Full Name)` -> `Requester`
    *   `Requisition Headers | Account Department` -> `Department`
    *   `Requisition Headers | Total` -> `TotalAmount`
    *   `Approvals | Approver (Full Name)` -> `Approver`

采购到付款 (P2P) — 采购申请数据模板

采购到付款 (P2P) — 采购申请数据模板

采购到付款 - 采购申请属性

采购到付款 - 采购申请活动

提取指南

用于申请数据导出的 Coupa 调度报表

步骤

配置

a 查询示例 config

通过 Coupa REST API 进行 Python 脚本提取

步骤

配置

a 查询示例 python

使用第三方 iPaaS 连接器进行提取

步骤

配置

a 查询示例 config

准备好开始了吗？

立即优化 Coupa P2P 采购申请，缩短周期时间

采购到付款 (P2P) — 采购申请数据模板

采购到付款 (P2P) — 采购申请数据模板

采购到付款 - 采购申请属性

采购到付款 - 采购申请活动

提取指南

用于申请数据导出的 Coupa 调度报表

步骤

配置

a 查询示例 config

通过 Coupa REST API 进行 Python 脚本提取

步骤

配置

a 查询示例 python

使用第三方 iPaaS 连接器进行提取

步骤

配置

a 查询示例 config

我们重视您的隐私

准备好开始了吗？

立即优化 Coupa P2P 采购申请，缩短周期时间