調達から支払いまで - 申請データテンプレート

NetSuite
調達から支払いまで - 申請データテンプレート

調達から支払いまで - 申請データテンプレート

このテンプレートは、貴社の購買から支払い(Purchase to Pay)および購買依頼(Requisition)プロセスの分析に必要な重要データポイントを収集するための明確なロードマップを提供します。追跡すべき重要な属性と主要なアクティビティを定義し、ソースシステムから情報を抽出するための実践的なガイダンスを提供します。このリソースを活用し、洞察に満ちたプロセスマイニングのためのイベントログを準備しましょう。
  • 収集を推奨する項目
  • プロセスディスカバリで追跡すべき主要な活動
  • データ抽出のガイダンス
イベントログについて初めての方へ: プロセスマイニングのイベントログ作成方法.

購買申請属性

これらは、購買申請プロセスの包括的な分析のためにイベントログに含めることを推奨するデータフィールドです。
3 必須 4 推奨 12 任意
名前 説明
アクティビティ名
ActivityName
購買申請のライフサイクル内で発生した特定のビジネスイベントまたはタスクの名前。
説明

「活動名」は、「申請書作成」「承認ステップ承認済み」「購買発注書作成」など、申請プロセスにおける個別のステップを記述します。これらの活動はプロセスマップの構成要素であり、実行されている作業を表します。

これらの活動を分析することで、プロセスフローの可視化、ボトルネックの特定、および異なるステージで費やされた時間の測定が可能になります。特定の購買申請IDに対する活動のシーケンスは、そのジャーニーを定義し、その後標準的な手順と比較して逸脱や非効率性を特定することができます。

その重要性

これはプロセスのステップを定義し、プロセスマップの可視化、プロセスバリアントの分析、ボトルネックの特定を可能にします。

取得元

これは通常、NetSuite内の取引ステータス、システムログエントリ、ワークフロー履歴、またはカスタムイベント追跡の組み合わせから導出されます。

採用申請作成済み承認ステップ承認済み申請書修正済み発注作成済み
イベント日時
EventTime
アクティビティが発生した正確な日時。
説明

イベント時間、すなわちタイムスタンプは、アクティビティが発生した正確な瞬間を記録します。この時間データは、その期間、イベントのシーケンス、およびタイミングを含む、申請プロセスのダイナミクスを理解するために不可欠です。

プロセス分析では、タイムスタンプはサイクルタイム、アクティビティ間の待機時間、およびサービスレベル契約への準拠を計算するために使用されます。これらはすべての時間ベース分析の基盤となり、「申請承認サイクルタイム」のようなダッシュボードや「平均申請サイクルタイム」のようなKPIの作成を可能にします。正確なタイムスタンプは、信頼性の高いプロセスモデルにとって不可欠です。

その重要性

このタイムスタンプは、サイクルタイムの計算、遅延の特定、プロセス効率の測定など、すべてのパフォーマンス関連分析の基盤となります。

取得元

この情報は、「作成日」のようなシステム生成フィールド、または各取引のシステムノートやワークフロー実行ログで利用可能なタイムスタンプに捕捉されます。

2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
購買依頼書ID
PurchaseRequisitionId
各購買申請書の一意の識別子であり、プロセス分析の主要なケースIDとして機能します。
説明

「購買申請ID」は、特定の商品またはサービスのリクエストに関連するすべての活動とイベントをリンクする中心的な識別子です。各申請書にはNetSuiteで作成時に一意のIDが割り当てられ、そのライフサイクル全体を通じて一定に保たれます。

プロセスマイニングにおいて、この属性はケース相関の基本となります。これにより、各申請書の初期作成からすべての承認ステップ、修正、そして承認、却下、購買発注書への変換といった最終結果までのエンドツーエンドのジャーニーを再構築できます。このIDでプロセスを分析することは、ライフサイクル期間の計算、ステータス変更の追跡、およびプロセスフローのバリエーションの特定に不可欠です。

その重要性

これは、単一の購買申請書の完全なライフサイクルを追跡するための不可欠なキーであり、プロセスフローの分析やケースレベルのメトリクス計算を可能にします。

取得元

これはNetSuiteにおける購買申請レコードの内部IDまたは取引番号です。通常、取引の「tranid」フィールドで見つけることができます。

PR-001254PR-001255PR-001256
リクエスター
Requester
購買申請書を作成し提出した従業員。
説明

「申請者」は、申請書を作成することで調達プロセスを開始する個人です。これは通常、業務を遂行するために特定の商品またはサービスを必要とする従業員です。

申請者ごとにデータを分析することは、ユーザー行動のパターンを特定するために不可欠です。却下率が高い、または修正頻度が高い個人を強調表示することで、「申請者パフォーマンスとトレーニングニーズ」のようなダッシュボードの構築に役立ちます。この洞察は、追加のトレーニングやより明確なガイドラインが初回提出の品質と全体的なプロセス効率を向上させる可能性がある領域を特定することができます。

その重要性

プロセス開始者を特定するもので、ユーザー行動、申請者ごとの却下率、トレーニングニーズの特定に不可欠です。

取得元

これは通常、購買申請取引レコードの「従業員」または「作成者」フィールドです。

John Smithジェーン・ドウPeter Jones
合計金額
TotalAmount
購買申請書の合計金額。
説明

この属性は、購買申請書に記載されているすべての品目の合計コストを捕捉します。これは、多くの場合、金額しきい値に基づいて異なる承認ワークフローをトリガーするなど、プロセス自体に影響を与える重要な財務データポイントです。

合計金額を分析することは、支出パターンと財務的影響を理解するのに役立ちます。金額で申請書をフィルタリングし、プロセス逸脱を高額なリクエストと関連付け、財務的に重要なケースの分析を優先することができます。これは、財務またはコンプライアンス関連のプロセス分析にとって基本的な属性です。

その重要性

財務的背景を提供し、金額に基づいた分析を可能にします。これは多くの場合、承認経路やビジネスの優先順位を決定します。

取得元

これは購買申請レコードの標準フィールドであり、多くの場合「合計」または類似のバリアントとして命名されます。

500.001250.7525000.00
申請ステータス
RequisitionStatus
申請書のライフサイクルにおける現在の状況を示します。
説明

「申請ステータス」は、ある時点での購買申請書がプロセス内のどこにあるかを示すスナップショットを提供します。一般的なステータスには、「承認待ち」「完全承認済み」「却下済み」「クローズ済み」などがあります。

この属性は、アクティブな申請書と現在の状態での滞留期間を追跡する「申請ステータスと滞留期間」のようなダッシュボードを作成する上で非常に重要です。ステータス遷移の分析は、プロセスの発見において重要な部分であり、ハッピーパスと例外の両方を理解するのに役立ちます。また、ケースの最終的な結果を判断するためにも使用されます。

その重要性

ケースの進捗状況のスナップショットを提供し、滞留申請の分析や、ケースがどこで滞っているかの特定を可能にします。

取得元

これは購買申請取引ヘッダーの「ステータス」または「承認ステータス」フィールドです。

承認待ち完全承認済み却下クローズ
部署
Department
申請書または申請者が所属する事業部門。
説明

「部門」属性は、購買申請書に関連付けられた組織単位を表し、通常は申請者の部門です。この情報は、組織の観点からプロセスをセグメント化して分析する方法を提供します。

これは、部門間の承認サイクルタイムの比較、支出パターンの理解、または却下率が最も高い部門の特定など、多くの分析において重要な側面です。このセグメンテーションは、経営陣がリソースを割り当て、トレーニングを調整し、特定の事業単位のワークフローを合理化するのに役立ちます。

その重要性

プロセスデータの強力なセグメンテーションを可能にし、異なる事業単位間でパフォーマンス、コスト、およびコンプライアンスを比較するために役立ちます。

取得元

この情報は、申請者の従業員レコードに関連付けられていることが多く、または購買申請書の取引ヘッダーに直接設定することもできます。

マーケティングIT財務運用
`購買発注`ID
PurchaseOrderId
承認済み申請書から作成された購買発注書の識別子。
説明

「購買発注書ID」は、承認済み申請書の結果として生成される購買発注書の一意の識別子です。この属性は、申請プロセスと後続の調達活動との間の重要なリンクとして機能します。

プロセス分析において、このリンクはエンドツーエンドのP2P分析に不可欠です。申請承認から発注書作成までの時間を測定することで、「発注書作成リードタイム」KPIの計算を可能にします。また、「申請書から発注書への変換率」の計算にも役立ち、申請書が実行可能な発注書にどの程度効果的に変換されているかについての洞察を提供します。

その重要性

申請書と結果として生成される購買発注書を連携させ、発注書作成のリードタイム測定とエンドツーエンドのプロセス分析を可能にします。

取得元

これは購買申請レコードにあり、多くの場合関連レコードのサブタブまたは購買発注書自体の「作成元」リンクにあります。

PO-005432PO-005433PO-005434
サイクルタイム
CycleTime
申請書の作成から最終解決までの経過時間。
説明

サイクルタイムは、単一ケースの購買申請プロセス全体の期間を測定する計算されたメトリックです。通常、最初の活動(例:「申請作成」)と最後の最終活動(例:「申請完全承認」または「申請最終却下」)の間の時間差として計算されます。

これは、プロセス全体の効率性を示す主要な重要業績評価指標(KPI)です。「平均申請サイクルタイム」KPIの計算に使用され、トレンド、外れ値、およびプロセス改善イニシアチブの影響を特定するのに役立ちます。サイクルタイム分布を分析することで、平均パフォーマンスを著しく低下させるロングテールな申請を明らかにできます。

その重要性

プロセスのエンドツーエンドの効率を直接測定するもので、遅延を特定し、全体的なパフォーマンスを評価するための主要なメトリックです。

取得元

これは計算された属性であり、各「PurchaseRequisitionId」の最後のイベントのタイムスタンプから最初のイベントのタイムスタンプを引くことで導出されます。

25920060480086400
ソースシステム
SourceSystem
データが抽出されたソースシステムを特定します。
説明

この属性は、プロセスデータの発生元システムを指定します。このケースではNetSuiteです。これは、複数のシステムからのデータが統合されて全体的なプロセスビューが作成される環境で特に有用です。

単一システム分析では静的に見えるかもしれませんが、重要なコンテキストを提供し、データガバナンスとトレーサビリティのためのベストプラクティスです。データの発生源を確認し、分析中にシステム固有のロジックや変換が正しく理解されることを保証するのに役立ちます。

その重要性

データの発生源に関する重要なコンテキストを提供し、特に複数システム環境において、明確さと適切なガバナンスを確保します。

取得元

これは、データ抽出および変換プロセス中に静的な値「NetSuite」として追加されるべきです。

NetSuiteNetSuite SuitePeopleNetSuite ERP
仕入先名
VendorName
申請書に提案された、または推奨されるベンダーの名前。
説明

「ベンダー名」属性は、商品またはサービスの購入元となるサプライヤーを特定します。申請書は内部文書ですが、推奨ベンダーが指定されることがよくあります。

この属性を分析することで、サプライヤー管理に関連するパターンが明らかになることがあります。どのベンダーが最も頻繁に要求されているか、特定のベンダーに対する申請書がより長い承認時間を要するかどうかを追跡し、推奨サプライヤー契約への準拠を確保するのに役立ちます。この情報は、戦略的ソーシングおよびベンダー関係管理にとって貴重なインプットとなります。

その重要性

サプライヤーごとの調達パターン分析に役立ち、優先ベンダーリストとのコンプライアンスを確保し、ベンダー固有のプロセスバリエーションを特定するのに貢献します。

取得元

これはヘッダーレベルの「ベンダー」フィールドであるか、購買申請レコードの明細行で指定される場合があります。

Dell Inc.ステープルズマッキンゼー・アンド・カンパニー
最終データ更新
LastDataUpdate
データがソースシステムから最後に抽出または更新された日時を示すタイムスタンプです。
説明

この属性は、NetSuiteからの最新のデータ抽出の日時を記録します。これは、あらゆるプロセスマイニングのダッシュボードや分析にとって重要なメタデータです。

このタイムスタンプは、データの鮮度に関するコンテキストを提供し、ユーザーがリアルタイムの情報を見ているのか、特定の時点のスナップショットを見ているのかを理解できるようにします。これは、データ検証およびプロセス分析から生成された洞察の適時性を利害関係者に伝えるために不可欠です。

その重要性

データの適時性をユーザーに伝え、プロセスの洞察がどの程度最新であるかを確実に理解してもらいます。

取得元

このタイムスタンプは、データの抽出、変換、ロード(ETL)プロセス中に生成・追加されます。

2024-05-21T08:00:00Z2024-05-20T08:00:00Z
却下理由
RejectionReason
承認者が申請書を却下した際に提供される説明。
説明

「却下理由」は、承認者が購買申請書が承認要件を満たさなかった理由を記述できるテキスト属性です。これは、「承認ステップ却下」活動に質的なコンテキストを提供します。

この情報は、根本原因分析にとって非常に貴重です。単に何が却下されたかだけでなく、その理由を示すことで、「申請書却下率分析」のようなダッシュボードを強化します。一般的な理由には、「GL勘定が不正確」「予算超過」「詳細不足」などが含まれます。これらの理由を分析することで、システム的な問題を特定し、ユーザーのトレーニングを改善し、提出ガイドラインを洗練させて手戻りや却下率を低減することができます。

その重要性

却下が発生する重要な背景を提供し、根本原因分析を可能にして将来の却下率を低減し、初回品質を向上させます。

取得元

これは却下アクション中の「メモ」フィールド、または承認ワークフローに追加されたカスタムフィールドで捕捉されることがよくあります。システムノートにも見つけることができます。

予算超過誤ったベンダーの選択品目詳細の欠落重複`申請`
品目カテゴリ
ItemCategory
申請書で要求されている商品またはサービスのカテゴリ。
説明

「品目カテゴリ」は、購買申請書に記載されている品目を「ITハードウェア」「事務用品」「プロフェッショナルサービス」などの論理的なグループに分類します。これは、申請書の明細行にリンクされている品目レコードから派生させることができます。

この属性により、申請プロセスをより深く、より詳細に分析することができます。「ITハードウェアの申請は、事務用品の申請よりも承認に時間がかかりますか?」といった疑問に答えるのに役立ちます。品目カテゴリごとにプロセスをセグメント化することで、企業はドメイン固有のボトルネックを発見し、カテゴリごとの支出を分析し、それに応じて調達戦略を調整することができます。

その重要性

購入されているものに基づいてプロセスの分析を可能にし、カテゴリ固有のボトルネックやコンプライアンス問題の特定に役立ちます。

取得元

この情報は、購買申請書の明細行レベルでリンクされている「品目」レコードから派生します。カテゴリ自体は、品目レコード上の標準フィールドまたはカスタムフィールドである場合があります。

ITハードウェアソフトウェアライセンスオフィス用品マーケティングサービス
手戻り
IsRework
申請が却下および再提出のサイクルを経たかどうかを示すブール値フラグです。
説明

「Is Rework」は、購買申請書がいずれかの時点で却下され、その後修正または承認のために再提出された場合にtrueに設定される派生ブール属性です。これは、標準的な「ハッピーパス」を超えて追加の作業や処理が必要だったケースを特定します。

この属性は、プロセスの非効率性の分析を簡素化します。「承認却下サイクル回数」KPIの計算に使用され、却下がプロセス全体に与える影響を定量化するのに役立ちます。「Is Rework」がtrueであるケースをフィルタリングすることで、アナリストは問題のあるプロセスバリアントを特定し、データ品質の低さやポリシーの誤解など、初期却下の根本原因を調査することができます。

その重要性

手戻りループの頻度と影響を定量化するのに役立ちます。これはプロセス非効率性と遅延の主要な原因です。

取得元

これは計算された属性です。論理は、同じケースに対して「承認のために申請書提出済み」活動の後に「承認ステップ却下済み」活動が発生するかどうかをチェックします。

truefalse
承認ワークフロー経路
ApprovalWorkflowPath
申請が経た承認ステップのシーケンスを表すものです。
説明

「承認ワークフローパス」は、特定の申請書に対する承認活動またはステータスのシーケンス(例:「提出済み」→「部長承認」→「財務承認」)を連結した派生属性です。これにより、各ケースが辿った経路のユニークなシグネチャが作成されます。

この属性は、適合性チェックとバリアント分析の基盤となります。これは、「コンプライアンス違反の申請経路」および「承認ワークフローパスのコンプライアンス」ダッシュボードを直接サポートし、正確なプロセスフローでケースをフィルタリングおよびグループ化することを容易にします。実際のパスを事前に定義された標準パスと比較することで、組織はコンプライアンスを定量化し、逸脱の根本原因を調査することができます。

その重要性

各ケースの承認ステップの正確なシーケンスを要約することで、強力なバリアント分析と適合性チェックを可能にします。

取得元

これは派生属性であり、各「PurchaseRequisitionId」について「活動名」の値を時系列順に連結することで計算されます。

作成済み > 提出済み > 承認済み作成済み > 提出済み > 却下済み > 修正済み > 提出済み > 承認済み作成済み > 提出済み > 承認済み > 取り消し済み
承認者
Approver
承認ステップの承認または却下に責任を持つ従業員またはユーザー。
説明

「承認者」は、承認ワークフローの特定の段階で購買申請書を審査し、対応する担当者です。1つの申請書に対して複数の承認者がいる場合があり、それぞれが異なる承認活動に関連付けられています。

この属性は、承認プロセス自体のパフォーマンスを分析するために不可欠です。「承認ステップサイクルタイム分布」のようなダッシュボードを作成するのに役立ち、個人またはグループのボトルネックを特定できます。誰が承認を行っているかを追跡することで、組織は説明責任を確保し、ワークロードのバランスを取り、特定の承認者によって引き起こされる遅延を特定することができます。

その重要性

承認タスクを実行しているユーザーを特定するもので、承認者のパフォーマンス、ワークロード、ボトルネックの特定を分析するための鍵となります。

取得元

この情報は、承認ステータスの変更に関連するワークフロー実行ログまたはシステムノートでよく見られます。承認ワークフローに関連するカスタムレコードフィールドに保存されている場合もあります。

サラ・ジェンキンスDavid Chen財務承認グループ
緊急度レベル
UrgencyLevel
申請の優先度分類(標準または緊急など)です。
説明

緊急度レベルは、購買依頼の業務上の優先度を示すカテゴリ別属性です。これにより、従業員は、重要な業務要件のため迅速な処理が必要な依頼にフラグを付けることができます。

この属性は、「緊急依頼処理パフォーマンス」ダッシュボードおよび「緊急依頼処理時間」KPIをサポートするために特別に設計されています。この属性に基づいてプロセスデータをフィルタリングすることで、アナリストは緊急依頼と通常依頼のサイクルタイムやプロセスパスを比較し、優先処理が効果的であるか、またはボトルネックが依然として遅延を引き起こしているかを判断できます。

その重要性

高優先度リクエストと標準リクエストのプロセスパフォーマンスを比較でき、重要なニーズが効率的に満たされることを保証します。

取得元

これは通常、購買依頼フォーム上のカスタムトランザクションボディフィールドとなります。

通貨
Currency
申請書の合計金額に対する通貨コード。
説明

「通貨」属性は、申請書の財務値がどの通貨(USD、EUR、GBPなど)で表示されているかを指定します。これは、複数の通貨で事業を行う多国籍企業にとって特に重要です。

このフィールドは、財務データが正しく解釈されることを保証します。プロセスマイニングでは、すべての金額を単一の基準通貨に変換するか、通貨別に分析をセグメント化することにより、金銭的価値の適切な集計と比較を可能にします。これにより、不正確な財務報告を防ぎ、グローバルな業務における明確性を確保します。

その重要性

多国籍企業における正確な財務分析に不可欠であり、金銭的価値が正確に解釈され、集計されることを保証します。

取得元

これは、特に複数通貨のNetSuiteインスタンスにおいて、購買申請取引レコードの標準「通貨」フィールドです。

USDEURGBP
必須 推奨 任意

購買申請活動

正確なプロセス発見とボトルネック特定のため、イベントログに記録すべき主要ステップとマイルストーンは次のとおりです。
5 推奨 6 任意
アクティビティ 説明
採用申請作成済み
ユーザーが新しい購買申請レコードを作成・保存することで、調達プロセスを開始します。これは申請ライフサイクルにおける最初のイベントであり、トランザクションレコードがNetSuiteに最初に保存されたときに捕捉されます。
その重要性

この活動は、特定のニーズに対する調達プロセスの公式な開始を示します。作成から提出までの時間を分析することで、データ入力の遅延や初期リクエスト作成における遅延が明らかになる可能性があります。

取得元

このイベントは、購買申請取引レコードの作成日タイムスタンプから取得されます。レコードのメインヘッダーまたは「作成」アクションを記録するシステムノートサブタブで見つけることができます。

取得

購買依頼レコードの「作成日」フィールドを使用します。

イベントタイプ explicit
申請書クローズ済み
申請書は正式にクローズされ、それ以上の行動が期待されないことを示します。これは通常、申請書に記載されたすべての数量がリンクされた購買発注書を介して発注された後に自動的に発生します。
その重要性

この活動は、申請書のライフサイクルの明確な終わりを示します。ビジネスニーズが満たされ、レコードが最終化されたことを確認します。

取得元

システムノートのサブタブから、明細レベルまたはヘッダーレベルの「ステータス」フィールドが「クローズ済み」に更新されたタイムスタンプを特定して推測されます。

取得

「ステータス」フィールドが「クローズ済み」に変更されたときのタイムスタンプ。

イベントタイプ inferred
申請書最終却下
購買申請書は決定的に却下され、これ以上処理されることはありません。このイベントは、申請書の最終的な「承認ステータス」が「却下済み」に更新されたときに推測されます。
その重要性

この活動は、失敗した申請書の重要な終着点です。申請書が最終的に却下される理由とタイミングを理解することで、ポリシーコンプライアンスや予算に関する洞察が得られます。

取得元

システムノートのサブタブから、「承認ステータス」フィールドが最終的な「却下済み」状態に設定されたタイムスタンプを特定して推測されます。

取得

「承認ステータス」が「却下済み」に変更されたときのタイムスタンプ。

イベントタイプ inferred
申請書完全承認済み
購買申請書は、承認ワークフローのすべての必須ステップを正常に完了します。これは、レコードの最終的な「承認ステータス」が「承認済み」に変更されたときに推測されます。
その重要性

これは、申請書が購買発注書に変換される準備ができたことを示す主要なマイルストーンです。これは承認サイクルの終わりと調達履行フェーズの開始を意味します。

取得元

システムノートのサブタブから、「承認ステータス」フィールドが最終的な「承認済み」状態に設定されたタイムスタンプを特定して推測されます。

取得

「承認ステータス」が「承認済み」に変更されたときのタイムスタンプ。

イベントタイプ inferred
発注作成済み
完全に承認された申請から購買オーダー(PO)が生成され、ベンダーに正式に資金をコミットします。これは、元の申請にリンクバックする新しいPOトランザクションの作成によってマークされる明示的なイベントです。
その重要性

これは、成功した申請書の主要な結果であり、購買から支払いまでのプロセスにおける重要な引き渡しポイントです。承認から発注書作成までの時間は、調達効率にとって重要なKPIです。

取得元

「Created From」または同様のリンクフィールドが購買申請IDを参照している購買オーダーレコードを見つけることで特定されます。そのPOの作成日がこのアクティビティのタイムスタンプとなります。

取得

「Created From」フィールドが申請IDと等しいPOを見つけ、POの「作成日」を使用します。

イベントタイプ explicit
承認ステップ却下済み
承認者が割り当てられたステップを却下する行為で、通常、修正のために申請を申請者に戻します。このアクションはSuiteApprovalsワークフローエンジンによって明示的にログに記録されます。
その重要性

このイベントは、手戻りやプロセスの非効率性の重要な指標です。却下ポイントを分析することで、ポリシー違反や誤ったデータなどの一般的な失敗原因を特定するのに役立ちます。

取得元

却下アクション、却下したユーザー、およびタイムスタンプを記録するSuiteApprovalsログまたはシステムノートサブタブから取得されます。

取得

SuiteApprovalsログまたはシステムノートで却下アクションを特定します。

イベントタイプ explicit
承認ステップ承認済み
権限のあるユーザーがワークフローで割り当てられたステップを承認する行為で、申請を最終承認に近づけます。NetSuiteのSuiteApprovalsプラットフォームは、このアクションをユーザーとタイムスタンプの詳細とともに明示的に記録します。
その重要性

この活動は、承認チェーンにおける前向きな進捗を表します。承認ステップ間の時間を分析することで、ワークフローと個々の承認者の効率を理解するのに役立ちます。

取得元

承認アクション、承認者、およびイベントの正確なタイムスタンプを記録するSuiteApprovalsログまたはシステムノートサブタブから取得されます。

取得

SuiteApprovalsログまたはシステムノートで承認アクションを特定します。

イベントタイプ explicit
承認ステップ開始済み
申請書は承認ワークフローの特定の段階に入り、指定された承認者またはグループからのアクションを待ちます。これは通常、ワークフローが申請書をシーケンス内の次の承認者に割り当てたときに推測されます。
その重要性

この活動は、個々の承認ステップごとの待機時間の始まりを示します。承認階層内のボトルネックを特定し、承認が遅い担当者を特定するために不可欠です。

取得元

ワークフロー実行ログ、または「現在の承認者」やワークフローステータスフィールドの変更から推測されます。SuiteApprovalsプラットフォームは、アクティブな承認ステップを追跡します。

取得

ワークフローログ、またはレコードが新しい承認者に割り当てられた時点から推測されます。

イベントタイプ inferred
承認のために申請書提出済み
申請者は、完成した申請書を正式に指定された承認ワークフローに提出します。これは多くの場合、申請レコードのステータス変更、例えば「ドラフト」や「提出待ち」から「承認待ち」への変更から推測されます。
その重要性

この活動は承認サイクルをトリガーし、承認リードタイムを測定するための重要な出発点となります。申請書が正式な承認プロセスを開始するまでどのくらいの期間待機しているかを特定するのに役立ちます。

取得元

システムノートのサブタブから、「承認ステータス」フィールドが初めて「承認待ち」のような値に変更されたタイムスタンプを特定して推測されます。

取得

「承認ステータス」フィールドが「承認待ち」に変わる最初のタイムスタンプを特定します。

イベントタイプ inferred
申請書修正済み
ユーザーが購買申請の初期作成後にいずれかのフィールドを修正する行為で、多くの場合、却下または要件変更に応じて行われます。このイベントはNetSuiteの監査証跡機能から直接捕捉されます。
その重要性

修正履歴を追跡することは、手戻りのループやデータ品質の問題を特定する上で非常に重要です。修正頻度が高い場合は、初期要件の不明確さや、申請者に対するトレーニングの必要性を示している可能性があります。

取得元

購買申請レコードのシステムノートサブタブから取得されます。関連フィールドにおける「タイプ」が「変更」または「編集」の各エントリは、修正を表します。

取得

システムノートログの「変更」タイプの各エントリに対してイベントを記録します。

イベントタイプ explicit
申請書取り下げ済み
元の申請者または管理者が、申請書が完全に承認されるか発注書に変換される前にキャンセルします。これは通常、「キャンセル済み」または「取り下げ済み」へのステータス変更から推測されます。
その重要性

この活動は、申請者によって開始されたプロセスの例外または終了を表します。取り下げを分析することで、ビジネスニーズの変化や無効になった申請書を浮き彫りにすることができます。

取得元

システムノートのサブタブから、「承認ステータス」フィールドが「キャンセル済み」やカスタムの取り下げステータスなどの値に更新されたタイムスタンプを追跡して推測されます。

取得

「承認ステータス」が「キャンセル済み」または「取り下げ済み」に変更されたときのタイムスタンプ。

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

抽出ガイド

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