データテンプレート:受注から現金化までのプロセス - 販売注文処理
貴社の受注から入金までの受注処理データテンプレート
- 詳細分析に推奨の属性
- プロセス内で追跡すべき主要なアクティビティ
- NetSuiteのための実践的なデータ抽出ガイド
Order to Cash - 販売注文処理属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
特定の時点に発生したビジネスイベントまたはアクティビティの名前。 | ||
|
説明
この属性は、「販売オーダー作成」、「商品出荷済み」、「支払い受領済み」など、販売オーダーライフサイクル内の特定のステップまたはステータス変更を記述します。これらのアクティビティのシーケンスがプロセスマップの基礎を形成します。 アクティビティの流れを分析することで、一般的なプロセスパス、逸脱、およびボトルネックを特定できます。アクティビティの頻度と順序を理解することは、業務効率化と手作業の削減の機会を特定するために不可欠です。
その重要性
これはプロセスの各ステップを定義し、プロセスフローの可視化と分析を可能にします。
取得元
これは通常、NetSuite内のシステムステータスの変更、伝票タイプ、または特定のイベントログから導出されます。多くの場合、ステータスフィールドや伝票作成イベントを標準化されたアクティビティ名にマッピングする必要があります。
例
販売注文作成済み販売注文承認済み商品発送済み請求書作成支払い受領済み
|
|||
|
イベント日時
EventTime
|
アクティビティの発生時刻を示すタイムスタンプです。 | ||
|
説明
この属性は、プロセス内の各アクティビティの正確な日時を提供します。これはイベントログの時間軸の基盤であり、各ステップ間のサイクルタイム、期間、および待機時間の算出を可能にします。 正確なタイムスタンプは、受注作成から出荷までの時間測定や信用承認プロセスにおける遅延の特定など、パフォーマンス分析に不可欠です。これにより、プロセス効率の詳細な分析やサービスレベル契約 (SLA) 遵守の確認が可能になります。
その重要性
タイムスタンプは、サイクルタイムや期間を含むすべての時間ベースのメトリクスの計算に不可欠であり、プロセスボトルネックを特定するために極めて重要です。
取得元
これは、NetSuiteのトランザクションレコードにある日付フィールドに対応しています。例えば、受注伝票の「作成日」、品目フルフィルメントの「実際の出荷日」、請求書や支払いの「日付」などです。
例
2023-04-15T10:00:00Z2023-04-15T14:30:00Z2023-04-16T09:00:00Z
|
|||
|
販売注文
SalesOrder
|
各販売オーダードキュメントの一意の識別子です。 | ||
|
説明
販売オーダーは、顧客からの発注から商品配送、最終的な支払いまでのすべてのアクティビティを紐づける主要なケース識別子として機能します。それぞれの販売オーダーは、エンドツーエンドプロセスの個別のインスタンスを表します。 プロセスマイニングにおいて、この属性は各オーダーのジャーニーを再構築するための基本となります。これにより、オーダーごとにプロセスバリアント、サイクルタイム、ボトルネックを分析し、個々の顧客リクエストのライフサイクル全体像を把握できます。
その重要性
これは、関連するすべてのイベントを単一のプロセスインスタンスに繋ぎ合わせ、エンドツーエンドの分析を可能にする主要な識別子です。
取得元
これはNetSuiteにおける販売オーダー伝票の内部IDです。通常、販売オーダーフォームまたは検索結果で「Internal ID」として確認できます。
例
SO-100521SO-100522SO-100523
|
|||
|
オーダー合計金額
TotalOrderAmount
|
販売オーダーの総金額です。 | ||
|
説明
この属性は、すべての商品、税金、送料を含む受注伝票の総財務価値を表します。これは、各プロセスインスタンスの経済的重要性を測る上で不可欠な指標です。 受注金額に基づいてプロセスを分析することで、重要なパターンが明らかになることがあります。例えば、高額な受注はより手動の承認プロセスを経る一方、低額な受注は高度に自動化されている場合があります。この分析は、最も影響の大きい受注に対してプロセス改善の取り組みを優先するのに役立ちます。
その重要性
価値ベースの分析を可能にし、高価値の注文を優先し、プロセスの効率が収益にどのように影響するかを理解するのに役立ちます。
取得元
これはNetSuiteの販売オーダー伝票にある「Total」フィールドです。
例
1500.00250.5012500.75
|
|||
|
ユーザー
User
|
アクティビティを実行したユーザーまたは従業員です。 | ||
|
説明
この属性は、オーダーを作成した営業担当者や商品を梱包した倉庫作業員など、特定のプロセスステップの実行責任者を特定します。これは、ユーザー名または一意のIDである場合があります。 ユーザー別に分析することで、ワークロードの分散を理解し、トレーニングニーズを特定し、個人間またはチーム間のパフォーマンスを比較するのに役立ちます。特定のユーザー行動に関連する逸脱や遅延を調査する際の根本原因分析において非常に重要です。
その重要性
従業員や役割ごとのパフォーマンス分析を可能にし、優秀な人材、自動化候補、トレーニング機会を特定するのに役立ちます。
取得元
この情報は、NetSuiteの様々なトランザクションレコードにある「作成者」、「最終更新者」、または「所有者」のようなフィールドで確認できます。
例
John Smithジェーン・ドウ倉庫担当者1
|
|||
|
希望納期
RequestedDeliveryDate
|
顧客が要求した納期。 | ||
|
説明
この属性は、顧客が商品の受領を希望した日付を記録します。これは、納期厳守を測定するための重要業績評価指標のベースラインとして機能します。 この日付は、実際の配送日(出荷済みのタイムスタンプ)と比較され、納期遵守率のKPIが計算されます。希望配送日と実際の配送日のギャップを分析することで、予測、在庫管理、ロジスティクスにおける顧客の期待を満たせないシステム的な問題を特定するのに役立ちます。
その重要性
オンタイム配送のパフォーマンスおよび顧客満足度を測定するための基準となります。
取得元
これは販売オーダーレコード上の標準またはカスタムフィールドに対応する可能性があり、多くの場合「Requested Delivery Date」などと名付けられています。
例
2023-05-202023-06-012023-06-15
|
|||
|
支払条件
PaymentTerms
|
請求書の支払いに関する合意された条件。 | ||
|
説明
この属性は、顧客が商品またはサービスの支払いをいつ行うべきか、例えば「Net 30」や「受領時払い」などの支払い条件を定義します。これらの条件は、請求書支払い期日の計算に使用されます。 支払い条件別に分析することで、どの条件が遅延支払いと関連しているかを特定し、企業が信用ポリシーの財務的影響を評価できるようになります。これは、「支払い条件遵守率」ダッシュボードを分析し、キャッシュフローダイナミクスを理解するための基本となります。
その重要性
支払期日の計算、顧客の支払行動および遵守率の分析の基礎を提供します。
取得元
これは、NetSuiteの受注伝票または請求書トランザクションレコードにある「支払条件」フィールドです。
例
支払条件:正味30日支払条件:正味60日受領時支払い
|
|||
|
製品カテゴリ
ProductCategory
|
販売注文における主要な製品またはサービスのカテゴリ。 | ||
|
説明
この属性は、販売オーダー上の品目を「ハードウェア」、「ソフトウェア」、「サービス」などの広範なカテゴリに分類します。オーダーに複数のカテゴリが含まれる場合、価値または品目数に基づいて主要なカテゴリが割り当てられることがあります。 製品カテゴリ別にプロセスを分析することで、フルフィルメントパスのバリエーションを発見できます。例えば、サービスは、ピッキング、梱包、出荷が必要な物理的なハードウェアよりもはるかにシンプルなフルフィルメントプロセスを持つ場合があります。このセグメンテーションは、カテゴリ固有のプロセス改善を設計する上で重要です。
その重要性
プロセスを製品カテゴリ別にセグメント化することで、異なるフルフィルメント経路が明らかになり、カテゴリ固有のボトルネックを特定するのに役立ちます。
取得元
この情報は、受注明細にリンクされた「品目」レコードから派生します。カテゴリを取得するためには、品目マスターデータとの結合が必要となる場合があります。
例
電子機器ソフトウェアライセンスコンサルティングサービス
|
|||
|
請求書番号
InvoiceNumber
|
顧客請求書の一意の識別子です。 | ||
|
説明
この属性は、受注伝票から生成された請求書ドキュメントの参照番号です。これにより、販売履行プロセスと売掛金管理プロセスが連携されます。 請求書番号の追跡は、財務照合や、受注から最終支払いまでの広範な分析にとって重要です。商品の出荷という業務活動と、現金回収という財務活動との具体的な連携を確立します。
その重要性
これは、受注伝票を請求のための特定の財務取引に連結し、真のエンドツーエンドのOrder to Cash分析を可能にします。
取得元
これは、受注伝票から作成された請求書レコードの「請求書番号」または「トランザクションID」です。
例
INV-2001INV-2002INV-2003
|
|||
|
販売注文ステータス
SalesOrderStatus
|
ライフサイクルにおける販売注文の現在のステータス。 | ||
|
説明
この属性は、「承認待ち」、「フルフィルメント待ち」、「請求済み」など、販売オーダーの現在の状態を示します。これは、オーダーが全体プロセスのどこにあるかを示すスナップショットを提供します。 アクティビティログは履歴フローを示しますが、現在のステータスは、現在停滞しているオーダーやアクティブなオーダーをフィルタリングして焦点を当てるのに役立ちます。最終ステータス別にケースを分析することで、オーダーが正常にクローズされたか、キャンセルされたか、またはまだ進行中であるかなど、プロセス結果を理解するのに役立ちます。
その重要性
これは、ケースを現在の状態に基づいてフィルタリングできるため、未処理のオーダーの分析や、ブロックまたは遅延しているオーダーの特定に極めて重要です。
取得元
これは、NetSuiteの受注伝票トランザクションレコードにある「ステータス」フィールドです。
例
フルフィルメント保留中請求保留中請求済みクローズ
|
|||
|
顧客名
CustomerName
|
販売注文を行った顧客の名前。 | ||
|
説明
この属性には、商品またはサービスを購入した法人または個人の名前が含まれます。これは、販売オーダープロセスを特定の顧客アカウントに紐付けます。 顧客ごとのフィルタリングまたはディメンション分析は、顧客固有の行動を理解し、主要アカウントに影響を与える問題を特定し、サービスレベルを評価するために不可欠です。これにより、プロセスを顧客中心の視点で捉えることができ、どの顧客が最も多くの遅延や手戻りを経験しているかを明らかにします。
その重要性
プロセスを顧客ごとにセグメント化することで、顧客満足度の分析、主要顧客における問題の特定、およびサービスの調整が可能になります。
取得元
これは、NetSuiteの受注伝票トランザクションレコードにある「顧客」または「エンティティ」フィールドです。
例
Global Corp Inc.Innovate Solutions Ltd.ダイナミックテック
|
|||
|
ソースシステム
SourceSystem
|
データの出所となったシステムを特定します。 | ||
|
説明
この属性は、イベントデータが生成されたソースアプリケーションを特定します。このプロセスでは、通常「NetSuite」となります。より複雑な環境では、個別のCRMやWMSなど、さまざまな統合システムから来るデータを区別するのに役立ちます。 分析においては、データリネージの確認に役立ち、複数のソースからのデータを統合して単一の統一されたプロセスビューを作成する際に極めて重要です。これにより、データがその出所に正しく帰属されることが保証され、データガバナンスとトラブルシューティングにとって重要です。
その重要性
複数のシステムが統合された環境において、データの発生源に関する重要なコンテキストを提供します。
取得元
これは、データ抽出および変換プロセス中に付加される静的な値(「NetSuite」)です。
例
NetSuite
|
|||
|
与信ステータス
CreditStatus
|
受注伝票の与信保留ステータスを示します。 | ||
|
説明
この属性は、受注処理時点での顧客の信用ステータス(例:「ホールド中」または「承認済み」)を反映します。これは受注ライフサイクルの初期段階における重要な要素です。 この属性を分析することで、与信チェックが全体的な受注サイクルタイムに与える影響を理解するのに役立ちます。「信用チェックサイクルタイム分析」ダッシュボードは、このデータに基づいて、どれだけの受注がホールドされ、解除にどれくらいの時間がかかっているかを特定し、信用管理プロセスにおけるボトルネックを浮き彫りにします。
その重要性
「与信チェックサイクルタイム」というKPIに直接影響し、注文プロセスの初期段階における遅延を説明するのに役立ちます。
取得元
これは販売オーダーレコード上の標準ステータスフィールドまたはカスタムチェックボックス(例:「Credit Hold」)である可能性があります。「Credit Hold Applied」および「Credit Hold Released」のアクティビティの存在から推測することも可能です。
例
良好保留中リリース済み
|
|||
|
最終データ更新
LastDataUpdate
|
ソースシステムからの最終データ更新・抽出のタイムスタンプ。 | ||
|
説明
この属性は、データセットが最終更新された日時を示します。これにより、ビジネスユーザーは分析しているデータの鮮度を明確に把握し、プロセスマイニングのダッシュボードや分析が対象とする期間を確実に理解できます。 これはプロセスフロー分析には使用されませんが、データガバナンスとユーザーからの信頼を確保する上で不可欠なメタデータ要素です。ユーザーはインサイトの最新性を評価し、いつ新しいデータが反映されるかを把握するのに役立ちます。
その重要性
データの適時性についてユーザーに通知し、これは分析に基づいた意思決定を行う上で不可欠です。
取得元
このタイムスタンプは、NetSuiteからのデータ抽出時に生成され、データセットに付与されます。
例
2023-10-27T02:00:00Z
|
|||
|
出荷国
ShippingCountry
|
出荷先の国。 | ||
|
説明
この属性には、オーダーの商品が出荷される国が含まれます。これは、販売オーダーに関連付けられた配送先住所から導出されます。 配送国に基づいた地理的分析は、ロジスティクス、関税、または地域オフィスの効率によって生じるプロセスパフォーマンスのバリエーションを明らかにすることができます。これにより、異なる国や地域間での配送時間、配送精度、プロセスコストを比較することが可能になります。
その重要性
地域ごとのボトルネックを特定し、ロジスティクスパフォーマンスを比較し、国際的な複雑さを理解するための地理的分析を可能にします。
取得元
これは、受注伝票トランザクションレコードの「配送先住所」の一部です。
例
米国ドイツ日本
|
|||
|
営業チーム
SalesTeam
|
販売オーダーを担当する営業チームまたはグループです。 | ||
|
説明
この属性は、販売を担当するチームまたは部門を特定します。これは、営業担当者を組織し、営業テリトリーや製品ラインを管理するために使用されます。 プロセスマイニングにおいて、営業チーム別にパフォーマンスを分析することで、高業績チームからベストプラクティスを発見したり、特定のチームに影響を与えるシステム的な問題を特定したりできます。これは、データ入力品質、割引承認、または下流のフルフィルメントプロセスに影響を与えるその他の上流要因の違いを浮き彫りにすることができます。
その重要性
異なる営業チーム間のパフォーマンス比較を可能にし、ベストプラクティスやサポートが必要な領域を特定するのに役立ちます。
取得元
これは販売オーダーレコード上の標準またはカスタムフィールドであり、多くの場合、営業担当者の従業員レコードにリンクされています。
例
北米営業EMEAエンタープライズAPACチャネル
|
|||
|
支払期日
PaymentDueDate
|
請求書の支払期日です。 | ||
|
説明
この属性は、請求書日付と支払条件に基づいて算出される、顧客の支払期日です。例えば、4月1日付けの請求書で「ネット30日」の場合、支払期日は5月1日となります。 この日付は財務分析にとって極めて重要であり、「支払い受領」日と直接比較することで、支払いが期限内に行われたかどうかが判断されます。「期日内支払率」KPIの算出や売掛金管理の重要な要素です。
その重要性
これは、キャッシュフローと売掛金の管理に不可欠な、支払期日遵守率を測定するためのベンチマークです。
取得元
これは、請求書トランザクションレコードの「期日」フィールドです。請求書日付と支払条件に基づいてNetSuiteによって自動的に算出されます。
例
2023-05-302023-06-152023-07-01
|
|||
|
期日通りに支払い済み
IsOnTimePayment
|
請求書が期日までに支払われたかどうかを示すフラグです。 | ||
|
説明
この算出されたブール型属性は、「支払い受領」タイムスタンプと「支払期日」を比較します。支払いが期日までに完了していれば真、それ以外の場合は偽となります。 この属性は、「期日内支払率」KPIと「支払条件遵守率」ダッシュボードの基盤となります。顧客の支払行動を明確に測定し、どの顧客、地域、または支払条件が支払遅延に最も関連しているかを分析できるようにします。
その重要性
顧客の支払い規律を直接測定するもので、キャッシュフロー管理と信用リスク評価にとって極めて重要です。
取得元
これは、データ変換中に「支払い受領」アクティビティのタイムスタンプと「支払期日」属性を比較することで算出されます。
例
truefalse
|
|||
|
期日通りに配達されているか
IsOnTimeDelivery
|
注文が依頼された期日までに配送されたかどうかを示すフラグです。 | ||
|
説明
この算出されたブール型属性は、「商品出荷」または実際の配送タイムスタンプと「要求配送日」を比較します。配送が期限内または早期であれば真、遅延していれば偽となります。 このフラグは、「期日内配送率」KPIの算出や、「配送約束と現実のギャップ」ダッシュボードの機能提供に不可欠です。配送パフォーマンスの分析を簡素化し、特定の製品、地域、またはプロセスボトルネックなど、遅延出荷の原因を特定するための簡単なフィルタリングと集計を可能にします。
その重要性
配送実績について明確な二値的な結果を提供し、KPIの算出と遅延注文の根本原因分析を簡素化します。
取得元
これは、データ変換中に「商品出荷」アクティビティのタイムスタンプと「要求配送日」属性を比較することで算出されます。
例
truefalse
|
|||
|
販売注文タイプ
SalesOrderType
|
標準、緊急、特別などの販売注文の分類。 | ||
|
説明
この属性は、販売オーダーをそのタイプに基づいて分類します。これにより、多くの場合、プロセスパスと優先度が決定されます。例えば、緊急オーダーは特定のステップをスキップしたり、通常オーダーよりも厳格なSLAが適用されたりする場合があります。 オーダータイプ別にプロセスを分析することは、異なるプロセスバリアントが意図的かつ効果的であるかを理解するために非常に重要です。特定のオーダータイプに対する特別処理手順が、実際により速いまたはより良い結果をもたらしているのか、そしてそのコストがどの程度であるかを評価するのに役立ちます。
その重要性
標準注文と緊急注文など、意図された異なるプロセス経路を比較することで、それらが期待どおりに機能しているかを確認できます。
取得元
これは通常、販売オーダーフォーム上のカスタム「Order Type」フィールドです。NetSuiteはデフォルトで単一のタイプフィールドではなく、異なる伝票フォーム(例:Standard Sales Order、Standard Sales Order - Cash Sale)を使用するためです。
例
通常注文緊急注文プロジェクト注文
|
|||
|
販売注文変更回数
SalesOrderChangeCount
|
販売注文が初回作成後に変更された回数。 | ||
|
説明
この算出された指標は、各ケースにおける「受注変更」アクティビティの発生回数をカウントします。変更回数が多いことは手戻りを示しており、顧客からの要求、データ入力ミス、価格調整などが原因となることがあります。 この属性は、「受注手戻り率」KPIおよび「受注手戻りバリアント」ダッシュボードへの直接的な入力となります。変更回数が多い受注の特性を分析することで、特定の製品、顧客、または営業担当者に関する問題など、手戻りの根本原因を特定するのに役立ちます。
その重要性
手戻り作業を直接定量化し、非効率の原因、データ品質の問題、プロセスの不安定性を特定するのに役立ちます。
取得元
これは、データ変換中に各「SalesOrder」ケースIDに対する「受注変更」イベントをカウントすることで算出されます。
例
013
|
|||
Order to Cash - 販売注文処理アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
商品発送済み
|
このマイルストーンは、商品が倉庫から出荷され、顧客に向けて発送された瞬間を示します。これは「Item Fulfillment」レコードのステータスが「Shipped」に更新された際に推測されます。 | ||
|
その重要性
出荷は、運送業者と顧客への重要な引き渡し点です。このイベントは、定時配送実績の追跡や、総注文履行リードタイムの測定に不可欠です。
取得元
リンクされた「品目履行」トランザクションの「ステータス」フィールドが「発送済み」に変更されたことから推測されます。このイベントのタイムスタンプは、このステータス変更の日付です。
取得
Item Fulfillmentレコードにおけるステータスが「Shipped」に変更されたタイムスタンプ。
イベントタイプ
inferred
|
|||
|
支払い受領済み
|
このアクティビティは、顧客から請求書に対する支払いが受領されたことを示します。これは、顧客支払いトランザクションが作成され、販売オーダーに関連付けられた請求書に適用されたときに捕捉されます。 | ||
|
その重要性
主要な最終イベントとして、この活動はキャッシュコンバージョンサイクルと期日通りの支払いパフォーマンスを分析する上で極めて重要です。これは、販売取引の財務的な成功を意味します。
取得元
これは明示的なイベントです。タイムスタンプは、該当する請求書に適用された「顧客支払い」トランザクション(Transactionテーブル、Type='CustPymt')の作成日です。
取得
Invoiceに適用されたCustomer Paymentレコードの伝票日付を使用します。
イベントタイプ
explicit
|
|||
|
注文フルフィルメント作成済み
|
このアクティビティは、倉庫での物理的なフルフィルメントプロセスの開始を示します。これは、販売オーダーから品目フルフィルメントトランザクションが生成されたときに発生します。 | ||
|
その重要性
これは、販売プロセスと倉庫業務を連携させる重要なマイルストーンです。受注承認からフルフィルメント作成までの時間は、運用準備状況の主要な指標となります。
取得元
これは明示的なイベントです。タイムスタンプは、「品目フルフィルメント」レコードの作成日であり、これはソースの受注伝票にリンクされます。
取得
リンクされたItem Fulfillmentレコードには伝票作成日を使用します。
イベントタイプ
explicit
|
|||
|
請求書作成
|
これは、出荷された商品またはサービスに対する財務インボイスの作成を表します。販売オーダーにリンクされた「Invoice」伝票の作成によってトリガーされる明示的なイベントです。 | ||
|
その重要性
このアクティビティは、収益認識における重要なマイルストーンであり、支払いサイクルの開始を示します。出荷と請求書発行の間の時間は、キャッシュフローに直接影響を与えます。
取得元
これは、請求書トランザクションレコード(Transactionテーブル、Type='CustInvc')の「作成日」フィールドから捕捉され、受注伝票にリンクされる明示的なイベントです。
取得
リンクされたInvoiceには伝票作成日を使用します。
イベントタイプ
explicit
|
|||
|
販売注文クローズ済み
|
これは、販売オーダーが完全に履行され、請求も完了したことを示す最終アクティビティです。販売オーダーのステータスが「Closed」に変更されたことから推測されます。 | ||
|
その重要性
このイベントは、受注ライフサイクルの運用上の終了を示します。作成からクローズまでの期間は、エンドツーエンドのプロセス期間の全体像を提供します。
取得元
Sales Order(受注伝票)トランザクションの「ステータス」フィールドが「クローズ済み」に変更されたことから推測されます。この最終ステータス変更のタイムスタンプはシステムノートから取得されます。
取得
販売オーダーのシステムノートにおけるステータスが「Closed」に変更されたタイムスタンプ。
イベントタイプ
inferred
|
|||
|
販売注文作成済み
|
このアクティビティは、販売オーダープロセスの正式な開始を示します。これは、新しい販売オーダートランザクションがNetSuiteに初めて保存され、初期の顧客リクエストが捕捉されたときに発生します。 | ||
|
その重要性
これは受注から入金までのプロセスにおける主要な開始イベントです。このイベントから後続のアクティビティまでの時間を分析することは、全体的なオーダー処理効率とサイクルタイムを測定するために不可欠です。
取得元
これは、受注伝票トランザクションレコード(Transactionテーブル、Type='SalesOrd')の「作成日」フィールドから捕捉される明示的なイベントです。
取得
販売オーダーには伝票作成日を使用します。
イベントタイプ
explicit
|
|||
|
販売注文承認済み
|
このマイルストーンは、販売オーダーが与信や在庫などのすべての内部チェックを通過し、履行準備が整ったことを示します。これは通常、オーダーステータスが「Pending Fulfillment」に変更されることで推測されます。 | ||
|
その重要性
承認はプロセスにおける重要なゲートウェイです。承認までの時間を測定することで、内部レビューや意思決定における遅延を特定できます。
取得元
Sales Order(受注伝票)レコードのステータス変更から推測されます。タイムスタンプは、「注文ステータス」フィールドが「履行保留中」または類似のカスタム承認済みステータスに更新されたときに記録されます。
取得
販売オーダーのシステムノートにおけるステータスが「Pending Fulfillment」に変更されたタイムスタンプ。
イベントタイプ
inferred
|
|||
|
クレジットメモ作成
|
このイベントは、受注伝票または請求書に対してクレジットメモが発行されたときに発生します。これは通常、返品、価格調整、またはその他の割引・譲歩のために行われます。「クレジットメモ」トランザクションが作成された際に捕捉されます。 | ||
|
その重要性
クレジットメモは、しばしば出荷エラーや製品不良などのプロセス上の失敗を示します。その発生頻度とタイミングを分析することで、根本原因を特定し、全体的な品質向上に役立ちます。
取得元
これは、「クレジットメモ」トランザクション(Transactionテーブル、Type='CredMemo')の作成に基づいた明示的なイベントであり、元の請求書または受注伝票にリンクすることができます。
取得
リンクされたCredit Memoには伝票作成日を使用します。
イベントタイプ
explicit
|
|||
|
ピッキング済み
|
注文品目が倉庫の保管場所からピッキングされたことを示します。これは、関連する「品目履行」レコードのステータス変更に基づいた推測されたイベントです。 | ||
|
その重要性
商品のピッキングにかかる時間を分析することは、倉庫の効率を最適化する上で不可欠です。この活動により、ピッキングプロセスにおけるボトルネックを測定し特定できます。
取得元
リンクされた「品目履行」トランザクションの「ステータス」フィールドが「ピッキング済み」に変更されたことから推測されます。このステータス変更のタイムスタンプはシステムノートから取得されます。
取得
Item Fulfillmentレコードにおけるステータスが「Picked」に変更されたタイムスタンプ。
イベントタイプ
inferred
|
|||
|
与信保留解除済み
|
販売注文が与信保留から解除され、出荷処理に進むことができる時点を表します。これは、保留ステータスからオープンまたは承認済みステータスへのステータス変更を観察することで捉えられます。 | ||
|
その重要性
与信保留期間は重要なKPIです。このイベントにより、与信問題の解決にかかる時間と、それが受注から入金までの全体的なサイクルに与える影響を測定できます。
取得元
Sales Order(受注伝票)レコードのシステムノートまたは監査証跡から推測され、「注文ステータス」が保留状態から変更された時点のタイムスタンプを捕捉します。
取得
注文ステータスが与信保留状態からアクティブ状態に変わった時点のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
与信保留適用済み
|
このイベントは、受注伝票が自動的または手動で信用ホールドにされ、フルフィルメントプロセスが一時停止されたときに発生します。これは通常、受注ステータスが「承認待ち」または特定の「信用ホールド」状態に変化したことから推測されます。 | ||
|
その重要性
注文がいつ、なぜ保留されたのかを特定することは、履行サイクルにおける遅延を理解する上で重要です。このアクティビティは、顧客の信用問題に関連するボトルネックを浮き彫りにします。
取得元
Sales Order(受注伝票)レコードのシステムノートまたは監査証跡から推測され、特に「注文ステータス」フィールドが保留ステータスに変更されたかどうかを調べます。
取得
注文ステータスが与信保留状態に変わった時点のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
在庫コミット済み
|
このイベントは、受注伝票のために在庫が正式に引当された時点を示し、フルフィルメントに利用可能であることを保証します。これは受注明細の「引当済数量」の変更を監視することで推測されます。 | ||
|
その重要性
このアクティビティは、在庫割り当て効率を分析するために非常に重要です。オーダー承認から在庫引き当てまでの遅延は、在庫切れを引き起こし、納期約束に影響を与える可能性があります。
取得元
Sales Order(受注伝票)の明細項目に関するシステムノートから推測されます。タイムスタンプは、「コミット済み数量」フィールドがゼロから正の値に更新された時点に対応します。
取得
オーダーラインの「Quantity Committed」フィールド変更のタイムスタンプ。
イベントタイプ
inferred
|
|||
|
梱包済み
|
ピックアップされた品目が梱包され、出荷準備が完了したことを示します。これは、Item Fulfillment(品目履行)レコードのステータスがPacked(梱包済み)に変更されたことを追跡することで捕捉されます。 | ||
|
その重要性
このアクティビティは、梱包ステーションの効率を測定するのに役立ちます。ピッキングと梱包の間の期間を分析することで、キャパシティ制約やプロセス非効率性を明らかにすることができます。
取得元
リンクされた「品目履行」トランザクションの「ステータス」フィールドが「梱包済み」に変更されたことから推測されます。この更新のタイムスタンプはシステムノートから記録されます。
取得
Item Fulfillmentレコードにおけるステータスが「Packed」に変更されたタイムスタンプ。
イベントタイプ
inferred
|
|||
|
販売注文変更済み
|
このアクティビティは、販売オーダーが作成された後に発生した、数量、品目、価格などの重要な変更を記録します。これは、システムノートまたは監査証跡の更新を追跡することで捕捉されます。 | ||
|
その重要性
頻繁な変更は、データ入力エラーや不安定な顧客需要を示唆する可能性があり、手戻りやプロセス上の非効率性を引き起こします。これらの変更を追跡することで、注文変更の根本原因を特定するのに役立ちます。
取得元
販売注文取引に関連するシステムノートまたは監査証跡から導き出されます。関連するフィールドへのログに記録された変更はそれぞれ、この活動のインスタンスとして扱われます。
取得
初期作成後のSales Order(受注伝票)システムノートにおけるフィールド変更を特定します。
イベントタイプ
inferred
|
|||