調達から支払いまで - 申請データテンプレート
SAP S/4HANA
調達から支払いまで - 申請データテンプレート
- 詳細分析のために収集すべき推奨属性
- プロセスディスカバリで追跡すべき主要な活動
- SAP S/4HANAからのデータ抽出に関するガイダンス
購買から支払いまで - 購買依頼属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 購入依頼プロセスの特定の時点で発生したビジネスアクティビティの名称です。 | ||
| 説明 「アクティビティ名」は、購入依頼のライフサイクル内で発生した特定のイベントやタスクを示します。これらは変更伝票やワークフロー履歴などのシステムログから抽出され、「依頼作成」「承認ステップ開始」「購買発注作成」といったプロセスの重要な節目を表します。 これらのアクティビティを分析することで、プロセスフローの可視化、ボトルネックの特定、各段階での所要時間の測定が可能になります。「依頼修正」や「依頼却下」といったアクティビティの順序や頻度を把握することは、プロセスの非効率性や改善の余地を見出すために不可欠です。 その重要性 プロセスにおけるステップを定義し、プロセス図の基盤を形成し、プロセスフロー、バリエーション、およびボトルネックの分析を可能にします。 取得元 これは派生属性であり、通常、変更伝票テーブル（CDHDR、CDPOS）やワークフローログ（SWWLOGHISTなど）のデータを解釈して構築されます。 例 採用申請作成済み承認ステップ完了依頼書承認済み発注作成済み | |||
| イベント日時 EventTime | 特定の`アクティビティ`が発生した正確な`日付`と`時間`です。 | ||
| 説明 イベントタイムは、活動が発生した時点を記録するタイムスタンプです。このデータは、ケース内のイベントを時系列で順序付けるために不可欠であり、プロセスマイニングにおけるすべての期間とパフォーマンス計算の基礎となります。例えば、「購買依頼提出済み」イベントと「購買依頼承認済み」イベント間の時間差が承認サイクルタイムを決定します。 正確なタイムスタンプは、プロセスパフォーマンスの分析、遅延の特定、およびサービスレベル契約への遵守状況の監視に不可欠です。この属性により、サイクルタイムを視覚化し、停滞している購買依頼を追跡し、異なる期間でのパフォーマンスを比較するダッシュボードが可能になります。 その重要性 このタイムスタンプは、イベントの順序付け、サイクルタイムの計算、プロセスパフォーマンスとボトルネックの分析に不可欠です。 取得元 タイムスタンプは通常、変更伝票ヘッダー（CDHDR-UDATE、CDHDR-UTIME）またはワークフローイベントログから取得されます。 例 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| 購買依頼書ID PurchaseRequisitionId | 購買依頼文書の一意な識別子。 | ||
| 説明 「購入依頼ID」は、SAP S/4HANA内で物品やサービスの各リクエストを一意に識別する主キーです。これは中心となる「ケース識別子」として機能し、作成から最終状態（承認、却下、購買発注への変換など）に至るまでの、特定の購入依頼に関連するすべてのアクティビティや変更を紐付けます。 プロセスマイニングにおいて、この属性は各購入依頼のエンドツーエンドのライフサイクルを再構成するための基盤となります。関連するすべてのイベントを単一の購入依頼IDの下にグループ化することで、分析担当者はサイクルタイムを正確に測定し、ステータスの変化を追跡し、承認プロセスで取り得るさまざまなルート（バリアント）を分析できます。 その重要性 関連するすべてのプロセスステップを繋ぎ、購入依頼のライフサイクルを完全かつ一貫した形で把握することを可能にする、不可欠なケース識別子です。 取得元 この 例 100178901001789110017892 | |||
| ユーザー`ID` UserId | 購買依頼を作成した、または特定の`アクティビティ`を実行したユーザーの識別子です。 | ||
| 説明 「ユーザーID」は、購入依頼のライフサイクルにおける特定のイベントを担当した従業員またはシステムユーザーを特定します。これには、依頼を作成した人、承認したマネージャー、修正を行った担当者などが含まれます。自動化されたステップの場合、システムまたはバッチユーザーのIDになることがあります。 ユーザーID別に分析することで、ユーザー固有の行動、負荷分散、パフォーマンスを把握できます。これは、トレーニングの必要性の特定、優秀な担当者の評価、プロセス内の責任の明確化に役立ちます。また、ユーザーマスターデータと組み合わせることで、部門別のパフォーマンス分析も可能になります。 その重要性 ユーザーのパフォーマンス、ワークロードの分散、プロセスコンプライアンスの分析を可能にします。トレーニングの機会やリソースのボトルネックを特定する上で不可欠です。 取得元 作成者の場合はEBAN-ERNAMにあります。その後の変更についてはCDHDR-USERNAMEに、承認についてはワークフローログにあります。 例 JSMITHRROEWF-BATCH | |||
| 依頼種別 RequisitionType | 購買依頼を分類するコードで、例えば標準品目、サービス、設備投資などのカテゴリを示します。 | ||
| 説明 「購入依頼タイプ」（SAPでは「伝票タイプ」）は、購入依頼を分類する重要な設定項目です。タイプによって、異なる承認ワークフローが起動されたり、項目の設定が異なったりします。また、標準在庫品、外部サービス、資産購入など、異なるビジネス目的で使用されます。 購入依頼タイプに基づいてプロセスを分析することで、組織はさまざまな種類のリクエストがどのように処理されているかを把握できます。カテゴリーごとのパフォーマンス、サイクルタイム、承認ルートを比較できるため、特定の依頼タイプの効率の良し悪しが明らかになり、プロセス改善のカスタマイズに役立ちます。 その重要性 購買依頼を分類することで比較分析を可能にし、異なる種類の依頼が異なるプロセスフロー、ボトルネック、またはサイクルタイムを持つかどうかを理解するのに役立ちます。 取得元 これは伝票タイプフィールドであり、テーブルEBANの項目BSARTにあります。 例 NB`FO`RV | |||
| 承認者ID ApproverId | 承認または却下`ステップ`を実行したユーザーの識別子です。 | ||
| 説明 「承認者ID」は、承認または却下のアクティビティを完了したユーザーを特定するものです。これは、一般的な「ユーザーID」とは異なり、承認ワークフロー内の意思決定者にのみ焦点を当てています。この情報を取得することは、承認プロセスを詳細に分析する上で非常に重要です。 この属性により、承認に時間がかかっている担当者や、頻繁に却下を行う担当者の特定など、承認行動の分析が可能になります。これは、承認ステップのサイクルタイムやワークフローのボトルネック分析に特化したダッシュボードの基礎となり、遅延の原因となっている特定の個人やロール（役割）をピンポイントで特定するのに役立ちます。 その重要性 承認ステップにおける特定の意思決定者を特定し、個人または役割ごとの承認サイクルタイムとボトルネックの詳細な分析を可能にします。 取得元 この情報は通常、SWW_WI2OBJやSWWLOGHISTなどのSAPビジネスワークフローテーブルから抽出され、ワークアイテムと完了したユーザーを紐付けます。 例 MJOHNSONCWILLIAMSLBLACK | |||
| 購買依頼ステータス RequisitionStatus | 購買依頼の現在の処理または承認`ステータス`です。 | ||
| 説明 「購入依頼ステータス」は、ライフサイクル内での購入依頼の現在の状態を示します。SAPでは通常、これは「承認インジケータ」で表され、依頼がブロックされているか、承認中か、一部承認済みか、あるいは完全に承認済みかを示します。このステータスは、依頼がワークフローを進むにつれて変化します。 ステータスの推移を追跡することは、プロセスフローを理解するための基本です。これにより、購入依頼がどこで、どのくらいの期間滞留しているかを特定できます。ステータス間の遷移を分析することで、承認プロセスとそのバリエーションを詳細に把握できます。 その重要性 購買依頼の現在の状態を示します。これは、進捗状況の追跡、ボトルネックの特定、およびプロセスフローの分析にとって重要です。 取得元 リリース 例 B1S | |||
| 購買依頼金額 RequisitionAmount | 購買申請の合計金額です。 | ||
| 説明 「購入依頼金額」は、依頼された物品やサービスの推定総コストを表します。この値は多くの場合、承認ワークフローの複雑さや長さを決定する主要な要因となり、高額な依頼ほど通常は多くの承認階層が必要になります。 この属性を分析することで、金額に基づいたプロセスのセグメンテーション（層別化）が可能になります。「高額な依頼は承認に時間がかかるのか？」や「頻繁に却下される依頼の金額帯は？」といった問いに答えるのに役立ちます。プロセスの非効率性がもたらす財務的影響を理解するための重要な指標です。 その重要性 財務上の影響に基づいてプロセスをセグメント化するのに役立ち、多くの場合、承認の複雑さやサイクルタイムと相関します。価値ベースのプロセス分析には不可欠です。 取得元 合計金額はテーブルEBANの項目GFWERTにあります。明細レベルの金額はEBAN-PREISにあります。 例 1500.0075000.50250.75 | |||
| 部署 Department | 購入依頼の費用が計上される部門または原価センターです。 | ||
| 説明 「部門」属性（SAPでは通常「原価センター」で表されます）は、購入を依頼したビジネスユニットを特定します。これは、購入依頼の明細レベルで割り当てられる、財務および組織上の重要な情報です。 プロセスマイニングにおいて、この属性は部門別のパフォーマンス分析に欠かせません。部門間でサイクルタイム、修正率、却下率などの主要メトリクスを比較するダッシュボードを実現します。これにより、優れた慣行（ベストプラクティス）を持つ部門を特定して他部署へ展開したり、追加のトレーニングやプロセス支援が必要な部門を見極めたりするのに役立ちます。 その重要性 ビジネスユニット間のパフォーマンス比較を可能にし、サイクルタイムや却下率のばらつきを浮き彫りにすることで、ベストプラクティスと改善領域を特定します。 取得元 これは原価センターであり、通常、勘定設定テーブルEBKNの項目KOSTLにあります。 例 FIN-1001IT-2005MKT-3010 | |||
| ソースシステム SourceSystem | データが抽出された特定のSAP S/4HANAインスタンスを識別します。 | ||
| 説明 「ソースシステム」属性は、プロセスデータが生成された元のシステムを示します。開発用、品質保証用、本番用など複数のSAPインスタンスを運用している組織や、地域ごとにシステムを分けている組織にとって、このフィールドはデータガバナンスとコンテキストの維持に不可欠です。 異なるソースからのデータを確実に区別することで、誤った集計を防ぎ、システム固有の分析を可能にします。データの系統（データリネージ）を維持し、プロセスデータの追跡可能性（トレーサビリティ）を確保するために必須の属性です。 その重要性 特に複数のシステムが存在する環境において、データの出所とガバナンスに関する不可欠なコンテキストを提供し、データトレーサビリティを確保します。 取得元 これは通常、SAPシステムID（SID）であり、システム変数や設定テーブルから取得できます。 例 S4PECCS4H_PROD_01 | |||
| 最終データ更新 LastDataUpdate | このレコードのデータがソースシステムから最後に更新された日時を示すタイムスタンプ。 | ||
| 説明 この属性は、ソースシステムからの最新のデータ抽出または更新の日時を記録します。これは、分析対象データの鮮度を理解するための重要なメタデータです。分析担当者やビジネスユーザーは、このタイムスタンプを頼りに、プロセスデータが最新の運用状況を反映しているかどうかを判断します。 いかなるプロセス分析においても、データの鮮度を知ることは、情報に基づいた意思決定を行うための基本です。この属性は、ユーザーの期待値を管理し、特定の分析に必要な最新のデータに基づいて結論が導き出されていることを保証するのに役立ちます。 その重要性 データの鮮度を示します。これは、分析を信頼し、タイムリーなビジネス上の意思決定を行う上で非常に重要です。 取得元 この 例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| 処理時間 ProcessingTime | 特定の活動に費やされた時間の長さ。 | ||
| 説明 処理時間とは、単一の活動を完了するのにかかった時間を測定します。これはイベントの終了時刻と開始時刻の差として計算されます。SAPの多くのイベントでは、開始時刻と終了時刻が同じであるため、処理時間はゼロになります。しかし、承認ステップでは、承認者がタスクに費やした時間を表すことができます。 この計算された指標は、異なるプロセスステップに関わる労力を理解するのに役立ちます。ケースが待機している時間（待機時間）と実際に作業されている時間（処理時間）を区別するのに役立ち、プロセスパフォーマンスのより微妙な視点を提供します。 その重要性 活動のアクティブな作業時間を測定し、作業に費やされた時間と待機に費やされた時間を区別するのに役立ちます。これはリソース分析にとって重要です。 取得元 これは計算属性であり、通常はイベントログ内の各イベントの終了時間（EndTime）から開始時間（StartTime）を引いて算出されます。 例 PT15MPT2H30MP1D | |||
| 却下理由 RejectionReason | 購買依頼が却下された際に提供される`理由`です。 | ||
| 説明 「却下理由」は、承認者がなぜ購入依頼を却下したのかを説明するものです。理由には、予算超過、情報の誤り、ポリシー違反、重複依頼などが含まれます。この情報は、プロセス上の失敗の原因を理解するための重要なコンテキストとなります。 却下理由を分析することで、プロセスの非効率性や手戻りの根本原因を特定できます。例えば「原価センターの誤り」が一般的な理由であれば、ユーザー教育の強化やシステムでの入力チェック（バリデーション）の必要性が示唆されます。この属性は「購入依頼却下分析」ダッシュボードの鍵となり、的を絞ったプロセス改善に不可欠です。 その重要性 プロセス障害の根本原因を提供し、手戻りを減らし、購買依頼の初回正答率を高めるための的を絞った改善を可能にします。 取得元 多くの場合、これは標準フィールドではありません。ワークフローコンテナの要素、購入依頼に関連付けられた長テキスト、またはカスタムフィールドに記録されている場合があります。 例 予算超過不正確な仕入先重複`申請` | |||
| 必要期日 RequiredByDate | 依頼者が要求された物品やサービスを必要とする日付です。 | ||
| 説明 「希望納期」（SAPでは「納入日付」）は、購入依頼の明細に含まれる物品やサービスが必要とされる日付を指定します。この日付は依頼者によって設定され、調達プロセス全体の目標となります。 この属性は、「購入依頼の適時完了率」KPIを算出するために不可欠です。希望納期と最終承認日または購買発注作成日を比較することで、組織が社内のサービスレベルやビジネスニーズをどの程度満たせているかを測定できます。この期日を過ぎた購入依頼を分析することで、調達プロセスにおける構造的な遅延を浮き彫りにできます。 その重要性 依頼の目標完了日を定義し、納期遵守率と内部サービスレベルへの準拠を測定できるようにします。 取得元 これは納入日付であり、テーブルEBANの明細レベル（項目LFDAT）にあります。 例 2023-11-152023-12-012024-01-20 | |||
| 手戻り IsRework | 活動が手戻りであるかどうかを示すフラグ。例えば、提出後の修正などが該当します。 | ||
| 説明 「手戻りである」は、付加価値のない、または反復的な作業を表す活動を特定する計算されたブールフラグです。このプロセスでの一般的な例は、購買依頼がすでに承認のために提出された後に発生する「購買依頼変更」活動であり、これにより承認プロセスが再開されます。 この属性は、プロセスにおける手戻りの量と、それが全体のサイクルタイムに与える影響を定量化するために不可欠です。購買依頼修正および手戻り率のダッシュボードは、このフラグに依存してプロセスの非効率性を浮き彫りにします。手戻りの削減は、時間の節約と労力の削減に直接つながるため、プロセス改善イニシアチブの主要な目標となることがよくあります。 その重要性 無駄な労力や繰り返しを表す活動にフラグを立て、手戻りの量とそれがプロセス効率に与える影響を直接測定できるようにします。 取得元 これは計算属性です。通常、最初の「承認依頼済み」アクティビティの後に発生した「依頼修正」アクティビティを「手戻り」としてフラグを立てるロジックになります。 例 truefalse | |||
| 承認ステップ名 ApprovalStepName | ワークフローにおける承認ステップの具体的な名称または説明です。 | ||
| 説明 「承認ステップ名」は、「マネージャー承認」や「財務責任者承認」など、承認ワークフロー内の特定の段階を分かりやすく説明したものです。これは、単なる「承認ステップ完了」という汎用的なアクティビティ名よりも詳細な情報を提供します。 この属性は、「承認ステップサイクルタイム」や「ワークフローボトルネック分析」のダッシュボードにおいて極めて重要です。承認プロセスを詳細に把握できるため、どの承認段階で大きな遅延が発生しているか、どこに業務が滞留しているかを正確に特定できます。このレベルの詳細データがあることで、承認フローを効率化するための的確な対策を講じることが可能になります。 その重要性 承認ステージに関する詳細な情報を提供し、多段階承認ワークフロー内のボトルネックを正確に特定できるようにします。 取得元 この情報はワークフロータスクの説明から派生したもので、ワークフローログをT528Tなどのタスク定義テーブルにリンクさせることで取得できます。 例 マネージャー承認部長承認財務VP承認 | |||
| 発注書番号 PurchaseOrderNumber | 購買依頼から作成された発注書の`番号`です。 | ||
| 説明 「購買発注番号」は、承認された購入依頼から作成された正式な購買伝票の識別子です。購買発注の作成は、多くの場合、購入依頼プロセスの最終的な成功成果であり、依頼がサプライヤーへの正式な注文に変換されたことを意味します。 この属性は、「購入依頼から購買発注までのリードタイム」KPIや全体の転換率を測定するために不可欠です。購入依頼プロセスと後続の調達プロセスをリンクさせ、P2P（調達から支払い）サイクル全体の包括的なエンドツーエンドの視点を提供します。 その重要性 購買依頼を後続の調達文書にリンクし、依頼からPOへの変換率とリードタイムの測定を可能にします。 取得元 購買依頼明細からPOが作成されると、テーブルEBANのフィールドEBELNに記載されます。 例 450001789045000178914500017892 | |||
| 終了日時 EndTime | 特定の`アクティビティ`が完了した正確な`日付`と`時刻`です。 | ||
| 説明 EndTimeは、活動が完了した時点を記録するタイムスタンプです。多くのシステム生成イベントは瞬間的（StartTimeとEndTimeが同じ）ですが、承認などの人間が関わるタスクには明確な開始と終了がある場合があります。このタイムスタンプは、その作業の完了を示します。 EndTimeが個別に存在することで、実際の処理時間とアイドル待機時間をより正確に測定できます。これはStartTimeと組み合わせてProcessingTime指標を計算するために使用されます。この詳細なレベルは、手動タスクのリソース利用率と効率の分析を強化します。 その重要性 活動の完了をマークし、アクティブ処理時間の計算を可能にし、タスク期間のより詳細なビューを提供します。 取得元 これは、ワークアイテムが作成された時間（StartTime）と完了した時間（EndTime）の両方を記録したワークフローログから取得されます。 例 2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z | |||
| 緊急度レベル UrgencyLevel | 購買依頼の緊急度を分類するもので、その処理優先順位に影響を与える可能性があります。 | ||
| 説明 「緊急度レベル」は、購入リクエストの優先順位を示します。標準の専用フィールドではありませんが、一部の組織では「所要量追跡番号」などのフィールドを使用してこの情報を取得しています。これにより、依頼者は迅速な処理が必要な重要なニーズにフラグを立てることができます。 緊急度の影響を分析することは、プロセスが重要なリクエストを効果的に優先順位付けできているかを評価するために重要です。「緊急度レベル影響分析」ダッシュボードはこの属性を使用して、緊急の依頼と標準的な依頼のサイクルタイムや承認率を比較し、優先処理が意図通りに機能しているかを確認するのに役立ちます。 その重要性 優先度の高い依頼に対するプロセスパフォーマンスの違いを分析し、緊急品目が実際に迅速に処理されているかを確認するのに役立ちます。 取得元 標準の緊急度フィールドはありません。一部の企業では、この目的で所要量追跡番号（EBAN-BEDAR）を使用しています。また、カスタムフィールドである場合もあります。 例 高中低 | |||
| 自動化 IsAutomated | 活動が人間ではなくシステムユーザーによって実行されたかどうかを示すフラグ。 | ||
| 説明 「自動実行フラグ」は、ワークフローアクションの「WF-BATCH」のように、システムまたはバッチユーザーによってアクティビティが実行された場合に「true」となる真偽値（boolean）です。これにより、プロセス内の手動ステップと自動ステップを区別できます。 この属性は、購入依頼プロセスにおける自動化レベルの測定や、「自動承認率」KPIの算出に不可欠です。自動ステップと手動ステップをフィルタリングして比較することで、分析担当者はそれぞれの効率性を評価し、処理時間や手作業の削減に向けたさらなる自動化の機会を特定できます。 その重要性 人間による活動とシステム主導の活動を区別します。これは、自動化率を測定し、手動タスクを自動化する機会を特定するための鍵となります。 取得元 これは派生属性であり、通常、イベントのユーザーIDが既知のシステムユーザーまたはバッチユーザーのリストに含まれているかどうかを確認するルールに基づいています。 例 truefalse | |||
| 通貨 Currency | 購買依頼金額の通貨コード。 | ||
| 説明 この属性は、購入依頼金額の通貨（USD、EUR、JPYなど）を指定します。特に複数の通貨を使用する多国籍企業において、「購入依頼金額」属性に必要なコンテキストを提供します。 正確な財務分析とレポート作成には、通貨の考慮が不可欠です。購入依頼の金額を集計または比較する際は、意味のある結果を得るためにすべての金額を共通の通貨に換算する必要があります。この属性は、そのような換算を行うための前提条件となります。 その重要性 購買依頼金額に関する不可欠なコンテキストを提供し、複数通貨環境での正確な財務分析と比較を可能にします。 取得元 これは 例 USDEURGBP | |||
購買から支払いまで - 購買依頼アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| 依頼書承認済み | 購買依頼の最終かつ完全な承認をマークし、購買オーダーへの変換を可能にします。このマイルストーンは、全体リリースステータスが最終承認状態に達したときに推測されます。 | ||
| その重要性 これは成功を示す重要な節目であり、サイクルタイム分析における一般的な終止点です。これは、依頼がすべてのチェックを通過し、調達部門が処理できる状態になったことを意味します。 取得元 EBANテーブルのステータス変更、特に全体リリースインジケータ（FRGZU）または処理ステータス（PROCSTAT）が最終的な「承認済み」値に更新された場合に推測されます。 取得 最終リリースコードが適用された、または購買依頼全体のステータスが「承認済み」に変更されたタイムスタンプを特定します。 イベントタイプ inferred | |||
| 承認ステップ完了 | 承認者が購買依頼に対して肯定的なアクションを取り、多段階承認ワークフローの1ステップを完了した場合に発生します。これは、購買依頼のリリースステータスの変更から推測されます。 | ||
| その重要性 このアクティビティにより承認ワークフローの詳細な分析が可能になり、個々のステップにかかった時間を測定できます。効率的な承認者と、プロセスのボトルネックとなっている箇所を特定するのに役立ちます。 取得元 EBANテーブルの変更文書（CDHDR/CDPOS）から推測されます。特定のコードに対するリリースコードステータス（例：フィールドFRGZU）が未リリースからリリース済みに変更された場合、このイベントを示します。 取得 戦略で定義された各承認コードについて、EBANの承認ステータスフィールドへの変更を追跡します。 イベントタイプ inferred | |||
| 採用申請作成済み | システムにおける購買依頼文書の初回作成をマークします。このイベントは、ユーザーが新しい購買依頼を初めて保存したときに明示的に取得され、作成タイムスタンプが記録されます。 | ||
| その重要性 このアクティビティは、購入依頼のライフサイクル分析における主要な開始点となります。最初のニーズの特定から、最終承認または購買発注への変換に至るまでの、エンドツーエンドのサイクルタイムを測定するために不可欠です。 取得元 これはEBANテーブルから取得される明示的なイベントで、特定の購入依頼番号（BANFN）に対する登録日付（ERDAT）と登録時間（ERZEIT）のフィールドを使用します。 取得 各購入依頼（BANFN）について、EBANテーブルの登録タイムスタンプフィールド（ERDAT、ERZEIT）を使用します。 イベントタイプ explicit | |||
| 発注作成済み | 購買依頼品目を参照する購買オーダーが生成されたことを示します。これは、購買依頼を後続の調達文書にリンクする明示的なシステムイベントです。 | ||
| その重要性 これは重要な節目であり、購入依頼プロセスにおける成功成果です。購入依頼の承認から購買発注の作成までの時間は、調達の効率を測定するための重要なKPIです。 取得元 購買オーダー明細が作成されたときに明示的に記録されます。リンクはEKPOテーブル（購買オーダー明細）に保存され、そこには元の購買依頼番号（BANFN）と明細番号（BNFPO）が含まれます。 取得 EKPOテーブルをEBANテーブルに購買依頼番号と明細で結合します。PO明細の作成日がイベントをマークします。 イベントタイプ explicit | |||
| 購買依頼クローズ済み | 購買依頼明細が完全に処理され、それ以上購買オーダーが作成できないと見なされることを示します。このステータスは通常、全数量がオーダーされると自動的に設定されます。 | ||
| その重要性 このアクティビティは、購入依頼明細のライフサイクルの最終的な成功完了を表します。これは、ビジネス上のニーズが調達発注に完全に変換されたことを裏付けるものです。 取得元 EBANテーブルから推測されます。これは、「完了」インジケータ（EBAKZ）が設定されたときに発生し、通常はPOでオーダーされた数量が購買依頼数量と等しい場合に発生します。 取得 変更文書を介してテーブルEBANで「完了」インジケータ（EBAKZ）が設定されるイベントを特定します。 イベントタイプ inferred | |||
| 購買依頼却下済み | 承認者による購買依頼の最終的な却下を表し、プロセスを停止させます。これは、却下を示す特定のステータス更新によって捕捉されます。 | ||
| その重要性 このアクティビティは、プロセスの失敗を示す重要な終止点です。却下の頻度、理由、およびプロセス内のどの時点で発生したかを分析することで、ポリシー遵守、予算、または依頼内容の質に関する問題を特定できます。 取得元 EBANテーブルのステータス変更から推測されます。処理ステータス（PROCSTAT）またはリリースインジケータが明示的に「却下済み」を意味する値に設定されている場合です。 取得 変更文書を介してEBANの全体ステータスが「却下済み」状態に更新されたタイムスタンプを特定します。 イベントタイプ inferred | |||
| 供給元割り当て済み | バイヤーが承認された購買依頼品目に特定の仕入先、契約、または情報レコードを割り当てるアクションを表します。これは、購買オーダー作成のための購買依頼準備の重要なステップです。 | ||
| その重要性 このアクティビティは承認から発注までの橋渡しをします。供給元の割り当てにかかる時間を測定することで、購買担当者の負荷やソーシング（調達先選定）の効率における遅延を特定できます。 取得元 EBANテーブルの調達元関連フィールド（固定仕入先（LIFNR）、情報レコード（INFNR）、契約（KONNR）など）に値が入力された場合に推測されます。 取得 変更伝票を通じて、EBANテーブルのLIFNR、INFNR、またはKONNRといった項目の値の入力を追跡します。 イベントタイプ inferred | |||
| 承認ステップ開始 | 特定の承認者または承認グループからのアクションを購買依頼が待っていることを示します。これは、購買依頼のステータスが特定のリリースコードが保留中であることを示している場合に推測されます。 | ||
| その重要性 このアクティビティは、承認チェーン内のボトルネックを特定するために不可欠です。この状態の期間を分析することで、停滞している依頼や過負荷の承認者を特定できます。 取得元 EBANテーブルのリリースステータスフィールド（例：FRGZU）と基盤となるリリース戦略設定から推測されます。このイベントは、特定のリリースコードが次に処理される対象となったときに開始されます。 取得 ワークフローログまたはステータスフィールドに基づき、特定のリリースコードの承認が保留中の状態に購買依頼が移行した時点を特定します。 イベントタイプ inferred | |||
| 承認リセット | 承認ワークフロー全体がリセットされるイベントを表します。これは、購買依頼の大幅な修正などが原因で発生することが多く、承認プロセスが最初からやり直されることになります。 | ||
| その重要性 このアクティビティは、サイクルタイムに深刻な影響を与える大規模な手戻りを浮き彫りにします。承認リセットの原因を特定することは、プロセスを合理化し遅延を削減するための鍵となります。 取得元 EBANテーブルの変更文書（CDHDR/CDPOS）から推測されます。このイベントは、リリースステータスフィールド（FRGKZやFRGZUなど）が部分的または完全に設定された後にクリアされたときに検出されます。 取得 変更ログ内で、リリース済み状態から未リリース状態へのリリースステータスの変更を探します。 イベントタイプ inferred | |||
| 購買依頼変更済み | ユーザーが購買依頼の初回作成後に数量、価格、品目などの主要フィールドを変更した場合に発生します。このアクションはSAPの変更文書システムに明示的にログ記録されます。 | ||
| その重要性 修正を追跡することは、手戻りループとそのサイクルタイムへの影響を特定するために極めて重要です。修正の頻度が高い場合は、データ品質の問題や要件の変更を示唆しており、プロセス改善における重点領域となります。 取得元 SAP変更文書テーブル（CDHDRおよびCDPOS）に、EBANテーブルへの変更として明示的にログ記録されます。追跡対象フィールドへの各変更によりエントリが作成されます。 取得 オブジェクトクラスが購買依頼のBANFであるCDHDR/CDPOSから変更イベントを抽出します。 イベントタイプ explicit | |||
| 購買依頼承認申請済み | 依頼者が正式に購買依頼を提出し、承認ワークフローが開始される瞬間を表します。これは通常、購買依頼のリリース戦略が決定され、ステータスが「承認中」に変更されたときに推測されます。 | ||
| その重要性 これは、承認サイクルタイムKPIのカウントを開始する重要な節目です。作成から提出までの時間を分析することで、購入依頼の準備段階における遅延を明らかにできます。 取得元 EBANテーブルの変更文書（CDHDR/CDPOS）から推測されます。特に、リリース戦略フィールド（例：FRGST）が入力された場合や、全体ステータス（PROCSTAT）が承認中の状態を反映するように変更された場合です。 取得 承認ワークフローの開始、または「承認中」へのステータス変更を示す最初の変更文書エントリを特定します。 イベントタイプ inferred | |||
| 購買依頼撤回済み | 元の依頼者が、購買依頼が完全に処理される前にそれをキャンセルまたは削除した場合に発生します。これは通常、購買依頼明細に削除フラグを設定する明示的なアクションです。 | ||
| その重要性 取り下げを追跡することで、需要の変動やキャンセルの理由を把握できます。これは購入依頼の終止状態を表し、それ以上の処理を防止します。 取得元 EBANテーブルの削除インジケータ（LOEKZ）フィールドが購買依頼明細に対して設定されたときに明示的に取得されます。変更はCDHDR/CDPOSにログ記録されます。 取得 テーブルEBANの削除インジケータ（LOEKZ）が「L」に設定されるイベントを特定します。 イベントタイプ explicit | |||
抽出ガイド
ステップ
- 前提条件: 必要なCDSビューにアクセスするための適切な権限を持つユーザーがSAP S/4HANAにいることを確認してください。これには通常、S_TABU_NAMなどのオブジェクトに対する権限やデータ表示ツールへのアクセスが含まれます。
- システムアクセス方法の特定: SQLクエリを実行するために、SAP S/4HANAデータベースにどのように接続するかを決定します。一般的なツールには、SAP HANA Studio、ADT（ABAP Development Tools）を備えたEclipse IDE、またはSAP HANAデータベースクライアントを介して接続できるDBeaverなどのサードパーティSQLクライアントがあります。
- SQLクエリの確認: 提供されたSQLスクリプトに慣れてください。これは共通テーブル式（CTE）を使用して、異なるアクティビティのデータを収集し、それらを結合して統一されたイベントログを作成します。
- プレースホルダーのカスタマイズ: クエリ内のプレースホルダーを見つけて置き換えます。抽出期間の日付範囲（
[YYYY-MM-DD]形式）を設定し、組織に関連する会社コード（[Your Company Code]）を指定する必要があります。 - クエリの実行: カスタマイズされた完全なSQLクエリをSAP S/4HANAデータベースに対して実行します。データ量と選択した日付範囲によっては、このクエリの実行に時間がかかる場合があります。
- 初期データの確認: クエリが完了したら、出力の最初の数行を確認します。PurchaseRequisitionId、ActivityName、EventTimeなどのすべての列が期待どおりに表示され、データ形式が正しいことを確認してください。
- データ変換への対応: 提供されるクエリは、プロセスマイニング用の準備ができた形式でデータを出力するように設計されています。
CASTおよびCONCAT関数は、データ型の一貫性を確保するために使用されます。実行後に主要な変換は不要なはずです。 - イベントログのエクスポート: SQLクライアントから結果セット全体をCSVファイルにエクスポートします。文字化けを防ぐため、ファイルエンコーディングがUTF-8に設定されていることを確認してください。
- アップロードの準備: プロセスマイニングツールにアップロードする前に、CSVファイルに正しいヘッダー（
PurchaseRequisitionId、ActivityName、EventTimeなど）があり、EventTimeの日付と時刻形式がターゲットプラットフォームで一貫しておりサポートされていることを確認してください。 - ProcessMindへのアップロード: 最終的なCSVファイルをProcessMindプロジェクトにアップロードします。
PurchaseRequisitionIdをCase IDとして、ActivityNameをActivityとして、EventTimeをTimestampとしてマッピングしてプロジェクトを設定してください。
設定
- Core CDS Views: データ抽出では、主に申請データのコアに
I_PurchaseRequisitionAPI01を、変更履歴とステータス更新の追跡にI_ChangeDocumentとI_ChangeDocumentItemを、購買オーダーへのリンクにI_PurchaseOrderItemAPI01を使用します。 - Authorization: 実行ユーザーは、前述のCDSビューに対する読み取りアクセス権限が必要です。必要なロールと権限については、貴社のSAPセキュリティチームにご相談ください。
- Date Range Filtering: データ量を制限するため、申請の登録日（
CreationDate）に日付範囲フィルターを適用することが不可欠です。初回分析には3ヶ月から6ヶ月分のデータ範囲が推奨されます。 - Organizational Filtering: 適切な事業体のプロセスを分析するために、
CompanyCodeでデータをフィルタリングしてください。また、特定の調達プロセス（例：標準品目とサービス）に焦点を当てるために、PurchaseRequisitionTypeでフィルタリングすることも検討できます。 - Change Document Configuration: 「申請変更」などのアクティビティや様々な承認ステップの取得は、SAPシステム内の関連フィールドで変更文書ログが有効になっているかに依存します。これらのイベントが欠落している場合は、テーブルEBANのシステム設定を確認してください。
- Performance: 数百万件の申請がある非常に大規模なシステムの場合、このクエリを長期間実行するとシステムパフォーマンスに影響を与える可能性があります。オフピーク時または最近更新されたデータを持つ非本番環境での実行をご検討ください。
a クエリ例 sql
WITH REQUISITIONS AS (
SELECT
PurchaseRequisition,
PurchaseRequisitionType,
PurReqnDescription,
CreatedByUser,
CreationDate,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS CreationTimestamp,
SourceOfSupplyIsAssigned
FROM I_PurchaseRequisitionAPI01
WHERE CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
AND CompanyCode IN ('[Your Company Code]')
),
CHANGE_DOCS AS (
SELECT
ObjectValue AS PurchaseRequisition,
UserName,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS ChangeTimestamp,
FieldName,
ValueNew,
ValueOld
FROM I_ChangeDocument AS H
JOIN I_ChangeDocumentItem AS I
ON H.ChangeDocument = I.ChangeDocument
WHERE H.Objectclass = 'EINKBELEG'
AND H.CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
)
-- 1. Requisition Created
SELECT
R.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Created' AS "ActivityName",
R.CreationTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM REQUISITIONS AS R
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON R.PurchaseRequisition = I.PurchaseRequisition
UNION ALL
-- 2. Requisition Submitted For Approval & 5. Approval Step Started
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
CASE
WHEN C.ValueOld = ''
THEN 'Requisition Submitted For Approval'
ELSE 'Approval Step Started'
END AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R
ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew != ''
UNION ALL
-- 3. Requisition Amended
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Amended' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('MENGE', 'PREIS', 'MATNR', 'LIFNR', 'INFNR')
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 4. Approval Reset
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Reset' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueOld != '' AND C.ValueNew = ''
UNION ALL
-- 6. Approval Step Completed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Step Completed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew IN ('1', '2', '3', '4', '5', '6', '7') -- Adjust release codes as per your config
UNION ALL
-- 7. Requisition Approved
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Approved' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGKE' AND C.ValueNew = '2' -- Final release indicator '2' is common for approved
UNION ALL
-- 8. Requisition Rejected
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Rejected' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew = 'B' -- 'B' for Blocked/Rejected is a common setting
UNION ALL
-- 9. Requisition Withdrawn
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Withdrawn' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'LOEKZ' AND C.ValueNew = 'X'
UNION ALL
-- 10. Source of Supply Assigned
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Source of Supply Assigned' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('LIFNR', 'INFNR') AND C.ValueNew != ''
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 11. Purchase Order Created
SELECT DISTINCT
I.PurchaseRequisition AS "PurchaseRequisitionId",
'Purchase Order Created' AS "ActivityName",
CAST(CONCAT(H.PurchaseOrderDate, 'T', LPAD(H.CreationTime, 6, '0')) AS TIMESTAMP) AS "EventTime",
H.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.OrderPriceUnit * I.OrderQuantity AS "RequisitionAmount",
'PO Created' AS "RequisitionStatus"
FROM I_PurchaseOrderItemAPI01 AS I
JOIN I_PurchaseOrderAPI01 AS H
ON I.PurchaseOrder = H.PurchaseOrder
JOIN REQUISITIONS AS R
ON I.PurchaseRequisition = R.PurchaseRequisition
WHERE I.PurchaseRequisition IS NOT NULL AND I.PurchaseRequisition != ''
UNION ALL
-- 12. Requisition Closed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Closed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'EBAKZ' AND C.ValueNew = 'X'ステップ
- 前提条件: 必要なCDSビューにアクセスするための適切な権限を持つユーザーがSAP S/4HANAにいることを確認してください。これには通常、S_TABU_NAMなどのオブジェクトに対する権限やデータ表示ツールへのアクセスが含まれます。
- システムアクセス方法の特定: SQLクエリを実行するために、SAP S/4HANAデータベースにどのように接続するかを決定します。一般的なツールには、SAP HANA Studio、ADT（ABAP Development Tools）を備えたEclipse IDE、またはSAP HANAデータベースクライアントを介して接続できるDBeaverなどのサードパーティSQLクライアントがあります。
- SQLクエリの確認: 提供されたSQLスクリプトに慣れてください。これは共通テーブル式（CTE）を使用して、異なるアクティビティのデータを収集し、それらを結合して統一されたイベントログを作成します。
- プレースホルダーのカスタマイズ: クエリ内のプレースホルダーを見つけて置き換えます。抽出期間の日付範囲（
[YYYY-MM-DD]形式）を設定し、組織に関連する会社コード（[Your Company Code]）を指定する必要があります。 - クエリの実行: カスタマイズされた完全なSQLクエリをSAP S/4HANAデータベースに対して実行します。データ量と選択した日付範囲によっては、このクエリの実行に時間がかかる場合があります。
- 初期データの確認: クエリが完了したら、出力の最初の数行を確認します。PurchaseRequisitionId、ActivityName、EventTimeなどのすべての列が期待どおりに表示され、データ形式が正しいことを確認してください。
- データ変換への対応: 提供されるクエリは、プロセスマイニング用の準備ができた形式でデータを出力するように設計されています。
CASTおよびCONCAT関数は、データ型の一貫性を確保するために使用されます。実行後に主要な変換は不要なはずです。 - イベントログのエクスポート: SQLクライアントから結果セット全体をCSVファイルにエクスポートします。文字化けを防ぐため、ファイルエンコーディングがUTF-8に設定されていることを確認してください。
- アップロードの準備: プロセスマイニングツールにアップロードする前に、CSVファイルに正しいヘッダー（
PurchaseRequisitionId、ActivityName、EventTimeなど）があり、EventTimeの日付と時刻形式がターゲットプラットフォームで一貫しておりサポートされていることを確認してください。 - ProcessMindへのアップロード: 最終的なCSVファイルをProcessMindプロジェクトにアップロードします。
PurchaseRequisitionIdをCase IDとして、ActivityNameをActivityとして、EventTimeをTimestampとしてマッピングしてプロジェクトを設定してください。
設定
- Core CDS Views: データ抽出では、主に申請データのコアに
I_PurchaseRequisitionAPI01を、変更履歴とステータス更新の追跡にI_ChangeDocumentとI_ChangeDocumentItemを、購買オーダーへのリンクにI_PurchaseOrderItemAPI01を使用します。 - Authorization: 実行ユーザーは、前述のCDSビューに対する読み取りアクセス権限が必要です。必要なロールと権限については、貴社のSAPセキュリティチームにご相談ください。
- Date Range Filtering: データ量を制限するため、申請の登録日（
CreationDate）に日付範囲フィルターを適用することが不可欠です。初回分析には3ヶ月から6ヶ月分のデータ範囲が推奨されます。 - Organizational Filtering: 適切な事業体のプロセスを分析するために、
CompanyCodeでデータをフィルタリングしてください。また、特定の調達プロセス（例：標準品目とサービス）に焦点を当てるために、PurchaseRequisitionTypeでフィルタリングすることも検討できます。 - Change Document Configuration: 「申請変更」などのアクティビティや様々な承認ステップの取得は、SAPシステム内の関連フィールドで変更文書ログが有効になっているかに依存します。これらのイベントが欠落している場合は、テーブルEBANのシステム設定を確認してください。
- Performance: 数百万件の申請がある非常に大規模なシステムの場合、このクエリを長期間実行するとシステムパフォーマンスに影響を与える可能性があります。オフピーク時または最近更新されたデータを持つ非本番環境での実行をご検討ください。
a クエリ例 sql
WITH REQUISITIONS AS (
SELECT
PurchaseRequisition,
PurchaseRequisitionType,
PurReqnDescription,
CreatedByUser,
CreationDate,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS CreationTimestamp,
SourceOfSupplyIsAssigned
FROM I_PurchaseRequisitionAPI01
WHERE CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
AND CompanyCode IN ('[Your Company Code]')
),
CHANGE_DOCS AS (
SELECT
ObjectValue AS PurchaseRequisition,
UserName,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS ChangeTimestamp,
FieldName,
ValueNew,
ValueOld
FROM I_ChangeDocument AS H
JOIN I_ChangeDocumentItem AS I
ON H.ChangeDocument = I.ChangeDocument
WHERE H.Objectclass = 'EINKBELEG'
AND H.CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
)
-- 1. Requisition Created
SELECT
R.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Created' AS "ActivityName",
R.CreationTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM REQUISITIONS AS R
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON R.PurchaseRequisition = I.PurchaseRequisition
UNION ALL
-- 2. Requisition Submitted For Approval & 5. Approval Step Started
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
CASE
WHEN C.ValueOld = ''
THEN 'Requisition Submitted For Approval'
ELSE 'Approval Step Started'
END AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R
ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew != ''
UNION ALL
-- 3. Requisition Amended
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Amended' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('MENGE', 'PREIS', 'MATNR', 'LIFNR', 'INFNR')
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 4. Approval Reset
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Reset' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueOld != '' AND C.ValueNew = ''
UNION ALL
-- 6. Approval Step Completed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Step Completed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew IN ('1', '2', '3', '4', '5', '6', '7') -- Adjust release codes as per your config
UNION ALL
-- 7. Requisition Approved
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Approved' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGKE' AND C.ValueNew = '2' -- Final release indicator '2' is common for approved
UNION ALL
-- 8. Requisition Rejected
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Rejected' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew = 'B' -- 'B' for Blocked/Rejected is a common setting
UNION ALL
-- 9. Requisition Withdrawn
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Withdrawn' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'LOEKZ' AND C.ValueNew = 'X'
UNION ALL
-- 10. Source of Supply Assigned
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Source of Supply Assigned' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('LIFNR', 'INFNR') AND C.ValueNew != ''
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 11. Purchase Order Created
SELECT DISTINCT
I.PurchaseRequisition AS "PurchaseRequisitionId",
'Purchase Order Created' AS "ActivityName",
CAST(CONCAT(H.PurchaseOrderDate, 'T', LPAD(H.CreationTime, 6, '0')) AS TIMESTAMP) AS "EventTime",
H.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.OrderPriceUnit * I.OrderQuantity AS "RequisitionAmount",
'PO Created' AS "RequisitionStatus"
FROM I_PurchaseOrderItemAPI01 AS I
JOIN I_PurchaseOrderAPI01 AS H
ON I.PurchaseOrder = H.PurchaseOrder
JOIN REQUISITIONS AS R
ON I.PurchaseRequisition = R.PurchaseRequisition
WHERE I.PurchaseRequisition IS NOT NULL AND I.PurchaseRequisition != ''
UNION ALL
-- 12. Requisition Closed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Closed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'EBAKZ' AND C.ValueNew = 'X'