貴社の購買から支払いまで - 請求書処理データテンプレート
貴社の購買から支払いまで - 請求書処理データテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- Oracle Fusion Financials 向け抽出ガイド
購買から支払いまで(P2P)- 請求書処理属性
| 名前 | 説明 | ||
|---|---|---|---|
|
請求書番号
InvoiceNumber
|
ベンダー請求書の一意の識別子。 | ||
|
説明
請求書番号は、単一のベンダー請求書の作成から最終支払いまでに関連するすべてのアクティビティとイベントをリンクする主要なケース識別子として機能します。各請求書はプロセス分析において一意のケースインスタンスとして扱われます。 プロセスマイニングにおいて、この属性は各請求書のエンドツーエンドのプロセスフローを再構築するための基本です。これにより、請求書ごとのプロセスフロー、サイクルタイム、および変動の分析が可能になります。検証、承認、支払いなどの異なるアクティビティを一貫したプロセスナラティブに結びつけるための鍵となります。
その重要性
これは、関連するすべてのプロセスステップを接続する不可欠なケース識別子であり、請求書の全ライフサイクルを追跡することを可能にします。
取得元
これは通常、AP_INVOICES_ALLテーブルのINVOICE_NUM列にあります。
例
INV-2023-001987654321ACME-FIN-5501
|
|||
|
アクティビティ
ActivityName
|
請求書プロセスで発生した業務アクティビティ/イベント名。 | ||
|
説明
この属性は、「請求書作成済み」、「請求書承認済み」、「支払い実行済み」など、請求書ライフサイクルにおける特定のステップまたはステータス変更を記述します。これは、プロセスフローを構成するイベントのシーケンスを形成します。 アクティビティのシーケンスと頻度を分析することがプロセスマイニングの核心です。これにより、実際のプロセスパスを発見し、アクティビティが遅延しているボトルネックを特定し、承認後に請求書が却下されるような逸脱や手戻りループを発見するのに役立ちます。
その重要性
プロセスのステップを定義し、プロセスマップの可視化、フローのバリエーション分析、およびボトルネックの特定に不可欠です。
取得元
この属性は通常、AP_INVOICES_ALL.WFAPPROVAL_STATUSや関連するワークフローテーブルなど、Oracle Fusion Financials内のステータスフィールド、監査テーブル、またはワークフローログの組み合わせから導出されます。
例
請求書検証済み請求書を保留に設定請求書承認済み支払い実行
|
|||
|
開始時刻
EventTime
|
アクティビティ/event の発生時刻を示すタイムスタンプ。 | ||
|
説明
この属性は、請求書プロセスにおける各アクティビティの日付と時間を提供します。サイクルタイム、期間、ステップ間の待機時間の計算を含む、すべてのタイムベースのプロセス分析に不可欠です。 このタイムスタンプを使用してイベントを時系列に並べることで、プロセスマイニングツールは各請求書の正確なアクティビティシーケンスを再構築できます。これにより、平均請求書サイクルタイムなどの主要なパフォーマンスインジケーターの計算が可能になり、プロセスのどの段階が最も時間を消費しているかを特定するのに役立ちます。
その重要性
このタイムスタンプは、サイクルタイムやボトルネックなど、期間と時間に関連するすべてのパフォーマンスメトリックを計算するために不可欠です。
取得元
このタイムスタンプは、AP_INVOICES_ALLのようなテーブルのCREATION_DATEやLAST_UPDATE_DATE、または関連するワークフローおよび支払いテーブルなど、Oracle Fusionテーブルの様々な日付フィールドから導出されます。
例
2023-04-15T10:00:00Z2023-04-16T14:35:10Z2023-04-20T09:05:00Z
|
|||
|
ユーザー名
UserName
|
アクティビティを実行したユーザーの名称です。 | ||
|
説明
この属性は、請求書の検証、保留の実行、支払いの承認など、アクティビティの実行責任を負う特定のユーザーまたはシステムエージェントを識別します。これはプロセスに人間またはシステムのリソースディメンションを提供します。 ユーザーによる分析は、ワークロードの分散を理解し、最高のパフォーマーを特定し、潜在的なトレーニングの必要性やコンプライアンスの問題を検出するのに役立ちます。例えば、特定のユーザーが常に手戻りループに関連しているか、あるいは特定の承認ステップが常に同じ個人によって処理され、潜在的な単一障害点を作成しているかどうかが明らかになることがあります。
その重要性
リソースのパフォーマンス分析、ワークロードのバランス調整、および特定のプロセスステップにどのユーザーやチームが関与しているかを特定することを可能にします。
取得元
この情報は、AP_INVOICES_ALLのようなテーブルのCREATED_BYやLAST_UPDATED_BYなどの監査列、または関連するワークフローログに格納されていることがよくあります。
例
john.doejane.smithシステム管理者
|
|||
|
仕入先名
VendorName
|
請求書を発行したベンダーまたはサプライヤーの名前。 | ||
|
説明
この属性は、請求書の発行元であるサプライヤーエンティティを識別します。ベンダー情報は、財務取引に不可欠なビジネスコンテキストを提供します。 ベンダーごとのプロセス分析は、サプライヤー関係とパフォーマンスに関する重要な洞察を明らかにできます。例えば、特定のベンダーからの請求書が照合不一致、保留、または遅延を起こしやすいかどうかを浮き彫りにすることができます。この情報は、ベンダーオンボーディング、コミュニケーション、および全体的なサプライチェーン効率を改善するために使用できます。また、潜在的な二重支払いを特定する際にも使用されます。
その重要性
ベンダー固有のプロセス分析を可能にし、特定のサプライヤーが引き起こす遅延や例外の問題を特定するのに役立ちます。
取得元
POZ_SUPPLIERSテーブルにあります。請求書テーブルAP_INVOICES_ALLには
例
アクメコーポレーション`Global Tech Inc.`事務用品株式会社
|
|||
|
会社コード
CompanyCode
|
請求書を処理する法的事業体または会社の識別子です。 | ||
|
説明
会社コードは、請求書に対して財務責任を負う組織内の特定の事業体を表します。複数の企業からなる組織では、これは基本的な組織データポイントです。 この属性により、プロセス分析を法エンティティ別にセグメント化できます。これは、事業の異なる部分間でプロセスパフォーマンスを比較したり、エンティティ固有のボトルネックやコンプライアンスの問題を特定したり、KPIが会社レベルで報告されることを保証したりするのに役立ちます。また、適切な承認ワークフローを決定する際の要因となることもよくあります。
その重要性
組織内の異なる法人やビジネスユニット間でプロセス比較とパフォーマンスベンチマークを可能にします。
取得元
これは通常、AP_INVOICES_ALLのLEGAL_ENTITY_IDまたは類似のフィールドで表され、総勘定元帳テーブルに結合してコードまたは名前を取得できます。
例
1001US01DE01
|
|||
|
支払期日
PaymentDueDate
|
仕入先への支払い期限日。 | ||
|
説明
支払い期日は、ベンダーと合意した支払い条件に基づいて計算されます。これは、違約金を回避し、良好なベンダー関係を維持し、潜在的な早期支払い割引を獲得するための支払い期限として機能します。 この属性は、「期日内支払いパフォーマンス」ダッシュボードおよび関連するKPIにとって不可欠です。実際の支払い実行タイムスタンプと支払い期日を比較することで、分析は支払いを期日内または遅延に分類でき、組織が支払いの適時性を監視し、改善するのに役立ちます。
その重要性
これは、期日内支払いパフォーマンスを測定するためのベースラインであり、ベンダー管理と財務健全性にとって重要なKPIです。
取得元
この日付は、請求書にリンクされたAP_PAYMENT_SCHEDULES_ALLのような支払いスケジュールテーブルでよく利用可能です。
例
2023-05-152023-06-012023-06-30
|
|||
|
終了日時
EndTime
|
アクティビティまたはイベントが完了した時点を示すタイムスタンプ。 | ||
|
説明
終了タイムは特定のアクティビティの完了を示します。開始タイムが開始を示すのに対し、終了タイムは終了点を提供し、個々のステップの正確な期間計算を可能にします。 分析では、終了タイムと開始タイムの差が各アクティビティの処理時間を示します。これは詳細なパフォーマンス分析に不可欠であり、アクティブな処理時間とアイドル待ち時間を区別するのに役立ちます。例えば、承認者が承認タスクに費やした実際の時間と、タスクがキューで待機していた時間を測定するのに役立ちます。
その重要性
活動処理時間の正確な計算を可能にし、実作業時間と待機時間を区別します。
取得元
これは、特定のケースのシーケンスにおける後続イベントの開始タイムから導出される概念属性です。
例
2023-04-15T10:05:12Z2023-04-16T15:00:00Z2023-04-20T09:15:30Z
|
|||
|
請求書ステータス
InvoiceStatus
|
請求書ライフサイクルにおける現在のステータス。 | ||
|
説明
この属性は、「検証済み」、「再検証が必要」、「支払い済み」、「キャンセル済み」など、請求書の最後に既知の状態を反映します。これにより、請求書がプロセスのどの段階にあるかのスナップショットがいつでも提供されます。 請求書ステータスは、「現在の請求書ステータス分布」ダッシュボードにとって不可欠であり、運用管理者がバックログを特定し、請求書処理パイプライン全体の健全性を監視するのに役立ちます。時間の経過とともにステータスがどのように変化するかを分析することは、プロセスフローの簡略化されたビューを提供することもできます。
その重要性
請求書の現状を提供し、バックログとワークロードを追跡する運用ダッシュボードに不可欠です。
取得元
Oracle Fusion Financialsのドキュメントを参照してください。ステータスは、AP_INVOICES_ALLの
例
検証済み支払い済みキャンセル済み再検証が必要
|
|||
|
請求金額
InvoiceAmount
|
請求書の合計金額。 | ||
|
説明
請求金額は、請求書に記載されているベンダーへの総支払い額を表します。これはプロセス全体に影響を与える重要な財務属性であり、承認経路、審査レベル、支払い優先順位を決定することがよくあります。 プロセスマイニング分析において、請求金額はフィルタリングとセグメンテーションの重要な要素です。例えば、アナリストは高額請求書と低額請求書のプロセスを比較し、異なる経路がたどられているか、サイクルタイムが著しく異なるかを調べることができます。また、財務KPIの計算や、支払い遅延などのプロセス非効率による金銭的影響を評価するためにも不可欠です。
その重要性
この値は、財務分析、値に基づくプロセス逸脱の理解、および「承認コンプライアンス率KPI」にとって不可欠です。
取得元
AP_INVOICES_ALLテーブルの
例
1500.00250.75125000.50
|
|||
|
ソースシステム
SourceSystem
|
イベントデータが記録された発生元システムを示します。 | ||
|
説明
この属性は、Oracle Fusion Financialsなど、データを生成したソースアプリケーションまたはモジュールを指定します。複数の統合システムを持つ環境では、このフィールドは異なるプロセスステップの出所を区別するのに役立ちます。 ソースシステムを理解することは、データ検証、トラブルシューティング、および特定のシステムに固有のプロセス変動を分析する上で価値があります。これにより、請求書のプロセスが複数のアプリケーションにまたがる可能性のある複雑なITランドスケープにおいて明確さが保証されます。
その重要性
データ起源に関するコンテキストを提供し、データガバナンス、トラブルシューティング、およびシステム固有のプロセス動作の分析にとって重要です。
取得元
これは多くの場合、
例
Oracle Fusion FinancialsOracle Payables Cloud
|
|||
|
保留理由
HoldReason
|
請求書に保留または支払い保留がかけられた理由。 | ||
|
説明
請求書が保留になった際、この属性は「価格不一致」、「数量不一致」、「商品受領待ち」など、その理由を特定します。これは、通常のプロセスフローがなぜ中断されたのかに関するコンテキストを提供します。 この属性は、「支払い保留トレンドと分析ダッシュボード」の主要なディメンションです。異なる保留理由の頻度を分析することで、企業は調達プロセスやベンダー請求の正確性の問題など、支払い保留の根本原因を特定し、対処することができ、最終的に処理遅延を削減します。
その重要性
支払ブロックの根本原因を提供し、保留と支払いの遅延の頻度を減らすためのターゲットを絞った改善を可能にします。
取得元
保留情報は通常、AP_HOLDS_ALLテーブルに保存され、請求書にリンクされており、保留理由またはコードが含まれています。
例
価格不一致請求数量が受領数量を超過無効な PO 番号
|
|||
|
最終データ更新
LastUpdateDate
|
ソースシステムでレコードが最後に更新された日時を示すタイムスタンプ。 | ||
|
説明
この属性は、Oracle Fusion Financialsにおける基盤となるデータの最新の変更時間を反映します。増分データロードを管理し、プロセスマイニングモデルが最新であることを保証するために使用されます。 プロセスフロー分析に直接使用されるわけではありませんが、この技術的なタイムスタンプはデータの鮮度と整合性を維持するために不可欠です。これにより、データパイプラインが前回の更新以降の新しいレコードまたは変更されたレコードのみを効率的に照会でき、ソースシステムへの負荷を軽減します。
その重要性
データパイプラインを効率的かつ増分的に実行し、完全な再ロードなしでプロセス分析を最新に保ちます。
取得元
AP_INVOICES_ALLを含む多くのOracle Fusionテーブルで、通常
例
2023-05-20T11:00:00Z2023-05-21T16:45:00Z
|
|||
|
処理時間
ProcessingTime
|
単一の`アクティビティ`に費やされた時間の長さ。 | ||
|
説明
処理時間とは、特定のプロセスステップにおける実際の作業時間を測定するものです。これは、アクティビティの終了時間と開始時間の差として計算されます。 この算出されたメトリックはパフォーマンス分析に不可欠であり、実際の処理時間とアイドル待ち時間を区別するのに役立ちます。例えば、承認アクティビティが実際の作業に5分かかったが、キューで3日間待機していたということが分かります。この洞察により、管理者は、トレーニングや自動化による作業時間の短縮、またはより良いワークロード管理による待ち時間の短縮のいずれかに改善努力を集中させることができます。
その重要性
活動の実作業時間を分離し、非効率なタスクと長い待機期間を区別するのに役立ちます。
取得元
これは、終了タイムから開始タイムを差し引いて導出される計算属性です(終了タイム - 開始タイム)。
例
PT5MPT1H30MP2D
|
|||
|
手戻り
IsRework
|
再作業ループの一部である活動を識別するブールフラグです。 | ||
|
説明
このフラグは、「請求書修正済み」や却下後の2回目の「請求書検証済み」など、理想的なプロセスフローからの逸脱を示すアクティビティに対してTrueに設定されます。これにより、非効率なプロセスループを明示的にタグ付けし、定量化するのに役立ちます。 この属性は、「手戻りと例外処理率」ダッシュボードにとって不可欠です。手戻りアクティビティにフラグを付けることで、アナリストは手戻りの量とコストを簡単に定量化し、その根本原因を特定し、初回で正しく処理することを目的としたプロセス改善イニシアチブの影響を測定できます。
その重要性
再作業を明確に特定し定量化することで、プロセス非効率性の頻度、原因、影響を分析しやすくします。
取得元
これは計算属性です。手戻りを構成するアクティビティのシーケンスを特定するために、データ変換中にロジックが定義されます。
例
truefalse
|
|||
|
承認者名
ApproverName
|
請求書を承認または却下した人物の名前。 | ||
|
説明
この属性は、承認ステップ中にアクションを実行した個人の識別情報を捕捉します。「請求書承認済み」や「請求書却下済み」などのアクティビティに記録されます。 分析では、承認者名は承認ワークロードを理解し、個々の承認者のサイクルタイムを測定し、承認ポリシーへのコンプライアンスを監査するために使用されます。「承認コンプライアンス率」KPIの場合、この属性は請求金額と会社コードに基づいた権限委譲ルールに対してチェックできます。
その重要性
これは、承認サイクルタイムの分析、承認マトリックスポリシーへのコンプライアンスの確保、ワークロードの分散理解に不可欠です。
取得元
この情報は、請求書オブジェクトに関連付けられたOracle Fusion ワークフローまたは承認履歴テーブルに存在します。
例
David Wilsonサラ・ジョンソンマイケル・ブラウン
|
|||
|
期日内支払いか
IsOnTimePayment
|
請求書が期日までに支払われたかどうかを示すブールフラグです。 | ||
|
説明
このフラグは、指定された支払い期日までに支払いが実行された場合はTrueに、それ以外の場合はFalseに設定されます。これにより、支払い済みの各請求書に対するシンプルで明確な分類が提供されます。 この算出された属性は、「期日内支払い率KPI」とその対応するダッシュボードを直接サポートします。データ比較をその場で行うことなく、ユーザーが遅延支払いと期日内支払いの割合を簡単にフィルタリング、カウント、可視化できるようにすることで、分析を簡素化します。これにより、支払い遅延の規模を迅速に特定し、時間の経過とともに改善を追跡するのに役立ちます。
その重要性
これにより、支払い適時性の分析が簡素化され、「期日内支払い率KPI」を計算するための直接的な入力となります。
取得元
これは、「支払い実行済み」アクティビティのタイムスタンプと「PaymentDueDate」属性を比較して導出される計算属性です。
例
truefalse
|
|||
|
照合不一致の理由
MatchingDiscrepancyReason
|
請求書、発注書、受領書の間の不一致の具体的な理由。 | ||
|
説明
この属性は、請求書が自動照合プロセスに失敗した理由を詳しく説明します。一般的な理由には、請求書と対応する発注書または商品受領書との間で価格、数量、または品目コードに差異があることが含まれます。 この情報は「請求書照合不一致率」ダッシュボードにとって不可欠です。不一致の理由を分類し分析することで、企業は調達または受領プロセスにおけるシステム的な問題を特定できます。これにより、ストレートスルーでタッチレスな請求書処理の割合を高めるための是正措置が可能になります。
その重要性
請求書が自動照合に失敗する理由を説明し、初回照合率を改善し、手作業による再作業を削減するために必要なインサイトを提供します。
取得元
Oracle Fusion Financialsのドキュメントを参照してください。これは、AP_HOLDS_ALLの特定の種類の保留理由として、または関連する照合詳細テーブルに記録される場合があります。
例
単価が発注書と異なる請求数量 > 受領数量請求書上の無効な品目
|
|||
|
発注書番号
PurchaseOrderNumber
|
請求書に関連付けられている発注書の識別子。 | ||
|
説明
この属性は、請求書を対応する発注書(PO)にリンクし、商品またはサービスの調達を承認したものです。請求書はPOに裏付けられている場合とそうでない場合があります。 POによる分析は、P2Pプロセスの調達部分へのリンクを提供します。これにより、調達プロセスがどれだけコンプライアンスに準拠しているか、また照合不一致などの請求書に関する問題が最初のPOの問題に起因するかどうかを理解するのに役立ちます。PO番号の有無は、異なる請求書処理パスをセグメント化し分析する主要な方法です。
その重要性
請求書を調達プロセスにリンクさせ、PO請求書と非PO請求書のフローを分析するための主要な属性です。
取得元
この情報は、AP_INVOICE_LINES_ALLの請求書明細をPO_DISTRIBUTION_IDを介して発注書配賦にリンクすることで利用できます。
例
PO-2023-5001600789PO-FIN-9981
|
|||
|
請求日
InvoiceDate
|
ベンダーの請求書ドキュメントに記載されている日付。 | ||
|
説明
この属性は、ベンダーが正式に請求書を発行した日付です。これは原ドキュメント上の重要な情報であり、合意された支払い条件に基づいて支払い期日を計算するための開始点として使用されます。 必ずしも内部プロセスの開始点ではありませんが、請求書日付は重要なコンテキストです。ベンダー名および請求金額と組み合わせて、潜在的な二重請求書を特定するのに役立ちます。請求書日付とシステムで請求書が作成された日付との間の遅延を分析することも、メールルームまたは請求書取り込みプロセスの非効率性を明らかにすることができます。
その重要性
重複請求書を特定し、支払期日を計算するための重要なデータポイントです。
取得元
これはAP_INVOICES_ALLテーブルの標準フィールドで、INVOICE_DATEという名前です。
例
2023-04-102023-05-012023-05-25
|
|||
|
通貨
InvoiceCurrencyCode
|
請求金額の通貨です。 | ||
|
説明
この属性は、請求書が建てられている通貨を指定します。例えば、USD、EUR、GBPなどです。これは請求金額フィールドの重要なコンテキストです。 グローバル組織では、通貨別に請求書を分析することは、財務報告や地域ごとのプロセス変動を理解する上で重要です。これにより、金銭的価値が正しく解釈され、支払い慣行や承認しきい値の通貨固有の分析が可能になります。
その重要性
あらゆる財務金額に必要なコンテキストを提供し、特に多国籍企業における正確な解釈と分析を保証します。
取得元
AP_INVOICES_ALLテーブルの
例
USDEURGBPCAD
|
|||
購買から支払いまで(P2P)- 請求書処理アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
承認のために請求書を送信
|
請求書は設定されたビジネスルールに基づき、承認ワークフローに提出されます。これにより、正式な承認サイクルが開始されます。 | ||
|
その重要性
プロセスの重要な部分を開始します。この開始時刻を追跡することは、「請求書承認サイクルタイム」を測定および最適化するために不可欠です。
取得元
AP_INVOICES_ALLテーブルのステータス変更、具体的には
取得
AP_INVOICES_ALL.APPROVAL_STATUSが'Initiated'に変更されたことから推測されます。
イベントタイプ
inferred
|
|||
|
支払い実行
|
支払いが実行され、決済されたことの最終確認です。小切手の場合、これは決済日であり、電子支払いの場合、銀行からの確認です。 | ||
|
その重要性
これは請求書ライフサイクルの最終アクティビティであり、プロセスの正常な完了を示します。「平均請求書サイクルタイム」と「期日内支払い率」を計算するためのエンドポイントです。
取得元
AP_CHECKS_ALLテーブルで支払いステータスが「Cleared」または「Reconciled」に更新されたこと(
取得
AP_CHECKS_ALLのステータス更新、またはCEモジュールでの調整から推測されます。
イベントタイプ
inferred
|
|||
|
請求書をPOと照合済み
|
このアクティビティは、請求書明細が対応する発注書明細と正常に照合されたことを示し、請求された商品やサービスが注文されたことを確認します。これは通常、システムに記録される自動または手動のアクションです。 | ||
|
その重要性
購買発注書、受領書、請求書を含む三者照合にとって不可欠です。この段階での失敗は、例外と遅延の主な原因となります。
取得元
請求書をPO配布(PO_DISTRIBUTION_ID)にリンクするAP_INVOICE_DISTRIBUTIONS_ALLテーブルのレコード作成から推測できます。AP_INVOICE_LINES_ALLの行レベル照合ステータスも使用できます。
取得
請求書明細行へのPO配布データの投入から推測されます。
イベントタイプ
inferred
|
|||
|
請求書会計処理済み
|
請求書は正常に総勘定元帳に転記され、仕訳が作成されます。このイベントは、請求書の財務的影響が正式に記録されたことを確認します。 | ||
|
その重要性
支払いにおける重要な財務管理ポイントであり、必須要件です。これにより、請求書が完全に検証、承認され、決済準備が整っていることが確認されます。
取得元
AP_INVOICE_DISTRIBUTIONS_ALLテーブルのステータス(
取得
AP_INVOICE_DISTRIBUTIONS_ALLのフラグまたはリンクされたGLエントリから推測されます。
イベントタイプ
inferred
|
|||
|
請求書作成
|
システムでの請求書レコードの初回作成を表します。これは手動入力、スキャン、または電子送信を通じて行われます。このイベントは通常、主要な請求書テーブルに新しい行が挿入されたときに捕捉されます。 | ||
|
その重要性
請求書処理ライフサイクルの開始を示します。このイベントからの時間を分析することで、データ入力の効率性とプロセス開始全体の遅延を理解するのに役立ちます。
取得元
Oracle Fusion Financialsでは、これはAP_INVOICES_ALLテーブルのレコードの作成タイムスタンプ、特に
取得
AP_INVOICES_ALLにおけるレコード作成タイムスタンプ。
イベントタイプ
explicit
|
|||
|
請求書承認済み
|
請求書はワークフロー内のすべての関係者によって完全に承認されました。これで会計処理と支払いスケジューリングの準備が整いました。 | ||
|
その重要性
承認プロセスの成功裏の完了を示す主要なマイルストーンです。このステップ前の遅延は、一般的なボトルネックです。
取得元
AP_INVOICES_ALLテーブルの
取得
AP_INVOICES_ALL.APPROVAL_STATUSが'Approved'に変更されたことから推測されます。
イベントタイプ
inferred
|
|||
|
支払いスケジュール設定
|
請求書は選択され、支払い処理リクエスト(多くの場合、支払い実行または支払いバッチと呼ばれます)に含まれます。これで支払いキューに入れられました。 | ||
|
その重要性
会計処理と実際の支払いの中間のステップです。この段階の期間は、キャッシュフロー予測と早期支払い割引の獲得能力に影響を与えます。
取得元
これは、支払いレコードが作成されたもののまだ支払い済みとして確認されていない場合に、AP_INVOICE_PAYMENTS_ALLテーブルに記録されます。IBY_PAYMENT_PROCESS_REQUESTSのような支払いバッチテーブルでも見つけることができます。
取得
予定された支払いについて、AP_INVOICE_PAYMENTS_ALLにレコードが作成されること。
イベントタイプ
explicit
|
|||
|
支払作成
|
請求書に対する支払い指示がシステムによって生成されました。これは、小切手の作成、電子資金移動(EFT)ファイル、またはその他の支払い手段である可能性があります。 | ||
|
その重要性
これは組織が支払いのために資金をコミットする時点です。銀行口座から資金が引き出される直前の重要なマイルストーンです。
取得元
すべての支払いに関する情報を格納するAP_CHECKS_ALLテーブルに記録されます。CHECK_DATEは支払いドキュメントが作成された日時を示します。
取得
AP_CHECKS_ALLテーブルにレコードが作成されること。
イベントタイプ
explicit
|
|||
|
照合データの不一致が検出されました
|
システムまたはユーザーが、請求書、発注書、受領書情報(価格や数量など)の間に不一致を特定したときに発生します。これにより、請求書にシステムが自動的に保留をかけることがよくあります。 | ||
|
その重要性
手動介入が必要なプロセス例外を強調します。これらのイベントを追跡することは、「請求書照合不一致率」KPIと根本原因分析に不可欠です。
取得元
これは、請求書にかけられる特定のタイプの保留として記録されることがよくあります。AP_HOLDS_ALLテーブルで、照合に関連する保留タイプ(例:'QTY REC'や'PRICE')を確認してください。HOLD_DATEはタイムスタンプを示します。
取得
照合関連の保留タイプを持つAP_HOLDS_ALLにレコードが作成されること。
イベントタイプ
explicit
|
|||
|
請求書から保留解除
|
このイベントは、以前に請求書にかけられていた保留の解決を示します。ユーザーまたは自動化されたプロセスがブロックを解除するアクションを実行し、請求書がそのライフサイクルを継続できるようにします。 | ||
|
その重要性
保留が設定されてから解除されるまでの時間は、例外処理効率の重要な指標です。これは「平均例外解決時間」KPIをサポートします。
取得元
AP_HOLDS_ALLテーブルに記録されます。保留が解除されると、RELEASE_LOOKUP_CODEおよびRELEASE_REASONフィールドがLAST_UPDATE_DATEとともに更新されます。
取得
AP_HOLDS_ALLテーブルのレコードを更新し、保留を解除済みとしてマークします。
イベントタイプ
explicit
|
|||
|
請求書キャンセル
|
請求書は無効またはキャンセルされ、これ以上処理されたり支払われたりすることはありません。これはプロセスの最終終了状態を表します。 | ||
|
その重要性
支払いにつながらない請求書にとって重要な終点です。キャンセルを分析することで、重複請求書や不正確なベンダー提出の問題を明らかにすることができます。
取得元
AP_INVOICES_ALLのステータス変更から推測されます。
取得
AP_INVOICES_ALLテーブルのCANCELLED_DATEフィールドが更新されます。
イベントタイプ
explicit
|
|||
|
請求書を保留に設定
|
請求書に保留が設定され、支払いに進むのを妨げる一般的な活動です。照合の問題、資金不足、手動介入など、さまざまな理由が考えられます。 | ||
|
その重要性
サイクルタイムに直接影響し、支払いの遅延につながる可能性があります。保留の分析は、システム的なプロセス問題の特定と解決に不可欠であり、「支払ブロック傾向」分析をサポートします。
取得元
AP_HOLDS_ALLテーブルに明示的に記録されます。各行は、作成日(
取得
AP_HOLDS_ALLテーブルにレコードが作成されること。
イベントタイプ
explicit
|
|||
|
請求書修正済み
|
ユーザーが請求書を修正する際に発生します。多くの場合、却下された後やデータ入力ミスを修正するためです。これはプロセスにおける手作業の手戻りステップを表します。 | ||
|
その重要性
このアクティビティは手戻りの明確な指標です。その頻度を分析することで、プロセス非効率性を定量化し、「請求書手戻り率」KPIをサポートします。
取得元
請求書がすでに検証または承認のために提出された後、AP_INVOICES_ALLの請求書レコードに対する重要な更新を追跡することで推測できます。
取得
却下または保留後の
イベントタイプ
inferred
|
|||
|
請求書却下
|
承認ワークフロー中に承認者が請求書を却下しました。このアクションは通常、請求書を修正またはキャンセルするために差し戻し、再作業ループを開始します。 | ||
|
その重要性
負の結果を表し、手戻りとサイクルタイム増加の主な要因となります。却下を追跡することで、請求書の品質または発注書コンプライアンスに関する問題を特定するのに役立ちます。
取得元
AP_INVOICES_ALLテーブルの
取得
AP_INVOICES_ALL.APPROVAL_STATUSが'Rejected'に変更されたことから推測されます。
イベントタイプ
inferred
|
|||
|
請求書検証済み
|
請求書がシステムによるヘッダーおよび行情報の完全性と正確性の検証チェックをパスしたことを示します。これは多くの場合、請求書レコードのステータス変更から推測されます。 | ||
|
その重要性
照合および承認前の重要なマイルストーンです。ここでの遅延は、請求書データの品質やシステム構成に問題があることを示唆している可能性があります。
取得元
AP_INVOICES_ALLテーブルの請求書ステータスが「Validated」に変更されたことから推測されます。
取得
AP_INVOICES_ALL.
イベントタイプ
inferred
|
|||