您的采购到付款:采购订单数据模板
您的采购到付款:采购订单数据模板
- 全面采集数据所需的建议属性
- 需要跟踪和分析的关键流程活动
- Oracle Fusion Financials数据提取分步指南
采购到付款:采购订单属性
| 名称 | 说明 | ||
|---|---|---|---|
|
开始时间
EventTime
|
表示特定活动或事件发生时间的时间戳。 | ||
|
说明
此属性记录流程中每项活动的准确日期和时间,是按时间顺序排列事件及开展所有时间分析的基础。 在流程挖掘中,开始时间用于构建事件日志、计算活动间的周期时间、衡量等待时间,以及分析不同时段的流程绩效。它也是周期时间和绩效相关仪表板的重要数据。
重要性
此时间戳对于正确排列事件顺序,以及计算周期时间、瓶颈等所有基于时长的指标至关重要。
获取途径
各表中的时间戳字段,例如 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。 | ||
|
说明
采购订单编号是关联所有相关活动的核心标识符,涵盖从创建到最终关闭的整个过程。借助该编号,可以端到端分析单个采购案例。 在流程挖掘中,每个唯一的采购订单编号代表一个流程实例。按此标识符分组分析数据,有助于了解不同订单的流程差异、周期时间和合规情况。
重要性
这是关联所有相关事件的关键案例ID,可用于重建和分析采购订单的完整生命周期。
获取途径
Oracle Fusion Cloud SCM,采购模块,PO_HEADERS_ALL 表,SEGMENT1 列。
示例
100234510023461002347
|
|||
|
供应商名称
VendorName
|
提供所购货物或服务的供应商名称。 | ||
|
说明
此属性标识采购订单对应的外部供应商,是与采购订单抬头关联的关键主数据。 供应商分析是采购到付款流程挖掘的重要组成部分。按供应商筛选或细分数据,企业可以分析“供应商交付绩效”、比较按时交付率,并调查“货物退货率”,从而识别绩效较好或较差的供应商。这些数据对于管理供应商关系和战略寻源至关重要。
重要性
这是供应商绩效分析的基础,可用于比较不同供应商的交付时间、退货率和整体可靠性。
获取途径
通过 PO_HEADERS_ALL.VENDOR_ID 关联至 POZ_SUPPLIERS.VENDOR_NAME。
示例
Global Office SuppliesTech Solutions Inc.Advanced Logistics Co.
|
|||
|
审批人姓名
ApproverName
|
对采购订单执行批准或拒绝操作的用户姓名。 | ||
|
说明
此属性记录工作流审批步骤的负责人,通常存储在与采购订单关联的操作历史记录表或工作流日志表中。 按审批人分析数据,是“采购订单审批周期时间分析”和“审批资源工作量”仪表板的关键。此分析有助于识别造成瓶颈的审批人或审批组、公平评估工作量,并发现委派审批或重新设计流程的机会。
重要性
标识审批链中的人员,以便按审批人分析审批瓶颈、工作量和周期时间。
获取途径
执行操作的用户,记录在 PO_ACTION_HISTORY.ACTION_PERFORMED_BY 中;关联用户表后可获取全名。
示例
susan.managerdavid.directoremily.finance
|
|||
|
用户
UserName
|
执行活动的人员的用户ID或姓名。 | ||
|
说明
此属性标识负责特定事件的员工或系统用户,例如创建采购申请、批准采购订单或收货过账。数据通常来自“创建者”或“最后更新者”等字段。 按用户分析流程,有助于了解工作量分布和个人绩效,并识别培训需求。这也是“审批资源工作量”仪表板以及调查用户操作相关合规问题的基础。
重要性
将用户操作关联到具体人员,以便分析工作量、评估绩效并发现培训机会。
获取途径
根据 PO_HEADERS_ALL 和 PO_ACTION_HISTORY 等表中 CREATED_BY 或 LAST_UPDATED_BY 等字段的ID,与用户表进行关联。
示例
john.doejane.smithsystem.batch
|
|||
|
结束时间
EndTime
|
活动完成时的时间戳。对于原子事件,通常与开始时间相同。 | ||
|
说明
对于有持续时间的活动,此时间戳表示活动完成时间。对于瞬时事件,通常与开始时间相同。它是计算单项活动处理时间的必要数据。 单独记录结束时间,可以更准确地分析活动耗时。活动耗时可能不同于活动间的等待时间。区分实际工作时间和空闲时间,有助于分析资源工作量和效率。
重要性
可准确计算活动处理时间,这是分析资源效率和识别耗时任务的关键。
获取途径
对于原子事件,结束时间可以与开始时间相同,也可以根据后续事件的时间戳推导。部分活动可能有单独的完成时间戳。
示例
2023-04-15T10:05:00Z2023-04-16T14:45:00Z2023-05-01T09:15:00Z
|
|||
|
要求交付日期
RequestedDeliveryDate
|
申请方期望收到货物或服务的日期。 | ||
|
说明
此日期在采购订单行中指定,用于向供应商说明期望的交付时间,是衡量按时交付绩效的基准。 此属性对于计算“按时交付率”KPI至关重要。将实际收货日期与要求交付日期进行比较,企业可以量化并跟踪供应商的可靠性,识别供应链中的系统性延误。
重要性
作为衡量按时交付绩效的基准,是评估供应商可靠性和供应链效率的重要KPI。
获取途径
位于 PO_LINE_LOCATIONS_ALL 表的行位置级别,列名为 NEED_BY_DATE。
示例
2023-05-202023-06-152023-07-01
|
|||
|
部门
DepartmentName
|
发起采购订单或负责该订单的部门名称。 | ||
|
说明
此属性指定与采购相关的组织单位,例如“财务”“IT”或“制造”,用于成本分摊和组织报告。 在流程挖掘中,按部门细分流程对于比较绩效、识别部门特有的瓶颈,以及了解组织内不同流程执行方式的差异至关重要。它直接支持“采购订单审批周期时间分析”和“采购订单变更趋势”等仪表板。
重要性
可按不同业务单元筛选和比较流程绩效,发现部门特有的问题或最佳实践。
获取途径
可根据 PO_DISTRIBUTIONS_ALL 等表中的成本中心信息推导,该表关联部门主数据。
示例
IT运营市场营销研发
|
|||
|
采购订单总金额
PurchaseOrderTotalAmount
|
采购订单的货币总金额。 | ||
|
说明
此属性表示采购订单中所有项目按指定货币计算的总成本,是了解流程中交易金额的重要财务指标。 分析采购订单总金额有助于确定流程改进工作的优先级。例如,高金额订单可能需要经过更严格的审批流程。此属性还可用于分析财务影响,例如计算频繁变更或延迟的采购订单金额。
重要性
为流程分析提供财务背景,可按金额开展分析,例如重点关注高金额订单,或了解延误造成的财务影响。
获取途径
可汇总指定采购订单抬头对应的 PO_LINES_ALL 金额计算得出,也可直接使用抬头级别的总金额(如有)。
示例
5250.00120000.50750.99
|
|||
|
业务单元
BusinessUnitName
|
组织内负责采购的特定业务单元。 | ||
|
说明
业务单元是企业内独立的业务实体,通常拥有自己的分类账和财务报告,也是 Oracle Fusion 中主要的数据隔离机制。 对于大型跨国企业,按业务单元分析流程绩效至关重要。这样可以比较组织不同部分的采购效率、合规情况和成本,发现最佳实践及改进空间。
重要性
对于大型组织,比较不同运营部门的流程效率和合规情况至关重要。
获取途径
业务单元信息通常位于采购订单抬头的 PO_HEADERS_ALL.PRC_BU_ID,并关联至 FUN_ALL_BUSINESS_UNITS_V 视图。
示例
美国业务单元EMEA愿景APAC服务
|
|||
|
交付地点
DeliveryLocation
|
货物的实际交付地点或地址。 | ||
|
说明
此属性指定采购订单项目的收货地址,是重要的物流信息。 在流程挖掘中,按交付地点分析有助于支持“收货处理效率”仪表板。通过分析,可以识别某些仓库或站点的收货速度是否较慢,从而发现特定地点可能存在的资源或流程问题。
重要性
可按地理位置分析绩效,帮助识别收货流程中的区域性或站点特有瓶颈。
获取途径
通过 PO_LINE_LOCATIONS_ALL.SHIP_TO_LOCATION_ID 关联至 HR_LOCATIONS_ALL 视图。
示例
主仓库- A号月台3号楼-接待处旧金山办公室-10楼
|
|||
|
审批是否符合要求
IsApprovalCompliant
|
用于标记采购订单是否在发送给供应商之前获得批准。 | ||
|
说明
这是一个计算得出的布尔属性,用于检查是否遵守一项关键内部控制要求:采购订单必须先获批准,再发送给供应商。如果“采购订单已批准”活动发生在“采购订单已发送给供应商”活动之前,则该属性为true。 此属性对于“采购订单流程合规审计”仪表板和“采购订单审批合规率”KPI至关重要。它能直观地识别并量化合规违规情况,帮助落实采购政策,并降低未经授权支出的相关风险。
重要性
直接衡量“采购订单审批合规率”KPI,突出显示订单未经批准便发送给供应商这一严重的内部控制违规情况。
获取途径
计算字段。如果“采购订单已批准”的时间戳早于或等于“采购订单已发送给供应商”的时间戳,则设为“true”。
示例
truefalse
|
|||
|
数据最近更新时间
LastDataUpdate
|
数据最近一次从源系统提取或刷新的时间戳。 | ||
|
说明
此属性反映所分析数据的新鲜度,记录最近一次从 Oracle Fusion Financials 提取数据的日期和时间。 这项信息有助于用户了解分析结果和仪表板数据的时效性,明确流程洞察的更新程度,并判断近期交易是否已纳入分析。
重要性
清楚呈现数据的新鲜度,让用户了解流程分析反映的最新情况。
获取途径
此时间戳在数据提取和转换(ETL)过程中生成并添加。
示例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
是否延迟交付
IsLateDelivery
|
用于标记最终收货是否晚于要求的交付日期。 | ||
|
说明
这是一个计算得出的布尔属性。如果某采购订单的“已收货”活动时间戳晚于“要求的交付日期”属性值,则该属性为true。 此标记是“按时交付率”KPI的基础,可轻松区分并分析延迟订单和按时订单,帮助您调查延迟的根本原因,例如是否与特定供应商、地点或产品类别有关。
重要性
直接支持“按时交付率”KPI,便于清晰分析供应商绩效和交付可靠性。
获取途径
计算字段。如果“已收货”活动的时间戳晚于“RequestedDeliveryDate”属性,则设为“true”。
示例
truefalse
|
|||
|
是否返工
IsRework
|
用于标记采购订单在初次创建后是否经过修改。 | ||
|
说明
这是一个计算得出的布尔属性。如果采购订单案例中包含“采购订单已更改”活动,该属性将设为true。借助此属性,您可以快速识别需要更正或修改的订单。 此标记可简化“采购订单修改率”KPI的计算,并便于筛选和分析返工订单。了解返工订单的特征,例如涉及的供应商或部门,有助于找出数据不准确或需求变化的根本原因。
重要性
直接支持“采购订单修改率”KPI,并通过标记所有发生过更改的订单,简化对流程不稳定性的分析。
获取途径
计算字段。如果案例的事件日志中包含“采购订单已更改”活动,则设为“true”,否则设为“false”。
示例
truefalse
|
|||
|
源系统
SourceSystem
|
提取此数据的信息系统。 | ||
|
说明
此属性标识数据来源,在集成多个系统的环境中特别有用。对于此流程,通常为 'Oracle Fusion Financials'。 对于特定数据集,此值通常固定不变,但对数据治理、故障排查和确保数据沿袭至关重要。分析合并多个来源的数据时,可按来源系统筛选和细分数据。
重要性
标识数据来源,对于数据治理、理解数据背景及与其他系统集成至关重要。
获取途径
此值通常在数据提取和转换(ETL)过程中定义并添加,且保持不变。
示例
Oracle Fusion FinancialsOracle Cloud SCMOracle Fusion P2P
|
|||
|
采购申请
PurchaseRequisitionNumber
|
前置于采购订单并为其授权的采购申请标识符。 | ||
|
说明
采购申请是用于提出货物或服务采购需求的内部文档。此属性将采购订单关联到最初的申请。 纳入采购申请编号后,分析范围可以从最初申请开始,而不只是关注采购订单。这样有助于分析从申请到下单的周期时间,并了解申请详情对后续采购订单流程的影响。
重要性
将采购订单关联到最初的申请,从而全面查看从申请到付款的端到端流程。
获取途径
通过 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.硬件.笔记本电脑办公用品.文具专业服务.咨询
|
|||
|
采购订单状态
PurchaseOrderStatus
|
采购订单文档的当前状态。 | ||
|
说明
此属性表示采购订单生命周期中的当前状态,例如“未关闭”“已批准”“最终关闭”或“已取消”,反映采购订单的当前进度。 流程挖掘侧重分析活动顺序,而当前状态可用于筛选案例。例如,只分析未关闭的采购订单,以了解当前待处理情况;或只分析已关闭的采购订单,以查看已完成的流程实例。此属性是“采购订单流程与状态”仪表板的重要数据。
重要性
呈现采购订单的当前状态,可按进行中、已完成或已取消的订单筛选分析。
获取途径
Oracle Fusion Cloud SCM,PO_HEADERS_ALL 表中的 AUTHORIZATION_STATUS 或 DOCUMENT_STATUS 列。
示例
未关闭已批准最终关闭已取消
|
|||
|
采购订单类型
PurchaseOrderType
|
采购订单的类型,例如“标准”“长期协议”或“合同”。 | ||
|
说明
此属性根据采购用途对采购订单进行分类。不同类型的采购订单通常遵循不同的流程规则,生命周期也有所不同。 “标准”采购订单用于一次性采购,“长期协议”采购订单则是与供应商签订的长期协议。按采购订单类型分析流程,能更准确地了解流程绩效。将标准采购订单与长期协议的周期时间进行比较可能会产生误导,因此应比较同类订单。
重要性
区分不同的采购场景,以便对相似类型的订单进行更准确、同类对比的流程绩效分析。
获取途径
Oracle Fusion Cloud SCM,PO_HEADERS_ALL 表,TYPE_LOOKUP_CODE 列。
示例
标准长期协议合同
|
|||
采购到付款:采购订单活动
| 活动 | 说明 | ||
|---|---|---|---|
|
最终关闭采购订单
|
采购订单已完成,即货物已全部收齐和/或发票已全部处理,预计不会再有后续活动。这是一个明确操作,会将采购订单设为终止状态。 | ||
|
重要性
此活动标志着采购订单生命周期顺利结束,是主要的正向终态。跟踪此活动对于衡量整体流程吞吐量和完成率至关重要。
获取途径
此事件记录在 PO_ACTION_HISTORY 表中,ACTION_CODE 为 'FINALLY CLOSE'。PO_HEADERS_ALL 中的采购订单状态也会更新为 'Finally Closed'。
采集
在 PO_ACTION_HISTORY 中筛选 ACTION_CODE = 'FINALLY CLOSE'。
事件类型
explicit
|
|||
|
取消采购订单
|
采购订单已永久取消,预计不会再发生后续交易。这是一个明确操作,会将文档状态更改为终止状态。 | ||
|
重要性
此活动表示流程以负面结果结束。分析取消情况有助于发现重复下单、预算变更或项目需求变化等问题。
获取途径
此操作记录在 PO_ACTION_HISTORY 表中,ACTION_CODE 为 'CANCEL';PO_HEADERS_ALL 中的采购订单状态也会相应更新。
采集
在 PO_ACTION_HISTORY 中筛选 ACTION_CODE = 'CANCEL'。
事件类型
explicit
|
|||
|
收到货物
|
货物已实际收货、清点,并登记到采购订单中。此交易事件会更新库存和采购订单状态。 | ||
|
重要性
这是衡量供应商按时交付绩效和整体周期时间的重要节点,也会触发后续活动,例如质量检验和发票匹配。
获取途径
此事件明确记录在 RCV_TRANSACTIONS 表中,可通过 TRANSACTION_TYPE 为 'RECEIVE' 的交易识别。
采集
使用 RCV_TRANSACTIONS 中 TRANSACTION_TYPE 为 'RECEIVE' 的记录所对应的 TRANSACTION_DATE。
事件类型
explicit
|
|||
|
采购订单已创建
|
这是采购订单生命周期的正式起点,系统会生成一份状态为草稿或未完成的采购订单单据。系统通过记录新采购订单头记录的创建时间戳来捕获此事件。 | ||
|
重要性
作为采购订单案例的主要开始事件,此活动是所有周期时间计算的基础,也为衡量审批和供应商沟通等后续步骤的效率提供基准。
获取途径
此事件依据PO_HEADERS_ALL表中指定采购订单ID(PO_HEADER_ID)对应的CREATION_DATE字段明确记录。
采集
使用PO_HEADERS_ALL表中的创建时间戳。
事件类型
explicit
|
|||
|
采购订单已发送给供应商
|
已批准的采购订单正式发送给供应商,例如通过电子邮件或EDI。通常可根据状态变更或采购订单通信记录中的时间戳推断此事件。 | ||
|
重要性
此事件标志着供应商交付周期的开始,是衡量供应商表现的重要节点,可用于追踪从确认到最终交付的时间。
获取途径
可根据采购订单单据状态变为'Open'且已填写通信日期来推断此事件。具体字段通常为PO_HEADERS_ALL.communicated_date或相关状态字段。
采集
根据采购订单通信状态更新为'Communicated'时的时间戳推断。
事件类型
inferred
|
|||
|
采购订单已批准
|
采购订单已获得所有必要审批,现在可以发送给供应商。单据的操作历史中会明确记录这一关键里程碑事件。 | ||
|
重要性
这是阻止采购订单发送给供应商的关键审批关口。监控此事件对于衡量审批周期时间和确保遵守支出政策至关重要。
获取途径
此事件记录在PO_ACTION_HISTORY表中,通常对应ACTION_CODE为'APPROVE';也可通过PO_HEADERS_ALL中的单据状态变为已批准来识别。
采集
在PO_ACTION_HISTORY中筛选最终的'APPROVE'操作。
事件类型
explicit
|
|||
|
创建收货单
|
系统中已创建收货单,为货物实际到达做好准备。此活动标志着内部收货流程的开始。 | ||
|
重要性
这标志着流程从采购转入物流。分析从此时到最终收货过账的耗时,有助于发现仓库或收货部门的效率问题。
获取途径
这是一个明确记录的事件:系统会在 RCV_SHIPMENT_HEADERS 表中创建与采购订单关联的新记录,并记录创建时间。
采集
使用 RCV_SHIPMENT_HEADERS 中对应记录的创建日期。
事件类型
explicit
|
|||
|
完成质量检验
|
需要质量控制的货物已完成检验,并被接受或拒收。此活动发生在初始收货之后,并作为单独的交易记录。 | ||
|
重要性
此活动对质量管理至关重要。分析检验耗时有助于优化质量控制流程,减少货物投入使用前的延误。
获取途径
此活动记录在 RCV_TRANSACTIONS 表中。初始收货交易之后,TRANSACTION_TYPE 为 'ACCEPT' 或 'REJECT' 的交易即为检验结果。
采集
使用 RCV_TRANSACTIONS 中 TRANSACTION_TYPE 为 'ACCEPT' 或 'REJECT' 的记录所对应的 TRANSACTION_DATE。
事件类型
explicit
|
|||
|
确认服务已交付
|
对于服务类采购订单,此活动表示已确认服务按约定完成。通常通过手动操作或服务验收单记录此确认。 | ||
|
重要性
这相当于服务类采购的收货,是支付发票前的关键步骤。服务确认延迟可能导致付款逾期,并影响供应商关系。
获取途径
通常将此活动记录为采购订单服务行的收货。记录可能涉及特定字段或复杂的收货信息,用于跟踪服务进度或完成情况。
采集
识别与服务类采购订单行关联的收货交易(RCV_TRANSACTIONS)。
事件类型
explicit
|
|||
|
退货给供应商
|
此前收到的货物已退回供应商,通常是因为存在缺陷、损坏或发错货。收货模块会将其记录为特定的退货交易。 | ||
|
重要性
跟踪退货情况对于评估供应商质量和订单准确性至关重要。某供应商的退货率偏高,可能意味着存在需要解决的系统性问题。
获取途径
此事件明确记录在 RCV_TRANSACTIONS 表中,TRANSACTION_TYPE 为 'RETURN TO VENDOR'。
采集
使用 RCV_TRANSACTIONS 中 TRANSACTION_TYPE 为 'RETURN TO VENDOR' 的记录所对应的 TRANSACTION_DATE。
事件类型
explicit
|
|||
|
采购申请已创建
|
此活动表示已创建采购申请,即采购订单之前用于正式申请货物或服务的单据。在Oracle Fusion中,系统会在请购单头表中新建记录时记录此活动。 | ||
|
重要性
分析此活动有助于了解需求的发起阶段。追踪从请购到创建采购订单的时间,可以发现将内部需求转化为可执行采购订单时可能存在的延误。
获取途径
保存新采购申请时会明确记录此事件。您可以追踪POR_REQUISITION_HEADERS_ALL表中的创建时间戳来查找该事件。
采集
此事件依据POR_REQUISITION_HEADERS_ALL表中记录的创建日期确定。
事件类型
explicit
|
|||
|
采购申请已批准
|
指定审批人已批准采购申请,授权采购部门创建采购订单。系统会在该申请的操作历史记录中明确记录此事件。 | ||
|
重要性
此里程碑表示申请的内部审批流程已结束。此处的延误会直接影响整个采购周期,因此监控所需时间至关重要。
获取途径
此事件记录在与采购申请关联的操作历史中,通常通过工作流表或申请单据上的特定审批状态字段追踪。
采集
此事件作为审批操作记录在相应采购申请单据的工作流历史中。
事件类型
explicit
|
|||
|
采购订单已变更
|
采购订单首次获批后又进行了修改,例如更改数量、价格或交付日期。Oracle Fusion 会为文档创建新修订版本,以记录这些变更。 | ||
|
重要性
采购订单变更意味着返工,也可能反映初始订单信息不准确或业务需求发生变化。分析变更的频率和类型,有助于发现提升流程效率的机会。
获取途径
创建文档的新修订版本时,系统会明确记录此事件。可通过 PO_HEADERS_ALL 表中 REVISION_NUM 字段的递增来识别。
采集
识别每个 PO_HEADER_ID 对应的 REVISION_NUM 增加的情况。
事件类型
explicit
|
|||
|
采购订单已提交
|
已创建的采购订单提交至审批工作流。Oracle Fusion会明确记录此操作,并捕获提交事件的用户和时间戳。 | ||
|
重要性
此活动标志着审批周期开始。分析提交到批准之间的时间,是识别内部审批流程瓶颈的关键。
获取途径
此操作记录在PO_ACTION_HISTORY表中,对应的PO_HEADER_ID的ACTION_CODE为'SUBMIT'。
采集
在PO_ACTION_HISTORY中筛选ACTION_CODE = 'SUBMIT'。
事件类型
explicit
|
|||
|
采购订单已确认
|
供应商已确认收到采购订单并接受其条款。此事件通常由采购人员根据供应商沟通情况手动记录,也可能通过电子确认记录。 | ||
|
重要性
供应商确认可让您确定订单已收到并正在处理。追踪此活动有助于管理供应商沟通,并主动发现潜在的履约问题。
获取途径
通常可根据采购订单头或行上的确认状态字段变化推断此事件,例如PO_HEADERS_ALL.acceptance_status变为'Accepted'。
采集
根据采购订单确认状态字段的更新推断。
事件类型
inferred
|
|||
|
采购订单已驳回
|
审批人驳回了采购订单,并将其退回创建者修改。操作历史中会明确记录此事件,表明标准流程出现中断。 | ||
|
重要性
驳回会导致流程返工和延误。追踪此活动有助于找出常见驳回原因、培训需求或不明确的审批要求。
获取途径
此操作记录在PO_ACTION_HISTORY表中,对应的PO_HEADER_ID的ACTION_CODE为'REJECT'。
采集
在PO_ACTION_HISTORY中筛选ACTION_CODE = 'REJECT'。
事件类型
explicit
|
|||
提取指南
立即优化您的采购到付款:采购订单流程
轻松找出成本高昂的瓶颈,将周期时间缩短30%。
无需信用卡,立即开始优化。