您的采购到付款请购数据模板
您的采购到付款请购数据模板
- 建议采集的属性
- 流程发现需跟踪的关键活动
- 数据提取指南
采购到付款请购属性
| 名称 | 说明 | ||
|---|---|---|---|
|
事件时间
EventTime
|
活动发生的准确日期和时间。 | ||
|
说明
事件时间(即时间戳)记录活动发生的准确时刻。这类时间数据对于了解采购申请流程的时长、事件顺序和发生时间至关重要。 在流程分析中,时间戳用于计算周期时间、活动间等待时间,以及服务级别协议的达成情况。所有基于时间的分析都以此为基础,可用于创建“采购申请审批周期时间”等仪表板,并计算“采购申请平均周期时间”等KPI。准确的时间戳是建立可靠流程模型的关键。
重要性
此时间戳是所有绩效分析的基础,可用于计算周期时间、识别延误并衡量流程效率。
获取途径
此信息记录在系统生成的字段中,例如“创建日期”;也可从每笔交易的“系统备注”或工作流执行日志中的时间戳获取。
示例
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
活动名称
ActivityName
|
采购申请生命周期中发生的特定业务事件或任务的名称。 | ||
|
说明
活动名称用于描述采购申请流程中的具体步骤,例如“创建采购申请”“审批步骤已批准”或“创建采购订单”。这些活动构成流程图的基本要素,代表实际执行的工作。 分析这些活动有助于呈现流程路径、识别瓶颈,并衡量各阶段的耗时。某个采购申请ID对应的活动顺序构成该申请的处理路径,您可以将其与标准流程进行比较,以发现偏差或低效环节。
重要性
它定义流程中的各个步骤,可用于呈现流程图、分析流程变体并识别瓶颈。
获取途径
通常根据交易状态、系统日志记录、工作流历史记录或NetSuite中的自定义事件跟踪信息综合得出。
示例
创建采购申请审批步骤已批准修改采购申请创建采购订单
|
|||
|
采购申请ID
PurchaseRequisitionId
|
每份采购申请的唯一标识符,也是流程分析中的主要案例ID。 | ||
|
说明
采购申请ID是关联特定商品或服务申请相关活动和事件的核心标识符。每份申请在NetSuite中创建时都会获得唯一ID,并在整个生命周期内保持不变。 在流程挖掘中,此属性是关联案例的基础。它可以还原每份申请从创建、经历各审批步骤和修改,到最终获批、驳回或转换为采购订单的完整过程。按此ID分析流程,有助于计算生命周期时长、跟踪状态变化,并识别流程路径中的差异。
重要性
这是追踪单份采购申请完整生命周期的关键,可用于分析流程路径并计算案例级指标。
获取途径
这是NetSuite中采购申请记录的内部ID或交易编号,通常可在交易的“tranid”字段中找到。
示例
PR-001254PR-001255PR-001256
|
|||
|
总金额
TotalAmount
|
采购申请的货币总额。 | ||
|
说明
此属性记录采购申请中所有商品的总成本,是重要的财务数据。例如,金额达到特定门槛时,可能会触发不同的审批工作流。 分析总金额有助于了解支出模式和财务影响。您可以按金额筛选申请,分析流程偏差与高金额申请之间的关联,并优先分析财务影响较大的案例。它是财务或合规相关流程分析中的基础属性。
重要性
提供财务背景,支持按金额分析;金额通常会影响审批路径和业务优先级。
获取途径
这是采购申请记录中的标准字段,通常名为“总计”或类似名称。
示例
500.001250.7525000.00
|
|||
|
申请人
Requester
|
创建并提交采购申请的员工。 | ||
|
说明
申请人是通过创建采购申请来启动采购流程的人员,通常是因工作需要特定商品或服务的员工。 按申请人分析数据有助于识别用户行为模式。通过找出驳回率较高或频繁修改申请的人员,您可以创建“申请人绩效与培训需求”等仪表板。这些洞察有助于判断是否需要加强培训或明确指引,从而提高首次提交质量和整体流程效率。
重要性
标识流程发起人,对于分析用户行为、按申请人统计驳回率和识别培训需求至关重要。
获取途径
通常对应采购申请交易记录中的“员工”或“创建者”字段。
示例
John SmithJane DoePeter Jones
|
|||
|
部门
Department
|
采购申请或申请人所属的业务部门。 | ||
|
说明
部门属性表示与采购申请关联的组织单元,通常是申请人所属的部门。此信息可用于按组织维度细分和分析流程。 它是多种分析的重要维度,例如比较各部门的审批周期时间、了解支出模式,或识别驳回率最高的部门。通过这种细分,管理人员可以合理分配资源、制定有针对性的培训,并优化各业务单元的工作流。
重要性
支持对流程数据进行细分,以比较不同业务单元的绩效、成本和合规情况。
获取途径
此信息通常关联在申请人的员工记录中,也可以直接设置在采购申请的交易标题中。
示例
市场营销IT财务运营
|
|||
|
采购申请状态
RequisitionStatus
|
表示采购申请在生命周期中的当前状态。 | ||
|
说明
采购申请状态反映了采购申请在任意时点所处的流程阶段。常见状态包括“待审批”“已全部批准”“已驳回”和“已关闭”。 此属性对于创建“采购申请状态与处理时长”等仪表板至关重要,可用于跟踪未完成的申请及其当前状态持续时间。分析状态变化是流程发现的重要环节,有助于了解理想路径和例外情况,也可用于确定案例的最终结果。
重要性
呈现案例进度快照,支持分析处理时间过长的申请,并识别案例卡在哪个环节。
获取途径
这是采购申请交易标题中的“状态”或“审批状态”字段。
示例
待审批已全部批准已驳回已关闭
|
|||
|
上次数据更新
LastDataUpdate
|
指示上次从源系统提取或刷新的数据时间戳。 | ||
|
说明
此属性记录最近一次从NetSuite提取数据的日期和时间,是流程挖掘仪表板或分析中的重要元数据。 此时间戳可说明数据的新鲜度,帮助用户判断当前查看的是实时信息,还是某个时间点的数据快照。它对于数据验证至关重要,也有助于向相关方说明流程分析所得洞察的时效性。
重要性
向用户说明数据的时效性,帮助他们了解流程洞察反映的实际情况有多新。
获取途径
此时间戳在数据提取、转换和加载(ETL)过程中生成并添加。
示例
2024-05-21T08:00:00Z2024-05-20T08:00:00Z
|
|||
|
供应商名称
VendorName
|
请购单中建议或首选供应商的名称。 | ||
|
说明
供应商名称属性用于标识拟采购商品或服务的供应商。请购单虽是内部单据,但通常会注明首选供应商。 分析此属性有助于发现供应商管理方面的规律,例如跟踪最常被申请的供应商、了解针对特定供应商的请购单是否审批时间更长,以及检查是否遵循首选供应商协议。这些信息有助于制定战略采购方案并管理供应商关系。
重要性
按供应商分析采购规律,检查是否遵循首选供应商名单,并发现特定供应商相关的流程差异。
获取途径
此信息可以来自请购单记录抬头级别的“供应商”字段,也可以在明细行中指定。
示例
Dell Inc.StaplesMcKinsey & Company
|
|||
|
周期时间
CycleTime
|
从创建请购单到最终处理完成所经过的总时间。 | ||
|
说明
周期时间是一个计算指标,用于衡量单个案例的采购请购流程总时长。通常以第一个活动(如“请购单已创建”)与最后一个终结活动(如“请购单已完全批准”或“请购单最终被拒绝”)的时间差计算。 这是衡量整体流程效率的核心绩效指标,可用于计算“请购单平均周期时间”KPI,并帮助发现趋势、异常值及流程改进举措的影响。分析周期时间分布,可以找出显著拉低平均绩效的长周期请购单。
重要性
直接衡量流程端到端效率,是发现延误和评估整体绩效的核心指标。
获取途径
这是一个计算属性,通过计算每个“PurchaseRequisitionId”的首个事件时间戳与最后一个事件时间戳之差得出。
示例
25920060480086400
|
|||
|
审批人
Approver
|
负责批准或驳回某个审批步骤的员工或用户。 | ||
|
说明
审批人是在审批工作流的特定阶段负责审核并处理采购申请的人员。一份申请可能涉及多位审批人,分别对应不同的审批活动。 此属性对于分析审批流程绩效至关重要。您可以据此创建“审批步骤周期时间分布”等仪表板,定位个人或团队层面的瓶颈。跟踪审批执行人员有助于明确责任、平衡工作量,并识别由特定审批人造成的延误。
重要性
标识执行审批任务的用户,是分析审批人绩效、工作量和瓶颈的关键。
获取途径
此信息通常可在工作流执行日志或与审批状态变化相关的“系统备注”中找到,也可能存储在与审批工作流相关的自定义记录字段中。
示例
Sarah JenkinsDavid Chen财务审批组
|
|||
|
审批工作流路径
ApprovalWorkflowPath
|
请购单经历的审批步骤顺序。 | ||
|
说明
审批工作流路径是一个派生属性,将特定请购单的审批活动或状态按顺序串联起来,例如“已提交 -> 经理审批 -> 财务审批”。由此可为每个案例生成唯一的流程路径标识。 此属性是流程一致性检查和变体分析的基础。它支持“非合规请购路径”和“审批工作流路径合规性”等仪表板,便于按实际流程路径筛选和分组案例。将实际路径与预定义的标准路径进行比较,企业可以量化合规情况并调查偏差的根本原因。
重要性
汇总每个案例的确切审批步骤顺序,支持流程变体分析和一致性检查。
获取途径
这是一个派生属性,按时间顺序串联每个“PurchaseRequisitionId”的“ActivityName”值计算得出。
示例
已创建 > 已提交 > 已批准已创建 > 已提交 > 已拒绝 > 已修改 > 已提交 > 已批准已创建 > 已提交 > 已批准 > 已撤回
|
|||
|
币种
Currency
|
采购申请总金额所用的币种代码。 | ||
|
说明
币种属性用于指定采购申请财务金额所用的币种,例如USD、EUR或GBP。对于使用多种币种开展业务的跨国组织,这一信息尤为重要。 此字段可确保财务数据得到正确解读。在流程挖掘中,您可以将所有金额换算为同一基准币种后汇总比较,也可以按币种细分分析。这样可以避免财务报告失真,并确保全球业务数据清晰准确。
重要性
对于跨国组织的准确财务分析至关重要,可确保正确解读和汇总货币金额。
获取途径
这是采购申请交易记录中的标准“币种”字段,在支持多币种的NetSuite实例中尤为常见。
示例
USDEURGBP
|
|||
|
拒绝原因
RejectionReason
|
审批人拒绝请购单时提供的说明。 | ||
|
说明
拒绝原因是一个文本属性,审批人可在其中说明采购请购单未获批准的原因。它为“审批步骤被拒绝”活动提供了定性背景。 这些信息对根因分析很有价值。它不仅能通过“请购单拒绝率分析”等仪表板显示哪些请购单被拒绝,还能说明拒绝原因。常见原因包括“总账科目错误”“超出预算”或“信息不充分”。分析这些原因有助于发现系统性问题、改进用户培训并完善提交指南,从而减少返工和拒绝。
重要性
说明请购单被拒绝的原因,支持根因分析,帮助降低后续拒绝率并提升首次提交质量。
获取途径
此信息通常记录在拒绝操作时填写的“备注”字段中,也可能位于审批工作流中的自定义字段或系统备注中。
示例
超出预算选择了错误的供应商缺少物品明细重复申请
|
|||
|
是否返工
IsRework
|
一个布尔标记,用于指示请购单是否经历过拒绝后重新提交。 | ||
|
说明
是否返工是一个派生布尔属性。如果采购请购单曾被拒绝,之后又经过修改或重新提交审批,该属性就会设为true。它用于识别超出标准“理想路径”、需要额外处理的案例。 此属性简化了流程低效问题的分析,可用于计算“审批拒绝循环次数”KPI,并量化拒绝对整体流程的影响。筛选“是否返工”为true的案例,分析人员可以单独检查问题流程变体,并调查首次拒绝的根本原因,例如数据质量差或对政策理解有误。
重要性
帮助量化返工循环的频率和影响。返工循环是造成流程低效和延误的主要原因之一。
获取途径
这是一个计算属性。其逻辑会检查同一案例中,“请购单已提交审批”活动是否发生在“审批步骤被拒绝”活动之后。
示例
truefalse
|
|||
|
源系统
SourceSystem
|
标识数据提取自哪个源系统。 | ||
|
说明
此属性用于标明流程数据的来源系统,本例中为NetSuite。在整合多个系统的数据以全面了解流程时,这一信息尤其有用。 在单系统分析中,该值可能看似固定,但它为数据治理和追溯提供了必要背景。它有助于确认数据来源,并确保分析时正确理解系统特定的逻辑或转换。
重要性
提供有关数据来源的重要背景信息,确保信息清晰且便于治理,尤其适用于多系统环境。
获取途径
这是一个固定值“NetSuite”,应在数据提取和转换过程中添加。
示例
NetSuiteNetSuite SuitePeopleNetSuite ERP
|
|||
|
物品类别
ItemCategory
|
请购单中申请的商品或服务类别。 | ||
|
说明
物品类别用于将采购请购单中的物品划分为“IT硬件”“办公用品”或“专业服务”等类别。此信息可从与请购单关联的物品记录中获取。 此属性支持对请购流程进行更深入、细致的分析,帮助回答“IT硬件请购单是否比办公用品请购单审批时间更长?”等问题。按物品类别细分流程后,企业可以发现特定领域的瓶颈、分析各类别支出,并据此调整采购策略。
重要性
按采购内容分析流程,帮助发现特定类别的瓶颈或合规问题。
获取途径
此信息来自采购请购单明细行关联的“物品”记录。类别本身可能是物品记录中的标准字段或自定义字段。
示例
IT硬件软件许可证办公用品营销服务
|
|||
|
紧急程度
UrgencyLevel
|
请购单优先级分类,例如普通或紧急。 | ||
|
说明
紧急程度是一个分类属性,用于标示采购请购单的业务优先级。员工可据此标记因关键业务需求而需要加急处理的申请。 此属性专为“紧急申请处理绩效”仪表板和“紧急请购单处理时间”KPI设计。分析人员可按此属性筛选流程数据,比较紧急申请与普通申请的周期时间和流程路径,从而判断优先处理是否有效,或是否仍有瓶颈造成延误。
重要性
比较高优先级与普通申请的流程绩效,确保关键需求得到高效处理。
获取途径
通常是采购请购单表单上的自定义交易主体字段。
示例
高中低
|
|||
|
采购订单ID
PurchaseOrderId
|
根据已批准的采购申请创建的采购订单标识符。 | ||
|
说明
采购订单ID是已批准请购单生成的采购订单的唯一标识。此属性将请购流程与后续采购活动关联起来。 在流程分析中,这一关联对端到端采购到付款(P2P)分析至关重要。通过计算请购单获批到采购订单创建之间的时间,可得出“采购订单创建周期时间”KPI。它还可用于计算“请购单转采购订单率”,帮助了解请购单转化为可执行订单的成效。
重要性
将请购单与生成的采购订单关联,以便衡量采购订单创建周期时间并开展端到端流程分析。
获取途径
此信息通常位于采购请购单记录中,可能显示在相关记录子选项卡中,也可能通过采购订单上的“创建来源”链接查看。
示例
PO-005432PO-005433PO-005434
|
|||
采购到付款请购活动
| 活动 | 说明 | ||
|---|---|---|---|
|
关闭采购申请
|
采购申请正式关闭,表示后续无需再处理。通常在关联采购订单订购完申请中的所有数量后,系统会自动关闭申请。 | ||
|
重要性
此活动标志着采购申请生命周期正式结束,确认业务需求已得到满足,记录也已完成。
获取途径
可在“系统备注”子选项卡中查找行级或标题级“状态”字段更新为“已关闭”时的时间戳,以此推断该活动。
采集
“状态”字段变为“已关闭”时的时间戳。
事件类型
inferred
|
|||
|
创建采购申请
|
用户创建并保存新的采购申请记录,启动采购流程。这是申请生命周期中的第一个事件,在NetSuite首次保存交易记录时记录。 | ||
|
重要性
此活动标志着针对特定需求的采购流程正式开始。分析从创建到提交的时间,可以发现数据录入或初始需求拟定环节的延误。
获取途径
此事件取自采购申请交易记录的创建日期时间戳。您可以在记录的主标题区域,或记录“创建”操作的“系统备注”子选项卡中找到该信息。
采集
使用采购申请记录中的“创建日期”字段。
事件类型
explicit
|
|||
|
创建采购订单
|
根据已全部批准的申请生成采购订单(PO),正式承诺向供应商支付款项。这是一个明确事件:系统创建新的PO交易记录,并将其关联到源采购申请。 | ||
|
重要性
这是采购申请成功处理的主要结果,也是订单到付款流程中的关键交接环节。从批准到创建PO的耗时是衡量采购效率的重要KPI。
获取途径
查找“创建来源”或类似关联字段引用采购申请ID的采购订单记录。该PO的创建日期即为此活动的时间戳。
采集
查找“创建来源”字段等于采购申请ID的PO,并使用PO的“创建日期”。
事件类型
explicit
|
|||
|
采购申请最终驳回
|
采购申请被正式驳回,不再继续处理。申请的最终“审批状态”更新为“已驳回”时,可推断此事件已发生。 | ||
|
重要性
此活动是未成功申请的重要终点。了解申请最终被驳回的原因和时间,有助于发现政策合规和预算方面的问题。
获取途径
可在“系统备注”子选项卡中查找“审批状态”字段变为最终“已驳回”状态时的时间戳,以此推断该活动。
采集
“审批状态”变为“已驳回”时的时间戳。
事件类型
inferred
|
|||
|
采购申请已全部批准
|
采购申请已完成审批工作流中的所有必需步骤。记录的最终“审批状态”变为“已批准”时,可推断此事件已发生。 | ||
|
重要性
这是一个重要里程碑,表示采购申请已准备好转换为采购订单。它标志着审批周期结束,采购履行阶段开始。
获取途径
可在“系统备注”子选项卡中查找“审批状态”字段变为最终“已批准”状态时的时间戳,以此推断该活动。
采集
“审批状态”变为“已批准”时的时间戳。
事件类型
inferred
|
|||
|
修改采购申请
|
用户在采购申请创建后修改任意字段,通常是因为申请被驳回或需求发生变化。NetSuite的审计跟踪功能会直接记录此事件。 | ||
|
重要性
跟踪修改对于识别返工循环和数据质量问题至关重要。频繁修改可能表明初始需求不明确,或申请人需要接受培训。
获取途径
此信息记录在采购申请记录的“系统备注”子选项卡中。相关字段的每条“类型”为“更改”或“编辑”的记录都代表一次修改。
采集
在“系统备注”日志中,为每条“更改”类型的记录记录一个事件。
事件类型
explicit
|
|||
|
审批步骤已批准
|
获授权的用户批准其负责的工作流步骤,使采购申请向最终批准推进。NetSuite的SuiteApprovals平台会明确记录此操作及用户和时间戳信息。 | ||
|
重要性
此活动表示审批链取得进展。分析各审批步骤之间的耗时,有助于了解工作流和各审批人的效率。
获取途径
此信息取自SuiteApprovals日志或“系统备注”子选项卡,其中记录了审批操作、审批人和事件的准确时间戳。
采集
在SuiteApprovals日志或“系统备注”中查找审批操作。
事件类型
explicit
|
|||
|
审批步骤已驳回
|
审批人驳回其负责的步骤,通常会将申请退回给申请人修改。SuiteApprovals工作流引擎会明确记录此操作。 | ||
|
重要性
此事件是返工和流程低效的重要指标。分析驳回环节有助于找出常见原因,例如违反政策或数据错误。
获取途径
此信息取自SuiteApprovals日志或“系统备注”子选项卡,其中记录了驳回操作、驳回用户和时间戳。
采集
在SuiteApprovals日志或“系统备注”中查找驳回操作。
事件类型
explicit
|
|||
|
审批步骤开始
|
采购申请进入审批工作流的某个阶段,等待指定审批人或审批组处理。通常可根据工作流将申请分配给审批顺序中的下一位审批人来推断此活动。 | ||
|
重要性
此活动标志着每个审批步骤的等待时间开始。它对于定位审批层级中的瓶颈、识别审批缓慢的人员至关重要。
获取途径
可根据工作流执行日志,或“当前审批人”字段、工作流状态字段的变化推断此活动。SuiteApprovals平台会跟踪当前审批步骤。
采集
根据工作流日志,或记录被分配给新审批人的时间推断此活动。
事件类型
inferred
|
|||
|
提交采购申请以供审批
|
申请人将填写完整的申请正式提交至指定审批工作流。通常可根据申请记录的状态变化推断此活动,例如状态从“草稿”或“待提交”变为“待审批”。 | ||
|
重要性
此活动会启动审批周期,是衡量审批周期时间的重要起点。它有助于确定申请在正式进入审批流程前等待了多久。
获取途径
可在“系统备注”子选项卡中查找“审批状态”字段首次变为“待审批”等值时的时间戳,以此推断该活动。
采集
查找“审批状态”字段首次变为“待审批”时的时间戳。
事件类型
inferred
|
|||
|
撤回采购申请
|
原申请人或管理员在申请完全获批或转换为采购订单之前取消申请。通常可根据状态变为“已取消”或“已撤回”来推断此活动。 | ||
|
重要性
此活动表示申请人发起的流程出现例外或终止。分析撤回情况有助于发现业务需求变化,或不再有效的采购申请。
获取途径
可在“系统备注”子选项卡中跟踪“审批状态”字段更新为“已取消”或自定义撤回状态等值时的时间戳,以此推断该活动。
采集
“审批状态”变为“已取消”或“已撤回”时的时间戳。
事件类型
inferred
|
|||
数据提取指南
立即优化您的采购到付款请购流程!
让请购审批速度提升30%,消除瓶颈。
无需信用卡,立即开始优化。