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