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

SAP Ariba

从采购到付款 - 请购属性 (22) 从采购到付款 - 请购活动 (13) 提取指南 (2)

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

此综合数据 template 旨在帮助您高效收集并构建分析“从采购到付款 - 请购”流程所需的信息。它列出了构建稳健事件日志所必需的关键属性和活动，从而实现对流程绩效的深度洞察。此外，您还将获得从源系统中提取这些数据的实用指南，确保您的 Process Mining 之旅顺利起步。

用于全面分析的建议属性
要追踪的关键流程活动和里程碑
从您的系统中提取数据的详细指南

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

下载模板

从采购到付款 - 请购属性

这些是建议在事件日志中包含的数据字段，用于全面的“从采购到付款 - 请购”分析，确保不遗漏任何关键信息。

3 必填 8 推荐 11 可选

	名称	描述
	事件timestamp EventTimestamp	活动发生的精确日期和时间，作为事件排序的主要时间戳。
描述 Event Timestamp 记录了活动发生的准确时刻。这一高精度数据对于在每个 case 内正确排列事件顺序以及计算流程中不同步骤之间的持续时间至关重要。在分析中，此时间戳是所有基于时间的计算的基础，包括周期时间、等待时间和处理时长。它用于支持分析绩效的 dashboard，例如“请购审批周期时间”和“审批路径瓶颈分析”。该字段的准确性直接影响到所有绩效指标的可靠性。为何重要此属性提供事件的时间顺序，是所有绩效和时长计算（如周期时间和瓶颈）的基础。获取方式通常可以在 SAP Ariba 的审计追踪或事务日志表中与活动或状态变更记录一起找到。示例 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:05:00Z
	活动名称 ActivityName	请购生命周期内特定时间点发生的业务事件名称。
描述 Activity Name 描述了请购流程中的单个步骤或里程碑，例如“已创建请购单”、“审批步骤已通过”或“请购已关闭”。这些数据通常源自 SAP Ariba 中记录的事件日志、状态变更或特定的用户操作。该属性对于构建流程图至关重要，它以视觉方式呈现活动流。通过分析这些活动的顺序和频率，分析师可以识别常见的流程路径、瓶颈、与标准程序的偏差以及重工环节。它是任何 Process Mining 分析的核心支柱。为何重要它定义了流程中的各个步骤，支持申请工作流的可视化和分析，包括瓶颈和偏差分析。获取方式派生自 SAP Ariba 中的事件日志、审计追踪或状态变更记录，通常与申请抬头表和行项目表相关联。示例招聘需求已提交审批步骤已通过请购单已修改采购订单已创建
	采购请购ID PurchaseRequisitionId	采购申请单据的唯一标识符，作为该流程的主要 case 标识符。
描述 Purchase Requisition ID 是链接与单次货物或服务请求相关的所有活动的核心键值。在 SAP Ariba 中创建的每项请购都会分配一个唯一的 ID，该 ID 在其从创建、提交到最终批准、拒绝或关闭的整个生命周期中保持不变。在 Process Mining 分析中，此属性是 case 关联的基础。它能够重建每项请购的完整端到端路径，从而精确计算周期时间、识别流程变体并分析重工循环。如果没有这个标识符，将无法区分属于不同请购单的事件。为何重要这是连接所有相关活动的必不可少的 case 标识符，使分析每个唯一请求的端到端请购流程成为可能。获取方式这是 SAP Ariba 数据结构中主请购单表头表的主键字段。示例 PR-102345PR-102346PR-102347
	Event User EventUser	执行该活动的用户的 ID 或姓名，例如申请人或审批人。
描述 Event User 属性识别负责执行特定流程步骤的个人。这可能是提交请购的员工、批准申请的经理或处理申请的采购专员。该属性对于工作量分析、绩效对比和识别培训机会至关重要。它通过分析每位用户的审批时间来支持“审批人工作量与绩效”dashboard。同时，它还用于通过追溯到特定个人或团队来调查延迟或偏差的来源。为何重要支持分析工作负载分布、用户绩效和资源分配，有助于识别由特定用户或团队导致的瓶颈。获取方式请参阅 SAP Ariba 文档。这通常存储在审计追踪或历史记录表中，并与用户主数据关联。示例 john.doejane.smithmanager123
	审批工作流路径 ApprovalWorkflowPath	请购单预期遵循的预定义审批步骤顺序。
描述此属性根据金额、品类和部门等特征，定义了请购单应遵循的标准流程变体或审批矩阵。它代表了“理想”或“标准路径”流程。这是合规性检查的基础，并用于“请购合规概览”dashboard。通过将实际活动顺序与预期的“审批工作流路径”进行对比，分析师可以自动检测违反政策、未经授权的审批步骤或跳过的控制环节。这对于内部审计和风险管理至关重要。为何重要定义应遵循的标准流程，通过一致性检查自动检测偏差和违规行为。获取方式请参阅 SAP Ariba 文档。这可能派生自审批矩阵配置或申请中的特定字段。示例标准 IT > $10k市场营销服务 < 5000 美元资本支出 (CAPEX) > 10 万美元
	拒绝原因 RejectionReason	当请购单或审批步骤被拒绝时，审批人提供的理由。
描述当请购单被拒绝时，审批人通常会提供理由，可以是自由文本或从预定义列表中选择。此属性捕获了这一关键反馈。这些数据是“请购拒绝率分析”dashboard 的基石。分析最常见的拒绝原因有助于识别流程失败的根本原因，例如科目错误、理由不充分或预算问题。随后，这些洞察可用于改善对申请人的培训并提高初始提交的质量，从而减少重工。为何重要直接洞察请购失败的原因，支持根因分析以减少重工，并提高一次成功率。获取方式请参阅 SAP Ariba 文档。此信息通常记录在与驳回事件相关的备注或历史记录部分。示例总账科目错误预算超支理由不充分重复申请
	物料类别 ItemCategory	所申请货物或服务的分类，例如“IT 硬件”、“办公用品”或“专业服务”。
描述 Item Category 提供了采购内容的详细信息。这种分类有助于了解支出模式并应用特定品类的采购策略和政策。在 Process Mining 中，此属性对于“请购单修改分析”dashboard 至关重要，因为它可以突出显示某些品类的项目是否更容易发生修改，从而反映出规格不明确或价格波动等问题。它还允许跨不同采购类型比较流程绩效（如审批时间），以观察特定品类是否面临更多阻碍。为何重要支持基于所购商品或服务的类型进行分析，有助于识别特定类别的瓶颈或合规问题。获取方式请参阅 SAP Ariba 文档。此信息通常可以在申请的行项目层级找到。示例 IT硬件咨询服务办公用品营销物料
	紧急程度 UrgencyLevel	申请优先级的指标，例如“普通”、“紧急”或“特急”。
描述紧急程度（通常表现为优先级标志）传递了需要加急处理的业务需求。这通常由申请人设置，以确保关键需求得到及时处理。此属性是“紧急请购流程监控”dashboard 和“紧急请购处理时间”KPI 的核心驱动因素。它支持对紧急请购与标准请购的周期时间进行直接对比，以验证优先级处理是否有效。分析紧急请求中的偏差或延迟是确保业务连续性的关键场景。为何重要支持优先进行分析，并监控高优先级申请是否得到更快处理，确保关键业务需求得到满足。获取方式请参阅 SAP Ariba 文档。这通常是申请创建表单中的一个可选字段。示例高中低
	请求人部门 RequesterDepartment	创建采购申请的员工所属的业务部门或成本中心。
描述此属性通过识别发起请求的业务部门来提供组织背景信息。它通常源自申请人的用户配置文件或直接在请购单上指定。在分析中，这是一个用于筛选和对比的强大维度。它几乎在所有 dashboard（如“请购审批周期时间”和“请购拒绝率分析”）中被使用，按部门拆解各项指标。这有助于识别哪些部门的周期最长、修改率最高或违规请求最多，从而指导针对性的流程改进工作。为何重要支持对组织内不同部门的流程绩效进行切片和对比，突出显示特定部门的问题或最佳实践。获取方式请参阅 SAP Ariba 文档。通常可在申请抬头数据中找到，一般关联自申请人的用户个人资料。示例市场营销IT运维财务研发
	请购总金额 TotalRequisitionAmount	采购申请的总货币价值。
描述此属性获取整个请求的财务价值。它是关键的业务背景信息，有助于对请购单进行分类和设置优先级。根据该价值分析流程指标可以揭示重要的模式。例如，高价值请购单可能会遵循不同的、更严格的审批路径，或经历更长的周期。此属性对于理解流程低效带来的财务影响，以及将请购单按价值区间分类进行对比分析至关重要。为何重要提供关键的财务背景信息，以便分析请购金额如何影响流程行为（例如审批时间和 workflow 的复杂程度）。获取方式请参阅 SAP Ariba 文档。这是采购申请抬头中的标准字段。示例 1500.0025000.5099.95
	请购状态 RequisitionStatus	采购申请在其生命周期中的当前状态。
描述此属性反映了请购单的实时状态，例如“正在编写”、“已提交”、“已批准”、“被拒绝”或“已关闭”。它提供了数据提取时每个 case 在流程中所处位置的快照。虽然 Process Mining 重建了历史流，但此属性对于运营监控至关重要。它是“实时请购状态跟踪器”的主要数据点，让管理人员能够查看当前工作量，并识别停滞或超期的请购单。它为活跃的请购流水线提供了即时、可操作的可见性。为何重要支持对申请流水线进行实时监控，帮助在出现问题之前识别并处理停滞或超时的请求。获取方式请参阅 SAP Ariba 文档。这是申请抬头中的标准状态字段。示例已批准已提交已拒绝审批中
	最后数据更新 LastDataUpdate	指示此 record 数据上次从源系统刷新的 timestamp。
描述此属性显示给定事件最近一次数据提取或更新的日期和时间。它体现了所分析数据的时效性，这对于监控进行中的流程尤为重要。分析师利用这些信息来了解生成洞察的新鲜度。对于像“实时请购状态跟踪器”这样的 dashboard，此字段对于告知用户所显示信息的更新程度至关重要。它有助于管理用户对数据及时性的预期。为何重要指示数据的实时性，这对于理解流程挖掘洞察的时效性和相关性至关重要。获取方式此时间戳通常在数据摄取过程中生成并添加到每条记录中。示例 2024-05-21T02:00:00Z2024-05-22T02:00:00Z
	审批人姓名 ApproverName	被指派负责 workflow 中特定审批步骤的用户姓名。
描述此属性识别负责审批活动的特定经理或利益相关者。它与通用的 Event User 不同，因为它专门与审批任务相关。这是“审批人工作量与绩效”dashboard 的关键属性。它支持跟踪每位审批人处理的请购单数量及其平均审批时间。这有助于识别个人瓶颈、平衡工作负载并根据目标评估绩效。为何重要精准定位负责审批的具体人员，从而实现详细的工作量平衡和审批人绩效分析。获取方式请参阅 SAP Ariba 文档。此信息存储在与申请关联的审批流数据中。示例 Sarah Jones陈大卫Maria Garcia
	审批步骤耗时 ApprovalStepDuration	单个审批步骤耗费的时间，从任务分配开始到执行操作为止。
描述此计算指标衡量了更广泛审批 workflow 中各个环节的时长。它隔离出了等待特定审批人或审批级别所花费的时间。此属性对于“审批路径瓶颈分析”dashboard 和“平均审批步骤时长”KPI 至关重要。它的计算方法是“审批步骤开始”事件与相应的“审批步骤已批准”或“审批步骤被驳回”事件之间的时间差。这种细致的衡量可以精准定位导致延迟的具体审批人或步骤。为何重要提供对审批 workflow 的细致洞察，精准识别导致瓶颈的具体步骤或审批人。获取方式计算方法：“审批步骤开始”的时间戳与对应的终端事件（“已批准”或“已驳回”）时间戳之差。示例 1 天 2 小时15 minutes3天
	已修改 IsAmended	布尔标志，指示申请在首次提交后是否至少修改过一次。
描述此计算属性识别了经历过至少一次“请购单已修改”活动的 case。它简化了标记在生命周期内需要变更的请购单的过程。该标志用于计算“请购修改率”KPI。通过统计此标志为真的 case 数量，分析师可以轻松衡量重工频率，并通过将其与“申请人姓名”或“品类”等其他属性关联来调查根本原因。为何重要简化修改率 KPI 的计算，助力重工量化，并识别哪些领域需要更清晰的初始规范。获取方式如果某个案例包含一次或多次“申请已修改”活动，则计算结果为 true，否则为 false。示例 truefalse
	是否已自动化 IsAutomated	布尔标志，指示活动是由系统还是人工用户执行的。
描述此属性区分了自动化系统事件（如自动审批或系统驱动的状态变更）和用户执行的手动活动。这对于了解流程的自动化程度至关重要。在分析中，这有助于准确衡量人力投入并识别进一步自动化的机会。例如，通过筛选手动活动，可以精确计算以用户为中心的处理时间。它还有助于验证系统内的自动化规则是否按预期运行。为何重要区分人工操作和系统操作，这对于衡量自动化率和发现新的自动化机会至关重要。获取方式这通常通过检查 Event User 是否对应于系统或批处理用户 ID 来得出。示例 truefalse
	是否返工 IsRework	布尔标志，指示申请是否经历过返工，例如被驳回或多次修改。
描述此计算属性是比 'IsAmended' 更广泛的低效衡量标准。它标记了经历过重大重工循环的 case，通常定义为具有一个或多个“审批步骤被驳回”事件或多次“请购单已修改”事件。此标志用于计算“请购重工率”KPI。它有助于量化与流程失败相关的潜在成本和延迟。分析被标记为重工的 case 可以揭示与特定审批人、部门或请求类型相关的模式，这些模式往往是流程阻力的根源。为何重要识别存在明显流程摩擦（如驳回）的案例，从而能够集中分析导致低效和延误的原因。获取方式如果某个案例包含驳回活动或超过一次修改活动，则计算结果为 true。示例 truefalse
	源系统 SourceSystem	提取 data 的记录系统。
描述此属性识别流程数据的来源。在此视图中，该值始终为“SAP Ariba”，但在可能合并多个系统数据的更广泛背景下，此字段对于数据血缘和故障排除至关重要。在分析中，它有助于确认数据来源，并可用于筛选或比较跨不同系统的流程。它确保了数据源的清晰透明和可信度，这对于获得利益相关者的认可非常重要。为何重要识别数据来源，这对于数据治理、故障排查以及确保理解分析背景至关重要。获取方式这通常是在 data 提取和 transformation 过程中添加的静态值，用于标记 dataset 的来源。示例 SAP AribaSAP_ARIBA_P2PAribaCloud
	申请人姓名 RequesterName	发起采购申请的员工姓名。
描述此 case 级属性识别了采购申请的创建者。它提供了关于请求来源和个人利益相关者的背景信息。在分析中，此属性用于筛选流程并分析特定申请人的行为。例如，“请购修改分析”和“请购拒绝率分析”dashboard 利用此属性来识别那些由于修改率或拒绝率较高而可能需要额外培训的人员。这有助于提供个性化的反馈和改进计划。为何重要识别请求的创建者，支持按申请人分析流程行为和质量。获取方式请参阅 SAP Ariba 文档。这是申请抬头中的标准字段，通常标记为“创建人”或“申请人”。示例 Alice WilliamsBob MillerCharles Brown
	请购审批时间 RequisitionApprovalCycleTime	从请购单提交到获得最终批准所经历的总时长。
描述这是一个衡量核心审批流程时长的计算指标。它是反映审批 workflow 效率的关键绩效指标 (KPI)。此 KPI 直接支持“请购审批周期时间”dashboard，并作为“平均请购审批时间”KPI 的基础。其计算方式为每个 case 的“已提交请购”与“已批准请购”事件之间的时间差。分析此指标有助于识别审批链条中的整体延迟。为何重要衡量核心审批流程的效率，直接支持用于识别和减少延误的关键 KPI 和仪表板。获取方式计算方法：“申请已批准”的时间戳减去“申请已提交”的时间戳。示例 2 天 4 小时8 小时 30 分钟5天
	请购转 PO 前置时间 RequisitionToPoLeadTime	从创建请购单到生成相应采购订单的总时长。
描述这是一个衡量将业务需求转化为可执行采购订单的全端到端时长的计算指标。它提供了采购流程初始阶段效率的全面视图。此属性直接支持“请购转 PO 前置时间”KPI。其计算方式为“请购单已创建”与“采购订单已创建”事件之间的时间差。分析此指标有助于组织了解业务用户经历的总前置时间，并识别需要整体改进的领域。为何重要衡量从请求到下单的完整端到端时间，为采购周期效率提供全局性的 KPI。获取方式计算方法：“采购订单已创建”的时间戳减去“申请已创建”的时间戳。示例 7 天 3 小时10 天4 天 12 小时
	采购订单ID PurchaseOrderId	根据已批准请购单创建的采购订单 (PO) 标识符。
描述此属性将采购请购单与其下游单据采购订单 (PO) 关联起来。它的存在标志着申请已成功转化为订单。这对于延伸到请购阶段之后的端到端流程分析至关重要。通过连接请购创建事件和 PO 创建事件，它被用于计算“请购转 PO 前置时间”KPI。这提供了采购周期前端环节的整体视图。为何重要将申请与后续采购订单关联，从而能够衡量从申请到 PO 的端到端周期时间。获取方式请参阅 SAP Ariba 文档。生成 PO 后，此信息通常存储在申请行项目数据中。示例 PO-4500012345PO-4500012346PO-4500012347

必填推荐可选

从采购到付款 - 请购活动

这些是在事件日志中需要捕获的关键流程步骤和里程碑，用于准确的流程发现和瓶颈识别。

6 推荐 7 可选

	活动	描述
	已创建招聘需求	标志着用户初始创建采购申请单据。这是在申请首次以“Composing”或草稿状态保存时捕捉到的。
为何重要这是请购生命周期的起点。分析从创建到提交的时间有助于衡量用户效率并识别培训需求。获取方式取自 SAP Ariba 中采购申请对象的创建时间戳。该信息可在申请文档的抬头数据中找到，代表了明确的创建事件。捕获使用请购单据表头表中的 'CreateTime' 或同等的时间戳。事件类型 explicit
	招聘需求已提交	代表申请人正式将采购申请提交至审批 workflow。通过状态从“正在编写” (Composing) 更改为“已提交” (Submitted) 来捕获。
为何重要这是触发审批流程的关键里程碑。对于衡量“请购审批周期时间”和“请购创建前置时间”至关重要。获取方式派生自 Ariba 单据历史记录或审计日志，记录了申请状态变更为“Submitted”的事件及其时间戳。捕获识别申请状态字段首次变为“Submitted”的时间戳。事件类型 inferred
	请购已关闭	在所有相关操作（如订购和收货）完成后，采购申请的最终行政关闭。通过最终状态更改为“已关闭” (Closed) 来捕获。
为何重要代表整个请购生命周期的最终结束。分析从采购订单 (PO) 创建到关闭的时间，可以发现下游收货或开票流程中的瓶颈。获取方式派生自 Ariba 单据历史记录，记录了申请状态变更为“Closed”的事件。捕获识别申请状态字段变为“Closed”的时间戳。事件类型 inferred
	请购被拒绝	代表审核后采购申请的最终拒绝。这是流程的终点，通过状态更改为“已拒绝” (Denied) 来捕获。
为何重要这是一个关键的失败终点。分析被拒绝的请购单对于“请购拒绝率”KPI 至关重要，有助于识别模式并提高申请质量。获取方式派生自 Ariba 单据历史记录，记录了申请最终状态变更为“Denied”的事件。捕获识别申请状态字段变为“Denied”的时间戳。事件类型 inferred
	采购申请已批准	标志着采购申请在成功通过工作流所有步骤后的最终核准。这是通过状态变为“Approved”来捕捉的。
为何重要标志着审批阶段结束的关键里程碑。它是衡量“平均申请审批时间”的终点，并预示着已准备好创建采购订单 (PO)。获取方式派生自 Ariba 单据历史记录，记录了申请最终状态变更为“Approved”的事件。捕获识别申请状态字段变为“Approved”的时间戳。事件类型 inferred
	采购订单已创建	标志着已核准的采购申请成功转换为采购订单。这是通过创建引用该申请的 PO 单据来捕捉的。
为何重要这是请购流程的主要成功结果。对于衡量端到端的“请购转 PO 前置时间”KPI 至关重要。获取方式这是一个明确的事件。使用采购订单 (PO) 单据的创建时间戳，该单据包含指向源采购申请 ID 的直接链接或引用。捕获从 PO 抬头表中查找与申请关联的 PO，并使用其创建时间戳。事件类型 explicit
	审批步骤已开始	指示采购申请已路由至审批人或审批队列，正在等待操作。这是在生成并分配审批请求时捕捉到的。
为何重要提供对审批 workflow 的细致洞察。这对于计算排队时间以及在“审批路径瓶颈分析”中识别具体瓶颈步骤至关重要。获取方式来自 Ariba 审批流表，该表记录了与申请关联的各个审批任务的创建和分配情况。捕获使用与请购单和特定审批步骤关联的审批请求记录的创建时间戳。事件类型 explicit
	审批步骤已通过	代表审批步骤的正向结果，即审批人已批准其负责的请购部分。这在日志中明确记录为审批操作。
为何重要衡量每个审批人的处理时间。这些数据对于计算“平均审批步骤耗时”和评估审批人工作量至关重要。获取方式来自 Ariba 审批流表。当审批人对其分配的任务执行“批准”操作时，系统会记录时间戳。捕获使用审批历史记录中针对特定步骤的“批准” (Approve) 操作的时间戳。事件类型 explicit
	审批步骤已驳回	代表审批步骤的负面结果，即审批人拒绝了请购申请，通常会将其退回进行修改。这在日志中明确记录为“拒绝” (Deny) 操作。
为何重要突出了返工和流程延误的主要来源。分析这些事件对于理解“申请返工率”和驳回原因至关重要。获取方式来自 Ariba 审批流表。当审批人对其分配的任务执行“拒绝”或“驳回”操作时，系统会记录时间戳。捕获使用审批历史记录中针对特定步骤的“拒绝” (Deny) 操作的时间戳。事件类型 explicit
	请购单已修改	当用户在提交后修改采购申请时发生（通常是为了回应驳回或查询）。这是在单据被编辑并重新提交时捕捉到的。
为何重要跟踪重工和流程低效环节。高频率的修改通常意味着初始需求或政策不明确，这会影响“请购修改率”KPI。获取方式派生自 Ariba 中的版本数据。每次修改都会创建采购申请单据的新版本。版本号大于 1 则代表发生过修改。捕获检查在初始“已提交”状态后是否创建了新版本的申请。新版本的时间戳即为事件时间。事件类型 inferred
	请购已发送至寻源环节	当已核准的申请在创建 PO 之前被路由至寻源部门以执行寻源事件（如 RFQ）时发生。通过状态变更捕捉，例如变更为“Sourcing”。
为何重要识别高价值或非标物品流程中的重要分支。它有助于分析寻源部门对交付周期的贡献。获取方式派生自申请状态变更，指示其已发送至寻源。这在 Ariba Buying 与 Ariba Sourcing 集成的环境中很常见。捕获识别申请状态字段变为“Sourcing”或类似自定义状态的时间戳。事件类型 inferred
	请购已撤回	当原始申请人在提交的采购申请获得最终核准前将其撤回时发生。通过状态变更为“Withdrawn”或“Canceled”来捕捉。
为何重要代表由用户发起的流程终止。分析请购撤回的原因可以揭示业务需求变更或审批时间过长等问题。获取方式派生自 Ariba 单据历史记录或审计日志，记录了申请状态变更为“Withdrawn”的事件。捕获识别申请状态字段变为“Withdrawn”的时间戳。事件类型 inferred
	请购行项目已订购	代表请购单上的单个行项目在下达采购订单后状态更改为“已订购” (Ordered)。这比表头级的 PO 创建提供了更细致的跟踪。
为何重要支持在行项目层级分析部分下单或延误情况，这在仅查看抬头时是不可见的。对于包含多个行项目且由不同 PO 履行的申请非常有用。获取方式派生自申请行项目对象的状态变更。一旦为该行项目生成了 PO，其状态将更新为“Ordered”。捕获识别申请行项目的状态字段变为“Ordered”的时间戳。事件类型 inferred

推荐可选

提取指南

如何从SAP Ariba获取数据

步骤

登录 SAP Ariba：使用具有创建和运行分析报告权限的用户账号（如“报告分析师”角色）访问您的 SAP Ariba 环境。
导航至分析报告：从主仪表板进入报告区域。通常位于“报告”、“分析”或“管理”>“分析报告”菜单下。
创建新报告：开始创建新的分析报告。系统会提示您选择主要数据区域（即“事实”）。选择与申购相关的事实，例如“[Requisition]”或 Ariba 配置中的类似名称。
添加数据字段：使用报告生成器界面添加列。您需要关联多个数据源（事实）以获取所有必要信息。典型报告会以 Requisition ID 为主键，关联“[Requisition Fact]”、“[Approval History Fact]”和“[Purchase Order Fact]”。添加查询配置中列出的所有字段，包括所有相关的的时间戳，如：创建日期、提交日期、核准日期以及审批历史中的操作日期。
配置过滤器：设置过滤器以限制数据范围。最重要的过滤器是日期范围。对“请购单创建日期”应用所需时段的过滤（例如过去 3 到 6 个月）。根据需要添加其他过滤器，如特定的公司代码或 Realm。
运行并导出原始报告：执行报告。完成后，将结果导出为 CSV 或 Excel 文件。初始导出的文件为“宽表”格式，即每个申请或审批条目占一行，包含多个代表不同日期和用户操作的列。
将数据转换为事件日志格式：这是关键的线下步骤。使用 Microsoft Excel (Power Query)、Python 脚本或其他数据准备工具将宽表转换为“长表”格式。对于导出的每个时间戳列（如“创建日期”、“提交日期”），您必须在最终的事件日志中为其创建单独的行。这一过程通常被称为“逆透视 (unpivoting)”或“熔接 (melting)”。
映射活动和属性：在转换过程中，创建 ActivityName 和 EventTimestamp 列。例如，处理“提交日期”列时，对应的 ActivityName 设为 “Requisition Submitted”，而 EventTimestamp 则取该列的值。
整合并清理数据：将所有时间戳列转换后的数据整合到一个文件中。确保每行的 PurchaseRequisitionId、ActivityName 和 EventTimestamp 列均已正确填充。清理空行或格式问题。
保存为最终 CSV：将最终转换好的事件日志保存为 UTF-8 编码的 CSV 文件。现在，该文件即可上传至流程挖掘工具进行分析。

配置

报告类型：使用 Ariba 标准报告界面的分析报告 (Analytical Report)。
核心数据事实 (Facts)：您需要整合多个事实的数据，通常包括 “[Requisition Fact]”、“[Approval History Fact]” 和 “[Purchase Order Fact]”。具体名称可能因您的 Ariba 数据模型而异。
日期范围：建议根据 “采购申请创建日期” 进行过滤，选择 3-6 个月左右的可控时间段。初次测试时，建议使用一周左右的较短时间。
关键过滤器：务必设置特定的日期范围过滤。此外，建议按 “公司代码” 或 “采购组织” 进行过滤，以缩小数据集到相关业务范围，从而提高报告性能。
前提条件：运行报告的用户必须拥有访问分析报告模块以及采购申请、审批和采购订单相关底层数据事实的权限。

a 查询示例 config

REPORT CONFIGURATION for SAP Ariba Analytical Reporting

REPORT TYPE: Analytical Report

PRIMARY DATA SOURCE (FACT):
*   [Requisition Fact]

JOINED DATA SOURCES (FACTS):
*   [Approval History Fact] on Requisition ID
*   [Purchase Order Fact] on Requisition ID
*   [Requisition Line Item Fact] on Requisition ID

REPORT FIELDS (COLUMNS TO EXPORT for subsequent transformation):

// Case and General Attributes
*   Requisition.Requisition ID (as PurchaseRequisitionId)
*   Requisition.Status (as RequisitionStatus)
*   Requisition.Requester.Department (as RequesterDepartment)
*   Requisition.Total Cost.Amount (as TotalRequisitionAmount)
*   Requisition.Line Items.Category (as ItemCategory)
*   Requisition.Is Urgent (as UrgencyLevel)
*   Requisition.Approval Flow Name (as ApprovalWorkflowPath)

// Fields for 'Requisition Created'
*   Requisition.Created Date (Timestamp)
*   Requisition.Requester.User ID (User)

// Fields for 'Requisition Submitted'
*   Requisition.Submitted Date (Timestamp)
*   Requisition.Submitter.User ID (User)

// Fields for 'Requisition Amended'
*   Requisition.Last Modified Date (Timestamp) - Note: Requires logic to isolate true amendment events
*   Requisition.Last Modified By.User ID (User)

// Fields for 'Approval Step' activities
*   Approval History.Approval Request Date (Timestamp for 'Approval Step Started')
*   Approval History.Action Date (Timestamp for 'Approval Step Approved'/'Approval Step Rejected')
*   Approval History.Action (Value: 'Approve'/'Deny')
*   Approval History.Approver.User ID (User)
*   Approval History.Comments (for RejectionReason)

// Fields for final status activities
*   Requisition.Approved Date (Timestamp for 'Requisition Approved')
*   Requisition.Denied Date (Timestamp for 'Requisition Denied')
*   Requisition.Withdrawn Date (Timestamp for 'Requisition Withdrawn')
*   Requisition.Closed Date (Timestamp for 'Requisition Closed')

// Fields for downstream activities
*   Requisition.Sourcing Status Date (Timestamp for 'Requisition Sent To Sourcing')
*   Purchase Order.Created Date (Timestamp for 'Purchase Order Created')
*   Purchase Order.Creator.User ID (User for 'Purchase Order Created')
*   Requisition Line Item.Ordered Date (Timestamp for 'Requisition Line Item Ordered')

FILTERS:
*   Requisition.Created Date BETWEEN [Start Date] AND [End Date]
*   Company Code IN ([Your Company Codes])

步骤

设置 Python 环境：确保已安装 Python 3.6 或更高版本。使用 pip 安装必要的库：pip install requests pandas。
配置 API 访问：在 SAP Ariba Developer Portal 中注册一个新应用程序。订阅 “Operational Reporting API for Requisitions” 并获取您的 OAuth 凭据：Application Key (API Key)、OAuth Client Secret，以及 [your_api_key]:[your_client_secret] 的 Base64 编码字符串。
自定义 Python 脚本：打开提供的 Python 脚本。填写顶部的占位符变量，包括 ARIBА_REALM、BASE_URL、API_KEY 和 BASE64_CREDS。同时，设置数据提取的 START_DATE（开始日期）和 END_DATE（结束日期）。
定义报告负载：检查脚本中的 report_payload JSON 对象。这定义了要执行的报告。脚本预配置为使用 RequisitionFactSystemView 并选择与所需活动和属性相关的字段。您可以根据需要添加更多字段或过滤器。
执行脚本：在终端中使用 python your_script_name.py 运行脚本。脚本首先会向 Ariba 进行身份验证以获取访问令牌。
提交并监控报告作业：脚本会自动向 Ariba API 提交报告请求。由于作业是异步运行的，脚本将每隔 60 秒轮询一次 Ariba API 以检查作业状态。
下载报告数据：一旦 Ariba API 返回作业状态为 “COMPLETED”，脚本将下载结果数据（通常是包含单个 CSV 文件的 ZIP 压缩包）。
处理并转换数据：脚本解压文件并将原始数据加载到 pandas DataFrame 中。随后执行关键的转换步骤，将数据从宽表格式（每个申请一行，带多个日期列）转换为长表事件日志格式（每个申请多行，每个活动占一行）。
生成事件日志：转换后的 DataFrame 现在结构完整，包含 PurchaseRequisitionId、ActivityName 和 EventTimestamp 等列，并保存为同目录下的 ariba_requisition_event_log.csv。
准备上传：生成的 CSV 文件已准备好上传至 ProcessMind。请确保列标题与您 ProcessMind 项目中配置的映射相匹配。

配置

API 端点 URL：脚本需要您 Ariba 实例 API 的基础 URL，格式通常为 https://[your-realm].api.ariba.com/api/operationalreporting/v2/。请将 [your-realm] 替换为您公司特定的 Ariba Realm 名称。
身份认证：提取过程使用 OAuth 2.0 进行认证。您必须提供有效的 apiKey、clientSecret 以及从 Ariba Developer Portal 注册的应用程序中获取的 base64EncodedCredentials 字符串。
视图模板：脚本配置为使用 RequisitionFactSystemView。这是 Ariba 的标准视图，但您必须确保您的环境中已启用该视图，且您的 API 用户拥有访问权限。
日期范围过滤：报告负载中的 creationDate 过滤器对于控制数据量至关重要。对于初始提取，建议选择 3 到 6 个月的时间段。对于大型组织，可以考虑按月分批提取数据。
增量加载：对于后续提取，请调整 START_DATE 和 END_DATE 以仅获取新增或更新的记录。脚本不会自动管理增量逻辑，因此每次运行需手动设置日期范围。
前提条件：您必须拥有具有 “Developer Portal Access” 权限的 SAP Ariba 用户，以便创建应用程序和凭据。API 应用程序本身需要 “Operational Reporting API User” 角色才能执行报告任务。

a 查询示例 python

import requests
import json
import pandas as pd
import time
import zipfile
import io

class=class="hl-string">"hl-comment"># --- Configuration --- 
class=class="hl-string">"hl-comment"># Replace with your SAP Ariba realm, datacenter-specific URL, and credentials
ARIBA_REALM = class="hl-string">"[Your Ariba Realm]"
BASE_URL = fclass="hl-string">"https://{ARIBA_REALM}.api.ariba.com/api/operationalreporting/v2/"
TOKEN_URL = class="hl-string">"https://api.ariba.com/v2/oauth/token"
API_KEY = class="hl-string">"[Your Application Key]"
BASE64_CREDS = class="hl-string">"[Your Base64-encoded ClientID:ClientSecret]"

class=class="hl-string">"hl-comment"># --- Report Parameters ---
class=class="hl-string">"hl-comment"># Set the date range for the extraction
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-06-30T23:59:59Z"

class=class="hl-string">"hl-comment"># The main function to orchestrate the extraction process
def main():
    print(class="hl-string">"1. Acquiring access token...")
    access_token = get_access_token()
    if not access_token:
        return

    print(class="hl-string">"2. Creating asynchronous report job...")
    job_id = create_report_job(access_token)
    if not job_id:
        return

    print(fclass="hl-string">"Job created with ID: {job_id}. Polling for completion...")
    status = poll_job_status(access_token, job_id)

    if status == class="hl-string">'COMPLETED':
        print(class="hl-string">"3. Job completed. Downloading report data...")
        raw_data = download_report(access_token, job_id)
        if raw_data:
            print(class="hl-string">"4. Processing raw data into event log...")
            event_log = process_data(raw_data)
            output_filename = class="hl-string">'ariba_requisition_event_log.csv'
            event_log.to_csv(output_filename, index=False)
            print(fclass="hl-string">"5. Success! Event log saved to {output_filename}")
    else:
        print(fclass="hl-string">"Job failed or timed out with status: {status}")

def get_access_token():
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Basic {BASE64_CREDS}',
        class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded',
    }
    data = {class="hl-string">'grant_type': class="hl-string">'client_credentials'}
    try:
        response = requests.post(TOKEN_URL, headers=headers, data=data)
        response.raise_for_status()
        return response.json().get(class="hl-string">'access_token')
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error getting access token: {e}")
        return None

def create_report_job(token):
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}',
        class="hl-string">'apiKey': API_KEY,
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    report_payload = {
        class="hl-string">"name": class="hl-string">"ProcessMind Requisition Extraction",
        class="hl-string">"viewTemplateName": class="hl-string">"RequisitionFactSystemView",
        class="hl-string">"outputFormat": class="hl-string">"CSV",
        class="hl-string">"filters": {
            class="hl-string">"creationDate": {
                class="hl-string">"from": START_DATE,
                class="hl-string">"to": END_DATE
            }
        },
        class="hl-string">"select": [
            class="hl-string">"RequisitionId", class="hl-string">"StatusString", class="hl-string">"SubmitDate", class="hl-string">"ApprovedState.TimeUpdated",
            class="hl-string">"DeniedState.TimeUpdated", class="hl-string">"SourcingState.TimeUpdated", class="hl-string">"ClosedState.TimeUpdated",
            class="hl-string">"WithdrawnState.TimeUpdated", class="hl-string">"Requester.Name", class="hl-string">"Requester.Department",
            class="hl-string">"TotalCost.Amount", class="hl-string">"LineItems.Category.Name", class="hl-string">"IsUrgent", class="hl-string">"ApprovalFlow.Name",
            class="hl-string">"RequisitionVersion", class="hl-string">"TimeCreated", class="hl-string">"LineItems.OrderedState.TimeUpdated", class="hl-string">"POInfo.POId"
        ]
    }
    try:
        response = requests.post(fclass="hl-string">"{BASE_URL}jobs", headers=headers, json=report_payload)
        response.raise_for_status()
        return response.json().get(class="hl-string">'jobId')
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error creating report job: {e}")
        return None

def poll_job_status(token, job_id):
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}', class="hl-string">'apiKey': API_KEY}
    while True:
        try:
            response = requests.get(fclass="hl-string">"{BASE_URL}jobs('{job_id}')", headers=headers)
            response.raise_for_status()
            status = response.json().get(class="hl-string">'status')
            print(fclass="hl-string">"Current job status: {status}")
            if status in [class="hl-string">'COMPLETED', class="hl-string">'FAILED', class="hl-string">'CANCELLED']:
                return status
            time.sleep(60) class=class="hl-string">"hl-comment"># Wait 60 seconds before polling again
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error polling job status: {e}")
            return class="hl-string">'FAILED'

def download_report(token, job_id):
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}', class="hl-string">'apiKey': API_KEY}
    try:
        response = requests.get(fclass="hl-string">"{BASE_URL}jobs('{job_id}')/result", headers=headers, stream=True)
        response.raise_for_status()
        return response.content
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error downloading report: {e}")
        return None

def process_data(zip_content):
    try:
        with zipfile.ZipFile(io.BytesIO(zip_content)) as z:
            class=class="hl-string">"hl-comment"># Assuming the first file in the zip is the CSV we need
            csv_filename = z.namelist()[0]
            with z.open(csv_filename) as f:
                df = pd.read_csv(f)
    except Exception as e:
        print(fclass="hl-string">"Error reading zipped CSV: {e}")
        return pd.DataFrame()

    class=class="hl-string">"hl-comment"># Rename columns for clarity
    df.rename(columns={
        class="hl-string">'RequisitionId': class="hl-string">'PurchaseRequisitionId',
        class="hl-string">'TimeCreated': class="hl-string">'Timestamp_Created',
        class="hl-string">'SubmitDate': class="hl-string">'Timestamp_Submitted',
        class="hl-string">'ApprovedState.TimeUpdated': class="hl-string">'Timestamp_Approved',
        class="hl-string">'DeniedState.TimeUpdated': class="hl-string">'Timestamp_Denied',
        class="hl-string">'SourcingState.TimeUpdated': class="hl-string">'Timestamp_SentToSourcing',
        class="hl-string">'ClosedState.TimeUpdated': class="hl-string">'Timestamp_Closed',
        class="hl-string">'WithdrawnState.TimeUpdated': class="hl-string">'Timestamp_Withdrawn',
        class="hl-string">'LineItems.OrderedState.TimeUpdated': class="hl-string">'Timestamp_LineItemOrdered',
        class="hl-string">'POInfo.POId': class="hl-string">'POId',
        class="hl-string">'Requester.Name': class="hl-string">'EventUser',
        class="hl-string">'Requester.Department': class="hl-string">'RequesterDepartment',
        class="hl-string">'TotalCost.Amount': class="hl-string">'TotalRequisitionAmount',
        class="hl-string">'LineItems.Category.Name': class="hl-string">'ItemCategory',
        class="hl-string">'IsUrgent': class="hl-string">'UrgencyLevel',
        class="hl-string">'ApprovalFlow.Name': class="hl-string">'ApprovalWorkflowPath',
        class="hl-string">'StatusString': class="hl-string">'RequisitionStatus'
    }, inplace=True)
    
    class=class="hl-string">"hl-comment"># Create a base dataframe for melting
    id_vars = [
        class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventUser', class="hl-string">'RequesterDepartment', class="hl-string">'TotalRequisitionAmount',
        class="hl-string">'ItemCategory', class="hl-string">'UrgencyLevel', class="hl-string">'ApprovalWorkflowPath', class="hl-string">'RequisitionStatus', class="hl-string">'RequisitionVersion', class="hl-string">'POId'
    ]
    
    timestamp_cols = [col for col in df.columns if col.startswith(class="hl-string">'Timestamp_')]
    
    class=class="hl-string">"hl-comment"># Melt the dataframe to turn timestamp columns into rows
    event_log = pd.melt(df, id_vars=id_vars, value_vars=timestamp_cols, var_name=class="hl-string">'ActivityName', value_name=class="hl-string">'EventTimestamp')
    
    class=class="hl-string">"hl-comment"># Clean up and format
    event_log.dropna(subset=[class="hl-string">'EventTimestamp'], inplace=True)
    event_log[class="hl-string">'ActivityName'] = event_log[class="hl-string">'ActivityName'].str.replace(class="hl-string">'Timestamp_', class="hl-string">'Requisition ')
    event_log[class="hl-string">'EventTimestamp'] = pd.to_datetime(event_log[class="hl-string">'EventTimestamp'])

    class=class="hl-string">"hl-comment"># --- Handle specific/derived activities ---
    class=class="hl-string">"hl-comment"># Requisition Amended
    amended_df = df[df[class="hl-string">'RequisitionVersion'] > 1].copy()
    if not amended_df.empty:
        amended_df[class="hl-string">'ActivityName'] = class="hl-string">'Requisition Amended'
        amended_df[class="hl-string">'EventTimestamp'] = pd.to_datetime(amended_df[class="hl-string">'Timestamp_Submitted'])
        event_log = pd.concat([event_log, amended_df[event_log.columns]], ignore_index=True)

    class=class="hl-string">"hl-comment"># Purchase Order Created (use the timestamp of the first line item ordered as a proxy)
    po_created_df = df[df[class="hl-string">'POId'].notna() & df[class="hl-string">'Timestamp_LineItemOrdered'].notna()].copy()
    if not po_created_df.empty:
        po_created_df[class="hl-string">'ActivityName'] = class="hl-string">'Purchase Order Created'
        po_created_df[class="hl-string">'EventTimestamp'] = pd.to_datetime(po_created_df[class="hl-string">'Timestamp_LineItemOrdered'])
        event_log = pd.concat([event_log, po_created_df[event_log.columns]], ignore_index=True)
    
    class=class="hl-string">"hl-comment"># Placeholder for Approval Steps - requires parsing ApprovalRecords not included in this basic script
    class=class="hl-string">"hl-comment"># For now, we only have the final class="hl-string">'Approved' status. This logic can be expanded.
    class=class="hl-string">"hl-comment"># Creating dummy class="hl-string">'Approval Step Started/Approved' for demonstration.
    approval_df = df[df[class="hl-string">'Timestamp_Approved'].notna()].copy()
    if not approval_df.empty:
        approval_started = approval_df.copy()
        approval_started[class="hl-string">'ActivityName'] = class="hl-string">'Approval Step Started'
        class=class="hl-string">"hl-comment"># Approximate start time as submit time
        approval_started[class="hl-string">'EventTimestamp'] = pd.to_datetime(approval_started[class="hl-string">'Timestamp_Submitted'])
        
        approval_approved = approval_df.copy()
        approval_approved[class="hl-string">'ActivityName'] = class="hl-string">'Approval Step Approved'
        approval_approved[class="hl-string">'EventTimestamp'] = pd.to_datetime(approval_approved[class="hl-string">'Timestamp_Approved'])
        approval_approved[class="hl-string">'RejectionReason'] = None class=class="hl-string">"hl-comment"># Add column for consistency
        
        event_log = pd.concat([event_log, approval_started[event_log.columns], approval_approved[event_log.columns.tolist() + [class="hl-string">'RejectionReason']]], ignore_index=True)

    class=class="hl-string">"hl-comment"># Add placeholder for RejectionReason, as it's not directly in this view
    if class="hl-string">'RejectionReason' not in event_log.columns:
        event_log[class="hl-string">'RejectionReason'] = None

    class=class="hl-string">"hl-comment"># Final sorting and cleanup
    event_log = event_log.sort_values(by=[class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventTimestamp']).reset_index(drop=True)
    
    class=class="hl-string">"hl-comment"># Rename class="hl-string">'Requisition LineItemOrdered' to class="hl-string">'Requisition Line Item Ordered'
    event_log[class="hl-string">'ActivityName'] = event_log[class="hl-string">'ActivityName'].replace({class="hl-string">'Requisition LineItemOrdered': class="hl-string">'Requisition Line Item Ordered'})

    class=class="hl-string">"hl-comment"># Final column selection
    final_columns = [
        class="hl-string">'PurchaseRequisitionId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventUser',
        class="hl-string">'RequesterDepartment', class="hl-string">'TotalRequisitionAmount', class="hl-string">'ItemCategory', class="hl-string">'UrgencyLevel',
        class="hl-string">'ApprovalWorkflowPath', class="hl-string">'RejectionReason', class="hl-string">'RequisitionStatus'
    ]
    event_log = event_log[final_columns]

    return event_log

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

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

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

从采购到付款 - 请购属性

从采购到付款 - 请购活动

提取指南

SAP Ariba 分析报表 CSV/Excel 导出

步骤

配置

a 查询示例 config

通过 Operational Reporting API 进行 Python 脚本提取

步骤

配置

a 查询示例 python

准备好开始了吗？

拒绝延迟：优化您的从采购到付款请购流程

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

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

从采购到付款 - 请购属性

从采购到付款 - 请购活动

提取指南

SAP Ariba 分析报表 CSV/Excel 导出

步骤

配置

a 查询示例 config

通过 Operational Reporting API 进行 Python 脚本提取

步骤

配置

a 查询示例 python

我们重视您的隐私

准备好开始了吗？

拒绝延迟：优化您的从采购到付款请购流程