与信管理および債権回収データテンプレート
与信管理および債権回収データテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- `SAP ECC`の抽出ガイダンス
債権``管理・回収属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
請求書ライフサイクル内の特定の時点で発生したビジネス活動またはイベントの名称。 | ||
|
説明
この属性は、「請求書記帳」、「督促実行」、「入金伝票記帳」など、与信管理および債権回収プロセス内の特定のステップまたはイベントを記述します。これらのアクティビティがプロセスマップのノードを形成します。 これらのアクティビティ間の順序、頻度、および期間を分析することで、企業は実際のプロセスフローを可視化し、標準手順からの逸脱を特定し、ボトルネックを特定できます。たとえば、「督促実行」後のパスを分析することで、督促戦略の有効性を明らかにすることができます。
その重要性
取得元
これは導出された属性であり、通常、トランザクションコード(TCODE)、伝票タイプ(BLART)、または様々なSAPテーブル(例:BKPF、BSID、MHNK、UDM_CASE)からの特定フィールドの変更を、ユーザーフレンドリーな活動名にマッピングすることによって構築されます。
例
請求書仕訳計上済み督促実行支払約束作成入金伝票が記帳されました請求書 消込済み
|
|||
|
イベント日時
EventTime
|
特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプ。 | ||
|
説明
イベントタイムは、プロセス内の各アクティビティの正確な日時を記録します。これはイベントログの時系列的な骨格であり、アクティビティの順序付けやそれらの間の期間の計算を可能にします。 分析において、このタイムスタンプは、異議申し立て解決サイクルタイム、支払い記帳遅延、期日から支払いまでの平均日数など、すべての時間ベースのKPIを計算するために不可欠です。連続するステップ間の長い待機時間を強調表示することで、ボトルネックの発見を可能にします。
その重要性
この属性は、イベントを正しく順序付けし、サイクルタイムや期間など、時間に関連するすべてのパフォーマンス指標を計算するために不可欠です。
取得元
SAPテーブルの様々な日付および時刻フィールド(例:BKPFのBUDAT(転記日付)またはCPUDT/CPUTM(伝票入力日付/時刻)、またはイベント固有のテーブル)から取得されます。
例
2023-01-15T09:30:00Z2023-02-10T14:00:00Z2023-02-28T11:25:10Z
|
|||
|
請求書番号
InvoiceNumber
|
顧客請求書の一意の識別子であり、与信管理プロセスの主要なケース識別子として機能します。 | ||
|
説明
請求書番号(SAPではBelegnummer (BELNR))は、各売掛金伝票を一意に識別します。プロセスマイニングにおいて、この番号は、記帳、督促、最終的な支払いまたは貸倒処理までのすべての関連アクティビティを単一のまとまったケースとしてリンクするため、非常に重要です。 請求書番号をケース識別子としてプロセスを分析することで、請求書のライフサイクル全体を包括的に把握できます。これにより、売掛金回収日数(DSO)などの主要な指標を追跡し、債権回収プロセスにおけるボトルネックを特定し、特定の請求書に対するさまざまな債権回収戦略の有効性を理解するのに役立ちます。
その重要性
これは、請求書のプロセスにおけるすべてのイベントを繋ぐ不可欠なキーであり、エンドツーエンドの与信から現金化までのプロセスを追跡・分析することを可能にします。
取得元
SAP ECCのさまざまな財務会計
例
190000000119000000451900000102
|
|||
|
`督促``レベル`
Mahns
|
請求書に対して到達した最高督促(リマインダー)レベル。 | ||
|
説明
督促レベル(SAPのMAHNS)は、延滞請求書に対して何回の督促通知が送信されたかを示し、督促手続きの強度に対応します。 この属性は督促プロセスを評価する上で重要です。「レベル別督促効果」ダッシュボードで直接使用され、各督促通知の送信後に何パーセントの請求書が支払われたかを測定します。この分析は、例えば効果のないレベルでの通知のタイミングや内容を変更するなど、督促戦略を洗練するのに役立ちます。
その重要性
取得元
例
1234
|
|||
|
ユーザー名
UserName
|
`アクティビティ`を実行した担当者の`ユーザーID`です。 | ||
|
説明
この属性は、請求書の記帳や異議申し立てケースの作成など、イベントの責任者である特定のユーザーを識別します。SAPでは、これは多くの場合、ERNAM(作成者)やUSNAMなどのフィールドに保存されます。 ユーザー別に分析することで、ワークロードの配分を理解し、トレーニングのニーズを特定し、潜在的なコンプライアンス問題を検出するのに役立ちます。例えば、特定のユーザーが常にプロセス逸脱や遅延に関連しているか、あるいはトップパフォーマーがより効率的なプロセスバリアントに従っているかなどを明らかにできます。
その重要性
プロセス内における人のパフォーマンスと行動の分析を可能にし、優秀な担当者の特定、トレーニング機会の発見、ワークロードの不均衡の解消に役立ちます。
取得元
通常、BKPFのようなヘッダーテーブルにおいて、USNAM(ユーザー名)またはERNAM(オブジェクト作成者名)として見られます。
例
SMITHJRDOECFO-ADMIN
|
|||
|
回収担当者
Sachp
|
顧客勘定に割り当てられた会計担当者または債権回収担当者。 | ||
|
説明
この属性は、特定の顧客勘定の債権回収を管理する担当者またはグループを特定します。SAPでは、これは多くの場合、顧客マスタレコードで定義されている会計担当者(SACHP)です。 この次元は、債権回収チーム内のパフォーマンス管理にとって非常に重要です。債権回収担当者でフィルタリングされた「請求書年齢分析概要」のようなダッシュボードを作成することを可能にし、ワークロードの管理や異なる債権回収担当者またはチームの有効性の比較に役立ちます。どの債権回収担当者が延滞請求書の解決に最も成功しているかという疑問に答えます。
その重要性
取得元
通常、得意先マスタの会社コードデータ(テーブルKNB1、項目SACHP)に存在します。
例
J. スミスチームA国際債権回収
|
|||
|
延滞日数
DaysOverdue
|
請求書が期日を過ぎてからの日数(計算値)。 | ||
|
説明
この指標は、請求書の支払期日と消込日の間の日数を計算します。未決済請求書の場合、現在の日付に基づいて計算されます。 延滞日数は、すべての売掛金分析にとって基本的な指標です。「請求書年齢分析概要」ダッシュボードの主要な測定値であり、債権回収活動の優先順位付けに使用されます。この指標の集計レベルでのトレンド分析は、企業の売掛金全体の健全性を示すことができます。
その重要性
これは、支払い遅延を直接的に定量化する主要なパフォーマンス指標であり、債権回収努力の優先順位付けやプロセス健全性の測定に使用されます。
取得元
例
0153295
|
|||
|
支払期日
NetDueDate
|
請求書支払いが契約上期日となる日付。 | ||
|
説明
期日は、顧客が請求書を支払うことが期待される最終期限です。これは請求書の基準日付と支払条件に基づいて計算されます。SAPでは、純期日は多くの場合FAEDTフィールドで利用可能です。 この日付は与信管理にとって不可欠です。これは適時性が測定される基準であり、「期日から支払いまでの平均日数」などのKPIの計算に使用され、期限を過ぎると債権回収活動をトリガーします。この日付に対する遅延を分析することは、債権回収分析の中核的な活動です。
その重要性
これは支払い適時性を測定するための主要なベンチマークであり、延滞日数および関連KPIを計算するために不可欠です。
取得元
この日付は、BSIDのような顧客明細テーブルでFAEDT(純期日)として直接利用できることが多いです。また、基準日(ZFBDT)と支払条件(ZTERM)から計算することも可能です。
例
2023-02-142023-03-312023-04-15
|
|||
|
請求金額
Dmbtr
|
現地通貨建ての請求書の合計金額。 | ||
|
説明
この属性は、請求書の総額を表します。SAPでは、多くの場合、現地通貨額のDMBTRフィールドに保存されます。 請求書金額は分析にとって重要な次元です。高額な請求書に対する債権回収努力を優先させ、請求書金額と支払い遅延や異議申し立ての発生との間に相関があるかを理解することを可能にします。プロセスマップをフィルタリングして、特定の閾値を超える請求書にのみ焦点を当てるために使用できます。
その重要性
プロセスに財務的な文脈を提供し、価値に基づいた分析と、高額な項目への債権回収努力の優先順位付けを可能にします。
取得元
BSEG、BSID、BSADなどのテーブルにおける標準フィールドDMBTR(現地通貨額)。
例
1500.0012500.50750.25
|
|||
|
顧客セグメント
CustomerSegment
|
顧客の分類。例えば、規模、業界、戦略的重要性に基づく。 | ||
|
説明
この**
その重要性
さまざまなタイプの
取得元
多くの場合、顧客マスタテーブルKNA1の顧客勘定グループ(KTOKD)フィールド、またはその他のカスタムフィールドから派生します。
例
主要顧客中小企業政府内部
|
|||
|
顧客番号
Kunnr
|
顧客の一意の識別子。 | ||
|
説明
顧客番号(SAPのKUNNR)は、顧客勘定の一意のキーです。これにより、取引を特定の顧客のマスタデータ(支払い履歴、与信情報、連絡先詳細を含む)にリンクさせます。 プロセスマイニングにおいて、この属性は分析をセグメント化するために不可欠です。異なる顧客間でプロセスパフォーマンスを比較したり、慢性的な遅延支払者を特定したり、戦略的顧客と非戦略的顧客で債権回収戦略がどのように異なるかを分析したりできます。これは、請求書年齢分析や支払条件遵守などのダッシュボードの基本となります。
その重要性
取得元
顧客明細テーブル(BSID、BSAD)および伝票ヘッダテーブル(BKPF、入力されている場合)の標準フィールドKUNNR。
例
10002050CUST-7890
|
|||
|
`ソースシステムID`
SourceSystemId
|
データが抽出されたソースシステムの識別子。 | ||
|
説明
この属性は、発生元システム(例:「ECCPRD100」のような特定のSAP ECCインスタンス)を指定します。これは、複数のERPシステムが存在する環境や、異なるソースからのデータを統合する際に重要です。 これにより、異なるシステムや地域間でのプロセスをフィルタリングおよび比較できます。データの出所が明確になり、データ抽出の問題解決に役立ちます。
その重要性
特に複雑なITランドスケープにおいて、データの出所に関する重要なコンテキストを提供し、データの追跡可能性を確保し、システム固有の分析を可能にします。
取得元
通常、データ抽出プロセス中に追加されます。SAPでは、論理システム名(LOGSYS)を使用できます。
例
SAPECC_PROD_100ECC_EU_200US_FIN_ERP
|
|||
|
`ディスピュートケースID`
DisputeCaseId
|
請求書にリンクされた異議申し立てケースの一意の識別子。 | ||
|
説明
顧客が請求書に異議を申し立てる際、SAPのDispute Managementモジュールで正式な紛争ケースが作成されることがあります。このIDはそのケースを一意に識別します。 この識別子を持つことで、紛争解決プロセスの詳細な分析が可能になります。「紛争解決サイクルタイム」KPIの計算や、紛争が発生する理由、その処理方法、一般的な結果を理解するために不可欠です。これにより、標準の回収フローから紛争のサブプロセスを分離して分析することができます。
その重要性
債権回収活動と正式な異議申し立てケースを関連付け、異議申し立て解決プロセスの効率性と根本原因に焦点を当てた分析を可能にします。
取得元
UDM_CASE_ATTR00などのSAP Dispute Management
例
400000000021400000000157400000000305
|
|||
|
`与信限度額`
Klimk
|
顧客に割り当てられた与信限度額の合計。 | ||
|
説明
与信限度額(SAPのKLIMK)は、顧客勘定に付与される最大の与信額です。これは信用リスク管理の重要な要素です。 この属性は「与信限度額の正確性と貸倒」ダッシュボードに不可欠です。割り当てられた与信限度額と貸倒発生の関係を分析することで、企業は与信ポリシーの有効性を評価できます。また、「与信限度額見直し率」などのKPIをサポートし、初期評価が正確かどうかを確認するのにも役立ちます。
その重要性
信用リスクに関するコンテキストを提供し、売上を妨げずに貸倒を防止する与信ポリシーが効果的であるかどうかを分析できるようにします。
取得元
例
10000.0050000.00250000.00
|
|||
|
`決済``伝票`
Augbl
|
請求書を消込した伝票番号。通常は支払い伝票またはクレジットメモ。 | ||
|
説明
消込伝票番号(SAPのAUGBL)は、請求書のような未決済項目を、それを決済した伝票とリンクさせます。請求書が支払われると、その支払伝票番号が請求書の消込伝票として保存されます。 このフィールドは、請求書が消込済みであることを確認し、特定の支払またはクレジットメモイベントにリンクするために技術的に不可欠です。「請求書消込」アクティビティを特定し、エンドツーエンドのプロセスが正確に捕捉されることを保証するための基礎となります。
その重要性
請求書とその決済伝票との間の明確なリンクを提供し、消込イベントを正確にモデリングするために不可欠です。
取得元
顧客明細テーブルBSID(未決済時は空白)およびBSAD(消込後は入力済み)の標準フィールドAUGBL。
例
140000000114000000551400000120
|
|||
|
ドキュメントタイプ
Blart
|
請求書、クレジットメモ、支払いなどの財務伝票のタイプ。 | ||
|
説明
伝票タイプ(SAPのBLART)は、会計伝票を分類します。例えば、「RV」は顧客請求書、「DZ」は顧客支払い、「DG」はクレジットメモである可能性があります。 プロセスマイニングのためにアクティビティが導出される一方で、元の伝票タイプは重要なコンテキストを提供し、検証やより詳細な財務分析に使用できます。これにより、処理されている取引の性質を理解するのに役立ち、顧客請求書のような特定の種類の伝票にのみ焦点を当てるように分析をフィルタリングするために使用できます。
その重要性
取引を分類することで財務コンテキストを提供し、分析のフィルタリングや導出されたアクティビティ名の検証に使用できます。
取得元
伝票ヘッダテーブルBKPFの標準フィールドBLART。
例
RV`DZ``DG`AB
|
|||
|
リスクカテゴリ
Ctlpc
|
`顧客`の`与信``リスク`の`分類`です。 | ||
|
説明
リスクカテゴリ(SAPのCTLPC)は、顧客を信用力と支払い履歴に基づいてグループ化します。この分類は、自動与信チェックを推進し、債権回収戦略を導くために使用されます。 リスクカテゴリ別にプロセスを分析することで、深い洞察が得られます。これにより、高リスク顧客が異なるプロセスパスをたどるか、または支払サイクルが著しく長いかを示すことができます。この情報は、リスク分類の正確性を検証し、リスクに基づいて債権回収の強度を調整するために価値があります。
その重要性
取得元
例
001002高リスク
|
|||
|
会社コード
Bukrs
|
請求書が属する法的エンティティ(会社コード)の識別子。 | ||
|
説明
会社コード(SAPのBUKRS)は、財務諸表が作成される独立した法的エンティティを表します。これはSAP財務会計における基本的な組織単位です。 この属性は、企業内の異なる法的エンティティ間でプロセスパフォーマンスをフィルタリングし、比較するために不可欠です。これにより、債権回収プロセスが標準化されているか、または異なる会社コード間でDSOや異議申し立て率などに significant な差異があるかを分析できます。
その重要性
取得元
BKPF, BSEG, BSID, BSADを含むほぼ全ての財務テーブルの標準フィールドBUKRS。
例
10002000US01
|
|||
|
最終データ更新
LastDataRefreshTimestamp
|
プロセスマイニングツールでデータが最後に抽出または更新された時点を示すタイムスタンプ。 | ||
|
説明
この属性は、最新のデータロードの日時を記録します。これにより、ビジネスユーザーが分析しているデータの鮮度について透明性を提供します。 ダッシュボードや分析を確認する際に、このタイムスタンプは、データに最新のトランザクションが含まれているか、または既知の遅延があるかをユーザーが理解するのに役立ちます。これは、分析結果への信頼を構築するための重要なメタデータです。
その重要性
ユーザーが利用可能な最新のプロセス情報に基づいて意思決定を行う上で非常に重要な、データの適時性について通知します。
取得元
この値は、データが更新される際にデータ抽出・ロード(ETL)パイプラインによって生成および保存されます。
例
2023-03-01T02:00:00Z2023-03-02T02:00:00Z2023-03-03T02:00:00Z
|
|||
|
支払条件
Zterm
|
顧客と合意した支払条件のコード。 | ||
|
説明
支払条件コード(SAPのZTERM)は、期日や早期支払いに対する割引などの支払い条件を定義します。これは通常、顧客マスタデータに設定され、請求書にコピーされます。 支払条件ごとに分析することで、異なる条件が支払い行動にどのように影響するかを理解するのに役立ちます。例えば、「支払条件遵守と影響」ダッシュボードは、条件遵守がどのように異なり、それが延滞日数にどのような影響を与えるかを可視化します。これにより、異なる顧客セグメントにどのような支払条件を提供すべきかについて、意思決定を行うことができます。
その重要性
取得元
顧客マスタデータ(KNB1)および財務伝票テーブル(BSEG)に見られる標準フィールドZTERM。
例
0001NT30ZD60
|
|||
|
貸倒処理済み
IsWrittenOff
|
最終的に`不良債権`として償却されたかどうかを示す`ブール``フラグ`です。 | ||
|
説明
これは導出されたフラグで、通常、貸倒処理を示す特定の理由コードまたは伝票タイプを使用して請求書が消込された場合にtrueに設定されます。これにより、財務損失を表すケースが識別されます。 この属性は、「貸倒損失率」KPIおよび関連するダッシュボードの計算に不可欠です。これにより、頻繁に貸倒処理される請求書や顧客の特性を理解するための根本原因分析が可能になり、与信ポリシーと債権回収の有効性を改善するのに役立ちます。
その重要性
財務損失につながるプロセス結果を特定し、貸倒の根本原因を究明し、与信方針を改善するための分析を可能にします。
取得元
これは導出された属性です。ロジックは通常、貸倒処理に使用される特定の消込理由コード(BSEG-RSTGR)または伝票タイプ(BKPF-BLART)を特定することに基づいています。
例
truefalse
|
|||
債権``管理・回収``アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
支払期日経過
|
`請求書`が正式に`期日`経過したことを示す`計算済み``イベント`です。これは明示的な`システム``イベント`ではなく、`請求書`の正味`期日`を現在の日付または後続の`アクティビティ`の`タイムスタンプ`と比較することによって派生されます。 | ||
|
その重要性
このイベントは、標準請求から債権回収プロセスへの移行を示します。これは、延滞日数を計算し、督促手続きを開始するためのトリガーであり、年齢分析レポートの基礎となります。
取得元
これは計算されたイベントです。未決済請求書明細の純期日(BSID-NETDT)とシステム日付または別のイベントのタイムスタンプを比較することで導出されます。
取得
イベントタイプ
calculated
|
|||
|
督促実行
|
このアクティビティは、延滞請求書に対する自動督促プログラムの実行を表します。システムは、督促実行に含まれる各請求書について、督促レベル、日付、その他の詳細を記録します。 | ||
|
その重要性
督促活動の追跡は、債権回収戦略の有効性を評価するために不可欠です。どの督促段階が最も効果的に支払いを促しているかを特定し、対応しない顧客を見つけるのに役立ちます。
取得元
これは明示的なイベントです。督促実行の詳細は、主にMHNK(督促データ)という督促データテーブルに保存され、各督促済み請求書の実行日(LAUFD)と督促レベル(MAHNS)が含まれています。
取得
イベントタイプ
explicit
|
|||
|
請求書 消込済み
|
このイベントは、請求書の正常なクローズを示します。通常、全額の支払いが受領され適用された後です。請求書明細項目が未決済項目テーブル(BSID)から消込済み項目テーブル(BSAD)に移動したときに推測されます。 | ||
|
その重要性
これはプロセスの主要な「良い」終了イベントです。この活動に到達するまでの時間はDSOの中核要素です。ここに繋がるパスを分析することは、ベストプラクティスを特定するのに役立ちます。
取得元
これは推測されたイベントです。消込は、請求書明細に対する消込伝票(AUGBL)および消込日付(AUGDT)の存在によって識別され、これは消込済み項目テーブルBSADに見られます。
取得
特定の請求書明細のクリアリング日付(BSAD-AUGDT)をイベントのタイムスタンプとして使用します。
イベントタイプ
inferred
|
|||
|
請求書仕訳計上済み
|
財務会計モジュールにおける売掛金請求書伝票の作成を表します。このイベントは、販売管理(SD)からの請求伝票が会計にリリースされたとき、またはFI請求書が直接入力され、テーブルBKPFおよびBSEGにエントリが作成されたときに明示的に取得されます。 | ||
|
その重要性
これは請求書ライフサイクルの主要な開始イベントです。この時点から支払いまでの時間を分析することは、売掛金回収日数(DSO)と全体的なプロセス効率を測定するために非常に重要です。
取得元
これは、財務伝票作成時に記録される明示的なイベントです。イベントのタイムスタンプは、対応する請求書伝票番号(BELNR)について、伝票ヘッダテーブルBKPF(フィールドCPUDTまたはBKTXT)から取得できます。
取得
テーブルBKPF内の関連する伝票タイプ(例:'RV'、'DR')を持つFI伝票の作成イベントを特定します。
イベントタイプ
explicit
|
|||
|
請求書償却済み
|
未払い請求書を損失として吸収し、貸倒債権として分類する決定を表します。これは、元の請求書を消し込み、金額を貸倒勘定に振り替える特定の財務記帳によって捕捉されます。 | ||
|
その重要性
これは主要な「悪い」終了イベントであり、与信または債権回収プロセスの失敗と直接的な財務損失を意味します。これらのケースを分析することは、与信ポリシーと債権回収戦略を改善するために不可欠です。
取得元
これは通常、明示的な記帳または消込取引に基づいて推測されるイベントです。消込は、貸倒処理を示す特定の取引コードと理由コードを使用して行われます。消込伝票を分析することで、貸倒処理を確認できます。
取得
貸倒のための特定の理由コード (BSEG-RSTGR) が使用されている消込伝票、または相手勘定科目が貸倒費用勘定に記帳されている消込伝票を特定します。
イベントタイプ
inferred
|
|||
|
`回収``連絡`記録
|
`回収`担当者が、`期日`経過した`請求書`について`電話`や`メール`などで`連絡`を取った`アクティビティ`です。この`アクティビティ`は、通常、`回収`担当者によって`システム`に手動で`ログ`されます。 | ||
|
その重要性
このアクティビティは、債権回収チームの手動作業を測定します。コンタクトの頻度とタイミングをその後の支払いと比較分析することで、債権回収担当者の行動の有効性を判断するのに役立ちます。
取得元
SAP FSCM Collections Managementをご利用の場合、これは「顧客コンタクト」として記録されます。詳細は、債権回収ワークリストおよびコンタクト履歴に関連するテーブルに保存され、多くの場合UDM_CASEにリンクされています。
取得
関連するFSCM Collections Management
イベントタイプ
explicit
|
|||
|
クレジットメモ計上済
|
顧客勘定に対するクレジットメモ伝票の作成を表し、多くの場合、請求エラーの修正や紛争の解決のために行われます。この伝票はFIモジュールで明示的に作成されます。 | ||
|
その重要性
取得元
これは、クレジットメモ伝票タイプ(例:'DG')を持つ財務伝票の作成時に捕捉される明示的なイベントです。イベントのタイムスタンプは伝票ヘッダテーブルBKPFから取得できます。
取得
テーブルBKPF内のクレジットメモ伝票タイプ(例:'DG'、'G2')を持つFI伝票の作成イベントを特定します。
イベントタイプ
explicit
|
|||
|
入金伝票が記帳されました
|
顧客からの支払いがシステムに最初に記録されることを表し、多くの場合、特定の請求書に適用される前です。これは、たとえばDZ伝票タイプのような支払伝票を作成する明示的なイベントです。 | ||
|
その重要性
これは現金の受領を示します。このイベントと最終的な「請求書消込」イベント間の時間差は、重要なボトルネックとなる可能性があるキャッシュアプリケーションプロセスを表します。
取得元
これは明示的なイベントです。テーブルBKPFでの支払伝票の作成から捕捉され、特定の伝票タイプ(例:「DZ」)で識別可能です。転記日付(BKPF-BUDAT)がタイムスタンプとして機能します。
取得
テーブルBKPF内の支払い関連伝票タイプ(例:'DZ')を持つ伝票の作成を特定します。
イベントタイプ
explicit
|
|||
|
支払約束不履行
|
`顧客`が「`支払い`約束」で合意された期日までに`支払い`を行わなかったことを示す`計算済み``イベント`です。これは、約束の日までに対応する`支払い`がないことから推測されます。 | ||
|
その重要性
支払約束の不履行を特定することは、債権回収努力を強化するために不可欠です。支払約束の不履行率が高い場合、債権回収戦略または顧客の財務健全性に問題がある可能性があります。
取得元
これは推測または計算されたイベントです。約束日(UDM_P2P_ATTRから)と請求書の実際の支払消込日を比較することによって決定されます。約束日までに支払いが受領されない場合、約束は破られたとみなされます。
取得
UDM_P2P_ATTR内の約束日と
イベントタイプ
calculated
|
|||
|
支払約束作成
|
`顧客`が`回収``部門`に`連絡`し、特定の日付までに`支払い`を行うことを約束したものです。この`イベント`は、SAP FSCM Collections Managementが使用されている場合に明示的に`ログ`されます。 | ||
|
その重要性
支払約束は債権回収活動の主要な成果です。その作成、履行、不履行率を分析することで、債権回収担当者の行動の有効性を測定し、キャッシュインフローを予測するのに役立ちます。
取得元
SAP FSCM Collections Managementをご利用の場合、これは明示的なイベントです。支払約束の詳細は、取引先および請求書にリンクされたUDM_P2P_ATTRのようなテーブルに保存されます。
取得
SAP FSCMのUDM_P2P_ATTRなどの
イベントタイプ
explicit
|
|||
|
残余明細の作成
|
支払適用時に顧客が請求書を過少支払いし、残りの少額残高が新しい未決済項目として記帳される場合に発生します。これは、消込取引の詳細から推測されます。 | ||
|
その重要性
残余明細は支払い差異を示し、追加の作業を生み出します。これらを追跡することで、頻繁に過少支払いを行う顧客を特定し、紛争につながる価格設定や請求の問題を浮き彫りにします。
取得元
これは推測されたイベントです。消込取引(例:F-28経由)が元の請求書を消込し、かつ残額に対して新しい未決済項目伝票を記帳する場合、残余明細が作成されます。これは、消込伝票の明細項目を確認することで特定できます。
取得
イベントタイプ
inferred
|
|||
|
異議申し立てケース作成
|
請求書に関連する顧客の異議申し立て(価格や数量の不一致など)の正式な登録を表します。これは、SAP FSCM Dispute Managementモジュール内に記録される明示的なイベントです。 | ||
|
その重要性
紛争は
取得元
SAP FSCM Dispute Managementをご利用の場合、これは明示的なイベントです。異議申し立てケースの作成は、UDM_CASEまたはSCMG_T_CASE_ATTRのようなテーブルに作成タイムスタンプとともに記録されます。
取得
イベントタイプ
explicit
|
|||
|
紛争`ケース`解決済み
|
請求書に関連する異議申し立てが調査され、解決策が合意されました。これは通常、SAP FSCM Dispute Managementの異議申し立てケースのステータス変更によって捕捉されます。 | ||
|
その重要性
異議申し立ての解決は、支払いプロセスをブロック解除します。異議申し立ての作成から解決までの時間を測定することは、異議申し立て処理プロセスにおける非効率性を特定するための重要なKPIです。
取得元
これは異議申し立てケースのステータス変更から推測されるイベントです。UDM_CASEのようなテーブルにおける異議申し立てケースのステータスフィールドの変更ログ(CDHDR/CDPOS)がタイムスタンプを提供します。
取得
変更ログを分析することで、異議申し立てケースのステータスが「クローズ」または「解決済み」に変更されたタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
請求書 支払ブロック
|
請求書に手動または自動の支払ブロックが設定され、支払いができない状態であることを示します。これは、BSEGテーブルの請求書明細項目に設定された特定の支払ブロック指標によって取得されます。 | ||
|
その重要性
支払ブロックは、遅延やプロセス例外の主要な原因となります。請求書がいつ、なぜブロックされるのかを特定することは、支払い遅延の根本原因を突き止め、キャッシュフローを改善するための鍵となります。
取得元
このステータスは通常、請求書明細項目における支払ブロックフィールド(BSEG-ZLSPR)の変更から推測されます。このフィールドの変更ログ(テーブルCDHDRおよびCDPOS)は、明示的なタイムスタンプを提供できます。
取得
イベントタイプ
inferred
|
|||