您的信用管理和催收数据模板
您的信用管理和催收数据模板
- 全面分析所需的推荐属性
- 流程发现需要跟踪的关键活动
- 分步数据提取指南
信用管理与催收属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间 EventTime | 活动发生的准确日期和时间,即事件的时间戳。 | ||
| 说明 事件时间或时间戳记录活动发生的准确时刻。它对于按时间顺序排列事件、构建准确的流程至关重要。没有准确的时间戳,就无法正确确定事件顺序。 在分析中,该属性用于计算活动之间的持续时间和周期时间,是绩效衡量的重要依据。例如,它可用于计算争议解决周期时间或发票付款周期时间等KPI,也支持分析不同时期的流程绩效趋势。 为什么重要 该时间戳对于排列事件顺序、计算周期时间和持续时间,以及分析流程绩效随时间的变化至关重要。 获取位置 源自Oracle Fusion Financials各表中的不同日期字段,例如RA_CUSTOMER_TRX_ALL中的TRX_DATE(用于发票创建),或催收操作的创建日期。 示例 2023-04-15T10:00:00Z2023-05-01T14:30:00Z2023-05-20T09:15:22Z | |||
| 发票编号 InvoiceNumber | 每张客户发票的唯一标识符,也是信用管理流程的主要案例标识。 | ||
| 说明 发票编号是连接单笔应收账款相关所有事件和活动的核心键,从发票创建一直到最终结算或核销。它能够完整呈现发票的端到端生命周期。 在流程挖掘分析中,该属性用于重建每张发票的处理历程。将所有相关活动归入同一发票编号后,分析人员可以可视化流程,识别常见路径和偏差路径,并衡量整个流程或争议解决、付款过账等特定阶段的周期时间。 为什么重要 这是连接所有相关流程步骤的核心案例ID,可重建并分析每张发票从开具到结清的完整路径。 获取位置 在Oracle Fusion Financials中,该标识通常位于RA_CUSTOMER_TRX_ALL表的TRX_NUMBER字段。 示例 INV-1005679884321AR-2023-04-112 | |||
| 活动名称 ActivityName | 信用管理流程中某一时点发生的具体业务事件或任务名称。 | ||
| 说明 该属性描述发票生命周期中的单个步骤,例如“发票已生成”“催收过程已启动”或“已收到付款”。每项活动都代表一个推动案例向前发展的独立事件。 分析活动的顺序和频率是流程挖掘的核心。它有助于发现实际流程,识别案例停滞的瓶颈,检测活动重复发生的返工循环,并将实际流程与设计流程或理想流程进行比较。活动名称是构建流程图和计算步骤间转换时间的基础。 为什么重要 该属性定义流程图中的步骤,用于可视化和分析发票从开始到结束的生命周期。 获取位置 这是一个概念字段,源自Oracle Fusion Financials中的各种业务事件,通常通过映射应收款(AR)和Advanced Collections等模块中的交易状态、事件日期或具体操作构建。 示例 生成发票催缴程序已启动已收到付款争议已登记 | |||
| 最后数据更新时间 LastDataUpdate | 表示该事件数据最近一次从源系统刷新或提取时间的时间戳。 | ||
| 说明 该属性标记最近一次数据提取的日期和时间。它属于元数据字段,不是业务流程本身的一部分,但对于了解所分析数据的新鲜度至关重要。 分析人员使用该时间戳确认当前使用的是最新信息,并了解数据截止时间。它对于数据治理以及管理用户和利益相关者对仪表板、报告数据时效性的预期十分重要。 为什么重要 反映数据的新鲜度,确保分析人员和利益相关者了解数据的时效性和相关性。 获取位置 该值在数据提取和加载(ETL)过程中生成,并写入每条记录。 示例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| 源系统 SourceSystem | 数据来源的系统。 | ||
| 说明 该属性标识记录事件数据的源应用。在复杂的IT环境中,一项端到端流程可能涉及多个系统。 明确源系统对于数据治理、问题排查和理解数据背景十分重要。当多个系统的数据合并到同一流程视图时,它有助于区分不同系统产生的事件,确保数据血缘清晰。 为什么重要 明确数据来源,对于数据验证、治理和理解流程的技术背景至关重要。 获取位置 通常在数据提取期间添加静态值,用于标识记录来源。 示例 Oracle Fusion FinancialsOracle AROracle Collections | |||
| 催收人员 Collector | 分配给该发票的催收代理姓名或ID。 | ||
| 说明 催收人员是负责管理逾期发票催收活动的个人或团队。这项分配是催收工作流中的关键步骤。 该属性对于催收部门的绩效管理和资源分配至关重要。通过分析每位催收人员的结果,管理者可以评估工作效果、识别培训需求并平衡工作量。催收人员分配效果仪表板直接依赖该属性,用于比较不同催收人员的成功率和周期时间。 为什么重要 支持分析个人或团队催收人员的绩效,帮助优化资源分配并提升整体催收效率。 获取位置 该信息通常存储在Oracle Advanced Collections模块中,例如IEX_CASES_ALL_B或相关分配表。 示例 John SmithJane DoeCollections Team A | |||
| 催缴级别 DunningLevel | 应用于发票的催缴程序阶段或级别。 | ||
| 说明 催缴级别表示催收提醒的强度,通常会随时间逐步升级。例如,级别1可能是温和的电子邮件提醒,级别3可能是正式信函或电话催收。 按催缴级别分析流程,有助于评估催缴策略的效果。催缴效果仪表板使用该属性,展示从每个催缴步骤到付款的转化率。企业可以据此确定最有效的催缴措施,并优化提醒的时间和内容,以提高回款效果。 为什么重要 跟踪催收工作的升级阶段,对于评估催缴策略效果至关重要。 获取位置 该数据在Oracle Advanced Collections模块中管理,可在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 | |||
| 客户编号 CustomerNumber | 与发票关联的客户唯一标识符。 | ||
| 说明 客户编号将发票关联到具体客户账户,使分析人员能够根据客户属性对信用和催收流程进行分组分析。 通过客户编号,分析人员可以调查某些客户是否持续延迟付款、提出更多争议或需要更多催收工作。这些信息对于制定针对客户的催收策略、调整信用条款和识别高风险客户群体至关重要,也直接支持按客户群体分析发票核销率等分析。 为什么重要 支持按客户细分流程,帮助识别模式、风险和制定定制化催收策略的机会。 获取位置 通常位于RA_CUSTOMER_TRX_ALL表的BILL_TO_CUSTOMER_ID字段,并关联至HZ_CUST_ACCOUNTS。 示例 CUST-0012389455ACME-CORP-US | |||
| 客户群体 CustomerSegment | 根据规模、行业或战略重要性等标准,将客户划分到特定群组。 | ||
| 说明 客户群体是根据共同特征对客户进行分组的分类属性。群体可以按“战略客户”“中小企业”“大型企业”等因素定义,也可以按“制造业”或“零售业”等行业定义。 该属性适合进行对比分析。分析人员可以比较不同群体的流程绩效,例如某一群体是否争议率更高或付款周期更长。这些洞察有助于根据各群体的具体需求和风险制定信用政策与催收策略,并支持发票核销率分析等仪表板。 为什么重要 支持高效的对比分析,揭示不同客户群体在流程绩效和风险方面的差异。 获取位置 通常在客户主数据(HZ_CUST_ACCOUNTS或相关表)中维护,也可根据收入或行业等客户属性推导。 示例 大型企业中小企业政府战略合作伙伴 | |||
| 用户 User | 执行该活动的用户或系统ID。 | ||
| 说明 该属性标识负责执行活动的具体员工或自动化系统用户,例如批准信用额度、过账付款或解决争议的人员或系统。 按用户分析活动,对于了解工作量分配、个人绩效和合规情况至关重要。对于自动化活动,它有助于跟踪系统流程的参与情况,也可通过监控用户行为识别培训需求或潜在的欺诈活动。 为什么重要 将流程活动归因至具体人员或自动化系统,从而支持绩效跟踪、工作负载分析和审计。 获取位置 来源于Oracle Fusion Financials各类交易表和历史表中的“CREATED_BY”或“LAST_UPDATED_BY”列。 示例 jsmithar_specialist_1SYSTEM_AUTOMATION | |||
| 业务单元 BusinessUnit | 开具发票的具体业务单元或组织实体。 | ||
| 说明 大型组织通常划分为多个业务单元。该属性标识发票所属的业务单元。 按业务单元分析流程,可以比较组织不同部分的绩效,发现信用和催收政策执行中的差异,并识别应收款管理更有效的业务单元。这有助于推广最佳实践,并在需要时推动流程标准化。 为什么重要 支持比较不同组织单元的绩效,帮助识别最佳实践和改进方向。 获取位置 可通过RA_CUSTOMER_TRX_ALL表中的ORG_ID字段获取,该字段关联组织结构。 示例 BU North AmericaBU EMEA全球服务事业部 | |||
| 争议原因 DisputeReason | 客户提出发票争议的原因。 | ||
| 说明 客户对发票提出争议时,通常会说明原因,例如“价格错误”“货物损坏”或“发票重复”。该属性记录具体原因。 分析争议原因是根因分析的关键。它有助于识别订单管理或开票等上游流程中的重复问题,这些问题可能导致付款延迟。通过分类并跟踪不同争议原因的发生频率,企业可以采取有针对性的措施解决根因,从而缩短争议解决周期时间。 为什么重要 帮助识别发票争议的根因,推动主动改进上游流程,避免未来再次发生争议。 获取位置 如果争议管理已正式纳入流程,该信息通常记录在Oracle Advanced Collections或Oracle Channel Revenue Management模块中,也可能位于AR_DISPUTE_HISTORY等表。 示例 数量错误价格差异货物损坏未提供服务 | |||
| 付款承诺日期 PromiseToPayDate | 客户承诺付款的日期。 | ||
| 说明 在催收过程中,客户可能承诺在未来某个日期付款。系统会记录该“付款承诺日期”以跟踪这一承诺。 该属性对于管理催收工作流和评估客户承诺的可靠性十分重要。通过比较付款承诺日期与实际收款日期,催收人员可以评估承诺兑现率。它有助于更准确地预测现金流,并在客户未履行承诺时决定何时升级催收措施。 为什么重要 跟踪客户付款承诺,帮助预测现金流入并管理催收协商的效果。 获取位置 存储在Oracle Advanced Collections模块中,可能位于IEX_PROMISES_T等表。 示例 2023-06-102023-06-252023-07-05 | |||
| 付款条款 PaymentTerms | 约定的付款条件,用于规定付款到期时间。 | ||
| 说明 付款条款定义客户应付款的条件,例如“净30天”或“净60天”。这些条款用于计算发票到期日。 按付款条款分析付款绩效,可以发现有价值的规律。例如,付款期限较短的客户可能更容易逾期。这些信息可用于审查和优化信用政策,并为客户划分不同的催收策略,从而更好地理解发票逾期的原因。 为什么重要 提供约定付款计划的背景,支持分析不同信用条款下的付款行为。 获取位置 存储在RA_TERMS表中,并与发票交易关联。 示例 30天账期60天账期收款时到期 | |||
| 信用额度 CreditLimitAmount | 为客户批准的最高信用金额。 | ||
| 说明 信用额度是企业愿意为特定客户承担的总信用风险敞口,在信用审核过程中确定。 该属性对于Credit Limit Decision Impact仪表板至关重要。将批准的信用额度与后续付款行为和核销情况关联起来,企业可以评估信用风险政策的有效性。通过分析还可以发现,过高的信用额度是否导致坏账率上升,从而改进信用审批流程。 为什么重要 将批准的信用额度与付款结果和核销情况关联起来,对于评估信用风险政策的有效性至关重要。 获取位置 该数据在Oracle Credit Management中管理,通常存储于与客户信用档案相关的表中,例如HZ_CUST_PROFILE_AMTS。 示例 10000.0050000.00250000.00 | |||
| 发票币种 InvoiceCurrency | 发票金额所使用的币种。 | ||
| 说明 该属性指定发票币种,例如USD、EUR或GBP。在跨国组织中,发票通常使用多种币种开具。 分析多币种数据需要谨慎处理。该属性支持按币种筛选流程视图,或应用正确汇率进行合并财务报告,确保正确解读金额,并在同一口径下比较金额。 为什么重要 对于正确解读多币种环境中的财务数据和确保财务分析准确性至关重要。 获取位置 通常位于RA_CUSTOMER_TRX_ALL表的INVOICE_CURRENCY_CODE字段。 示例 USDEURGBPJPY | |||
| 发票状态 InvoiceStatus | 发票在生命周期中的当前状态。 | ||
| 说明 发票状态反映发票当前处于流程中的哪个阶段。常见状态包括“未结”“已付款”“争议中”“逾期”或“已核销”。该属性提供应收款状态的高层概览。 在流程挖掘中,该属性可用于筛选案例,聚焦特定群体,例如所有未结逾期发票。它是逾期发票账龄与状态仪表板的关键维度,可即时展示发票组合当前状态,帮助确定催收优先级。 为什么重要 快速概览发票当前状态,便于筛选并确定催收工作的优先级。 获取位置 通常位于AR_PAYMENT_SCHEDULES_ALL表的STATUS字段。 示例 未结已关闭有争议催收中 | |||
| 是否已核销 IsWrittenOff | 表示发票是否已作为坏账核销的布尔标记。 | ||
| 说明 这是一个派生标记,用于识别企业认定为无法收回、并已从活跃应收账款中移除的发票。这通常是发票最终且不理想的结果。 该属性对于计算Invoice Write-Off Rate KPI及相关分析仪表板至关重要。分析人员可以筛选出催收失败的发票,识别可能与较高核销风险相关的共同特征,例如客户细分或发票金额。这些洞察可用于改进信用政策和催收策略。 为什么重要 清晰识别催收失败案例,对于分析坏账根因和计算核销率至关重要。 获取位置 这是一个计算字段,通过检查案例中是否存在“Invoice Written Off”活动,或发票状态是否为“Written Off”得出。 示例 truefalse | |||
| 是否逾期 IsOverdue | 表示发票是否已超过付款到期日的布尔标记。 | ||
| 说明 这是一个派生属性,用于简单表示发票是否逾期,取值为true或false。通常通过比较当前日期(或付款日期)与发票到期日计算得出。 该标记非常适合用于分析中的筛选和分组。分析人员可以快速筛选出逾期发票,研究其流程路径、催收活动的有效性及其他特征。它还简化了逾期债务管理相关仪表板和KPI的创建,例如Overdue Invoice Aging & Status仪表板。 为什么重要 提供清晰简明的标记,用于识别和分析所有逾期发票,这是催收流程的主要关注对象。 获取位置 这是一个计算字段,逻辑为:IF CurrentDate > DueDate AND Status != 'Paid' THEN True ELSE False。 示例 truefalse | |||
| 结束时间 EndTime | 表示某项具有持续时间的活动完成时间的时间戳。 | ||
| 说明 对于具有明确开始和结束时间的活动,该属性记录活动完成时间。流程挖掘中的许多事件是瞬时发生的,但“Dispute Investigation”等活动可能会持续一段时间。 单独记录结束时间,可以准确计算活动处理时长。与根据下一项活动的开始时间推算持续时间相比,这种方式更准确,尤其是在存在空闲时段时。它对于分析资源利用率,以及识别流程中耗时最长的具体步骤至关重要。 为什么重要 支持准确计算具体活动的耗时,帮助深入了解瓶颈和资源利用率。 获取位置 这通常是一个概念性属性,可能来源于源表中的“last updated”时间戳,或与该活动对应的特定“close date”字段。 示例 2023-04-15T11:30:00Z2023-05-02T09:00:00Z2023-05-21T16:45:00Z | |||
| 逾期天数 DaysOverdue | 发票超过到期日的天数。 | ||
| 说明 该计算指标用于量化未付款发票的逾期时长。对于未结发票,计算当前日期与到期日之差;对于已结发票,计算付款日期与到期日之差。 逾期天数是账龄分析和催收工作优先级排序的重要指标。它是Overdue Invoice Aging & Status仪表板中的核心指标,发票会按账龄区间分组,例如1至30天、31至60天。这有助于催收团队优先处理账龄最长、风险最高的债务。 为什么重要 量化付款延迟程度,是催收优先级排序和账龄分析的核心指标。 获取位置 这是一个计算字段,逻辑为:未结发票使用CurrentDate - DueDate,已结发票使用PaymentDate - DueDate。 示例 1545920 | |||
信用管理与催收活动
| 活动 | 说明 | ||
|---|---|---|---|
| 付款到期日已过 | 当当前日期超过发票到期日且发票尚未全额支付时发生的计算事件。该事件标志着发票从“未逾期”转为“逾期”状态。 | ||
| 为什么重要 这是触发催收和催缴流程的关键里程碑。分析超过到期日的发票数量和金额,对于管理营运资金和评估信用风险至关重要。 获取位置 通过将系统当前日期与AR_PAYMENT_SCHEDULES_ALL表中的DUE_DATE进行比较计算该事件,适用于STATUS为“OP”(未结)的发票。 采集 计算事件:当SYSDATE>AR_PAYMENT_SCHEDULES_ALL.DUE_DATE时发生。 事件类型 calculated | |||
| 付款已核销 | 表示将已收到的付款核销到具体发票,从而减少发票未结余额。这一步正式建立付款与发票之间的关联。 | ||
| 为什么重要 该活动对于确认发票已付款至关重要,也是未偿销售天数(DSO)和付款过账周期计算的真正终点。 获取位置 这是从AR_RECEIVABLE_APPLICATIONS_ALL表中的APPLY_DATE明确获取的事件,该表将现金收款与客户交易(发票)关联。 采集 相关发票在AR_RECEIVABLE_APPLICATIONS_ALL中的APPLY_DATE。 事件类型 explicit | |||
| 催缴程序已启动 | 表示针对逾期发票正式启动催缴流程,通常包括发送第一封正式催缴函。通常在催缴批处理运行并纳入该发票时记录。 | ||
| 为什么重要 跟踪该活动对于衡量催缴效果和政策执行情况至关重要。它提供了衡量催缴促成付款所需时间的基准。 获取位置 记录在Oracle Advanced Collections模块中。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)和发票付款周期时间,都取决于这一初始时间戳。 获取位置 这是从RA_CUSTOMER_TRX_ALL表中特定TRX_NUMBER(Invoice Number)的CREATION_DATE或TRX_DATE列直接捕获的事件。 采集 事件时间戳为RA_CUSTOMER_TRX_ALL表中的CREATION_DATE。 事件类型 explicit | |||
| 争议已登记 | 表示客户已正式对发票提出部分或全部异议。通常通过发票付款计划的状态变更记录。 | ||
| 为什么重要 该活动是争议解决流程的起点。分析从登记到解决所需的时间,对于识别延迟现金回收的瓶颈至关重要。 获取位置 根据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 | |||
| 付款承诺已创建 | 表示系统中记录的一项正式协议,即客户承诺在指定日期付款。这是催收活动的重要结果。 | ||
| 为什么重要 跟踪付款承诺及其履约率,是衡量催收人员绩效的重要指标。这有助于预测逾期应收款带来的现金流,并评估催收人员的工作效果。 获取位置 在Oracle Advanced Collections中明确创建。创建日期取自IEX_PROMISE_DETAILS表。 采集 对应发票在IEX_PROMISE_DETAILS表中的创建日期。 事件类型 explicit | |||
| 催收人员操作已完成 | 表示催收人员执行的手动操作,例如拨打电话、发送电子邮件或记录互动备注。这些操作会在催收模块中记录为“活动”或“互动”。 | ||
| 为什么重要 监控催收人员的操作有助于衡量手动催收工作流的效率和效果,并分析活动频率与付款成功之间的关联。 获取位置 从Oracle Advanced Collections中的互动或活动历史表获取,例如JTF_IH_ACTIVITIES,这些记录与客户及可能的具体发票关联。 采集 JTF_IH_ACTIVITIES中具有相关结果或原因代码的记录创建时间戳。 事件类型 explicit | |||
| 催收策略已分配 | 当系统为逾期发票或客户分配自动催收策略时发生。该策略定义系统或催收人员将执行的一系列步骤和活动。 | ||
| 为什么重要 该事件反映催收流程的自动化程度。分析分配的策略及其结果,有助于针对不同客户群体优化催收方式。 获取位置 记录在Oracle Advanced Collections模块中。通常可通过IEX_STRATEGIES等表或相关对象中的策略分配创建日期找到。 采集 催收表中与客户或交易关联的策略工作项创建日期。 事件类型 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 | |||
| 完成信用审核 | 表示与发票关联的客户已完成信用评估。通常通过将发票创建日期与该客户账户最近一次信用审核完成日期关联来推断此事件,为信用相关分析提供基准。 | ||
| 为什么重要 分析从信用审核到下单的时间,有助于识别订单到收款周期初始阶段的延迟。这是衡量Credit Approval Cycle Time KPI和了解信用决策影响的基础。 获取位置 通过查询发票客户的HZ_CREDIT_PROFILE.LAST_CREDIT_REVIEW_DATE推断,该客户由RA_CUSTOMER_TRX_ALL.BILL_TO_CUSTOMER_ID标识。事件时间戳为早于发票CREATION_DATE的LAST_CREDIT_REVIEW_DATE。 采集 将发票关联至发票创建前客户最近一次信用审核日期。 事件类型 inferred | |||
提取指南
步骤
- 访问Oracle BI Publisher:登录您的Oracle Fusion Financials环境。点击Navigator图标,然后选择Tools > Reports and Analytics,进入Reports and Analytics区域。
- 创建新的数据模型:在Reports and Analytics窗格中,点击“Browse Catalog”按钮。在目录中点击“New”下拉菜单,然后选择“Data Model”。
- 定义SQL Query数据集:在Data Model编辑器中,点击“+”图标添加新数据集,然后选择“SQL Query”。
- 配置数据源:在新数据集窗口中,为数据集设置描述性名称,例如“CreditCollectionsEventLog”。选择“FSCM”或相应的Oracle Fusion应用数据库作为数据源。将SQL类型设置为“Standard SQL”。
- 输入SQL Query:复制本文档“query”部分提供的完整SQL查询,并粘贴到SQL Query文本区域。
- 定义查询参数:查询使用
:P_START_DATE和:P_END_DATE等参数筛选日期范围。BI Publisher会自动识别这些参数。您可以将其配置为用户提示,并将数据类型设置为“Date”。 - 保存并测试数据模型:将数据模型保存到共享文件夹或自定义文件夹中。要验证查询是否正常运行,请进入“Data”选项卡,输入示例参数值,例如近期日期范围,然后点击“View”查看示例输出数据。确保所有列均正确显示。
- 创建新报告:返回目录,点击“New”下拉菜单,然后选择“Report”。在“Create Report”对话框中,选择“Use Data Model”选项,并找到刚刚保存的数据模型。
- 配置报告属性:在报告编辑器中,使用简单表格布局即可提取数据。设置默认输出格式。对于流程挖掘,建议使用CSV格式。点击“View a List”,在“Output Formats”列表中找到“CSV”并勾选。您也可以取消选择其他格式,以简化使用体验。
- 保存报告:将报告保存到与数据模型相同的文件夹中。
- 安排提取任务:您可以安排报告运行,以实现自动提取。打开报告,点击“Actions”,然后选择“Schedule”。配置运行频率,例如每天,指定输出格式为CSV,并设置交付目标,例如内容服务器目录或通过FTP连接的外部服务器。
配置
- 前提条件:创建并运行报告的用户必须拥有适当的BI角色,例如“BI Administrator”或“BI Author”,以及访问底层Financials表(AR、IEX、HZ、JTF)所需的数据安全授权。
- 数据源:查询应针对主应用数据库运行,该数据库通常名为“FSCM”。
- 日期范围参数:必须使用
:P_START_DATE和:P_END_DATE参数限制数据量。初始测试时,请使用较小的范围,例如一个月。生产运行通常使用3至6个月的滚动周期。 - 筛选:对于大型组织,可以考虑在
invoices_base公用表表达式的WHERE子句中添加BU_NAME(业务单元名称)参数,以便一次处理一个业务单元的数据。 - 性能注意事项:该查询会连接多个大型交易表。在没有筛选条件的情况下运行较宽日期范围,可能导致BI Publisher执行时间过长或超时。请安排报告在业务低峰期运行。
- 输出格式:确保默认或计划输出格式为CSV。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' 立即优化您的信用管理和催收流程
在Oracle Fusion中将周期时间缩短30%,改善财务状况。
无需信用卡,几分钟即可开始。