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

受注から入金まで：請求・請求書発行のデータテンプレート

Oracle Fusion Financials

受注から入金まで：請求・請求書発行の属性 (22) 受注から入金まで：請求・請求書発行のアクティビティ (13) 抽出ガイド (2)

受注から入金まで：請求・請求書発行のデータテンプレート

このテンプレートでは、受注から入金までの請求・請求書発行プロセスを分析するために必要なデータの抽出方法を詳しく説明します。収集すべき属性、追跡すべき主要なアクティビティ、データ抽出の進め方をまとめています。このテンプレートに沿って準備することで、プロセスマイニングと改善に適したデータセットを整えられます。

収集を推奨する属性
追跡すべき主要なアクティビティ
Oracle Fusion Financialsからの抽出方法

イベントログを初めて扱いますか。学ぶプロセスマイニングのイベントログを作成する方法.

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

受注から入金まで：請求・請求書発行の属性

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

3 必須 5 推奨 14 任意

	名前	説明
	請求書番号 InvoiceNumber	各請求書を一意に識別する番号であり、関連するすべてのアクティビティを追跡するための主要なケースIDです。
説明請求書番号は、請求プロセス分析の基盤となる項目です。ケースIDとして機能し、請求書の作成から最終的な支払いとクローズまで、すべてのイベントをグループ化します。これにより、1件の請求書について、ライフサイクル全体をエンドツーエンドで確認できます。プロセスマイニングでは、請求書番号で分析することで、プロセスバリアントを可視化し、請求書ごとのサイクルタイムを計算できます。また、特定のトランザクションに影響するボトルネックや手戻りループも特定できます。「請求書エンドツーエンドサイクルタイム」などのダッシュボードや、請求書単位の売上債権回転日数（DSO）といった基本KPIの計算にも欠かせません。重要な理由この属性は、関連するすべての請求および支払いアクティビティを1つのケースに結び付け、請求書のライフサイクルを完全かつ正確に分析できるようにします。入手先通常は、Oracle Fusion FinancialsのRA_CUSTOMER_TRX_ALLテーブルにあるTransaction Number（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フィールドから取得します。その後、この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	請求書の支払いについて合意した条件です。「Net 30」や「2% 10, Net 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
	請求書サイクルタイム InvoiceCycleTime	請求書が最初に作成されてからクローズされるまでの合計時間です。
説明 1つのケースにおける請求書のライフサイクル全体のエンドツーエンドの所要時間を測定します。通常は、最初のアクティビティである「請求書を作成」と、最後のアクティビティである「請求書をクローズ」の時間差として計算します。プロセス全体の効率を把握するための指標です。「請求書のエンドツーエンドサイクルタイム」ダッシュボードの主要な測定値となります。顧客や事業部門などのディメンション別に分析すると、処理に最も時間がかかる請求書の種類と、その根本原因を特定できます。重要な理由プロセス全体の処理速度を示す単一の重要な指標であり、開始から完了までに最も時間がかかる請求書をすばやく特定できます。入手先計算指標です。一意のInvoiceNumberごとに、EventTimestampの最大値と最小値の差分から算出します。例 45日8時間32日2時間90日12時間
	請求書日付 InvoiceDate	請求書が正式に発行された日付です。
説明請求書日付はトランザクション日付とも呼ばれ、請求書に記載された日付です。支払条件を計算する際の起点となります。売上債権回転日数（DSO）の計算に欠かせません。DSOは請求書日付から支払日までの期間を測定します。システム上の作成日とは異なり、顧客の視点で支払いサイクルが正式に始まる日付を表します。重要な理由請求書のライフサイクルにおける正式な開始日であり、売上債権回転日数（DSO）KPIを計算する基準となります。入手先 RA_CUSTOMER_TRX_ALLテーブルのTRX_DATEフィールドにあります。例 2023-04-142023-05-182023-06-25
	請求部門 BillingDepartment	請求書の作成と管理を担当する社内の部門またはチームです。
説明請求プロセスを担当した組織内のチームまたは部門を識別します。分析における組織上の背景をさらに詳しく示します。請求部門別にプロセスを分類すると、異なるチームの効率と正確性を比較できます。手戻り率、承認サイクル、DSOへの影響が大きい部門を特定し、対象を絞った研修やプロセス標準化の機会を見つけられます。重要な理由社内チーム間のパフォーマンスを比較し、ベストプラクティス、リソースの必要性、プロセス改善が必要な領域を特定できます。入手先請求書を作成したユーザーを基に、HRシステムの所属部門情報とユーザーを関連付けて取得する場合があります（例：PER_ALL_ASSIGNMENTS_F経由）。例法人請求サービス請求チーム製品販売請求

必須推奨任意

受注から入金まで：請求・請求書発行のアクティビティ

正確なプロセスディスカバリーのため、イベントログに記録する主要なプロセス手順とマイルストーンです。

6 推奨 7 任意

	アクティビティ	説明
	請求書に支払いを充当	受領した顧客からの支払いが特定の請求書と正常に照合され、充当された状態です。これにより、請求書の未決済残高が減少します。これは個別のトランザクションレコードです。
重要な理由このアクティビティにより、現金が正しく配分されたことを確認できます。正確な滞留期間レポートや財務諸表の作成に欠かせません。売掛金に対する現金の認識を完了する最終ステップです。入手先 AR_RECEIVABLE_APPLICATIONS_ALLテーブルに明示的に記録されます。apply_dateとgl_dateフィールドが、充当が行われた時点を示します。取得 AR_RECEIVABLE_APPLICATIONS_ALLテーブルのapply_dateを使用し、現金受領を請求書に関連付けます。イベントタイプ explicit
	請求書をクローズ	請求書の支払いと照合が完了し、ライフサイクルが終了した状態です。通常は、請求書の未決済残高がゼロになり、ステータスが更新された時点から推定します。
重要な理由請求書に対する最終的な解決を示し、プロセスの終了点となります。この状態に達するまでの合計時間はエンドツーエンドのサイクルタイムであり、請求プロセスの主要KPIです。入手先 AR_PAYMENT_SCHEDULES_ALLテーブルでstatusが「CLOSED」に更新され、amount_due_remainingがゼロになった時点から推定します。「gl_date_closed」フィールドがクローズ日を示します。取得対象の請求書について、AR_PAYMENT_SCHEDULES_ALLのgl_date_closedを使用します。イベントタイプ inferred
	請求書作成	システム上で請求書取引が最初に作成された時点です。多くの場合、下書きまたは未完了の状態です。売掛金モジュールでユーザーが新しい請求書レコードを初めて保存した時点で、このイベントが明示的に記録されます。
重要な理由請求プロセスの明確な開始点です。作成から完了までの時間を分析することで、フロントエンドのデータ入力遅延やシステム性能の問題を特定できます。入手先 RA_CUSTOMER_TRX_ALLテーブルにある取引レコードの作成日から、このイベントを取得します。初期ステータスは通常「Incomplete」です。取得対象の請求書番号について、RA_CUSTOMER_TRX_ALLテーブルのcreation_dateを使用します。イベントタイプ explicit
	請求書承認	請求書に必要なすべての承認が完了し、顧客へ送付できる状態です。承認ワークフローが正常に完了し、請求書のステータスが更新された時点で取得します。
重要な理由請求書を顧客へ送付できるかどうかを決める重要なマイルストーンです。ここでの遅延は支払期間の開始時点に直接影響し、売上債権回転日数（DSO）にも影響します。入手先請求書取引レコードの最終承認ステータスの更新、または関連するBPMワークフロータスクの完了タイムスタンプから推定します。取得請求書の承認ステータスが「Approved」に設定された時点のタイムスタンプを取得します。イベントタイプ 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）ワークフローテーブルから取得します。取得請求書の承認ステータスが「Pending」または同様の状態に変わった時点のタイムスタンプを特定します。イベントタイプ inferred
	支払期日到来	請求書の支払期日として契約上定められた日を過ぎた状態です。これは取引イベントではなく、請求書の支払条件と現在の日付に基づいて算出されます。
重要な理由この算出イベントは、滞留期間の分析とDSOの計算に欠かせません。期日どおりに支払われた請求書と延滞した請求書を区別し、回収活動の対象を絞り込めます。入手先これは計算イベントです。指定した請求書について、現在の日付がAR_PAYMENT_SCHEDULES_ALLテーブルのdue_dateフィールドを過ぎた時点で発生します。取得現在の日付とAR_PAYMENT_SCHEDULES_ALLのdue_dateフィールドを比較して計算します。イベントタイプ calculated
	支払督促を発行	支払期限を過ぎた請求書について、督促状またはリマインダー通知を顧客に送付した状態です。回収モジュールによって明示的に記録されるアクションです。
重要な理由リマインダーを追跡すると、回収プロセスの有効性を測定できます。どの督促方法が支払いの早期化につながるかを分析できます。入手先 Oracle Advanced Collectionsモジュールに明示的に記録されます。IEX_DUNNINGSなどの督促履歴テーブルに、送付したリマインダーの日付とレベルが記録されます。取得督促履歴テーブルから取得し、督促トランザクションを請求書に関連付けます。イベントタイプ explicit
	異議申立てを開始	顧客が請求書に対して正式に異議を申し立て、システムに異議申立て案件が作成された状態です。通常は、請求書の支払スケジュールにあるステータスフラグを変更して記録します。
重要な理由異議申立てが発生すると支払いプロセスが停止し、解決には手作業が必要になります。異議申立ての頻度と解決時間を分析すると、価格設定や出荷の誤りなど、根本原因を特定できます。入手先 AR_PAYMENT_SCHEDULES_ALLテーブルのstatusフィールドが異議申立てのステータスに設定されていること、またはAR_DISPUTE_HISTORYの作成記録から推定できます。取得請求書の支払スケジュールで、異議申立てフラグまたはステータスが有効になった時点を特定します。イベントタイプ inferred
	請求書を調整	償却やクレジットなど、請求書金額に変更が加えられた状態です。請求書の未決済残高を変更する明示的なトランザクションです。
重要な理由調整は、異議申立て、譲歩、訂正などを示すことがよくあります。調整の頻度と金額を分析すると、受注から入金までのプロセスに潜む問題を明らかにできます。入手先 AR_ADJUSTMENTS_ALLテーブルに明示的に記録されます。調整レコードのcreation_dateがイベントの日付を示します。取得対象の請求書について、AR_ADJUSTMENTS_ALLテーブルのcreation_dateを使用します。イベントタイプ explicit
	請求書却下	承認者が請求書を却下した状態です。通常は、価格や数量などのデータに誤りがある場合に発生します。このイベントによって請求書が修正のために差し戻され、手戻りのループが発生します。
重要な理由却下を追跡すると、請求の正確性や内部統制に関する問題を明らかにできます。却下の頻度と理由を分析することで、プロセス改善やトレーニングが必要な領域を特定できます。入手先請求書取引レコードのステータス更新、またはBPMワークフロータスクの「Rejected」という結果から推定します。取得請求書の承認ステータスが「Rejected」に設定された時点のタイムスタンプを取得します。イベントタイプ inferred
	請求書完了	請求書のデータ入力が完了し、取引が検証と会計処理に進める状態になった時点を示します。通常は、請求書のステータスが「Incomplete」から「Complete」に変わったことを確認して取得します。
重要な理由データ入力段階の終了を示すマイルストーンです。作成から完了までの時間は、請求部門におけるデータ入力と確認プロセスの効率を示します。入手先 RA_CUSTOMER_TRX_ALLテーブルの請求書取引レコードにおけるステータス変更から推定します。「Complete」への更新に関連付けられたタイムスタンプを確認します。取得 RA_CUSTOMER_TRX_ALLまたは関連するワークフローテーブルで、取引のステータス履歴を追跡します。イベントタイプ inferred

推奨任意

抽出ガイド

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

ステップ

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

設定

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

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などのエンドポイントを呼び出し、関連するイベントを収集します。
ページネーションを処理する：スクリプトにはget_paginated_dataヘルパー関数が含まれており、APIレスポンスのnextリンクをたどって、Queryに該当するすべてのレコードを自動的に取得します。
データを取得する：スクリプトの主要部分では、まず指定した日付範囲の請求書一覧を取得します。次に各請求書を順番に処理し、詳細情報と関連イベントを収集します。
イベントを生成する：各請求書について、スクリプトがさまざまなアクティビティ行を作成します。「請求書作成」などのアクティビティは、請求書の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が効率的です。スクリプトには既定の上限が設定されています。
事業部門フィルター：Queryパラメータ（q）に事業部門のフィルターを追加し、抽出範囲を絞れます。例：BusinessUnitName = '[Your Business Unit Name]'。
パフォーマンス：請求書を1件ずつ抽出すると、大量データでは時間がかかる場合があります。スクリプトは請求書ごとに複数の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 Fusion Financialsの業務に関する理解を深め、効率化を進められます。

改善ガイドに戻るテンプレートをダウンロード

今すぐOracleの請求・請求書発行を最適化

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

無料トライアルを開始

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

受注から入金まで：請求・請求書発行のデータテンプレート

受注から入金まで：請求・請求書発行のデータテンプレート

受注から入金まで：請求・請求書発行の属性

受注から入金まで：請求・請求書発行のアクティビティ

抽出ガイド

請求・請求書発行データ用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の請求・請求書発行を最適化

プライバシーを大切にしています