> 継続的なプロセス改善 > 購買から支払いまで購買依頼 > SAP Ariba > データテンプレート

調達から支払いまで - 申請データテンプレート

SAP Ariba

購買から支払いまで - 購買依頼属性 (22) 購買から支払いまで - 購買依頼アクティビティ (13) 抽出ガイド (2)

調達から支払いまで - 申請データテンプレート

この包括的な`データテンプレート`は、`購買から支払いまで`（`P2P`）の`購買依頼`プロセスを分析するために必要な情報を効率的に収集し、構造化するのに役立つように設計されています。堅牢な`イベントログ`に必要な必須属性とアクティビティが概説されており、プロセス`パフォーマンス`に関する深い`洞察`を可能にします。さらに、ソース`システム`からこの`データ`を抽出するための実用的なガイダンスも提供されており、`プロセスマイニング`の旅をスムーズに開始できます。

包括的な分析のために収集を推奨する`属性`
追跡すべき主要なプロセスアクティビティとマイルストーン
システムからのデータ抽出に関する詳細なガイダンス

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

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

購買から支払いまで - 購買依頼属性

これらは、購買から支払いまで（P2P）の購買依頼分析のために`イベントログ`に含めるべき推奨`データフィールド`であり、重要な情報が見逃されることがないようにします。

3 必須 8 推奨 11 任意

	名前	説明
	アクティビティ名 ActivityName	購買依頼のライフサイクル内で特定の時点で発生したビジネス`イベント`の名前。
説明 `アクティビティ名`は、購買依頼プロセスにおける単一のステップやマイルストーンを記述します。例えば、「購買依頼作成済み」、「承認ステップ承認済み」、「購買依頼クローズ済み」などです。このデータは通常、SAP Aribaに記録されたイベントログ、ステータス変更、または特定のユーザーアクションから取得されます。この属性は、アクティビティの流れを視覚的に表現するプロセス`マップ`を構築するために不可欠です。これらのアクティビティの順序と頻度を分析することで、アナリストは一般的なプロセス`パス`、`ボトルネック`、標準手順からの逸脱、および手戻りの領域を特定できます。これはあらゆる`プロセスマイニング`分析の`バックボーン`を形成します。その重要性プロセスのステップを定義し、ボトルネックや逸脱を含む申請ワークフローの視覚化と分析を可能にします。取得元 SAP Ariba内のイベントログ、監査証跡、またはステータス変更記録から派生し、多くの場合、申請ヘッダーおよび明細項目テーブルに関連付けられます。例申請提出済承認ステップ承認済み購買依頼変更済み発注作成済み
	イベントのタイムスタンプ EventTimestamp	アクティビティが発生した正確な日時。`イベント`の順序付けのための主要な`タイムスタンプ`として機能します。
説明 `イベントタイムスタンプ`は、アクティビティが発生した正確な瞬間を記録します。この高精度な`データ`は、各ケース内で`イベント`を正しく順序付けし、プロセス内の異なるステップ間の期間を計算するために不可欠です。分析において、この`タイムスタンプ`は、サイクルタイム、待機時間、処理期間を含むすべての時間ベースの計算の基盤となります。これは、「購買依頼承認サイクルタイム」や「承認パスのボトルネック分析」のようなパフォーマンスを分析する`ダッシュボード`を動かすために使用されます。この`フィールド`の精度は、すべてのパフォーマンス`メトリクス`の信頼性に直接影響を及ぼします。その重要性この属性は`イベント`の時系列順序を提供し、`サイクルタイム`や`ボトルネック`など、すべての`パフォーマンス`および期間計算の基礎となります。取得元通常、SAP Aribaの`監査証跡`または`トランザクションログテーブル`のアクティビティまたは`ステータス`変更`レコード`と共に見つかります。例 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:05:00Z
	購買依頼書ID PurchaseRequisitionId	購買依頼`ドキュメント`の一意の`識別子`であり、プロセスの主要な`ケース識別子`として機能します。
説明 `購買依頼ID`は、単一の商品またはサービス要求に関連するすべてのアクティビティをリンクする中心的な`キー`です。SAP Aribaで作成された各購買依頼には、作成から提出、最終承認、却下、またはクローズに至るまでのライフサイクル全体を通じて一貫した固有の`ID`が割り当てられます。 `プロセスマイニング`分析において、この属性は`ケース`相関の基礎となります。これにより、各購買依頼の完全な`エンドツーエンド`のジャーニーが再構築され、サイクルタイムの正確な計算、`プロセスバリアント`の識別、および手戻り`ループ`の分析が可能になります。この`識別子`がなければ、異なる購買依頼に属する`イベント`を区別することは不可能です。その重要性これは、関連するすべてのアクティビティを接続する不可欠な`ケース識別子`であり、各固有の`依頼`に対する`エンドツーエンド`の`購買依頼`プロセスを分析することを可能にします。取得元これは、SAP Aribaの`データ構造`内の主要な購買依頼``ヘッダーテーブルにおける主`キーフィールド`です。例 PR-102345PR-102346PR-102347
	イベント_ユーザー EventUser	依頼者または承認者など、アクティビティを実行したユーザーIDまたは氏名。
説明 `イベントユーザー`属性は、特定のプロセスステップを実行した個人を識別します。これは、購買依頼を提出した従業員、それを承認したマネージャー、または処理した調達担当者である可能性があります。この属性は、ワークロード分析、パフォーマンス比較、およびトレーニング機会の特定に不可欠です。ユーザーごとの承認時間の分析を可能にすることで、「承認者のワークロードとパフォーマンス」`ダッシュボード`を動かします。また、特定の個人やチームにまで遡って追跡することで、遅延や逸脱の原因を調査するためにも使用されます。その重要性ワークロードの分散、ユーザーパフォーマンス、リソース割り当ての分析を可能にし、特定のユーザーやチームによって引き起こされるボトルネックの特定に役立ちます。取得元 SAP Aribaのドキュメントを参照してください。これは通常、監査証跡または履歴テーブルに保存され、ユーザーマスターデータにリンクされています。例 john.doejane.smithmanager123
	依頼者部門 RequesterDepartment	購買依頼を作成した従業員の事業部門またはコストセンター。
説明この属性は、ビジネスのどの部門が`依頼`を開始したかを識別することで、組織的な`コンテキスト`を提供します。これは通常、`依頼`者のユーザー`プロファイル`から派生するか、`購買依頼フォーム`に直接指定されます。分析において、これは`フィルタリング`と比較のための強力な`ディメンション`です。「`購買依頼承認サイクルタイム`」や「`購買依頼却下率分析`」など、ほぼすべての`ダッシュボード`で部門別に`メトリクス`を細分化するために使用されます。これにより、どの部門が最も長い`サイクルタイム`、最も高い`修正率`、または最も`コンプライアンス違反`の`依頼`を抱えているかを特定し、ターゲットを絞ったプロセス改善の取り組みを導くことができます。その重要性組織内の異なる部門間でプロセスパフォーマンスをセグメント化して比較することを可能にし、部門固有の問題やベストプラクティスを浮き彫りにします。取得元 SAP Aribaのドキュメントを参照してください。通常、申請ヘッダーデータで利用可能であり、申請者のユーザープロファイルからリンクされていることがよくあります。例マーケティングIT運用財務研究開発
	却下理由 RejectionReason	申請または承認ステップが却下された際に、承認者が提供する理由です。
説明 `購買依頼`が却下された際、承認者はしばしばその理由を提供します。これは`自由記述`または事前に定義された`リスト`から選択されたものである場合があります。この属性は、その重要な`フィードバック`を捕捉します。この`データ`は、「`購買依頼却下率分析`」`ダッシュボード`の`礎`となります。最も一般的な却下理由を分析することで、`コーディング`の誤り、不十分な正当化、または予算の問題など、プロセス障害の根本原因を特定するのに役立ちます。これらの`洞察`は、`依頼者`へのトレーニングを改善し、初回提出の品質を高め、手戻りを減らすために使用できます。その重要性購買依頼が失敗する原因を直接洞察し、根本原因分析を可能にすることで、手戻りを減らし、初回成功率を向上させます。取得元 SAP Aribaのドキュメントを参照してください。この情報は通常、却下イベントに関連付けられたコメントまたは履歴セクションに記録されます。例不正確なGL勘定予算超過正当性の欠如重複リクエスト
	品目カテゴリ ItemCategory	「ITハードウェア」、「オフィス用品」、「プロフェッショナルサービス」など、依頼されている商品やサービスの分類。
説明 `品目カテゴリ`は、購入されるものの詳細を提供します。この分類は、支出パターンを理解し、カテゴリ固有の調達戦略やポリシーを適用するのに役立ちます。 `プロセスマイニング`において、この属性は「購買依頼修正分析」`ダッシュボード`にとって不可欠です。特定の`アイテム`カテゴリが修正される傾向が高いかどうかを`ハイライト`し、不明確な仕様や価格変動を示唆する可能性があるためです。また、承認時間など、異なる種類の購買全体でプロセス`パフォーマンス`を比較し、特定のカテゴリがより多くの摩擦に直面しているかどうかを確認することも可能です。その重要性購買される商品やサービスの種類に基づいた分析を可能にし、カテゴリ固有のボトルネックやコンプライアンス問題の特定に役立ちます。取得元 SAP Aribaのドキュメントを参照してください。この情報は通常、申請の明細項目レベルで確認できます。例 ITハードウェアコンサルティングサービスオフィス用品マーケティング資料
	承認ワークフローパス ApprovalWorkflowPath	購買依頼が従うべきとされている承認ステップの事前定義された順序。
説明この属性は、金額、品目`カテゴリ`、部門などの特性に基づいて、購買依頼が準拠すべき標準`プロセスバリアント`または承認`マトリックス`を定義します。これは「`To-Be`」または「`ハッピーパス`」プロセスを表します。これは`コンフォーマンスチェック`の基礎であり、「購買依頼`コンプライアンス`概要」`ダッシュボード`で使用されます。実際のアクティビティのシーケンスを想定される承認`ワークフローパス`と比較することで、アナリストはポリシー違反、不正な承認ステップ、またはスキップされた`コントロール`を自動的に検出できます。これは内部監査と`リスクマネジメント`にとって重要です。その重要性従うべき標準プロセスを定義し、適合性チェックによって逸脱やポリシー違反を自動的に検出できるようにします。取得元 SAP Aribaのドキュメントを参照してください。これは承認マトリックスの設定または申請上の特定のフィールドから派生する場合があります。例標準IT > 1万ドルマーケティングサービス < 5千ドルCAPEX > $100k
	緊急度レベル UrgencyLevel	申請の優先度を示す指標で、「通常」、「緊急」、「重要」などがあります。
説明 `緊急度レベル`は、優先度`フラグ`として表現されることが多く、迅速な処理が必要なビジネスニーズを示します。これは通常、重要なニーズが迅速に対処されることを確実にするために依頼者によって設定されます。この属性は、「緊急購買依頼プロセスモニター」`ダッシュボード`と「緊急購買依頼処理時間」`KPI`の主要な`ドライバー`です。緊急`購買依頼`と通常の`購買依頼`のサイクルタイムを直接比較し、優先処理が効果的であるかどうかを検証できます。緊急依頼における逸脱や遅延を分析することは、ビジネス`コンティニュイティ`を確保するための主要な`ユースケース`です。その重要性優先度の高い申請がより迅速に処理されるかどうかを分析および監視することを可能にし、重要なビジネスニーズが満たされることを保証します。取得元 SAP Aribaのドキュメントを参照してください。これは申請作成フォームで選択可能なフィールドであることがよくあります。例高中低
	購買依頼ステータス RequisitionStatus	購買依頼のライフサイクルにおける現在の状態。
説明この属性は、「作成中」、「提出済み」、「承認済み」、「却下済み」、「クローズ済み」など、購買依頼の`リアルタイム`の`ステータス`を反映します。`データ`抽出時における各`ケース`がプロセス内のどこにあるかの`スナップショット`を提供します。 `プロセスマイニング`は履歴`フロー`を再構築しますが、この属性は`オペレーショナルモニタリング`にとって不可欠です。これは「`ライブ購買依頼ステータストラッカー`」の主要な`データポイント`であり、マネージャーが現在の`ワークロード`を確認し、停滞または長期化している`購買依頼`を特定できるようにします。これにより、アクティブな`購買依頼パイプライン`に対する即時かつ実用的な`可視性`が提供されます。その重要性申請パイプラインのリアルタイム監視を可能にし、問題となる前に停滞したまたは長期化している要求を特定し、対処するのに役立ちます。取得元 SAP Aribaのドキュメントを参照してください。これは申請ヘッダーの標準ステータスフィールドです。例承認済み申請済み否認承認中
	購買依頼合計金額 TotalRequisitionAmount	購買申請の合計金額です。
説明この属性は、`依頼`全体の財務的価値を把握します。これは、購買依頼を分類し、優先順位を付けるのに役立つ重要なビジネス`コンテキスト`の一部です。この`値`に基づいてプロセス`メトリクス`を分析することで、重要なパターンが明らかになることがあります。例えば、高額な購買依頼は、より厳格な承認`パス`をたどったり、より長いサイクルタイムを経験したりする可能性があります。この属性は、プロセス`非効率`の財務的影響を理解し、比較分析のために`購買依頼`を`価値帯`に分類するために不可欠です。その重要性重要な財務情報を提供し、購買依頼の金額が承認時間やワークフローの複雑さといったプロセス挙動にどのように影響するかを分析できるようにします。取得元 SAP Aribaのドキュメントを参照してください。これは購買申請ヘッダーの標準フィールドです。例 1500.0025000.5099.95
	`購買発注`ID PurchaseOrderId	承認された購買依頼から作成された購買発注の識別子。
説明この属性は、`購買依頼`をその下流`ドキュメント`である`購買発注`（`PO`）にリンクします。その存在は、`依頼`が`発注`に正常に変換されたことを示します。これは、`購買依頼`段階を超えて広がる`エンドツーエンド`のプロセス分析に不可欠です。`購買依頼`作成`イベント`と`PO`作成`イベント`を接続することで、「`購買依頼`から`PO`までの`リードタイム`」`KPI`を計算するために使用されます。これにより、`調達サイクル`の`フロントエンド`の全体像が提供されます。その重要性申請と後続の発注書をリンクさせ、エンドツーエンドの申請からPOまでのサイクルタイムの測定を可能にします。取得元 SAP Aribaのドキュメントを参照してください。これは通常、POが生成された後の申請明細データに保存されます。例 PO-4500012345PO-4500012346PO-4500012347
	ソースシステム SourceSystem	`データ`が抽出された記録システム。
説明この属性は、プロセス`データ`の`発生源`を識別します。この`ビュー`では`値`は一貫して「SAP Ariba」ですが、複数の`システム`から`データ`が統合される広範な`コンテキスト`では、この`フィールド`はデータ``リネージとトラブルシューティングにとって非常に重要です。分析において、`データ`の`発生源`を確認するのに役立ち、異なる`システム`にまたがるプロセスを`フィルタリング`または比較するために使用できます。これにより、`データソース`の明確さと信頼性が確保され、関係者の`合意`を得る上で重要です。その重要性データの出所を特定します。これはデータガバナンス、トラブルシューティング、分析のコンテキストが理解されていることを保証するために不可欠です。取得元データ抽出・変換の過程で付与する固定値で、データセットのソースを示すラベルとして利用します。例 SAP AribaSAP_ARIBA_P2PAribaCloud
	最終データ更新 LastDataUpdate	このレコードのデータがソースシステムから最後に更新された日時を示すタイムスタンプ。
説明この属性は、特定の`イベント`の最新の`データ`抽出または更新の日時を示します。これは、分析されている`データ`の鮮度に関する透明性を提供し、進行中のプロセスを`モニタリング`する上で特に重要です。アナリストは、この情報を使用して生成された`洞察`の最新性を理解します。「`ライブ購買依頼ステータストラッカー`」のような`ダッシュボード`では、この`フィールド`は表示される情報がどれだけ最新であるかをユーザーに知らせるために不可欠です。`データ`の適時性に関する期待値を管理するのに役立ちます。その重要性データの鮮度を示し、プロセスマイニングの洞察のタイムリーさと関連性を理解するために不可欠です。取得元この`タイムスタンプ`は、通常`データ`取り込みプロセス中に生成され、各`レコード`に追加されます。例 2024-05-21T02:00:00Z2024-05-22T02:00:00Z
	変更済み IsAmended	初回提出後、申請が少なくとも一度修正されたかどうかを示すブール値フラグです。
説明この計算属性は、少なくとも1つの「購買依頼修正済み」アクティビティを経た`ケース`を特定します。これにより、`ライフサイクル`中に変更が必要だった`購買依頼`に`フラグ`を立てるプロセスが簡素化されます。この`フラグ`は「`購買依頼修正率`」`KPI`を計算するために使用されます。この`フラグ`が`True`である`ケース`の数を数えることで、アナリストは手戻りの頻度を簡単に測定し、「`依頼者名`」や「`品目カテゴリ`」などの他の属性と関連付けることで根本原因を調査できます。その重要性修正率KPIの計算を簡素化し、手戻りを定量化し、より明確な初期仕様が必要な領域を特定するのに役立ちます。取得元ケースに1つ以上の「申請修正」アクティビティが含まれる場合、真と計算され、そうでない場合は偽と計算されます。例 truefalse
	手戻り IsRework	申請が却下されたり、複数回修正されたりするなど、手戻りが発生したかどうかを示すブール値フラグです。
説明この計算属性は、「修正済みであるか」よりも広範な非効率性の`尺度`です。これは、1つ以上の「承認ステップ却下済み」`イベント`または複数の「購買依頼修正済み」`イベント`を経験するなど、重大な手戻り`ループ`を経験した`ケース`に`フラグ`を立てます。この`フラグ`は「`購買依頼手戻り率`」`KPI`を計算するために使用されます。これは、プロセス障害に関連する潜在的な`コスト`と遅延を定量化するのに役立ちます。手戻りとしてマークされた`ケース`を分析することで、特定の承認者、部門、または`依頼タイプ`に関連するパターンを発見し、プロセス摩擦につながる原因を特定できます。その重要性却下など、プロセスに大きな摩擦があるケースを特定し、非効率性と遅延の原因に焦点を当てた分析を可能にします。取得元ケースに却下アクティビティまたは複数の修正アクティビティが含まれる場合、真と計算されます。例 truefalse
	承認ステップ期間 ApprovalStepDuration	単一の承認ステップに要した時間。割り当てられてから処理されるまでの期間です。
説明この計算`メトリクス`は、より広範な承認`ワークフロー`内の個々のセグメントの期間を測定します。これは、特定の承認者または承認`レベル`を待機している時間を分離します。この属性は、「承認`パス`の`ボトルネック`分析」`ダッシュボード`と「平均承認ステップ期間」`KPI`にとって不可欠です。これは、「承認ステップ開始」`イベント`と、それに対応する「承認ステップ承認済み」または「承認ステップ却下済み」`イベント`の間の時間として計算されます。この`粒度`の測定により、遅延の原因となっている特定の承認者またはステップを正確に特定できます。その重要性承認ワークフローを詳細に洞察し、ボトルネックの原因となっている特定のステップや承認者を正確に特定します。取得元「承認ステップ開始済み」のタイムスタンプと、それに対応する終了イベント（「承認済み」または「却下済み」）のタイムスタンプとの差として計算されます。例 1日2時間15分3 days
	承認者名 ApproverName	ワークフロー内の特定のステップを承認するために割り当てられたユーザーの名前。
説明この属性は、承認アクティビティを担当する特定のマネージャーまたは`ステークホルダー`を識別します。承認`タスク`に特に関連するため、一般的な「`イベントユーザー`」とは異なります。これは「承認者の`ワークロード`と`パフォーマンス`」`ダッシュボード`にとって重要な属性です。各承認者が処理した`購買依頼`の数と平均承認時間を追跡できます。これは、個々の`ボトルネック`を特定し、`ワークロード`のバランスを取り、目標に対する`パフォーマンス`を評価するのに役立ちます。その重要性承認を担当する特定の個人を正確に特定し、詳細なワークロードのバランス調整と承認者のパフォーマンス分析を可能にします。取得元 SAP Aribaのドキュメントを参照してください。この情報は、申請にリンクされた承認フローデータに保存されています。例サラ・ジョーンズDavid ChenMaria Garcia
	申請者名 RequesterName	購買依頼を開始した従業員の氏名。
説明この`ケースレベル`属性は、`購買依頼`の作成者を識別します。これは、`依頼`の`発生源`と個々の`ステークホルダー`に関する`コンテキスト`を提供します。分析において、この属性はプロセスを`フィルタリング`し、特定の`依頼者`による`行動`を分析するために使用されます。例えば、「`購買依頼修正分析`」や「`購買依頼却下率分析`」`ダッシュボード`は、高い修正率または却下率のために追加のトレーニングを必要とする可能性のある個人を特定するためにこれを使用します。これにより、`フィードバック`と改善`イニシアチブ`を個別化するのに役立ちます。その重要性要求の作成者を特定し、申請者ごとのプロセス動作と品質の分析を可能にします。取得元 SAP Aribaのドキュメントを参照してください。これは申請ヘッダーの標準フィールドで、しばしば「作成者」または「申請者」としてラベル付けされています。例アリス・ウィリアムズBob MillerCharles Brown
	自動化 IsAutomated	アクティビティがシステムまたは人間によって実行されたかどうかを示すブール値フラグです。
説明この属性は、自動承認やシステム駆動の`ステータス`変更などの自動化された`システムイベント`と、ユーザーによって実行される手動のアクティビティとを区別します。これは、プロセスにおける自動化のレベルを理解するために非常に重要です。分析において、これは人的な労力を正確に測定し、さらなる自動化の機会を特定するのに役立ちます。例えば、手動アクティビティでフィルタリングすることで、ユーザー中心の処理時間を正確に計算できます。また、プロセス内で自動化された`ルール`が期待どおりに機能していることを検証するのにも役立ちます。その重要性人間とシステムのアクションを区別します。これは自動化率の測定や新たな自動化機会の特定に不可欠です。取得元これは通常、「`イベントユーザー`」が`システム`または`バッチユーザーID`に対応するかどうかを確認することで導出されます。例 truefalse
	購買依頼からPOまでのリードタイム RequisitionToPoLeadTime	購買依頼の作成から、結果として生じる購買発注の作成までの合計時間。
説明これは、ビジネスニーズを実行可能な`購買発注`に変換するための、`エンドツーエンド`の全期間を測定する計算`メトリクス`です。これは、`調達プロセス`の初期段階の効率に関する包括的な`ビュー`を提供します。この属性は「`購買依頼`から`PO`までの`リードタイム`」`KPI`を直接サポートします。これは、「`購買依頼`作成済み」`イベント`と「`購買発注`作成済み」`イベント`の間の時間差として計算されます。この`メトリクス`を分析することで、組織はビジネス`ユーザー`が経験する総`リードタイム`を理解し、全体的な改善のための領域を特定するのに役立ちます。その重要性要求から発注までのエンドツーエンドの全時間を測定し、調達サイクル効率のための全体的なKPIを提供します。取得元「申請作成済み」のタイムスタンプから「発注書作成済み」のタイムスタンプを差し引くことで計算されます。例 7日3時間10日4日12時間
	購買依頼承認時間 RequisitionApprovalCycleTime	購買依頼が提出されてから最終承認を受けるまでの合計経過時間。
説明これは、`コア`承認プロセスの期間を測定する計算`メトリクス`です。承認`ワークフロー`の効率を反映する主要な`パフォーマンス指標`です。この`KPI`は「`購買依頼承認サイクルタイム`」`ダッシュボード`を直接動かし、「平均`購買依頼承認時間`」`KPI`の基礎となります。これは、各`ケース`の「`購買依頼提出済み`」`イベント`と「`購買依頼承認済み`」`イベント`の間の時間差として計算されます。この`メトリクス`を分析することで、承認`チェーン`における全体的な遅延を特定するのに役立ちます。その重要性主要なKPIとダッシュボードを直接サポートし、遅延を特定および削減するためのコア承認プロセスの効率性を測定します。取得元「申請提出済み」のタイムスタンプから「申請承認済み」のタイムスタンプを差し引くことで計算されます。例 2日4時間8 hours 30 minutes5 days

必須推奨任意

購買から支払いまで - 購買依頼アクティビティ

これらは、正確なプロセスディスカバリとボトルネックの特定のためにイベントログに捕捉すべき主要なプロセスステップとマイルストーンです。

6 推奨 7 任意

	アクティビティ	説明
	依頼書承認済み	購買申請がワークフロー内のすべてのステップを正常に通過した後の最終承認を示します。これはステータスの「承認済み」への変更によって捕捉されます。
その重要性承認フェーズの終了を示す重要なマイルストーンです。「平均申請承認時間」を測定する終点であり、PO作成の準備が整ったことを示します。取得元 Aribaの文書履歴から推測され、申請の最終ステータスが「承認済み」に変更されたことが記録されます。取得申請のステータスフィールドが「承認済み」に変更されたときのタイムスタンプを特定します。イベントタイプ inferred
	採用申請作成済み	ユーザーによる購買申請文書の初期作成を示します。これは、申請が最初に「作成中」または下書きステータスで保存されたときに捕捉されます。
その重要性これは購買依頼``ライフサイクルの`開始点`です。作成から提出までの時間を分析することで、`ユーザー`効率を測定し、トレーニングニーズを特定するのに役立ちます。取得元 SAP Aribaにおける購買申請オブジェクトの作成タイムスタンプからです。これは申請文書のヘッダーデータで確認でき、明示的な作成イベントを表します。取得購買依頼`ドキュメントヘッダーテーブル`の「`作成時間`」またはそれに相当する`タイムスタンプ`を使用してください。イベントタイプ explicit
	申請提出済	依頼者による承認ワークフローへの購買依頼の正式な提出を表します。「作成中」から「提出済み」へのステータス変更によって記録されます。
その重要性これは承認プロセスを`トリガー`する主要な`マイルストーン`です。「`購買依頼承認サイクルタイム`」と「`購買依頼作成リードタイム`」を測定するために不可欠です。取得元 Aribaの文書履歴または監査ログから推測され、申請のステータスが「提出済み」に変更されたことと、その変更のタイムスタンプが記録されます。取得申請のステータスフィールドが最初に「提出済み」に変更されたときのタイムスタンプを特定します。イベントタイプ inferred
	発注作成済み	承認された購買申請が発注書に正常に変換されたことを示します。これは、申請を参照するPO文書の作成によって捕捉されます。
その重要性これは`購買依頼`プロセスの主要な成功結果です。`エンドツーエンド`の「`購買依頼`から`PO`までの`リードタイム`」`KPI`を測定するために不可欠です。取得元これは明示的な`イベント`です。元となる`購買依頼ID`への直接`リンク`または参照を含む`購買発注ドキュメント`の作成`タイムスタンプ`が使用されます。取得 POヘッダーテーブルから、申請にリンクされたPOを見つけ、その作成タイムスタンプを使用します。イベントタイプ explicit
	購買依頼クローズ済み	発注や受領など、関連するすべてのアクションが完了した後の購買依頼の最終的な管理上のクローズ。「クローズ済み」への最終的なステータス変更によって記録されます。
その重要性購買依頼ライフサイクル全体の最終的な終了を表します。PO作成からクローズまでの時間を分析することで、下流の受領または請求プロセスにおけるボトルネックが明らかになることがあります。取得元 Aribaの文書履歴から推測され、申請のステータスが「クローズ済み」に変更されたことが記録されます。取得申請のステータスフィールドが「クローズ済み」に変更されたときのタイムスタンプを特定します。イベントタイプ inferred
	購買依頼却下済み	レビュー後の購買依頼の最終的な却下を表します。これはプロセスにおける終了状態であり、「却下済み」へのステータス変更によって記録されます。
その重要性これは主要な失敗`エンドポイント`です。却下された`購買依頼`を分析することは、「`購買依頼却下率`」`KPI`にとって、パターンを特定し、`依頼`品質を向上させるために不可欠です。取得元 Aribaの文書履歴から推測され、申請の最終ステータスが「拒否済み」に変更されたことが記録されます。取得申請のステータスフィールドが「拒否済み」に変更されたときのタイムスタンプを特定します。イベントタイプ inferred
	ソーシングに送信された購買依頼	承認された申請が、POが作成される前にRFQのようなソーシングイベントを実行するためにソーシング部門にルーティングされたときに発生します。ステータス変更、例えば「ソーシング中」によって捕捉されます。
その重要性高額または非標準品目のプロセスにおける重要な分岐点を特定します。ソーシング部門のリードタイムへの貢献度を分析するのに役立ちます。取得元申請ステータスがソーシングに送られたことを示す値に変更されたことから推測されます。これはAriba BuyingがAriba Sourcingと統合されている場合によく見られます。取得申請のステータスフィールドが「ソーシング中」または類似のカスタムステータスに変更されたときのタイムスタンプを特定します。イベントタイプ inferred
	承認ステップ却下済み	承認ステップの否定的結果を表し、承認者が購買依頼を却下し、通常は修正のために差し戻します。これは「却下」アクションとして明示的にログに記録されます。
その重要性手戻りやプロセス遅延の主要な原因を浮き彫りにします。これらのイベントを分析することは、「申請手戻り率」と却下理由を理解するために不可欠です。取得元 Ariba承認フローテーブルからです。これは、承認者が割り当てられたタスクで「拒否」または「却下」アクションを実行したときにタイムスタンプとともにログに記録されます。取得特定の`ステップ`の承認履歴に記録された「却下」`アクション`の`タイムスタンプ`を使用してください。イベントタイプ explicit
	承認ステップ承認済み	承認ステップの肯定的な結果を表し、承認者が割り当てられた購買依頼の一部を承認しました。これは承認アクションとして明示的にログに記録されます。
その重要性個々の承認者の処理時間を測定します。このデータは、「平均承認ステップ期間」を計算し、承認者のワークロードを評価するために不可欠です。取得元 Ariba承認フローテーブルからです。これは、承認者が割り当てられたタスクで「承認」アクションを実行したときにタイムスタンプとともにログに記録されます。取得特定の`ステップ`の承認履歴に記録された「承認」`アクション`の`タイムスタンプ`を使用してください。イベントタイプ explicit
	承認ステップ開始済み	購買申請が承認者または承認キューにルーティングされ、アクション待ちであることを示します。これは、承認要求が生成され割り当てられたときに捕捉されます。
その重要性承認ワークフローを詳細に洞察します。「承認パスのボトルネック分析」において、キュー時間を計算し、どの特定のステップがボトルネックであるかを特定するために不可欠です。取得元申請にリンクされた個々の承認タスクの作成と割り当てをログに記録するAriba承認フローテーブルからです。取得 `購買依頼`と特定の承認`ステップ`に関連付けられた承認リクエスト``レコードの作成`タイムスタンプ`を使用してください。イベントタイプ explicit
	購買依頼変更済み	購買申請が提出された後、多くの場合却下または問い合わせに応じてユーザーがそれを修正したときに発生します。これは、文書が編集され再提出されたときに捕捉されます。
その重要性手戻りやプロセス非効率性を追跡します。修正の頻度が高いことは、初期要件や`ポリシー`が不明確であることを示唆し、「`購買依頼修正率`」`KPI`に影響を与えます。取得元 Aribaのバージョン管理データから推測されます。各修正は申請文書の新しいバージョンを作成します。バージョンが1より大きいバージョンの作成は修正を示します。取得最初の「提出済み」ステータス後に作成された申請の新しいバージョンを確認します。新しいバージョンのタイムスタンプがイベント時間です。イベントタイプ inferred
	購買依頼撤回済み	元の申請者が、完全に承認される前に提出済みの購買申請を取り消したときに発生します。これは、ステータスが「取り消し済み」または「キャンセル済み」に変更されることによって捕捉されます。
その重要性ユーザーによって開始されたプロセスの終了を表します。購買依頼が取り下げられる理由を分析することで、ビジネスニーズの変化や長期化する承認時間に関する問題が明らかになることがあります。取得元 Aribaの文書履歴または監査ログから推測され、申請のステータスが「取り消し済み」に変更されたことが記録されます。取得申請のステータスフィールドが「取り消し済み」に変更されたときのタイムスタンプを特定します。イベントタイプ inferred
	購買依頼明細項目が発注済み	購買依頼の個別の明細項目が購買発注に計上された後、「発注済み」にステータス変更されたことを表します。これは、ヘッダーレベルのPO作成よりも詳細な追跡を提供します。
その重要性ヘッダーのみを見ているだけでは見えない、明細項目レベルでの部分的な発注や遅延の分析を可能にします。これは、異なるPOによって多くの明細が満たされる申請にとって有用です。取得元申請明細項目オブジェクトのステータス変更から推測されます。POが生成されると、明細項目のステータスは「発注済み」に更新されます。取得申請明細項目のステータスフィールドが「発注済み」に変更されたときのタイムスタンプを特定します。イベントタイプ inferred

推奨任意

抽出ガイド

SAP Aribaからデータを取得する方法

ステップ

SAP Aribaにログイン: 「Reporting Analyst」ロールなど、分析レポートの作成および実行権限を持つユーザーアカウントでSAP Ariba環境にアクセスします。
分析レポートへ移動: メインダッシュボードからレポートエリアへ移動します。これは通常、「Reporting」、「Analytics」、または「Manage」>「Analytical Reports」のようなメニューの下にあります。
新規レポートの作成: 新しい分析レポートを作成するプロセスを開始します。プライマリデータエリア（しばしば「Fact」と呼ばれる）を選択するように求められます。'[Requisition]'など、申請に関連するファクト、またはAribaの設定で提供される同様の名称を選択してください。
データフィールドの追加: レポートビルダーインターフェースを使用して、レポートに列を追加します。必要なすべての情報を取得するには、複数のデータソース（Facts）を結合する必要があります。一般的なレポートでは、申請IDをキーとして'[Requisition Fact]'と'[Approval History Fact]'、'[Purchase Order Fact]'を結合します。承認履歴からの作成日、提出日、承認日、処理日など、関連するすべてのタイムスタンプを含む、クエリ設定にリストされているすべてのフィールドを追加します。
フィルターの設定: データスコープを制限するためにフィルターを設定します。最も重要なフィルターは日付範囲です。「Requisition Created Date」に目的の期間（例：過去3〜6か月）のフィルターを適用します。必要に応じて、特定のCompany CodesやRealmsなどの他のフィルターも追加します。
生レポートの実行とエクスポート: レポートを実行します。完了したら、結果をCSVまたはExcelファイルにエクスポートします。この初期エクスポートは「ワイド」形式になり、申請または承認エントリごとに1行、異なる日付やユーザーアクションに対して多数の列が含まれます。
データをイベントログ形式に変換: これは重要なオフラインステップです。Microsoft ExcelのPower Query、Pythonスクリプト、または別のデータ準備ツールを使用して、ワイド形式のデータをロング形式に変換します。エクスポートした各タイムスタンプ列（例：「Created Date」、「Submitted Date」、「Approved Date」）について、最終的なイベントログに個別の行を作成する必要があります。このプロセスはしばしば「unpivoting」または「melting」と呼ばれます。
アクティビティと属性のマッピング: 変換中に、ActivityNameとEventTimestamp列を作成します。例えば、「Submitted Date」列を処理するときは、ActivityNameが「Requisition Submitted」、EventTimestampが「Submitted Date」列の値である行を作成します。
データを統合してクリーンアップ: すべてのタイムスタンプ列からunpivotされたデータを単一のファイルに結合します。PurchaseRequisitionId、ActivityName、EventTimestamp列がすべての行で正しく入力されていることを確認します。空の行や書式設定の問題をクリーンアップします。
最終CSVとして保存: 最終的に変換されたイベントログをUTF-8エンコーディングのCSVファイルとして保存します。このファイルは、プロセスマイニングツールへのアップロード準備が整いました。

設定

レポートタイプ: 標準Aribaレポートインターフェースを使用した分析レポートです。
コアデータファクト: 通常、「[Requisition Fact]」、「[Approval History Fact]」、「[Purchase Order Fact]」を含む複数のファクトからのデータを結合する必要があります。正確な名称はAribaのデータモデルによって異なる場合があります。
日付範囲: 管理しやすい期間（例: 3〜6か月）で「Requisition Created Date」をフィルターすることをお勧めします。初期テストでは、1週間のような短い期間を使用してください。
主要フィルター: 常に特定の日付範囲でフィルターしてください。また、関連するビジネススコープにデータセットを制限し、レポートのパフォーマンスを向上させるために、「Company Code」または「Purchasing Organization」でフィルターすることも検討してください。
前提条件: レポートを実行するユーザーは、分析レポートモジュールおよび申請、承認、発注の基盤となるデータファクトにアクセスする権限を持つロールが必要です。

a クエリ例 config

REPORT CONFIGURATION for SAP Ariba Analytical Reporting

REPORT TYPE: Analytical Report

PRIMARY DATA SOURCE (FACT):
*   [Requisition Fact]

JOINED DATA SOURCES (FACTS):
*   [Approval History Fact] on Requisition ID
*   [Purchase Order Fact] on Requisition ID
*   [Requisition Line Item Fact] on Requisition ID

REPORT FIELDS (COLUMNS TO EXPORT for subsequent transformation):

// Case and General Attributes
*   Requisition.Requisition ID (as PurchaseRequisitionId)
*   Requisition.Status (as RequisitionStatus)
*   Requisition.Requester.Department (as RequesterDepartment)
*   Requisition.Total Cost.Amount (as TotalRequisitionAmount)
*   Requisition.Line Items.Category (as ItemCategory)
*   Requisition.Is Urgent (as UrgencyLevel)
*   Requisition.Approval Flow Name (as ApprovalWorkflowPath)

// Fields for 'Requisition Created'
*   Requisition.Created Date (Timestamp)
*   Requisition.Requester.User ID (User)

// Fields for 'Requisition Submitted'
*   Requisition.Submitted Date (Timestamp)
*   Requisition.Submitter.User ID (User)

// Fields for 'Requisition Amended'
*   Requisition.Last Modified Date (Timestamp) - Note: Requires logic to isolate true amendment events
*   Requisition.Last Modified By.User ID (User)

// Fields for 'Approval Step' activities
*   Approval History.Approval Request Date (Timestamp for 'Approval Step Started')
*   Approval History.Action Date (Timestamp for 'Approval Step Approved'/'Approval Step Rejected')
*   Approval History.Action (Value: 'Approve'/'Deny')
*   Approval History.Approver.User ID (User)
*   Approval History.Comments (for RejectionReason)

// Fields for final status activities
*   Requisition.Approved Date (Timestamp for 'Requisition Approved')
*   Requisition.Denied Date (Timestamp for 'Requisition Denied')
*   Requisition.Withdrawn Date (Timestamp for 'Requisition Withdrawn')
*   Requisition.Closed Date (Timestamp for 'Requisition Closed')

// Fields for downstream activities
*   Requisition.Sourcing Status Date (Timestamp for 'Requisition Sent To Sourcing')
*   Purchase Order.Created Date (Timestamp for 'Purchase Order Created')
*   Purchase Order.Creator.User ID (User for 'Purchase Order Created')
*   Requisition Line Item.Ordered Date (Timestamp for 'Requisition Line Item Ordered')

FILTERS:
*   Requisition.Created Date BETWEEN [Start Date] AND [End Date]
*   Company Code IN ([Your Company Codes])

ステップ

Python環境のセットアップ: Python 3.6以降がインストールされていることを確認します。pip install requests pandasを使用して必要なライブラリをインストールします。
APIアクセス設定: SAP Ariba開発者ポータルで新しいアプリケーションを登録します。「Operational Reporting API for Requisitions」を購読し、OAuth認証情報（Application Key (API Key)、OAuth Client Secret、および[your_api_key]:[your_client_secret]のBase64エンコード文字列）を取得します。
Pythonスクリプトのカスタマイズ: 提供されたPythonスクリプトを開きます。上部のプレースホルダー変数（ARIBА_REALM、BASE_URL、API_KEY、BASE64_CREDSなど）を入力します。また、データ抽出期間のSTART_DATEとEND_DATEを設定します。
レポートペイロードの定義: スクリプト内のreport_payload JSONオブジェクトを確認します。これは実行するレポートを定義します。スクリプトはRequisitionFactSystemViewを使用し、必要なアクティビティと属性に関連するフィールドを選択するように事前設定されています。必要に応じて、さらにフィールドやフィルターを追加できます。
スクリプトの実行: ターミナルからpython your_script_name.pyを実行します。スクリプトは最初にAribaで認証を行い、アクセストークンを取得します。
レポートジョブの送信と監視: スクリプトはレポートリクエストを自動的にAriba APIに送信します。ジョブは非同期で実行されるため、スクリプトはAribaのAPIを60秒ごとにポーリングしてジョブステータスを確認します。
レポートデータのダウンロード: Ariba APIがジョブを「COMPLETED」と報告すると、スクリプトは結果データをダウンロードします。これは通常、単一のCSVファイルを含むZIPファイルです。
データの処理と変換: スクリプトはファイルを解凍し、生データをpandas DataFrameにロードします。その後、データ形式をワイド形式（申請ごとに1行で多数の日付列を持つ）からロング形式（申請ごとに複数行で各アクティビティに対応する）のイベントログ形式に変換する重要なステップを実行します。
イベントログの生成: 変換されたDataFrameは、PurchaseRequisitionId、ActivityName、EventTimestampなどの列を持つ適切なイベントログとして構造化され、スクリプトと同じディレクトリにariba_requisition_event_log.csvとして保存されます。
アップロードの準備: 生成されたCSVファイルはProcessMindへのアップロード準備が整いました。列ヘッダーがProcessMindプロジェクトで設定されたマッピングと一致することを確認してください。

設定

API Endpoint URL: スクリプトには、AribaインスタンスのAPIのベースURLが必要です。通常、https://[your-realm].api.ariba.com/api/operationalreporting/v2/ の形式です。[your-realm] を貴社固有のAribaレルム名に置き換えてください。
認証: 抽出にはOAuth 2.0認証を使用します。Ariba Developer Portalで登録されたアプリケーションから取得した有効なapiKey、clientSecret、およびbase64EncodedCredentials文字列を提供する必要があります。
ビューテンプレート: スクリプトはRequisitionFactSystemViewを使用するように設定されています。これは標準のAribaビューですが、貴社の環境で有効になっており、APIユーザーがアクセス権限を持っていることを確認する必要があります。
日付範囲フィルター: レポートペイロードのcreationDateフィルターは、データ量を制御するために非常に重要です。初期抽出では、3〜6か月の期間を使用することをお勧めします。大規模な組織の場合は、データをより小さい月次バッチで抽出することを検討してください。
増分ロード: 後続の抽出では、START_DATEとEND_DATEを調整して、新規または更新されたレコードのみを取得します。スクリプトは増分ロジックを自動的に管理しないため、実行ごとに日付範囲を手動で設定する必要があります。
前提条件: アプリケーションと資格情報を作成するには、「Developer Portal Access」の権限を持つSAP Aribaユーザーが必要です。APIアプリケーション自体には、レポートジョブを実行するための「Operational Reporting API User」ロールが必要です。

a クエリ例 python

import requests
import json
import pandas as pd
import time
import zipfile
import io

class=class="hl-string">"hl-comment"># --- Configuration --- 
class=class="hl-string">"hl-comment"># Replace with your SAP Ariba realm, datacenter-specific URL, and credentials
ARIBA_REALM = class="hl-string">"[Your Ariba Realm]"
BASE_URL = fclass="hl-string">"https://{ARIBA_REALM}.api.ariba.com/api/operationalreporting/v2/"
TOKEN_URL = class="hl-string">"https://api.ariba.com/v2/oauth/token"
API_KEY = class="hl-string">"[Your Application Key]"
BASE64_CREDS = class="hl-string">"[Your Base64-encoded ClientID:ClientSecret]"

class=class="hl-string">"hl-comment"># --- Report Parameters ---
class=class="hl-string">"hl-comment"># Set the date range for the extraction
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-06-30T23:59:59Z"

class=class="hl-string">"hl-comment"># The main function to orchestrate the extraction process
def main():
    print(class="hl-string">"1. Acquiring access token...")
    access_token = get_access_token()
    if not access_token:
        return

    print(class="hl-string">"2. Creating asynchronous report job...")
    job_id = create_report_job(access_token)
    if not job_id:
        return

    print(fclass="hl-string">"Job created with ID: {job_id}. Polling for completion...")
    status = poll_job_status(access_token, job_id)

    if status == class="hl-string">'COMPLETED':
        print(class="hl-string">"3. Job completed. Downloading report data...")
        raw_data = download_report(access_token, job_id)
        if raw_data:
            print(class="hl-string">"4. Processing raw data into event log...")
            event_log = process_data(raw_data)
            output_filename = class="hl-string">'ariba_requisition_event_log.csv'
            event_log.to_csv(output_filename, index=False)
            print(fclass="hl-string">"5. Success! Event log saved to {output_filename}")
    else:
        print(fclass="hl-string">"Job failed or timed out with status: {status}")

def get_access_token():
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Basic {BASE64_CREDS}',
        class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded',
    }
    data = {class="hl-string">'grant_type': class="hl-string">'client_credentials'}
    try:
        response = requests.post(TOKEN_URL, headers=headers, data=data)
        response.raise_for_status()
        return response.json().get(class="hl-string">'access_token')
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error getting access token: {e}")
        return None

def create_report_job(token):
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}',
        class="hl-string">'apiKey': API_KEY,
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    report_payload = {
        class="hl-string">"name": class="hl-string">"ProcessMind Requisition Extraction",
        class="hl-string">"viewTemplateName": class="hl-string">"RequisitionFactSystemView",
        class="hl-string">"outputFormat": class="hl-string">"CSV",
        class="hl-string">"filters": {
            class="hl-string">"creationDate": {
                class="hl-string">"from": START_DATE,
                class="hl-string">"to": END_DATE
            }
        },
        class="hl-string">"select": [
            class="hl-string">"RequisitionId", class="hl-string">"StatusString", class="hl-string">"SubmitDate", class="hl-string">"ApprovedState.TimeUpdated",
            class="hl-string">"DeniedState.TimeUpdated", class="hl-string">"SourcingState.TimeUpdated", class="hl-string">"ClosedState.TimeUpdated",
            class="hl-string">"WithdrawnState.TimeUpdated", class="hl-string">"Requester.Name", class="hl-string">"Requester.Department",
            class="hl-string">"TotalCost.Amount", class="hl-string">"LineItems.Category.Name", class="hl-string">"IsUrgent", class="hl-string">"ApprovalFlow.Name",
            class="hl-string">"RequisitionVersion", class="hl-string">"TimeCreated", class="hl-string">"LineItems.OrderedState.TimeUpdated", class="hl-string">"POInfo.POId"
        ]
    }
    try:
        response = requests.post(fclass="hl-string">"{BASE_URL}jobs", headers=headers, json=report_payload)
        response.raise_for_status()
        return response.json().get(class="hl-string">'jobId')
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error creating report job: {e}")
        return None

def poll_job_status(token, job_id):
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}', class="hl-string">'apiKey': API_KEY}
    while True:
        try:
            response = requests.get(fclass="hl-string">"{BASE_URL}jobs('{job_id}')", headers=headers)
            response.raise_for_status()
            status = response.json().get(class="hl-string">'status')
            print(fclass="hl-string">"Current job status: {status}")
            if status in [class="hl-string">'COMPLETED', class="hl-string">'FAILED', class="hl-string">'CANCELLED']:
                return status
            time.sleep(60) class=class="hl-string">"hl-comment"># Wait 60 seconds before polling again
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error polling job status: {e}")
            return class="hl-string">'FAILED'

def download_report(token, job_id):
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}', class="hl-string">'apiKey': API_KEY}
    try:
        response = requests.get(fclass="hl-string">"{BASE_URL}jobs('{job_id}')/result", headers=headers, stream=True)
        response.raise_for_status()
        return response.content
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error downloading report: {e}")
        return None

def process_data(zip_content):
    try:
        with zipfile.ZipFile(io.BytesIO(zip_content)) as z:
            class=class="hl-string">"hl-comment"># Assuming the first file in the zip is the CSV we need
            csv_filename = z.namelist()[0]
            with z.open(csv_filename) as f:
                df = pd.read_csv(f)
    except Exception as e:
        print(fclass="hl-string">"Error reading zipped CSV: {e}")
        return pd.DataFrame()

    class=class="hl-string">"hl-comment"># Rename columns for clarity
    df.rename(columns={
        class="hl-string">'RequisitionId': class="hl-string">'PurchaseRequisitionId',
        class="hl-string">'TimeCreated': class="hl-string">'Timestamp_Created',
        class="hl-string">'SubmitDate': class="hl-string">'Timestamp_Submitted',
        class="hl-string">'ApprovedState.TimeUpdated': class="hl-string">'Timestamp_Approved',
        class="hl-string">'DeniedState.TimeUpdated': class="hl-string">'Timestamp_Denied',
        class="hl-string">'SourcingState.TimeUpdated': class="hl-string">'Timestamp_SentToSourcing',
        class="hl-string">'ClosedState.TimeUpdated': class="hl-string">'Timestamp_Closed',
        class="hl-string">'WithdrawnState.TimeUpdated': class="hl-string">'Timestamp_Withdrawn',
        class="hl-string">'LineItems.OrderedState.TimeUpdated': class="hl-string">'Timestamp_LineItemOrdered',
        class="hl-string">'POInfo.POId': class="hl-string">'POId',
        class="hl-string">'Requester.Name': class="hl-string">'EventUser',
        class="hl-string">'Requester.Department': class="hl-string">'RequesterDepartment',
        class="hl-string">'TotalCost.Amount': class="hl-string">'TotalRequisitionAmount',
        class="hl-string">'LineItems.Category.Name': class="hl-string">'ItemCategory',
        class="hl-string">'IsUrgent': class="hl-string">'UrgencyLevel',
        class="hl-string">'ApprovalFlow.Name': class="hl-string">'ApprovalWorkflowPath',
        class="hl-string">'StatusString': class="hl-string">'RequisitionStatus'
    }, inplace=True)
    
    class=class="hl-string">"hl-comment"># Create a base dataframe for melting
    id_vars = [
        class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventUser', class="hl-string">'RequesterDepartment', class="hl-string">'TotalRequisitionAmount',
        class="hl-string">'ItemCategory', class="hl-string">'UrgencyLevel', class="hl-string">'ApprovalWorkflowPath', class="hl-string">'RequisitionStatus', class="hl-string">'RequisitionVersion', class="hl-string">'POId'
    ]
    
    timestamp_cols = [col for col in df.columns if col.startswith(class="hl-string">'Timestamp_')]
    
    class=class="hl-string">"hl-comment"># Melt the dataframe to turn timestamp columns into rows
    event_log = pd.melt(df, id_vars=id_vars, value_vars=timestamp_cols, var_name=class="hl-string">'ActivityName', value_name=class="hl-string">'EventTimestamp')
    
    class=class="hl-string">"hl-comment"># Clean up and format
    event_log.dropna(subset=[class="hl-string">'EventTimestamp'], inplace=True)
    event_log[class="hl-string">'ActivityName'] = event_log[class="hl-string">'ActivityName'].str.replace(class="hl-string">'Timestamp_', class="hl-string">'Requisition ')
    event_log[class="hl-string">'EventTimestamp'] = pd.to_datetime(event_log[class="hl-string">'EventTimestamp'])

    class=class="hl-string">"hl-comment"># --- Handle specific/derived activities ---
    class=class="hl-string">"hl-comment"># Requisition Amended
    amended_df = df[df[class="hl-string">'RequisitionVersion'] > 1].copy()
    if not amended_df.empty:
        amended_df[class="hl-string">'ActivityName'] = class="hl-string">'Requisition Amended'
        amended_df[class="hl-string">'EventTimestamp'] = pd.to_datetime(amended_df[class="hl-string">'Timestamp_Submitted'])
        event_log = pd.concat([event_log, amended_df[event_log.columns]], ignore_index=True)

    class=class="hl-string">"hl-comment"># Purchase Order Created (use the timestamp of the first line item ordered as a proxy)
    po_created_df = df[df[class="hl-string">'POId'].notna() & df[class="hl-string">'Timestamp_LineItemOrdered'].notna()].copy()
    if not po_created_df.empty:
        po_created_df[class="hl-string">'ActivityName'] = class="hl-string">'Purchase Order Created'
        po_created_df[class="hl-string">'EventTimestamp'] = pd.to_datetime(po_created_df[class="hl-string">'Timestamp_LineItemOrdered'])
        event_log = pd.concat([event_log, po_created_df[event_log.columns]], ignore_index=True)
    
    class=class="hl-string">"hl-comment"># Placeholder for Approval Steps - requires parsing ApprovalRecords not included in this basic script
    class=class="hl-string">"hl-comment"># For now, we only have the final class="hl-string">'Approved' status. This logic can be expanded.
    class=class="hl-string">"hl-comment"># Creating dummy class="hl-string">'Approval Step Started/Approved' for demonstration.
    approval_df = df[df[class="hl-string">'Timestamp_Approved'].notna()].copy()
    if not approval_df.empty:
        approval_started = approval_df.copy()
        approval_started[class="hl-string">'ActivityName'] = class="hl-string">'Approval Step Started'
        class=class="hl-string">"hl-comment"># Approximate start time as submit time
        approval_started[class="hl-string">'EventTimestamp'] = pd.to_datetime(approval_started[class="hl-string">'Timestamp_Submitted'])
        
        approval_approved = approval_df.copy()
        approval_approved[class="hl-string">'ActivityName'] = class="hl-string">'Approval Step Approved'
        approval_approved[class="hl-string">'EventTimestamp'] = pd.to_datetime(approval_approved[class="hl-string">'Timestamp_Approved'])
        approval_approved[class="hl-string">'RejectionReason'] = None class=class="hl-string">"hl-comment"># Add column for consistency
        
        event_log = pd.concat([event_log, approval_started[event_log.columns], approval_approved[event_log.columns.tolist() + [class="hl-string">'RejectionReason']]], ignore_index=True)

    class=class="hl-string">"hl-comment"># Add placeholder for RejectionReason, as it's not directly in this view
    if class="hl-string">'RejectionReason' not in event_log.columns:
        event_log[class="hl-string">'RejectionReason'] = None

    class=class="hl-string">"hl-comment"># Final sorting and cleanup
    event_log = event_log.sort_values(by=[class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventTimestamp']).reset_index(drop=True)
    
    class=class="hl-string">"hl-comment"># Rename class="hl-string">'Requisition LineItemOrdered' to class="hl-string">'Requisition Line Item Ordered'
    event_log[class="hl-string">'ActivityName'] = event_log[class="hl-string">'ActivityName'].replace({class="hl-string">'Requisition LineItemOrdered': class="hl-string">'Requisition Line Item Ordered'})

    class=class="hl-string">"hl-comment"># Final column selection
    final_columns = [
        class="hl-string">'PurchaseRequisitionId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventUser',
        class="hl-string">'RequesterDepartment', class="hl-string">'TotalRequisitionAmount', class="hl-string">'ItemCategory', class="hl-string">'UrgencyLevel',
        class="hl-string">'ApprovalWorkflowPath', class="hl-string">'RejectionReason', class="hl-string">'RequisitionStatus'
    ]
    event_log = event_log[final_columns]

    return event_log

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

調達から支払いまで - 申請データテンプレート

調達から支払いまで - 申請データテンプレート

購買から支払いまで - 購買依頼属性

購買から支払いまで - 購買依頼アクティビティ

抽出ガイド

SAP Ariba分析レポートのCSV/Excelエクスポート

ステップ

設定

a クエリ例 config

オペレーショナルレポーティングAPIによるPythonスクリプト抽出

ステップ

設定

a クエリ例 python

今すぐ始めますか？

遅延をなくす: 購買から支払いまで（P2P）の購買依頼プロセスを最適化する

調達から支払いまで - 申請データテンプレート

調達から支払いまで - 申請データテンプレート

購買から支払いまで - 購買依頼属性

購買から支払いまで - 購買依頼アクティビティ

抽出ガイド

SAP Ariba分析レポートのCSV/Excelエクスポート

ステップ

設定

a クエリ例 config

オペレーショナルレポーティングAPIによるPythonスクリプト抽出

ステップ

設定

a クエリ例 python

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

今すぐ始めますか？

遅延をなくす: 購買から支払いまで（P2P）の購買依頼プロセスを最適化する