返品・返金処理データテンプレート
返品・返金処理データテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- NetSuiteからのデータ抽出ガイダンス
返品・返金処理属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 返品プロセス内で発生した特定のビジネスイベントまたはステップの名前。例えば「商品検査済み」または「返金処理済み」など。 | ||
| 説明 アクティビティ名とは、返品および返金ライフサイクルにおける個別のステップまたはマイルストーンを指します。これらのイベントはタイムスタンプ順に並べられ、プロセスフローを構築します。アクティビティの順序と頻度を分析することで、最も一般的なプロセス経路、ステップ間のボトルネック、および手戻りや繰り返される活動を特定するのに役立ちます。例としては、「返品承認作成済み」、「商品受領」、「クレジットメモ承認済み」などがあります。 その重要性 この属性はプロセスのステップを定義します。プロセスマップの可視化、フローのバリエーション分析、ボトルネックや手戻りループの特定に不可欠です。 取得元 この属性は通常、返品承認やクレジットメモなどのトランザクションレコードのステータス変更、またはシステムノートやカスタムイベントログに記録された特定のユーザーアクションから導出されます。 例 返品承認作成済み品目受領済み品目検査済み返金処理済み返品承認書クローズ済み | |||
| イベントのタイムスタンプ EventTimestamp | 活動が発生した正確な日時であり、プロセスの時系列的な基盤として機能します。 | ||
| 説明 イベントタイムスタンプは、活動が行われた正確な瞬間を記録します。このデータは、イベントを正しく順序付けし、すべての時間ベースの分析を行うために不可欠です。活動間の期間、総ケースサイクルタイム、および待機時間の計算に使用され、これらはパフォーマンス監視、ボトルネック分析、SLA遵守チェックの基本となります。プロセスマイニングの洞察の信頼性を確保するためには、タイムスタンプが正確である必要があります。 その重要性 この属性はイベントの時系列順序を提供し、これはプロセスフローの発見やサイクルタイム、待機時間といったすべてのパフォーマンス指標の計算に必要です。 取得元 この情報は通常、NetSuiteレコード上の「作成日」または「最終更新日」フィールド、あるいはトランザクションに関連付けられたシステムノートサブリストのタイムスタンプから取得されます。 例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:12:05Z | |||
| 返品ケースID ReturnCaseId | 単一の顧客返品または返金ケースの固有の識別子であり、開始からクローズまでのすべての関連活動をリンクします。 | ||
| 説明 返品ケースIDは、返品のend-to-endジャーニーを追跡するための主要な識別子として機能します。各固有のIDは単一の返品承認に対応し、商品受領、検査、返金処理など、関連するすべてのイベントの包括的な分析を可能にします。プロセスマイニングでは、このIDは各返品の完全なプロセスフローを再構築し、サイクルタイムの計算やケースレベルの逸脱を特定するために不可欠です。 その重要性 これはプロセスマイニングの基本的な属性であり、すべての個々のイベントを一貫性のあるend-to-endプロセスインスタンスに接続することで、プロセスフローとパフォーマンスの分析を可能にします。 取得元 これは通常、NetSuiteの返品承認レコードの内部IDまたはトランザクションIDです。 例 RMA-0012345RMA-0012346RMA-0012347 | |||
| ソースシステム SourceSystem | データの抽出元システムであり、データのリネージ追跡に使用されます。 | ||
| 説明 この属性は、プロセスデータの発生元を特定します。この文脈では、通常「NetSuite」となります。複数のシステムからデータが統合される可能性のある環境では、ソースシステムを指定することが重要であり、明確なデータリネージとトレーサビリティを確保します。 その重要性 データの出所を特定します。これはデータガバナンス、トラブルシューティング、および複数のシステムからのデータを組み合わせてプロセス全体を包括的に把握する場合に不可欠です。 取得元 これは、データ抽出および変換プロセス中に通常追加される静的な値(「NetSuite」)です。 例 NetSuiteNetSuite ERP | |||
| 最終データ更新 LastDataUpdate | このプロセスのデータが最後に更新またはリフレッシュされたことを示すタイムスタンプ。 | ||
| 説明 この属性は、データセットがソースシステムから最後に更新された日時を記録します。これは、分析の鮮度についてユーザーに知らせる重要なメタデータです。この情報をダッシュボードに表示することで、期待値を管理し、データの適時性を理解した上で意思決定が行われることを保証します。 その重要性 データの鮮度に関する透明性を提供し、ユーザーが分析を信頼し、現在の業務状況との関連性を理解するために不可欠です。 取得元 この 例 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| サイクルタイム CycleTime | 返品リクエストの作成から最終クローズまでの経過時間の合計。 | ||
| 説明 サイクルタイムは、各返品ケースについて計算される主要業績評価指標です。これは最初から最後のイベントまでの期間を測定し、プロセス効率の全体像を提供します。この指標は、「返品プロセスエンドツーエンドサイクルタイム」ダッシュボードおよび「平均返品サイクルタイム」KPIの基盤となります。各ケースについて、最初のアクティビティのタイムスタンプから最後のアクティビティのタイムスタンプを引くことで計算されます。 その重要性 これはプロセスパフォーマンスの主要な指標です。高いサイクルタイムは、多くの場合、非効率性、ボトルネック、または過剰な手作業を示し、その結果、運用コストの増加と顧客体験の低下につながります。 取得元 これはソースシステムには存在しないフィールドです。各ケースの最大タイムスタンプから最小タイムスタンプを差し引くことで、プロセスマイニング分析中に計算される指標です。 例 10日4時間5日12時間21日2時間 | |||
| 処理担当者 ProcessingAgent | 返品プロセスにおいて特定の活動を実行した従業員またはユーザー。 | ||
| 説明 処理担当者は、返品の承認や商品の検査など、特定のタスクの実行責任者を特定します。この属性は、ユーザーレベルでのパフォーマンス分析に不可欠です。高パフォーマンスの従業員、追加トレーニングが必要な領域、およびチーム全体でのワークロード配分の不均衡を特定するのに役立ちます。担当者による活動分析は、「部門別返品プロセスパフォーマンス」ダッシュボードの鍵となります。 その重要性 個人およびチームのパフォーマンス分析、ワークロードのバランス調整、トレーニングニーズの特定を可能にし、運用効率に直接影響を与えます。 取得元 これは、NetSuiteトランザクションのシステムノートサブリストにある「作成者」、「承認者」、またはユーザーフィールドといったフィールドから取得できます。 例 Alice JohnsonBob WilliamsCharlie Brown | |||
| 実際の返金額 ActualRefundAmount | 実際に顧客に返金された最終的な金額。 | ||
| 説明 この属性は、クレジットメモまたは返金トランザクションに記録された、顧客に実際に貸方記入または返金された金額を表します。この金額は、再入荷手数料、送料、破損品の部分返金などの調整により、リクエストされた金額と異なる場合があります。この属性は、財務報告および「返金額不一致率」KPIの計算に不可欠です。 その重要性 返品の真の財務的影響を表し、財務照合および返金精度の分析に不可欠です。 取得元 この値は、返品承認から生成されたクレジットメモトランザクションの「合計」フィールドから取得されます。 例 99.99140.000.00 | |||
| 返品ステータス ReturnAuthorizationStatus | 返品承認の現在のステータス。例えば「承認保留中」、「承認済み」、または「クローズ済み」など。 | ||
| 説明 この属性は、ライフサイクル内での返品ケースの現在の状態を示します。返品の進捗状況を理解し、ケースをセグメント化するために不可欠です。例えば、「受領保留中」ステータスで費やされた時間を分析することで配送遅延を浮き彫りにすることができ、一方「承認保留中」の長い期間は内部のボトルネックを示す可能性があります。また、「クローズ済み」や「却下済み」といった返品の最終結果を決定するためにも使用されます。 その重要性 各返品がプロセスのどの段階にあるかのスナップショットを提供し、ケースの分布、ステータス期間、およびプロセス結果の分析を可能にします。 取得元 これは、NetSuiteの返品承認レコード上の「ステータス」または類似のフィールドに対応します。 例 承認待ち受領待ち承認済み却下クローズ | |||
| 返品タイプ ReturnType | 顧客から提供された理由に基づいた返品の分類。 | ||
| 説明 返品タイプは、「不良品」、「サイズ違い」、「気が変わった」、「説明と異なる」といった根本的な理由に基づいて返品を分類します。この分類は根本原因分析に不可欠です。異なる返品タイプ間でプロセス指標を分析することで、企業は製品品質の問題、説明の不正確さ、または履行エラーを特定できます。この属性は、「タイプ別およびチャネル別返品パフォーマンス」ダッシュボードの鍵となります。 その重要性 返品の根本原因を特定するのに役立ち、製品、マーケティング記述、またはフルフィルメントプロセスにおけるターゲットを絞った改善を可能にし、返品量を削減します。 取得元 これは通常、返品承認フォーム上のカスタムフィールドまたは標準のリスト/レコードフィールドであり、返品理由がキャプチャされます。 例 不良品誤出荷品顧客の不満サイズ/色の間違い | |||
| 部署 Department | 特定の段階で返品ケースの処理を担当する事業部門またはチーム。 | ||
| 説明 この属性は、プロセス活動を「カスタマーサービス」、「倉庫」、「財務」といった特定の部門に割り当てます。これはチーム間の引き渡しを理解し、部門ごとのボトルネックを特定するために不可欠です。特定の部門内または部門が待機している時間を分析することで、組織は遅延の原因を正確に特定し、リソース割り当てを最適化できます。これは、「部門別返品プロセスパフォーマンス」ダッシュボードの主要なディメンションです。 その重要性 機能領域ごとのプロセスパフォーマンス分析を可能にし、部門間の引き継ぎ遅延や部門のボトルネックを浮き彫りにします。 取得元 これは、アクティビティに関連付けられたユーザーまたは従業員レコード、あるいはトランザクション自体の「部門」フィールドから導出できます。多くの場合、NetSuiteの従業員レコードで設定されます。 例 倉庫カスタマーサポート財務品質保証 | |||
| `製品識別子` ProductIdentifier | 返品される製品の固有の識別子。SKUや商品番号など。 | ||
| 説明 この属性は、返品に関わる特定の商品を特定します。製品レベルで返品を分析することは、高い返品率を示す商品(品質欠陥、不適切な説明、その他の問題を示唆する可能性のあるもの)を特定するために不可欠です。このデータは、製品パフォーマンスの詳細分析を可能にし、製品開発、調達、マーケティングに関連する意思決定を通知することができます。 その重要性 返品プロセスデータを特定の製品と連携させることで、製品関連の問題の根本原因分析を可能にし、全体の返品率を削減するのに役立ちます。 取得元 これは、返品承認レコードの「商品」サブリストにあります。「商品」フィールドに対応します。 例 SKU-TEE-BL-LPROD-00543ITEM-987123 | |||
| SLA準拠 IsSlaCompliant | 返金が定義されたSLA目標内で処理されたかどうかを示す計算済みフラグです。 | ||
| 説明 このブール属性は、「返金処理済み」タイムスタンプと「返金SLA目標日」を比較することで導出されます。返金が目標日またはそれ以前に処理された場合、値はtrueとなり、それ以外の場合はfalseとなります。このフラグは、「返金SLA遵守監視」ダッシュボードのようなコンプライアンスレポートやダッシュボードの作成を簡素化し、「返金SLA達成率」KPIの計算に使用されます。 その重要性 ケースごとのSLAパフォーマンスについて明確な二者択一の結果を提供し、時間の経過とともに遵守率を簡単に追跡、報告、分析できるようにします。 取得元 この属性は、データ変換中またはプロセスマイニングツール内で計算されます。ロジックは、「返金処理済み」の 例 truefalse | |||
| ポリシー遵守 ReturnPolicyAdherence | 返品が確立された会社の返品ポリシーに準拠しているかどうかを示します。 | ||
| 説明 このブール値またはカテゴリ属性は、返品期間、商品の状態、購入証明といった事前定義されたすべての基準を返品が満たしているかどうかをフラグ付けします。コンプライアンスの監視と例外の管理に使用されます。「返品ポリシー遵守例外」ダッシュボードは、この属性に依存して特別な処理やレビューが必要なケースを強調表示し、リスクを最小限に抑え、一貫したルール適用を確保するのに役立ちます。 その重要性 返品ポリシーの監視と実施に役立ち、コンプライアンス違反の返品による財務リスクを軽減し、公平性と一貫性を確保します。 取得元 これはほぼ間違いなく、ワークフローを通じて管理される、返品承認レコード上のカスタムフィールド(チェックボックスまたはリストの可能性あり)でしょう。 例 準拠規定外 - 期間外例外承認済み | |||
| リクエストされた返金額 RequestedRefundAmount | 返品のために最初期にリクエストされた、または予想された返金の金額。 | ||
| 説明 この属性は、プロセス開始時の予想される返金額を保存します。通常、返品された商品の元の購入価格に基づいています。この金額は、最終的な返金額と比較するためのベースラインとして機能します。「返金額不一致率」KPIは、この値と実際の返金額を直接比較し、再入荷手数料、部分返金、またはその他の調整によって引き起こされる差異を特定します。 その重要性 財務分析のベースラインを提供し、予測される返金額と実際の返金額の間の不一致を追跡し、調整の理由を特定するのに役立ちます。 取得元 この値は、返品承認トランザクションの明細項目にある「金額」または「レート」フィールドから導出されます。 例 99.99150.0025.50 | |||
| 自動化 IsAutomated | ある活動がシステムによって自動的に実行されたかどうかを示すブール値フラグです。 | ||
| 説明 この属性は、活動がユーザーによって実行されたか、自動システム、スクリプト、またはワークフローによって実行されたかを示します。例えば、最初の「返品承認作成済み」イベントは顧客ポータルを介して自動化される場合がありますが、「商品検査済み」は手動の活動です。自動化を追跡することは、手動ステップを自動化する機会を特定し、既存の自動化による効率向上を測定するのに役立ちます。 その重要性 手動タスクと自動化タスクを区別するのに役立ち、自動化の機会を特定し、デジタルトランスフォーメーションの取り組みの影響を測定するために重要です。 取得元 これは、イベントに関連付けられたユーザーから推測できます。NetSuiteのシステム生成イベントは、多くの場合、特定のシステムユーザーまたはスクリプトIDに関連付けられます。 例 truefalse | |||
| 返品チャネル ReturnChannel | 元の購入が行われた、または返品が開始されたチャネル。 | ||
| 説明 返品チャネルは、返品の発生元を示します。例えば、「オンライン」、「店舗」、または「マーケットプレイス」などです。異なるチャネルは、独自の返品プロセス、コスト、顧客期待を持つ可能性があります。チャネルごとのパフォーマンスを分析することで、企業は各特定のプロセスを最適化し、リソースを効果的に割り当て、チャネル固有の問題を理解するのに役立ちます。これは、「タイプ別およびチャネル別返品パフォーマンス」ダッシュボードのコア属性です。 その重要性 異なるビジネスチャネル間でのパフォーマンス比較を可能にし、返品がどのように開始および処理されるかに特有の非効率性やベストプラクティスを明らかにします。 取得元 この情報は、多くの場合、返品に関連付けられた元の販売注文レコードから取得されます。「チャネル」または「場所」フィールドに保存されている可能性があります。 例 ウェブストア小売店Amazonマーケットプレイス電話注文 | |||
| 返品状態 ReturnCondition | 検査時に評価された返品商品の状態。例えば「新品」、「破損」、「使用済み」など。 | ||
| 説明 この属性は、返品商品の物理検査の結果を記録します。この状態は、全額返金されるか、商品が補充されるか、廃棄する必要があるかなど、その後のステップを決定します。この評価の一貫性と処理時間の分析は、「返品状態評価品質」ダッシュボードの焦点であり、財務照合および在庫管理にとって非常に重要です。 その重要性 返品の財務結果およびその後の在庫行動に直接影響します。一貫性のない評価は、金銭的損失やプロセス手戻りにつながる可能性があります。 取得元 これは、商品受領レコードまたは返品承認レコード上のカスタムフィールドである可能性が高く、検査中に倉庫スタッフによって入力されます。 例 再販可能破損 - 箱入り中古 - 良好な状態欠品 | |||
| 返金SLA目標日 RefundSlaTargetDate | サービスレベル契約に従って返金が処理されると予想される目標日。 | ||
| 説明 返金SLA目標日は、顧客への返金処理に関するコミットメントを表す計算されたタイムスタンプです。通常、「商品受領」や「返金承認済み」などの主要イベントに、5営業日といった事前定義された期間を追加して計算されます。この属性は、「返金SLA遵守監視」ダッシュボードおよび「返金SLA達成率」KPIに不可欠であり、企業が約束に対するパフォーマンスを測定できるようにします。 その重要性 顧客との約束に対するパフォーマンスの定量的測定を可能にし、顧客満足度と信頼を維持するために不可欠です。 取得元 この日付は通常、標準フィールドではありません。「商品受領」日などの主要なタイムスタンプに、事前定義されたSLA期間(例:5日間)を追加することで導出する必要があります。 例 2023-11-01T23:59:59Z2023-11-05T23:59:59Z2023-11-10T23:59:59Z | |||
| 返金額の不一致 RefundAmountDiscrepancy | リクエストされた返金額と実際に返金された金額との間の計算された差額。 | ||
| 説明 この指標は、「リクエストされた返金額」から「実際の返金額」を差し引いて計算されます。ゼロ以外の値は、再入荷手数料や破損品など、プロセス中に調整が行われたことを示します。この属性は、「返金額不一致率」KPIの分析を強化するために使用され、重要な財務調整を伴うケースをさらにレビューするためにフラグ付けするのに役立ちます。 その重要性 返品プロセス中に発生した財務調整を強調表示し、不一致が発生する理由、およびそれらが一貫性があり正当であるかどうかを分析できるようにします。 取得元 これは計算された属性です。計算式は、 例 0.0010.00-5.00 | |||
| 顧客ID CustomerId | 返品を開始する顧客の固有の識別子。 | ||
| 説明 顧客IDは、返品トランザクションを特定の顧客にリンクします。これにより、頻繁な返品を行う顧客を特定するといった顧客中心の分析が可能となり、不満や不正行為を示唆する可能性があります。また、顧客タイプや価値に基づいてプロセスパフォーマンスをセグメント化できるため、主要アカウントへのサービスを優先順位付けするのに役立ちます。 その重要性 顧客レベルでの返品行動分析を促進し、セグメントやLTV(顧客生涯価値)などの顧客属性に基づいてプロセスをセグメント化できます。 取得元 これは、NetSuiteの返品承認レコードのヘッダーにある「顧客」または「エンティティ」フィールドです。 例 CUST-001CUST-002CUST-003 | |||
返品・返金処理活動
| アクティビティ | 説明 | ||
|---|---|---|---|
| クレジットメモ作成 | このアクティビティは、クレジットメモを作成することで返品の財務部分が開始されたことを示します。この文書は顧客に返金される金額を詳細に記述し、商品が受領および承認された後、返品承認から作成されます。 | ||
| その重要性 クレジットメモの作成は、財務上の重要なマイルストーンです。商品受領からクレジットメモ作成までの時間は、検査からクレジット発行までのプロセスの効率性を明らかにします。 取得元 このイベントは、クレジットメモトランザクションの作成タイムスタンプです。クレジットメモの「作成元」フィールドは、それを返品承認にリンクします。 取得 NetSuiteクレジットメモトランザクションのレコード作成日。 イベントタイプ explicit | |||
| 品目受領済み | このアクティビティは、返品された商品が倉庫または処理センターで物理的に受領されたことを示します。NetSuiteでは、元の返品承認にリンクされた商品受領トランザクションを作成することで、これが明示的に記録されます。 | ||
| その重要性 これは、プロセスを顧客の行動から内部処理へと移行させる重要なマイルストーンです。「返品承認済み」から「商品受領」までの時間は顧客の返品速度を測定し、このイベント後の時間は内部効率を測定します。 取得元 このイベントは、商品受領トランザクションの作成タイムスタンプです。このレコードは、元の返品承認に直接リンクされています。 取得 RAにリンクされたNetSuite入庫トランザクションのレコード作成日。 イベントタイプ explicit | |||
| 返品承認作成済み | このアクティビティは、顧客が商品の返品をリクエストした際に返品プロセスが開始されることを示します。NetSuiteでは、新しい返品承認(RA)レコードの作成を通じて明示的にキャプチャされ、これが返品の主要なケース識別子として機能します。 | ||
| その重要性 プロセスの開始点として、この活動は返品の総サイクルタイムを測定し、時間の経過に伴う返品リクエストの量を分析するために不可欠です。 取得元 このイベントは、NetSuiteの返品承認レコードの作成タイムスタンプです。ユーザー、日付、および初期ステータス(例:「承認保留中」)は、通常このレコードにキャプチャされます。 取得 NetSuite返品承認トランザクションのレコード作成日。 イベントタイプ explicit | |||
| 返品承認書クローズ済み | これは最終活動であり、すべての処理が完了した後に返品ケースの管理上のクローズを示します。これは、返品承認レコードの最終ステータスが「クローズ済み」状態に変更されたことから推測されます。 | ||
| その重要性 プロセスの決定的な終点として、この活動はエンドツーエンドのサイクルタイムを計算し、返金処理後も長期間未解決のままになっているケースを特定するために不可欠です。 取得元 返品承認レコードのシステムノートまたはワークフロー履歴から推測されます。具体的には、「ステータス」フィールドが「クローズ済み」などの最終的な終端状態に更新された場合です。 取得 返品承認レコードのステータスが「クローズ済み」状態に変更されたことを検出します。 イベントタイプ inferred | |||
| 返品承認書承認済み | このアクティビティは、従業員による顧客の返品リクエストの正式な承認を表し、プロセスを前進させることを可能にします。通常、返品承認レコードのステータスフィールドの変更、例えば「承認保留中」から「受領保留中」への変更から推測してキャプチャされます。 | ||
| その重要性 この承認ステップを追跡することは、初期レビュー段階でのボトルネックを特定するために不可欠です。ここでの遅延は、顧客に通知し、返品された商品を受け取るまでにかかる時間に直接影響します。 取得元 返品承認レコードのシステムノートまたはワークフロー履歴から推測されます。具体的には、「ステータス」フィールドが承認済み状態(例:「受領待ち」)に更新された場合です。 取得 返品承認レコードのステータスが「承認済み」状態に変更されたことを検出します。 イベントタイプ inferred | |||
| 返金処理済み | これは、資金が顧客に返還される最終的な財務決済です。これは、クレジットメモから生成される顧客返金トランザクションの作成によって明示的にキャプチャされます。 | ||
| その重要性 このアクティビティは、SLA遵守と顧客満足度を測定するために不可欠です。「クレジットメモ承認済み」から「返金処理済み」までの期間は、財務部門または経理部門の速度を直接反映します。 取得元 このイベントは、顧客返金トランザクションの作成タイムスタンプです。このトランザクションの「作成元」フィールドは、それをクレジットメモにリンクします。 取得 NetSuite顧客返金トランザクションのレコード作成日。 イベントタイプ explicit | |||
| クレジットメモ充当 | このアクティビティは、クレジットメモが未払い顧客請求書に適用される現金返金の代替案を表します。クレジットメモの「適用先」リンクから推測され、クレジットが使用されたことを示します。 | ||
| その重要性 現金返金と与信申請を区別することは、財務分析にとって重要です。このパスは、直接的な返金とは異なるタイプのプロセス解決を表します。 取得元 貸方票のシステムノートまたは関連レコードから推測されます。具体的には、顧客の残高を相殺するために請求書トランザクションにリンクされた場合です。 取得 貸方票が請求書トランザクションに適用されたことを検出します。 イベントタイプ inferred | |||
| 交換注文作成済み | このアクティビティは、返金ではなく顧客のために新しい販売注文が作成される交換シナリオを表します。このイベントは通常、元の返品承認にリンクされた販売注文の作成によってキャプチャされます。 | ||
| その重要性 交換を個別の経路として追跡することで、顧客の好みや、交換プロセスと返金プロセスの効率性を分析するのに役立ちます。これは一般的で重要なバリアントです。 取得元 このイベントは、新しい販売注文トランザクションの作成タイムスタンプです。返品承認へのリンクは、標準フィールドまたはカスタムフィールドにある可能性があり、システム分析が必要です。 取得 返品承認にリンクされた販売注文のレコード作成日。 イベントタイプ explicit | |||
| 品目検査済み | この概念的な活動は、返品された商品の物理的な検査が完了し、その状態が評価されたことを表します。NetSuiteには標準の「検査」オブジェクトがないため、これは通常、返品承認または商品受領上のカスタムフィールドまたはステータス更新から推測されます。 | ||
| その重要性 検査はしばしば主要なボトルネックとなります。その完了時間を追跡することは、担当者のパフォーマンス、決定の一貫性、およびその後の返金承認への影響を分析するために不可欠です。 取得元 システム分析が必要です。これはReturnAuthorizationレコードのカスタム「検査ステータス」フィールドの変更から推測されるか、記録されないオフラインプロセスである可能性があります。 取得 返品承認または入荷レコード上のカスタムステータスフィールドの変更から推測されます。 イベントタイプ inferred | |||
| 貸方票承認済み | クレジットメモの正式な承認を表し、高額な返金や財務管理の一部としてしばしば必要とされます。これは、クレジットメモレコードのステータス変更から推測され、適用または支払いの準備ができたことを示します。 | ||
| その重要性 財務承認が必要な場合、このステップが大きなボトルネックになる可能性があります。その期間を分析することで、顧客への返金を遅らせることなく財務管理を合理化するのに役立ちます。 取得元 貸方票レコードのシステムノートから推測されます。具体的には、承認ステータスフィールドが「承認待ち」から「承認済み」または「オープン」に更新された場合です。 取得 貸方票トランザクションのステータスが「承認済み」状態に変更されたことを検出します。 イベントタイプ inferred | |||
| 返品承認書却下済み | これは、顧客の返品リクエストを拒否する決定を表し、しばしばポリシー違反が理由となります。このイベントは、返品承認レコードのステータスが「却下済み」または「クローズ済み」状態に変化したことから推測され、それ以上の処理は行われません。 | ||
| その重要性 拒否されたケースを分析することは、コンプライアンスに準拠しない返品リクエストの一般的な理由を特定するのに役立ち、顧客コミュニケーションやポリシーの明確化に情報を提供できます。これは「ハッピーパス」からの重要な逸脱です。 取得元 返品承認レコードのシステムノートまたはワークフロー履歴から推測されます。具体的には、「ステータス」フィールドが最終的な「拒否済み」状態に更新された場合です。 取得 返品承認レコードのステータスが「拒否済み」状態に変更されたことを検出します。 イベントタイプ inferred | |||
| 顧客通知済み | 承認、商品受領、返金処理済みといった主要なステータス更新について顧客に通知することを表します。これは通常、レコードのコミュニケーションタブに記録されたシステム生成メールのタイムスタンプから推測されます。 | ||
| その重要性 タイムリーなコミュニケーションは顧客満足度の鍵です。マイルストーンと顧客通知の間の遅延を測定することは、顧客体験のギャップを特定するのに役立ちます。 取得元 システム分析が必要です。ReturnAuthorizationまたはCreditMemoのコミュニケーションサブタブにある送信メールまたはユーザーメモのタイムスタンプから取得されます。 取得 ケースにリンクされたメールまたはコミュニケーションログエントリのタイムスタンプ。 イベントタイプ inferred | |||
抽出ガイド
ステップ
- 保存済み検索の作成へ移動: NetSuiteにログインします。[レポート] > [新規検索]へ移動します。新規保存済み検索ページで、「トランザクション」をクリックします。
- 主要な基準の定義: 保存済み検索設定ページの「基準」タブおよび「標準」サブタブで、返品承認レコードを分離するために以下のフィルターを設定します。
TypeがReturn Authorizationである。Main LineがYesである。Date Createdフィルターを追加し、例えば「過去3ヶ月以内」など、希望する日付範囲に設定します。これはデータ量を管理するために不可欠です。
- 属性用の結果列の構成: 「結果」タブに移動します。イベントログの属性となる以下のフィールドを追加します。必要に応じて「カスタムラベル」を使用して名前を変更し、明確にします。
- ケースID:
Document NumberまたはTranID(カスタムラベル: ReturnCaseId) - 返品ステータス:
Status(カスタムラベル: ReturnAuthorizationStatus) - 処理担当者:
Created Byまたは該当する場合はカスタムフィールド (カスタムラベル: ProcessingAgent) - 部門:
Department(カスタムラベル: Department) - 返品タイプ:
[Your Return Reason Field]のようなカスタムフィールド (カスタムラベル: ReturnType) - 返金額:
Amount(カスタムラベル: ActualRefundAmount)
- ケースID:
- イベントタイムスタンプ用の数式列の追加: これは最も重要なステップです。12の各活動について、「数式(日付/時刻)」列を追加します。各数式はCASEステートメントを使用して、その特定のイベントが発生した場合にのみタイムスタンプを返します。各活動に使用する正確な数式については、「クエリ」セクションを参照してください。
- 静的列の追加: 結果に2つの「数式(テキスト)」列を追加します。
SourceSystemには、数式:'NetSuite'を使用します。LastDataUpdateには、実行日を表す数式、例えば{today}を使用します。正確なタイムスタンプとしては、エクスポート時刻になります。
- 検索の保存とエクスポート: 検索に「ProcessMind Returns Extraction」のような説明的な名前を付けます。「保存して実行」をクリックします。結果が表示されたら、エクスポートアイコンをクリックし、「CSV」を選択します。
- データをイベントログに変換: エクスポートされたCSVは「ワイド」形式であり、返品ケースごとに1行、異なるイベントタイムスタンプの列が多数あります。これを「ロング」形式のイベントログに変換する必要があります。この変換を実行するには、Microsoft Excel Power Query(列のピボット解除)、Python、または別のスクリプトツールを使用します。
- CSVの各行について、空でないイベントタイムスタンプ列ごとに複数の新しい行を作成します。
- 新しく変換されたテーブルには、
ReturnCaseId、ActivityName、EventTimestampなどの列が必要です。ActivityNameは元のタイムスタンプ列のヘッダー(例:「返品承認作成済み」)から取得され、EventTimestampはその列の値です。
- アップロードの最終準備: 最終的なCSVファイルに、
ReturnCaseId、ActivityName、EventTimestamp、SourceSystem、LastDataUpdate、および推奨されるその他の属性の必須ヘッダーが含まれていることを確認します。これでファイルはProcessMindへのアップロード準備が整いました。
設定
- 検索タイプ: 保存済み検索は
Transaction検索である必要があります。 - 日付範囲: 返品承認の
Date Createdフィールドに日付範囲フィルターを適用することが重要です。データ完全性とパフォーマンスのバランスをとるために、3〜6ヶ月の範囲が推奨されます。 - プライマリフィルター: 検索は、
TypeがReturn Authorizationであり、Main LineがYesであるレコードにフィルターをかける必要があります。これにより、返品ケースごとに1つの初期レコードが確実に取得されます。 - カスタムフィールド: この抽出の精度、特に「商品検査済み」のような概念的なイベントや「返品タイプ」のような属性の精度は、トランザクションレコードにおける貴社のカスタムフィールドの使用に大きく依存します。提供された数式には、
{custbody_...}のようなプレースホルダーが含まれており、貴社のNetSuite設定に合わせて調整する必要があります。 - ユーザー権限: 検索を実行するユーザーは、関連するすべてのトランザクションタイプ(返品承認、入荷、貸方票、顧客返金、販売注文)に対する表示権限が必要です。
- パフォーマンス: 返品量が多いアカウントの場合、この包括的な検索は遅くなる可能性があります。オフピーク時に実行するか、ファイルキャビネットに自動的にエクスポートするようにスケジュールすることを検討してください。
a クエリ例 config
This configuration represents the settings in the NetSuite Saved Search UI. The 'Results' tab should be configured with the following columns and formulas.
**Criteria Tab:**
* `Type` = `Return Authorization`
* `Main Line` = `true`
* `Date Created` = `[Specify Desired Date Range]`
**Results Tab (Columns):**
| Custom Label | Field / Formula Type | Formula / Field ID |
|---|---|---|
| `ReturnCaseId` | Formula (Text) | `{tranid}` |
| `SourceSystem` | Formula (Text) | `'NetSuite'` |
| `LastDataUpdate` | Formula (Date/Time) | `{today}` |
| `ReturnAuthorizationStatus` | Field | `Status` |
| `ProcessingAgent` | Field | `Created By` |
| `Department` | Field | `Department` |
| `ReturnType` | Field | `{custbody_return_reason}` |
| `ActualRefundAmount` | Field | `Amount` |
| `CycleTime` | Formula (Numeric) | `CASE WHEN {status} = 'Closed' THEN {lastmodifieddate} - {datecreated} ELSE NULL END` |
| `Activity_ReturnAuthorizationCreated` | Field | `Date Created` |
| `Activity_ReturnAuthorizationApproved` | Formula (Date/Time) | `MIN(CASE WHEN {systemnotes.newvalue} = 'Pending Receipt' AND {systemnotes.field} = 'Status' THEN {systemnotes.date} ELSE NULL END)` |
| `Activity_ReturnAuthorizationRejected` | Formula (Date/Time) | `MIN(CASE WHEN {systemnotes.newvalue} = 'Rejected' AND {systemnotes.field} = 'Status' THEN {systemnotes.date} ELSE NULL END)` |
| `Activity_ItemReceived` | Formula (Date/Time) | `{applyingtransaction.trandate}` |
| `Activity_ItemInspected` | Formula (Date/Time) | `CASE WHEN {custbody_inspection_status} = 'Complete' THEN {custbody_inspection_date} ELSE NULL END` |
| `Activity_CreditMemoCreated` | Formula (Date/Time) | `{createdfrom.trandate}` |
| `Activity_CreditMemoApproved` | Formula (Date/Time) | `MIN(CASE WHEN {createdfrom.systemnotes.newvalue} = 'Open' AND {createdfrom.systemnotes.field} = 'Status' THEN {createdfrom.systemnotes.date} ELSE NULL END)` |
| `Activity_RefundProcessed` | Formula (Date/Time) | `{createdfrom.appliedtotransaction.trandate}` |
| `Activity_CreditMemoApplied` | Formula (Date/Time) | `CASE WHEN {createdfrom.status} = 'Fully Applied' AND {createdfrom.appliedtotransaction.type} = 'Invoice' THEN {createdfrom.appliedtotransaction.date} ELSE NULL END` |
| `Activity_ExchangeOrderCreated` | Formula (Date/Time) | `{custbody_exchange_order.trandate}` |
| `Activity_CustomerNotified` | Formula (Date/Time) | `MAX({messages.messagedate})` |
| `Activity_ReturnAuthorizationClosed` | Formula (Date/Time) | `MIN(CASE WHEN {systemnotes.newvalue} = 'Closed' AND {systemnotes.field} = 'Status' THEN {systemnotes.date} ELSE NULL END)` | ステップ
- SuiteAnalytics Connectの有効化: NetSuiteアカウントにSuiteAnalytics Connectライセンスがあることを確認してください。管理者は、[設定] > [会社] > [機能の有効化] > [分析]からこの機能を有効にする必要があります。
- ユーザー権限の割り当て: 接続ユーザーロールに「SuiteAnalytics Connect」権限を付与します。このユーザーは、トランザクション、従業員、顧客など、クエリ対象となるすべてのレコードに対する表示権限も必要です。
- ODBCドライバーのインストール: NetSuiteのSuiteAnalytics Connectダウンロードページから、ご使用のオペレーティングシステムに適したNetSuite ODBCドライバーをダウンロードしてインストールします。
- DSNの構成: クエリを実行するマシン上でDSN(データソース名)を設定します。サービスデータソース、サーバーホスト名、ポート、ロールID、アカウントID、および認証情報を入力します。
- SQLクライアントの接続: DBeaverやMicrosoft SQL Server Management StudioなどのSQLクライアントを使用して、構成したDSNを使用してNetSuiteに接続します。
- SQLクエリの準備: 提供されたSQLクエリをクライアントにコピーします。このクエリは、返品および返金プロセスにおけるすべての主要イベントを抽出するように設計されています。
- クエリのカスタマイズ: クエリ内のプレースホルダー値を変更します。少なくとも、
ReturnAuthorizations共通テーブル式(CTE)内の日付範囲を更新し、目的の期間でフィルターをかける必要があります。また、CUSTBODY_RETURN_TYPEのようなカスタムフィールド名や特定のステータス値を、NetSuiteの設定に合わせて調整する必要がある場合があります。 - クエリの実行: カスタマイズしたSQLクエリをNetSuiteデータベースレプリカに対して実行します。実行時間は、日付範囲とデータ量によって異なる場合があります。
- データの確認とエクスポート: クエリが完了したら、結果が正しいことを確認します。結果セット全体をCSVファイルにエクスポートします。
- アップロードの最終準備: CSVファイルのヘッダーが、
ReturnCaseId、ActivityName、EventTimestamp、SourceSystem、LastDataUpdateなど、必要な属性と一致していることを確認します。EventTimestamp列が一貫した日付/時刻形式であることを確認します。これでファイルはProcessMindへのアップロード準備が整いました。
設定
- 前提条件: SuiteAnalytics Connectアドオンモジュールを含むNetSuiteライセンスが必要です。接続を実行するユーザーは、「SuiteAnalytics Connect」権限と、トランザクション、エンティティ、従業員レコードへの読み取りアクセス権を持つロールが必要です。
- データソース構成: NetSuite ODBCドライバーを使用してDSN(データソース名)を構成する必要があります。これには、アカウントID、ロールID、および認証情報が必要です。本番環境の場合、サービスホストは通常
odbcserver.netsuite.comです。 - 日付範囲フィルター: 返品承認を選択する初期CTEに日付範囲フィルターを適用することが重要です。フィルターがない場合、クエリはすべての返品データを取得しようとし、非常に遅くなったりタイムアウトしたりする可能性があります。初期分析には3〜6ヶ月の範囲が推奨されます。
- 主要トランザクションタイプ: このクエリは、いくつかの主要なトランザクションタイプ(ReturnAuthorization、ItemReceipt、CreditMemo、CustomerRefund、SalesOrd(交換用))を対象としています。お客様のプロセスがこれらの標準オブジェクトを使用していることを確認してください。
- カスタムフィールド依存関係: 「商品検査済み」などの活動や「返品タイプ」などの属性は、カスタムフィールドで捕捉されることが多いです。提供されたクエリでは、
CUSTBODY_INSPECTION_STATUSやCUSTBODY_RETURN_TYPEのようなプレースホルダーが使用されています。お客様のシステムで正しいカスタムフィールドIDを特定し、それに応じてクエリを更新する必要があります。 - パフォーマンスに関する考慮事項: これは、複数の結合と大規模な
UNION ALL構造を持つ複雑なクエリです。システムパフォーマンスへの影響を最小限に抑えるため、オフピーク時に実行してください。非常に大規模なデータセットの場合は、より小さな時間間隔でクエリを実行し、結果を追記することを検討してください。
a クエリ例 sql
WITH ReturnAuthorizations AS (
SELECT
T.TRANSACTION_ID AS ReturnCaseId,
T.TRANDATE
FROM
TRANSACTION T
WHERE
T.TYPE = 'ReturnAuthorization'
AND T.TRANDATE BETWEEN TO_DATE('[YYYY-MM-DD]', 'YYYY-MM-DD') AND TO_DATE('[YYYY-MM-DD]', 'YYYY-MM-DD')
)
SELECT
RA.ReturnCaseId AS "ReturnCaseId",
'Return Authorization Created' AS "ActivityName",
T.CREATED_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM TRANSACTION T
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON T.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
UNION ALL
SELECT
RA.ReturnCaseId,
'Return Authorization Approved' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
SN.NEW_VALUE AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION T ON SN.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE SN.FIELD = 'TRANSACTION.STATUS' AND SN.NEW_VALUE = 'Pending Receipt'
UNION ALL
SELECT
RA.ReturnCaseId,
'Return Authorization Rejected' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
SN.NEW_VALUE AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION T ON SN.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE SN.FIELD = 'TRANSACTION.STATUS' AND SN.NEW_VALUE IN ('Rejected', 'Closed')
UNION ALL
SELECT
RA.ReturnCaseId,
'Item Received' AS "ActivityName",
IR.CREATED_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T_RA.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM TRANSACTION IR
INNER JOIN TRANSACTION T_RA ON IR.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON IR.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE IR.TYPE = 'ItemReceipt'
UNION ALL
SELECT
RA.ReturnCaseId,
'Item Inspected' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION T ON SN.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE SN.FIELD = 'TRANSACTION.CUSTBODY_INSPECTION_STATUS' AND SN.NEW_VALUE = 'Completed'
UNION ALL
SELECT
RA.ReturnCaseId,
'Credit Memo Created' AS "ActivityName",
CM.CREATED_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T_RA.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM TRANSACTION CM
INNER JOIN TRANSACTION T_RA ON CM.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON CM.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE CM.TYPE = 'CreditMemo'
UNION ALL
SELECT
RA.ReturnCaseId,
'Credit Memo Approved' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
SN.NEW_VALUE AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION CM ON SN.TRANSACTION_ID = CM.TRANSACTION_ID
INNER JOIN TRANSACTION T_RA ON CM.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE CM.TYPE = 'CreditMemo' AND SN.FIELD = 'TRANSACTION.APPROVAL_STATUS' AND SN.NEW_VALUE = 'Approved'
UNION ALL
SELECT
RA.ReturnCaseId,
'Refund Processed' AS "ActivityName",
REF.CREATED_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T_RA.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
ABS(REF.TOTAL) AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM TRANSACTION REF
INNER JOIN TRANSACTION CM ON REF.APPLIED_TO_TRANSACTION_ID = CM.TRANSACTION_ID
INNER JOIN TRANSACTION T_RA ON CM.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON REF.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE REF.TYPE = 'CustomerRefund'
UNION ALL
SELECT
RA.ReturnCaseId,
'Credit Memo Applied' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
SN.NEW_VALUE AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION CM ON SN.TRANSACTION_ID = CM.TRANSACTION_ID
INNER JOIN TRANSACTION T_RA ON CM.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE CM.TYPE = 'CreditMemo' AND SN.FIELD = 'TRANSACTION.STATUS' AND SN.NEW_VALUE = 'Fully Applied'
UNION ALL
SELECT
RA.ReturnCaseId,
'Exchange Order Created' AS "ActivityName",
SO.CREATED_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T_RA.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM TRANSACTION SO
INNER JOIN TRANSACTION T_RA ON SO.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SO.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE SO.TYPE = 'SalesOrd'
UNION ALL
SELECT
RA.ReturnCaseId,
'Customer Notified' AS "ActivityName",
MSG.MESSAGE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM MESSAGES MSG
INNER JOIN TRANSACTION T ON MSG.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON MSG.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE MSG.INCOMING = 'F'
UNION ALL
SELECT
RA.ReturnCaseId,
'Return Authorization Closed' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
SN.NEW_VALUE AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION T ON SN.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE T.TYPE = 'ReturnAuthorization' AND SN.FIELD = 'TRANSACTION.STATUS' AND SN.NEW_VALUE LIKE '%Closed%';