> 継続的なプロセス改善 > 受注から入金まで：請求・請求書処理 > Oracle Fusion Financials > データテンプレート

受注から入金までの請求・請求書処理向けデータテンプレート

Oracle Fusion Financials

受注から入金までの請求・請求書処理の属性(22) 受注から入金までの請求・請求書処理のアクティビティ(13) データ抽出ガイド(2)

受注から入金までの請求・請求書処理向けデータテンプレート

このテンプレートでは、受注から入金までの請求・請求書処理を分析するために必要なデータの抽出方法をご案内します。収集する属性や追跡するアクティビティ、データ抽出の手順をまとめています。テンプレートに沿ってデータを準備することで、プロセスマイニングとプロセス改善に必要なデータセットを整えられます。

収集を推奨する属性
追跡する主なアクティビティ
Oracle Fusion Financialsからのデータ抽出ガイド

イベントログを初めて作成する方はこちら：プロセスマイニング用イベントログの作成方法.

テンプレートをダウンロード

受注から入金までの請求・請求書処理の属性

受注から入金までの請求・請求書処理を詳しく分析するために、イベントログに含めることを推奨するデータ項目です。

3 必須 5 推奨 14 任意

	名前	説明
	請求書番号 InvoiceNumber	各請求書を一意に識別する番号です。関連するすべてのアクティビティを追跡するための主要なケースIDとして使用されます。
説明請求書番号は、請求プロセス分析の基盤となる項目です。ケースIDとして機能し、請求書の作成から最終的な支払い、終了までのすべてのイベントをまとめます。これにより、個々の請求書のライフサイクルを最初から最後まで把握できます。プロセスマイニングでは、請求書番号を使って分析することで、プロセスのバリアントを可視化し、請求書ごとのサイクルタイムを算出し、特定の取引に影響するボトルネックや手戻りのループを特定できます。「請求書のエンドツーエンドサイクルタイム」などのダッシュボードや、売上債権回転日数（DSO）などの基本的なKPIを請求書単位で算出する際にも欠かせません。重要な理由この属性は、関連する請求と支払いのアクティビティを1つのケースにまとめ、請求書のライフサイクルを漏れなく正確に分析するために重要です。入手先通常は、Oracle Fusion FinancialsのRA_CUSTOMER_TRX_ALLテーブルにある取引番号（TRX_NUMBER）です。例 INV-1002345983451CM-55432
	開始時刻 EventTimestamp	特定のアクティビティまたはイベントが発生した正確な日時です。
説明イベントのタイムスタンプには、アクティビティが発生した正確な時刻が記録されます。請求書ごとのイベントの順序を示すため、プロセスフローの作成や時間に基づく分析に欠かせません。この属性は、所要時間やパフォーマンスの計算の基礎となります。アクティビティ間の時間やエンドツーエンドのサイクルタイムの測定、支払いが期限内かどうかの判定、経時的な傾向の分析に使われます。「請求書の平均承認時間」や「請求書のエンドツーエンドサイクルタイム」などのKPIは、これらのタイムスタンプから直接算出されます。重要な理由タイムスタンプは、サイクルタイム、遅延、期限の遵守状況など、あらゆるパフォーマンス指標の算出に欠かせず、定量的なプロセス分析の基礎となります。入手先 Oracle Fusion Financialsのさまざまなテーブルの日付フィールドから取得します。たとえば、RA_CUSTOMER_TRX_ALLのCREATION_DATEや、ワークフローテーブルのステータス更新タイムスタンプが該当します。例 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-20T11:25:10Z
	アクティビティ名 ActivityName	請求書のライフサイクルにおいて、特定の時点で発生した業務イベントまたはタスクの名前です。
説明アクティビティ名は、「請求書の作成」「請求書の承認」「顧客からの支払い受領」など、請求プロセスの各ステップを表します。これらのイベントが、請求書ごとのプロセスフローを構成します。この属性はプロセスの発見に欠かせません。プロセスマイニングツールはこの情報を使って、請求書が実際にどのように処理されているかを図示します。また、プロセスのバリアントの分析、複数回の承認などの手戻りの特定、各段階の発生頻度や所要時間の測定にも使われます。プロセスフローの把握に必要なすべてのダッシュボードとKPIが、この属性に基づいています。重要な理由プロセスマップの各ステップを定義する属性です。請求書のワークフローを可視化して分析し、非効率な箇所を特定できます。入手先 Oracle Fusion Financialsのさまざまなテーブルやステータス変更から取得します。たとえば、承認に関連するワークフロー履歴テーブルや、取引のステータスフィールドが該当します。例請求書作成請求書承認顧客から入金請求書クローズ
	事業部門 BusinessUnit	請求書を発行した組織内の事業部門です。
説明事業部門は、取引を担当する組織単位を表します。大規模な企業で財務データを分類、報告する際の重要なデータ項目です。この属性を使うと、社内の各部門間でプロセスのパフォーマンスを比較できます。たとえば、事業部門ごとのDSOに大きな差があるか、特定の部門で請求の手戻り率が著しく高いかを分析できます。改善施策が特に必要な領域を見極めるのに役立ちます。重要な理由組織内の各部門のパフォーマンスを比較し、ベストプラクティスや改善が必要な領域を細かく特定できます。入手先 RA_CUSTOMER_TRX_ALLなどの取引テーブルにあり、多くの場合、事業部門の定義に関連付けられたORG_IDとして記録されています。例米国コンサルティングEMEA製造APACサービス
	支払期日 DueDate	請求書の支払い期限となる日付です。
説明支払期日は、支払条件に基づいて請求書の支払い期限を定める重要な日付属性です。この属性は、債権回収と財務状況の把握に欠かせません。期限内支払率KPIの算出や、支払経過期間レポートの作成の基準となります。ダッシュボードでは、支払い予定日を示してキャッシュフローを予測したり、回収対応が必要な期限超過の請求書を特定したりするために使われます。重要な理由支払いの適時性を測定し、DSOを算出し、売掛金の経過期間を管理するための主要な基準です。入手先 AR_PAYMENT_SCHEDULES_ALLテーブルのDUE_DATEフィールドにあります。例 2023-05-302023-06-152023-07-01
	請求書のステータス InvoiceStatus	請求書のライフサイクルにおける現在の状態です。「未決済」「決済済み」「異議申し立て中」などがあります。
説明請求書のステータスから、プロセスのどの段階にあるかを把握できます。一般的なステータスには、未決済（未払い）、決済済み（支払い済み）、異議申し立て中、無効があります。この属性は、全体的な状況の監視やデータの絞り込みに役立ちます。たとえば、「リアルタイムキャッシュフロー予測」ダッシュボードでは、未回収額の分類にこのステータスを使います。期限超過、異議申し立て中、決済済みの請求書をすばやく特定できます。重要な理由請求書の現在の状態をすばやく把握できます。財務報告や業務管理に向けた効率的な絞り込みと分類に役立ちます。入手先 RA_CUSTOMER_TRX_ALLやAR_PAYMENT_SCHEDULES_ALLなどのテーブルにあるステータスフィールド（STATUSなど）から取得します。例未決済決済済み異議申し立て中承認待ち
	請求金額 InvoiceAmount	請求書の合計金額です。
説明この属性は、請求書の請求総額を表します。請求プロセスで扱う金額を把握するための重要な財務指標です。分析では、請求金額を使って高額取引の優先順位を付けたり、未回収債権の総額を算出したり、売上債権回転日数（DSO）などのKPIに重み付けしたりできます。財務への影響に応じてプロセスを分類できるため、高額請求書で承認経路が異なるか、支払いまでに時間がかかるかなども分析できます。重要な理由各ケースの財務状況を把握するための属性です。金額に基づく分析や高額請求書の優先順位付け、主要な財務KPIの算出に役立ちます。入手先 RA_CUSTOMER_TRX_ALLテーブルにあります。INVOICE_AMOUNTなど、取引の合計額を表すフィールドが該当します。例 5000.001250.75250000.00
	顧客名 CustomerName	請求先となる顧客または法人の名前です。
説明この属性は、請求書に関連付けられた顧客を特定します。プロセスデータを分類、絞り込むための主要な軸です。顧客名ごとにプロセスを分析すると、支払いサイクルが最も長い顧客、請求書に異議を申し立てる可能性が高い顧客、常に期限内に支払う顧客を特定できます。「DSOの推移」ダッシュボードや、顧客ごとの行動に合わせた回収方針の策定にも欠かせません。重要な理由顧客ごとにプロセスを分類し、顧客ごとの行動や支払いパターン、キャッシュフローに影響する関係上の課題を明らかにできます。入手先取引テーブル（RA_CUSTOMER_TRX_ALL）と、HZ_PARTIESなどの顧客マスターデータテーブルを結合して取得します。例 Global Tech Inc.Innovate Solutions LLCApex Manufacturing
	ソースシステム SourceSystem	イベントデータの抽出元となる記録システムです。
説明この属性は、データの発生元であるアプリケーションを示します。このプロセスでは通常、Oracle Fusion Financialsが該当しますが、Oracle Receivables（AR）など、特定のモジュールを示す場合もあります。複数のシステムが連携する環境では、このフィールドによってデータソースを区別できます。データの検証とガバナンスにも欠かせず、意図した正しいデータセットに基づいて分析できるようにします。重要な理由データの発生元を特定します。データガバナンスやトラブルシューティングに欠かせないほか、正しい記録システムのデータに基づいて分析するためにも重要です。入手先通常は「Oracle Fusion Financials」などの固定値で、データの抽出・変換時に追加されます。例 Oracle Fusion FinancialsOracle AR CloudFusion Apps
	ユーザー User	特定のアクティビティを実行した従業員またはシステムユーザーです。
説明ユーザー属性は、プロセスのステップを実行した担当者または自動処理を特定します。請求書を作成したユーザー、承認したマネージャー、督促状を送付した回収担当者などが該当します。ユーザーごとの分析により、研修の必要性や業務量の配分、個人またはチーム間のパフォーマンスの違いを把握できます。特定のユーザーにエラーが多い場合や、特定の承認者が一貫してボトルネックになっている場合も明らかになります。重要な理由プロセスの各ステップの担当者を明確にし、ユーザーのパフォーマンスや業務量の配分、研修の必要性を分析できます。入手先さまざまな取引テーブルやワークフローテーブルにあるCREATED_BYやLAST_UPDATED_BYなどのユーザーIDフィールドから取得します。その後、PER_ALL_PEOPLE_Fなどのユーザーディレクトリテーブルと結合し、ユーザー名を取得します。例 john.smithjane.doeCollectionsBot
	最終データ更新 LastDataUpdate	このイベントのデータがソースシステムから最後に更新または抽出された日時を示すタイムスタンプです。
説明この属性には、直近のデータ抽出時刻が記録されます。分析対象データがどの程度新しいかを把握するために欠かせないメタデータです。分析担当者はこの情報を確認し、最新のデータを使っているか、またデータがいつ時点のものかを把握できます。「リアルタイム」またはほぼリアルタイムとするダッシュボードでは、データの遅延が生じる可能性を明示するため、特に重要です。重要な理由データの新しさを把握できるため、分析や結論が、更新時点の明らかな許容範囲内のデータに基づいていることを確認できます。入手先データの抽出、変換、ロード（ETL）処理で生成されるメタデータです。通常はデータパイプラインの実行時刻に相当します。例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	地域 Region	顧客または取引に関連する地理的な地域です。
説明地域属性は、通常は顧客の所在地に基づいて、請求書の地理的な背景を示します。これにより、地域別にプロセスのパフォーマンスを分析できます。地域ごとの分析から、現地の規制、市場環境、地域チームのパフォーマンスによる違いを明らかにできます。「DSOの推移」や「請求書のエンドツーエンドサイクルタイム」などのダッシュボードを地域別に分類し、請求書の支払いに特有の課題がある地域を確認できます。重要な理由地域別にプロセスを分類し、パフォーマンス、顧客の行動、コンプライアンスにおける地域差を明らかにできます。入手先通常は、TCA（HZ_LOCATIONS、HZ_PARTY_SITES）に保存された顧客の住所情報から取得します。請求書自体に直接記録されているフィールドではありません。例北米欧州アジア太平洋
	売上債権回転日数 DaysSalesOutstanding	請求日から支払いを受領した日までの日数です。
説明売上債権回転日数（DSO）は、請求書の発行後、支払いを回収するまでの平均日数を測る重要な財務指標です。この属性では、請求書ごとのDSOを算出します。全体のDSOは重要なKPIですが、請求書単位で算出すると、より詳細な分析が可能になります。推移を示すダッシュボードの作成や、DSOが長い請求書の特徴の特定、プロセス遅延による財務への影響の測定に利用できます。この詳細な計算結果から、全体のDSO KPIを左右する要因を把握できます。重要な理由請求書ごとのキャッシュフローに関する重要な指標を算出し、回収期間や財務パフォーマンスを左右する要因を詳しく分析できます。入手先「顧客からの支払い受領」アクティビティのタイムスタンプと「請求日」の差を求めて算出します。例 356228
	手戻りかどうか IsRework	アクティビティが手戻りに該当するかどうかを示す真偽値です。承認のやり直しや修正などが該当します。
説明この計算属性は、不要または重複した作業に該当するアクティビティを示します。たとえば、請求書が却下された後に再申請された場合や、最初の作成後に修正された場合が該当します。手戻りを識別することで、プロセスへの影響を簡単に定量化できます。請求の手戻り率KPIは、この属性から直接算出されます。ダッシュボードで手戻りの頻度や、それによって増加するサイクルタイムを可視化し、非効率やエラーの原因を特定できます。重要な理由不要な作業や繰り返し作業を特定し、プロセスの非効率を直接定量化できます。品質上の問題がもたらすコストや時間への影響も測定しやすくなります。入手先アクティビティの順序に基づいて、データ変換時に算出します。たとえば、同じケースで「請求書の却下」の後に「請求書の承認」が発生した場合、そのアクティビティを手戻りとして記録します。例 truefalse
	支払い方法 PaymentMethod	銀行振込やクレジットカードなど、顧客が支払いに使用した方法です。
説明この属性は、顧客が請求書をどの方法で支払ったかを示します。支払いの傾向やコストの分析に役立ちます。支払い方法によって、処理時間や取引コストが異なる場合があります。支払い方法ごとに分析すると、特定の方法で照合エラーや遅延が起きやすいかを把握できます。また、より効率的な支払い方法を顧客に促す施策の検討にも役立ちます。重要な理由支払い方法ごとの処理効率、取引コスト、照合エラー率の分析に役立ちます。入手先 AR_CASH_RECEIPTS_ALLなどの入金テーブルにあります。支払い方法を示すフィールドが含まれています。例 ACH銀行振込クレジットカード小切手
	支払条件 PaymentTerms	「30日以内」や「10日以内に2％割引、30日以内に支払い」など、合意された請求書の支払条件です。
説明支払条件は、早期支払い割引の有無も含め、請求書をいつ、どのように支払うかを定めます。債権とキャッシュフローの管理に欠かせない情報です。正確な支払期日の算出や、早期支払い割引の機会を特定するために必要な属性です。早期支払い割引適用率KPIは、割引対象となる請求書を判定するため、このデータに直接依存します。重要な理由請求書の支払ルールを定める属性です。支払期日の算出に直接影響し、早期支払い割引の適用状況の追跡と最適化にも役立ちます。入手先 RA_TERMSテーブルにあり、RA_CUSTOMER_TRX_ALLのterm_idを介して取引に関連付けられています。例 30日以内60日以内10日以内に2％割引、30日以内に支払い
	期限内に支払われたか IsPaidOnTime	請求書が支払期日までに支払われたかどうかを示す真偽値です。
説明この計算属性は、支払いが期限内かどうかを真偽値で示します。「顧客からの支払い受領」アクティビティの日付と、請求書の「支払期日」属性を比較して算出します。このフラグにより、期限内支払率KPIの分析や報告が簡単になります。顧客、地域、請求金額などの条件で絞り込み、支払いの遅延に関係する要因を把握できます。債権回収の有効性を評価する重要な指標です。重要な理由債権回収のパフォーマンスを測定しやすくなり、期限内の支払いと遅延の要因を簡単に分析できます。入手先最終支払いアクティビティのタイムスタンプとDueDate属性を比較して算出します。計算式は`PaymentTimestamp <= DueDate`です。例 truefalse
	異議申し立ての理由 DisputeReason	顧客が請求書に異議を申し立てた理由です。
説明顧客が請求書に異議を申し立てた場合、その理由が記録されます。価格、数量、サービス品質などに関する問題が該当します。異議申し立ての理由を分析すると、根本原因を特定できます。よくある理由を把握することで、価格設定、注文処理、データ品質に関する根本的な問題に対処できます。これにより、請求書の異議解決にかかる平均時間を短縮し、顧客満足度を高められます。重要な理由支払いの遅延や顧客の不満につながる根本原因を把握し、組織として構造的な問題に対処できます。入手先 Oracle Collectionsまたは関連する異議管理モジュールに保存されている場合があります。専用の異議管理テーブル、または取引自体の理由コードに記録されている可能性があります。例価格の誤り数量の不一致商品の破損請求書の重複
	終了時刻 EventEndTime	特定のアクティビティまたはイベントが完了した正確な日時です。
説明イベント終了時刻には、アクティビティが完了した時刻が記録されます。多くのイベントは瞬時に完了しますが、「請求書の承認」など、申請から判断まで一定の時間がかかるアクティビティもあります。終了時刻があれば、アクティビティの処理時間を正確に算出できます。特定のタスクにユーザーがどれだけ時間をかけているかを分析する際に役立ちます。また、待ち時間と実際の処理時間を区別できるため、ボトルネック分析の精度も高まります。重要な理由アクティビティの処理時間を正確に算出し、実作業時間と待ち時間を区別できます。詳細なボトルネック分析に欠かせない情報です。入手先多くの場合、後続アクティビティの開始時刻から算出します。アクティビティによっては、ワークフローログに専用の終了時刻フィールドが記録されています。例 2023-04-15T09:05:12Z2023-04-18T15:00:00Z2023-05-20T11:25:45Z
	請求日 InvoiceDate	請求書が正式に発行された日付です。
説明請求日は取引日とも呼ばれ、請求書に記載された日付です。支払条件の計算開始日となります。売上債権回転日数（DSO）の算出に欠かせない項目です。DSOは請求日から支払日までの期間を測定します。システム上の作成日とは異なり、顧客から見た支払いサイクルの正式な開始日を表します。重要な理由請求書のライフサイクルの正式な開始日であり、売上債権回転日数（DSO）KPIを算出する際の基準となります。入手先 RA_CUSTOMER_TRX_ALLテーブルのTRX_DATEフィールドにあります。例 2023-04-142023-05-182023-06-25
	請求書のサイクルタイム InvoiceCycleTime	請求書の作成から終了までにかかった合計時間です。
説明この属性は、1つのケースにおける請求書のライフサイクル全体の所要時間を測定します。通常は「請求書の作成」である最初のアクティビティから、最後の「請求書の終了」までの時間差として算出します。この指標から、プロセス全体の効率を把握できます。「請求書のエンドツーエンドサイクルタイム」ダッシュボードの主要な測定項目です。顧客や事業部門などの切り口で分析すると、処理に最も時間がかかる請求書の種類を特定し、根本原因を調査できます。重要な理由プロセス全体の処理速度を示す重要な指標です。開始から完了までに時間がかかる請求書をすばやく特定できます。入手先計算指標です。一意のInvoiceNumberごとに、EventTimestampの最大値と最小値の差を求めて算出します。例 45日8時間32日2時間90日12時間
	請求部門 BillingDepartment	請求書の作成と管理を担当する社内の部門またはチームです。
説明この属性は、組織内で請求プロセスを担当したチームまたは部門を特定します。分析に組織面の情報を加えることができます。請求部門ごとにプロセスを分類すると、チーム間で効率や正確性を比較できます。手戻り率や承認サイクルが長い部門、DSOの上昇に大きく影響している部門を特定し、対象を絞った研修やプロセスの標準化につなげられます。重要な理由社内チーム間のパフォーマンスを比較し、ベストプラクティスや必要なリソース、プロセス改善が必要な領域を特定できます。入手先請求書を作成したユーザーを特定し、PER_ALL_ASSIGNMENTS_Fなどを介してHRシステム上の所属部門と関連付けることで取得できる場合があります。例全社請求部門サービス請求チーム製品販売請求部門

必須推奨任意

受注から入金までの請求・請求書処理のアクティビティ

プロセスを正確に把握するために、イベントログに記録する主なプロセスのステップと節目です。

6 推奨 7 任意

	アクティビティ	説明
	入金を請求書に充当	受領した顧客からの入金が特定の請求書と照合され、正常に充当された状態です。請求書の未回収残高が減少します。個別の取引レコードとして記録されます。
重要な理由このアクティビティは、入金が適切に割り当てられたことを示します。滞留期間レポートや財務諸表を正確に作成するうえで重要であり、売掛金として計上した入金を認識する最終段階です。入手先 AR_RECEIVABLE_APPLICATIONS_ALLテーブルに明示的に記録されます。apply_dateとgl_dateのフィールドは、入金が充当された日付を示します。記録現金受領を請求書に関連付けるAR_RECEIVABLE_APPLICATIONS_ALLテーブルのapply_dateを使用します。イベントタイプ explicit
	請求書クローズ	請求書の全額が支払われ、照合が完了すると、請求書のライフサイクルは終了します。このイベントは通常、請求書の未決済残高がゼロになり、ステータスが更新された時点で推定されます。
重要な理由これは請求書の最終的な処理結果であり、プロセスの終了を示します。この状態に至るまでの合計時間がエンドツーエンドのサイクルタイムとなり、請求プロセスの主要なKPIです。入手先 AR_PAYMENT_SCHEDULES_ALLテーブルで、ステータスが「CLOSED」に更新され、amount_due_remainingがゼロになったことから推定されます。gl_date_closedフィールドに終了日が記録されています。記録対象の請求書について、AR_PAYMENT_SCHEDULES_ALLのgl_date_closedを使用します。イベントタイプ inferred
	請求書を顧客に送付	メールや印刷物など、顧客が希望する方法で請求書を送付した状態です。多くの場合、システムには送付処理を実行した時点のタイムスタンプが記録されます。
重要な理由このアクティビティをもって支払条件の期間が始まります。承認から送付までの時間を測定すると、請求書の配布プロセスの効率を把握できます。入手先 RA_CUSTOMER_TRX_ALLの「last_printed_date」フィールドから推定できます。電子送付の場合は、Oracle Business Intelligence Publisherのログから取得できます。記録請求書に関連する送付ログまたは印刷ログのタイムスタンプを使用します。イベントタイプ inferred
	請求書作成	システムで請求書取引が最初に作成された時点です。多くの場合、下書きまたは未完了の状態です。売掛金モジュールでユーザーが新しい請求書レコードを初めて保存すると、このイベントが明示的に記録されます。
重要な理由請求プロセスの明確な開始点です。作成から完了までの時間を分析すると、初期段階のデータ入力の遅れやシステムの処理性能に関する問題を特定できます。入手先 RA_CUSTOMER_TRX_ALLテーブルの取引レコードの作成日から取得します。初期状態は「未完了」であることが一般的です。記録対象の請求書番号について、RA_CUSTOMER_TRX_ALLテーブルのcreation_dateを使用します。イベントタイプ explicit
	請求書承認	請求書に必要な承認がすべて完了し、顧客に送付できる状態です。承認ワークフローが正常に完了し、請求書のステータスが更新された時点で記録します。
重要な理由顧客への請求書送付に進むための重要な節目です。ここで遅れが生じると、支払期間の開始が遅れ、売上債権回転日数（DSO）に影響します。入手先請求書取引レコードの最終承認ステータスの更新、または関連するBPMワークフロータスクの完了タイムスタンプから推定します。記録請求書の承認ステータスが「承認済み」に設定された時点のタイムスタンプを記録します。イベントタイプ inferred
	顧客から入金	顧客からの入金が、現金受領としてシステムに登録された状態です。この時点では、特定の請求書にまだ充当されていない場合があります。
重要な理由資金流入を示す重要な節目です。入金から請求書への充当までの時間は、資金管理の効率を測る重要な指標です。入手先 AR_CASH_RECEIPTS_ALLテーブルにレコードが作成された時点で明示的に記録されます。receipt_dateは支払いが処理された日付を示します。記録 AR_CASH_RECEIPTS_ALLテーブルのcreation_dateまたはreceipt_dateを使用します。イベントタイプ explicit
	支払期日到来	契約上定められた請求書の支払期日を過ぎた状態です。取引上のイベントではなく、請求書の支払条件と現在の日付に基づいて算出します。
重要な理由この算出イベントは、滞留期間分析やDSOの計算に欠かせません。期日どおりの請求書と支払遅延の請求書を区別し、対象を絞った回収活動を可能にします。入手先算出イベントです。対象の請求書について、AR_PAYMENT_SCHEDULES_ALLテーブルのdue_dateフィールドより現在の日付が後になった時点で発生します。記録現在の日付とAR_PAYMENT_SCHEDULES_ALLのdue_dateフィールドを比較して算出します。イベントタイプ calculated
	支払督促の送付	支払遅延の請求書について、督促状または支払案内を顧客に送付した状態です。回収モジュールに明示的なアクションとして記録されます。
重要な理由督促を追跡すると、回収プロセスの効果を測定できます。どの督促方法が入金を早めているかを分析できます。入手先 Oracle Advanced Collectionsモジュールに明示的に記録されます。IEX_DUNNINGSなどの督促履歴テーブルには、督促の送付日と段階が記録されます。記録督促履歴テーブルから取得し、督促取引を請求書に関連付けます。イベントタイプ explicit
	異議申し立て開始	顧客が請求書に正式に異議を申し立て、システムに紛争案件が作成された状態です。通常、請求書の支払予定にあるステータスフラグを変更して記録します。
重要な理由異議申し立てがあると支払いが保留され、解決には手作業が必要になります。発生頻度と解決時間を分析すると、価格設定や配送の誤りなど、根本原因を特定できます。入手先 AR_PAYMENT_SCHEDULES_ALLテーブルのステータスフィールドが紛争中に設定されたこと、またはAR_DISPUTE_HISTORYの作成レコードから推定できます。記録請求書の支払予定で、異議申し立てフラグまたはステータスが有効になった時点を特定します。イベントタイプ inferred
	請求書の承認却下	通常、価格や数量などのデータに誤りがある場合、承認者が請求書を却下します。請求書は修正のために差し戻され、手戻りが発生します。
重要な理由却下を追跡すると、請求の正確性や内部統制に関する問題が明らかになります。却下の頻度や理由を分析することで、プロセスの改善やトレーニングが必要な箇所を特定できます。入手先請求書取引レコードのステータス更新、またはBPMワークフロータスクの「却下」結果から推定します。記録請求書の承認ステータスが「却下」に設定された時点のタイムスタンプを記録します。イベントタイプ inferred
	請求書の承認申請	承認ワークフローが設定されている場合、請求書が正式に申請されます。請求書のステータスが承認待ちに更新され、指定された承認者に通知が送信された時点で記録します。
重要な理由承認サイクルの開始を示します。このアクティビティを追跡すると、請求書のサイクルタイム全体を左右する重要な要素である、その後の承認時間を測定・分析できます。入手先請求書取引のステータス変更から推定するか、承認タスクの開始を記録するOracle Business Process Management（BPM）のワークフローテーブルから取得します。記録請求書の承認ステータスが「保留中」または同様の状態に変わった時点のタイムスタンプを特定します。イベントタイプ inferred
	請求書の金額を調整	貸倒処理やクレジットなどにより、請求書の金額が変更された状態です。請求書の未回収残高を変更する取引として明示的に記録されます。
重要な理由調整は、異議申し立て、譲歩、または修正があったことを示す場合があります。調整の頻度や金額を分析すると、受注から入金までのプロセスに潜む問題を明らかにできます。入手先 AR_ADJUSTMENTS_ALLテーブルに明示的に記録されます。調整レコードのcreation_dateがイベントの発生日を示します。記録対象の請求書について、AR_ADJUSTMENTS_ALLテーブルのcreation_dateを使用します。イベントタイプ explicit
	請求書処理完了	請求書のデータ入力が完了し、検証と会計処理に進める状態です。通常、請求書のステータスが「未完了」から「完了」に変わった時点で記録します。
重要な理由データ入力段階の終了を示す節目です。作成から完了までの時間から、請求部門のデータ入力や確認の効率を把握できます。入手先 RA_CUSTOMER_TRX_ALLテーブルの請求書取引レコードのステータス変更から推定します。「完了」への更新に関連付けられたタイムスタンプを確認します。記録 RA_CUSTOMER_TRX_ALLまたは関連するワークフローテーブルで、取引のステータス履歴を追跡します。イベントタイプ inferred

推奨任意

データ抽出ガイド

Oracle Fusion Financialsからデータを取得する方法

ステップ

BI Publisherを開く：Oracle Fusion Applicationsにログインし、ナビゲーターから「ツール」を開いて「レポートと分析」を選択します。「カタログの参照」をクリックして、Business Intelligenceカタログを開きます。
データモデルを作成する：カタログで「新規」ドロップダウンメニューをクリックし、「データモデル」を選択します。データモデルエディターが開きます。
SQLクエリのデータセットを定義する：データモデル画面で「データセット」の横にあるプラスアイコンをクリックし、「SQLクエリ」を選択します。新しいダイアログでデータセット名（例：AR_INVOICE_LIFECYCLE）を入力します。通常はApplicationDB_FSCMをデータソースとして選択します。
SQLクエリを入力する：この文書のqueryセクションにあるSQLクエリ全体をコピーし、SQLクエリの入力欄に貼り付けます。クエリ内の:P_START_DATE、:P_END_DATE、:P_BUSINESS_UNITなどのパラメーターは自動的に認識されます。
パラメーターを設定してデータを確認する：「パラメーター」タブで既定値や表示オプションを設定します。次に「データ」タブでパラメーターの値（例：短い日付範囲）を入力し、「表示」をクリックしてクエリをテストし、出力データのサンプルを確認します。
データモデルを保存する：データが正しいことを確認したら、「保存」アイコンをクリックし、適切なフォルダー（例：Shared Folders/Custom/ProcessMining）に保存します。
レポートを作成する：カタログに戻り、「新規」ドロップダウンから「レポート」を選択します。レポート作成ウィザードで「データモデルを使用」を選び、先ほど保存したデータモデルを指定します。
レポートのレイアウトを設定する：レポートレイアウトエディターでは、複雑なレイアウトを作成する必要はありません。「表を作成」を選択し、データセットの列をすべてドラッグ＆ドロップします。目的は書式付きレポートではなく、生のデータのエクスポートです。
既定の出力形式をCSVにする：レポートのプロパティで、既定の出力形式をCSVに設定します。レポートの実行時に、プロセスマイニングに適したテキストファイルが生成されます。
レポートをスケジュールする：カタログでレポートを見つけ、「その他」から「スケジュール」を選択します。ジョブを新規作成し、パラメーター（日付範囲、事業部門）と出力先を設定します。出力先には、Content Server（UCM）や外部SFTPサーバーを指定できます。
イベントログを取得する：スケジュールしたジョブの完了後、指定した出力先（例：UCMコンテンツリポジトリ）に移動し、生成されたCSVファイルをダウンロードします。このファイルがイベントログです。
アップロードの準備をする：CSVファイルの列見出しが、クエリで定義した内容（InvoiceNumber、ActivityName、EventTimestampなど）と一致していることを確認します。これでプロセスマイニングプラットフォームにアップロードできます。

設定

BI Publisherのパラメーター：クエリには、対象データの範囲を指定するパラメーターが設定されています。データモデルからレポートを作成すると、自動的に表示されます。
- :P_START_DATE：抽出期間の開始日（形式：YYYY-MM-DD）。クエリはイベントのタイムスタンプを基準にデータを絞り込みます。
- :P_END_DATE：抽出期間の終了日（形式：YYYY-MM-DD）。
- :P_BUSINESS_UNIT：請求書を絞り込む事業部門名です。データ量を抑え、分析対象を絞るために指定します。
日付範囲：初期のテストや分析では、3～6か月分など、期間を限定してデータを抽出してください。全体を分析する場合は、業務上の必要性に応じて12～18か月分を抽出します。
ステータスコードの設定：クエリには'[Your Pending Approval Status]'のようなプレースホルダーが含まれています。請求書の承認ワークフローで使用している実際のステータスコードに置き換えてください。機能担当者に確認し、RA_CUST_TRX_TYPES_ALLテーブルまたはシステムの参照データから値を特定してください。
パフォーマンス：長期間またはすべての事業部門のデータを一度に抽出すると、システムリソースを多く消費する場合があります。他のユーザーへの影響を避けるため、BI Publisherレポートは利用の少ない時間帯に実行することを強くおすすめします。
前提条件：BI Publisherでデータモデルやレポートを作成できるロール（BI Administratorや同等の権限を持つカスタムロールなど）が付与されたユーザーアカウントが必要です。また、必要な売掛金、顧客、事業部門のデータにアクセスできるデータセキュリティプロファイルも必要です。

クエリの例 sql

WITH BaseInvoices AS (
    SELECT
        rct.trx_number,
        rct.customer_trx_id,
        hp.party_name AS customer_name,
        rct.trx_date,
        rct.creation_date,
        rct.last_update_date,
        rct.complete_flag,
        aps.status AS payment_schedule_status,
        aps.amount_due_original,
        aps.due_date,
        aps.dispute_flag,
        aps.gl_date_closed,
        rct.last_printed_date,
        rct.status_trx,
        bu.bu_name AS business_unit
    FROM
        ra_customer_trx_all rct
    JOIN
        hz_cust_accounts hca ON rct.bill_to_customer_id = hca.cust_account_id
    JOIN
        hz_parties hp ON hca.party_id = hp.party_id
    JOIN
        ar_payment_schedules_all aps ON rct.customer_trx_id = aps.customer_trx_id
    JOIN
        fun_all_business_units_v bu ON rct.org_id = bu.bu_id
    WHERE
        bu.bu_name = :P_BUSINESS_UNIT
        AND rct.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD') + 1
        AND aps.class = 'INV'
)
-- 1. Invoice Created
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Created' AS "ActivityName",
    bi.creation_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi

UNION ALL

-- 2. Invoice Completed
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Completed' AS "ActivityName",
    bi.last_update_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.complete_flag = 'Y'

UNION ALL

-- 3. Invoice Submitted for Approval
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Submitted for Approval' AS "ActivityName",
    bi.last_update_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.status_trx = '[Your Pending Approval Status]' -- Placeholder: Configure status based on your system

UNION ALL

-- 4. Invoice Approved
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Approved' AS "ActivityName",
    bi.last_update_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.status_trx = '[Your Approved Status]' -- Placeholder: Configure status based on your system

UNION ALL

-- 5. Invoice Rejected
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Rejected' AS "ActivityName",
    bi.last_update_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.status_trx = '[Your Rejected Status]' -- Placeholder: Configure status based on your system

UNION ALL

-- 6. Invoice Sent to Customer
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Sent to Customer' AS "ActivityName",
    bi.last_printed_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.last_printed_date IS NOT NULL

UNION ALL

-- 7. Payment Due Date Reached
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Payment Due Date Reached' AS "ActivityName",
    bi.due_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.due_date <= CURRENT_TIMESTAMP

UNION ALL

-- 8. Payment Reminder Issued
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Payment Reminder Issued' AS "ActivityName",
    dlt.trx_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
JOIN
    ar_dunning_letters_trx dlt ON bi.customer_trx_id = dlt.customer_trx_id

UNION ALL

-- 9. Dispute Initiated
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Dispute Initiated' AS "ActivityName",
    bi.last_update_date AS "EventTimestamp", -- Uses last update as a proxy for dispute date
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    'Disputed' AS "InvoiceStatus", -- Overrides status
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.dispute_flag = 'Y'

UNION ALL

-- 10. Customer Payment Received
SELECT DISTINCT
    bi.trx_number AS "InvoiceNumber",
    'Customer Payment Received' AS "ActivityName",
    acr.receipt_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
JOIN
    ar_receivable_applications_all ara ON bi.customer_trx_id = ara.applied_customer_trx_id
JOIN
    ar_cash_receipts_all acr ON ara.cash_receipt_id = acr.cash_receipt_id
WHERE
    ara.status = 'APP'

UNION ALL

-- 11. Payment Applied to Invoice
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Payment Applied to Invoice' AS "ActivityName",
    ara.apply_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
JOIN
    ar_receivable_applications_all ara ON bi.customer_trx_id = ara.applied_customer_trx_id
WHERE
    ara.status = 'APP'

UNION ALL

-- 12. Invoice Adjusted
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Adjusted' AS "ActivityName",
    adj.creation_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
JOIN
    ar_adjustments_all adj ON bi.customer_trx_id = adj.customer_trx_id

UNION ALL

-- 13. Invoice Closed
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Closed' AS "ActivityName",
    bi.gl_date_closed AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    'Closed' AS "InvoiceStatus", -- Overrides status
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.payment_schedule_status = 'CL' AND bi.gl_date_closed IS NOT NULL

ステップ

前提条件：Python 3.6以降と、requestsおよびpandasライブラリがインストールされていることを確認します。次のpipコマンドでインストールできます：pip install requests pandas。
Oracle Fusionの認証情報：Oracle Fusion REST APIへのアクセスに必要な認証情報を用意します。FusionインスタンスのベースURL、ユーザー名、売掛金データの読み取りに必要な権限を持つユーザーのパスワードが必要です。
スクリプトを設定する：提供されたPythonスクリプトをエディターで開きます。スクリプトの先頭にある設定セクションで、FUSION_URL、USERNAME、PASSWORDやstart_dateなどのフィルターパラメーターのプレースホルダーを置き換えます。
APIエンドポイントを確認する：スクリプトでは主にreceivablesInvoicesエンドポイントを使って請求書の基本データを取得します。その後、receivablesReceipts、receivablesReceiptApplications、receivablesAdjustments、collectionsDelinquentTransactionsなどのエンドポイントを呼び出し、関連イベントを収集します。
ページネーションを処理する：スクリプトにはget_paginated_dataというヘルパー関数が含まれています。APIレスポンスのnextリンクをたどり、クエリに該当するすべてのレコードを取得するまでページネーションを自動で処理します。
データを取得する：スクリプトのメイン処理では、まず指定した日付範囲の請求書一覧を取得します。次に各請求書を順に処理し、詳細情報と関連イベントを収集します。
イベントを作成する：請求書ごとに、さまざまなアクティビティの行を作成します。「請求書作成」などのアクティビティは、請求書のフィールド（CreationDate）から直接取得します。「請求書への入金消込」などのアクティビティでは、別のAPIを呼び出し、請求書番号とデータを関連付けます。
計算によるイベントを処理する：「支払期日到来」イベントは、取引データに直接記録されていません。スクリプトは請求書のDueDateを過ぎていて、かつ未払いの場合に、このイベントを計算します。
スクリプトを実行する：ターミナルでpython your_script_name.pyを実行します。請求書ごとのデータ取得状況が進捗として表示されます。
出力を確認する：実行が完了すると、同じディレクトリにoracle_fusion_ar_event_log.csvというファイルが作成されます。このファイルに抽出したイベントログが含まれます。
アップロードの準備をする：生成されたCSVファイルを開きます。基本的なプロセスマップを作成する場合は、列見出しがCaseId、ActivityName、EventTimestampであることを確認します。または、アップロード時にプロセスマイニングツールで、生成された列（InvoiceNumber、ActivityName、EventTimestamp、InvoiceAmountなど）を対応付けます。

設定

APIベースURL：Oracle Fusion FinancialsインスタンスのルートURLです。例：https://[your-pod].fa.em2.oraclecloud.com/fscmRestApi/resources/11.13.18.05。
認証：スクリプトはBasic Authenticationを使用します。ユーザーアカウントに「Accounts Receivable Manager」などのロール、またはreceivablesInvoices、receivablesReceipts、receivablesReceiptApplications、receivablesAdjustments、collectionsDelinquentTransactionsのRESTリソースにアクセスできる権限を持つカスタムロールが付与されていることを確認してください。
日付範囲フィルター：スクリプトはCreationDateを条件にしたqパラメーターを使い、最初に取得する請求書を絞り込みます。抽出時間とAPIへの負荷を抑えるため、まずは3～6か月など短い期間から始めることをおすすめします。例：CreationDate between 'YYYY-MM-DD' and 'YYYY-MM-DD'。
ページネーションの上限：API呼び出しのlimitパラメーターで、1回のリクエストで返されるレコード数を指定します。通常は100～500が効率的です。スクリプトには既定の上限が設定されています。
事業部門のフィルター：クエリパラメーター（q）に事業部門の条件を追加すると、抽出対象を絞り込めます。例：BusinessUnitName = '[Your Business Unit Name]'。
パフォーマンス：請求書を1件ずつ処理するため、大量のデータを抽出すると時間がかかる場合があります。スクリプトは請求書ごとに複数回APIを呼び出します。請求書が10万件を超える場合は、処理性能の低下やAPIのレート制限を避けるため、バッチに分けるか、利用の少ない時間帯に実行してください。

クエリの例 python

import requests
import pandas as pd
import datetime
import os

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Oracle Fusion instance URL, username, and password
FUSION_URL = class="hl-string">"https://[your-pod].fa.em2.oraclecloud.com/fscmRestApi/resources/11.13.18.05"
USERNAME = class="hl-string">"YOUR_USERNAME"
PASSWORD = class="hl-string">"YOUR_PASSWORD"

class=class="hl-string">"hl-comment"># --- Filter Parameters ---
class=class="hl-string">"hl-comment"># Define the date range for the initial invoice query
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-06-30"
class=class="hl-string">"hl-comment"># Optional: Filter by a specific Business Unit
BUSINESS_UNIT_FILTER = class="hl-string">"" class=class="hl-string">"hl-comment"># e.g., class="hl-string">" and BusinessUnitName = 'US1 Business Unit'"

class=class="hl-string">"hl-comment"># API call settings
API_LIMIT = 100

def get_paginated_data(endpoint, params):
    class="hl-string">"""Helper function to handle pagination for Oracle Fusion REST API calls."""
    all_items = []
    url = fclass="hl-string">"{FUSION_URL}/{endpoint}"
    
    while url:
        try:
            response = requests.get(url, auth=(USERNAME, PASSWORD), params=params)
            response.raise_for_status()
            data = response.json()
            all_items.extend(data.get(class="hl-string">'items', []))
            
            class=class="hl-string">"hl-comment"># Get the next page link
            links = data.get(class="hl-string">'links', [])
            next_link = next((link[class="hl-string">'href'] for link in links if link[class="hl-string">'rel'] == class="hl-string">'next'), None)
            url = next_link
            class=class="hl-string">"hl-comment"># Params are only needed for the first request
            params = {}

        except requests.exceptions.HTTPError as e:
            print(fclass="hl-string">"HTTP Error fetching data from {url}: {e}")
            print(fclass="hl-string">"Response body: {response.text}")
            break
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Request Error: {e}")
            break
            
    return all_items


def main():
    class="hl-string">"""Main function to extract, transform, and save the event log."""
    event_log = []
    today = datetime.datetime.now().strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')

    class=class="hl-string">"hl-comment"># 1. Fetch main invoice data
    print(class="hl-string">"Fetching invoices...")
    invoice_params = {
        class="hl-string">'q': fclass="hl-string">"CreationDate between '{START_DATE}' and '{END_DATE}'{BUSINESS_UNIT_FILTER}",
        class="hl-string">'fields': class="hl-string">'TransactionNumber,CreationDate,TransactionDate,CreatedBy,LastUpdateDate,LastUpdatedBy,Amount,AmountDueRemaining,Status,CompletedDate,CustomerName,DueDate,BusinessUnitName,ApprovalStatus,paymentSchedules,CustomerTransactionId',
        class="hl-string">'limit': API_LIMIT,
        class="hl-string">'expand': class="hl-string">'paymentSchedules'
    }
    invoices = get_paginated_data(class="hl-string">'receivablesInvoices', invoice_params)
    print(fclass="hl-string">"Found {len(invoices)} invoices.")

    class=class="hl-string">"hl-comment"># 2. Process each invoice to generate events
    for i, inv in enumerate(invoices):
        print(fclass="hl-string">"Processing invoice {i+1}/{len(invoices)}: {inv.get('TransactionNumber')}")
        
        case_id = inv.get(class="hl-string">'TransactionNumber')
        cust_trx_id = inv.get(class="hl-string">'CustomerTransactionId')
        common_attrs = {
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'InvoiceAmount': inv.get(class="hl-string">'Amount'),
            class="hl-string">'CustomerName': inv.get(class="hl-string">'CustomerName'),
            class="hl-string">'DueDate': inv.get(class="hl-string">'DueDate'),
            class="hl-string">'InvoiceStatus': inv.get(class="hl-string">'Status'),
            class="hl-string">'BusinessUnit': inv.get(class="hl-string">'BusinessUnitName')
        }

        class=class="hl-string">"hl-comment"># Event: Invoice Created
        event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Created', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'CreationDate')})

        class=class="hl-string">"hl-comment"># Event: Invoice Completed
        if inv.get(class="hl-string">'CompletedDate'):
            event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Completed', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'CompletedDate')})
        
        class=class="hl-string">"hl-comment"># Events: Approval Cycle (based on final status)
        if inv.get(class="hl-string">'ApprovalStatus') == class="hl-string">'APPROVED':
            event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Approved', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'LastUpdateDate')})
        elif inv.get(class="hl-string">'ApprovalStatus') == class="hl-string">'REJECTED':
            event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Rejected', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'LastUpdateDate')})
        elif inv.get(class="hl-string">'ApprovalStatus') == class="hl-string">'PENDING':
            event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Submitted for Approval', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'LastUpdateDate')})
        
        class=class="hl-string">"hl-comment"># Placeholder for class="hl-string">'Invoice Sent to Customer' - requires specific configuration
        class=class="hl-string">"hl-comment"># This might come from BI Publisher or another module. Using LastUpdateDate if status is class="hl-string">'COMPLETE' as an example.
        if inv.get(class="hl-string">'Status') == class="hl-string">'COMPLETE': class=class="hl-string">"hl-comment"># This is a proxy event
             event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Sent to Customer', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'LastUpdateDate')})

        class=class="hl-string">"hl-comment"># Event: Payment Due Date Reached (calculated)
        if inv.get(class="hl-string">'DueDate') and inv.get(class="hl-string">'DueDate') < today and inv.get(class="hl-string">'AmountDueRemaining', 0) > 0:
            event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Payment Due Date Reached', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'DueDate')})

        class=class="hl-string">"hl-comment"># Event: Dispute Initiated
        for ps in inv.get(class="hl-string">'paymentSchedules', []):
            if ps.get(class="hl-string">'DisputeDate'):
                event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Dispute Initiated', class="hl-string">'EventTimestamp': ps.get(class="hl-string">'DisputeDate')})
                break class=class="hl-string">"hl-comment"># Assuming one dispute event per invoice for simplicity

        class=class="hl-string">"hl-comment"># Event: Invoice Closed
        if inv.get(class="hl-string">'AmountDueRemaining') == 0 and inv.get(class="hl-string">'Status') == class="hl-string">'CLOSED':
             event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Closed', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'LastUpdateDate')})
        
        class=class="hl-string">"hl-comment"># 3. Fetch related events using other APIs
        if cust_trx_id:
            class=class="hl-string">"hl-comment"># Events: Payment Applied and Payment Received
            apps = get_paginated_data(class="hl-string">'receivablesReceipts', {class="hl-string">'q': fclass="hl-string">'AppliedCustomerTransactionId={cust_trx_id}', class="hl-string">'onlyData': class="hl-string">'true', class="hl-string">'fields': class="hl-string">'ReceiptNumber,ReceiptDate,ActivityApplication.ApplyDate,ActivityApplication.AppliedCustomerTransactionId'})
            for app in apps:
                for activity_app in app.get(class="hl-string">'ActivityApplication', []):
                    if activity_app.get(class="hl-string">'AppliedCustomerTransactionId') == cust_trx_id:
                        event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Customer Payment Received', class="hl-string">'EventTimestamp': app.get(class="hl-string">'ReceiptDate')})
                        event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Payment Applied to Invoice', class="hl-string">'EventTimestamp': activity_app.get(class="hl-string">'ApplyDate')})

            class=class="hl-string">"hl-comment"># Event: Invoice Adjusted
            adjustments = get_paginated_data(class="hl-string">'receivablesAdjustments', {class="hl-string">'q': fclass="hl-string">'CustomerTransactionId={cust_trx_id}', class="hl-string">'onlyData': class="hl-string">'true', class="hl-string">'fields': class="hl-string">'ApplyDate'})
            for adj in adjustments:
                event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Adjusted', class="hl-string">'EventTimestamp': adj.get(class="hl-string">'ApplyDate')})

            class=class="hl-string">"hl-comment"># Event: Payment Reminder Issued (from Delinquency data)
            reminders = get_paginated_data(class="hl-string">'collectionsDelinquentTransactions', {class="hl-string">'q': fclass="hl-string">'TransactionId={cust_trx_id}', class="hl-string">'onlyData': class="hl-string">'true', class="hl-string">'fields': class="hl-string">'LastDunningLetterDate'})
            for rem in reminders:
                if rem.get(class="hl-string">'LastDunningLetterDate'):
                    event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Payment Reminder Issued', class="hl-string">'EventTimestamp': rem.get(class="hl-string">'LastDunningLetterDate')})

    class=class="hl-string">"hl-comment"># 4. Create DataFrame and save to CSV
    if not event_log:
        print(class="hl-string">"No events generated. Exiting.")
        return

    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTimestamp'])
    class=class="hl-string">"hl-comment"># Ensure required columns are present
    df_final = df[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'DueDate', class="hl-string">'InvoiceStatus', class="hl-string">'BusinessUnit']]

    output_filename = class="hl-string">'oracle_fusion_ar_event_log.csv'
    df_final.to_csv(output_filename, index=False)
    print(fclass="hl-string">"\nEvent log successfully saved to {os.path.abspath(output_filename)}")

if __name__ == class="hl-string">'__main__':
    main()

始める準備はできましたか？

このテンプレートを使ってデータを準備し、受注から入金までの請求・請求書処理を効率化して、入金までの期間を短縮しましょう。Oracle Fusion Financialsの業務に関するインサイトを得て、今すぐ効率向上に取り組めます。

改善ガイドに戻る

テンプレートをダウンロード

Oracleの請求・請求書処理の改善を始めましょう

このソリューションで請求サイクルタイムを30％短縮し、キャッシュフローを改善できます。

無料トライアルを開始しましょう

クレジットカードは不要です。数分で設定できます。

受注から入金までの請求・請求書処理向けデータテンプレート

受注から入金までの請求・請求書処理向けデータテンプレート

受注から入金までの請求・請求書処理の属性

受注から入金までの請求・請求書処理のアクティビティ

データ抽出ガイド

請求・請求書処理データ用Oracle BI Publisherレポート

ステップ

設定

クエリの例 sql

Oracle Fusion REST APIを使ったPythonスクリプトによる抽出

ステップ

設定

クエリの例 python

始める準備はできましたか？

Oracleの請求・請求書処理の改善を始めましょう