> 継続的なプロセス改善 > 調達から支払いまで：購買依頼 > Oracle Fusion Financials > データテンプレート

調達から支払いまで：購買依頼データテンプレート

Oracle Fusion Financials

調達から支払いまで：購買依頼の属性 (22) 調達から支払いまで：購買依頼のアクティビティ (12) 抽出ガイド (4)

調達から支払いまで：購買依頼データテンプレート

このテンプレートは、調達から支払いまでの購買依頼プロセスを分析するために必要なデータを収集する手順を示します。収集すべき主要な属性、追跡すべき重要なアクティビティ、Oracle Fusion Financialsから情報を抽出する方法をまとめています。これにより、プロセスマイニングに適したイベントログを効率的に準備できます。

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

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

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

調達から支払いまで：購買依頼の属性

調達から支払いまで：購買依頼プロセスを詳細に分析するため、イベントログに含めることを推奨するデータ項目です。

5 必須 7 推奨 10 任意

	名前	説明
	アクティビティ ActivityName	申請プロセスの特定の時点で発生した業務イベントの名称です。
説明アクティビティは、購買申請のライフサイクルにおける個別のステップまたはマイルストーンを表します。例として、「Requisition Created」、「Approval Step Approved」、「Purchase Order Created」などがあります。これらのアクティビティは、ソースシステムの監査ログやトランザクションテーブルに記録されたステータス変更、ユーザー操作、システムイベントから導出されます。この属性は、申請の流れを視覚的に表すプロセスマップの作成に欠かせません。アクティビティの順序と頻度を分析すると、一般的なプロセス経路、ボトルネック、手戻りのループ、標準手順からの逸脱を特定できます。重要な理由プロセスマップの基盤となり、申請ワークフローの可視化と分析を可能にします。入手先 POR_REQUISITION_HEADERS_ALLなどのテーブルにあるステータス変更記録、トランザクション履歴、またはFA_FUSION_SOAINFRA.WFTASKなどのワークフロー監査証跡から導出されます。例申請作成承認ステップの承認申請の却下発注書の作成
	イベント時刻 EventTime	アクティビティが発生した時点を示すタイムスタンプです。
説明イベント時刻は、特定のアクティビティが発生した正確な日時を記録します。このタイムスタンプは、ケース内のイベントを時系列に並べるための基本情報であり、システム内の作成日、最終更新日、特定の操作時刻から取得されます。分析では、イベント間のサイクル時間、待機時間、ケース全体の所要時間など、時間に基づくすべての指標の計算に使用します。ボトルネックの特定、SLAに対するパフォーマンスの測定、申請プロセスの時間的な動きを把握するうえで重要です。重要な理由時間関連のKPIを計算し、イベントを正しく並べ、プロセスのパフォーマンスとボトルネックを分析するために欠かせない属性です。入手先通常は、トランザクションまたはステータス変更に関連付けられた「LAST_UPDATE_DATE」または「CREATION_DATE」列から取得します。POR_REQUISITION_HEADERS_ALLやワークフロー履歴テーブルなどに含まれていることが多くあります。例 2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
	購買申請ID PurchaseRequisitionId	購買申請を一意に識別するIDであり、プロセスのケースIDとして使用されます。
説明購買申請IDは、特定の物品またはサービスの申請に関するすべてのアクティビティを結び付ける中心的な識別子です。各申請には作成時に一意のIDが割り当てられ、ライフサイクル全体を通じて変わりません。プロセスマイニングでは、この属性を使って、作成、提出、承認ステップ、最終クローズなど、関連するすべてのイベントを1つのケースにまとめます。これにより、申請の開始から終了までを分析し、プロセスマップの可視化、サイクル時間の計算、個々の申請におけるバリアントの分析が可能になります。重要な理由申請のライフサイクルを開始から終了まで追跡するための基本的な属性です。ケース単位の分析とKPI計算を可能にします。入手先通常は、Oracle Fusion FinancialsのPOR_REQUISITION_HEADERS_ALL.REQUISITION_HEADER_IDなど、申請ヘッダーテーブルの主キーです。例 100234810023491002350
	ソースシステム SourceSystem	このデータを抽出した情報システムです。
説明プロセスデータの取得元を識別する属性です。このデータモデルでは、常に「Oracle Fusion Financials」になります。複数のERPや統合システムを利用する環境では、データの系譜、トラブルシューティング、データ品質の確保に欠かせません。分析対象のプロセスイベントがどのシステムを正とするものかを示します。重要な理由データの取得元に関する重要な背景情報を提供します。データガバナンスや複数システムからのデータ統合に欠かせません。入手先データの抽出・変換処理中に追加される固定値で、データセットの取得元を示します。例 Oracle Fusion Financials
	最終データ更新日時 LastDataUpdate	ソースシステムからデータが最後に更新された時点のタイムスタンプです。
説明 Oracle Fusion Financialsからデータが最後に抽出された日時を示す属性です。個々のイベントではなく、データセット全体に適用されます。分析担当者はこの情報からデータの鮮度を確認し、最新のトランザクションが含まれた日時を把握できます。ダッシュボードのレポート作成や、最新の情報に基づく分析を確実にするための重要なメタデータです。重要な理由データの新しさを示し、分析が最新の情報に基づく適切なものになるよう支えます。入手先通常はETLツールまたはデータパイプラインによって、データ抽出時に生成・保存されます。例 2023-10-27T02:00:00Z
	却下理由 RejectionReason	申請または承認ステップを却下した際に、承認者が入力する理由です。
説明申請が却下されると、承認者は通常、定義済みのリストから選択するか、自由記述で理由を入力します。この属性は、その根拠を記録します。プロセス失敗の根本原因分析に欠かせない属性です。「修正・却下傾向」ダッシュボードを直接支え、却下に至った理由を明らかにします。却下理由を分析すると、コードの誤り、予算超過、ポリシー違反などの共通する問題を特定でき、トレーニングやシステム制御によって対処できます。重要な理由申請が却下された理由を直接把握でき、対象を絞った改善によって手戻りを減らし、ストレートスルー処理率を高められます。入手先ワークフローのコメント、またはワークフロー監査証跡にある却下理由コードのフィールドから取得します。FA_FUSION_SOAINFRA.WFTASK関連のテーブルや、コメントを保存するテーブルに含まれている場合があります。例誤ったGL勘定原価センターの予算超過優先仕入先以外の選択重複申請
	必要日 RequiredByDate	申請者が物品またはサービスを必要とする期限です。
説明申請者が、依頼した品目を受け取りたい期限として指定する日付です。購買プロセスにおける社内サービスレベル合意（SLA）の目標になります。「必要日パフォーマンス」ダッシュボードと「必要日遵守率」KPIの基盤となる属性です。この日付と実際の発注書作成日または入荷日を比較すると、購買プロセスが社内顧客の要望にどの程度応えられているかを分析し、構造的な遅延を特定できます。重要な理由社内の期限に対するプロセスパフォーマンスを測定し、購買プロセスが業務上のニーズに適時対応できているかを把握するうえで重要です。入手先通常は申請明細レベルに保存され、POR_REQUISITION_LINES_ALLなどのテーブルの「NEED_BY_DATE」フィールドに記録されます。例 2023-11-012023-12-152024-01-31
	業務単位 BusinessUnit	組織内で、その申請が属する特定の業務単位です。
説明業務単位は、申請が行われる会社内の独立した法的または機能上の組織を表します。部門より上位の組織グループです。業務単位別にデータを分析すると、組織の異なる領域間でパフォーマンスを比較できます。プロセスの非効率が一部に限られるのか、広範囲に及ぶのかを経営層が把握し、改善に注力すべき領域を判断するのに役立ちます。ほぼすべてのダッシュボードとKPIで使われる主要な分析軸です。重要な理由組織全体を俯瞰する背景情報を提供し、企業内の異なる領域間でのパフォーマンス比較と戦略的な分析を可能にします。入手先 Oracle Fusionの基本的な組織項目です。通常は、POR_REQUISITION_HEADERS_ALLなどのテーブルにある申請ヘッダーで利用できます。例北米BU欧州BU本社
	申請ステータス RequisitionStatus	購買申請の現在または最終的なステータスです。
説明特定の時点における申請全体の状態、または最終結果を示す属性です。「Approved」、「Rejected」、「In Process」、「Closed」などが該当します。イベントログ内の多くのアクティビティは、この属性を元に導出されます。「申請ステータス概要」ダッシュボードの基盤となり、現在の作業量と滞留案件を把握できます。また、特定のステータスで終了したケースを抽出し、申請却下率など、結果に基づくKPIの計算にも使用します。重要な理由申請の現在の状態を把握し、KPI計算における最終結果の判定に使用します。入手先申請ヘッダーテーブルにあり、通常はPOR_REQUISITION_HEADERS_ALLの「DOCUMENT_STATUS」または「APPROVAL_STATUS」などのフィールドに保存されています。例承認済み処理中却下済み取り下げ済み
	申請総額 RequisitionTotalAmount	購買申請の金額合計です。
説明 1件の購買申請に含まれるすべての明細金額の合計を表す属性です。各申請の金銭的な重要度を把握するための重要なデータ項目です。プロセスマイニングでは、総額をさまざまな分析に利用できます。高額な申請を抽出すると、承認経路が異なる申請や、より厳しい審査が必要な申請を分析できます。ダッシュボードでは、この属性を使って、サイクル時間や却下率などのプロセス指標と申請金額の関係を分析できます。重要な理由金額に基づく分析を可能にし、プロセス改善の優先順位付けや、申請金額がプロセスの動きに与える影響の把握に役立つ財務的な背景情報を提供します。入手先申請ヘッダーにあり、POR_REQUISITION_HEADERS_ALLのREQUISITION_TOTALなどのフィールドに保存されていることが多くあります。POR_REQUISITION_LINES_ALLから明細金額を合計して算出する場合もあります。例 550.0012500.7599.99
	申請者名 RequesterName	購買申請を作成して提出した従業員の名前です。
説明物品またはサービスの申請を開始した個人を識別する属性です。通常は、申請が最初に作成されたプロセスの開始時点で取得されます。申請者別にプロセスのパフォーマンスを分析することは、「申請者パフォーマンス指標」ダッシュボードに欠かせません。申請に伴う修正、却下、長いサイクル時間の割合を明らかにし、追加のトレーニングが必要なユーザーやグループを特定できます。プロセスを人の側面から把握するための属性です。重要な理由申請者別のパフォーマンス分析を可能にし、トレーニングの必要性や、効率的なユーザー・部門の特定に役立ちます。入手先申請ヘッダーデータから取得します。多くの場合、申請者IDを従業員またはユーザーマスターデータのテーブルと結合します。POR_REQUISITION_HEADERS_ALLの「PREPARER_ID」に関連するフィールドを確認し、PER_ALL_PEOPLE_Fと結合します。例 John SmithJane DoeEmily Jones
	部門 DepartmentName	申請者が所属する業務部門です。
説明申請を作成した人の組織単位を示す属性です。「Finance」、「IT」、「Marketing」などが該当します。通常は、HRシステムの申請者ユーザープロファイルから導出されます。部門別の分析は、プロセスデータを分類する一般的で有効な方法です。却下率が高い、サイクル時間が長いなど、部門ごとの特徴を特定でき、対象を絞ったプロセス改善の取り組みに役立ちます。「申請者パフォーマンス指標」ダッシュボードの主要な分析軸です。重要な理由業務単位別にプロセスを分析でき、部門ごとのパターン、パフォーマンス、コンプライアンス上の問題を明らかにします。入手先通常は申請者のプロファイルから導出します。多くの場合、申請テーブルを、部門情報を持つHRまたはユーザーディレクトリのテーブルと結合します。例情報システム財務オペレーションマーケティング
	サプライヤー名 SupplierName	物品またはサービスの候補、または事前に選択されたサプライヤーの名前です。
説明物品またはサービスの購入先となるベンダーを識別する属性です。申請者がサプライヤーを指定する場合もあれば、カタログや既存契約に基づいてシステムが決定する場合もあります。サプライヤー別に分析すると、重要な購買パターンを明らかにできます。たとえば、特定のサプライヤー向けの申請で承認に時間がかかる、または却下率が高いかどうかを確認できます。この情報は、サプライヤーとの関係管理や購買戦略に役立ちます。重要な理由サプライヤー別にプロセスパフォーマンスを分析でき、調達戦略やサプライヤーとの関係管理に役立ちます。入手先申請明細テーブルPOR_REQUISITION_LINES_ALLにあり、通常はVENDOR_IDを介してPOZ_SUPPLIERSなどのサプライヤーマスターテーブルと関連付けられます。例 Office Supplies Inc.Global Tech SolutionsCreative Marketing Agency
	ストレートスルーかどうか IsStraightThrough	修正や却下を伴わずに購買依頼が承認されたかどうかを示すフラグです。
説明この計算フラグは、送信から承認までのプロセスを、修正や却下などの手戻りループなしで完了した購買依頼を特定します。1つのケースでプロセスが完全に実行されたことを示します。この属性は、「ストレートスルー購買依頼率」KPIの基礎となります。ストレートスルーで完了した購買依頼の特徴（よく見られる部門、依頼者、種類など）を分析すると、ベストプラクティスや自動化の機会を見つけられます。一方、ストレートスルーではない購買依頼を分析すれば、非効率の主な要因を特定できます。重要な理由プロセス効率を直接測定し、「ストレートスルー購買依頼率」KPIの基礎として、手戻りの要因を特定するのに役立ちます。入手先この属性はデータ変換時に算出されます。「購買依頼の修正」または「承認ステップの却下」アクティビティが存在しないケースをtrueとして記録します。例 truefalse
	ユーザー名 UserName	承認者や編集者など、特定のアクティビティを実行したユーザーの名前です。
説明申請者名が開始者を示すのに対し、ユーザー名は承認や却下など、プロセス内の特定のイベントを実行した個人を示します。複数の承認ステップで異なる個人が関与する場合に特に重要です。この属性は、承認のボトルネックを分析し、特定の承認者やチームのパフォーマンスを測定するうえで欠かせません。承認経路に関与する各ユーザーの処理時間を分析できるため、「承認ワークフローのボトルネック」ダッシュボードを直接支えます。重要な理由各イベントの実行者を特定し、引き継ぎ時間、承認者のパフォーマンス、リソース配分を分析するうえで重要な情報を提供します。入手先各タスクの完了に関連するユーザーを記録するFA_FUSION_SOAINFRA.WFTASKなどのワークフロー履歴または監査証跡テーブルから取得します。例 David LeeSusan ChenMichael Brown
	修正済みかどうか IsAmendedFlag	申請が1回以上修正されている場合にtrueとなるブール型フラグです。
説明この計算属性は、購買依頼が初回送信後に変更されたかどうかを示します。ケース履歴に「購買依頼の修正」アクティビティが存在するかどうかを確認して算出します。このフラグにより、分析とKPIの計算が簡単になります。「購買依頼修正率」KPIの計算や、ストレートスルーではないケースの特定に直接使用します。修正済みの購買依頼と未修正の購買依頼を簡単にフィルタリングして比較できるため、プロセス指標を分析しやすくなります。重要な理由修正率の計算を簡単にし、修正済みと未修正の購買依頼を容易に比較できます。入手先この属性はソースシステムには存在しませんが、イベントログ内に修正関連のアクティビティが存在するかどうかに基づき、データ変換時に算出されます。例 truefalse
	品目説明 ItemDescription	申請明細で依頼された製品またはサービスの説明です。
説明調達する品目のテキスト形式の説明を含む属性です。依頼した物品やサービスの具体的な内容を示します。構造化されていないことも多い一方で、品目説明は分析に役立つ背景情報を提供します。申請タイプでは捉えきれない特定の購入を抽出するためのフィルターとして利用できます。たとえば、「Software License」を含むすべての申請を検索し、そのプロセスフローやサイクル時間を分析できます。重要な理由購入対象の詳細な背景情報を提供し、特定の物品やサービスをより細かく絞り込んで分析できます。入手先申請明細テーブルPOR_REQUISITION_LINES_ALLの「ITEM_DESCRIPTION」などのフィールドに保存されています。例 15インチノートパソコン、16GB RAMコンサルティングサービス：第4四半期プロジェクトソフトウェア年間保守更新
	承認ワークフロー経路 ApprovalWorkflowPath	申請に必要な承認者または承認グループの定義済みの順序です。
説明会社のポリシーに基づき、申請金額、タイプ、部門などを考慮して定められた、申請ごとの標準的な承認プロセスを定義する属性です。想定されるプロセスモデルを表します。承認ワークフロー経路は、コンプライアンス分析と適合性分析の基盤です。実際に行われた承認ステップと規定の経路を直接比較できるため、「コンプライアンス・逸脱分析」ダッシュボードと「申請適合性指数」KPIを支えます。逸脱は、ポリシー違反やプロセスの非効率を示している可能性があります。重要な理由実際のプロセスフローと必要な承認階層を比較して適合性を確認し、要件に適合しない申請を明らかにします。入手先 Oracle Fusion BPM WorklistまたはApproval Management Engine（AMX）で設定されます。申請ごとに定義された経路を抽出する処理は複雑になる場合があり、設定テーブルへのクエリが必要になることもあります。例マネージャー > ディレクター > 財務担当VP原価センター責任者 > ITセキュリティマネージャー > 部門長
	申請タイプ RequisitionType	物品やサービスの申請など、申請の分類です。
説明申請内容に基づいて申請を分類する属性です。一般的なタイプには、物品、サービス、資本支出があります。タイプによって、必要な承認ワークフローや購買戦略が変わる場合があります。分析では、申請タイプを絞り込みや比較のための有効な分析軸として利用できます。たとえば、サービス申請の承認サイクル時間が物品申請より長いかどうかを分析できます。申請タイプごとに異なるプロセスの動きやボトルネックがあるかを把握するのに役立ちます。重要な理由物品とサービスなど、購入タイプごとのプロセスの違いを把握するために、分析を分類できます。入手先通常は、申請作成時に選択された明細タイプまたはカテゴリから判定します。申請明細テーブルPOR_REQUISITION_LINES_ALLに保存されている場合があります。例商品サービス資本的支出
	発注書番号 PurchaseOrderNumber	承認済みの申請から作成された発注書の識別子です。
説明購買申請と、その結果作成された発注書を結び付ける属性です。申請が完全に承認されると、通常は1件以上の発注書に変換され、サプライヤーに送付されます。分析では、申請後のプロセスを追跡するために欠かせません。「申請から発注書までのリードタイム」KPIの計算や、「申請から発注書までのサイクル時間」ダッシュボードを支えます。また、申請プロセスのデータを、その後の発注書・請求プロセスと組み合わせ、受注から入金までのプロセスをエンドツーエンドで分析できます。重要な理由申請とその後の発注書を結び付け、申請から発注書までのサイクル時間の測定と、プロセス全体の分析を可能にします。入手先 POの作成後に保存されます。通常は、申請明細に関連付けられたPOの配分テーブルを確認して特定します。たとえば、PO_DISTRIBUTIONS_ALLは申請明細への参照を持っています。例 PO-2023-5832PO-2023-5833PO-2023-5834
	自動化されているかどうか IsAutomated	アクティビティがシステムによって自動的に実行されたかどうかを示すフラグです。
説明この属性は、プロセス内のイベントが人ではなく、システムユーザーまたは自動化エージェントによって実行されたかどうかを識別します。たとえば、システムによるステータス変更や、少額案件に対する自動承認ステップなどが該当します。この属性を分析すると、プロセスの自動化レベルを定量化できます。自動化されたステップと手動ステップの速度や効率を比較したり、さらなる自動化の機会を特定したりする際に利用できます。重要な理由プロセスの自動化レベルの測定や、手動タスクを自動化する機会の特定に役立ちます。入手先アクティビティに関連付けられたユーザーがシステムアカウントまたはサービスアカウントかどうかを確認して算出します。既知のシステムユーザーIDの一覧が必要です。例 truefalse
	通貨 CurrencyCode	申請金額の通貨コードです。USDやEURなどが該当します。
説明申請総額がどの通貨で表示されているかを示す属性です。グローバルな組織では、申請が複数の通貨で作成される場合があります。財務データを正しく解釈・集計するために欠かせません。金額を含む分析では、単一通貨に絞り込むか、すべての金額を共通通貨に換算するなど、通貨コードを使って金額を正確に比較する必要があります。重要な理由複数の通貨を扱う多国籍組織において、正確な財務分析とレポート作成を可能にします。入手先通常は金額フィールドとともに申請ヘッダーテーブルにあります。たとえば、POR_REQUISITION_HEADERS_ALLに保存されています。例 USDEURGBPJPY

必須推奨任意

調達から支払いまで：購買依頼のアクティビティ

調達から支払いまで：購買依頼プロセスを正確に発見するため、イベントログに記録する主要なプロセス手順とマイルストーンです。

6 推奨 6 任意

	アクティビティ	説明
	申請のクローズ	申請のライフサイクルが最終的に終了したことを示します。すべての明細が処理済み（発注書への変換など）またはキャンセル済みになった状態です。最終的なステータス更新から推定します。
重要な理由プロセスが正常に終了したことを示す主要な終端イベントです。申請の処理が完了し、追加の対応が不要であることを確認できます。入手先 POR_REQUISITION_HEADERS_ALLの申請ヘッダーステータスが「CLOSED」に変わったことから推定します。取得申請のドキュメントステータスが「Closed」に変わった時点のタイムスタンプを特定します。イベントタイプ inferred
	申請の却下	申請が最終的に却下され、この申請のプロセスが終了したことを表します。申請全体のステータスが「Rejected」に更新されたことから推定します。
重要な理由不成立となった申請の終点となるアクティビティです。申請却下率KPIと失敗理由を把握するには、これらのケースを分析する必要があります。入手先 POR_REQUISITION_HEADERS_ALLテーブルのドキュメントステータスが「REJECTED」に変わったことから推定します。取得ドキュメントステータスが初めて「Rejected」に設定された時点のタイムスタンプを特定します。イベントタイプ inferred
	申請の承認完了	ワークフローのすべてのステップを正常に通過した後、購買申請が最終承認されたことを示します。申請全体のステータスが「Approved」に変わったことから推定します。
重要な理由申請が購買処理に進める状態になったことを示す重要なマイルストーンです。申請承認サイクル全体の時間を測定する際の終点になります。入手先 POR_REQUISITION_HEADERS_ALLテーブルのドキュメントステータスが「APPROVED」に変わったことから推定します。このステータス変更日をイベント時刻とします。取得ドキュメントステータスが初めて「Approved」に設定された時点のタイムスタンプを特定します。イベントタイプ inferred
	申請作成	ユーザーが新しい購買依頼を初めて保存した時点で、調達プロセスの開始を示します。通常は、システム内で対応するタイムスタンプを伴う明示的なレコード作成として記録されます。
重要な理由購買依頼プロセスの主な開始イベントです。作成から提出までの時間を分析すると、依頼を正式な形に整える際の遅延を明らかにできます。入手先このイベントはPOR_REQUISITION_HEADERS_ALLテーブルに記録され、新しいRequisition IDが生成された際のcreation_date列から取得されます。取得購買依頼ヘッダーレコードの作成タイムスタンプを使用します。イベントタイプ explicit
	申請提出	完成した購買依頼を承認ワークフローへ提出するユーザー操作を示します。購買依頼のステータスが「Incomplete」または「Draft」から、承認待ちを示すステータスへ変わった時点で記録されます。
重要な理由このアクティビティは承認サイクルを開始します。申請承認サイクル時間と全体のリードタイムを測定するうえで重要なマイルストーンです。入手先 POR_REQUISITION_HEADERS_ALLテーブルのステータス変更（例：ステータスが「PENDING APPROVAL」に変わること）から推定します。申請日は明示的に保存されている場合も多くあります。取得ドキュメントのステータスフィールドが初めて「Pending Approval」に変わった時点のタイムスタンプを特定します。イベントタイプ inferred
	発注書の作成	承認済みの申請明細を使って発注書が作成されたときに発生します。申請プロセスと、その後の購買プロセスをつなぎます。
重要な理由申請から発注書までのリードタイムを測定するうえで重要なマイルストーンです。ここでの遅延は、承認から購買への引き継ぎにボトルネックがあることを示します。入手先明示的なイベントです。申請と発注書の関連付けは、元の申請明細IDへの参照を持つPO_LINE_LOCATIONS_ALLなどのテーブルに保存されます。取得指定された申請IDを参照する発注書の作成日を特定します。イベントタイプ explicit
	承認ステップの却下	承認者が申請を却下します。通常は、修正のため作成者に差し戻すか、申請を終了します。この操作はワークフロー履歴に明示的に記録されます。
重要な理由このアクティビティは、手戻りや遅延の主な要因です。却下を分析すると、コンプライアンス上の問題、予算上の問題、根拠の不明確さを特定できます。入手先申請の承認操作履歴から取得します。ワークフローシステムは「REJECT」操作をタイムスタンプ付きで記録します。取得ワークフロー操作履歴ログに記録された「REJECT」操作のタイムスタンプを使用します。イベントタイプ explicit
	承認ステップの差し戻し	承認者が、正式に却下することなく、追加情報の提出や軽微な修正を求めて申請を作成者に戻します。通常はワークフローシステム上の明示的な操作です。
重要な理由これは確認や説明の追加が必要であることを示し、サイクル時間を延ばす手戻りのループを生みます。差し戻しと却下を区別すると、プロセス上の摩擦をより詳しく把握できます。入手先申請の承認操作履歴から取得します。ワークフローシステムは「RETURN」または同様の操作をタイムスタンプ付きで記録します。取得ワークフロー履歴に記録された「RETURN」または「Request for Information」操作のタイムスタンプを使用します。イベントタイプ explicit
	承認ステップの承認	承認者がワークフロー上の担当ステップで申請を承認する操作を表します。このイベントは承認履歴に明示的に記録されます。
重要な理由個々の承認ステップを追跡すると、実際の承認経路を可視化し、階層の各段階における処理時間を測定できます。入手先申請の承認操作履歴から取得します。通常は、承認階層を管理するワークフロー（WF）またはHuman Capital Management（HCM）のテーブルに保存されています。取得ワークフロー操作履歴ログに記録された「APPROVE」操作のタイムスタンプを使用します。イベントタイプ explicit
	承認ステップの開始	申請がワークフロー内の特定の承認者または承認グループに割り当てられた時点を示します。ワークフローエンジンのトランザクションログから取得します。
重要な理由このアクティビティは、各承認ステップの待機時間を計算するうえで欠かせません。特定の承認者や承認レベルが原因となっているボトルネックの特定に役立ちます。入手先ユーザーに割り当てられたタスクを記録するOracle Fusionのワークフローテーブルから取得します。承認タスクの割り当て時刻を使用します。取得対象の申請について、ワークフロー履歴に記録されたタスクの作成時刻を使用します。イベントタイプ explicit
	申請の修正	このイベントは、ユーザーが初回提出後に申請を変更したことを示します。多くの場合、承認プロセスの再開が必要になります。主要なデータ項目の変更、または申請の新しいバージョンの作成を検出して推定します。
重要な理由修正が頻繁に発生する場合、データ品質や要件の変化に問題があり、手戻りやプロセス遅延につながっている可能性があります。これは「申請修正率」KPIを直接支えます。入手先申請のバージョン番号を追跡するか、提出後にステータスが「Incomplete」に戻ったことを特定して推定します。変更ログや監査証跡テーブルに修正内容が記録されている場合もあります。取得提出後、同じ申請IDに対して新しいバージョンが作成された時点のタイムスタンプを特定します。イベントタイプ inferred
	申請の取り下げ	申請者が、提出済みの申請を完全に承認される前にキャンセルまたは取り下げたときに発生します。通常は、ユーザー操作による明示的なステータス変更です。
重要な理由取り下げを追跡すると、業務要件の変更や、提出後の誤りの修正など、早期終了の理由を特定できます。入手先 POR_REQUISITION_HEADERS_ALLテーブルでステータスが「WITHDRAWN」に変更されたことから推定します。この操作は申請の操作履歴に記録されます。取得申請のステータスが「Withdrawn」に更新された時点のタイムスタンプを検出します。イベントタイプ inferred

推奨任意

抽出ガイド

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

ステップ

**Reports and Analyticsに移動：**Oracle Fusion Financialsにログインします。NavigatorメニューからToolsに移動し、Reports and Analyticsを選択します。ここがすべてのレポート作業の中心となります。
**新しい分析を作成：**Reports and Analyticsの作業領域で「Create」ボタンをクリックし、ドロップダウンメニューから「Analysis」を選択します。新しいタブでOracle Transactional Business Intelligence（OTBI）の分析エディターが起動します。
**Subject Areaを選択：**Subject Areaの選択を求められます。検索ボックスに「Procurement - Requisitions Real Time」と入力し、一覧から選択します。このSubject Areaには、購買依頼のライフサイクルイベントに必要なすべてのデータ項目が含まれています。
**購買依頼イベントの分析を作成：**この手順では、個別のイベントを取得するために複数のクエリを結合する必要があります。OTBIのUIにはイベントタイプごとの直接的なUNION ALL機能がないため、関連するすべての日付フィールドとステータスフィールドを取得する単一のレポートを作成します。「Criteria」タブで、左側の「Subject Areas」ペインにあるクエリセクション記載の列を、「Selected Columns」領域にドラッグアンドドロップします。作成日、提出日、承認日、購買注文作成日などの列が含まれます。
**購買依頼アクション履歴を追加：**詳細な承認ステップ（Approved、Rejected、Returned、Withdrawn）を取得するには、Subject Area内の「Requisition Action History」フォルダーにあるフィールドを含めます。「Action Date」、「Action」、「Performer」を選択列にドラッグします。
フィルターを設定：「Prompts」タブに切り替えて、分析のフィルターを作成します。データ量を管理するため、日付範囲でフィルタリングすることが重要です。「Requisition Header」.「Requisition Creation Date」にフィルターを作成し、たとえば直近6か月などの範囲を設定します。「Business Unit」や「Requester Name」のプロンプトを追加して、データを絞り込むこともできます。
レポートを実行して確認：「Results」タブに移動して分析を実行し、データをプレビューします。出力は、購買依頼明細行または承認アクションごとに1行を持ち、複数の日付列とステータス列を含む横持ちのテーブルになります。
**生のデータをエクスポート：**プレビューを確認したら、通常は結果ページの下部にある「Export」リンクをクリックします。形式として「Data」＞「CSV File」を選択します。分析から生のデータがダウンロードされます。
**データをイベントログ形式に変換：**エクスポートしたCSVは横持ち形式です。外部ツール（Pythonスクリプト、ExcelのPower Query、その他のデータ準備ツールなど）を使って変換する必要があります。日付列を1つのEventTime列にアンピボットし、各イベントタイプに対応するActivityName列を作成します（例：「Requisition Created」、「Requisition Submitted」）。
**最終確認とアップロード準備：**変換後のファイルに、PurchaseRequisitionId、ActivityName、EventTime、SourceSystem、LastDataUpdateの必須列があることを確認します。最終イベントログをCSVファイルとして保存し、ProcessMindにアップロードします。

設定

サブジェクト領域：主に使用するサブジェクト領域は「Procurement - Requisitions Real Time」です。購買依頼のヘッダー、明細、配賦、承認履歴に関する主要な情報が含まれています。
期間：データ量を制限してパフォーマンスを改善するため、必ず日付フィルターを適用してください。まずは「Requisition Header」．「Requisition Creation Date」を直近3～6か月に絞り込む方法が適しています。
主要フィルター：「Requisition Header」．「Business Unit」および「Requisition Header」．「Requisition Status」のフィルター追加を検討してください。関連する組織単位に抽出範囲を限定し、分析に不要な「Canceled」などのステータスを除外できます。
列の選択：分析に追加する列は必要なものに限定してください。特に複数のフォルダー（ディメンション）から多数の列を含めると、パフォーマンスが低下する場合があります。イベントログに必要なフィールドだけに絞り込んでください。
権限：抽出を実行するユーザーには、Reports and Analytics作業領域と「Procurement - Requisitions Real Time」サブジェクト領域にアクセスするための必要な権限を持つロールが必要です。通常、「BI Author」や「Procurement Analyst」などのロールにこれらの権限が付与されています。

a サンプルクエリ sql

/*
OTBI analyses are built visually, not with SQL. This conceptual query illustrates the logic required to extract the data for all specified activities. The user would build an analysis containing these fields and then transform the output into an event log.
*/

-- 1. Requisition Created
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Created' AS ActivityName,
  "Requisition Header"."Requisition Creation Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Creation Date" IS NOT NULL

UNION ALL

-- 2. Requisition Submitted
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Submitted' AS ActivityName,
  "Requisition Header"."Submitted Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Submitted Date" IS NOT NULL

UNION ALL

-- 3, 5, 6, 7, 8. Approval History Events (Withdrawn, Started, Approved, Rejected, Returned)
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  CASE "Requisition Action History"."Action"
    WHEN 'WITHDRAW' THEN 'Requisition Withdrawn'
    WHEN 'SUBMIT' THEN 'Approval Step Started' -- Assumes submit action assigns to first approver
    WHEN 'APPROVE' THEN 'Approval Step Approved'
    WHEN 'REJECT' THEN 'Approval Step Rejected'
    WHEN 'RETURN' THEN 'Approval Step Returned'
  END AS ActivityName,
  "Requisition Action History"."Action Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  CASE WHEN "Requisition Action History"."Action" = 'REJECT' THEN "Requisition Action History"."Action Note" ELSE NULL END AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Action History"."Action" IN ('WITHDRAW', 'SUBMIT', 'APPROVE', 'REJECT', 'RETURN')

UNION ALL

-- 4. Requisition Amended
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Amended' AS ActivityName,
  "Requisition Header"."Last Update Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Version" > 1 AND "Requisition Header"."Last Update Date" > "Requisition Header"."Submitted Date"

UNION ALL

-- 9. Requisition Approved (Final)
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Approved' AS ActivityName,
  "Requisition Header"."Approved Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Status" = 'APPROVED'
AND "Requisition Header"."Approved Date" IS NOT NULL

UNION ALL

-- 10. Requisition Rejected (Final)
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Rejected' AS ActivityName,
  "Requisition Action History"."Action Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  "Requisition Action History"."Action Note" AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Status" = 'REJECTED'
AND "Requisition Action History"."Action" = 'REJECT'
AND "Requisition Action History"."Sequence Number" = (SELECT MAX(T2."Sequence Number") FROM "Procurement - Requisitions Real Time" T2 WHERE T2."Requisition Header"."Requisition Number" = "Requisition Header"."Requisition Number")

UNION ALL

-- 11. Purchase Order Created
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Purchase Order Created' AS ActivityName,
  "Purchase Order Schedule"."PO Creation Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Purchase Order Schedule"."PO Creation Date" IS NOT NULL

UNION ALL

-- 12. Requisition Closed
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Closed' AS ActivityName,
  "Requisition Line"."Line Close Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Line"."Line Close Date" IS NOT NULL AND "Requisition Line"."Line Status" = 'CLOSED'

ステップ

BI Authorまたは同等の権限を持つユーザーでOracle Fusion Financialsにログインします。
Navigatorアイコンをクリックし、Tools＞Reports and Analyticsを選択して、Reports and Analyticsの作業領域に移動します。
「Browse Catalog」ボタンをクリックして、Business Intelligence Publisherカタログを開きます。
BI Publisherのインターフェースで「New」をクリックし、ドロップダウンリストから「Data Model」を選択します。
Data Modelのプロパティで、名前と説明を入力できます。「+」アイコンをクリックして新しいData Setを追加し、「SQL Query」を選択します。
新しいData Setダイアログで名前（例：Requisition_Event_Log）を入力し、Financialsデータに対応するData Source（例：ApplicationDB_FSCM）を選択して、SQLのTypeを「Standard SQL」に設定します。
このドキュメントの「query」セクションにある完全なSQLスクリプトをコピーし、SQL Queryのテキスト領域に貼り付けます。
クエリにはパラメーター:p_start_dateと:p_end_dateが含まれています。これらはBI Publisherによって自動的に認識されます。必要に応じてデフォルト値を設定できます。
Data Modelを適切なカタログフォルダー（例：Shared Folders/Custom）に保存します。
データをエクスポートするには、カタログに戻り、「New」をクリックして「Report」を選択します。この新しいレポートを、作成したData Modelにリンクします。
レポートを実行し、開始日と終了日のパラメーターを入力します。レポートにデータが表示されたら、「Export」機能を使って結果をCSVファイルとしてダウンロードします。
最終CSVファイルがUTF-8エンコーディングで保存され、プロセスマイニングツールへの取り込みに必要なヘッダーを含んでいることを確認します。

設定

データソース：通常「ApplicationDB_FSCM」などの名前で設定されるBI Publisher Data Sourceには、クエリ内のすべてのテーブルへの読み取りアクセス権を持つユーザーを設定する必要があります。対象には、Procurement（POR、PO）、Human Capital Management（PER、HR）、Financials（FUN）のテーブルが含まれます。
期間フィルタリング：クエリには、購買依頼の作成日に適用する必須の日付パラメーター（:p_start_dateおよび:p_end_date）が設定されています。初回抽出や大規模システムでは、タイムアウトを防ぐため、3～6か月ずつなど、管理しやすいバッチに分けて抽出することが重要です。
事業単位のフィルタリング：事業単位名のフィルターは、クエリのWHERE句内にコメントアウトされたセクションとして含まれています。分析対象の事業単位にデータを限定するとパフォーマンスを大幅に改善できるため、このフィルターのコメントを解除して設定することを強く推奨します。
前提条件：レポートを作成・実行するユーザーには、「BI Administrator Role」や「BI Author Role」など、BI Publisherの権限を持つロールが必要です。さらに、購買データにアクセスするための必要なデータセキュリティ付与も必要です。

a サンプルクエリ sql

WITH BaseRequisitions AS (
    SELECT
        PRH.REQUISITION_HEADER_ID,
        PRH.REQUISITION_NUMBER,
        PRH.CREATION_DATE,
        PRH.LAST_UPDATE_DATE AS HEADER_LAST_UPDATE_DATE,
        PRH.DOCUMENT_STATUS,
        PRH.PREPARER_ID,
        PPNF_REQ.DISPLAY_NAME AS RequesterName,
        HOU.NAME AS DepartmentName,
        BU.BU_NAME AS BusinessUnit,
        SUM(PRL.AMOUNT) OVER (PARTITION BY PRH.REQUISITION_HEADER_ID) AS RequisitionTotalAmount,
        MIN(PRL.NEED_BY_DATE) OVER (PARTITION BY PRH.REQUISITION_HEADER_ID) AS RequiredByDate
    FROM
        POR_REQUISITION_HEADERS_ALL PRH
    JOIN
        POR_REQUISITION_LINES_ALL PRL ON PRH.REQUISITION_HEADER_ID = PRL.REQUISITION_HEADER_ID
    JOIN
        PER_USERS PU_REQ ON PRH.PREPARER_ID = PU_REQ.USER_ID
    LEFT JOIN
        PER_PERSON_NAMES_F PPNF_REQ ON PU_REQ.PERSON_ID = PPNF_REQ.PERSON_ID AND PPNF_REQ.NAME_TYPE = 'GLOBAL' AND SYSDATE BETWEEN PPNF_REQ.EFFECTIVE_START_DATE AND PPNF_REQ.EFFECTIVE_END_DATE
    LEFT JOIN
        PER_ALL_ASSIGNMENTS_F PAAF ON PU_REQ.PERSON_ID = PAAF.PERSON_ID AND PAAF.ASSIGNMENT_TYPE = 'E' AND PAAF.PRIMARY_FLAG = 'Y' AND SYSDATE BETWEEN PAAF.EFFECTIVE_START_DATE AND PAAF.EFFECTIVE_END_DATE
    LEFT JOIN
        HR_ORGANIZATION_UNITS_F_VL HOU ON PAAF.ORGANIZATION_ID = HOU.ORGANIZATION_ID AND SYSDATE BETWEEN HOU.EFFECTIVE_START_DATE AND HOU.EFFECTIVE_END_DATE
    JOIN
        FUN_ALL_BUSINESS_UNITS_V BU ON PRH.REQ_BU_ID = BU.BU_ID
    WHERE PRH.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
    -- AND BU.BU_NAME IN ('[Your Business Unit Name]') -- Recommended: Uncomment and specify your Business Unit(s)
)
-- 1. Requisition Created
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Created' AS "ActivityName",
    BR.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR

UNION ALL

-- 2. Requisition Submitted, 4. Requisition Amended
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    CASE 
        WHEN PAH.OBJECT_REVISION_NUM > 1 THEN 'Requisition Amended'
        ELSE 'Requisition Submitted'
    END AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'SUBMIT'

UNION ALL

-- 3. Requisition Withdrawn
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Withdrawn' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'WITHDRAW'

UNION ALL

-- 5. Approval Step Started
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Started' AS "ActivityName",
    PAH.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE IN ('APPROVE', 'REJECT', 'SUBMIT', 'RETURN')

UNION ALL

-- 6. Approval Step Approved
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Approved' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'APPROVE'

UNION ALL

-- 7. Approval Step Rejected
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Rejected' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    PAH.NOTE AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'REJECT'

UNION ALL

-- 8. Approval Step Returned
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Returned' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    PAH.NOTE AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'RETURN'

UNION ALL

-- 9. Requisition Approved
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Approved' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    'APPROVED' AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'FINALLY CLOSE' AND BR.DOCUMENT_STATUS = 'APPROVED'

UNION ALL

-- 10. Requisition Rejected
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Rejected' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    'REJECTED' AS "RequisitionStatus",
    BR.RequiredByDate,
    PAH.NOTE AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'REJECT'
AND BR.DOCUMENT_STATUS = 'REJECTED'
AND PAH.ACTION_DATE = (SELECT MAX(PAH2.ACTION_DATE) FROM PO_ACTION_HISTORY PAH2 WHERE PAH2.OBJECT_ID = BR.REQUISITION_HEADER_ID AND PAH2.ACTION_CODE = 'REJECT')

UNION ALL

-- 11. Purchase Order Created
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Purchase Order Created' AS "ActivityName",
    POH.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN POR_REQUISITION_LINES_ALL PRL ON BR.REQUISITION_HEADER_ID = PRL.REQUISITION_HEADER_ID
JOIN PO_DISTRIBUTIONS_ALL POD ON PRL.REQUISITION_LINE_ID = POD.REQUISITION_LINE_ID
JOIN PO_HEADERS_ALL POH ON POD.PO_HEADER_ID = POH.PO_HEADER_ID

UNION ALL

-- 12. Requisition Closed
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Closed' AS "ActivityName",
    BR.HEADER_LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    'CLOSED' AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
WHERE BR.DOCUMENT_STATUS = 'CLOSED'

ステップ

**前提条件と環境設定：**システムにPython 3がインストールされていることを確認します。ターミナルで次のコマンドを実行し、必要なrequestsライブラリをインストールします：pip install requests。また、購買依頼データを読み取るための十分な権限を持つOracle FusionユーザーのAPI認証情報（ユーザー名、パスワード）と、Oracle FusionインスタンスのベースURLが必要です。
Pythonスクリプトを保存：「query」セクションに記載された完全なPythonコードを、たとえばextract_requisitions.pyというファイル名で保存します。
**スクリプトパラメーターを設定：**テキストエディターでスクリプトファイルを開きます。スクリプト上部のプレースホルダー値を変更します。FUSION_URL、USERNAME、PASSWORDをOracle Fusion環境の値に設定します。START_DATEとEND_DATEを調整して、抽出期間を指定します。
**APIエンドポイントとフィールドを確認：**スクリプトはpurchaseRequisitions REST APIリソースを対象とします。fieldsパラメーターを使って、必要なデータだけを要求します。パフォーマンス向上のため、PO情報用のlinesや承認イベント用のactionHistoryなど、ネストされたコレクションも含めます。
**スクリプトを実行：**ターミナルで次のコマンドを実行します：python extract_requisitions.py。スクリプトがAPIで認証し、データ取得を開始します。処理済みの購買依頼数など、進捗状況がコンソールに表示されます。
**ページネーションを処理：**スクリプトはページネーションを自動的に処理します。Oracle Fusion REST APIはデータをページ単位で返します。スクリプトは各レスポンスのhasMoreフラグを確認し、offsetパラメーターを更新して、指定した日付範囲内のすべての購買依頼を取得するまでリクエストを繰り返します。
**データ変換ロジック：**APIから取得した各購買依頼について、スクリプトはイベントログに複数の行を生成します。CreationDateから「Requisition Created」イベントを、SubmittedDateから「Requisition Submitted」イベントを作成します。また、actionHistoryコレクションを反復処理し、各承認ステップ（Started、Approved、Rejected、Returned）の詳細イベントを作成します。
**最終ステータスイベントを推定：**スクリプトは、購買依頼の最終DocumentStatusを確認し、LastUpdateDateをイベントタイムスタンプとして使用することで、「Requisition Approved」や「Requisition Rejected」などの最終結果イベントを取得します。
**購買注文イベントを生成：**スクリプトは各購買依頼明細行を確認します。明細行にPoHeaderIdがある場合は、購買注文が作成されたことを示します。このアクティビティのイベントログエントリを生成し、購買依頼を後続の調達プロセスに関連付けます。
**出力ファイルを確認：**スクリプトが完了すると、同じディレクトリにoracle_fusion_requisitions_event_log.csvというCSVファイルが作成されます。このファイルには抽出したイベントログが含まれます。
**アップロード準備：**生成されたCSVファイルを表計算ソフトで開き、内容を確認します。列とデータ形式がプロセスマイニングツールの要件に合っていることを確認します。これでファイルをProcessMindにアップロードできます。

設定

API認証情報：Purchase Requisitions REST APIへの読み取り専用アクセス権を付与するロールを持つ専用の連携ユーザーアカウントが必要です。ロールの例として、Procurement Managerやカスタム連携ロールがあります。
REST APIエンドポイント：スクリプトでは.../fscmRestApi/resources/11.13.18.05/purchaseRequisitionsエンドポイントを使用するよう設定されています。URL内のバージョン番号がOracle Fusion環境と一致していることを確認してください。
期間フィルター：スクリプトにはSTART_DATEおよびEND_DATE変数が含まれています。APIのタイムアウトやパフォーマンス上の問題を避けるため、3～6か月ずつなど、管理しやすいバッチで抽出することを強く推奨します。フィルターは購買依頼のCreationDateに適用されます。
フィールドの選択：スクリプトのfieldsパラメーターは、パフォーマンスに大きく影響します。イベントログに必要な属性だけに応答内容を限定し、ネットワーク通信量と処理時間を削減します。RequisitionId、CreationDate、actionHistory、linesなどの必須フィールドは削除しないでください。
ページネーション上限：limitパラメーターは100に設定されています。多くの環境では安全な値ですが、抽出を高速化できる可能性があるため、200または500への増加を試すこともできます。ただし、高すぎる値を設定すると、メモリ不足やAPI制限が発生する場合があります。

a サンプルクエリ python

import requests
import csv
import json
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- 
class=class="hl-string">"hl-comment"># Replace with your Oracle Fusion instance URL, username, and password.
FUSION_URL = class="hl-string">"https://[your-fusion-instance-url].oraclecloud.com"
USERNAME = class="hl-string">"your_api_user"
PASSWORD = class="hl-string">"your_api_password"

class=class="hl-string">"hl-comment"># Define the date range for the extraction.
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-06-30"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

def get_requisitions_data():
    class="hl-string">"""Fetches and processes purchase requisition data from Oracle Fusion REST API."""
    
    api_url = fclass="hl-string">"{FUSION_URL}/fscmRestApi/resources/11.13.18.05/purchaseRequisitions"
    
    class=class="hl-string">"hl-comment"># Define the fields to retrieve to optimize the API call
    fields_to_get = [
        class="hl-string">"RequisitionId", class="hl-string">"RequisitionNumber", class="hl-string">"CreationDate", class="hl-string">"SubmittedDate", class="hl-string">"LastUpdateDate",
        class="hl-string">"DocumentStatus", class="hl-string">"PreparerName", class="hl-string">"BusinessUnitName", class="hl-string">"RequisitionTotal", class="hl-string">"NeedByDate",
        class="hl-string">"Department", class="hl-string">"RejectionReason", 
        class="hl-string">"actionHistory(ActionCode,ActionDate,PerformerName)",
        class="hl-string">"lines(PoHeaderId,LastUpdateDate)"
    ]
    
    class=class="hl-string">"hl-comment"># Parameters for the API request
    params = {
        class="hl-string">"q": fclass="hl-string">"CreationDate between '{START_DATE}' and '{END_DATE}'",
        class="hl-string">"fields": class="hl-string">",".join(fields_to_get),
        class="hl-string">"limit": 100,
        class="hl-string">"offset": 0
    }
    
    headers = {
        class="hl-string">'Content-Type': class="hl-string">'application/vnd.oracle.adf.resourceitem+json'
    }
    
    event_log = []
    has_more = True
    total_processed = 0
    now_iso = datetime.utcnow().isoformat() + class="hl-string">'Z'

    while has_more:
        print(fclass="hl-string">"Fetching requisitions from offset {params['offset']}...")
        try:
            response = requests.get(
                api_url, 
                auth=(USERNAME, PASSWORD), 
                params=params, 
                headers=headers
            )
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes (4xx or 5xx)
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data: {e}")
            break

        data = response.json()
        requisitions = data.get(class="hl-string">'items', [])

        if not requisitions:
            print(class="hl-string">"No more requisitions found.")
            break

        for req in requisitions:
            base_event = {
                class="hl-string">'PurchaseRequisitionId': req.get(class="hl-string">'RequisitionNumber'),
                class="hl-string">'RequesterName': req.get(class="hl-string">'PreparerName'),
                class="hl-string">'DepartmentName': req.get(class="hl-string">'Department'),
                class="hl-string">'RequisitionTotalAmount': req.get(class="hl-string">'RequisitionTotal'),
                class="hl-string">'RequisitionStatus': req.get(class="hl-string">'DocumentStatus'),
                class="hl-string">'RequiredByDate': req.get(class="hl-string">'NeedByDate'),
                class="hl-string">'RejectionReason': req.get(class="hl-string">'RejectionReason'),
                class="hl-string">'BusinessUnit': req.get(class="hl-string">'BusinessUnitName'),
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials',
                class="hl-string">'LastDataUpdate': now_iso
            }

            class=class="hl-string">"hl-comment"># 1. Requisition Created
            if req.get(class="hl-string">'CreationDate'):
                event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Created', class="hl-string">'EventTime': req[class="hl-string">'CreationDate']})

            class=class="hl-string">"hl-comment"># 2. Requisition Submitted
            if req.get(class="hl-string">'SubmittedDate'):
                event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Submitted', class="hl-string">'EventTime': req[class="hl-string">'SubmittedDate']})

            class=class="hl-string">"hl-comment"># 3-8. Approval Workflow Events from actionHistory
            po_created = False
            if class="hl-string">'actionHistory' in req and req[class="hl-string">'actionHistory'] is not None:
                for action in req[class="hl-string">'actionHistory']:
                    activity = None
                    action_code = action.get(class="hl-string">'ActionCode')
                    if action_code == class="hl-string">'SUBMIT':
                        class=class="hl-string">"hl-comment"># This is often the first step in the approval flow
                        activity = class="hl-string">'Approval Step Started'
                    elif action_code == class="hl-string">'APPROVE':
                        activity = class="hl-string">'Approval Step Approved'
                    elif action_code == class="hl-string">'REJECT':
                        activity = class="hl-string">'Approval Step Rejected'
                    elif action_code == class="hl-string">'RETURN':
                        activity = class="hl-string">'Approval Step Returned'
                    elif action_code == class="hl-string">'WITHDRAW':
                        activity = class="hl-string">'Requisition Withdrawn'
                    elif action_code == class="hl-string">'UPDATE':
                        activity = class="hl-string">'Requisition Amended'
                    
                    if activity:
                        event_log.append({**base_event, class="hl-string">'ActivityName': activity, class="hl-string">'EventTime': action.get(class="hl-string">'ActionDate')})

            class=class="hl-string">"hl-comment"># 9-10 & 12. Final Status Events
            final_status = req.get(class="hl-string">'DocumentStatus')
            last_update_date = req.get(class="hl-string">'LastUpdateDate')
            if last_update_date:
                if final_status == class="hl-string">'APPROVED':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Approved', class="hl-string">'EventTime': last_update_date})
                elif final_status == class="hl-string">'REJECTED':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Rejected', class="hl-string">'EventTime': last_update_date})
                elif final_status == class="hl-string">'CLOSED':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Closed', class="hl-string">'EventTime': last_update_date})

            class=class="hl-string">"hl-comment"># 11. Purchase Order Created
            if class="hl-string">'lines' in req and req[class="hl-string">'lines'] is not None:
                for line in req[class="hl-string">'lines']:
                    if line.get(class="hl-string">'PoHeaderId') and not po_created:
                        event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Purchase Order Created', class="hl-string">'EventTime': line.get(class="hl-string">'LastUpdateDate', last_update_date)})
                        po_created = True class=class="hl-string">"hl-comment"># Create only one PO event per requisition
                        break
        
        total_processed += len(requisitions)
        print(fclass="hl-string">"Processed {total_processed} total requisitions so far.")

        class=class="hl-string">"hl-comment"># Check if there is more data to fetch for pagination
        has_more = data.get(class="hl-string">'hasMore', False)
        if has_more:
            params[class="hl-string">'offset'] += params[class="hl-string">'limit']

    class=class="hl-string">"hl-comment"># Write to CSV
    if event_log:
        filename = class="hl-string">'oracle_fusion_requisitions_event_log.csv'
        fieldnames = list(event_log[0].keys())
        with open(filename, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
            writer = csv.DictWriter(csvfile, fieldnames=fieldnames)
            writer.writeheader()
            writer.writerows(event_log)
        print(fclass="hl-string">"\nSuccessfully extracted {len(event_log)} events to {filename}")
    else:
        print(class="hl-string">"\nNo events were generated.")

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

ステップ

Oracle BI Cloud Connector、必要なOracle Fusion Financialsの調達コンテンツ、および関連するPublic View Objectsへのアクセスが環境内で利用できることを確認します。BICCユーザーまたは統合アカウントに、購買依頼、承認履歴、発注書データを抽出する権限があることを確認します。正確なロール名やナビゲーションラベルはOracleのリリースによって異なるため、テナント内の対応するBICC管理領域を使用します。
抽出に必要なPVOを特定して有効にします。RequisitionHeaderPVO、または環境内で対応する購買依頼ヘッダーPVOを使用し、購買依頼明細、購買依頼ステータス履歴、承認ワークフロー履歴、発注書参照を公開するPVOと組み合わせます。1つのPVOにワークフロー履歴や発注書作成履歴が含まれているとは限りません。テナントで利用できる正確なPVO名と属性を記録します。
増分抽出または履歴一括抽出用のBICCジョブを設定します。[Start date parameter]と[End date parameter]で抽出期間を指定し、承認済みのクラウドストレージにCSVファイルを配信するようジョブを設定します。初回ロードでは、十分に広い履歴期間を指定します。定期ロードでは、遅れて更新されたデータを取り込めるよう期間を重複させ、利用可能な場合はケース識別子、アクティビティ、イベント日時、ソースイベント識別子を使ってイベントを重複排除します。
抽出する列を設定します。購買依頼識別子、購買依頼ヘッダーおよび明細識別子、申請者、部門、金額、ステータス、必要日、事業単位、却下理由、作成日時と更新日時、ステータス遷移日時、承認割り当て日時とアクション日時、承認アクション、発注書参照、BICC更新日時を含めます。選択したPVOが公開する正確な属性名を使用します。属性を利用できない場合は、未確認のフィールドで代替せず、[Configure based on your system]にマッピングして制約を記録します。
ソースCSVファイルを抽出し、元のファイルを保持します。各ファイルをステージング領域にロードし、ソースPVO名とファイル名を保持します。日時を合意した1つのタイムゾーンに統一し、Oracleの日付値とタイムスタンプ値を一貫した方法で解析します。先頭のゼロや精度が失われないよう、識別子は文字列として扱います。
ソースデータを、明示的な業務イベントごとに1行を持つイベントテーブルへ整形します。出力にはPurchaseRequisitionId、ActivityName、EventTime、SourceSystem、LastDataUpdateを含めます。利用可能な場合は推奨属性を追加します。ステータスやフィールドの変更からProcessMindがイベントを推測することを前提にしないでください。変換処理では、クエリに記載された12個すべてのアクティビティについて、行を明示的に作成する必要があります。
適切なソース証跡からイベント行を作成します。Requisition Createdにはレコード作成の証跡、Requisition Submittedには明示的な提出遷移、Requisition Withdrawnには明示的な取り下げアクションまたは遷移、Requisition Amendedには提出後の変更または新しいバージョンの検出、Approval Step Startedにはワークフロー割り当て、Approval Step Approved、Approval Step Rejected、Approval Step Returnedには明示的な承認履歴アクションを使用します。Requisition Approved、Requisition Rejected、Requisition Closedには、全体ステータスの明示的な遷移を使用します。Purchase Order Createdには、購買依頼に関連付けられた明示的な発注書作成レコードまたは作成日時を使用します。
決定的な重複排除を適用します。複数のソース行が同じイベントを表す場合は、最も具体的なイベント日時と、利用可能な場合は安定したソース識別子を使って1行を残します。同じ購買依頼識別子を持つという理由だけで、異なる承認ステップを統合しないでください。承認者やワークフローステップが異なる場合は、承認イベントを分けて保持します。
作成したイベントログを検証します。必要なすべてのアクティビティが含まれていること、すべてのイベントにケース識別子とイベント日時があること、日時が抽出期間内に収まっていること、または遅れて到着した更新について説明できることを確認します。ソースに値がある推奨属性が入力されていることも確認します。購買依頼件数と発注書リンクをソース抽出結果と照合します。
最終イベントログを、ヘッダー行1行とイベント1件につき1行を含むUTF-8 CSVとしてエクスポートします。PurchaseRequisitionId、ActivityName、EventTime、および推奨属性には正確な列名を使用します。CSVをProcessMindにアップロードし、PurchaseRequisitionIdをケース識別子、ActivityNameをアクティビティ、EventTimeをイベント日時として設定します。

設定

抽出方法：Oracle BI Cloud Connectorによる一括データ抽出を使用し、設定したクラウドストレージの場所にCSVファイルとして保存します。
ソースオブジェクト：テナントで利用可能なRequisitionHeaderPVO、および対応する購買依頼明細、ステータス履歴、承認ワークフロー履歴、発注書参照用PVOを使用します。正確なPVO名と属性は、環境内で確認する必要があります。
必須出力列：PurchaseRequisitionId、ActivityName、EventTime、SourceSystem、LastDataUpdate。
推奨出力列：RequesterName、DepartmentName、RequisitionTotalAmount、RequisitionStatus、RequiredByDate、RejectionReason、BusinessUnit。
日付範囲：通常の分析では3～6か月を使用します。初回の履歴データ読み込みが必要な場合は、より広い範囲を使用します。定期的な抽出では、更新の遅延を取り込めるよう抽出期間を重複させ、その後に重複データを排除します。
フィルター：選択したPVOで次の属性が利用できる場合に限り、[会社固有のフィルター]、[文書タイプフィルター]、[事業単位フィルター]、[日付範囲フィルター]を適用します。フィルターが作成日、更新日、ステータス遷移日、その他のソース日付のどれに適用されるかを確認します。
増分抽出：BICCが提供する更新タイムスタンプまたはサポート対象の増分抽出機能を優先します。最後に成功した抽出のウォーターマークを保持し、次回の実行では小さな重複期間を設けます。
イベントの完全性：購買依頼ヘッダーから承認履歴、ステータス遷移、変更、発注書の作成を取得できない場合は、ソース抽出を分けて設定します。現在の状態だけを示すヘッダー抽出では、過去のイベントを確実に再構成できません。
パフォーマンス：日付範囲と選択列を絞り、対応している場合は大規模な抽出を分割し、不要な説明用属性を避け、CSVファイルをバッチ処理します。照合に備えてソースファイルを保持します。
ストレージ：十分な容量、保持期間、暗号化、アクセス制御を備えた承認済みのクラウドストレージの場所を設定します。抽出アカウントがファイルを書き込めること、変換処理がファイルを読み取れることを確認します。
前提条件：BICCの利用環境、関連するOracle Fusionの調達・承認データへのアクセス権、適切な連携認可、選択したPVOへのアクセス権、必要なOracleのサブスクリプションまたは機能利用権が必要です。正確なロール名、ライセンス、ナビゲーションパスは、Oracleのリリースとテナント設定によって異なります。
時刻の扱い：すべてのソースタイムスタンプを文書化したタイムゾーンに正規化し、監査可能性が必要な場合は元のタイムスタンプも保持します。
ケースの扱い：ケース識別子にはPurchaseRequisitionIdを使用します。プロセスを意図的に明細レベルでモデル化する場合を除き、購買依頼明細の識別子をケース識別子として使用しないでください。

a サンプルクエリ sql

WITH
source_requisition AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([Creation timestamp attribute] AS TIMESTAMP) AS CreatedAt,
        CAST([Submission timestamp attribute] AS TIMESTAMP) AS SubmittedAt,
        CAST([Withdrawal timestamp attribute] AS TIMESTAMP) AS WithdrawnAt,
        CAST([Approval timestamp attribute] AS TIMESTAMP) AS ApprovedAt,
        CAST([Rejection timestamp attribute] AS TIMESTAMP) AS RejectedAt,
        CAST([Closure timestamp attribute] AS TIMESTAMP) AS ClosedAt,
        CAST([Last update timestamp attribute] AS TIMESTAMP) AS SourceLastUpdate,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Requisition header extract or view]
    WHERE CAST([Last update timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Last update timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
      AND ([Company filter attribute] = '[Company-specific filter]' OR '[Company-specific filter]' = '[All companies]')
      AND ([Document type filter attribute] = '[Document Type filter]' OR '[Document Type filter]' = '[All document types]')
),
source_status_history AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Previous status attribute] AS VARCHAR(200)) AS PreviousStatus,
        CAST([New status attribute] AS VARCHAR(200)) AS NewStatus,
        CAST([Status change timestamp attribute] AS TIMESTAMP) AS StatusChangedAt,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Requisition status history extract or view]
    WHERE CAST([Status change timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Status change timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
source_amendments AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Amendment timestamp attribute] AS TIMESTAMP) AS AmendedAt,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Requisition amendment or version extract or view]
    WHERE CAST([Amendment timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Amendment timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
source_approval_history AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Approval step identifier attribute] AS VARCHAR(200)) AS ApprovalStepId,
        CAST([Approver or approval group attribute] AS VARCHAR(500)) AS ApproverName,
        CAST([Approval action attribute] AS VARCHAR(200)) AS ApprovalAction,
        CAST([Approval assignment timestamp attribute] AS TIMESTAMP) AS ApprovalStartedAt,
        CAST([Approval action timestamp attribute] AS TIMESTAMP) AS ApprovalActionAt,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Approval workflow history extract or view]
    WHERE COALESCE(CAST([Approval assignment timestamp attribute] AS TIMESTAMP), CAST([Approval action timestamp attribute] AS TIMESTAMP)) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND COALESCE(CAST([Approval assignment timestamp attribute] AS TIMESTAMP), CAST([Approval action timestamp attribute] AS TIMESTAMP)) < CAST('[End date parameter]' AS TIMESTAMP)
),
source_purchase_orders AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Purchase order creation timestamp attribute] AS TIMESTAMP) AS PurchaseOrderCreatedAt,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Purchase order reference extract or view]
    WHERE CAST([Purchase order creation timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Purchase order creation timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
events AS (
    SELECT PurchaseRequisitionId, 'Requisition Created' AS ActivityName, CreatedAt AS EventTime, RequesterName, DepartmentName, RequisitionTotalAmount, RequisitionStatus, RequiredByDate, RejectionReason, BusinessUnit, LastDataUpdate FROM source_requisition WHERE CreatedAt IS NOT NULL
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Submitted', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) IN ('pending approval', 'submitted', 'pending') AND LOWER(COALESCE(h.PreviousStatus, '')) IN ('incomplete', 'draft')
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Withdrawn', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) IN ('withdrawn', 'cancelled', 'canceled')
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Requisition Amended', a.AmendedAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_amendments a WHERE a.AmendedAt IS NOT NULL
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Started', a.ApprovalStartedAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalStartedAt IS NOT NULL
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Approved', a.ApprovalActionAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalActionAt IS NOT NULL AND LOWER(a.ApprovalAction) IN ('approved', 'approve')
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Rejected', a.ApprovalActionAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalActionAt IS NOT NULL AND LOWER(a.ApprovalAction) IN ('rejected', 'reject')
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Returned', a.ApprovalActionAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalActionAt IS NOT NULL AND LOWER(a.ApprovalAction) IN ('returned', 'return', 'sent back', 'send back')
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Approved', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) = 'approved'
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Rejected', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) = 'rejected'
    UNION ALL
    SELECT p.PurchaseRequisitionId, 'Purchase Order Created', p.PurchaseOrderCreatedAt, p.RequesterName, p.DepartmentName, p.RequisitionTotalAmount, p.RequisitionStatus, p.RequiredByDate, p.RejectionReason, p.BusinessUnit, p.LastDataUpdate FROM source_purchase_orders p WHERE p.PurchaseOrderCreatedAt IS NOT NULL
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Closed', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) IN ('closed', 'finally closed', 'complete', 'completed')
)
SELECT
    PurchaseRequisitionId,
    ActivityName,
    EventTime,
    'Oracle Fusion Financials' AS SourceSystem,
    LastDataUpdate,
    RequesterName,
    DepartmentName,
    RequisitionTotalAmount,
    RequisitionStatus,
    RequiredByDate,
    RejectionReason,
    BusinessUnit
FROM events
WHERE PurchaseRequisitionId IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY PurchaseRequisitionId, EventTime, ActivityName;

準備はできましたか？

このテンプレートを使って、調達から支払いまでの購買依頼プロセスの最適化と新たな効率化に向けた取り組みを始めましょう。調達業務を変革する準備を整えてください。

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

調達から支払いまで：購買依頼の処理を30％高速化

Oracleの調達から支払いまでの購買依頼プロセスを効率化し、処理サイクルを30％短縮します。

無料トライアルを開始

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

調達から支払いまで：購買依頼データテンプレート

調達から支払いまで：購買依頼データテンプレート

調達から支払いまで：購買依頼の属性

調達から支払いまで：購買依頼のアクティビティ

抽出ガイド

Oracle Transactional Business Intelligence（OTBI）エクスポート

ステップ

設定

a サンプルクエリ sql

Oracle BI PublisherのSQLベースデータモデルによる抽出

ステップ

設定

a サンプルクエリ sql

Oracle Fusion REST APIを使用したPythonスクリプト

ステップ

設定

a サンプルクエリ python

Oracle BI Cloud Connector（BICC）による一括データ抽出

ステップ

設定

a サンプルクエリ sql

準備はできましたか？

調達から支払いまで：購買依頼の処理を30％高速化

調達から支払いまで：購買依頼データテンプレート

調達から支払いまで：購買依頼データテンプレート

調達から支払いまで：購買依頼の属性

調達から支払いまで：購買依頼のアクティビティ

抽出ガイド

Oracle Transactional Business Intelligence（OTBI）エクスポート

ステップ

設定

a サンプルクエリ sql

Oracle BI PublisherのSQLベースデータモデルによる抽出

ステップ

設定

a サンプルクエリ sql

Oracle Fusion REST APIを使用したPythonスクリプト

ステップ

設定

a サンプルクエリ python

Oracle BI Cloud Connector（BICC）による一括データ抽出

ステップ

設定

a サンプルクエリ sql

準備はできましたか？

調達から支払いまで：購買依頼の処理を30％高速化

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