与信管理・債権回収データテンプレート
与信管理・債権回収データテンプレート
- 包括的な分析のための推奨属性
- プロセスディスカバリで追跡すべき主要な活動
- データ抽出の手順ガイド
与信管理・債権回収の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 与信管理プロセス内で特定の時点で発生したビジネスイベントまたはタスクの名称。 | ||
| 説明 この属性は、「請求書生成済み」、「督促手続き開始済み」、「入金受領済み」など、請求書ライフサイクルにおける単一のステップを記述します。各活動は、ケースを前進させる個別のイベントを表します。 活動の順序と頻度を分析することは、プロセスマイニングのコアです。これにより、実際のプロセスフローを発見し、ケースが滞るボトルネックを特定し、活動が繰り返されるリワーク ループを検出し、実際のプロセスを設計されたプロセスまたは理想的なプロセスと比較するのに役立ちます。活動名は、プロセスマップを構築し、ステップ間のトランジションタイムを計算するための基本です。 その重要性 この属性はプロセスマップ内のステップを定義し、請求書ライフサイクルの最初から最後までを可視化し分析することを可能にします。 取得元 これは、Oracle Fusion Financials内の様々なビジネスイベントから導出される概念的なフィールドであり、多くの場合、売掛金(AR)やAdvanced Collectionsのようなモジュールからのトランザクション ステータス、イベント日付、または特定の行動をマッピングすることによって構築されます。 例 請求書生成済み督促手続き開始入金確認済み紛争登録済み | |||
| イベント日時 EventTime | 活動が発生した正確な日付と時刻であり、イベントのタイムスタンプとして機能します。 | ||
| 説明 イベント時間、またはタイムスタンプは、活動が行われた正確な瞬間を記録します。正確なプロセスフローを構築するために、イベントを時系列に並べ替えるのに不可欠です。正確なタイムスタンプがなければ、イベントの順序を正しく判断することはできません。 分析では、この属性は活動間の期間とサイクルタイムを計算するために使用され、パフォーマンス測定にとって極めて重要です。例えば、紛争解決サイクルタイムや請求書支払サイクルタイムなどのKPIを計算するために使用されます。また、異なる期間にわたるプロセスパフォーマンスのトレンド分析も可能にします。 その重要性 このタイムスタンプは、イベントの順序付け、サイクルタイムと期間の計算、および経時的なプロセスパフォーマンスの分析に不可欠です。 取得元 請求書作成のためのRA_CUSTOMER_TRX_ALLのTRX_DATEや、債権回収アクションの作成日など、Oracle Fusion Financialsの複数のテーブルのさまざまな日付フィールドから派生します。 例 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 | |||
| ソースシステム SourceSystem | データの発生源となるシステム。 | ||
| 説明 この属性は、イベントデータが記録された元のアプリケーション(ソースシステム)を特定するためのものです。複雑なIT環境においては、1つのエンドツーエンドのプロセスに複数のシステムが関わることが珍しくありません。 ソースシステムを明確にすることは、データガバナンスの強化やトラブルシューティング、さらにはデータの背景(コンテキスト)を正確に把握するために不可欠です。複数のシステムのイベントを1つのプロセスビューに統合した際、それらを適切に識別し、データの履歴(データリネージ)を透明化するのに役立ちます。 その重要性 データの出所を明確にし、データ検証、ガバナンス、およびプロセスの技術的背景を理解するために不可欠です。 取得元 これは通常、データ抽出時にレコードの出所を識別するために追加される静的な値です。 例 Oracle Fusion FinancialsOracle AROracle Collections | |||
| 最終データ更新 LastDataUpdate | この`イベント`の`データ`が`ソースシステム`から`最終的`に`更新`または`抽出`された`時刻`を示す`タイムスタンプ`です。 | ||
| 説明 この属性は、最新のデータ抽出の日時を示します。これはビジネスプロセス自体の一部ではありませんが、分析中のデータの鮮度を理解するために不可欠なメタデータ フィールドです。 アナリストは、このタイムスタンプを使用して、最新の情報で作業していることを確認し、データのカットオフ ポイントを理解します。データ ガバナンスや、ダッシュボードやレポートにおけるデータの鮮度に関するユーザーの期待値を管理するために不可欠です。 その重要性 データがどれだけ最新であるかを示し、アナリストやステークホルダーがデータの適時性と関連性を認識していることを保証します。 取得元 この値は、データ抽出およびロード(ETL)プロセス中に各レコードに生成され、スタンプされます。 例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| `督促``レベル` DunningLevel | 請求書に適用された督促手続きのステージまたはレベル。 | ||
| 説明 督促レベルは、債権回収リマインダーの強度を示し、通常時間とともにエスカレートします。例えば、レベル1は穏やかなメールリマインダーである一方、レベル3は正式な書面や電話である可能性があります。 督促レベルによってプロセスを分析することで、督促戦略の有効性を評価できます。督促の有効性ダッシュボードは、この属性を使用して各督促ステップから支払いへのコンバージョン率を可視化します。これにより、企業はどの督促アクションが最も効果的であるかを判断し、リマインダーのタイミングとコンテンツを微調整して債権回収を最大化できます。 その重要性 回収努力のエスカレーション ステージを追跡します。これは督促戦略の有効性を評価するために不可欠です。 取得元 このデータはOracle Advanced Collectionsモジュール内で管理されます。IEX_DUNNINGSのような督促履歴に関連するテーブルで見つけることができます。 例 レベル1:リマインダーレベル2:警告レベル3:最終通知 | |||
| ユーザー User | 活動を実行したユーザーまたはシステム ID。 | ||
| 説明 この属性は、与信限度額の承認、支払のポスト、紛争の解決など、活動を実行する特定の従業員または自動システム ユーザーを識別します。 ユーザーごとの活動を分析することは、ワークロードの分散、個々のパフォーマンス、およびコンプライアンスを理解するために不可欠です。自動活動の場合、システムプロセスの関与を追跡するのに役立ちます。また、ユーザーの行動をモニタリングすることで、トレーニングの必要性や潜在的な不正行為を特定するためにも使用できます。 その重要性 プロセス活動を特定の個人または自動化システムに割り当て、パフォーマンス追跡、ワークロード分析、および監査を可能にします。 取得元 Oracle Fusion Financials全体の様々な取引および履歴テーブルの「CREATED_BY」または「LAST_UPDATED_BY」カラムから取得されます。 例 jsmithar_specialist_1SYSTEM_AUTOMATION | |||
| 回収担当者 Collector | 請求書に割り当てられた回収エージェントの氏名またはID。 | ||
| 説明 回収担当者は、支払遅延請求書の回収活動を管理する個人またはチームです。この割り当ては、債権回収ワークフローにおける重要なステップです。 この属性は、債権回収部門内のパフォーマンス管理およびリソース割り当てにとって極めて重要です。回収担当者ごとの成果を分析することで、管理者は回収担当者の有効性を評価し、研修ニーズを特定し、ワークロードのバランスを取ることができます。回収担当者割り当て有効性ダッシュボードは、異なる回収担当者間の成功率とサイクルタイムを比較するために、この属性に直接依存します。 その重要性 個々の回収担当者またはチームのパフォーマンス分析を可能にし、リソース配分を最適化し、全体的な回収効率を向上させるのに役立ちます。 取得元 この情報は通常、Oracle Advanced Collectionsモジュールに保存されており、多くの場合、IEX_CASES_ALL_Bのようなテーブルまたは関連する割り当てテーブルに格納されています。 例 John Smithジェーン・ドウ回収チームA | |||
| 支払期日 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 | |||
| ビジネスユニット BusinessUnit | 請求書を発行した特定の事業単位または組織エンティティ。 | ||
| 説明 大規模な組織では、業務が複数のビジネスユニットに分かれていることがよくあります。この属性は、請求書がどのビジネスユニットに関連付けられているかを識別します。 ビジネスユニットごとにプロセスを分析することで、組織の異なる部門間でのパフォーマンス比較が可能になります。これにより、与信および債権回収ポリシーがどのように適用されているかにおける不整合を強調し、どのビジネスユニットが売掛金の管理により効果的であるかを明らかにできます。これは、ベストプラクティスを共有し、必要に応じてプロセスを標準化するのに役立ちます。 その重要性 異なる組織単位間でのパフォーマンス比較を可能にし、ベストプラクティスと改善領域を特定するのに役立ちます。 取得元 組織構造にリンクされているORG_IDフィールドを介して、RA_CUSTOMER_TRX_ALLテーブルで利用可能です。 例 BU North AmericaBU EMEAグローバルサービス部門 | |||
| 与信限度額 CreditLimitAmount | 顧客に承認された最大与信額。 | ||
| 説明 与信限度額は、企業が特定の顧客に対して持つことを許容するクレジットの総額です。これは与信審査プロセス中に決定されます。 この属性は、与信限度額決定影響ダッシュボードにとって不可欠です。承認された与信限度額と、その後の支払行動および貸倒を関連付けることで、企業は与信リスクポリシーの有効性を評価できます。分析により、過度に高い与信限度額が貸倒率の増加に寄与しているかどうかが明らかになり、与信承認プロセスを改善するのに役立ちます。 その重要性 承認された与信限度額を支払い結果および償却と関連付けることにより、与信リスクポリシーの有効性を評価するために不可欠です。 取得元 これはOracle Credit Managementで管理されており、通常、HZ_CUST_PROFILE_AMTSのような顧客クレジット プロファイルに関連するテーブルに保存されています。 例 10000.0050000.00250000.00 | |||
| 償却済み IsWrittenOff | 請求書が貸倒として償却されたかどうかを示す真偽値フラグです。 | ||
| 説明 これは、企業が回収不能と判断し、アクティブな売掛金から削除した請求書を識別する導出フラグです。これは通常、請求書にとって最終的かつ望ましくない結果です。 この属性は、請求書貸倒率KPIと関連する分析ダッシュボードの計算に不可欠です。これにより、アナリストは失敗した回収の母集団を分離し、顧客セグメントや請求書金額など、貸倒のリスクが高いことに関連する可能性のある共通の特性を特定できます。このインサイトは、与信ポリシーと回収戦略の改善に役立ちます。 その重要性 債権回収失敗のケースを明確に特定し、貸倒の根本原因を分析し、償却率を計算するために不可欠です。 取得元 これは、「請求書貸倒済み」活動がケースに存在するか、または請求書ステータスが「貸倒済み」であるかをチェックすることによって導出される計算フィールドです。 例 truefalse | |||
| 処理時間 ProcessingTime | アクティビティに実作業として費やした時間。 | ||
| 説明 処理時間とは、特定のタスクに対する実際の作業時間であり、待機時間やアイドル時間は含まれません。これは、活動の終了時刻と開始時刻の差として計算されます。 この指標は、ケースに積極的に取り組んだ時間と、何かが起こるのを待っていた時間を区別するのに役立つため、パフォーマンス分析において非常に貴重です。例えば、「紛争解決」活動自体の非効率性を、紛争がアサインされるのを待っていた時間とは別に浮き彫りにすることができます。これは、債権回収ワークフロー効率のようなダッシュボードをサポートします。 その重要性 各活動の実際の作業時間を測定し、活動間の時間だけでなく、特定のタスク内の非効率性を特定するのに役立ちます。 取得元 これは、開始時刻を終了時刻から減算することで導出される計算メトリックです(終了時刻 - 開始時刻)。 例 864003600604800 | |||
| 延滞日数 DaysOverdue | 請求書が期日を過ぎた日数。 | ||
| 説明 この計算されたメトリックは、未払い請求書の遅延度合いを定量化します。これは、現在の日付(オープン請求書の場合)または支払日(クローズ済み請求書の場合)と期日との差として計算されます。 支払遅延日数は、エージング分析と債権回収努力の優先順位付けにとって重要な尺度です。これは、支払遅延請求書エージング&ステータス ダッシュボードにおける主要なメトリックであり、請求書はエージング バケット(例:1-30日、31-60日)にグループ化されます。これにより、債権回収チームは最も古く、リスクの高い債務に集中することができます。 その重要性 支払遅延の程度を定量化し、債権回収の優先順位付けとエージング分析を行うための主要なメトリックとなります。 取得元 これは計算フィールドです。ロジックは以下の通りです:オープン請求書の場合は現在日付 - 期日、クローズ済み請求書の場合は支払日 - 期日。 例 1545920 | |||
| 支払い確約日 PromiseToPayDate | 顧客が支払いを約束した日付。 | ||
| 説明 債権回収活動中に、顧客が将来の特定の日付に支払いを約束する場合があります。この「支払い約束日」は、この約束を追跡するために記録されます。 この属性は、債権回収ワークフローを管理し、顧客の約束の信頼性を評価するために重要です。支払い約束日と実際の支払い受領日を比較することで、回収担当者はこれらの約束の成功率を評価できます。これにより、キャッシュフローをより正確に予測し、約束が破られた場合に債権回収活動をエスカレートする時期を決定するのに役立ちます。 その重要性 顧客の支払確約を追跡し、キャッシュインフローを予測し、債権回収交渉の有効性を管理するのに役立ちます。 取得元 Oracle Advanced Collectionsモジュール内に保存されており、IEX_PROMISES_Tのようなテーブルに格納されている可能性が高いです。 例 2023-06-102023-06-252023-07-05 | |||
| 支払条件 PaymentTerms | 支払期日を規定する合意済みの条件。 | ||
| 説明 支払条件は、「Net 30」や「Net 60」のように、顧客が支払うべき条件を定めます。これらの条件は、請求書の期日を計算するために使用されます。 支払条件ごとの支払実績を分析すると、興味深いパターンが明らかになることがあります。例えば、支払期間が短い顧客ほど支払いが遅れる可能性が高い、といった傾向です。この情報は、与信ポリシーの見直しと最適化、および異なる回収戦略のための顧客セグメント化に活用できます。特定の請求書がなぜ延滞になるのかを理解するための貴重な文脈を提供します。 その重要性 合意された支払スケジュールに関するコンテキストを提供し、異なる与信条件における支払行動の分析を可能にします。 取得元 これはRA_TERMSテーブルに保存され、請求書トランザクションにリンクされます。 例 支払条件:正味30日支払条件:正味60日受領時支払い | |||
| 期限超過 IsOverdue | 請求書が支払い期日を過ぎているかどうかを示す真偽値フラグです。 | ||
| 説明 これは、請求書の支払遅延ステータスを示す単純な真偽値のフラグを提供する導出属性です。通常、現在日付(または支払日)と請求書の期日を比較することで計算されます。 このフラグは、分析におけるフィルタリングとセグメンテーションに非常に役立ちます。アナリストは、支払遅延請求書の母集団を迅速に分離して、そのプロセスパス、回収活動の有効性、およびその他の特性を調査することができます。支払遅延請求書エージング&ステータス ダッシュボードなど、支払遅延債務の管理に焦点を当てたダッシュボードとKPIの作成を簡素化します。 その重要性 債権回収プロセスにおける主要な焦点である、すべての支払遅延請求書を特定および分析するためのシンプルで明確なフラグを提供します。 取得元 これは計算フィールドです。ロジックは以下の通りです:もし現在日付 > 期日 かつ ステータス != '支払済み' ならば True さもなくば False。 例 truefalse | |||
| 紛争理由 DisputeReason | 顧客が請求書に異議を唱えるために提供した理由。 | ||
| 説明 顧客が請求書に異議を唱える場合、通常、「価格間違い」、「商品破損」、「重複請求」などの理由を提示します。この属性はその理由を捕捉します。 紛争理由を分析することは、根本原因分析のキーとなります。これにより、注文管理や請求のようなアップストリームプロセスで発生し、支払遅延につながる繰り返しの問題を特定するのに役立ちます。異なる紛争理由の頻度を分類・追跡することで、企業はこれらの根本原因を修正するための的を絞った行動をとることができ、紛争解決サイクルタイムの短縮という目標をサポートします。 その重要性 請求書紛争の根本原因を特定するのに役立ち、将来の紛争を防ぐために、上流プロセスへのプロアクティブな改善を可能にします。 取得元 この情報は、紛争管理が正式化されている場合、通常、Oracle Advanced CollectionsモジュールまたはOracle Channel Revenue Managementモジュールで捕捉されます。AR_DISPUTE_HISTORYのようなテーブルに存在する可能性があります。 例 数量誤り価格不一致破損品サービス未提供 | |||
| 終了日時 EndTime | 期間を伴う活動が完了した時期を示すタイムスタンプ。 | ||
| 説明 明確な開始と終了を持つ活動の場合、この属性は完了時間をキャプチャします。プロセスマイニングにおける多くのイベントは瞬間的ですが、「紛争調査」のように一定の期間にわたるものもあります。 個別の終了時間を持つことで、活動の処理時間を正確に計算できます。これは、特にアイドル期間がある場合に、次の活動の開始時間から期間を推測するよりも正確です。リソース利用状況を分析し、プロセス内でどの特定のステップが最も時間を要しているかを特定するために不可欠です。 その重要性 特定の活動にどれくらいの時間がかかるかを正確に計算でき、ボトルネックとリソース活用に関するより深い洞察を提供します。 取得元 これは多くの場合、概念的な属性です。活動に対応するソーステーブルの「最終更新」タイムスタンプまたは特定の「クローズ日付」フィールドから取得される場合があります。 例 2023-04-15T11:30:00Z2023-05-02T09:00:00Z2023-05-21T16:45:00Z | |||
| 請求書ステータス InvoiceStatus | 請求書ライフサイクルにおける現在のステータス。 | ||
| 説明 請求書ステータスは、プロセスにおける請求書の現在の状態のスナップショットを提供します。一般的なステータスには、「オープン」、「支払い済み」、「紛争中」、「期日超過」、「償却済み」などがあります。この属性は、売掛金の状態の概要を提供します。 プロセスマイニングでは、この属性は、すべての未決済延滞請求書など、特定の対象に焦点を当てるためにケースをフィルタリングするのに役立ちます。これは、延滞請求書の滞留およびステータスダッシュボードの主要な次元であり、請求書ポートフォリオの現在の状態を即座に可視化し、債権回収活動の優先順位付けに役立ちます。 その重要性 請求書の現在の状態をすばやく把握でき、債権回収活動のフィルタリングと優先順位付けを容易にします。 取得元 通常、AR_PAYMENT_SCHEDULES_ALLテーブルのSTATUSという名前のフィールドで利用可能です。 例 オープンクローズ紛争中債権回収中 | |||
| 請求通貨 InvoiceCurrency | 請求書金額の通貨単位。 | ||
| 説明 この属性は、米ドル、ユーロ、英ポンドなど、請求書の通貨を指定します。多国籍企業では、請求書は様々な通貨で発行されることがよくあります。 複数の通貨を含むデータの分析には慎重な取り扱いが必要です。この属性を使用すると、通貨によるプロセスビューのフィルタリングや、連結財務レポートに適切な為替レートを適用することができます。これにより、金銭的価値が正しく解釈され、金額の比較が同一基準で行われることが保証されます。 その重要性 多通貨環境で財務データを正確に解釈し、正確な財務分析を保証するために不可欠です。 取得元 通常、RA_CUSTOMER_TRX_ALLテーブルでINVOICE_CURRENCY_CODEとして見つかります。 例 USDEURGBPJPY | |||
与信管理・債権回収活動
| アクティビティ | 説明 | ||
|---|---|---|---|
| 入金確認済み | 顧客からの入金受領を示しますが、まだ特定の請求書に充当されていない場合があります。これは、システムで現金受領取引が作成されたときに記録されます。 | ||
| その重要性 これは債権回収プロセスにおける主要なマイルストーンであり、現金が受領されたことを示します。これと支払充当の間の時間は、内部処理効率の尺度となります。 取得元 AR_CASH_RECEIPTS_ALLテーブルのRECEIPT_DATEから明示的に取得されます。その後、領収書はAR_RECEIVABLE_APPLICATIONS_ALLを介して適用された請求書にリンクできます。 取得 AR_CASH_RECEIPTS_ALLからのRECEIPT_DATEで、アプリケーションテーブルを通じてリンクされます。 イベントタイプ explicit | |||
| 支払期日経過 | 請求書が全額支払われることなく、現在の日付が請求書の期日を過ぎたときに発生する計算イベントです。このイベントは、請求書が「現在の」ステータスから「延滞」ステータスへ移行することを示します。 | ||
| その重要性 これは、債権回収および督促プロセスをトリガーする重要なマイルストーンです。期日を過ぎた請求書の量と金額を分析することは、運転資金の管理と与信リスクの評価に不可欠です。 取得元 このイベントは、「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 | |||
| 督促手続き開始 | 支払遅延請求書に対する督促プロセスの正式な開始を表し、多くの場合、最初の公式督促状の送付を伴います。これは通常、督促バッチプロセスが実行され、請求書が含まれるときに記録されます。 | ||
| その重要性 この活動を追跡することは、督促の有効性と督促ポリシーの遵守を測定するために不可欠です。督促が支払いに至るまでにかかる時間を測定するためのベースラインを提供します。 取得元 Oracle Advanced Collectionsモジュールにログインしました。このイベントは、トランザクションIDにリンクされたIEX_DUNNINGSのようなテーブルにおける督促記録の作成日で特定されます。 取得 請求書に関連付けられたIEX_DUNNINGSテーブルのレコードの作成日。 イベントタイプ explicit | |||
| 請求書償却済み | 債権回収の取り組みを中止し、請求金額を貸倒として計上する正式な決定を表します。これは、請求書残高をゼロに調整する明確な財務取引です。 | ||
| その重要性 これは、債権回収プロセスにおける重大な失敗終点です。顧客セグメント、地域、または与信限度額ごとの貸倒を分析することは、損失を最小限に抑えるために与信ポリシーと回収戦略を改善するのに役立ちます。 取得元 貸倒または償却活動を指すRECEIVABLES_TRX_IDを持つAR_ADJUSTMENTS_ALLテーブルでの調整の作成から明示的に取得されます。 取得 償却活動タイプを持つAR_ADJUSTMENTS_ALLのレコードの作成日。 イベントタイプ explicit | |||
| 請求書生成済み | Oracle Fusion Financialsでの請求書取引記録の作成を示します。これは売掛金モジュールにおける請求書ライフサイクルの正式な開始であり、分析の主要な出発点となります。 | ||
| その重要性 これは、請求書ジャーニーの重要な開始イベントです。売掛金回収日数(DSO)や請求書支払サイクルタイムなど、すべてのその後のサイクルタイム計算は、この初期タイムスタンプに依存します。 取得元 これは、特定のTRX_NUMBER(請求書番号)について、RA_CUSTOMER_TRX_ALLテーブルのCREATION_DATEまたはTRX_DATEカラムから捕捉される明示的なイベントです。 取得 イベントのタイムスタンプはRA_CUSTOMER_TRX_ALLテーブルからのCREATION_DATEです。 イベントタイプ explicit | |||
| 与信審査完了 | 請求書に関連する顧客に対する与信評価の完了を表します。このイベントは通常、請求書作成日をその顧客アカウントの最新の与信審査完了日にリンクすることで推測され、与信関連分析のベースラインを提供します。 | ||
| その重要性 与信審査から受注までの時間を分析することで、受注から現金化までのサイクル初期段階における遅延を特定できます。これは与信承認サイクルタイムKPIを測定し、与信決定の影響を理解するための基礎となります。 取得元 請求書上の顧客(RA_CUSTOMER_TRX_ALL.BILL_TO_CUSTOMER_ID)についてHZ_CREDIT_PROFILE.LAST_CREDIT_REVIEW_DATEを照会することで推測されます。イベントのタイムスタンプは、請求書のCREATION_DATEより前のLAST_CREDIT_REVIEW_DATEです。 取得 請求書を、請求書作成前の顧客の最新の与信審査日にリンクします。 イベントタイプ inferred | |||
| 債権回収戦略割り当て済み | 延滞請求書または顧客に自動債権回収戦略が割り当てられたときに発生します。これにより、システムまたは回収担当者が従う一連のステップと活動が定義されます。 | ||
| その重要性 このイベントは、債権回収プロセスの自動化に関するインサイトを提供します。どの戦略が割り当てられ、その結果どうなったかを分析することは、異なる顧客セグメントに対する回収アプローチを最適化するのに役立ちます。 取得元 Oracle Advanced Collectionsモジュール内で記録されました。これは通常、IEX_STRATEGIESなどのテーブルまたは関連オブジェクトにおける戦略アサインメントの作成日を確認することで見つけることができます。 取得 顧客またはトランザクションにリンクされた債権回収テーブル内の戦略ワークアイテムの作成日。 イベントタイプ explicit | |||
| 担当者アクション完了 | 回収担当者によって行われた手動の行動(電話、電子メールの送信、やり取りメモの記録など)を表します。これらは債権回収モジュール内で「活動」または「やり取り」として記録されます。 | ||
| その重要性 回収担当者の行動を監視することで、手動の債権回収ワークフローの効率と有効性を測定できます。これにより、活動の頻度と支払成功との相関関係を分析できます。 取得元 Oracle Advanced CollectionsのJTF_IH_ACTIVITIESなどのインタラクションまたは活動履歴テーブルから取得され、顧客および場合によっては特定の請求書にリンクされます。 取得 関連する結果または理由コードを持つJTF_IH_ACTIVITIESのレコードの作成タイムスタンプ。 イベントタイプ explicit | |||
| 支払約束作成済み | 顧客が特定の日付に支払うことを約束した、システムに記録された正式な合意を表します。これは債権回収活動の主要な成果です。 | ||
| その重要性 支払約束とその履行率を追跡することは、回収担当者にとって重要なパフォーマンス指標です。これは、支払遅延売掛金からのキャッシュフローを予測し、回収担当者の有効性を評価するのに役立ちます。 取得元 Oracle Advanced Collectionsで明示的に作成されます。作成日はIEX_PROMISE_DETAILSテーブルから取得されます。 取得 対応する請求書について、IEX_PROMISE_DETAILSテーブルからの作成日。 イベントタイプ 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 | |||
| 請求書がクローズ済み | 請求書の未払い残高が、支払、クレジットメモの適用、または調整によってゼロになったときに発生します。これは、請求書ライフサイクルの正常な完了を示します。 | ||
| その重要性 このイベントは、プロセスの主要な成功終点として機能します。請求書のクローズをモニタリングすることは、売掛金ポートフォリオ全体の健全性を理解するために不可欠です。 取得元 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 BI Publisherにアクセス: Oracle Fusion Financials環境にログインします。ナビゲーターアイコンをクリックし、「ツール」>「レポートと分析」を選択して、レポートと分析エリアに移動します。
- 新しいデータモデルを作成: レポートと分析ペインで、「カタログの参照」ボタンをクリックします。カタログ内で、「新規」ドロップダウンメニューをクリックし、「データモデル」を選択します。
- SQLクエリデータセットを定義: データモデルエディタで、「+」アイコンをクリックして新しいデータセットを追加し、「SQLクエリ」を選択します。
- データソースを構成: 新しいデータセットウィンドウで、データセットに分かりやすい名前(例: 「CreditCollectionsEventLog」)を付けます。データソースとして「FSCM」または適切なOracle Fusionアプリケーションデータベースを選択します。SQLのタイプを「Standard SQL」に設定します。
- SQLクエリを入力: このドキュメントの「query」セクションに記載されている完全なSQLクエリをコピーし、SQLクエリテキストエリアに貼り付けます。
- クエリパラメーターを定義: クエリは、日付範囲をフィルタリングするために
:P_START_DATEや:P_END_DATEのようなパラメーターを使用します。BI Publisherはこれらを自動的に検出します。それらをユーザープロンプトとして構成し、データ型を「Date」に設定できます。 - データモデルを保存してテスト: データモデルを共有フォルダまたはカスタムフォルダに保存します。クエリが機能することを確認するには、「データ」タブに移動し、サンプルパラメーター値(例: 最近の日付範囲)を入力し、「表示」をクリックして出力データのサンプルを確認します。すべての列が正しく表示されていることを確認します。
- 新しいレポートを作成: カタログに戻り、「新規」ドロップダウンをクリックし、「レポート」を選択します。「レポートの作成」ダイアログで、「データモデルを使用」オプションを選択し、保存したデータモデルを見つけます。
- レポートプロパティを構成: レポートエディタでは、データ抽出のためにシンプルなテーブルレイアウトで十分です。デフォルトの出力形式を設定します。プロセスマイニングでは、CSVが推奨される形式です。これを行うには、「リストを表示」をクリックし、「出力形式」リストで「CSV」を見つけて、そのチェックボックスをオンにします。ユーザーエクスペリエンスを簡素化するために、他の形式のチェックを外すこともできます。
- レポートを保存: レポートをデータモデルと同じフォルダに保存します。
- 抽出をスケジュール: 抽出を自動化するには、レポートをスケジュールできます。レポートを開き、「アクション」をクリックし、「スケジュール」を選択します。スケジュールの頻度(例: 毎日)を設定し、出力形式をCSVとして指定し、コンテンツサーバーディレクトリまたはFTP経由の外部サーバーなどの配信先を定義します。
設定
- 前提条件: レポートを作成・実行するユーザーは、適切なBIロール(例: 「BI管理者」または「BI作成者」)と、基盤となる財務テーブル(AR、IEX、HZ、JTF)にアクセスするためのデータセキュリティ権限を持っている必要があります。
- データソース: クエリは、通常「FSCM」という名前の主要なアプリケーションデータベースに対して実行されるべきです。
- 日付範囲パラメーター: データ量を制限するために、
:P_START_DATEと:P_END_DATEパラメーターを使用することが不可欠です。初期テストでは、1ヶ月などの短い範囲を使用してください。本番稼働では、3~6ヶ月のローリング期間が一般的です。 - フィルタリング: 大規模な組織の場合、一度に1つのビジネスユニットのデータを処理するため、
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'