受注から入金まで:請求・請求書発行のデータテンプレート
受注から入金まで:請求・請求書発行のデータテンプレート
- 収集を推奨する属性
- 追跡する主要なアクティビティ
- 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)を介して紐づけます。 例 CANYTXBA | |||
| 支払期日 PaymentDueDate | 顧客が請求書を支払う予定の日付です。 | ||
| 説明 支払期日は、請求書日付と合意した支払条件に基づいて計算します。請求書が延滞になることなく入金を受けるための期限を示します。 回収の有効性を監視し、キャッシュフローを予測するうえで欠かせない属性です。期限内支払率KPIの計算や、経過期間レポートでの請求書の分類に直接使います。支払期日と実際の支払日との差を分析することで、支払条件の有効性を評価できます。 重要な理由 顧客からの支払期限を定めるため、期限内支払率の計算や売掛金管理に欠かせません。 入手先 直接保存される日付ではありません。請求書日付(VBRK-FKDAT)と支払条件キー(VBRK-ZTERM)に基づき、SAP標準の日付決定機能で計算します。 例 2023-04-192023-05-012023-06-17 | |||
| 終了時刻 EndTime | アクティビティまたはイベントが完了した正確なタイムスタンプです。 | ||
| 説明 終了時刻は、アクティビティが完了した時点を示します。プロセスマイニングでは、ケース内で後続するアクティビティの開始時刻から推定することが多く、システムが開始イベントと終了イベントの両方を記録している場合は、直接取得できます。 個々のアクティビティの処理時間を計算するために欠かせない属性です。開始時刻を終了時刻から差し引くことで各ステップの所要時間を測定でき、請求書承認段階の遅延など、ボトルネックの分析に役立ちます。 重要な理由 各アクティビティの正確な所要時間(処理時間)を計算でき、ボトルネック分析の基礎になります。 入手先 プロセスマイニング用に導出する属性です。通常は、ケース内のシーケンスで次に発生するイベントのStartTimeとして計算します。状況によっては、専用のテーブルに完了時刻が記録されている場合もあります。 例 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の顧客マスターデータから取得します。 顧客別にプロセスを分析すると、特定の顧客に固有の傾向を特定できます。たとえば、支払遅延が常態化している顧客、異議申立てが多い顧客、請求プロセスの非効率が大きい顧客を把握できます。これにより、顧客ごとの関係管理や回収戦略を設定できます。 重要な理由 顧客を軸にした分析を可能にし、特定の顧客における支払行動、異議申立ての頻度、プロセスの非効率を特定できます。 入手先 顧客マスターデータテーブルKNA1(フィールド:NAME1)から取得し、請求書ヘッダーの支払人ID(VBRK-KUNRG)を介して紐づけます。 例 Springfield Power PlantKwik-E-MartCyberdyne Systems | |||
| クレジットメモ理由 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つの受注から1件以上の請求書が作成される場合があり、このリンクによって伝票フロー全体を確認できます。 真のエンドツーエンドの受注から入金までの分析に欠かせない属性です。プロセスの範囲を上流へ広げ、請求上の問題を受注作成や履行段階の根本原因候補と関連付けられます。たとえば、受注の履行時点から請求書生成サイクルタイムを計算できます。 重要な理由 請求書を元の受注に結び付け、請求だけにとどまらない、受注から入金までのプロセス全体を把握できます。 入手先 SAPテーブル:VBRP(請求伝票明細データ)、フィールド:AUBEL 例 100001231000045610000789 | |||
| 支払ステータス 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の異議申立て管理モジュールやテキストメモに保存される場合があります。 異議申立て理由の分析は、請求エラー率KPIと関連するエラー分析の基礎です。請求の不正確さの根本原因を特定し、上流プロセスの構造的な問題に対処して請求書の品質を高め、顧客満足度を向上できます。 重要な理由 請求書に異議が申し立てられる理由を示し、請求エラーと顧客の不満の根本原因を直接把握できます。 入手先 SAP異議申立て管理を使用している場合は、UDM_DISPUTEなどのテーブルで確認できます。それ以外の場合は、関連伝票の理由コードやテキストフィールドから導出することがあります。 例 価格誤り数量不一致受領時の破損品 | |||
| 請求伝票タイプ BillingDocumentType | 請求書、クレジットメモ、取消など、請求伝票を分類するコードです。 | ||
| 説明 請求伝票タイプは、請求プロセス内の取引を分類する主要フィールドです。番号範囲や会計転記ルールなど、伝票の処理方法を制御します。 この属性でプロセスをフィルタリングし、特定の取引タイプを分析できます。たとえば、クレジットメモだけのプロセスビューを作成して財務修正の理由とフローを把握したり、標準請求書と取消を分けて分析し、通常の請求プロセスをより明確に確認したりできます。 重要な理由 取引を分類し、標準請求書、クレジットメモ、取消など、特定の伝票フローに絞った分析を可能にします。 入手先 SAPテーブル:VBRK、フィールド:FKART 例 F2G2S1L2 | |||
| 通貨 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-BUDAT)から取得します(通常、BKPFテーブルの伝票タイプ「DZ」です)。 取得 イベントは、BKPF/BSEGで入金伝票が作成されたことに基づきます。 イベントタイプ explicit | |||
| クレジットメモ作成 | 過請求を修正したり、返品された商品に対する返金を行ったりするために顧客へ発行するクレジットメモの作成を示すアクティビティです。元の請求書と紐づくことがよくあります。 | ||
| 重要な理由 請求後に財務調整が必要となる問題を明らかにします。クレジットメモを分析することで、価格設定エラー、製品上の問題、その他の収益漏れの根本原因を見つけられます。 入手先 クレジットメモ専用の請求タイプ(例:「G2」)を指定した新しい請求伝票として、VBRKに明示的に作成されます。元の受注または請求書を参照することがよくあります。 取得 クレジットメモの請求タイプを持つVBRKの請求伝票が作成された時点から取得します。 イベントタイプ explicit | |||
| 支払期日が到来 | 合意した支払条件に基づき、請求書の支払いが正式に期日を迎えた日を示す計算イベントです。取引イベントではなく、請求書データから導出されます。 | ||
| 重要な理由 期日どおりの支払パフォーマンスを測定し、顧客の支払行動を分析するための重要な基準になります。期限内の支払いと延滞を区別できます。 入手先 会計伝票の顧客明細に保存された支払基準日(BSEG-ZFBDT)と支払条件に基づいて計算します。 取得 会計伝票明細(BSEG)にある支払基準日に、支払条件の日数を加えて導出します。 イベントタイプ calculated | |||
| 支払督促を発行 | 延滞した請求書について、顧客へ支払督促または督促通知を送信したことを示します。自動督促手続きによって生成される明示的なイベントです。 | ||
| 重要な理由 督促プロセスの効果を分析できます。督促によって支払いが早まったか、どの督促レベルが最も効果的かを判断できます。 入手先 請求書の未決済項目に対して督促実行(トランザクションF150)が行われた際、督促履歴テーブル(MAHNV、MHND)に記録されます。 取得 督促履歴テーブルに記録された督促通知の実行日から取得します。 イベントタイプ explicit | |||
| 請求の手戻りを検出 | 請求書が取り消された後、同じ受注に対して新しい請求書が作成された手戻りループを特定する計算イベントです。単一の取引ではなく、複数のイベントから成るパターンです。 | ||
| 重要な理由 修正の発生件数を定量化し、Billing Rework Rate KPIを直接支援します。請求プロセスの非効率や品質不良によるコストを特定するのに役立ちます。 入手先 同じ元伝票(受注番号など)に紐づく「請求書取消」イベントの後に、新しい「請求書生成」イベントが続くパターンを特定して計算します。 取得 同じ受注参照に対する「請求書取消」と「請求書生成」の連続を検出して導出します。 イベントタイプ calculated | |||
| 請求書の計上がブロック | 請求書が作成されたものの、与信チェックやデータの不整合などの理由で、財務会計への計上が自動的にブロックされた場合に発生するイベントです。このステータスは、請求伝票の計上ステータス項目から推定されます。 | ||
| 重要な理由 請求書が作成されたにもかかわらず、財務部門へすぐにリリースされないボトルネックを特定します。入金回収サイクル全体を遅らせる、データ品質や与信管理上の問題を示す重要な指標です。 入手先 請求伝票ヘッダーテーブル(VBRK-RFBSK)の計上ステータス項目から推定します。「A」(FIへの転送がブロックされた請求伝票)などのステータスは、ブロックを示します。 取得 請求書生成直後の計上ステータス項目(VBRK-RFBSK)の値を確認して推定します。 イベントタイプ inferred | |||
| 請求書取消 | 作成済みの請求書が取り消されたときに発生します。通常は、対応する取消伝票を作成します。これにより、元の請求書とその会計上の影響が実質的に反転されます。 | ||
| 重要な理由 手戻り、修正、請求エラーを示します。取消の頻度が高い場合、受注入力や請求設定に重大な上流問題がある可能性があります。 入手先 取消請求伝票が作成されたときに取得します(例:伝票タイプ「S1」)。VBRKのこの新しい伝票は、VBRK-SFAKNフィールドで元の請求書番号を参照します。 取得 元の請求書を参照するVBRKの取消伝票の作成日から取得します。 イベントタイプ explicit | |||
| 顧客からの紛争が開始 | 顧客が請求書に対する異議を申し立て、その内容がシステムに正式に記録された時点で発生するアクティビティです。SAP Dispute Managementモジュールの利用が必要です。 | ||
| 重要な理由 請求の正確性、製品品質、サービス提供に関する問題のうち、支払いの遅延につながるものを明らかにします。紛争の理由を分析することで、根本原因への対処と顧客満足度の向上につなげられます。 入手先 会計伝票明細に関連付けられたDispute Managementテーブル(例:UDM_CASE)に紛争ケースが作成された時点で記録します。 取得 請求書に関連付けられた紛争ケースレコードの作成タイムスタンプから取得します。 イベントタイプ explicit | |||
| 顧客へ請求書を送付 | 請求書が印刷、メール、EDIなどで顧客に送信された時点を示すアクティビティです。取得方法は、SAPの出力管理設定によって異なります。 | ||
| 重要な理由 顧客側で支払期間の起点となる正式な時点です。請求書の送付が遅れると、DSOとキャッシュフローに直接影響します。 入手先 出力管理テーブル(旧方式のNASTや、S/4HANAの同等テーブルなど)に明示的に記録できます。明示的な記録がない場合は、「請求書を会計へ計上」と同じ時点で発生したと推定することが一般的です。 取得 出力管理テーブルの処理ログを確認し、請求書の出力タイプに関連付けられたタイムスタンプを取得します。 イベントタイプ explicit | |||
抽出ガイド
ステップ
- 前提条件:SAP S/4HANAでユーザーアカウントを用意し、Core Data Services(CDS)ビューを照会するために必要な権限を付与してください。具体的には、I_BillingDocument、I_JournalEntryItem、I_Customer、I_Outgmgmtdocumentoutputreq、I_DisputeCase、I_DunningHistoryなどのビューへの読み取りアクセスが必要です。
- データ抽出ツールへのアクセス:SAP S/4HANAシステムにログインしてください。CDSビューに対してSQLクエリを実行するには、SAP HANA Studio、SAP HANAクライアント経由で接続したDBeaver、SAP Analysis for Microsoft Excelプラグインなど、さまざまなツールを利用できます。このガイドでは、標準的な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をシステムで利用している必要があります。
- パフォーマンス:クエリでは複数の結合とUNIONを使用します。数年分のデータなど非常に大きなデータセットを扱う場合は、負荷の低い時間帯に実行するか、より厳しいフィルターを適用して初回のデータ取得量を抑えてください。
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 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をケース識別子、ActivityNameをアクティビティ列、EventTimeをイベントタイムスタンプとしてマッピングします。利用可能な推奨属性を含めたうえで、設定済みのProcessMindインポートプロセスからファイルをアップロードし、最後に行数とアクティビティ数を確認してください。
設定
- 日付範囲:まずは3~6か月から始めてください。増分実行間でイベントが重複しないよう、開始タイムスタンプは含み、終了タイムスタンプは含まない設定にします。
- ケース識別子:請求伝票ヘッダーの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、ローカルシステム時刻、その他の設定済みタイムゾーンのいずれで保存されているかを記録します。
a サンプルクエリ 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/4H4ANAのデータを、今日から具体的な改善案につなげていきましょう。
受注から入金までの請求プロセスを最適化し、キャッシュフローを30%短縮
非効率な処理をなくし、今日から請求サイクルを30%短縮します。
クレジットカードは不要です。数分で始められます。