您的采购到付款流程:采购申请数据模板
您的采购到付款流程:采购申请数据模板
- 建议收集的属性,支持详细分析
- 流程发现需要跟踪的关键活动
- 从SAP S/4HANA提取数据的指南
采购到付款,采购申请属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间 EventTime | 特定活动发生的准确日期和时间。 | ||
| 说明 事件时间是记录活动发生时刻的时间戳。该数据对于按时间顺序排列案例中的事件至关重要,也是流程挖掘中所有时长和绩效计算的基础。例如,“Requisition Submitted”与“Requisition Approved”事件之间的时间差决定了审批周期时间。 准确的时间戳对于分析流程绩效、识别延迟以及监控服务级别协议的遵循情况至关重要。此属性支持构建可视化周期时间、跟踪停滞采购申请并比较不同时段绩效的仪表板。 为什么重要 此时间戳对于排列事件、计算周期时间以及分析流程绩效和瓶颈至关重要。 获取位置 时间戳通常来自变更文档抬头(CDHDR-UDATE、CDHDR-UTIME)或工作流事件日志。 示例 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| 活动名称 ActivityName | 采购申请流程中特定时点发生的业务活动名称。 | ||
| 说明 Activity Name描述采购申请生命周期中发生的特定事件或任务。这些活动来源于变更文档和工作流历史等系统日志,代表“Requisition Created”“Approval Step Started”和“Purchase Order Created”等关键流程节点。 分析这些活动可以可视化流程顺序、识别瓶颈,并衡量不同阶段的耗时。了解“Requisition Amended”或“Requisition Rejected”等活动的顺序和频率,对于发现流程低效环节和改进机会至关重要。 为什么重要 定义流程中的步骤,构成流程图的基础,并支持对流程顺序、变体和瓶颈进行分析。 获取位置 这是一个派生属性,通常通过解读变更文档表(CDHDR、CDPOS)和工作流日志(如SWWLOGHIST)中的数据构建。 示例 创建采购申请审批步骤完成采购申请已批准已创建采购订单 | |||
| 采购申请ID PurchaseRequisitionId | 采购申请单据的唯一标识符。 | ||
| 说明 采购申请ID是SAP S/4HANA中唯一标识每项商品或服务申请的主键。它是核心案例标识符,将特定采购申请从创建到最终状态(如批准、拒绝或转换为采购订单)的所有相关活动和变更关联起来。 在流程挖掘中,此属性是重建每项采购申请端到端生命周期的基础。将所有相关事件归入同一个采购申请ID后,分析人员可以准确衡量周期时间、跟踪状态变化,并分析采购申请在审批流程中可能经历的不同路径。 为什么重要 这是连接所有相关流程步骤的核心案例标识符,可提供完整且连贯的采购申请生命周期视图。 获取位置 此属性是采购申请编号,位于EBAN表的BANFN字段。 示例 100178901001789110017892 | |||
| 审批人ID ApproverId | 执行审批或拒绝步骤的用户标识符。 | ||
| 说明 审批人ID专门标识完成审批或拒绝活动的用户。它不同于通用用户ID,仅关注审批工作流中的决策人员。记录此信息对于详细分析审批流程至关重要。 此属性支持分析审批行为,例如识别审批时间较长或经常拒绝采购申请的经理。它是审批步骤周期时间和工作流瓶颈分析仪表板的基础,有助于定位可能造成延迟的具体人员或角色。 为什么重要 定位审批步骤中的具体决策人员,支持按个人或角色详细分析审批周期时间和瓶颈。 获取位置 此信息通常从SAP Business Workflow表(如SWW_WI2OBJ和SWWLOGHIST)中提取,这些表将工作项与完成操作的用户关联起来。 示例 MJOHNSONCWILLIAMSLBLACK | |||
| 用户ID UserId | 创建采购申请或执行特定活动的用户标识符。 | ||
| 说明 用户ID标识采购申请生命周期中特定事件的负责员工或系统用户。该用户可能是创建采购申请的人员、批准申请的经理或修改申请的经办人。对于自动化步骤,也可能是系统用户或批处理用户ID。 按用户ID分析有助于了解用户行为、工作负荷分布和绩效。它对于识别培训需求、发现高绩效人员以及确保流程责任落实至关重要。结合用户主数据后,还可支持部门绩效分析。 为什么重要 支持用户绩效、工作负荷分布和流程合规分析,对于识别培训机会和资源瓶颈至关重要。 获取位置 创建人信息位于EBAN-ERNAM。后续变更记录在CDHDR-USERNAME中。审批信息位于工作流日志中。 示例 JSMITHRROEWF-BATCH | |||
| 部门 Department | 采购申请成本所归属的部门或成本中心。 | ||
| 说明 部门属性在SAP中通常由成本中心表示,用于标识负责所申请采购的业务单元。这是采购申请项目层面的重要财务和组织信息。 在流程挖掘中,此属性对于部门绩效分析至关重要。它支持构建仪表板,对比不同部门的周期时间、修改率和拒绝率等关键指标。这有助于发现可供其他部门借鉴的高绩效实践,也能识别需要额外培训或流程支持的部门。 为什么重要 支持跨业务单元比较绩效,突出周期时间或拒绝率差异,从而发现最佳实践和改进领域。 获取位置 这是成本中心,通常位于科目分配表EBKN的KOSTL字段。 示例 FIN-1001IT-2005MKT-3010 | |||
| 采购申请状态 RequisitionStatus | 采购申请当前的处理或审批状态。 | ||
| 说明 Requisition Status表示采购申请在其生命周期中的当前状态。在SAP中,它通常由Release Indicator表示,用于显示采购申请是被阻止、审批中、部分批准还是已完全批准。采购申请在工作流中流转时,该状态会随之变化。 持续跟踪状态对于理解流程顺序至关重要。它有助于识别采购申请卡在哪个环节以及停留了多长时间。分析状态之间的转换,可以详细了解审批流程及其变体。 为什么重要 表示采购申请的当前状态,对于跟踪进度、识别瓶颈和分析流程顺序至关重要。 获取位置 发布状态通常由发布标识确定,位于EBAN表的FRGZU字段。 示例 B1S | |||
| 采购申请类型 RequisitionType | 用于对采购申请进行分类的代码,例如标准物料、服务或资本性支出。 | ||
| 说明 采购申请类型在SAP中也称为单据类型,是用于分类采购申请的关键配置字段。不同类型可以触发不同的审批工作流、使用不同的字段设置,并对应不同的业务用途,例如标准库存物料、外部服务或资产采购。 按采购申请类型分析流程,可以了解不同类型申请的处理方式。通过比较各类别的绩效、周期时间和审批路径,企业可以发现某些采购申请类型的效率差异,并据此制定针对性的流程改进措施。 为什么重要 对采购申请进行分类,以支持比较分析,帮助了解不同类型的申请是否具有不同的流程顺序、瓶颈或周期时间。 获取位置 这是单据类型字段,位于EBAN表的BSART字段。 示例 NBFORV | |||
| 采购申请金额 RequisitionAmount | 采购申请的货币总金额。 | ||
| 说明 采购申请金额表示所申请商品或服务的预计总成本。该数值通常是决定审批工作流复杂度和时长的关键因素,金额较高的采购申请通常需要更多审批级别。 分析此属性可以按金额对流程进行分段。例如,可以回答“高金额采购申请是否需要更长时间审批?”或“经常被拒绝的采购申请金额是多少?”等问题。这是了解流程低效财务影响的重要维度。 为什么重要 帮助根据财务影响划分流程,通常与审批复杂度和周期时间相关,是开展基于金额的流程分析的重要依据。 获取位置 总金额位于EBAN表的GFWERT字段。项目级金额位于EBAN-PREIS。 示例 1500.0075000.50250.75 | |||
| 最后数据更新时间 LastDataUpdate | 表示该记录数据最近一次从源系统刷新时间的时间戳。 | ||
| 说明 此属性记录最近一次从源系统提取或更新数据的日期和时间,是了解所分析数据新鲜度的重要元数据。分析人员和业务用户依靠此时间戳判断流程数据是否反映运营的最新状态。 在任何流程分析中,了解数据的时效性都是制定有效决策的基础。此属性有助于管理用户预期,并确保结论基于满足具体分析要求的最新数据。 为什么重要 表示数据的新鲜度,这对于信任分析结果和及时制定业务决策至关重要。 获取位置 此时间戳在数据提取、转换和加载(ETL)过程中生成并添加。 示例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| 审批步骤名称 ApprovalStepName | 工作流中某个审批步骤的具体名称或说明。 | ||
| 说明 Approval Step Name以易于理解的方式描述审批工作流中的特定阶段,例如“Manager Approval”或“VP Finance Approval”。相比通用的“Approval Step Completed”活动,该属性提供了更明确的信息。 该属性对于Approval Step Cycle Time和Workflow Bottleneck Analysis仪表板至关重要。它支持对审批流程进行细粒度分析,准确定位造成严重延迟、导致工作积压的审批阶段。只有掌握这一层级的详细信息,您才能针对性地优化审批链。 为什么重要 提供审批阶段的细粒度信息,帮助您准确识别多级审批工作流中的瓶颈。 获取位置 此信息来自工作流任务说明,可通过将工作流日志关联到T528T等任务定义表获取。 示例 经理审批总监审批财务副总裁审批 | |||
| 拒绝原因 RejectionReason | 采购申请被拒绝时提供的原因。 | ||
| 说明 拒绝原因说明审批人拒绝采购申请的原因,可能包括超出预算、信息错误、不符合政策或与其他申请重复。该信息为了解流程失败提供了重要背景。 分析拒绝原因有助于识别流程低效和返工的根本原因。例如,如果“成本中心错误”是常见原因,则说明需要加强用户培训或系统校验。此属性是采购申请拒绝分析仪表板的关键,也是开展针对性流程改进的重要依据。 为什么重要 提供流程失败的根本原因,支持制定针对性改进措施,减少返工并提高采购申请一次通过率。 获取位置 这通常不是标准字段,可能记录在工作流容器元素、与采购申请关联的长文本或自定义字段中。 示例 超出预算供应商错误重复申请 | |||
| 是否自动化 IsAutomated | 用于标识活动由系统用户而非人工用户执行的标志。 | ||
| 说明 Is Automated属性是一个布尔标记。如果某项活动由系统用户或批处理用户执行,例如工作流操作使用的“WF-BATCH”,该标记则为true。借助此属性,您可以区分流程中的人工步骤和自动化步骤。 该属性对于衡量采购申请流程的自动化程度以及计算“Automated Approval Rate”KPI至关重要。通过筛选自动化步骤或人工步骤,分析人员可以比较两者的效率,并识别进一步自动化的机会,从而缩短处理时间、减少人工投入。 为什么重要 区分人工活动和系统驱动的活动,是衡量自动化率、识别人工任务自动化机会的关键。 获取位置 这是一个派生属性,通常通过规则判断事件的User ID是否属于已知系统用户或批处理用户列表。 示例 truefalse | |||
| 是否返工 IsRework | 用于标记某项活动是否属于返工,例如提交后的修改。 | ||
| 说明 Is Rework是一个计算得出的布尔标记,用于识别不增值或重复性的活动。在此流程中,常见示例是采购申请提交审批后发生“Requisition Amended”活动,导致审批流程重新开始。 该属性对于量化流程中的返工量及其对整体周期时间的影响至关重要。Requisition Amendment and Rework Rate仪表板依靠此标记突出显示流程低效环节。减少返工通常是流程改进的首要目标,因为这会直接节省时间和人工投入。 为什么重要 标记代表无效投入或重复工作的活动,支持直接衡量返工量及其对流程效率的影响。 获取位置 这是一个计算得出的属性。通常,如果某个“Requisition Amended”活动发生在第一个“Requisition Submitted For Approval”活动之后,系统就会将其标记为返工。 示例 truefalse | |||
| 源系统 SourceSystem | 标识提取数据的SAP S/4HANA具体实例。 | ||
| 说明 源系统属性表示生成流程数据的来源系统。在拥有多个SAP实例的组织中,例如分别用于开发、质量保证和生产的系统,或不同区域使用的独立系统,此字段对于数据治理和业务背景至关重要。 它确保能够区分不同来源的数据,避免错误汇总,并支持针对特定系统的分析。这是维护数据血缘、确保流程数据可追溯性的必填属性。 为什么重要 为数据来源和治理提供必要背景,尤其适用于多系统环境,并确保数据可追溯。 获取位置 通常指SAP系统ID(SID),可从系统变量或配置表中获取。 示例 S4PECCS4H_PROD_01 | |||
| 紧急程度 UrgencyLevel | 对采购申请紧急程度的分类,可能影响其处理优先级。 | ||
| 说明 Urgency Level表示采购申请的优先级。虽然系统通常没有专门的标准字段,但部分组织会使用Requirement Tracking Number等字段记录此信息。申请人可以借此标记需要加急处理的关键需求。 分析紧急程度的影响,有助于评估流程是否能够有效优先处理关键申请。Urgency Level Impact Analysis仪表板使用此属性,对比紧急采购申请与标准采购申请的周期时间和审批率,帮助您判断优先处理机制是否达到预期。 为什么重要 支持分析高优先级申请的流程表现差异,帮助验证紧急事项是否真正获得加急处理。 获取位置 系统没有标准的紧急程度字段。部分公司会使用Requirement Tracking Number(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 | 申请人需要所申请商品或服务的截止日期。 | ||
| 说明 要求日期在SAP中也称为交付日期,表示采购申请项目所需商品或服务的到位时间。该日期由申请人设定,是整个采购流程的目标日期。 此属性对于计算“采购申请按时完成率”KPI至关重要。将要求日期与最终审批日期或PO创建日期进行比较,企业可以衡量满足内部服务水平和业务需求的能力。分析未能按时完成的采购申请,可以发现采购流程中的系统性延迟。 为什么重要 定义申请的目标完成日期,支持衡量按时交付情况以及对内部服务水平的遵循程度。 获取位置 这是交付日期,位于EBAN表项目级别的LFDAT字段。 示例 2023-11-152023-12-012024-01-20 | |||
| 货币 Currency | 采购申请金额使用的货币代码。 | ||
| 说明 此属性指定采购申请金额所使用的货币,例如USD、EUR或JPY。它为采购申请金额属性提供必要背景,尤其适用于使用多种货币运营的跨国组织。 为确保财务分析和报告准确,必须考虑货币因素。汇总或比较采购申请金额时,应将所有金额换算为统一货币,以确保结果具有可比性。此属性是完成此类换算的前提。 为什么重要 为采购申请金额提供必要背景,支持多币种环境下准确开展财务分析和比较。 获取位置 位于EBAN表的WAERS字段。 示例 USDEURGBP | |||
| 采购订单编号 PurchaseOrderNumber | 根据采购申请创建的采购订单编号。 | ||
| 说明 采购订单编号是根据已批准采购申请创建的正式采购单据标识。创建采购订单通常是采购申请的最终成功结果,表示申请已转换为与供应商签订的正式订单。 此属性对于衡量采购申请到采购订单周期时间KPI和整体转换率至关重要。它将采购申请流程与后续采购流程连接起来,支持对整个采购到付款周期进行更全面的端到端分析。 为什么重要 将采购申请与后续采购单据关联,支持衡量采购申请到PO的转换率和周期时间。 获取位置 当采购申请项目已创建PO后,信息位于EBAN表的EBELN字段。 示例 450001789045000178914500017892 | |||
采购到付款,采购申请活动
| 活动 | 说明 | ||
|---|---|---|---|
| 创建采购申请 | 表示系统中采购申请单据的初始创建。当用户首次保存新采购申请时,系统会明确记录此事件及创建时间。 | ||
| 为什么重要 此活动是采购申请生命周期分析的主要起点,对于衡量从识别初始需求到最终审批或转换为采购订单的端到端周期时间至关重要。 获取位置 这是从EBAN表中明确捕获的事件,使用特定采购申请编号(BANFN)对应的创建日期(ERDAT)和创建时间(ERZEIT)字段。 采集 使用EBAN表中每个采购申请(BANFN)的创建时间字段(ERDAT、ERZEIT)。 事件类型 explicit | |||
| 审批步骤完成 | 当审批人对采购申请采取批准操作,完成多级审批工作流中的一个步骤时发生。可根据采购申请发布状态的变化推断。 | ||
| 为什么重要 此活动支持对审批工作流进行详细分析,衡量每个步骤所需的时间,并帮助识别流程中的高效审批人和瓶颈。 获取位置 根据EBAN表的变更文档(CDHDR/CDPOS)推断。对于特定发布代码,发布代码状态字段(如FRGZU)从未发布变为已发布,即表示此事件发生。 采集 针对策略中定义的每个发布代码,跟踪EBAN表中的发布状态字段变化。 事件类型 inferred | |||
| 已创建采购订单 | 表示已生成引用采购申请项目的采购订单。这是一个明确的系统事件,将采购申请与后续采购单据关联起来。 | ||
| 为什么重要 这是采购申请流程的重要里程碑和成功结果。采购申请获批到采购订单创建之间的时间,是衡量采购效率的关键KPI。 获取位置 当采购订单项目创建时明确记录。该关联存储在EKPO表(采购订单项目)中,其中包含源采购申请编号(BANFN)和项目编号(BNFPO)。 采集 根据采购申请编号和项目,将EKPO表与EBAN表关联。采购订单项目的创建日期标志着此事件。 事件类型 explicit | |||
| 采购申请已关闭 | 表示采购申请项目已完成处理,无法再据此创建采购订单。通常在全部数量完成订购后,系统会自动设置此状态。 | ||
| 为什么重要 此活动代表采购申请项目生命周期的最终成功完成,确认业务需求已完整转化为采购订单。 获取位置 根据EBAN表推断。当“Closed”标识(EBAKZ)被设置时发生,通常表示采购订单中的订购数量等于采购申请数量。 采集 通过变更文档,识别EBAN表中“Closed”标识(EBAKZ)被设置的事件。 事件类型 inferred | |||
| 采购申请已批准 | 标志着采购申请已获得最终且完整的批准,因此可以转换为采购订单。当整体发布状态达到最终批准状态时,可推断此里程碑。 | ||
| 为什么重要 这是关键的成功里程碑,也是周期时间分析的常见终点。它表示采购申请已通过所有检查,可以交由采购部门处理。 获取位置 根据EBAN表中的状态变化推断,具体表现为整体发布标识(FRGZU)或处理状态(PROCSTAT)更新为最终的“Approved”值。 采集 识别最终发布代码被应用,或整体采购申请状态变更为“Approved”的时间戳。 事件类型 inferred | |||
| 采购申请已拒绝 | 表示审批人最终拒绝采购申请,流程随之停止。系统会通过表示拒绝的特定状态更新记录此事件。 | ||
| 为什么重要 此活动是关键的失败终点。分析拒绝频率、原因及发生环节,有助于发现政策合规、预算或申请质量方面的问题。 获取位置 根据EBAN表中的状态变化推断。处理状态(PROCSTAT)或发布标识被设置为明确表示“Rejected”的值。 采集 通过变更文档,识别EBAN中的整体状态更新为“Rejected”状态的时间戳。 事件类型 inferred | |||
| 审批步骤开始 | 表示采购申请正在等待特定审批人或审批组处理。当采购申请状态显示其正在等待特定发布代码时,可推断发生此事件。 | ||
| 为什么重要 此活动对于定位审批链中的瓶颈至关重要。分析该状态的持续时间,有助于识别停滞的采购申请和负荷过高的审批人。 获取位置 根据EBAN表的发布状态字段(如FRGZU)及底层发布策略配置推断。当某个特定发布代码成为下一项待处理代码时,事件开始。 采集 根据工作流日志或状态字段,确定采购申请进入等待特定发布代码审批状态的时间。 事件类型 inferred | |||
| 审批重置 | 表示整个审批工作流被重置的事件,通常由采购申请发生重大修改引起。这会迫使审批流程从第一级重新开始。 | ||
| 为什么重要 此活动体现了会严重影响周期时间的重大返工。识别审批重置的原因,是简化流程、减少延迟的关键。 获取位置 根据EBAN表的变更文档(CDHDR/CDPOS)推断。当发布状态字段(如FRGKZ或FRGZU)在部分或全部设置后被清空时,即检测到此事件。 采集 在变更日志中查找发布状态从已发布状态恢复为未发布状态的变更。 事件类型 inferred | |||
| 已分配供应来源 | 表示采购员为已批准的采购申请项目分配特定供应商、合同或信息记录。这是准备创建采购订单的关键步骤。 | ||
| 为什么重要 此活动衔接了审批与下单环节。衡量供应来源分配所需时间,有助于识别采购员工作负荷和寻源效率方面的延迟。 获取位置 当EBAN表中与供应来源相关的字段录入值时推断,例如固定供应商(LIFNR)、信息记录(INFNR)或合同(KONNR)。 采集 通过变更文档跟踪EBAN表中LIFNR、INFNR或KONNR等字段的填充情况。 事件类型 inferred | |||
| 提交采购申请以供审批 | 表示申请人正式提交采购申请并触发审批工作流的时刻。通常可根据采购申请的发布策略已确定且状态变为“In Approval”来推断。 | ||
| 为什么重要 这是启动审批周期时间KPI计时的关键里程碑。分析创建到提交之间的时间,可以发现采购申请准备阶段的延迟。 获取位置 根据EBAN表的变更文档(CDHDR/CDPOS)推断,具体包括发布策略字段(如FRGST)被填充,或整体状态(PROCSTAT)变更为表示“In Approval”的状态。 采集 识别首条表明审批工作流开始,或状态变更为“In Approval”的变更文档记录。 事件类型 inferred | |||
| 采购申请已修改 | 当用户在采购申请初始创建后修改关键字段时发生,例如数量、价格或物料。此操作会明确记录在SAP的变更文档系统中。 | ||
| 为什么重要 跟踪修改对于识别返工循环及其对周期时间的影响至关重要。修改频率较高通常表明数据质量或需求变化存在问题,这些都是流程改进的重点领域。 获取位置 明确记录在SAP变更文档表(CDHDR和CDPOS)中,用于记录对EBAN表的修改。每次对受跟踪字段的修改都会生成一条记录。 采集 从CDHDR/CDPOS中提取变更事件,其中对象类为BANF,表示采购申请。 事件类型 explicit | |||
| 采购申请已撤回 | 当原申请人在采购申请完成处理前取消或删除申请时发生。通常表现为对采购申请项目设置删除标识的明确操作。 | ||
| 为什么重要 跟踪撤回情况有助于了解需求波动和取消原因。这是采购申请的终止状态,会阻止后续处理。 获取位置 当EBAN表中采购申请项目的删除标识字段(LOEKZ)被设置时明确记录。相关变更会记录在CDHDR/CDPOS中。 采集 识别EBAN表中删除标识(LOEKZ)被设置为“L”的事件。 事件类型 explicit | |||
提取指南
步骤
- 前提条件:确保您在SAP S/4HANA中拥有具备适当授权的用户,可访问所需的CDS View。通常需要S_TABU_NAM等对象的权限,以及数据查看工具的访问权限。
- 确定系统访问方式:确定连接SAP S/4HANA数据库并执行SQL查询的方式。常用工具包括SAP HANA Studio、带有ADT(ABAP Development Tools)的Eclipse IDE,或可通过SAP HANA数据库客户端连接的DBeaver等第三方SQL客户端。
- 查看SQL查询:熟悉提供的SQL脚本。脚本使用Common Table Expressions(CTE)收集不同活动的数据,并通过合并这些数据创建统一的事件日志。
- 自定义占位符:找到并替换查询中的占位符。您需要设置提取期间的日期范围,格式为
[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 View:提取主要使用
I_PurchaseRequisitionAPI01获取核心采购申请数据,使用I_ChangeDocument和I_ChangeDocumentItem跟踪变更和状态更新,并使用I_PurchaseOrderItemAPI01关联采购订单。 - 授权:执行用户需要具备上述CDS View的读取权限。请咨询SAP安全团队,确认所需角色和授权。
- 日期范围筛选:必须根据采购申请创建日期(
CreationDate)应用日期范围筛选,以限制数据量。首次分析建议使用3至6个月的数据。 - 组织筛选:按
CompanyCode筛选数据,确保分析正确业务实体的流程。您也可以按PurchaseRequisitionType筛选,聚焦特定采购流程,例如标准物料与服务采购。 - 变更文档配置:是否能捕获“Requisition Amended”和各类审批步骤等活动,取决于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' 步骤
- 确认可以直接读取包含EBAN和EBKN的SAP HANA架构,并识别系统中用于申请单变更、发布处理、源分配、采购订单引用和关闭的变更文档及采购单据对象。由于这些对象和字段可能因版本和配置而异,请将查询中的每个方括号占位符替换为系统中的对应对象或字段。
- 在SAP GUI中,使用事务SE16H或经批准的数据库管理工具检查EBAN和EBKN,验证申请单关键字段,并确认可用的日期、时间、用户、状态、删除、发布、科目分配和采购单据引用字段。使用SE11或SAP数据字典验证字段定义。测试时不要暴露生产数据。
- 识别用于申请单修改和审批变更的已配置变更文档源。查询要求使用名为[Your requisition change document source]的标准化变更源,其中包含申请单号、项目号、变更字段、旧值、新值、变更日期、变更时间和用户字段。执行前,将此源映射到系统中相关的SAP变更文档表或CDS视图。
- 识别用于提交、审批重置、审批步骤开始、审批步骤完成、最终审批和拒绝的已配置工作流或发布源。查询要求使用[Your requisition approval event source],每个状态或发布转换对应一行,并包含申请单号、项目号、事件类型、发布代码或审批组、审批人、事件日期、事件时间和状态字段。将其映射到S/4HANA配置所使用的发布或工作流持久化对象。
- 识别源分配、采购订单引用和关闭源。查询要求使用[Your requisition source assignment source]、[Your requisition purchase order reference source]和[Your requisition closure source]。将这些占位符映射到系统中经批准的表或视图。采购订单创建必须由采购订单行对申请单行的明确引用表示,不得根据无关采购活动推断。
- 使用[Start date]和[End date]设置提取时间范围。首次运行建议使用3至6个月的范围。只有在验证数据库性能和事件量后,才使用更宽的范围。查询会筛选创建日期和事件日期,同时保留申请单标识符作为案例标识符。
- 在连接到SAP HANA的经批准SQL客户端中执行查询。仅替换查询之外的连接详细信息、日期参数、公司专用筛选条件,以及有明确文档说明的源和字段占位符。严格保留输出列名:PurchaseRequisitionId、ActivityName、EventTime、UserId、ApproverId、RequisitionType、Department、RequisitionAmount和RequisitionStatus。
- 检查重复事件、时间戳精度、时区处理,以及项目级与单据级粒度。查询输出单据级案例标识符,并在内部包含项目上下文。如果多个项目产生相同活动和时间戳,除非您的ProcessMind设计明确要求去重,否则应保留独立记录。
- 验证每项必需活动是否都作为ActivityName值出现,EventTime是否有值且时间顺序合理,并确认必需案例标识符不为null。针对相同日期范围,与SAP报告或经批准的运营提取结果进行数量核对。
- 将结果导出为UTF-8 CSV或其他ProcessMind支持的表格格式。包含表头行,保留兼容ISO格式的时间戳,将null保留为空值,并上传文件,将PurchaseRequisitionId作为案例标识符、ActivityName作为活动列、EventTime作为时间戳列。
配置
- 案例标识符:使用EBAN中的采购申请单据编号,并将其表示为PurchaseRequisitionId。如果流程按项目配置,则改用已记录的复合键,例如采购申请编号与项目编号,并将同一键应用于每个事件。
- 主要来源:EBAN用于采购申请项目数据,EBKN用于科目分配以及部门或成本中心补充信息。执行前,请在SAP数据字典中确认确切的字段名称和数据类型。
- 事件来源:查询有意为变更、审批、来源分配、采购订单引用和关闭来源保留明确占位符,因为这些来源取决于S/4HANA版本、工作流设计、发布流程、已激活的业务功能和客户扩展。
- 日期范围:从3至6个月开始。条件允许时,应在已建立索引或支持分区裁剪的日期字段上设置有界范围。对于增量加载,应适当重叠提取窗口,以捕获延迟到达的变更,然后使用案例、活动、时间戳、项目和来源事件键进行去重。
- 业务筛选条件:仅在字段可用且业务含义已确认时,配置[Company code filter]、[Document type filter]、[Purchasing group filter]和[Plant filter]。如果目标是捕获完整生命周期,请避免按状态筛选。
- 状态映射:根据目标系统的发布策略或工作流配置,设置In Approval、final approved、rejected、reset、pending release code和closed的对应值。不要假设所有SAP客户端都使用相同的状态代码。
- 修改映射:纳入数量、价格、物料、交货日期、科目分配以及流程定义为关键字段的其他字段变更。查询包含针对所列关键字段的明确条件,并要求来源提供变更字段名称。
- 时间戳处理:在数据库时区中合并事件日期和事件时间,然后记录转换为UTC的过程。如果来源仅存储日期,则仅在没有更精确时间戳时使用午夜,并记录这一限制。
- 性能:按日期和业务范围限制首次提取,仅选择所需列,避免不受限制地连接大型变更历史或工作流历史,并检查HANA执行计划。如果需要重复提取,可将标准化事件来源物化或暂存。
- 授权和前提条件:获取EBAN、EBKN、已配置的变更和工作流来源、来源分配数据、采购订单引用数据及关闭数据的读取权限。确认直接数据库访问已获批准,相关采购和工作流功能已启用,并具备所需的SAP HANA数据库许可证或管理工具。
- 安全性:遵循最小权限原则,保护用户和审批人标识符,并遵守组织关于提取采购和财务信息的规定。
a 示例查询 sql
WITH
base_items AS (
SELECT
eban.[Purchase requisition number field] AS PurchaseRequisitionId,
eban.[Purchase requisition item field] AS RequisitionItem,
eban.[Creation date field] AS CreationDate,
eban.[Creation time field] AS CreationTime,
eban.[Created by field] AS CreatedBy,
eban.[Requisition type field] AS RequisitionType,
eban.[Company code field] AS CompanyCode,
eban.[Plant field] AS Plant,
eban.[Purchasing group field] AS PurchasingGroup,
eban.[Quantity field] AS Quantity,
eban.[Net price field] AS NetPrice,
eban.[Currency field] AS Currency,
eban.[Material field] AS Material,
eban.[Deletion indicator field] AS DeletionIndicator,
eban.[Overall release status field] AS OverallReleaseStatus,
eban.[Item processing status field] AS ItemProcessingStatus,
ebkn.[Cost center field] AS CostCenter,
ebkn.[Department field] AS Department,
CAST(eban.[Quantity field] * eban.[Net price field] AS DECIMAL(19,4)) AS RequisitionAmount
FROM [Your SAP schema].EBAN eban
LEFT JOIN [Your SAP schema].EBKN ebkn
ON ebkn.[Purchase requisition number field] = eban.[Purchase requisition number field]
AND ebkn.[Purchase requisition item field] = eban.[Purchase requisition item field]
WHERE eban.[Creation date field] BETWEEN '[Start date]' AND '[End date]'
AND ('[Company code filter]' = '' OR eban.[Company code field] = '[Company code filter]')
AND ('[Document type filter]' = '' OR eban.[Requisition type field] = '[Document type filter]')
AND ('[Purchasing group filter]' = '' OR eban.[Purchasing group field] = '[Purchasing group filter]')
AND ('[Plant filter]' = '' OR eban.[Plant field] = '[Plant filter]')
),
created_events AS (
SELECT
PurchaseRequisitionId,
'Requisition Created' AS ActivityName,
TO_TIMESTAMP(CAST(CreationDate AS NVARCHAR(8)) || LPAD(COALESCE(CAST(CreationTime AS NVARCHAR(6)), '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CreatedBy AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
RequisitionType,
Department,
RequisitionAmount,
'Created' AS RequisitionStatus
FROM base_items
),
submitted_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Submitted For Approval' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Requester or submitter field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'SUBMITTED'
OR a.[Status field] = 'In Approval'
),
amended_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Amended' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Amended' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] IN ('QUANTITY', 'PRICE', 'MATERIAL', 'DELIVERY_DATE', 'ACCOUNT_ASSIGNMENT')
),
reset_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Reset' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'RESET'
OR a.[Status field] = 'Approval Reset'
),
step_started_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Started' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_STARTED'
OR a.[Status field] = 'Pending Release'
),
step_completed_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Completed' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_COMPLETED'
OR a.[Status field] = 'Step Approved'
),
approved_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Approved' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'FINAL_APPROVED'
OR a.[Status field] = 'Approved'
),
rejected_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Rejected' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'REJECTED'
OR a.[Status field] = 'Rejected'
),
withdrawn_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Withdrawn' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Withdrawn' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] = 'DELETION_INDICATOR'
AND c.[New value field] IS NOT NULL
AND c.[New value field] <> ''
),
source_assigned_events AS (
SELECT
b.PurchaseRequisitionId,
'Source of Supply Assigned' AS ActivityName,
TO_TIMESTAMP(CAST(s.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(s.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
s.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Source Assigned' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition source assignment source] s
ON s.[Purchase requisition number field] = b.PurchaseRequisitionId
AND s.[Purchase requisition item field] = b.RequisitionItem
WHERE s.[Source identifier field] IS NOT NULL
AND s.[Source identifier field] <> ''
),
purchase_order_events AS (
SELECT
b.PurchaseRequisitionId,
'Purchase Order Created' AS ActivityName,
TO_TIMESTAMP(CAST(p.[Purchase order creation date field] AS NVARCHAR(8)) || LPAD(CAST(p.[Purchase order creation time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
p.[Purchase order creator field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Purchase Order Created' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition purchase order reference source] p
ON p.[Purchase requisition number field] = b.PurchaseRequisitionId
AND p.[Purchase requisition item field] = b.RequisitionItem
WHERE p.[Purchase order number field] IS NOT NULL
AND p.[Purchase order number field] <> ''
),
closed_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Closed' AS ActivityName,
TO_TIMESTAMP(CAST(cl.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(cl.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
cl.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
cl.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition closure source] cl
ON cl.[Purchase requisition number field] = b.PurchaseRequisitionId
AND cl.[Purchase requisition item field] = b.RequisitionItem
WHERE cl.[Event type field] = 'CLOSED'
OR cl.[Status field] = 'Closed'
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM created_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM submitted_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM amended_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM reset_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_started_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_completed_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM approved_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM rejected_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM withdrawn_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM source_assigned_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM purchase_order_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM closed_events
ORDER BY PurchaseRequisitionId, EventTime, ActivityName; 告别P2P采购申请延迟:立即优化您的工作流!
简化流程、缩短周期时间,并将周期时间减少30%。
无需信用卡,5分钟即可完成设置。