貴社の信用管理・債権回収データテンプレート
貴社の信用管理・債権回収データテンプレート
- 包括的な分析のために収集を推奨する`属性`
- 正確な発見のために追跡すべき主要なプロセスアクティビティ
- システムからのデータ抽出に関する実践的なガイダンス
債権管理・回収属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
請求書ライフサイクルのある時点で発生した特定のイベントまたはタスクの名前。 | ||
|
説明
アクティビティ名には、「Invoice Generated」「Dunning Letter Sent」「Payment Received」など、信用管理および債権回収プロセス内の特定のステップやイベントが記述されます。この属性は、プロセスマップのノードを定義するため、プロセスマイニングの根幹をなすものです。これらのアクティビティの順序と頻度を分析することで、実際プロセスフローが明らかになり、手戻りループ、非効率性、コンプライアンス違反のプロセスパスを特定できます。これは、すべてのプロセスフロー可視化の作成を直接サポートし、プロセスの異なる段階間のサイクルタイム計算をセグメント化するために使用されます。
その重要性
この属性はプロセスマップのステップを定義し、請求書ライフサイクルを可視化・分析することを可能にします。
取得元
この属性は通常、「CustInvoiceJour」、「CustTrans」、「CustCollectionLetterJour」、「CustPaymPromise」などのさまざまなテーブルからの特定のシステムイベント、ステータス変更、またはレコード作成日を標準化されたアクティビティ名にマッピングすることで導出されます。
例
請求書転記・送付済み督促状生成済み紛争登録済み入金確認済み
|
|||
|
イベント日時
EventTime
|
特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプ。 | ||
|
説明
イベントタイムは、システムで活動が記録された正確な日付と時刻です。これはプロセスマイニングの基礎であり、プロセスフローを構築し、すべての時間ベースのメトリックを計算するために必要な時系列順序を提供します。この属性は、期間の分析、ボトルネックの特定、SLAの監視に不可欠です。例えば、「請求書発行済み」と「入金済み」のイベント間の時間差は、重要なビジネスKPIである売掛金回収期間(DSO)の計算に使用されます。正確なタイムスタンプがなければ、パフォーマンス分析とボトルネックの特定は不可能です。
その重要性
このタイムスタンプは、イベントの順序付け、プロセスマップの発見、およびサイクルタイムや期間などのすべてのパフォーマンス指標の計算に不可欠です。
取得元
この属性は、特定の活動に応じて、「CustInvoiceJour」の「CreatedDateTime」や「CustTrans」の「TransDate」など、D365テーブルのさまざまな日付/時刻フィールドから取得されます。
例
2023-01-15T09:30:00Z2023-02-28T14:12:55Z2023-03-20T11:05:10Z
|
|||
|
請求書番号
InvoiceNumber
|
各顧客請求書の一意の識別子であり、信用管理プロセスの主要なケース識別子として機能します。 | ||
|
説明
請求書番号は、顧客との各財務取引を一意に識別する重要な属性です。請求書の生成、転記から支払い回収、最終決済に至るまで、すべての関連アクティビティをリンクします。プロセスマイニングでは、この番号を使用して各請求書のエンドツーエンドの道のりを再構築し、そのライフサイクルを詳細に分析することを可能にします。各請求書を個別のケースとして追跡することで、組織は共通のプロセスパス、ボトルネック、および標準手順からの逸脱を特定できます。これは、売上債権回転日数(Days Sales Outstanding)のような主要なメトリクスを計算し、プロセスバリアントを分析するための基盤となります。
その重要性
これは、すべてのプロセスイベントを接続し、請求書から現金化までのライフサイクル全体を再構築および分析することを可能にする必須のケースIDです。
取得元
これは通常、Microsoft Dynamics 365 Financeの「CustInvoiceJour」テーブルの「Invoice」フィールドです。
例
INV-0012345CIV-2023-8876SI-9510034
|
|||
|
`督促``レベル`
DunningLevel
|
延滞請求書の督促(回収)プロセスの現在の段階または深刻度を示します。 | ||
|
説明
督促レベルは、構造化された督促手続きにおけるステップを表します。例えば、「Level 1: Gentle Reminder」「Level 2: Formal Notice」「Level 3: Final Warning」などです。この属性を追跡することは、債権回収戦略の成功を評価するために不可欠です。「督促戦略の有効性」ダッシュボードは、この属性を使用して、各レベルに達した後に支払われた請求書の割合を示します。これにより、企業は督促ワークフローを改善し、顧客関係を維持しながら支払いを確保する上での有効性を高めることができます。
その重要性
これは、督促戦略の有効性を測定し、顧客が最も支払いやすい段階を理解するために不可欠です。
取得元
この情報は、「CustCollectionLetterJour」など、債権回収および督促状に関連するテーブルで見つかります。
例
123 - 最終法的措置
|
|||
|
回収担当者割り当て済み
CollectorAssigned
|
延滞請求書の管理責任者である債権回収担当者またはチームメンバーの名前。 | ||
|
説明
この属性は、特定の請求書に関する債権回収活動を担当する個々の従業員を識別します。これはパフォーマンスとワークロード分析にとって不可欠です。プロセスマップやダッシュボードを債権回収担当者でフィルタリングすることで、管理者は個人の生産性を評価し、債権回収戦略を比較し、コーチングの機会を特定できます。この属性は、「債権回収チームの生産性」および「紛争解決サイクルタイム」ダッシュボードにとって重要なディメンションであり、特定の個人またはチームにプロセス成果を帰属させるのに役立ちます。
その重要性
回収チームのパフォーマンス分析を可能にし、ワークロードのバランス調整を支援し、回収担当者の有効性を比較することでベストプラクティスを特定します。
取得元
Microsoft Dynamics 365のドキュメントを参照してください。これは、債権管理モジュールまたは顧客・取引レコードのユーザー責任フィールドからリンクされている可能性があります。
例
John Smithエミリー・ジョーンズ回収チームA
|
|||
|
延滞日数
DaysOverdue
|
請求書が支払期日を過ぎた日数。 | ||
|
説明
未回収日数は、未払い請求書の支払期日からの経過時間を測定する計算メトリックです。これは現在の日付から支払期日を引いたものとして計算されます。これは回収チームにとって主要なパフォーマンス指標であり、どの請求書に焦点を当てるべきかを優先順位付けするのに役立ちます。「セグメント別未回収請求書」ダッシュボードの主要メトリックであり、売掛金の健全性と回収努力の有効性を評価するための基本です。
その重要性
これは、債権回収の努力を優先順位付けし、支払い遅延の深刻度を測定するために使用される重要な運用メトリクスです。
取得元
これは計算フィールドです。ロジックは次のとおりです:もし請求書が未払いならば (Today() - PaymentDueDate)、そうでなければ 0。
例
1532910
|
|||
|
支払期日
PaymentDueDate
|
請求書支払いが契約上期日となる日付。 | ||
|
説明
支払期日は、顧客と合意した支払い条件によって定義される重要な日付属性です。この日付は、請求書が延滞しているかどうかを判断するための基準となります。これは、リマインダーの送付や正式な督促手続きの開始など、債権回収活動を開始するための主要なトリガーです。プロセスマイニングでは、「延滞日数」メトリクスを計算したり、督促ポリシーへのコンプライアンスをチェックしたりするために使用されます。例えば、期日経過後X日以内にリマインダーが送付されたかを確認します。
その重要性
この日付は支払い適時性を測定するためのベンチマークであり、すべての延滞および債権回収関連活動のトリガーとなります。
取得元
通常、「CustTrans」または「CustInvoiceJour」テーブルの「DueDate」フィールドとして見つかります。
例
2023-02-142023-03-312023-04-30
|
|||
|
請求書ステータス
InvoiceStatus
|
請求書ライフサイクルにおける現在のステータス。 | ||
|
説明
請求書ステータスは、「Open」「Paid」「Disputed」「Written Off」など、請求書がプロセスのどの段階にあるかのスナップショットを提供します。アクティビティログは詳細な履歴を提供しますが、現在のステータスはフィルタリングや高レベルのレポート作成に役立つケースレベルの属性です。これにより、アナリストはデータを迅速にセグメント化して、未払いの延滞請求書のみに焦点を当てたり、償却済み請求書すべての特性を分析したりできます。これは売掛金の現状を理解するためのシンプルかつ強力な方法です。
その重要性
請求書の現在の状態に基づいて請求書をフィルタリングおよび分析する迅速かつ簡単な方法を提供します。例えば、未処理または紛争中のすべてのケースに焦点を当てることができます。
取得元
「CustTrans」テーブルの取引の決済ステータスから導出されます。オープンな取引は未払いであり、クローズされた取引は決済済みです。
例
オープン支払い済み一部支払い済み償却済み
|
|||
|
請求金額
InvoiceAmount
|
請求書の合計金額。 | ||
|
説明
請求書金額は、請求された商品またはサービスの総財務価値を表します。これはプロセス内の財務分析にとって基本的な属性です。この属性により、ケースを金額でセグメント化し、高額な請求書が異なるプロセスをたどるか、より長い遅延を経験するかを確認できます。この属性は、「回収不能な請求書償却」および「信用限度額管理分析」ダッシュボードに不可欠であり、財務的影響を定量化し、リスクを評価するのに役立ちます。
その重要性
財務影響分析、高額請求書の優先順位付け、および請求書価値がプロセス動作にどのように影響するかを理解することを可能にします。
取得元
おそらく「CustInvoiceJour」テーブルの「InvoiceAmount」フィールドです。
例
1500.7525000.00549.99
|
|||
|
顧客セグメント
CustomerSegment
|
顧客の分類(規模、業界、戦略的重要性など)です。 | ||
|
説明
顧客セグメントは、顧客を有意義なコホート(例:「戦略的アカウント」、「中小企業」、「政府」など)にグループ化するために使用されるカテゴリ属性です。このセグメンテーションは戦略的分析に不可欠です。「戦略的アカウントはDSOが低いか?」や「特定の業界セグメントで償却がより一般的か?」といった質問に答えるのに役立ちます。これは、「売掛金回収期間トレンド」、「回収不能請求書償却」、「セグメント別未回収請求書」のダッシュボードで直接使用され、個々の顧客を超えたより高レベルの洞察を提供します。
その重要性
顧客グループ全体での集計分析を可能にし、戦略的な傾向を特定し、異なるセグメントに合わせた回収戦略を構築します。
取得元
これは多くの場合、カスタムフィールドであるか、「CustTable」(顧客マスターテーブル)の属性から導出されます。
例
エンタープライズミッドマーケット公共部門取引先
|
|||
|
顧客名
CustomerName
|
請求書が発行された顧客の正式名称。 | ||
|
説明
顧客名は、請求書に関連付けられた特定の顧客を識別します。この属性は、フィルタリングおよびセグメンテーションのための主要なディメンションです。顧客別にプロセスを分析することで、常に支払い遅延が発生したり、紛争を提起したり、広範な債権回収努力を必要とする問題のある顧客を特定できます。これは「紛争解決サイクルタイム」ダッシュボードや、特定の顧客アカウントに関する詳細な分析にとって重要な属性です。
その重要性
顧客固有のプロセス分析を可能にし、主要なアカウントや問題のあるアカウントとのパターンを特定し、関係を管理するのに役立ちます。
取得元
この情報は通常、「CustInvoiceJour」に存在する顧客口座番号を使用して「CustTable」から結合されます。
例
Contoso Ltd.アドベンチャーワークスFabrikam Inc.
|
|||
|
`売上債権回転日数`
DaysSalesOutstanding
|
請求書発行から支払い受領までの日数。 | ||
|
説明
売掛金回収期間(DSO)は、販売後に支払いを受け取るまでの平均日数を測定する主要な財務KPIです。このプロセスモデルでは、各請求書の「請求書発行済み」と「入金済み」活動間の期間として計算されます。DSOが低いほど、より効率的な回収プロセスと良好なキャッシュフローを示します。この属性により、時間の経過に伴うトレンド分析や、顧客セグメントなどのディメンションによるセグメンテーションが可能になり、どのグループが全体的なメトリックに影響を与えているかを確認できます。
その重要性
これは、キャッシュフロー効率と請求書から現金化までのプロセス全体のパフォーマンスを測定するための重要なKPIです。
取得元
「請求書発行済み」と「入金済み」の活動のタイムスタンプ間の期間として計算されます。
例
28.545.261.0
|
|||
|
ソースシステム
SourceSystem
|
データ発生元のシステムを特定します。 | ||
|
説明
この属性は、イベントデータが記録されたソースアプリケーションを指定します。このコンテキストでは「Microsoft Dynamics 365」となります。単一システム分析では静的に見えるかもしれませんが、データガバナンス、トラブルシューティング、および将来の統合にとって極めて重要です。別のCRMや債権回収代行会社のポータルなど、他のシステムからのデータを含める場合、このフィールドはそれらを区別し、完全なクロスシステムプロセスを理解するために不可欠です。
その重要性
明確なデータリネージを提供し、データ品質の維持および複数の統合システム間での分析を可能にするために不可欠です。
取得元
これは通常、データ抽出プロセス中に、レコードの出所を示すために追加される静的な値です。
例
Microsoft Dynamics 365D365 F&O
|
|||
|
信用限度額
CreditLimit
|
顧客に承認された信用限度額の最大値。 | ||
|
説明
信用限度額は、顧客が借り入れることができる負債の総額です。この属性はリスク管理にとって不可欠です。「信用限度額管理分析」ダッシュボードは、この値を延滞または償却済み口座の請求書金額と比較します。この分析は、信用限度額が適切に設定されているか、実施されているか、そしてデフォルトする顧客が最近限度額を増やしている傾向があるかどうかを判断するのに役立ち、信用承認プロセスの潜在的な弱点を浮き彫りにします。
その重要性
リスク評価に不可欠なこの属性は、貸倒が不適切に管理された、または不十分な顧客信用限度額に関連しているかどうかを分析するのに役立ちます。
取得元
この値は通常、「CustTable」の顧客マスターレコードに保存されます。
例
10000.0050000.000.00
|
|||
|
最終データ更新
LastDataUpdate
|
最終データ更新またはリフレッシュのタイムスタンプ。 | ||
|
説明
この属性は、データセットがソースシステムから最後に更新された日時を示します。これは、プロセスマイニング分析のユーザーにとって重要なメタデータであり、データの鮮度に関するコンテキストを提供します。データが特定の時点まで最新であることを知ることは、アナリストが情報に基づいた意思決定を行い、調査結果の範囲を理解するのに役立ちます。通常、データインジェスチョンパイプライン中にデータセット全体に適用されます。
その重要性
データの鮮度をユーザーに伝え、分析が正確な期間に基づいていることを保証し、古い情報による意思決定を防ぎます。
取得元
この値は、実行時にETL/データパイプラインによってデータセットに生成され、スタンプされます。
例
2023-04-01T02:00:00Z2023-04-02T02:00:00Z
|
|||
|
国
Country
|
顧客の請求先住所の国。 | ||
|
説明
この属性は、顧客アカウントに関連付けられた国を指定します。これは地理的分析の一般的なディメンションです。DSOや償却率などのプロセスKPIを国別にセグメント化することで、顧客の支払い行動、債権回収の有効性、または経済状況における地域差を明らかにできます。これにより、地域に合わせた債権回収戦略や、特定の地域に対して異なる支払い条件を設定できるようになります。
その重要性
地理的分析を可能にし、支払い行動と回収プロセスパフォーマンスにおける地域的な傾向を特定します。
取得元
これは、顧客マスターレコード(「CustTable」)から、多くの場合「LogisticsPostalAddress」にある主要な住所レコードに結合することで導出されます。
例
米国DEUGBRCAN
|
|||
|
異議あり
IsDisputed
|
請求書が過去に紛争状態になったことがあるかどうかを示すブール値フラグです。 | ||
|
説明
これは、請求書ケースに「Dispute Registered」アクティビティが含まれている場合にtrueに設定される計算フラグです。紛争中の請求書と紛争のない請求書のプロセスフローをユーザーが簡単にフィルタリングまたは比較できるようにすることで、分析を簡素化します。例えば、紛争中の請求書の平均DSOと紛争のない請求書の平均を簡単に比較して、紛争がキャッシュフローに与える影響を定量化できます。これは、高レベルのダッシュボード作成や比較分析に有用な属性です。
その重要性
紛争中の請求書と紛争のない請求書のグループを容易に比較できるようにすることで、分析とフィルタリングを簡素化します。
取得元
これは計算フィールドです。ロジックは次のとおりです:もしケースに「Dispute Registered」アクティビティが含まれているならば true、そうでなければ false。
例
truefalse
|
|||
|
紛争理由
DisputeReason
|
顧客が請求書を紛争する際に提示した理由。 | ||
|
説明
顧客が請求書を紛争する際、通常「Incorrect Pricing」「Damaged Goods」「Duplicate Billing」といった理由を提示します。この属性はその理由を捕捉します。紛争理由の分析は根本原因分析に不可欠です。これにより、販売、出荷、請求部門の問題など、受注から現金化までのプロセスにおける再発する問題を特定できます。発生源で紛争を削減することは、この分析の主要な成果であり、支払い遅延を防ぐことでDSOに直接影響を与えます。
その重要性
支払い遅延の根本原因分析に不可欠なデータを提供し、請求書紛争につながる上流の問題を特定し、解決するのに役立ちます。
取得元
Microsoft Dynamics 365のドキュメントを参照してください。これは、紛争管理またはケース管理機能の一部となります。
例
価格設定エラー数量不足製品未受領サービスが説明と異なる
|
|||
|
紛争解決時間
DisputeResolutionTime
|
顧客紛争が最初に登録されてから解決にかかった時間。 | ||
|
説明
紛争解決時間は、紛争処理プロセスの効率を測定します。「紛争登録済み」と「紛争解決済み」の活動間の期間として計算されます。解決時間が長いと、支払いが遅延し、顧客満足度に悪影響を与える可能性があります。この指標を、回収担当者または紛争理由別にセグメント化して分析することで、紛争管理ワークフローにおけるボトルネックと改善領域を特定するのに役立ちます。
その重要性
紛争処理プロセスの効率性を測定します。これは、大幅な支払い遅延の一般的な原因です。
取得元
「紛争登録済み」と「紛争解決済み」の活動のタイムスタンプ間の期間として計算されます。
例
7.215.83.5
|
|||
|
通貨コード
CurrencyCode
|
請求書の通貨。例えば、USDやEURなど。 | ||
|
説明
通貨コードは、請求書金額の取引通貨を指定します。これは特に多国籍企業にとって重要なコンテキスト属性です。財務価値を正しく解釈するために必要であり、支払いサイクルや問題が特定の通貨と相関しているかどうかを分析するために使用されることがあります。これは外国為替や国際支払い処理の複雑性に関連している可能性があります。
その重要性
すべての金額に対して必須のコンテキストを提供し、複数通貨を含むプロセスの分析を可能にします。
取得元
通常、「CustInvoiceJour」テーブルの「CurrencyCode」フィールドとして見つかります。
例
USDEURGBPCAD
|
|||
債権管理・回収活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
入金確認済み
|
顧客からの支払いが受領され、システムに入力されたことを示します(通常は支払仕訳を介して)。このイベントは、特定の請求書への最終的な転記と現金の適用に先行します。 | ||
|
その重要性
これは、DSOを計算し、キャッシュフローを理解するための重要なマイルストーンです。このイベントと支払い転記(Payment Posted)の間の時間差は、現金適用プロセスにおけるボトルネックを明らかにします。
取得元
顧客支払仕訳行(LedgerJournalTrans)の作成日から取得される明示的なイベントで、転記前に行われます。これは、支払いが受領として記録された日付を表します。
取得
顧客支払い仕訳帳明細の取引日を使用します。
イベントタイプ
explicit
|
|||
|
支払い期日超過
|
現在の日付が請求書の支払期日を超過したときに発生する、計算されたイベントです。この活動は直接的なユーザーアクションに対応するものではなく、システム日付と請求書の支払期日フィールドを比較することで導出されます。 | ||
|
その重要性
このイベントは、すべての債権回収活動のトリガーとなります。これにより、延滞請求書の量や督促アクションの適時性を分析でき、督促ポリシー遵守などのKPIをサポートします。
取得元
顧客取引テーブル(CustTrans)の「DueDate」フィールドと現在のタイムスタンプを比較して計算されます。イベントタイムスタンプはDueDateそのものです。
取得
'NOW()'が請求書の支払期日より大きい場合にイベントを作成します。
イベントタイプ
calculated
|
|||
|
支払い計上
|
顧客支払いが総勘定元帳に正式に転記され、請求書決済に適用されたことを表します。これは、顧客支払い仕訳帳の転記日から捕捉されます。 | ||
|
その重要性
プロセスの支払い部分を最終化します。入金から転記までの時間、すなわち現金適用ラグは、財務部門にとって重要な効率指標です。
取得元
顧客支払仕訳(LedgerJournalTrans)の転記タイムスタンプから取得されます。これにより、支払いが元帳で完全に処理されたことが確認されます。
取得
転記された顧客支払い仕訳帳の転記日を使用します。
イベントタイプ
explicit
|
|||
|
督促状生成済み
|
延滞請求書に対して正式な督促状または回収状が作成されたことを示します。これは、Dynamics 365で定期的な督促プロセスが実行され、関連する請求書の書簡レコードが生成されたときに取得されます。 | ||
|
その重要性
正式な債権回収努力の開始と頻度を追跡します。督促の有効性や内部債権回収ポリシーへのコンプライアンスを測定するために不可欠です。
取得元
督促履歴テーブル(CustCollectionLetterJour)に明示的なレコードが作成されます。督促状仕訳の作成日がタイムスタンプとなります。
取得
CustCollectionLetterJourテーブルから作成イベントを抽出し、請求書にリンクします。
イベントタイプ
explicit
|
|||
|
紛争登録済み
|
顧客が正式に請求書を紛争したことを示し、それに応じてステータスが更新されます。これは通常、債権回収管理モジュールでユーザーが請求書のステータスを「Disputed」に変更することで捕捉されます。 | ||
|
その重要性
これは紛争解決プロセスの開始点です。これを追跡することで、紛争の頻度と解決にかかる時間を測定でき、顧客満足度とキャッシュフローに影響を与えます。
取得元
顧客取引(CustTrans)のステータス変更、または関連する紛争管理テーブル(smmCaseDetail)から推測されます。ステータス変更のタイムスタンプ付きログが必要です。
取得
請求書取引の紛争ステータスフィールドが設定されたか、「紛争中」に変更された時期を特定します。
イベントタイプ
inferred
|
|||
|
請求書の精算完了
|
請求書が完全に支払われ、残高がゼロになったことを示し、プロセスの成功裏の完了を意味します。このステータスは、適用された支払いの合計が総請求書金額と等しくなったときに推測されます。 | ||
|
その重要性
これはクレジット・トゥ・キャッシュプロセスの主要な成功終点です。ここに繋がる経路を分析することで、ベストプラクティスと効率的なプロセスバリアントが明らかになります。
取得元
顧客決済テーブル(CustSettlement)の決済日から推測されます。これは、CustTransにおける請求書の「AmountCur」フィールドと「SettleAmountCur」フィールドの合計がゼロになった場合に発生します。
取得
残高をゼロにする請求書取引に関連付けられた最新の決済日を特定します。
イベントタイプ
inferred
|
|||
|
請求書償却済み
|
請求書が回収不能と見なされ、正式に不良債権として償却されました。これは、承認されたユーザーが実行する明示的なアクションであり、これにより売掛金が消去され、損失が計上されます。 | ||
|
その重要性
これはプロセスの主要な失敗終点です。償却を追跡することは、信用リスク、債権回収の失敗、財務損失を理解するために不可欠です。
取得元
不良債権の償却に使用される特定の一般仕訳取引から取得され、元の請求書にリンクされています。償却仕訳の転記日がタイムスタンプとなります。
取得
請求書を参照する特定の償却転記プロファイルを持つ仕訳帳エントリを特定します。
イベントタイプ
explicit
|
|||
|
請求書生成済み
|
システム内で売上請求書レコードが作成されたことを示し、正式に転記される前の段階です。このアクティビティは通常、ユーザーが販売注文を確定し、対応する請求書ドキュメントを生成したときに捕捉される明示的なイベントです。 | ||
|
その重要性
これは請求書ライフサイクルの主要な開始イベントです。この時点から支払いまでの時間を分析することは、売上債権回転日数(DSO)を測定するために不可欠です。
取得元
請求書作成時に販売請求書ヘッダーテーブル(SalesInvoiceHeader)または販売テーブル(SalesTable)に記録されます。記録の作成タイムスタンプがイベント時間となります。
取得
売上請求書レコードの作成タイムスタンプをキャプチャします。
イベントタイプ
explicit
|
|||
|
請求書転記・送付済み
|
請求書が総勘定元帳に正式に記録され、正式な売掛金となることを表します。このイベントは通常、請求書が顧客に送付されることと一致し、Dynamics 365で転記ルーティンが完了したときに捕捉されます。 | ||
|
その重要性
これは、支払い条件と債権年齢の計時を正式に開始する重要なマイルストーンです。請求書作成と転記の間の遅延は、請求プロセスにおける非効率性を隠す可能性があります。
取得元
顧客請求書仕訳帳(CustInvoiceJour)の転記日、またはステータスが「Posted」に変更された時点から推測されます。転記タイムスタンプが主要なデータポイントです。
取得
顧客請求書仕訳帳(CustInvoiceJour)の転記タイムスタンプを使用します。
イベントタイプ
inferred
|
|||
|
回収活動が記録されました
|
顧客または請求書に対して記録された、電話やメールなどの手動による債権回収アクションを表します。これは、債権回収担当者が債権回収ワークスペース内のアクティビティ機能を使用してやり取りを記録したときに捕捉されます。 | ||
|
その重要性
債権回収チームの手作業による労力を可視化します。これらの活動を支払い成功率と照らし合わせて分析することで、チームの生産性やさまざまな連絡方法の有効性を測定できます。
取得元
アクティビティ(smmActivities)または顧客アカウントに関連付けられたケース管理テーブルに記録されます。可能であれば、アクティビティを特定の請求書にリンクする必要があります。
取得
タイプが「電話」または「メール」である回収関連の活動レコードの作成をキャプチャします。
イベントタイプ
explicit
|
|||
|
支払約束作成済み
|
顧客が特定の将来の日付での支払いを確約し、その約束がシステムに記録されています。このイベントは、回収担当者が回収モジュールで支払い約束の詳細を入力したときに明示的に記録されます。 | ||
|
その重要性
非公式な支払約束とその履行率を追跡します。約束と実際の支払いを比較することで、キャッシュフローの予測や顧客の信頼性評価に役立ちます。
取得元
債権回収ワークスペースまたはケース管理に関連するテーブル、特に支払約束機能のために記録されます。約束記録の作成日がイベント時間となります。
取得
支払い約束または回収ケース詳細テーブルからの作成イベントをキャプチャします。
イベントタイプ
explicit
|
|||
|
紛争解決済み
|
紛争プロセスが解決に達し、文書化されたことを示します。このイベントは、ユーザーが請求書の紛争ステータスを「Resolved」に更新するか、関連する紛争ケースをクローズしたときに記録されます。 | ||
|
その重要性
このアクティビティは、紛争サブプロセスを終了させます。紛争登録から解決までの期間は、解決チームの効率性を測定するための重要なKPIです。
取得元
顧客取引(CustTrans)のステータス変更、または関連する紛争ケース(smmCaseDetail)がクローズされた時点から推測されます。このステータス変更のタイムスタンプがイベント時間となります。
取得
請求書の紛争ステータスフィールドがクリアされたか、「解決済み」に変更された時期を特定します。
イベントタイプ
inferred
|
|||