買掛請求書処理のデータテンプレート
買掛請求書処理のデータテンプレート
- 収集を推奨する属性
- 追跡する主なアクティビティ
- データ抽出ガイド
買掛請求書処理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
請求書
Invoice
|
仕入先請求書ごとに付与される一意の識別子です。 | ||
|
説明
請求書は主要なケース識別子として機能し、受領から最終的な支払いまでのすべてのアクティビティを関連付けます。これにより、買掛金プロセスにおける個々の請求書の流れを最初から最後まで分析できます。 分析では、この識別子でイベントをグループ化することが、請求書ごとのプロセスフローを再構築する第一歩です。ケース単位の合計サイクルタイムなどの重要業績評価指標(KPI)を算出できるほか、個々の請求書の流れに特有のバリアントやボトルネックを特定できます。
重要な理由
請求書のライフサイクル全体を追跡するための重要なキーであり、買掛金のプロセスマイニング分析の基盤となります。
入手先
通常は、Dynamics 365 Financeの「仕入先請求書」ページ、または関連するデータエンティティにある仕入先請求書番号です。
例
INV-00125475000921DE-8832-2023
|
|||
|
アクティビティ
ActivityName
|
実行された業務プロセスのステップ名です。 | ||
|
説明
この属性には、請求書の登録や承認など、特定の時点で発生した操作やイベントが記録されます。これらのアクティビティが、検出されたプロセスマップのノードになります。 アクティビティの順序や頻度の分析は、プロセスマイニングの基本です。プロセスフローを可視化し、よくある経路とまれな経路(バリアント)を特定できるほか、遅延や手戻りの原因となるアクティビティを見つけられます。
重要な理由
アクティビティによってプロセスで何が行われたかが明らかになり、プロセスマップの作成や、プロセスフローとその変化の分析が可能になります。
入手先
通常は、Dynamics 365の買掛金モジュールにあるステータス変更、ワークフロー履歴ログ、または文書の転記記録から取得します。
例
請求書を登録請求書を承認不一致を解消支払いを実行
|
|||
|
開始時刻
EventTime
|
アクティビティまたはイベントが発生した日時を示すタイムスタンプです。 | ||
|
説明
この属性には各アクティビティの日付と時刻が記録され、イベントを時系列に並べたり、所要時間を算出したりするために欠かせません。イベントログの時間情報の基盤となります。 分析では、開始時刻を使って、アクティビティ間のサイクルタイム、待ち時間、ケース全体の所要時間など、時間に関するすべての指標を算出します。ボトルネックの特定や、SLAに対するプロセスのパフォーマンス測定にも欠かせません。
重要な理由
イベントを正しい順序に並べ、サイクルタイムやボトルネックなどのパフォーマンス指標を算出するうえで、このタイムスタンプは欠かせません。
入手先
Dynamics 365の取引レコードにある作成日や変更日、ワークフロー履歴ログ、または転記日のフィールドから取得します。
例
2023-04-15T09:00:12Z2023-04-18T14:35:00Z2023-05-02T11:21:45Z
|
|||
|
ユーザー
UserName
|
アクティビティを実行したユーザーです。 | ||
|
説明
請求書の登録や承認など、プロセスのステップを完了したユーザーを特定します。通常は、Dynamics 365のユーザーシステムIDに関連付けられています。 ユーザー別にパフォーマンスを分析すると、トレーニングの必要性、優れた実績、業務負荷の分布を把握できます。承認時間やリソース効率に注目するダッシュボードにも欠かせません。どのユーザーやチームがボトルネックになっているかを確認できます。
重要な理由
作業を個人に関連付けることで、業務負荷やパフォーマンスを分析し、トレーニングの機会を特定できます。
入手先
通常は、取引の「作成者」または「変更者」フィールド、あるいはDynamics 365のワークフロー履歴ログから取得します。
例
j.doea.smithr.williams
|
|||
|
仕入先
VendorName
|
請求書を提出した供給業者または仕入先の名前です。 | ||
|
説明
この属性は、請求書に関連付けられた仕入先を特定します。仕入先データには通常、名前、ID、カテゴリなどが含まれます。 仕入先別に買掛金プロセスを分析すると、不一致の多い請求書を繰り返し提出する仕入先、特別な支払条件がある仕入先、処理に時間がかかる仕入先を把握できます。こうした情報は、仕入先との関係や連携の改善に役立ちます。
重要な理由
仕入先ごとにプロセスを分けて分析でき、不一致の頻発や支払いの遅延など、仕入先固有の問題を特定できます。
入手先
仕入先請求書のヘッダーから関連付けます。通常は、仕入先勘定番号を基に「VendTable」データエンティティから取得します。
例
Contoso LtdFabrikam IncNorthwind Traders
|
|||
|
支払条件
PaymentTerms
|
仕入先と合意した請求書の支払条件です。 | ||
|
説明
この属性は、仕入先請求書の支払い条件を定義します。たとえば、「Net 30」は30日以内の支払い、「2/10 Net 30」は10日以内に支払うと2%割引、そうでない場合は30日以内の支払いを意味します。 支払条件別の分析により、契約内容が支払いの適時性やキャッシュフローに与える影響を把握できます。早期支払割引の機会を特定する基準となるほか、特定の条件が守りにくいかどうかを確認するため、コンプライアンス分析を条件別に分けることもできます。
重要な理由
支払期限と割引の機会を定め、キャッシュフロー管理やコスト削減に直接影響します。
入手先
仕入先マスターデータ、または発注書や請求書のヘッダーに記載されています。「PaymTermId」などのフィールドに格納されています。
例
Net 30Net 602/10 Net 30
|
|||
|
発注書番号
PurchaseOrderNumber
|
請求書に関連付けられた発注書の一意の識別子です。 | ||
|
説明
この属性は、請求書と対応する発注書(PO)を関連付けます。請求書には、発注書に基づくものと、発注書に基づかないものがあります。 この属性を分析すると、異なるワークフローに従うことが多い、発注書に基づく請求書とそうでない請求書を区別できます。発注書との照合効率の測定や、請求書の詳細が発注書と一致しない場合に生じる問題の特定にも欠かせません。
重要な理由
異なるプロセスに従う、発注書に基づく請求書とそうでない請求書を区別でき、照合効率の分析に欠かせません。
入手先
仕入先請求書のヘッダーまたは明細にあり、通常は「VendInvoiceInfoTable」の「PurchId」というフィールドに格納されています。
例
PO-000432PO-000511
|
|||
|
請求書の支払期日
InvoiceDueDate
|
支払条件に基づいて算出される、請求書の支払期限です。 | ||
|
説明
この日付は、違約金を避け、仕入先との契約を守るための請求書の支払期限を示します。通常、請求日と指定された支払条件に基づいて算出されます。 「支払条件のコンプライアンス」分析に欠かせない属性です。「支払い実行日」と「請求書の支払期日」を比較することで、支払い遅延を自動的に検出し、コンプライアンス率を算出できます。仕入先との良好な関係を保つため、支払いの優先順位付けにも役立ちます。
重要な理由
期日どおりの支払い状況の測定、仕入先との関係管理、延滞料金の回避に欠かせません。
入手先
請求日と支払条件に基づく計算フィールドです。「VendTrans」などの仕入先取引テーブルにある「DueDate」などのフィールドに格納されています。
例
2023-05-152023-06-302023-07-01
|
|||
|
請求金額
InvoiceAmount
|
請求書の合計金額です。 | ||
|
説明
仕入先請求書の支払総額を示します。ケースごとの重要な財務指標です。 この属性を使って、買掛金プロセスを財務面から分析できます。高額請求書の優先順位付け、金額のしきい値に応じた承認時間の分析、支払い遅延や早期支払割引が財務に与える影響の把握に役立ちます。
重要な理由
金額に応じたプロセスの違いを分析するための財務情報が得られ、高額請求書が異なる方法で処理されているかどうかを特定できます。
入手先
仕入先請求書のヘッダーにあり、「VendInvoiceInfoTable」の「InvoiceAmount」などのフィールドに格納されています。
例
1500.75250.0012345.50
|
|||
|
ソースシステム
SourceSystem
|
データの抽出元となるシステムです。 | ||
|
説明
この属性はイベントデータの取得元を示します。この場合、通常は「Microsoft Dynamics 365」です。OCRスキャンツールやD365など、複数のシステムのデータを組み合わせる場合に特に重要です。 プロセスマイニング分析では、データの来歴確認、問題の調査、プロセスを支えるシステム環境の把握に役立ちます。特定のシステムからのイベントに絞って分析することもできます。
重要な理由
データの取得元を把握できるため、データ検証や複数システムにまたがるプロセス分析に欠かせないコンテキストが得られます。
入手先
通常は、データの抽出・変換時に設定される固定値(「Microsoft Dynamics 365」)です。
例
Microsoft Dynamics 365 FinanceD365 F&OAX2012
|
|||
|
不一致の理由
DiscrepancyReason
|
請求書の不一致に関する理由コードまたは説明です。 | ||
|
説明
請求書が保留された場合や不一致が見つかった場合に、この属性に理由が記録されます。「価格の不一致」「数量の差異」「入庫記録の欠落」などがあります。 「不一致の解消と手戻り」分析の要となる属性です。理由別に手戻りを分類すると、プロセスの非効率を招く根本原因を特定できます。たとえば、「価格の不一致」が最も多い場合、購買部門と仕入先の間でデータをより正確に一致させる必要があると分かります。
重要な理由
手戻りの根本原因を把握でき、例外や手作業を減らすための的を絞ったプロセス改善につながります。
入手先
買掛金モジュールの請求書保留テーブル、ワークフローのコメント、または不一致記録用のフィールドに格納されている場合があります。
例
価格の不一致数量の差異無効な発注書
|
|||
|
会社コード
CompanyCode
|
請求書を処理する法人の識別子です。 | ||
|
説明
この属性は、組織内で請求書を担当する会社または法人を特定します。複数の会社を運営する場合、重要な組織上の区分となります。 会社コード別に買掛金プロセスを分析すると、事業部門や法人間でパフォーマンスを比較できます。効率の低い法人、手戻り率の高い法人、異なるプロセスのバリアントに従う法人を特定し、標準化やベストプラクティスの共有につなげられます。
重要な理由
組織内の法人や事業部門間で、パフォーマンスの比較やプロセスの比較分析ができます。
入手先
Dynamics 365のほぼすべての取引テーブルにある標準フィールドで、通常は「DataAreaId」という名前です。
例
USMFDEMFGBSI
|
|||
|
入庫番号
GoodsReceiptNumber
|
請求書に関連する入庫文書の識別子です。 | ||
|
説明
この属性は、請求書と受領した商品またはサービスの記録を関連付けます。発注書、入庫、請求書の3点照合に必要です。 プロセスの照合効率を分析するうえで欠かせません。「入庫との照合」アクティビティの遅延や失敗を調べる際、この識別子を使って元の入庫文書を追跡できます。買掛金に影響する調達や受領の段階の問題を特定するのに役立ちます。
重要な理由
3点照合の効率を分析し、商品の受領プロセスに起因する問題を特定できます。
入手先
発注書の明細を介して関連付けます。通常は、納品書仕訳(「VendPackingSlipJour」)または関連テーブルから取得します。
例
GRN-00981GRN-01024
|
|||
|
最終データ更新日時
LastDataUpdate
|
ソースシステムからデータを最後に更新した日時です。 | ||
|
説明
この属性は、Microsoft Dynamics 365から新しいデータを取得してイベントログを最後に更新した日時を示します。分析対象データがどの程度新しいかを把握するための情報です。 ダッシュボードや継続的なモニタリングでは、最新のプロセスデータが表示されているかを確認するうえで、このタイムスタンプが重要です。データの鮮度に関する認識をそろえ、データパイプラインの状態を監視するのにも役立ちます。
重要な理由
データがどの程度新しいかを把握できるため、分析に基づいて適切なタイミングで正確な業務判断を行えます。
入手先
データ取り込み時に、データ抽出・読み込み(ETL)ツールが生成して記録するメタデータフィールドです。
例
2023-06-01T02:00:00Z2023-06-02T02:00:00Z
|
|||
|
割引適用期限
EarlyPaymentDiscountDate
|
早期支払割引を受けるための請求書の支払期限です。 | ||
|
説明
この属性は、仕入先の割引を受けるために請求書を支払う最終日を示します。請求日と支払条件の割引部分(「2/10 Net 30」の「10」など)に基づいて算出されます。 「早期支払割引の状況」分析の基準となる日付です。「支払予定日」または「支払い実行日」とこの期限を比較すると、割引を適用できたかどうかを判定でき、財務面の改善状況を明確な指標で確認できます。
重要な理由
コスト削減につながる割引の適用期限を定めるため、支払いの優先順位付けや効率改善の基準となります。
入手先
支払条件と請求日に基づいてシステムが算出します。「VendTrans」の「CashDiscDate」などのフィールドに格納されています。
例
2023-04-252023-05-102023-06-15
|
|||
|
手戻りの有無
IsRework
|
請求書に手戻りが発生したかどうかを示す計算フラグです。 | ||
|
説明
この真偽値フラグは、「不一致を解消」などの手戻りアクティビティがプロセスフローに含まれる場合や、最初の検証失敗後に「請求書データを検証」するステップが再度行われた場合にtrueになります。ケース全体を対象に算出されます。 この属性は「不一致による手戻り率」の重要業績評価指標(KPI)に直接役立ちます。追加の手作業が必要だった請求書を簡単に絞り込み、集計できるため、データ品質の低さやプロセス上の例外が与える影響を把握できます。
重要な理由
手戻りを直接測定できるため、プロセス上の例外や非効率の規模を簡単に把握し、分析できます。
入手先
ソースシステムのフィールドではありません。プロセスマイニングツールで、ケース内に手戻りを示す特定のアクティビティが発生したかどうかを確認して算出します。
例
truefalse
|
|||
|
承認者
ApproverName
|
特定のステップで請求書を承認または却下したユーザーです。 | ||
|
説明
この属性は、ワークフローで承認を判断した担当者を特定します。複数段階の承認が必要な請求書では、ステップごとに承認者が異なる場合があります。 「請求書の承認サイクルタイム分析」ダッシュボードに欠かせません。承認者別に分析すると、業務負荷などの要因によりプロセスのボトルネックとなっている担当者を特定できます。対象を絞った対策を講じ、承認サイクルの短縮につなげられます。
重要な理由
承認プロセスを詳しく分析し、個人やチーム単位のボトルネックを特定できます。
入手先
各承認ステップを完了したユーザーが記録されるワークフロー履歴ログ(「WorkflowTrackingStatusTable」)から取得します。
例
David ChenMaria GarciaAP_Manager_Group
|
|||
|
支払い遅延の有無
IsLatePayment
|
支払期日を過ぎて支払いが行われたかどうかを示す計算フラグです。 | ||
|
説明
「支払い実行」アクティビティが「請求書の支払期日」より後に発生した場合、この真偽値属性はtrueになります。支払条件が守られなかったケースを明確に示します。 この属性を使うと、「支払条件のコンプライアンス率」の重要業績評価指標(KPI)を簡単に算出できます。支払い遅延の件数や金額をすばやく絞り込んでダッシュボードに表示できるほか、対象ケースの根本原因を分析し、遅延の理由を把握できます。
重要な理由
支払条件が守られなかったケースを明確に示し、期日どおりの支払いに関する重要業績評価指標(KPI)の算出に役立ちます。
入手先
ソースシステムのフィールドではありません。プロセスマイニングツールで、「支払い実行」アクティビティのタイムスタンプと「InvoiceDueDate」属性を比較して算出します。
例
truefalse
|
|||
|
早期支払割引額
EarlyPaymentDiscountAmount
|
請求書を早期に支払った場合に適用される割引額です。 | ||
|
説明
この属性は、支払条件に基づいて仕入先が提示する早期支払割引の金額を示します。 この財務データは「早期支払割引の状況」ダッシュボードに欠かせません。適用できた割引と適用できなかった割引の金額を把握でき、請求書の承認や支払予定の作成を効率化する明確な財務上の動機になります。
重要な理由
プロセスの効率化による財務上の効果を金額で示し、プロセスのパフォーマンスとコスト削減を直接結び付けます。
入手先
請求金額と支払条件に基づく計算フィールドです。「VendTrans」などのテーブルや、関連する現金割引フィールドから取得できます。
例
30.015.00246.91
|
|||
|
自動処理かどうか
IsAutomated
|
アクティビティがシステムによって自動実行されたかどうかを示すフラグです。 | ||
|
説明
この真偽値属性は、ユーザーが実行したアクティビティと、請求書の自動転記や照合など、システムが自動実行したアクティビティを区別します。 この属性の分析は、買掛金プロセスの自動化率を測定するうえで重要です。ストレートスルー処理(STP)率の算出や、今後の自動化の候補となる手作業の特定に役立ち、最終的にはコストと処理時間の削減につながります。
重要な理由
ストレートスルー処理率の測定や、自動化と効率化の機会の特定に役立ちます。
入手先
アクティビティに関連付けられたユーザーがシステムユーザーまたはバッチユーザー(「Admin」「BatchUser」など)かどうかを確認して判定します。
例
truefalse
|
|||
|
請求書のステータス
InvoiceStatus
|
請求書の現在の処理状況です。 | ||
|
説明
この属性は、請求書のプロセスにおける最終確認時点の状態を示します。「処理中」「承認済み」「支払済み」「キャンセル済み」などがあります。請求書のライフサイクルにおける現在の位置を把握できます。 プロセスマイニングではアクティビティからフローを導き出しますが、最終ステータスは検証や、未処理の請求書の現在の状態をまとめる業務向けダッシュボードの作成に役立ちます。「承認済み」だが「支払済み」ではない請求書に絞り込むこともできます。
重要な理由
請求書の現在の状態を大まかに把握でき、ステータスによる絞り込みやダッシュボードの作成に役立ちます。
入手先
通常は、買掛金モジュールの文書ステータスまたはワークフローステータスのフィールドから取得します。
例
処理中承認済み支払済みキャンセル済み
|
|||
買掛請求書処理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
支払いを実行
|
支払い仕訳帳の転記によって、正式に支払いが行われます。この取引により、転記済み請求書によって発生した債務が決済されます。 | ||
|
重要な理由
このアクティビティは、プロセスの主な終了イベントです。支払条件の遵守状況や支払い遅延の特定、エンドツーエンドの最終的なサイクルタイムの測定に使われます。
入手先
支払い仕訳帳の転記時に明示的に記録されるイベントです。決済の詳細は仕入先取引テーブル(VendTrans)に保存され、支払いと請求書が関連付けられます。
記録
VendTransの支払い決済レコードにある取引日を使用します。
イベントタイプ
explicit
|
|||
|
請求書を承認
|
ワークフローで最終承認され、請求書を支払いのために転記できる状態になったことを示します。請求書が支払い段階に進む前の重要な節目です。 | ||
|
重要な理由
承認サイクルの終了を示します。「承認申請」からこのアクティビティまでの時間は、承認のボトルネックや長期化するワークフローを特定するための重要業績評価指標です。
入手先
ワークフローのステータスが「完了」または「承認済み」に更新された際に、ワークフロー履歴ログ(WorkflowTrackingStatusTable)に明示的に記録されるイベントです。
記録
ワークフロー追跡履歴から、請求書の「承認済み」または「完了」イベントを抽出します。
イベントタイプ
explicit
|
|||
|
請求書を承認に申請
|
請求書が、権限を持つ担当者による確認と承認のため、正式にワークフローへ送信されます。ここから承認サイクルが始まります。 | ||
|
重要な理由
この重要な節目を起点に、請求書の承認サイクルタイムを測定します。データ入力や照合にかかった時間と、承認待ちの時間を区別するのに役立ちます。
入手先
特定の請求書文書について、D365のワークフロー履歴ログ(WorkflowTrackingStatusTable)に明示的に記録されるイベントです。申請のタイムスタンプが記録されます。
記録
ワークフロー追跡履歴から、請求書の「申請済み」イベントを抽出します。
イベントタイプ
explicit
|
|||
|
請求書を登録
|
手入力、OCRスキャン、または電子データ交換(EDI)によって、システムに請求書レコードが最初に作成されたことを示します。請求書処理のライフサイクルはここから始まります。 | ||
|
重要な理由
このアクティビティは、プロセスの主な開始イベントです。この時点から支払いまでの時間を分析すると、請求書の全体的なサイクルタイムを把握できます。これは重要業績評価指標の1つです。
入手先
保留中の仕入先請求書テーブルや請求書仕訳帳テーブル(VendInvoiceInfoTableなど)にある請求書ヘッダーレコードの作成タイムスタンプ(CreatedDateTimeフィールド)から推定します。
記録
請求書ヘッダーレコードの作成タイムスタンプを使用します。
イベントタイプ
inferred
|
|||
|
請求書を転記
|
承認済みの請求書が総勘定元帳に正式に記録され、財務上の債務が発生します。これは重要で、多くの場合、取り消しが難しい会計取引です。 | ||
|
重要な理由
転記は、請求書が支払い対象となる重要な節目です。すべての検証と承認が完了し、債務が認識されたことを示します。
入手先
明示的に記録される取引です。仕入先請求書仕訳帳(VendInvoiceJour)と関連する総勘定元帳エントリ(GeneralJournalEntry)に、転記日時が記録されます。
記録
VendInvoiceJourまたはGeneralJournalEntryテーブルの転記タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
不一致を特定
|
請求書が検証に失敗した場合、または発注書や入庫記録との照合ができず、手作業での対応が必要になった場合に発生します。請求書が保留になったり、特定のステータスが設定されたりすることがあります。 | ||
|
重要な理由
このアクティビティをきっかけに、やり直しが発生します。頻度と原因を分析することは、プロセスの非効率、データ品質の問題、取引先に関する問題を特定するうえで重要です。
入手先
請求書の履歴に明示的に記録される場合と、照合差異に関する理由コードとともに請求書が「保留」に設定されたことから推定する場合があります。請求書ヘッダーのステータス変更を確認します。
記録
請求書のステータスが「保留」に設定された時刻、または不一致フラグが設定された時刻を記録します。
イベントタイプ
inferred
|
|||
|
不一致を解消
|
不一致の特定後に保留を解除する、または請求書を修正するために行う対応です。請求書は照合または承認に再申請できる状態になります。 | ||
|
重要な理由
このアクティビティで、やり直しの一連の流れが終了します。不一致の解消にかかる時間は、例外処理の効率を示す重要な指標です。
入手先
請求書の「保留」ステータスが解除された時刻、または却下後に請求書がワークフローへ再申請された時刻から推定します。
記録
保留が解除された時刻、または却下後に請求書が再申請された時刻を記録します。
イベントタイプ
inferred
|
|||
|
入庫記録と照合
|
3点照合では、入庫記録と照らし合わせ、請求対象の商品やサービスが受領済みであることを確認します。請求書の内容と実際の納品を照合する工程です。 | ||
|
重要な理由
このアクティビティを追跡すると、3点照合の効率を分析し、入庫情報の欠落や誤りによる遅延を特定できます。
入手先
発注書との照合と同様に、商品受領仕訳帳(Packing Slips)との照合が成功したことを示す請求書のステータス更新から推定します。
記録
3点照合の成功を示すステータス変更やフラグを確認します。
イベントタイプ
inferred
|
|||
|
支払いの決済を確認
|
銀行照合によって、会社が実行した支払いが銀行で決済されたことを確認します。支払い完了を示す最終的な財務上の確認です。 | ||
|
重要な理由
このアクティビティで、資金流出が最終的に確認されます。支払いの実行から銀行での決済までにかかる時間は、財務や資金管理の観点から重要です。
入手先
銀行照合モジュールの情報から取得します。支払いに対応する銀行明細行がD365で照合され、転記された時点から推定します。
記録
銀行取引データ(BankStmtISOAccountStatement)を元の支払いに関連付ける必要があります。
イベントタイプ
inferred
|
|||
|
支払いを予定
|
転記済みの請求書が支払い提案または支払い仕訳帳に選択され、今後の支払い処理に組み込まれます。支払う意図が示されます。 | ||
|
重要な理由
このアクティビティは、キャッシュフロー予測と支払条件の遵守状況の分析に欠かせません。早期支払い割引が考慮され、予定されているかどうかも確認できます。
入手先
請求書を含む支払い仕訳帳明細(LedgerJournalTrans)の作成から推定します。仕訳帳明細の取引日は、予定された支払日を示します。
記録
請求書を参照する支払い仕訳帳明細の作成日を使用します。
イベントタイプ
inferred
|
|||
|
発注書と照合
|
請求書を1つ以上の発注書と関連付け、数量、価格、条件を確認するプロセスです。発注書に基づく請求書の重要な検証工程です。 | ||
|
重要な理由
このアクティビティは、初回照合率の測定や照合プロセスのボトルネック特定に欠かせません。ここで照合に失敗すると、不一致の解消を繰り返すことがよくあります。
入手先
請求書レコードの照合ステータスが「照合済み」に更新された時点、または明細レベルの照合情報が正常に保存された時点から推定できます。通常、この情報は仕入先請求書明細に関連するテーブルに保存されています。
記録
発注書との照合が成功したことを示す、請求書ヘッダーまたは明細のステータス変更を特定します。
イベントタイプ
inferred
|
|||
|
請求書データを検証
|
照合や承認の前に、システムまたは担当者が取り込んだ請求書データの完全性と正確性を初期確認することを示します。システムによる自動検証の場合も、担当者による確認の場合もあります。 | ||
|
重要な理由
このアクティビティを追跡すると、データ品質の低さによる遅延を特定できます。失敗率が高い、または所要時間が長い場合は、OCRの精度など、データ取り込みプロセスに問題がある可能性があります。
入手先
多くの場合、推定イベントです。請求書のステータスが「新規」または「下書き」から「検証済み」や「照合準備完了」などに変わった時刻、またはワークフローへの送信前に最後に更新された時刻から特定できます。
記録
検証の成功を示すステータス変更、またはワークフローへの送信前の更新イベントのタイムスタンプを記録します。
イベントタイプ
inferred
|
|||
|
請求書を却下
|
承認者がワークフロー内で請求書を却下し、通常は修正や確認のために申請者へ差し戻します。これにより、やり直しが発生します。 | ||
|
重要な理由
却下を追跡すると、承認の遅れややり直しの原因を特定できます。請求書の勘定科目コード、ポリシー違反、文書の不足などの問題が明らかになることがあります。
入手先
承認者が「却下」アクションを選択した際に、ワークフロー履歴(WorkflowTrackingStatusTable)に明示的に記録されるイベントです。
記録
ワークフロー追跡履歴から、請求書の「却下」イベントを抽出します。
イベントタイプ
explicit
|
|||
|
請求書を取り消し
|
通常は誤りを修正するため、転記後の請求書を無効化または取り消します。プロセスにおける例外的な終了経路です。 | ||
|
重要な理由
取り消しを追跡すると、プロセスの品質やエラー率を把握できます。取り消しが頻繁に発生する場合、前工程に構造的な問題がある可能性があります。
入手先
明示的に記録されるイベントです。D365では、元の請求書仕訳帳に関連付けられた取消仕訳または貸方取引が作成されます。この取消処理の転記日が、取り消しの時点を示します。
記録
元の請求書に関連する取消取引の転記日を特定する
イベントタイプ
explicit
|
|||
データ抽出ガイド
始める準備はできましたか?
このデータテンプレートを使って、買掛請求書処理の効率化に取り組みましょう。プロセスデータから改善点を見つけ、業務の大幅な改善につなげられます。
二重払いを防ぎ、買掛請求書処理を改善
非効率な箇所を特定し、延滞料金をなくして、処理コストを60%削減します。
14日間無料でお試しいただけます。クレジットカードは不要です。