采购到付款 (P2P) — 采购申请数据模板
采购到付款 (P2P) — 采购申请数据模板
- 为深入分析建议收集的属性
- 用于流程发现的关键跟踪活动
- SAP S/4HANA 数据提取指南
从采购到付款 - 采购申请属性
| 名称 | 描述 | ||
|---|---|---|---|
| Event 时间 EventTime | 特定 Activity 发生的精确日期和时间。 | ||
| 描述 事件时间 (Event Time) 是记录活动发生的时间戳。该数据对于按时间顺序排列 Case 内的事件至关重要，也是流程挖掘中所有时长和绩效计算的基础。例如，“申请已提交”和“申请已批准”事件之间的时间差决定了审批周期。 准确的时间戳对于分析流程表现、识别延误以及监控对服务水平协议 (SLA) 的遵守情况必不可少。该属性支持仪表板可视化周期时间、追踪停滞的申请，并对比不同时段的表现。 为何重要 此时间戳对于排列事件顺序、计算周期时间以及分析流程绩效和瓶颈至关重要。 获取方式 时间戳通常提取自更改文档抬头（CDHDR-UDATE, CDHDR-UTIME）或工作流事件日志。 示例 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| 活动名称 ActivityName | 在采购申请流程特定时点发生的业务活动名称。 | ||
| 描述 Activity Name 描述了采购申请生命周期中发生的特定事件或任务。这些活动提取自系统日志（如更改文档和工作流历史记录），代表了流程中的关键里程碑，例如“创建申请”、“开始审批步骤”或“创建采购订单”。 通过分析这些活动，您可以实现流程流的可视化、识别瓶颈并衡量各个阶段所花费的时间。了解“修改申请”或“驳回申请”等活动的顺序和频率，对于识别流程低效环节和改进点至关重要。 为何重要 它定义了流程中的各个步骤，构成了流程图的骨干，并支持对流程流转、变体和瓶颈的分析。 获取方式 这是一个派生属性，通常通过解析更改文档表（CDHDR、CDPOS）和工作流日志（如 SWWLOGHIST）中的数据构建而成。 示例 已创建招聘需求审批步骤已完成采购申请已批准采购订单已创建 | |||
| 采购请购ID PurchaseRequisitionId | 采购申请单据的唯一标识符。 | ||
| 描述 Purchase Requisition ID（采购申请 ID）是在 SAP S/4HANA 中唯一标识每项货物或服务请求的主键。它作为核心 Case 标识符，将特定申请从创建到最终状态（如批准、驳回或转为采购订单）的所有相关活动和变更关联起来。 在流程挖掘中，此属性是重建每项申请端到端生命周期的基础。通过将所有相关事件归组在同一个采购申请 ID 下，分析师可以准确衡量周期时间、追踪状态变更，并分析申请在审批流程中可能经历的各种路径。 为何重要 这是核心的 Case 标识符，它将所有相关的流程步骤连接起来，从而实现对采购申请生命周期的完整且连贯的洞察。 获取方式 此属性即采购申请编号，位于表 EBAN 的字段 BANFN 中。 示例 100178901001789110017892 | |||
| 审批人 ID ApproverId | 执行审批或驳回步骤的用户标识符。 | ||
| 描述 Approver ID 专门用于识别完成审批或驳回活动的用户。它与通用的 User ID 不同，因为它仅关注审批工作流中的决策者。捕获此信息对于详细分析审批流程至关重要。 该属性支持审批行为分析，例如识别审批时间过长的经理或频繁驳回申请的人员。它是“审批步骤周期时间”和“工作流瓶颈分析”仪表板的基础数据，有助于精准定位可能导致延迟的特定个人或角色。 为何重要 定位审批步骤中的具体决策者，支持按个人或角色深入分析审批周期和瓶颈。 获取方式 此信息通常从 SAP 业务工作流表（如 SWW_WI2OBJ 和 SWWLOGHIST）中提取，这些表将工作项与完成用户关联起来。 示例 MJOHNSONCWILLIAMSLBLACK | |||
| 用户ID UserId | 创建采购申请或执行特定活动的用户标识符。 | ||
| 描述 User ID 识别了负责采购申请生命周期中特定事件的员工或系统用户。这可以是创建申请的人员、批准申请的经理，或者是修改申请的经办人。在自动化步骤中，这可能是系统或批处理用户 ID。 通过 User ID 进行分析有助于理解用户行为特点、工作量分布和绩效表现。它是识别培训需求、表彰优秀个人以及确保流程内问责制的关键。结合用户主数据，它还能支持部门绩效分析。 为何重要 支持分析用户绩效、工作量分布和流程合规性。这对于识别培训需求和资源瓶颈至关重要。 获取方式 创建者可在 EBAN-ERNAM 中找到。后续变更记录在 CDHDR-USERNAME 中。审批信息可在工作流日志中找到。 示例 JSMITHRROEWF-BATCH | |||
| 申请单类型 RequisitionType | 对采购申请进行分类的代码，例如：标准物料、服务或资本支出。 | ||
| 描述 Requisition Type（在 SAP 中称为单据类型）是一个关键配置字段，用于对采购申请进行分类。不同类型可能会触发不同的审批流、具有不同的字段设置，并用于不同的业务目的（如标准库存物料、外部服务或资产采购）。 通过基于申请类型进行分析，企业可以了解各类请求的处理方式。这支持对不同类别的绩效、周期时间和审批路径进行对比，从而揭示某些类型的申请是否存在效率差异，并协助制定针对性的流程改进方案。 为何重要 对申请进行分类以便开展对比分析，帮助了解不同类型的请求是否具有不同的流程、瓶颈或周期。 获取方式 这是单据类型字段，位于表 EBAN 的字段 BSART 中。 示例 NBFORV | |||
| 部门 Department | 承担该采购申请费用的部门或成本中心。 | ||
| 描述 Department 属性（在 SAP 中通常由成本中心表示）用于识别负责该采购请求的业务部门。它是分配在采购申请行项目级别的关键财务和组织信息。 在流程挖掘中，此属性对于部门绩效分析必不可少。它支持通过仪表板对比不同部门之间的周期时间、修改率和驳回率等关键指标。这有助于发现表现优异的部门（其经验可供推广），以及可能需要额外培训或流程支持的部门。 为何重要 支持跨业务单元的绩效对比，突出周期或驳回率的差异，从而识别最佳实践和待改进领域。 获取方式 这是成本中心，通常可以在账户分配表 EBKN 的字段 KOSTL 中找到。 示例 FIN-1001IT-2005MKT-3010 | |||
| 采购申请状态 RequisitionStatus | 采购申请当前的系统处理或审批状态。 | ||
| 描述 Requisition Status（采购申请状态）表示申请在其生命周期中所处的阶段。在 SAP 中，这通常由下达指示符表示，显示申请是处于冻结、审批中、部分批准还是已获完全批准状态。该状态会随着申请在工作流中的推进而改变。 追踪状态随时间的变化是理解流程流的基础。它有助于识别申请卡在哪里以及卡了多久。通过分析状态间的流转，可以获得审批流程及其变体形式的详细视图。 为何重要 指示申请的当前状态，这对于追踪进度、识别瓶颈和分析流程至关重要。 获取方式 下达状态通常由“下达指示符”（Release Indicator）决定，位于表 EBAN 的字段 FRGZU 中。 示例 B1S | |||
| 采购申请金额 RequisitionAmount | 采购申请的总金额。 | ||
| 描述 Requisition Amount（采购申请金额）代表所请求货物或服务的预计总成本。该数值通常是决定审批流复杂程度和时长的关键因素，高金额申请通常需要更多层级的审批。 分析此属性支持基于金额的流程细分。它有助于解答诸如“高价值申请是否需要更长的审批时间？”或“经常被驳回的申请金额是多少？”等问题。它是理解流程低效所带来的财务影响的关键维度。 为何重要 有助于按财务影响对流程进行细分，这通常与审批复杂度和周期正相关。对于基于价值的流程分析至关重要。 获取方式 总金额可在表 EBAN 的字段 GFWERT 中找到。行项目级别的金额位于 EBAN-PREIS 中。 示例 1500.0075000.50250.75 | |||
| 最后数据更新 LastDataUpdate | 指示此 record 数据上次从源系统刷新的 timestamp。 | ||
| 描述 此属性记录了从源系统进行最新数据提取或更新的日期和时间。它是理解所分析数据时效性的关键元数据。分析师和业务用户依靠此时间戳来判断流程数据是否反映了最新的运营状态。 在任何流程分析中，了解数据的时效性是做出明智决策的基础。此属性有助于管理用户预期，并确保基于足够新的数据得出结论，以满足特定的分析需求。 为何重要 指示数据的实时性，这对于信任分析结果并做出及时的业务决策至关重要。 获取方式 此时间戳在数据提取、转换与加载（ETL）过程中生成并添加。 示例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| 处理时间 ProcessingTime | 在特定活动上花费的时间时长。 | ||
| 描述 “处理时间 (Processing Time)”衡量完成单项活动所需的时间。它的计算方法是事件结束时间与开始时间之差。在 SAP 中，对于许多事件，开始和结束时间是相同的，因此处理时间为零。然而，对于审批步骤，它可以代表审批人处理该任务所花费的时间。 这一计算指标有助于了解不同流程步骤所涉及的工作量。它可以帮助区分 Case 的等待时间 (Wait Time) 和实际工作时间 (Processing Time)，从而提供更细致的流程表现视图。 为何重要 衡量活动的实际工作时间，有助于区分工作时间与等待时间，这是资源分析的关键。 获取方式 这是一个计算属性，通常通过事件日志中每个事件的“结束时间”减去“开始时间”得出。 示例 PT15MPT2H30MP1D | |||
| 审批步骤名称 ApprovalStepName | 工作流中审批步骤的具体名称或描述。 | ||
| 描述 Approval Step Name 提供了审批工作流中特定阶段的易读描述，例如“经理审批”或“财务副总裁审批”，这比通用的“审批步骤已完成”更具参考价值。 此属性对于“审批步骤周期时间”和“工作流瓶颈分析”仪表板至关重要。它支持以细颗粒度视角观察审批流程，从而精确指出哪些审批阶段导致了严重的延迟以及工作在何处堆积。这种深度的细节对于通过针对性干预来精简审批链是必不可少的。 为何重要 提供审批阶段的细粒度细节，支持精确识别多级审批工作流中的瓶颈。 获取方式 此信息源自工作流任务描述，可以通过将工作流日志链接到任务定义表（如 T528T）来获取。 示例 经理审批总监审批财务副总裁审批 | |||
| 拒绝原因 RejectionReason | 采购申请被驳回时提供的理由。 | ||
| 描述 Rejection Reason 解释了审批人为何驳回某项采购申请。原因可能包括超出预算、信息有误、违反政策或重复申请。这些信息为理解流程失败提供了关键背景。 分析驳回原因有助于识别流程低效和返工的根源。例如，如果“成本中心错误”是一个普遍原因，则表明需要加强用户培训或系统校验。此属性是“采购申请驳回分析”仪表板的核心，对于实施有针对性的流程改进至关重要。 为何重要 提供流程失败的根本原因，支持进行针对性改进，以减少返工并提升申请的一次通过率。 获取方式 这通常不是标准字段。它可能被记录在工作流容器元素、与申请关联的长文本或自定义字段中。 示例 超出预算供应商错误重复请求 | |||
| 是否已自动化 IsAutomated | 指示活动是由系统用户而非人工执行的标记。 | ||
| 描述 Is Automated 属性是一个布尔值标记。如果活动是由系统或批处理用户执行的（例如工作流动作中的“WF-BATCH”），则该值为 true。这有助于区分流程中的人工步骤和自动化步骤。 该属性对于衡量采购申请流程的自动化程度以及计算“自动审批率”KPI 至关重要。通过筛选自动化或人工步骤，分析师可以对比两者的效率，并寻找进一步自动化的机会，以减少处理时间并节省人力。 为何重要 区分人工活动和系统驱动活动，这是衡量自动化率及识别手动任务自动化机会的关键。 获取方式 这是一个派生属性，通常基于一条规则：检查事件的 User ID 是否属于已知系统或批处理用户列表。 示例 truefalse | |||
| 是否返工 IsRework | 指示活动是否构成返工的标记，例如提交后的修改。 | ||
| 描述 “是否返工 (Is Rework)”是一个计算得出的布尔标记，用于识别代表非增值或重复工作的活动。在此流程中，一个典型的例子是在申请已提交审批后又发生了“申请已修改”活动，迫使审批流程重新开始。 该属性对于量化流程中的返工量及其对整体周期的影响至关重要。“申请修改与返工率”仪表板依靠此标记来突出流程效率低下的环节。减少返工通常是流程改进计划的首要目标，因为它能直接转化为时间和精力的节省。 为何重要 标记代表无效劳动或重复劳动的活动，支持直接衡量返工及其对流程效率的影响。 获取方式 这是一个计算属性。逻辑上通常将发生在首次“提交审批”之后的任何“修改申请”活动标记为返工。 示例 truefalse | |||
| 源系统 SourceSystem | 识别提取数据所属的特定 SAP S/4HANA 实例。 | ||
| 描述 Source System（源系统）属性指明了生成流程数据的原始系统。对于拥有多个 SAP 实例（如独立的开发、测试和生产系统，或分属不同地区的系统）的企业，该字段对于数据治理和背景识别至关重要。 它确保了来自不同源头的数据可以被准确区分，防止错误的数据聚合，并支持针对特定系统的分析。这是维护数据血缘和确保流程数据可追溯性的必备属性。 为何重要 为数据来源和治理提供必要的上下文，特别是在多系统环境中，确保数据可追溯。 获取方式 这通常是 SAP 系统 ID (SID)，可以从系统变量或配置表中检索。 示例 S4PECCS4H_PROD_01 | |||
| 紧急程度 UrgencyLevel | 对采购申请紧急程度的分类，可能会影响其处理优先级。 | ||
| 描述 Urgency Level（紧急程度）表示采购请求的优先级。虽然这不是一个标准专用字段，但部分企业使用“需求跟踪号”等字段来捕获此信息，这使得申请人能够标记需要加急处理的关键需求。 分析紧急程度的影响对于评估流程是否有效地优先处理关键请求非常重要。“紧急程度影响分析”仪表板利用此属性对比紧急申请与标准申请的周期时间和审批率，从而判断优先级处理机制是否按预期运作。 为何重要 支持分析高优先级请求的流程表现差异，有助于验证紧急事项是否得到了真正的加急处理。 获取方式 不存在标准紧急程度字段。部分公司使用需求跟踪号（EBAN-BEDAR）来达到此目的，也可能使用自定义字段。 示例 高中低 | |||
| 结束时间 EndTime | 特定活动完成的精确日期和时间。 | ||
| 描述 EndTime 是记录活动结束的时间戳。虽然许多系统生成的事件是瞬间完成的（即 StartTime 等于 EndTime），但审批等人工任务可能有明确的开始和结束时间。此时间戳标志着该项工作的完成。 拥有独立的 EndTime 可以更准确地衡量实际处理时间与空闲等待时间。它与 StartTime 结合使用来计算“处理时间 (ProcessingTime)”指标。这种细节程度增强了对人工任务资源利用率和效率的分析。 为何重要 标志着活动的完成，支持计算实际处理时间，并提供更详细的任务时长视图。 获取方式 这源自工作流日志，可能同时记录了工作项的创建时间（StartTime）和完成时间（EndTime）。 示例 2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z | |||
| 要求到货日期 RequiredByDate | 申请人需要所申请货物或服务的最后期限。 | ||
| 描述 Required By Date（在 SAP 中为交付日期）规定了采购申请行项目中的货物或服务被需要的日期。该日期由申请人设定，是整个采购流程的目标时限。 此属性对于计算“采购申请准时完成率”KPI 至关重要。通过将“要求日期”与最终批准日期或采购订单创建日期进行对比，企业可以衡量其满足内部服务水平和业务需求的能力。分析未能在该日期前完成的申请，有助于发现采购流程中的系统性延迟。 为何重要 定义请求的目标完成日期，以便衡量准时交付率和对内部服务水平协议 (SLA) 的遵守情况。 获取方式 这是交付日期，位于表 EBAN 的行项目层级字段 LFDAT 中。 示例 2023-11-152023-12-012024-01-20 | |||
| 货币 Currency | 采购申请金额的货币代码。 | ||
| 描述 此属性指明了采购申请金额的计价货币，例如 USD、EUR 或 JPY。它为“采购申请金额”属性提供了必要的背景，对于在多币种环境下运营的跨国企业尤为重要。 为了确保财务分析和报告的准确性，必须考虑货币因素。在汇总或对比申请价值时，所有金额应转换为统一货币以确保结果具有实际意义。此属性是进行此类货币转换的前提。 为何重要 为申请金额提供必要的上下文信息，从而支持在多货币环境下进行准确的财务分析和对比。 获取方式 这可以在表 EBAN 的字段 WAERS 中找到。 示例 美元EURGBP | |||
| 采购订单号 PurchaseOrderNumber | 基于此采购申请创建的采购订单编号。 | ||
| 描述 Purchase Order Number（采购订单编号）是根据已批准的采购申请创建的正式采购文件的标识符。创建采购订单通常是采购申请的最终成功结果，标志着请求已转化为与供应商签署的正式订单。 此属性对于衡量“从申请到采购订单提前期”KPI 以及整体转化率至关重要。它将申请流程与下游采购流程联系起来，从而实现对整个采购到付款（P2P）周期的全面端到端洞察。 为何重要 将申请与后续采购单据关联，从而支持衡量申请到订单的转化率及前置时间。 获取方式 一旦从申请项创建了采购订单，即可在 EBAN 表的 EBELN 字段中找到。 示例 450001789045000178914500017892 | |||
从采购到付款 - 采购申请活动
| 活动 | 描述 | ||
|---|---|---|---|
| 审批步骤已完成 | 发生在审批人对申请执行通过操作时，完成多级审批流中的一个步骤。这可以通过申请发布状态的变更推断出来。 | ||
| 为何重要 此活动支持对审批工作流进行详细分析，衡量每个步骤所花费的时间，有助于区分高效审批人与流程中的瓶颈点。 获取方式 根据 EBAN 表的变更文档 (CDHDR/CDPOS) 推断。特定代码的发布代码状态（例如字段 FRGZU）从“未发布”变为“已发布”标志着此事件。 捕获 针对策略中定义的每个下达代码，追踪 EBAN 中下达状态字段的变更。 事件类型 inferred | |||
| 已创建招聘需求 | 标志着系统中采购申请单据的初始创建。当用户第一次保存新申请时，系统会明确捕捉此事件并记录创建时间戳。 | ||
| 为何重要 此活动是采购申请生命周期分析的首要起点，对于衡量从最初需求识别到最终批准或转为采购订单的端到端周期时间至关重要。 获取方式 这是一个从 EBAN 表捕获的明确事件，使用了特定采购申请编号（BANFN）的创建日期（ERDAT）和创建时间（ERZEIT）字段。 捕获 使用 EBAN 表中每项申请（BANFN）的创建时间戳字段（ERDAT, ERZEIT）。 事件类型 explicit | |||
| 采购申请已关闭 | 指示申请项已被视为处理完毕，无法再基于其创建更多采购订单。该状态通常在足额订购后由系统自动设置。 | ||
| 为何重要 此活动代表采购申请行项目生命周期的最终圆满完成，确认业务需求已完全转化为采购订单。 获取方式 从 EBAN 表推断。当“已关闭”指示符 (EBAKZ) 被设置时发生，通常出现在采购订单的订购数量等于申请数量时。 捕获 通过变更文档识别 EBAN 表中设置“已关闭”指示符 (EBAKZ) 的事件。 事件类型 inferred | |||
| 采购申请已批准 | 标志着采购申请获得最终完整审批，使其具备转化为采购订单的资格。当整体发布状态达到最终批准状态时，即可推断出这一里程碑。 | ||
| 为何重要 这是一个关键的成功里程碑，也是周期时间分析的常用终点。它标志着申请已通过所有检查，准备好由采购部门执行。 获取方式 根据 EBAN 表中的状态变更推断，具体指整体发布指示符 (FRGZU) 或处理状态 (PROCSTAT) 更新为最终“已批准”值时。 捕获 识别应用最终发布代码或整体申请状态变为“已批准”时的时间戳。 事件类型 inferred | |||
| 采购申请被驳回 | 代表审批人对采购申请的最终驳回，流程随之终止。这通过指示驳回的特定状态更新来捕捉。 | ||
| 为何重要 此活动是一个关键的失败终点。分析驳回频率、原因和发生环节，有助于发现政策合规性、预算或申请质量方面的问题。 获取方式 根据 EBAN 表中的状态变更推断。处理状态 (PROCSTAT) 或发布指示符被设置为明确代表“已驳回”的值。 捕获 通过变更文档识别 EBAN 中的整体状态更新为“已驳回”状态时的时间戳。 事件类型 inferred | |||
| 采购订单已创建 | 指示已生成引用该申请项的采购订单。这是一个显式的系统事件，将申请与后续的采购单据关联起来。 | ||
| 为何重要 这是采购申请流程的一个重大里程碑和成功结果。从申请获批到创建采购订单之间的时间，是衡量采购效率的关键 KPI。 获取方式 在创建采购订单项时明确记录。该关联存储在 EKPO 表（采购订单项）中，其中包含来源申请号 (BANFN) 和项号 (BNFPO)。 捕获 通过申请号和项将 EKPO 表关联回 EBAN。采购订单项的创建日期即为该事件的时间点。 事件类型 explicit | |||
| 审批步骤已开始 | 指示申请正在等待特定审批人或审批组的操作。当申请状态显示其正等待特定发布代码时，即可推断出此状态。 | ||
| 为何重要 此活动对于精准定位审批链中的瓶颈至关重要。分析此状态的持续时间有助于识别停滞的申请和超负荷的审批人。 获取方式 根据 EBAN 表的发布状态字段（如 FRGZU）和底层的发布策略配置推断。当某个特定的发布代码成为下一个待处理代码时，该事件开始。 捕获 根据工作流日志或状态字段，确定申请何时进入特定发布代码待审批状态。 事件类型 inferred | |||
| 审批重置 | 代表整个审批工作流被重置的事件，通常由于对申请做了重大修改。这会迫使审批流程从第一级开始重新运行。 | ||
| 为何重要 此活动突显了严重影响周期时间的重大返工。识别审批重置的原因是精简流程和减少延迟的关键。 获取方式 根据 EBAN 表的变更文档 (CDHDR/CDPOS) 推断。当发布状态字段（如 FRGKZ 或 FRGZU）在部分或全部设置后被清除时，系统会检测到此事件。 捕获 在变更日志中寻找发布状态从“已发布”变回“未发布”的记录。 事件类型 inferred | |||
| 已分配供应源 | 代表采购员为已批准的申请项指派特定供应商、合同或信息记录的操作。这是将申请转化为采购订单的关键准备步骤。 | ||
| 为何重要 此活动填补了审批与订购之间的空白。通过衡量分配供应源所需的时间，有助于发现采购员工作负荷中的延迟和采购效率问题。 获取方式 根据 EBAN 表中与货源相关的字段（如固定供应商 LIFNR、信息记录 INFNR 或合同 KONNR）中输入的值推断。 捕获 通过更改文档追踪 EBAN 表中 LIFNR、INFNR 或 KONNR 等字段的填值情况。 事件类型 inferred | |||
| 采购申请已修改 | 发生在用户在初始创建后修改申请中的关键字段（如数量、价格或物料）时。该操作会明确记录在 SAP 的变更文档系统中。 | ||
| 为何重要 追踪修改对于识别返工循环及其对周期时间的影响至关重要。频繁的修改通常意味着数据质量问题或需求变动，这些都是流程改进的关键领域。 获取方式 在 SAP 变更文档表 (CDHDR 和 CDPOS) 中明确记录对 EBAN 表所做的更改。对被追踪字段的每次更改都会创建一条条目。 捕获 从 CDHDR/CDPOS 中提取对象类为 BANF（采购申请）的变更事件。 事件类型 explicit | |||
| 采购申请已提交审批 | 代表申请人正式提交申请、触发审批工作流的时刻。通常在确定申请的发布策略且状态变为“审批中”时推断出此事件。 | ||
| 为何重要 这是一个关键里程碑，标志着审批周期时间 KPI 的开始。分析从创建到提交之间的时间，可以揭示申请准备阶段的延迟。 获取方式 根据 EBAN 表的变更文档 (CDHDR/CDPOS) 推断，具体指发布策略字段（如 FRGST）被填充或整体状态 (PROCSTAT) 变更为反映审批中状态时。 捕获 识别第一条指示审批工作流开始或状态变更为“审批中”的变更文档条目。 事件类型 inferred | |||
| 采购申请已撤回 | 发生在原始申请人在处理完成前取消或删除申请时。这通常是一个显式操作，会在申请项上设置删除标记。 | ||
| 为何重要 追踪撤回操作有助于了解需求波动和取消原因。它代表了采购申请的终结状态，防止了后续的进一步处理。 获取方式 当 EBAN 表中采购申请项的删除指示符 (LOEKZ) 字段被设置时明确捕捉。该变更记录在 CDHDR/CDPOS 中。 捕获 识别 EBAN 表中删除指示符 (LOEKZ) 被设置为 'L' 的事件。 事件类型 explicit | |||
提取指南
步骤
- 前提条件：确保您的用户在 SAP S/4HANA 中拥有访问所需 CDS 视图的适当权限。通常涉及 S_TABU_NAM 等对象的权限以及数据展示工具的访问权。
- 确定系统接入方式：确定您将如何连接到 SAP S/4HANA 数据库以执行 SQL 查询。常用工具包括 SAP HANA Studio、带有 ADT (ABAP Development Tools) 的 Eclipse IDE，或可通过 SAP HANA 数据库客户端连接的 DBeaver 等第三方 SQL 客户端。
- 审查 SQL 查询内容：熟悉提供的 SQL 脚本。它使用公用表表达式 (CTE) 来收集不同活动的数据，并将它们联合 (Union) 起来以创建统一的事件日志。
- 自定义占位符：在查询中找到并替换占位符。您需要设置提取时段的日期范围（格式为
[YYYY-MM-DD]）并指定所属组织的相关公司代码 ([Your Company Code])。 - 执行查询：在 SAP S/4HANA 数据库上运行完整且自定义后的 SQL 查询。根据数据量和选定的日期范围，该查询可能需要一些时间来执行。
- 初步数据核对：查询完成后，核对输出的前几行数据。检查所有列（如 PurchaseRequisitionId、ActivityName 和 EventTime）是否按预期填充，且数据格式是否正确。
- 数据转换处理：提供的查询旨在输出符合流程挖掘要求的格式。脚本中使用了
CAST和CONCAT函数以确保数据类型的一致性，因此执行后通常不需要进行大规模转换。 - 导出事件日志：从 SQL 客户端将整个结果集导出为 CSV 文件。请确保文件编码设置为 UTF-8，以防止出现乱码问题。
- 上传前准备：在上传到流程挖掘工具之前，验证 CSV 文件是否具有正确的标题（
PurchaseRequisitionId、ActivityName、EventTime等），并确保EventTime的日期时间格式一致且受目标平台支持。 - 上传至 ProcessMind：将最终的 CSV 文件上传到您的 ProcessMind 项目中。在项目中进行映射配置：将
PurchaseRequisitionId设为 Case ID，ActivityName设为 Activity，EventTime设为 Timestamp。
配置
- 核心 CDS 视图：数据提取主要使用
I_PurchaseRequisitionAPI01获取采购申请核心数据，使用I_ChangeDocument和I_ChangeDocumentItem追踪变更和状态更新，并使用I_PurchaseOrderItemAPI01关联至采购订单。 - 授权说明：执行用户需要对上述 CDS 视图具有读取权限。具体所需的角色和权限请咨询您的 SAP 安全团队。
- 日期范围筛选：为了控制数据量，必须在申请创建日期 (
CreationDate) 上应用日期范围过滤器。建议初始分析提取 3 到 6 个月的数据。 - 组织机构筛选：通过
CompanyCode筛选数据，以确保分析的是正确的业务实体流程。您也可以考虑通过PurchaseRequisitionType进行筛选，以专注于特定的采购流程（例如：标准商品与服务）。 - 变更文档配置：能否捕捉到“申请已修改”以及各类审批步骤等活动，取决于 SAP 系统中相关字段的变更文档记录是否已激活。如果缺失这些事件，请检查 EBAN 表的系统配置。
- 性能考量：对于拥有数百万条采购申请的大型系统，长时间运行此查询可能会影响系统性能。建议在非高峰时段执行，或在数据已更新的非生产环境中运行。
a 查询示例 sql
WITH REQUISITIONS AS (
SELECT
PurchaseRequisition,
PurchaseRequisitionType,
PurReqnDescription,
CreatedByUser,
CreationDate,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS CreationTimestamp,
SourceOfSupplyIsAssigned
FROM I_PurchaseRequisitionAPI01
WHERE CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
AND CompanyCode IN ('[Your Company Code]')
),
CHANGE_DOCS AS (
SELECT
ObjectValue AS PurchaseRequisition,
UserName,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS ChangeTimestamp,
FieldName,
ValueNew,
ValueOld
FROM I_ChangeDocument AS H
JOIN I_ChangeDocumentItem AS I
ON H.ChangeDocument = I.ChangeDocument
WHERE H.Objectclass = 'EINKBELEG'
AND H.CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
)
-- 1. Requisition Created
SELECT
R.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Created' AS "ActivityName",
R.CreationTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM REQUISITIONS AS R
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON R.PurchaseRequisition = I.PurchaseRequisition
UNION ALL
-- 2. Requisition Submitted For Approval & 5. Approval Step Started
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
CASE
WHEN C.ValueOld = ''
THEN 'Requisition Submitted For Approval'
ELSE 'Approval Step Started'
END AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R
ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew != ''
UNION ALL
-- 3. Requisition Amended
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Amended' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('MENGE', 'PREIS', 'MATNR', 'LIFNR', 'INFNR')
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 4. Approval Reset
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Reset' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueOld != '' AND C.ValueNew = ''
UNION ALL
-- 6. Approval Step Completed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Step Completed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew IN ('1', '2', '3', '4', '5', '6', '7') -- Adjust release codes as per your config
UNION ALL
-- 7. Requisition Approved
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Approved' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGKE' AND C.ValueNew = '2' -- Final release indicator '2' is common for approved
UNION ALL
-- 8. Requisition Rejected
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Rejected' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew = 'B' -- 'B' for Blocked/Rejected is a common setting
UNION ALL
-- 9. Requisition Withdrawn
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Withdrawn' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'LOEKZ' AND C.ValueNew = 'X'
UNION ALL
-- 10. Source of Supply Assigned
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Source of Supply Assigned' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('LIFNR', 'INFNR') AND C.ValueNew != ''
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 11. Purchase Order Created
SELECT DISTINCT
I.PurchaseRequisition AS "PurchaseRequisitionId",
'Purchase Order Created' AS "ActivityName",
CAST(CONCAT(H.PurchaseOrderDate, 'T', LPAD(H.CreationTime, 6, '0')) AS TIMESTAMP) AS "EventTime",
H.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.OrderPriceUnit * I.OrderQuantity AS "RequisitionAmount",
'PO Created' AS "RequisitionStatus"
FROM I_PurchaseOrderItemAPI01 AS I
JOIN I_PurchaseOrderAPI01 AS H
ON I.PurchaseOrder = H.PurchaseOrder
JOIN REQUISITIONS AS R
ON I.PurchaseRequisition = R.PurchaseRequisition
WHERE I.PurchaseRequisition IS NOT NULL AND I.PurchaseRequisition != ''
UNION ALL
-- 12. Requisition Closed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Closed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'EBAKZ' AND C.ValueNew = 'X'步骤
- 前提条件：确保您的用户在 SAP S/4HANA 中拥有访问所需 CDS 视图的适当权限。通常涉及 S_TABU_NAM 等对象的权限以及数据展示工具的访问权。
- 确定系统接入方式：确定您将如何连接到 SAP S/4HANA 数据库以执行 SQL 查询。常用工具包括 SAP HANA Studio、带有 ADT (ABAP Development Tools) 的 Eclipse IDE，或可通过 SAP HANA 数据库客户端连接的 DBeaver 等第三方 SQL 客户端。
- 审查 SQL 查询内容：熟悉提供的 SQL 脚本。它使用公用表表达式 (CTE) 来收集不同活动的数据，并将它们联合 (Union) 起来以创建统一的事件日志。
- 自定义占位符：在查询中找到并替换占位符。您需要设置提取时段的日期范围（格式为
[YYYY-MM-DD]）并指定所属组织的相关公司代码 ([Your Company Code])。 - 执行查询：在 SAP S/4HANA 数据库上运行完整且自定义后的 SQL 查询。根据数据量和选定的日期范围，该查询可能需要一些时间来执行。
- 初步数据核对：查询完成后，核对输出的前几行数据。检查所有列（如 PurchaseRequisitionId、ActivityName 和 EventTime）是否按预期填充，且数据格式是否正确。
- 数据转换处理：提供的查询旨在输出符合流程挖掘要求的格式。脚本中使用了
CAST和CONCAT函数以确保数据类型的一致性，因此执行后通常不需要进行大规模转换。 - 导出事件日志：从 SQL 客户端将整个结果集导出为 CSV 文件。请确保文件编码设置为 UTF-8，以防止出现乱码问题。
- 上传前准备：在上传到流程挖掘工具之前，验证 CSV 文件是否具有正确的标题（
PurchaseRequisitionId、ActivityName、EventTime等），并确保EventTime的日期时间格式一致且受目标平台支持。 - 上传至 ProcessMind：将最终的 CSV 文件上传到您的 ProcessMind 项目中。在项目中进行映射配置：将
PurchaseRequisitionId设为 Case ID，ActivityName设为 Activity，EventTime设为 Timestamp。
配置
- 核心 CDS 视图：数据提取主要使用
I_PurchaseRequisitionAPI01获取采购申请核心数据，使用I_ChangeDocument和I_ChangeDocumentItem追踪变更和状态更新，并使用I_PurchaseOrderItemAPI01关联至采购订单。 - 授权说明：执行用户需要对上述 CDS 视图具有读取权限。具体所需的角色和权限请咨询您的 SAP 安全团队。
- 日期范围筛选：为了控制数据量，必须在申请创建日期 (
CreationDate) 上应用日期范围过滤器。建议初始分析提取 3 到 6 个月的数据。 - 组织机构筛选：通过
CompanyCode筛选数据，以确保分析的是正确的业务实体流程。您也可以考虑通过PurchaseRequisitionType进行筛选，以专注于特定的采购流程（例如：标准商品与服务）。 - 变更文档配置：能否捕捉到“申请已修改”以及各类审批步骤等活动，取决于 SAP 系统中相关字段的变更文档记录是否已激活。如果缺失这些事件，请检查 EBAN 表的系统配置。
- 性能考量：对于拥有数百万条采购申请的大型系统，长时间运行此查询可能会影响系统性能。建议在非高峰时段执行，或在数据已更新的非生产环境中运行。
a 查询示例 sql
WITH REQUISITIONS AS (
SELECT
PurchaseRequisition,
PurchaseRequisitionType,
PurReqnDescription,
CreatedByUser,
CreationDate,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS CreationTimestamp,
SourceOfSupplyIsAssigned
FROM I_PurchaseRequisitionAPI01
WHERE CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
AND CompanyCode IN ('[Your Company Code]')
),
CHANGE_DOCS AS (
SELECT
ObjectValue AS PurchaseRequisition,
UserName,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS ChangeTimestamp,
FieldName,
ValueNew,
ValueOld
FROM I_ChangeDocument AS H
JOIN I_ChangeDocumentItem AS I
ON H.ChangeDocument = I.ChangeDocument
WHERE H.Objectclass = 'EINKBELEG'
AND H.CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
)
-- 1. Requisition Created
SELECT
R.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Created' AS "ActivityName",
R.CreationTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM REQUISITIONS AS R
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON R.PurchaseRequisition = I.PurchaseRequisition
UNION ALL
-- 2. Requisition Submitted For Approval & 5. Approval Step Started
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
CASE
WHEN C.ValueOld = ''
THEN 'Requisition Submitted For Approval'
ELSE 'Approval Step Started'
END AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R
ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew != ''
UNION ALL
-- 3. Requisition Amended
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Amended' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('MENGE', 'PREIS', 'MATNR', 'LIFNR', 'INFNR')
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 4. Approval Reset
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Reset' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueOld != '' AND C.ValueNew = ''
UNION ALL
-- 6. Approval Step Completed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Step Completed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew IN ('1', '2', '3', '4', '5', '6', '7') -- Adjust release codes as per your config
UNION ALL
-- 7. Requisition Approved
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Approved' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGKE' AND C.ValueNew = '2' -- Final release indicator '2' is common for approved
UNION ALL
-- 8. Requisition Rejected
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Rejected' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew = 'B' -- 'B' for Blocked/Rejected is a common setting
UNION ALL
-- 9. Requisition Withdrawn
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Withdrawn' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'LOEKZ' AND C.ValueNew = 'X'
UNION ALL
-- 10. Source of Supply Assigned
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Source of Supply Assigned' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('LIFNR', 'INFNR') AND C.ValueNew != ''
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 11. Purchase Order Created
SELECT DISTINCT
I.PurchaseRequisition AS "PurchaseRequisitionId",
'Purchase Order Created' AS "ActivityName",
CAST(CONCAT(H.PurchaseOrderDate, 'T', LPAD(H.CreationTime, 6, '0')) AS TIMESTAMP) AS "EventTime",
H.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.OrderPriceUnit * I.OrderQuantity AS "RequisitionAmount",
'PO Created' AS "RequisitionStatus"
FROM I_PurchaseOrderItemAPI01 AS I
JOIN I_PurchaseOrderAPI01 AS H
ON I.PurchaseOrder = H.PurchaseOrder
JOIN REQUISITIONS AS R
ON I.PurchaseRequisition = R.PurchaseRequisition
WHERE I.PurchaseRequisition IS NOT NULL AND I.PurchaseRequisition != ''
UNION ALL
-- 12. Requisition Closed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Closed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'EBAKZ' AND C.ValueNew = 'X'