データテンプレート:買掛金の請求書処理
買掛金(AP)請求書処理用データテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- 抽出の手引き
買掛金の請求書処理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
請求書
Invoice
|
各ベンダー請求書ドキュメントの一意の識別子。 | ||
|
説明
請求書IDは主要な case 識別子として機能し、請求書の受領から最終支払いまでの全アクティビティをひとつに結び付けます。これにより、買掛金(AP)プロセスを請求書ごとにエンドツーエンドで分析できます。 分析では、この識別子で event をグループ化することが、請求書ごとのプロセスフローを復元する第一歩です。案件(case)単位の KPI(総サイクルタイムなど)の算出や、請求書ごとのバリアントやボトルネックの特定に役立ちます。
その重要性
請求書のライフサイクル全体を追跡するための中核キーであり、AP におけるあらゆる Process Mining 分析の土台となります。
取得元
一般的には、Dynamics 365 Finance の 'Vendor invoice' ページまたは関連データエンティティにある Vendor Invoice Number を指します。
例
INV-00125475000921DE-8832-2023
|
|||
|
アクティビティ
ActivityName
|
実行された業務プロセスのステップ名。 | ||
|
説明
この属性は、請求書に対してその時点で発生した具体的なアクションやイベント(例: 'Invoice Registered'、'Invoice Approved')を記録します。これらのアクティビティが、発見されたプロセスマップのノードになります。 アクティビティの順序と頻度の分析はProcess Miningの土台です。プロセスフローを可視化し、一般的な経路と稀なバリアントを見分け、遅延や手戻りの原因となるアクティビティを特定できます。
その重要性
アクティビティはプロセスの「何を」を定義し、プロセスマップの作成やプロセスの流れとばらつきの分析を可能にします。
取得元
これは、Dynamics 365 の AP モジュール内におけるステータス変更、workflow 履歴、ドキュメントの転記記録などから導出されることが多い項目です。
例
請求書登録請求書承認済み不一致を解消支払い実行
|
|||
|
開始時刻
EventTime
|
アクティビティ/event の発生時刻を示すタイムスタンプ。 | ||
|
説明
この属性は各アクティビティの日時を持ち、時系列の並び替えや所要時間の算出に用います。イベントログの時間軸の基盤となる情報です。 分析では、Start Timeを基にアクティビティ間のサイクルタイム、待ち時間、ケース全体の所要時間などの時間指標を算出します。ボトルネックの特定やSLAに対するパフォーマンス測定に不可欠です。
その重要性
このタイムスタンプは、イベントの正しい時系列整列や、サイクルタイムやボトルネックなど各種パフォーマンス指標の算出に不可欠です。
取得元
トランザクションレコードの作成日・更新日、workflow の履歴ログ、または Dynamics 365 の計上日フィールドから取得します。
例
2023-04-15T09:00:12Z2023-04-18T14:35:00Z2023-05-02T11:21:45Z
|
|||
|
User
UserName
|
そのアクティビティを実行したユーザー。 | ||
|
説明
特定の処理ステップ(請求書の登録や承認など)を完了した担当ユーザーを特定します。多くの場合、Dynamics 365 のユーザーIDと紐づいています。 ユーザー別のパフォーマンス分析により、教育の必要性やハイパフォーマー、業務負荷の偏りを把握できます。承認時間やリソース効率に焦点を当てたダッシュボードには不可欠で、どのユーザー/チームがボトルネックかを明確にします。
その重要性
作業を担当者ごとに紐づけることで、業務負荷やパフォーマンスの分析、教育・トレーニング機会の特定が可能になります。
取得元
取引の 'Created by' または 'Modified by' フィールド、あるいは Dynamics 365 の workflow 履歴から取得するのが一般的です。
例
j.doea.smithr.williams
|
|||
|
Vendor
VendorName
|
請求書の発行元である仕入先/ベンダー名。 | ||
|
説明
この属性は、請求書に紐づく仕入先(ベンダー)を示します。仕入先データには名称、ID、カテゴリなどが含まれます。 仕入先別にAPプロセスを分析すると、差異が頻発する請求書を出す仕入先、特別な支払条件を持つ仕入先、処理時間が長くなりがちな仕入先が分かります。こうした洞察は、仕入先との関係や協働の改善に役立ちます。
その重要性
仕入先別にプロセスを分け、頻発する不一致や支払遅延などの仕入先特有の課題を特定できます。
取得元
ベンダー請求書ヘッダーからリンクされます。通常はベンダーアカウント番号に基づいて '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)の一意の識別子。 | ||
|
説明
この属性は、請求書を対応する発注書(PO)に紐づけます。請求書には、POベースと非POベースがあります。 この属性を分析すると、POベースと非POベースで処理がどう違うか(異なるワークフロー)を切り分けられます。POとの突合の効率を測定したり、請求書の明細が発注内容と一致しないことで生じる問題を特定するうえで不可欠です。
その重要性
PO あり/なしの請求書を区別します。プロセスが異なるため、照合効率の分析に不可欠です。
取得元
仕入先請求書のヘッダーまたは明細にあり、通常は 'VendInvoiceInfoTable' の 'PurchId' フィールドに格納されています。
例
PO-000432PO-000511
|
|||
|
請求書の支払期日
InvoiceDueDate
|
支払条件に基づいて算出された、請求書の支払期日。 | ||
|
説明
この日付は、違約金を回避し仕入先との合意を守るための請求書の支払期限を示します。通常、請求書日付と定められた支払条件から計算されます。 'Payment Terms Compliance' 分析に不可欠な属性です。'Payment Executed' と 'Invoice Due Date' を比較することで、遅延支払いを自動でフラグ付けし、遵守率を算出し、良好な仕入先関係を維持するための支払の優先順位付けに活かせます。
その重要性
期日内の支払達成度を測定し、仕入先との関係を適切に管理し、延滞手数料を回避するうえで不可欠です。
取得元
請求書日付と支払条件に基づく計算フィールドです。仕入先取引テーブル(例:'VendTrans')の 'DueDate' などに保存されます。
例
2023-05-152023-06-302023-07-01
|
|||
|
請求金額
InvoiceAmount
|
請求書の合計金額。 | ||
|
説明
仕入先請求書の支払総額を表します。各ケースにとって重要な財務指標です。 この属性により、AP プロセスの財務分析が可能になります。高額請求書の優先順位付け、金額しきい値に応じた承認時間の分析、支払い遅延や早期支払い割引の財務インパクトの把握などに活用できます。
その重要性
金額に基づくプロセス挙動の分析を可能にする財務的な文脈を付与します。たとえば高額請求書が異なる流れで処理されていないかを見極めるのに使えます。
取得元
ベンダー請求書ヘッダー内にあります。例として 'VendInvoiceInfoTable' の 'InvoiceAmount' フィールドなど。
例
1500.75250.0012345.50
|
|||
|
ソースシステム
SourceSystem
|
データを抽出した元システム。 | ||
|
説明
この属性は event data の発生元を示します。この文脈では通常 'Microsoft Dynamics 365' です。複数システム(例:OCRスキャンツールとD365)のデータを統合する場合に特に重要になります。 Process Mining の分析では、データの来歴の把握、トラブルシューティング、プロセスの技術構成の理解に役立ちます。特定のシステム由来の event に絞って分析することも可能になります。
その重要性
データの出所に関する重要なコンテキストを提供します。データ検証や、複数システムにまたがるプロセス分析に不可欠です。
取得元
通常はデータ抽出・変換の過程で付与される固定値('Microsoft Dynamics 365')です。
例
Microsoft Dynamics 365 FinanceD365 F&OAX2012
|
|||
|
不一致理由
DiscrepancyReason
|
請求書の不一致に対する理由コード/説明。 | ||
|
説明
請求書が保留になったり差異が見つかった際、その理由を記録する属性です。例:「価格不一致」「数量差」「検収記録なし」など。 この属性は「差異解消と手戻りの分析」の中核です。理由ごとに手戻りを分類することで、プロセスの非効率を生む根本原因を特定できます。たとえば「価格不一致」が最も多いなら、購買と仕入先の間のデータ整合性を見直す必要があるサインです。
その重要性
手戻りの根本原因を示し、例外や手作業を減らすための的確なプロセス改善につなげます。
取得元
AP モジュール内の請求書保留テーブル、workflow コメント、差異記録用フィールドなどに保存されている場合があります。
例
価格不一致数量差異無効なPO
|
|||
|
会社コード
CompanyCode
|
請求書を処理する法的主体(会社)の識別子。 | ||
|
説明
この属性は、組織内でその請求書を担当する会社コード(Company Code)または法人(Legal Entity)を示します。マルチカンパニー環境では非常に重要な切り口です。 会社コード別に買掛金(AP)プロセスを分析すると、事業部や法人間のパフォーマンス比較ができます。効率の低い組織、手戻り率の高い組織、異なるプロセスバリアントが存在する組織を可視化でき、標準化やベストプラクティスの展開につながります。
その重要性
組織内の異なる法的エンティティや事業部門間で、パフォーマンスのベンチマークやプロセス比較ができます。
取得元
Dynamics 365のほぼすべてのトランザクションテーブルにある標準フィールド。一般に 'DataAreaId' という名前です。
例
USMFDEMFGBSI
|
|||
|
入荷伝票番号
GoodsReceiptNumber
|
請求書に関連する入荷受領伝票の識別子。 | ||
|
説明
この属性は、請求書を対応する受入記録(品目・サービス)に紐づけます。これは三点照合(PO・Goods Receipt・Invoice)に必要です。 突合効率を分析するうえで不可欠な情報です。'Goods Receipt Matched' の遅延や失敗があれば、この識別子で元の受入ドキュメントまで遡り、調達や受入の工程で発生した、買掛金に影響する問題を特定できます。
その重要性
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')から算出されます。 この日付は 'Early Payment Discount Status' 分析の主要な基準です。'Payment Scheduled' や 'Payment Executed' の日付とこの期限を比較し、割引を獲得できたかどうかを判定して、財務最適化の指標を明確にします。
その重要性
コスト削減を実現するための目標日を示し、支払の優先順位付けや効率化を促す重要な指標となります。
取得元
支払条件と請求書日付に基づきシステムが計算します。'VendTrans' の 'CashDiscDate' などに保存されます。
例
2023-04-252023-05-102023-06-15
|
|||
|
延滞
IsLatePayment
|
支払いが期日超過だったかを示す計算フラグ。 | ||
|
説明
このboolean属性は、'Payment Executed' が 'Invoice Due Date' を過ぎて発生した場合に true になります。支払条件の不遵守をケース単位で明確に示します。 この属性により、'Payment Terms Compliance Rate' KPIの算出が容易になります。遅延支払いの件数・金額をフィルタやダッシュボードで素早く可視化でき、これらのケースの遅延理由に対する根本原因分析にも活用できます。
その重要性
規定外の支払いの分析やオンタイム支払い KPI の算出に使える、シンプルでわかりやすいフラグです。
取得元
これはソースシステムの項目ではありません。'Payment Executed' アクティビティのタイムスタンプと 'InvoiceDueDate' 属性を比較し、Process Mining ツールで算出します。
例
truefalse
|
|||
|
手戻り
IsRework
|
請求書に手戻り(再作業)が発生したかを判定する計算フラグ。 | ||
|
説明
このbooleanフラグは、プロセス内に手戻りアクティビティ(例: 'Discrepancy Resolved'、初回失敗後の2回目の 'Invoice Data Validated' など)が含まれる場合に true になります。ケース全体を通じて計算されます。 'Discrepancy Rework Rate' KPIを直接支える属性です。追加の手作業を要した請求書を簡単に抽出・集計でき、データ品質の低さや例外処理が与える影響を定量化できます。
その重要性
手戻りを直接測定でき、プロセスの例外や非効率を定量化・分析しやすくなります。
取得元
これはソースシステムの項目ではありません。ケース内で手戻りを示す特定のアクティビティの発生有無を確認し、Process Mining ツール側で計算します。
例
truefalse
|
|||
|
承認者
ApproverName
|
特定ステップで請求書を承認または却下したユーザー。 | ||
|
説明
この属性は、workflow 内で承認判断を行った担当者を特定します。多段承認の請求書では、ステップごとに異なる承認者が存在します。 'Invoice Approval Cycle Time Analysis' dashboard に不可欠な情報です。承認者別にブレークダウンすることで、業務量やその他の要因によりボトルネックとなっている個人を特定でき、承認サイクル短縮に向けたピンポイントの対策が可能になります。
その重要性
承認プロセスを詳細に分析し、個人やチーム単位のボトルネックを特定できます。
取得元
各承認ステップを完了したユーザーを記録するワークフロー履歴ログ('WorkflowTrackingStatusTable')から抽出します。
例
David ChenMaria GarciaAP_Manager_Group
|
|||
|
早期支払割引額
EarlyPaymentDiscountAmount
|
早期支払い時に適用できる割引の見込額。 | ||
|
説明
この属性は、支払条件に基づく早期支払い割引の金額を示します。 'Early Payment Discount Status' ダッシュボードに不可欠な財務データです。獲得できた割引額と取り逃した割引額を定量化でき、請求書の承認や支払スケジューリングの効率化に対する明確な金銭的インセンティブを示せます。
その重要性
プロセス効率化による金銭的な効果を定量化し、パフォーマンスとコスト削減をダイレクトに結び付けます。
取得元
請求書金額と支払条件に基づく計算フィールドです。値は 'VendTrans' など、関連する現金割引のフィールドで参照できます。
例
30.015.00246.91
|
|||
|
自動化
IsAutomated
|
そのアクティビティがシステムによって自動実行されたかを示すフラグ。 | ||
|
説明
このboolean属性は、人による実行か、システム自動化(自動仕訳や自動突合など)かを区別します。 この属性の分析は、APプロセスの自動化度を測る鍵です。STP(Straight-Through Processing)率を算出し、今後自動化すべき手作業アクティビティを特定して、コストと処理時間の削減につなげます。
その重要性
完全自動処理率の測定や、自動化・効率化の余地の特定に役立ちます。
取得元
アクティビティに紐づいているユーザーがシステム/バッチユーザー(例:'Admin'、'BatchUser')かどうかを判定して導出します。
例
truefalse
|
|||
|
請求書ステータス
InvoiceStatus
|
請求書の現在の処理ステータス。 | ||
|
説明
この属性は、請求書の最新の状態(例: 'In Progress'、'Approved'、'Paid'、'Cancelled')を表します。ライフサイクル上の現在地をスナップショットで示します。 Process Miningはアクティビティからフローを導きますが、最終ステータスがあると検証が容易になり、オープンな請求書の現状を要約するビジネスレベルのダッシュボード作成にも役立ちます。例えば、現在 'Approved' だがまだ 'Paid' でない請求書だけを絞り込めます。
その重要性
請求書の現在の状態をわかりやすく要約します。フィルタやステータス別の dashboard 作成に役立ちます。
取得元
AP モジュール内のドキュメントステータスや workflow ステータスのフィールドから取得されることが一般的です。
例
進行中承認済み支払い済み取り消し済み
|
|||
|
請求書の処理時間
InvoiceProcessingTime
|
請求書の受領から支払いまでの総サイクルタイム。 | ||
|
説明
この指標は、請求書ケースの総経過時間を表します。通常、最初のアクティビティ(例:'Invoice Registered')のタイムスタンプから、終端アクティビティ(例:'Payment Executed')のタイムスタンプまでで計算します。 全体のプロセス効率を測る主要 KPI('Average Invoice Cycle Time')です。所要時間を分析することで構造的な遅延を特定でき、改善活動の上位指標として活用できます。ベンダーや会社コードなどのディメンションで切り分ければ、サイクルタイムが長い領域を絞り込めます。
その重要性
エンドツーエンドのプロセス効率を直接測定し、AP 全体の健全性をモニタリングする主要KPIとして機能します。
取得元
これはソースシステムの項目ではありません。ケースの最初と最後のイベントのタイムスタンプ差分から、Process Mining ツールで計算します。
例
15日4時間3日11時間32日1時間
|
|||
買掛金の請求書処理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
支払い実行
|
payment journalを計上することで、正式に支払いが実行されます。この取引で、計上済み請求書により発生した負債が清算されます。 | ||
|
その重要性
これはプロセスの主要な終端イベントです。支払条件遵守率の算出、遅延支払いの特定、エンドツーエンドのサイクルタイムの測定に利用します。
取得元
支払仕訳を転記した時点で記録される明示的なイベントです。精算の詳細は仕入先取引テーブル(VendTrans)に保存され、支払と請求書が紐づけられます。
取得
VendTrans の支払消込レコードの取引日を使用します。
イベントタイプ
explicit
|
|||
|
請求書を承認申請済み
|
請求書は、承認権限者によるレビューと承認のために、正式に workflow に投入されます。ここから承認サイクルが始まります。 | ||
|
その重要性
請求書承認のリードタイム計測を開始する重要なマイルストーンです。データ入力/照合にかかる時間と、承認待ちによる遅延を切り分けるのに役立ちます。
取得元
これは、対象の請求書ドキュメントについて D365 の workflow 履歴(WorkflowTrackingStatusTable)に記録される明示的なイベントです。申請のタイムスタンプが記録されます。
取得
ワークフローの追跡履歴から、請求書の 'Submitted' イベントを抽出します。
イベントタイプ
explicit
|
|||
|
請求書仕訳計上済み
|
承認済みの請求書が総勘定元帳に正式計上され、負債が発生します。多くの場合、取り消しが難しい重要な会計トランザクションです。 | ||
|
その重要性
計上は、支払い可能な状態になる重要なマイルストーンです。すべての検証と承認が完了し、債務が認識されたことを意味します。
取得元
これは明示的な取引です。仕入先請求書仕訳(VendInvoiceJour)および関連する総勘定元帳エントリ(GeneralJournalEntry)に、転記日時が記録されます。
取得
VendInvoiceJour または GeneralJournalEntry テーブルの転記タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
請求書承認済み
|
workflow における最終承認を表します。これにより請求書は支払いのために計上可能となります。支払い工程に進む直前の重要なマイルストーンです。 | ||
|
その重要性
承認サイクルの終了を示します。「Submitted for Approval」から本アクティビティまでの時間は、承認ボトルネックや長期化した workflow を見極める重要なKPIです。
取得元
ワークフローのステータスが『Completed』または『Approved』に更新された時点で、履歴ログ(WorkflowTrackingStatusTable)に記録される明示的なイベントです。
取得
ワークフローの追跡履歴から、請求書に対する 'Approved' または 'Completed' イベントを抽出します。
イベントタイプ
explicit
|
|||
|
請求書登録
|
請求書レコードがシステムに初期登録された時点を示します。手入力、OCR 取込、EDI(電子データ交換)などの経路があり、請求書処理ライフサイクルの起点です。 | ||
|
その重要性
このアクティビティがプロセスの主要な開始イベントです。ここから支払いまでの時間を分析すると、重要指標である請求書の総サイクルタイムが把握できます。
取得元
保留中の仕入先請求書や請求書仕訳テーブル(例: VendInvoiceInfoTable)にある請求書ヘッダーレコードの作成日時(CreatedDateTime)から推定します。
取得
請求書ヘッダーレコードの作成タイムスタンプを使用します。
イベントタイプ
inferred
|
|||
|
不一致を検出
|
請求書が発注書や入荷実績との照合・検証に失敗し、手動対応が必要な状態。多くの場合、請求書に保留や特定のステータスが付与されます。 | ||
|
その重要性
このアクティビティが手戻りループの起点です。発生頻度や原因を分析することで、プロセスの非効率、データ品質の問題、仕入先の課題を特定できます。
取得元
これは請求書の履歴に明示的に記録される場合も、突合差異に関する理由コードで 'On Hold' にされたことから推測される場合もあります。請求書ヘッダーのステータス変更を確認してください。
取得
請求書ステータスが『On Hold』に設定された時点、または不一致フラグが設定された時点のタイムスタンプを取得します。
イベントタイプ
inferred
|
|||
|
不一致を解消
|
差異が見つかった後に、保留を解除したり請求書を修正したりする対応を指します。再度、照合または承認に回せる状態です。 | ||
|
その重要性
このアクティビティで手戻りループが収束します。不一致の解消に要した時間は、例外処理プロセスの効率を測る重要な指標です。
取得元
'On Hold' ステータスが解除された時刻、または却下後にワークフローへ再送された時刻から推定します。
取得
保留が解除された時点、または却下後に請求書が再提出された時点のタイムスタンプを取得します。
イベントタイプ
inferred
|
|||
|
入荷伝票と照合済み
|
3点照合では、入荷伝票と突合して、請求された商品・サービスの受領を確認します。このステップで、請求内容と実際の受領を照合します。 | ||
|
その重要性
この活動を追跡すると、3-way マッチの効率を評価でき、入荷情報の欠落や誤りによって生じる遅延を特定できます。
取得元
PO 照合と同様に、請求書のステータス更新から、製品入荷ジャーナル(Packing Slip)との照合が成功したことを推定します。
取得
ステータスの変化や、三点照合の完了を示すフラグを確認します。
イベントタイプ
inferred
|
|||
|
支払いスケジュール設定
|
計上済み請求書を選択し、payment proposal または payment journal に含め、次回の payment run に予定登録します。支払意思を示すステップです。 | ||
|
その重要性
このアクティビティはキャッシュフロー予測や支払条件の遵守状況の分析に不可欠です。早期支払割引が考慮・計画されているかを見極めるのに役立ちます。
取得元
請求書を含む支払仕訳行(LedgerJournalTrans)の作成から推定します。仕訳行の取引日が予定支払日を示します。
取得
請求書を参照する支払仕訳行の作成日を使用します。
イベントタイプ
inferred
|
|||
|
支払い決済済み
|
会社が実行した支払いが銀行照合により消込済みであることを確認します。これが支払い完了の最終的な財務確認です。 | ||
|
その重要性
このアクティビティは資金流出の最終的な確定を示します。支払実行から消込までの時間を分析することは、財務・資金管理にとって重要です。
取得元
この情報は銀行調整(Bank Reconciliation)モジュールから導出されます。支払いに対応する銀行取引明細行が D365 で照合・転記された時点をもって判断します。
取得
銀行取引データ(BankStmtISOAccountStatement)を元の支払いにひも付ける必要があります。
イベントタイプ
inferred
|
|||
|
発注書と照合済み
|
請求書を1件以上の発注書(PO)にひも付け、数量・単価・条件を確認するプロセス。POベース請求書における重要な検証ステップです。 | ||
|
その重要性
このアクティビティは初回マッチ率の測定や、マッチング工程のボトルネック特定に不可欠です。ここで失敗すると、差異解消のループに陥りがちです。
取得元
請求書レコードの照合ステータスが 'Matched' に更新されたタイミング、または明細行レベルの照合情報が正常に保存されたタイミングから推定できます。情報は通常、仕入先請求書明細に関するテーブルに格納されます。
取得
PO照合の成功に関連する、請求書ヘッダー/明細のステータス変更を特定します。
イベントタイプ
inferred
|
|||
|
請求書データ検証済み
|
照合や承認の前段で、取り込んだ請求書データの完全性・正確性を初期チェックするシステムまたはユーザーを表します。自動のシステム検証の場合もあれば、手動レビューの場合もあります。 | ||
|
その重要性
この活動を追跡することで、データ品質の低さに起因する遅延を見抜けます。ここでの失敗率の高さや滞留の長さは、OCR 精度などデータ取得プロセスの問題を示唆します。
取得元
これは推定イベントであることが多いです。請求書ステータスが 'New' や 'Draft' から 'Validated' や 'Ready for Matching' に変わった時点、または workflow 提出直前の最終更新時刻などから導出します。
取得
検証完了を示すステータス変更、またはワークフロー送信前の更新イベントのタイムスタンプを取得します。
イベントタイプ
inferred
|
|||
|
請求書却下
|
ワークフロー内で承認者が請求書を却下し、通常は作成者に差し戻して修正や説明を求めます。これにより再作業のループを招きます。 | ||
|
その重要性
却下の記録を追うことで、承認遅延や手戻りの原因を特定できます。コード設定の不備、ポリシー違反、証憑不足といった課題をあぶり出します。
取得元
承認者が 'Reject' を選択した際、workflow 履歴(WorkflowTrackingStatusTable)に記録される明示的なイベントです。
取得
ワークフローの追跡履歴から、請求書の 'Rejected' イベントを抽出します。
イベントタイプ
explicit
|
|||
|
請求書取消し済み
|
計上後の請求書を無効化/取消します。多くは誤りを正すためです。これはプロセスの例外的な終了パターンです。 | ||
|
その重要性
取消しの追跡は、プロセス品質やエラー率の把握に重要です。取消し頻度が高い場合、上流プロセスに構造的な問題があるサインかもしれません。
取得元
これは明示的なイベントです。D365 は元の請求書仕訳に紐づく戻し(reversing)またはクレジット取引を作成します。その転記日が取消し日となります。
取得
元の請求書に対する戻し仕訳の計上日を特定します。
イベントタイプ
explicit
|
|||