受注から現金化まで - 請求および売上計上データテンプレート

Oracle E-Business Suite
受注から現金化まで - 請求および売上計上データテンプレート

受注から現金化まで - 請求および売上計上データテンプレート

このテンプレートは、受注から現金化まで(Order to Cash)- 請求および売上計上プロセスを分析するために必要な不可欠なデータを収集するための明確なロードマップを提供します。イベントログに含めるべき主要なデータフィールド、追跡すべき重要なプロセスステップ、およびこの情報を抽出するための実用的なガイダンスを概説しています。このリソースを活用し、効果的なプロセス分析と最適化に必要なすべてのデータを確実に収集してください。
  • 収集を推奨する項目
  • 追跡すべき主要アクティビティ
  • Oracle E-Business Suite向けの抽出ガイダンス
イベントログについて初めての方へ: プロセスマイニングのイベントログ作成方法.

受注から現金化まで - 請求および売上計上属性

これらは、受注から現金化まで(Order to Cash)- 請求および売上計上プロセスの包括的な分析のために、イベントログに含めることが推奨されるデータフィールドです。
3 必須 6 推奨 12 任意
名前 説明
イベント日時
EventTime
アクティビティが発生した正確な日時。
説明

イベントタイムは、各アクティビティに関連付けられたタイムスタンプであり、ケース内のイベントの時系列順序を提供します。これは、プロセスマイニングにおけるすべての時間ベースの分析に使用される生データです。

この属性は、サイクルタイム、アクティビティ間の期間、プロセスリードタイムなどの主要なパフォーマンス指標を計算するために不可欠です。例えば、「請求書生成」と「請求書承認」のイベントタイムの差は承認期間を示します。正確で完全なタイムスタンプは、信頼性の高いプロセス分析に不可欠です。

その重要性

すべてのイベントの時間的コンテキストを提供し、期間の計算、プロセスパフォーマンスの分析、ボトルネックの発見を可能にします。

取得元

RA_CUSTOMER_TRX_ALLやAR_CASH_RECEIPTS_ALLのようなテーブルのCREATION_DATEやLAST_UPDATE_DATEフィールドなど、Oracle EBSの様々なテーブルの日付フィールドから取得されます。

2023-04-15T10:00:00Z2023-04-20T14:35:10Z2023-05-15T00:00:00Z
請求書番号
InvoiceNumber
各請求書ドキュメントの一意の識別子であり、請求プロセスの主要なケースIDとして機能します。
説明

請求書番号は、受注から現金化まで(Order to Cash)請求分析の要であり、各請求取引を一意に識別します。作成、承認、送付、支払い、クローズなどのすべての関連活動を、単一のまとまったプロセスインスタンスにグループ化します。これにより、請求書ライフサイクルの完全なエンドツーエンドビューが可能になります。

プロセスマイニングでは、請求書番号別にプロセスを分析することで、総サイクル時間を測定し、請求書の処理方法のバリアントを特定し、支払いを遅らせるボトルネックを特定するのに役立ちます。作成から決済までの請求書個々の全ジャーニーを追跡するために不可欠です。

その重要性

これは、すべての関連イベントを接続する不可欠なケース識別子であり、各固有の請求書に対して請求プロセス全体を再構築し、分析することを可能にします。

取得元

これは通常、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と結合され、ユーザー名が取得されます。

JSMITHBWILLIAMS`CDAVIS`
支払期日
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は、マスターデータ内の請求書を特定の顧客アカウントにリンクします。これにより、異なる顧客間でのプロセスパフォーマンスの集計と比較が可能になります。

この属性を使用すると、アナリストは顧客の支払い行動を強調表示し、最も多くの紛争や手戻りに関連する顧客を特定し、顧客セグメント間で請求書処理時間を比較するダッシュボードを構築できます。これは、プロセスのみの視点から顧客中心の分析へと移行するための鍵となります。

その重要性

顧客中心の分析を可能にし、支払いパターン、頻繁な紛争、または特定の顧客に固有のプロセスバリエーションを特定するのに役立ちます。

取得元

RA_CUSTOMER_TRX_ALLテーブルでSOLD_TO_CUSTOMER_IDまたはBILL_TO_CUSTOMER_IDとして発見されます。

CUST-100239845ACME-US-01
`売上債権回転日数`
DaysSalesOutstanding
請求書作成から支払い受領までの日数。
説明

売掛金回収日数(DSO)は、請求書が生成されてから支払い回収にかかる平均時間を測定する重要な財務指標です。この属性は個々の請求書ごとに計算されます。

全体的なKPIは平均値ですが、請求書ごとのこの値を持つことで強力な分析が可能になります。これを使用して分布を作成し、外れ値を特定し、回収効率の経時的な傾向を分析できます。「DSOトレンド」ダッシュボードは、この属性の平均値を経時的に直接可視化します。

その重要性

個々の請求書レベルでの回収効率を測定し、トレンド分析のための生データを提供し、高いDSOと相関する要因を特定します。

取得元

データ変換中に計算されます。ロジック:Timestamp('Customer Payment Received') - Timestamp('Invoice Generated')。

304592
ソースシステム
SourceSystem
`データ`が抽出された記録システム。
説明

この属性は、イベントデータがどこで生成されたかを示すソースアプリケーションを識別します。このプロセスでは、一貫してOracle E-Business Suiteになります。

複数のシステムがある環境では、このフィールドはデータリネージュとトラブルシューティングにとって不可欠です。単一システム環境であっても、データが想定されたソースから来ていることを確認するデータガバナンスのための必須フィールドです。

その重要性

データトレーサビリティとコンテキストを確保し、これはデータガバナンスにとって、また複数のエンタープライズシステムからデータを統合する際に不可欠です。

取得元

これは、データ抽出プロセス中にソースERPを識別するために設定される静的な値です。

Oracle E-Business SuiteOracle EBS R12
ビジネスユニット
BusinessUnit
請求書を発行した会社内の特定の事業単位またはオペレーティングユニット。
説明

事業単位は、取引に責任を持つ組織エンティティを表します。Oracle EBSでは、これはしばしばOperating Unitによって表されます。

この属性により、プロセスパフォーマンスをビジネスの異なる部門間で比較することができます。特定の事業単位がより効率的であるか、期日内支払率が高いか、またはより多くの紛争を経験しているかを判断するのに役立ち、ベストプラクティスの共有や的を絞った介入を可能にします。

その重要性

組織の異なる部分間でのパフォーマンス比較を可能にし、ベストプラクティスとエリア固有の課題を特定するのに役立ちます。

取得元

Operating Unitのコンテキストは、RA_CUSTOMER_TRX_ALLのようなほとんどの取引テーブルのORG_IDを介して暗黙的に利用可能です。

米国事業EMEAサービスグローバル製造
最終データ更新
LastDataUpdate
この`イベント`の`データ`が`ソースシステム`から`最終的`に`更新`または`抽出`された`時刻`を示す`タイムスタンプ`です。
説明

この属性は、前回のデータ抽出のタイムスタンプを提供します。これは、分析されているデータの鮮度を理解するために不可欠です。

ユーザーは、ダッシュボードや分析がプロセスの最新の状態を反映しているかどうかを知るために、このフィールドに依存します。データ遅延に関する期待値を管理するのに役立ち、あらゆる信頼性の高いデータモデルにとって重要なメタデータの一部です。

その重要性

ユーザーにデータのタイムリー性について通知し、プロセス分析がどれほど最新であるかを理解できるようにします。

取得元

これは、データ抽出、変換、ロード(ETL)プロセス中に各レコードに生成され、スタンプされるメタデータフィールドです。

2023-10-27T02:00:00Z2023-10-28T02:00:00Z
手戻り
IsRework
請求書に修正や再承認などの手戻り作業が行われたかどうかを示す計算されたフラグです。
説明

このブールフラグは、請求書のプロセスフローに「請求書修正」や2回目の「請求書承認」イベントなど、手戻りを示す活動が含まれる場合にtrueに設定されます。これにより、標準的で効率的なパスから逸脱する請求書を迅速に特定するのに役立ちます。

この属性は、「請求書エラー率」や「手動手戻り率」のようなKPIにとって重要です。これにより、アナリストは手戻りの頻度を簡単に定量化し、これらの非効率なケースをフィルタリングし、手戻り活動に最も関連するユーザーや部門などの根本原因を調査することができます。

その重要性

標準外の追加ステップを要した請求書にフラグを立てることで、プロセスの非効率性を定量化し、手戻りの原因と影響の分析を可能にします。

取得元

データ変換中に、ケース内の特定のアクティビティシーケンス(例:「請求書承認」の後に「請求書修正」)を検出することによって計算されます。

truefalse
承認サイクルタイム
ApprovalCycleTime
請求書が作成されてから承認されるまでの期間。
説明

この属性は、内部請求書承認プロセスにかかる時間を測定します。これは内部効率の主要な指標であり、全体の請求サイクルにおけるボトルネックの頻繁な原因です。

各請求書についてこの期間を計算することで、「請求書承認サイクルタイム」ダッシュボードの作成が可能になります。部門、ユーザー、または請求額別に分析することで、承認遅延の原因を特定し、プロセス改善イニシアチブの影響を測定することができます。

その重要性

承認ワークフローの効率性を測定することで内部のボトルネックを特定します。これは顧客への請求書送付遅延の一般的な原因となっています。

取得元

データ変換中に計算されます。ロジック:Timestamp('Invoice Approved') - Timestamp('Invoice Generated')。

864001728003600
支払条件
PaymentTerms
顧客が請求書を支払うべき時期を規定する、合意された条件。
説明

支払条件は、「Net 30」や「Net 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
販売オーダー番号
SalesOrderNumber
請求書の作成につながった元の販売オーダーの識別子。
説明

販売オーダー番号は、受注から現金化まで(Order to Cash)サイクルにおける先行する「オーダー管理」の部分への直接的なリンクを提供します。これは、請求プロセスと最初の顧客オーダーを結びつけます。

この属性により、より広範な、クロスプロセス分析が可能になります。例えば、アナリストは特定の種類の販売オーダーが常に請求紛争や支払遅延につながるかどうかを調査できます。これは、請求プロセスを単独で見たときに失われがちな貴重なコンテキストを提供します。

その重要性

請求プロセスを上流の販売プロセスに接続し、より包括的な受注から入金までの分析と根本原因調査を可能にします。

取得元

通常、INTERFACE_LINE_ATTRIBUTE1または類似の記述フレックスフィールドなど、請求書明細テーブルRA_CUSTOMER_TRX_LINES_ALLの参照またはインターフェース属性フィールドで見つかります。

SO-54321601882ORD-2023-9910
通貨
Currency
請求書上の金額に対する通貨コード。
説明

この属性は、請求金額が表記されている通貨(USDやEURなど)を指定します。これは、すべての財務指標に必要なコンテキストを提供します。

多国籍事業のデータを分析する場合、通貨属性は財務値を正確に解釈し比較するために不可欠です。ダッシュボードは、通貨でフィルタリングしたり、連結報告のために為替レートを適用したりするためにそれを使用できます。

その重要性

すべての財務属性に不可欠なコンテキストを提供し、多通貨環境での正確な解釈と分析を保証します。

取得元

通常、RA_CUSTOMER_TRX_ALLテーブルのINVOICE_CURRENCY_CODE列で見つかります。

USDEURGBP
顧客名
CustomerName
請求書が発行された顧客の正式名称。
説明

顧客名は、顧客の人間に読みやすい識別子を提供します。顧客IDが結合と一意の識別に使われる一方、名前はレポートやダッシュボードでの表示に使用されます。

これにより、ユーザーはIDを調べる手間なく顧客名を容易に認識できるため、分析がより直感的になります。顧客ごとの平均支払遅延を示す棒グラフなど、ユーザーフレンドリーな可視化を作成する上で不可欠です。

その重要性

フィルタリングとグループ化のために人間が読める名前を提供することで、ダッシュボードとレポートの使いやすさを向上させ、分析をよりアクセスしやすくします。

取得元

請求書ヘッダーの顧客IDを使用して、HZ_PARTIESおよびHZ_CUST_ACCOUNTSテーブルから結合されます。

Global Corp Inc.Innovate Solutions Ltd.Test Company LLC
顧客国
Country
顧客の請求先住所の国。
説明

この属性は、顧客の請求先住所に関連付けられた国を指定します。これは、プロセス分析のための地理的側面を提供します。

国別にプロセスを分析することで、支払い行動、プロセス効率、または現地規制への準拠における地域差を明らかにすることができます。例えば、「顧客支払い行動洞察」ダッシュボードで使用して、平均支払遅延が国間で大きく異なるかどうかを確認できます。

その重要性

プロセスの地域分析を可能にし、顧客行動、規制の影響、または運用パフォーマンスにおける地域差を強調します。

取得元

顧客の請求先サイト情報(HZ_LOCATIONSおよびFND_TERRITORIESに保存)から結合され、顧客勘定テーブルを介してリンクされます。

米国ドイツ英国
必須 推奨 任意

受注から現金化まで - 請求および売上計上活動

これらは、請求業務の正確な発見と分析のために、イベントログにキャプチャすべき不可欠なプロセスステップとマイルストーンです。
5 推奨 8 任意
アクティビティ 説明
入金消込/照合
受領された顧客からの支払いは、1つ以上の特定の請求書に正常に適用され、未払残高が減少しました。これは、債務に対する支払いの消込を表します。
その重要性

これは支払いプロセスの最終ステップであり、キャッシュアプリケーションサイクルタイムを測定するために不可欠です。ここでの遅延は、顧客アカウントの残高を誤って表示したり、信用管理に影響を与えたりする可能性があります。

取得元

このイベントは、AR_RECEIVABLE_APPLICATIONS_ALLテーブルにキャッシュレシートを取引にリンクするレコードが作成される際に、タイムスタンプとともに明示的に記録されます。

取得

イベントは、AR_RECEIVABLE_APPLICATIONS_ALLのレコードの作成タイムスタンプ(GL_DATEまたはAPPLY_DATE)です。

イベントタイプ explicit
請求書がクローズ済み
請求書は正式にクローズされ、支払い、クレジットメモ、および/または調整により残高がゼロになったことを示します。これは、請求書ライフサイクルの成功裏の完了を意味します。
その重要性

これはプロセスの主要な終点です。「請求書作成」から「請求書クローズ」までの総サイクル時間は、受注から現金化まで(Order to Cash)請求サイクルの全体的な効率を示す主要な指標です。

取得元

AR_PAYMENT_SCHEDULES_ALLテーブルのSTATUSフィールドが「CL」(クローズ)に変更されたことから推測されます。クローズを引き起こした最終トランザクションの日付をタイムスタンプとして使用できます。

取得

AR_PAYMENT_SCHEDULES_ALLでステータスが「CL」に変更されたことから推測され、最後に関連するアプリケーションによってタイムスタンプが付けられます。

イベントタイプ inferred
請求書生成済み
システムにおける新しい請求書トランザクションの作成を示します。このイベントは通常、履行された販売注文明細を処理する「自動請求書インポートプログラム」または売掛金モジュールでの手動請求書入力によってトリガーされます。
その重要性

これは請求プロセスの開始点です。このイベントから他のイベントまでの時間を分析することで、請求書ライフサイクル全体が明らかになり、初期段階のボトルネックを特定するのに役立ちます。

取得元

Oracle ReceivablesテーブルRA_CUSTOMER_TRX_ALL内の取引の作成日として記録されます。TRX_DATEまたはCREATION_DATEをイベントのタイムスタンプとして使用できます。

取得

イベントは、RA_CUSTOMER_TRX_ALLテーブルのレコードの作成タイムスタンプです。

イベントタイプ explicit
顧客からの入金受領
顧客からの支払いが現金受領としてシステムに入力されました。この段階では、支払いが特定の請求書にまだ適用されていない可能性があります。
その重要性

これは、売掛金回収日数(DSO)を計算するための主要なマイルストーンです。請求書作成から支払い受領までの期間は、回収効率の主要な尺度となります。

取得元

このイベントは、AR_CASH_RECEIPTS_ALLテーブルにレコードが作成される際に、タイムスタンプとともに明示的に記録されます。

取得

イベントは、AR_CASH_RECEIPTS_ALLテーブルのレコードの作成タイムスタンプです。

イベントタイプ explicit
顧客へ請求書送付
この活動は、請求書が印刷または電子的手段のいずれかによって正式に顧客に送信されたことを意味します。このイベントは、顧客の支払条件カウントダウンの開始をマークします。
その重要性

これは、請求書送付リードタイムと支払いまでの遅延を測定するための重要なマイルストーンです。内部処理の遅延と顧客の支払い行動を区別するのに役立ちます。

取得元

Oracle EBSでは、このイベントが常に標準フィールドに明示的に記録されるわけではありません。「Invoice Print」同時実行プログラムのタイムスタンプ、または電子配信時に設定されるカスタムフラグから推測できる場合があります。

取得

請求書印刷プログラムの完了日、または電子送信用のカスタムロジックから推測されます。

イベントタイプ inferred
クレジットメモ作成
クレジットメモトランザクションは生成され、請求エラーを修正したり返品処理を行ったりするために、既存の請求書に適用されることがよくあります。これは売掛金内の個別の関連トランザクションです。
その重要性

大量のクレジットメモは、注文履行、価格設定、または初期請求の正確性における上流の問題を示唆します。これらのイベントを分析することは、収益漏れと顧客不満の根本原因分析の鍵となります。

取得元

CUST_TRX_TYPE_IDが「CM」(クレジットメモ)クラスのタイプにリンクされているRA_CUSTOMER_TRX_ALL内の新しい取引として記録されます。PREVIOUS_CUSTOMER_TRX_IDフィールドは、これを元の請求書にリンクし直します。

取得

イベントは、RA_CUSTOMER_TRX_ALLにクレジットメモトランザクションタイプのレコードが作成されたことです。

イベントタイプ explicit
償却作成
残りの請求残高の全部または一部を貸倒金として償却する調整が行われます。これは通常、回収努力が尽くされた後に行われます。
その重要性

償却は、直接的な収益の損失を表します。その頻度と価値を分析することは、信用政策の改善や、回収不能債権の財務的影響を理解するのに役立ちます。

取得元

これは、請求書に対する特定の調整タイプ取引としてログに記録されます。このイベントは、償却のために定義された債権活動タイプへのリンクとともに、AR_ADJUSTMENTS_ALLテーブルで見つけることができます。

取得

イベントは、AR_ADJUSTMENTS_ALLに「償却」アクティビティタイプのレコードが作成されたことです。

イベントタイプ explicit
支払催促通知発行
期限切れの請求書に関して、顧客に督促状またはリマインダー通知が送付されました。これは回収プロセスにおける主要な活動です。
その重要性

この活動を追跡することは、回収戦略の有効性を測定するために不可欠です。催促通知送付前後の支払い率を分析することを可能にします。

取得元

Oracle Advanced Collectionsが使用されている場合、督促状の送付は明示的なイベントとしてログに記録されます。このモジュールがない場合、この活動はしばしばシステム外で実行され、確実に追跡できない可能性があります。

取得

Oracle Advanced Collectionsモジュールにおいて、督促状イベントとしてログに記録されます。

イベントタイプ explicit
支払取り消し
以前に受け取った顧客の支払いが取り消されたことを示します。これは通常、資金不足(NSF)またはその他の銀行処理エラーが原因で発生します。
その重要性

支払の取り消しはキャッシュフロー予測を妨げ、追加の管理作業を必要とします。これらのイベントを追跡することで、問題のある顧客や支払い方法を特定するのに役立ちます。

取得元

これはOracle Receivablesにおける明示的なアクションです。取消により、AR_CASH_RECEIPT_HISTORY_ALLに「REVERSED」など、取消を示すステータスを持つエントリが作成されます。

取得

AR_CASH_RECEIPT_HISTORY_ALLテーブルでステータスが「REVERSED」に変更されたことによって特定されます。

イベントタイプ explicit
支払期日到達
このイベントは、請求書が支払い条件に従って支払期日となる日を示す計算イベントです。ユーザーまたはシステムのアクションに対応するものではありませんが、重要な時間的マイルストーンとなります。
その重要性

このイベントは、期日内支払率の計算と顧客の支払い行動の分析に不可欠です。支払いが早期、期日内、または遅延であるかを判断するための基準として機能します。

取得元

これはイベントとして記録されません。特定の請求書について、AR_PAYMENT_SCHEDULES_ALLテーブルのTERM_DUE_DATEフィールドとシステム日付を比較することで計算されます。

取得

現在のタイムスタンプとAR_PAYMENT_SCHEDULES_ALL.TERM_DUE_DATEを比較することによって導き出されます。

イベントタイプ calculated
異議が提起されました
顧客は正式に請求書を異議申し立てし、解決まで回収活動が保留されています。これはしばしばOracle Advanced Collections内で管理されるか、手動でのステータス更新を通じて行われます。
その重要性

紛争は支払いを遅延させることでキャッシュフローに直接影響を与えます。その頻度と解決時間を追跡することは、製品、サービス、または請求の正確性に関する繰り返し発生する問題を特定するのに役立ちます。

取得元

Oracle Advanced Collectionsが使用されている場合、これは明示的なトランザクションです。そうでない場合、ARの請求書に適用された特定の「紛争」ステータスまたは保留から推測できます。

取得

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
推奨 任意

抽出ガイド

`Oracle E-Business Suite`から`データ`を取得する方法