您的信用管理与催收数据模板
您的信用管理与催收数据模板
- 全面分析所需的建议属性
- 流程发现需跟踪的关键活动
- 分步数据提取指南
信用管理与催收属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间 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 Doe催收团队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列。 示例 jsmith应收账款专员_1系统自动化 | |||
| 业务单元 BusinessUnit | 开具发票的具体业务单元或组织实体。 | ||
| 说明 大型组织通常划分为多个业务单元。此属性用于标识发票所属的业务单元。 按业务单元分析流程,可以比较组织不同部分的表现,发现信用和催收政策执行上的差异,并了解哪些业务单元更善于管理应收账款。这有助于分享最佳实践,并在需要时统一流程。 重要性 便于比较不同组织单元的表现,发现最佳实践和改进空间。 获取途径 可通过RA_CUSTOMER_TRX_ALL表中的ORG_ID字段获取,该字段关联组织架构。 示例 北美业务单元欧洲、中东和非洲业务单元全球服务事业部 | |||
| 争议原因 DisputeReason | 客户提出发票争议时说明的原因。 | ||
| 说明 客户对发票提出争议时,通常会说明原因,例如“价格错误”“货物损坏”或“重复开票”。此属性用于记录争议原因。 分析争议原因有助于查明根本原因,并发现订单管理或开票等上游流程中的反复问题,这些问题可能导致付款延迟。企业可以对不同争议原因进行分类并跟踪其发生频率,针对根本原因采取措施,从而缩短争议解决周期时间。 重要性 帮助查明发票争议的根本原因,以便主动改进上游流程,减少后续争议。 获取途径 如果企业已建立正式的争议管理流程,此信息通常记录在Oracle Advanced Collections或Oracle Channel Revenue Management模块中,也可能存储在AR_DISPUTE_HISTORY等表中。 示例 数量错误价格差异货物损坏未提供服务 | |||
| 付款条款 PaymentTerms | 双方约定的付款期限。 | ||
| 说明 付款条款规定客户应在何时付款,例如“净30天”或“净60天”。这些条款用于计算发票到期日。 按付款条款分析付款表现,可以发现有价值的规律。例如,付款期限较短的客户可能更容易逾期。企业可据此审查并优化信用政策,并按客户群体制定不同的催收策略。这些信息也有助于了解某些发票逾期的原因。 重要性 说明双方约定的付款安排,便于分析不同信用条款下的付款行为。 获取途径 此信息存储在RA_TERMS表中,并与发票交易记录关联。 示例 净30天净60天收到即付 | |||
| 信用额度 CreditLimitAmount | 批准给客户的最高信用额度。 | ||
| 说明 信用额度是企业愿意承担的单个客户信用风险敞口上限,在信用审查过程中确定。 此属性是信用额度决策影响仪表板的重要数据。将批准的信用额度与后续付款行为和核销情况关联分析,企业可以评估信用风险政策的效果。分析还可能揭示信用额度过高是否导致坏账率上升,从而帮助改进信用审批流程。 重要性 将批准的信用额度与付款结果和核销情况关联分析,有助于评估信用风险政策的效果。 获取途径 此信息由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字段中找到。 示例 未结清已结清有争议催收中 | |||
| 承诺付款日期 PromiseToPayDate | 客户承诺付款的日期。 | ||
| 说明 催收过程中,客户可能承诺在未来某日付款。系统会记录此“承诺付款日期”,以跟踪客户的承诺。 此属性有助于管理催收工作流,并评估客户承诺的可靠性。催收人员可以将承诺付款日期与实际收款日期进行比较,评估承诺兑现率。它还有助于更准确地预测现金流,并在客户未兑现承诺时判断何时升级催收措施。 重要性 跟踪客户的付款承诺,帮助预测现金流入并评估催收协商的效果。 获取途径 此信息存储在Oracle Advanced Collections模块中,可能位于IEX_PROMISES_T等表中。 示例 2023-06-102023-06-252023-07-05 | |||
| 是否已核销 IsWrittenOff | 用于标记发票是否已作为坏账核销的布尔值。 | ||
| 说明 此派生标记用于识别企业认定为无法收回、并已从活跃应收账款中移除的发票。这通常是发票处理的最终结果,也是企业希望避免的结果。 此属性对于计算发票核销率KPI及相关分析仪表板至关重要。分析人员可以筛选出催收失败的发票,识别可能与较高核销风险相关的共同特征,例如客户群体或发票金额。企业可据此改进信用政策和催收策略。 重要性 清晰标记催收失败的案例,为分析坏账根本原因和计算核销率提供依据。 获取途径 这是一个计算字段,根据案例中是否存在“发票已核销”活动,或发票状态是否为“已核销”得出。 示例 truefalse | |||
| 是否逾期 IsOverdue | 用于标记发票是否已超过付款到期日的布尔值。 | ||
| 说明 这是一个派生属性,用于简单标记发票是否逾期。通常通过比较当前日期(或付款日期)与发票到期日计算得出。 此标记便于在分析中筛选和细分数据。分析人员可以快速筛出逾期发票,研究其流程路径、催收工作的效果及其他特征。它还简化了逾期债务管理相关仪表板和KPI的创建,例如逾期发票账龄与状态仪表板。 重要性 清晰标记所有逾期发票,便于识别和分析催收流程重点处理的对象。 获取途径 这是一个计算字段,逻辑为:IF CurrentDate > DueDate AND Status != 'Paid' THEN True ELSE False。 示例 truefalse | |||
| 结束时间 EndTime | 表示有持续时间的活动何时完成的时间戳。 | ||
| 说明 对于有明确开始和结束时间的活动,此属性记录其完成时间。流程挖掘中的许多事件都是瞬时发生的,但“争议调查”等活动可能持续一段时间。 单独记录结束时间,可以准确计算活动处理时间。与根据下一项活动的开始时间推算相比,这种方式更准确,尤其是在活动之间存在空闲时段的情况下。此属性对于分析资源利用情况,以及识别流程中耗时较长的具体步骤至关重要。 重要性 准确计算各项活动的耗时,帮助您深入了解瓶颈和资源利用情况。 获取途径 这通常是一个概念性属性,数据可能来自源表中的“最后更新时间”时间戳,或与该活动对应的特定“关闭日期”字段。 示例 2023-04-15T11:30:00Z2023-05-02T09:00:00Z2023-05-21T16:45:00Z | |||
| 逾期天数 DaysOverdue | 发票超过到期日的天数。 | ||
| 说明 此计算指标用于量化未付款发票的逾期时长。对于未结清发票,按当前日期减去到期日计算;对于已结清发票,则按付款日期减去到期日计算。 逾期天数是账龄分析和催收优先级排序的重要指标,也是逾期发票账龄与状态仪表板的核心指标。仪表板会按账龄区间对发票分组,例如1至30天、31至60天,帮助催收团队优先处理逾期时间最长、风险最高的债务。 重要性 量化付款延迟程度,是确定催收优先级和开展账龄分析的核心指标。 获取途径 这是一个计算字段。未结清发票的计算逻辑为CurrentDate - DueDate;已结清发票为PaymentDate - DueDate。 示例 1545920 | |||
信用管理与催收活动
| 活动 | 说明 | ||
|---|---|---|---|
| 付款到期日已过 | 当当前日期超过发票到期日且发票尚未全额付清时发生的计算事件。此事件标志着发票状态从“未逾期”转为“逾期”。 | ||
| 重要性 这是触发催收流程的关键节点。分析超过到期日的发票数量和金额,对于管理营运资金和评估信用风险至关重要。 获取途径 对于STATUS为“OP”(未结)的发票,将系统当前日期与AR_PAYMENT_SCHEDULES_ALL表中的DUE_DATE进行比较,以计算此事件。 采集 计算事件:当SYSDATE > AR_PAYMENT_SCHEDULES_ALL.DUE_DATE时发生。 事件类型 calculated | |||
| 付款已核销 | 表示将已收到的付款核销到具体发票,从而减少发票未结余额。这一步正式建立付款与发票之间的关联。 | ||
| 重要性 此活动对于确认发票已付款至关重要,也是计算应收账款周转天数(DSO)和付款入账周期的实际终点。 获取途径 这是从AR_RECEIVABLE_APPLICATIONS_ALL表中的APPLY_DATE直接记录的事件,该表将现金收款与客户交易(发票)关联起来。 采集 相关发票在AR_RECEIVABLE_APPLICATIONS_ALL中的APPLY_DATE。 事件类型 explicit | |||
| 发票已核销 | 表示正式决定停止催收,并将发票金额确认为坏账。这是一项明确的财务交易,会将发票余额调整为零。 | ||
| 重要性 这是催收流程以失败告终的关键节点。按客户群、地区或信用额度分析核销情况,有助于完善信用政策和催收策略,减少损失。 获取途径 直接根据AR_ADJUSTMENTS_ALL表中调整记录的创建情况获取,其中RECEIVABLES_TRX_ID指向坏账或核销活动。 采集 AR_ADJUSTMENTS_ALL表中核销活动类型记录的创建日期。 事件类型 explicit | |||
| 发票生成 | 表示Oracle Fusion Financials中发票交易记录的创建,是应收账款模块中发票生命周期的正式起点,也是分析的主要起点。 | ||
| 重要性 这是发票流转过程的关键开始事件。后续所有周期时间计算,例如应收账款周转天数(DSO)和发票付款周期时间,都取决于这一初始时间戳。 获取途径 这是从RA_CUSTOMER_TRX_ALL表中特定TRX_NUMBER(发票编号)对应的CREATION_DATE或TRX_DATE列直接记录的事件。 采集 事件时间戳取自RA_CUSTOMER_TRX_ALL表中的CREATION_DATE。 事件类型 explicit | |||
| 启动催收程序 | 表示针对逾期发票正式启动催收流程,通常包括发送第一封正式催收函。一般在催收批处理运行并纳入该发票时记录。 | ||
| 重要性 跟踪此活动对于衡量催收成效和催收政策执行情况至关重要。它提供了一个基准,用于衡量催收启动后多久能够收到付款。 获取途径 记录在Oracle Advanced Collections模块中。IEX_DUNNINGS等表中与交易ID关联的催收记录创建日期标志着此事件。 采集 与发票关联的IEX_DUNNINGS表记录的创建日期。 事件类型 explicit | |||
| 已收到付款 | 表示已收到客户款项,但款项可能尚未核销到具体发票。系统创建现金收款交易时会记录此事件。 | ||
| 重要性 这是催收流程的重要节点,表示已收到现金。此事件与付款核销之间的时间可用于衡量内部处理效率。 获取途径 直接取自AR_CASH_RECEIPTS_ALL表中的RECEIPT_DATE。之后可通过AR_RECEIVABLE_APPLICATIONS_ALL将收款关联到已核销的发票。 采集 取自AR_CASH_RECEIPTS_ALL中的RECEIPT_DATE,并通过核销相关表进行关联。 事件类型 explicit | |||
| 争议已解决 | 表示已调查登记的争议并达成解决方案。发票的争议状态被移除时会记录此事件。 | ||
| 重要性 此事件标志着争议解决周期结束。从“已登记争议”到此事件的时长,是衡量运营效率及其对现金流影响的重要KPI。 获取途径 当AR_PAYMENT_SCHEDULES_ALL中的STATUS从“DS”(争议中)变回“OP”(未结),或在贷项通知单或调整后变为“CL”(已关闭)时,可推断此事件。 采集 检测AR_PAYMENT_SCHEDULES_ALL.STATUS是否从“DS”变为其他状态。 事件类型 inferred | |||
| 信用审查完成 | 表示已完成对发票对应客户的信用评估。通常通过关联发票创建日期与该客户账户最近一次信用审查完成日期来推断此事件,为信用相关分析提供基准。 | ||
| 重要性 分析从信用审查到下单的时间,有助于发现订单到收款周期初始阶段的延误。这是衡量信用审批周期时间KPI和了解信用决策影响的基础。 获取途径 查询发票对应客户的HZ_CREDIT_PROFILE.LAST_CREDIT_REVIEW_DATE来推断。客户通过RA_CUSTOMER_TRX_ALL.BILL_TO_CUSTOMER_ID确定。事件时间戳为早于发票CREATION_DATE的LAST_CREDIT_REVIEW_DATE。 采集 将发票关联到创建发票前客户最近一次信用审查日期。 事件类型 inferred | |||
| 催收人员已完成操作 | 表示催收人员执行的手动操作,例如拨打电话、发送电子邮件或记录沟通备注。这些操作会作为“活动”或“交互”记录在催收模块中。 | ||
| 重要性 监控催收人员的操作有助于衡量手动催收工作流的效率和成效,并分析活动频率与付款成功率之间的关系。 获取途径 从Oracle Advanced Collections中的交互或活动历史表获取,例如JTF_IH_ACTIVITIES,并关联到客户,必要时关联到具体发票。 采集 JTF_IH_ACTIVITIES中具有相关结果或原因代码的记录创建时间戳。 事件类型 explicit | |||
| 发票已关闭 | 当发票未结余额变为零时发生,可能是通过付款、核销贷项通知单或调整实现。这标志着发票生命周期顺利完成。 | ||
| 重要性 此事件是流程顺利结束的主要标志。监控发票关闭情况是了解应收账款整体状况的基础。 获取途径 根据AR_PAYMENT_SCHEDULES_ALL表中的状态变更推断:STATUS变为“CL”(已关闭)。时间戳为此次变更的LAST_UPDATE_DATE。 采集 检测发票对应的AR_PAYMENT_SCHEDULES_ALL.STATUS是否变为“CL”。 事件类型 inferred | |||
| 发票已发送给客户 | 表示发票已正式送达客户,可以通过电子方式或纸质方式发送。此事件可能由交付模块直接记录,也可能根据发票打印日期推断。 | ||
| 重要性 此活动标志着客户付款期限开始计算。跟踪该活动有助于准确计算逾期天数,并分析发票生成到通知客户之间是否存在延误。 获取途径 可从RA_CUSTOMER_TRX_ALL中的LAST_PRINTED_DATE获取,也可根据电子邮件送达系统或其他通信平台的集成日志推断。 采集 使用RA_CUSTOMER_TRX_ALL中的LAST_PRINTED_DATE,或交付日志中的状态。 事件类型 inferred | |||
| 已分配催收策略 | 当系统为逾期发票或客户分配自动催收策略时发生。该策略规定系统或催收人员将遵循的一系列步骤和活动。 | ||
| 重要性 此事件反映催收流程的自动化情况。分析分配了哪些策略及其结果,有助于针对不同客户群优化催收方式。 获取途径 记录在Oracle Advanced Collections模块中。通常可通过IEX_STRATEGIES等表或相关对象中的策略分配创建日期查找。 采集 催收相关表中与客户或交易关联的策略工作项创建日期。 事件类型 explicit | |||
| 已创建付款承诺 | 表示系统中记录的一项正式约定,即客户承诺在指定日期付款。这是催收活动的一项关键结果。 | ||
| 重要性 跟踪付款承诺及其履行率是衡量催收人员绩效的重要指标,有助于预测逾期应收款带来的现金流,并评估催收人员的成效。 获取途径 在Oracle Advanced Collections中直接创建。创建日期取自IEX_PROMISE_DETAILS表。 采集 对应发票在IEX_PROMISE_DETAILS表中的创建日期。 事件类型 explicit | |||
| 已登记争议 | 表示客户已正式对全部或部分发票提出争议。通常通过发票付款计划的状态变更记录。 | ||
| 重要性 此活动是争议解决流程的起点。分析从登记到解决所需的时间,对于找出延误收款的瓶颈至关重要。 获取途径 根据AR_PAYMENT_SCHEDULES_ALL表中的状态变更推断:STATUS字段变为“DS”(争议中)。时间戳可从审计表或最后更新时间获取。 采集 检测发票对应的AR_PAYMENT_SCHEDULES_ALL.STATUS是否变为“DS”。 事件类型 inferred | |||
数据提取指南
步骤
- 访问Oracle BI Publisher:登录Oracle Fusion Financials环境。点击导航器图标,然后依次选择“工具”>“报表和分析”,进入“报表和分析”区域。
- 创建数据模型:在“报表和分析”面板中,点击“浏览目录”。在目录中点击“新建”下拉菜单,选择“数据模型”。
- 定义SQL查询数据集:在数据模型编辑器中,点击“+”图标添加数据集,然后选择“SQL查询”。
- 配置数据源:在新建数据集窗口中,为数据集填写描述性名称,例如“CreditCollectionsEventLog”。将“FSCM”或相应的Oracle Fusion应用数据库设为数据源。将SQL类型设为“标准SQL”。
- 输入SQL查询:复制本文档“query”部分提供的完整SQL查询,并粘贴到SQL查询文本框中。
- 定义查询参数:查询使用
:P_START_DATE和:P_END_DATE等参数筛选日期范围。BI Publisher会自动识别这些参数。您可以将其设为用户提示,并将数据类型设为“日期”。 - 保存并测试数据模型:将数据模型保存到共享文件夹或自定义文件夹。要验证查询是否正常运行,请转到“数据”选项卡,输入示例参数值(例如近期日期范围),然后点击“查看”检查输出数据样例。确认所有列均正确显示。
- 创建报表:返回目录,点击“新建”下拉菜单并选择“报表”。在“创建报表”对话框中,选择“使用数据模型”,然后找到刚保存的数据模型。
- 配置报表属性:在报表编辑器中,使用简单表格即可提取数据。设置默认输出格式。流程挖掘建议使用CSV格式:点击“查看列表”,在“输出格式”列表中找到“CSV”并勾选。您也可以取消其他格式,以简化使用体验。
- 保存报表:将报表保存到与数据模型相同的文件夹。
- 安排数据提取:您可以安排报表运行,以自动提取数据。打开报表,点击“操作”,然后选择“安排”。设置运行频率(例如每天),将输出格式设为CSV,并指定交付位置,例如内容服务器目录或通过FTP连接的外部服务器。
配置
- 前提条件:创建并运行报表的用户必须拥有适当的BI角色(例如“BI管理员”或“BI作者”),并获准访问底层Financials表(AR、IEX、HZ、JTF)。
- 数据源:查询应在主应用数据库上运行,该数据库通常名为“FSCM”。
- 日期范围参数:务必使用
:P_START_DATE和:P_END_DATE参数限制数据量。初次测试时,请使用较短的时间范围,例如一个月。正式运行时,通常采用滚动的3至6个月周期。 - 筛选:对于大型组织,可考虑在
invoices_base公用表表达式的WHERE子句中添加BU_NAME(业务单元名称)参数,每次处理一个业务单元的数据。 - 性能注意事项:查询会联接多个大型事务表。若不加筛选而查询较长日期范围,可能导致BI Publisher运行时间过长或超时。建议在业务低峰时段安排报表运行。
- 输出格式:确保默认或计划输出格式为CSV。该格式生成结构清晰、以分隔符分列的文件,便于流程挖掘工具读取。请检查CSV输出属性,确认分隔符和字符编码设置正确。
查询示例 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' 立即优化信用管理与催收流程
将周期时间缩短30%,改善Oracle Fusion中的财务状况。
无需信用卡,几分钟即可开始。