数据模板:采购到付款 - 采购订单
您的采购到付款-采购订单数据模板
- 全面采集数据的推荐属性
- 需要跟踪和分析的关键流程活动
- Oracle Fusion Financials 分步抽取指南
采购到付款 - 采购订单属性
| 名称 | 描述 | ||
|---|---|---|---|
|
开始时间
EventTime
|
指示特定活动或事件发生时间的时间戳。 | ||
|
描述
此属性记录流程中每个活动发生的精确日期和时间,是按时间顺序排列事件及开展所有基于时间分析的基础。 在流程挖掘中,开始时间用于构建事件日志(Event Log)、计算活动间的周期时长、衡量等待时间,并分析不同时间段的流程表现。它是与周期时长和绩效相关仪表板的核心字段。
为何重要
此时间戳 (timestamp) 对于正确地排序事件 (events) 和计算所有基于持续时间的指标 (metrics),例如周期时间 (cycle times) 和瓶颈 (bottlenecks),至关重要。
获取方式
时间戳 (Timestamp) 字段,例如来自PO_HEADERS_ALL、PO_ACTION_HISTORY和RCV_SHIPMENT_LINES等表中的CREATION_DATE和LAST_UPDATE_DATE。
示例
2023-04-15T10:05:00Z2023-04-16T14:30:00Z2023-05-01T09:00:00Z
|
|||
|
活动
ActivityName
|
发生在采购订单生命周期中的具体业务事件或步骤名称。 | ||
|
描述
此属性描述流程中的具体任务或状态变化,如“创建采购订单”或“收货”。这些活动构成流程中的一系列事件。 分析这些活动的先后顺序与时间点是流程挖掘的核心。它有助于可视化流程图、定位瓶颈、发现偏离标准流程的行为,并衡量特定步骤的持续时间。
为何重要
活动是流程图的基本组成部分。跟踪活动有助于可视化并分析流程流转、瓶颈和偏差。
获取方式
来自 PO_HEADERS_ALL、PO_ACTION_HISTORY 等表的状态变更,或来自用于收货的 RCV_TRANSACTIONS 等交易表。
示例
采购订单已创建采购订单已批准已收货
|
|||
|
采购订单
PurchaseOrder
|
采购订单单据的唯一标识,用作跟踪采购生命周期的主实例ID。 | ||
|
描述
采购订单编号是贯穿从创建到最终关闭、连接所有相关活动的核心标识,便于对单个采购案例进行端到端分析。 在流程挖掘中,每个唯一的采购订单编号代表一个流程实例。按该标识汇总分析数据,有助于理解单个订单的流程差异、周期时长和合规情况。
为何重要
这是将所有相关事件 (events) 连接起来的核心案例ID (Case ID),能够重构和分析整个采购订单生命周期 (Purchase Order lifecycle)。
获取方式
Oracle Fusion Cloud SCM采购模块,表PO_HEADERS_ALL,字段SEGMENT1。
示例
100234510023461002347
|
|||
|
PO总金额
PurchaseOrderTotalAmount
|
采购订单的总金额。 | ||
|
描述
此属性表示采购订单中所有行项目按指定币种计价的总金额,是衡量流程中交易规模的核心财务指标。 分析PO总金额有助于确定改进优先级。例如,高金额订单可能需要更严格的审批路径。它也支持财务影响评估,如量化频繁被修改或延迟的PO所对应的金额。
为何重要
为流程提供财务背景,可按金额维度开展分析,例如聚焦高金额订单,或评估延误对财务的影响。
获取方式
针对指定的 PO 头,通过汇总 PO_LINES_ALL 的金额计算;如有头级总额,则直接取用。
示例
5250.00120000.50750.99
|
|||
|
供应商名称
VendorName
|
提供所购货物或服务的供应商名称。 | ||
|
描述
此属性用于标识采购订单(PO)的外部供应商,是与PO抬头关联的关键主数据。 供应商分析是P2P流程挖掘的核心环节。通过按供应商筛选或细分,可评估“供应商交付表现”,对比准时交付率,并查看“退货率”,从而识别表现好或欠佳的供应商。这些数据对供应商关系管理和战略寻源至关重要。
为何重要
供应商绩效分析的关键,可用于对比各供应商的交付时效、退货率与整体可靠性。
获取方式
从PO_HEADERS_ALL.VENDOR_ID关联到POZ_SUPPLIERS.VENDOR_NAME。
示例
全球办公用品Tech Solutions Inc.Advanced Logistics Co.
|
|||
|
审批人姓名
ApproverName
|
对采购订单执行批准或拒绝操作的用户姓名。 | ||
|
描述
此属性用于标识工作流中负责某个审批环节的个人。该信息通常存放在与采购订单关联的操作历史或工作流日志表中。 按审批人维度分析数据,是“PO审批周期分析”和“审批资源工作量”仪表板的核心。这有助于识别成为瓶颈的审批人或审批组,客观评估工作量,并挖掘可委派或流程再设计的机会。
为何重要
标识审批链中的人员,可按审批人分析审批瓶颈、工作负载与审批周期。
获取方式
执行该操作的用户,来源于PO_ACTION_HISTORY.ACTION_PERFORMED_BY,并关联用户表以获取全名。
示例
susan.managerdavid.directoremily.finance
|
|||
|
客户要求交货日期
RequestedDeliveryDate
|
申请方期望货物或服务交付的日期。 | ||
|
描述
该日期填在采购订单行上,用于向供应商传达期望的交付时间,是衡量准时交付表现的基准。 此属性对计算“准时交付率”KPI至关重要。将实际收货日期与要求交期进行对比,企业即可量化并跟踪供应商可靠性,并识别供应链中的系统性延误。
为何重要
作为衡量准时交付表现的基线,是评估供应商可靠性与供应链效率的关键KPI。
获取方式
位于行位置层级:表PO_LINE_LOCATIONS_ALL,字段NEED_BY_DATE。
示例
2023-05-202023-06-152023-07-01
|
|||
|
用户
UserName
|
执行该活动的人员的用户 ID 或姓名。 | ||
|
描述
此属性用于标识对某个事件负责的员工或系统用户,例如创建申请、批准PO或进行收货过账。该信息通常来自“Created By”或“Last Updated By”等字段。 按用户维度分析流程,有助于了解工作量分布、个人绩效,并识别培训需求。这也是“审批资源工作量”仪表板以及用户操作合规性调查的基础。
为何重要
将用户操作归属到具体个人,便于进行工作量分析、绩效评估,并识别培训机会。
获取方式
根据PO_HEADERS_ALL、PO_ACTION_HISTORY等表中的CREATED_BY、LAST_UPDATED_BY等字段的ID,与用户表进行关联。
示例
john.doejane.smithsystem.batch
|
|||
|
结束时间
EndTime
|
某项活动完成时的时间。对于原子事件,通常与开始时间相同。 | ||
|
描述
对于有持续时长的活动,该时间标记完成时刻;对于瞬时事件,通常与 Start Time 相同。它是计算单个活动处理时长的关键。 区分 End Time 可更精确地分析活动执行时长,并将其与活动间的等待时间区分开来,从而分辨有效工作时间与空闲时间,支持资源负载与效率分析。
为何重要
支持精确计算活动处理时间,这是分析资源效率、识别耗时任务的关键。
获取方式
对于原子事件,其值可与开始时间相同,或由后续事件的时间戳推导。部分活动可能存在单独的完成时间戳。
示例
2023-04-15T10:05:00Z2023-04-16T14:45:00Z2023-05-01T09:15:00Z
|
|||
|
部门
DepartmentName
|
发起或负责该采购订单的部门名称。 | ||
|
描述
此属性用于标识与采购相关的组织单元,如“财务”“IT”“制造”,常用于成本归集与组织维度报表。 在流程挖掘中,按部门切分流程至关重要:便于对比绩效、定位部门特有的瓶颈,并理解组织内执行差异。它直接支撑“PO审批周期分析”“采购订单变更趋势”等仪表板。
为何重要
支持按业务单元筛选并比较流程绩效,发现各部门特有的问题或最佳实践。
获取方式
源自 PO_DISTRIBUTIONS_ALL 等表中的成本中心信息,并关联至部门主数据。
示例
IT运维市场营销研发
|
|||
|
PO状态
PurchaseOrderStatus
|
采购订单(PO)单据的当前状态。 | ||
|
描述
此属性表示采购订单在其生命周期中的当前状态,如“Open”“Approved”“Finally Closed”或“Canceled”,用于快速了解PO的推进情况。 尽管流程挖掘关注活动顺序,但当前状态非常适合用于筛选流程实例。例如,只分析处于 Open 状态的PO以把握当前在途订单,或仅分析已关闭的PO以复盘已完成的流程实例。该属性也是“采购订单流程与状态”仪表板的关键输入。
为何重要
提供采购订单当前状态快照,可按在途、已完成或已取消进行筛选分析。
获取方式
Oracle Fusion Cloud SCM,表PO_HEADERS_ALL,字段AUTHORIZATION_STATUS或DOCUMENT_STATUS。
示例
OPENAPPROVEDFINALLY_CLOSEDCANCELED
|
|||
|
PO类型
PurchaseOrderType
|
采购订单类型,例如“Standard”“Blanket”或“Contract”。 | ||
|
描述
此属性依据采购目的对采购订单进行归类。不同类型的PO往往遵循不同的流程规则与生命周期。 “Standard” PO为一次性采购,“Blanket” PO为与供应商的长期协议。按PO类型分析流程能更准确地评估流程绩效;将标准PO与长期协议的周期时长直接对比会产生误导。该方式支持同类对比。
为何重要
区分不同的采购场景,便于对同类订单进行更准确的同口径流程绩效对比。
获取方式
Oracle Fusion Cloud SCM,表PO_HEADERS_ALL,字段TYPE_LOOKUP_CODE。
示例
STANDARDBLANKETCONTRACT
|
|||
|
业务单元
BusinessUnitName
|
组织内进行采购的具体业务单元。 | ||
|
描述
业务实体(Business Unit)代表企业内独立的经营主体,通常拥有各自的总账与财务报表。在 Oracle Fusion 中,它是数据隔离的主要机制。 按业务实体分析流程绩效对大型跨国企业尤为关键,可横向比较不同组织单元的采购效率、合规水平与成本,既能沉淀最佳实践,也能定位改进空间。
为何重要
对大型组织而言,用于在不同运营板块间比较流程效率与合规性,至关重要。
获取方式
业务实体信息通常位于PO抬头字段 PO_HEADERS_ALL.PRC_BU_ID,并关联到视图 FUN_ALL_BUSINESS_UNITS_V。
示例
美国业务部门EMEA VisionAPAC Services
|
|||
|
最后数据更新
LastDataUpdate
|
从源系统最后一次抽取或刷新数据的时间。 | ||
|
描述
此属性反映所分析数据的时效性,记录最近一次从 Oracle Fusion Financials 抽取数据的日期和时间。 这有助于用户判断分析与仪表板的及时性,明确洞察是否已覆盖最新交易,从而合理设定预期。
为何重要
清晰展示数据时效,帮助用户了解当前分析的及时性。
获取方式
这是一个在数据 (data) 提取、转换和加载 (ETL) 过程中生成并添加的时间戳 (timestamp)。
示例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
审批周期时间
ApprovalCycleTime
|
从采购订单创建到最终批准的时长。 | ||
|
描述
这是一个计算型持续时间指标,用于衡量单个案例中“采购订单已创建” (Purchase Order Created) 活动与“采购订单已审批” (Purchase Order Approved) 活动之间所经过的时间。 此属性直接为“平均采购订单审批周期” (Average PO Approval Cycle Time) KPI 提供数值。分析其分布有助于了解审批工作流的效率,识别异常值,并衡量旨在减少审批延迟的流程改进举措的影响。
为何重要
量化审批瓶颈,直接衡量“平均PO审批周期”KPI,并突出显示工作流中的延误。
获取方式
计算字段。'Purchase Order Approved' 与 'Purchase Order Created' 两个活动的时间戳之差。
示例
P2DPT8H30MP5DT12H
|
|||
|
审批是否合规
IsApprovalCompliant
|
用于标识采购订单在发送给供应商前是否已批准。 | ||
|
描述
这是一个计算型布尔属性,用于检查关键内部控制的遵循情况:采购订单 (Purchase Order) 必须在发送给供应商之前获得批准。如果“采购订单已审批” (Purchase Order Approved) 活动发生在“采购订单已发送给供应商” (Purchase Order Sent to Vendor) 活动之前,则该属性为True。 此属性对于“采购订单流程合规审计” (PO Process Compliance Audit) 仪表板和“采购订单审批合规率” (PO Approval Compliance Rate) KPI至关重要。它提供了一种直接的方法来识别和量化合规性违规,有助于执行采购政策并降低与未经授权支出相关的风险。
为何重要
直接衡量『采购订单审批合规率』KPI,突出在审批前即发送给供应商等关键内控违规。
获取方式
计算字段。若 'Purchase Order Approved' 的时间戳小于或等于 'Purchase Order Sent to Vendor' 的时间戳,则设为 'true'。
示例
truefalse
|
|||
|
收货地点
DeliveryLocation
|
货物的实际交付地点或地址。 | ||
|
描述
此属性为采购订单所列物品的送货地址,是关键物流信息。 在流程挖掘中,按送达地点分析可支撑“收货处理效率”仪表板,帮助识别某些仓库或站点收货更慢,从而定位特定地点的资源或流程问题。
为何重要
支持按地理位置进行绩效分析,识别收货流程中的区域或站点级瓶颈。
获取方式
从PO_LINE_LOCATIONS_ALL.SHIP_TO_LOCATION_ID关联到HR_LOCATIONS_ALL视图。
示例
主仓库-A卸货口3号楼-前台SF Office - 10th Floor
|
|||
|
是否延迟交付
IsLateDelivery
|
用于标识最终收货是否晚于要求的交货日期。 | ||
|
描述
这是一个计算得到的布尔属性:当某一PO的“Goods Received”活动的时间戳晚于其“Requested Delivery Date”属性时,其值为真(true)。 该标记是“准时交付率”KPI的基础。借助它可便捷地对逾期与准时订单进行分组分析,进一步排查延误是否与特定供应商、地点或品类相关。
为何重要
直接支撑『准时交付率』KPI,便于清晰分析供应商表现与交付可靠性。
获取方式
计算字段。若 'Goods Received' 活动的时间戳晚于 'RequestedDeliveryDate' 属性,则设为 'true'。
示例
truefalse
|
|||
|
是否返工
IsRework
|
用于标识采购订单在初次创建后是否被修改。 | ||
|
描述
这是一个计算型布尔属性,如果采购订单 (Purchase Order) 案例中包含“采购订单已更改” (Purchase Order Changed) 活动,则其值设为True。它有助于快速识别需要更正或修改的订单。 此标记简化了“采购订单修改率” (PO Modification Rate) KPI 的计算,并支持对返工订单进行轻松筛选和分析。了解返工订单的特征,例如涉及的供应商或部门,有助于查明数据不准确或需求变更的根本原因。
为何重要
直接支撑『采购订单变更率』KPI,通过标记所有发生过变更的订单,简化对流程不稳定性的分析。
获取方式
计算字段。若某个流程实例的事件日志包含活动 'Purchase Order Changed',则设为 'true',否则为 'false'。
示例
truefalse
|
|||
|
源系统
SourceSystem
|
此数据的来源系统。 | ||
|
描述
此属性用于标识数据来源,尤其适用于多系统集成环境。对于本流程,通常为“Oracle Fusion Financials”。 虽然在某一数据集中该值通常不变,但它对数据治理、故障排查与数据血缘至关重要。在多来源合并分析中,可按来源系统进行筛选或分组。
为何重要
标识数据来源,这对数据治理、业务上下文以及与其他系统的集成至关重要。
获取方式
这通常是一个在数据 (data) 提取、转换和加载 (ETL) 过程中定义并添加的常量值。
示例
Oracle Fusion FinancialsOracle Cloud SCMOracle Fusion P2P
|
|||
|
采购申请
PurchaseRequisitionNumber
|
作为该采购订单依据的前置采购申请编号。 | ||
|
描述
采购申请是用于申请采购货物或服务的内部单据。此属性将采购订单关联回其最初的申请。 纳入申请编号后,分析范围可从最初的申请开始,而非只看采购订单(PO)。这有助于分析从申请到下单的周期时长,并了解申请明细如何影响后续的采购订单流程。
为何重要
将PO与初始请购单关联,可构建从请购到付款的端到端流程视图。
获取方式
通过PO_DISTRIBUTIONS_ALL表关联(包含REQ_DISTRIBUTION_ID),可回溯到POR_REQUISITION_LINES_ALL表。
示例
PR-2023-05-001PR-2023-05-002PR-2023-05-003
|
|||
|
采购类别
PurchaseCategory
|
对采购的商品或服务进行分类,例如“IT硬件”或“办公用品”。 | ||
|
描述
此属性将采购订单中的品项按采购层级进行分类。该分类用于支出分析与供应商管理。 在流程挖掘中,按采购类别对流程分段可揭示不同的行为模式或绩效水平。例如,资本性支出的审批流程可能比日常物料更长。它也直接支撑“退货率与原因”仪表板,可分析哪些类别最常被退回。
为何重要
支持按支出类型进行流程分析,可揭示不同物料类别的流程路径、瓶颈与退货率差异。
获取方式
从PO_LINES_ALL.CATEGORY_ID关联到EGP_CATEGORIES_VL视图。
示例
IT.Hardware.LaptopsOffice.Supplies.StationeryProfessional.Services.Consulting
|
|||
采购到付款 - 采购订单活动
| 活动 | 描述 | ||
|---|---|---|---|
|
已收货
|
实物已收货、清点,并登记到对应的采购订单。这是一项会更新库存和采购订单状态的交易事件。 | ||
|
为何重要
这是一个衡量供应商准时交付绩效和总体交货期的关键里程碑。它还充当质量检查和发票匹配等后续活动的触发器。
获取方式
这是一个记录在RCV_TRANSACTIONS表中的显式事件 (explicit event)。具体交易可通过TRANSACTION_TYPE为“RECEIVE” (收货) 来识别。
捕获
使用RCV_TRANSACTIONS中TRANSACTION_TYPE为“RECEIVE” (收货) 的TRANSACTION_DATE。
事件类型
explicit
|
|||
|
采购订单已最终关闭
|
该采购订单被视为完成,表示已全部收货和/或完成开票,不再有后续活动。这是一项将采购订单设为终止状态的操作。 | ||
|
为何重要
此活动标志着采购订单生命周期成功结束。它是主要的正向终态,跟踪该状态对于衡量整体流程吞吐量与完成率至关重要。
获取方式
该事件记录在 PO_ACTION_HISTORY 表中,ACTION_CODE 为“FINALLY CLOSE”。同时 PO_HEADERS_ALL 中的PO状态会更新为“Finally Closed”。
捕获
在 PO_ACTION_HISTORY 中筛选 ACTION_CODE='FINALLY CLOSE'。
事件类型
explicit
|
|||
|
采购订单已创建
|
这是采购订单生命周期 (purchase order lifecycle) 的正式开始,此时采购订单 (PO) 文档以草稿或未完成状态生成。系统通过记录新采购订单头记录 (PO header record) 的创建时间戳 (creation timestamp) 来捕获此事件。 | ||
|
为何重要
作为 PO 流程实例的主要起始事件,该活动是所有周期时间计算的基础。它为衡量后续步骤(如审批与供应商沟通)的效率提供基线。
获取方式
这是一个基于PO_HEADERS_ALL表中指定采购订单ID (PO_HEADER_ID) 的CREATION_DATE字段的显式事件 (explicit event)。
捕获
使用PO_HEADERS_ALL表中的创建时间戳 (creation timestamp)。
事件类型
explicit
|
|||
|
采购订单已发送至供应商
|
已批准的采购订单将通过邮件或EDI等方式正式发送给供应商。此事件通常可由状态变更或PO通信记录上的时间戳推断得到。 | ||
|
为何重要
这标志着供应商交货期的开始。它是衡量供应商绩效的关键节点,涵盖从确认到最终交付的整个过程。
获取方式
可通过PO单据状态变为“Open”且通信日期被写入来推断。对应字段通常为 PO_HEADERS_ALL.communicated_date 或相关状态。
捕获
根据 PO 传送状态更新为 'Communicated' 时的时间戳进行推断。
事件类型
inferred
|
|||
|
采购订单已取消
|
该采购订单已被永久取消,不再发生后续交易。这是一项将单据置为终止状态的操作。 | ||
|
为何重要
此活动代表流程的负向终态。分析取消情形可揭示如重复下单、预算调整或项目需求变更等问题。
获取方式
该操作会以ACTION_CODE为“CANCEL”的形式记录在PO_ACTION_HISTORY表中,并相应更新PO_HEADERS_ALL中的采购订单状态。
捕获
在 PO_ACTION_HISTORY 中筛选 ACTION_CODE='CANCEL'。
事件类型
explicit
|
|||
|
采购订单已批准
|
该采购订单已获得全部必要批准,可发出给供应商。这一关键里程碑事件会在单据的操作历史中被记录。 | ||
|
为何重要
这是一个关键里程碑,它控制着采购订单 (PO) 是否可以发送给供应商。它对于衡量审批周期和确保支出政策的合规性至关重要。
获取方式
该事件记录在 PO_ACTION_HISTORY 表中,通常的 ACTION_CODE 为“APPROVE”,或当 PO_HEADERS_ALL 中的单据状态变为已批准时。
捕获
在 PO_ACTION_HISTORY 中筛选最终一次 'APPROVE' 操作。
事件类型
explicit
|
|||
|
已创建收货单
|
系统中发起收货单,为实物到货做准备。此活动标志着内部收货流程的开始。 | ||
|
为何重要
这标志着从采购到物流 (logistics) 的过渡。分析从此时点到最终收货过账的时间,有助于识别仓库或收货部门的效率低下问题。
获取方式
这是一个显式事件 (explicit event),通过RCV_SHIPMENT_HEADERS表中与采购订单关联的新记录的创建时间戳 (creation timestamp) 捕获。
捕获
使用RCV_SHIPMENT_HEADERS中相应记录的创建日期。
事件类型
explicit
|
|||
|
已执行质量检验
|
需质检的物料已完成检验,并被判定为通过或拒收。该活动发生在初次收货之后,并作为独立的交易记录。 | ||
|
为何重要
此活动对质量管理至关重要。分析检验耗时有助于精简质控流程,缩短货物可用前的等待时间。
获取方式
此活动记录在RCV_TRANSACTIONS表中。它通过在收货交易后发生的TRANSACTION_TYPE为“ACCEPT” (接受) 或“REJECT” (拒绝) 的交易来识别。
捕获
使用RCV_TRANSACTIONS中TRANSACTION_TYPE为“ACCEPT” (接受) 或“REJECT” (拒绝) 的TRANSACTION_DATE。
事件类型
explicit
|
|||
|
服务交付已确认
|
对于服务类采购订单,该活动标记服务已按约定完成。此确认通常由人工记录或通过服务录入单完成。 | ||
|
为何重要
这相当于服务的收货,是发票支付前的关键步骤。服务确认的延迟可能导致付款逾期和供应商关系紧张。
获取方式
这通常作为采购订单 (PO) 上服务行的收货记录。它可能涉及特定字段或复杂收货,以追踪服务的进度或完成情况。
捕获
识别与服务类 PO 行项目关联的收货交易(RCV_TRANSACTIONS)。
事件类型
explicit
|
|||
|
退回供应商
|
已收货的物料被退回给供应商,通常因缺陷、损坏或错发。该操作会在收货模块中以特定的退货事务记录。 | ||
|
为何重要
追踪退货对于评估供应商质量和订单准确性至关重要。供应商较高的退货率可能表明存在需要解决的系统性问题。
获取方式
这是一个记录在RCV_TRANSACTIONS表中,且TRANSACTION_TYPE为“RETURN TO VENDOR” (退货给供应商) 的显式事件 (explicit event)。
捕获
使用RCV_TRANSACTIONS中TRANSACTION_TYPE为“RETURN TO VENDOR” (退货给供应商) 的TRANSACTION_DATE。
事件类型
explicit
|
|||
|
采购申请已创建
|
此活动标志着采购申请的创建,它是在采购订单之前提出的正式货物或服务请求。在Oracle Fusion的申请头表新增记录时予以采集。 | ||
|
为何重要
分析此活动有助于理解需求发起阶段。跟踪从请购到创建采购订单的时间,可揭示将内部需求转化为可执行采购订单的潜在延迟。
获取方式
这是一个在保存新采购申请时记录的显式事件 (explicit event)。可以通过追踪POR_REQUISITION_HEADERS_ALL表中的创建时间戳 (creation timestamp) 来找到它。
捕获
该事件基于 POR_REQUISITION_HEADERS_ALL 表中记录的创建日期。
事件类型
explicit
|
|||
|
采购申请已批准
|
该采购申请已由指定审批方批准,授权采购部门创建采购订单。此事件会在系统的申请单操作历史中被记录。 | ||
|
为何重要
此里程碑标志着请求的内部审批流程的结束。此处的延迟会直接影响整个采购时间,因此监控其持续时间至关重要。
获取方式
该事件记录在请购单的操作历史中,通常通过工作流表或请购单上的特定审批状态字段进行跟踪。
捕获
在该请购单的工作流历史中记录为审批动作。
事件类型
explicit
|
|||
|
采购订单已变更
|
采购订单在首次批准后被修改,例如数量、价格或交期发生变化。Oracle Fusion会通过创建该单据的新修订版进行跟踪。 | ||
|
为何重要
PO变更代表返工,可能暴露初始下单不准确或业务需求变化。分析变更的频次与类型,有助于发现提升流程效率的机会。
获取方式
当创建新的单据修订版时会显式记录该事件,可通过 PO_HEADERS_ALL 表中 REVISION_NUM 字段递增来识别。
捕获
识别同一 PO_HEADER_ID 的 REVISION_NUM 每次递增的记录。
事件类型
explicit
|
|||
|
采购订单已拒绝
|
审批人已驳回该采购订单,并退回给创建者修改。此事件会作为显式事件记录在操作历史中,表明标准流程被打断。 | ||
|
为何重要
被拒会带来返工与延误。跟踪此活动有助于找出常见拒绝原因、培训需求或审批要求不清等问题。
获取方式
该操作会以ACTION_CODE为“REJECT”的形式记录在PO_ACTION_HISTORY表中,并关联到对应的PO_HEADER_ID。
捕获
在 PO_ACTION_HISTORY 中筛选 ACTION_CODE='REJECT'。
事件类型
explicit
|
|||
|
采购订单已提交
|
已创建的采购订单会提交到审批工作流。Oracle Fusion会记录此操作,并保存提交人和时间。 | ||
|
为何重要
此活动标志着审批周期的开始。分析从提交到批准的时间,是找出内部签核流程瓶颈的关键。
获取方式
该操作会以ACTION_CODE为“SUBMIT”的形式记录在PO_ACTION_HISTORY表中,并关联到对应的PO_HEADER_ID。
捕获
在 PO_ACTION_HISTORY 中筛选 ACTION_CODE='SUBMIT'。
事件类型
explicit
|
|||
|
采购订单已确认收悉
|
供应商已确认收到并接受采购订单条款。此事件通常由采购人员依据与供应商的沟通手动记录,或通过电子回执采集。 | ||
|
为何重要
供应商确认 (acknowledgement) 提供了订单已被接收和处理的确定性。追踪此信息有助于管理供应商沟通,并主动识别潜在的履约问题。
获取方式
这通常是通过采购订单头 (PO header) 或行上的确认状态字段 (acknowledgement status fields) 的变化来推断的,例如PO_HEADERS_ALL.acceptance_status变为“Accepted” (已接受)。
捕获
根据 PO 确认状态字段的更新进行推断。
事件类型
inferred
|
|||