Order to Cash - 請求・入金データテンプレート
SAP S/4HANA
Order to Cash - 請求・入金データテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- `SAP S/4HANA`向け抽出`ガイド`
受注から入金まで（請求・債権回収）属性
| 名前 | 説明 | ||
|---|---|---|---|
| 請求書番号 InvoiceNumber | 請求伝票の一意の識別子であり、請求プロセスの主要なケース識別子として機能します。 | ||
| 説明 請求書番号は、SAPでは請求伝票番号として知られ、各請求取引を一意に識別します。請求書の作成、転記、支払い受領、照合まで、関連するすべての活動を結びつける中心的なキーとして機能します。 プロセスマイニングにおいて、この属性はケース相関に不可欠です。同じ請求書番号を共有するすべてのイベントは単一のプロセスインスタンスにグループ化され、個々の請求書に対する請求ライフサイクル全体の完全なエンドツーエンド分析を可能にします。これにより、サイクルタイムの追跡、逸脱の特定、および各請求書のジャーニーの分析が可能になります。 その重要性 関連するすべての請求活動を単一のケースに結びつける基本的な識別子であり、エンドツーエンドのプロセス分析を可能にします。 取得元 SAPテーブル：VBRK、フィールド：VBELN 例 900012349000567890009012 | |||
| アクティビティ名 ActivityName | 請求プロセス内で発生したビジネスアクティビティまたはイベントの名前（例：「請求書発行済み」または「支払い受領」）。 | ||
| 説明 アクティビティ名とは、請求ライフサイクルにおける特定のステップや節目を表します。これらのアクティビティは、SAP内の様々なデータポイント（トランザクションコード、伝票ステータスの変更、特定のイベントログエントリなど）から導き出され、順序立ったプロセスフローを構築します。 これらのアクティビティの順序と頻度を分析することが、プロセスマイニングの中核です。これにより、プロセスマップの視覚化、一般的および稀なプロセスバリアントの発見、ステップ間のボトルネックの特定、再作業やキャンセルなどの付加価値のないアクティビティの頻度測定が可能になります。 その重要性 この属性はプロセスのステップを定義し、プロセスマップの視覚化、プロセスフロー、バリエーション、ボトルネックの分析を可能にします。 取得元 トランザクションコード（SY-TCODE）、変更伝票ステータス（CDHDR/CDPOSテーブル）、またはビジネスワークフローログ（例：SWW_WI2OBJ）を含む様々な情報源から導出されます。 例 請求書生成済み請求書が会計に転記された顧客からの入金受領請求書取消し済み | |||
| イベント日時 EventTime | アクティビティまたはイベントが発生した正確なタイムスタンプです。 | ||
| 説明 イベントタイムは、各活動の日付と時刻を提供し、プロセスの時系列的な基盤を形成します。このタイムスタンプは、請求プロセスの異なるステップ間の期間、サイクルタイム、および待機時間を計算するために非常に重要です。 分析では、イベントタイムは活動を時系列に並べ、売掛金回収期間や請求書生成サイクルタイムなどの主要業績評価指標を計算し、時間ベースのボトルネックを特定するために使用されます。これにより、時間の経過とともにパフォーマンスがどのように変化するか、請求サイクルの各段階にどれくらいの時間がかかるかを示す、プロセスの動的なビューが可能になります。 その重要性 イベントの時系列順序を提供し、サイクルタイムや期間など、すべての時間ベースのメトリックを計算するために不可欠です。 取得元 活動に応じて、作成日時（VBRK-ERDAT、VBRK-ERZET）、変更タイムスタンプ（CDHDR-UDATE、CDHDR-UTIME）、または転記日付（BKPF-BUDAT）など、様々な日付と時刻のフィールドから抽出されます。 例 2023-04-15T10:30:00Z2023-04-20T14:00:00Z2023-05-10T09:15:00Z | |||
| ユーザー名 UserName | アクティビティを実行した従業員のユーザーIDです。 | ||
| 説明 この属性は、請求書の作成、伝票の転記、支払いの消込などの特定のイベントを担当したSAPユーザーIDを捕捉します。これにより、プロセスステップとそれらを実行する個人またはチームとの間のリンクが提供されます。 ユーザー名別に分析することで、高パフォーマンスの個人、トレーニングの必要性、またはワークロード配分の不均衡を特定するのに役立ちます。また、主要なアクティビティを実行した人物を示し、異なるユーザーが同じプロセスを実行する方法のバリエーションを理解するために、コンプライアンス分析においても重要です。 その重要性 プロセス活動を特定のユーザーにリンクさせ、個人またはチームレベルでのワークロード、パフォーマンス、およびコンプライアンスの分析を可能にします。 取得元 作成イベントの場合、これはVBRK-ERNAMにあります。後続の変更の場合、CDHDR-USERNAMEのような変更履歴テーブルやワークフローログで見つかります。 例 CBURNSHSIMPSONLLEONARD | |||
| 地域 Region | 顧客の地理的地域です。 | ||
| 説明 「地域」属性は、顧客の住所に関連付けられた地理的領域（州や都道府県など）を示します。このデータは通常、顧客マスタレコードの一部です。 この属性は、「地域別請求パフォーマンスダッシュボード」の鍵となります。異なる地域間でサイクルタイム、エラー率、DSOなどの主要な指標をベンチマークできます。この比較により、プロセス実行、コンプライアンス、または効率性における地域差を浮き彫りにし、的を絞った改善とベストプラクティスの標準化への道を開きます。 その重要性 異なる地理的領域間での請求パフォーマンスの比較を可能にし、地域格差を特定し、プロセスを標準化するのに役立ちます。 取得元 請求書ヘッダーの支払人ID（VBRK-KUNRG）を介してリンクされ、得意先マスタデータテーブルKNA1（フィールド：REGIO）から取得されます。 例 CANYTXBA | |||
| 支払期日 PaymentDueDate | 顧客が請求書を支払うことが期待される期日です。 | ||
| 説明 支払期日は、請求書日付と合意された支払条件に基づいて計算されます。これは、請求書が延滞することなく支払いを受け取る期限を表します。 この属性は、回収の有効性監視とキャッシュフロー予測に不可欠です。期日内支払率KPIの計算や、年齢報告書での請求書のセグメンテーションに直接使用されます。期日と実際の支払い日の間の逸脱を分析することで、異なる支払条件の有効性を評価するのに役立ちます。 その重要性 顧客の支払期日を設定し、期限内支払率の計算や売掛金管理に不可欠です。 取得元 この日付は直接保存されませんが、SAPの標準的な日付決定機能を使用して、請求書日付（VBRK-FKDAT）と支払条件キー（VBRK-ZTERM）に基づいて計算されます。 例 2023-04-192023-05-012023-06-17 | |||
| 終了日時 EndTime | アクティビティまたはイベントが完了した正確なタイムスタンプです。 | ||
| 説明 終了時刻は、アクティビティの完了を示します。プロセスマイニングでは、これはケース内の後続アクティビティの開始時刻として推測されることがよくあります。または、システムが開始イベントと終了イベントの両方をイベントログに記録している場合は直接取得できます。 この属性は、個々のアクティビティの処理時間を計算するために不可欠です。終了時刻から開始時刻を引くことで、各ステップの期間を測定でき、請求書承認段階での遅延の特定など、ボトルネック分析に不可欠です。 その重要性 各活動の正確な期間（処理時間）の計算を可能にし、これはボトルネック分析の基本となります。 取得元 これはプロセスマイニングの派生属性です。通常、ケースシーケンス内の次のイベントの開始時刻として計算されます。一部のシナリオでは、特定のテーブルが完了時間をイベントログに記録する場合があります。 例 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| 請求日 InvoiceDate | 請求書が顧客に発行された公式な日付です。 | ||
| 説明 請求書日付は、SAPでは請求日付とも呼ばれ、多くの財務計算の出発点となります。支払条件、支払期日、および売掛金の経過日数が決定される日付です。 この日付は、財務分析にとって重要なケースレベルの属性です。売上債権回転日数（DSO）KPIの計算の基準となり、未回収請求書年齢レポートの作成に利用されます。これらはキャッシュフローと回収管理に不可欠なツールです。 その重要性 財務計算の主要な日付であり、DSO、支払い期日、および請求書齢分析の開始点として機能します。 取得元 SAPテーブル：VBRK、フィールド：FKDAT 例 2023-03-202023-04-012023-05-18 | |||
| 請求金額 InvoiceAmount | 請求書の総正味額です。 | ||
| 説明 この属性は、税金を除く、請求される商品またはサービスの総貨幣価値を表します。各請求書ケースの基本的な財務データポイントです。 請求額は、広範囲な分析に使用されます。例えば、高額請求書が異なる方法で処理されているか、より多くの遅延が発生しているかを確認するために、金額別にプロセスをセグメント化することができます。また、財務報告書や未回収債権の総額を計算するための基礎にもなります。 その重要性 各請求書の財務的価値を定量化し、価値に基づく分析、回収の優先順位付け、および財務的影響評価を可能にします。 取得元 SAPテーブル：VBRK、フィールド：NETWR 例 1500.0025000.50125.75 | |||
| 顧客名 CustomerName | 請求書が発行された顧客の名前です。 | ||
| 説明 この属性は、請求対象の顧客の正式名称を識別します。これはSAPの中央顧客マスタデータから取得されます。 顧客別にプロセスを分析することで、特定の顧客に特有のパターンを特定できます。例えば、どの顧客が常に支払いが遅れるのか、どの顧客が最も多くの紛争を提起するのか、あるいはどの顧客に対して請求プロセスが最も非効率であるのかを明らかにできます。これにより、的を絞った顧客関係管理と、個別の回収戦略が可能になります。 その重要性 顧客中心の分析を可能にし、特定の口座における支払い行動、紛争頻度、およびプロセスの非効率性を特定するのに役立ちます。 取得元 請求書ヘッダーの支払人ID（VBRK-KUNRG）を介してリンクされ、得意先マスタデータテーブルKNA1（フィールド：NAME1）から取得されます。 例 スプリングフィールド発電所クイックEマートサイバーダインシステムズ | |||
| クレジットメモ理由 CreditMemoReason | 貸方メモが発行された理由を示す理由コードです。 | ||
| 説明 請求書が誤っていて貸方処理が必要な場合、通常、貸方メモ伝票に理由が割り当てられます。これにより、請求エラーの原因を構造的に分類できます。 この属性は、請求エラー率KPIを直接サポートします。貸方メモの理由を集計・分析することで、企業は価格間違いや返品などの最も一般的なエラータイプを特定できます。この分析は、財務修正や再作業の必要性を減らすことを目的としたプロセス改善を推進します。 その重要性 クレジット発行理由を分類することで、請求エラーの最も頻繁な原因を特定し、品質改善を推進するのに役立ちます。 取得元 SAPテーブル：VBRK、フィールド：AUGRU（受注理由）。このフィールドは、後に請求される貸方/借方メモ依頼に使用されます。 例 001 - 価格差異002 - 品質不良005 - 返品 | |||
| ソースシステム SourceSystem | データが抽出された特定のソースシステムを識別します。 | ||
| 説明 この属性はデータの出所を特定します。これは、複数のSAPインスタンスやその他の統合システムがある環境で特に役立ちます。通常、システムIDとクライアント番号が含まれます。 分析において、異なるシステムや組織エンティティ間でプロセスとパフォーマンスを区別するのに役立ちます。データの履歴を保証し、コンテキストを提供します。特に、複数のソースからのデータが全体的なプロセスビューのために結合される場合に重要です。 その重要性 データの出所に関する重要なコンテキストを提供し、複数システム環境での明確性を確保し、データガバナンスをサポートします。 取得元 これは通常、データ抽出中に定義される静的な値で、多くの場合、システムID（SY-SYSID）とクライアント（SY-MANDT）を組み合わせたものです。 例 S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| 会社コード CompanyCode | 財務取引が記録される組織単位です。 | ||
| 説明 会社コードは、SAP Financialsにおける基本的な組織エンティティであり、財務諸表が作成される法的に独立した会社を表します。各請求伝票は特定の会社コードに割り当てられます。 会社コード別に分析することは、複数企業組織において、異なる法人間のプロセスパフォーマンス、DSOなどの財務指標、およびコンプライアンスを比較するために不可欠です。すべてのプロセスダッシュボードに、上位レベルの組織フィルターを提供します。 その重要性 プロセス分析を法主体ごとにセグメント化することができ、組織全体のパフォーマンス比較と財務連結を可能にします。 取得元 SAPテーブル：VBRK、フィールド：BUKRS 例 10002000US01 | |||
| 最終データ更新 LastDataUpdate | このイベントのデータが最後に抽出または更新された時期を示すタイムスタンプです。 | ||
| 説明 この属性は、ソースシステムから最後にデータが取得された日付と時刻を記録します。これは、分析対象データの鮮度を理解するために重要なメタデータフィールドです。 この情報は、分析の最新性を検証し、データ更新スケジュールを管理するために使用されます。これにより、ステークホルダーがデータの適時性を認識していることを保証します。 その重要性 データの鮮度を示し、分析を信頼し、現在の運用状況との関連性を理解するために不可欠です。 取得元 このタイムスタンプは、データ抽出およびロード（ETL）プロセス中に生成され、各レコードに付与されます。 例 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
| 処理時間 ProcessingTime | アクティビティの期間。開始から終了までの時間として計算されます。 | ||
| 説明 処理時間とは、タスク間の待機時間ではなく、タスクに積極的に取り組んだ時間を測定したものです。これは、アクティビティの終了時刻と開始時刻の差として計算されます。 この算出された指標は、パフォーマンス分析の要です。「請求書承認ボトルネック分析」のようなダッシュボードで使用され、特定のステップにかかる時間を定量化します。特定アクティビティの処理時間が長い場合、非効率性、複雑性、または自動化の必要性を示している可能性があります。 その重要性 プロセスステップのアクティブな期間を測定し、最適化または自動化の有力候補となる非効率な活動を特定するのに役立ちます。 取得元 データ変換プロセス中に「StartTime」から「EndTime」を減算して導出される計算済みメトリックです。 例 PT30MPT5MPT1H15M | |||
| 支払ステータス PaymentStatus | 請求書の支払いに関する現在のステータス（例：未決済、支払い済み、期日超過）。 | ||
| 説明 支払ステータスは、請求書が回収ライフサイクルのどの段階にあるかを一目で把握できる情報です。これはSAPの単一フィールドではなく、対応する会計伝票の決済ステータスを確認することで導き出されます。 この属性は、「未回収請求書年齢ダッシュボード」に不可欠です。すべての未回収請求書をステータスと経過日数で分類し、回収チームが効果的に業務を優先順位付けするのに役立ちます。ステータス間の遷移を追跡することは、回収プロセス自体を監視する手段にもなります。 その重要性 請求書の回収状況を一目で明確に把握でき、売掛金の管理や回収努力の優先順位付けに不可欠です。 取得元 BSID（未消込項目）やBSAD（消込済み項目）などの財務テーブルで会計伝票（VBRK-BELNR）の消込ステータスを確認して導出されます。 例 オープン支払い済み期限超過一部支払い済み | |||
| 支払条件 PaymentTerms | 支払い期間など、支払条件を定義するコードです。 | ||
| 説明 支払条件は、顧客と合意された、請求書の支払期日を定める所定の条件です。例としては、「Net 30」（30日以内に支払い）や「2/10 Net 30」（10日以内に支払えば2%割引、それ以外は30日以内に支払い）などがあります。 支払条件別に分析することで、その有効性を評価できます。異なる支払条件と実際の入金に要した期間を関連付けることにより、企業はどの条件が迅速な支払いを最も促進するかを判断し、キャッシュフロー改善のために条件を最適化できます。 その重要性 合意された支払いスケジュールを定義し、どの条件が顧客からのタイムリーな支払いを確保するのに最も効果的であるかを分析できるようにします。 取得元 SAPテーブル：VBRK、フィールド：ZTERM 例 Z030Z060ZB60 | |||
| 期日内支払い済みか IsPaidOnTime | 請求書が期日までに支払われたかどうかを示すブール型のフラグです。 | ||
| 説明 これは、実際の支払い日と予定されている支払期日を比較する算出属性です。支払いが期日内であれば「true」、遅延していれば「false」となります。 このフラグは、期日内支払率KPIの計算と視覚化を簡素化します。遅延して支払われた請求書と期日内に支払われた請求書の特性を分析するための簡単なフィルタリングとセグメンテーションを可能にします。これにより、特定の顧客、地域、または支払い条件に関連する遅延支払いにつながるパターンを明らかにすることができます。 その重要性 各請求書を「期日通り」または「遅延」と明確にマークすることでパフォーマンス測定を簡素化し、期限内支払率KPIを直接サポートします。 取得元 これは計算フィールドです。「顧客からの入金受領」アクティビティのタイムスタンプを、「PaymentDueDate」属性の値と比較するロジックです。 例 truefalse | |||
| 紛争理由 CustomerDisputeReason | 顧客が請求書に異議を唱える際に提示した理由です。 | ||
| 説明 顧客が請求書に異議を唱える際、その紛争理由は記録されることがよくあります。これは価格エラー、数量間違い、または商品の破損が原因である可能性があります。この情報は、SAP Dispute Managementモジュールまたはテキストメモとして保存される場合があります。 紛争理由の分析は、請求エラー率KPIおよび関連するエラー分析の基本です。これにより、請求の不正確さの根本原因を特定し、企業が上流プロセスにおけるシステム的な問題に対処し、請求書の品質を向上させ、顧客満足度を高めるのに役立ちます。 その重要性 請求書が紛争になっている理由を説明し、請求エラーと顧客不満の根本原因への直接的な洞察を提供します。 取得元 SAP Dispute Managementが使用されている場合、この情報はUDM_DISPUTEのようなテーブルで見つけることができます。そうでない場合、関連する伝票の理由コードやテキストフィールドから導出されることがあります。 例 価格間違い数量不一致損傷品受領 | |||
| 請求伝票タイプ BillingDocumentType | 請求書、クレジットメモ、キャンセルなど、請求伝票を分類するコードです。 | ||
| 説明 請求伝票タイプは、請求プロセス内の取引を分類する主要なフィールドです。これは、伝票の処理方法を制御し、番号範囲や会計転記ルールを含みます。 この属性を使用すると、プロセスをフィルタリングして特定の種類の取引を分析できます。例えば、貸方メモだけの独立したプロセスビューを作成して財務修正の理由とプロセスフローを理解したり、標準請求書をキャンセルとは別に分析して主要な請求プロセスをより明確に把握したりすることができます。 その重要性 取引を分類し、標準請求書、クレジットメモ、キャンセルなど、特定の伝票フローに焦点を当てた分析を可能にします。 取得元 SAPテーブル：VBRK、フィールド：FKART 例 F2G2S1L2 | |||
| 販売オーダー番号 SalesOrderNumber | 請求書につながった元の販売オーダーの識別子です。 | ||
| 説明 販売オーダー番号は、請求伝票を先行する販売アクティビティにリンクします。単一の販売オーダーから1つ以上の請求書が生成される可能性があり、このリンクが完全な伝票フローを提供します。 この属性は、真のエンドツーエンドの「受注から現金回収まで」分析にとって非常に重要です。これにより、プロセスビューを上流に拡張し、請求の問題と販売オーダーの作成または履行フェーズにおける潜在的な根本原因とを結びつけることができます。例えば、オーダーが履行されてから始まる全体的な請求書生成サイクルタイムの計算に役立ちます。 その重要性 請求書を元の販売注文にリンクさせ、請求書発行だけでなく受注から入金までのプロセスのより広範なエンドツーエンドビューを可能にします。 取得元 SAPテーブル：VBRP（請求伝票明細データ）、フィールド：AUBEL 例 100001231000045610000789 | |||
| 通貨 Currency | 請求金額の通貨コード。 | ||
| 説明 この属性は、請求額がUSD、EUR、JPYなどのどの通貨で表示されているかを指定します。これにより、すべての貨幣価値に必要なコンテキストが提供されます。 グローバル組織において、通貨は正確な財務分析と報告のために不可欠です。すべての金額を共通の報告通貨に変換することで財務データの適切な集計を可能にし、異なる現地通貨を持つ地域間で請求パフォーマンスを比較することを可能にします。 その重要性 すべての貨幣価値に不可欠なコンテキストを提供し、特に多国籍企業における正確な財務分析とレポート作成を保証します。 取得元 SAPテーブル：VBRK、フィールド：WAERK 例 USDEURGBP | |||
受注から入金まで（請求・債権回収）活動
| アクティビティ | 説明 | ||
|---|---|---|---|
| 入金適用/消込済み | 顧客からの入金が照合され、未決済の請求書明細が売掛金補助元帳から消し込まれる瞬間を表します。このアクティビティにより、財務的観点から取引が完了します。 | ||
| その重要性 入金消込プロセスの効率性を測定します。ここでの遅延は、顧客口座の真の状態を誤って伝え、回収チームにとって不必要な作業を生み出す可能性があります。 取得元 このイベントは、元の請求書の会計伝票明細における消込日付（BSEG-AUGDT）によって捕捉されます。この日付は、消込伝票が明細を消し込んだときに設定されます。 取得 請求書明細のBSEG/ACDOCAテーブルの消込日付（AUGDT）フィールドから取得されます。 イベントタイプ explicit | |||
| 請求書がクローズ済み | このアクティビティは、正常に支払いが行われた請求書の最終状態を示します。「キャッシュ適用/照合済み」と機能的には同じであり、この請求書に関するプロセスが完了したことを意味します。 | ||
| その重要性 プロセスの主要な「ハッピーパス」の終了イベントとして機能します。この時点までの総サイクルタイムを測定することで、請求および売掛金ライフサイクルのエンドツーエンドの全体像を把握できます。 取得元 会計伝票の顧客明細のステータスから推測されます。消込日付（BSEG-AUGDT）と消込伝票（BSEG-AUGBL）フィールドが入力されたときに、明細はクローズまたは「消込済み」とされます。 取得 請求書明細のBSEG/ACDOCAテーブルにおける消込日付（AUGDT）の入力から推測されます。 イベントタイプ inferred | |||
| 請求書が会計に転記された | 請求伝票が財務会計モジュールに正常に転記されたことを表します。これは、請求書が正式な売掛金明細となり、総勘定元帳にエントリが作成される重要な節目です。 | ||
| その重要性 このアクティビティは、請求書が法的な財務伝票であることを確認します。生成から転記までの時間は、内部処理効率を示す主要なパフォーマンス指標です。 取得元 このイベントは、対応する会計伝票が作成されたときに捕捉されます。請求伝票（VBRK-VBELN）は、VBRK-BELNRを介して会計伝票（BKPF-BELNR）にリンクされ、転記日付はBKPF-BUDATです。 取得 請求伝票にリンクされたBKPFテーブルの会計伝票の転記日付（BUDAT）から取得されます。 イベントタイプ explicit | |||
| 請求書生成済み | このアクティビティは、システムで請求伝票が作成されたことを示します。これは、ユーザーがVF01のようなトランザクションを実行したとき、またはバックグラウンドジョブが請求書を作成したときに捕捉される明確なイベントであり、請求伝票ヘッダーテーブルに新しいエントリが作成されます。 | ||
| その重要性 これは請求プロセスの主要な開始イベントです。オーダー履行からこのアクティビティまでの時間を分析することは、請求書生成サイクルタイムを測定し、初期のプロセス遅延を特定するために不可欠です。 取得元 作成時にSAP S/4HANAのVBRKテーブル（請求伝票：ヘッダーデータ）に記録されます。作成日付（VBRK-ERDAT）と時刻（VBRK-ERZET）がタイムスタンプとして機能します。 取得 イベントは、VBRKテーブルの請求伝票レコードの作成タイムスタンプから取得されます。 イベントタイプ explicit | |||
| 顧客からの入金受領 | このアクティビティは、顧客からの入金が財務システムに転記されたことを示します。この段階ではまだ特定の請求書に支払いが適用されていない可能性がありますが、資金は記録されています。 | ||
| その重要性 売掛金回収期間（DSO）を計算するための重要なマイルストーンです。これは、消込がまだ保留中であっても、現金の受領を意味します。 取得元 顧客支払伝票（通常、テーブルBKPFの伝票タイプ「DZ」）の転記日付（BKPF-BUDAT）から取得されます。 取得 イベントは、BKPF/BSEGにおける支払伝票の作成に基づいています。 イベントタイプ explicit | |||
| クレジットメモ作成 | このアクティビティは、過剰請求の修正や返品に対するクレジットを提供するために顧客に発行される貸方メモの作成を表します。これは多くの場合、元の請求書にリンクされます。 | ||
| その重要性 請求後の財務調整につながる問題を浮き彫りにします。クレジットメモを分析することで、価格設定エラー、製品の問題、または収益漏れの他の根本原因を特定できます。 取得元 クレジットメモに特化した請求タイプ（例：「G2」）を持つ新しい請求伝票（VBRK内）として明示的に作成されます。多くの場合、元の販売注文または請求書を参照します。 取得 クレジットメモ請求タイプでVBRKに請求伝票が作成された際に取得されます。 イベントタイプ explicit | |||
| 支払リマインダー発行済み | 顧客に対し、期限を過ぎた請求書に関する支払いリマインダーまたは督促状を送付することを示します。これは、自動督促処理によって生成される明確なイベントです。 | ||
| その重要性 督促プロセスの有効性を分析できます。リマインダーが支払いを加速するかどうか、どの督促レベルが最も効果的であるかを判断するのに役立ちます。 取得元 請求書の未決済明細に対して督促実行（トランザクションF150）が実行された際、督促履歴テーブル（MAHNV, MHND）に記録されます。 取得 督促履歴テーブルに記録された督促通知の実行日付から取得されます。 イベントタイプ explicit | |||
| 支払期日到達 | 合意された支払条件に従って、請求書の支払いが正式に期日となる日付を表す計算済みイベントです。これはトランザクションイベントではなく、請求書データから導出されます。 | ||
| その重要性 これは、期日内支払いパフォーマンスを測定し、顧客の支払い行動を分析するための重要なベースラインを提供します。期日内の支払いと延滞中の支払いを区別するのに役立ちます。 取得元 支払基準日（BSEG-ZFBDT）と、会計伝票の顧客明細項目に格納されている支払条件に基づいて計算されます。 取得 会計伝票明細（BSEG）に見つかる支払基準日に支払条件の日数を加算して導出されます。 イベントタイプ calculated | |||
| 請求再作業が特定された | 請求書がキャンセルされ、その後同じ販売注文に対して新しい請求書が生成された再作業ループを特定する計算済みイベントです。これは単一のトランザクションではなく、イベントのパターンです。 | ||
| その重要性 修正インスタンスを定量化することで、請求再作業率KPIを直接サポートします。これにより、非効率性を特定し、請求プロセスにおける品質不良のコストを測定するのに役立ちます。 取得元 このパターンは、「請求書キャンセル済み」イベントに続いて、同じソース伝票（販売オーダー番号など）にまで遡ることができる新しい「請求書発行済み」イベントを特定することで計算されます。 取得 同じ販売注文参照に対して「請求書キャンセル済み」と「請求書生成済み」のシーケンスを検出することによって導出されます。 イベントタイプ calculated | |||
| 請求書取消し済み | 以前に作成された請求書がキャンセルされたときに発生します。これは通常、対応するキャンセル伝票の作成を伴います。これにより、元の請求書とその会計上の影響が効果的に取り消されます。 | ||
| その重要性 再作業、修正、または請求エラーを示します。キャンセルの頻度が高い場合、受注入力または請求設定における重要な上流の問題を示唆しています。 取得元 キャンセル請求伝票（例：伝票タイプ「S1」）が作成されたときに取得されます。VBRKのこの新しい伝票は、VBRK-SFAKNフィールドの元の請求書番号を参照します。 取得 イベントは、元の請求書を参照するVBRKにおけるキャンセル伝票の作成日付から取得されます。 イベントタイプ explicit | |||
| 請求書転記ブロック | このイベントは、請求書が作成されたものの、与信チェックやデータの不整合など様々な理由により、財務会計への転記が自動的にブロックされた場合に発生します。このステータスは、請求伝票の転記ステータスフィールドから推測されます。 | ||
| その重要性 請求書が作成されたものの、すぐに財務部門にリリースされず、キャッシュ回収サイクル全体を遅らせるボトルネックを特定します。これは、データ品質の問題や信用管理の問題の主要な指標です。 取得元 請求伝票ヘッダーテーブル（VBRK-RFBSK）の転記ステータスフィールドから推測されます。「A」（FIへの転送のために請求伝票がブロックされている）のようなステータスは、ブロックを示します。 取得 請求書が生成された直後の転記ステータスフィールド（VBRK-RFBSK）の値を確認することによって推測されます。 イベントタイプ inferred | |||
| 顧客へ請求書送付 | このアクティビティは、請求書が顧客に送信された時点（例：印刷、電子メール、EDI経由）を示します。捕捉メカニズムは、SAPの出力管理設定によって異なります。 | ||
| その重要性 顧客の視点から見た支払期限の正式な開始日です。請求書送付の遅延は、売上債権回転日数（DSO）とキャッシュフローに直接影響します。 取得元 出力管理テーブル（旧来の方法ではNASTなど、またはそのS/4HANAでの同等機能）に明示的にログが記録される場合があります。明示的にログが記録されていない場合、「請求書が会計に転記された」と同時期に発生したと推測されることがよくあります。 取得 請求書出力タイプに関連付けられたタイムスタンプについては、出力管理テーブルの処理ログを確認してください。 イベントタイプ explicit | |||
| 顧客紛争が開始された | このアクティビティは、顧客が請求書に異議を申し立て、それがシステムに正式にイベントログとして記録されたときに発生します。これにはSAP Dispute Managementモジュールの使用が必要です。 | ||
| その重要性 請求の正確性、製品品質、またはサービス提供における、支払遅延につながる問題を浮き彫りにします。紛争理由を分析することで、根本原因に対処し、顧客満足度を向上させるのに役立ちます。 取得元 紛争管理テーブル（例：UDM_CASE）で紛争ケースが作成された際に記録されます。これは会計伝票明細にリンクされます。 取得 請求書にリンクされた紛争ケースレコードの作成タイムスタンプから取得されます。 イベントタイプ explicit | |||
抽出ガイド
ステップ
- 前提条件: SAP S/4HANAで、Core Data Services (CDS) ビューを照会するために必要な権限を持つユーザーアカウントがあることを確認してください。具体的には、I_BillingDocument、I_JournalEntryItem、I_Customer、I_Outgmgmtdocumentoutputreq、I_DisputeCase、I_DunningHistoryなどのビューへの読み取りアクセスが必要です。
- データ抽出ツールへのアクセス: SAP S/4HANAシステムにログインします。SAP HANA Studio、SAP HANAクライアントを介して接続されたDBeaver、またはSAP Analysis for Microsoft Excelプラグインなど、様々なツールを使用してCDSビューに対してSQLクエリを実行できます。このガイドでは、標準のSQLクライアントを想定しています。
- システムパラメーターの特定: クエリを実行する前に、分析の対象となる特定の会社コードと関連する日付範囲を特定します。管理しやすいクエリ実行時間を確保するため、まずは過去3〜6ヶ月間のデータなど、限定的な範囲から始めることをお勧めします。
- SQLクエリの準備: このドキュメントの「クエリ」セクションに提供されている完全なSQLクエリを、選択したSQLクライアントにコピーします。
- プレースホルダーのカスタマイズ: クエリ内のプレースホルダー値を変更します。「'YYYY-MM-DD'」を希望の開始日と終了日に置き換えます。「'XXXX'」を対象の会社コードに置き換えます。また、システム構成に基づいて、クレジットメモのドキュメントタイプ（例：「'G2'」）のプレースホルダーを調整する必要がある場合があります。
- クエリの実行: 変更したSQLクエリをSAP S/4HANAデータベースに対して実行します。実行時間は、選択した日付範囲内のデータ量によって異なります。
- 結果の確認: クエリの完了後、出力を確認します。結果セットは、各行が請求プロセスにおける単一の活動を表すフラットなテーブルである必要があります。これがイベントログです。
- データ変換（必要な場合）: このクエリは、クリーンなイベントログ形式を生成するように設計されています。ただし、プロセスサイクルのタイムスタンプ形式がプロセスサイクルのツールと互換性があることを確認してください。このクエリは
ABAP_SYSTEM_UTCL_TO_TIMESTAMPを使用して標準UTCタイムスタンプに変換するため、広く互換性があるはずです。 - イベントログのエクスポート: SQLクライアントから完全な結果セットをCSVファイルにエクスポートします。文字化けを防ぐために、ファイルがUTF-8エンコードされていることを確認します。
- ProcessMindへのアップロード: 生成されたCSVファイルをProcessMindプラットフォームにアップロードし、InvoiceNumber、ActivityName、EventTimeなどのファイルからの列をツール内の対応するフィールドにマッピングします。
設定
- 日付範囲: 初期共通テーブル式（CTE）の
WHERE句で開始日と終了日を設定します。データ量とパフォーマンスのバランスを取るため、最初の分析では3〜6ヶ月の範囲が推奨されます。フィルターはBillingDocumentDateに適用されます。 - 会社コード: 関連する法人に抽出を限定するため、1つ以上の
CompanyCode値でフィルターをかけます。これはデータ範囲を管理するための重要なフィルターです。 - 伝票タイプ: クエリには、
BillingDocumentTypeに基づいてクレジットメモを識別するロジックが含まれています。例えば('G2', 'CR')のようなプレースホルダーを、貴社でクレジットメモに使用されている特定の伝票タイプで設定する必要があります。 - 前提条件: 基盤となるCDSビューへのアクセスが必須です。これには、SAPセキュリティチームによって割り当てられた特定のロールと権限が必要です。さらに、「顧客紛争開始」や「支払リマインダー発行」などの活動については、それぞれのSAPモジュール、SAP Dispute ManagementおよびSAP Financials Dunningがシステムでアクティブに使用されている必要があります。
- パフォーマンス: クエリは複数の結合とユニオンを使用します。非常に大規模なデータセット（例えば数年分のデータ）の場合、オフピーク時間帯に実行するか、より制限的なフィルターを適用して初期データ取得を制限することを検討してください。
a クエリ例 sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime;ステップ
- 前提条件: SAP S/4HANAで、Core Data Services (CDS) ビューを照会するために必要な権限を持つユーザーアカウントがあることを確認してください。具体的には、I_BillingDocument、I_JournalEntryItem、I_Customer、I_Outgmgmtdocumentoutputreq、I_DisputeCase、I_DunningHistoryなどのビューへの読み取りアクセスが必要です。
- データ抽出ツールへのアクセス: SAP S/4HANAシステムにログインします。SAP HANA Studio、SAP HANAクライアントを介して接続されたDBeaver、またはSAP Analysis for Microsoft Excelプラグインなど、様々なツールを使用してCDSビューに対してSQLクエリを実行できます。このガイドでは、標準のSQLクライアントを想定しています。
- システムパラメーターの特定: クエリを実行する前に、分析の対象となる特定の会社コードと関連する日付範囲を特定します。管理しやすいクエリ実行時間を確保するため、まずは過去3〜6ヶ月間のデータなど、限定的な範囲から始めることをお勧めします。
- SQLクエリの準備: このドキュメントの「クエリ」セクションに提供されている完全なSQLクエリを、選択したSQLクライアントにコピーします。
- プレースホルダーのカスタマイズ: クエリ内のプレースホルダー値を変更します。「'YYYY-MM-DD'」を希望の開始日と終了日に置き換えます。「'XXXX'」を対象の会社コードに置き換えます。また、システム構成に基づいて、クレジットメモのドキュメントタイプ（例：「'G2'」）のプレースホルダーを調整する必要がある場合があります。
- クエリの実行: 変更したSQLクエリをSAP S/4HANAデータベースに対して実行します。実行時間は、選択した日付範囲内のデータ量によって異なります。
- 結果の確認: クエリの完了後、出力を確認します。結果セットは、各行が請求プロセスにおける単一の活動を表すフラットなテーブルである必要があります。これがイベントログです。
- データ変換（必要な場合）: このクエリは、クリーンなイベントログ形式を生成するように設計されています。ただし、プロセスサイクルのタイムスタンプ形式がプロセスサイクルのツールと互換性があることを確認してください。このクエリは
ABAP_SYSTEM_UTCL_TO_TIMESTAMPを使用して標準UTCタイムスタンプに変換するため、広く互換性があるはずです。 - イベントログのエクスポート: SQLクライアントから完全な結果セットをCSVファイルにエクスポートします。文字化けを防ぐために、ファイルがUTF-8エンコードされていることを確認します。
- ProcessMindへのアップロード: 生成されたCSVファイルをProcessMindプラットフォームにアップロードし、InvoiceNumber、ActivityName、EventTimeなどのファイルからの列をツール内の対応するフィールドにマッピングします。
設定
- 日付範囲: 初期共通テーブル式（CTE）の
WHERE句で開始日と終了日を設定します。データ量とパフォーマンスのバランスを取るため、最初の分析では3〜6ヶ月の範囲が推奨されます。フィルターはBillingDocumentDateに適用されます。 - 会社コード: 関連する法人に抽出を限定するため、1つ以上の
CompanyCode値でフィルターをかけます。これはデータ範囲を管理するための重要なフィルターです。 - 伝票タイプ: クエリには、
BillingDocumentTypeに基づいてクレジットメモを識別するロジックが含まれています。例えば('G2', 'CR')のようなプレースホルダーを、貴社でクレジットメモに使用されている特定の伝票タイプで設定する必要があります。 - 前提条件: 基盤となるCDSビューへのアクセスが必須です。これには、SAPセキュリティチームによって割り当てられた特定のロールと権限が必要です。さらに、「顧客紛争開始」や「支払リマインダー発行」などの活動については、それぞれのSAPモジュール、SAP Dispute ManagementおよびSAP Financials Dunningがシステムでアクティブに使用されている必要があります。
- パフォーマンス: クエリは複数の結合とユニオンを使用します。非常に大規模なデータセット（例えば数年分のデータ）の場合、オフピーク時間帯に実行するか、より制限的なフィルターを適用して初期データ取得を制限することを検討してください。
a クエリ例 sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime;