您的采购到付款流程采购申请数据模板
您的采购到付款流程采购申请数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- 提取指南
采购到付款-采购申请属性
| 名称 | 说明 | ||
|---|---|---|---|
|
事件时间
EventTime
|
具体活动或事件发生时的准确时间戳。 | ||
|
说明
事件时间即时间戳,记录业务事件在系统中的发生日期和时间,是所有基于时间的流程分析的基础。 该属性对于计算活动之间的周期时间、持续时间和等待时间至关重要。它支持流程绩效分析、瓶颈识别和SLA合规监控。准确的时间戳是确保流程挖掘分析可靠的必要条件。
为什么重要
它提供事件的时间顺序,这是计算流程时长、识别瓶颈和分析一段时间内绩效所必需的。
获取位置
可在工作流历史表或文档日志表中找到,通常是与每次状态变更或事件记录关联的“CreatedDateTime”或“ModifiedDateTime”字段。
示例
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:22:05Z
|
|||
|
活动名称
ActivityName
|
申请流程中发生的具体业务事件或步骤的名称。 | ||
|
说明
该属性记录采购申请生命周期中执行的每项活动名称,例如“申请已创建”“审批步骤已通过”和“采购订单已创建”。这些活动构成发现的流程图节点。 分析这些活动的顺序、频率及其间隔时长,是流程挖掘的核心。它有助于识别瓶颈、返工循环以及偏离标准流程路径的情况,为运营低效提供洞察。
为什么重要
该属性定义流程图中的步骤,使申请工作流能够被可视化、分析和理解。
获取位置
通常根据Microsoft Dynamics 365中的状态变更日志、工作流历史表或特定事件表得出,例如WorkflowTrackingStatusTable。
示例
申请已提交审批审批步骤已通过申请已修改
|
|||
|
采购申请ID
PurchaseRequisitionId
|
采购申请的唯一标识符,也是主要案例标识。 | ||
|
说明
采购申请ID是关联单个商品或服务申请所有活动的核心键。每个申请流程从创建到最终审批和关闭,都会通过该唯一ID进行追踪。 在流程挖掘中,该属性是重建每个申请端到端历程的基础。它支持分析单个案例的流程变体、周期时间和合规情况,完整呈现申请生命周期。
为什么重要
它对于将所有相关事件归入单个流程实例至关重要,从而支持对每个申请生命周期进行完整的端到端分析。
获取位置
它通常是采购申请主表的主键,例如Microsoft Dynamics 365中的PurchReqTable。
示例
PR-001254PR-001255PR-001256
|
|||
|
上次数据更新
LastDataIngestionTimestamp
|
数据最近一次提取并加载到流程挖掘工具中的时间戳。 | ||
|
说明
该属性表示当前分析数据的新鲜度,显示源系统最近一次刷新数据的日期和时间。它并非Dynamics 365自身的字段,而是在数据导入过程中添加的元数据。 该时间戳对于帮助用户了解洞察的时效性至关重要。它可以说明您查看的是实时数据,还是特定时间点的快照,而这会影响结论的相关性。
为什么重要
它向用户说明数据的新鲜度,确保用户了解分析所覆盖的时间范围以及洞察的相关性。
获取位置
该值在数据导入或ETL过程中生成并附加到数据集。
示例
2024-05-20T08:00:00Z2024-05-21T08:00:00Z2024-05-22T08:00:00Z
|
|||
|
源系统
SourceSystemId
|
提取数据的记录系统。 | ||
|
说明
该属性用于标识事件数据的来源系统。在此场景中,值应为“Microsoft Dynamics 365”。在包含多个集成系统的环境中,该字段对于数据血缘和上下文至关重要。 在分析中,它有助于区分跨多个系统的流程,或确认数据来自单一权威来源。这对于数据验证以及确保分析基于正确数据集非常重要。
为什么重要
它提供数据来源的上下文,对于数据治理、验证以及多系统集成环境至关重要。
获取位置
这是一个静态值“Microsoft Dynamics 365”,在数据提取和转换过程中添加。
示例
Microsoft Dynamics 365 F&OD365MSD365
|
|||
|
审批步骤
ApprovalStep
|
工作流中某个具体审批步骤的名称或阶段。 | ||
|
说明
此属性用于识别审批工作流中的具体阶段,例如“经理审批”或“财务审批”。相比通用活动名称,它提供了更细粒度的信息。 此属性是“审批步骤瓶颈分析”的基础。跟踪每个独立审批步骤所耗费的时间,可以准确定位导致整体流程延迟的阶段,从而采取有针对性的措施提升工作流效率。
为什么重要
它支持对审批工作流进行细粒度分析,帮助识别导致瓶颈的具体阶段。
获取位置
此信息包含在工作流历史表中,例如WorkflowTrackingStatusTable。该表记录已配置工作流的每个步骤。
示例
经理审批部门负责人审批财务审核
|
|||
|
用户
User
|
执行活动的人员的用户ID或姓名。 | ||
|
说明
该属性用于标识负责执行特定流程步骤的员工或系统用户,例如提交申请或批准请求的人员。它可以是用户ID、姓名全称或电子邮件地址。 按用户分析活动有助于识别培训需求、高绩效个人或团队以及工作负载分布。它对于合规分析同样重要,例如职责分离分析,也有助于了解不同用户角色如何与流程交互。
为什么重要
它支持分析特定用户的行为、工作负载和绩效,这对于资源管理和发现培训机会至关重要。
获取位置
通常可在工作流历史表(例如WorkflowTrackingStatusTable)或交易表(例如PurchReqTable)中找到,并与用户表(例如UserInfo)关联。
示例
j.smitha.joness.patel
|
|||
|
申请总金额
RequisitionTotalAmount
|
采购申请的货币总价值。 | ||
|
说明
该属性记录采购申请中所有行项目的总价值。金额通常会影响审批工作流的复杂度,金额较高的申请往往需要更多审批步骤。 在流程分析中,该属性对于按金额筛选和分析至关重要。它可以帮助回答“高金额申请是否需要更长时间审批?”或“当前卡在流程中的申请金额是多少?”等问题,为流程绩效提供财务视角。
为什么重要
它为分析增加财务维度,支持优先处理高金额案例,并了解金额如何影响流程行为。
获取位置
该值通常位于采购申请抬头表中,或根据采购申请行表(PurchReqLine)中的行项目金额汇总计算。
示例
1500.0025000.50500.75
|
|||
|
申请状态
RequisitionStatus
|
采购申请当前或最终所处的状态。 | ||
|
说明
该属性表示采购申请在任意时点的整体状态,例如“In Review”“Approved”“Rejected”或“Closed”。它通常是代表最终结果的案例级属性。 分析最终状态有助于了解流程的整体结果。例如,大量“Rejected”或“Withdrawn”申请可能表明初始申请阶段存在问题,或审批流程过于繁琐。它是衡量成功率和流程效率的关键指标。
为什么重要
它为每个案例提供清晰结果,支持分析批准率、驳回率和撤回率,这些都是关键绩效指标。
获取位置
状态字段通常位于采购申请抬头表PurchReqTable中,字段名通常为“Status”或“PurchReqStatus”。
示例
已批准审核中已拒绝草稿
|
|||
|
紧急程度
UrgencyLevel
|
用于分类申请的紧急程度,例如“高”“中”或“低”。 | ||
|
说明
紧急程度或优先级表示所申请的商品或服务需要多快到位。此属性通常用于影响审批路径,或帮助审批人确定工作优先级。 分析此属性有助于判断优先级体系是否有效。例如,您可以比较“高”紧急程度申请与“低”紧急程度申请的周期时间。如果两者没有明显差异,可能说明优先级字段未被使用或使用不当。这是“紧急程度影响分析”仪表板中的重要洞察。
为什么重要
它有助于评估优先级设置是否能有效加快关键请求的处理,并发现紧急程度分类可能存在的滥用问题。
获取位置
这可能是PurchReqTable中的标准字段或自定义字段。字段是否存在及其名称可能因系统配置而异。
示例
高中低
|
|||
|
部门
Department
|
申请人的部门,或与申请关联的成本中心。 | ||
|
说明
该属性用于指定发起采购申请的业务部门或成本中心,例如“Marketing”“IT”或“Operations”。这些信息通常属于申请抬头的一部分。 按部门细分流程对于比较分析至关重要。它可以帮助您了解哪些部门的周期时间最长、驳回率最高或修改最频繁。这些洞察有助于根据不同部门的需求制定改进方案。
为什么重要
它支持按不同业务单元筛选和比较流程绩效,揭示部门特有的模式、瓶颈或低效环节。
获取位置
这些信息通常存储在采购申请抬头表(PurchReqTable)中,并与Dynamics 365中的财务维度配置关联。
示例
IT部门财务部运营部
|
|||
|
修改次数
AmendmentCount
|
采购申请被修改的总次数。 | ||
|
说明
这是一个计算得出的数值属性,用于统计每个采购申请案例中“采购申请已修改”活动的出现次数。 此属性是“采购申请修改频率”仪表板和“采购申请修改率”KPI的基础。它量化每个案例的返工量,帮助您快速识别修改频繁、效率较低的申请、部门或用户,从而有针对性地提升初始申请质量。
为什么重要
它量化案例中的返工情况,便于衡量和分析修改频率及其对流程效率的影响。
获取位置
这是一个计算得出的属性。数据转换期间,通过统计每个唯一PurchaseRequisitionId对应的“采购申请已修改”活动数量来生成。
示例
013
|
|||
|
审批工作流路径
ApprovalWorkflowPath
|
对实际执行的审批步骤顺序的表示。 | ||
|
说明
该属性是一个派生字段,用于连接某份申请的审批步骤顺序,例如“经理审批 -> 部门负责人审批 -> 财务审批”。它可以有效概括审批子流程的流程变体。 这对于“一致性偏差监控”仪表板至关重要。通过将实际工作流路径与预定义的标准路径或预期路径进行比较,您可以轻松标记可能代表政策违规或运营风险的不合规或异常流程路径。
为什么重要
它通过提供清晰的流程变体字符串表示,简化合规分析,帮助您快速发现偏离标准程序的情况。
获取位置
此属性不是标准字段。数据转换期间,必须按时间顺序拼接每个案例的ApprovalStep值来生成该属性。
示例
经理→总监经理→总监→财务副总裁经理→自动批准
|
|||
|
审批组
ApproverGroup
|
负责某个审批步骤的用户组或角色。 | ||
|
说明
此属性用于识别负责处理特定审批任务的组、角色或队列,例如“财务审批人”或“IT经理”。 按审批组分析流程绩效,有助于了解工作负载分布,并识别资源不足或需要额外培训的团队。它还直接支持“审批步骤瓶颈分析”仪表板,让您可以按负责审批的团队切分绩效数据。
为什么重要
它有助于识别不同审批团队之间的绩效差异,突出特定团队可能存在的资源限制或培训需求。
获取位置
此信息属于工作流历史的一部分,例如WorkflowTrackingStatusTable。该表记录每项任务所分配的用户或用户组。
示例
财务审批人IT经理高级管理层
|
|||
|
币种
Currency
|
申请金额所使用的币种代码。 | ||
|
说明
此属性指定申请总金额所使用的币种,例如USD、EUR或GBP。对于涉及多种币种的跨国组织,这对财务分析尤为重要。 使用币种属性可以正确处理和汇总财务数据,确保准确解读货币金额,并支持将金额转换为统一币种,从而实现不同地区或业务部门之间的准确报告和比较。
为什么重要
它为财务属性提供必要的上下文,确保在多币种环境中准确解读和汇总货币金额。
获取位置
此字段通常位于采购申请抬头表PurchReqTable中,与金额字段并列。
示例
USDEURGBP
|
|||
|
是否首次审批通过
IsFirstPass
|
用于标记申请是否在未修改或被拒绝过的情况下通过审批。 | ||
|
说明
这是一个计算得出的布尔属性:如果申请的审批路径中不包含“采购申请已修改”或“审批步骤已拒绝”活动,则值为“true”;否则为“false”。 此属性直接支持“采购申请首次审批通过率”KPI。它通过提供清晰的案例级返工指标,简化流程效率分析。首次审批通过率较低,通常说明初始数据质量存在问题或需求不明确,也表明流程仍有改进空间。
为什么重要
它通过识别需要返工的案例,直接衡量流程质量和效率,并支持关注一次通过率的KPI。
获取位置
这是一个计算得出的属性。数据转换期间,需要分析每个案例的完整活动序列,检查审批前是否不存在返工活动。
示例
truefalse
|
|||
|
采购订单编号
PurchaseOrderNumber
|
根据申请创建的采购订单标识符。 | ||
|
说明
此属性存储由已批准采购申请生成的采购订单唯一ID。它连接采购申请流程与后续采购流程。 跟踪此编号对于分析“申请到采购订单转换时间”至关重要。它可以确认申请已成功进入采购到付款周期的下一阶段,并支持覆盖采购申请和采购订单的端到端流程分析。
为什么重要
它将采购申请与后续采购订单关联起来,支持分析申请到采购订单的转换过程,并连接P2P流程的不同阶段。
获取位置
采购订单创建后,通常可以在采购申请行表PurchReqLine中找到此信息,并通过该表关联回PurchTable。
示例
PO-000987PO-000988PO-000989
|
|||
采购到付款-采购申请活动
| 活动 | 说明 | ||
|---|---|---|---|
|
审批步骤已通过
|
审批人完成分配给自己的任务,批准该申请在当前阶段通过。申请随后进入下一步骤或最终审批。 | ||
|
为什么重要
用于衡量每个审批阶段的处理时间,并帮助定位工作流中高效的环节,也是变体分析的重要组成部分。
获取位置
当用户以“Approve”结果完成工作项时,“WorkflowTrackingStatusTable”会明确记录该事件。
采集
在工作流历史日志中识别结果为“Approve”的“WorkItemCompleted”事件。
事件类型
explicit
|
|||
|
申请已关闭
|
整个采购申请已完成,意味着所有行都已处理为采购订单或已取消。这是最终的成功结束状态。 | ||
|
为什么重要
该活动标志着申请生命周期成功完成,是衡量端到端流程总时长的最终终点。
获取位置
该状态通常通过计算或推断得出。当所有关联的“PurchReqLine”记录均达到终止状态(例如“Closed”或“Cancelled”)时,申请即达到该状态。
采集
检查PurchReqTable对应的所有子PurchReqLine记录是否均已达到最终状态,以推导该事件。
事件类型
calculated
|
|||
|
申请已创建
|
该事件表示采购申请记录最初以草稿状态创建。系统通过识别采购申请抬头的创建时间戳来捕获此事件。 | ||
|
为什么重要
作为流程起点,该活动对于衡量申请整体生命周期时长和分析每日申请处理量至关重要。
获取位置
对于每个新的采购申请ID,该活动可根据PurchReqTable中的“createdDateTime”字段推断。
采集
使用PurchReqTable中记录的创建时间戳。
事件类型
inferred
|
|||
|
申请已批准
|
申请已成功通过工作流中所有必需的审批步骤。当工作流实例以最终批准状态完成时,系统会捕获该活动。 | ||
|
为什么重要
这是一个重要里程碑,标志着审批周期结束和采购阶段开始,也是“申请审批周期时间”KPI的结束事件。
获取位置
工作流完成时,从“WorkflowTrackingStatusTable”中明确捕获该事件,同时将“PurchReqTable”中的“Status”字段更新为“Approved”。
采集
筛选状态为“Approved”的工作流“Completion”事件,或追踪PurchReqTable中的状态变化。
事件类型
explicit
|
|||
|
申请已提交审批
|
用户提交已完成的申请,正式启动审批工作流。这是由系统工作流引擎记录的明确操作。 | ||
|
为什么重要
该活动是启动审批周期的关键里程碑,也是衡量“申请审批周期时间”和“首次审批通过率”的起点。
获取位置
从“WorkflowTrackingStatusTable”或类似的工作流历史表中获取,其中会记录与采购申请关联的“Submission”事件。
采集
筛选工作流历史日志,查找与申请关联的“Submission”或“Start”事件类型。
事件类型
explicit
|
|||
|
申请已驳回
|
申请在审批工作流中被驳回,不会继续处理。这表示申请进入最终失败状态。 | ||
|
为什么重要
该结束事件对于分析整体驳回率以及了解失败申请带来的财务或运营影响至关重要。
获取位置
工作流以“Rejected”状态完成时,从“WorkflowTrackingStatusTable”中明确捕获该事件,同时更新“PurchReqTable”的状态字段。
采集
筛选状态为“Rejected”的工作流“Completion”事件,或追踪PurchReqTable中的状态变化。
事件类型
explicit
|
|||
|
采购订单已创建
|
已批准的采购申请行被转换为采购订单行,表示流程已移交采购团队。系统通过关联申请行与采购订单行来捕获该事件。 | ||
|
为什么重要
这是连接申请与后续采购流程的关键里程碑,对于衡量“申请到采购订单转换时间”KPI至关重要。
获取位置
通过查找“PurchLine”表中引用与申请案例关联的“PurchReqLine”ID的记录来推断。
采集
使用关联引用字段(例如PurchReqLineRefId)连接PurchReqLine与PurchLine。
事件类型
inferred
|
|||
|
审批步骤已开始
|
作为工作流的一部分,系统会将单个审批任务分配给用户或组。这表示特定审批人开始等待或处理该任务。 | ||
|
为什么重要
该活动对于“审批步骤瓶颈分析”至关重要,可用于衡量特定审批阶段的排队时间。
获取位置
当新的工作项创建并分配给申请对应的工作流实例时,从“WorkflowTrackingStatusTable”中捕获。
采集
在特定申请的工作流历史日志中识别“WorkItemCreated”或类似事件。
事件类型
explicit
|
|||
|
审批步骤已驳回
|
审批人驳回分配给自己的任务,通常会将申请退回发起人进行修改。这是由工作流引擎记录的明确操作。 | ||
|
为什么重要
该活动是计算“申请驳回率”和识别最常发生驳回阶段的基础,可突出需要改进的流程环节。
获取位置
当用户以“Reject”结果完成工作项时,“WorkflowTrackingStatusTable”会明确记录该事件。
采集
在工作流历史日志中识别结果为“Reject”的“WorkItemCompleted”事件。
事件类型
explicit
|
|||
|
申请已修改
|
当用户从工作流中撤回已提交的申请并进行修改时,就会发生该事件。通常通过识别撤回操作及其后的再次提交来捕获。 | ||
|
为什么重要
追踪修改对于识别返工、初始需求不清和流程低效至关重要,并直接支持“申请修改频率”仪表板。
获取位置
可通过工作流历史记录(“WorkflowTrackingStatusTable”)检测“Recall”或“RequestChange”操作来推断,也可以根据提交后“PurchReqTable”中“modifiedDateTime”字段的变化推断。
采集
检测工作流撤回事件,或比较提交事件之间的记录版本变化。
事件类型
inferred
|
|||
|
申请已撤回
|
创建人或授权用户在申请提交后将其取消。该操作会终止工作流和申请。 | ||
|
为什么重要
追踪撤回情况有助于发现需求规划问题或流程过于复杂等问题,并支持“申请撤回洞察”仪表板。
获取位置
可根据“PurchReqTable”中的状态变更为“Cancelled”,或“WorkflowTrackingStatusTable”中的“Cancel”事件推断。
采集
检测PurchReqTable中状态变更为“Cancelled”的记录,或检测工作流取消事件。
事件类型
inferred
|
|||
|
申请行已关闭
|
采购申请中的单个行项目已完成处理。通常发生在该行已完全转换为采购订单之后。 | ||
|
为什么重要
提供申请履行情况的细粒度信息,帮助识别申请是部分转换还是全部转换为采购订单。
获取位置
可根据“PurchReqLine”表中单个行的状态字段推断。显示已订购或已收货的状态通常表示该行已关闭。
采集
监控PurchReqLine表中的状态字段,查找“Invoiced”或“Closed”等终止值。
事件类型
inferred
|
|||
提取指南
立即优化采购到付款流程中的采购申请,加快审批
消除延迟,让Dynamics 365中的周期时间缩短30%。
无需信用卡,几分钟即可完成设置。