您的信用管理与催收数据模板
您的信用管理与催收数据模板
- 全面分析的推荐属性
- 用于流程发现的关键跟踪活动
- 分步数据提取指南
信用管理与催收属性
| 名称 | 描述 | ||
|---|---|---|---|
| Event 时间 EventTime | 活动发生的精确日期和时间,作为事件的 timestamp。 | ||
| 描述 Event Time(即 timestamp)记录了活动发生的精确时刻。这对于按时间顺序排列事件以构建准确的流程流至关重要。如果没有准确的 timestamp,就无法正确确定事件序列。 在分析中,此属性用于计算活动之间的持续时间和周期时间,这对于绩效衡量非常关键。例如,它被用于计算“争议解决周期”或“发票付款周期”等 KPI,同时也支持分析不同时间段内的流程绩效趋势。 为何重要 此 timestamp 对于事件排序、计算周期时间和持续时间以及分析随时间变化的流程绩效至关重要。 获取方式 派生自 Oracle Fusion Financials 表中的各种日期字段,例如用于发票生成的 RA_CUSTOMER_TRX_ALL 中的 TRX_DATE,或催收动作的创建日期。 示例 2023-04-15T10:00:00Z2023-05-01T14:30:00Z2023-05-20T09:15:22Z | |||
| 发票编号 InvoiceNumber | 每张客户发票的唯一标识符,作为信用管理流程的主要 case 标识符。 | ||
| 描述 发票号码是关联单个应收账款所有相关事件和活动的核心 key,涵盖从创建到最终结清或核销的全过程。它支持实现发票生命周期的完整端到端视图。 在 Process Mining 分析中,此属性用于重建每张发票的处理路径。通过在单个发票号码下对所有相关活动进行分组,分析人员可以实现流程流的可视化,识别常规路径和偏差路径,并衡量整个流程或特定阶段(如争议解决或付款过账)的周期时间。 为何重要 这是连接所有相关流程步骤的核心 Case ID,支持重建和分析每张发票从开具到结清的完整路径。 获取方式 此标识符通常位于 Oracle Fusion Financials 的 RA_CUSTOMER_TRX_ALL 表中的 TRX_NUMBER 列。 示例 INV-1005679884321AR-2023-04-112 | |||
| 活动名称 ActivityName | 在信用管理流程中的特定时间点发生的业务事件或任务的名称。 | ||
| 描述 此属性描述了发票生命周期中的单个步骤,例如“发票已生成”、“催收程序已启动”或“已收到付款”。每个活动都代表一个推动 case 进展的独立事件。 分析活动的顺序和频率是 Process Mining 的核心。它有助于揭示真实的流程流,识别 case 停滞的瓶颈,检测活动重复的返工循环,并将实际流程与设计流程或理想流程进行对比。活动名称是构建流程图和计算步骤间转换时间的基础。 为何重要 此属性定义了流程图中的各个步骤,支持对发票从开始到结束的生命周期进行可视化分析。 获取方式 这是一个概念性字段,源自 Oracle Fusion Financials 中的各种业务事件,通常通过对应收账款 (AR) 和高级催收等模块中的交易状态、事件日期或具体操作进行映射而构建。 示例 已生成发票催收程序已启动已收到付款争议已登记 | |||
| 最后数据更新 LastDataUpdate | 指示该事件数据最近一次从源系统刷新或提取的时间戳。 | ||
| 描述 此属性记录最近一次 data 提取的日期和时间。它是一个元数据字段,不属于业务流程本身,但对于了解所分析 data 的新鲜度至关重要。 分析人员利用此 timestamp 来确认他们使用的是最新信息,并了解 data 的截止点。这对于 data 治理以及在仪表板和报表中管理用户对 data 及时性的预期非常关键。 为何重要 指示数据的实时程度,确保分析师和利益相关者了解数据的时效性和相关性。 获取方式 此值在 data 提取和加载 (ETL) 过程中生成并标记在每条记录上。 示例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| 源系统 SourceSystem | data 的来源系统。 | ||
| 描述 此属性标识记录事件 data 的源应用程序。在复杂的 IT 环境中,一个端到端流程可能涉及多个系统。 指定源系统对于 data 治理、故障排除以及理解 data 背景非常重要。当来自不同系统的事件被整合到单一流程视图中时,它有助于区分这些事件,确保 data 血缘关系清晰可见。 为何重要 明确 data 来源,这对于 data 验证、治理以及理解流程的技术背景至关重要。 获取方式 这通常是在 data 提取期间添加的静态值,用于标识记录的来源。 示例 Oracle Fusion FinancialsOracle 应收账款Oracle 催收模块 | |||
| 催款等级 DunningLevel | 应用于发票的催收程序阶段或级别。 | ||
| 描述 “催收级别”指示催收提醒的力度,通常随时间推移而升级。例如,级别 1 可能只是温和的邮件提醒,而级别 3 则可能是正式信函或电话催收。 按催收级别分析流程有助于评估催收策略的有效性。“催收效力仪表板”利用该属性将每个催收步骤到付款的转化率可视化。这使企业能够确定哪些催收动作最有效,并微调提醒的时机和内容,从而实现回款最大化。 为何重要 追踪催收工作的升级阶段,这对于评估催收策略的有效性至关重要。 获取方式 此数据在 Oracle 高级催收模块中管理,可以在 IEX_DUNNINGS 等催收历史相关表中找到。 示例 级别 1:提醒级别 2:警告级别 3:最终通知 | |||
| 到期日期 DueDate | 发票的应付到期日期。 | ||
| 描述 到期日是合同约定的关键付款日期属性。它是衡量付款及时性的基准。 此属性是识别逾期发票和计算逾期天数的基础。它是决定何时启动催收程序的首要输入项,并用于计算 DSO 等 KPI。此外,它对于创建对未偿债务进行分类的账龄报告也必不可少。 为何重要 作为判断发票是否逾期的基准,触发催收活动并支持账龄分析。 获取方式 可在 AR_PAYMENT_SCHEDULES_ALL 表中的 DUE_DATE 字段找到。 示例 2023-05-302023-06-152023-07-01 | |||
| 发票金额 InvoiceAmount | 发票的总货币价值。 | ||
| 描述 发票金额代表开给客户的货物或服务的总价值。这是理解流程财务影响的关键属性。 在分析中,发票金额用于确定催收优先级,使精力集中在高价值逾期发票上。它还用于根据交易金额分析付款行为,并计算核销带来的财务影响。诸如“发票核销率分析”之类的仪表板依靠此数值来评估财务损失的规模。 为何重要 为流程提供财务背景,支持优先处理高价值发票,并分析流程低效对资金造成的财务影响。 获取方式 此信息可从 AR_PAYMENT_SCHEDULES_ALL 表中获得,该表存储了发票的应付金额。 示例 5000.001250.75250000.00 | |||
| 客户细分 CustomerSegment | 根据规模、行业或战略重要性等对客户进行的分类。 | ||
| 描述 “客户细分”是一个分类属性,它根据共同特征对客户进行分组。细分维度可以包括“战略客户”、“中小企业”、“大型企业”,或按行业划分为“制造业”或“零售业”等。 该属性对于对比分析非常有用。它允许分析师比较不同细分市场的流程绩效,例如查看某一细分市场是否具有更高的争议率或更长的付款周期。这种洞察有助于针对每个细分市场的特定需求和风险量身定制信用政策和催收策略,为“发票核销率分析”等仪表板提供支持。 为何重要 支持强大的对比分析,揭示不同客户群体的流程绩效和风险差异。 获取方式 通常在客户主数据(HZ_CUST_ACCOUNTS 或相关表)中管理,或根据收入、行业等客户属性派生。 示例 大型企业中小企业政府战略合作伙伴 | |||
| 客户编号 CustomerNumber | 与发票关联的客户唯一标识符。 | ||
| 描述 客户编号将发票与特定的客户账户关联起来。这使得基于客户属性对信用和催收流程进行细分和分析成为可能。 通过引入客户编号,分析人员可以调查哪些客户经常逾期、提出更多争议或需要更多催收投入。这些信息对于制定定制化的催收策略、调整信用条款以及识别高风险客户群体至关重要。它直接支持“按客户群细分的发票核销率分析”等深度分析。 为何重要 支持按客户对流程进行细分,有助于识别模式、风险和机会,从而制定量身定制的催收策略。 获取方式 通常位于 RA_CUSTOMER_TRX_ALL 表中的 BILL_TO_CUSTOMER_ID,用于关联 HZ_CUST_ACCOUNTS。 示例 CUST-0012389455ACME-CORP-US | |||
| 收款专员 Collector | 分配给该发票的催收人员姓名或 ID。 | ||
| 描述 催收员是负责管理逾期发票催收活动的个人或团队。该分配是催收 workflow 中的关键步骤。 此属性对于催收部门的绩效管理和资源分配至关重要。通过分析每位催收员的成果,管理层可以评估其工作成效、识别培训需求并平衡工作负载。“催收员分配有效性”仪表板直接依赖此属性来比较不同催收员的成功率和周期时间。 为何重要 支持对单个催收员或团队进行绩效分析,有助于优化资源配置并提高整体催收效率。 获取方式 此信息通常存储在 Oracle 高级催收模块中,多见于 IEX_CASES_ALL_B 或相关的分配表。 示例 约翰·史密斯Jane Doe收款 A 组 | |||
| 用户 User | 执行该活动的 penchant 用户或系统 ID。 | ||
| 描述 此属性标识负责执行某项活动的具体员工或自动系统用户,例如批准信用额度、过账付款或解决争议。 按用户分析活动对于了解工作量分配、个人绩效和合规性至关重要。对于自动化活动,它有助于跟踪系统流程的参与情况。此外,通过监控用户行为,还可以识别培训需求或潜在的欺诈行为。 为何重要 将流程活动归因于特定个人或自动化系统,支持绩效跟踪、工作量分析和审计。 获取方式 源自 Oracle Fusion Financials 各类交易和历史表中的 'CREATED_BY' 或 'LAST_UPDATED_BY' 列。 示例 jsmithar_specialist_1SYSTEM_AUTOMATION | |||
| 业务单元 BusinessUnit | 开具发票的具体业务单位或组织实体。 | ||
| 描述 在大型组织中,业务通常划分为多个业务单元。该属性标识与发票关联的业务单元。 按业务单元分析流程可以比较组织不同部分的绩效。它能突出信用和催收政策在执行中的不一致性,并揭示哪些业务单元在应收账款管理方面更有效。这有助于分享最佳实践并在必要时实现流程标准化。 为何重要 支持不同组织单元之间的绩效对比,有助于识别最佳实践和改进领域。 获取方式 可通过 RA_CUSTOMER_TRX_ALL 表中的 ORG_ID 字段获取,该字段连接到组织结构。 示例 北美业务单元欧洲、中东及非洲业务单元全球服务部门 | |||
| 争议原因 DisputeReason | 客户提出的发票争议原因。 | ||
| 描述 当客户对发票提出争议时,通常会提供理由,例如“定价错误”、“货物损坏”或“重复发票”。此属性会捕捉该原因。 分析争议原因是进行根因分析的关键。它有助于识别订单管理或计费等上游流程中导致付款延迟的重复性问题。通过对不同争议原因的频率进行分类和追踪,企业可以采取针对性措施解决这些根源问题,从而支持缩短“争议解决周期时间”的目标。 为何重要 有助于识别发票争议的根本原因,从而主动改进上游流程以防止未来发生争议。 获取方式 如果争议管理已正式化,此类信息通常在 Oracle 高级催收或 Oracle 渠道收入管理模块中捕捉,可能存放在 AR_DISPUTE_HISTORY 等表中。 示例 数量错误价格差异货物损坏未提供服务 | |||
| 付款承诺日期 PromiseToPayDate | 客户承诺付款的日期。 | ||
| 描述 在催收活动中,客户可能会承诺在未来某个日期付款。这一“付款承诺日期”将被记录下来以跟踪该承诺。 该属性对于管理催收工作流和评估客户承诺的可靠性非常重要。通过比较承诺付款日期与实际收款日期,催收人员可以评估这些承诺的成功率。这有助于更准确地预测现金流,并决定在承诺未兑现时何时升级催收力度。 为何重要 追踪客户的付款承诺,有助于预测现金流入并评估催收谈判的效果。 获取方式 存储在 Oracle 高级催收模块中,通常位于 IEX_PROMISES_T 等表中。 示例 2023-06-102023-06-252023-07-05 | |||
| 付款条款 PaymentTerms | 指明付款到期日的约定条款。 | ||
| 描述 付款条款定义了客户应遵循的付款条件,例如“Net 30”或“Net 60”,这些条款用于计算发票到期日。 按付款条款分析付款绩效可以揭示一些规律。例如,账期较短的客户可能更容易发生逾期。这些信息可用于审查和优化信用政策,并针对不同客户群体制定差异化的催收策略。它为理解特定发票逾期的深层原因提供了重要背景。 为何重要 提供已定付款计划的背景信息,支持对不同信用条款下的付款行为进行分析。 获取方式 此项存储在 RA_TERMS 表中,并与发票交易关联。 示例 净 30 天净 60 天见票即付 | |||
| 信用额度金额 CreditLimitAmount | 为客户批准的最高信用额度。 | ||
| 描述 信用额度是公司愿意承担的针对特定客户的总信用风险敞口,在信用审查过程中确定。 此属性对于“信用额度决策影响”仪表板至关重要。通过将批准的信用额度与后续的付款行为和核销情况进行关联,企业可以评估其信用风险政策的有效性。分析可能会揭示过高的信用额度是否导致了坏账率上升,从而帮助完善信用审批流程。 为何重要 通过将获批的信用额度与付款结果和核销情况关联,来评估信用风险政策的有效性,这一点至关重要。 获取方式 此项在 Oracle 信用管理模块中管理,通常存储在与客户信用概况相关的表中,如 HZ_CUST_PROFILE_AMTS。 示例 10000.0050000.00250000.00 | |||
| 发票币种 InvoiceCurrency | 发票金额所使用的货币。 | ||
| 描述 此属性指定发票的币种,如美元、欧元或英镑。在跨国组织中,发票通常以多种货币开具。 分析涉及多种货币的 data 需要谨慎处理。此属性允许按币种筛选流程视图,或应用正确的汇率进行合并财务报告。它确保了货币价值被正确解读,并使金额比较建立在一致的基础上。 为何重要 对于在多货币环境中正确解读财务数据并确保财务分析的准确性至关重要。 获取方式 通常位于 RA_CUSTOMER_TRX_ALL 表中的 INVOICE_CURRENCY_CODE 列。 示例 美元EURGBPJPY | |||
| 发票状态 InvoiceStatus | 发票在其生命周期中的当前状态。 | ||
| 描述 “发票状态”反映了发票目前在流程中所处的阶段。常见状态包括“未结”、“已付”、“争议中”、“逾期”或“已核销”。该属性提供了应收账款状态的高层概览。 在流程挖掘中,此属性对于过滤案例以关注特定群体(例如所有未结的逾期发票)非常有用。它是“逾期发票账龄与状态”仪表板中的关键维度,可让您立即掌握发票组合的当前状况,并协助确定催收活动的优先级。 为何重要 提供发票当前状态的快速概览,便于对催收工作进行筛选和优先级排序。 获取方式 通常可在 AR_PAYMENT_SCHEDULES_ALL 表名为 STATUS 的字段中找到。 示例 未结已结案争议中催收中 | |||
| 处理时间 ProcessingTime | 在一项活动上实际投入工作的时间长度。 | ||
| 描述 处理时间衡量特定任务的实际工作时长,不包括任何等待或空闲时间。其计算方法为活动结束时间与开始时间的差值。 该指标对绩效分析具有极高价值,因为它能区分是在积极处理 case 还是在等待后续环节。例如,它可以突出“争议解决”活动本身的低效,而不计入争议等待分配的时间。这为“催收工作流效率”等仪表板提供了核心数据支持。 为何重要 衡量各环节的实际工作时长,帮助精准定位具体任务内部的低效问题,而非仅仅关注任务之间的间隔时间。 获取方式 这是一个计算指标,通过结束时间减去开始时间 (EndTime - StartTime) 得出。 示例 864003600604800 | |||
| 是否已核销 IsWrittenOff | 一个布尔标志,指示发票是否已作为呆账核销。 | ||
| 描述 这是一个派生标识,用于识别公司认为无法收回并已从活跃应收账款中移除的发票。这通常是发票生命周期中最终且不理想的结果。 此属性对于计算“发票核销率”KPI 及其相关的分析仪表板至关重要。它允许分析人员隔离催收失败的样本,以识别共同特征(如客户细分或发票金额),这些特征可能与较高的核销风险相关。此类洞察可用于改进信用政策和催收策略。 为何重要 清晰识别催收失败的案例,这对于分析坏账根本原因和计算核销率至关重要。 获取方式 这是一个计算字段,通过检查 case 是否存在“发票已核销”活动或发票状态是否为“已核销”得出。 示例 truefalse | |||
| 是否逾期 IsOverdue | 一个布尔标志,指示发票是否已超过付款截止日期。 | ||
| 描述 这是一个派生属性,提供关于发票逾期状态的简单 True/False 指示。通常通过将当前日期(或付款日期)与发票到期日进行比较来计算。 此标识对于分析中的筛选和细分非常有用。它允许分析人员快速锁定逾期发票群体,以研究其流程路径、催收活动的有效性及其他特征。它简化了专注于管理逾期债务的仪表板和 KPI 的创建过程,例如“逾期发票账龄与状态”仪表板。 为何重要 为识别和分析所有逾期发票提供简单明了的标记,这是催收流程的核心关注点。 获取方式 这是一个计算字段。逻辑为:如果当前日期大于到期日且状态不等于“已付”,则为 True,否则为 False。 示例 truefalse | |||
| 结束时间 EndTime | 指示具有持续时间的活动何时完成的 timestamp。 | ||
| 描述 对于具有明显开始和结束的活动,该属性记录完成时间。虽然流程挖掘中的许多事件是瞬时的,但某些事件(如“争议调查”)可能会持续一段时间。 拥有独立的结束时间可以精确计算活动处理时长。这比根据下一个活动的开始时间推断持续时间更准确,尤其是在存在空闲期时。这对于分析资源利用率以及识别流程中哪些具体步骤最耗时至关重要。 为何重要 支持准确计算特定活动所需的时长,从而对瓶颈和资源利用率有更深入的了解。 获取方式 这通常是一个概念性属性,可能源自对应活动的源表中的“最后更新”timestamp 或特定的“关闭日期”字段。 示例 2023-04-15T11:30:00Z2023-05-02T09:00:00Z2023-05-21T16:45:00Z | |||
| 逾期天数 DaysOverdue | 发票超过到期日的天数。 | ||
| 描述 这一计算指标量化了未付发票的逾期程度。其计算方法是:对于未结发票,取当前日期与到期日的差值;对于已结发票,取付款日期与到期日的差值。 逾期天数是账龄分析和确定催收优先级的关键指标。它是“逾期发票账龄与状态”仪表板中的核心指标,发票在此按账龄桶(如 1-30 天、31-60 天)进行分组。这有助于催收团队专注于时间最久、风险最高的债务。 为何重要 量化付款延迟的程度,作为确定催收优先级和进行账龄分析的核心指标。 获取方式 这是一个计算字段。逻辑为:对于未结发票,当前日期减去到期日;对于已结发票,付款日期减去到期日。 示例 1545920 | |||
信用管理与催收活动
| 活动 | 描述 | ||
|---|---|---|---|
| 付款到期日已过 | 一个计算事件,当当前日期超过发票到期日且发票未足额支付时触发。该事件标志着发票从“正常”状态转为“逾期”状态。 | ||
| 为何重要 这是触发催收程序的关键里程碑。分析超过到期日的发票数量和金额,对于管理营运资金和评估信用风险至关重要。 获取方式 此事件通过将系统当前日期与 AR_PAYMENT_SCHEDULES_ALL 表中状态为“OP”(未结)发票的 DUE_DATE 进行对比计算得出。 捕获 计算事件:当 SYSDATE > AR_PAYMENT_SCHEDULES_ALL.DUE_DATE 时触发。 事件类型 calculated | |||
| 付款已应用 | 代表将收到的款项应用于特定发票,从而冲减发票的未清余额。这是正式将付款与发票关联的步骤。 | ||
| 为何重要 此活动对于确认发票已付至关重要。它是 DSO 计算和付款过账周期的真实终点。 获取方式 这是一个明确的事件,从 AR_RECEIVABLE_APPLICATIONS_ALL 表中的 APPLY_DATE 捕捉,该表将现金回款与客户交易(发票)关联起来。 捕获 来自相关发票的 AR_RECEIVABLE_APPLICATIONS_ALL 表中的 APPLY_DATE。 事件类型 explicit | |||
| 催收程序已启动 | 代表逾期发票催收流程的正式开始,通常涉及发送第一封正式催收函。这通常在催收批处理运行并包含该发票时记录。 | ||
| 为何重要 追踪此活动对于衡量催收有效性和催收政策合规性至关重要。它提供了一个基准,用以衡量从催收开始到最终收到付款所需的时间。 获取方式 记录在 Oracle 高级催收模块中。此事件由 IEX_DUNNINGS 等表中催收记录的创建日期标记,并与交易 ID 关联。 捕获 与发票关联的 IEX_DUNNINGS 表中记录的创建日期。 事件类型 explicit | |||
| 发票已核销 | 代表正式决定停止催收并将发票金额转为坏账。这是一种明确的财务交易,会将发票余额调整为零。 | ||
| 为何重要 这是催收流程的一个关键失败终点。按客户群、地区或信用额度分析核销情况,有助于完善信用政策和催收策略,从而将损失降至最低。 获取方式 通过在 AR_ADJUSTMENTS_ALL 表中创建调整来明确捕获,其 RECEIVABLES_TRX_ID 指向坏账或核销活动。 捕获 AR_ADJUSTMENTS_ALL 表中具有核销活动类型的记录的创建日期。 事件类型 explicit | |||
| 已收到付款 | 标记收到客户款项,该款项此时可能尚未关联至特定发票。当系统创建现金收款交易时,会捕捉到此事件。 | ||
| 为何重要 这是催收流程中的重要里程碑,表明已收到现金。此事件与付款应用之间的时间间隔是衡量内部处理效率的一个指标。 获取方式 从 AR_CASH_RECEIPTS_ALL 表中的 RECEIPT_DATE 明确捕获。随后可以通过 AR_RECEIVABLE_APPLICATIONS_ALL 将收据关联到所应用的发票。 捕获 来自 AR_CASH_RECEIPTS_ALL 的 RECEIPT_DATE,通过应用表关联。 事件类型 explicit | |||
| 已生成发票 | 标记 Oracle Fusion Financials 中发票交易记录的创建。这是应收账款模块中发票生命周期的正式起点,也是流程分析的主要出发点。 | ||
| 为何重要 这是发票生命周期中至关重要的起始事件。所有后续的周期时间计算(如 DSO 和发票付款周期)都依赖于这个初始 timestamp。 获取方式 这是一个明确的事件,从特定 TRX_NUMBER(发票号码)的 RA_CUSTOMER_TRX_ALL 表中的 CREATION_DATE 或 TRX_DATE 列捕捉。 捕获 事件时间戳是 RA_CUSTOMER_TRX_ALL 表中的 CREATION_DATE。 事件类型 explicit | |||
| 争议已登记 | 指示客户已正式就发票的全部或部分内容提出争议。这通常通过发票付款计划的状态更改来捕获。 | ||
| 为何重要 此活动是争议解决流程的起点。分析从登记到解决的时间对于识别拖延回款的瓶颈 (bottleneck) 至关重要。 获取方式 根据 AR_PAYMENT_SCHEDULES_ALL 表中的状态更改推断,其中 STATUS 字段变为 'DS'(争议中)。时间戳可源自审计表或最后更新日期。 捕获 检测发票在 AR_PAYMENT_SCHEDULES_ALL.STATUS 中的状态何时变为 'DS'。 事件类型 inferred | |||
| 争议已解决 | 指示已登记的争议已调查完毕并达成解决方案。当发票的争议状态被移除时,将捕获此事件。 | ||
| 为何重要 此事件标志着争议解决周期的结束。“争议已登记”与此事件之间的时间间隔是衡量运营效率及其对现金流影响的关键 KPI。 获取方式 当 AR_PAYMENT_SCHEDULES_ALL 中的 STATUS 从 'DS'(争议中)变回 'OP'(开启)或在贷项通知单/调整后变为 'CL'(已关闭)时推断。 捕获 检测 AR_PAYMENT_SCHEDULES_ALL.STATUS 何时从 'DS' 变为其他状态。 事件类型 inferred | |||
| 信用审查已完成 | 代表已完成与该发票相关客户的信用评估。此事件通常通过将发票创建日期与该客户账户最近的信用审查完成日期相关联来推断,为信用相关分析提供基准。 | ||
| 为何重要 分析从信用审查到订单下达的时间,有助于识别订单到现金周期初期的延迟。这是衡量“信用审批周期时间”KPI 以及评估信用决策影响的基础。 获取方式 通过查询发票客户(RA_CUSTOMER_TRX_ALL.BILL_TO_CUSTOMER_ID)的 HZ_CREDIT_PROFILE.LAST_CREDIT_REVIEW_DATE 推断。事件时间戳是发票 CREATION_DATE 之前的 LAST_CREDIT_REVIEW_DATE。 捕获 将发票链接到发票创建前客户最近的信用审查日期。 事件类型 inferred | |||
| 催收动作已完成 | 代表催收人员采取的手动操作,如拨打电话、发送电子邮件或记录互动笔记。这些在催收模块中记录为“活动”或“互动”。 | ||
| 为何重要 监控催收人员的操作有助于评估手动催收 workflow 的效率和效果,支持对活动频率及其与回款成功率的相关性进行深度分析。 获取方式 从 Oracle Advanced Collections 的交互或活动历史表(如 JTF_IH_ACTIVITIES)中捕获,关联到客户及特定的发票。 捕获 JTF_IH_ACTIVITIES 表中具有相关结果或原因代码的记录的创建时间戳。 事件类型 explicit | |||
| 发票已发送给客户 | 指示发票已通过电子或纸质形式正式交付给客户。该事件可由交付模块明确记录,或从发票打印日期中推断。 | ||
| 为何重要 此活动标志着客户付款期限计时的开始。追踪此项有助于准确计算逾期天数,并分析从发票生成到通知客户之间是否存在延迟。 获取方式 可从 RA_CUSTOMER_TRX_ALL 中的 LAST_PRINTED_DATE 获取。或者,可以从与电子邮件投递系统或其他通信平台的集成日志中推断。 捕获 使用 RA_CUSTOMER_TRX_ALL 中的 LAST_PRINTED_DATE 或交付日志中的状态。 事件类型 inferred | |||
| 发票已结案 | 当发票的未清余额因付款、应用贷项通知单或调整而清零时发生。这标志着发票生命周期的圆满结束。 | ||
| 为何重要 此事件是流程的主要成功终点。监控发票的结清情况是了解应收账款组合整体健康状况的基础。 获取方式 根据 AR_PAYMENT_SCHEDULES_ALL 表中的状态更改推断,其中 STATUS 变为 'CL'(已关闭)。时间戳是此更改的 LAST_UPDATE_DATE。 捕获 检测发票在 AR_PAYMENT_SCHEDULES_ALL.STATUS 表中的状态何时变为 'CL'。 事件类型 inferred | |||
| 已分配催收策略 | 当逾期发票或客户被分配了自动催收策略时发生。这定义了系统或催收人员将执行的一系列步骤和活动。 | ||
| 为何重要 此事件提供了催收流程自动化的相关洞察。分析分配了哪些策略及其产出,有助于针对不同客户群优化催收方法。 获取方式 记录在 Oracle 高级催收模块中。通常可以通过查看 IEX_STRATEGIES 表或相关对象中策略分配的创建日期来找到。 捕获 催收表中与客户或事务处理关联的策略工作项的创建日期。 事件类型 explicit | |||
| 已创建付款承诺 | 代表系统中记录的一项正式协议,即客户承诺在特定日期付款。这是催收活动的一个关键产出。 | ||
| 为何重要 追踪付款承诺及其履行率是催收人员的关键绩效指标。它有助于预测逾期应收账款的现金流,并评估催收人员的工作成效。 获取方式 在 Oracle Advanced Collections 中明确创建。创建日期从 IEX_PROMISE_DETAILS 表中捕获。 捕获 对应发票在 IEX_PROMISE_DETAILS 表中的创建日期。 事件类型 explicit | |||
提取指南
步骤
- 访问 Oracle BI Publisher:登录您的 Oracle Fusion Financials 环境。点击“导航器”图标,然后选择“工具 > 报表和分析”,进入报表和分析区域。
- 创建新数据模型:在“报表和分析”窗格中,点击“浏览目录”按钮。在目录中,点击“新建”下拉菜单并选择“数据模型”。
- 定义 SQL 查询数据集:在数据模型编辑器中,点击“+”图标添加新数据集,并选择“SQL 查询”。
- 配置数据源:在新数据集窗口中,为数据集起一个描述性名称(例如 'CreditCollectionsEventLog')。选择 'FSCM' 或相应的 Oracle Fusion 应用程序数据库作为“数据源”。将“SQL 类型”设置为“标准 SQL”。
- 输入 SQL 查询:复制本文档“查询”部分提供的完整 SQL 查询,并将其粘贴到 SQL 查询文本区域中。
- 定义查询参数:该查询使用
:P_START_DATE和:P_END_DATE等参数来过滤日期范围。BI Publisher 会自动检测这些参数。您可以将其配置为用户提示,并将数据类型设置为“日期”。 - 保存并测试数据模型:将数据模型保存在共享或自定义文件夹中。要验证查询是否有效,请导航至“数据”选项卡,输入示例参数值(例如最近的日期范围),然后点击“查看”以查看输出数据示例。确保所有列显示正确。
- 创建新报表:返回目录,点击“新建”下拉菜单,然后选择“报表”。在“创建报表”对话框中,选择“使用数据模型”选项,并找到您刚刚保存的数据模型。
- 配置报表属性:在报表编辑器中,简单的表格布局即可满足数据提取需求。设置默认输出格式。对于流程挖掘,建议使用 CSV 格式。为此,点击“查看列表”,在“输出格式”列表中找到“CSV”,然后勾选其复选框。您可以取消勾选其他格式以简化用户体验。
- 保存报表:将报表保存在数据模型所在的同一文件夹中。
- 安排提取计划:要实现提取自动化,您可以为报表设置计划任务。打开报表,点击“操作”,然后选择“计划”。配置计划频率(例如每天),指定输出格式为 CSV,并定义交付目的地(如内容服务器目录或通过 FTP 发送至外部服务器)。
配置
- 先决条件:创建并运行报表的用户必须拥有相应的 BI 角色(例如“BI 管理员”或“BI 作者”)以及访问底层财务表(AR、IEX、HZ、JTF)的数据安全授权。
- 数据源:查询应针对主应用程序数据库(通常名为“FSCM”)运行。
- 日期范围参数:务必使用
:P_START_DATE和:P_END_DATE参数来限制数据量。初始测试时,建议使用较小范围(如一个月)。对于生产环境运行,通常采用 3 到 6 个月的滚动周期。 - 过滤:对于大型机构,考虑在
invoices_base公用表表达式的WHERE子句中添加BU_NAME(业务单元名称)参数,以便逐个处理业务单元的数据。 - 性能注意事项:该查询连接了多个大型事务表。在没有过滤器的情况下运行大日期范围的查询可能导致 BI Publisher 执行时间过长或超时。建议将报表计划在非高峰时段运行。
- 输出格式:确保默认或计划的输出格式为 CSV。这将生成一个清晰的分隔符文件,方便流程挖掘工具读取。请检查 CSV 输出属性,确保分隔符和字符编码设置正确。
a 查询示例 sql
WITH invoices_base AS (
SELECT
trx.customer_trx_id,
trx.trx_number AS InvoiceNumber,
hca.account_number AS CustomerNumber,
hcp.class_category || ':' || hcp.class_code AS CustomerSegment, -- Example of segment, may need adjustment
ps.amount_due_original AS InvoiceAmount,
coll.name AS Collector,
ps.due_date AS DueDate,
trx.creation_date AS InvoiceCreationDate,
trx.created_by AS InvoiceCreatedBy,
ps.payment_schedule_id
FROM
ra_customer_trx_all trx
JOIN ar_payment_schedules_all ps ON trx.customer_trx_id = ps.customer_trx_id
JOIN hz_cust_accounts hca ON trx.bill_to_customer_id = hca.cust_account_id
JOIN hz_customer_profiles hcp ON hca.cust_account_id = hcp.cust_account_id AND hcp.site_use_id IS NULL
LEFT JOIN iex_delinquencies_all del ON ps.payment_schedule_id = del.payment_schedule_id
LEFT JOIN JTF_RS_RESOURCE_EXTNS_VL coll ON del.collector_id = coll.resource_id
WHERE
trx.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')
AND trx.complete_flag = 'Y'
AND ps.class = 'INV'
)
-- 1. Credit Review Completed
SELECT
ib.InvoiceNumber AS "InvoiceNumber",
'Credit Review Completed' AS "ActivityName",
cr.review_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber AS "CustomerNumber",
ib.CustomerSegment AS "CustomerSegment",
ib.InvoiceAmount AS "InvoiceAmount",
ib.Collector AS "Collector",
NULL AS "DunningLevel",
ib.DueDate AS "DueDate",
cr.created_by AS "User"
FROM
invoices_base ib
JOIN
hz_credit_reviews cr ON ib.CustomerNumber = (SELECT hca.account_number FROM hz_cust_accounts hca WHERE hca.cust_account_id = cr.cust_account_id)
WHERE cr.review_date = (SELECT MAX(cr_inner.review_date) FROM hz_credit_reviews cr_inner WHERE cr_inner.cust_account_id = cr.cust_account_id AND cr_inner.review_date < ib.InvoiceCreationDate)
UNION ALL
-- 2. Invoice Generated
SELECT
ib.InvoiceNumber,
'Invoice Generated' AS "ActivityName",
trx.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
trx.created_by AS "User"
FROM
invoices_base ib
JOIN ra_customer_trx_all trx ON ib.customer_trx_id = trx.customer_trx_id
UNION ALL
-- 3. Invoice Sent To Customer
SELECT
ib.InvoiceNumber,
'Invoice Sent To Customer' AS "ActivityName",
trx.last_printed_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
trx.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ra_customer_trx_all trx ON ib.customer_trx_id = trx.customer_trx_id
WHERE trx.last_printed_date IS NOT NULL
UNION ALL
-- 4. Payment Due Date Passed
SELECT
ib.InvoiceNumber,
'Payment Due Date Passed' AS "ActivityName",
ps.due_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
'SYSTEM' AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.due_date < SYSDATE AND ps.status = 'OP'
UNION ALL
-- 5. Dunning Procedure Initiated
SELECT
ib.InvoiceNumber,
'Dunning Procedure Initiated' AS "ActivityName",
dunn.dunning_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
TO_CHAR(dunn.dunning_level) AS "DunningLevel",
ib.DueDate,
dunn.created_by AS "User"
FROM
invoices_base ib
JOIN iex_dunning_transactions dunt ON ib.customer_trx_id = dunt.transaction_id
JOIN iex_dunnings dunn ON dunt.dunning_id = dunn.dunning_id
UNION ALL
-- 6. Collection Strategy Assigned
SELECT
ib.InvoiceNumber,
'Collection Strategy Assigned' AS "ActivityName",
strat.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
strat.created_by AS "User"
FROM
invoices_base ib
JOIN iex_strategy_work_items swi ON ib.payment_schedule_id = swi.payment_schedule_id
JOIN iex_strategies_vl strat ON swi.strategy_id = strat.strategy_id
UNION ALL
-- 7. Collector Action Completed
SELECT
ib.InvoiceNumber,
task_type.name AS "ActivityName",
task.actual_end_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
res.source_name AS "User"
FROM
invoices_base ib
JOIN jtf_task_references_b ref ON ib.customer_trx_id = ref.object_id AND ref.object_type_code = 'OKC_K_HEADER'
JOIN jtf_tasks_b task ON ref.task_id = task.task_id
JOIN jtf_task_types_vl task_type ON task.task_type_id = task_type.task_type_id
JOIN jtf_rs_resource_extns_vl res ON task.owner_id = res.resource_id
WHERE task.actual_end_date IS NOT NULL
UNION ALL
-- 8. Promise To Pay Created
SELECT
ib.InvoiceNumber,
'Promise To Pay Created' AS "ActivityName",
prom.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
prom.created_by AS "User"
FROM
invoices_base ib
JOIN iex_promise_details prom ON ib.payment_schedule_id = prom.payment_schedule_id
UNION ALL
-- 9. Dispute Registered
SELECT
ib.InvoiceNumber,
'Dispute Registered' AS "ActivityName",
ps.dispute_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
ps.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.amount_in_dispute IS NOT NULL AND ps.dispute_date IS NOT NULL
UNION ALL
-- 10. Dispute Resolved
SELECT
ib.InvoiceNumber,
'Dispute Resolved' AS "ActivityName",
disp.resolution_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
disp.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_disputes_all disp ON ib.payment_schedule_id = disp.payment_schedule_id
WHERE disp.status = 'CLOSED' AND disp.resolution_date IS NOT NULL
UNION ALL
-- 11. Payment Received
SELECT
ib.InvoiceNumber,
'Payment Received' AS "ActivityName",
cr.receipt_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
cr.created_by AS "User"
FROM
invoices_base ib
JOIN ar_receivable_applications_all app ON ib.payment_schedule_id = app.applied_payment_schedule_id
JOIN ar_cash_receipts_all cr ON app.cash_receipt_id = cr.cash_receipt_id
WHERE app.status = 'APP'
UNION ALL
-- 12. Payment Applied
SELECT
ib.InvoiceNumber,
'Payment Applied' AS "ActivityName",
app.apply_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
app.created_by AS "User"
FROM
invoices_base ib
JOIN ar_receivable_applications_all app ON ib.payment_schedule_id = app.applied_payment_schedule_id
WHERE app.status = 'APP'
UNION ALL
-- 13. Invoice Closed
SELECT
ib.InvoiceNumber,
'Invoice Closed' AS "ActivityName",
ps.gl_date_closed AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
ps.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.status = 'CL' AND ps.gl_date_closed IS NOT NULL
UNION ALL
-- 14. Invoice Written Off
SELECT
ib.InvoiceNumber,
'Invoice Written Off' AS "ActivityName",
adj.apply_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
adj.created_by AS "User"
FROM
invoices_base ib
JOIN ar_adjustments_all adj ON ib.customer_trx_id = adj.customer_trx_id
JOIN ar_receivables_trx_all rt ON adj.receivables_trx_id = rt.receivables_trx_id
WHERE rt.name = '[Your Write-Off Activity Name]' -- Example: 'Bad Debt Write-off'