与信管理と債権回収のデータテンプレート
与信管理と債権回収のデータテンプレート
- 詳細な分析に推奨される属性
- プロセスの把握に必要な主要アクティビティ
- データ抽出の手順
与信管理と債権回収の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 与信管理プロセスの中で、特定の時点に発生した業務イベントまたはタスクの名称です。 | ||
| 説明 この属性は、「請求書生成」「督促手順開始」「入金受領」など、請求書のライフサイクルにおける個々のステップを表します。各アクティビティは、ケースを次の段階へ進める個別のイベントです。 アクティビティの順序や頻度の分析は、プロセスマイニングの中核です。実際のプロセスフローを明らかにし、ケースが滞留するボトルネックや、同じアクティビティが繰り返される手戻りを特定できます。また、実際のプロセスを設計上のプロセスや理想的なプロセスと比較できます。アクティビティ名は、プロセスマップの作成やステップ間の遷移時間の計算に欠かせません。 重要な理由 この属性はプロセスマップ上のステップを定義し、請求書のライフサイクルを開始から終了まで可視化して分析できるようにします。 入手先 Oracle Fusion Financials内のさまざまな業務イベントから導出する概念上の項目です。売掛金（AR）やAdvanced Collectionsなどのモジュールから、トランザクションのステータス、イベントの日付、特定のアクションを対応付けて作成することがよくあります。 例 請求書生成督促手順開始入金受領紛争登録 | |||
| イベント時刻 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 | 各顧客請求書を一意に識別する番号で、与信管理プロセスの主なケース識別子として使用します。 | ||
| 説明 請求書番号は、作成から最終的な決済または貸倒処理まで、1つの売掛債権に関するすべてのイベントとアクティビティを結び付ける中心的なキーです。請求書のライフサイクルを最初から最後まで把握できます。 プロセスマイニング分析では、この属性を使って各請求書の流れを再構成します。関連するすべてのアクティビティを1つの請求書番号にまとめることで、分析担当者はプロセスフローを可視化し、一般的な経路や通常と異なる経路を特定できます。また、プロセス全体や紛争解決、支払い計上など特定の段階にかかるサイクルタイムを測定できます。 重要な理由 関連するすべてのプロセスステップを結び付ける重要なケースIDです。請求書の発行からクローズまでの流れを再構成し、分析できます。 入手先 Oracle Fusion Financialsでは、通常、RA_CUSTOMER_TRX_ALLテーブルのTRX_NUMBERとして記録されています。 例 INV-1005679884321AR-2023-04-112 | |||
| ソースシステム SourceSystem | データの取得元となるシステムです。 | ||
| 説明 この属性は、イベントデータが記録されたソースアプリケーションを示します。複雑なIT環境では、1つのエンドツーエンドのプロセスに複数のシステムが関わる場合があります。 ソースシステムを指定すると、データガバナンスやトラブルシューティングに役立ち、データのコンテキストを把握できます。複数のシステムのイベントを1つのプロセスビューにまとめる場合も、イベントの出所を区別できるため、データの来歴が明確になります。 重要な理由 データの出所を明確にします。データの検証やガバナンス、プロセスの技術的な背景を把握するうえで重要です。 入手先 通常、レコードの取得元を識別するため、データ抽出時に静的な値として追加します。 例 Oracle Fusion FinancialsOracle売掛金Oracle債権回収 | |||
| 最終データ更新日時 LastDataUpdate | このイベントのデータがソースシステムから最後に更新または抽出された日時を示すタイムスタンプです。 | ||
| 説明 この属性には、データを最後に抽出した日時が記録されます。業務プロセス自体には含まれないメタデータ項目ですが、分析対象データの鮮度を把握するうえで重要です。 分析担当者はこのタイムスタンプを確認し、最新の情報を使っていることや、データの対象期間の終点を把握します。データガバナンスに欠かせないほか、ダッシュボードやレポートのデータがいつ時点のものか、利用者に伝える際にも役立ちます。 重要な理由 データの鮮度を示し、分析担当者や関係者がデータの適時性と関連性を把握できるようにします。 入手先 データの抽出・読み込み（ETL）処理中に生成され、各レコードに記録されます。 例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| ユーザー User | アクティビティを実行したユーザーまたはシステムのIDです。 | ||
| 説明 この属性は、与信限度額の承認、入金の記帳、異議申し立ての解決などのアクティビティを担当した従業員または自動化システムを特定します。 ユーザー別にアクティビティを分析すると、業務負荷の分布、個人の実績、コンプライアンスを把握できます。自動化されたアクティビティでは、システム処理の関与状況を追跡できます。また、ユーザーの行動を監視し、研修の必要性や不正行為の可能性を特定するのにも役立ちます。 重要な理由 アクティビティを個人または自動化システムに紐付け、実績の追跡、業務負荷の分析、監査を可能にします。 入手先 Oracle Fusion Financialsの各種取引テーブルや履歴テーブルにあるCREATED_BY列またはLAST_UPDATED_BY列から取得します。 例 jsmithar_specialist_1SYSTEM_AUTOMATION | |||
| 回収担当者 Collector | 請求書を担当する債権回収担当者の氏名またはIDです。 | ||
| 説明 回収担当者は、延滞請求書の回収活動を管理する個人またはチームです。この担当者の割り当ては、債権回収ワークフローの重要なステップです。 この属性は、債権回収部門のパフォーマンス管理やリソース配分に欠かせません。担当者ごとの結果を分析することで、管理者は回収の効果を評価し、研修の必要性を特定し、業務量のバランスを調整できます。回収担当者割り当て効果のダッシュボードでは、この属性を使って担当者ごとの成功率やサイクルタイムを比較します。 重要な理由 個人またはチームごとのパフォーマンス分析が可能になり、リソース配分の最適化と債権回収全体の効率向上に役立ちます。 入手先 この情報は通常、Oracle Advanced Collectionsモジュールに保存されており、IEX_CASES_ALL_Bなどのテーブルや、関連する割り当てテーブルに格納されています。 例 ジョン・スミスジェーン・ドウ債権回収チームA | |||
| 支払期日 DueDate | 請求書の支払期限となる日付です。 | ||
| 説明 支払期日は、契約で合意した重要な日付です。支払いが期日どおりに行われたかを判断する基準となります。 この属性は、期限超過の請求書を特定し、支払期日から何日経過しているかを計算するうえで欠かせません。督促手順を開始するタイミングの判断に使われるほか、売上債権回転日数（DSO）などの重要業績評価指標（KPI）の計算にも利用されます。また、未回収債権を滞留期間別に分類するレポートの作成にも必要です。 重要な理由 請求書が期限超過かどうかを判断する基準となり、債権回収の開始や滞留期間分析に役立ちます。 入手先 AR_PAYMENT_SCHEDULES_ALLテーブルのDUE_DATEとして確認できます。 例 2023-05-302023-06-152023-07-01 | |||
| 督促レベル DunningLevel | 請求書に適用された督促手順の段階またはレベルです。 | ||
| 説明 督促レベルは、債権回収の督促の強さを示します。通常、時間の経過とともに段階が上がります。たとえば、レベル1では穏やかなメールでの督促を行い、レベル3では正式な書面や電話で通知する場合があります。 督促レベル別にプロセスを分析すると、督促方針の有効性を評価できます。督促効果ダッシュボードでは、この属性を使って、各督促段階から支払いに至る割合を可視化します。これにより、効果の高い督促方法を特定し、回収額を最大化できるよう、督促のタイミングや内容を調整できます。 重要な理由 債権回収の段階を追跡します。督促方針の有効性を評価するうえで重要な属性です。 入手先 このデータはOracle Advanced Collectionsモジュールで管理されます。IEX_DUNNINGSなど、督促履歴に関連するテーブルで確認できます。 例 レベル1：督促レベル2：警告レベル3：最終通知 | |||
| 請求金額 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 | |||
| 与信限度額 CreditLimitAmount | 顧客に対して承認された与信の上限額です。 | ||
| 説明 与信限度額は、企業が特定の顧客に対して許容する与信総額です。与信審査の過程で決定されます。 この属性は、与信限度額の決定が与える影響を分析するダッシュボードに欠かせません。承認された与信限度額と、その後の支払い状況や償却額を関連付けることで、与信リスク方針の有効性を評価できます。分析によって、与信限度額が過度に高いことで貸倒れが増えていないかを確認し、与信承認プロセスの見直しに役立てられます。 重要な理由 承認された与信限度額と支払い結果、償却額を関連付け、与信リスク方針の有効性を評価するうえで重要です。 入手先 Oracle Credit Managementで管理され、通常はHZ_CUST_PROFILE_AMTSなど、顧客の与信プロファイルに関連するテーブルに保存されます。 例 10000.0050000.00250000.00 | |||
| 事業部門 BusinessUnit | 請求書を発行した事業部門または組織です。 | ||
| 説明 大規模な組織では、業務が複数の事業部門に分かれていることがよくあります。この属性は、請求書がどの事業部門に属するかを示します。 事業部門別にプロセスを分析すると、組織内の各部門の実績を比較できます。与信方針や債権回収方針の適用方法にばらつきがないか、また、売掛金の管理に効果を上げている事業部門はどこかを把握できます。優れた取り組みを共有し、必要に応じてプロセスを標準化するのにも役立ちます。 重要な理由 組織内の各部門の実績を比較し、優れた取り組みや改善が必要な領域を特定できます。 入手先 RA_CUSTOMER_TRX_ALLテーブルのORG_IDフィールドで確認できます。このフィールドは組織構造に関連付けられています。 例 北米事業部門EMEA事業部門グローバルサービス部門 | |||
| 償却済みかどうか IsWrittenOff | 請求書が貸倒債権として償却されたかどうかを示す真偽値です。 | ||
| 説明 この派生属性は、回収不能と判断され、売掛金の管理対象から除外された請求書を特定します。通常、請求書にとって最終的で望ましくない結果です。 この属性は、請求書の償却率に関する重要業績評価指標（KPI）の計算と、関連する分析ダッシュボードに欠かせません。回収に失敗した請求書を抽出し、顧客セグメントや請求額など、償却リスクの高さに関係する共通点を特定できます。こうした分析結果は、与信方針や債権回収方法の改善に役立ちます。 重要な理由 債権回収に失敗したケースを明確に特定でき、貸倒れの根本原因分析や償却率の計算に役立ちます。 入手先 計算フィールドです。ケースに「請求書の償却」アクティビティが存在するか、請求書のステータスが「償却済み」かどうかを確認して算出します。 例 truefalse | |||
| 支払条件 PaymentTerms | 支払期日を定めた合意条件です。 | ||
| 説明 支払条件は、顧客がいつまでに支払うかを定める条件です。たとえば、「30日以内」「60日以内」などがあります。請求書の支払期日は、この条件に基づいて計算されます。 支払条件別に支払い状況を分析すると、傾向が見えてくることがあります。たとえば、支払期間が短い顧客ほど、支払いが遅れる可能性が高い場合があります。この情報は、与信方針の見直しや改善、顧客の分類、債権回収方法の検討に役立ちます。また、特定の請求書が期限超過となる理由を理解するための背景情報にもなります。 重要な理由 合意された支払スケジュールを把握でき、与信条件ごとの支払い状況を分析できます。 入手先 RA_TERMSテーブルに保存され、請求書の取引情報に関連付けられています。 例 30日以内60日以内受領時払い | |||
| 支払約束日 PromiseToPayDate | 顧客が支払いを約束した日付です。 | ||
| 説明 債権回収の過程で、顧客が将来の日付で支払うことを約束する場合があります。この約束を追跡するために、「支払約束日」を記録します。 この属性は、債権回収のワークフローを管理し、顧客との約束がどの程度守られるかを評価するうえで重要です。支払約束日と実際の入金日を比較すると、約束が守られた割合を確認できます。また、キャッシュフローの予測精度を高め、約束が守られなかった場合に債権回収をいつ強化するか判断するのにも役立ちます。 重要な理由 顧客の支払約束を追跡し、入金の予測や債権回収の交渉状況の把握に役立ちます。 入手先 Oracle Advanced Collectionsモジュールに保存されます。IEX_PROMISES_Tなどのテーブルに記録されている可能性があります。 例 2023-06-102023-06-252023-07-05 | |||
| 期限超過かどうか IsOverdue | 請求書の支払期日を過ぎているかどうかを示す真偽値です。 | ||
| 説明 この派生属性は、請求書が期限超過かどうかを真または偽で示します。通常、現在の日付（または支払日）と請求書の支払期日を比較して算出します。 分析対象の絞り込みや分類に役立つ属性です。期限超過の請求書をすばやく抽出し、そのプロセスの流れ、債権回収の効果、その他の特徴を調べられます。期限超過債権の管理に関するダッシュボードや重要業績評価指標（KPI）の作成も簡単になります。たとえば、期限超過請求書の滞留期間・ステータスダッシュボードで利用できます。 重要な理由 期限超過の請求書を明確に特定して分析できます。債権回収プロセスの主な対象を把握するために役立ちます。 入手先 計算フィールドです。判定条件は、CurrentDate > DueDateかつStatus != 'Paid'の場合はTrue、それ以外はFalseです。 例 truefalse | |||
| 期限超過日数 DaysOverdue | 請求書の支払期日を過ぎてからの日数です。 | ||
| 説明 この計算指標は、未払いの請求書が何日遅れているかを示します。未決済の請求書では現在の日付、決済済みの請求書では支払日と支払期日の差として計算します。 期限超過日数は、滞留期間分析や債権回収の優先順位付けに欠かせない指標です。期限超過請求書の滞留期間・ステータスダッシュボードの主要指標として、請求書を滞留期間別（例：1～30日、31～60日）に分類します。これにより、債権回収チームは滞留期間が長く、リスクの高い債権に注力できます。 重要な理由 支払いの遅れを数値で把握でき、債権回収の優先順位付けや滞留期間分析の主要指標となります。 入手先 計算フィールドです。未決済の請求書ではCurrentDate - DueDate、決済済みの請求書ではPaymentDate - DueDateで算出します。 例 1545920 | |||
| 異議申し立ての理由 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 | 請求金額の通貨です。 | ||
| 説明 この属性は、請求書の通貨を示します。例として、USD、EUR、GBPがあります。多国籍の組織では、さまざまな通貨で請求書が発行されます。 複数通貨のデータを分析する際は、慎重な取り扱いが必要です。この属性を使うと、通貨別にプロセスビューを絞り込んだり、連結財務報告に適切な為替レートを適用したりできます。金額を正しく解釈し、同じ条件で比較できるようになります。 重要な理由 複数通貨を扱う環境で財務データを正しく解釈し、正確な財務分析を行うために欠かせません。 入手先 通常、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 | |||
| 入金消込 | 受領した入金を特定の請求書に消し込み、請求書の未決済残高を減らすことを示します。入金と請求書を正式に関連付けるステップです。 | ||
| 重要な理由 請求書が支払われたことを確認するうえで、このアクティビティは欠かせません。売上債権回転日数（DSO）の計算と支払い計上サイクルにおける実質的な終点です。 入手先 AR_RECEIVABLE_APPLICATIONS_ALLテーブルのAPPLY_DATEから明示的に取得するイベントです。このテーブルでは、入金と顧客トランザクション（請求書）が関連付けられています。 記録 該当する請求書に対応するAR_RECEIVABLE_APPLICATIONS_ALLのAPPLY_DATE。 イベントタイプ explicit | |||
| 支払期日超過 | 請求書が全額支払われないまま、現在の日付が支払期日を過ぎたときに発生する計算イベントです。請求書のステータスが「未延滞」から「延滞」に移行したことを示します。 | ||
| 重要な理由 債権回収や督促のプロセスを開始する重要な節目です。支払期日を過ぎた請求書の件数と金額を分析することは、運転資本の管理や信用リスクの評価に欠かせません。 入手先 AR_PAYMENT_SCHEDULES_ALLテーブルでSTATUSが「OP」（未決済）の請求書を対象に、システムの現在の日付とDUE_DATEを比較して算出します。 記録 計算イベント：SYSDATE > AR_PAYMENT_SCHEDULES_ALL.DUE_DATEとなったときに発生します。 イベントタイプ calculated | |||
| 督促手順開始 | 延滞請求書に対する督促プロセスが正式に開始されたことを示します。通常、最初の正式な督促状の送付を伴います。督促バッチ処理が実行され、請求書が対象に含まれた時点で記録されます。 | ||
| 重要な理由 このアクティビティを追跡することは、督促の効果と方針の遵守状況を測定するうえで重要です。督促開始から支払いまでにかかる期間を測るためのベースラインになります。 入手先 Oracle Advanced Collectionsモジュールに記録されます。IEX_DUNNINGSなどのテーブルにある督促レコードの作成日をトランザクションIDに関連付けて、このイベントを特定します。 記録 請求書に関連付けられたIEX_DUNNINGSテーブルのレコード作成日。 イベントタイプ explicit | |||
| 請求書の貸倒処理 | 回収を打ち切り、請求金額を貸倒債権として処理する正式な決定を示します。請求書の残高をゼロに調整する、明示的な財務トランザクションです。 | ||
| 重要な理由 債権回収プロセスにおける重大な失敗の終点です。顧客セグメント、地域、与信限度額ごとに貸倒処理を分析すると、損失を抑えるための与信方針や回収戦略の見直しに役立ちます。 入手先 AR_ADJUSTMENTS_ALLテーブルで、貸倒債権または貸倒処理のアクティビティを示すRECEIVABLES_TRX_IDを持つ調整が作成された時点で明示的に取得します。 記録 貸倒処理のアクティビティタイプを持つ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 | |||
| 支払約束の登録 | 顧客が特定の日に支払うと約束したことをシステムに正式に記録したものです。債権回収活動の重要な成果の1つです。 | ||
| 重要な理由 支払約束とその履行率の追跡は、回収担当者の重要業績評価指標です。延滞債権からのキャッシュフロー予測や、回収担当者の効果測定に役立ちます。 入手先 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の種類は「標準SQL」に設定します。
- SQLクエリを入力：「この文書の「クエリ」セクションに記載された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のパラメーターを必ず使用してください。初回のテストでは、1か月など短い期間を指定します。本番実行では、通常3～6か月のローリング期間を使用します。 - 絞り込み：大規模な組織では、
invoices_base共通テーブル式のWHERE句にBU_NAME（事業部門名）パラメーターを追加し、一度に1つの事業部門のデータを処理する方法を検討してください。 - パフォーマンスに関する考慮事項：このクエリでは、複数の大規模なトランザクションテーブルを結合します。絞り込みを行わずに広い日付範囲で実行すると、BI Publisherで実行時間が長くなったり、タイムアウトしたりすることがあります。レポートは利用の少ない時間帯に実行するようスケジュールしてください。
- 出力形式：既定またはスケジュール済みの出力形式がCSVであることを確認してください。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'始める準備はできていますか？
このテンプレートを使って分析用のデータを準備し、与信管理と債権回収のプロセスに関するインサイトを得てください。今日からプロセスの最適化に取り組みましょう。
今日から与信管理と債権回収の最適化を始めましょう
Oracle Fusionでサイクルタイムを30％短縮し、財務状況を改善しましょう。
クレジットカードは不要です。数分で利用を開始できます。