您的订单到收款——销售订单处理数据模板
您的订单到收款——销售订单处理数据模板
- 建议收集的属性
- 需要追踪的关键活动
- 实用的数据提取指南
订单到收款—销售订单处理属性
| 名称 | 描述 | ||
|---|---|---|---|
| 销售订单 SalesOrder | 销售订单的唯一标识符,作为从订单到收款流程的主要案例 (case)。 | ||
| 描述 销售订单编号在整个生命周期内唯一标识每一笔客户订单。它是连接所有相关活动的核心线索,涵盖了从初始创建和确认,到履行、开票及最终付款的全部环节。 在流程挖掘中,此属性对于将所有相关事件归组为单个“案例” (case) 至关重要。按销售订单分析流程可以实现完整的端到端视图,从而计算总循环时间、识别单个订单的流程变体,并跟踪订单跨越不同部门和系统的旅程。 为何重要 这是案例 ID (Case ID)。它将所有流程事件联系在一起,从而可以追踪单笔客户订单的端到端路径。 获取方式 此标识符通常位于 Oracle Fusion 销售订单抬头表中,例如 DOO_HEADERS_ALL。请参阅 Oracle Fusion Financials 文档。 示例 SO-100567SO-100568SO-100569 | |||
| Event 时间 EventTime | 指示销售订单的特定活动或事件发生的时间戳。 | ||
| 描述 此属性提供流程中每个活动的日期和时间,从而建立事件的时间顺序。它是流程分析的时间基石,记录了每一步发生的具体时刻。 在流程挖掘中,EventTime 对于计算循环时间、活动间的时长以及整体案例的前置时间至关重要。它支持绩效分析、基于等待时间的瓶颈检测,并监控与时效相关的服务水平协议 (SLA) 合规情况。所有基于时间的 KPI 和仪表板都依赖于此属性的准确性。 为何重要 此时间戳对于按时间顺序排列事件以及计算所有基于时间的指标(如循环时间和时长)至关重要。 获取方式 这是一个派生属性,源自不同 Oracle Fusion 表中的各种时间戳字段,如订单创建日期、发货日期、开票日期和付款日期。 示例 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z | |||
| 活动名称 ActivityName | 在销售订单流程中发生的特定业务事件或任务的名称。 | ||
| 描述 此属性描述了在特定时间点为销售订单执行的步骤,例如“创建销售订单”、“已发货”或“已收到付款”。这些活动的顺序构成了每个案例的流程流。 分析 ActivityName 是 Process Mining 的基础。它实现了流程图的可视化、不同流程变体的发现以及案例堆积瓶颈的识别。它是计算步骤间流转时间以及理解从订单到收款流程操作顺序的核心。 为何重要 此属性定义了流程图中的步骤,以便实现流程流的可视化和分析。 获取方式 这是一个派生属性,通过将来自各种 Oracle Fusion 表的交易状态或事件类型(例如订单状态、货运状态、发票状态)映射到标准化的活动名称列表来构建。 示例 已创建销售订单已发货发票已创建已收到付款 | |||
| 付款到期日 PaymentDueDate | 客户须在此日期前支付发票款项。 | ||
| 描述 付款截止日期是根据发票日期和与客户约定的付款条件计算得出的。它设定了及时收款的期限。 此属性对于“按时收款率”KPI 至关重要。通过将 PaymentDueDate 与实际收款日期进行对比,系统可以确定付款是按时还是逾期,从而帮助监控应收账款绩效并管理现金流。 为何重要 作为计算按时付款率的截止日期,这是衡量现金流效率的关键指标。 获取方式 可在 Oracle Fusion 的应收账款或发票表中找到,例如 AR_PAYMENT_SCHEDULES_ALL。 示例 2023-06-192023-07-012023-06-25 | |||
| 实际交付日期 ActualDeliveryDate | 货物实际送达客户的日期。 | ||
| 描述 此属性记录最终交付日期,标志着流程中履行部分的完成。它是衡量计划或请求日期的实际结果。 通过将此日期与 RequestedDeliveryDate 进行对比,可以计算按时交付绩效。它是“按时交付率”KPI 和“交付 SLA”仪表板的关键输入,提供了物流和供应链有效性的清晰衡量标准。 为何重要 这是用于计算按时交付率并评估履行绩效(相对于客户请求)的实际结果日期。 获取方式 源自 Oracle Fusion 中的运输和交付交易表。请参阅 Oracle Fusion Financials 文档。 示例 2023-05-202023-06-032023-05-25 | |||
| 客户名称 CustomerName | 下单客户的名称。 | ||
| 描述 此属性标识与销售订单关联的客户账户法定名称。它是从客户视角细分和分析流程的关键维度。 按客户分析有助于识别某些客户是否经历了更长的循环时间、更多的重工或特定的流程偏差。这些洞察可用于改善客户服务、为大客户定制流程,并调查影响客户满意度的问题。 为何重要 支持以客户为中心的分析,识别影响特定客户的流程问题,从而提升客户满意度。 获取方式 源自客户主数据表(如 HZ_PARTIES),并通客户 ID 链接至销售订单。 示例 Global Corp Inc.Innovate Solutions Ltd.Tech Services LLC | |||
| 客户要求的交货日期 RequestedDeliveryDate | 客户在订单中提出的期望交付日期。 | ||
| 描述 此属性记录客户希望收到货物的日期。它是从订单到收款流程中履行环节的关键绩效目标。 该日期对于计算“按时交付率”KPI 和支持“交付服务水平协议 (SLA)”仪表板至关重要。通过将此日期与 ActualDeliveryDate 进行对比,组织可以衡量其满足客户预期的能力,并识别交付延迟的根本原因。 为何重要 作为衡量准时交付绩效和客户服务水平协议 (SLA) 遵循情况的基准。 获取方式 通常位于 Oracle Fusion 的销售订单行项目表中。请参阅 Oracle Fusion Financials 文档。 示例 2023-05-202023-06-012023-05-25 | |||
| 是否已自动化 IsAutomated | 标识某项活动由系统自动执行还是由用户手动完成的标记。 | ||
| 描述 此布尔属性区分系统驱动的事件(如自动信用检查、系统生成的发票)和人工操作。它通常根据与活动关联的用户名派生,其中通用系统 ID 表示自动化。 分析此属性有助于衡量流程的自动化水平,并且是“人工重工订单占比”KPI 的直接输入。通过显示哪些人工步骤最耗时或最容易出错,它可以突出进一步自动化的机会。 为何重要 有助于量化流程的自动化水平,并识别减少高成本人工干预的机会。 获取方式 这是一个派生字段,通常基于应用于 UserName 属性的规则。例如,如果用户是“SYSTEM”或“BATCH”,则此标志设置为 true。 示例 truefalse | |||
| 用户名称 UserName | 执行该活动的用户姓名或ID。 | ||
| 描述 此属性标识负责执行特定流程步骤的员工或系统用户。它可用于分析个人层面的绩效、工作量分配以及对标准程序的遵守情况。 按用户分析有助于识别培训需求、表彰高绩效个人或团队,并调查由特定用户引起的流程偏差。这对于合规和审计目的也极具价值,可以追踪具体操作的执行人。 为何重要 支持按用户进行绩效分析、工作量分配分析,并识别与个人相关的由于手动操作导致的返工模式。 获取方式 通常源自 Oracle Fusion 交易表中的 CREATED_BY 或 LAST_UPDATED_BY 等字段,通常链接到 FND_USER 等用户主表。 示例 john.smithjane.doesystem_batch_user | |||
| 销售渠道 SalesChannel | 接收销售订单的渠道。 | ||
| 描述 此属性对销售订单的来源进行分类,例如“Web”、“直接销售”、“合作伙伴”或“EDI”。它提供了订单进入组织的上下文背景。 按销售渠道细分流程对于“销售渠道绩效概览”仪表板非常关键。它有助于比较不同渠道的效率、循环时间和错误率,从而识别哪些渠道最有效,哪些可能需要流程改进或进一步的自动化。 为何重要 支持按渠道进行绩效分析,有助于识别订单处理效率最高和最低的渠道。 获取方式 此信息可能存储在销售订单抬头的专用字段中。请参阅 Oracle Fusion Financials 文档。 示例 直销网络门户EDI分销商 | |||
| 销售订单总额 SalesOrderTotalAmount | 销售订单的总金额。 | ||
| 描述 此属性代表向客户收取的整个销售订单总额。它包括所有行项目、税费和其他费用的总和(折扣前)。 在流程分析中,此属性对于基于价值的流程挖掘至关重要。它允许按价值细分订单(例如高价值与低价值订单),以观察它们是否遵循不同的流程路径或具有不同的循环时间。它还有助于将流程改进工作优先集中在财务影响最大的案例上。 为何重要 支持财务影响分析,有助于优先处理高价值订单的流程改进并了解成本驱动因素。 获取方式 通常存在于 Oracle Fusion 的销售订单抬头表中。请参阅 Oracle Fusion Financials 文档。 示例 5250.00125000.75980.50 | |||
| 业务单元 BusinessUnitName | 负责该销售订单的内部业务单元名称。 | ||
| 描述 此属性代表公司内部拥有该交易的特定部门或业务单元。它允许在组织的不同部分之间进行绩效比较。 按业务单元细分流程有助于识别公司内部在效率、成本和合规性方面的差异。此类分析可以揭示高绩效部门中可供分享的最佳实践,或突出显示需要针对性改进流程的低绩效部门。 为何重要 支持在不同组织单元之间进行绩效标杆分析和流程一致性分析。 获取方式 通常在销售订单抬头中提供,并链接到 Oracle Fusion 中定义的组织结构。 示例 北美业务部BU-EMEA全球服务 | |||
| 产品名称 ProductName | 所销售的产品或服务名称。 | ||
| 描述 此属性指定销售订单行中的项目。如果一个订单有多行,案例可能会在行项目级别进行分析,或者将此属性在抬头级别进行汇总。 按产品分析有助于了解某些产品是否与更复杂或更具挑战性的流程流相关联(如频繁的交付延迟或付款问题)。这可以为产品管理和供应链策略提供依据。 为何重要 支持对不同产品的流程绩效进行分析,突出显示可能具有复杂履约或开票路径的项目。 获取方式 源自销售订单行项目表,并与产品主表关联。请参阅 Oracle Fusion Financials 文档。 示例 标准件 X1尊享服务包组件 Y2-B | |||
| 付款条款 PaymentTerms | 约定的客户付款条件。 | ||
| 描述 此属性指定了客户支付发票的条件,例如“Net 30”或“Net 60”。这些条款是计算 PaymentDueDate 的基础。 在分析中,按付款条件细分有助于解释付款循环时间的差异。它为“按时付款率”KPI 提供了上下文,因为不同的条款自然会导致不同的付款行为。这可以为信用政策制定和现金流预测提供参考。 为何重要 为付款行为分析提供关键上下文,有助于解释发票到付款循环时间的差异。 获取方式 可在 Oracle Fusion 的销售订单或客户账户级别找到。请参考 Oracle Fusion Financials 文档。 示例 净 30 天净 60 天见票即付 | |||
| 最后数据更新 LastUpdateDate | 用于标识该事件数据最近一次从源系统刷新的时间戳。 | ||
| 描述 此属性记录数据最后一次提取或更新到流程挖掘数据集的时间。它提供了所分析数据新鲜度的透明信息。 此信息对于用户了解流程分析的时效性至关重要。它有助于管理对数据及时性的预期,并对于设置和监控数据刷新计划非常重要。 为何重要 指示数据的时效性,确保用户了解其流程分析的更新程度。 获取方式 此值在每个数据提取和转换周期中生成并标记到数据集中。 示例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| 发票是否已更正 IsInvoiceCorrected | 指示发票在首次创建后是否经过更正或修订的标记。 | ||
| 描述 如果发票经历了更正循环(由存在“发票已更正”活动指示),则此布尔属性为 true。它标记了在开票阶段涉及重工的案例。 这是“发票准确性与重工分析”仪表板和“发票重工率”KPI 的关键输入。它有助于量化开票错误的程度,并允许进行根本原因分析以确定需要更正的原因,旨在减少人工工作量和付款延迟。 为何重要 识别发票返工,这是流程低效、数据质量问题和潜在付款延迟的关键指标。 获取方式 这是一个计算字段。如果案例的事件日志中存在“发票已更正”活动,通常将其设置为 true。 示例 falsetrue | |||
| 发票编号 InvoiceNumber | 客户发票的唯一标识符。 | ||
| 描述 此属性是分配给销售订单所生成发票的唯一编号。它将销售和履行活动与流程中的财务结算部分联系起来。 虽然销售订单是主要的案例 ID (case ID),但发票编号对于分析开票和付款子流程至关重要。它对于跟踪发票更正、争议和付款状态必不可少,可支持“发票准确性与重工分析”等仪表板。 为何重要 提供与应收账款流程的关键关联,是分析发票重工和付款周期的必要条件。 获取方式 可在 Oracle Fusion 的应收账款交易表中找到,例如 RA_CUSTOMER_TRX_ALL。 示例 INV-93485INV-93486INV-93487 | |||
| 客户国家/地区 CustomerCountry | 客户所在的国家/地区。 | ||
| 描述 此属性提供客户收货或账单地址中的国家/地区。它是进行地理分析的关键维度。 按国家/地区细分流程可以揭示流程绩效、循环时间或付款行为的地域差异。这对于理解当地法规、物流挑战和市场状况对从订单到收款流程的影响非常有价值。 为何重要 支持地理维度分析,识别不同地区在流程效率、合规性和客户行为方面的差异。 获取方式 源自与销售订单链接的客户主数据表(HZ_LOCATIONS、HZ_PARTY_SITES)。 示例 美国德国日本 | |||
| 是否准时交付 IsOnTimeDelivery | 一个计算标记,如果实际交付时间在要求交付日期或之前,则为 true。 | ||
| 描述 此布尔属性通过对比 ActualDeliveryDate 与 RequestedDeliveryDate 派生。它提供了一个简单的案例级交付绩效指标。 该标志是计算综合“按时交付率”KPI 的基础。它简化了过滤和分析过程,允许用户快速隔离所有延迟订单,从而对导致延迟的因素进行根本原因分析。 为何重要 直接衡量针对客户预期的履约绩效,并简化对延迟订单的分析。 获取方式 这是一个计算字段。逻辑为:ActualDeliveryDate <= RequestedDeliveryDate。 示例 truefalse | |||
| 是否逾期支付 IsLatePayment | 一个计算标记,如果付款是在付款截止日期之后收到的,则为 true。 | ||
| 描述 此布尔属性通过对比实际收款日期与 PaymentDueDate 派生。它提供了一个发票是否按时支付的清晰指标。 此属性用于计算“按时付款率”KPI。它允许对按时付款与逾期付款进行轻松细分,以分析逾期客户的特征、延迟的常见原因以及对营运资金的财务影响。 为何重要 直接衡量款项催收的有效性,并简化对逾期付款的分析。 获取方式 这是一个计算字段。逻辑为:PaymentReceivedDate > PaymentDueDate。 示例 falsetrue | |||
| 源系统 SourceSystemIdentifier | 识别提取事件 data 的源系统。 | ||
| 描述 此属性指定数据的来源,这在多个系统参与从订单到收款流程的环境中特别有用。例如,订单数据可能来自 Oracle Fusion,而运输数据可能来自第三方物流系统。 在分析中,这有助于理解数据谱系,并可用于过滤来自特定系统的流程事件视图。这对于数据验证以及识别跨不同 IT 环境的流程碎片化至关重要。 为何重要 提供有关数据来源的上下文信息,这对于多系统环境下的数据治理和排障至关重要。 获取方式 这通常是在 data 提取和 transformation 过程中添加的静态值,用于标记 dataset 的来源。 示例 Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| 订单类型 OrderType | 销售订单的分类,例如“标准订单”或“退货单”。 | ||
| 描述 订单类型用于根据业务目的对销售订单进行分类。常见类型包括标准销售、服务订单、退货授权 (RMAs) 和内部订单。 按订单类型分析流程至关重要,因为不同类型的订单通常具有不同的流程流和性能目标。这种细分有助于理解那些有意为之且符合预期的流程差异,防止将其误解为流程异常偏差。 为何重要 允许对不同的合法流程(例如标准流程与退货流程)进行细分,以确保分析的公平性和准确性。 获取方式 通常作为 Oracle Fusion 销售订单抬头表中的一个字段。请参阅 Oracle Fusion Financials 文档。 示例 标准销售订单退货授权服务工单 | |||
| 配送方式 ShippingMethod | 将货物运送至客户所采用的方法或承运商。 | ||
| 描述 此属性详细记录了用于交付的物流承运商或服务级别,例如“陆运”、“空运快递”或“同城快递”。 此信息对于“运输方式交付合规性”仪表板必不可少。它允许在不同方式和承运商之间比较按时交付绩效和运输成本,从而帮助优化物流策略和供应商选择。 为何重要 支持物流分析,允许对不同承运商和发运方式进行绩效对比。 获取方式 可在 Oracle Fusion 的发运和履约表中找到。请参考 Oracle Fusion Financials 文档。 示例 FedEx GroundUPS次日达DHL 国际 | |||
订单到收款—销售订单处理活动
| 活动 | 描述 | ||
|---|---|---|---|
| 发票已创建 | 此活动代表在应收账款模块中创建客户发票,通常由发货确认事件触发。系统会生成包含唯一编号和创建日期的发票记录。 | ||
| 为何重要 标志着收款周期的正式开始。它是衡量“从发票到付款的时间”以及整体现金流效率的基础。 获取方式 这是 Oracle 应收账款 (AR) 中的一个显式事件。RA_CUSTOMER_TRX_ALL 表中会创建一条带有交易日期的发票记录。 捕获 从 AR 模块中发票交易的创建日期中获取。 事件类型 explicit | |||
| 已创建销售订单 | 此活动标志着销售订单流程的开始,代表新销售订单录入 Oracle Fusion 的时刻。当用户在 Order Management 模块中保存新订单记录时,通常会明确采集此事件。 | ||
| 为何重要 作为流程的起点,此活动对于衡量整体“订单到收款”周期时间和分析订单接收量至关重要。 获取方式 在 Order Management Cloud 中创建销售订单记录时明确记录。请在 DOO_HEADERS_ALL 表中查看创建时间戳。 捕获 从销售订单头记录的创建时间戳中获取。 事件类型 explicit | |||
| 已发货 | 此活动标志着货物已从仓库发出并在运往客户途中的时间点。当 Oracle Shipping 中处理发货确认交易时,会采集此事件。 | ||
| 为何重要 这是一个关键里程碑,标志着流程中履行部分的完成并触发开票。这对于衡量按时发货和交付前置时间至关重要。 获取方式 这是 Oracle 运输执行中记录的一个显式事件。发货确认交易会在运输表中(如 WSH_DELIVERY_DETAILS)创建一条带有发货日期的记录。 捕获 从与订单行关联的交付详情记录上的“实际发运日期”时间戳中获取。 事件类型 explicit | |||
| 已收到付款 | 此活动表示已收到客户付款,并在应收账款中冲销了发票。当过账现金收据申请时,会采集此事件。 | ||
| 为何重要 这是衡量“端到端从订单到收款循环时间”和“按时付款率”的关键里程碑。它代表销售向现金的转化。 获取方式 这是 Oracle 应收账款中的一个显式事件。当收据应用于发票时,它会记录在现金收款表中,如 AR_RECEIVABLE_APPLICATIONS_ALL。 捕获 从 AR 中收款应用记录的“应用日期”时间戳中获取。 事件类型 explicit | |||
| 订单已关闭 | 流程中的最后一项活动,表示销售订单上的所有行均已履行、开票并关闭。订单抬头状态更新为“已关闭”。 | ||
| 为何重要 此活动标志着销售订单生命周期的圆满结束。它对于计算端到端流程时长以及识别从未关闭的“僵尸订单”至关重要。 获取方式 通过 DOO_HEADERS_ALL 表中销售订单头状态更改为“已关闭”来推断。此最终状态更改的时间戳即为事件时间。 捕获 源自销售订单头状态更改为“已关闭”的时间戳。 事件类型 inferred | |||
| 订单已确认 | 这一关键里程碑表示销售订单已通过所有初始检查(包括信用审批),现在已进入履行阶段。通常当订单状态推进到“等待发货”或“已排产”时推断出此事件。 | ||
| 为何重要 此活动是计算“平均订单确认时间”的关键里程碑,标志着流程从订单录入移交至履行阶段。 获取方式 根据销售订单头或订单行状态更改为指示已准备好履约的值(例如“等待发货”)来推断。检查 DOO_HEADERS_ALL 或 DOO_FULFILL_LINES_ALL 中的状态列。 捕获 源自订单状态更改为已确认或已调度状态时的时间戳。 事件类型 inferred | |||
| 发票已修正 | 当先前创建的发票由于错误或客户争议而需要修改、重新开具或冲销时发生。这通常通过在系统中创建贷记通知单 (credit memo) 或新版本的发票来记录。 | ||
| 为何重要 跟踪发票更正是“发票重工率”KPI 的核心,它能突出计费流程中的问题,这些问题会延迟付款并增加管理成本。 获取方式 通过在 RA_CUSTOMER_TRX_ALL 表中创建贷项通知单(关联到原始发票)或同一张发票的后续版本来推断。 捕获 通过识别引用先前发票交易的贷项通知单或发票来得出。 事件类型 inferred | |||
| 已启用信用冻结 | 当销售订单因信用检查失败或其他信用相关问题而被自动或人工挂起时,会发生此活动。这通常通过系统中订单挂起状态的变化来采集。 | ||
| 为何重要 跟踪信用冻结对于识别订单处理延迟背后的原因以及衡量信用冻结释放流程的效率至关重要。 获取方式 通过销售订单上应用的冻结来推断。这通常记录在与销售订单关联的冻结相关表中,例如 DOO_HOLDS_ALL。 捕获 通过订单冻结表中创建的具有“信用”冻结类型的记录来推断。 事件类型 inferred | |||
| 已完成信用检查 | 代表对客户账户执行信用检查以评估其信用状况。这通常是订单处理工作流中的一个自动或人工步骤,其完成情况通常记录为状态更新或已完成的任务。 | ||
| 为何重要 分析信用检查所用的时间有助于识别订单审批中的瓶颈。这对于“从信用检查到确认的时间”这一 KPI 至关重要。 获取方式 可以从销售订单的状态变更(如变为“待信用审批”状态)中推断,或从信用管理功能中的显式事件日志中获取。 捕获 通过订单状态变更或与信用审查任务相关的时间戳来推断。 事件类型 inferred | |||
| 库存已预留 | 此活动代表为了履行销售订单行而进行的实物库存分配或预留。系统会锁定特定库存,确保在订单准备拣货时有货。 | ||
| 为何重要 跟踪此项有助于分析“库存分配前置时间”KPI,并识别从订单确认到货物锁定之间的延迟。 获取方式 此事件通常在库存或供应链执行模块中采集。它可以从履行行上的状态更新中推断出来,表明库存已被细化或预留。 捕获 通过与库存预留或调度相关的履约行状态变更来推断。 事件类型 inferred | |||
| 拣货完成 | 代表为了履行订单而从仓库中进行的实物拣货。这是物流流程中的关键步骤,通常记录在仓库管理或运输模块中。 | ||
| 为何重要 此活动提供了仓库运营的可见性。库存预留与拣货之间的延迟可能预示着仓库中的资源或流程瓶颈。 获取方式 在 Oracle Fusion Cloud SCM(供应链管理)模块中捕获。可以从与销售订单行关联的拣货波次或拣货单的状态变更中推断。 捕获 通过 SCM 模块中拣货交易的完成时间戳来推断。 事件类型 inferred | |||
| 订单已取消 | 代表销售订单在完全发货前的取消。这可能由多种原因引起,最终导致“已取消”的终止状态。 | ||
| 为何重要 这是一条关键的异常路径。分析已取消的订单有助于识别根本原因(如缺货、定价问题或客户改变主意),从而为流程改进提供参考。 获取方式 通过销售订单头或订单行状态更改为“已取消”状态来推断。该状态更改的时间戳用于记录事件。 捕获 源自订单头或订单行状态更改为“已取消”的时间戳。 事件类型 inferred | |||
| 订单行已关闭 | 代表单个销售订单行的最终关闭,表示该行已完全发货、开票,且预计不再有后续交易。系统将行状态更新为“已关闭”。 | ||
| 为何重要 关闭订单行标志着该项目的所有合同义务已履行完毕。分析这一点有助于识别在履约和付款后仍长期处于开启状态的订单。 获取方式 通过 DOO_FULFILL_LINES_ALL 表中履约行状态更改为“已关闭”来推断。该状态更改的时间戳即为事件时间。 捕获 源自履约行状态更改为“已关闭”的时间戳。 事件类型 inferred | |||
| 货物已送达 | 表示客户已收到货件。此信息通常来自外部承运商并更新回 Oracle Fusion,或者可以根据发货日期后的标准运输时间进行推断。 | ||
| 为何重要 此活动对于计算“按时交付率”KPI 和准确衡量客户服务水平至关重要。 获取方式 这通常不是 Oracle 的原生事件。如果已实施承运商集成,则可以采集该事件;或者通过在“已发货”日期基础上增加标准运输时间来计算。这需要系统分析。 捕获 通过承运商 data 源推断,或根据发货日期加上平均运输时间计算得出。 事件类型 inferred | |||
提取指南
步骤
- 导航至 Oracle BI Publisher: 使用具有 BI Administrator 或 BI Author 权限的用户登录 Oracle Fusion 环境。使用导航菜单进入“工具”>“报表和分析”。点击“浏览目录”按钮打开 Business Intelligence Catalog。
- 创建新数据模型: 在 BI Catalog 中,导航至合适的文件夹(例如 Shared Folders > Custom)。点击“新建”下拉菜单并选择 “Data Model”。
- 定义 SQL 查询数据集: 在数据模型编辑器中,点击 “+” 图标创建新数据集并选择 “SQL Query”。在弹出的对话框中为数据集命名(如 “OrderToCash_EventLog”),选择 “Oracle BI EE” 作为数据源,并选择 “Standard SQL” 作为 SQL 类型。
- 输入 SQL 查询: 复制本文档 “query” 部分提供的完整 SQL 查询,并将其粘贴到 SQL 查询文本区域。该查询包含开始和结束日期参数(:p_start_date 和 :p_end_date),BI Publisher 会自动识别这些参数。
- 配置数据模型属性: 粘贴查询后点击“确定”。导航至数据模型编辑器左侧窗格的“属性”部分。确保选中 “Include Parameter Tags”。如果需要,您还可以为日期参数设置默认值。
- 查看并保存数据模型: 点击“数据”选项卡。系统可能会提示您输入日期参数的值。输入一个小日期范围进行测试。点击“查看”以查看 data 样本。如果 data 显示正确,请点击保存图标并指定描述性名称(如 “OrderToCash_EventLog_DM”)来保存数据模型。
- 从数据模型创建报表: 数据模型保存后,点击右上角的“创建报表”按钮。这将打开报表创建向导。
- 配置报表: 在向导中,选择 “Use Data Model” 选项。向导将引导您完成布局设置。对于简单的 CSV 导出,您可以选择 “Table” 布局。将所有列拖放到表格中。点击“下一步”,然后取消选中 “Show Grand Totals Row”。点击“完成”保存报表,并命名为 “OrderToCash_EventLog_Report”。
- 运行报表: 打开新创建的报表。系统将提示您输入提取的开始和结束日期。提供所需的日期范围。
- 导出数据: 报表运行后,点击“查看”下拉菜单并选择不同的视图选项(如“查看报表”)。然后,找到“导出”链接或图标,并选择 “CSV” 作为导出格式。这将下载事件日志文件。
- 准备上传: 打开下载的 CSV 文件。验证列标题是否匹配所需属性:SalesOrder、ActivityName、EventTime、UserName、SalesOrderTotalAmount、CustomerName、SalesChannel、RequestedDeliveryDate、ActualDeliveryDate、PaymentDueDate 和 IsAutomated。该文件现在可以上传到流程挖掘工具了。
配置
- 用户权限: 您必须拥有具备 BI Publisher 数据模型和报表创建权限的角色,例如 “BI Administrator” 或 “BI Author”。
- 数据源: 该查询专为标准 “Oracle BI EE” 应用程序数据源设计,该数据源连接到交易数据库 (Fusion Apps)。通常不需要特殊配置。
- 日期范围参数: 查询使用 :p_start_date 和 :p_end_date 两个参数来过滤 data。强烈建议分批提取 data(例如每次 3 到 6 个月),以避免报表超时和性能问题。
- 业务单元过滤: 若要限制提取范围,可以在查询的 BaseOrders CTE 中添加 WHERE 子句,按特定的业务单元 ID 进行过滤(例如:AND dhead.SUBMITTING_BU_ID IN ([您的业务单元 ID]))。
- 订单类型过滤: 您还可以通过在 BaseOrders CTE 中添加 dhead.SOURCE_ORDER_TYPE_CODE 条件来过滤特定的销售订单类型。
- 性能: 对于跨越数年的超大数据集,这种单次查询方法可能会变慢。请考虑在非高峰时段运行,或将提取分解为较小的按月批次。确保 Data Model 中未选中 “Enable SQL Pruning” 属性,因为它可能会干扰复杂的 UNION 查询。
a 查询示例 sql
WITH BaseOrders AS (
SELECT
dhead.HEADER_ID,
dhead.ORDER_NUMBER AS SalesOrder,
dhead.CREATION_DATE,
dhead.CREATED_BY,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.CREATED_BY AND ROWNUM = 1) AS UserName,
dhead.SUBMITTING_BU_ID,
dhead.AMOUNT AS SalesOrderTotalAmount,
hp_sold.PARTY_NAME AS CustomerName,
dhead.SALES_CHANNEL_CODE AS SalesChannel,
dfl.REQUEST_SHIP_DATE AS RequestedDeliveryDate
FROM
DOO_HEADERS_ALL dhead
JOIN
DOO_FULFILL_LINES_ALL dfl ON dhead.HEADER_ID = dfl.HEADER_ID
JOIN
HZ_CUST_ACCOUNTS hc_sold ON dhead.SOLD_TO_CUSTOMER_ID = hc_sold.CUST_ACCOUNT_ID
JOIN
HZ_PARTIES hp_sold ON hc_sold.PARTY_ID = hp_sold.PARTY_ID
WHERE
dhead.OBJECT_VERSION_NUMBER = 1
AND dfl.LINE_NUMBER = 1 -- To avoid duplicating header-level events for each line
AND dhead.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
)
-- 1. Sales Order Created
SELECT
bo.SalesOrder,
'Sales Order Created' AS ActivityName,
bo.CREATION_DATE AS EventTime,
bo.UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN bo.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM BaseOrders bo
UNION ALL
-- 2. Credit Check Performed (inferred from Credit Hold Release)
SELECT
bo.SalesOrder,
'Credit Check Performed' AS ActivityName,
dha.RELEASED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.RELEASED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.RELEASED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.RELEASED_FLAG = 'Y' AND dha.RELEASED_DATE IS NOT NULL
UNION ALL
-- 3. Credit Hold Applied
SELECT
bo.SalesOrder,
'Credit Hold Applied' AS ActivityName,
dha.APPLIED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.APPLIED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.APPLIED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.APPLIED_DATE IS NOT NULL
UNION ALL
-- 4. Order Confirmed (inferred from status 'Awaiting Shipping')
SELECT
bo.SalesOrder,
'Order Confirmed' AS ActivityName,
dfl.STATUS_CHANGE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'AWAIT_SHIP'
UNION ALL
-- 5. Inventory Reserved
SELECT
bo.SalesOrder,
'Inventory Reserved' AS ActivityName,
irl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = irl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN irl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM INV_RESERVATIONS irl
JOIN DOO_FULFILL_LINES_ALL dfl ON irl.DEMAND_SOURCE_LINE_ID = dfl.FULFILL_LINE_ID
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE irl.DEMAND_SOURCE_TYPE_ID = 2 -- Order Entry
UNION ALL
-- 6. Goods Picked (inferred from delivery detail status 'Staged')
SELECT
bo.SalesOrder,
'Goods Picked' AS ActivityName,
wdd.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wdd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wdd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_DELIVERY_DETAILS wdd
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wdd.RELEASED_STATUS = 'S' -- 'S' typically means Staged/Picked
UNION ALL
-- 7. Goods Shipped
SELECT
bo.SalesOrder,
'Goods Shipped' AS ActivityName,
wnd.INITIAL_PICKUP_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.STATUS_CODE = 'CL' -- Closed/Shipped
UNION ALL
-- 8. Goods Delivered
SELECT
bo.SalesOrder,
'Goods Delivered' AS ActivityName,
wnd.ULTIMATE_DROPOFF_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
wnd.ULTIMATE_DROPOFF_DATE AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.ULTIMATE_DROPOFF_DATE IS NOT NULL
UNION ALL
-- 9. Invoice Created
SELECT
bo.SalesOrder,
'Invoice Created' AS ActivityName,
rct.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
aps.DUE_DATE AS PaymentDueDate,
CASE WHEN rct.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.CUSTOMER_TRX_ID = aps.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 10. Invoice Corrected (Credit Memo)
SELECT
bo.SalesOrder,
'Invoice Corrected' AS ActivityName,
rct_cm.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct_cm.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN rct_cm.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct_cm
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_cm ON rct_cm.CUSTOMER_TRX_ID = rctl_cm.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_ALL rct_orig ON rct_cm.PREVIOUS_CUSTOMER_TRX_ID = rct_orig.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_orig ON rct_orig.CUSTOMER_TRX_ID = rctl_orig.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl_orig.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl_orig.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl_cm.LINE_TYPE = 'LINE'
UNION ALL
-- 11. Payment Received
SELECT
bo.SalesOrder,
'Payment Received' AS ActivityName,
araa.APPLY_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = araa.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN araa.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM AR_RECEIVABLE_APPLICATIONS_ALL araa
JOIN RA_CUSTOMER_TRX_ALL rct ON araa.APPLIED_CUSTOMER_TRX_ID = rct.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE araa.STATUS = 'APP' AND rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 12. Order Line Closed
SELECT
bo.SalesOrder,
'Order Line Closed' AS ActivityName,
dfl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'CLOSED'
UNION ALL
-- 13. Order Closed
SELECT
bo.SalesOrder,
'Order Closed' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CLOSED'
UNION ALL
-- 14. Order Cancelled
SELECT
bo.SalesOrder,
'Order Cancelled' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CANCELED' 步骤
- 访问 BICC 控制台: 使用具有 BICC_ADMINISTRATOR 角色的用户登录 Oracle Fusion Applications 实例。导航至“工具”并从菜单中选择 “Business Intelligence Cloud Connector”。
- 创建新产品: 在 BICC 控制台中,点击“配置外部存储”来设置目标位置,可以是 Oracle Universal Content Management (UCM) 或 OCI Object Storage 存储桶。确保连接详情和凭证正确无误。
- 启动新的提取作业: 导航至“管理提取作业”部分。点击 “+” 图标创建新作业。为其指定一个描述性名称,例如 ProcessMind_O2C_SalesOrder_Extract。
- 选择数据存储 (PVO): 在作业配置中,搜索并添加捕获销售订单生命周期所需的 Public View Objects (PVO)。您需要添加多个 PVO,包括 FscmTopModelAM.DooTopAM.Header、FscmTopModelAM.DooTopAM.FulfillLine、FscmTopModelAM.DooTopAM.HoldInstance、FscmTopModelAM.ScmTopAM.ShipmentLine、FscmTopModelAM.ArTopAM.ReceivableInvoice 以及 FscmTopModelAM.ArTopAM.CashReceiptApplication。
- 配置每个 PVO 的列: 对于选定的每个 PVO,点击“操作”菜单并选择“选择列”。仔细选择生成事件日志所需的列,如 HeaderId、CreationDate、ShippedDate、TrxDate、ApplyDate 和用户标识符。详情请参考查询清单中每个 PVO 的所需列列表。
- 应用增量加载过滤器: 为管理 data 量,请根据 LastUpdateDate 列对每个 PVO 应用过滤器。对于初始运行,可以选择较宽的日期范围。对于后续的调度运行,应配置此过滤器以仅提取自上次作业执行以来更新的记录。
- 调度提取作业: 导航至“管理调度”部分。为您的作业创建一个新调度。建议在非高峰时段运行作业(例如每日凌晨),以尽量减小对系统性能的影响。
- 提交并监控作业: 配置完成后提交作业。您可以在“管理提取作业”屏幕监控进度。成功完成后,数据文件将以压缩 CSV 格式存储在您配置的云存储位置中。
- 将原始数据转换为事件日志: 下载提取的 CSV 文件。BICC 提供的是原始表 data,而非格式化的事件日志。您必须使用外部工具(如 Python、数据库脚本或 ETL 平台)来处理这些文件。这包括:
- 联接来自不同文件的 data(例如将发票 data 关联回销售订单头)。
- 将日期列转换为不同的活动行。例如,从 FscmTopModelAM.DooTopAM.Header 文件中,使用 CreationDate 创建一行“Sales Order Created”,使用 ClosedDate 创建另一行“Order Closed”。
- 将状态代码或标识映射到特定活动,如 “Order Confirmed” 或 “Order Cancelled”。
- 将所有转换后的 data 合并为一个具有所需列的文件:SalesOrder、ActivityName 和 EventTime。
- 格式化以上传: 确保最终转换的文件是单个 CSV,其列与所需和推荐的属性相匹配。该文件现在可以上传到 ProcessMind 了。
配置
- PVO 选择: 事件日志的准确性完全取决于 PVO 的选择。关键 PVO 包括 FscmTopModelAM.DooTopAM.Header(用于订单创建、关闭)、FscmTopModelAM.ScmTopAM.ShipmentLine(用于出运事件)以及 FscmTopModelAM.ArTopAM.ReceivableInvoice(用于开票)。
- 增量提取: 对于定期提取,务必使用 LastUpdateDate 过滤器。这对于系统性能至关重要,可避免重复提取数 GB 的相同数据。初始全量加载应建立基线,后续运行仅抓取变更内容。
- 日期范围: 对于首次历史数据加载,建议提取具有代表性的周期(如过去 3 到 6 个月的数据),以平衡数据完整性与可控的数据量。后续运行将采用增量方式。
- 存储配置: BICC 可导出至 Oracle UCM 或 OCI Object Storage。对于大数据量场景,通常推荐使用 OCI Object Storage,以便更好地与下游 ETL 工具集成。
- 作业调度: 将提取作业安排在非业务高峰时段,以避免对 Oracle Fusion Financials 交易系统产生潜在的性能影响。
- 先决条件: 配置作业的用户需要具备 BICC_ADMINISTRATOR 角色。您必须预先配置云存储凭证,并清晰了解提取后所需的数据转换逻辑。
a 查询示例 config
# BICC Data Store (PVO) and Column Selection Manifest
# This manifest outlines the PVOs and columns to select in the BICC UI for the extract job.
# PVO for Sales Order Header information (Created, Confirmed, Closed, Cancelled events)
PVO: FscmTopModelAM.DooTopAM.Header
Columns:
- HeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Sales Order Created')
- CreatedBy -> UserName (for 'Sales Order Created')
- LastUpdateDate # For incremental filtering
- StatusCode
- SubmittedDate -> EventTime (for 'Order Confirmed')
- SubmittedBy -> UserName (for 'Order Confirmed')
- OrderedTotal -> SalesOrderTotalAmount
- SoldToPartyName -> CustomerName
- SourceSalesChannelCode -> SalesChannel
- RequestShipDate -> RequestedDeliveryDate
- ClosedDate -> EventTime (for 'Order Closed')
- CanceledFlag
- CanceledDate -> EventTime (for 'Order Cancelled')
# PVO for Sales Order Lines (Line Closed event)
PVO: FscmTopModelAM.DooTopAM.FulfillLine
Columns:
- HeaderId -> SalesOrder
- ActualCompletionDate -> EventTime (for 'Order Line Closed')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
- StatusName # To confirm closed status
# PVO for Holds (Credit Hold Applied event)
PVO: FscmTopModelAM.DooTopAM.HoldInstance
Columns:
- SourceHeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Credit Hold Applied')
- CreatedBy -> UserName
- HoldName # To filter for credit-related holds
# PVO for Shipments (Picked, Shipped, Delivered events)
PVO: FscmTopModelAM.ScmTopAM.ShipmentLine
Columns:
- SourceHeaderNumber -> SalesOrder
- PickedDate -> EventTime (for 'Goods Picked')
- ShippedDate -> EventTime (for 'Goods Shipped')
- ActualDeliveryDate -> ActualDeliveryDate & EventTime (for 'Goods Delivered')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
# PVO for Invoices (Invoice Created, Invoice Corrected events)
PVO: FscmTopModelAM.ArTopAM.ReceivableInvoice
Columns:
- InterfaceHeaderAttribute1 -> SalesOrder # Link to SO via reference field
- TrxDate -> EventTime (for 'Invoice Created')
- CreatedBy -> UserName
- DueDate -> PaymentDueDate
- PreviousTrxNumber # If populated, indicates a correction
- CreationDate # Can be used for 'Invoice Corrected' if a new record is made
- LastUpdateDate # For incremental filtering
# PVO for Payments (Payment Received event)
PVO: FscmTopModelAM.ArTopAM.CashReceiptApplication
Columns:
- AppliedCustomerTrxId # ID to link back to the invoice
- ApplyDate -> EventTime (for 'Payment Received')
- CreatedBy -> UserName
- LastUpdateDate # For incremental filtering