您的采购到付款流程:采购订单数据模板
您的采购到付款流程:采购订单数据模板
- 推荐的数据属性
- 关键流程活动
- Coupa数据提取步骤
采购到付款-采购订单属性
| 名称 | 说明 | ||
|---|---|---|---|
|
开始时间
EventTime
|
表示活动或事件发生时间的精确时间戳。 | ||
|
说明
事件时间记录具体活动执行的日期和时间。流程中的每个活动都有对应的时间戳,用于标记其发生时间。 此属性对于流程挖掘中的所有时间分析都至关重要。它用于计算活动之间的周期时间、衡量流程持续时间并识别延迟。例如,“Purchase Order Drafted”和“Purchase Order Approved”时间戳之间的差值,可用于计算采购订单审批周期时间KPI。
为什么重要
它为每个事件提供时间背景,是计算周期时间、分析绩效和发现瓶颈的基础。
获取位置
位于Coupa的事件日志或审计轨迹中,通常与采购订单的每次状态变化或操作相关联。
示例
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
活动
ActivityName
|
采购订单生命周期中某一时间点发生的具体事件或任务名称。 | ||
|
说明
活动名称描述采购到付款流程中的单个步骤,例如“采购订单已批准”或“收货已过账”。这些活动按顺序组成每个采购订单的流程。 该属性是流程挖掘的基础,用于构建流程图、发现流程变体以及分析事件的频率和顺序。它有助于识别瓶颈、返工循环以及偏离标准流程的情况。例如,分析“采购订单已更改”活动的顺序,可以发现订单准确性方面的低效问题。
为什么重要
它定义流程中的各个步骤,用于展示流程、识别瓶颈、返工和偏差。
获取位置
根据Coupa中与Purchase Order对象关联的事件日志、审计轨迹或状态变更记录获取。
示例
采购申请已批准采购订单已提交收货已过账已收到采购订单发票
|
|||
|
采购订单
PurchaseOrderNumber
|
采购订单的唯一标识符,作为流程的主要案例标识。 | ||
|
说明
采购订单编号是连接从初始申请到最终确认商品或服务收货的所有活动的核心案例标识。每个唯一的采购订单编号代表采购流程的一个实例。 在流程挖掘分析中,此属性对于追踪每笔采购的端到端过程至关重要。它使分析人员能够可视化流程图、识别变体,并计算案例级KPI,例如订单总周期时间。所有事件及相关数据都会归集到此标识下,从而构建统一的流程视图。
为什么重要
它对于跟踪每笔采购的完整生命周期至关重要,可重建单个流程实例以进行详细分析。
获取位置
这是Coupa中Purchase Order对象的标准主键字段。
示例
PO-2023-00123PO-2023-00456PO-2023-00789
|
|||
|
上次数据更新
LastDataUpdate
|
表示流程数据上次刷新的时间戳。 | ||
|
说明
此属性记录数据集上次从源系统更新的时间。它是适用于整个数据集而非单个事件的元数据字段。 在任何分析仪表板中,此时间戳都能帮助用户了解当前查看数据的新鲜度。它让用户确信洞察基于近期信息,也有助于管理用户对数据时效性的预期。该信息通常会在仪表板中突出显示。
为什么重要
告知用户数据的时效性,帮助其了解流程分析和KPI反映的是多新的数据。
获取位置
此时间戳由数据提取和加载(ETL)管道在运行时生成并存储。
示例
2023-11-01T05:00:00Z
|
|||
|
源系统
SourceSystem
|
提取流程数据的系统。 | ||
|
说明
此属性用于标识记录事件数据的源信息系统。对于此流程,该值通常固定为“Coupa”。 在企业数据可能来自多个系统的环境中,例如采购数据来自Coupa、发票数据来自其他ERP,此属性有助于区分数据来源。它确保数据血缘清晰,也可用于筛选特定系统的流程视图。
为什么重要
它提供有关数据来源的重要背景信息,确保数据可追溯并支持适当的数据治理,尤其适用于多系统环境。
获取位置
这是一个静态值,通常在数据提取和转换过程中添加,用于标记数据集。
示例
Coupa
|
|||
|
供应商名称
VendorName
|
提供所采购商品或服务的供应商名称。 | ||
|
说明
供应商名称用于标识采购订单中提供商品的外部合作方,是采购分析的基础信息。 按供应商分析流程绩效对于供应商关系管理至关重要。通过该分析,您可以评估“供应商交付周期绩效”、识别“收货流程延迟”,并通过“商品退货率”评估供应商质量。该属性也是计算“非首选供应商支出占比”KPI的关键数据。
为什么重要
支持供应商绩效分析,帮助优化供应商选择、协商更优条款,并识别绩效较高或较低的供应商。
获取位置
Coupa采购订单抬头中的标准字段,与供应商主数据关联。
示例
Global Office SuppliesTech Solutions Inc.Advanced Industrial PartsCreative Marketing Agency
|
|||
|
用户
User
|
执行活动人员的用户ID或姓名,例如审批人或申请人。 | ||
|
说明
此属性用于标识负责执行流程中特定事件的人员,可能是起草订单的员工、审批订单的经理,或完成收货过账的专员。 按用户分析绩效有助于识别培训需求、高绩效人员和工作量分配情况。例如,“采购订单审批周期时间绩效”仪表板使用此属性按具体审批人拆分审批时间,帮助发现可能成为流程瓶颈的人员。
为什么重要
它支持按个人或角色分析流程绩效,有助于识别瓶颈、培训机会和资源分配问题。
获取位置
与Coupa采购订单审计轨迹或历史日志中的每个事件相关联。“Created By”“Approved By”或“Updated By”等字段是常见来源。
示例
j.doea.smithm.jones
|
|||
|
订单总金额
TotalOrderAmount
|
采购订单的货币总价值。 | ||
|
说明
该属性表示采购订单中所有指定商品和服务的总成本,并以特定货币计价。它是适用于整个订单的案例级属性。 这项财务数据对于支出分析和流程改进优先级排序至关重要。高价值订单可能需要更严格的审核或不同的审批路径。该属性直接用于“按采购类别进行支出分析”仪表板,也是计算“非首选供应商支出占比”KPI的组成数据。
为什么重要
为每笔采购提供财务背景,支持支出分析、高价值订单优先级排序和财务影响评估。
获取位置
在Coupa采购订单抬头中提供,通常显示为“Total”或“Grand Total”。
示例
1500.00250.7512500.50
|
|||
|
部门
Department
|
承担采购订单费用的业务部门或成本中心。 | ||
|
说明
部门属性用于指定发起采购或承担采购成本的组织单位,通常与采购订单行项目中的申请人或成本中心信息相关联。 此维度对于细分流程分析和KPI至关重要。管理者可以据此比较组织不同部门的流程效率、合规性和支出模式。例如,“按采购类别分析支出”仪表板使用Department展示不同业务单元如何使用预算。
为什么重要
它支持按不同业务单元筛选和比较流程及支出分析,从而发现效率和合规性方面的差异。
获取位置
在Coupa的采购订单抬头或行项目中提供,通常与成本中心或组织单元关联。
示例
市场营销信息技术运营财务
|
|||
|
采购类别
PurchaseCategory
|
所采购商品或服务的分类,例如IT硬件或专业服务。 | ||
|
说明
采购类别也称为商品类别或物料组,用于归类相似类型的采购。此类结构化数据支持系统分析支出和采购流程。 在流程挖掘中,该属性是强大的筛选和分段维度。“按采购类别进行支出分析”仪表板依靠它拆解支出模式。它还可以揭示某些类别,例如复杂服务,是否比标准办公用品具有更长的周期时间或更高的变更率。
为什么重要
支持按类别开展支出和流程分析,帮助识别采购模式、与供应商协商,并制定针对性的流程控制措施。
获取位置
通常位于Coupa采购订单行项目层级,并经常与商品代码或采购目录关联。
示例
IT硬件办公用品专业服务营销材料
|
|||
|
变更原因
ChangeReason
|
采购订单初次创建后发生变更时提供的原因。 | ||
|
说明
该属性记录采购订单被修改的理由,例如“数量已更新”或“价格修正”。用户执行“采购订单已变更”活动时,这些信息通常会记录在审计轨迹中。 了解订单变更原因是“采购订单变更分析”仪表板的关键。它有助于区分不可避免的变更,例如供应商库存问题,与可避免的变更,例如初始数据录入错误,从而指导企业提高订单准确性并降低“采购订单变更率”KPI。
为什么重要
解释采购订单变更的根本原因,支持采取针对性措施,提高首次订单准确性并减少流程返工。
获取位置
通常位于Coupa采购订单变更事件关联的审计日志或评论中。
示例
供应商更新价格交付日期已调整已更正物料编码
|
|||
|
拒绝原因
RejectionReason
|
采购申请或采购订单在审批环节被拒绝时提供的原因。 | ||
|
说明
审批人拒绝采购订单时,通常会说明拒绝原因。该属性记录这段文字说明,例如“预算代码错误”或“超出支出限额”。 分析拒绝原因可以直接了解返工和流程失败的根本原因。这些定性数据有助于识别申请流程中的常见错误,并据此开展针对性培训或系统改进,减少后续拒绝,提高一次审批通过率。
为什么重要
直接提供采购订单被拒绝原因的可执行洞察,帮助解决流程返工和延迟的根本原因。
获取位置
通常记录在Coupa审批工作流中与“采购订单已拒绝”或“采购申请已拒绝”活动关联的评论或备注字段中。
示例
重复申请预算未获批准选择的供应商不正确
|
|||
|
收货地点
ReceivingLocation
|
商品交付的实际地点,例如仓库或办公室。 | ||
|
说明
收货地点用于指定采购订单中所订商品的目的地,可以是具体的仓库、工厂或办公室地址。 该属性用于分析不同地点的物流和收货绩效。“收货流程延迟”仪表板可按此属性筛选,以判断某些地点处理到货是否较慢,从而定位特定地点的运营低效或资源限制。
为什么重要
支持按地点分析收货流程,突出仓库、工厂或办公室之间的绩效差异。
获取位置
该信息属于Coupa采购订单中的“Ship-To”地址。
示例
仓库A-芝加哥5号楼-伦敦办公室法兰克福工厂
|
|||
|
是否一次审批通过
IsFirstPassApproval
|
如果采购订单起草后未发生任何变更即获批准,则该计算标记为true。 | ||
|
说明
如果采购订单从“采购订单已起草”到“采购订单已批准”的过程中,没有出现“采购订单已变更”或“采购订单已拒绝”活动,则该布尔标记设为true。 该属性直接衡量“一次审批通过率”KPI。较高的通过率表明初始处理高效且准确。分析该标记为false的案例,有助于发现返工原因并提高采购订单的前置数据质量。
为什么重要
直接衡量初始创建和审批流程的效率,突出无需返工即可完成流转的订单数量。
获取位置
在数据转换期间,通过分析每个PurchaseOrderNumber的事件序列进行计算。
示例
truefalse
|
|||
|
是否为首选供应商
IsPreferredVendor
|
用于标识采购是否来自首选供应商或战略供应商的布尔标记。 | ||
|
说明
该标记用于识别采购订单中的供应商是否属于预先批准的战略供应商名单。通常通过将供应商名称或ID与首选供应商主列表进行比对确定。 该属性对于战略采购和支出管理至关重要。它用于计算“非首选供应商支出占比”KPI,帮助企业监控和控制非规范采购,并将支出集中到关键合作伙伴,以获得批量折扣和更优条款。
为什么重要
通过跟踪首选与非首选供应商的支出,帮助监控采购政策合规情况和战略采购目标。
获取位置
这通常不是Coupa中的标准字段,而是通过将采购订单中的供应商ID与外部首选供应商列表进行比对得出。
示例
truefalse
|
|||
|
是否准时交付
IsDeliveryOnTime
|
用于标识商品是否在要求交付日期当天或之前收货的计算标记。 | ||
|
说明
该布尔属性通过比较“收货已过账”事件的时间戳与“RequestedDeliveryDate”计算得出。当收货日期早于或等于要求日期时,标记设为true。 该标记直接支持“供应商交付日期遵循率”KPI和“交付日期偏差与退货”仪表板。它为准时绩效提供清晰的二元结果,便于聚合和可视化,从而快速识别供应商或内部收货流程的绩效问题。
为什么重要
提供清晰的二元交付绩效指标,简化准时交付KPI的计算和趋势分析。
获取位置
在数据转换期间,通过比较“RequestedDeliveryDate”与“收货已过账”活动的时间戳进行计算。
示例
truefalse
|
|||
|
是否返工
IsRework
|
用于识别采购订单是否经历过变更活动的计算标记。 | ||
|
说明
只要采购订单历史中至少包含一个“采购订单已变更”事件,该布尔标记就设为true。它是从事件日志中派生的案例级属性。 该属性简化了“采购订单变更率”等KPI的计算。您可以轻松筛选和分段数据,对比发生过返工与未发生返工的订单流程,从而量化变更对周期时间和成本的影响。它是“采购订单变更分析”仪表板的核心组成部分。
为什么重要
通过支持对至少变更过一次的所有采购订单进行筛选和聚合,简化返工分析。
获取位置
在数据转换期间,通过检查每个PurchaseOrderNumber是否存在“采购订单已变更”活动进行计算。
示例
truefalse
|
|||
|
申请人姓名
RequesterName
|
最初申请商品或服务的人员姓名。 | ||
|
说明
该属性用于识别创建采购申请并促成采购订单的员工。申请人是提出业务需求的用户,可能不同于采购员或审批人。 按申请人分析流程行为,有助于识别特定用户或部门相关的模式。“采购订单变更分析”仪表板可借此判断某些申请人的订单变更频率是否更高,这可能表明他们需要接受更好的规格要求培训。
为什么重要
帮助识别采购的业务来源,支持在申请人层面分析采购行为和准确性。
获取位置
该信息通常存储在源采购申请中,并在Coupa中传递至采购订单。
示例
Alice CooperBob DylanCharlie Parker
|
|||
|
要求交付日期
RequestedDeliveryDate
|
申请人要求商品或服务交付的日期。 | ||
|
说明
该属性是业务用户在申请流程中指定的目标交付日期,代表业务方对订单完成时间的预期。 该日期是衡量供应商和内部绩效的重要基准。通过与实际“收货已过账”日期进行比较,它可直接用于计算“供应商交付日期遵循率”KPI。“交付日期偏差与退货”仪表板可展示要求日期与实际交付日期之间的偏差,帮助管理预期并改进预测。
为什么重要
作为关键绩效基线,用于衡量供应商准时交付情况和内部收货流程效率。
获取位置
Coupa采购订单行项目中的标准字段。
示例
2023-11-152023-12-012024-01-10
|
|||
|
货币
Currency
|
采购订单中货币金额所使用的货币代码。 | ||
|
说明
该属性指定订单总金额所使用的货币,例如USD、EUR或GBP。对于全球化企业,正确解读财务数据必不可少。 对于跨国企业,不考虑货币因素的支出分析可能产生误导。该属性支持正确的货币换算和仪表板中的一致财务报告,确保各项金额在统一口径下进行比较。
为什么重要
为货币换算提供必要信息,确保跨国场景下财务分析和报告的准确性。
获取位置
Coupa采购订单抬头中的标准字段。
示例
USDEURGBPJPY
|
|||
|
采购申请编号
PurchaseRequisitionNumber
|
采购订单之前的采购申请的唯一标识符。 | ||
|
说明
该属性将采购订单关联回其源采购申请。一份采购申请可能对应一个或多个采购订单。 这种关联对于分析完整的“申请到订单”周期时间至关重要。通过连接采购申请创建事件与采购订单创建及发送事件,企业可以衡量从申请到履行的整个采购启动流程效率。
为什么重要
连接流程中的申请和下单阶段,支持分析申请到订单的周期时间和转化率。
获取位置
通常是Coupa采购订单行项目中的引用字段,用于关联源采购申请。
示例
PR-2023-00098PR-2023-00152PR-2023-00341
|
|||
采购到付款-采购订单活动
| 活动 | 说明 | ||
|---|---|---|---|
|
收货已过账
|
这是对货物已接收、检验并验收的正式确认。此事件会更新库存记录,并表示供应商已履行本次交付义务。 | ||
|
为什么重要
此关键里程碑标志着供应商交付周期结束,可用于衡量交付日期达成情况。收货过账延迟会掩盖实际库存水平。
获取位置
这是Coupa中的核心交易,记录在Receipt对象中。当收货状态变为“Posted”或“Received”时,系统会记录该事件。
采集
收货交易在系统中完成后记录。
事件类型
explicit
|
|||
|
采购申请已创建
|
此活动表示采购申请已创建。采购申请是采购订单之前,对商品或服务提出的正式请求。在Coupa中,当用户保存并提交新的申请单时,系统会记录这一明确事件。 | ||
|
为什么重要
作为采购流程通常的起点,此活动对于衡量完整的申请到下单周期时间、了解上游流程效率至关重要。
获取位置
此事件对应Coupa中Purchase Requisitions对象或表中的创建记录。时间戳可在“created_at”或同等的系统生成创建日期字段中找到。
采集
创建新的申请记录后直接记录。
事件类型
explicit
|
|||
|
采购订单已关闭
|
这是最后一个活动,表示采购订单已完成。当采购订单已全部收货、全部开票且不再预期发生其他交易时,即视为关闭。 | ||
|
为什么重要
此活动正式结束采购订单生命周期。分析关闭所需时间,有助于发现最终对账和记录维护中的低效环节。
获取位置
根据Purchase Order对象的状态变为“Closed”推断。Coupa通常会根据收货和开票容差等业务规则自动设置此状态。
采集
根据状态变为“Closed”的时间戳推导。
事件类型
inferred
|
|||
|
采购订单已发送给供应商
|
此活动表示已批准的采购订单正式发送给供应商,例如通过电子邮件或Coupa Supplier Portal发送。此事件将采购订单从内部单据转变为对外承诺。 | ||
|
为什么重要
这是结束内部申请到下单周期并启动供应商交付周期的关键里程碑,对于衡量内部效率和供应商绩效都十分重要。
获取位置
通常根据采购订单状态变为“Ordered”或“Sent”推断。Coupa也可能在采购订单记录中提供“last_exported_at”或“sent_to_supplier_at”等专用时间戳字段。
采集
根据状态变为“Ordered”的时间戳,或专用传输时间戳字段推导。
事件类型
inferred
|
|||
|
采购订单已取消
|
此活动表示采购订单在完成前被取消。取消可能发生在不同阶段,例如申请已不再有效,或采购订单因误操作创建。 | ||
|
为什么重要
作为另一种流程结束方式,追踪取消情况有助于了解流程中断,并识别采购申请被放弃的原因。
获取位置
根据Purchase Order对象的状态变为“Canceled”推断。使用该状态变化的时间戳作为事件时间。
采集
根据状态变为“Canceled”的时间戳推导。
事件类型
inferred
|
|||
|
采购订单已批准
|
此里程碑表示采购订单已完成内部审批工作流,获准发送给供应商。通常这是多步骤流程中的最终审批步骤。 | ||
|
为什么重要
这是计算采购订单审批周期时间和识别审批瓶颈的重要里程碑,也是关键的一致性检查节点。
获取位置
从Coupa中采购订单的审批历史日志获取。最终审批操作的时间戳即为事件时间。
采集
最终审批人完成任务后,记录在审批历史中。
事件类型
explicit
|
|||
|
供应商已确认订单
|
此事件表示供应商已收到并确认采购订单。若通过Coupa Supplier Portal(CSP)等供应商门户进行确认,系统通常会以电子方式记录。 | ||
|
为什么重要
供应商确认可确保订单正在处理,从而提高交付预测准确性并降低供应链不确定性。
获取位置
如果供应商使用Coupa Supplier Portal执行“Acknowledge”操作,采购订单中通常会提供此信息。使用该操作的时间戳。
采集
供应商在供应商门户中执行“Acknowledge”操作时记录。
事件类型
explicit
|
|||
|
已启动收货
|
此活动表示收货流程开始,例如货物实际到达后在Coupa中创建收货单据。此时货物尚未正式过账至库存,也尚未确认收货。 | ||
|
为什么重要
此事件是衡量收货处理时间KPI的起点,有助于区分货物在收货区等待的时间与系统处理所用的时间。
获取位置
可以根据状态为“Draft”或“Pending”的收货单据创建时间戳推断。该事件发生在收货最终过账之前。
采集
根据处于未过账状态的收货记录创建时间戳推导。
事件类型
inferred
|
|||
|
已完成质量检验
|
此事件表示收到的物品已完成质量检验并通过。根据企业流程不同,这可能是收货过账后的独立步骤。 | ||
|
为什么重要
此活动对于衡量质量控制流程效率至关重要。此处的延迟可能在收货与物品可用之间形成瓶颈。
获取位置
可以记录为收货行项目的状态变化,或通过Coupa中的独立检验对象记录。是否可用取决于企业是否使用质量模块或自定义工作流。
采集
根据收货状态变化或相关检验记录中的时间戳推断。
事件类型
inferred
|
|||
|
已收到采购订单发票
|
此事件表示已收到并录入引用该采购订单的供应商发票,标志着采购到付款周期进入发票处理和付款阶段。 | ||
|
为什么重要
虽然属于应付账款流程,但将发票接收与采购订单关联起来,可以完整呈现交易生命周期,并帮助分析交付与开票之间的间隔。
获取位置
从Coupa中Invoice单据的创建时间戳获取,发票会根据对应的采购订单编号进行匹配。
采集
创建与采购订单关联的发票记录后记录。
事件类型
explicit
|
|||
|
服务确认已录入
|
对于服务类采购订单,此活动相当于收货。它确认服务已按照采购订单条款完成。 | ||
|
为什么重要
跟踪服务确认对于管理服务支出至关重要,可确保仅为已核实完成的工作付款。
获取位置
此事件根据Coupa中与采购订单关联的服务收货单或服务录入单的创建或审批记录获取。
采集
服务录入单创建并审批后记录。
事件类型
explicit
|
|||
|
货物已退回
|
此前已收货的商品退回供应商时,会记录此活动。通常原因包括质量问题、货物损坏或发错货。 | ||
|
为什么重要
跟踪退货对于计算退货率、识别供应商质量或订单准确性问题至关重要。较高的退货率通常意味着流程存在高成本的失误。
获取位置
根据Coupa中的“Return to Supplier”交易或负数收货交易获取。该交易的时间戳即为事件时间。
采集
创建与原采购订单或收货记录关联的退货交易时记录。
事件类型
explicit
|
|||
|
采购申请已批准
|
采购申请在转换为采购订单前需要经过审批工作流。此事件表示申请已完成最终审批,可以进入下单环节。 | ||
|
为什么重要
跟踪申请审批有助于识别下单前阶段的瓶颈。此处的延迟会直接影响采购订单的签发速度。
获取位置
通常从Coupa中申请对象的审批历史记录获取。最终审批操作会对应一个时间戳和用户。
采集
最终审批人执行操作后,记录在审批历史中。
事件类型
explicit
|
|||
|
采购订单已变更
|
此事件表示采购订单初次起草后发生的任何修改。在Coupa中,变更通常通过采购订单单据的版本管理进行跟踪。 | ||
|
为什么重要
跟踪变更对于采购订单变更率和不合规采购订单率等KPI至关重要。频繁变更通常表明流程不稳定或初始申请不准确。
获取位置
可以通过跟踪采购订单的不同版本来推断。每个大于首个版本号的新版本都表示发生了变更,新版本的创建日期即为事件时间戳。
采集
根据新采购订单版本的创建时间戳推断。
事件类型
inferred
|
|||
|
采购订单已拒绝
|
审批人在审批工作流中拒绝采购订单时,会发生此活动。随后,采购订单通常会退回创建人进行修改或取消。 | ||
|
为什么重要
分析拒绝情况有助于发现数据质量问题、政策违规或培训不足,并揭示导致流程显著延迟的返工循环。
获取位置
这是Coupa中采购订单审批历史日志记录的明确事件。日志会显示带有相应时间戳的“Reject”操作。
采集
以“Reject”状态记录在审批历史中。
事件类型
explicit
|
|||
|
采购订单已提交
|
采购订单起草后,会正式提交至审批工作流。这是一个独立的用户操作,会将采购订单从草稿状态转为待审批状态。 | ||
|
为什么重要
此事件将起草时间与采购订单实际进入待审批状态的时间区分开来,从而更清晰地反映用户行为和流程交接。
获取位置
根据Purchase Order对象的状态变化推断,例如从“draft”变为“pending approval”。使用该状态变化的时间戳。
采集
根据状态变为“pending approval”的时间戳推导。
事件类型
inferred
|
|||
|
采购订单已起草
|
此事件表示系统中首次创建采购订单单据,通常源自已批准的采购申请。在此阶段,采购订单仍是内部草稿,尚未提交审批或发送给供应商。 | ||
|
为什么重要
此活动是衡量采购订单审批周期时间KPI的起点,也是采购订单自身生命周期中的第一个正式步骤。
获取位置
此事件对应Coupa中采购订单记录的创建时间戳,通常位于“created_at”等字段中。
采集
从系统生成的采购订单记录创建时间戳中获取。
事件类型
explicit
|
|||
提取指南
优化P2P采购订单,立即提升效率
将P2P周期时间缩短30%,快速看到成效。
无需信用卡,几分钟即可完成设置。