采购到付款 (P2P) — 采购申请数据模板

NetSuite
采购到付款 (P2P) — 采购申请数据模板

采购到付款 (P2P) — 采购申请数据模板

本模板为采购申请(Purchase to Pay, Requisition)流程的数据采集提供了清晰的路线图。它列出了核心属性,定义了需追踪的关键活动,并针对如何从源系统中提取信息提供了实用指南。您可以利用此资源准备事件日志,开启深度流程挖掘。
  • 建议收集的属性
  • 用于流程发现的关键跟踪活动
  • 数据提取指南
不熟悉事件日志?了解 如何创建流程挖掘事件日志.

采购到付款 - 采购申请属性

这些是建议包含在事件日志中的数据字段,用于对采购申请流程进行全面分析。
3 必填 4 推荐 12 可选
名称 描述
Event 时间
EventTime
活动发生的精确日期和时间。
描述

Event Time(即 timestamp)记录了活动发生的精确时刻。这一时间 data 对于理解请购流程的动态至关重要,包括其持续时间、event 顺序和时机。

在流程分析中,timestamp 用于计算 cycle time、活动间的等待时间以及对服务水平协议 (SLA) 的遵守情况。它们是所有基于时间的分析的基础,能够创建诸如“请购审批 Cycle Time”之类的 dashboard 以及“平均请购 Cycle Time”之类的 KPI。准确的 timestamp 对于建立可靠的流程模型至关重要。

为何重要

此 timestamp 是执行所有性能分析的基础,例如计算周转时间、识别延迟以及衡量流程效率。

获取方式

此信息捕获在系统生成的字段(如“创建日期”)中,或记录在每笔交易的“系统附注”或工作流执行日志的时间戳中。

示例
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
活动名称
ActivityName
采购申请生命周期中发生的特定业务事件或任务的名称。
描述

“活动名称”描述申请流程中一个明确的步骤,例如“申请已创建”、“审批步骤已通过”或“采购订单已创建”。这些活动是流程图的构建模块,代表了正在进行的工作。\n\n分析这些活动可以实现流程流向的可视化、识别瓶颈,并测量在不同阶段花费的时间。特定采购申请 ID 的活动序列定义了其历程,随后可将其与标准程序进行比较,以识别偏差或低效环节。

为何重要

它定义了流程中的各个步骤,从而实现流程图的可视化、分析流程变体并识别瓶颈。

获取方式

这通常派生自交易状态、系统日志条目、工作流历史记录或 NetSuite 内自定义事件跟踪的组合。

示例
已创建招聘需求审批步骤已通过申请已修改采购订单已创建
采购请购ID
PurchaseRequisitionId
每项采购申请的唯一标识符,作为流程分析的主要案例 ID。
描述

“采购申请 ID”是链接与特定货物或服务请求相关的所有活动和事件的核心标识符。在 NetSuite 中创建每项申请时都会分配一个唯一 ID,且在整个生命周期中保持不变。\n\n在流程挖掘中,该属性是案例关联的基础。它能够重建每项申请的端到端历程,从初始创建到所有审批步骤、修改,以及最终结果(如批准、驳回或转为采购订单)。按此 ID 分析流程对于计算生命周期时长、跟踪状态更改以及识别流程流向中的变体至关重要。

为何重要

这是追踪单个采购申请完整生命周期的核心关键,使分析流程流向和计算案例级指标成为可能。

获取方式

这是 NetSuite 中采购申请记录的内部 ID 或交易编号。通常可以在交易的“tranid”字段中找到。

示例
PR-001254PR-001255PR-001256
总金额
TotalAmount
采购申请的总金额。
描述

该属性捕获采购申请中列出的所有项目的总成本。这是一个关键的财务数据点,通常会影响流程本身,例如通过根据金额阈值触发不同的审批工作流。\n\n分析总额有助于理解支出模式和财务影响。它支持按金额筛选申请,将流程偏差与高额请求关联起来,并优先分析具有重大财务影响的案例。它是任何财务或合规相关流程分析的基础属性。

为何重要

提供财务背景,允许根据金额进行分析,金额通常决定了审批路径和业务优先级。

获取方式

这是采购申请记录上的标准字段,通常名为“总计”或类似名称。

示例
500.001250.7525000.00
申请状态
RequisitionStatus
指示采购申请在其生命周期中的当前状态。
描述

“申请状态”提供采购申请在流程中任一时间点的快照。常见状态包括“待审批”、“已完全审批”、“被驳回”和“已关闭”。\n\n该属性对于创建“申请状态与账龄”等仪表板至关重要,这类仪表板用于跟踪活跃申请及其在当前状态下停留的时间。分析状态转换是流程发现的核心部分,有助于理解理想路径和异常情况。它还用于确定案例的最终结果。

为何重要

提供案例进度的快照,以便分析待处理申请的账龄并识别案例卡滞的环节。

获取方式

这是采购申请交易表头上的“状态”或“审批状态”字段。

示例
待审批已完全通过已驳回已结案
请求人
Requester
创建并提交采购申请的员工。
描述

“申请人”是指通过创建申请启动采购流程的个人。这通常是因工作需要特定货物或服务的员工。\n\n按申请人分析数据对于识别用户行为模式至关重要。通过突出显示驳回率高或频繁修改的个人,它有助于构建如“申请人绩效与培训需求”等仪表板。这种洞察可以精准定位需要额外培训或更清晰指南的领域,从而提高初始提交质量和整体流程效率。

为何重要

识别流程发起人,这对于分析用户行为、按请购人统计的拒绝率以及识别培训需求至关重要。

获取方式

这通常是采购申请交易记录上的“员工”或“创建者”字段。

示例
约翰·史密斯Jane DoePeter Jones
部门
Department
申请或申请人所属的业务部门。
描述

“部门”属性代表与采购申请相关的组织单位,通常是申请人所属的部门。此信息提供了一种从组织角度细分和分析流程的方法。\n\n它是多项分析的关键维度,例如比较各部门的审批周期、了解支出模式或识别驳回率最高的部门。这种细分有助于管理层分配资源、量化培训需求,并为特定业务单位优化工作流。

为何重要

支持对流程 data 进行强大的细分,以便比较不同业务单元的性能、成本和合规情况。

获取方式

此信息通常与申请人的员工记录相关联,或者可以直接在采购申请的交易表头上设置。

示例
市场营销IT财务运营
供应商名称
VendorName
申请中建议或首选的供应商名称。
描述

“供应商名称”属性识别计划采购货物或服务的供应商。虽然申请是内部文件,但通常会指定首选供应商。\n\n分析该属性可以揭示与供应商管理相关的模式。它有助于跟踪哪些供应商被请求最频繁、某些供应商的申请是否面临更长的审批时间,并确保符合首选供应商协议。此信息可作为战略采购和供应商关系管理的宝贵参考。

为何重要

有助于按供应商分析采购模式,确保符合首选供应商名单,并识别特定供应商的流程差异。

获取方式

这可以是表头级的“供应商”字段,也可以在采购申请记录的行项目中指定。

示例
Dell Inc.Staples麦肯锡公司
最后数据更新
LastDataUpdate
指示数据上次从源系统提取或刷新的时间戳。
描述

该属性记录最近一次从 NetSuite 提取数据的日期和时间。它是任何流程挖掘仪表板或分析的关键元数据。\n\n此时间戳提供了数据新鲜度的背景,使用户能够了解其查看的是实时信息还是特定时间点的快照。它对于数据验证以及向利益相关者传达流程分析洞察的及时性至关重要。

为何重要

告知用户数据的及时性,确保其了解流程洞察的实时程度。

获取方式

此时间戳在数据提取、转换与加载(ETL)过程中生成并添加。

示例
2024-05-21T08:00:00Z2024-05-20T08:00:00Z
周期时间
CycleTime
从创建到申请最终解决所经过的总时长。
描述

Cycle Time 是一个计算指标,用于衡量单个 case 请购流程的总持续时间。它通常计算为第一个活动(例如“请购单已创建”)与最后一个终端活动(例如“请购单已完全通过”或“请购单最终被拒绝”)之间的时间差。

这是衡量整体流程效率的核心 KPI。它用于计算“平均请购 Cycle Time”这一 KPI,并有助于识别趋势、异常值以及流程改进计划的影响。分析 Cycle Time 分布可以揭示那些显著拖累平均性能的长尾请购单。

为何重要

直接衡量流程的端到端效率,这是识别延迟和评估整体性能的核心指标。

获取方式

这是一个计算属性,通过每个“PurchaseRequisitionId”的最后一个事件的时间戳减去第一个事件的时间戳得出。

示例
25920060480086400
审批人
Approver
负责批准或驳回审批步骤的员工或用户。
描述

“审批人”是指在审批工作流的特定阶段被分配负责审查并处理采购申请的个人。单个申请可能有多个审批人,每个审批人对应不同的审批活动。\n\n该属性对于分析审批流程本身的绩效至关重要。它有助于构建如“审批步骤周期时间分布”等仪表板,从而精准识别个人或团队瓶颈。通过跟踪谁执行了审批,组织可以确保问责制、平衡工作负载,并识别由特定审批人引起的延迟。

为何重要

识别执行审批任务的用户,这是分析审批人绩效、工作负载及识别 bottleneck 的关键。

获取方式

此信息通常见于与审批状态更改相关的工作流执行日志或系统附注中。它也可能存储在与审批工作流相关的自定义记录字段中。

示例
Sarah Jenkins陈大卫财务审批组
审批工作流路径
ApprovalWorkflowPath
请购单所经历审批步骤序列的呈现。
描述

“审批工作流路径”是一个派生属性,它串联了给定申请的审批活动或状态序列,例如“已提交 -> 经理审批 -> 财务审批”。这为每个案例遵循的路径创建了唯一的标识。\n\n该属性是合规性检查和变体分析的基础。通过简化按精确流程流向筛选和分组案例的操作,它直接支持“不合规申请路径”和“审批工作流路径合规性”仪表板。通过将实际路径与预定义的标准路径进行比较,组织可以量化合规情况并调查偏差的根本原因。

为何重要

通过汇总每个 case 的精确审批步骤序列,实现强大的变体分析和一致性检查。

获取方式

这是一个派生属性,通过按时间顺序串联每个“PurchaseRequisitionId”的“ActivityName”值计算得出。

示例
已创建 > 已提交 > 已通过已创建 > 已提交 > 已拒绝 > 已修订 > 已提交 > 已通过已创建 > 已提交 > 已通过 > 已撤回
拒绝原因
RejectionReason
审批人在驳回申请时提供的说明。
描述

“驳回原因”是一个文本属性,审批人可以在其中说明采购申请未满足审批要求的原因。这为“审批步骤被驳回”活动提供了定性背景。\n\n此信息对于根本原因分析极具价值。它为“申请驳回率分析”等仪表板提供支持,不仅显示哪些被驳回,还显示原因。常见原因可能包括“总账科目错误”、“超出预算”或“详情不足”。分析这些原因有助于发现系统性问题、改进用户培训并优化提交指南,从而减少重做和驳回率。

为何重要

为驳回原因提供关键背景,支持根本原因分析,从而降低未来的驳回率并提高“一次性成功”的质量。

获取方式

这通常在驳回操作期间捕获在“备注”字段中,或添加到审批工作流的自定义字段中。也可以在“系统附注”中找到。

示例
超出预算供应商选择错误项目详情缺失重复请求
是否返工
IsRework
一个布尔标志,指示请购单是否经历了拒绝并重新提交的循环。
描述

“是否重做”是一个派生的布尔属性,如果采购申请在任何阶段被驳回并随后修改或重新提交审批,该属性将设为 true。它用于识别那些在标准“理想路径”之外需要额外工作和处理的案例。\n\n该属性简化了流程低效分析。它用于计算“审批驳回循环计数”KPI,并帮助量化驳回对整体流程的影响。通过筛选“是否重做”为 true 的案例,分析人员可以隔离有问题的流程变体,并调查初始驳回的根本原因,例如数据质量差或对政策理解有误。

为何重要

有助于量化返工循环的频率和影响,返工是流程低效和延迟的主要来源。

获取方式

这是一个计算属性。其逻辑是检查同一案例中是否在“审批步骤被驳回”活动之后发生了“申请提交审批”活动。

示例
truefalse
源系统
SourceSystem
标识数据的来源系统。
描述

该属性指定流程数据的来源系统,在本案例中为 NetSuite。在需要合并多个系统的数据以获得整体流程视图的环境中,它特别有用。\n\n虽然在单一系统分析中它可能看起来是静态的,但它提供了必要的背景,是数据治理和可追溯性的最佳实践。它有助于确认数据来源,并确保在分析过程中正确理解任何特定于系统的逻辑或转换。

为何重要

提供有关数据来源的关键背景,确保清晰度和妥善治理,尤其是在多系统环境中。

获取方式

这是一个静态值“NetSuite”,应在数据提取和转换过程中添加。

示例
NetSuiteNetSuite SuitePeopleNetSuite ERP
物料类别
ItemCategory
申请中请求的货物或服务的类别。
描述

“项目类别”将采购申请中的项目分为“IT 硬件”、“办公用品”或“专业服务”等逻辑组。这可以从链接到申请行项目的记录中派生。\n\n该属性支持对申请流程进行更深入、更细致的分析。它有助于回答诸如“IT 硬件的申请审批是否比办公用品的申请审批耗时更长?”之类的问题。通过按项目类别细分流程,企业可以发现特定领域的瓶颈、按类别分析支出,并相应地调整采购策略。

为何重要

支持根据所购物品进行流程分析,有助于识别特定类别的 bottleneck 或合规问题。

获取方式

此信息从采购申请行项目级别链接的“项目”记录中派生。类别本身可能是项目记录上的标准或自定义字段。

示例
IT硬件软件许可办公用品营销服务
紧急程度
UrgencyLevel
请购单优先级的分类,例如“标准”或“紧急”。
描述

“紧急程度”是一个分类属性,用于反映采购申请的业务优先级。这允许员工标记出因业务紧迫而需要加急处理的申请。

该属性专为“紧急请求处理性能”仪表板和“紧急申请处理时间”KPI 而设计。通过基于此属性筛选流程数据,分析人员可以对比紧急请求与标准请求的周转时间和流程路径,从而判断加急处理是否奏效,或是否存在导致延迟的瓶颈。

为何重要

允许对高优先级与标准申请的流程性能进行比较,确保高效满足关键需求。

获取方式

这通常是采购申请表单上的一个自定义交易主体字段。

示例
货币
Currency
申请总额的币种代码。
描述

“币种”属性指定申请财务金额所使用的货币单位,如美元 (USD)、欧元 (EUR) 或英镑 (GBP)。这对于涉及多种货币运营的跨国组织尤为重要。\n\n该字段确保财务数据得到正确解读。在流程挖掘中,它支持货币价值的妥善汇总和比较,既可以将所有金额转换为单一基准货币,也可以按币种进行细分分析。这能防止财务报告不准确,并确保全球业务运营的清晰透明。

为何重要

对于跨国组织的精确财务分析至关重要,确保金额价值得到正确解读和汇总。

获取方式

这是采购申请交易记录上的标准“币种”字段,在多币种 NetSuite 实例中尤为常见。

示例
美元EURGBP
采购订单ID
PurchaseOrderId
从获批申请生成的采购订单标识符。
描述

“采购订单 ID”是从获批申请生成的采购订单的唯一标识符。该属性作为申请流程与后续采购活动之间的关键纽带。\n\n在流程分析中,此链接对于端到端 P2P 分析至关重要。通过测量申请获批到创建 PO 之间的时间,它可以计算“PO 创建提前期”KPI。它还有助于计算“申请转 PO 转化率”,从而洞察申请转化为实际订单的效率。

为何重要

将申请链接到生成的采购订单,从而能够测量 PO 创建提前期并进行端到端流程分析。

获取方式

这可以在采购申请记录上找到,通常在相关记录子页签中,或在采购订单本身的“创建自”链接中。

示例
PO-005432PO-005433PO-005434
必填 推荐 可选

采购到付款 - 采购申请活动

这些是您事件日志中需要捕获的关键流程步骤和里程碑,以便准确进行流程发现和瓶颈识别。
5 推荐 6 可选
活动 描述
已创建招聘需求
用户通过创建并保存新的请购单记录来启动采购流程。这是请购生命周期中的第一个 event,在 NetSuite 中首次保存交易记录时被捕捉。
为何重要

此活动标志着针对特定需求的采购流程正式启动。分析从创建到提交的时间,可以揭示数据录入或初始请求制定的延迟。

获取方式

此事件根据采购申请交易记录的创建日期时间戳捕获。可以在记录的主表头或记录“创建”操作的“系统附注”子页签中找到。

捕获

使用采购申请记录中的“创建日期”字段。

事件类型 explicit
申请最终被驳回
采购申请已被最终驳回,将不再进行处理。当申请的最终“审批状态”更新为“被驳回”时,推断发生此事件。
为何重要

此活动是未获批准申请的关键终点。了解申请最终被驳回的原因和时间,可以洞察政策合规性和预算问题。

获取方式

通过识别“系统附注”子页签中“审批状态”字段设定为最终“被驳回”状态的时间戳推断得出。

捕获

“审批状态”变更为“已拒绝”时的 Timestamp。

事件类型 inferred
申请已关闭
申请已正式关闭,表示不再对其进行任何操作。在申请上的所有数量都已通过链接的采购订单完成订购后,这通常会自动发生。
为何重要

此活动标志着申请生命周期的最终结束。它确认业务需求已得到处理且记录已定稿。

获取方式

通过识别“系统附注”子页签中行级或表头级“状态”字段更新为“已关闭”的时间戳推断得出。

捕获

“状态”字段变更为“已关闭”时的 Timestamp。

事件类型 inferred
申请已完全通过审批
采购申请成功完成了审批工作流中所有要求的步骤。当记录的最终“审批状态”更改为“已批准”时,推断发生此事件。
为何重要

这是一个重要的里程碑,表示申请已准备好转为采购订单。它标志着审批循环的结束和采购履行阶段的开始。

获取方式

通过识别“系统附注”子页签中“审批状态”字段设定为最终“已批准”状态的时间戳推断得出。

捕获

“审批状态”变更为“已批准”时的 Timestamp。

事件类型 inferred
采购订单已创建
根据已完全获批的请购单生成采购订单 (PO),正式向供应商承诺资金。这是一个显式 event,以创建链接回源请购单的新 PO 交易为标志。
为何重要

这是申请获批的主要结果,也是采购到付款流程中的关键交接环节。获批与创建 PO 之间的时间是衡量采购效率的关键 KPI。

获取方式

通过查找其“创建自”或类似关联字段引用了该请购 ID 的采购订单记录来识别。该 PO 的创建日期即为该活动的 timestamp。

捕获

找到“创建自”字段等于请购单 ID 的 PO,并使用该 PO 的“创建日期”。

事件类型 explicit
审批步骤已开始
申请进入审批工作流中的特定阶段,等待指定的审批人或小组处理。通常在工作流按序列将申请分配给下一位审批人时推断。
为何重要

此活动标志着每个独立审批步骤等待时间的开始。它对于精准识别审批层级中的瓶颈以及发现处理缓慢的审批人至关重要。

获取方式

通过工作流执行日志或“当前审批人”/ 工作流状态字段的更改推断。SuiteApprovals 平台负责跟踪活跃的审批步骤。

捕获

通过工作流日志或记录分配给新审批人的时间点推断。

事件类型 inferred
审批步骤已拒绝
审批人拒绝了其分配的步骤,通常会将请购单退回给请购人进行更正。此操作由 SuiteApprovals workflow 引擎显式记录。
为何重要

此事件是重做和流程低效的关键指标。分析驳回点有助于识别失败的常见原因,例如违反政策或数据错误。

获取方式

从 SuiteApprovals 日志或 System Notes 子选项卡中获取,记录了拒绝操作、执行拒绝的用户以及 timestamp。

捕获

在 SuiteApprovals 日志或 System Notes 中识别拒绝操作。

事件类型 explicit
审批步骤已通过
授权用户批准其在 workflow 中分配的步骤,使请购单更接近最终审批。NetSuite 的 SuiteApprovals 平台会显式记录此操作以及用户和 timestamp 详情。
为何重要

此活动代表审批链中的积极进展。分析审批步骤之间的时间有助于了解工作流和单个审批人的效率。

获取方式

从 SuiteApprovals 日志或 System Notes 子选项卡中获取,记录了审批操作、审批人以及该 event 的精确 timestamp。

捕获

在 SuiteApprovals 日志或 System Notes 中识别审批操作。

事件类型 explicit
申请已修改
用户在请购单创建后对其任何字段进行修改,通常是为了响应拒绝或需求变更。此 event 直接从 NetSuite 的审计追踪功能中获取。
为何重要

追踪修改记录对于识别返工循环和数据质量问题至关重要。频繁的修改通常意味着初始需求不明,或者申请人需要进一步的培训。

获取方式

从请购单记录上的 System Notes 子选项卡中获取。相关字段上每个“类型”为“更改”或“编辑”的条目都代表一次修订。

捕获

为“系统附注”日志中每个“更改”类型的条目记录一个事件。

事件类型 explicit
申请已提交审批
申请人正式将完成的申请提交至指定的审批工作流。这通常通过申请记录的状态更改来推断,例如从“草稿”或“待提交”更改为“待审批”。
为何重要

此活动触发审批循环,是测量审批提前期的关键起点。它有助于识别在正式审批流程开始前申请等待了多长时间。

获取方式

通过识别“系统附注”子页签中“审批状态”字段首次更改为“待审批”等值的时间戳推断得出。

捕获

识别“审批状态”字段首次变为“待审批”时的 timestamp。

事件类型 inferred
申请已撤回
原始申请人或管理员在申请被完全批准或转为 PO 之前将其取消。通常通过状态更改为“已取消”或“已撤回”来推断。
为何重要

此活动代表由申请人发起的流程异常或终止。分析撤回情况可以突显业务需求的变化或不再有效的申请。

获取方式

通过跟踪“系统附注”子页签中“审批状态”字段更新为“已取消”或自定义撤回状态的时间戳推断得出。

捕获

“审批状态”变更为“已取消”或“已撤回”时的 Timestamp。

事件类型 inferred
推荐 可选

提取指南

如何从 NetSuite 获取您的数据