調達から支払いまで：請求書処理のデータテンプレート

Activity属性は、請求書処理ワークフロー内の個別の段階またはアクションを表します。これらのアクティビティは、伝票の作成、ステータス変更、承認、SAPの変更ログに記録されたユーザー操作など、さまざまなシステムイベントから導出されます。

アクティビティの分析は、プロセスマイニングの中核です。プロセスマップの可視化、ボトルネック（例：「Invoice Sent For Approval」の後の長い待ち時間）の特定、手戻りループ（例：「Payment Block Set」と「Payment Block Released」の繰り返し）、コンプライアンス違反の検出が可能になります。アクティビティの順序と頻度から、実際の現行プロセスの流れが明らかになります。

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

通常は、トランザクションコード（SY-TCODE）、RBKPなどのテーブルにあるステータスフィールド（例：RBSTAT）、CDHDRおよびCDPOSテーブルの変更イベントなど、複数の情報源から導出されます。

Event Timeは、業務アクティビティが実行され、ソースシステムに記録された正確な時点を記録します。このタイムスタンプはプロセスの時系列を支える基盤であり、各請求書のアクティビティを一貫した順序に並べます。

分析では、Event Timeがアクティビティ間のサイクルタイム、待ち時間、処理時間など、時間に基づくすべての指標の計算に欠かせません。「Invoice End-to-End Cycle Time」や「Payment Block Resolution Duration」などのダッシュボードでは、プロセス上の任意の2地点間の経過時間を測定するために必要なデータを提供します。遅延やパフォーマンス上のボトルネックを特定するには、正確なタイムスタンプが欠かせません。

イベントを正しい順序に並べ、サイクルタイムやボトルネックの継続時間など、すべてのパフォーマンス指標を計算するために欠かせません。

通常は、変更文書ヘッダーテーブルCDHDRの変更日（UDATE）と変更時刻（UTIME）を組み合わせて導出します。特定の作成イベントでは、RBKPなどのテーブルにある作成日と作成時刻（ERNAM、ERZET）が使われる場合があります。

請求書番号は、請求書処理の一連の流れを追跡するための一意のケース識別子です。各番号は仕入先から受領した1件の請求書に対応し、データ取得から最終支払いまで、関連するすべてのアクティビティを1つのプロセスインスタンスとして追跡できます。

プロセスマイニング分析では、この属性がすべての請求書のライフサイクルを再構成する基盤となります。SAPに記録された仮保存、転記、ブロック、消込などの個別のイベントを、時系列に結び付けることができます。これにより、各請求書がどのように処理されたか、どのくらい時間がかかったか、標準プロセスからどこで逸脱したかを明確に把握できます。

1件の請求書に関連するすべてのイベントを結び付ける主キーであり、プロセス分析とバリアント探索の基盤となります。

通常は、SAPテーブルRBKPのBELNRフィールドにある文書番号を使用します。完全に一意にするため、会社コード（BUKRS）と会計年度（GJAHR）を連結することもあります。

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

この属性は、ユーザーまたはチーム単位のパフォーマンス分析に欠かせません。「最も承認が速い担当者は誰か」「最も多く手戻りを発生させているユーザーは誰か」といった問いに答えられます。ダッシュボードでは、業務量の分布、トレーニングの必要性、従業員間のパフォーマンス差を分析するために使われます。

個人またはチーム単位でパフォーマンスと業務量を分析でき、優れたパフォーマンスを上げている担当者、トレーニングの機会、リソースの偏りを特定できます。

変更文書ヘッダーテーブルCDHDRの「Changed By」フィールド（USERNAME）です。作成イベントでは、RBKPなどのテーブルにある「Entered by」フィールド（ERNAM）が使われる場合があります。

Vendor Numberは、仕入先を識別するマスターデータのキーです。請求書取引を特定のビジネスパートナーに関連付け、仕入先の特性に基づく分析を可能にします。

Vendor Numberでプロセスを分析すると、仕入先との関係やパフォーマンスに関する重要な傾向が見えてきます。たとえば、支払ブロックや不一致につながる問題のある請求書を繰り返し提出する仕入先や、最も効率よく処理される仕入先の請求書を特定できます。この情報は、仕入先管理や戦略的ソーシングの取り組みに役立ちます。

仕入先単位の分析を可能にし、特定のサプライヤーに関連する傾向、問題、効率性を特定できます。

請求書伝票ヘッダーテーブルRBKPの「Invoicing Party」フィールド（LIFNR）です。

請求書に不一致がある場合や、追加調査が必要な場合は、支払ブロックが設定されます。Payment Block Reasonコードは、数量差異、価格差異、手動ブロックなど、ブロックの理由を示します。

「Payment Block Resolution Duration」ダッシュボードに欠かせません。理由別にブロックの頻度と継続時間を分析すると、支払遅延の根本原因を特定できます。たとえば、「Price Discrepancy」が長期ブロックの主な理由であれば、マスターデータや購買発注プロセスに対処すべき問題がある可能性を示します。

請求書が遅延した理由を明らかにし、支払ブロックの根本原因分析と、プロセス改善施策の優先順位付けに役立ちます。

支払ブロック理由は、RSEGテーブルの明細レベル（フィールドSPGRS）または会計伝票テーブルBSEG（フィールドZLSPR）で確認できます。

Payment Due Dateは、請求書の基準日と合意済みの支払条件に基づいて計算されます。支払いの遅延や、それによる違約金の発生、仕入先との関係悪化を避けるための期限です。

「On-Time Payment Rate」や「Cash Discount Opportunity Loss」などのパフォーマンスおよびコンプライアンスKPIに欠かせません。実際の支払日（Clearing Date）とPayment Due Dateを比較することで、支払いが期日どおり、早期、または遅延だったかを自動的に判定できます。Payment Terms Adherenceダッシュボードの基盤となる属性です。

期日どおりの支払パフォーマンスを測定し、早期支払割引を獲得できる機会を特定するための基準になります。

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

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

「Average Invoice Cycle Time」や「On-Time Payment Rate」など、多くの重要なKPIの終点になります。Payment Due Dateと比較して支払パフォーマンスを測定します。現金割引の分析では、割引期間と比較し、割引を獲得できる期限内に支払われたかを確認します。

プロセスの完了を示し、総サイクルタイム、期日どおりの支払率、現金割引の獲得額を計算する基準になります。

消込済み明細では、消込済み仕入先明細テーブルBSAKの「Clearing Date」フィールド（AUGDT）です。

Invoice Amountは、仕入先が提出した請求書の総額を表します。各請求書ケースにおける重要な財務指標です。

プロセスマイニングでは、金額に基づく分析に欠かせません。請求書金額でプロセスをフィルタリングまたは分類でき、金額はプロセスの複雑さや承認要件と相関することがよくあります。たとえば、高額な請求書には、より厳格な別の承認経路が設定されている場合があります。また、高額請求書が必要な承認ステップを省略していないかを確認するなど、コンプライアンス分析にも使われます。

金額に基づく分析を可能にし、高額請求書の優先順位付けや、請求書金額がプロセスフローとコンプライアンスに与える影響の把握に役立ちます。

請求書伝票ヘッダーテーブルRBKPの「Gross invoice amount」フィールド（RMWWR）です。

Purchase Order Numberは、請求書を元の調達伝票に関連付けます。PO、入庫、請求書による三者照合や、POに基づく請求書処理の効率を分析するうえで基本となる属性です。

「Invoice-PO Matching Discrepancy Rate」などのダッシュボードに欠かせません。プロセスをPO請求書と非PO請求書に分けて分析できます。両者は処理経路や複雑さが大きく異なることがよくあります。特定のPOに関する問題を分析すれば、調達プロセスの上流にある問題の原因を特定できます。

請求書を調達プロセスに関連付け、PO請求書と非PO請求書の分析や、照合不一致の特定を可能にします。

通常は明細レベルにあります。「Purchase Order Number」（EBELN）は請求書明細テーブルRSEGに記録されます。ヘッダーレベルに集約する必要がある場合があります。

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

プロセス分析では、この日付が示す「Invoice Posted」アクティビティが主要なマイルストーンになります。請求書の受領からPosting Dateまでの期間は、全体のサイクルタイムを構成する重要な要素です。また、週または月ごとの転記済み請求書数を追跡するなど、財務報告や処理量分析にも欠かせません。

プロセス上の重要なマイルストーンを示し、取引の会計期間を決定するとともに、サイクルタイム計算の主要な要素になります。

請求書伝票ヘッダーテーブルRBKPの「Posting Date」フィールド（BUDAT）です。

Source System属性は、イベントデータの発生元を示します。たとえば、特定のSAP ECCインスタンス名などです。複数のERPシステムを利用している環境や、異なる情報源のデータを統合する環境では、特に重要です。

分析では、この属性によって、別々のインスタンスで稼働している可能性がある複数のシステム、地域、事業部門間で、プロセスとパフォーマンスを区別できます。データの系譜を明確にし、システム単位のフィルタリングと分析を可能にします。

複数システムが存在する環境で重要なコンテキストを提供し、適切なデータ分離とシステム単位のパフォーマンス分析を可能にします。

通常は、データ抽出時に追加される固定値です。SAP System ID（TADIR-SRCSYSTEM）または特定のSAPインスタンスに手動で割り当てた識別子を表します。

Company Codeは、SAP Financialsにおける基本的な組織単位で、独立した法人を表します。請求書を含むすべての財務取引は、特定の会社コードに転記されます。

この属性により、法人単位でプロセスを分けて分析できます。企業グループ内の各社について、プロセスのパフォーマンス、コンプライアンス、効率を比較するうえで欠かせません。ダッシュボードをCompany Codeでフィルタリングすれば、会社ごとの請求書処理KPIを確認できます。

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

請求書伝票ヘッダーテーブルRBKPの「Company Code」フィールド（BUKRS）です。

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

分析では、この属性によって特定の取引タイプに絞ってプロセスを確認できます。たとえば、クレジットメモの処理は標準請求書とは大きく異なる場合があります。Document Typeでフローを分けることで、より正確で意味のあるプロセスビューを作成できます。

請求書とクレジットメモなど、異なるプロセスに従う業務取引を分けて分析できます。

請求書伝票ヘッダーテーブルRBKPの「Document Type」フィールド（BLART）です。

最新のデータ抽出または更新が行われた日時を記録します。個々のイベントではなくデータセット全体に適用され、データがいつ時点のものかを明確に示します。

これは、ダッシュボードの利用者や分析担当者にとって重要なメタデータ属性です。分析対象の期間を把握し、最新の情報に基づいて意思決定できるようにします。通常はダッシュボード上に目立つ形で表示され、データの更新状況を知らせます。

データの更新状況を利用者に知らせ、分析や意思決定が最新の情報に基づいて行われるようにします。

データ更新時に、データ抽出ツールまたはETLツールがこの値を生成し、データセットに追加します。

承認者が請求書を却下する際は、通常、理由を記載します。「Incorrect PO number」「Duplicate Invoice」「Amount incorrect」などの問題を示す標準コードまたは自由記述のコメントです。

このデータは「Invoice Rejection Reasons & Trends」ダッシュボードに欠かせません。却下理由ごとの頻度を分析すると、よくある問題を特定し、是正措置を講じられます。たとえば、「Incorrect PO number」が頻発する場合、仕入先とのコミュニケーション改善やデータ入力担当者へのトレーニングが必要な可能性があります。この分析は、プロセスの手戻り削減に重要です。

却下の根本原因を明らかにし、手戻りを減らして初回正解率を高めるための、対象を絞ったプロセス改善を可能にします。

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

Payment Termsは、請求書の支払期限と、早期支払いで利用できる現金割引の有無や条件を定義します。たとえば「Net 30 days」は30日以内の全額支払いを意味し、「2% 10, Net 30」は10日以内なら2％割引、そうでなければ30日以内に全額支払うことを意味します。

「Cash Discount Opportunity Loss」ダッシュボードと「Cash Discount Capture Rate」KPIの基盤となる属性です。分析では、支払条件を転記日や支払日と組み合わせ、割引が利用可能だったか、実際に適用できたかを判定します。Payment Terms Adherenceダッシュボードにも欠かせません。

現金割引の獲得率を分析し、プロセス遅延が財務に与える影響を把握するために欠かせません。

請求書伝票ヘッダーテーブルRBKPの「Terms of Payment Key」フィールド（ZTERM）です。

「Clearing Date」（実際の支払日）と「Payment Due Date」を比較して計算するブール型属性です。消込日が支払期日より後であればtrue、そうでなければfalseになります。各請求書の期日どおりの支払パフォーマンスを、簡潔かつ直接的に測定できます。

この属性により、ダッシュボードでの分析と可視化が簡単になります。フィルタリングや集計によって「On-Time Payment Rate」KPIを容易に計算できます。期限超過の請求書と期日どおりに支払われた請求書のプロセスフローを比較し、支払遅延につながるプロセスの傾向を明らかにできます。

期日どおりの支払パフォーマンスを簡単に分析し、期日どおりの請求書と遅延した請求書のプロセスを比較できます。

SAPには存在しません。データ変換時に、次の式で計算されます：ClearingDate > PaymentDueDate。

支払条件と実際の支払日に基づいて計算するブール型属性です。Payment Termsに早期支払割引が設定されており、Clearing Dateが割引期間の終了後であればtrueになります。プロセスの非効率による財務上の損失を直接測定できます。

この属性は「Cash Discount Opportunity Loss」ダッシュボードの基盤です。処理遅延による財務的影響を簡単に定量化できます。このフラグがtrueのケースに絞り込むことで、割引の取り逃しにつながるプロセスバリアントやボトルネックを調査でき、プロセス改善の必要性を示す明確な根拠になります。

プロセス遅延による財務上の損失を直接定量化し、請求書処理ワークフローを最適化する明確な根拠を示します。

SAPには存在しません。データ変換時に「PaymentTerms」を解釈し、「ClearingDate」と割引期日を比較して計算されます。

End Time属性は、特定のアクティビティが完了した時点を示します。SAPの多くのイベントは時点として記録されるため、End TimeはStart Timeと同じになります。一方、実際の作業を伴う承認ステップなど、測定可能な継続時間を持つアクティビティでは、その作業の完了時点を表します。

プロセス分析で個別のEnd Timeを設定すると、アクティビティの処理時間を、その前に発生する待ち時間と分けて測定できます。これにより、アクティビティの実行にかかった時間と、開始を待っていた時間を区別でき、リソース効率をより深く把握できます。

アクティビティの処理時間を計算し、アクティビティ間の待ち時間と区別できるため、ボトルネック分析の精度が向上します。

Start Timeと同じ値になることが多く、CDHDR-UDATEとCDHDR-UTIMEから導出されます。場合によっては、タスクの開始と終了を明示的に記録するワークフローログから導出します。

General Ledger（G/L）Accountは、勘定コード表の中で請求書の財務的影響を記録する勘定科目です。財務報告と原価管理に欠かせないデータです。

プロセスマイニングでは、G/L勘定を分析することで、プロセスフローに財務の観点を加えられます。「General Ledger Account Usage Analysis」ダッシュボードでは、支出の傾向、請求書の勘定誤りの可能性、原価が正しい部門やプロジェクトに配賦されているかを確認できます。プロセスの実行と財務的影響を結び付けるのに役立ちます。

プロセスに財務の観点を加え、原価配賦、支出傾向、請求書の勘定誤りの可能性を分析できます。

明細レベルにあります。「G/L Account Number」（HKONT）は、PO請求書では請求書明細テーブルRSEGに、直接FI請求書ではBSEGに記録されます。

Currency属性は、請求書金額の通貨を示します。たとえば、USD、EUR、JPYなどです。

この属性はInvoice Amountを解釈するために欠かせないコンテキストを提供します。複数の通貨を扱うグローバルな組織では、財務データを正しく解釈・集計できます。通貨で分析をフィルタリングし、異なる通貨圏の処理効率や問題を比較できます。財務データを意味のある形で集計するには、単一の報告通貨への換算が必要になる場合があります。

財務金額を正しく解釈するために必要なコンテキストを提供し、通貨に基づくフィルタリングと分析を可能にします。

請求書伝票ヘッダーテーブルRBKPの「Currency Key」フィールド（WAERS）です。