調達から支払いまで:発注書のデータテンプレート

NetSuite
調達から支払いまで:発注書のデータテンプレート

調達から支払いまで:発注書のデータテンプレート

このテンプレートは、プロセスマイニングに必要なデータを準備し、調達から支払いまでの発注書プロセスを効果的に分析できるよう設計されています。必要なデータ項目や記録すべき主要なアクティビティを示し、NetSuiteからデータを抽出する方法も説明します。テンプレートに沿って準備を進めることで、データ準備の手間を減らし、改善につながるインサイトをより早く得られます。
  • 収集を推奨する属性
  • 記録すべき主要なアクティビティ
  • NetSuiteからのデータ抽出ガイド
イベントログを初めて作成する方はこちら: プロセスマイニング用イベントログの作成方法.

調達から支払いまで:発注書の属性

調達から支払いまでの発注書プロセスを詳しく分析するため、イベントログに含めることを推奨するデータ項目です。
5 必須 6 推奨 10 任意
名前 説明
アクティビティ名
ActivityName
発注書プロセスで発生した業務イベントまたはステップの名称です。
説明

この属性は、「発注書作成」「発注書承認」「請求書支払い」など、発注書のライフサイクルにおける具体的な操作やステータスの変化を示します。これらのアクティビティがプロセスマップのノードになります。

アクティビティの順序や発生頻度の分析は、プロセスマイニングの中心となる機能です。プロセスの流れを可視化し、よくある経路やまれな経路(バリアント)を特定して、ボトルネックや標準手順からの逸脱を見つけるのに役立ちます。

重要な理由

プロセスマップのステップを定義し、プロセスの流れ、バリアント、適合性チェックを可視化・分析できます。

入手先

通常、取引タイプとステータス項目(例:「注文ステータス」)の組み合わせ、またはNetSuiteのシステム監査証跡ログから取得します。

例
発注書を作成発注書を承認商品入庫を作成発注書から請求書を作成
イベント時刻
EventTime
アクティビティが発生した正確な日時です。
説明

このタイムスタンプは、特定のアクティビティが発生した正確な時点を示します。プロセスマイニングでパフォーマンスや所要時間を分析する際の基礎となります。

イベント時刻を使って、ケース内のアクティビティを時系列に並べ、ステップ間の所要時間やケース全体のサイクルタイムを算出します。ボトルネックの特定、待ち時間の測定、サービスレベル合意に対するパフォーマンスの分析にも欠かせないデータです。

重要な理由

サイクルタイムや所要時間など、プロセスの遅延を特定するうえで基本となる時間関連の指標を算出できます。

入手先

各取引やステータス変更に関連付けられたタイムスタンプです。NetSuiteでは、「作成日」などの項目やシステム監査証跡ログに記録されています。

例
2023-10-26T09:00:00Z2023-10-26T11:30:00Z2023-10-27T14:45:00Z
発注書
PurchaseOrder
発注書を一意に識別する番号で、調達プロセスを追跡するための主要なケースIDです。
説明

発注書番号は、最初の作成から最終的な支払い、クローズまで、関連するすべてのアクティビティを結び付ける中心的な識別子です。発注書番号ごとに、調達プロセスの1つのケースを表します。

プロセスマイニングでは、この属性を使って関連するすべてのイベントを1つのケースにまとめます。発注書ごとの流れを分析すると、プロセス全体を把握し、バリアントを特定できるほか、ケース単位のサイクルタイムなどの指標を算出できます。

重要な理由

各発注書のライフサイクル全体を再構成し、分析するために必要なケース識別子です。

入手先

通常、NetSuiteの発注書レコードにある主要な取引識別子で、「Transaction ID」または「PO #」と呼ばれることがあります。

例
PO-001254PO-001299PO-001357
ソースシステム
SourceSystem
データの抽出元となるシステムです。
説明

この属性は、プロセスデータの取得元を示します。このビューでは、値は常に「NetSuite」です。

複数のシステムのデータを組み合わせる大規模なプロセスマイニングでは、データの来歴の確認、問題の調査、システムごとの動作の把握に欠かせない項目です。各データの取得元を明確にできます。

重要な理由

プロセスデータの取得元を明確にし、特に複数のシステムを連携している環境でデータの来歴を確認できます。

入手先

データの抽出・変換時に追加する固定値(「NetSuite」)です。

例
NetSuite
最終データ更新日時
LastDataUpdate
このイベントのデータがソースシステムから最後に更新された日時を示すタイムスタンプです。
説明

この属性には、データが最後に抽出または更新された日時が記録されます。分析対象データの鮮度を把握するための情報です。

最終更新日時を確認すると、インサイトがどの時点のデータに基づいているかを把握できます。分析担当者や業務担当者は、最新のプロセスデータを見ているか確認できます。業務の状況を監視するダッシュボードでは、特に重要です。

重要な理由

データの鮮度を示します。分析やダッシュボードが最新の情報に基づいているか確認するために重要です。

入手先

データの抽出、変換、読み込み(ETL)の過程で生成・追加されるタイムスタンプです。

例
2024-05-21T02:00:00Z
ユーザー名
UserName
アクティビティを実行したユーザーの名前です。
説明

この属性は、発注書の承認や請求書の作成など、特定のプロセスステップを実行した従業員またはシステムユーザーを示します。プロセスを人またはシステムのリソース別に分析できます。

ユーザーごとにアクティビティを分析すると、業務負荷の分布やトレーニングの必要性を把握し、不規則な処理を見つけられます。また、発注書の変更や承認など、重要な操作を誰が行ったか追跡できるため、コンプライアンスの監視にも役立ちます。

重要な理由

アクティビティをユーザーごとに把握し、業務負荷やパフォーマンス、権限ポリシーへの準拠状況を分析できます。

入手先

取引レコードの「System Notes」または監査証跡のサブタブで確認できます。変更を行ったユーザーが記録されています。

例
Alice JohnsonBob Williamsシステム自動処理
仕入先名
VendorName
商品やサービスの購入先となる仕入先の名称です。
説明

この属性は、発注書の外部仕入先を示します。仕入先との関係やパフォーマンスを分析するための重要な項目です。

仕入先名は、「仕入先の納品実績」ダッシュボードや関連する重要業績評価指標(KPI)に欠かせません。仕入先ごとにプロセスを分類し、リードタイム、納期遵守率、品質検査の結果を比較できます。これにより、信頼できる仕入先やパフォーマンスに課題のある仕入先を特定できます。

重要な理由

仕入先ごとの納品期間や信頼性などを分析でき、サプライチェーンの改善に役立ちます。

入手先

NetSuiteの発注書レコードのメインタブにある「Vendor」または「Supplier」項目に対応します。

例
Global Office SuppliesTech Solutions Inc.Creative Marketing Agency
合計金額
TotalAmount
発注書の合計金額です。
説明

この属性は、発注書に含まれるすべての商品とサービスの合計金額を示します。調達分析の基本となる財務指標です。

合計金額別にプロセス指標を分析すると、金額の大きい発注書ほど承認に時間がかかる、または変更が多いといった傾向を把握できます。プロセスの非効率が財務に与える影響を理解し、改善の優先順位を決めるうえで役立ちます。

重要な理由

調達プロセスを財務面から分析し、発注書の金額がサイクルタイムや承認経路、コンプライアンスに与える影響を把握できます。

入手先

NetSuiteの発注書レコードの概要セクションにある「Total」項目に対応します。

例
500.001250.7515000.00
発注書ステータス
PurchaseOrderStatus
発注書の現在または最終のステータスです。
説明

この属性は、「承認待ち」「請求処理完了」「クローズ」など、特定の時点における発注書の状態を示します。多くの場合、「ActivityName」に相当するアクティビティの値を導き出すために使われます。

ステータス別に分析すると、却下と承認の件数や、未完了の発注書の件数など、発注書の結果を把握できます。「発注書承認失敗率」などの重要業績評価指標(KPI)の算出や、完了状況に基づくケースの絞り込みにも役立ちます。

重要な理由

発注書の状態を把握し、却下やクローズなどの結果を分析できます。承認失敗に関する重要業績評価指標(KPI)にも利用できます。

入手先

NetSuiteの発注書取引レコードにある「Status」項目です。

例
上長の承認待ち入庫待ち請求処理完了クローズ却下
購入カテゴリ
PurchaseCategory
購入する商品やサービスの分類です。例:IT機器、マーケティングサービス、事務用品。
説明

この属性は、発注書の品目を支出の種類ごとに分類します。NetSuiteでは、カスタム分類項目やセグメントとして設定されることがよくあります。

購入カテゴリ別の分析は、「購入カテゴリ別効率」ダッシュボードに欠かせません。購入の種類によってサイクルタイムや変更率、コンプライアンス上の問題に差があるかを把握し、支出分野ごとに改善策を検討できます。

重要な理由

支出カテゴリ別にプロセス効率を分析し、非効率またはコンプライアンスに準拠していない購入の種類を特定できます。

入手先

カスタム項目の場合や、「Class」などの標準分類セグメント、または発注書のヘッダーや明細行に適用するカスタムセグメントの場合があります。詳しくはNetSuiteの文書をご確認ください。

例
IT機器専門サービス事務用品ソフトウェアライセンス
部門名
DepartmentName
発注書に関連付けられた部門の名称です。
説明

この属性は、購入を申請した、または費用を負担する業務部門やコストセンターを示します。組織構造に基づいてプロセスデータを絞り込み、分類できます。

部門別のプロセス分析は、部門固有のボトルネックの特定、事業部門間の効率比較、支出傾向の把握に役立ちます。「部門別ボトルネック分析」などのダッシュボードにも直接利用できます。

重要な理由

部門別にプロセスを分析し、部門固有のボトルネックや非効率な点、支出傾向を特定できます。

入手先

NetSuiteの発注書レコードのヘッダーまたは明細行にある標準項目です。

例
財務ITサービスマーケティングオペレーション
イベント終了時刻
EventEndTime
アクティビティが終了した正確な日時です。
説明

このタイムスタンプは、アクティビティの完了時点を示します。開始時刻と組み合わせることで、イベントの処理時間を算出できます。瞬時に完了するイベントでは、終了時刻と開始時刻が同じ場合があります。

この属性は、処理時間と呼ばれる個々のタスクの正確な所要時間を算出するために必要です。タスクの実作業にかかった時間と、次のステップまでの待ち時間を区別できるため、ボトルネックを詳しく分析できます。

重要な理由

アクティビティの処理時間を正確に算出し、実作業時間と待ち時間を区別できます。

入手先

所要時間を測定できるアクティビティでは、別の項目に記録されている場合や、監査ログから算出できる場合があります。多くの場合、推定する必要があるか、開始時刻と同じ値になります。

例
2023-10-26T09:05:12Z2023-10-26T11:30:45Z2023-10-27T15:00:00Z
却下理由
RejectionReason
承認プロセスで発注書が却下された理由です。
説明

発注書が却下された場合、この属性には「予算超過」「仕入先の誤り」「ポリシー違反」など、具体的な理由が記録されます。承認に至らなかった原因を把握するための情報です。

「発注書の却下・再申請率」ダッシュボードに直接利用できます。却下理由を分析すると、トレーニング不足やポリシーの不明確さなど、発注書作成時によくある誤りの原因を特定し、却下に伴う手戻りを減らすための対策を講じられます。

重要な理由

発注書が承認されなかった理由を把握し、却下率の低減と初回承認率の向上に向けた対策を検討できます。

入手先

却下イベントのメモ項目、または承認ワークフローのカスタム項目「Rejection Reason」に記録されることがよくあります。詳しくはNetSuiteの文書をご確認ください。

例
部門予算を超過優先仕入先以外を選択明細行の説明が不完全
変更理由
ChangeReason
発注書の作成後に変更した理由です。
説明

この属性には、「価格改定」「数量変更」「納品日の変更」など、発注書を変更した理由が記録されます。手戻りの原因を把握するために必要な情報です。

「発注書変更分析」ダッシュボードで重要な属性です。変更理由ごとの発生頻度を分析すると、当初の要件が不正確だった、仕入先の価格が変動しやすいなど、プロセスが安定しない根本原因を特定できます。

重要な理由

発注書を変更した理由を把握し、根本原因を分析することで、発注書の変更率を下げるための改善策を検討できます。

入手先

承認済みの発注書を編集する際に入力を求めるカスタム項目や、変更イベントの「Memo」項目に記録される可能性があります。詳しくはNetSuiteの文書をご確認ください。

例
品目の数量誤り仕入先による価格変更納品要件の変更
希望納品日
RequestedDeliveryDate
商品やサービスの納品を仕入先に依頼した日付です。
説明

この属性は、購買プロセスで設定した納品予定日です。実際の納品状況を測る際のベースラインになります。

「仕入先納期遵守率」の重要業績評価指標(KPI)の算出に必要です。「希望納品日」と実際の「入庫記録作成」タイムスタンプを比較することで、仕入先が納期を守っているか分析できます。この結果は、「仕入先の納品実績」ダッシュボードにも利用できます。

重要な理由

仕入先の納期遵守状況を測る基準となり、サプライチェーン管理の重要業績評価指標(KPI)に利用できます。

入手先

カスタム項目、または発注書の明細行にある「Expected Receipt Date」の可能性があります。詳しくはNetSuiteの文書をご確認ください。

例
2023-11-152023-12-012024-01-10
手戻りの有無
IsRework
却下後の再承認など、アクティビティが手戻りにあたるかを示すフラグです。
説明

この計算済みの真偽値属性は、プロセスのループやステップの繰り返しを示すアクティビティでtrueになります。たとえば、同じケース内で「発注書却下」の後に「発注書承認」が発生した場合、後者は手戻りとして記録されます。

この属性は、プロセスの停滞や非効率を定量化するために必要です。手戻りのループを簡単に分析でき、「発注書の却下・再申請率」の測定や、初回で正しく処理されていないプロセスの特定に役立ちます。

重要な理由

手戻りのループに含まれるアクティビティを明示し、プロセスの非効率を定量化して、分析や対策を進めやすくします。

入手先

ケース内のアクティビティの順序を分析し、データ変換時にこのフラグを算出します。

例
truefalse
正規手続き外の購入の有無
IsMaverickBuy
先行する購買申請なしで発注書が作成されたかを示すフラグです。
説明

プロセスの最初のアクティビティが「購買申請作成」ではなく「発注書作成」の場合、ケース単位でtrueに設定される計算済みの真偽値属性です。標準手順に沿わない調達を直接示します。

この属性は、「調達コンプライアンス監視」の重要業績評価指標(KPI)である「直接発注率」の算出に使われます。正規手続き外の購入をすばやく特定・定量化できます。こうした購入は、コスト増やリスクの高まりにつながる可能性があります。

重要な理由

コンプライアンスに準拠しない購入を直接特定し、組織が正規手続き外の購入を監視・削減しやすくします。

入手先

計算属性です。ロジック:(ケース内の最初のアクティビティ=「発注書作成」)かつ(「購買申請」との関連付けがない)。

例
truefalse
納品先
DeliveryLocation
商品を納品する物理的な場所または住所です。
説明

この属性は、発注書で注文した商品の納品先を示します。倉庫、オフィス、工場などを指定できます。地域や拠点ごとにプロセスを分類できます。

「入庫処理時間」ダッシュボードで重要な分析軸となります。納品先別に入庫時間を分析すると、人員不足や入庫プロセスの非効率が疑われる拠点を特定し、対象を絞った業務改善につなげられます。

重要な理由

場所別にプロセスのパフォーマンスを分析し、入庫などのアクティビティにおける拠点固有のボトルネックを特定できます。

入手先

NetSuiteの発注書レコードにある「Ship To」住所または「Location」項目に対応します。

例
中央倉庫-Aドック本社-15階西海岸配送センター
納期遅延の有無
IsLateDelivery
希望納品日より後に商品を受領したかどうかを示すフラグです。
説明

「入庫記録作成」アクティビティが、発注書に指定された「希望納品日」より後に発生した場合にtrueとなる、計算済みの真偽値属性です。納期遵守状況を簡潔に示します。

この属性を使うと、仕入先のパフォーマンスに関するダッシュボードや重要業績評価指標(KPI)を作成しやすくなります。簡単に絞り込みや集計ができ、「仕入先納期遵守率」の算出や、納期を継続的に守れていない仕入先の特定に役立ちます。

重要な理由

納期遵守をtrue/falseで示すため、仕入先管理におけるパフォーマンス分析や重要業績評価指標(KPI)の算出が容易になります。

入手先

計算項目です。ロジック:(「入庫記録作成」のタイムスタンプ)>(「RequestedDeliveryDate」)。

例
truefalse
購買申請
PurchaseRequisition
発注書の前段階にあたる購買申請の識別子です。
説明

この属性は、発注書を元となる購買申請に関連付けます。この関連付けがない場合、標準プロセスから逸脱している可能性があります。

コンプライアンスの監視や、正規の手続きを経ない購入の特定に欠かせない項目です。「直接発注率」は、購買申請との関連付けがない発注書を確認して算出します。標準の承認ワークフローを経ずに行われた購入を把握できます。

重要な理由

承認済みの購買申請を経ずに発注書が作成された購入を特定できるため、コンプライアンス分析に役立ちます。

入手先

発注書レコードの「Related Records」サブタブまたは「Created From」項目で確認できることが一般的です。

例
PR-00582PR-00610PR-00715
通貨
Currency
取引金額の通貨コードです。
説明

この属性は、発注書の合計金額に使われている通貨(USD、EUR、GBPなど)を示します。金額を正しく解釈するために必要な情報です。

複数の国や地域で事業を展開する組織では、正確な財務報告と分析に欠かせません。地域をまたいだ発注書の金額を適切に集計・比較でき、金額に関する重要業績評価指標(KPI)を正しく解釈できます。

重要な理由

金額の通貨を明確にし、複数通貨を扱う環境で正確な財務分析と報告を行えます。

入手先

発注書レコードの「Currency」項目に対応します。仕入先の設定によって決まる場合があります。

例
USDEURGBP
必須 推奨 任意

調達から支払いまで:発注書のアクティビティ

プロセスを正確に把握し、ボトルネックを特定するために、イベントログに記録する主要なプロセスの手順と節目です。
6 推奨 8 任意
アクティビティ 説明
商品入庫を作成
発注書で注文した商品が実際に入庫したことを示すアクティビティです。NetSuiteでは明示的なイベントとして記録され、「商品入庫」の取引レコードが作成され、該当する発注書の明細に関連付けられた時点で確認できます。
重要な理由

この重要な節目は、仕入先からの納品サイクルの終了を示します。仕入先の納期遵守率や全体のリードタイムを算出するうえで欠かせません。

入手先

商品入庫の取引レコードの作成日から記録します。レコードには、元の発注書へのリンクが含まれます。

記録

商品入庫の取引レコードの作成タイムスタンプを追跡します。

イベントタイプ explicit
発注書から請求書を作成
仕入先から請求書を受領し、発注書に関連付けてNetSuiteに登録した状態です。受領した商品やサービスに対する債務を正式に記録する取引です。
重要な理由

このアクティビティは、調達から買掛金処理への移行を示します。入庫から請求書の登録までの時間を分析すると、財務処理の遅延を把握できます。

入手先

仕入先請求書の取引レコードの作成日から記録します。請求書は元の発注書に直接関連付けられます。

記録

仕入先請求書の取引レコードの作成タイムスタンプを追跡します。

イベントタイプ explicit
発注書をクローズ
発注書が正式にクローズされ、以降の入庫や請求書が予定されていない状態です。発注書のステータスが「クローズ」に変わった時点で推定します。すべての入庫と請求処理の完了後に自動で変わる場合と、手動で変更される場合があります。
重要な理由

このアクティビティは、発注書のライフサイクルにおける業務上の終了点です。注文の履行と処理が完了したことを確認でき、サイクルタイム分析の明確な終点になります。

入手先

発注書レコードの「ステータス」フィールドが「クローズ」に変わったことから推定します。

記録

発注書の「ステータス」フィールドが「クローズ」に変わったことを検出します。

イベントタイプ inferred
発注書を作成
正式な発注書が作成されたことを示すアクティビティです。この分析の中心となるケースです。NetSuiteでは、手動で作成した場合も、承認済みの購買申請から作成した場合も、発注書の取引レコードが作成された時点で記録されます。
重要な理由

依頼が正式な発注に切り替わる重要な段階です。プロセスの主要な節目となり、購買申請を経由しない発注書ではプロセスの開始点にもなるため、コンプライアンスの監視に役立ちます。

入手先

発注書の取引レコードにあるシステムフィールド「作成日」から記録します。

記録

発注書の取引レコードの作成タイムスタンプを使用します。

イベントタイプ explicit
発注書を承認
発注書が正式に最終承認され、仕入先に送付できる状態を示します。発注書の「承認ステータス」フィールドが「承認済み」に更新された時点で記録する、重要な節目です。
重要な理由

承認サイクルタイムの算出と承認経路のボトルネック特定に欠かせない節目です。ここでの遅延は、調達のリードタイムに直接影響します。

入手先

発注書レコードの「承認ステータス」フィールドが「承認済み」に変わったことを記録したシステムノートまたはワークフロー履歴から推定します。

記録

発注書の「承認ステータス」フィールドが「承認済み」に変わったことを検出します。

イベントタイプ inferred
購買申請を作成
商品やサービスの正式な依頼を示すアクティビティで、調達プロセスの開始点です。NetSuiteでは、新しい購買申請の取引レコードが作成され、保存された時点で記録されます。
重要な理由

通常、プロセスの開始点となるこのアクティビティは、開始から完了までのサイクルタイム全体を分析するうえで重要です。省略されている場合は、規定外の購買を特定する手がかりにもなります。

入手先

購買申請の取引レコードの作成日から、このイベントを記録します。レコードは後続の発注書に関連付けられます。

記録

購買申請の取引レコードの作成タイムスタンプを追跡します。

イベントタイプ explicit
品質検査を実施
入庫した商品に品質検査が実施された状態です。NetSuiteの標準取引ではないため、通常はカスタムフィールドの更新やカスタムレコード、または商品入庫のステータス変更から記録します。
重要な理由

このアクティビティを追跡すると、品質管理プロセスのサイクルタイムを測定できます。検査が遅れると、入庫から商品を利用できるようになるまでの間にボトルネックが生じることがあります。

入手先

記録方法はカスタマイズ内容によって大きく異なります。商品入庫のカスタムフィールド「品質保証ステータス」や、「品質検査」の個別カスタムレコードから記録できる場合があります。

記録

品質検査に関連するカスタムフィールドの更新、またはカスタムレコードの作成を追跡します。

イベントタイプ inferred
発注書を仕入先に送信
承認済みの発注書が仕入先に送信された状態です。NetSuiteでは、「メール送信予定」チェックボックスなどの連絡用フラグが更新された時点や、送信済みを示すステータスに変わった時点から推定できます。
重要な理由

このアクティビティは仕入先のリードタイムの開始点です。この時点から入庫までの時間を測定すると、仕入先の納品実績を評価できます。

入手先

「メール送信予定」または「FAX送信予定」フラグが解除された時点のタイムスタンプ、または発注書に関連付けられた連絡履歴から推定します。

記録

発注書に関連付けられた連絡イベント(メール送信など)のタイムスタンプを追跡します。

イベントタイプ inferred
発注書を却下
承認者が発注書を却下したため、修正して再申請する必要がある状態です。発注書の「承認ステータス」フィールドが「却下」に変更された時点で、このイベントを推定します。
重要な理由

却下を追跡すると、手戻りの発生や承認されない理由を把握し、最初に提出する発注書の品質を改善できます。

入手先

発注書レコードの「承認ステータス」フィールドが「却下」に変わったことを記録したシステムノートまたはワークフロー履歴から推定します。

記録

発注書の「承認ステータス」フィールドが「却下」に変わったことを検出します。

イベントタイプ inferred
発注書を変更
発注書の作成後または承認後に変更が加えられたことを示します。「最終更新日」を「作成日」または別途記録された承認日と比較して推定できます。
重要な理由

頻繁な変更は、非効率や初期計画の不備、要件の拡大を示している可能性があります。変更の時期と理由を分析すると、プロセスの効率化やミスの削減に役立ちます。

入手先

発注書レコードの「最終更新日」を作成または承認のタイムスタンプと比較して推定します。システムノートには、変更された具体的なフィールドが記録されます。

記録

「最終更新日」を作成日または承認日と比較し、システムによる更新は除外します。

イベントタイプ inferred
発注書を申請
発注書が確定され、承認ワークフローに申請された状態です。通常は発注書レコードのステータス変更から記録します。たとえば、「上長の承認待ち」などの下書き状態から、確認中の状態に変わった時点です。
重要な理由

このイベントは承認サイクルの開始を示します。この時点から「発注書を承認」までの時間を測定することで、承認の効率を分析し、遅延を特定できます。

入手先

発注書レコードの「承認ステータス」フィールドの変更から推定します。たとえば、「承認待ち」またはカスタムの下書きステータスからの変更です。

記録

発注書の「承認ステータス」フィールドが審査中の状態に変わったことを検出します。

イベントタイプ inferred
請求書の支払いを実行
請求金額が仕入先に支払われた状態です。「仕入先支払い」の取引が作成され、仕入先請求書に適用された時点で記録します。
重要な理由

このアクティビティは、発注書に関する金銭債務の履行を示します。期日どおりの支払い状況やキャッシュフローを分析するうえで重要です。

入手先

仕入先請求書に適用された仕入先支払いの取引レコードの作成日から記録します。

記録

請求書に適用された仕入先支払いの取引レコードの作成タイムスタンプを追跡します。

イベントタイプ explicit
請求書を承認
仕入先からの請求書が確認され、支払いの承認を受けた状態です。発注書と同様に、仕入先請求書レコードの「承認ステータス」フィールドの変更から記録します。
重要な理由

請求書の承認は支払いプロセスの重要な段階です。所要時間を追跡すると、支払いの遅延や早期支払い割引の機会損失につながる買掛金処理のボトルネックを特定できます。

入手先

仕入先請求書レコードの「承認ステータス」フィールドが「承認済み」に変わったことを記録したシステムノートまたはワークフロー履歴から推定します。

記録

仕入先請求書の「承認ステータス」フィールドが「承認済み」に変わったことを検出します。

イベントタイプ inferred
購買申請を承認
商品やサービスの依頼が正式に承認され、発注書を作成できる状態を示します。購買申請レコードの「承認ステータス」フィールドが「承認待ち」から「承認済み」に変わったことから、このイベントを推定します。
重要な理由

購買申請の承認を追跡すると、調達前の段階にあるボトルネックを特定し、社内での申請確認の効率を測定できます。

入手先

購買申請レコードの「承認ステータス」フィールドの変更を記録したシステムノートまたはワークフロー履歴から推定します。

記録

購買申請の「承認ステータス」フィールドが「承認済み」に変わったことを検出します。

イベントタイプ inferred
推奨 任意

データ抽出ガイド

NetSuiteからデータを取得する方法

準備を始めましょう

このテンプレートは、調達から支払いまでの発注書プロセスの可能性を引き出すための第一歩です。データの準備を始め、効率化できる箇所を特定して改善につなげましょう。

発注書処理を効率化:NetSuiteの業務を今すぐ改善

プラットフォームで発注書のサイクルタイムを30%短縮し、ボトルネックを解消しましょう。

無料トライアルを開始

クレジットカードは不要です。今日から業務改善を始めましょう。