債権管理・回収データテンプレート
SAP S/4HANA債権管理・回収データテンプレート
- イベントログに収集を推奨する属性
- 請求書ライフサイクル全体で追跡すべき主要なプロセス活動
- SAP S/4HANA向けの具体的なデータ抽出ガイダンス
債権管理・回収属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
信用管理および回収プロセスで発生した特定のビジネスイベントの名前。 | ||
|
説明
この属性は、「請求書生成済み」、「督促手続き開始済み」、「支払い受領済み」など、プロセス内の単一のステップまたはタスクを記述します。これらの活動のシーケンスが、各ケースのプロセスフローを形成します。 活動名の分析は、プロセスマイニングにとって基本であり、プロセスマップの発見、バリアントの特定、および異なるステップ間の遷移の測定を可能にします。これは、督促活動に続くイベントを追跡する「督促成功率」のようなKPI計算を含む、ほぼすべてのプロセス分析の基礎となります。
その重要性
プロセスのステップを定義するものであり、プロセスマップの可視化、バリアントの分析、およびプロセスフローの理解に不可欠です。
取得元
トランザクションコード(TCODE)、テーブル変更ログ(CDHDR/CDPOS)、またはSAPドキュメント内のステータスフィールドの組み合わせから生成されます。
例
顧客へ請求書送付督促手続き開始入金確認済み異議申し立てケース登録
|
|||
|
イベント日時
EventTime
|
アクティビティの発生時刻を示すタイムスタンプです。 | ||
|
説明
この属性は、記録された各活動の正確な日付と時間を提供します。イベントのシーケンスを決定し、それらの間の期間を計算するために重要です。 イベントタイムは、活動を時系列に並べ、プロセスマップを構築し、パフォーマンスメトリクスを計算するために使用されます。たとえば、「異議申し立て登録」タイムスタンプと「異議申し立て解決」タイムスタンプ間の期間を測定することで、「平均異議申し立て解決時間」を計算するために使用されます。
その重要性
イベントの時系列順序を提供し、サイクル時間の計算、プロセスパフォーマンスの分析、およびボトルネックの発見に必要です。
取得元
BKPFテーブルのBUDAT(転記日付)や、さまざまなテーブルのCPUDT/CPUTM(入力日付/時刻)など、SAPテーブル内の様々な日付/時刻フィールドから取得されます。変更ログテーブルCDHDR/CDPOSにもタイムスタンプが含まれます。
例
2023-04-15T10:00:00Z2023-05-01T14:30:00Z2023-05-10T09:15:00Z
|
|||
|
請求書番号
InvoiceNumber
|
顧客請求書の一意な識別子であり、債権管理・回収プロセスの主要なケースIDとして機能します。 | ||
|
説明
請求書番号は、多くの場合会計伝票番号として表現され、各債権取引を一意に識別します。請求書作成や督促通知から、異議申し立て管理、最終的な支払いまたは償却に至るまで、すべてのプロセスイベントを結びつける中心的な役割を果たします。 プロセスマイニングでは、各請求書番号のジャーニーを分析することで、エンドツーエンドのプロセスの全体像を把握できます。これにより、共通の経路、支払い処理のボトルネック、異なる請求書の処理におけるバリエーションを特定することができ、「請求書プロセスバリアント分析」や「期限超過請求書の経過とステータス」のようなダッシュボードにとって不可欠です。
その重要性
すべての関連する与信および回収活動をリンクする不可欠なケース識別子であり、各債権の完全なライフサイクル分析を可能にします。
取得元
通常、BKPF(会計伝票ヘッダー)テーブルのBELNRフィールド、またはVBRK(請求伝票:ヘッダーデータ)テーブルのVBELNフィールドにあります。
例
190000012319000004561900000789
|
|||
|
ユーザー名
UserName
|
`アクティビティ`を実行した担当者の`ユーザーID`です。 | ||
|
説明
この属性は、支払い転記や督促実行の開始など、特定のプロセスステップを担当するユーザーを識別します。SAPでは、これはしばしば「ユーザー名」(UNAME)または「入力者」フィールドとして保存されます。 ユーザーによる分析は、高いパフォーマンスを発揮する個人やチーム、追加トレーニングが必要な領域、および作業負荷の分散パターンを特定するのに役立ちます。また、コンプライアンスの問題や不正な活動を調査するためにも使用できます。たとえば、「回収電話有効性」ダッシュボードでは、回収担当者ごとの成果を追跡することでサポートされます。
その重要性
プロセス活動を特定の個人にリンクさせ、リソースパフォーマンス、ワークロード、およびコンプライアンスの分析を可能にします。
取得元
BKPF(項目USNAM)のようなヘッダーテーブルや、CDHDR(項目USERNAME)のような変更ログテーブルで一般的に見られます。
例
JSMITHRROEBATCH_USER
|
|||
|
延滞日数
DaysOverdue
|
請求書が支払期日を過ぎてからの日数。 | ||
|
説明
これは、「支払期日」と現在日(未決済請求書の場合)または「支払日」(消込済み請求書の場合)の経過時間を測定する算出メトリクスです。正の値は遅延支払いを示します。 期限超過日数は、回収における重要なKPIです。「期限超過請求書の経過とステータス」ダッシュボードの主要メトリクスであり、回収努力の優先順位付けに使用されます。このメトリクスの分布を分析することで、売掛金ポートフォリオ全体の健全性を理解するのに役立ちます。
その重要性
回収効果の重要な業績評価指標であり、期日経過分析、作業の優先順位付け、および支払い遅延の測定に使用されます。
取得元
データ変換時に計算されます:(現在日付または消込日付)-支払期日 (BSEG-ZFBDT)。
例
1530920
|
|||
|
支払期日
PaymentDueDate
|
請求書の支払期日です。 | ||
|
説明
支払期日は、請求書発行日と顧客との合意済み支払条件に基づいて計算されます。これは、支払いの適時性を測定するための基準となります。 この日付は、すべての期限超過分析にとって基本的です。「期限超過日数」の計算や督促手続きのトリガーとなる出発点です。「期限超過請求書の経過とステータス」のようなダッシュボードや、「平均売掛金回収日数(DSO)」のようなKPIは、この属性に大きく依存しています。
その重要性
請求書が延滞しているかどうかを判断し、回収活動をトリガーし、重要なKPIを計算するための重要な日付です。
取得元
会計伝票の得意先明細項目、テーブルBSEG(項目ZFBDT)で見られます。
例
2023-05-302023-06-152023-07-01
|
|||
|
請求金額
InvoiceAmount
|
伝票通貨建ての請求書の合計金額。 | ||
|
説明
この属性は、請求された商品またはサービスの総金銭的価値を表します。各ケースの財務的影響を測る重要な指標です。 「回収ポートフォリオ優先順位付け」ダッシュボードで見られるように、請求金額の分析は回収努力の優先順位付けにとって不可欠です。また、異議申し立てされた請求書の総額や期限超過債権に拘束されている資金の額など、プロセスの非効率性の財務的影響を評価するためにも使用されます。「請求書償却率」のようなKPIを、その価値基準を提供することで直接サポートします。
その重要性
各ケースの財務的価値を定量化するものであり、優先順位付け、リスク評価、およびパフォーマンス測定に不可欠です。
取得元
テーブルBSEGの会計伝票明細項目から導出されます(現地通貨額の場合はDMBTRフィールド、伝票通貨額の場合はWRBTRフィールド)。
例
1500.0025000.50750.75
|
|||
|
顧客番号
CustomerNumber
|
顧客アカウントの一意の識別子。 | ||
|
説明
顧客番号は、請求書が発行された取引先の識別子です。これは、財務取引を顧客のマスターデータレコードにリンクさせます。 この属性は、特定の顧客やセグメントの支払い行動を特定するなど、顧客中心の分析に不可欠です。「顧客支払行動トレンド」のようなダッシュボードで使用され、どの顧客が常に支払いを遅延させているかを追跡したり、請求書を顧客ごとにグループ化することで「高優先度アカウントカバレッジ」のようなKPIをサポートしたりします。
その重要性
取引を特定の顧客にリンクさせ、支払い行動、セグメンテーション、および関係管理の分析を可能にします。
取得元
BSEG(項目KUNNR)のような会計伝票明細テーブルや、顧客マスタデータテーブルKNA1で見られます。
例
CUST100234CUST200567CUST300890
|
|||
|
`督促``レベル`
DunningLevel
|
延滞請求書に対する督促プロセスの現在の段階を示します。 | ||
|
説明
督促レベルは、回収努力の度合いを表し、通常は簡単なリマインダーからより正式な法的通知へと段階的にエスカレートします。各レベルは、督促手続きで定義された特定の督促活動に対応します。 この属性を追跡することは、督促プロセスの有効性とコンプライアンスを監視するために不可欠です。「督促プロセス有効性」ダッシュボードは、これを様々なレベルでの支払い率分析に利用し、「督促プロセスコンプライアンス」ダッシュボードは、レベルの順序が正しく守られているかを確認します。
その重要性
回収活動の進行状況を追跡し、督促の効果とプロセスコンプライアンスの分析を可能にします。
取得元
この情報は、MHND(督促データ)のような督促データテーブルに保存されています。アイテムの最終督促レベルは、BSEG(項目MANST)で見つけることができます。
例
123 - 最終通知法的措置
|
|||
|
ソースシステム
SourceSystem
|
`データ`の出所となった`システム`を特定します。 | ||
|
説明
この属性は、ソース情報システムを指定します。この場合はSAP S/4HANAです。異なるERPインスタンスや個別のCRMなど、複数のシステムからデータが統合される可能性のある環境では特に重要です。 プロセス分析において、これは複数のシステムにまたがる可能性のあるプロセスを区別したり、分析を特定のシステムインスタンスにフィルターしたりするのに役立ちます。データの系統を確保し、特にデータ検証やトラブルシューティング中にコンテキストを提供します。
その重要性
データの出所に関する重要なコンテキストを提供し、マルチシステム環境での明確性を確保し、データガバナンスを支援します。
取得元
これは通常、データ抽出プロセス中に追加される静的な値で、特定のSAP S/4HANAインスタンス(例:システムIDまたはSIDによる)を識別します。
例
S4H_PROD_100S4HANA_FINANCE_EUSAP_ECC_US
|
|||
|
会社コード
CompanyCode
|
財務諸表が作成される、法的に独立した会社を表す組織単位。 | ||
|
説明
会社コードは、SAP財務管理における基本的な組織エンティティです。請求書や支払いを含むすべての財務取引は、特定の会社コードに転記されます。 プロセスマイニングでは、会社コードによるフィルタリングやディメンション設定は、企業内の異なる法人間でプロセスパフォーマンスを比較するために不可欠です。これにより、ある法人におけるベストプラクティスを他の法人に適用したり、特定の企業に影響を与えるシステム上の問題を特定したりできます。これは、ほぼすべての財務プロセス分析における重要なフィルターとなります。
その重要性
組織内の異なる法人間でプロセスパフォーマンスとコンプライアンスを比較することを可能にします。
取得元
BKPFやBSEG(項目BUKRS)など、ほとんどの財務テーブルで見られます。
例
10002000US01DE01
|
|||
|
信用限度
CreditLimit
|
顧客に付与される信用供与の最大額。 | ||
|
説明
信用限度額は、顧客の信用マスターデータに保存されている値で、企業がその顧客に対して許容する総信用供与額を定義します。「信用限度額申請」や「信用限度額承認」といった活動は、この属性に直接関連します。 この属性は信用リスク分析のコンテキストを提供します。「信用承認サイクルタイム分析」ダッシュボードは、この限度額の設定または変更プロセスを追跡します。これを期限超過額と合わせて分析することで、ポートフォリオ全体のリスを評価するのに役立ちます。
その重要性
顧客に対する承認された信用リスクを定義し、与信承認プロセスおよび全体的な信用エクスポージャーを分析する上で中心的です。
取得元
SAP信用管理(FSCM)モジュール内のUKM_BP_CMS_SGMT(項目CREDIT_LIMIT)などのテーブルに保存されています。
例
50000.00100000.00250000.00
|
|||
|
償却理由
WriteOffReason
|
請求書が回収不能として償却された理由を説明する理由コード。 | ||
|
説明
債権が回収不能と見なされると、帳簿から償却され、「倒産」、「少額償却」、「未解決の異議申し立て」など、その原因を分類するための理由コードが割り当てられます。 この属性は、「請求書償却分析」ダッシュボードにとって不可欠です。理由ごとの償却の頻度と金額を分析することで、企業は信用ポリシーや回収戦略の弱点を特定し、将来の損失を最小限に抑えるための是正措置を講じることができます。
その重要性
回収不能な債務による財務損失の根本原因を説明し、与信および回収ポリシーの改善に役立つ情報を提供します。
取得元
これは、売掛金償却に使用される特定の財務転記トランザクション(例:F-30)中に、理由コードフィールド(BSEG-RSTGR)を介して捕捉されることがよくあります。
例
倒産SMALL_BALANCE異議申し立てによる損失
|
|||
|
最終データ更新
LastDataUpdate
|
ソースシステムからの最新のデータ更新/抽出時点を示すタイムスタンプ。 | ||
|
説明
この属性は、データセットが最後に更新された日時を示します。ユーザーに分析しているデータの鮮度に関するコンテキストを提供します。 これは、あらゆるダッシュボードや分析にとって重要なメタデータです。分析がカバーする期間をユーザーに伝え、古い情報に基づく誤解を防ぎます。たとえば、期限超過請求書の分析は、ユーザーがデータがいつ最後に取得されたかを知っている場合にのみ意味があります。
その重要性
ユーザーがデータの適時性を理解することを保証し、これは正確なデータに基づいた意思決定を行う上で不可欠です。
取得元
この値は、データ抽出、変換、ロード(ETL)プロセス中に生成され、保存されます。
例
2023-10-27T02:00:00Z2023-10-26T02:00:00Z
|
|||
|
処理時間
ProcessingTime
|
特定の活動の期間。 | ||
|
説明
この属性は、活動の完了にかかる時間を測定し、活動の終了時刻と開始時刻の差として計算されます。これは、瞬間的ではない活動に最も関連性が高いです。 SAPにおける多くの財務取引では、開始時刻と終了時刻は同じです。しかし、異議申し立ての解決のようなプロセスでは、この指標はケースが特定のステータスで費やす時間を測定できます。これは、転記活動の期間を測定することで「支払転記サイクルタイム」のようなKPIを直接サポートします。
その重要性
プロセスにおける潜在的なボトルネックである時間のかかる活動を特定するのに役立ちます。
取得元
イベントデータから(終了時刻-開始時刻)として計算されます。各アクティビティについて開始時刻と終了時刻の両方のタイムスタンプが必要です。
例
P1DPT2H30MP3DT5H
|
|||
|
紛争理由
DisputeReason
|
顧客が請求書に異議を申し立てる理由として提供される理由コード。 | ||
|
説明
顧客が請求書に異議を申し立てる際、通常、「誤った価格設定」、「破損品」、「重複請求書」など、問題の性質を分類するための理由が割り当てられます。これはSAP Dispute Managementモジュールで管理されます。 異議申し立て理由の分析は、顧客不満と支払い遅延の根本原因を特定するために重要です。「請求書異議申し立て件数と解決」ダッシュボードは、この属性によって分類することができ、上流の受注から現金化までのプロセスにおける繰り返しの問題を特定し、修正が必要な箇所を明確にします。
その重要性
請求書に関する異議申し立ての根本原因について重要な洞察を提供し、根本的な運用上の問題を特定し解決するのに役立ちます。
取得元
SAP Dispute Managementモジュールから取得され、異議申し立てケースの属性に基づいて、UDM_SCASE_ATTRなどのテーブルから取得されると考えられます。
例
PRC_ERR - 価格設定エラーQTY_DIF - 数量差異SHIP_DMG - 出荷破損
|
|||
|
自動化
IsAutomated
|
当該アクティビティがシステムユーザーによって実行されたか、人間によって実行されたかを示すフラグです。 | ||
|
説明
このブール属性は、システムによって自動的に実行される活動(例:スケジュールされた督促実行、自動支払転記)と、ユーザーによって手動で実行される活動(例:回収電話)を区別します。 この属性を分析することは、プロセスにおける自動化のレベルを測定するのに役立ちます。自動化されたステップと手動ステップの効率性と一貫性を比較し、さらなる自動化の機会を特定し、回収プロセスにおける実際の手作業の労力を理解することを可能にします。
その重要性
プロセスにおける自動化のレベルを定量化し、効率とコストに対する自動化の影響を分析することを可能にします。
取得元
これは通常「UserName」に基づいて導出される属性です。ユーザーIDがシステムまたはバッチユーザーの事前定義されたリスト(例:「BATCH_USER」)と一致する場合、フラグはtrueに設定されます。
例
truefalse
|
|||
|
請求通貨
InvoiceCurrency
|
請求書が発行された通貨。 | ||
|
説明
この属性は、請求金額の通貨コード(例:USD、EUR)を指定します。特に多国籍企業において、金銭的価値を解釈するために必要なコンテキストを提供します。 ほとんどの分析は標準化された現地通貨で行われますが、伝票通貨は元の取引を理解し、外国為替の影響に関連するあらゆる分析にとって重要です。InvoiceAmount属性にコンテキストを提供します。
その重要性
請求書金額に不可欠なコンテキストを提供し、多通貨環境での正確な財務分析を可能にします。
取得元
通常、BKPF(項目WAERS)のようなヘッダーテーブル、またはBSEG(項目PSWSL)のような明細テーブルにあります。
例
USDEURGBP
|
|||
|
顧客セグメント
CustomerSegment
|
顧客の分類であり、例えば規模、業界、戦略的重要性などに基づいて行われます。 | ||
|
説明
顧客セグメントとは、年間収益、業界、地理的所在地、関係ステータス(例:ゴールド、シルバー、ブロンズ)などの要素に基づき、類似した特性を持つ顧客をグループ化するために使用されるマーケティングまたは営業上の分類です。 回収分析では、この属性でセグメント化することにより、特定のグループに固有のパターンを発見するのに役立ちます。例えば、「請求書償却分析」ダッシュボードは、特定のセグメントが不均衡な量の償却の原因となっているかどうかを明らかにし、そのセグメントの信用ポリシーに関する戦略的意思決定を導きます。
その重要性
異なる顧客グループ間でのプロセスパフォーマンスと顧客行動の分析を可能にし、貴重な戦略的インサイトを明らかにします。
取得元
通常、顧客マスターデータ(テーブルKNA1)から取得され、多くの場合、KDKG1-KDKG5(顧客グループ1-5)のような分類または属性フィールドにあります。
例
大企業中小企業政府戦略的アカウント
|
|||
債権管理・回収活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
入金確認済み
|
この活動は、顧客からの資金受領を表し、それが未決済請求書に適用されます。これは、請求金額を決済する消込伝票の作成によって捕捉されます。 | ||
|
その重要性
これはキャッシュフローとDSOに直接影響する重要なマイルストーンです。支払いまでの時間とそれに先行する活動を分析することで、回収プロセス全体の有効性が明らかになります。
取得元
これは、請求書に対して転記された消込伝票から推測されます。特定の請求書について、消込済み品目テーブルBSADからの消込日付(AUGDT)がタイムスタンプを提供します。
取得
対応する請求書伝票番号(BELNR)について、BSADテーブルから消込日付(AUGDT)を特定します。
イベントタイプ
inferred
|
|||
|
支払期日経過
|
請求書の正味支払期日を過ぎても入金処理が行われなかった場合に発生する計算イベントです。請求書が「現行」ステータスから「延滞」ステータスに移行したことを示します。 | ||
|
その重要性
この活動は、すべての回収および督促活動のトリガーとなります。支払い行動、期限超過の理由、およびプロアクティブなリマインダーの有効性を分析するために不可欠です。
取得元
これは明示的なログではありません。正味支払期日(BSIDテーブルのZFBDTフィールドなどから)と、分析または後続活動のタイムスタンプを比較して計算されます。
取得
請求書正味支払期日 (BSID-ZFBDT) を現在のタイムスタンプまたは後続イベントのタイムスタンプと比較して導出します。
イベントタイプ
calculated
|
|||
|
異議申し立てケース登録
|
この活動は、顧客が請求書に正式に異議を申し立て、SAP Dispute Managementでケースが作成されたことを意味します。これは、新しい異議申し立てケースが作成され、請求書伝票にリンクされたときに捕捉されます。 | ||
|
その重要性
異議申し立ての登録は、プロセス例外を理解するための重要なステップです。異議申し立ての件数、理由、および解決時間を分析することで、価格設定や出荷エラーなどの根本原因を特定できます。
取得元
これはSAP Dispute Managementテーブルに記録される明示的なイベントです。UKM_CASEやFDM_DCOBJのようなテーブルで請求書にリンクされたケースの作成日付がタイムスタンプとして機能します。
取得
UKM_CASEテーブルから異議申し立てケースの作成タイムスタンプを使用し、異議申し立てのケースタイプでフィルタリングします。
イベントタイプ
explicit
|
|||
|
請求書の精算完了
|
これは請求書にとって最終的かつ成功した結果であり、完全に支払いが行われ、未決済項目から消し込まれたことを示します。この状態は、請求書に対応する消込伝票と日付がある場合に認識されます。 | ||
|
その重要性
このプロセスにおける主要な成功終点として、この活動は請求書ライフサイクルを完結させます。この状態に至るまでの経路と所要時間を分析することは、プロセス最適化の基本です。
取得元
これは個別のイベントではなく、財務テーブルから推測される状態です。請求書は、消込済み顧客明細テーブルBSADに表示され、有効な消込日付(AUGDT)を持つ場合に決済済みとみなされます。
取得
この完了活動のタイムスタンプとして、BSADテーブルの消込日付(AUGDT)を使用します。
イベントタイプ
inferred
|
|||
|
請求書償却済み
|
この活動は、未払い請求書を損失として吸収し、不良債権として分類する決定を表します。これは、特定のタイプの消込伝票が、しばしば固有の理由コードとともに転記されたときに捕捉されます。 | ||
|
その重要性
償却は直接的な財務損失を表します。その頻度、金額、および先行活動を分析することは、リスクのある顧客や回収プロセスにおける失敗を特定するのに役立ちます。
取得元
これは、請求書を決済する消込伝票を分析することで推測できます。消込伝票で使用される特定の総勘定元帳勘定または理由コード(BSEG-RSTGR)は、償却を示します。
取得
消込伝票を特定し、特定の理由コードまたは不良債権勘定への記帳を確認します。
イベントタイプ
inferred
|
|||
|
請求書生成済み
|
この活動は、顧客請求書の作成を示し、回収プロセスの出発点となります。このイベントは、SAP S/4HANAシステムで請求書伝票タイプを持つ新しい会計伝票が転記されたときに捕捉されます。 | ||
|
その重要性
これは、請求書から現金化までのプロセスの主要な開始イベントです。この時点から支払いまでの時間を分析することは、売掛金回収日数(DSO)と全体的なプロセス効率を測定するために不可欠です。
取得元
このイベントは明示的に記録されます。作成日付と時刻は、関連する伝票番号(BELNR)の会計伝票ヘッダーテーブルBKPFにあります。「RV」のような伝票タイプは通常、顧客請求書を示します。
取得
請求書伝票については、BKPFテーブルの伝票作成タイムスタンプ(CPUDT、CPUTM)を使用します。
イベントタイプ
explicit
|
|||
|
回収コール実施
|
期限超過請求書に関して、回収担当者が顧客に対して手動で行った連絡を示します。これは標準的なSAPイベントではないことが多く、カスタムログ記録またはCRMシステムとの統合に依存します。 | ||
|
その重要性
手作業による介入は、回収プロセスにおいてコストのかかる部分です。これらの電話対応を追跡することで、回収担当者の有効性を測定し、どの口座に手作業が必要かを把握できます。
取得元
この情報は、標準のS/4HANA設定では通常利用できません。カスタムテーブル、回収ワークリストのメモ、または統合が必要な外部CRMシステムに保存されている可能性があります。
取得
システム拡張機能、注記、または回収活動がログに記録されている外部システムからのデータの分析が必要です。
イベントタイプ
explicit
|
|||
|
支払い計上
|
支払いが総勘定元帳に記録される会計エントリを表します。多くの場合、これは支払い受領と同時に行われますが、独自の遅延を伴う別のステップとなることもあります。 | ||
|
その重要性
入金から記帳までの遅延は、財務報告を歪める可能性があります。このサイクル時間を測定することで、会計プロセスが効率的かつ正確であることを保証するのに役立ちます。
取得元
このイベントは、BKPFテーブルにある消込伝票の転記日付(BUDAT)または作成日付(CPUDT)から推測できます。消込伝票番号はBSAD-AUGBLにあります。
取得
請求書を決済した消込伝票については、BKPFテーブルの転記日付(BUDAT)を使用します。
イベントタイプ
inferred
|
|||
|
支払約束作成済み
|
このイベントは、回収担当者が顧客の期限超過品目に対する特定の期日での支払い約束を記録したときに発生します。これは、SAP Collections Managementモジュール内の明示的なアクションです。 | ||
|
その重要性
支払約束は、回収活動の重要な成果です。その頻度、履行率、および支払い時間に与える影響を分析することで、回収戦略の改善に役立ちます。
取得元
これはSAP Collections Managementに記録される明示的なイベントです。支払約束の作成日は、UDM_P2P_ATTRのようなテーブルから取得できます。
取得
請求書にリンクされたUDM_P2P_ATTRなどの支払約束テーブルから作成日を使用します。
イベントタイプ
explicit
|
|||
|
督促手続き開始
|
この活動は、期限超過請求書に対する自動督促プロセスの正式な開始を表します。これは、督促実行が請求書を処理し、督促レベルを割り当てたときに捕捉されます。 | ||
|
その重要性
これは自動回収の開始を示します。督促活動を追跡することは、督促戦略の有効性を評価し、内部ポリシーへのコンプライアンスを確保するために重要です。
取得元
これは、督促データテーブルに明示的に記録されるイベントです。請求書に関連付けられた督促ヘッダーテーブルMHNKからの実行日付(LAUFD)は、手続きがいつ実行されたかを示します。
取得
特定の請求書に対する督促実行日 (MHNK-LAUFD) と督促レベル (MHNK-MAHNS) を抽出します。
イベントタイプ
explicit
|
|||
|
紛争解決済み
|
この活動は、顧客の主張が妥当とされたか、または却下されたかによって、異議申し立てケースのクローズを示します。これは、異議申し立てケースのステータスが「クローズ済み」または「解決済み」に更新されたときに捕捉されます。 | ||
|
その重要性
異議申し立ての解決にかかる時間は、顧客満足度と業務効率の主要な業績評価指標(KPI)です。解決に時間がかかると、支払いが遅延し、顧客関係に負担がかかる可能性があります。
取得元
これは異議申し立てケースのステータス変更から推測されます。UKM_CASEテーブルでのステータスが「クローズ済み」または「確認済み」への変更に関連するタイムスタンプは、解決がいつ発生したかを示します。
取得
UKM_CASEテーブルまたは関連するステータス変更ログテーブル内で、最終的かつ解決済みのステータスへの変更のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
顧客へ請求書送付
|
請求書が顧客に(印刷、メール、EDIなどを介して)送信された時点を示します。これは通常、出力メッセージが処理された日時を記録するSAPの出力決定ログを通じて捕捉されます。 | ||
|
その重要性
請求書作成から送付までの遅延は、支払いサイクル全体を延長する可能性があります。これを追跡することで、顧客コミュニケーションおよび文書配布におけるボトルネックを特定するのに役立ちます。
取得元
これは、メッセージステータスNASTテーブル内の処理日付と時刻から推測できます。このテーブルでは、出力タイプが顧客請求書に対応しています。出力決定の適切な設定が必要です。
取得
請求書の請求伝票番号にリンクされたNASTテーブル内の、正常に処理されたレコードを検索します。
イベントタイプ
inferred
|
|||