> 継続的なプロセス改善 > 受注から現金化までのプロセス（請求・回収） > Oracle Fusion Financials > データテンプレート

受注から入金までの請求・支払いデータテンプレート

Oracle Fusion Financials

受注から現金化までのプロセス（請求・回収）属性 (22) 受注から現金化までのプロセス（請求・回収）活動 (13) 抽出ガイド (2)

受注から入金までの請求・支払いデータテンプレート

このテンプレートは、受注から入金までの請求・支払いプロセスを分析するために必要なデータ抽出に関する包括的なガイドを提供します。収集すべき必須属性、追跡すべき重要なアクティビティ、およびデータ抽出の実践的なガイダンスを概説しています。このテンプレートに従うことで、効果的なプロセスマイニングと最適化のための堅牢なデータセットを確保できます。

収集を推奨する項目
追跡すべき主要アクティビティ
Oracle Fusion Financials 向け抽出ガイド

イベントログについて初めての方へ：プロセスマイニングのイベントログ作成方法.

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

受注から現金化までのプロセス（請求・回収）属性

受注から入金までの請求・支払いプロセスの包括的な分析のために、イベントログに含めるべき推奨データフィールドです。

3 必須 5 推奨 14 任意

	名前	説明
	請求書番号 InvoiceNumber	各請求書の一意の識別子であり、すべての関連活動を追跡するための主要なケースIDとして機能します。
説明請求書番号は、請求プロセス分析の基盤です。ケースIDとして機能し、請求書作成から最終支払い、クローズまでのすべてのイベントをグループ化します。これにより、単一の請求書文書のライフサイクルを完全にエンドツーエンドで把握できます。プロセスマイニングでは、請求書番号による分析により、プロセスバリアントの可視化、個々の請求書のサイクルタイムの計算、および特定の取引に影響を与えるボトルネックや手戻りループの特定が可能になります。これは、「請求書エンドツーエンドサイクルタイム」などのダッシュボードや、請求書ごとの売掛金回収期間（DSO）などの基本的なKPIを計算するために不可欠です。その重要性この属性は、関連するすべての請求および支払い活動を単一のケースに接続するため、請求書ライフサイクルの完全かつ正確な分析を可能にする上で不可欠です。取得元これは通常、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として、事業部門定義にリンクされます。例 US ConsultingEMEA ManufacturingAPAC Services
	支払期日 DueDate	請求書の支払いが期日を迎える日付。
説明期日（Due Date）は、支払い条件によって決定される請求書の支払い期限を定義する重要な日付属性です。この属性は、回収業務と財務健全性を監視するために不可欠です。期限内支払い率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
	`売上債権回転日数` DaysSalesOutstanding	請求書日付から支払い受領日までの日数。
説明売掛金回収日数（DSO）は、請求書発行後に支払いを回収するまでにかかる平均時間を測定する重要な財務指標です。この属性は、個々の請求書ごとにそれを計算します。 DSO全体は主要なKPIですが、個々の請求書レベルで計算することで、より深い分析が可能になります。これは、トレンドダッシュボードの作成、DSOが高い請求書の特性の特定、およびプロセス遅延の財務的影響の測定に使用できます。この詳細な計算により、DSO全体のKPIの背後にある要因を理解するために必要なデータが提供されます。その重要性個々の請求書レベルで重要なキャッシュフロー指標を計算し、回収期間と財務パフォーマンスを左右する要因の詳細な分析を可能にします。取得元これは、「顧客からの支払い受領」アクティビティのタイムスタンプと「請求書日付」属性の差を見つけることで計算されます。例 356228
	ソースシステム SourceSystem	イベントデータが抽出された元システムです。
説明この属性は、データが生成されたソースアプリケーションを特定します。このプロセスでは、通常Oracle Fusion Financialsになりますが、Oracle Receivables (AR)のような特定のモジュールを指定することもできます。複数の統合システムが存在する環境では、このフィールドはデータソースを区別するのに役立ち、データ検証とガバナンスにとって重要です。分析が正確で意図されたデータセットに基づいていることを保証します。その重要性データの出所を特定します。これはデータガバナンス、トラブルシューティング、および分析が正しいシステムオブレコードに基づいていることを保証するために不可欠です。取得元これは通常、データ抽出と変換プロセス中に追加される静的値（「Oracle Fusion Financials」）です。例 Oracle Fusion FinancialsOracle AR CloudFusion Apps
	ユーザー User	特定のアクティビティを実行した従業員またはシステムユーザー。
説明ユーザー属性は、プロセスステップの実行を担当する人物または自動エージェントを識別します。これは、請求書を作成したユーザー、それを承認したマネージャー、またはリマインダーを発行した回収担当者である可能性があります。ユーザー別に分析することで、トレーニングの機会、ワークロードの分散、個人またはチーム間のパフォーマンスの差異を特定するのに役立ちます。特定のユーザーが高いエラー率に関連しているか、または特定の承認者が一貫したボトルネックであるかを明らかにできます。その重要性プロセスステップの責任を割り当て、ユーザーパフォーマンスの分析、ワークロードのバランス調整、およびトレーニングニーズの特定を可能にします。取得元さまざまな取引テーブルやワークフローテーブルのCREATED_BYやLAST_UPDATED_BYなどのユーザーIDフィールドから取得されます。この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）に保存されている顧客の住所情報から導出されます。請求書自体に直接存在するフィールドではありません。例北米ヨーロッパアジア太平洋
	手戻り IsRework	アクティビティが繰り返しの承認や修正のような手戻りと見なされるかどうかを示すブールフラグ。
説明この計算属性は、不要または冗長な作業を表すアクティビティにフラグを付けます。例としては、請求書が却下されてから承認のために再提出される場合や、初期作成後に修正が行われる場合などがあります。手戻りにフラグを付けることで、プロセスへの影響を定量化することが容易になります。請求手戻り率KPIは、この属性から直接計算されます。ダッシュボードは、手戻りの頻度を可視化し、それが追加する余分なサイクルタイムを測定することで、非効率性やエラーの原因を特定するのに役立ちます。その重要性不要な作業や繰り返しの作業にフラグを立てることで、プロセスの非効率性を直接定量化し、品質問題のコストと時間への影響を簡単に測定できるようにします。取得元これは、データ変換中にアクティビティのシーケンスに基づいて計算されます。例えば、同じケースで「請求書承認」アクティビティの前に「請求書却下」アクティビティがある場合、それは手戻りとしてフラグが立てられます。例 truefalse
	支払方法 PaymentMethod	顧客が支払いを行うために使用した方法（銀行振込やクレジットカードなど）。
説明この属性は、顧客が請求書をどのように支払ったかを指定します。この情報は、支払い傾向とコストを分析するのに役立ちます。異なる支払い方法は、異なる処理時間と取引コストを持つ可能性があります。支払い方法別に分析することで、特定の決済方法が照合エラーや遅延を招きやすいかどうかを理解するのに役立ちます。また、顧客に効率的な支払いチャネルの使用を促す戦略を策定するのにも役立ちます。その重要性支払い処理効率、トランザクションコスト、およびさまざまな支払いチャネルに関連する照合エラー率の分析に役立ちます。取得元 `AR_CASH_RECEIPTS_ALL`のような現金受領テーブルに見つかり、支払い方法を示すフィールドが含まれています。例 ACH銀行振込クレジットカード小切手
	支払条件 PaymentTerms	「Net 30」や「2% 10, Net 30」といった、請求書支払いの合意された条件。
説明支払い条件は、請求書がいつどのように支払われるべきかを規定するルールを定義し、早期支払いに対する潜在的な割引を含みます。この情報は、売掛金とキャッシュフローを管理するために不可欠です。この属性は、正しい期日を計算し、早期支払い割引の機会を特定するために不可欠です。早期支払い割引獲得率KPIは、どの請求書が割引の対象であったかを判断するために、このデータに直接依存します。その重要性請求書の支払いルールを定義し、期日計算、および早期支払い割引の獲得を追跡し最適化する能力に直接影響を与えます。取得元 `RA_TERMS`テーブルに位置し、`RA_CUSTOMER_TRX_ALL`の`term_id`を介してトランザクションにリンクされます。例支払条件：正味30日支払条件：正味60日2% 10, Net 30
	期日内支払い済みか IsPaidOnTime	請求書が期日までに支払われたかどうかを示すブールフラグ。
説明この計算属性は、支払いの適時性を示す単純な真偽値の指標を提供します。これは、「顧客からの支払い受領」アクティビティの日付と、請求書の「期日」属性を比較することで導出されます。このフラグは、期限内支払い率KPIの分析と報告を簡素化します。顧客、地域、請求額などの要因が遅延支払いとどのように相関しているかを理解するための簡単なフィルタリングとセグメンテーションを可能にします。これは、回収効果を評価するための重要な指標です。その重要性回収パフォーマンスの測定を簡素化し、期限内支払いと遅延支払いの要因を簡単に分析できます。取得元最終支払いアクティビティのタイムスタンプとDueDate属性を比較して計算されます。ロジックは：`PaymentTimestamp <= DueDate`です。例 truefalse
	紛争理由 DisputeReason	顧客によって請求書が異議申し立てされた理由。
説明顧客が請求書に異議を唱える際、その紛争の理由が捕捉されます。これは、価格設定、数量、サービス品質、またはその他の問題に関連する可能性があります。紛争理由を分析することは、根本原因分析を行うための強力な方法です。紛争の最も一般的な理由を理解することで、企業は価格設定、注文処理、またはデータ品質における根本的な問題に対処できます。これは、平均請求書紛争解決時間を短縮し、顧客満足度を向上させるのに役立ちます。その重要性支払い遅延や顧客不満の根本原因を直接的に把握し、企業がシステム的な問題に対処できるようにします。取得元この情報は、Oracle Collectionsまたは関連する紛争管理モジュールに保存されている可能性があります。専用の紛争テーブル、または取引自体の理由コードとして存在する可能性があります。例不正確な価格設定数量不一致破損品重複請求書
	終了日時 EventEndTime	特定のアクティビティまたはイベントが完了した正確な日時。
説明イベント終了時刻は、アクティビティが完了した瞬間を記録します。多くのイベントは瞬時ですが、「請求書承認」のような一部のアクティビティは、提出された時点から決定が下されるまで、期間を持つ場合があります。終了時刻を持つことで、アクティビティ処理時間の正確な計算が可能になります。これは、ユーザーが特定のタスクに費やす時間を分析するのに役立ちます。待機時間と実際の処理時間を区別することで、ボトルネック分析の精度が向上します。その重要性アクティビティ処理時間の正確な計算を可能にし、実稼働時間とアイドル待ち時間を区別します。これは、詳細なボトルネック分析の鍵となります。取得元これは、プロセスの次のアクティビティの開始時刻を取得することで導出されることが多いです。一部のアクティビティについては、ワークフローログに専用の終了時刻フィールドが存在する場合があります。例 2023-04-15T09:05:12Z2023-04-18T15:00:00Z2023-05-20T11:25:45Z
	経理部門 BillingDepartment	請求書の作成と管理を担当する社内部署またはチーム。
説明この属性は、請求プロセスを処理した組織内の特定のチームまたは部署を識別します。分析のための組織的コンテキストの別の層を提供します。請求部門別にプロセスをセグメント化することで、企業は異なるチームの効率と正確性を比較できます。どの部門が高い手戻り率、長い承認サイクルを持っているか、または高いDSOに多く貢献しているかを特定するのに役立ち、ターゲットを絞ったトレーニングやプロセス標準化の機会を強調します。その重要性内部チーム間のパフォーマンス比較を可能にし、ベストプラクティス、リソースニーズ、またはプロセス改善が必要な領域の特定に役立ちます。取得元この情報は、請求書を作成したユーザーから、ユーザーをHRシステム内の割り当てられた部門にリンクさせることで（例：PER_ALL_ASSIGNMENTS_Fを介して）導出される可能性があります。例 Corporate Billingサービス請求チーム製品販売請求
	請求日 InvoiceDate	請求書が発行された公式な日付。
説明請求書日付（取引日付とも呼ばれる）は、請求書文書に記録された日付です。これは支払い条件計算の開始点として機能します。この日付は、売掛金回収期間（DSO）を計算するための重要な要素です。DSOは、請求書日付から支払い日までの期間を測定するためです。システム内の作成日とは異なり、顧客の視点から見た支払いサイクルの公式な開始を表します。その重要性請求書ライフサイクルの公式な開始日として機能し、売掛金回収期間（DSO）KPI算出の基準となります。取得元 `RA_CUSTOMER_TRX_ALL`テーブルの`TRX_DATE`フィールドに位置します。例 2023-04-142023-05-182023-06-25
	請求書処理リードタイム InvoiceCycleTime	請求書が最初に作成されてからクローズされるまでの合計時間。
説明この属性は、単一ケースの請求書ライフサイクル全体のエンドツーエンド期間を測定します。これは通常、「請求書作成」という最初の活動と、「請求書クローズ」という最終活動との間の時間差として計算されます。このメトリックは、全体的なプロセス効率の高レベルな視点を提供します。「請求書エンドツーエンドサイクルタイム」ダッシュボードの主要な測定値です。顧客や事業部門など、さまざまなディメンションでこの属性を分析することで、組織はどの種類の請求書の処理に最も時間がかかり、その根本原因を調査することができます。その重要性全体的なプロセス速度を示す単一の重要な指標を提供し、どの請求書が最初から最後まで完了するのに最も時間がかかるかを迅速に特定するのに役立ちます。取得元これは計算メトリックであり、各一意の請求書番号における最大および最小のイベントタイムスタンプの差を取ることで導出されます。例 45日8時間32日2時間90日12時間

必須推奨任意

受注から現金化までのプロセス（請求・回収）活動

これらは、正確なプロセスディスカバリーのために`イベントログ`に記録すべき主要なプロセス`ステップ`と`マイルストーン`です。

6 推奨 7 任意

	アクティビティ	説明
	請求書がクローズ済み	請求書が完全に支払いされ、照合が完了し、そのライフサイクルが完了した状態。このイベントは通常、請求書の未払い残高がゼロになり、そのステータスが更新されたときに推測されます。
その重要性これは請求書の最終解決であり、プロセスの終了を示します。この状態に達するまでの合計時間は、請求プロセスの主要なKPIであるエンドツーエンドサイクルタイムです。取得元 `AR_PAYMENT_SCHEDULES_ALL`テーブルにおいて、ステータスが「CLOSED」に更新され、`amount_due_remaining`がゼロの場合に推論されます。`gl_date_closed`フィールドがクローズ日を示します。取得特定の請求書について、AR_PAYMENT_SCHEDULES_ALLのgl_date_closedを使用します。イベントタイプ inferred
	請求書に支払いを適用済み	受領した顧客の支払いが特定の請求書に正常に照合され、適用され、未払い残高が減少した状態。これは個別の取引記録です。
その重要性この活動は、現金が適切に割り当てられたことを確認するものであり、正確な滞留分析レポートと財務諸表にとって不可欠です。売掛金に対する現金を認識する最終ステップです。取得元 `AR_RECEIVABLE_APPLICATIONS_ALL`テーブルに明示的に記録されます。`apply_date`と`gl_date`フィールドは、適用が発生した時期を示します。取得 AR_RECEIVABLE_APPLICATIONS_ALLテーブルのapply_dateを使用し、現金受領を請求書にリンクさせます。イベントタイプ explicit
	請求書作成	システムにおける請求書取引の初期作成（多くの場合、ドラフトまたは不完全なステータス）。このイベントは、ユーザーが売掛金管理モジュールで新しい請求書レコードを初めて保存したときに明示的にログに記録されます。
その重要性これは請求プロセスの明確な開始点です。作成から完了までの時間を分析することで、フロントエンドのデータ入力遅延やシステムパフォーマンスの問題を特定するのに役立ちます。取得元このイベントは、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
	顧客へ請求書送付済み	請求書が顧客の希望する方法（メールまたは印刷など）で顧客に送付された状態。システムは通常、送付アクションが実行された際のタイムスタンプを記録します。
その重要性この活動は、支払い期間を正式に開始します。承認から送付までの時間を測定することは、請求書配布プロセスの効率を理解するための鍵です。取得元これは、RA_CUSTOMER_TRX_ALLテーブルの「last_printed_date」フィールドから、または電子送付が使用されている場合はOracle Business Intelligence Publisherのログから推測できます。取得請求書に関連する配信または印刷ログのタイムスタンプを使用します。イベントタイプ inferred
	承認のために請求書提出済み	設定されている場合、請求書が承認ワークフローに正式に提出された状態。これは、請求書ステータスが承認待ちの状態に更新され、指定された承認者に通知がトリガーされたときに捕捉されます。
その重要性承認サイクルの開始を示します。この活動を追跡することは、その後の承認時間を測定し分析するために不可欠であり、全体的な請求書サイクルタイムの主要な構成要素です。取得元請求書トランザクションのステータス変更から推論されるか、承認タスクの開始をログに記録するOracle Business Process Management (BPM) ワークフローテーブルから取得されます。取得請求書の承認ステータスが「保留中」または類似の状態に変化したときのタイムスタンプを特定します。イベントタイプ inferred
	支払いリマインダー発行済み	期限切れの請求書に対して、顧客に督促状またはリマインダー通知が送付されました。これは、回収モジュールによって記録された明示的なアクションです。
その重要性リマインダーを追跡することで、回収プロセスの有効性を測定するのに役立ちます。どのリマインダー戦略がより迅速な支払いにつながるかを分析することを可能にします。取得元 Oracle Advanced Collectionsモジュールに明示的に記録されます。`IEX_DUNNINGS`のような督促履歴テーブルには、送信されたリマインダーの日付とレベルが記録されます。取得督促履歴テーブルから取得し、督促トランザクションを請求書にリンクします。イベントタイプ explicit
	支払い期日到達	請求書の支払いが契約上期日を迎える日付が過ぎた状態。これは取引イベントではなく、請求書の支払い条件と現在の日付に基づいて計算されます。
その重要性この計算イベントは、滞留分析とDSOの計算にとって不可欠です。期限内請求書と期限超過請求書を区別し、焦点を絞った回収活動を可能にします。取得元これは計算イベントです。特定の請求書について、現在の日付がAR_PAYMENT_SCHEDULES_ALLテーブルのdue_dateフィールドより大きい場合に発生します。取得 `AR_PAYMENT_SCHEDULES_ALL`テーブルの`due_date`フィールドと現在の日付を比較して計算されます。イベントタイプ calculated
	異議提起済み	顧客が請求書に正式に異議を唱え、システム内に異議申し立てケースが作成された状態。これは通常、請求書支払いスケジュール上のステータスフラグを変更することで記録されます。
その重要性紛争は支払いプロセスを停止させ、解決には手作業が必要となります。紛争の頻度と解決時間を分析することで、価格設定や発送のエラーなど、根本原因の特定に役立ちます。取得元これは、AR_PAYMENT_SCHEDULES_ALLテーブルのステータスフィールドが異議申し立てステータスに設定されていることから、またはAR_DISPUTE_HISTORYの作成記録から推測できます。取得請求書の支払いスケジュールに対して紛争フラグまたはステータスがアクティブ化された時期を特定します。イベントタイプ inferred
	請求書却下	承認者が請求書を却下しました。通常、価格設定や数量などのデータエラーが原因です。このイベントにより請求書は修正のために差し戻され、手戻りループが生成されます。
その重要性却下を追跡することで、請求の正確性および内部統制に関する問題が浮き彫りになります。却下の頻度と理由を分析することで、プロセス改善とトレーニングの領域を特定できます。取得元請求書トランザクションレコードのステータス更新、またはBPMワークフロータスクにおける「却下」の結果から推論されます。取得請求書承認ステータスが「却下」に設定されたときのタイムスタンプを取得します。イベントタイプ inferred
	請求書完了済み	請求書のデータ入力が完了し、取引が検証と会計処理の準備ができた時点を表します。これは通常、請求書ステータスが「不完全」から「完了」に変更された際に記録されます。
その重要性このマイルストーンは、データ入力フェーズの終了を示します。作成から完了までの時間は、請求部門のデータ入力およびレビュープロセスの効率を示すことができます。取得元 `RA_CUSTOMER_TRX_ALL`テーブルの請求書トランザクションレコードのステータス変更から推論されます。ステータスが「完了」に更新されたときのタイムスタンプを探してください。取得 RA_CUSTOMER_TRX_ALLまたは関連するワークフローテーブル内の取引のステータス履歴を追跡。イベントタイプ inferred
	請求書調整済み	請求金額に対して、償却やクレジットなどの修正が行われました。これは、請求書の未決済残高を変更する明示的なトランザクションです。
その重要性調整はしばしば紛争、譲歩、または修正を示します。調整の頻度と価値を分析することで、受注から現金化までのプロセスにおける根本的な問題を明らかにすることができます。取得元 `AR_ADJUSTMENTS_ALL`テーブルに明示的に記録されます。調整レコードの`creation_date`がイベントを示します。取得関連する請求書について、AR_ADJUSTMENTS_ALLテーブルのcreation_dateを使用します。イベントタイプ explicit

推奨任意

抽出ガイド

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

ステップ

BI Publisherへの移動: Oracle Fusion Applicationsにログインし、ナビゲーターメニューを使用して「ツール」に進み、「レポートと分析」を選択します。「カタログを参照」ボタンをクリックして「ビジネスインテリジェンスカタログ」を開きます。
データモデルの作成: カタログで、「新規」ドロップダウンメニューをクリックし、「データモデル」を選択します。これによりデータモデルエディタが開きます。
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に設定します。これにより、レポートが実行されたときに、プロセスマイニングに適したプレーンテキストファイルが生成されます。
レポートのスケジュール設定: カタログからレポートを見つけ、「その他」をクリックし、「スケジュール」を選択します。新しいジョブを作成し、パラメーター（日付範囲、事業部門）を設定し、宛先を設定します。一般的な宛先はコンテンツサーバー（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]'のようなプレースホルダーが含まれています。これらは、Oracle Fusionの実装で請求書承認ワークフローに使用されている実際のステータスコードに置き換える必要があります。これらの値をRA_CUST_TRX_TYPES_ALLテーブルまたはシステムルックアップで特定するために、ファンクショナルアナリストにご相談ください。
パフォーマンス: 長期間またはすべての事業部門のデータを一度に抽出することは、リソースを大量に消費する可能性があります。他のユーザーのシステムパフォーマンスへの影響を避けるため、BI Publisherレポートをオフピーク時間帯に実行するようにスケジュールすることを強くお勧めします。
前提条件: BI Administratorのような、BI Publisherでデータモデルやレポートを作成する権限を付与するロールを持つユーザーアカウントが必要です。または、同様の権限を持つカスタムロールでも構いません。また、ユーザーは、必要な売掛金、顧客、および事業部門データへのアクセスを許可するデータセキュリティプロファイルを持っている必要があります。

a クエリ例 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などの他のエンドポイントに続けて呼び出しを行い、関連するイベントを収集します。
ページネーション処理: スクリプトには、API応答のnextリンクを辿り、指定されたクエリのすべてのレコードが取得されるまでAPIページネーションを自動的に処理するヘルパー関数get_paginated_dataが含まれています。
データ取得: スクリプトの主要部分は、まず指定された日付範囲内の請求書リストを取得します。その後、各請求書を反復処理して、その特定の詳細と関連イベントを収集します。
イベント生成: 各請求書について、スクリプトは異なるアクティビティ行を構築します。「Invoice Created」のような一部のアクティビティは、請求書フィールド（CreationDate）から直接派生します。一方、「Payment Applied to Invoice」のようなアクティビティは、個別のAPIを呼び出し、データを請求書番号にリンクする必要があります。
計算イベントの処理: 「Payment Due Date Reached」イベントは直接的なトランザクションではありません。スクリプトは、請求書の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認証を使用します。ユーザーアカウントに「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パラメーターは、リクエストごとに返されるレコード数を制御します。通常、100～500の値が効率的です。スクリプトはデフォルトの制限で設定されています。
事業部門フィルター: 抽出の範囲を絞るために、クエリパラメーター（q）に事業部門のフィルターを追加できます。例：BusinessUnitName = '[Your Business Unit Name]'。
パフォーマンス: 請求書ごとにデータを抽出する方法は、大量のデータには時間がかかる場合があります。スクリプトは請求書ごとに複数のAPI呼び出しを行います。100,000件を超える請求書のデータセットの場合、パフォーマンスの低下やAPIレート制限を避けるため、スクリプトをバッチで実行するか、オフピーク時間帯に実行することを検討してください。

a クエリ例 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 BI Publisherレポート

ステップ

設定

a クエリ例 sql

Oracle Fusion REST APIによるPythonスクリプト抽出

ステップ

設定

a クエリ例 python

今すぐ始めますか？

Oracle請求・支払いの最適化を今すぐ開始

受注から入金までの請求・支払いデータテンプレート

受注から入金までの請求・支払いデータテンプレート

受注から現金化までのプロセス（請求・回収）属性

受注から現金化までのプロセス（請求・回収）活動

抽出ガイド

請求および回収データ用Oracle BI Publisherレポート

ステップ

設定

a クエリ例 sql

Oracle Fusion REST APIによるPythonスクリプト抽出

ステップ

設定

a クエリ例 python

お客様のプライバシーを大切にしています

今すぐ始めますか？

Oracle請求・支払いの最適化を今すぐ開始