您的采购到付款:采购申请数据模板
您的采购到付款:采购申请数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- Oracle Fusion Financials数据提取指南
采购到付款-采购申请属性
| 名称 | 说明 | ||
|---|---|---|---|
|
事件时间
EventTime
|
表示活动发生时间的时间戳。 | ||
|
说明
Event Time记录特定活动发生的准确日期和时间。该时间戳是按案例对事件进行时间排序的基础,来源包括系统中的创建日期、最后更新日期或具体操作时间戳。 在分析中,Event Time用于计算所有基于时长的指标,例如活动间周期时间、等待时间和案例总时长。它对于识别瓶颈、衡量SLA达成情况以及了解申请流程的时间特征至关重要。
为什么重要
该属性对于计算所有时间相关KPI、正确排列事件顺序以及分析流程绩效和瓶颈至关重要。
获取位置
通常来源于与事务或状态变更关联的“LAST_UPDATE_DATE”或“CREATION_DATE”列,常见于POR_REQUISITION_HEADERS_ALL或工作流历史表。
示例
2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
|
|||
|
活动
ActivityName
|
申请流程中特定时点发生的业务事件名称。 | ||
|
说明
Activity表示采购申请生命周期中的一个独立步骤或里程碑。例如“申请已创建”“审批步骤已批准”或“采购订单已创建”。这些活动源自源系统审计日志或事务表中记录的状态变更、用户操作或系统事件。 该属性对于构建流程图至关重要,流程图用于直观呈现申请流转过程。分析活动的顺序和频率,有助于识别常见流程路径、瓶颈、返工循环以及偏离标准流程的情况。
为什么重要
它构成流程图的基础,可用于直观呈现和分析申请工作流。
获取位置
根据POR_REQUISITION_HEADERS_ALL等表中的状态变更记录、事务历史或FA_FUSION_SOAINFRA.WFTASK等工作流审计跟踪记录生成。
示例
创建采购申请审批步骤已批准申请已拒绝采购订单已创建
|
|||
|
采购申请ID
PurchaseRequisitionId
|
采购申请的唯一标识符,用作流程的案例ID。 | ||
|
说明
采购申请ID是连接特定货物或服务申请相关所有活动的核心标识符。每个申请在创建时都会分配唯一ID,并在整个生命周期内保持不变。 在流程挖掘中,该属性用于将创建、提交、审批步骤和最终关闭等所有相关事件归入同一案例。这样可以端到端分析申请流转过程,绘制流程图、计算周期时间,并分析每个申请的流程变体。
为什么重要
这是跟踪申请从开始到结束整个生命周期的基础属性,可支持所有案例级分析和KPI计算。
获取位置
通常是申请头表中的主键,例如Oracle Fusion Financials中的POR_REQUISITION_HEADERS_ALL.REQUISITION_HEADER_ID。
示例
100234810023491002350
|
|||
|
最近数据更新时间
LastDataUpdate
|
源系统最近一次数据刷新的时间戳。 | ||
|
说明
该属性表示数据最近一次从Oracle Fusion Financials提取的日期和时间,适用于整个数据集,而非单个事件。 分析人员可据此了解数据的新鲜度,并确认最新交易的纳入时间。这是仪表板报告的重要元数据,也有助于确保分析基于最新信息。
为什么重要
告知用户数据的时效性,确保分析具有相关性并基于最新可用信息。
获取位置
该时间戳在数据提取过程中生成并存储,通常由ETL工具或数据管道完成。
示例
2023-10-27T02:00:00Z
|
|||
|
源系统
SourceSystem
|
提取这些数据的信息系统。 | ||
|
说明
该属性用于标识流程数据的来源。对于此数据模型,其值始终为“Oracle Fusion Financials”。 在包含多个ERP或集成系统的环境中,该字段对于数据溯源、问题排查和确保数据质量至关重要。它说明了所分析流程事件的事实来源。
为什么重要
提供有关数据来源的重要背景信息,对于数据治理以及整合多个系统的数据至关重要。
获取位置
这是在数据提取和转换过程中添加的静态值,用于标记数据集来源。
示例
Oracle Fusion Financials
|
|||
|
业务单元
BusinessUnit
|
申请所属组织中的具体业务单元。 | ||
|
说明
业务单元代表公司内提出申请的独立法律实体或职能实体,其组织层级高于部门。 按业务单元分析数据,可以比较组织不同部分的高层绩效。这有助于管理层判断流程低效是局部问题还是普遍问题,并确定改进重点。它几乎是所有仪表板和KPI的重要筛选维度。
为什么重要
提供高层组织背景,支持企业不同部分之间的绩效比较和战略分析。
获取位置
这是Oracle Fusion中的基础组织字段,通常位于POR_REQUISITION_HEADERS_ALL等表的申请头中。
示例
北美业务部门欧洲业务部门总部
|
|||
|
拒绝原因
RejectionReason
|
审批人拒绝申请或审批步骤时提供的原因。 | ||
|
说明
申请被拒绝时,审批人通常会通过预定义列表选择原因或输入自由文本。该属性用于记录相关说明。 这是分析流程失败根因的关键属性。它通过说明拒绝背后的原因,直接支持“修改与拒绝趋势”仪表板。分析拒绝原因有助于识别编码错误、预算超支或违反政策等常见问题,并通过培训或系统控制加以解决。
为什么重要
直接揭示申请被拒绝的原因,支持有针对性地改进流程,减少返工并提高直通式处理率。
获取位置
来源于工作流评论或工作流审计跟踪中的具体拒绝原因代码字段,可能位于FA_FUSION_SOAINFRA.WFTASK相关表或评论存储表中。
示例
总账科目错误超出成本中心预算选择了非首选供应商重复申请
|
|||
|
申请人姓名
RequesterName
|
创建并提交采购申请的员工姓名。 | ||
|
说明
该属性用于标识发起货物或服务申请的人员。通常在流程开始、申请首次创建时采集。 按申请人分析流程绩效对于“申请人绩效指标”仪表板至关重要。通过突出显示其申请的高修改率、高拒绝率或较长周期时间,可以识别需要额外培训的用户或群组,从而从人员视角了解流程。
为什么重要
支持按申请人分析绩效,有助于识别培训需求,并发现高效用户或部门。
获取位置
来源于申请头数据,通常通过将申请人ID与员工或用户主数据表关联获取。可查找POR_REQUISITION_HEADERS_ALL中与“PREPARER_ID”相关的字段,并与PER_ALL_PEOPLE_F关联。
示例
John SmithJane DoeEmily Jones
|
|||
|
申请总金额
RequisitionTotalAmount
|
采购申请的货币总金额。 | ||
|
说明
该属性表示单个采购申请所有行项目金额的总和,是了解每项申请财务重要性的关键数据。 在流程挖掘中,总金额可用于多种分析。例如,可筛选高价值申请,因为这类申请通常具有不同的审批路径或更严格的审核。仪表板还可利用该属性分析周期时间、拒绝率等流程指标与申请金额之间的关系。
为什么重要
提供财务背景,支持基于金额的分析,以确定流程改进优先级,并了解申请金额如何影响流程行为。
获取位置
位于申请头中,通常是POR_REQUISITION_HEADERS_ALL中的REQUISITION_TOTAL等字段,也可以通过汇总POR_REQUISITION_LINES_ALL中的行项目金额计算。
示例
550.0012500.7599.99
|
|||
|
申请状态
RequisitionStatus
|
采购申请当前或最终状态。 | ||
|
说明
该属性表示申请在特定时间点的整体状态或最终结果,例如“Approved”“Rejected”“In Process”或“Closed”。事件日志中的许多活动通常都由此属性派生。 该属性是“申请状态概览”仪表板的关键,为当前工作量和积压提供快照。它还用于计算基于结果的KPI,例如通过筛选以特定状态结束的案例来计算申请拒绝率。
为什么重要
提供申请当前状态的快照,并用于确定KPI计算所需的最终结果。
获取位置
位于申请头表中,通常是POR_REQUISITION_HEADERS_ALL中的“DOCUMENT_STATUS”或“APPROVAL_STATUS”等字段。
示例
已批准处理中已拒绝已撤回
|
|||
|
要求完成日期
RequiredByDate
|
申请人需要收到货物或服务的日期。 | ||
|
说明
申请人通过该日期指定所需物品的接收期限。它是采购流程的内部服务级别协议(SLA)目标。 该属性是“要求完成日期绩效”仪表板和“要求完成日期达成率”KPI的基础。将此日期与实际采购订单创建日期或收货日期进行比较,可以评估采购流程满足内部客户需求的程度,并识别系统性延误。
为什么重要
对于衡量流程相对于内部期限的绩效,以及了解采购流程能否及时满足业务需求至关重要。
获取位置
通常存储在申请行项目层级,例如POR_REQUISITION_LINES_ALL中的“NEED_BY_DATE”字段。
示例
2023-11-012023-12-152024-01-31
|
|||
|
部门
DepartmentName
|
申请人所属的业务部门。 | ||
|
说明
该属性表示创建申请人员所属的组织单位,例如“财务”“IT”或“市场营销”。通常根据申请人在HR系统中的用户档案获取。 按部门分析是细分流程数据的常用有效方式,有助于识别部门特有的行为,例如较高的拒绝率或较长的周期时间,从而制定有针对性的流程改进措施。这是“申请人绩效指标”仪表板的重要维度。
为什么重要
支持按业务部门细分流程分析,揭示部门特有的模式、绩效和合规问题。
获取位置
通常根据申请人档案获取,往往需要将申请表与包含部门信息的HR或用户目录表关联。
示例
信息技术部财务部运营部市场部
|
|||
|
供应商名称
SupplierName
|
货物或服务的建议供应商或预选供应商名称。 | ||
|
说明
该属性用于标识计划采购货物或服务的供应商。供应商可能由申请人建议,也可能由系统根据目录或既有协议确定。 按供应商分析可以揭示重要的采购模式。例如,可以识别某些供应商的申请是否需要更长时间才能获批,或是否具有更高的拒绝率。这些信息有助于供应商关系管理和采购策略制定。
为什么重要
支持按供应商分析流程绩效,有助于制定寻源策略和开展供应商关系管理。
获取位置
位于申请行项目表POR_REQUISITION_LINES_ALL中,通常通过VENDOR_ID与POZ_SUPPLIERS等供应商主数据表关联。
示例
Office Supplies Inc.Global Tech SolutionsCreative Marketing Agency
|
|||
|
审批工作流路径
ApprovalWorkflowPath
|
申请所需审批人或审批组的预定义顺序。 | ||
|
说明
该属性根据公司政策定义特定申请的预期标准审批流程,并考虑申请金额、类型和部门等因素。它代表“应有”流程模型。 审批工作流路径是合规性和一致性分析的基础。它通过将实际执行的审批步骤与规定路径直接比较,支持“合规与偏差分析”仪表板和“申请一致性指数”KPI。偏差可能表明违反政策或流程效率低下。
为什么重要
通过将实际流程与规定的审批层级进行比较,执行一致性检查,并突出显示不符合要求的采购申请。
获取位置
该信息在Oracle Fusion BPM Worklist或Approval Management Engine(AMX)中配置。提取每个申请的定义路径可能较为复杂,可能需要查询配置表。
示例
经理>总监>财务副总裁成本中心负责人>IT安全经理>部门负责人
|
|||
|
币种
CurrencyCode
|
申请金额使用的币种代码,例如USD或EUR。 | ||
|
说明
该属性指定申请总金额所使用的币种。对于全球化组织,申请可能使用不同币种创建。 它对于正确解读和汇总财务数据至关重要。涉及金额的分析必须使用币种代码确保准确比较,可以筛选单一币种,也可以将所有金额转换为统一币种。
为什么重要
确保财务分析和报告准确,尤其适用于使用多种币种的跨国组织。
获取位置
通常与金额字段一起位于申请头表中,例如POR_REQUISITION_HEADERS_ALL。
示例
USDEURGBPJPY
|
|||
|
是否已修改
IsAmendedFlag
|
布尔标志。如果申请至少修改过一次,则值为true。 | ||
|
说明
此计算属性用于表示采购申请在首次提交后是否发生过任何变更。系统通过检查案例历史中是否存在“Requisition Amended”活动来确定该属性。 此标记可简化分析和KPI计算,直接用于计算“Requisition Amendment Rate”KPI,并识别未实现直通处理的案例。您可以据此轻松筛选和比较已变更与未变更采购申请的流程指标。
为什么重要
简化变更率计算,便于比较已变更与未变更的采购申请。
获取位置
此属性不在源系统中,而是在数据转换期间根据事件日志中是否存在与变更相关的活动计算得出。
示例
truefalse
|
|||
|
是否直通处理
IsStraightThrough
|
用于表示采购申请是否在未发生任何变更或拒绝的情况下获批。 | ||
|
说明
此计算标记用于识别从提交到获批过程中未经历变更、拒绝等返工循环的采购申请,表示单个案例实现了完全顺畅的处理。 此属性是“Straight-Through Requisition Rate”KPI的基础。分析直通采购申请的特征,例如常见部门、申请人或申请类型,有助于发现最佳实践和自动化机会。反过来,分析未实现直通处理的案例,则有助于定位低效的主要原因。
为什么重要
直接衡量流程效率,是“Straight-Through Requisition Rate”KPI的基础,有助于识别返工原因。
获取位置
此属性在数据转换期间计算得出。如果案例中不存在“Requisition Amended”或“Approval Step Rejected”活动,则标记为true。
示例
truefalse
|
|||
|
是否自动化
IsAutomated
|
用于表示某项活动是否由系统自动执行。 | ||
|
说明
此属性用于识别流程中由系统用户或自动化代理而非人工执行的事件。例如,系统驱动的状态变更或低金额项目的自动审批步骤。 分析此属性有助于量化流程自动化水平。您可以据此比较自动化步骤与人工步骤的速度和效率,并发现进一步自动化的机会。
为什么重要
有助于衡量流程自动化水平,并发现自动化人工任务的机会。
获取位置
通过检查与活动关联的用户是否为系统账户或服务账户得出。为此需要维护已知系统用户ID列表。
示例
truefalse
|
|||
|
用户名
UserName
|
执行特定活动的用户姓名,例如审批人或编辑者。 | ||
|
说明
申请人姓名用于标识发起人,而用户名用于标识执行流程中特定事件的人员,例如批准或拒绝操作。这对于涉及不同人员的多步骤审批工作流尤其重要。 该属性对于分析审批瓶颈以及衡量特定审批人或团队的绩效至关重要。它通过支持对审批链中每位用户处理时间的分析,直接服务于“审批工作流瓶颈”仪表板。
为什么重要
标识每个事件的执行者,对于分析交接时间、审批人绩效和资源分配至关重要。
获取位置
来源于工作流历史或审计跟踪表,例如FA_FUSION_SOAINFRA.WFTASK,该表记录与每项任务完成相关的用户。
示例
David LeeSusan ChenMichael Brown
|
|||
|
申请类型
RequisitionType
|
申请类别,例如货物或服务申请。 | ||
|
说明
该属性根据申请内容对申请进行分类。常见类型包括货物、服务或资本性支出。申请类型可能影响所需审批工作流和采购策略。 在分析中,申请类型是用于筛选和比较的重要维度。例如,可以分析服务申请的审批周期时间是否长于货物申请。它有助于了解不同类型申请是否呈现不同的流程行为或瓶颈。
为什么重要
支持按采购类型细分分析,了解货物与服务等不同采购类型的流程差异。
获取位置
通常根据创建申请时选择的行项目类型或类别确定,可能存储在申请行表POR_REQUISITION_LINES_ALL中。
示例
货物服务资本性支出
|
|||
|
采购订单编号
PurchaseOrderNumber
|
根据已批准申请创建的采购订单标识符。 | ||
|
说明
该属性将采购申请与生成的采购订单关联起来。申请完全获批后,通常会转换为一个或多个采购订单并发送给供应商。 在分析中,该ID对于跟踪申请后续流程至关重要。它支持计算“申请到采购订单周期时间”KPI,并服务于“申请到采购订单周期时间”仪表板。它还支持将申请流程数据与后续采购订单和发票流程结合,实现真正端到端的采购到付款分析。
为什么重要
将申请与后续采购订单关联起来,从而支持衡量申请到采购订单的周期时间并开展端到端流程分析。
获取位置
采购订单创建后会存储此信息。通常可通过采购订单分配表中的关联申请引用查找,例如PO_DISTRIBUTIONS_ALL,该表会关联回申请行。
示例
PO-2023-5832PO-2023-5833PO-2023-5834
|
|||
|
项目描述
ItemDescription
|
申请行中所请求产品或服务的描述。 | ||
|
说明
该属性包含采购项目的文本描述,提供所请求货物或服务的具体信息。 虽然通常属于非结构化数据,项目描述仍能为分析提供有价值的背景。它可用于筛选,以识别申请类型未覆盖的特定采购。例如,分析人员可以搜索所有包含“Software License”的申请,了解其具体流程和周期时间。
为什么重要
提供采购内容的详细背景,支持对特定货物或服务进行更细粒度的筛选和分析。
获取位置
位于申请行项目表POR_REQUISITION_LINES_ALL中,通常是ITEM_DESCRIPTION等字段。
示例
15英寸笔记本电脑,16GB内存咨询服务-第四季度项目软件年度维护续订
|
|||
采购到付款-采购申请活动
| 活动 | 说明 | ||
|---|---|---|---|
|
创建采购申请
|
当用户首次保存新的采购申请时,标志着采购流程启动。系统通常会将其记录为明确的创建事件,并保存相应时间戳。 | ||
|
为什么重要
这是采购申请流程的主要开始事件。分析从创建到提交的耗时,可以发现申请正式提交过程中的延误。
获取位置
该事件记录在POR_REQUISITION_HEADERS_ALL表中,取自生成新Requisition ID时的creation_date列。
采集
使用采购申请头记录的创建时间戳。
事件类型
explicit
|
|||
|
提交采购申请
|
表示用户将已完成的采购申请提交至审批工作流的操作。当采购申请状态从“Incomplete”或“Draft”变为表示等待审批的状态时,系统会记录该事件。 | ||
|
为什么重要
此活动会触发审批周期,是衡量申请审批周期时间和整体周期时间的关键里程碑。
获取位置
根据POR_REQUISITION_HEADERS_ALL表中的状态变更推断,例如状态变为“PENDING APPROVAL”。提交日期通常也会明确存储。
采集
识别单据状态字段首次变为“Pending Approval”时的时间戳。
事件类型
inferred
|
|||
|
申请已关闭
|
表示申请生命周期最终结束,即所有申请行均已完成履行(例如已转换为采购订单)或已取消。可根据最终状态更新推断。 | ||
|
为什么重要
这是流程成功完成的主要结束事件,表明申请已全部处理完毕,无需进一步操作。
获取位置
根据POR_REQUISITION_HEADERS_ALL中的申请头状态变为“CLOSED”推断。
采集
识别申请单据状态变为“Closed”时的时间戳。
事件类型
inferred
|
|||
|
申请已批准
|
标记采购申请成功完成工作流中的所有步骤后获得最终批准。可根据申请整体状态变为“Approved”来推断。 | ||
|
为什么重要
这是表明申请已准备好进入采购操作的关键里程碑,也是衡量申请审批总周期时间的终点。
获取位置
根据POR_REQUISITION_HEADERS_ALL表中的单据状态字段变为“APPROVED”推断。该状态变更日期即为事件时间。
采集
识别单据状态首次设置为“Approved”时的时间戳。
事件类型
inferred
|
|||
|
申请已拒绝
|
表示申请被最终拒绝,该申请流程随之终止。可根据申请整体状态更新为“Rejected”来推断。 | ||
|
为什么重要
此活动是未成功申请的终止节点。分析这些案例对于理解申请拒绝率KPI及失败原因至关重要。
获取位置
根据POR_REQUISITION_HEADERS_ALL表中的单据状态变为“REJECTED”推断。
采集
识别单据状态首次设置为“Rejected”时的时间戳。
事件类型
inferred
|
|||
|
采购订单已创建
|
当已批准的申请行被用于生成采购订单时发生。该事件将申请流程与后续采购流程连接起来。 | ||
|
为什么重要
这是衡量申请到采购订单周期时间的关键里程碑。此处出现延误,通常表明审批到采购交接环节存在瓶颈。
获取位置
这是一个明确事件。申请与采购订单之间的关联存储在PO_LINE_LOCATIONS_ALL等表中,其中包含源申请行ID的引用。
采集
查找引用指定申请ID的采购订单创建日期。
事件类型
explicit
|
|||
|
审批步骤已开始
|
标记申请被分配给工作流中的特定审批人或审批组的时刻。该信息取自工作流引擎的事务日志。 | ||
|
为什么重要
此活动对于计算每个审批步骤的等待时间至关重要,有助于定位由特定审批人或审批层级造成的瓶颈。
获取位置
从Oracle Fusion的工作流表中获取,这些表会记录分配给用户的任务。使用审批任务的分配时间戳。
采集
使用指定申请在工作流历史记录中对应任务的创建时间戳。
事件类型
explicit
|
|||
|
审批步骤已批准
|
表示审批人在工作流指定步骤中批准申请的操作。该事件会明确记录在审批历史中。 | ||
|
为什么重要
跟踪各个审批步骤有助于还原实际审批路径,并衡量层级中每个阶段的处理时间。
获取位置
取自申请的审批操作历史,通常存储在管理审批层级的工作流(WF)或人力资本管理(HCM)表中。
采集
使用工作流操作历史日志中“APPROVE”操作的时间戳。
事件类型
explicit
|
|||
|
审批步骤已拒绝
|
审批人拒绝申请,通常会将其退回申请编制人进行修改,或终止该申请。此操作会明确记录在工作流历史中。 | ||
|
为什么重要
此活动是返工和延误的主要原因之一。分析拒绝情况有助于识别合规问题、预算问题或理由说明不清等原因。
获取位置
取自申请的审批操作历史。工作流系统会记录带有时间戳的“REJECT”操作。
采集
使用工作流操作历史日志中“REJECT”操作的时间戳。
事件类型
explicit
|
|||
|
审批步骤已退回
|
审批人在未正式拒绝申请的情况下,将其退回申请编制人,以补充信息或进行小幅修改。这通常是工作流系统中的明确操作。 | ||
|
为什么重要
这表明申请需要进一步澄清,并形成延长周期时间的返工循环。区分退回和拒绝,有助于更深入地了解流程摩擦。
获取位置
取自申请的审批操作历史。工作流系统会记录带有时间戳的“RETURN”或类似操作。
采集
使用工作流历史中“RETURN”或“Request for Information”操作的时间戳。
事件类型
explicit
|
|||
|
申请已修改
|
此事件表示用户在申请首次提交后对其进行了修改,通常需要重新启动审批流程。可通过检测关键数据字段的变化或申请新版本的创建来推断。 | ||
|
为什么重要
频繁修改通常表明数据质量或需求存在问题,进而导致返工和流程延误。该指标直接支持“申请修改率”KPI。
获取位置
可通过跟踪申请版本号,或识别提交后状态变回“Incomplete”来推断。变更日志或审计跟踪表也可能记录这些修改。
采集
识别申请提交后,同一申请ID对应的新版本创建时间戳。
事件类型
inferred
|
|||
|
申请已撤回
|
当申请人在申请完全获批前取消或撤回已提交的申请时发生。通常这是用户执行的明确操作,并会导致状态变更。 | ||
|
为什么重要
跟踪撤回情况有助于识别提前终止的原因,例如业务需求发生变化,或用户在提交后修正错误。
获取位置
根据POR_REQUISITION_HEADERS_ALL表中的状态变更为“WITHDRAWN”推断。相关操作会记录在申请的操作历史中。
采集
检测申请状态更新为“Withdrawn”时的时间戳。
事件类型
inferred
|
|||
提取指南
将采购到付款:采购申请流程提速30%
简化OracleP2P采购申请流程,将周期时间缩短30%。
无需信用卡,几分钟即可完成设置。