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