データ テンプレート: 購買から支払いまで - 購買オーダー
貴社のP2P(購買から支払い)購買オーダーデータテンプレート
- 収集を推奨する項目
- プロセスマッピングのために追跡すべき主要な活動
- 実践的なデータ抽出ガイド
購買から支払いまで - 発注書属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
発注書ライフサイクル内で発生した特定のビジネスイベントまたはステップの名前。 | ||
|
説明
この属性は、「購買発注書作成」、「購買発注書承認」、または「物品受領イベント」といった購買発注書プロセスにおける単一のステップを記述します。これらの活動の順序が、各購買発注書のプロセスフローを形成します。 活動の分析はプロセスマイニングの核心です。これにより、プロセスマップの可視化、プロセスバリアントの発見、そして頻繁に繰り返されたり遅延を引き起こしたりする活動の特定が可能になります。活動の順序と頻度を理解することは、プロセス最適化に不可欠です。
その重要性
この属性は、プロセスマップを構築し、購買発注書のライフサイクルを構成するイベントの順序を理解するために不可欠です。
取得元
PurchTable、PurchReqTableなどのテーブル、およびVendPackingSlipJourやVendInvoiceJourなどの関連する転記ジャーナルにおけるステータス変更に基づいたビジネス ロジックから導出されます。
例
発注書作成発注書承認済み入庫記帳済み発注書請求済み
|
|||
|
イベント日時
EventTime
|
特定のアクティビティやイベントが発生した正確な日時。 | ||
|
説明
このタイムスタンプは、購買発注書プロセスにおける各アクティビティがいつ発生したかを記録します。これはプロセスの時系列的な基盤であり、イベントが正しく順序付けられるようにします。 プロセス分析において、イベントタイムスタンプは、サイクルタイム、アクティビティ間の期間、および全体のケース期間を計算するために不可欠です。これらは、ボトルネックを特定し、SLAに対するパフォーマンスを測定し、プロセスの時間的ダイナミクスを理解するために使用されます。例えば、「購買発注書作成済み」と「購買発注書承認済み」間の時間を計算するために利用されます。
その重要性
タイムスタンプは、サイクルタイムや期間など、すべての時間ベースのパフォーマンス指標を計算するために不可欠であり、プロセスのボトルネックを特定するためにも極めて重要です。
取得元
PurchTableのCreatedDateTimeや関連する仕訳テーブルの記帳日など、複数のテーブルにある様々な日付/時刻フィールドから抽出されます。
例
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-11-05T09:12:00Z
|
|||
|
購買発注
PurchaseOrderNumber
|
購買発注書の固有の識別子であり、プロセス分析における主ケースとして機能します。 | ||
|
説明
発注書番号は、初期のドラフトから最終的な完了またはキャンセルまで、関連するすべてのアクティビティをリンクする中心となる識別子です。各固有の番号は、発注プロセスの単一インスタンスを表します。 プロセスマイニングでは、この属性を使用して各発注書のエンドツーエンドのジャーニーを再構築します。この識別子に基づいてプロセスを分析することで、ライフサイクル全体を詳細に把握でき、個々の発注書における一般的なプロセスパス、逸脱、ボトルネックを特定するのに役立ちます。
その重要性
これは、プロセスフローを再構築するための基本的な鍵であり、各発注の最初から最後までの過程の分析を可能にします。
取得元
これは購買発注書ヘッダーテーブルの主キーであり、通常、Microsoft Dynamics 365のPurchTableテーブルのPurchIdフィールドです。
例
PO-001245PO-001246PO-001247
|
|||
|
ソースシステム
SourceSystem
|
データが抽出されたシステムを示します。 | ||
|
説明
この属性は、購買発注書データの発生源となるソースアプリケーションを特定します。このデータモデルでは、値は通常「Microsoft Dynamics 365」になります。 大規模な組織では、調達プロセスが複数のシステムにまたがる場合があります。この属性はデータガバナンスに役立ち、データの発生源が明確であることを保証します。これは、異なるソースからのデータを統合する際に特に重要です。
その重要性
データの起源に関する重要なコンテキストを提供します。これは、データガバナンス、検証、およびプロセスの技術的ランドスケープを理解する上で不可欠です。
取得元
これは、データ抽出および変換プロセス中にデータセットにラベルを付けるために追加される静的な値です。
例
Microsoft Dynamics 365 F&OD365
|
|||
|
最終データ更新
LastDataUpdate
|
このプロセスのデータが最後に更新された日時を示すタイムスタンプです。 | ||
|
説明
この属性は、ソースシステムからの最新のデータ抽出の日時を記録します。これは、分析中のデータの鮮度に関するコンテキストを提供します。 ユーザーが最新のプロセスデータを表示しているかどうかを理解するために、最終更新時刻を知ることは重要です。これは、分析の関連性を評価し、定期的なデータ更新をスケジュールするのに役立ちます。
その重要性
データの適時性に関する透明性を確保し、ユーザーが自身のプロセス 分析がどの程度最新であるかを把握できるようにします。
取得元
これは、データインジェストプロセス中に生成され、保存されるメタデータ属性です。
例
2024-05-21T05:00:00Z
|
|||
|
ユーザー名
UserName
|
特定のアクティビティを実行したユーザーの名前。 | ||
|
説明
この属性は、購買発注書の作成、承認、変更など、イベントの実行責任者を特定します。これはシステムユーザーIDまたは氏名である場合があります。 ユーザー活動を分析することは、ワークロードの分散を理解し、トレーニングの必要性を特定し、プロセス逸脱に関与する個人やチームを特定するのに役立ちます。承認者のパフォーマンスに関連するダッシュボードに不可欠であり、特定のユーザーによって実行された活動でプロセスをフィルタリングするために使用できます。
その重要性
これにより、ユーザーごとのパフォーマンス分析が可能になり、特定の個人に関連するボトルネックの特定に役立ち、プロセスステップに対する説明責任を提供します。
取得元
PurchTableなどのテーブルにあるCreatedByやModifiedByなどのフィールドから見つけることができます。ユーザー詳細は通常、UserInfo テーブルに保存されています。
例
Alice JohnsonBob WilliamsSysAdmin
|
|||
|
仕入先名
VendorName
|
発注書の作成対象となるサプライヤーまたはベンダーの名前。 | ||
|
説明
この属性には、物品またはサービスを提供する外部の仕入先の名前が含まれています。これは、調達活動を分析するための重要なディメンションです。 プロセスを仕入先名でセグメント化することは、仕入先のパフォーマンスを評価するために不可欠です。これにより、各仕入先の定時配送率、返品率、および品質検査結果を分析できます。これは、信頼できるパートナーや、遅延または品質問題を引き起こす可能性のある仕入先を特定するのに役立ちます。
その重要性
この属性は、仕入先パフォーマンス管理にとって不可欠であり、仕入先ごとの配送時間、返品率、および全体的な信頼性の分析を可能にします。
取得元
仕入先アカウントはPurchTable(フィールドOrderAccount)に保存されます。名前はVendTableと結合することで取得されます。
例
Contoso Office Suppliesファブリカム・ロボティクスノースウィンドトレーダーズ
|
|||
|
希望納期
RequestedDeliveryDate
|
企業がベンダーに品目またはサービスの配送を要求した日付。 | ||
|
説明
この日付は購買発注書に記載されており、希望する納品期間をベンダーに伝えます。これは、ベンダーの納品パフォーマンスを測定するための基準となります。 この属性は、「ベンダー納品遵守」ダッシュボードおよび「納期遵守率」KPIに不可欠です。RequestedDeliveryDateと実際の入荷日を比較することで、企業はベンダーの信頼性を定量化し、サプライチェーンにおける慢性的な遅延を特定できます。
その重要性
これは定時納品実績を測定するためのベースラインであり、ベンダーの信頼性とサプライチェーン効率を評価する上で重要なKPIです。
取得元
通常、PurchTable(ヘッダーレベル)またはPurchLine(明細レベル)にDeliveryDateとして存在します。
例
2023-11-152023-12-012024-01-20
|
|||
|
発注書ステータス
PurchaseOrderStatus
|
発注書のライフサイクルにおける現在のステータス。 | ||
|
説明
この属性は、「未処理」、「受領済み」、「請求済み」、または「キャンセル済み」など、ある時点における購買発注書の全体的なステータスを示します。これは最新の活動の結果を表します。 ステータスを追跡することは、すべての未処理の購買発注書の現在のステータスを理解するのに役立ちます。プロセスマイニングでは、例えば「キャンセル済み」ステータスで終了したすべての購買発注書をフィルタリングして、その理由を調査するなど、ケースの結果を分析するために使用できます。
その重要性
発注書の現在の状態をスナップショットで提供します。これは、ケースのフィルタリングや、完了率やキャンセル率などのプロセス結果の分析に役立ちます。
取得元
PurchTableにあります。主要なステータスフィールドはDocumentStateとPurchStatusです。
例
オープンオーダー受領済みInvoicedキャンセル済み
|
|||
|
発注書合計金額
PurchaseOrderTotalAmount
|
購買発注書の合計金額です。 | ||
|
説明
この属性は、購買発注書に含まれるすべての品目とサービスの総コストを表します。これは、調達プロセスにおける重要な財務指標です。 総額に基づいてプロセスを分析することで、重要なインサイトが得られます。例えば、高額な購買発注書は、より厳格な承認経路をたどったり、サイクルタイムが長くなったりする傾向があります。また、財務報告書や、分析のためにPOを金額帯別に分類する際にも利用されます。
その重要性
調達プロセスの財務分析を可能にし、注文価値が承認時間や経路などのプロセス動作にどのように影響するかを特定できます。
取得元
この値は、PurchLineテーブルから、特定のPurchIdに対するLineAmountを合計することで計算できます。または、PurchTable上のヘッダーレベルの金額フィールドで見つけることも可能です。
例
5250.00120.50150000.00
|
|||
|
会社コード
CompanyCode
|
発注書を発行する法人または企業の識別子。 | ||
|
説明
複数企業環境において、この属性は、どの法人エンティティが購買を行っているかを指定します。これは組織の基本的なデータポイントです。 この属性により、同じ組織内の異なる法人エンティティ間でのP2Pプロセスの比較分析が可能になります。企業間のプロセス効率、コンプライアンス、ベンダー管理の違いを浮き彫りにし、標準化の取り組みを支援します。
その重要性
複数エンティティを持つ組織が異なる 法人 エンティティ間で調達 プロセスを比較し、標準化するために不可欠です。
取得元
これは、PurchTableを含むDynamics 365のほぼすべてのテーブルに存在するDataAreaIdフィールドです。
例
USMFDEMFGBSI
|
|||
|
定時配送
IsOnTimeDelivery
|
要求された納期までに商品が受領されたかどうかを示す真偽値フラグです。 | ||
|
説明
この計算属性は、「入荷計上済み」アクティビティのタイムスタンプとRequestedDeliveryDateを比較します。受領日が要求された日付以前である場合に「true」に設定されます。 このフラグは、「納期遵守率」KPIの計算を直接的にサポートします。これにより、ベンダーパフォーマンスの分析が簡素化され、納期内納品と遅延納品を容易にフィルタリングし、可視化できるようになります。これは「ベンダー納品遵守」ダッシュボードの中心的な要素です。
その重要性
配送パフォーマンスについて明確な二値の結果を提供し、オンタイム配送KPIやベンダー評価の計算を簡素化します。
取得元
これは、「入荷計上済み」アクティビティのEventTimeとRequestedDeliveryDateを比較することで導出される計算属性です。
例
truefalse
|
|||
|
承認サイクルタイム
ApprovalCycleTime
|
発注書作成から最終承認までの期間。 | ||
|
説明
この計算指標は、「購買発注書作成済み」アクティビティから「購買発注書承認済み」アクティビティまでの経過時間を測定します。これは、承認ワークフローの効率を直接的に測るものです。 この属性は、「平均PO承認時間」KPIおよび「PO承認サイクルタイム分析」ダッシュボードの主要な測定値です。この期間を分析することで、承認プロセスにおけるボトルネックを特定し、承認プロセスが社内のサービスレベル契約を満たしているかを評価するのに役立ちます。
その重要性
調達プロセスにおいて遅延が発生しやすい一般的な領域である承認 ワークフローの効率性を直接測定します。
取得元
各ケースにおいて、「購買オーダー承認済み」アクティビティのEventTimeと、「購買オーダー作成済み」アクティビティのEventTimeの間の時間差を計算して算出されます。
例
P2DT12H30MPT8HP7D
|
|||
|
承認者名
ApproverName
|
発注書を承認した、または承認ワークフロー内のステップを実行したユーザーの名前。 | ||
|
説明
この属性は、購買発注書に正式な承認を与え、その進行を許可したマネージャーまたはユーザーを特定します。多段階承認ワークフローでは、1つの購買発注書に対して複数の承認者がいる場合があります。 承認者を追跡することは、「購買発注書承認サイクルタイム分析」および「承認者パフォーマンスメトリクス」ダッシュボードにとって不可欠です。これにより、各承認者がかかる時間を測定し、承認チェーンにおけるボトルネックを特定し、ワークロードの分散と効率を評価するのに役立ちます。
その重要性
承認 プロセスの分析を可能にし、承認 ボトルネックの特定や、異なる 承認者のパフォーマンスとワークロードの測定に役立ちます。
取得元
承認情報は通常、PurchTableに直接ではなく、ワークフロートラッキングテーブルに格納されます。購買オーダーに関連付けられたワークフロー履歴を照会する必要があります。
例
Charles GreenDiana PrinceEdward Nigma
|
|||
|
発注は変更されましたか
IsPurchaseOrderChanged
|
購買オーダーが最初の承認後に変更されたかどうかを示す真偽値フラグです。 | ||
|
説明
この計算属性は、特定のケースにおいて「購買発注書承認済み」アクティビティの後に「購買発注書変更済み」アクティビティが発生した場合に「true」に設定されます。これにより、手戻りや修正の分析が簡素化されます。 このフラグは、「承認後のPO変更率」KPIおよび「購買発注書変更トレンド」ダッシュボードの計算に不可欠です。手戻りが必要だった購買発注書を特定し、分析するための直接的な方法を提供し、そのような変更の根本原因を特定するのに役立ちます。
その重要性
手戻りや変更頻度の測定を簡素化します。これらはプロセスの不安定性や非効率性を示す主要な指標です。
取得元
これは、イベントログ内のアクティビティのシーケンスから導出される計算属性です。
例
truefalse
|
|||
|
購買カテゴリ
PurchaseCategory
|
購入した品目またはサービスの分類(例:「ITハードウェア」または「事務用品」)。 | ||
|
説明
この属性は、購買発注書の品目を論理的なカテゴリにグループ化する方法を提供します。この分類は、異なる種類の調達における支出パターンやプロセスのバリエーションを分析するのに役立ちます。 プロセス分析では、購買カテゴリでフィルタリングすることで、異なるふるまいが明らかになることがあります。例えば、設備投資の調達プロセスは、運用資材のそれよりも長く、複雑になる可能性があります。これはダッシュボードで使用され、カテゴリごとの変更トレンドと返品率を分析します。
その重要性
購入される商品やサービスの種類によってプロセスを分割でき、異なる費用カテゴリにおける様々なプロセス動作を明らかにします。
取得元
品目カテゴリは、InventTableのリリース済み製品にリンクされており、それがPurchLineで使用されます。カテゴリ情報自体はカテゴリ管理テーブルに保存されます。
例
ITハードウェア事務用品プロフェッショナルサービス原材料
|
|||
|
購買依頼書
PurchaseRequisitionNumber
|
発注書に先行する購買依頼の識別子。 | ||
|
説明
この属性は、購買発注書を元の社内要求である購買要求書に関連付けます。すべての購買発注書が要求書から発生するわけではありません。 このリンクは、完全な「要求書から購買発注書まで」プロセスを分析する上で極めて重要です。これにより、「要求書から購買発注書への変換速度」KPIを測定し、社内需要がどのくらい迅速に外部注文に変換されるかを理解できます。また、例えば正式な要求書なしで作成された購買発注書を特定するなど、コンプライアンスの分析にも役立ちます。
その重要性
発注を最初の依頼にリンクさせ、依頼から注文までのサイクルタイムの分析を可能にし、プロセスコンプライアンスを保証します。
取得元
PurchLineテーブルのPurchReqIdフィールドにあり、PurchReqTableにリンクしています。
例
PR-000871PR-000872PR-000873
|
|||
|
返品理由
ReturnReason
|
発注書に基づく品目がベンダーに返品される際に提供される理由。 | ||
|
説明
「ベンダーに返品済み」アクティビティが発生した場合、この属性は「破損品」、「品目間違い」、「品質不良」など、返品の理由を記録します。 このデータは、「購買オーダー返品率ダッシュボード」にとって非常に価値があります。返品理由を分析することは、ベンダー品質、社内発注ミス、配送問題など、返品の根本原因を特定するのに役立ちます。これにより、返品率を削減するための的を絞った対策が可能になります。
その重要性
商品の返品理由に関する洞察を提供し、ベンダーの品質、発注の正確性、または物流に関する問題を診断するのに役立ちます。
取得元
返品理由は通常、返品オーダー、またはマイナス受領ジャーナルに関連付けられた理由コードを通じて捕捉されます。
例
輸送中に破損誤った品目が配送された品質検査不合格
|
|||
|
部署
DepartmentName
|
購買依頼または発注を開始した部署名。 | ||
|
説明
この属性は、購買を担当する内部のビジネスユニットまたは部署を特定します。多くの場合、購買要求書を作成したユーザーから導き出されます。 部署別にプロセスを分析することは、組織の異なる部門がどのように調達プロセスを利用しているかを理解する上で重要です。これにより、承認サイクルが長い部署、購買発注書変更率が高い部署、または特定の購買パターンを持つ部署を特定するのに役立ちます。これは、ターゲットを絞ったプロセス改善イニシアチブを可能にします。
その重要性
異なる事業単位間でのプロセス パフォーマンスの比較を可能にし、部門固有の行動、ボトルネック、または非効率性の特定に役立ちます。
取得元
この情報は、購買要求(PurchReqTable)または購買発注書(PurchTable)の要求者または作成者、および人事モジュールにおける彼らの関連部署を通じてリンクされることがよくあります。
例
財務IT製造業マーケティング
|
|||
|
配送場所
DeliveryLocation
|
品目が配送される特定のサイト、倉庫、または住所。 | ||
|
説明
この属性は、購買発注書に記載された品目の納品場所を示します。倉庫、特定のオフィス、またはプロジェクト現場などが該当します。 納品場所別にプロセスを分析することで、地域固有またはサイト固有のボトルネックを特定するのに役立ちます。特に、入荷処理プロセスにおいて有効です。「入荷処理時間」ダッシュボードでは、この属性を使用して異なる場所間での効率を比較できます。
その重要性
特に、入庫および品質検査の段階における、場所固有のプロセス変動や遅延の特定に役立ちます。
取得元
配送先住所と場所に関する情報はPurchTableに保存されており、会社またはベンダーの設定からデフォルトで取得できます。
例
メイン倉庫AC棟オフィス西海岸流通センター
|
|||
購買から支払いまで - 発注書活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
ベンダーへ発注書送付済み
|
この活動は、承認された購買発注書が仕入先に伝達されたことを示します。これは、購買発注書が確認されたときに捕捉され、その際に確認ジャーナルが生成され、通常、ドキュメントの送付がトリガーされます。 | ||
|
その重要性
これは最初の対外的なステップであり、サプライヤーのリードタイムの計測を開始します。ベンダーパフォーマンスの追跡および「納期遵守率」KPIにとって不可欠です。
取得元
このイベントは、PurchPurchaseOrderJour テーブル(PO確認ジャーナル)にレコードが作成されることで記録されます。このジャーナルの作成日がアクティビティのタイムスタンプとして使用されます。
取得
POの最初のPurchPurchaseOrderJourレコードの作成timestampを使用します。
イベントタイプ
explicit
|
|||
|
入庫記帳済み
|
システム内で発注書に基づき、受領された商品の正式な記録を示します。このイベントは、商品受領仕訳が転記された際に取得されます。 | ||
|
その重要性
これは、在庫を更新し、請求書照合プロセスの開始を示す重要なマイルストーンです。「納期遵守率」およびベンダーリードタイムを測定するための終点となります。
取得元
VendPackingSlipJourに保存されている製品受領ジャーナルの作成時に取得されます。このテーブルのcreatedDateTimeまたはPackingSlipDateは、商品が正式に受領された時期を示します。
取得
POにリンクされたVendPackingSlipJourレコードから、作成または転記timestampを使用します。
イベントタイプ
explicit
|
|||
|
発注書作成
|
この活動は、システム内で購買発注書の下書きドキュメントが作成されたことを示します。これは、多くの場合、承認された要求書に続いて購買発注書ヘッダーレコードの作成タイムスタンプから捕捉されます。 | ||
|
その重要性
これは、内部要求から正式な購買文書への移行を示します。PO処理および承認のサイクルタイムを測定するための重要な開始点です。
取得元
このイベントは、PurchTableにレコードが作成されることです。このテーブルのcreatedDateTimeフィールドがアクティビティのタイムスタンプを提供します。
取得
各発注について、PurchTableから作成タイムスタンプを抽出します。
イベントタイプ
explicit
|
|||
|
発注書完了
|
すべての物品が受領され、請求された発注ライフサイクルの成功裏の完了を示します。これは通常、発注ステータスが最終的なクローズド状態に更新されたときに推測されます。 | ||
|
その重要性
この活動は、成功したプロセスインスタンスの終点を示します。作成から完了までの「購買発注書全体のサイクルタイム」を測定することで、プロセス効率の全体像を把握できます。
取得元
PurchTable上のステータスフィールドから推測されます。例えば、DocumentStateが「請求済み」であり、明細アイテムのステータスが完全な受領と請求を示している場合などです。
取得
発注のヘッダーおよび明細ステータスが最終的なクローズド状態(例: 「請求済み」)に更新されたタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
発注書承認済み
|
発注書が最終承認され、ベンダーに送付される準備が整ったことを示します。このイベントは通常、発注書のステータス変更から推測されるか、ワークフロー履歴から直接取得されます。 | ||
|
その重要性
これは重要なマイルストーンであり、POが承認されるまでそれ以上の措置を講じることはできません。承認のボトルネックを分析し、「PO承認サイクルタイム」KPIを測定する上で不可欠です。
取得元
PurchTable上のDocumentStateフィールドが「承認済み」に変化したことから推測されます。あるいは、WorkflowTrackingStatusTableにおける最終承認ステップの完了タイムスタンプから取得できます。
取得
PurchTable上のDocumentStateが「承認済み」に遷移したタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
購買依頼書作成
|
この活動は、物品またはサービスの正式な要求である購買要求書の作成を示します。これは、購買要求書テーブルに新しいレコードが作成されたときに捕捉され、調達要求の開始を意味します。 | ||
|
その重要性
これは購買発注書プロセスの初期トリガーです。このイベントからPO作成までの時間を分析することで、内部プロセス効率と需要への対応力を測定するのに役立ちます。
取得元
このイベントは、PurchReqTableにレコードが作成されたことに対応します。レコードの作成タイムスタンプ(createdDateTime)がイベント時刻となります。
取得
各購買依頼について、PurchReqTableから作成タイムスタンプを抽出します。
イベントタイプ
explicit
|
|||
|
ベンダーによる発注書確認済み
|
ベンダーによる発注書詳細の確認と承認を表します。これは、多くの場合、ベンダーからの連絡に基づいて手動でデータ入力されるステップです。 | ||
|
その重要性
ベンダーからの確認は、注文が処理中であるという安心感をもたらします。この段階での遅延や不一致は、潜在的な履行上の問題を示す兆候となり得ます。
取得元
これは通常、PurchTable上の納品確認日などの確認関連の日付またはステータスフィールドの入力から推測されます。個別のイベントではない場合があります。
取得
PurchTableまたはPurchLine上の特定の確認日フィールドの入力から推測されます。
イベントタイプ
inferred
|
|||
|
ベンダーに返品済み
|
損傷や誤った品目などの問題により、以前に受領した物品がベンダーに返品されたことを示します。これは返品トランザクションを記帳することで捕捉されます。 | ||
|
その重要性
返品はプロセスの失敗と追加コストを意味します。このアクティビティを追跡することで、「発注書返品率」を算出し、ベンダーや製品に関する問題を特定するのに役立ちます。
取得元
このイベントは、負の数量を持つ購買発注書の作成、または元のPOを参照する特定の返品オーダー伝票の作成から推測されます。返品転記の取引日付がイベント時刻となります。
取得
元POに対する購買返品注文または借方票の記帳を特定します。
イベントタイプ
explicit
|
|||
|
品質検査実行済み
|
受領した品目の品質検査が完了したことを表します。このイベントは、多くの場合、品質管理モジュールまたはステータス更新によって管理されます。 | ||
|
その重要性
この活動は、物品受領から使用可能になるまでの間に重要なボトルネックとなる可能性があります。その期間を分析することで、「品質検査サイクルタイム」KPIの改善に役立ちます。
取得元
これは、購買発注書受領に紐づく品質検査オーダー(InventQualityOrderTable)の完了から推測できます。ステータスが「合格」または「不合格」に変更された際のタイムスタンプがイベント時刻となります。
取得
PO明細行に関連付けられたInventQualityOrderTable上のステータス完了タイムスタンプを追跡します。
イベントタイプ
inferred
|
|||
|
発注書キャンセル済み
|
発注書が完全に完了する前に終了したことを表します。これは、発注書ドキュメント上の特定のステータス変更によって捕捉されます。 | ||
|
その重要性
キャンセルは重要な例外パスです。その頻度や理由を分析することで、計画やベンダーの信頼性に関する問題が明らかになります。
取得元
これは、PurchTable上のDocumentStateフィールドが「キャンセル済み」に更新されたことから推測されます。このステータス変更のタイムスタンプがイベント時刻となります。
取得
PurchTable上のDocumentStateが「キャンセル済み」に設定されたタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
発注書変更済み
|
この活動は、承認された購買発注書に加えられたあらゆる変更を捕捉します。Dynamics 365は購買発注書のバージョンを追跡できるため、変更の特定が可能になります。 | ||
|
その重要性
変更を追跡することは、手戻りの特定、プロセス不安定性の理解、および「PO変更率」の測定にとって不可欠です。変更は遅延やコスト変動につながる可能性があります。
取得元
アーカイブまたはバージョン管理テーブル(例: PurchTableHistory)に保存されている発注の異なるバージョンを比較することで推測されます。バージョン番号の増加は変更を示します。
取得
PurchTable上のバージョン番号が承認後に増加したレコードを特定します。
イベントタイプ
inferred
|
|||
|
発注書承認申請済み
|
発注書のドラフトが正式に承認ワークフローに提出された時点を表します。これは通常、ユーザーによる明示的なアクションであり、ワークフローログを通じて捕捉されます。 | ||
|
その重要性
この活動は、購買発注書の承認サイクルを正式に開始します。これを追跡することで、購買発注書が承認を待つ期間や承認全体の期間を正確に測定できます。
取得元
購買オーダーのWorkflowTrackingStatusTableから取得されます。このテーブルは申請イベントとタイムスタンプをログに記録します。
取得
PurchTableレコードに関連付けられたワークフロー履歴から、「提出済み」イベントを特定します。
イベントタイプ
explicit
|
|||
|
発注書請求済み
|
この活動は、仕入先からの請求書が受領され、購買発注書に計上された時点を示します。このイベントは、調達プロセスと支払いプロセスを結びつけます。 | ||
|
その重要性
これは支払い前の最終ステップであり、購買の最終コストを計算するために不可欠です。三者照合分析の終点を提供します。
取得元
このイベントは、購買発注書に照合されたベンダー請求書仕訳帳(VendInvoiceJour)の転記から取得されます。このレコード上のInvoiceDateまたは転記日付がタイムスタンプとなります。
取得
PurchTableレコードにリンクされたVendInvoiceJourテーブルから、転記timestampを使用します。
イベントタイプ
explicit
|
|||
|
購買依頼書承認済み
|
購買依頼が権限のあるマネージャーによって正式に承認されたことを表します。このイベントは通常、ワークフロー履歴ログから取得されるか、依頼記録のステータス変更を追跡することで捕捉されます。 | ||
|
その重要性
承認は、依頼を購買オーダーに変換するために不可欠な重要なマイルストーンです。ここでの遅延は、調達全体のタイムラインに直接影響します。
取得元
購買依頼に関連付けられたWorkflowTrackingStatusTableから取得するか、PurchReqTableのステータスが「承認済み」状態に変化したことから推測できます。
取得
申請のワークフロー履歴における最終承認ステップの完了timestampを使用します。
イベントタイプ
explicit
|
|||