您的订单到收款-销售订单处理数据模板
您的订单到收款-销售订单处理数据模板
- 建议采集的属性
- 需要跟踪的关键活动
- 实用的数据提取指南
订单到收款-销售订单处理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 销售订单 SalesOrder | 销售订单的唯一标识符,是订单到收款流程的主要案例。 | ||
| 说明 销售订单编号可在整个生命周期内唯一标识每笔客户订单。它将所有相关活动串联起来,涵盖订单创建、确认、履约、开票直至最终付款。 在流程挖掘中,此属性对于将相关事件归入同一案例至关重要。按销售订单分析流程,可以全面了解端到端流程,计算总周期时间,识别单笔订单的流程变体,并跟踪订单在不同部门和系统间的流转情况。 重要性 这是案例ID。它将所有流程事件关联起来,以便追踪单笔客户订单的端到端历程。 获取途径 此标识符通常位于Oracle Fusion的销售订单头表中,例如DOO_HEADERS_ALL。请参阅Oracle Fusion Financials文档。 示例 SO-100567SO-100568SO-100569 | |||
| 事件时间 EventTime | 表示销售订单某项活动或事件发生时间的时间戳。 | ||
| 说明 此属性记录流程中每项活动的日期和时间,用于确定事件的先后顺序。它是流程分析的时间基础,准确记录每个步骤的发生时间。 在流程挖掘中,EventTime对于计算周期时间、活动间时长和案例总周期至关重要。它支持绩效分析、基于等待时间的瓶颈识别,以及服务级别协议(SLA)时效要求的一致性监控。所有基于时间的KPI和仪表板都依赖此属性的准确性。 重要性 此时间戳对于按时间顺序排列事件,以及计算周期时间和时长等所有时间指标至关重要。 获取途径 这是一个派生属性,取自Oracle Fusion各表中的不同时间戳字段,例如订单创建日期、发运日期、发票日期和付款日期。 示例 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z | |||
| 活动名称 ActivityName | 销售订单流程中发生的具体业务事件或任务的名称。 | ||
| 说明 此属性描述销售订单在特定时间点执行的步骤,例如“销售订单已创建”“货物已发运”或“已收到付款”。这些活动按顺序排列,构成每个案例的流程路径。 分析ActivityName是流程挖掘的基础。它有助于可视化流程图、发现不同的流程变体,并识别案例积压的瓶颈。该属性也是计算步骤间转换时间、了解订单到收款流程运行顺序的依据。 重要性 此属性定义流程图中的步骤,用于可视化和分析流程路径。 获取途径 这是一个派生属性,通过将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 | |||
| 是否自动执行 IsAutomated | 用于标记活动由系统自动执行还是由用户手动执行。 | ||
| 说明 此布尔属性用于区分系统驱动的事件(例如自动信用检查、系统生成的发票)和用户手动操作。通常根据活动关联的用户名推导,通用系统ID表示自动执行。 分析此属性有助于衡量流程自动化程度,也是“人工返工订单占比”KPI的直接输入。它可以显示哪些人工步骤最耗时或最容易出错,从而发现进一步自动化的机会。 重要性 帮助量化流程自动化程度,并发现减少高成本人工干预的机会。 获取途径 这是一个派生字段,通常根据UserName属性应用规则得出。例如,用户为“SYSTEM”或“BATCH”时,此标记设为true。 示例 truefalse | |||
| 用户名 UserName | 执行活动的用户姓名或ID。 | ||
| 说明 此属性用于识别负责执行特定流程步骤的员工或系统用户。可据此分析用户绩效、工作量分布,以及对标准流程的遵循情况。 按用户分析有助于发现培训需求、识别表现出色的个人或团队,并调查特定用户导致的偏差。它也有助于合规和审计,追踪每项操作的执行者。 重要性 支持按用户分析绩效和工作量分布,并识别与个人相关的人工返工模式。 获取途径 通常取自Oracle Fusion交易表中的CREATED_BY或LAST_UPDATED_BY等字段,并常与FND_USER等用户主数据表关联。 示例 john.smithjane.doesystem_batch_user | |||
| 要求交付日期 RequestedDeliveryDate | 客户要求的订单交付日期。 | ||
| 说明 此属性记录客户希望收到货物的日期,是订单到收款流程中履约环节的重要绩效目标。 此日期对于计算“按时交付率”KPI和支持“交付服务级别协议(SLA)”仪表板至关重要。将此日期与ActualDeliveryDate比较,组织便可衡量满足客户预期的能力,并找出交付延迟的根本原因。 重要性 作为衡量按时交付绩效和客户服务级别协议(SLA)执行情况的基准。 获取途径 通常位于Oracle Fusion销售订单行项目表中。请参阅Oracle Fusion Financials文档。 示例 2023-05-202023-06-012023-05-25 | |||
| 销售渠道 SalesChannel | 接收销售订单的渠道。 | ||
| 说明 此属性用于标记销售订单的来源,例如“网站”“直销”“合作伙伴”或“EDI”,说明订单通过何种渠道进入组织。 按销售渠道细分流程对于“销售渠道绩效概览”仪表板至关重要。通过比较不同渠道的效率、周期时间和错误率,您可以识别表现较好的渠道,以及需要改进流程或进一步自动化的渠道。 重要性 支持按渠道分析绩效,帮助识别订单处理效率最高和最低的渠道。 获取途径 此信息可能存储在销售订单头的专用字段中。请参阅Oracle Fusion Financials文档。 示例 直销网络门户EDI经销商 | |||
| 销售订单总金额 SalesOrderTotalAmount | 销售订单的货币总金额。 | ||
| 说明 此属性表示整笔销售订单向客户收取的总金额,包括所有订单行项目、税费和其他费用的合计,不含折扣。 在流程分析中,此属性对于按价值开展流程挖掘至关重要。您可以按订单金额分组(例如高价值订单和低价值订单),比较其流程路径和周期时间。它还有助于优先改进财务影响最大的案例。 重要性 支持财务影响分析,帮助优先改进高价值订单流程并了解成本驱动因素。 获取途径 通常位于Oracle Fusion销售订单头表中。请参阅Oracle Fusion Financials文档。 示例 5250.00125000.75980.50 | |||
| 业务单元 BusinessUnitName | 负责销售订单的内部业务单元名称。 | ||
| 说明 此属性表示公司内部负责该交易的具体部门或运营单元,可用于比较组织不同部分的绩效。 按业务单元细分流程,有助于发现公司各部门在效率、成本和合规方面的差异。分析结果可以揭示绩效较好部门的最佳实践,供其他部门借鉴,也能指出需要针对性改进的部门。 重要性 支持跨组织单元开展绩效对标和流程一致性分析。 获取途径 通常可在销售订单头中找到,并关联至Oracle Fusion定义的组织结构。 示例 BU-North AmericaBU-EMEAGlobal Services | |||
| 产品名称 ProductName | 所售产品或服务的名称。 | ||
| 说明 此属性指定销售订单行上的商品。如果订单包含多个订单行,可按行项目级别分析案例,也可在订单头级别汇总此属性。 按产品分析有助于了解某些产品是否对应更复杂或问题更多的流程路径,例如频繁延迟交付或出现付款问题。这些信息可为产品管理和供应链策略提供依据。 重要性 支持比较不同产品的流程绩效,并发现履约或开票路径可能较复杂的商品。 获取途径 取自销售订单行项目表,并与产品主数据表关联。请参阅Oracle Fusion Financials文档。 示例 Standard Widget X1Premium Service PackageComponent Y2-B | |||
| 付款条款 PaymentTerms | 与客户约定的付款条件。 | ||
| 说明 此属性指定客户支付发票的条件,例如“净30天”或“净60天”。这些条款是计算PaymentDueDate的依据。 按付款条款细分分析,有助于解释付款周期时间的差异。它为“按时付款率”KPI提供背景,因为不同条款自然会带来不同的付款行为。这些信息可为信用政策和现金流预测提供依据。 重要性 为付款行为分析提供重要背景信息,并帮助解释发票至付款周期时间的差异。 获取途径 可在Oracle Fusion的销售订单或客户账户级别找到。请参阅Oracle Fusion Financials文档。 示例 净30天净60天收到即付 | |||
| 发票是否已更正 IsInvoiceCorrected | 用于标记发票在首次创建后是否经过更正或修订。 | ||
| 说明 如果事件日志中存在“发票已更正”活动,则此布尔属性为true,表示该案例经历了发票更正环节。它用于标记开票阶段发生返工的案例。 此属性是“发票准确性与返工分析”仪表板和“发票返工率”KPI的重要输入,可帮助量化开票错误的程度,并分析需要更正的根本原因,从而减少人工工作和付款延迟。 重要性 识别发票返工,这是流程效率低、数据质量问题及潜在付款延迟的重要指标。 获取途径 这是一个计算字段。如果案例的事件日志中存在“发票已更正”活动,通常会将其设为true。 示例 falsetrue | |||
| 发票编号 InvoiceNumber | 客户发票的唯一标识符。 | ||
| 说明 此属性是根据销售订单生成的发票唯一编号,将销售和履约活动与流程中的财务结算环节关联起来。 销售订单是主要案例ID,而发票编号对于分析开票和付款子流程至关重要。它有助于跟踪发票更正、争议和付款状态,并支持“发票准确性与返工分析”等仪表板。 重要性 与应收账款流程建立重要关联,是分析发票返工和付款周期所必需的。 获取途径 可在Oracle Fusion的应收账款交易表中找到,例如RA_CUSTOMER_TRX_ALL。 示例 INV-93485INV-93486INV-93487 | |||
| 客户所在国家/地区 CustomerCountry | 客户所在的国家/地区。 | ||
| 说明 此属性提供客户送货地址或账单地址所在的国家/地区,是地理分析的重要维度。 按国家/地区细分流程,可以发现各地区在流程绩效、周期时间或付款行为方面的差异。这有助于了解当地法规、物流挑战和市场环境对订单到收款流程的影响。 重要性 支持地理分析,帮助识别不同地区在流程效率、合规和客户行为方面的差异。 获取途径 取自客户主数据表(HZ_LOCATIONS、HZ_PARTY_SITES),并与销售订单关联。 示例 USA德国日本 | |||
| 数据上次更新时间 LastUpdateDate | 表示此事件的数据上次从源系统刷新时间的时间戳。 | ||
| 说明 此属性记录流程挖掘数据集中数据上次提取或更新的时间,让您了解所分析数据的新鲜度。 这有助于用户判断流程分析反映的实际情况有多新。它便于管理对数据时效性的预期,也有助于设置和监控数据刷新计划。 重要性 显示数据的新鲜度,让用户了解流程分析所用数据的更新情况。 获取途径 每次数据提取和转换时,系统都会生成此值并写入数据集。 示例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| 是否按时交付 IsOnTimeDelivery | 如果实际交付日期不晚于客户要求的交付日期,则此计算标记为true。 | ||
| 说明 此布尔属性通过比较ActualDeliveryDate和RequestedDeliveryDate得出,可在案例级别清晰标记交付绩效。 此标记是计算汇总“按时交付率”KPI的基础。它简化了筛选和分析,便于用户快速找出所有延迟订单,并分析造成延迟的根本原因。 重要性 直接衡量履约绩效是否符合客户预期,并简化延迟订单分析。 获取途径 这是一个计算字段。逻辑为:ActualDeliveryDate <= RequestedDeliveryDate。 示例 truefalse | |||
| 是否逾期付款 IsLatePayment | 如果收到付款的日期晚于付款到期日,则此计算标记为true。 | ||
| 说明 此布尔属性通过比较实际收款日期和PaymentDueDate得出,可清晰标记发票是否按时付款。 此属性用于计算“按时付款率”KPI。您可以轻松区分按时付款和逾期付款,分析逾期客户的特征、常见延迟原因,以及对营运资金的财务影响。 重要性 直接衡量收款效果,简化逾期付款分析。 获取途径 这是一个计算字段,逻辑为:PaymentReceivedDate > PaymentDueDate。 示例 falsetrue | |||
| 源系统 SourceSystemIdentifier | 标识提取事件数据的源系统。 | ||
| 说明 此属性标明数据来源,在订单到收款流程涉及多个系统时尤其有用。例如,订单数据可能来自Oracle Fusion,而发运数据可能来自第三方物流系统。 分析时,此属性有助于了解数据沿袭,也可用于筛选特定系统中的事件。它对于数据验证以及识别不同IT环境中的流程断点至关重要。 重要性 提供数据来源背景信息,对于多系统环境中的数据治理和问题排查至关重要。 获取途径 通常在数据提取和转换过程中添加一个固定值,用于标记数据集的来源。 示例 Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| 订单类型 OrderType | 销售订单的分类,例如“标准订单”或“退货订单”。 | ||
| 说明 订单类型用于根据业务目的对销售订单分类。常见类型包括标准销售订单、服务订单、退货授权(RMA)和内部订单。 按订单类型分析流程很重要,因为不同类型通常有各自的流程路径和绩效目标。此类细分有助于识别有意且符合预期的流程差异,避免将其误判为偏差。 重要性 支持区分不同且合理的流程路径(例如标准订单与退货订单),确保分析公平、准确。 获取途径 通常是Oracle Fusion销售订单头表中的一个字段。请参阅Oracle Fusion Financials文档。 示例 标准销售订单退货授权服务订单 | |||
| 运输方式 ShippingMethod | 用于将货物运送给客户的方式或承运商。 | ||
| 说明 此属性记录用于交付的物流承运商或服务等级,例如“陆运”“航空快递”或“本地快递”。 此信息对于“运输方式交付合规”仪表板至关重要。通过比较不同运输方式和承运商的按时交付绩效及运输成本,您可以优化物流策略和供应商选择。 重要性 支持物流分析,便于比较不同承运商和运输方式的绩效。 获取途径 可在Oracle Fusion的运输和履约表中找到。请参阅Oracle Fusion Financials文档。 示例 FedEx GroundUPS Next Day AirDHL International | |||
订单到收款-销售订单处理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 发票已创建 | 此活动表示在应收账款模块中创建客户发票,通常由发货确认事件触发。系统会生成包含唯一编号和创建日期的发票记录。 | ||
| 重要性 此活动标志着收款周期正式开始,是衡量“发票至付款时间”和整体现金流效率的依据。 获取途径 这是Oracle应收账款(AR)中的明确事件。系统会在RA_CUSTOMER_TRX_ALL表中创建发票记录,并记录交易日期。 采集 根据AR模块中发票交易的创建日期获取。 事件类型 explicit | |||
| 收到付款 | 此活动表示客户付款已收到,并已在应收账款中核销相应发票。当现金收款核销记录过账时,系统会记录此活动。 | ||
| 重要性 这是衡量“订单到收款总周期时间”和“按时付款率”的关键里程碑,代表销售收入转化为现金。 获取途径 这是Oracle应收账款中的明确事件。收款核销至发票时,系统会在AR_RECEIVABLE_APPLICATIONS_ALL等现金收款表中记录此事件。 采集 取自AR中现金收款核销记录的“核销日期”时间戳。 事件类型 explicit | |||
| 订单已关闭 | 这是流程中的最后一个活动,表示销售订单的所有订单行均已完成履约、开票并关闭。订单头状态会更新为“已关闭”。 | ||
| 重要性 此活动标志着销售订单生命周期顺利结束。它对于计算端到端流程时长,以及发现始终未关闭的僵尸订单至关重要。 获取途径 根据DOO_HEADERS_ALL表中销售订单头状态变为“已关闭”推断。最终状态变更的时间戳即为事件时间。 采集 根据销售订单头状态变为“已关闭”的时间戳得出。 事件类型 inferred | |||
| 订单已确认 | 这一关键里程碑表示销售订单已通过包括信用审批在内的所有初始检查,现已进入履约阶段。通常可根据订单状态变为“等待发货”或“已排程”等状态推断。 | ||
| 重要性 此活动是计算“平均订单确认时间”的关键里程碑,也标志着订单录入环节向履约流程的交接。 获取途径 根据销售订单标头或订单行状态变更为表示已准备履约的值推断,例如“等待发货”。请检查DOO_HEADERS_ALL或DOO_FULFILL_LINES_ALL中的状态列。 采集 根据订单状态变为已确认或已排程时的时间戳得出。 事件类型 inferred | |||
| 货物已发运 | 此活动标志着货物已从仓库发出,正在运往客户途中。在Oracle Shipping中处理发货确认交易时会记录此活动。 | ||
| 重要性 这是一个关键里程碑,表示流程中的履约环节已完成,并会触发开票。此活动对于衡量按时发货情况和交付周期至关重要。 获取途径 这是Oracle Shipping Execution中明确记录的事件。发货确认交易会在WSH_DELIVERY_DETAILS等发货表中创建记录,并包含发货日期。 采集 根据与订单行关联的交付明细记录中的“实际发货日期”时间戳获取。 事件类型 explicit | |||
| 销售订单已创建 | 此活动标志着销售订单流程的开始,即新销售订单录入Oracle Fusion的时刻。通常,用户在订单管理模块中保存新订单记录时,系统会明确记录此事件。 | ||
| 重要性 作为流程起点,此活动对于衡量整体订单到收款周期时间和分析订单接收量至关重要。 获取途径 在订单管理云中创建销售订单记录时会明确记录。请查找DOO_HEADERS_ALL表中的创建时间戳。 采集 根据销售订单标头记录的创建时间戳获取。 事件类型 explicit | |||
| 发票已更正 | 当已创建的发票因错误或客户争议而被修改、重新开具或冲销时,会发生此活动。通常通过创建贷项通知单或发票新版本来记录。 | ||
| 重要性 跟踪发票更正情况是计算“发票返工率”KPI的关键,有助于发现开票流程中的问题。这些问题可能延迟收款并增加管理成本。 获取途径 可根据贷项通知单(关联至原发票)的创建记录,或RA_CUSTOMER_TRX_ALL表中同一发票后续版本的记录推断。 采集 通过识别引用先前发票交易的贷项通知单或发票得出。 事件类型 inferred | |||
| 已执行信用检查 | 表示对客户账户执行信用检查,以评估其信用状况。这通常是订单处理工作流中的自动或人工步骤,完成后一般会记录为状态更新或已完成的任务。 | ||
| 重要性 分析信用检查所需时间,有助于发现订单审批中的瓶颈。这是“信用检查至确认时间”KPI的关键数据。 获取途径 可根据销售订单状态变更推断,例如状态变为“待信用审批”;也可从信用管理功能中的明确事件日志获取。 采集 根据订单状态变更或信用审核任务的相关时间戳推断。 事件类型 inferred | |||
| 已设置信用冻结 | 销售订单因信用检查未通过或其他信用相关问题而被自动或人工冻结时,会发生此活动。系统通常会记录订单冻结状态的变更。 | ||
| 重要性 跟踪信用冻结对于查明订单处理延迟的原因,以及衡量信用冻结解除流程的效率至关重要。 获取途径 根据销售订单被设置冻结状态推断。相关记录通常保存在DOO_HOLDS_ALL等冻结相关表中,并与销售订单关联。 采集 根据订单冻结表中创建的“Credit”冻结类型记录推断。 事件类型 inferred | |||
| 库存已预留 | 此活动表示为履行销售订单行而分配或预留实物库存。系统会锁定特定库存,确保订单准备拣货时有货可用。 | ||
| 重要性 跟踪此活动有助于分析“库存分配周期”KPI,并找出订单确认与货物落实之间的延迟。 获取途径 此事件通常记录在库存或供应链执行模块中。可根据履约订单行的状态更新推断库存已明细分配或预留。 采集 根据与库存预留或排程相关的履约订单行状态变更推断。 事件类型 inferred | |||
| 订单已取消 | 表示销售订单在全部发货前被取消。取消原因可能各不相同,最终状态为“已取消”。 | ||
| 重要性 这是一条关键的异常路径。分析已取消订单有助于找出根本原因,例如缺货、定价问题或客户改变主意,从而为流程改进提供依据。 获取途径 根据销售订单头或订单行状态变为“已取消”推断。状态变更的时间戳用于记录此事件。 采集 根据订单头或订单行状态变为“已取消”的时间戳得出。 事件类型 inferred | |||
| 订单行已关闭 | 表示单个销售订单行最终关闭,即该订单行已完成发货和开票,且预计不会再发生后续交易。系统会将订单行状态更新为“已关闭”。 | ||
| 重要性 订单行关闭表示该商品的所有合同义务均已履行。分析此活动有助于发现履约和付款完成后仍长期未关闭的订单。 获取途径 根据DOO_FULFILL_LINES_ALL表中履约行状态变为“已关闭”推断。状态变更的时间戳即为事件时间。 采集 根据履约行状态变为“已关闭”的时间戳得出。 事件类型 inferred | |||
| 货物已交付 | 表示客户已收到货物。此信息通常由外部承运商提供并更新至Oracle Fusion,也可能根据发货日期和标准运输时间推断。 | ||
| 重要性 此活动对于准确计算“按时交付率”KPI和衡量客户服务水平至关重要。 获取途径 这通常不是Oracle原生事件。若已集成承运商系统,则可记录此事件;也可在发货日期上加上标准运输时间进行计算。需要分析系统后才能确定。 采集 根据承运商数据源推断,或根据发货日期加平均运输时间计算。 事件类型 inferred | |||
| 货物已拣选 | 表示从仓库拣出货物以履行订单。这是物流流程中的关键步骤,通常记录在仓库管理或发货模块中。 | ||
| 重要性 此活动有助于了解仓库运营情况。库存预留与拣货之间的延迟可能表明仓库存在资源不足或流程瓶颈。 获取途径 此活动记录在Oracle Fusion Cloud SCM(供应链管理)模块中。可根据与销售订单行关联的拣货波次或拣货单状态变更推断。 采集 根据SCM模块中拣货交易的完成时间戳推断。 事件类型 inferred | |||
数据提取指南
步骤
- 打开Oracle BI Publisher:使用具有BI Administrator或BI Author权限的用户登录Oracle Fusion环境。通过Navigator菜单依次进入Tools > Reports and Analytics。点击“Browse Catalog”按钮,打开Business Intelligence Catalog。
- 新建数据模型:在BI Catalog中,进入合适的文件夹(例如Shared Folders > Custom)。点击“New”下拉菜单,选择“Data Model”。
- 定义SQL查询数据集:在Data Model编辑器中,点击“+”图标新建数据集,并选择“SQL Query”。在弹出的对话框中,为数据集命名(例如“OrderToCash_EventLog”),将“Oracle BI EE”设为数据源,并将“Standard SQL”设为SQL类型。
- 输入SQL查询:复制本文档“query”部分提供的完整SQL查询,并粘贴到SQL Query文本区域。查询包含开始和结束日期参数(:p_start_date和:p_end_date),BI Publisher会自动识别这些参数。
- 配置数据模型属性:粘贴查询后点击“OK”。在数据模型编辑器左侧窗格中打开“Properties”部分,确认已勾选“Include Parameter Tags”。您也可以按需设置日期参数的默认值。
- 查看并保存数据模型:点击“Data”选项卡。系统可能会提示您输入日期参数值。输入较短的日期范围进行测试。点击“View”查看数据样例。确认数据无误后,点击保存图标,并使用易于识别的名称保存数据模型(例如“OrderToCash_EventLog_DM”)。
- 根据数据模型创建报表:保存数据模型后,点击右上角的“Create Report”按钮,打开报表创建向导。
- 配置报表:在向导中选择“Use Data Model”。按照指引设置布局。若要导出简单的CSV文件,可选择“Table”布局,并将所有列拖入表格。点击“Next”,取消勾选“Show Grand Totals Row”,再点击“Finish”保存报表。报表可命名为“OrderToCash_EventLog_Report”。
- 运行报表:打开新建的报表。系统会提示您输入提取数据的开始和结束日期,请填写所需日期范围。
- 导出数据:报表运行后,点击“View”下拉菜单并选择其他视图选项,例如“View Report”。然后找到“Export”链接或图标,将导出格式设为“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两个参数筛选数据。建议分批提取数据,每批3至6个月,以避免报表超时和性能问题。
- 业务单元筛选:如需限定提取范围,可在查询的BaseOrders CTE中添加WHERE子句,按特定业务单元ID筛选(例如AND dhead.SUBMITTING_BU_ID IN ([Your Business Unit ID]))。
- 订单类型筛选:您也可以在BaseOrders CTE中添加dhead.SOURCE_ORDER_TYPE_CODE条件,筛选特定销售订单类型。
- 性能:对于跨越数年的大型数据集,此单条查询可能运行较慢。建议在非高峰时段运行,或按月拆分提取。请确保数据模型中未选中“Enable SQL Pruning”属性,否则可能影响复杂的UNION查询。
查询示例 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实例。在Tools菜单中选择Business Intelligence Cloud Connector。
- 新建提取配置:在BICC控制台中,点击Configure External Storage设置目标位置,可以选择Oracle Universal Content Management(UCM)或OCI Object Storage存储桶。请确认连接信息和凭据正确。
- 创建提取任务:进入Manage Extract Jobs部分,点击+图标新建任务,并设置易于识别的名称,例如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,点击Actions菜单并选择Select Columns。仔细选择生成事件日志所需的列,例如HeaderId、CreationDate、ShippedDate、TrxDate、ApplyDate和用户标识符。所需列的详细清单请参阅查询清单。
- 设置增量加载筛选条件:为控制数据量,按LastUpdateDate列为每个PVO设置筛选条件。首次运行时可选择较大的日期范围。之后按计划运行时,应将筛选条件设为仅提取上次任务执行后更新的记录。
- 安排提取任务:进入Manage Schedule部分,为任务创建新计划。建议在非高峰时段运行,例如每天夜间,以尽量减少对系统性能的影响。
- 提交并监控任务:配置完成后提交任务。您可以在Manage Extract Jobs页面查看进度。任务成功完成后,数据文件将以压缩CSV格式存放在配置的云存储位置。
- 将原始数据转换为事件日志:下载提取的CSV文件。BICC提供的是原始表数据,而非格式化的事件日志。您需要使用外部工具(例如Python、数据库脚本或ETL平台)处理这些文件,包括:
- 合并不同文件中的数据(例如,将发票数据关联回销售订单标头)。
- 将日期列转换为独立的活动行。例如,从FscmTopModelAM.DooTopAM.Header文件中,使用CreationDate生成“销售订单已创建”行,使用ClosedDate生成“订单已关闭”行。
- 将状态代码或标记映射为“订单已确认”或“订单已取消”等活动。
- 将转换后的数据合并为一个文件,并包含所需列: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角色。您还需要预先配置云存储凭据,并了解提取后所需的数据转换逻辑。
查询示例 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 立即优化订单到收款-销售订单处理流程
轻松发现瓶颈,将订单到收款周期时间缩短30%。
无需信用卡,免费试用14天。