購買から支払いまで（P2P）の請求書処理データテンプレート

活動（Activity）属性は、請求書処理ワークフロー内の明確な段階またはアクションを表します。これらの活動は、文書作成、ステータス変更、承認、SAP変更ログに記録されたユーザーアクションなど、さまざまなシステムイベントから派生します。

活動の分析はプロセスマイニングの核です。これにより、プロセスマップの可視化、ボトルネック（例：「請求書承認依頼済み」後の長い待機時間）、手戻り作業（例：繰り返される「支払保留設定」と「支払保留解除」のサイクル）、およびコンプライアンス違反の特定が可能になります。活動の順序と頻度によって、実際の現状のプロセスフローが明らかになります。

プロセスマップのステップを定義し、プロセスフローの可視化、ボトルネックの発見、手戻りの特定を可能にします。

この属性は通常、トランザクションコード（SY-TCODE）、RBKPのようなテーブルのステータスフィールド（例：RBSTAT）、およびCDHDRとCDPOSテーブルからの変更イベントを含む複数のソースから導出されます。

イベントタイムは、ビジネスアクティビティが実行され、ソースシステムに記録された正確な瞬間を記録します。このタイムスタンプはプロセスの時系列的なバックボーンであり、各請求書のすべてのアクティビティを一貫したシーケンスに並べます。

分析において、イベントタイムはサイクルタイム、待機時間、アクティビティ間の処理時間など、すべての期間ベースのメトリックを計算するために不可欠です。「請求書のエンドツーエンドサイクルタイム」や「支払ブロック解決期間」のようなダッシュボードは、プロセス内の任意の2点間で経過した時間を測定するために必要なデータを提供することで機能します。正確なタイムスタンプは、遅延やパフォーマンスのボトルネックを特定するために極めて重要です。

このタイムスタンプは、イベントを正しく順序付けし、サイクルタイムやボトルネック期間など、すべてのパフォーマンス指標を計算するために不可欠です。

これは通常、変更伝票ヘッダーテーブルCDHDRからの変更日付（UDATE）と変更時刻（UTIME）を組み合わせることで導出されます。特定の作成イベントの場合、RBKPのようなテーブルからの作成日付と時刻（ERNAM, ERZET）となることがあります。

請求書番号は、請求書処理ジャーニーの一意のケース識別子として機能します。各番号は、仕入先から受け取った単一の請求書に対応し、データ入力から最終支払いまでのすべての関連活動を、一貫した単一のプロセスインスタンスの一部として追跡できるようにします。

プロセスマイニング分析において、この属性はすべての請求書の包括的なライフサイクルを再構築するための基礎となります。SAPに記録された、保留、転記、保留、決済などの異なるイベントを時系列に接続することを可能にします。これにより、各請求書がどのように処理され、どれくらいの時間がかかり、標準プロセスからの逸脱がどこで発生するかを明確に把握できます。

これは、単一の請求書に関連するすべてのイベントをリンクする主キーであり、プロセス分析およびバリアント探索の不可欠な基盤となります。

これは通常、SAPテーブルRBKPの伝票番号（BELNR）であり、絶対的な一意性を確保するために、会社コード（BUKRS）と会計年度（GJAHR）と連結されることがよくあります。

ユーザー名（User Name）属性は、プロセス内で特定の活動を実行した担当者を識別します。これは通常、トランザクションまたは変更イベントとともにログに記録されるSAPユーザー名です。

この属性は、ユーザーまたはチームレベルでのパフォーマンス分析にとって重要です。「最も迅速な承認者は誰か？」や「最も多くの手戻り作業を発生させるユーザーは誰か？」といった質問に答えるのに役立ちます。ダッシュボードでは、ワークロードの配分を分析し、トレーニングの必要性を特定し、異なる従業員間でのパフォーマンスのばらつきを理解するために使用されます。

個人またはチームごとのパフォーマンスとワークロードの分析を可能にし、優秀な人材、トレーニング機会、リソースの不均衡を特定するのに役立ちます。

これは、変更伝票ヘッダーテーブルCDHDRの「変更者」フィールド（USERNAME）です。作成イベントの場合、RBKPなどのテーブルの「入力者」フィールド（ERNAM）となることがあります。

仕入先コード（Vendor Number）は、サプライヤーを識別するマスターデータキーです。これは請求書取引を特定のビジネスパートナーにリンクさせ、仕入先特性に基づいた分析を可能にします。

仕入先コードごとにプロセスを分析することで、サプライヤー関係とパフォーマンスに関する重要な洞察が得られます。例えば、どの仕入先が常に支払保留や不一致につながる問題のある請求書を提出しているか、あるいはどの仕入先の請求書が最も効率的に処理されているかを特定するのに役立ちます。この情報は、仕入先管理および戦略的調達イニシアチブにとって貴重です。

サプライヤー固有の分析を可能にし、特定のサプライヤーに関連するパターン、問題、または効率性を特定するのに役立ちます。

これは、請求書伝票ヘッダーテーブルRBKPの「請求元」フィールド（LIFNR）です。

請求書に不一致がある場合やさらなる調査が必要な場合、支払保留が適用されます。支払保留理由コードは、数量差異、価格差異、または手動ブロックなど、保留が設定された理由を指定します。

この属性は、「支払保留解決期間」ダッシュボードにとって不可欠です。理由別に保留の頻度と期間を分析することで、支払遅延の根本原因を特定するのに役立ちます。例えば、「価格不一致」が長期保留の最も一般的な理由である場合、マスターデータまたは発注プロセスにおける潜在的な問題を示しており、対処が必要です。

請求書が遅延する理由を説明し、支払ブロックの根本原因分析を可能にし、プロセス改善の取り組みを優先順位付けするのに役立ちます。

支払保留理由は、テーブルRSEGの項目レベル（フィールドSPGRS）または会計伝票テーブルBSEG（フィールドZLSPR）で見つけることができます。

支払期日（Payment Due Date）は、請求書の基準日付と合意された支払条件に基づいて計算されます。これは、遅延を避け、潜在的な罰金やベンダー関係の損害を招かないための支払い期限を表します。

この属性は、「期日内支払率」や「キャッシュディスカウント機会損失」などのパフォーマンスおよびコンプライアンスKPIにとって重要です。実際の支払日（決済日付）と支払期日を比較することで、分析は支払いが期日通りか、早期か、遅延かを自動的に判断できます。これは「支払条件遵守」ダッシュボードの基礎的な要素です。

期限内支払いパフォーマンスを測定し、早期支払割引を獲得する機会を特定するためのベースラインとして機能します。

この日付はしばしば計算されます。支払の基準日付（ZFBDT）はテーブルBSEGにあります。期日のロジックは支払条件（BSEG-ZTERM）にも依存します。

決済日付（Clearing Date）は、請求書ライフサイクルの最終ステップである支払いを示します。これは、未払いの請求書明細項目がシステム内の支払伝票によって決済された日付です。この日付は実際の支払実行時間を表します。

この属性は、「平均請求書サイクルタイム」や「期日内支払率」を含む多くの重要なKPIのエンドポイントです。支払期日と比較して支払パフォーマンスを測定します。キャッシュディスカウント分析では、支払いが割引期間内に実行され、割引を獲得できたかを確認するために割引期間と比較されます。

プロセスの完了を示し、総サイクルタイム、期限内支払い率、現金割引の実現を計算するための基礎となります。

消込済みの項目については、これは消込済みサプライヤー明細テーブルBSAKの「消込日付」フィールド（AUGDT）です。

発注書番号（Purchase Order Number）は、請求書を元の調達文書にリンクさせます。これは三点照合（発注書、入庫、請求書）の基本であり、発注書に基づいた請求書処理の効率を分析するために重要です。

この属性は、「請求書-発注書照合不一致率」のようなダッシュボードにとって不可欠です。これにより、プロセスを発注書付き請求書と発注書なし請求書にセグメント化でき、これらはしばしば非常に異なる処理経路と複雑さを持っています。特定のPOに関連する問題を分析することで、調達プロセスの上流における問題を診断するのに役立ちます。

請求書を調達プロセスに接続し、PO（購買発注）と非PO請求書の比較分析や、照合の不一致の特定を可能にします。

これは通常、明細項目レベルで見つかります。「発注書番号」（EBELN）は請求書項目テーブルRSEGにあります。ヘッダーレベルに集計する必要がある場合があります。

転記日付（Posting Date）は会計プロセスにおける重要な日付です。これは、請求書の費用が総勘定元帳で認識される会計期間を決定します。通常、請求書処理中に買掛金担当者によって設定されます。

プロセス分析において、この日付でマークされる「請求書転記済み」活動は重要なマイルストーンです。請求書受領から転記日付までの期間は、全体のサイクルタイムの重要な要素です。この日付は、週ごとまたは月ごとの転記済み請求書数を追跡するなど、財務報告およびスループット分析にとっても基礎となります。

プロセスの重要な節目を示し、取引の会計期間を決定し、サイクルタイム計算の主要な構成要素となります。

これは、請求書伝票ヘッダーテーブルRBKPの「転記日付」フィールド（BUDAT）です。

請求金額は、サプライヤーが提出した請求書の総額を表します。これは、各請求書ケースにとって重要な財務メトリックです。

プロセスマイニングにおいて、この属性は価値ベースの分析に不可欠です。請求金額に基づいてプロセスをフィルタリングおよびセグメント化することができ、これはプロセスの複雑性や承認要件と相関することがよくあります。例えば、高額な請求書は異なる、より厳格な承認経路をたどる可能性があります。また、コンプライアンス分析にも使用され、例えば、高額な請求書が必須の承認ステップを迂回しているかどうかをチェックします。

価値ベースの分析を可能にし、高額な請求書を優先し、請求金額がプロセスフローとコンプライアンスにどのように影響するかを理解するのに役立ちます。

これは、請求書伝票ヘッダーテーブルRBKPの「請求書総額」フィールド（RMWWR）です。

ソースシステム（Source System）属性は、イベントデータの発生源、例えば特定のSAP ECCインスタンス名を示します。これは、複数のERPシステムを持つ環境や、異なるソースからデータが結合される場合に特に重要です。

分析において、この属性は、別々のインスタンスで稼働している可能性のあるさまざまなシステム、地域、またはビジネスユニット間でのプロセスとパフォーマンスを区別するのに役立ちます。これによりデータのリネージが明確になり、システム固有のフィルタリングと分析が可能になります。

複数システム環境において重要なコンテキストを提供し、適切なデータ分離とシステム固有のパフォーマンス分析を可能にします。

これは通常、データ抽出プロセス中に付加される静的値で、SAPシステムID（TADIR-SRCSYSTEM）または特定のSAPインスタンスに手動で割り当てられた識別子を表します。

伝票タイプ（Document Type）は、SAPでさまざまな種類の取引を分類するために使用されます。請求書処理では、標準請求書には「RE」、仕入先クレジットメモには「KG」などの一般的なタイプがあります。伝票タイプは、使用される番号範囲など、転記の側面を制御します。

分析では、この属性によりプロセスを特定の取引タイプにフィルタリングできます。例えば、クレジットメモの処理プロセスは標準請求書とは大きく異なる場合があります。伝票タイプを使用してこれらの流れを分離することで、より正確で意味のあるプロセスビューが提供されます。

請求書とクレジットメモのように異なるプロセスに従う異なるビジネストランザクションの分離と分析を可能にします。

これは、請求書伝票ヘッダーテーブルRBKPの「伝票タイプ」フィールド（BLART）です。

会社コード（Company Code）はSAPファイナンシャルにおける基本的な組織単位であり、独立した法的エンティティを表します。請求書を含むすべての財務取引は、特定の会社コードに転記されます。

この属性により、プロセス分析を法的エンティティごとにセグメント化することができます。これは、企業グループ内の異なる会社間でプロセスパフォーマンス、コンプライアンス、効率を比較するために不可欠です。ダッシュボードは会社コードでフィルタリングすることで、請求書処理KPIの会社固有のビューを提供できます。

組織内の異なる法人間でプロセス比較とパフォーマンスベンチマークを可能にします。

これは、請求書伝票ヘッダーテーブルRBKPの「会社コード」フィールド（BUKRS）です。

この属性は、最新のデータ抽出または更新の日時を記録します。個々のイベントではなくデータセット全体に適用され、データの鮮度を明確に示します。

これはダッシュボードユーザーおよびアナリストにとって重要なメタデータ属性です。これにより、分析対象期間を理解し、最新情報に基づいて意思決定を行っていることを確認できます。通常、データの鮮度をユーザーに通知するためにダッシュボードに目立つように表示されます。

データの鮮度をユーザーに通知し、分析と意思決定が最新の情報に基づいていることを保証します。

この値は、データ抽出またはETLツールによって、データ更新時にデータセットに生成および挿入されます。

処理時間（Processing Time）は、活動の開始から終了までに要する時間を測定します。活動の「終了時刻」と「開始時刻」の差として計算されます。これは、活動間の待機時間を含むサイクルタイムとは異なります。

処理時間を分析することで、異なるステップにおける実際の労力や接触時間を理解するのに役立ちます。リソース集約的または非効率的な活動を特定できます。例えば、長い「請求書データ入力済み」処理時間は、複雑な請求書または非効率なデータ入力プロセスを示している可能性があります。この指標は、リソース計画や自動化イニシアチブにとって貴重です。

アクティビティの実際の作業期間を測定し、リソース集約型のステップを特定し、アクティブな作業時間とアイドル状態の待機時間を区別するのに役立ちます。

この属性はSAPには存在しません。データ変換時に「終了時刻 - 開始時刻」の計算式を用いて計算されます。

承認者が請求書を却下する場合、理想的には却下の理由を提供します。これは、「誤った発注書番号」、「重複請求書」、「金額間違い」などの問題を指摘する標準化されたコードまたは自由記述コメントである可能性があります。

このデータは「請求書却下理由と傾向」ダッシュボードにとって不可欠です。異なる却下理由の頻度を分析することで、企業は一般的な問題を特定し、是正措置を講じることができます。例えば、「誤った発注書番号」が頻繁な理由である場合、ベンダーとのコミュニケーション改善やデータ入力担当者へのトレーニングの必要性を示している可能性があります。この分析は、手戻り作業を削減する上で鍵となります。

却下の根本原因を提供し、手戻りを削減し、初回正解率を向上させるためのターゲットを絞ったプロセス改善を可能にします。

この情報は、単一の標準フィールドに保存されていないことがよくあります。ワークフローコンテナログ、伝票に関連付けられた長文テキストフィールド、またはカスタムワークフローソリューションの特定のフィールドで見つかる場合があります。

支払条件は、請求書がいつ支払われるべきか、早期支払いに対してキャッシュディスカウントが利用可能かどうかを定義するルールです。例としては、「30日ネット」や「2% 10日、30日ネット」（10日以内に支払うと2%割引、それ以外の場合は30日以内に全額支払い）などがあります。

この属性は、「キャッシュディスカウント機会損失」ダッシュボードおよび「キャッシュディスカウント取得率」KPIの基盤となります。分析では、支払条件を転記日および支払日と組み合わせて、割引が利用可能であったか、そしてそれが正常に適用されたかを判断します。これは「支払条件遵守」ダッシュボードにとっても重要な要素です。

現金割引獲得率の分析や、プロセス遅延の財務的影響を理解するために不可欠です。

これは、請求書伝票ヘッダーテーブルRBKPの「支払条件キー」フィールド（ZTERM）です。

これは「決済日付」（実際の支払日）と「支払期日」を比較することで計算されるブール値属性です。決済日付が期日後であればフラグはtrue、そうでなければfalseとなります。これにより、各請求書の期日内支払パフォーマンスをシンプルかつ直接的に測定できます。

この属性は、ダッシュボードでの分析と可視化を簡素化します。「期日内支払率」KPIを計算するためのフィルタリングと集計を容易にします。ユーザーはプロセスを迅速にセグメント化して、延滞請求書と期日内支払い請求書のプロセスフローを比較でき、支払遅延につながるプロセスパターンを明らかにする可能性があります。

期限内支払いパフォーマンスの分析を簡素化し、期限内と遅延の請求書プロセスを容易に比較できるようにします。

この属性はSAPには存在しません。データ変換時に「決済日付 > 支払期日」の計算式を用いて計算されます。

これは支払条件と実際の支払日に基づいて計算されるブール値属性です。「支払条件」が早期支払いの割引を提供し、「決済日付」が割引期間の期限切れ後であった場合、「true」に設定されます。これはプロセス非効率による財務的損失を直接測定します。

この属性は「キャッシュディスカウント機会損失」ダッシュボードの基盤となります。処理遅延による財務的影響を容易に定量化できます。このフラグがtrueであるケースでフィルタリングすることで、アナリストは割引機会の損失に最も頻繁につながる特定のプロセスバリアントとボトルネックを調査でき、プロセス改善のための強力なビジネスケースを提供します。

プロセス遅延による財務上の損失を直接定量化し、請求書処理ワークフロー最適化の説得力のある根拠を創出します。

この属性はSAPには存在しません。「支払条件」を解釈し、「決済日付」を割引期日と比較することで、データ変換中に計算されます。

終了時刻（End Time）属性は、特定の活動の完了を示します。SAPで多くのイベントが単一の時点としてログに記録される場合、終了時刻は開始時刻と同一になります。しかし、承認ステップのように測定可能な期間を持つ活動の場合、それはその作業の完了を表すことがあります。

プロセス分析において、明確な終了時刻を持つことで、その活動に先行する待機時間とは別に、活動の処理時間を測定できます。これにより、活動の実行にかかる時間と、その活動が開始されるまでケースが待機する時間を区別でき、リソース効率に関するより深い洞察が得られます。

アクティビティの処理時間を計算し、アクティビティ間の待機時間と区別することで、ボトルネック分析を改善します。

これはしばしば開始時刻と同じで、CDHDR-UDATEとCDHDR-UTIMEから導出されます。場合によっては、タスクの開始と終了を明示的に記録するワークフローログから導出されることもあります。

総勘定元帳（G/L）勘定科目は、請求書の財務的影響が記録される勘定科目表内の最終勘定科目です。これは財務報告およびコスト管理にとって重要なデータです。

プロセスマイニングにとって、G/L勘定科目を分析することは、プロセスフローに財務的側面をもたらします。「総勘定元帳勘定使用分析」ダッシュボードは、支出パターンを明らかにし、請求書の潜在的な誤分類を特定し、コストが正しい部門やプロジェクトに割り当てられていることを確認できます。これは、プロセス実行と財務的影響との間のギャップを埋めるのに役立ちます。

プロセスに財務的な側面を追加し、コスト配分、支出パターン、潜在的な請求書の誤ったコーディングの分析を可能にします。

これは明細項目レベルで見つかります。「G/L勘定科目番号」（HKONT）は、発注書（PO）請求書の場合は請求書項目テーブルRSEGに、直接財務会計（FI）請求書の場合はBSEGにあります。

通貨（Currency）属性は、請求書金額がどの通貨で表記されているかを示します。例えば、USD、EUR、JPYなどです。

この属性は請求書金額にとって不可欠なコンテキストを提供します。特に複数の通貨を扱うグローバルな組織では、財務データの正しい解釈と集計を可能にします。異なる通貨圏間での処理効率や問題点を比較するために、分析を通貨でフィルタリングできます。意味のある財務集計のためには、金額を単一の報告通貨に換算する必要がある場合があります。

あらゆる財務金額に必要なコンテキストを提供し、正確な解釈を保証し、通貨ベースのフィルタリングと分析を可能にします。

これは、請求書伝票ヘッダーテーブルRBKPの「通貨キー」フィールド（WAERS）です。