返品・返金処理データテンプレート
返品・返金処理データテンプレート
- 推奨されるデータ収集フィールド
- 追跡すべき主要なプロセスステップ
- データ抽出のガイダンス
返品・返金処理属性
| 名前 | 説明 | ||
|---|---|---|---|
| イベント日時 EventTime | 特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプ。 | ||
| 説明 イベントタイム、つまりタイムスタンプは、活動が発生した正確な日時を記録します。イベントログ内の各活動には対応するタイムスタンプがあり、イベントの時系列順序を提供します。 この属性は、すべての時間ベースのプロセスマイニング分析にとって重要です。活動間のサイクルタイムの計算、待機時間とボトルネックの特定、全体的なケース期間の測定、およびサービスレベル契約(SLA)への準拠の確認に使用されます。タイムスタンプの精度は、パフォーマンス分析の信頼性に直接影響します。 その重要性 このタイムスタンプは、サイクルタイムや待機時間など、パフォーマンス分析の基本となるすべての期間ベースのメトリクスを計算するために不可欠です。 取得元 注文作成のための「SalesTable.createdDateTime」や倉庫ジャーナルのための「WMSJournalTrans.createdDateTime」など、さまざまなテーブルの作成日または変更日フィールドに対応します。 例 2023-10-26T10:00:00Z2023-10-26T14:30:15Z2023-10-27T09:05:42Z | |||
| 返品案件ID ReturnCaseId | 顧客の返品・返金案件の一意の識別子。関連するすべてのアクティビティをリンクします。 | ||
| 説明 返品案件IDは、個々の返品プロセスインスタンスの主要な識別子として機能します。これは、返品注文の最初の作成から最終的なクローズまで、特定の顧客の返品または返金リクエストに関連するすべてのアクティビティをリンクします。 プロセス分析において、このIDは各返品のエンドツーエンドのジャーニーを再構築するための基本です。これにより、完全なライフサイクルを追跡し、合計サイクル時間を測定し、異なる案件間のバリエーションを分析することができます。すべてのイベント、データ、およびメトリクスは、この識別子を使用して集約および相関されます。 その重要性 これはすべてのプロセスステップを結びつける必須の案件識別子であり、各返品を最初から最後まで追跡・分析することを可能にします。 取得元 これは通常、「販売とマーケティング」モジュールにおける返品承認(RMA)番号、または「返品注文」タイプの販売注文番号です。「SalesType」が「Returned Order」である「SalesTable」のようなテーブルに見られます。 例 RMA-001234RMA-001235RMA-001236 | |||
| アクティビティ名 ActivityName | 返品および返金プロセス内で発生した特定のビジネスイベントまたはタスクの名前。 | ||
| 説明 この属性は、「返品注文作成済み」、「商品受領済み」、「クレジットノート転記済み」など、返品・返金ライフサイクルにおける特定のステップまたはイベントを記述します。各アクティビティは、システムに記録されるプロセスの明確なポイントを表します。 これらのアクティビティの順序と頻度を分析することは、プロセスマイニングの核となります。これにより、プロセスマップの可視化、ステップ間のボトルネックの特定、および一般的・まれなプロセスバリアントの発見が可能になります。アクティビティのセットは、分析対象のプロセスの範囲を定義します。 その重要性 プロセスのステップを定義し、プロセスフローの可視化、ボトルネック、手戻り、逸脱の特定を可能にします。 取得元 これはシステムイベントから派生した概念的な属性です。'SalesTable'や'WMSJournalTable'のようなテーブルのステータス変更、または特定のイベントログをユーザーフレンドリーな名前にマッピングすることで生成できます。 例 返品注文作成済み品目受領済み処理コードが適用されたクレジットノート転記済み | |||
| 担当ユーザー ResponsibleUser | 特定の活動を実行した、または責任を負うユーザーまたは従業員。 | ||
| 説明 この属性は、プロセスステップの実行を担当する個々のユーザーを識別します。それは、商品を受け取った倉庫作業員、品質検査員、またはクレジットノートを転記した財務担当者である可能性があります。 ユーザーごとのプロセス分析は、ワークロードの分散を理解し、トップパフォーマーを特定し、潜在的なトレーニングニーズを検出するのに役立ちます。また、特定の個人やチームが処理したケースを調査し、職務分掌が適切に行われていることを確認するためにも使用できます。 その重要性 ワークロードの配分、個人またはチームごとのパフォーマンスの分析、トレーニングやリソース配分の機会の特定を可能にします。 取得元 「SalesTable.createdBy」やジャーナルテーブルのリンクされたユーザーIDなど、トランザクションレコードの「作成者」または「変更者」フィールドで見つけることができます。 例 アリス・Wボブ・Jクリス・P | |||
| 製品ID ProductId | 返品される製品の一意の識別子。 | ||
| 説明 製品ID(多くの場合SKU)は、お客様が返品する特定のアイテムを識別します。各返品注文明細は製品IDに関連付けられています。 製品ごとの返品を分析することは、返品率の高いアイテムを特定するために不可欠です。これは、品質管理の問題、不正確な製品説明、または製造上の欠陥を示している可能性があります。この分析は、製品関連の調査と改善の優先順位付けに役立ちます。 その重要性 商品ごとの返品分析を可能にし、品質問題のある商品や返品数の多い商品を特定するのに役立ちます。 取得元 これは、返品注文の'SalesLine'テーブルにある'ItemId'フィールドに対応します。 例 SKU-A-123SKU-B-456SKU-C-789 | |||
| 返品チャネル ReturnChannel | お客様が返品を開始した方法またはチャネル。 | ||
| 説明 この属性は、お客様が返品プロセスを開始するために使用したチャネルを指定します。例えば、「オンラインポータル」、「店舗内」、「カスタマーサービスコール」、「郵送」などです。 返品チャネルごとにプロセス分析をセグメント化することは、各チャネルのパフォーマンスと効率を評価するのに役立ちます。企業は、チャネル間のサイクルタイム、コスト、顧客満足度を比較することで、ベストプラクティスや投資・改善すべき領域を特定できます。これは、「返品チャネル利用パフォーマンス」ダッシュボードにとって重要です。 その重要性 異なる返品チャネル間のパフォーマンス比較を可能にし、最も効率的で費用対効果の高いチャネルを最適化するのに役立ちます。 取得元 この情報は、返品注文ヘッダー('SalesTable')に保存されるか、注文を作成したユーザーから派生する場合があります。カスタムロジックまたは専用フィールドが必要になることがあります。 例 Webポータル店内キオスクカスタマーサポート | |||
| 返品理由コード ReturnReasonCode | お客様が商品を返品した理由。 | ||
| 説明 返品理由コードは、「不良品」、「サイズ違い」、「説明と異なる」、「不要になった」など、お客様が表明した返品理由を捕捉します。この情報は通常、返品が開始される際に収集されます。 返品理由の分析は、根本原因分析にとって非常に重要です。これにより、企業は製品の品質問題、製品説明の問題、または物流上のエラーを特定するのに役立ちます。このデータからのインサイトは、将来の返品を減らすために、製品設計、マーケティング、およびサプライチェーン運用の改善を推進することができます。 その重要性 返品が発生する理由に関する重要な洞察を提供し、根本原因分析を可能にすることで、返品率の低減と顧客満足度の向上に貢献します。 取得元 これは通常、返品注文明細レベルに保存されます。返品注文の'SalesLine'テーブルで理由コードフィールドを探してください。 例 欠陥WRONG_ITEM不要輸送中の破損 | |||
| 退院区分コード DispositionCode | 商品の検査結果と次に取るべきアクションを示すコードです。 | ||
| 説明 ディスポジションコードは、返品された商品の品質検査中に割り当てられます。これは、'Credit'(返金)、'Replace'(交換)、'Scrap'(廃棄)、または'Return to Customer'(顧客へ返送)など、その後のプロセスステップを決定します。 この属性は、返品プロセスにおける重要な意思決定ポイントです。ディスポジションコード別に分析することで、企業は返品の結果を理解し、商品の廃棄による財務的影響を追跡し、交換と返金のような異なる解決パスの効率を評価することができます。 その重要性 このコードは、検査後に返品案件がたどるパスを決定するため、プロセスバリアントとそのビジネス成果を分析する上で重要です。 取得元 これは品質管理モジュールの主要フィールドです。品質オーダーまたは検査オーダー処理に関連付けられています。 例 CRDTREPL-DSCRAPRTV | |||
| SLAステータス SlaStatus | ケースがサービスレベル契約目標内に解決されたかどうかを示します。 | ||
| 説明 この計算された属性は、SLA遵守の簡易ステータス(通常「期日内」または「遅延」)を提供します。これは、最終アクティビティ(例:「返品注文クローズ済み」)のタイムスタンプと「RefundSlaTargetDate」を比較することによって決定されます。 この属性は、「返金解決SLAパフォーマンス」のようなダッシュボードでのパフォーマンスレポート作成を簡素化します。ユーザーが日付を比較する必要なく、直接的で理解しやすいステータスを提供します。これにより、迅速なフィルタリングと集計が可能になり、全体的な「解決SLA遵守率」を計算できます。 その重要性 SLA遵守状況をひと目でわかるように示すシンプルな指標を提供し、遅延ケースを簡単にフィルタリングして遅延の根本原因を分析できます。 取得元 これは派生属性であり、最終解決アクティビティのタイムスタンプを「RefundSlaTargetDate」属性と比較して計算されます。 例 期日どおり遅延 | |||
| クレジットノートID CreditNoteId | 返金のために作成されたクレジットノート文書の一意の識別子。 | ||
| 説明 返金が処理されると、クレジットノートまたはクレジットメモとして知られる財務文書が生成されます。この属性は、その文書の一意のIDを格納します。 このIDは、運用上の返品プロセスから会計システムの財務記録への直接リンクを提供します。監査目的や財務上の差異の詳細な調査に役立ち、アナリストは返品案件を決済した特定の財務取引まで追跡することができます。 その重要性 運用上の返品プロセスを対応する財務取引にリンクさせ、監査と財務調整にとって非常に重要です。 取得元 クレジットノート番号は通常、'CustInvoiceJour'テーブルの'InvoiceId'フィールドにあります。ここで取引タイプは'Credit note'です。これは返品注文にリンクして遡ることができます。 例 CN-10056CN-10057CN-10058 | |||
| ソースシステム SourceSystem | イベントデータが抽出された情報システム。 | ||
| 説明 この属性は、データが発信されたソース情報システムを識別します。このコンテキストでは、主に「Microsoft Dynamics 365」となります。 大規模な組織では、プロセスが複数のシステムにまたがる場合があります。各イベントのソースシステムを指定することは、データガバナンス、データ抽出の問題のトラブルシューティング、およびプロセスの技術的ランドスケープを理解するために非常に重要です。これにより、分析対象データの出所が確認されます。 その重要性 データの出所に関する重要なコンテキストを提供し、データガバナンス、検証、およびプロセスのシステムランドスケープの理解にとって不可欠です。 取得元 これは通常、データ抽出、変換、ロード(ETL)プロセス中に、データセットの発生源を識別するために追加される静的な値です。 例 Microsoft Dynamics 365 F&OD365-PROD | |||
| ポリシー準拠 IsPolicyAdherent | 返品承認が確立された返品ポリシーに準拠しているかを示すフラグです。 | ||
| 説明 これは、返品が会社の返品ポリシーで定義されたすべての基準を満たしているかどうかを示す計算されたブール属性です。これは、返品期間、商品の状態、返品理由などの要因に基づく場合があります。 この属性は、「返品承認コンプライアンス概要」ダッシュボードおよび「コンプライアンス準拠返品承認率」KPIを直接サポートします。これにより、企業はポリシー遵守を定量化し、例外として承認されたケースを特定し、そのような例外の理由と頻度を分析できます。これは、ガバナンスとコスト管理にとって不可欠です。 その重要性 ビジネスルールへのコンプライアンスを直接測定し、収益損失につながる可能性のある非準拠の返品承認を特定し削減するのに役立ちます。 取得元 これは派生属性です。ロジックは、返品の属性(例:返品日と購入日、返品理由)を事前定義されたビジネスルールと比較して構築する必要があります。 例 truefalse | |||
| 倉庫ID WarehouseId | 返品された商品が受領される倉庫または場所の識別子。 | ||
| 説明 この属性は、返品された商品を処理する特定の物理的な倉庫または返品センターを識別します。場所によって異なるプロセス、リソース、またはパフォーマンスレベルを持つ場合があります。 倉庫ごとのプロセス分析は、場所間のパフォーマンスベンチマークに役立ちます。これにより、どの施設が返品処理において最も効率的であるかを特定し、地域的なボトルネックを浮き彫りにし、ロジスティクスネットワーク全体でのリソース配分とプロセス標準化に関する意思決定に情報を提供することができます。 その重要性 異なる倉庫や返品センター間のパフォーマンス比較を可能にし、地域的なボトルネックやベストプラクティスの特定に役立ちます。 取得元 この情報は、到着ジャーナル('WMSJournalTable')や'SalesLine'などの在庫関連トランザクションの'InventLocationId'フィールドに保存されます。 例 WH-EASTWH-WESTCENTRAL-DC | |||
| 最終データ更新 LastDataUpdate | プロセスのデータが最後に更新された日時を示すタイムスタンプ。 | ||
| 説明 この属性は、データがソースシステムから最後に抽出され、プロセスマイニングツールで更新された日時を記録します。これにより、分析対象データの鮮度に関する参照点が提供されます。 最終データ更新時刻を知ることは、分析のタイムリーさを理解するために重要です。これは、ユーザーがリアルタイムデータを見ているのか、特定の時点のスナップショットを見ているのかを把握し、ダッシュボードやKPIを正しく解釈するのに役立ちます。これは運用監視にとって鍵となります。 その重要性 データの鮮度を示し、アナリストがプロセスインサイトの最新性を把握できるようにします。 取得元 これはデータ取り込みパイプライン中に生成・保存されるメタデータ属性であり、通常はETLジョブ完了のタイムスタンプを表します。 例 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| 実際の返金額 ActualRefundAmount | お客様に発行された最終的な返金金額。 | ||
| 説明 この属性は、お客様に返金された最終的な確認済み金額です。この値は、クレジットノートが作成され、転記される際に記録されます。 これは財務分析にとって重要な属性であり、「返金金額差異分析」ダッシュボードおよび「返金金額精度率」KPIで直接使用されます。このデータを分析することで、返品による財務的影響やプロセス中に行われた調整を理解するのに役立ちます。 その重要性 これは返品の実際の財務的影響を表し、返金の正確性を計算し、財務的成果を理解するために不可欠です。 取得元 この値は、転記されたクレジットノートの取引詳細で見つけることができます。クレジットノートの'CustTrans'および'CustInvoiceJour'テーブルに関連しています。 例 99.99135.000.00 | |||
| 終了日時 EndTime | 特定のアクティビティが完了した時点を示すタイムスタンプ。 | ||
| 説明 終了時刻は、アクティビティの完了タイムスタンプを表します。開始時刻が始まりを示す一方、終了時刻は完了を示し、その特定のタスクの処理時間を計算できます。 この属性は、特に「商品検査」のような測定可能な期間を持つタスクの詳細なパフォーマンス分析にとって重要です。開始時刻と終了時刻を比較することで、アナリストはタスクの実際の処理時間を正確に測定し、タスク間の待機時間と区別することができます。これにより、タスク間だけでなく、特定のアクティビティ内の非効率性を特定するのに役立ちます。 その重要性 個々のアクティビティのアクティブな処理時間を計算できるため、待機時間と実際の作業時間を区別するのに役立ちます。 取得元 これはしばしば派生させる必要があります。例えば、アクティビティを完了させるステータス変更の'modifiedDateTime'であるか、後続のアクティビティのStartTimeである可能性があります。 例 2023-10-26T10:15:00Z2023-10-26T14:45:20Z2023-10-27T09:55:12Z | |||
| 返品タイプ ReturnType | 返金や交換など、期待される結果に基づいて返品を分類します。 | ||
| 説明 この属性は、顧客が求める、または企業が提供する解決タイプに基づいて返品案件を分類します。一般的なタイプには、金銭的な「返金」、「交換品」との交換、または「修理」が含まれます。 この分類は、異なるプロセスパスを分析するのに役立ちます。返金を発行するプロセスは、交換品を発送するプロセスとは大きく異なります。返品タイプ別にセグメント化することで、各解決パスに特有のサイクルタイムとボトルネックをより正確に分析できます。 その重要性 返金プロセスと交換プロセスではステップとサイクルタイムが異なるため、意図する結果に基づいて分析をセグメント化することができます。 取得元 これは返品注文ヘッダーのカスタムフィールドであるか、ディスポジションコードや交換販売注文の作成のような後続の取引に基づいて派生する場合があります。 例 返金交換ストアクレジット | |||
| 返品注文ステータス ReturnOrderStatus | イベント発生時点での返品注文の全体的なステータス。 | ||
| 説明 この属性は、「オープン」、「請求済み」、「キャンセル済み」など、返品注文ヘッダーの現在のステータスを示します。これにより、案件がライフサイクルのどの段階にあるかという高レベルなビューが提供されます。 アクティビティが詳細なプロセスステップを提供する一方で、全体的なステータスは案件のフィルタリングとセグメント化に役立ちます。例えば、アナリストは現在のワークロードを理解するために「オープン」案件のみに焦点を当てたり、最終的に「キャンセル済み」となる案件のプロセスフローを分析したりすることができます。 その重要性 ケースの状態の概要を提供し、ケースのフィルタリングやキャンセルなどの結果を理解するのに役立ちます。 取得元 この情報は、'SalesTable'の'SalesStatus'または'DocumentStatus'フィールドにあります。 例 オープンオーダー配送済みInvoicedキャンセル済み | |||
| 返金SLA目標日 RefundSlaTargetDate | 返品・返金案件が完全に解決されるべき目標日付。 | ||
| 説明 この属性は、返品案件を解決するためのサービスレベル契約(SLA)の期限を定義します。これは、お客様が最終的な解決策(転記された返金や発送された交換品など)を受け取ることを期待される日付です。 この目標日付は、サービスコミットメントに対するパフォーマンス監視に不可欠です。これは、「解決SLA遵守率」KPIの計算と「返金解決SLAパフォーマンス」ダッシュボードの駆動に使用されます。この日付とプロセスの実際の完了日を比較することで、企業はSLA違反を特定し、滞留案件を積極的に管理することができます。 その重要性 これはプロセスパフォーマンスを測定する際のベンチマークであり、SLAコンプライアンスの追跡や遅延ケースの特定を可能にします。 取得元 これは標準フィールドではない可能性があります。多くの場合、返品作成日と事前定義されたSLA期間(例:14日)に基づいて計算されます。カスタムフィールドに保存されることもあります。 例 2023-11-10T23:59:59Z2023-11-15T23:59:59Z | |||
| 返金要求額 RequestedRefundAmount | お客様が要求した返金総額。 | ||
| 説明 この属性は、返品プロセス開始時に要求された、または期待された初期の返金金額を表します。通常、返品された商品の元の購入価格に基づいています。 この値は「返金金額差異分析」のベースラインとして機能します。要求された金額と実際に返金された金額を比較することで、企業は再入荷手数料、破損品の部分的返金、その他の調整によって生じた差異を特定できます。これにより、財務の正確性とポリシー遵守状況の監視に役立ちます。 その重要性 これは、実際の処理された返金額と比較することで、財務の正確性を測定するための基準として機能します。 取得元 これは通常、返品される元の販売注文明細の明細金額または合計金額であり、'SalesLine.LineAmount'に記載されています。 例 99.99150.0024.50 | |||
| 顧客ID CustomerId | 返品を開始した顧客の一意の識別子。 | ||
| 説明 顧客IDは、返品に関連付けられた顧客アカウントの一意の識別子です。これにより、返品取引をCRMまたは顧客データベース内の特定の顧客にリンクできます。 顧客ごとの返品を分析することで、異常に高い返品活動を持つ顧客を特定できます。これは、不正行為や慢性的な不満を示している可能性があります。また、例えば高価値顧客にプレミアムな返品サービスを提供するなど、顧客をセグメント化するためにも使用できます。 その重要性 返品プロセスを特定の顧客に紐付け、顧客レベルの分析や返品パターン、潜在的な不正行為の特定を可能にします。 取得元 これは、返品注文の'SalesTable'にある'CustAccount'フィールドです。 例 CUST-00045CUST-00192CUST-00315 | |||
返品・返金処理アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| クレジットノート転記済み | クレジットノートが正式に財務台帳に転記され、お客様がクレジットを利用できるようになります。これは、企業側から見た返金処理の完了を意味します。 | ||
| その重要性 これは重要な財務上のマイルストーンであり、返金がシステムで処理されたことを確認します。返金SLA遵守を測定するための主要なアクティビティとなることがよくあります。 取得元 返品注文の請求書仕訳の転記タイムスタンプ。これによりクレジットノートが確定します。返品注文のステータスは「請求済み」に変更されます。 取得 返品注文書の請求ジャーナルの転記。 イベントタイプ explicit | |||
| 処理コードが適用された | このアクティビティは、検査の完了と返品された商品をどうするかについての決定を表します。「返金」、「廃棄」、「交換」などのディスポジションコードが返品明細に割り当てられます。 | ||
| その重要性 これは、返金、交換、または拒否のいずれであるか、その後のプロセスパスを決定する重要な意思決定ポイントです。ここでの遅延は、全体の解決時間に大きな影響を与える可能性があります。 取得元 このイベントは、返品注文明細の在庫トランザクションまたは関連ジャーナルでDispositionCodeフィールドが入力されたときに捕捉されます。 取得 返品注文明細にDispositionCodeが設定された際の更新イベント。 イベントタイプ explicit | |||
| 品目受領済み | 倉庫または指定された返品センターでの返品商品の物理的な受領を示します。これは、返品注文に関連する入荷ジャーナルが転記されたときに捕捉されます。 | ||
| その重要性 これは、プロセスが顧客アクションから内部処理へ移行する重要なマイルストーンです。検査や処分など、すべての内部処理時間を計算するための出発点となります。 取得元 返品注文明細に関連付けられたWMSジャーナルまたは商品到着ジャーナルの転記タイムスタンプ。これにより、在庫トランザクションが「登録済み」または「受領済み」ステータスに更新されます。 取得 返品注文明細にリンクされた商品入荷ジャーナルの転記イベント。 イベントタイプ explicit | |||
| 返品注文クローズ済み | 返品注文が最終状態に達しました。これは、すべての物理的および財務的取引が完了したことを意味します。通常、クレジットノートが転記された後、または代替品が発送された後に発生します。 | ||
| その重要性 これは、正常に完了した返品プロセスの主要な終了イベントです。作成からこの時点までの期間は、総案件サイクルタイムを表します。 取得元 ReturnOrderのステータスフィールドが「請求済み」や「クローズ済み」といった最終値に変化したことから推測されます。これは、それ以上の処理が予定されていないことを示します。 取得 SalesTable.StatusまたはSalesTable.DocumentStatusフィールドが最終状態に変更されること。 イベントタイプ inferred | |||
| 返品注文作成済み | このアクティビティは、返品プロセスが開始されることを示し、システム内で返品承認(RMA)または返品注文が作成されます。これは、Dynamics 365で新しいReturnOrderレコードが作成された際に捕捉される明示的なイベントです。 | ||
| その重要性 これは、返品プロセス全体の主要な開始イベントです。このアクティビティから他のアクティビティまでの時間を分析することで、全体のプロセスリードタイムが明らかになり、初期段階のボトルネック特定に役立ちます。 取得元 このイベントは、ReturnOrderヘッダーの作成タイムスタンプから捕捉されます。これは通常、SalesTypeが「Returned Order」であるSalesTableに見られます。 取得 SalesType = 'Returned Order' を持つSalesTableレコードの作成イベント。 イベントタイプ explicit | |||
| クレジットノート作成済み | 「クレジット」の処分に基づいてクレジットノートが生成され、顧客への返金が承認されます。これはプロセスにおける財務決済の正式な開始点となります。 | ||
| その重要性 このアクティビティは、財務的な返金の承認を示します。処分とクレジットノート作成の間の時間は、返金開始における管理上の遅延を浮き彫りにします。 取得元 これは、元の返品注文にリンクされた負の値を持つ新しいSalesTableレコードの作成、または「クレジットノート作成」バッチジョブの実行によって推測できます。 取得 多くの場合、返品注文書を転記することによるクレジットノートの作成。 イベントタイプ explicit | |||
| 交換品が出荷された | 代替品の梱包伝票が転記され、お客様に発送されたことを示します。これにより、交換履行プロセスの完了がマークされます。 | ||
| その重要性 これは交換バリアントにおける重要なマイルストーンであり、お客様に対する会社の義務の履行を表します。交換サイクルタイムを追跡するために不可欠です。 取得元 代替販売注文の梱包伝票仕訳の転記日。これにより、注文ステータスが「配送済み」に更新されます。 取得 交換販売注文の梱包伝票の転記。 イベントタイプ explicit | |||
| 代替注文作成済み | 顧客に交換品を送るための新しい販売注文が作成されます。このアクティビティは、処分アクションが「交換とクレジット」または「交換と廃棄」の場合に発生します。 | ||
| その重要性 このアクティビティは交換プロセスバリアントを開始します。このパスを返金パスとは別に追跡することは、交換の複雑さとコストを理解するために不可欠です。 取得元 交換品用の新しいSalesTableレコードの作成。これは多くの場合、自動的に生成され、元の返品注文にリンクされます。 取得 処理アクションを通じて返品注文にリンクされた新しい販売注文の作成。 イベントタイプ explicit | |||
| 入荷ジャーナル作成 | このアクティビティは、倉庫が返品された商品の到着を待っていることを示します。これは到着ジャーナルの作成であり、商品の物理的な受領のためにシステムを準備します。 | ||
| その重要性 このステップは、物流準備と実際の物理的な受領を区別します。これにより、倉庫の準備状況の分析や、入庫する返品の計画に役立ちます。 取得元 WMSJournalTableにJournalType「入荷」のレコードを作成します。このジャーナルは返品注文明細にリンクされます。 取得 返品のWMSJournalTableレコードの作成タイムスタンプ。 イベントタイプ explicit | |||
| 品質オーダー生成済み | 公式な品質オーダーが作成され、返品された商品が構造化された検査プロセスを経る必要があることを示します。これは、返品に詳細なテストや品質基準に対するチェックが必要なシナリオで一般的です。 | ||
| その重要性 このアクティビティは、正式な検査プロセスの開始を示します。この時点からの時間を追跡することで、品質保証ワークフローの効率と期間を測定するのに役立ちます。 取得元 返品注文にリンクされたInventQualityOrderTableのレコードの作成タイムスタンプ。 取得 InventQualityOrderTableレコードの作成。 イベントタイプ explicit | |||
| 返品注文キャンセル済み | 返品注文は完了前にキャンセルされます。これは、お客様のリクエスト、または商品が返品されなかったことによる可能性があります。 | ||
| その重要性 これはプロセスに対する代替の、失敗した終了を表します。返品がキャンセルされる理由を分析することで、顧客行動やプロセス失敗に関するインサイトが得られます。 取得元 ReturnOrderステータスフィールドが「キャンセル済み」に変わったことから推測されます。これは、正常にクローズされた注文とは異なる最終状態です。 取得 SalesTable.Statusフィールドが「キャンセル済み」に変更されること。 イベントタイプ inferred | |||
| 返品注文確定済み | システム内で返品注文が正式に確定したことを示し、多くの場合、その後のロジックをトリガーします。これは通常、明示的なアクションまたは返品注文ヘッダーのステータス変更として記録されます。 | ||
| その重要性 確認は物流が開始される前の重要なステップです。作成と確認の間の遅延は、管理上またはシステム関連のバックログを示している可能性があります。 取得元 これは、返品注文の「確定」ジャーナル転記、またはSalesTableのDocumentStatusフィールドの変更によって特定できます。 取得 返品注文に対する「販売注文の確認」機能の実行。 イベントタイプ explicit | |||
抽出ガイド
ステップ
- 前提条件:Azure Active Directoryにアプリケーションを登録する。 Dynamics 365 APIに接続する前に、Azure AD テナントにアプリケーションを登録する必要があります。このアプリケーションに、例えば
Financials.ReadWrite.Allやカスタム権限など、Dynamics 365 Finance & Operationsへのアクセス権限を委任します。 - Dynamics 365でアプリケーションIDを構成する。 Dynamics 365で、「システム管理 > 設定 > Azure Active Directoryアプリケーション」に移動します。Azure ADアプリ登録からアプリケーション(クライアント)IDを追加し、必要なデータエンティティを読み取るためのセキュリティロールを持つユーザーアカウントに関連付けます。
- OAuth 2.0アクセストークンを取得する。 PowerShellやPythonなどのスクリプトを作成し、Microsoft IDプラットフォームエンドポイントに対して認証を行います。アプリケーションの資格情報(クライアントIDとシークレット)を使用して、Dynamics 365リソースURLのアクセストークンを要求します。
- Dynamics 365環境URLを特定する。 Dynamics 365環境のベースURLを見つけます。Web APIエンドポイントは通常、
https://[YourD365FinanceAndOpsURL].dynamics.com/dataのようになります。 - OData APIリクエストを構築し実行する。 必要な12のアクティビティそれぞれについて、特定のOData GETリクエストURLを構築します。
$selectを使用して必要な列のみを取得し、$filterを使用して日付範囲やステータス条件を指定します。ステップ3で取得した認証トークンは、各リクエストのAuthorizationヘッダーにBearerトークンとして含める必要があります。 - 抽出スクリプトを開発する。 ODataリクエストのリストを反復処理するスクリプトを作成します。このスクリプトは、認証を処理し、各GETリクエストを実行し、結果のJSONデータを保存する必要があります。API制限に注意し、必要に応じて一時停止を実装してください。
- APIページネーションを処理する。 Dynamics 365は大量の結果をページネーションします。スクリプトは応答の
@odata.nextLinkプロパティをチェックする必要があります。存在する場合、スクリプトは次のデータのページを取得するためにそのURLに対して後続のリクエストを行う必要があり、nextLinkが提供されなくなるまで続行します。 - データを変換して結合する。 12のAPI呼び出しそれぞれからのJSON応答を処理します。各アクティビティについて、
ReturnCaseId、ActivityName、EventTime、およびその他の属性を含む標準化されたレコードを作成します。例えば、「返品注文作成」イベントの場合、ReturnOrderNumberをReturnCaseIdにマッピングし、ActivityNameを「返品注文作成」に設定し、createdDateTimeをEventTimeにマッピングします。すべての呼び出しから変換されたレコードを単一のリストまたはテーブルに結合します。 - タイムスタンプをクリーンアップし標準化する。 すべての
EventTime値が、できればUTCでYYYY-MM-DDTHH:MM:SSZのような一貫した形式であることを確認します。欠落または無効なタイムスタンプを持つレコードは必要に応じて処理します。 - 最終イベントログをエクスポートする。 すべてのデータが収集され、単一の統合されたデータセットに変換されたら、CSVファイルにエクスポートします。列ヘッダーがProcessMindの要件(
ReturnCaseId、ActivityName、EventTime、ResponsibleUser、DispositionCodeなど)と一致していることを確認します。これでファイルはアップロード準備完了です。
設定
- API Endpoint URL: Dynamics 365 Finance & OperationsインスタンスのベースURLです。
https://[YourEnvironmentName].dynamics.com/dataの形式に従います。 - Azure AD アプリケーション: クライアントIDとシークレットを持つアプリケーションをAzure ADに登録する必要があります。Dynamics 365 データエンティティへのアクセスにはAPIアクセス許可が必要です。
- 日付範囲フィルタリング: すべてのAPI呼び出しで、
createdDateTimeやmodifiedDateTimeなどの関連する日付フィールドにOData$filterパラメータを使用して日付範囲フィルタを適用することが重要です。抽出を管理しやすい状態に保つため、通常は過去3~6ヶ月のデータを開始範囲とします。 - 会社フィルタ: 特定の法人のデータを抽出するには、
cross-company=trueクエリパラメータを含め、dataAreaIdフィールドに$filterを使用します。例:?cross-company=true&$filter=dataAreaId eq '[YourCompanyCode]'。 - ページネーション設定: リクエストに
Prefer: odata.maxpagesize=[value]ヘッダーを使用し、ページごとに返されるレコード数を制御します。1000から5000の値が一般的です。これにより、大量のエンティティでのAPIタイムアウトを防ぐことができます。 - API スロットリング: Dynamics 365 APIのサービス保護制限に注意してください。抽出スクリプトには、
429 (Too Many Requests)応答を処理するロジックを含める必要があります。通常は、指数バックオフまたは単純な一時停止と再試行メカニズムを実装します。
a クエリ例 graphql
/*
This is a conceptual guide representing multiple, distinct OData API calls.
You will need a script (e.g., Python, PowerShell) to execute these calls sequentially,
authenticate with a bearer token, handle pagination, and union the results into a single file.
Replace [YourD365URL], [StartDate], [EndDate], and [YourCompanyCode] with your specific values.
*/
// Base URL for all requests
const string BaseUrl = "https://[YourD365URL].dynamics.com/data";
const string CompanyFilter = "?cross-company=true&$filter=dataAreaId eq '[YourCompanyCode]' and ";
const string DateFilterCreated = "createdDateTime ge [StartDate]T00:00:00Z and createdDateTime le [EndDate]T23:59:59Z";
const string DateFilterModified = "modifiedDateTime ge [StartDate]T00:00:00Z and modifiedDateTime le [EndDate]T23:59:59Z";
// 1. Return Order Created
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}{DateFilterCreated}&$select=ReturnOrderNumber,createdDateTime,createdby,ReturnReasonCodeId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser, ReturnReasonCodeId -> ReturnReasonCode
// 2. Return Order Confirmed
// This often updates the header status. We look for a modification time on confirmed orders.
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Confirmed' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby,ReturnReasonCodeId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Confirmed' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser
// 3. Arrival Journal Created
GET {BaseUrl}/WarehouseArrivalJournalHeaders{CompanyFilter}{DateFilterCreated}&$expand=WarehouseArrivalJournalLines($select=InventTransactionId)&$select=JournalNumber,createdDateTime,createdby
// Note: This requires post-processing to link JournalNumber to a ReturnCaseId via InventTransactionId.
// Mapping: Link via InventTrans -> ReturnCaseId, 'Arrival Journal Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser
// 4. Item Received (Arrival Journal Posted)
GET {BaseUrl}/WarehouseArrivalJournalHeaders{CompanyFilter}JournalPosted eq 'Yes' and {DateFilterModified}&$expand=WarehouseArrivalJournalLines($select=InventTransactionId)&$select=JournalNumber,modifiedDateTime,modifiedby
// Mapping: Link via InventTrans -> ReturnCaseId, 'Item Received' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser
// 5. Quality Order Generated
GET {BaseUrl}/InventQualityOrders{CompanyFilter}{DateFilterCreated}&$select=QualityOrderId,InventTransId,createdDateTime,CreatedByUserId,ItemId
// Mapping: Link via InventTransId -> ReturnCaseId, 'Quality Order Generated' -> ActivityName, createdDateTime -> EventTime, CreatedByUserId -> ResponsibleUser, ItemId -> ProductId
// 6. Disposition Code Applied
// This is a status change on the return line.
GET {BaseUrl}/ReturnOrderLines{CompanyFilter}ReturnDispositionCodeId ne '' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby,ReturnDispositionCodeId,ItemId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Disposition Code Applied' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser, ReturnDispositionCodeId -> DispositionCode, ItemId -> ProductId
// 7. Credit Note Created
// Look for sales orders with type 'Returned Order' that are not yet invoiced.
GET {BaseUrl}/SalesOrderHeadersV2{CompanyFilter}SalesOrderProcessingStatus eq 'Open' and SalesOrderType eq 'ReturnedOrder' and {DateFilterCreated}&$select=SalesOrderNumber,createdDateTime,createdby
// Mapping: SalesOrderNumber -> ReturnCaseId, 'Credit Note Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser
// 8. Credit Note Posted
// Look for posted invoice journals linked to a return order.
GET {BaseUrl}/SalesInvoiceJournalHeaders{CompanyFilter}SalesOrderType eq 'ReturnedOrder' and {DateFilterCreated}&$select=SalesOrderNumber,InvoiceDate,createdby
// Mapping: SalesOrderNumber -> ReturnCaseId, 'Credit Note Posted' -> ActivityName, InvoiceDate -> EventTime, createdby -> ResponsibleUser
// 9. Replacement Order Created
// Disposition code on the return line triggers a replacement order.
GET {BaseUrl}/SalesOrderHeadersV2{CompanyFilter}SalesOrderOriginType eq 'ReturnOrder' and {DateFilterCreated}&$select=SalesOrderNumber,createdDateTime,createdby,ReturnOrderNumber
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Replacement Order Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser
// 10. Replacement Item Shipped
// Check for posted packing slips related to the replacement sales order.
GET {BaseUrl}/SalesPackingSlipJournals{CompanyFilter}{DateFilterCreated}&$select=SalesOrderNumber,DeliveryDate,createdby
// Note: This requires linking SalesOrderNumber back to the original ReturnOrderNumber for the ReturnCaseId.
// Mapping: Link SalesOrderNumber -> ReturnCaseId, 'Replacement Item Shipped' -> ActivityName, DeliveryDate -> EventTime, createdby -> ResponsibleUser
// 11. Return Order Closed
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Closed' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Closed' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser
// 12. Return Order Cancelled
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Canceled' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Cancelled' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser ステップ
- TDS エンドポイントを有効にする: Dynamics 365 Dataverse環境でタブラーデータストリーム(TDS)エンドポイントが有効になっていることを確認してください。システム管理者は、Power Platform管理センターの「環境 > 設定 > 機能」でこれを有効にできます。
- 環境URLを特定する: ご利用の環境URLを見つけてください。通常、
yourorg.crm.dynamics.comのようになります。TDSエンドポイントサーバー名は、このURLにポート5558を付加したものになります。例えば、yourorg.crm.dynamics.com,5558。 - SQLクライアントで接続する: SQL Server Management Studio (SSMS) や Azure Data Studioなど、TDSをサポートするSQLクライアントを使用してください。
- 認証する: Dataverse環境で適切な権限(通常はシステム管理者またはシステムカスタマイザー)を持つAzure Active Directoryアカウントを使用してサーバーに接続します。
- クエリを準備する: このドキュメントの
queryセクションに記載されている完全なSQLクエリを、SQLクライアントの新しいクエリウィンドウにコピーしてください。 - パラメータを設定する: クエリ内のプレースホルダーを見つけます。
'{StartDate}'と'{EndDate}'を抽出に必要な日付範囲に置き換えます。例えば、'2023-01-01'と'2023-12-31'。また、ステータスコードや処理コードのプレースホルダー値も、Dynamics 365の特定の設定に合わせて更新してください。 - クエリを実行する: 変更したクエリをDataverseデータベースに対して実行します。実行時間は、データ量と選択した日付範囲によって異なります。
- 結果を確認する: クエリが完了したら、返されたデータセットを確認し、期待される列(
ReturnCaseId、ActivityName、EventTime、および推奨される属性)が含まれていることを確認します。 - イベントログをエクスポートする: クエリ結果をCSVファイルにエクスポートします。ほとんどのSQLクライアントには、結果を直接ファイルに保存する組み込み機能があります。ファイルをUTF-8エンコーディングで保存するようにしてください。
- ProcessMindにアップロードする: エクスポートされたCSVファイルは、プロセスマイニング分析用の新しいイベントログとしてProcessMindにアップロードする準備ができました。
設定
- 前提条件: 関連するDataverseテーブル(例:SalesTable、SalesLine、CustInvoiceJour)への少なくとも読み取りアクセス権を持つユーザーアカウントが必要です。権限は通常、システム管理者などのセキュリティロール、または十分なテーブル権限を持つカスタムロールを通じて管理されます。
- TDS エンドポイント: 環境に対してDataverse TDS エンドポイントが有効になっている必要があります。この機能により、Dataverseデータベースに対して直接、読み取り専用のSQLクエリを実行できます。
- 日付範囲: クエリには
'{StartDate}'と'{EndDate}'のプレースホルダーが含まれています。初期分析では、パフォーマンスの問題を引き起こすことなく代表的なデータセットを提供するために、3〜6ヶ月の日付範囲が推奨されます。 - 会社フィルタ: 記述されたクエリは、ユーザーがアクセスできるすべての法人(会社)に対して実行されます。単一の会社分析の場合、コメントアウトを解除し、
UNION ALLステートメントの各部分でDATAAREAIDフィールドをフィルタリングするWHERE句を追加します。例えば、AND st.DATAAREAID = '[YourCompanyID]'。 - カスタムロジックプレースホルダー: クエリには、ディスポジションコードや交換注文のリンクに関するメモのための
[YourReplaceCode1]のようなプレースホルダーが含まれています。これらは、特定のビジネスプロセスとDynamics 365のセットアップに基づいて構成する必要があります。 - パフォーマンス: 大規模なデータセットに対してTDSエンドポイントに直接クエリを実行すると、処理が遅くなることがあります。接続は分析クエリ向けに最適化されていますが、数百万行にわたる複雑な結合はタイムアウトする可能性があります。厳密な日付フィルタを適用することを推奨します。
a クエリ例 sql
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Created' AS ActivityName,
st.CREATEDDATETIME AS EventTime,
st.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Confirmed' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.DOCUMENTSTATUS = 1 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Arrival Journal Created' AS ActivityName,
wjt.CREATEDDATETIME AS EventTime,
wjt.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN WMSJOURNALTABLE wjt ON st.SALESID = wjt.ORDERID AND st.DATAAREAID = wjt.DATAAREAID
WHERE st.SALESTYPE = 3 AND wjt.JOURNALTYPE = 4 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Item Received' AS ActivityName,
wjt.POSTEDDATETIME AS EventTime,
wjt.POSTEDUSERID AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN WMSJOURNALTABLE wjt ON st.SALESID = wjt.ORDERID AND st.DATAAREAID = wjt.DATAAREAID
WHERE st.SALESTYPE = 3 AND wjt.JOURNALTYPE = 4 AND wjt.POSTEDDATETIME IS NOT NULL AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Quality Order Generated' AS ActivityName,
iqot.CREATEDDATETIME AS EventTime,
iqot.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
iqot.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN INVENTQUALITYORDERTABLE iqot ON sl.INVENTTRANSID = iqot.INVENTTRANSID AND sl.DATAAREAID = iqot.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Disposition Code Applied' AS ActivityName,
iqot.VALIDATEDDATETIME AS EventTime,
iqot.VALIDATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
iqot.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN INVENTQUALITYORDERTABLE iqot ON sl.INVENTTRANSID = iqot.INVENTTRANSID AND sl.DATAAREAID = iqot.DATAAREAID
WHERE st.SALESTYPE = 3 AND iqot.VALIDATEDDATETIME IS NOT NULL AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Credit Note Created' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Credit Note Posted' AS ActivityName,
cij.CREATEDDATETIME AS EventTime,
cij.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN CUSTINVOICEJOUR cij ON st.SALESID = cij.SALESID AND st.DATAAREAID = cij.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ro.RETURNITEMNUM AS ReturnCaseId,
'Replacement Order Created' AS ActivityName,
replacement_so.CREATEDDATETIME AS EventTime,
replacement_so.CREATEDBY AS ResponsibleUser,
NULL AS DispositionCode,
NULL AS ReturnReasonCode,
replacement_so.SALESORIGINID AS ReturnChannel,
replacement_sl.ITEMID AS ProductId
FROM SALESTABLE ro
JOIN SALESLINE rol ON ro.SALESID = rol.SALESID AND ro.DATAAREAID = rol.DATAAREAID
JOIN SALESTABLE replacement_so ON ro.CUSTACCOUNT = replacement_so.CUSTACCOUNT AND ro.DATAAREAID = replacement_so.DATAAREAID
JOIN SALESLINE replacement_sl ON replacement_so.SALESID = replacement_sl.SALESID AND replacement_so.DATAAREAID = replacement_sl.DATAAREAID
WHERE ro.SALESTYPE = 3
AND rol.RETURNDISPOSITIONCODEID IN ('[YourReplaceCode1]', '[YourReplaceCode2]')
AND replacement_so.SALESTYPE = 1
AND replacement_so.CREATEDDATETIME > ro.CREATEDDATETIME
-- The join above is a basic example and must be replaced with your system's specific logic for linking returns to replacements.
AND ro.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ro.RETURNITEMNUM AS ReturnCaseId,
'Replacement Item Shipped' AS ActivityName,
cpsj.CREATEDDATETIME AS EventTime,
cpsj.CREATEDBY AS ResponsibleUser,
NULL AS DispositionCode,
NULL AS ReturnReasonCode,
replacement_so.SALESORIGINID AS ReturnChannel,
cpsl.ITEMID AS ProductId
FROM SALESTABLE ro
JOIN SALESLINE rol ON ro.SALESID = rol.SALESID AND ro.DATAAREAID = rol.DATAAREAID
JOIN SALESTABLE replacement_so ON ro.CUSTACCOUNT = replacement_so.CUSTACCOUNT AND ro.DATAAREAID = replacement_so.DATAAREAID
JOIN CUSTPACKINGSLIPJOUR cpsj ON replacement_so.SALESID = cpsj.SALESID AND replacement_so.DATAAREAID = cpsj.DATAAREAID
JOIN CUSTPACKINGSLIPTRANS cpsl ON cpsj.PACKINGSLIPID = cpsl.PACKINGSLIPID AND cpsj.SALESID = cpsl.SALESID AND cpsj.DATAAREAID = cpsl.DATAAREAID
WHERE ro.SALESTYPE = 3
AND rol.RETURNDISPOSITIONCODEID IN ('[YourReplaceCode1]', '[YourReplaceCode2]')
AND replacement_so.SALESTYPE = 1
AND replacement_so.CREATEDDATETIME > ro.CREATEDDATETIME
-- The join above is a basic example and must be replaced with your system's specific logic for linking returns to replacements.
AND ro.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Closed' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Cancelled' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 4 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}';