調達から支払いまで:発注書のデータテンプレート
調達から支払いまで:発注書のデータテンプレート
- 収集を推奨する属性
- プロセスマッピングで追跡する主なアクティビティ
- データ抽出の手順
調達から支払いまで:発注書の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
発注書のライフサイクルで発生した、特定の業務イベントまたはステップの名前です。 | ||
|
説明
この属性は、「発注書の作成」「発注書の承認」「入荷の計上」など、発注書プロセスの個々のステップを表します。これらのアクティビティの順序が、発注書ごとのプロセスフローを構成します。 アクティビティの分析は、プロセスマイニングの中心です。プロセスマップの可視化やプロセスバリアントの発見、繰り返し発生するアクティビティや遅延の原因となるアクティビティの特定に役立ちます。プロセスを改善するには、アクティビティの順序と頻度を把握することが重要です。
重要な理由
プロセスマップの作成と、発注書のライフサイクルを構成するイベントの順序の把握に欠かせない属性です。
入手先
PurchTableやPurchReqTableなどのテーブルにおけるステータス変更と、VendPackingSlipJourやVendInvoiceJourなど関連する計上仕訳に基づく業務ロジックから導出します。
例
発注書の作成発注書の承認入荷の計上発注書の請求書計上
|
|||
|
イベント時刻
EventTime
|
特定のアクティビティまたはイベントが発生した正確な日時です。 | ||
|
説明
このタイムスタンプは、発注書プロセスの各アクティビティが発生した日時を記録します。イベントを正しい順序に並べるための基準になります。 プロセス分析では、イベントのタイムスタンプを使ってサイクルタイムやアクティビティ間の所要時間、ケース全体の所要時間を算出します。ボトルネックの特定やSLAに対する実績の測定、プロセスの時間的な動きの把握にも役立ちます。たとえば、「発注書の作成」から「発注書の承認」までの時間を算出できます。
重要な理由
サイクルタイムや所要時間など、時間に基づくパフォーマンス指標の算出に欠かせません。プロセスのボトルネックを特定するうえでも重要です。
入手先
PurchTableのCreatedDateTimeや、関連する仕訳テーブルの計上日など、複数のテーブルにあるさまざまな日付・時刻フィールドから抽出します。
例
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-11-05T09:12:00Z
|
|||
|
発注書
PurchaseOrderNumber
|
発注書を一意に識別する番号で、プロセス分析の主要なケース識別子として使われます。 | ||
|
説明
発注書番号は、下書きから完了またはキャンセルまで、関連するすべてのアクティビティを結び付ける中心的な識別子です。番号ごとに、発注書プロセスの1つのケースを表します。 プロセスマイニングでは、この属性を使って各発注書の一連の流れを再構成します。この識別子に基づいて分析すると、発注書のライフサイクル全体を詳しく確認でき、よくある経路や逸脱、個々の注文で発生するボトルネックを特定できます。
重要な理由
プロセスフローを再構成するための基本となるキーです。各発注書の開始から終了までの流れを分析できます。
入手先
通常、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テーブルに保存されています。
例
アリス・ジョンソンボブ・ウィリアムズシステム管理者
|
|||
|
仕入先名
VendorName
|
発注書の発行先となる仕入先の名前です。 | ||
|
説明
商品やサービスを提供する外部の仕入先名を含む属性です。調達業務を分析する際の重要な切り口になります。 仕入先ごとにプロセスを分けて分析すると、納期遵守率や返品率、品質検査の結果を評価できます。信頼できる取引先や、遅延・品質問題の原因となっている仕入先を特定するのに役立ちます。
重要な理由
仕入先ごとの納品時間や返品率、全体的な信頼性を分析できるため、仕入先の実績管理に欠かせない属性です。
入手先
仕入先の取引先アカウントはPurchTableのOrderAccountフィールドに保存されています。VendTableと結合して仕入先名を取得します。
例
コンテーソ・オフィス用品ファブリカム・ロボティクスノースウィンド・トレーダーズ
|
|||
|
希望納品日
RequestedDeliveryDate
|
商品やサービスの納品を仕入先に希望する日付です。 | ||
|
説明
発注書に指定し、希望する納品時期を仕入先に伝える日付です。仕入先の納品実績を測定する際のベースラインになります。 「仕入先の納期遵守パフォーマンス」ダッシュボードや「納期遵守率」重要業績評価指標(KPI)に欠かせない属性です。RequestedDeliveryDateと実際の入荷日を比較すると、仕入先の信頼性を数値で評価し、サプライチェーンで繰り返し発生する遅延を特定できます。
重要な理由
納期遵守パフォーマンスを測定する際のベースラインです。仕入先の信頼性やサプライチェーンの効率を評価する重要な指標です。
入手先
通常、PurchTable(ヘッダーレベル)またはPurchLine(明細レベル)のDeliveryDateとして格納されています。
例
2023-11-152023-12-012024-01-20
|
|||
|
発注書のステータス
PurchaseOrderStatus
|
ライフサイクルにおける発注書の現在のステータスです。 | ||
|
説明
「Open order」「Received」「Invoiced」「Canceled」など、特定の時点における発注書全体の状態を示す属性です。直近のアクティビティの結果を表します。 ステータスを追跡すると、未完了の発注書の現在の状態を把握できます。プロセスマイニングでは、ケースの結果を分析する際にも使えます。たとえば、「Canceled」で終了した発注書に絞り込み、キャンセルの理由を調べられます。
重要な理由
発注書の現在の状態を把握できます。ケースの絞り込みや、完了率・キャンセル率などのプロセス結果の分析に役立ちます。
入手先
PurchTableにあります。主なステータスフィールドはDocumentStateとPurchStatusです。
例
未処理の注文受領済み請求書計上済みキャンセル済み
|
|||
|
発注書の合計金額
PurchaseOrderTotalAmount
|
発注書の合計金額です。 | ||
|
説明
発注書に含まれる商品やサービスの総額を表す属性です。調達プロセスにおける重要な財務指標です。 合計金額ごとにプロセスを分析すると、重要な傾向が見つかることがあります。たとえば、高額な発注書では承認経路が異なり、より厳格な承認が必要になったり、サイクルタイムが長くなったりする場合があります。財務報告や、分析用に発注書を金額帯別に分類する際にも使われます。
重要な理由
調達プロセスの財務分析に役立ち、注文金額が承認時間や承認経路などのプロセスの動きにどう影響するかを把握できます。
入手先
PurchLineテーブルのLineAmountをPurchIdごとに合計して算出するか、PurchTableのヘッダーレベルの金額フィールドから取得します。
例
5250.00120.50150000.00
|
|||
|
会社コード
CompanyCode
|
発注書を発行する法人または会社を識別するコードです。 | ||
|
説明
複数の会社を運営する環境では、この属性によって、どの法人が購買を行うかを示します。組織を管理するうえで基本となるデータです。 この属性を使うと、同じ組織内の複数の法人について、調達から支払いまでのプロセスを比較できます。会社ごとのプロセス効率、コンプライアンス、仕入先管理の違いを明らかにし、標準化の取り組みに役立てられます。
重要な理由
複数の法人を持つ組織で、法人ごとの調達プロセスを比較し、標準化するために必要です。
入手先
これはDataAreaIdフィールドです。PurchTableを含む、Dynamics 365のほぼすべてのテーブルにあります。
例
USMFDEMFGBSI
|
|||
|
承認者名
ApproverName
|
発注書、または承認ワークフローのステップを承認したユーザーの名前です。 | ||
|
説明
この属性は、発注書の正式な承認を行い、次の処理へ進めたマネージャーまたはユーザーを示します。複数段階の承認ワークフローでは、1つの発注書に複数の承認者が関わる場合があります。 承認者を記録することは、「発注書の承認サイクルタイム分析」や「承認者のパフォーマンス指標」のダッシュボードで分析するうえで欠かせません。承認者ごとの処理時間を測定し、承認経路のボトルネックを特定できるほか、業務負荷の配分や効率性の評価にも役立ちます。
重要な理由
承認プロセスを分析し、承認のボトルネックを特定するとともに、承認者ごとのパフォーマンスや業務負荷を測定できます。
入手先
承認情報は通常、PurchTableに直接保存されるのではなく、ワークフローの追跡テーブルに保存されます。発注書に関連付けられたワークフロー履歴を照会する必要があります。
例
Charles GreenDiana PrinceEdward Nigma
|
|||
|
発注書の変更有無
IsPurchaseOrderChanged
|
発注書が最初の承認後に変更されたかどうかを示す真偽値フラグです。 | ||
|
説明
この計算属性は、該当するケースで「発注書の承認」アクティビティの後に「発注書の変更」アクティビティが発生した場合に「true」に設定されます。手戻りや変更の分析を簡単に行えます。 このフラグは、「承認後の発注書変更率」KPIの算出や、「発注書の変更傾向」ダッシュボードでの分析に欠かせません。手戻りが発生した発注書を簡単に抽出して分析できるため、変更の根本原因の特定に役立ちます。
重要な理由
手戻りや変更の頻度を簡単に測定できます。これらは、プロセスの不安定さや非効率性を示す重要な指標です。
入手先
イベントログ内のアクティビティの順序から算出される属性です。
例
truefalse
|
|||
|
納品先
DeliveryLocation
|
商品を納品する特定の拠点、倉庫、または住所です。 | ||
|
説明
この属性は、発注明細の納品先となる物理的な場所を示します。倉庫、特定のオフィス、プロジェクトの現場などが該当します。 納品先別にプロセスを分析すると、地域や拠点に固有のボトルネックを特定できます。特に、入庫プロセスの分析に役立ちます。「入庫処理時間」ダッシュボードでは、この属性を使って拠点ごとの効率を比較できます。
重要な理由
拠点ごとのプロセスの違いや遅延を特定できます。特に、入庫や品質検査の段階の分析に役立ちます。
入手先
納品先の住所と場所の情報はPurchTableに保存され、会社または仕入先の設定から初期値が入力される場合があります。
例
主要倉庫AC棟オフィス西海岸配送センター
|
|||
|
納期どおりの納品かどうか
IsOnTimeDelivery
|
希望納品日までに商品を受領したかどうかを示す真偽値フラグです。 | ||
|
説明
この計算属性は、「入庫計上」アクティビティのタイムスタンプとRequestedDeliveryDateを比較します。受領日が希望納品日と同日またはそれ以前の場合、「true」に設定されます。 このフラグは、「納期遵守率」KPIの算出に直接役立ちます。仕入先のパフォーマンスを簡単に分析でき、納期どおりの納品と遅延した納品を絞り込んで可視化できます。「仕入先の納期遵守状況」ダッシュボードの中心となる指標です。
重要な理由
納品実績を明確に「納期どおり」か「遅延」かで示し、納期遵守率KPIや仕入先スコアカードの算出を簡単にします。
入手先
RequestedDeliveryDateと「入庫計上」アクティビティのEventTimeを比較して算出される属性です。
例
truefalse
|
|||
|
購買カテゴリ
PurchaseCategory
|
購入した商品やサービスの分類です。例:「IT機器」や「事務用品」。 | ||
|
説明
この属性を使うと、発注明細を分類ごとに整理できます。この分類により、購買の種類ごとの支出傾向やプロセスの違いを分析できます。 プロセス分析では、購買カテゴリで絞り込むことで、カテゴリごとの処理の違いを把握できます。たとえば、設備投資の調達は、日常業務用の備品の調達よりも時間がかかり、複雑になる場合があります。ダッシュボードでは、カテゴリ別の変更傾向や返品率の分析に利用できます。
重要な理由
購入する商品やサービスの種類ごとにプロセスを分類し、支出カテゴリによる処理の違いを把握できます。
入手先
品目カテゴリはリリース済み製品(InventTable)に関連付けられ、その製品はPurchLineで使用されます。カテゴリ情報自体は、カテゴリ管理テーブルに保存されています。
例
IT機器事務用品専門サービス原材料
|
|||
|
購買依頼
PurchaseRequisitionNumber
|
発注書の前段階にあたる購買依頼の識別子です。 | ||
|
説明
発注書と、その元となった社内依頼である購買依頼を結び付ける属性です。すべての発注書が購買依頼から作成されるわけではありません。 この関連付けは、「購買依頼から発注書まで」のプロセス全体を分析するうえで重要です。「購買依頼から発注書への移行速度」重要業績評価指標(KPI)を測定し、社内の需要がどれだけ早く外部への発注につながるかを把握できます。また、正式な購買依頼なしに作成された発注書を特定するなど、コンプライアンスの分析にも役立ちます。
重要な理由
発注書と最初の依頼を結び付け、購買依頼から発注までのサイクルタイムの分析や、プロセスのコンプライアンス確認に役立ちます。
入手先
PurchLineテーブルのPurchReqIdフィールドにあり、PurchReqTableを参照します。
例
PR-000871PR-000872PR-000873
|
|||
|
返品理由
ReturnReason
|
発注書の商品を仕入先に返品する際に記録する理由です。 | ||
|
説明
「仕入先への商品返品」アクティビティが発生した際、この属性には「輸送中の破損」「品目違い」「品質不良」など、返品の理由が記録されます。 このデータは、「発注書の返品率」ダッシュボードでの分析に役立ちます。返品理由を分析することで、仕入先の品質、社内の発注ミス、配送上の問題など、返品の根本原因を特定できます。原因に応じた対策を講じ、返品率の低減につなげられます。
重要な理由
返品の理由を把握し、仕入先の品質、発注の正確性、物流に関する問題の特定に役立ちます。
入手先
返品理由は通常、返品注文の取引、またはマイナスの入庫仕訳に関連付けられた理由コードに記録されます。
例
輸送中に破損誤った品目が納品された品質検査に不合格
|
|||
|
部門
DepartmentName
|
購買依頼または発注書を起票した部門の名前です。 | ||
|
説明
購買を担当する社内の事業部門または部門を示す属性です。多くの場合、購買依頼を作成した担当者の情報から導出します。 部門ごとにプロセスを分析すると、組織内の各部門が調達プロセスをどのように利用しているかを把握できます。承認サイクルが長い部門や、発注書の変更率が高い部門、特有の購買傾向を持つ部門を特定し、対象を絞ったプロセス改善につなげられます。
重要な理由
事業部門ごとのプロセス実績を比較し、部門固有の傾向やボトルネック、非効率な点を特定できます。
入手先
購買依頼(PurchReqTable)または発注書(PurchTable)の申請者・作成者と、HRモジュールに登録された所属部門の情報を関連付けて取得することがよくあります。
例
財務IT製造マーケティング
|
|||
調達から支払いまで:発注書のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
入荷の計上
|
発注書に対する入荷をシステムに正式に記録したことを示します。製品受領仕訳が計上された時点で記録されます。 | ||
|
重要な理由
在庫が更新され、請求書との照合が始まる重要な節目です。「納期遵守率」と仕入先のリードタイムを測定する際の終点になります。
入手先
VendPackingSlipJourに保存された製品受領仕訳の作成から取得します。このテーブルのcreatedDateTimeまたはPackingSlipDateから、商品を正式に受領した時刻を確認できます。
記録
発注書に関連付けられたVendPackingSlipJourレコードの作成時刻または計上時刻を使用します。
イベントタイプ
explicit
|
|||
|
発注書の作成
|
システム上で発注書の下書きが作成されたことを示すアクティビティです。発注書ヘッダーレコードの作成日時から取得します。通常、承認済みの購買依頼を受けて作成されます。 | ||
|
重要な理由
社内の依頼が正式な購買文書に移行したことを示します。発注書の処理時間や承認サイクルタイムを測定する際の重要な起点です。
入手先
PurchTableにレコードが作成されたことを示すイベントです。このテーブルのcreatedDateTimeフィールドからアクティビティの時刻を取得できます。
記録
各発注書について、PurchTableから作成日時を抽出します。
イベントタイプ
explicit
|
|||
|
発注書の完了
|
商品をすべて受領し、請求書の処理も完了して、発注書の一連の処理が正常に終了したことを示します。通常は、発注書のステータスが最終のクローズ状態に更新されたことから推定します。 | ||
|
重要な理由
このアクティビティは、プロセスが正常に完了したことを示します。作成から完了までの「発注書の総サイクルタイム」を測定すると、プロセス効率を全体的に把握できます。
入手先
PurchTableのステータスフィールドから推定します。たとえば、DocumentStateが「Invoiced」で、明細のステータスから全商品の受領と請求書処理が完了したと確認できる場合です。
記録
発注書のヘッダーと明細のステータスが最終のクローズ状態(例:「Invoiced」)に更新された時刻を特定します。
イベントタイプ
inferred
|
|||
|
発注書の承認
|
発注書の最終承認を示します。承認後、仕入先に発注書を送付できます。通常は発注書のステータス変更から推定するか、ワークフロー履歴から直接取得します。 | ||
|
重要な理由
承認されるまで次の処理に進めないため、重要な節目です。承認のボトルネックを分析し、「発注書の承認サイクルタイム」重要業績評価指標(KPI)を測定するうえで欠かせません。
入手先
PurchTableのDocumentStateフィールドが「Approved」に変わったことから推定します。または、WorkflowTrackingStatusTableから最後の承認ステップの完了時刻を取得できます。
記録
PurchTableのDocumentStateが「Approved」に変わった時刻を特定します。
イベントタイプ
inferred
|
|||
|
発注書を仕入先に送付
|
承認済みの発注書が仕入先に送付されたことを示すアクティビティです。発注書の確定時に記録されます。確定すると確認仕訳が作成され、通常は文書の送付も開始されます。 | ||
|
重要な理由
仕入先とのやり取りが始まる最初の段階であり、仕入先のリードタイムの計測起点になります。仕入先の実績や「納期遵守率」重要業績評価指標(KPI)を追跡するうえで重要です。
入手先
PurchPurchaseOrderJourテーブル(発注書の確認仕訳)にレコードが作成された時点で記録されます。この仕訳の作成日がアクティビティの時刻になります。
記録
発注書に対する最初のPurchPurchaseOrderJourレコードの作成日時を使用します。
イベントタイプ
explicit
|
|||
|
購買依頼の作成
|
購買依頼の作成を示すアクティビティです。商品やサービスを正式に申請した時点にあたります。購買依頼テーブルに新しいレコードが作成されたときに記録され、調達需要の発生を示します。 | ||
|
重要な理由
発注書プロセスの最初のきっかけとなるイベントです。この時点から発注書の作成までにかかる時間を分析すると、社内プロセスの効率や需要への対応速度を測定できます。
入手先
PurchReqTableにレコードが作成されたことを示すイベントです。レコードの作成日時(createdDateTime)がイベント時刻になります。
記録
各購買依頼について、PurchReqTableから作成日時を抽出します。
イベントタイプ
explicit
|
|||
|
仕入先による発注書の確認
|
仕入先が発注書の内容を確認し、承諾したことを示します。多くの場合、仕入先からの連絡を受けて手動でデータを入力します。 | ||
|
重要な理由
仕入先から確認を得ることで、注文が処理されていることを確認できます。この段階で遅れや不一致があれば、納品に問題が生じる可能性があります。
入手先
通常は、PurchTableの納品確認日など、確認に関する日付フィールドやステータスフィールドに値が入力されたことから推定します。独立したイベントとして記録されない場合があります。
記録
PurchTableまたはPurchLineの特定の確認日フィールドに値が入力されたことから推定します。
イベントタイプ
inferred
|
|||
|
品質検査の実施
|
受領した商品の品質検査が完了したことを示します。多くの場合、品質管理モジュールまたはステータス更新で管理されます。 | ||
|
重要な理由
入荷から商品を使用できるようになるまでの間で、大きなボトルネックになる場合があります。所要時間を分析すると、「検査サイクル時間」重要業績評価指標(KPI)の改善に役立ちます。
入手先
発注書の入荷に関連付けられた品質オーダー(InventQualityOrderTable)の完了から推定できます。ステータスが「Passed」または「Failed」に変わった時刻がイベント時刻になります。
記録
発注書明細に関連付けられたInventQualityOrderTableで、ステータスが完了した時刻を追跡します。
イベントタイプ
inferred
|
|||
|
商品を仕入先に返品
|
破損や品違いなどの理由で、受領済みの商品を仕入先に返品したことを示します。返品取引を計上した時点で記録されます。 | ||
|
重要な理由
返品はプロセス上の問題や追加コストを示します。このアクティビティを追跡すると、「発注書返品率」を算出し、仕入先や商品の問題を特定できます。
入手先
数量がマイナスの発注書、または元の発注書を参照する返品注文書の作成から推定します。返品の計上日がイベント時刻になります。
記録
元の発注書に対する購買返品注文またはデビットノートの計上を特定します。
イベントタイプ
explicit
|
|||
|
発注書のキャンセル
|
発注書の処理が完了する前に終了したことを示します。発注書のステータスが特定の値に変わった時点で記録されます。 | ||
|
重要な理由
キャンセルは、通常とは異なるプロセス経路の1つです。発生頻度や理由を分析すると、計画上の問題や仕入先の信頼性に関する課題が見つかることがあります。
入手先
PurchTableのDocumentStateフィールドが「Canceled」に更新されたことから推定します。ステータスが変わった時刻がイベント時刻になります。
記録
PurchTableのDocumentStateが「Canceled」に設定された時刻を特定します。
イベントタイプ
inferred
|
|||
|
発注書の変更
|
承認後に発注書へ加えられた変更を記録するアクティビティです。Dynamics 365では発注書のバージョンを追跡できるため、変更を特定できます。 | ||
|
重要な理由
変更を追跡することは、手戻りの特定やプロセスの不安定さの把握、「発注書変更率」の測定に欠かせません。変更によって遅延やコストの変動が生じることがあります。
入手先
PurchTableHistoryなど、アーカイブテーブルやバージョン管理テーブルに保存された発注書の各バージョンを比較して推定します。バージョン番号が増えていれば、変更があったことを示します。
記録
承認後にPurchTableのバージョン番号が増加したレコードを特定します。
イベントタイプ
inferred
|
|||
|
発注書の請求書計上
|
仕入先の請求書を受領し、発注書に対して計上した時点を示します。このイベントによって調達プロセスと支払いプロセスが結び付きます。 | ||
|
重要な理由
支払い前の最終段階であり、購買の最終コストを算出するうえで重要です。三点照合を分析する際の終点になります。
入手先
発注書と照合された仕入先請求書仕訳(VendInvoiceJour)の計上から取得します。このレコードのInvoiceDateまたは計上日がイベント時刻になります。
記録
PurchTableレコードに関連付けられたVendInvoiceJourテーブルから計上時刻を使用します。
イベントタイプ
explicit
|
|||
|
発注書を承認に申請
|
発注書の下書きが正式に承認ワークフローへ申請された時点を示します。通常はユーザーが明示的に操作し、ワークフローログに記録されます。 | ||
|
重要な理由
このアクティビティを起点に、発注書の承認サイクルが始まります。追跡することで、承認待ちの時間と承認にかかる総時間を正確に測定できます。
入手先
発注書の申請イベントと時刻を記録するWorkflowTrackingStatusTableから取得します。
記録
PurchTableレコードに関連付けられたワークフロー履歴から「Submitted」イベントを特定します。
イベントタイプ
explicit
|
|||
|
購買依頼の承認
|
権限を持つマネージャーが購買依頼を正式に承認したことを示します。通常はワークフロー履歴ログから取得するか、依頼レコードのステータス変更を追跡して記録します。 | ||
|
重要な理由
承認は、購買依頼を発注書に移行するための重要な節目です。この段階での遅れは、調達全体の所要時間に直接影響します。
入手先
購買依頼に関連付けられたWorkflowTrackingStatusTableから取得できます。または、PurchReqTableのステータスフィールドが「Approved」に変わったことから推定できます。
記録
購買依頼のワークフロー履歴で、最後の承認ステップが完了した時刻を使用します。
イベントタイプ
explicit
|
|||
データ抽出ガイド
始める準備はできましたか?
このテンプレートを使って、調達から支払いまでの発注書プロセスの改善に必要な準備を整えられます。今日から調達業務の改善に取り組みましょう。
調達から支払いまでの発注書プロセスを今すぐ効率化
非効率な箇所を特定し、調達から支払いまでのサイクルタイムを最大30%短縮できます。
クレジットカード不要。数分で設定できます。