您的Order to Cash:销售订单处理数据模板
您的Order to Cash:销售订单处理数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- 实用的数据提取指南
订单到收款-销售订单处理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 销售订单 SalesOrder | 销售订单的唯一标识符,作为Order to Cash流程的主案例。 | ||
| 说明 销售订单编号可在整个客户订单生命周期内唯一标识每个订单。它是连接所有相关活动的主线,从最初创建和确认,到履约、开票及最终收款。 在流程挖掘中,此属性对于将所有相关事件归入同一案例至关重要。按销售订单分析可以完整查看端到端流程,计算总周期时间,识别单个订单的流程变体,并跟踪订单在不同部门和系统中的流转过程。 为什么重要 这是Case 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 | 客户必须支付发票款项的日期。 | ||
| 说明 Payment Due Date根据发票日期和与客户约定的付款条款计算,设定及时收款的截止日期。 此属性对于“On-Time Payment Collection Rate”KPI至关重要。将PaymentDueDate与实际收款日期进行比较,系统可以判断付款是否按时到账,从而帮助监控应收账款绩效并管理现金流。 为什么重要 作为计算准时付款率的截止日期,这是衡量现金流效率的关键指标。 获取位置 位于Oracle Fusion的应收账款或发票表中,例如AR_PAYMENT_SCHEDULES_ALL。 示例 2023-06-192023-07-012023-06-25 | |||
| 实际交付日期 ActualDeliveryDate | 货物实际交付给客户的日期。 | ||
| 说明 此属性记录最终交付日期,标志着履约阶段完成。它是衡量计划日期或客户要求日期实际结果的依据。 将此日期与RequestedDeliveryDate进行比较,可以计算准时交付绩效。它是“On-Time Delivery Rate”KPI和“Delivery 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表示自动执行。 分析此属性有助于衡量流程自动化程度,也是“Manual Reworked Orders Percentage”KPI的直接输入。它可以显示哪些人工步骤最耗时或最容易出错,从而发现进一步自动化的机会。 为什么重要 帮助量化流程自动化程度,并识别减少高成本人工干预的机会。 获取位置 这是一个派生字段,通常根据UserName属性应用规则生成。例如,当用户为“SYSTEM”或“BATCH”时,此标志设为true。 示例 truefalse | |||
| 用户名 UserName | 执行该活动的用户姓名或ID。 | ||
| 说明 此属性标识负责执行特定流程步骤的员工或系统用户。它可用于分析用户级绩效、工作负载分布,以及对标准操作流程的遵循情况。 按用户分析有助于识别培训需求,发现高绩效个人或团队,并调查由特定用户造成的偏差。它对于合规和审计也很有价值,可追踪每项操作由谁执行。 为什么重要 支持按用户分析绩效和工作负载分布,并识别与个人相关的人工返工模式。 获取位置 通常来源于Oracle Fusion交易表中的CREATED_BY或LAST_UPDATED_BY等字段,并经常关联FND_USER等用户主表。 示例 john.smithjane.doesystem_batch_user | |||
| 要求交付日期 RequestedDeliveryDate | 客户要求订单交付的日期。 | ||
| 说明 此属性记录客户希望收到货物的日期,是Order to Cash流程履约阶段的关键绩效目标。 此日期对于计算“On-Time Delivery Rate”KPI和支持“Delivery Service Level Agreement(SLA)”仪表板至关重要。将此日期与ActualDeliveryDate进行比较,组织可以衡量满足客户期望的能力,并识别交付延误的根因。 为什么重要 作为衡量准时交付绩效和客户服务级别协议(SLA)合规情况的基准。 获取位置 通常位于Oracle Fusion的销售订单行项目表中。请参阅Oracle Fusion Financials文档。 示例 2023-05-202023-06-012023-05-25 | |||
| 销售渠道 SalesChannel | 接收销售订单的渠道。 | ||
| 说明 此属性对销售订单来源进行分类,例如“Web”“Direct Sales”“Partner”或“EDI”,帮助了解订单如何进入组织。 按销售渠道对流程进行分组,是“Sales Channel Performance Overview”仪表板的关键。它支持比较不同渠道的效率、周期时间和错误率,识别最有效的渠道,以及可能需要流程改进或进一步自动化的渠道。 为什么重要 支持按渠道分析绩效,帮助识别订单处理中效率最高和最低的渠道。 获取位置 此信息可能存储在销售订单头的专用字段中。请参阅Oracle Fusion Financials文档。 示例 直销Web门户EDI经销商 | |||
| 销售订单总金额 SalesOrderTotalAmount | 销售订单的货币总价值。 | ||
| 说明 此属性表示向客户收取的整个销售订单总金额,包括所有行项目、税费和其他费用,未扣除任何折扣。 在流程分析中,此属性对于基于价值的流程挖掘至关重要。它支持按订单价值(例如高价值订单和低价值订单)进行分组,以判断不同订单是否遵循不同流程路径或具有不同周期时间。它还有助于优先改进财务影响最大的流程案例。 为什么重要 支持财务影响分析,帮助优先改进高价值订单流程,并了解成本驱动因素。 获取位置 通常位于Oracle Fusion的销售订单头表中。请参阅Oracle Fusion Financials文档。 示例 5250.00125000.75980.50 | |||
| 业务单元 BusinessUnitName | 负责销售订单的内部业务单元名称。 | ||
| 说明 此属性表示公司内部负责该交易的具体部门或运营单元,支持比较组织不同部分的绩效。 按业务单元对流程进行分组,有助于识别公司各部门在效率、成本和合规方面的差异。分析可以发现高绩效单元中的最佳实践并推广,也可以识别需要重点改进的低绩效单元。 为什么重要 支持不同组织单元之间的绩效基准比较和流程一致性分析。 获取位置 通常可在销售订单头中找到,并与Oracle Fusion中定义的组织结构关联。 示例 BU-North AmericaBU-EMEA全球服务 | |||
| 产品名称 ProductName | 所销售产品或服务的名称。 | ||
| 说明 此属性指定销售订单行中的项目。如果订单包含多个行项目,可以在行项目级别分析案例,也可以在订单头级别汇总此属性。 按产品分析有助于了解某些产品是否更容易出现复杂或有问题的流程,例如频繁交付延误或付款问题。这些洞察可为产品管理和供应链策略提供依据。 为什么重要 支持分析不同产品的流程绩效,突出可能存在复杂履约或开票路径的项目。 获取位置 来源于销售订单行项目表,并与产品主表连接。请参阅Oracle Fusion Financials文档。 示例 Standard Widget X1高级服务套餐Component Y2-B | |||
| 付款条件 PaymentTerms | 与客户约定的付款条件。 | ||
| 说明 此属性规定客户应支付发票的条件,例如“Net 30”或“Net 60”。这些条件是计算PaymentDueDate的基础。 按付款条件细分分析,有助于解释付款周期时间的差异。它为“On-Time Payment Rate”KPI提供背景,因为不同付款条件自然会带来不同的付款行为。这些信息可用于制定信用政策和预测现金流。 为什么重要 为付款行为分析提供关键背景,并帮助解释从开票到付款周期时间的差异。 获取位置 可在Oracle Fusion的销售订单层级或客户账户层级找到。请参阅Oracle Fusion Financials文档。 示例 30天账期60天账期收到即付款 | |||
| 最后数据更新时间 LastUpdateDate | 表示此事件数据最近一次从源系统刷新时间的时间戳。 | ||
| 说明 此属性记录流程挖掘数据集最近一次提取或更新数据的时间,帮助用户了解当前分析数据的新鲜度。 这些信息对于判断流程分析的时效性至关重要,有助于管理用户对数据及时性的预期,并支持设置和监控数据刷新计划。 为什么重要 表示数据的新鲜度,帮助用户了解流程分析是否为最新状态。 获取位置 此值会在每次数据提取和转换周期中生成并写入数据集。 示例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| 发票是否已更正 IsInvoiceCorrected | 用于标记发票是否在首次创建后经过更正或修订。 | ||
| 说明 如果发票经历了更正循环,即事件日志中存在“Invoice Corrected”活动,则此布尔属性为true。它用于标记开票阶段发生返工的案例。 这是“Invoice Accuracy & Rework Analysis”仪表板和“Invoice Rework Rate”KPI的重要输入。它有助于量化开票错误程度,并通过根因分析找出需要更正的原因,从而减少人工工作和付款延迟。 为什么重要 识别发票返工,这是流程低效、数据质量问题和潜在付款延迟的重要指标。 获取位置 这是一个计算字段。如果案例的事件日志中存在“Invoice Corrected”活动,通常将其设置为true。 示例 falsetrue | |||
| 发票编号 InvoiceNumber | 客户发票的唯一标识符。 | ||
| 说明 此属性是为销售订单生成的发票分配的唯一编号,将销售和履约活动与流程中的财务结算环节关联起来。 虽然Sales Order是主要案例ID,但Invoice Number对于分析开票和付款子流程至关重要。它是跟踪发票更正、争议和付款状态的基础,可支持“Invoice Accuracy & Rework Analysis”等仪表板。 为什么重要 为应收账款流程提供关键关联,并用于分析发票返工和付款周期。 获取位置 可在Oracle Fusion的应收账款交易表中找到,例如RA_CUSTOMER_TRX_ALL。 示例 INV-93485INV-93486INV-93487 | |||
| 客户所在国家/地区 CustomerCountry | 客户所在的国家/地区。 | ||
| 说明 此属性提供客户发运地址或账单地址所在的国家/地区,是地理分析的重要维度。 按国家/地区细分流程,有助于发现不同地区在流程绩效、周期时间或付款行为方面的差异。这对于了解当地法规、物流挑战和市场状况对Order to Cash流程的影响非常有价值。 为什么重要 支持地理分析,帮助识别不同地区在流程效率、合规性和客户行为方面的差异。 获取位置 来源于与销售订单关联的客户主数据表(HZ_LOCATIONS、HZ_PARTY_SITES)。 示例 USA德国日本 | |||
| 是否延迟付款 IsLatePayment | 如果在付款到期日之后收到付款,则该计算标记为true。 | ||
| 说明 此布尔属性通过比较实际收款日期和PaymentDueDate得出,可清晰反映发票是否按时支付。 该属性用于计算“On-Time Payment Rate”KPI。它支持轻松区分按时付款和延迟付款,分析延迟付款客户的特征、常见延迟原因及其对营运资金的财务影响。 为什么重要 直接衡量收款效率,并简化逾期付款分析。 获取位置 这是一个计算字段。逻辑为:PaymentReceivedDate > PaymentDueDate。 示例 falsetrue | |||
| 是否按时交付 IsOnTimeDelivery | 如果实际交付日期早于或等于要求交付日期,则该计算标记为true。 | ||
| 说明 此布尔属性通过比较ActualDeliveryDate和RequestedDeliveryDate得出,可在案例层面直观反映交付绩效。 该标记是计算“On-Time Delivery Rate”KPI的基础。它简化了筛选和分析,帮助用户快速找出所有延迟订单,并对导致延迟的因素进行根因分析。 为什么重要 直接衡量履约绩效是否符合客户预期,并简化延迟订单分析。 获取位置 这是一个计算字段。逻辑为:ActualDeliveryDate <= RequestedDeliveryDate。 示例 truefalse | |||
| 源系统 SourceSystemIdentifier | 标识提取事件数据的源系统。 | ||
| 说明 此属性指定数据来源。在Order to Cash流程涉及多个系统的环境中,这一点尤其有用。例如,订单数据可能来自Oracle Fusion,而发运数据可能来自第三方物流系统。 在分析中,它有助于了解数据血缘,也可用于筛选特定系统中的事件,以查看相应流程。它对于数据验证,以及识别不同IT环境中的流程碎片化至关重要。 为什么重要 提供数据来源背景,对于多系统环境中的数据治理和问题排查至关重要。 获取位置 通常是在数据提取和转换过程中添加的静态值,用于标记数据集来源。 示例 Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| 订单类型 OrderType | 销售订单的分类,例如“标准订单”或“退货订单”。 | ||
| 说明 Order Type用于根据业务目的对销售订单进行分类。常见类型包括标准销售订单、服务订单、退货授权(RMA)和内部订单。 按订单类型分析流程非常重要,因为不同类型通常具有不同的流程路径和绩效目标。这种细分有助于理解有意且符合预期的流程差异,避免将其误判为偏差。 为什么重要 支持区分不同且合理的流程路径(例如标准订单与退货订单),确保分析公平、准确。 获取位置 通常可在Oracle Fusion的销售订单头表中找到。请参阅Oracle Fusion Financials文档。 示例 标准销售订单退货授权服务订单 | |||
| 运输方式 ShippingMethod | 用于将货物运送给客户的方式或承运商。 | ||
| 说明 此属性详细说明交付所使用的物流承运商或服务级别,例如“Ground Freight”“Air Express”或“Local Courier”。 此信息对于“Shipping Method Delivery Compliance”仪表板至关重要。它支持比较不同运输方式和承运商的准时交付绩效及运输成本,帮助优化物流策略和供应商选择。 为什么重要 直接支持物流分析,可比较不同运输承运商和运输方式的绩效。 获取位置 可在Oracle Fusion的发运和履约表中找到。请参阅Oracle Fusion Financials文档。 示例 FedEx GroundUPS Next Day AirDHL International | |||
订单到收款-销售订单处理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 发票已创建 | 此活动表示在Accounts Receivable模块中创建客户发票,通常由发运确认事件触发。系统会生成包含唯一编号和创建日期的发票记录。 | ||
| 为什么重要 标志着收款周期正式开始,是衡量“Invoice to Payment Time”和整体现金流效率的基础。 获取位置 这是Oracle Accounts Receivable(AR)中的明确事件。发票记录会在RA_CUSTOMER_TRX_ALL表中创建,并包含交易日期。 采集 取自AR模块中发票交易的创建日期。 事件类型 explicit | |||
| 已收到付款 | 此活动表示客户付款已收到,并已在Accounts Receivable中核销发票。现金收款核销过账时会记录此活动。 | ||
| 为什么重要 这是衡量“Overall Order to Cash Cycle Time”和“On-Time Payment Rate”的关键里程碑,代表销售收入转化为现金。 获取位置 这是Oracle Accounts Receivable中的明确事件。当收款核销发票时,系统会在AR_RECEIVABLE_APPLICATIONS_ALL等现金收款表中记录此事件。 采集 取自AR中现金收款核销记录的“apply date”时间戳。 事件类型 explicit | |||
| 订单已关闭 | 流程中的最终活动,表示销售订单的所有行均已完成履约、开票并关闭。订单头状态会更新为“Closed”。 | ||
| 为什么重要 此活动标志着销售订单生命周期顺利结束,对于计算端到端流程时长和识别始终未关闭的僵尸订单至关重要。 获取位置 根据DOO_HEADERS_ALL表中销售订单头状态变为“Closed”推断。最终状态变化的时间戳即为事件时间。 采集 根据销售订单头状态变为“Closed”时的时间戳得出。 事件类型 inferred | |||
| 订单已确认 | 这一关键里程碑表示销售订单已通过包括信用审批在内的所有初始检查,并已进入履约阶段。通常可根据订单状态变为“Awaiting Shipping”或“Scheduled”等状态推断。 | ||
| 为什么重要 此活动是计算“Average Order Confirmation Time”的关键里程碑,也标志着流程从订单录入交接至履约阶段。 获取位置 根据销售订单头或行状态变为表示可履约的值推断,例如“Awaiting Shipping”。请检查DOO_HEADERS_ALL或DOO_FULFILL_LINES_ALL中的状态列。 采集 根据订单状态变为已确认或已排程状态时的时间戳得出。 事件类型 inferred | |||
| 货物已发运 | 此活动标志着货物已从仓库发出,正在运输至客户。Oracle Shipping处理发运确认交易时会记录此活动。 | ||
| 为什么重要 这是履约流程完成的重要里程碑,并会触发开票。它对于衡量准时发运和交付周期时间至关重要。 获取位置 这是Oracle Shipping Execution中明确记录的事件。发运确认交易会在WSH_DELIVERY_DETAILS等发运表中创建包含发运日期的记录。 采集 取自与订单行关联的交付明细记录中的“actual ship date”时间戳。 事件类型 explicit | |||
| 销售订单已创建 | 此活动标志着销售订单流程的开始,表示新销售订单录入Oracle Fusion的时刻。通常,用户在Order Management模块中保存新订单记录时,系统会明确记录此事件。 | ||
| 为什么重要 作为流程起点,此活动对于衡量整体Order to Cash周期时间和分析订单接收量至关重要。 获取位置 在销售订单记录于Order Management Cloud中创建时明确记录。请在DOO_HEADERS_ALL表中查找创建时间戳。 采集 取自销售订单头记录的创建时间戳。 事件类型 explicit | |||
| 发票已更正 | 当已创建的发票因错误或客户争议而被修改、重新开具或贷记时,就会发生此活动。通常通过创建贷项通知单或同一发票的新版本记录。 | ||
| 为什么重要 跟踪发票更正是“Invoice Rework Rate”KPI的关键,可揭示开票流程中的问题,这些问题可能延迟付款并增加管理成本。 获取位置 根据创建与原发票关联的贷项通知单,或RA_CUSTOMER_TRX_ALL表中同一发票的后续版本推断。 采集 通过识别引用先前发票交易的贷项通知单或发票得出。 事件类型 inferred | |||
| 已应用信用冻结 | 当销售订单因信用检查失败或其他信用相关问题而被系统自动或人工冻结时,就会发生此活动。通常,系统会通过订单冻结状态的变化记录此活动。 | ||
| 为什么重要 跟踪信用冻结对于识别订单处理延误原因,以及衡量信用冻结解除流程的效率至关重要。 获取位置 根据销售订单上应用冻结的记录推断。通常记录在DOO_HOLDS_ALL等与订单关联的冻结相关表中。 采集 根据订单冻结表中创建一条“Credit”冻结类型的记录推断。 事件类型 inferred | |||
| 已执行信用检查 | 表示针对客户账户执行信用检查,以评估其信用状况。这通常是订单处理工作流中的自动或人工步骤,完成后一般会记录为状态更新或已完成任务。 | ||
| 为什么重要 分析信用检查耗时有助于识别订单审批中的瓶颈,也是“Credit Check to Confirmed Time”KPI的关键依据。 获取位置 可根据销售订单的状态变化推断,例如状态变为“Pending Credit Approval”,也可从信用管理功能中的明确事件日志获取。 采集 根据订单状态变化或信用审核任务相关时间戳推断。 事件类型 inferred | |||
| 库存已预留 | 此活动表示为履行销售订单行而分配或预留实物库存。系统会锁定特定库存,确保订单准备拣货时货物可用。 | ||
| 为什么重要 跟踪此活动有助于分析“Inventory Allocation Lead Time”KPI,并识别订单确认与货物锁定之间的延误。 获取位置 此事件通常记录在库存或供应链执行模块中。可根据履约行状态更新推断库存已明细分配或预留。 采集 根据与库存预留或排程相关的履约行状态变化推断。 事件类型 inferred | |||
| 订单已取消 | 表示销售订单在完全发运前被取消。取消可能由多种原因导致,最终状态为“Cancelled”。 | ||
| 为什么重要 这是关键的例外路径。分析已取消订单有助于识别库存不足、定价问题或客户改变意向等根因,为流程改进提供依据。 获取位置 根据销售订单头或行状态变为“Cancelled”推断。使用该状态变化的时间戳记录事件。 采集 根据订单头或行状态变为“Cancelled”时的时间戳得出。 事件类型 inferred | |||
| 订单行已关闭 | 表示单个销售订单行最终关闭,说明该订单行已完成发运和开票,且不再有后续交易。系统会将行状态更新为“Closed”。 | ||
| 为什么重要 关闭订单行表示该项目的所有合同义务均已完成。分析此活动有助于识别在履约和付款完成后仍长期保持打开状态的订单。 获取位置 根据DOO_FULFILL_LINES_ALL表中履约行状态变为“Closed”推断。该状态变化的时间戳即为事件时间。 采集 根据履约行状态变为“Closed”时的时间戳得出。 事件类型 inferred | |||
| 货物已交付 | 表示客户已收到货物。此信息通常来自外部承运商,并回写至Oracle Fusion;也可以根据发运日期和标准运输时间推断。 | ||
| 为什么重要 此活动对于计算“On-Time Delivery Rate”KPI和准确衡量客户服务水平至关重要。 获取位置 这通常不是Oracle原生事件。若已建立承运商集成,则可直接获取;也可在“Goods Shipped”日期上加上标准运输时间计算得出。需要进行系统分析。 采集 根据承运商数据馈送推断,或根据发运日期加平均运输时间计算得出。 事件类型 inferred | |||
| 货物已拣选 | 表示从仓库拣选货物以履行订单。这是物流流程中的关键步骤,通常记录在仓库管理或发运模块中。 | ||
| 为什么重要 此活动让仓库运营更加透明。库存预留与拣选之间的延误可能表明仓库存在资源或流程瓶颈。 获取位置 记录在Oracle Fusion Cloud SCM(Supply Chain Management)模块中。可根据与销售订单行关联的拣货波次或拣货单状态变化推断。 采集 根据SCM模块中拣货交易的完成时间戳推断。 事件类型 inferred | |||
数据提取指南
步骤
- 进入Oracle BI Publisher:使用具有BI Administrator或BI Author权限的用户登录Oracle Fusion环境。通过Navigator菜单进入Tools > Reports and Analytics。点击“Browse Catalog”按钮,打开Business Intelligence Catalog。
- 创建新的Data Model:在BI Catalog中进入合适的文件夹,例如Shared Folders > Custom。点击“New”下拉菜单,选择“Data Model”。
- 定义SQL Query数据集:在Data Model编辑器中,点击“+”图标创建新数据集,然后选择“SQL Query”。系统将显示对话框。为数据集命名,例如“OrderToCash_EventLog”,将“Oracle BI EE”选为Data Source,并将“Standard SQL”选为SQL类型。
- 输入SQL Query:复制本文档“query”部分提供的完整SQL查询,并粘贴到SQL Query文本区域。查询包含开始日期和结束日期参数(:p_start_date和:p_end_date),BI Publisher会自动识别这些参数。
- 配置Data Model属性:粘贴查询后,点击“OK”。在Data Model编辑器左侧窗格中进入“Properties”部分。确认已勾选“Include Parameter Tags”。如有需要,也可以为日期参数设置默认值。
- 查看并保存Data Model:点击“Data”选项卡。系统可能会提示您输入日期参数值。输入较小的日期范围进行测试。点击“View”查看数据样例。如果数据显示正确,点击保存图标并使用描述性名称保存Data Model,例如“OrderToCash_EventLog_DM”。
- 根据Data Model创建报表:保存Data Model后,点击右上角的“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 Data Model和报表创建权限的角色,例如“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添加条件,以筛选特定销售订单类型。
- 性能:对于跨越多年的超大数据集,单查询方式可能运行缓慢。建议在业务低峰期运行,或拆分为更小的月度批次。请确保未在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实例。进入Tools,从菜单中选择Business Intelligence Cloud Connector。
- 创建新的Offering:在BICC控制台中,点击Configure External Storage设置目标位置。目标可以是Oracle Universal Content Management(UCM)或OCI Object Storage存储桶。确认连接信息和凭据正确。
- 启动新的提取作业:进入Manage Extract Jobs部分。点击“+”图标创建新作业,并使用描述性名称,例如ProcessMind_O2C_SalesOrder_Extract。
- 选择Data Stores(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创建一行Sales Order Created记录,再使用ClosedDate创建一行Order Closed记录。
- 将状态代码或标志映射为Order Confirmed或Order Cancelled等具体活动。
- 将所有转换后的数据合并为单个文件,并包含所需列: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 立即优化订单到收款:销售订单处理流程
轻松识别瓶颈,将订单到收款周期时间缩短30%。
无需信用卡,免费试用14天。