受注から入金までの請求処理向けデータテンプレート
受注から入金までの請求処理向けデータテンプレート
- 収集を推奨する属性
- 記録する主なアクティビティ
- Oracle E-Business Suiteからのデータ抽出ガイド
受注から入金までの請求処理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
イベント時刻
EventTime
|
アクティビティが発生した正確な日時です。 | ||
|
説明
イベント時刻は各アクティビティに付与されるタイムスタンプで、ケース内のイベントの順序を示します。プロセスマイニングで時間に基づく分析を行うための生のデータです。 サイクルタイム、アクティビティ間の所要時間、プロセスのリードタイムなど、重要業績評価指標(KPI)の算出に欠かせません。たとえば、「請求書を発行」と「請求書を承認」のイベント時刻の差から、承認にかかった時間を算出できます。信頼できるプロセス分析には、正確で漏れのないタイムスタンプが必要です。
重要な理由
各イベントの時間的なコンテキストを示し、所要時間の算出、プロセスパフォーマンスの分析、ボトルネックの特定を可能にします。
入手先
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
|
請求書のライフサイクルにおいて、特定の時点で発生した業務イベントの名称です。 | ||
|
説明
アクティビティ名は、「請求書を発行」「請求書を承認」「顧客から入金」など、請求プロセスのステップや節目を表します。請求書番号ごとにこれらのアクティビティを時系列に並べると、プロセスフローがわかります。 この属性は、プロセスマップの作成、プロセスのバリアント分析、逸脱ややり直しの特定に使われるため、プロセスマイニングの基礎となります。特定のステップ間の所要時間の計算や、プロセスが規定に適合しているかの確認など、意味のある分析を行うには、アクティビティ名が明確で一貫していることが重要です。
重要な理由
プロセスフローの検出と可視化の基礎となり、プロセスのバリアント、ボトルネック、やり直しを分析できます。
入手先
通常、Oracle EBSの各種テーブル(例:AR_PAYMENT_SCHEDULES_ALL、RA_CUSTOMER_TRX_ALL)にあるステータス変更、イベントタイプ、レコードの作成・更新イベントを、標準化されたアクティビティ名に対応付けて作成します。
例
請求書を発行請求書を承認支払期日を迎える顧客から入金
|
|||
|
ユーザー
User
|
アクティビティを実行した担当者のユーザーIDです。 | ||
|
説明
請求書の承認や入金の充当など、プロセスのステップを実行した従業員またはシステムユーザーを特定する属性です。プロセスにおける人の関与を把握するうえで重要です。 ユーザー別に分析すると、トレーニングの必要性、業務負荷の偏り、個人ごとのパフォーマンスの違いを特定できます。たとえば、やり直しが多いユーザーや承認に時間がかかるユーザーを把握し、対象を絞ったプロセス改善に役立てられます。
重要な理由
個人単位のパフォーマンス分析が可能になり、成果を上げているユーザー、トレーニングの必要性、業務負荷の偏りを特定できます。
入手先
各種取引テーブルのCREATED_BYやLAST_UPDATED_BYなど、ユーザーID項目から取得します。そのIDをFND_USERと結合してユーザー名を取得します。
例
ジェイ・スミスビー・ウィリアムズシー・デイビス
|
|||
|
支払期日
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では、通常、事業単位(Operating Unit)として表されます。 この属性を使うと、事業部門ごとにプロセスのパフォーマンスを比較できます。効率性や期日どおりの支払い率、異議の発生状況に部門間の差があるかを確認し、優れた取り組みの共有や、課題に応じた対策につなげられます。
重要な理由
組織内の各部門のパフォーマンスを比較し、優れた取り組みや部門固有の課題を特定できます。
入手先
RA_CUSTOMER_TRX_ALLなど、多くの取引テーブルにあるORG_IDから事業単位の情報を取得できます。
例
米国事業EMEAサービスグローバル製造
|
|||
|
最終データ更新日時
LastDataUpdate
|
このイベントのデータがソースシステムから最後に更新または抽出された日時を示すタイムスタンプです。 | ||
|
説明
データを最後に抽出した日時を示す属性です。分析対象データの鮮度を把握するうえで重要です。 ダッシュボードや分析結果がプロセスの最新状況を反映しているかどうかを確認するために使います。データの反映にかかる時間について認識を共有でき、信頼できるデータモデルに欠かせないメタデータです。
重要な理由
データがどの程度新しいかを利用者に示し、プロセス分析がどの時点の状況を反映しているかを把握できるようにします。
入手先
データの抽出、変換、読み込み(ETL)処理中に各レコードへ付与されるメタデータ項目です。
例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
受注番号
SalesOrderNumber
|
請求書の作成につながった元の受注を識別する番号。 | ||
|
説明
受注番号を使うと、受注から入金までのプロセスにおける前段の「受注管理」と直接結び付けられます。請求処理と最初の顧客注文を関連付けることができます。 この属性により、プロセスをまたいだ分析が可能になります。たとえば、特定の種類の受注が請求に関する異議や支払いの遅延につながりやすいかを調べられます。請求処理だけを見ていては得られない背景情報を把握できます。
重要な理由
請求処理と前段の販売プロセスを結び付け、受注から入金までのプロセス全体の分析や根本原因の調査に役立ちます。
入手先
通常、請求書明細テーブルRA_CUSTOMER_TRX_LINES_ALLの参照用またはインターフェース属性フィールドから取得します。例:INTERFACE_LINE_ATTRIBUTE1などの記述フレックスフィールド。
例
SO-54321601882ORD-2023-9910
|
|||
|
売上債権回転日数
DaysSalesOutstanding
|
請求書の発行から支払いの受領までの日数。 | ||
|
説明
売上債権回転日数(DSO)は、請求書の発行後、支払いを回収するまでにかかる平均日数を測る重要な財務指標です。この属性は請求書ごとに算出されます。 全体の重要業績評価指標(KPI)は平均値ですが、請求書ごとの値があれば、分布の作成、外れ値の特定、回収効率の経時的な傾向分析ができます。「DSOの推移」ダッシュボードでは、この属性の平均値を時系列で確認できます。
重要な理由
請求書ごとの回収効率を測定します。推移分析に使うデータを提供し、DSOが高くなる要因の特定に役立ちます。
入手先
データ変換時に算出します。ロジック:Timestamp('Customer Payment Received') - Timestamp('Invoice Generated').
例
304592
|
|||
|
手戻りあり
IsRework
|
請求書に修正や再承認などの手戻りが発生したかを示す計算フラグ。 | ||
|
説明
請求書のプロセスフローに「請求書の修正」や2回目の「請求書の承認」など、手戻りを示すアクティビティが含まれる場合、この真偽値フラグはtrueになります。標準的で効率的な経路から外れた請求書をすばやく特定できます。 この属性は、「請求書エラー率」や「手作業による手戻り率」などの重要業績評価指標(KPI)に欠かせません。手戻りの頻度を把握し、非効率なケースを絞り込んで、手戻りに関係するユーザーや部門などの根本原因を調査できます。
重要な理由
標準外の追加手順が必要だった請求書を特定し、プロセスの非効率性を数値化できます。手戻りの原因と影響を分析する際に役立ちます。
入手先
データ変換時に、ケース内の特定のアクティビティの順序(例:「請求書の承認」の後に「請求書の修正」)を検出して算出します。
例
truefalse
|
|||
|
支払条件
PaymentTerms
|
顧客が請求書をいつまでに支払う必要があるかを定めた合意条件。 | ||
|
説明
支払条件は、「30日以内」や「60日以内」など、支払いに関する条件を定めるものです。請求書の支払期日の算出に使われます。キャッシュフローに直接影響する重要なマスターデータです。 支払条件ごとに分析すると、条件の違いが支払い行動や売上債権回転日数(DSO)にどう影響するかを把握できます。支払期限が短い顧客ほど早く支払うかどうかを確認し、顧客セグメントごとに提示する支払条件を決める際の参考にできます。
重要な理由
請求書の支払期日とキャッシュフロー予測に直接影響します。分析することで、異なる与信方針の効果を評価できます。
入手先
RA_CUSTOMER_TRX_ALLテーブルのTERM_IDを介して関連付けられた、RA_TERMS_Bテーブルから取得します。
例
30日以内60日以内受領時払い
|
|||
|
期日どおりに支払い済み
IsPaidOnTime
|
請求書が支払期日まで、または期日前に支払われたかを示す計算フラグ。 | ||
|
説明
「顧客支払い受領」のタイムスタンプと請求書の「支払期日」を比較して算出する真偽値属性です。期日どおり、または期日前の支払いならtrue、遅延していればfalseになります。 このフラグを使うと、支払いパフォーマンスに関する重要業績評価指標(KPI)やダッシュボードを簡単に作成できます。「期日どおりの支払い率」KPIの算出に直接使えるほか、請求書を「期日どおり」と「遅延」に分けて絞り込み、根本原因を分析できます。
重要な理由
「期日どおりの支払い率」KPIの算出に直接使えます。また、請求書を「期日どおり」と「遅延」に分類することで、分析を簡素化できます。
入手先
データ変換時に算出します。ロジック:IF (Timestamp('Customer Payment Received') <= Date('DueDate')) THEN true ELSE false.
例
truefalse
|
|||
|
通貨
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テーブルを結合して取得します。
例
グローバルコーポレーションイノベートソリューションズテストカンパニー
|
|||
受注から入金までの請求処理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
入金を充当・照合
|
顧客からの入金が1件以上の請求書に正しく充当され、未回収残高が減少した状態です。入金と債権の照合が完了したことを示します。 | ||
|
重要な理由
支払いプロセスの最終段階であり、入金消込サイクルタイムの測定に欠かせません。ここで遅れが生じると、顧客口座の残高が実態と異なって表示され、与信管理にも影響することがあります。
入手先
現金入金と取引を紐づけるレコードがAR_RECEIVABLE_APPLICATIONS_ALLテーブルに作成された時点で、タイムスタンプとともに明示的に記録されます。
記録
AR_RECEIVABLE_APPLICATIONS_ALLのレコード作成時刻(GL_DATEまたはAPPLY_DATE)をイベントとして扱います。
イベントタイプ
explicit
|
|||
|
請求書をクローズ
|
請求書が正式にクローズされ、支払い、クレジットメモ、または調整によって残高がゼロになったことを示します。請求書のライフサイクルが正常に完了した状態です。 | ||
|
重要な理由
プロセスの主な終了点です。「請求書を発行」から「請求書をクローズ」までのサイクルタイムは、受注から入金までの請求プロセス全体の効率を示す重要な指標です。
入手先
AR_PAYMENT_SCHEDULES_ALLテーブルのSTATUS項目が「CL」(Closed)に変わったことから推定します。クローズの原因となった最終取引の日付をタイムスタンプとして使用できます。
記録
AR_PAYMENT_SCHEDULES_ALLのステータスが「CL」に変わったことから推定し、最後に関連する充当処理のタイムスタンプを使用します。
イベントタイプ
inferred
|
|||
|
請求書を発行
|
システムで新しい請求取引が作成されたことを示します。通常は、履行済みの受注明細を処理する「Autoinvoice Import Program」の実行、または売掛金モジュールでの手入力によって発生します。 | ||
|
重要な理由
請求プロセスの開始点です。このイベントからほかのイベントまでの時間を分析すると、請求書のライフサイクル全体を把握でき、初期段階のボトルネックを特定できます。
入手先
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
|
|||
|
入金を取り消し
|
以前に受領した顧客からの入金が取り消されたことを示します。通常、残高不足(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
|
|||
|
請求書を変更
|
既存の未完了の請求書が更新または修正されたことを示します。請求書の確定や送付前に、明細、金額、請求情報などを変更する場合があります。 | ||
|
重要な理由
変更が頻繁に発生する場合、プロセスの非効率、データ品質の問題、またはユーザーの入力ミスが考えられます。このアクティビティを分析すると、やり直しの量とサイクルタイムへの影響を把握でき、「請求書エラー率」などの重要業績評価指標(KPI)の改善に役立ちます。
入手先
未完了の請求書について、RA_CUSTOMER_TRX_ALLテーブルのCREATION_DATEとLAST_UPDATE_DATEを比較して推定できます。監査が有効な場合は、変更をより明確に追跡できます。
記録
RA_CUSTOMER_TRX_ALLテーブルのLAST_UPDATE_DATEを使って更新を追跡し、推定します。
イベントタイプ
inferred
|
|||
|
請求書を承認
|
手入力または確認済みの請求書を顧客に送付する前に、社内で正式に承認したことを示します。設定済みのOracle Workflowの一部として行われる場合と、ステータスを手動で変更する場合があります。 | ||
|
重要な理由
承認にかかる時間は、重要業績評価指標(KPI)「請求書承認サイクルタイム」の測定に欠かせません。ここでの遅れは顧客への請求を遅らせ、現金化までの期間を延ばします。
入手先
このイベントの記録方法は、設定によって異なります。ワークフローテーブル(例:WF_ITEM_ACTIVITY_STATUSES)のステータス変更から推定するか、RA_CUSTOMER_TRX_ALLの請求取引にある付加フレックスフィールドから特定できる場合があります。
記録
ワークフローテーブルのステータス変更、またはカスタムステータス項目から推定します。
イベントタイプ
inferred
|
|||
|
貸倒償却を作成
|
残っている請求残高の全部または一部を貸倒損失として償却する調整です。通常、回収のための対応を尽くした後に行います。 | ||
|
重要な理由
貸倒償却は収益の直接的な損失です。発生頻度と金額を分析すると、与信方針の見直しや回収不能債権による財務上の影響の把握に役立ちます。
入手先
請求書に対する特定の調整タイプの取引として記録されます。AR_ADJUSTMENTS_ALLテーブルで確認でき、貸倒償却用に定義された売掛金アクティビティタイプに紐づいています。
記録
「Write-Off」アクティビティタイプのレコードがAR_ADJUSTMENTS_ALLに作成されたことをイベントとして扱います。
イベントタイプ
explicit
|
|||
データ抽出ガイド
始める準備はできましたか?
このテンプレートを使って、受注から入金までの請求処理に関するプロセスマイニングを始めましょう。インサイトを見つけ、業務の効率化に取り組む第一歩を踏み出せます。
受注から入金までの請求書処理を今すぐ迅速化
請求サイクルを30%短縮し、現金化を早めます。
クレジットカードは不要です。数分で設定できます。