您的订单到收款——销售订单处理数据模板
您的订单到收款——销售订单处理数据模板
- 建议收集的属性
- 需要追踪的关键活动
- 实用的数据提取指南
订单到收款—销售订单处理属性
| 名称 | 描述 | ||
|---|---|---|---|
| 销售订单 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-North AmericaBU-EMEA全球服务 | |||
| 产品名称 ProductName | 所销售的产品或服务名称。 | ||
| 描述 此属性指定销售订单行中的项目。如果一个订单有多行,案例可能会在行项目级别进行分析,或者将此属性在抬头级别进行汇总。 按产品分析有助于了解某些产品是否与更复杂或更具挑战性的流程流相关联(如频繁的交付延迟或付款问题)。这可以为产品管理和供应链策略提供依据。 为何重要 支持对不同产品的流程绩效进行分析,突出显示可能具有复杂履约或开票路径的项目。 获取方式 源自销售订单行项目表,并与产品主表关联。请参阅 Oracle Fusion Financials 文档。 示例 标准件 X1尊享服务包组件 Y2-B | |||
| 从订单到付款的时长 OrderToPaymentDuration | 从销售订单创建到收到付款的总时长。 | ||
| 描述 此计算属性衡量单个案例中从订单到收款流程的端到端循环时间。它代表从第一个事件(“创建销售订单”)到最后一个事件(“已收到付款”)的总时长。 该指标直接衡量整个流程的总体健康状况和效率。它是“端到端从订单到收款循环时间”KPI 的基础,有助于进行高层级的绩效监控和基准测试。 为何重要 代表端到端总循环时间,为整体流程效率和现金转化速度提供高阶 KPI 指标。 获取方式 这是一个计算字段。逻辑为:“已收到付款”时间戳 - “创建销售订单”时间戳。 示例 45 天 6 小时62 天 11 小时35 天 2 小时 | |||
| 付款条款 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 | |||