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