与信管理と債権回収のデータテンプレート
与信管理と債権回収のデータテンプレート
- 詳細な分析に推奨される属性
- プロセスディスカバリーで追跡すべき主要なアクティビティ
- データ抽出の手順ガイド
与信管理・債権回収の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 信用管理プロセス内の特定の時点で発生した業務イベントまたはタスクの名称です。 | ||
| 説明 この属性は、「請求書生成」「督促手続き開始」「入金受領」など、請求書ライフサイクルの1つのステップを表します。各アクティビティは、ケースを次の段階へ進める個別のイベントです。 アクティビティの順序と頻度の分析は、プロセスマイニングの中核です。実際のプロセスフローを明らかにし、ケースが滞留するボトルネックや、アクティビティが繰り返される手戻りループを特定できます。また、実際のプロセスを設計済みまたは理想的なプロセスと比較できます。アクティビティ名は、プロセスマップの作成とステップ間の遷移時間の計算に欠かせません。 重要な理由 この属性はプロセスマップ上のステップを定義し、請求書ライフサイクルを開始から終了まで可視化して分析できるようにします。 入手先 Oracle Fusion Financials内のさまざまな業務イベントから導出される概念的な項目です。通常は、Receivables(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つの請求書番号にまとめることで、アナリストはプロセスフローを可視化し、一般的な経路や逸脱経路を特定し、プロセス全体または異議申し立て解決や支払計上など特定の段階のサイクルタイムを測定できます。 重要な理由 関連するすべてのプロセスステップをつなぐ基本的なケース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 | |||
| ユーザー User | アクティビティを実行したユーザーまたはシステムIDです。 | ||
| 説明 信用限度額の承認、支払いの計上、異議申し立ての解決など、アクティビティを実行した担当者または自動システムユーザーを識別する属性です。 ユーザー別にアクティビティを分析することは、業務量の分布、個人のパフォーマンス、コンプライアンスを把握するうえで重要です。自動アクティビティでは、システムプロセスの関与状況を追跡できます。また、ユーザーの行動を監視することで、トレーニングの必要性や不正の可能性を特定することもできます。 重要な理由 プロセスのアクティビティを特定の担当者または自動化システムに割り当て、パフォーマンスの追跡、業務量の分析、監査を可能にします。 入手先 Oracle Fusion Financials全体のさまざまな取引テーブルおよび履歴テーブルにある「CREATED_BY」または「LAST_UPDATED_BY」列から取得されます。 例 jsmithar_specialist_1SYSTEM_AUTOMATION | |||
| 回収担当者 Collector | 請求書に割り当てられた回収担当者の氏名またはIDです。 | ||
| 説明 回収担当者は、延滞請求書の回収活動を管理する個人またはチームです。この割り当ては、回収ワークフローにおける重要なステップです。 この属性は、回収部門のパフォーマンス管理とリソース配分に欠かせません。担当者別に結果を分析することで、管理者は回収担当者の有効性を評価し、トレーニングの必要性を特定し、業務量を調整できます。「回収担当者割り当ての有効性」ダッシュボードでは、この属性を使って担当者ごとの成功率とサイクルタイムを比較します。 重要な理由 個々の回収担当者またはチームのパフォーマンスを分析し、リソース配分の改善と回収効率の向上に役立ちます。 入手先 通常、Oracle Advanced Collectionsモジュールに保存されます。IEX_CASES_ALL_Bなどのテーブルまたは関連する割り当てテーブルが該当します。 例 John SmithJane DoeCollections Team 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 | 規模、業種、戦略的重要性などに基づいて顧客を分類したグループです。 | ||
| 説明 顧客セグメントは、共通する特徴に基づいて顧客をグループ化するカテゴリ属性です。「Strategic」「SMB」「Enterprise」や、「Manufacturing」「Retail」などの業種で定義できます。 この属性は比較分析に役立ちます。セグメント間でプロセスパフォーマンスを比較し、たとえば、あるセグメントで異議申し立て率や支払サイクルが高くなっていないかを確認できます。この情報により、各セグメントのニーズとリスクに合わせて信用方針や回収戦略を調整でき、「顧客セグメント別の請求書償却率分析」などのダッシュボードを支援します。 重要な理由 顧客グループごとのプロセスパフォーマンスとリスクの違いを明らかにし、比較分析を可能にします。 入手先 顧客マスターデータ(HZ_CUST_ACCOUNTSまたは関連テーブル)で管理するか、売上高や業種などの顧客属性から導出します。 例 大企業中小企業政府機関戦略的パートナー | |||
| 顧客番号 CustomerNumber | 請求書に関連付けられた顧客を一意に識別する番号です。 | ||
| 説明 顧客番号は、請求書を特定の顧客口座に紐づけます。これにより、顧客属性に基づいて信用管理および回収プロセスをセグメント化し、分析できます。 顧客番号を含めることで、特定の顧客が継続的に支払いを遅延させているか、異議申し立てが多いか、より多くの回収対応を必要としているかを調査できます。この情報は、顧客ごとの回収戦略の策定、信用条件の調整、高リスク顧客セグメントの特定に欠かせません。「顧客セグメント別の請求書償却率分析」などの分析を直接支援します。 重要な理由 顧客別にプロセスをセグメント化し、個別の回収戦略に向けたパターン、リスク、機会を特定できます。 入手先 通常、RA_CUSTOMER_TRX_ALLテーブルのBILL_TO_CUSTOMER_IDとして確認でき、HZ_CUST_ACCOUNTSにリンクします。 例 CUST-0012389455ACME-CORP-US | |||
| 与信限度額 CreditLimitAmount | 顧客に承認された与信額の上限です。 | ||
| 説明 与信限度額は、企業が特定の顧客に対して許容する信用エクスポージャーの総額です。これは与信審査の過程で決定されます。 この属性は、「Credit Limit Decision Impact」ダッシュボードに欠かせません。承認済みの与信限度額を、その後の支払い状況や貸倒処理と関連付けることで、与信リスク方針の有効性を評価できます。分析によって、過度に高い与信限度額が貸倒率の上昇につながっているかどうかを確認し、与信承認プロセスの見直しに役立てられます。 重要な理由 承認済みの与信限度額を支払結果や貸倒処理と関連付け、与信リスク方針の有効性を評価するうえで重要です。 入手先 Oracle Credit Managementで管理され、通常はHZ_CUST_PROFILE_AMTSなど、顧客の与信プロファイルに関連するテーブルに保存されます。 例 10000.0050000.00250000.00 | |||
| 事業部門 BusinessUnit | 請求書を発行した特定の事業部門または組織単位です。 | ||
| 説明 大規模な組織では、業務を複数の事業部門に分けて運営することがよくあります。この属性は、請求書に関連する事業部門を識別します。 事業部門別にプロセスを分析することで、組織内の各部門のパフォーマンスを比較できます。信用方針や回収方針の適用方法における不一致を明らかにし、債権管理に優れた事業部門を特定できます。ベストプラクティスの共有や、必要に応じたプロセスの標準化にも役立ちます。 重要な理由 組織単位間のパフォーマンスを比較し、ベストプラクティスと改善領域を特定できます。 入手先 RA_CUSTOMER_TRX_ALLテーブルのORG_IDフィールドから確認でき、組織構造にリンクします。 例 BU北米BU EMEAグローバルサービス部門 | |||
| 支払条件 PaymentTerms | 支払期日を定める、合意済みの条件です。 | ||
| 説明 支払条件は、顧客が支払うべき条件を定めます。たとえば「Net 30」や「Net 60」などです。これらの条件を使って請求書の支払期日を計算します。 支払条件別に支払パフォーマンスを分析すると、興味深いパターンが見つかる場合があります。たとえば、支払期間が短い顧客ほど支払いが遅れやすい可能性があります。この情報を使って信用方針を見直し、改善したり、顧客を分けて異なる回収戦略を適用したりできます。特定の請求書が延滞する理由を理解するための背景情報にもなります。 重要な理由 合意された支払スケジュールを把握し、異なる信用条件における支払行動を分析できます。 入手先 RA_TERMSテーブルに保存され、請求書取引に紐づけられます。 例 30日後払い60日後払い受領時払い | |||
| 支払約束日 PromiseToPayDate | 顧客が支払うと約束した日付です。 | ||
| 説明 回収活動中に、顧客が将来の日付に支払うことを約束する場合があります。この「支払約束日」を記録して、約束を追跡します。 この属性は、回収ワークフローの管理と顧客の約束の信頼性評価に重要です。支払約束日と実際の入金受領日を比較することで、回収担当者は約束の履行率を評価できます。キャッシュインフローをより正確に予測し、約束が守られなかった場合に回収活動をエスカレーションする時期を判断するのにも役立ちます。 重要な理由 顧客の支払約束を追跡し、入金予測と回収交渉の有効性管理に役立ちます。 入手先 Oracle Advanced Collectionsモジュール内に保存されます。IEX_PROMISES_Tなどのテーブルが該当すると考えられます。 例 2023-06-102023-06-252023-07-05 | |||
| 期限超過フラグ IsOverdue | 請求書が支払期限を過ぎているかどうかを示す真偽値のフラグです。 | ||
| 説明 請求書の期限超過状況を、真または偽で簡潔に示す派生属性です。通常は、現在の日付(または支払日)と請求書の支払期限を比較して算出します。 このフラグは、分析におけるフィルタリングやセグメント分けに非常に役立ちます。期限を超過した請求書だけをすばやく抽出し、プロセス経路、回収活動の有効性、その他の特徴を調査できます。「Overdue Invoice Aging & Status」ダッシュボードなど、期限超過債権の管理に焦点を当てたダッシュボードやKPIも簡単に作成できます。 重要な理由 期限を超過したすべての請求書を明確に特定・分析でき、回収プロセスの中心的な対象を把握できます。 入手先 計算フィールドです。ロジックは、IF CurrentDate > DueDate AND Status != 'Paid' THEN True ELSE Falseです。 例 truefalse | |||
| 期限超過日数 DaysOverdue | 請求書が支払期限を過ぎている日数です。 | ||
| 説明 この計算指標は、未払いの請求書がどの程度遅延しているかを数値化します。未決済の請求書では現在の日付、決済済みの請求書では支払日と、支払期限との差分として算出します。 期限超過日数は、滞留期間の分析や回収活動の優先順位付けに欠かせない指標です。「Overdue Invoice Aging & Status」ダッシュボードの主要指標として、請求書を滞留期間の区分(例:1~30日、31~60日)に分類します。これにより、回収担当チームは最も古く、リスクの高い債権に集中できます。 重要な理由 支払い遅延の程度を数値化し、回収活動の優先順位付けや滞留期間分析の中核指標として利用できます。 入手先 計算フィールドです。ロジックは、未決済の請求書ではCurrentDate - DueDate、決済済みの請求書ではPaymentDate - DueDateです。 例 1545920 | |||
| 異議申し立て理由 DisputeReason | 顧客が請求書に異議を申し立てた理由です。 | ||
| 説明 顧客が請求書に異議を申し立てる際は、通常、「価格誤り」「商品破損」「請求書の重複」などの理由を提示します。この属性はその理由を記録します。 異議申し立て理由の分析は、根本原因分析の鍵です。支払遅延につながる受注管理や請求など、上流プロセスの繰り返し発生する問題を特定できます。異議申し立て理由を分類し、頻度を追跡することで、根本原因を解消するための対策を講じられます。これは、異議申し立て解決サイクルタイムの短縮にもつながります。 重要な理由 請求書への異議申し立ての根本原因を特定し、上流プロセスを先回りして改善することで、将来の異議申し立てを防げます。 入手先 通常、異議申し立て管理を正式に運用している場合は、Oracle Advanced CollectionsまたはOracle Channel Revenue Managementモジュールに記録されます。AR_DISPUTE_HISTORYなどのテーブルに保存される場合があります。 例 数量誤り価格差異商品破損サービス未提供 | |||
| 終了時刻 EndTime | 所要時間を伴うアクティビティが完了した時点を示すタイムスタンプです。 | ||
| 説明 明確な開始時点と終了時点があるアクティビティでは、この属性に完了時刻を記録します。プロセスマイニングのイベントの多くは瞬時に発生しますが、「Dispute Investigation」など、一定期間にわたるものもあります。 終了時刻を別に保持することで、アクティビティの処理時間を正確に計算できます。次のアクティビティの開始時刻から所要時間を推定する方法よりも正確で、特に待機時間がある場合に有効です。リソースの利用状況を分析し、プロセス内でどの手順に最も時間がかかっているかを特定するうえでも重要です。 重要な理由 特定のアクティビティにかかる時間を正確に計算でき、ボトルネックやリソースの利用状況を詳しく把握できます。 入手先 概念上の属性であることが多く、アクティビティに対応するソーステーブルの「last updated」タイムスタンプや「close date」フィールドから取得する場合があります。 例 2023-04-15T11:30:00Z2023-05-02T09:00:00Z2023-05-21T16:45:00Z | |||
| 請求書ステータス InvoiceStatus | ライフサイクルにおける請求書の現在のステータスです。 | ||
| 説明 請求書ステータスは、請求書がプロセスのどの段階にあるかを示すスナップショットです。一般的なステータスには「Open」「Paid」「Disputed」「Past Due」「Written Off」などがあります。この属性により、債権の状態を大まかに把握できます。 プロセスマイニングでは、特定の対象に絞り込むために使用します。たとえば、未決済の延滞請求書をすべて抽出できます。「延滞請求書の経過期間・ステータス」ダッシュボードの主要な分析軸であり、請求書ポートフォリオの現在の状態をすぐに確認し、回収活動の優先順位を決められます。 重要な理由 請求書の現在の状態をすばやく把握し、回収活動の絞り込みと優先順位付けを容易にします。 入手先 通常、AR_PAYMENT_SCHEDULES_ALLテーブルのSTATUSというフィールドで確認できます。 例 未処理クローズ済み異議申立て中回収中 | |||
| 請求通貨 InvoiceCurrency | 請求金額の表示に使用する通貨です。 | ||
| 説明 請求書の通貨を指定する属性です。USD、EUR、GBPなどが該当します。多国籍組織では、請求書が複数の通貨で発行されることがよくあります。 複数通貨のデータを分析するには、慎重な処理が必要です。この属性により、通貨別にプロセスビューを絞り込んだり、連結財務報告に適切な為替レートを適用したりできます。金額を正しく解釈し、同じ基準で比較できるようにします。 重要な理由 多通貨環境で財務データを正しく解釈し、正確な財務分析を行うために欠かせません。 入手先 通常、RA_CUSTOMER_TRX_ALLテーブルのINVOICE_CURRENCY_CODEとして確認できます。 例 USDEURGBPJPY | |||
| 貸倒処理済みフラグ IsWrittenOff | 請求書が貸倒債権として償却処理されたかどうかを示す真偽値のフラグです。 | ||
| 説明 回収不能と判断され、未収金の管理対象から除外された請求書を特定する派生フラグです。通常、請求書にとって最終的かつ望ましくない結果を示します。 この属性は、請求書貸倒率KPIの算出と関連する分析ダッシュボードに欠かせません。回収に失敗した請求書だけを抽出し、顧客セグメントや請求額など、貸倒リスクの上昇に関連する共通の特徴を特定できます。この分析結果は、与信方針や回収戦略の改善に役立ちます。 重要な理由 回収に失敗したケースを明確に特定でき、貸倒れの根本原因の分析や貸倒率の算出に欠かせません。 入手先 計算フィールドです。ケースに「Invoice Written Off」アクティビティが存在するか、請求書のステータスが「Written Off」かどうかを確認して算出します。 例 truefalse | |||
与信管理・債権回収のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| 入金受領 | 顧客から資金を受け取ったことを示します。特定の請求書にはまだ充当されていない場合があります。システムで現金受領取引が作成された時点で取得します。 | ||
| 重要な理由 回収プロセスにおける大きな節目であり、入金があったことを示します。このイベントから支払充当までの期間は、社内処理の効率を測る指標です。 入手先 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 | |||
| 支払期日超過 | 請求書が全額支払われないまま現在日が支払期日を過ぎたときに発生する計算イベントです。このイベントは、請求書のステータスが「current」から「overdue」に移行したことを示します。 | ||
| 重要な理由 回収および督促プロセスを開始する重要な節目です。支払期日を過ぎた請求書の件数と金額を分析することは、運転資本の管理と信用リスクの評価に欠かせません。 入手先 AR_PAYMENT_SCHEDULES_ALLテーブルでSTATUSが「OP」(Open)の請求書を対象に、システムの現在日とDUE_DATEを比較して計算します。 取得 計算イベント:SYSDATE > AR_PAYMENT_SCHEDULES_ALL.DUE_DATEとなったときに発生します。 イベントタイプ calculated | |||
| 督促手続き開始 | 支払期日を過ぎた請求書に対する正式な督促プロセスの開始を示し、通常は最初の正式な督促状の送付を伴います。督促バッチ処理が実行され、その請求書が対象に含まれた時点で記録されるのが一般的です。 | ||
| 重要な理由 このアクティビティを追跡することは、督促の有効性と督促方針の遵守状況を測定するうえで重要です。督促を開始してから支払いに至るまでの期間を測る基準にもなります。 入手先 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(Invoice Number)について、RA_CUSTOMER_TRX_ALLテーブルのCREATION_DATEまたはTRX_DATE列から取得される明示的なイベントです。 取得 イベント時刻は、RA_CUSTOMER_TRX_ALLテーブルのCREATION_DATEです。 イベントタイプ explicit | |||
| 与信審査完了 | 請求書に関連付けられた顧客の与信審査が完了したことを示します。通常は、請求書の作成日と、その顧客口座で直近に与信審査が完了した日付を関連付けて推定します。これにより、与信に関する分析の基準を設定できます。 | ||
| 重要な理由 与信審査から受注までの時間を分析すると、受注から入金までのサイクルの初期段階における遅延を特定できます。これは、Credit Approval Cycle Time 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」(Disputed)に変わったことから推定します。時刻は監査テーブルまたは最終更新日から取得できます。 取得 請求書についてAR_PAYMENT_SCHEDULES_ALL.STATUSが「DS」に変わったことを検出します。 イベントタイプ inferred | |||
| 異議申し立ての解決 | 登録された異議申し立ての調査が完了し、解決に至ったことを示します。請求書の異議申し立てステータスが解除された時点で取得します。 | ||
| 重要な理由 このイベントは、異議申し立て解決サイクルの終了を示します。「異議申し立ての登録」からこのイベントまでの期間は、業務効率とキャッシュフローへの影響を測定する主要なKPIです。 入手先 AR_PAYMENT_SCHEDULES_ALLのSTATUSが「DS」(Disputed)から「OP」(Open)に戻るか、クレジットメモまたは調整後に「CL」(Closed)へ変わったことから推定します。 取得 AR_PAYMENT_SCHEDULES_ALL.STATUSが「DS」から別のステータスに変わったことを検出します。 イベントタイプ inferred | |||
| 請求書クローズ | 支払い、クレジットメモの充当、または調整によって請求書の未決済残高がゼロになったときに発生します。請求書ライフサイクルが正常に完了したことを示します。 | ||
| 重要な理由 プロセスが正常に完了したことを示す主要な終点です。請求書のクローズ状況を監視することは、債権ポートフォリオ全体の健全性を把握するうえで基本となります。 入手先 AR_PAYMENT_SCHEDULES_ALLテーブルでSTATUSが「CL」(Closed)に変わったことから推定します。この変更の時刻には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環境にログインします。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」セクションに記載された完全な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パラメーターを使用することが重要です。初期テストでは、1か月などの短い範囲を指定します。本番実行では、通常3~6か月のローリング期間を使用します。 - フィルタリング:大規模な組織では、
invoices_base共通テーブル式のWHERE句にBU_NAME(Business Unit Name)用のパラメーターを追加し、1つのビジネスユニットずつデータを処理することを検討してください。 - パフォーマンスに関する考慮事項:このクエリでは、複数の大規模なトランザクションテーブルを結合します。フィルターを使わずに広い日付範囲で実行すると、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%短縮し、財務状態を改善します。
クレジットカードは必要ありません。数分で始められます。