受注から入金までの請求・請求書発行向けデータテンプレート
受注から入金までの請求・請求書発行向けデータテンプレート
- 収集を推奨する属性
- 追跡する主なアクティビティ
- SAP S/4HANAからのデータ抽出ガイド
受注から入金までの請求・請求書発行に関する属性
| 名前 | 説明 | ||
|---|---|---|---|
| 請求書番号 InvoiceNumber | 請求伝票を一意に識別する番号で、請求プロセスの主要なケース識別子として使われます。 | ||
| 説明 SAPで請求伝票番号とも呼ばれる請求書番号は、各請求取引を一意に識別します。請求書の作成や転記から入金、消込まで、関連するすべてのアクティビティを結び付ける中心的なキーです。 プロセスマイニングでは、ケースを関連付けるために欠かせない属性です。同じ請求書番号を持つすべてのイベントを1つのプロセスインスタンスにまとめることで、請求書ごとのライフサイクルを最初から最後まで分析できます。これにより、サイクルタイムの追跡、逸脱の特定、請求書ごとの処理経過の分析が可能になります。 重要な理由 関連するすべての請求アクティビティを1つのケースに結び付ける基本的な識別子であり、プロセス全体の分析を可能にします。 入手先 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などの主要指標を地域間で比較できます。比較を通じて、プロセスの実行方法、コンプライアンス、効率における地域差を把握し、対象を絞った改善や優れた業務手順の標準化につなげられます。 重要な理由 地域ごとの請求パフォーマンスを比較し、地域間の差を特定してプロセスの標準化に役立てられます。 入手先 顧客マスターデータテーブルKNA1(項目:REGIO)から取得し、請求書ヘッダーの支払人ID(VBRK-KUNRG)を介して紐づけます。 例 カリフォルニア州ニューヨーク州テキサス州バハ・カリフォルニア州 | |||
| 支払期日 PaymentDueDate | 顧客が請求書を支払う予定の日付です。 | ||
| 説明 支払期日は、請求日と合意した支払条件に基づいて算出します。請求書が延滞になる前に入金を受ける期限を示します。 債権回収の効果やキャッシュフロー予測を管理するうえで欠かせない属性です。期日内支払率の重要業績評価指標の算出や、滞留期間レポートでの請求書の分類に直接使います。支払期日と実際の入金日の差を分析することで、支払条件の効果を評価できます。 重要な理由 顧客の支払期限を定めるため、期日内支払率の算出や売掛金管理に欠かせません。 入手先 この日付は直接保存されません。請求日(VBRK-FKDAT)と支払条件キー(VBRK-ZTERM)に基づき、SAP標準の日付決定機能を使って算出します。 例 2023-04-192023-05-012023-06-17 | |||
| 終了時刻 EndTime | アクティビティまたはイベントが完了した時刻を示す正確なタイムスタンプです。 | ||
| 説明 終了時刻は、アクティビティの完了時点を示します。プロセスマイニングでは、同じケース内で次に発生するアクティビティの開始時刻から推定することがよくあります。システムに開始イベントと終了イベントの両方が記録されている場合は、そのデータを直接取得できます。 個々のアクティビティの処理時間を算出するには、この属性が欠かせません。終了時刻から開始時刻を差し引くと、各工程にかかった時間を測定できます。請求承認段階の遅延など、ボトルネックの分析に役立ちます。 重要な理由 各アクティビティの正確な所要時間(処理時間)を算出できるため、ボトルネック分析の基礎となります。 入手先 プロセスマイニングで使用する派生属性です。通常は、ケース内で次に発生するイベントの開始時刻から算出します。シナリオによっては、完了時刻を記録する専用テーブルがある場合もあります。 例 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| 請求日 InvoiceDate | 請求書を顧客に発行した正式な日付です。 | ||
| 説明 SAPで請求日とも呼ばれる請求書の日付は、多くの財務計算の起点となります。この日付を基に、支払条件、支払期日、売掛金の経過日数が決まります。 財務分析では、ケース単位で管理する重要な属性です。売上債権回転日数(DSO)の重要業績評価指標の算出や、未決済請求書の滞留期間レポートの作成に使われます。これらは、キャッシュフローと債権回収の管理に欠かせません。 重要な理由 財務計算の基準となる日付であり、DSO、支払期日、請求書の滞留期間分析の起点となります。 入手先 SAPテーブル:VBRK、項目:FKDAT 例 2023-03-202023-04-012023-05-18 | |||
| 請求金額 InvoiceAmount | 請求書の正味合計金額です。 | ||
| 説明 この属性は、請求対象となる商品やサービスの税抜き合計金額を表します。請求書ごとの基本的な財務データです。 請求金額は幅広い分析に使えます。金額別にプロセスを分類し、高額の請求書で処理方法が異なるか、遅延が多いかを確認できます。また、財務報告や未回収売掛金の総額算出の基礎にもなります。 重要な理由 各請求書の金額を数値化し、金額に基づく分析、債権回収の優先順位付け、財務への影響評価を可能にします。 入手先 SAPテーブル:VBRK、項目:NETWR 例 1500.0025000.50125.75 | |||
| 顧客名 CustomerName | 請求書の発行先となる顧客の名前です。 | ||
| 説明 この属性は、請求先顧客の正式名称を示します。SAPの顧客マスターデータから取得します。 顧客別にプロセスを分析すると、特定の顧客に固有の傾向を特定できます。たとえば、支払いが常に遅れる顧客、異議申し立てが多い顧客、請求プロセスが特に非効率な顧客を把握できます。これにより、顧客ごとの関係管理や債権回収の方針を調整できます。 重要な理由 顧客ごとの分析を可能にし、特定の顧客における支払行動、異議申し立ての頻度、プロセスの非効率な箇所を特定できます。 入手先 顧客マスターデータテーブルKNA1(項目:NAME1)から取得し、請求書ヘッダーの支払人ID(VBRK-KUNRG)を介して紐づけます。 例 スプリングフィールド発電所クイック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財務会計における基本的な組織単位で、財務諸表を作成する法的に独立した会社を表します。各請求伝票には、特定の会社コードが割り当てられます。 複数の会社で構成される組織では、会社コードごとの分析が欠かせません。法的組織ごとにプロセスのパフォーマンス、DSOなどの財務指標、コンプライアンスを比較できます。また、すべてのプロセスダッシュボードで、組織を大きな単位で絞り込む際にも使えます。 重要な理由 法的組織単位ごとにプロセスを分析できるため、組織全体でのパフォーマンス比較や財務情報の連結に役立ちます。 入手先 SAPテーブル:VBRK、項目:BUKRS 例 10002000US01 | |||
| 最終データ更新日時 LastDataUpdate | このイベントのデータが最後に抽出または更新された日時を示すタイムスタンプです。 | ||
| 説明 この属性には、ソースシステムから最後にデータを取得した日時が記録されます。分析対象データがどの程度新しいかを把握するための重要なメタデータ項目です。 分析結果の新しさを確認し、データ更新スケジュールを管理する際に使います。プロセスマイニングのダッシュボードやインサイトに基づいて意思決定する際、関係者がデータの鮮度を把握できるようにします。 重要な理由 データの鮮度を示します。分析への信頼性を保ち、現在の業務状況との関連性を理解するうえで重要です。 入手先 データ抽出・ロード(ETL)処理中に生成され、各レコードに付与されるタイムスタンプです。 例 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
| 受注番号 SalesOrderNumber | 請求書の元となった受注を識別する番号です。 | ||
| 説明 受注番号を使うと、請求伝票を先行する販売活動に関連付けられます。1件の受注から複数の請求書が発行される場合もあり、この関連付けによって伝票の流れを全体的に把握できます。 受注から入金までのプロセスをエンドツーエンドで分析するには、この属性が欠かせません。分析対象を請求より前の工程まで広げ、請求上の問題と、受注の作成や履行段階にある原因候補を結び付けられます。たとえば、受注の履行時点から請求書発行までのサイクルタイムを算出できます。 重要な理由 請求書を元の受注に関連付けることで、請求だけでなく、受注から入金までのプロセスをより広くエンドツーエンドで把握できます。 入手先 SAPテーブル:VBRP(請求伝票明細データ)、項目:AUBEL 例 100001231000045610000789 | |||
| 支払条件 PaymentTerms | 支払い可能期間など、支払い条件を定義するコードです。 | ||
| 説明 支払条件は、請求書の支払期限を定めるために顧客と合意する、あらかじめ設定された条件です。「Net 30」(30日以内に支払い)や「2/10 Net 30」(10日以内の支払いで2%割引、そうでない場合は30日以内に支払い)などがあります。 支払条件ごとに分析すると、その効果を評価できます。各条件と実際の入金までの日数を照らし合わせることで、早期の支払いにつながる条件を特定し、キャッシュフローの改善に向けて条件を見直せます。 重要な理由 合意した支払いスケジュールを定義するため、顧客から期日どおりに支払いを受けるうえで、どの条件が効果的かを分析できます。 入手先 SAPテーブル:VBRK、項目:ZTERM 例 Z030Z060ZB60 | |||
| 支払状況 PaymentStatus | 未決済、支払済み、支払期限超過など、請求書の現在の支払状況です。 | ||
| 説明 支払状況を見ると、請求書が回収プロセスのどの段階にあるかを把握できます。SAPの単一の項目として存在するものではなく、対応する会計伝票の消込状況を確認して判定します。 未回収請求書の経過期間を確認するダッシュボードには、この属性が欠かせません。未回収の請求書を状況や経過期間で分類できるため、債権回収チームが優先順位を付けて対応できます。状況の変化を追跡すれば、回収プロセス自体の進捗も確認できます。 重要な理由 請求書の回収状況をひと目で把握できるため、売掛金の管理や回収対応の優先順位付けに役立ちます。 入手先 BSID(未消込明細)やBSAD(消込済み明細)などの財務テーブルで、会計伝票(VBRK-BELNR)の消込状況を確認して判定します。 例 未決済支払済み支払期限超過一部支払済み | |||
| 期日どおりの支払い IsPaidOnTime | 請求書が支払期日までに支払われたかどうかを示す真偽値です。 | ||
| 説明 実際の支払日と予定された支払期日を比較して算出する属性です。期日どおりに支払われた場合は「true」、遅れた場合は「false」になります。 このフラグを使うと、期日どおりの支払率に関する重要業績評価指標(KPI)の算出や可視化が簡単になります。期日より遅れて支払われた請求書と、期日どおりに支払われた請求書を簡単に絞り込み、分類して分析できます。顧客、地域、支払条件など、支払いの遅れにつながる要因の傾向を見つけるのにも役立ちます。 重要な理由 各請求書が期日どおりか遅延かを明確に示し、期日どおりの支払率に関する重要業績評価指標(KPI)の測定を簡単にします。 入手先 計算項目です。「顧客からの入金」アクティビティのタイムスタンプと「PaymentDueDate」属性の値を比較します。 例 truefalse | |||
| 異議申し立ての理由 CustomerDisputeReason | 請求書に対して顧客から申し立てられた異議の理由です。 | ||
| 説明 顧客が請求内容に異議を申し立てた場合、その理由が記録されることがあります。価格の誤り、数量の不一致、商品の破損などが理由として挙げられます。この情報は、SAPの紛争管理モジュールやテキストメモに保存されている場合があります。 異議の理由を分析することは、請求エラー率の重要業績評価指標(KPI)や関連するエラー分析の基礎となります。請求の誤りの根本原因を特定し、前工程にある構造的な問題への対処、請求書の品質向上、顧客満足度の向上につなげられます。 重要な理由 請求書に異議が申し立てられた理由を示し、請求エラーや顧客の不満につながる根本原因を直接把握できます。 入手先 SAP紛争管理を使用している場合は、UDM_DISPUTEなどのテーブルで確認できます。使用していない場合は、関連伝票の理由コードやテキスト項目から特定できることがあります。 例 価格の誤り数量の不一致受領した商品の破損 | |||
| 請求伝票タイプ BillingDocumentType | 請求書、クレジットメモ、取消伝票など、請求伝票を分類するコードです。 | ||
| 説明 請求伝票タイプは、請求プロセス内の取引を分類する重要な項目です。伝票の番号範囲や会計転記ルールなど、伝票の処理方法を制御します。 この属性でプロセスを絞り込み、特定の種類の取引を分析できます。たとえば、クレジットメモだけを対象にしたプロセスビューを作成し、金額訂正の理由や処理の流れを確認できます。また、通常の請求書と取消伝票を分けて分析すれば、主な請求プロセスをより明確に把握できます。 重要な理由 取引を分類し、通常の請求書、クレジットメモ、取消伝票など、特定の伝票フローに絞った分析ができます。 入手先 SAPテーブル:VBRK、項目:FKART 例 F2G2S1L2 | |||
| 通貨 Currency | 請求金額の通貨コードです。 | ||
| 説明 この属性は、請求金額の通貨(USD、EUR、JPYなど)を示し、すべての金額データを解釈するために必要な情報を提供します。 グローバルに事業を展開する組織では、正確な財務分析と報告に通貨情報が欠かせません。金額を共通の報告通貨に換算して財務データを適切に集計できるほか、現地通貨が異なる地域間で請求業務のパフォーマンスを比較できます。 重要な理由 すべての金額データを正確に分析・報告するために必要な情報を提供します。特に複数の国や地域で事業を展開する場合に重要です。 入手先 SAPテーブル:VBRK、項目:WAERK 例 USDEURGBP | |||
受注から入金までの請求・請求書発行に関するアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| 入金の消込・照合 | 顧客からの入金を照合し、売掛金補助元帳の未決済請求書項目に消し込んだ時点を示します。財務上、このアクティビティをもって取引が完了します。 | ||
| 重要な理由 入金消込プロセスの効率を測定します。ここで遅延が発生すると、顧客口座の実際の状況が正しく反映されず、債権回収チームに不要な作業が生じる可能性があります。 入手先 元の請求書の会計伝票明細にある消込日(BSEG-AUGDT)からイベントを取得します。消込伝票によって項目が消し込まれると、この日付が記録されます。 記録 請求書明細に対応するBSEG/ACDOCAテーブルの消込日(AUGDT)項目から取得します。 イベントタイプ explicit | |||
| 請求書の会計転記 | 請求伝票が財務会計モジュールに正常に転記されたことを示します。請求書が正式な売掛金項目となり、総勘定元帳に仕訳が作成される重要な節目です。 | ||
| 重要な理由 このアクティビティにより、請求書が法的な効力を持つ財務文書になったことを確認できます。発行から転記までの時間は、社内処理の効率を示す重要業績評価指標です。 入手先 対応する会計伝票が作成された時点でイベントを取得します。請求伝票(VBRK-VBELN)は、VBRK-BELNRを介して会計伝票(BKPF-BELNR)に紐づき、転記日はBKPF-BUDATに記録されます。 記録 請求伝票に紐づくBKPFテーブルの会計伝票から、転記日(BUDAT)を取得します。 イベントタイプ explicit | |||
| 請求書の決済完了 | 正常に支払われた請求書の最終状態を示すアクティビティです。機能上は「入金の消込・照合」と同じで、この請求書に関するプロセスが完了したことを示します。 | ||
| 重要な理由 プロセスの理想経路における主要な終了イベントです。この時点までの総サイクルタイムを測定することで、請求業務の開始から完了までを把握できます。 入手先 会計伝票の顧客明細のステータスから判定します。消込日(BSEG-AUGDT)と消込伝票(BSEG-AUGBL)の項目に値が入ると、項目はクローズ、つまり消込済みとなります。 記録 請求書明細に対応するBSEG/ACDOCAテーブルの消込日(AUGDT)に値が入っているかどうかで判定します。 イベントタイプ inferred | |||
| 請求書発行 | このアクティビティは、システムで請求伝票が作成されたことを示します。ユーザーがVF01などのトランザクションを実行したとき、またはバックグラウンドジョブが請求書を作成したときに明示的なイベントとして記録され、請求伝票ヘッダーテーブルに新しいレコードが追加されます。 | ||
| 重要な理由 これは請求プロセスの主要な開始イベントです。受注の履行からこのアクティビティまでの時間を分析することで、請求書発行のサイクルタイムを測定し、プロセスの初期段階における遅延を特定できます。 入手先 作成時にSAP S/4HANAのVBRKテーブル(請求伝票:ヘッダーデータ)に記録されます。作成日(VBRK-ERDAT)と作成時刻(VBRK-ERZET)がタイムスタンプとして使われます。 記録 VBRKテーブルの請求伝票レコードに記録された作成タイムスタンプからイベントを取得します。 イベントタイプ explicit | |||
| 顧客からの入金 | このアクティビティは、顧客からの入金が財務システムに転記されたことを示します。この時点では特定の請求書に消し込まれていない場合もありますが、入金自体は記録されています。 | ||
| 重要な理由 売上債権回転日数(DSO)の算出に欠かせない節目です。消込が完了していなくても、入金があったことを示します。 入手先 顧客入金伝票(通常、BKPFテーブルの伝票タイプ「DZ」)の転記日(BKPF-BUDAT)から取得します。 記録 BKPF/BSEGでの入金伝票の作成に基づくイベントです。 イベントタイプ explicit | |||
| クレジットメモの作成 | このアクティビティは、過剰請求の訂正や返品商品の返金のために顧客へ発行するクレジットメモの作成を示します。元の請求書に紐づくことがよくあります。 | ||
| 重要な理由 請求後に金額の調整が必要となった問題を示します。クレジットメモを分析することで、価格設定の誤り、製品の問題、その他の売上漏れの根本原因を特定できます。 入手先 クレジットメモ用の請求タイプ(例:「G2」)を指定し、VBRKに新しい請求伝票として明示的に作成します。元の受注または請求書を参照することがよくあります。 記録 クレジットメモ用の請求タイプでVBRKに請求伝票が作成された時点で取得します。 イベントタイプ explicit | |||
| 支払期日の到来 | 合意した支払条件に基づき、請求書の支払期日を示す計算イベントです。取引イベントではなく、請求書のデータから算出します。 | ||
| 重要な理由 期日どおりの支払状況を測定し、顧客の支払行動を分析するための重要なベースラインです。期日内の支払いと延滞を区別するのに役立ちます。 入手先 支払基準日(BSEG-ZFBDT)と、会計伝票の顧客明細に記録された支払条件に基づいて算出します。 記録 会計伝票明細(BSEG)に記録された支払基準日に、支払条件の日数を加算して算出します。 イベントタイプ calculated | |||
| 支払督促の送付 | 支払期日を過ぎた請求書について、顧客に支払リマインダーまたは督促通知を送付したことを示します。自動督促手順によって生成される明示的なイベントです。 | ||
| 重要な理由 督促プロセスの効果を分析できます。リマインダーによって支払いが早まるか、どの督促レベルが最も効果的かを確認できます。 入手先 請求書の未決済項目に対して督促実行(トランザクションF150)を行うと、督促履歴テーブル(MAHNV、MHND)に記録されます。 記録 督促履歴テーブルに記録された督促通知の実行日から取得します。 イベントタイプ explicit | |||
| 請求書の取消 | 作成済みの請求書が取り消されると発生します。通常は、対応する取消伝票が作成されます。これにより、元の請求書とその会計上の影響が取り消されます。 | ||
| 重要な理由 手戻り、修正、請求エラーを示します。取消の頻度が高い場合は、受注入力や請求設定など、上流工程に大きな問題がある可能性があります。 入手先 取消請求伝票(例:伝票タイプ「S1」)が作成された時点で取得します。VBRKの新しい伝票では、VBRK-SFAKN項目に元の請求書番号が記録されます。 記録 元の請求書を参照する取消伝票がVBRKに作成された日付からイベントを取得します。 イベントタイプ explicit | |||
| 請求書の転記ブロック | 請求書が作成されたものの、与信チェックやデータの不整合などの理由で、財務会計への転記が自動的にブロックされた場合に発生するイベントです。この状態は、請求伝票の転記ステータス項目から判定します。 | ||
| 重要な理由 請求書が作成されても財務会計にすぐにリリースされず、入金回収サイクル全体が遅れるボトルネックを特定できます。データ品質や与信管理の問題を示す重要な指標です。 入手先 請求伝票ヘッダーテーブルの転記ステータス項目(VBRK-RFBSK)から判定します。「A」(請求伝票のFIへの転送がブロックされている)などのステータスは、ブロックを示します。 記録 請求書の発行直後に、転記ステータス項目(VBRK-RFBSK)の値を確認して判定します。 イベントタイプ inferred | |||
| 請求書の顧客への送付 | このアクティビティは、印刷、メール、EDIなどで請求書を顧客に送信した時点を示します。記録方法は、SAPの出力管理設定によって異なります。 | ||
| 重要な理由 顧客側で支払期間が始まる正式な時点です。請求書の送付が遅れると、売上債権回転日数(DSO)やキャッシュフローに直接影響します。 入手先 出力管理テーブル(旧方式のNASTや、S/4HANAでの同等機能など)に明示的に記録できます。明示的な記録がない場合は、「請求書の会計転記」と同時に発生したものと判定することが一般的です。 記録 出力管理テーブルの処理ログを確認し、請求書の出力タイプに対応するタイムスタンプを調べます。 イベントタイプ explicit | |||
| 請求業務の手戻りを検出 | 請求書が取り消された後、同じ受注に対して新しい請求書が発行された手戻りループを特定する計算イベントです。単一の取引ではなく、複数のイベントに見られるパターンです。 | ||
| 重要な理由 修正の発生件数を数値化し、請求業務の手戻り率に関する重要業績評価指標を直接把握できます。非効率な箇所を特定し、請求プロセスの品質不良によるコストを測定するのに役立ちます。 入手先 「請求書の取消」の後に、新しい「請求書発行」が続き、どちらも受注番号など同じ元伝票を参照しているパターンを特定して算出します。 記録 同じ受注番号を参照する「請求書の取消」と「請求書発行」の連続を検出して算出します。 イベントタイプ calculated | |||
| 顧客による異議申し立ての登録 | 顧客が請求書に対して異議を申し立て、その内容がシステムに正式に記録されたときに発生するアクティビティです。SAP Dispute Managementモジュールが必要です。 | ||
| 重要な理由 請求の正確性、製品品質、サービスの納品に関する問題が、支払いの遅延につながっていることを示します。異議の理由を分析することで、根本原因への対処と顧客満足度の向上に役立てられます。 入手先 会計伝票明細に紐づく異議申し立てケースが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クエリの準備:この文書の「query」セクションに記載されているSQLクエリ全体をコピーし、使用するSQLクライアントに貼り付けます。
- プレースホルダーの設定:クエリ内のプレースホルダーを変更します。
'YYYY-MM-DD'を開始日と終了日に置き換えます。'XXXX'は対象の会社コードに置き換えます。また、システム設定に応じて、クレジットメモの伝票タイプを示すプレースホルダー(例:'G2')も調整が必要な場合があります。 - クエリの実行:変更したSQLクエリをSAP S/4HANAデータベースに対して実行します。実行時間は、指定した期間のデータ量によって異なります。
- 結果の確認:クエリの実行後、出力結果を確認します。結果は、各行が請求プロセスの1つのアクティビティを表すフラットなテーブルになります。これがイベントログです。
- データ変換(必要な場合):このクエリは、整った形式のイベントログを出力するように設計されています。ただし、タイムスタンプ形式がプロセスマイニングツールと互換性があることを確認してください。クエリでは
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セキュリティチームから、所定のロールと権限を付与してもらう必要があります。また、「Customer Dispute Opened」や「Payment Reminder Issued」などのアクティビティを取得するには、SAP Dispute ManagementとSAP Financials Dunningの各モジュールがシステムで利用されている必要があります。
- 処理性能:クエリでは複数の結合とユニオンを使用します。数年分など非常に大きなデータセットを扱う場合は、利用の少ない時間帯に実行するか、フィルターを追加して初回のデータ取得範囲を絞ってください。
クエリの例 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 HANAスキーマへの直接読み取りアクセスが可能であることを確認します。システム管理者から、スキーマ名、接続情報、許可された期間、会社コードの範囲、請求伝票タイプ、顧客や地域のフィルターを入手します。クエリ内で置き換えるのは、接続情報とフィルターのプレースホルダーだけにしてください。
- 対象システムで使用するSAP S/4HANAのデータソースとフィールドの対応関係を確認します。クエリでは請求データにVBRKとVBRPを使用します。また、会計、出力管理、紛争管理、督促、入金、消込、伝票間の関連に対応するデータソースの設定が必要です。角括弧で示されたデータソースとフィールドのプレースホルダーは、システムのデータディクショナリと照合してから置き換えてください。
- 開始時刻を含み、終了時刻を含まない形で抽出期間を設定します。初回は3~6か月の期間をおすすめします。データ量を抑え、無関係な請求プロセスが混在しないよう、会社コードと必要に応じて請求タイプで絞り込みます。
- 読み取り専用のHANAデータベースユーザーでクエリを実行します。クエリは、明示的に抽出した各アクティビティについてイベント行を1件作成します。ProcessMindがイベントを推測する仕組みではありません。「Payment Due Date Reached」や「Billing Rework Identified」などの計算によるアクティビティはSQLロジックで作成され、行として返されます。
- 返されたスキーマを検証します。イベントログにはInvoiceNumber、ActivityName、EventTime、UserName、InvoiceDate、PaymentDueDate、InvoiceAmount、CustomerName、Region、EndTimeが含まれている必要があります。すべての行でInvoiceNumber、ActivityName、EventTimeに値が入っていることを確認します。
- イベントの意味と関連性を検証します。「Invoice Generated」の行を請求ヘッダーの作成データと、「Invoice Posted To Accounting」の行を会計転記ステータスと、「Invoice Sent To Customer」の行を出力レコードと照合します。また、入金行を会計伝票と、消込行を消込済みの請求明細と照合します。本番環境で使う前に、プレースホルダーに依存するすべての箇所を確認してください。
- ProcessMindで使える形式に結果を整えます。イベントごとに1行とし、タイムスタンプのデータ型とタイムゾーンを統一します。先頭のゼロを保持できるようInvoiceNumberはテキストとして扱い、ActivityNameの値が指定されたアクティビティ名と完全に一致することを確認します。InvoiceNumber、EventTimeの順に並べ、同じ時刻のイベントが複数ある場合は、順序が一定になるよう第2の並べ替え条件を設定します。
- 結果をUTF-8のCSV、またはProcessMindが対応する別の表形式でエクスポートします。InvoiceNumberをケースID、ActivityNameをアクティビティ列、EventTimeをイベントのタイムスタンプとして割り当てます。利用可能であれば推奨属性も含め、設定済みのProcessMindインポート手順でファイルをアップロードします。最後に行数とアクティビティ数を確認してください。
設定
- 期間:まずは3~6か月を対象にします。増分実行の間でイベントが重複しないよう、開始時刻を含み、終了時刻を含まない範囲を指定してください。
- ケースID:請求伝票ヘッダーのInvoiceNumberを使用します。SAPの伝票番号には先頭にゼロが付く場合があるため、文字列として保持してください。
- 必須アクティビティ:抽出結果には、Invoice Generated、Invoice Posting Blocked、Invoice Posted To Accounting、Invoice Sent To Customer、Payment Due Date Reached、Customer Dispute Opened、Payment Reminder Issued、Customer Payment Received、Cash Applied/Reconciled、Invoice Closed、Invoice Cancelled、Credit Memo Created、Billing Rework Identifiedの各イベント行を明示的に含める必要があります。
- フィルター:会社コード、請求伝票タイプ、販売組織、顧客、地域、日付の各フィルターは、対象システムで該当フィールドと業務範囲を確認してから適用してください。すべての請求伝票タイプで会計処理や出力処理が同じとは限りません。
- データソースの設定:請求データの主なデータソースはVBRKとVBRPです。会計、出力、紛争管理、督促、入金、消込、伝票フローのデータソースは、導入済みのSAP S/4HANAのリリースと有効なモジュールに応じて設定してください。角括弧で示されたデータソース参照は、検証済みのオブジェクトとフィールドに置き換えます。
- 計算イベント:「Payment Due Date Reached」は支払条件と支払期日のデータから算出します。「Billing Rework Identified」は取消と、その後の請求書生成のパターンから算出します。これらはSQLで作成するイベント行であり、標準のトランザクションレコードではありません。
- 処理性能:日付、会社コード、請求タイプ、伝票番号のフィルターを各データソースのクエリに適用します。必要な列だけを選択し、大規模な会計テーブルとの無制限な結合を避けます。期間を月単位または週単位に分けて処理し、データベースの実行計画で負荷の高い結合を特定してください。
- 増分抽出:データソースの作成時刻または転記時刻に基づく、安定したウォーターマークを使用します。後から到着する出力、入金、紛争、消込のレコードを取り込めるよう、短い重複期間を再処理します。その後、InvoiceNumber、ActivityName、EventTimeと、関連するデータソースの伝票キーを使って重複を除去します。
- 権限:抽出ユーザーには、選択したHANAスキーマのオブジェクトとフィールドに対する読み取り権限が必要です。データベースへの直接アクセスが組織のセキュリティポリシーで許可されていること、個人データや顧客データの取り扱い要件を満たしていることを確認してください。
- 機能上の前提条件:出力管理、会計連携、紛争管理、督促、入金、消込のデータは、システムで設定され、利用されている場合にのみ取得できます。モジュールやデータソースのレコードがない場合、該当アクティビティは推測されず、欠落します。
- タイムゾーン:ProcessMindで必要なタイムゾーンにタイムスタンプを統一します。データソースのタイムスタンプがUTC、ローカルシステム時刻、または別の設定済みタイムゾーンのいずれで保存されているかを文書化してください。
クエリの例 sql
WITH
billing_headers AS (
SELECT
h.VBELN AS InvoiceNumber,
h.FKDAT AS InvoiceDate,
h.NETWR AS InvoiceAmount,
h.KUNAG AS CustomerNumber,
h.ERDAT AS BillingCreatedDate,
h.ERZET AS BillingCreatedTime,
h.ERNAM AS BillingCreatedBy,
h.BUKRS AS CompanyCode,
h.FKART AS BillingType,
h.FKSTO AS CancellationIndicator,
h.RFBSK AS AccountingPostingStatus,
h.ZTERM AS PaymentTerms,
h.ZFBDT AS BaselineDate,
h.NETDT AS PaymentDueDate,
h.VBELV AS PrecedingDocument
FROM [Your HANA schema].VBRK h
WHERE h.ERDAT >= '[Start date, YYYY-MM-DD]'
AND h.ERDAT < '[End date, YYYY-MM-DD]'
AND h.BUKRS IN ([Company code filter])
AND h.FKART IN ([Billing document type filter])
),
customer_data AS (
SELECT
c.KUNNR AS CustomerNumber,
c.NAME1 AS CustomerName,
c.REGION AS Region
FROM [Your customer master source] c
),
invoice_base AS (
SELECT
b.InvoiceNumber,
b.InvoiceDate,
b.InvoiceAmount,
b.CustomerNumber,
c.CustomerName,
c.Region,
b.BillingCreatedDate,
b.BillingCreatedTime,
b.BillingCreatedBy,
b.CompanyCode,
b.BillingType,
b.CancellationIndicator,
b.AccountingPostingStatus,
b.PaymentTerms,
b.BaselineDate,
b.PaymentDueDate,
b.PrecedingDocument
FROM billing_headers b
LEFT JOIN customer_data c
ON c.CustomerNumber = b.CustomerNumber
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Generated' AS ActivityName,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EventTime,
i.BillingCreatedBy AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EndTime
FROM invoice_base i
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posting blocked status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
a.StatusTimestamp AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
a.StatusTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posted status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
o.SentTimestamp AS EventTime,
o.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
o.SentTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your output management source] o
ON o.InvoiceNumber = i.InvoiceNumber
AND o.OutputStatus = '[Successfully sent status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM invoice_base i
WHERE i.PaymentDueDate IS NOT NULL
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
d.OpenedTimestamp AS EventTime,
d.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
d.OpenedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dispute management source] d
ON d.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
r.IssuedTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.IssuedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dunning or payment reminder source] r
ON r.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Payment Received' AS ActivityName,
p.ReceivedTimestamp AS EventTime,
p.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
p.ReceivedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your incoming payment source] p
ON p.CustomerNumber = i.CustomerNumber
AND p.CompanyCode = i.CompanyCode
AND p.ReceivedTimestamp >= TO_TIMESTAMP(TO_VARCHAR(i.InvoiceDate))
UNION ALL
SELECT
i.InvoiceNumber,
'Cash Applied/Reconciled' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Closed' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
x.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
LEFT JOIN [Your billing cancellation or document flow source] x
ON x.InvoiceNumber = i.InvoiceNumber
WHERE i.CancellationIndicator = '[Cancellation indicator value]'
OR x.InvoiceNumber IS NOT NULL
UNION ALL
SELECT
cm.ReferenceInvoiceNumber AS InvoiceNumber,
'Credit Memo Created' AS ActivityName,
cm.CreatedTimestamp AS EventTime,
cm.UserName,
i.InvoiceDate,
i.PaymentDueDate,
cm.Amount AS InvoiceAmount,
i.CustomerName,
i.Region,
cm.CreatedTimestamp AS EndTime
FROM [Your credit memo source] cm
INNER JOIN invoice_base i
ON i.InvoiceNumber = cm.ReferenceInvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
r.ReworkTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.ReworkTimestamp AS EndTime
FROM invoice_base i
INNER JOIN (
SELECT
old_invoice.InvoiceNumber,
new_invoice.InvoiceNumber AS ReplacementInvoiceNumber,
new_invoice.BillingCreatedDate AS ReworkTimestamp,
new_invoice.BillingCreatedBy AS UserName
FROM invoice_base old_invoice
INNER JOIN invoice_base new_invoice
ON new_invoice.PrecedingDocument = old_invoice.InvoiceNumber
AND new_invoice.BillingCreatedDate > old_invoice.BillingCreatedDate
WHERE old_invoice.CancellationIndicator = '[Cancellation indicator value]'
) r
ON r.InvoiceNumber = i.InvoiceNumber
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
InvoiceDate,
PaymentDueDate,
InvoiceAmount,
CustomerName,
Region,
EndTime
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName; 始める準備はできていますか?
このテンプレートを使うと、データ準備を効率よく進め、受注から入金までの請求・請求書発行プロセスの改善に着手できます。SAP S/4HANAのデータを、改善に役立つインサイトへと変えましょう。
受注から入金までの請求プロセスを改善し、キャッシュフローを30%加速
非効率な作業をなくし、請求サイクルタイムを今すぐ30%短縮しましょう。
クレジットカードは不要です。数分で利用を開始できます。