調達から支払いまでの請求書処理用データテンプレート
調達から支払いまでの請求書処理用データテンプレート
- 収集を推奨する属性
- 追跡する主なアクティビティ
- Oracle Fusion Financialsからのデータ抽出ガイド
調達から支払いまでの請求書処理に関する属性
| 名前 | 説明 | ||
|---|---|---|---|
|
請求書番号
InvoiceNumber
|
仕入先の請求書を一意に識別する番号です。 | ||
|
説明
請求書番号は、仕入先の請求書1件に関するすべてのアクティビティとイベントを、作成から最終支払いまで関連付ける主要なケース識別子です。プロセス分析では、請求書ごとに個別のケースとして扱います。 プロセスマイニングでは、この属性を使って請求書ごとの一連の流れを最初から最後まで再構成します。請求書単位でプロセスの流れ、サイクルタイム、ばらつきを分析できます。また、検証、承認、支払いなどのアクティビティを一貫したプロセスの流れとして結び付けるための重要な項目です。
重要な理由
関連するすべてのプロセスステップを結び付ける重要なケース識別子です。請求書のライフサイクル全体を追跡できます。
入手先
通常はAP_INVOICES_ALLテーブルのINVOICE_NUM列にあります。
例
INV-2023-001987654321ACME-FIN-5501
|
|||
|
アクティビティ
ActivityName
|
請求書処理で発生した業務上のアクティビティまたはイベントの名前です。 | ||
|
説明
この属性は、「請求書を作成」「請求書を承認」「支払いを実行」など、請求書のライフサイクルにおける特定のステップやステータス変更を表します。プロセスの流れを構成する一連のイベントを示します。 アクティビティの順序や頻度の分析は、プロセスマイニングの中心です。実際のプロセス経路の把握、アクティビティの遅延が発生しているボトルネックの特定、承認後に請求書が却下されるような逸脱や手戻りの発見に役立ちます。
重要な理由
プロセスの各ステップを定義する属性です。プロセスマップの可視化、流れのばらつきの分析、ボトルネックの特定に欠かせません。
入手先
通常は、Oracle Fusion Financials内のステータスフィールド、監査テーブル、ワークフローログなどから取得します。例として、AP_INVOICES_ALL.WFAPPROVAL_STATUSや関連するワークフローテーブルがあります。
例
請求書を検証請求書を保留請求書を承認支払いを実行
|
|||
|
開始時刻
EventTime
|
アクティビティまたはイベントが発生した日時を示すタイムスタンプです。 | ||
|
説明
この属性は、請求書処理における各アクティビティの日付と時刻を示します。サイクルタイム、所要時間、ステップ間の待ち時間など、時間に基づくプロセス分析に欠かせません。 このタイムスタンプを使ってイベントを時系列に並べると、プロセスマイニングツールで請求書ごとの正確なアクティビティの順序を再構成できます。請求書サイクルタイムの平均などの重要業績評価指標を算出し、プロセスのどの段階に最も時間がかかっているかを特定できます。
重要な理由
サイクルタイムやボトルネックなど、所要時間に関するすべてのパフォーマンス指標の算出に欠かせないタイムスタンプです。
入手先
このタイムスタンプは、Oracle Fusionの各種テーブルの日付フィールドから取得します。たとえば、AP_INVOICES_ALLや関連するワークフローおよび支払いテーブルのCREATION_DATEやLAST_UPDATE_DATEなどです。
例
2023-04-15T10:00:00Z2023-04-16T14:35:10Z2023-04-20T09:05:00Z
|
|||
|
ユーザー名
UserName
|
アクティビティを実行したユーザーの名前です。 | ||
|
説明
この属性は、請求書の検証、保留設定、支払い承認などのアクティビティを実行したユーザーまたはシステムエージェントを特定します。プロセスに関わる人的リソースまたはシステムリソースを把握できます。 ユーザー別に分析すると、作業負荷の分布や高い成果を上げている担当者を把握し、トレーニングの必要性やコンプライアンス上の問題を見つけやすくなります。たとえば、特定のユーザーが手戻りの繰り返しに頻繁に関わっていないか、特定の承認ステップが常に同じ担当者に集中し、単一障害点になっていないかを確認できます。
重要な理由
リソースパフォーマンスや作業負荷の配分を分析し、特定のプロセスステップに関わるユーザーやチームを特定できます。
入手先
この情報は、AP_INVOICES_ALLなどのテーブルにあるCREATED_BYやLAST_UPDATED_BYなどの監査用列、または関連するワークフローログに保存されていることがよくあります。
例
john.doejane.smithSystem.Admin
|
|||
|
仕入先名
VendorName
|
請求書を発行した仕入先の名前です。 | ||
|
説明
この属性は、請求書の発行元である仕入先を特定します。仕入先情報は、財務取引の背景を把握するうえで重要です。 仕入先別にプロセスを分析すると、仕入先との関係やパフォーマンスに関するインサイトが得られます。たとえば、特定の仕入先の請求書で照合不一致、保留、遅延が多く発生していないかを確認できます。この情報は、仕入先の登録やコミュニケーションの改善、サプライチェーン全体の効率向上に役立ちます。また、重複支払いの可能性を特定する際にも使われます。
重要な理由
仕入先ごとのプロセス分析が可能になり、遅延や例外の原因となっている特定の仕入先の問題を見つけやすくなります。
入手先
POZ_SUPPLIERSテーブルにあります。請求書テーブルAP_INVOICES_ALLのVENDOR_IDを使って、仕入先テーブルと結合できます。
例
Acme CorporationGlobal Tech Inc.Office Supplies Co.
|
|||
|
会社コード
CompanyCode
|
請求書を処理する法人または会社を識別するコードです。 | ||
|
説明
会社コードは、請求書の財務責任を負う組織内の事業体を示します。複数の会社を持つ組織では、基本となる組織データの1つです。 この属性を使うと、法人別にプロセス分析を分類できます。事業の各部門間でパフォーマンスを比較し、法人固有のボトルネックやコンプライアンス上の問題を特定できるほか、会社単位で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のWFAPPROVAL_STATUSなどのフィールド、または関連する承認・支払いテーブルから取得できる場合があります。
例
検証済み支払済みキャンセル済み再検証が必要
|
|||
|
請求書金額
InvoiceAmount
|
請求書に記載された合計金額です。 | ||
|
説明
請求書金額は、請求書に記載された仕入先への支払総額です。承認経路、確認の厳しさ、支払いの優先順位を左右することが多く、プロセス全体に影響する重要な財務属性です。 プロセスマイニング分析では、請求書金額を使ってデータを絞り込み、分類できます。たとえば、高額請求書と低額請求書でプロセスの経路やサイクルタイムに大きな違いがあるかを比較できます。また、財務KPIの算出や、支払い遅延などプロセスの非効率性による金銭的影響の評価にも欠かせません。
重要な理由
財務分析や金額に応じたプロセス逸脱の把握に役立ち、承認コンプライアンス率などのKPIにも使われます。
入手先
AP_INVOICES_ALLテーブルのINVOICE_AMOUNT列にあります。
例
1500.00250.75125000.50
|
|||
|
ソースシステム
SourceSystem
|
イベントデータが記録された元のシステムを示します。 | ||
|
説明
この属性は、Oracle Fusion Financialsなど、データを生成したソースアプリケーションまたはモジュールを示します。複数のシステムを連携している環境では、プロセスの各ステップがどのシステムから発生したかを区別できます。 ソースシステムを把握すると、データの検証や問題の調査、特定のシステムに固有のプロセスのばらつきの分析に役立ちます。請求書の処理が複数のアプリケーションにまたがる複雑なIT環境でも、データの出所を明確にできます。
重要な理由
データの出所を把握できるため、データガバナンス、問題の調査、システム固有のプロセス動作の分析に役立ちます。
入手先
多くの場合、データ抽出時にデータセットの出所を示す固定値として追加されます。
例
Oracle Fusion FinancialsOracle Payables Cloud
|
|||
|
保留理由
HoldReason
|
請求書が保留または支払いブロックになった理由です。 | ||
|
説明
請求書が保留になると、この属性に「価格の不一致」「数量の不一致」「入荷待ち」などの理由が記録されます。通常のプロセスフローが中断された背景を把握できます。 この属性は、「支払いブロックの傾向と分析」ダッシュボードの主要な分析軸です。保留理由ごとの発生頻度を分析することで、調達プロセスの問題や仕入先の請求精度など、支払いブロックの根本原因を特定して対処できます。その結果、処理の遅延を減らせます。
重要な理由
支払いブロックの根本原因を把握できるため、保留や支払い遅延を減らすための改善策を絞り込めます。
入手先
保留情報は通常、請求書に関連付けられ、保留理由またはコードを含むAP_HOLDS_ALLテーブルに保存されます。
例
価格の不一致請求数量が入荷数量を超過発注書番号が無効
|
|||
|
最終データ更新日時
LastUpdateDate
|
ソースシステムでレコードが最後に更新された日時を示すタイムスタンプです。 | ||
|
説明
この属性は、Oracle Fusion Financialsの基盤データが最後に変更された日時を示します。増分データ読み込みの管理に使われ、プロセスマイニングモデルを最新の状態に保つために役立ちます。 プロセスフローの分析に直接使うものではありませんが、データの鮮度と整合性を保つうえで重要な技術情報です。前回の更新以降に追加または変更されたレコードだけをデータパイプラインで効率よく取得できるため、ソースシステムの負荷を抑えられます。
重要な理由
データパイプラインを効率よく増分実行できるため、完全再読み込みを行わずにプロセス分析を最新の状態に保てます。
入手先
AP_INVOICES_ALLを含む多くのOracle Fusionテーブルでは、LAST_UPDATE_DATEとして格納されています。
例
2023-05-20T11:00:00Z2023-05-21T16:45:00Z
|
|||
|
手戻りかどうか
IsRework
|
手戻りのループに含まれるアクティビティを識別する真偽値です。 | ||
|
説明
「請求書を修正」や、却下後に再度行われた「請求書を検証」など、理想的なプロセスフローからの逸脱を示すアクティビティにはtrueが設定されます。非効率なプロセスの繰り返しを明示し、その規模を定量化できます。 この属性は、「手戻りと例外処理率」ダッシュボードに欠かせません。手戻りのアクティビティにフラグを付けることで、手戻りの量やコストを簡単に定量化し、根本原因を特定できます。また、初回から正しく処理することを目指す改善施策の効果も測定できます。
重要な理由
手戻りを明示して定量化できるため、プロセスの非効率性が発生する頻度や原因、その影響を分析しやすくなります。
入手先
これは計算属性です。手戻りに該当するアクティビティの順序を特定するロジックは、データ変換時に定義します。
例
truefalse
|
|||
|
承認者名
ApproverName
|
請求書を承認または却下した担当者の名前です。 | ||
|
説明
この属性には、承認ステップで操作を行った担当者が記録されます。「請求書を承認」や「請求書を却下」などのアクティビティが対象です。 分析では、承認者名を使って承認業務の負荷を把握し、承認者ごとのサイクルタイムを測定し、承認ポリシーへの準拠状況を監査できます。「承認コンプライアンス率」KPIでは、この属性を請求書金額や会社コードに基づく権限委譲ルールと照合できます。
重要な理由
承認のサイクルタイムや承認マトリクスのポリシーへの準拠状況を分析し、作業負荷の分布を把握するうえで欠かせません。
入手先
この情報は、請求書オブジェクトに関連付けられたOracle Fusionのワークフローまたは承認履歴テーブルに保存されています。
例
David WilsonSarah JohnsonMichael Brown
|
|||
|
期日どおりの支払いか
IsOnTimePayment
|
請求書が支払期日までに支払われたかどうかを示す真偽値です。 | ||
|
説明
支払いが指定された支払期日までに実行された場合はtrue、期日を過ぎた場合はfalseに設定されます。支払い済みの請求書を明確に分類できます。 この計算属性は、「期日どおりの支払い率」KPIと対応するダッシュボードに直接使われます。日付をその都度比較しなくても、支払いの遅延と期日どおりの支払いの割合を簡単に絞り込み、集計、可視化できます。これにより、支払い遅延の規模をすばやく把握し、改善状況を継続的に追跡できます。
重要な理由
支払いの適時性を簡単に分析でき、「期日どおりの支払い率」KPIの算出に直接使われます。
入手先
「支払い実行」アクティビティのタイムスタンプと「PaymentDueDate」属性を比較して算出する属性です。
例
truefalse
|
|||
|
照合不一致の理由
MatchingDiscrepancyReason
|
請求書、発注書、入荷記録の間に不一致が生じた具体的な理由です。 | ||
|
説明
この属性には、請求書が自動照合に失敗した理由が記録されます。よくある理由として、請求書と対応する発注書または入荷記録の間で、価格、数量、品目コードが一致しないことが挙げられます。 この情報は、「請求書照合不一致率」ダッシュボードに欠かせません。不一致の理由を分類して分析することで、調達や入荷処理における組織的な問題を特定できます。これにより、請求書を手作業なしで一度で処理できる割合を高めるための是正措置を講じられます。
重要な理由
請求書が自動照合に失敗した理由を明らかにし、初回照合率の向上や手作業による手戻りの削減に必要な情報を得られます。
入手先
Oracle Fusion Financialsの文書を参照してください。AP_HOLDS_ALLの保留理由の種類、または関連する照合詳細テーブルに記録されている場合があります。
例
単価が発注書と異なる請求数量が入荷数量を超過請求書の品目が無効
|
|||
|
発注書番号
PurchaseOrderNumber
|
請求書に関連付けられた発注書を識別する番号です。 | ||
|
説明
この属性は、商品やサービスの調達を承認した発注書(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テーブルのINVOICE_CURRENCY_CODE列にあります。
例
USDEURGBPCAD
|
|||
調達から支払いまでの請求書処理に関するアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
支払いを実行
|
支払いが実行され、決済されたことを最終確認するイベントです。小切手の場合は決済日、電子決済の場合は銀行からの確認に該当します。 | ||
|
重要な理由
請求書処理の最後のアクティビティであり、プロセスの正常な完了を示します。「請求書サイクルタイムの平均」と「期日どおりの支払い率」の算出における終点です。
入手先
AP_CHECKS_ALLテーブルで支払いステータスが「Cleared」または「Reconciled」に更新されたこと(CLEARED_DATEを使用)から判断します。または、キャッシュ管理モジュールの銀行照合データ(CE_STATEMENT_LINES)を利用します。
記録
AP_CHECKS_ALLのステータス更新、またはCEモジュールでの照合から判断します。
イベントタイプ
inferred
|
|||
|
請求書と発注書を照合
|
請求書の明細と対応する発注書(PO)の明細が正常に照合されたことを示します。請求対象の商品やサービスが発注済みであることを確認する処理です。通常は、システムに記録された自動処理または手動操作です。 | ||
|
重要な理由
発注書(PO)、受領記録、請求書を照合する三点照合に欠かせない処理です。この段階での照合失敗は、例外や遅延の主な原因になります。
入手先
AP_INVOICE_DISTRIBUTIONS_ALLテーブルに、請求書とPOの配分(PO_DISTRIBUTION_ID)を関連付けるレコードが作成されたことから判断できます。AP_INVOICE_LINES_ALLの明細レベルの照合ステータスも利用できます。
記録
請求書明細にPOの配分データが登録されたことから判断します。
イベントタイプ
inferred
|
|||
|
請求書を会計処理
|
請求書が総勘定元帳に正常に転記され、仕訳が作成された状態です。このイベントにより、請求書の財務上の影響が正式に記録されたことを確認できます。 | ||
|
重要な理由
重要な財務管理上の確認点であり、支払いの前提となる処理です。請求書の検証と承認が完了し、決済の準備が整ったことを確認できます。
入手先
AP_INVOICE_DISTRIBUTIONS_ALLテーブルのステータス(ACCRUAL_POSTED_FLAG = 'Y')から判断するか、XLA_AE_HEADERSなどの総勘定元帳テーブルに対応する仕訳があるかを確認します。
記録
AP_INVOICE_DISTRIBUTIONS_ALLのフラグ、または関連する総勘定元帳の仕訳から判断します。
イベントタイプ
inferred
|
|||
|
請求書を作成
|
手入力、スキャン、電子送信などにより、システムに請求書レコードが初めて作成されたことを示します。通常は、請求書のメインテーブルに新しい行が追加された時点で記録されます。 | ||
|
重要な理由
請求書処理の開始を示すイベントです。このイベントからの経過時間を分析すると、データ入力の効率やプロセス開始までの遅れを把握できます。
入手先
Oracle Fusion Financialsでは、AP_INVOICES_ALLテーブルのCREATION_DATE列に記録されたレコードの作成日時に該当します。
記録
AP_INVOICES_ALLのレコード作成日時。
イベントタイプ
explicit
|
|||
|
請求書を承認
|
ワークフローで必要なすべての関係者による請求書の承認が完了した状態です。会計処理と支払いスケジュールの設定に進めます。 | ||
|
重要な理由
承認プロセスが正常に完了したことを示す重要な節目です。この段階までの遅延は、よくあるボトルネックです。
入手先
AP_INVOICES_ALLテーブルのAPPROVAL_STATUSが「Approved」や「Workflow Approved」などの最終承認状態に変わったことから判断します。このフィールドの監査履歴からタイムスタンプを取得できます。
記録
AP_INVOICES_ALL.APPROVAL_STATUSが「Approved」に変わったことから判断します。
イベントタイプ
inferred
|
|||
|
請求書を承認に回す
|
設定された業務ルールに基づき、請求書を承認ワークフローに送信します。正式な承認サイクルの開始を示します。 | ||
|
重要な理由
プロセスの重要な段階が始まります。開始時刻を追跡することは、「請求書承認サイクルタイム」の測定と改善に欠かせません。
入手先
AP_INVOICES_ALLテーブルのステータス変更から判断します。APPROVAL_STATUSが「Initiated」や「Pending Approval」などに変わったことを確認します。ワークフローテーブルにもこのイベントが記録されている場合があります。
記録
AP_INVOICES_ALL.APPROVAL_STATUSが「Initiated」に変わったことから判断します。
イベントタイプ
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_HOLDS_ALLテーブルに明示的に記録されます。各行には、保留の作成日(HOLD_DATE)と理由が含まれます。
記録
AP_HOLDS_ALLテーブルにレコードが作成されたこと。
イベントタイプ
explicit
|
|||
|
請求書を修正
|
却下への対応や入力ミスの修正などで、担当者が請求書を変更したときに発生します。プロセスにおける手作業の手戻りを示します。 | ||
|
重要な理由
このアクティビティは、手戻りが発生したことを明確に示します。発生頻度を分析すると、プロセスの非効率さを測定し、「請求書手戻り率」の重要業績評価指標(KPI)の算出に役立ちます。
入手先
請求書の検証後または承認への送信後に、AP_INVOICES_ALLのレコードが大幅に更新されたことを追跡して判断できます。LAST_UPDATE_DATEのタイムスタンプと監査証跡データが必要です。
記録
却下または保留の後にLAST_UPDATE_DATEが更新されたかを比較して判断します。
イベントタイプ
inferred
|
|||
|
請求書を却下
|
承認ワークフロー中に承認者が請求書を却下した状態です。通常、請求書は修正または取り消しのために差し戻され、手戻りが発生します。 | ||
|
重要な理由
望ましくない結果であり、手戻りやサイクルタイムの増加につながる主な要因です。却下を追跡すると、請求書の品質や発注書(PO)への適合性に関する問題を特定できます。
入手先
AP_INVOICES_ALLテーブルのAPPROVAL_STATUSが「Rejected」に変わったことから判断します。ワークフロー履歴には、却下した担当者と日時の詳細が記録されます。
記録
AP_INVOICES_ALL.APPROVAL_STATUSが「Rejected」に変わったことから判断します。
イベントタイプ
inferred
|
|||
|
請求書を取り消す
|
請求書が無効化または取り消され、それ以降の処理や支払いが行われない状態です。プロセスの最終状態を示します。 | ||
|
重要な理由
支払いに至らない請求書の重要な終点です。取り消しを分析すると、請求書の重複や仕入先による誤った提出などの問題を明らかにできます。
入手先
AP_INVOICES_ALLのステータス変更から判断します。CANCELLED_DATE列には取り消しのタイムスタンプが記録されます。
記録
AP_INVOICES_ALLテーブルのCANCELLED_DATEフィールドに値が設定されていること。
イベントタイプ
explicit
|
|||
|
請求書を検証
|
請求書のヘッダー情報と明細情報が完全かつ正確であることを確認するシステム検証に合格した状態を示します。多くの場合、請求書レコードのステータス変更から判断できます。 | ||
|
重要な理由
照合と承認に進む前の重要な節目です。この段階で遅延が発生している場合、請求書データの品質やシステム設定に問題がある可能性があります。
入手先
AP_INVOICES_ALLテーブルの請求書ステータスが「Validated」に変わったことから判断します。VALIDATION_STATUS列の変更履歴や監査証跡を利用できます。
記録
AP_INVOICES_ALL.VALIDATION_STATUSフィールドの変更から判断します。
イベントタイプ
inferred
|
|||
データ抽出ガイド
始める準備はできましたか?
このテンプレートを使ってデータを準備し、請求書処理の改善に取り組みましょう。インサイトを得て、組織全体の業務効率を高めることができます。
P2Pの請求書処理を改善し、サイクルを30%短縮
Oracle Fusion Financialsのボトルネックを解消し、サイクルタイムを30%短縮します。
クレジットカードは不要です。数日で結果を確認できます。