受注から入金まで:請求・請求書発行のデータテンプレート
受注から入金まで:請求・請求書発行のデータテンプレート
- 収集を推奨する属性
- 追跡すべき主要なアクティビティ
- Oracle E-Business Suiteからの抽出方法
受注から入金まで:請求・請求書発行の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
イベント時刻
EventTime
|
アクティビティが発生した正確な日付と時刻です。 | ||
|
説明
イベント時刻は各アクティビティに紐づくタイムスタンプであり、ケース内のイベントを時系列に並べるために使います。プロセスマイニングで時間に関する分析を行う際の、生のデータです。 この属性は、サイクルタイム、アクティビティ間の所要時間、プロセスのリードタイムなどの主要業績評価指標を計算するために欠かせません。たとえば、「Invoice Generated」と「Invoice Approved」のイベント時刻の差から、承認にかかった時間を算出できます。信頼できるプロセス分析には、正確で完全なタイムスタンプが必要です。
重要な理由
すべてのイベントに時間的な文脈を与え、所要時間の計算、プロセスパフォーマンスの分析、ボトルネックの発見を可能にします。
入手先
RA_CUSTOMER_TRX_ALLやAR_CASH_RECEIPTS_ALLなど、Oracle EBSの各テーブルにあるCREATION_DATEやLAST_UPDATE_DATEなどの日付フィールドから取得します。
例
2023-04-15T10:00:00Z2023-04-20T14:35:10Z2023-05-15T00:00:00Z
|
|||
|
請求書番号
InvoiceNumber
|
各請求書を識別する一意の識別子であり、請求プロセスの主要なケースIDとして機能します。 | ||
|
説明
請求書番号は、受注から入金までの請求分析の基盤となる項目です。各請求取引を一意に識別し、作成、承認、送付、支払い、クローズなど、関連するすべてのアクティビティを1つのまとまったプロセスインスタンスにまとめます。これにより、請求書のライフサイクルを最初から最後まで確認できます。 プロセスマイニングでは、請求書番号を基準に分析することで、総サイクルタイムを測定し、請求書の処理方法のバリエーションを特定し、支払いを遅らせるボトルネックを絞り込めます。請求書ごとに、作成から決済までの全行程を追跡するために欠かせない項目です。
重要な理由
関連するすべてのイベントを結び付ける重要なケース識別子です。請求書ごとの請求プロセス全体を再構築し、分析できます。
入手先
通常は、Oracle ReceivablesのRA_CUSTOMER_TRX_ALLテーブルにある取引番号です。
例
INV-9234501788144US-2023-001293
|
|||
|
アクティビティ名
ActivityName
|
請求書のライフサイクルにおいて、ある時点で発生した特定の業務イベントの名称です。 | ||
|
説明
アクティビティ名は、「Invoice Generated」「Invoice Approved」「Customer Payment Received」など、請求プロセスのステップや節目を表します。特定の請求書番号について、これらのアクティビティを時系列に並べることで、プロセスフローが形成されます。 この属性はプロセスマイニングの基礎となるもので、プロセスマップの作成、プロセスバリエーションの分析、逸脱ややり直しのループの特定に使われます。特定のステップ間の時間を計算したり、プロセスのコンプライアンスを確認したりするには、アクティビティ名が明確で一貫していることが欠かせません。
重要な理由
この属性を基にプロセスフローを発見して可視化できるため、プロセスバリエーション、ボトルネック、やり直しを分析できます。
入手先
通常は、Oracle EBSの各種テーブル(例:AR_PAYMENT_SCHEDULES_ALL、RA_CUSTOMER_TRX_ALL)にあるステータス変更、イベントタイプ、レコードの作成・更新イベントを、標準化されたアクティビティ名にマッピングして作成します。
例
請求書が作成されました請求書が承認されました支払期日になりました顧客から支払いを受領しました
|
|||
|
ユーザー
User
|
アクティビティを実行した担当者のユーザーIDです。 | ||
|
説明
この属性は、請求書の承認や入金消込など、プロセスのステップを実行した特定の従業員またはシステムユーザーを識別します。プロセスにおける人の関与を理解するために欠かせません。 ユーザー別に分析すると、研修の機会、業務量の偏り、個人間のパフォーマンス差を特定できます。たとえば、手戻りが最も多いユーザーや承認時間が最も長いユーザーを把握し、対象を絞ったプロセス改善につなげられます。
重要な理由
個人単位でパフォーマンスを分析でき、成果の高いユーザー、研修の必要性、業務量の偏りを特定できます。
入手先
各種トランザクションテーブルのCREATED_BYやLAST_UPDATED_BYなどのユーザーIDフィールドから取得します。その後、このIDをFND_USERと結合してユーザー名を取得します。
例
JSMITHBWILLIAMSCDAVIS
|
|||
|
支払期日
DueDate
|
顧客が請求書を支払う予定の日付です。 | ||
|
説明
支払期日は、支払条件によって定められる請求書の支払期限を示す、重要な日付属性です。実際の支払状況を測定する基準になります。 この属性は、期日内支払率などのKPIの計算や、請求書の滞留期間レポートの作成に欠かせません。プロセスマイニングでは、支払行動を分析し、継続的に支払いが遅れる顧客を特定したり、プロセスの遅延が期日内の回収に与える影響を把握したりできます。
重要な理由
支払状況の測定、請求書の滞留期間の計算、支払遅延や貸倒れのリスク評価における基準になります。
入手先
AR_PAYMENT_SCHEDULES_ALLテーブルのDUE_DATE列にあります。
例
2023-05-152023-06-302023-07-01
|
|||
|
請求書ステータス
InvoiceStatus
|
ライフサイクルにおける請求書の現在のステータスです。 | ||
|
説明
請求書ステータスは、「オープン」「クローズ」「異議申し立て中」など、請求書の現在の状態を示します。請求書の進捗を現在の状態として把握できます。 この属性は、「請求書滞留期間・ステータス概要」などのダッシュボードを作成するうえで欠かせません。状態別の請求書の件数と金額をすばやく確認できます。また、オープン状態の請求書の回収作業に優先順位を付け、売掛金ポートフォリオ全体の健全性を概観できます。
重要な理由
請求書の現在の状態を把握でき、業務用ダッシュボード、業務量の管理、回収活動の優先順位付けに役立ちます。
入手先
AR_PAYMENT_SCHEDULES_ALLテーブルのSTATUS列にあります(オープンは「OP」、クローズは「CL」)。
例
未処理クローズ済み係争中
|
|||
|
請求書合計金額
TotalInvoiceAmount
|
すべての明細、税金、手数料を含む請求書の合計金額です。 | ||
|
説明
顧客に送付した請求書の合計金額を表す属性です。請求プロセスにおける財務分析の基本指標です。 プロセスマイニングでは、請求書合計金額を使ってケースを分類・絞り込みます。たとえば、高額な請求書と低額な請求書でプロセスフローを比較し、処理方法に違いがあるかを確認できます。承認段階で滞留している請求書の金額を算出するなど、財務上の影響を分析する際にも欠かせません。
重要な理由
財務上の影響を分析し、金額に基づいて問題への対応優先度を決めたり、請求書の金額がプロセスに与える影響を把握したりできます。
入手先
AR_PAYMENT_SCHEDULES_ALLテーブルのAMOUNT_DUE_ORIGINALから取得するか、特定の請求書についてRA_CUSTOMER_TRX_LINES_ALLから算出します。
例
1500.0012550.75500.50
|
|||
|
部門
Department
|
アクティビティを実行したユーザーが所属する部門または機能チームです。 | ||
|
説明
部門属性は、「売掛金」や「営業オペレーション」など、アクティビティを実行したユーザーの組織上の位置付けを示します。これにより、チーム単位や部門単位で分析を集計できます。 組織の各部門が請求プロセスとどのように関わり、影響を与えているかを理解するうえで重要です。部門内の構造的な問題の特定、チーム間のパフォーマンス比較、リソース配分の分析に役立ちます。たとえば、「請求書承認サイクル時間」ダッシュボードを部門別に分解できます。
重要な理由
組織構造に沿ってプロセスのパフォーマンスを分析でき、チーム間の差異を明らかにし、部門固有のボトルネックを特定できます。
入手先
通常は、ユーザー情報と組織の人事階層データを結合して導出します。PER_ALL_ASSIGNMENTS_Fなどの人事テーブル、または同等の人事テーブルを使うことが一般的です。
例
売掛金財務業務請求サービス
|
|||
|
顧客ID
CustomerId
|
請求書の発行先顧客を一意に識別するIDです。 | ||
|
説明
顧客IDは、請求書とマスターデータ内の特定の顧客アカウントを関連付けます。これにより、顧客ごとにプロセスのパフォーマンスを集計し、比較できます。 この属性を使うと、顧客の支払行動を示すダッシュボードを作成したり、異議申し立てや手戻りが最も多い顧客を特定したり、顧客セグメントごとに請求書処理時間を比較したりできます。プロセスだけを見る分析から、顧客を中心とした分析へ移行するための重要な属性です。
重要な理由
顧客を中心とした分析を可能にし、支払パターン、頻発する異議申し立て、特定顧客に固有のプロセス差異を特定できます。
入手先
RA_CUSTOMER_TRX_ALLテーブルのSOLD_TO_CUSTOMER_IDまたはBILL_TO_CUSTOMER_IDとして格納されています。
例
CUST-100239845ACME-US-01
|
|||
|
ソースシステム
SourceSystem
|
データを抽出した記録元のシステムです。 | ||
|
説明
イベントデータの発生元であるアプリケーションを識別する属性です。このプロセスでは、一貫してOracle E-Business Suiteになります。 複数のシステムを利用する環境では、データの系譜とトラブルシューティングのために欠かせない項目です。単一システムの環境でも、想定したソースからデータが取得されていることを確認するデータガバナンス上の必須項目です。
重要な理由
データの追跡可能性と文脈を確保します。データガバナンスや、複数の業務システムからデータを統合する際に欠かせません。
入手先
データ抽出時に設定する固定値で、元のERPを識別します。
例
Oracle E-Business SuiteOracle EBS R12
|
|||
|
事業部門
BusinessUnit
|
請求書を発行した会社内の特定の事業部門または運営単位です。 | ||
|
説明
事業部門は、トランザクションを担当する組織上の単位を示します。Oracle EBSでは、運営単位として表されることが一般的です。 この属性により、事業の異なる部門間でプロセスのパフォーマンスを比較できます。特定の事業部門の効率、期日内支払率、異議申し立ての発生状況を確認し、ベストプラクティスの共有や対象を絞った対策につなげられます。
重要な理由
組織内の異なる部門間でパフォーマンスを比較でき、ベストプラクティスや地域・部門固有の課題を特定できます。
入手先
運営単位の情報は、RA_CUSTOMER_TRX_ALLなど、ほとんどのトランザクションテーブルにあるORG_IDから暗黙的に取得できます。
例
米国業務EMEAサービスグローバル製造
|
|||
|
最終データ更新日時
LastDataUpdate
|
このイベントのデータがソースシステムから最後に更新または抽出された時刻を示すタイムスタンプです。 | ||
|
説明
この属性は、最後にデータを抽出した時刻を示します。分析対象のデータがどの程度新しいかを把握するうえで欠かせません。 ダッシュボードや分析がプロセスの最新状態を反映しているかどうかを確認するために使います。データの遅延に対する認識をそろえるのに役立ち、信頼できるデータモデルに必要なメタデータの1つです。
重要な理由
データの適時性を示し、プロセス分析がどの時点の状態を反映しているかを把握できるようにします。
入手先
データの抽出、変換、ロード(ETL)処理中に各レコードへ生成・付与されるメタデータフィールドです。
例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
売上債権回転日数
DaysSalesOutstanding
|
請求書の作成から支払の受領までの日数です。 | ||
|
説明
売上債権回転日数(DSO)は、請求書の作成後に支払を回収するまでの平均日数を測定する重要な財務指標です。この属性は請求書ごとに計算されます。 全体のKPIは平均値ですが、請求書単位の値があると、より詳細な分析が可能になります。分布の作成、外れ値の特定、時間の経過に伴う回収効率の傾向分析に利用できます。「DSOトレンド」ダッシュボードでは、この属性の平均値を時系列で直接可視化します。
重要な理由
請求書単位で回収効率を測定し、傾向分析やDSOが高くなる要因の特定に必要な生のデータを提供します。
入手先
データ変換時に計算します。ロジック:Timestamp('Customer Payment Received') - Timestamp('Invoice Generated')。
例
304592
|
|||
|
手戻りの有無
IsRework
|
請求書に変更や再承認などの手戻りアクティビティが発生したかどうかを示す計算フラグです。 | ||
|
説明
請求書のプロセスフローに、「請求書変更」や2回目の「請求書承認」など、手戻りを示すアクティビティが含まれている場合、このブールフラグはtrueになります。標準的で効率的な経路から外れた請求書をすばやく特定できます。 この属性は、「請求書エラー率」や「手動手戻り率」などのKPIに欠かせません。手戻りの発生頻度を簡単に定量化し、非効率なケースを絞り込んで、手戻りアクティビティに最も関係するユーザーや部門などの根本原因を調査できます。
重要な理由
標準外の追加ステップが必要だった請求書にフラグを付けることで、プロセスの非効率性を定量化し、手戻りの原因と影響を分析できます。
入手先
データ変換時に、ケース内の特定のアクティビティ順序(例:「請求書承認」の後に「請求書変更」)を検出して計算します。
例
truefalse
|
|||
|
支払条件
PaymentTerms
|
顧客が請求書をいつ支払うかを定めた合意済みの条件です。 | ||
|
説明
支払条件は、「Net 30」や「Net 60」など、支払に関する条件を定めるもので、請求書の支払期日の計算に使われます。キャッシュフローに直接影響する重要なマスターデータです。 支払条件別に分析すると、条件の違いが支払行動や売上債権回転日数(DSO)に与える影響を把握できます。支払条件が短い顧客ほど早く支払うかどうかを明らかにし、顧客セグメントごとに提示する支払条件を決める際の判断材料になります。
重要な理由
請求書の支払期日とキャッシュフロー予測に直接影響します。分析することで、異なる与信方針の有効性を評価できます。
入手先
RA_TERMS_Bテーブルから取得し、RA_CUSTOMER_TRX_ALLテーブルのTERM_IDを介して関連付けます。
例
30日後払い60日後払い受領時払い
|
|||
|
期日内支払かどうか
IsPaidOnTime
|
請求書が支払期日までに支払われたかどうかを示す計算フラグです。 | ||
|
説明
「顧客支払受領」タイムスタンプと請求書の「支払期日」を比較して導出するブール属性です。期日どおりまたは期日前に支払われた場合はtrue、遅れた場合はfalseになります。 このフラグにより、支払パフォーマンスに関するKPIやダッシュボードを簡単に作成できます。「期日内支払率」KPIの直接的な入力値となり、請求書を「期日内」と「遅延」に分けて簡単に絞り込み、根本原因を分析できます。
重要な理由
「期日内支払率」KPIを直接支援し、請求書を「期日内」と「遅延」に分類することで分析を簡単にします。
入手先
データ変換時に計算します。ロジック:IF (Timestamp('Customer Payment Received') <= Date('DueDate')) THEN true ELSE false。
例
truefalse
|
|||
|
販売注文番号
SalesOrderNumber
|
請求書の作成につながった元の販売注文を識別する番号です。 | ||
|
説明
販売注文番号は、受注から入金までのサイクルにおける前段の「受注管理」プロセスに直接つながります。請求プロセスと最初の顧客注文を関連付けます。 この属性により、プロセスをまたいだ分析が可能になります。たとえば、特定の種類の販売注文が請求に関する異議申し立てや支払遅延につながりやすいかを調査できます。請求プロセスだけを見ていると失われがちな重要な背景情報を提供します。
重要な理由
請求プロセスと上流の販売プロセスを関連付け、受注から入金までのより広い分析と根本原因の調査を可能にします。
入手先
通常は、請求書明細テーブルRA_CUSTOMER_TRX_LINES_ALLの参照属性フィールドまたはインターフェース属性フィールドにあります。INTERFACE_LINE_ATTRIBUTE1などの付加フレックスフィールドが該当します。
例
SO-54321601882ORD-2023-9910
|
|||
|
通貨
Currency
|
請求書の金額に使用する通貨コードです。 | ||
|
説明
この属性は、請求書金額の通貨(USDやEURなど)を指定します。すべての財務指標を理解するために必要なコンテキストを提供します。 多国籍事業のデータを分析する場合、通貨属性は財務数値を正しく解釈し、比較するために欠かせません。ダッシュボードでは、この属性を使って通貨別に絞り込んだり、連結レポーティングのために為替レートを適用したりできます。
重要な理由
すべての財務属性に必要なコンテキストを提供し、複数通貨の環境における正確な解釈と分析を支援します。
入手先
通常はRA_CUSTOMER_TRX_ALLテーブルのINVOICE_CURRENCY_CODE列にあります。
例
USDEURGBP
|
|||
|
顧客の国
Country
|
顧客の請求先住所がある国です。 | ||
|
説明
この属性は、顧客の請求先住所に関連付けられた国を指定します。プロセス分析に地理的な切り口を加えます。 国別にプロセスを分析すると、支払行動、プロセス効率、現地規制へのコンプライアンスにおける地域差を明らかにできます。たとえば、「顧客支払行動インサイト」ダッシュボードで、国によって平均支払遅延に大きな差があるかを確認できます。
重要な理由
プロセスを地理的に分析でき、顧客行動、規制の影響、業務パフォーマンスにおける地域差を明らかにします。
入手先
顧客アカウントテーブルを介して関連付けられた、HZ_LOCATIONSおよびFND_TERRITORIESに保存されている顧客の請求先サイト情報から取得します。
例
USAドイツ英国
|
|||
|
顧客名
CustomerName
|
請求書の発行先顧客の正式名称です。 | ||
|
説明
顧客名は、顧客を人が読み取れる形で識別するための情報です。顧客IDは結合や一意識別に使われる一方、顧客名はレポートやダッシュボードでの表示に使われます。 これにより、IDを調べなくても顧客名を簡単に認識でき、分析が分かりやすくなります。顧客別の平均支払遅延を示す棒グラフなど、使いやすい可視化を作成するうえでも重要です。
重要な理由
人が読み取れる顧客名で絞り込みやグループ化ができるため、ダッシュボードやレポートの使いやすさが向上し、分析に取り組みやすくなります。
入手先
請求書ヘッダーの顧客IDを使い、HZ_PARTIESテーブルとHZ_CUST_ACCOUNTSテーブルを結合して取得します。
例
Global Corp Inc.Innovate Solutions Ltd.Test Company LLC
|
|||
受注から入金まで:請求・請求書発行のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
入金が消込・照合されました
|
受領した顧客からの支払いが1件以上の特定の請求書に正常に適用され、未決済残高が減少したことを示します。債務に対する支払いの照合が完了した状態です。 | ||
|
重要な理由
支払いプロセスの最終ステップであり、入金消込サイクルタイムの測定に欠かせません。ここで遅延すると、顧客口座の残高が正しく表示されず、与信管理にも影響します。
入手先
現金入金と取引を紐づけるレコードがAR_RECEIVABLE_APPLICATIONS_ALLテーブルに作成された時点で、タイムスタンプ付きの明示的なイベントとして記録されます。
取得
AR_RECEIVABLE_APPLICATIONS_ALLのレコード作成時刻(GL_DATEまたはAPPLY_DATE)がイベントです。
イベントタイプ
explicit
|
|||
|
請求書がクローズされました
|
支払い、クレジットメモ、調整などにより残高がゼロになり、請求書が正式にクローズされたことを示します。請求書のライフサイクルが正常に完了した状態です。 | ||
|
重要な理由
プロセスの主な終点です。「Invoice Generated」から「Invoice Closed」までの総サイクルタイムは、受注から入金までの請求サイクル全体の効率を示す重要な指標です。
入手先
AR_PAYMENT_SCHEDULES_ALLテーブルのSTATUSフィールドが「CL」(Closed)に変わったことから推定します。クローズの原因となった最後の取引日をタイムスタンプとして使用できます。
取得
AR_PAYMENT_SCHEDULES_ALLのステータスが「CL」に変わったことから推定し、最後に関連付けられた消込の時刻を記録します。
イベントタイプ
inferred
|
|||
|
請求書が作成されました
|
システムで新しい請求書取引が作成されたことを示します。通常は、処理済みの受注明細を処理する「Autoinvoice Import Program」によって開始されるか、Receivablesモジュールで請求書を手動入力することで発生します。 | ||
|
重要な理由
請求プロセスの開始点です。このイベントから他のイベントまでの時間を分析することで、請求書のライフサイクル全体を把握し、初期段階のボトルネックを特定できます。
入手先
Oracle ReceivablesのRA_CUSTOMER_TRX_ALLテーブルにおける取引の作成日として記録されます。イベントのタイムスタンプには、TRX_DATEまたはCREATION_DATEを使用できます。
取得
RA_CUSTOMER_TRX_ALLテーブルのレコード作成時刻がイベントです。
イベントタイプ
explicit
|
|||
|
請求書が顧客に送付されました
|
請求書が印刷または電子的な手段で正式に顧客へ送信されたことを示します。このイベントを起点に、顧客の支払い条件に基づく期限のカウントが始まります。 | ||
|
重要な理由
請求書の送付リードタイムと、送付から入金までの遅延を測定する重要な節目です。社内処理の遅延と顧客側の支払い行動を区別するのに役立ちます。
入手先
Oracle EBSでは、このイベントが標準フィールドに明示的に記録されない場合があります。「Invoice Print」コンカレントプログラムのタイムスタンプや、電子送付時に設定されるカスタムフラグから推定できることがあります。
取得
請求書印刷プログラムの完了日、または電子送信に用いるカスタムロジックから推定します。
イベントタイプ
inferred
|
|||
|
顧客から支払いを受領しました
|
顧客からの支払いが入金としてシステムに入力されたことを示します。この段階では、特定の請求書にまだ適用されていない場合があります。 | ||
|
重要な理由
売上債権回転日数(DSO)を計算するための主要な節目です。請求書の作成から入金までの時間は、回収効率を測る主要な指標です。
入手先
AR_CASH_RECEIPTS_ALLテーブルにレコードが作成された時点で、タイムスタンプ付きの明示的なイベントとして記録されます。
取得
AR_CASH_RECEIPTS_ALLテーブルのレコード作成時刻がイベントです。
イベントタイプ
explicit
|
|||
|
クレジットメモが作成されました
|
請求ミスの修正や返品処理のため、クレジットメモ取引が生成され、既存の請求書に適用されることがあります。売掛金内で発生する、関連性はあるものの別個の取引です。 | ||
|
重要な理由
クレジットメモの件数が多い場合、受注処理、価格設定、初回請求の正確性など、上流工程に問題がある可能性があります。これらのイベントを分析することは、収益流出や顧客満足度低下の根本原因を調べるうえで重要です。
入手先
RA_CUSTOMER_TRX_ALLで新しい取引として記録されます。CUST_TRX_TYPE_IDは「CM」(Credit Memo)区分のタイプに紐づき、PREVIOUS_CUSTOMER_TRX_IDフィールドから元の請求書を参照できます。
取得
クレジットメモの取引タイプでRA_CUSTOMER_TRX_ALLにレコードが作成されたことがイベントです。
イベントタイプ
explicit
|
|||
|
償却処理が作成されました
|
残りの請求書残高の全部または一部を貸倒れとして償却する調整が行われたことを示します。通常は、回収活動を尽くした後に実施されます。 | ||
|
重要な理由
償却は収益の直接的な損失を意味します。発生頻度と金額を分析することで、与信ポリシーを見直し、回収不能債権による財務上の影響を把握できます。
入手先
請求書に対する特定の調整タイプの取引として記録されます。イベントはAR_ADJUSTMENTS_ALLテーブルで確認でき、償却用に定義された売掛金アクティビティタイプに紐づきます。
取得
「Write-Off」アクティビティタイプでAR_ADJUSTMENTS_ALLにレコードが作成されたことがイベントです。
イベントタイプ
explicit
|
|||
|
支払いが取り消されました
|
以前に受領した顧客からの支払いが取り消されたことを示します。通常は、残高不足(NSF)やその他の銀行処理エラーが原因です。 | ||
|
重要な理由
支払いの取り消しはキャッシュフロー予測を乱し、追加の事務作業を発生させます。これらのイベントを追跡することで、問題のある顧客や支払い方法を特定できます。
入手先
Oracle Receivablesで明示的な操作として記録されます。取り消しが行われると、AR_CASH_RECEIPT_HISTORY_ALLに「REVERSED」など、取り消しを示すステータスのレコードが作成されます。
取得
AR_CASH_RECEIPT_HISTORY_ALLテーブルのステータスが「REVERSED」に変更されたことで特定します。
イベントタイプ
explicit
|
|||
|
支払いリマインダーが発行されました
|
支払期限を過ぎた請求書について、督促通知またはリマインダーが顧客に送付されたことを示します。回収プロセスにおける重要なアクティビティです。 | ||
|
重要な理由
このアクティビティを追跡することは、回収施策の効果を測定するうえで重要です。リマインダーの送付前後で支払い率を分析できます。
入手先
Oracle Advanced Collectionsを使用している場合、督促状の送付は明示的なイベントとして記録されます。このモジュールを使用していない場合、このアクティビティはシステム外で行われることが多く、確実に追跡できない場合があります。
取得
Oracle Advanced CollectionsモジュールのDunning Correspondenceイベントとして記録されます。
イベントタイプ
explicit
|
|||
|
支払期日になりました
|
支払い条件に基づいて請求書の支払期日となった日を示す、計算上のイベントです。ユーザーやシステムの操作に対応するものではありませんが、時間軸上の重要な節目です。 | ||
|
重要な理由
期日どおりの支払い率を計算し、顧客の支払い行動を分析するうえで欠かせません。支払いが早いか、期日どおりか、遅れているかを判断する基準になります。
入手先
イベントとしては記録されません。対象の請求書について、システム日付とAR_PAYMENT_SCHEDULES_ALLテーブルのTERM_DUE_DATEフィールドを比較して計算します。
取得
現在のタイムスタンプとAR_PAYMENT_SCHEDULES_ALL.TERM_DUE_DATEを比較して算出します。
イベントタイプ
calculated
|
|||
|
異議申し立てが行われました
|
顧客が請求書に正式な異議を申し立てたため、解決するまで回収活動が保留されます。通常はOracle Advanced Collections内で管理するか、ステータスを手動で更新します。 | ||
|
重要な理由
異議申し立ては支払いを遅らせ、キャッシュフローに直接影響します。発生頻度と解決までの時間を追跡することで、製品、サービス、請求の正確性に関する繰り返しの問題を特定できます。
入手先
Oracle Advanced Collectionsを使用している場合は、明示的な取引として記録されます。使用していない場合は、AR内の特定の「dispute」ステータスや請求書に設定された保留から推定できることがあります。
取得
Oracle Advanced Collectionsの取引として記録するか、請求書のステータス変更から推定します。
イベントタイプ
explicit
|
|||
|
請求書が変更されました
|
既存の未完了の請求書が更新または修正されたことを示します。請求書が完了または送付される前に、明細、金額、請求情報などが変更される場合があります。 | ||
|
重要な理由
変更が頻繁に発生する場合、プロセスの非効率、データ品質の問題、ユーザーエラーが考えられます。このアクティビティを分析することで、やり直しの量とサイクルタイムへの影響を測定し、「Invoice Error Rate」などのKPIに役立てられます。
入手先
未完了の請求書について、RA_CUSTOMER_TRX_ALLテーブルのCREATION_DATEとLAST_UPDATE_DATEを比較して推定できます。監査が有効になっている場合は、変更をより明確に追跡できます。
取得
RA_CUSTOMER_TRX_ALLテーブルのLAST_UPDATE_DATEを追跡して推定します。
イベントタイプ
inferred
|
|||
|
請求書が承認されました
|
手動入力または確認済みの請求書を顧客に送付する前に、正式な社内承認が完了したことを示します。設定済みのOracle Workflowの一部として処理される場合や、ステータスを手動で変更する場合があります。 | ||
|
重要な理由
承認時間を追跡することは、「Invoice Approval Cycle Time」KPIの測定に欠かせません。ここでの遅延は顧客への請求を直接遅らせ、キャッシュコンバージョンサイクル全体を長期化させます。
入手先
多くの場合、設定に依存します。ワークフローテーブル(例:WF_ITEM_ACTIVITY_STATUSES)のステータス変更から推定するか、RA_CUSTOMER_TRX_ALLの請求書取引にある付加フレックスフィールドから取得できる場合があります。
取得
ワークフローテーブルのステータス変更またはカスタムステータスフィールドから推定します。
イベントタイプ
inferred
|
|||
抽出ガイド
準備はできましたか?
このテンプレートを使って、受注から入金までの請求・請求書発行プロセスのプロセスマイニングを始めましょう。今日から業務の改善点を見つけ、効率化を進められます。
受注から入金までの請求・請求書発行を今すぐ迅速化
請求サイクルを30%短縮し、資金回収を促進します。
クレジットカードは不要です。数分で設定できます。