返品・返金処理のデータテンプレート
返品・返金処理のデータテンプレート
- 収集を推奨する属性
- 追跡すべき主なアクティビティ
- NetSuiteからのデータ抽出方法
返品・返金処理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 返品プロセスで発生した業務イベントや手順の名称です。例:「返品商品の検品」「返金処理の完了」。 | ||
| 説明 アクティビティ名は、返品・返金の一連の流れにおける個別の手順や節目を示します。各イベントを日時順に並べて、プロセスフローを作成します。アクティビティの順序や頻度を分析すると、よくある処理経路、手順間のボトルネック、手戻りや繰り返し作業を特定できます。例:「返品承認の作成」「返品商品の受領」「クレジットメモの承認」。 重要な理由 プロセスの各手順を定義する属性です。プロセスマップの表示、フローの違いの分析、ボトルネックや手戻りの特定に欠かせません。 入手先 通常、返品承認やクレジットメモなどの取引レコードのステータス変更、またはシステムノートやカスタムイベントログに記録されたユーザー操作から取得します。 例 返品承認の作成返品商品の受領返品商品の検品返金処理の完了返品承認のクローズ | |||
| イベント日時 EventTimestamp | アクティビティが発生した正確な日時です。プロセスの時系列を示します。 | ||
| 説明 イベント日時には、アクティビティが発生した正確な時刻が記録されます。イベントを正しい順序に並べるため、また時間に基づく分析全般を行うために欠かせないデータです。アクティビティ間の所要時間、ケース全体のサイクルタイム、待ち時間の算出に使われ、パフォーマンスの監視、ボトルネック分析、SLAの遵守状況の確認に役立ちます。プロセスマイニングの分析結果の信頼性を保つには、日時が正確である必要があります。 重要な理由 イベントの時系列を示す属性です。プロセスフローの把握や、サイクルタイム、待ち時間などのパフォーマンス指標の算出に必要です。 入手先 通常、NetSuiteレコードの「Date Created」または「Last Modified Date」フィールド、あるいは取引に関連するSystem Notesサブリストの日時から取得します。 例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:12:05Z | |||
| 返品ケースID ReturnCaseId | 1件の返品または返金ケースを識別する一意のIDです。申請から完了まで、関連するすべてのアクティビティを紐づけます。 | ||
| 説明 返品ケースIDは、返品の一連の流れを追跡するための主な識別子です。IDごとに1件の返品承認が対応し、商品の受領、検品、返金処理など、関連するすべてのイベントを分析できます。プロセスマイニングでは、このIDを使って返品ごとの全体のプロセスフローを再構成し、サイクルタイムの算出やケース単位の逸脱の特定を行います。 重要な理由 プロセスマイニングの基本となる属性です。個々のイベントを一貫したエンドツーエンドのプロセスインスタンスとして結びつけ、プロセスフローやパフォーマンスを分析できるようにします。 入手先 通常は、NetSuiteのReturn AuthorizationレコードのInternal IDまたはTransaction IDです。 例 RMA-0012345RMA-0012346RMA-0012347 | |||
| ソースシステム SourceSystem | データの抽出元となるシステムです。データの出所を追跡するために使います。 | ||
| 説明 プロセスデータの取得元を示す属性です。この場合、通常は「NetSuite」です。複数のシステムのデータを統合する環境では、ソースシステムを明記することで、データの流れと追跡可能性を明確にできます。 重要な理由 データの出所を示します。データガバナンスや問題の調査に役立ち、複数システムのデータを統合してプロセス全体を把握する場合にも欠かせません。 入手先 通常、データの抽出・変換処理で追加する固定値(「NetSuite」)です。 例 NetSuiteNetSuite ERP | |||
| 最終データ更新日時 LastDataUpdate | このプロセスのデータが最後に更新または再読み込みされた日時です。 | ||
| 説明 データセットがソースシステムから最後に更新された日時を記録する属性です。分析に使うデータがどの程度新しいかを利用者に伝える重要なメタデータです。ダッシュボードに表示することで、データの更新時期を踏まえた判断ができるようになります。 重要な理由 データの更新時期を明示します。分析結果への信頼を高め、現在の業務状況との関連性を理解するうえで欠かせません。 入手先 この日時は、データの抽出、変換、読み込み(ETL)の処理中に生成され、追加されます。 例 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| 処理担当者 ProcessingAgent | 返品プロセスで特定のアクティビティを実行した従業員またはユーザーです。 | ||
| 説明 処理担当者は、返品の承認や商品の検品など、各作業を担当した人を示します。ユーザー単位のパフォーマンス分析に欠かせない属性です。成果を上げている従業員、追加のトレーニングが必要な領域、チーム内の業務負荷の偏りを把握できます。担当者別のアクティビティ分析は、「部門別返品プロセスのパフォーマンス」ダッシュボードの基礎となります。 重要な理由 個人やチームのパフォーマンス、業務負荷の調整、トレーニングの必要性を分析でき、業務効率の向上に直接つながります。 入手先 NetSuite取引の「Created By」「Approved By」などのフィールドや、System Notesサブリストのユーザーフィールドから取得できます。 例 アリス・ジョンソンボブ・ウィリアムズチャーリー・ブラウン | |||
| 実際の返金額 ActualRefundAmount | 顧客に実際に返金された最終金額です。 | ||
| 説明 この属性には、Credit Memoまたは返金取引に記録された、顧客への実際の返金額が入ります。再入庫手数料、送料、破損品の一部返金などの調整により、申請額と異なる場合があります。財務報告と「返金額の差異率」重要業績評価指標(KPI)の算出に欠かせない属性です。 重要な理由 返品による実際の金銭的影響を示します。財務照合や返金の正確性の分析に不可欠です。 入手先 Return Authorizationから作成されたCredit Memo取引の「Total」フィールドから取得します。 例 99.99140.000.00 | |||
| 返品ステータス ReturnAuthorizationStatus | 返品承認の現在のステータスです。例:「承認待ち」「承認済み」「クローズ」。 | ||
| 説明 返品ケースのライフサイクルにおける現在の状態を示す属性です。返品の進捗を把握し、ケースを分類するための基本情報です。たとえば、「入荷待ち」の期間を分析すると配送の遅れが分かり、「承認待ち」が長く続いている場合は社内のボトルネックが考えられます。また、「クローズ」や「却下」など、返品の最終結果を判断する際にも使います。 重要な理由 各返品のプロセス上の現在地を示し、ケースの分布、ステータスごとの所要時間、処理結果を分析できます。 入手先 NetSuiteのReturn Authorizationレコードにある「Status」または同等のフィールドに対応します。 例 承認待ち入荷待ち承認済み却下クローズ | |||
| 返品理由 ReturnType | 顧客が申告した理由に基づく返品の分類です。 | ||
| 説明 返品理由は、「商品不良」「サイズ違い」「購入後の心変わり」「説明と異なる」など、返品の原因に基づいて返品を分類します。根本原因の分析に欠かせない情報です。返品理由ごとにプロセス指標を分析すると、商品の品質、説明の正確さ、出荷処理に関する問題を特定できます。「返品の種類・チャネル別パフォーマンス」ダッシュボードの主要な属性です。 重要な理由 返品の根本原因を特定し、商品、マーケティング上の説明、出荷処理を対象とした改善につなげ、返品件数の削減に役立てます。 入手先 通常、返品理由を記録する返品承認フォームのカスタムフィールド、または標準のリスト/レコードフィールドです。 例 商品不良誤った商品の発送顧客の不満サイズ・色違い | |||
| 部門 Department | 各段階で返品ケースを担当する部門またはチームです。 | ||
| 説明 この属性は、プロセスのアクティビティを「カスタマーサービス」「倉庫」「財務」などの部門に割り当てます。チーム間の引き継ぎを把握し、部門ごとのボトルネックを特定するために欠かせません。ケースが特定の部門で処理される時間や、部門の対応を待つ時間を分析すると、遅延の原因を特定し、リソース配分を見直せます。「部門別返品プロセスのパフォーマンス」ダッシュボードの主要な分析軸です。 重要な理由 部門などの機能別にプロセスのパフォーマンスを分析し、部門間の引き継ぎによる遅延や、部門ごとのボトルネックを明らかにします。 入手先 アクティビティに紐づくユーザーまたは従業員レコード、あるいは取引自体の「Department」フィールドから取得できます。NetSuiteでは、従業員レコードに設定されていることがよくあります。 例 倉庫カスタマーサポート財務品質保証 | |||
| SLAに準拠しているか IsSlaCompliant | 返金が定められたSLA目標内に処理されたかを示す計算済みのフラグです。 | ||
| 説明 この真偽値属性は、「返金処理」日時と「返金SLA目標日」を比較して算出します。目標日までに返金が処理されていればtrue、そうでなければfalseになります。このフラグを使うと、「返金SLA遵守状況の監視」ダッシュボードなどのコンプライアンスレポートやダッシュボードを簡単に作成でき、「返金SLA達成率」重要業績評価指標(KPI)の算出にも利用できます。 重要な理由 ケースごとのSLA達成状況を明確に二択で示すため、コンプライアンス率を継続的に追跡、報告、分析しやすくなります。 入手先 この属性は、データ変換時またはプロセスマイニングツール内で算出します。ロジックは次のとおりです: 例 truefalse | |||
| 商品識別子 ProductIdentifier | 返品対象の商品を識別する一意のIDです。SKUや商品番号などが該当します。 | ||
| 説明 返品対象の商品を特定する属性です。商品単位で返品を分析すると、返品率の高い商品を特定できます。返品率の高さは、品質上の欠陥、説明の不備、その他の問題を示している可能性があります。このデータを詳しく分析することで、商品開発、調達、マーケティングに関する判断に役立てられます。 重要な理由 返品プロセスのデータを特定の商品に紐づけます。商品に関する問題の根本原因を分析し、返品率全体の低減に役立ちます。 入手先 Return Authorizationレコードの「Items」サブリストにある「Item」フィールドです。 例 SKU-TEE-BL-LPROD-00543ITEM-987123 | |||
| 自動処理かどうか IsAutomated | アクティビティがシステムによって自動実行されたかを示す真偽値です。 | ||
| 説明 アクティビティをユーザー、自動システム、スクリプト、ワークフローのいずれが実行したかを示します。たとえば、「返品承認の作成」は顧客ポータルで自動化される一方、「商品の検品」は手作業で行われる場合があります。自動化の状況を追跡すると、手作業の工程を自動化できる箇所を特定し、既存の自動化による効率向上を測定できます。 重要な理由 手作業と自動処理を区別できます。自動化の機会を見つけ、デジタルトランスフォーメーションの取り組みによる効果を測定するうえで役立ちます。 入手先 イベントに関連付けられたユーザーから推定できます。NetSuiteでシステムが生成したイベントには、特定のシステムユーザーまたはスクリプトIDが関連付けられていることがよくあります。 例 truefalse | |||
| 返品チャネル ReturnChannel | 元の商品を購入した、または返品を申請したチャネルです。 | ||
| 説明 返品チャネルは、返品の発生元を示します。例:「オンライン」「店舗」「マーケットプレイス」。チャネルによって返品プロセス、コスト、顧客の期待は異なる場合があります。チャネル別にパフォーマンスを分析すると、各プロセスの改善、リソースの適切な配分、チャネル固有の問題の把握に役立ちます。「返品の種類・チャネル別パフォーマンス」ダッシュボードの主要な属性です。 重要な理由 事業チャネルごとのパフォーマンスを比較し、返品の申請方法や処理方法に固有の非効率な点や優れた取り組みを明らかにします。 入手先 多くの場合、返品に関連する元のSales Orderレコードから取得します。「Channel」または「Location」フィールドに保存されていることがあります。 例 オンラインストア実店舗Amazonマーケットプレイス電話注文 | |||
| 返品ポリシーの遵守状況 ReturnPolicyAdherence | 返品が社内で定められた返品ポリシーに準拠しているかを示します。 | ||
| 説明 この真偽値またはカテゴリ属性は、返品期間、商品の状態、購入証明など、あらかじめ定めた条件を返品がすべて満たしているかを示します。コンプライアンスの監視や例外対応に利用します。「返品ポリシーの遵守に関する例外」ダッシュボードでは、この属性を使って個別対応や確認が必要なケースを特定し、リスクの低減とルールの一貫した適用に役立てます。 重要な理由 返品ポリシーの監視と徹底に役立ち、ポリシーに準拠しない返品による金銭的リスクを抑えながら、公平で一貫した対応を実現できます。 入手先 Return Authorizationレコードに設定するカスタムフィールドで、チェックボックスまたはリスト形式にし、ワークフローで管理するケースがほとんどです。 例 準拠準拠せず・返品期間超過例外承認済み | |||
| 返品商品の状態 ReturnCondition | 検品時に評価された返品商品の状態です。「新品」「破損」「使用済み」などがあります。 | ||
| 説明 この属性には、返品商品の現物検査の結果が記録されます。商品の状態によって、全額返金、在庫への戻し、廃棄など、その後の対応が決まります。評価の一貫性や処理時間の分析は、「返品商品の状態評価の品質」ダッシュボードで行います。これは、財務照合や在庫管理にも欠かせません。 重要な理由 返品の金銭的な結果と、その後の在庫処理に直接影響します。評価にばらつきがあると、金銭的損失や手戻りにつながる可能性があります。 入手先 通常はItem ReceiptレコードまたはReturn Authorizationレコードのカスタムフィールドで、検品時に倉庫担当者が入力します。 例 再販売可能箱の中で破損使用済み・良好な状態部品不足 | |||
| 返金SLA目標日 RefundSlaTargetDate | サービスレベル合意に基づき、返金処理の完了が見込まれる期限日です。 | ||
| 説明 返金SLA目標日は、返金処理について顧客に約束した期限を示す計算済みの日時です。通常、「商品受領」や「返金承認」などの主要イベントに、5営業日などあらかじめ定めた期間を加えて算出します。「返金SLA遵守状況の監視」ダッシュボードと「返金SLA達成率」重要業績評価指標(KPI)に必要な属性であり、顧客への約束に対する実績を測定できます。 重要な理由 顧客への約束に対する実績を定量的に測定できます。顧客満足度と信頼の維持に欠かせません。 入手先 通常、この日付は標準フィールドではありません。「商品受領」日などの主要な日時に、あらかじめ定めたSLA期間(例:5日)を加えて算出します。 例 2023-11-01T23:59:59Z2023-11-05T23:59:59Z2023-11-10T23:59:59Z | |||
| 返金申請額 RequestedRefundAmount | 返品について当初申請された、または見込まれていた返金額です。 | ||
| 説明 この属性には、プロセス開始時点で見込まれる返金額が記録されます。通常は返品商品の元の購入価格に基づきます。この金額を基準として、最終的な返金額と比較します。「返金額の差異率」重要業績評価指標(KPI)では、この値と実際の返金額を直接比較し、再入庫手数料、一部返金、その他の調整による差異を特定します。 重要な理由 財務分析の基準となり、見込み額と実際の返金額の差異を追跡し、調整理由を特定できます。 入手先 Return Authorization取引の明細行にある「Amount」または「Rate」フィールドから取得します。 例 99.99150.0025.50 | |||
| 返金額の差異 RefundAmountDiscrepancy | 申請された返金額と実際の返金額の差として算出されます。 | ||
| 説明 この指標は、「返金申請額」から「実際の返金額」を差し引いて算出します。ゼロ以外の値は、再入庫手数料や商品の破損などにより、プロセス中に調整が行われたことを示します。「返金額の差異率」重要業績評価指標(KPI)の分析に使われ、金額の調整が大きいケースを確認対象として特定できます。 重要な理由 返品プロセス中に行われた金額調整が明らかになり、差異が生じた理由や、調整が一貫して妥当なものかを分析できます。 入手先 計算属性です。計算式: 例 0.0010.00-5.00 | |||
| 顧客ID CustomerId | 返品を申請した顧客を識別する一意のIDです。 | ||
| 説明 顧客IDは、返品取引を特定の顧客に結び付けます。これにより、返品頻度の高い顧客を特定し、不満や不正行為の可能性を調べるなど、顧客ごとの分析が可能になります。また、顧客の種類や価値に応じてプロセスの実績を比較できるため、重要顧客へのサービスを優先しやすくなります。 重要な理由 顧客ごとの返品傾向を分析できるほか、顧客セグメントや顧客生涯価値などの属性に基づいてプロセスを分類できます。 入手先 NetSuiteのReturn Authorizationレコードのヘッダーにある「Customer」または「Entity」フィールドです。 例 CUST-001CUST-002CUST-003 | |||
返品・返金処理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| クレジットメモの作成 | クレジットメモを作成し、返品に伴う金銭処理を開始するアクティビティです。この文書には顧客への返金額が記載され、商品を受領して承認した後、返品承認から作成されます。 | ||
| 重要な理由 クレジットメモの作成は、金銭処理における重要な節目です。商品受領からクレジットメモ作成までの時間を分析すると、検品からクレジット処理までの効率が分かります。 入手先 このイベントは、CreditMemo取引が作成された日時を示します。クレジットメモの「Created From」フィールドから、元のReturnAuthorizationを確認できます。 記録 NetSuiteのCreditMemo取引レコードの作成日。 イベントタイプ explicit | |||
| 返品商品の受領 | 返品商品が倉庫または処理センターに到着したことを示すアクティビティです。NetSuiteでは、元の返品承認に紐づくItem Receipt取引を作成した記録として明示的に残ります。 | ||
| 重要な理由 顧客側の対応から社内処理へ移る重要な節目です。「返品承認」から「返品商品の受領」までの時間は顧客の返品にかかる時間を示し、このイベント以降の時間は社内処理の効率を示します。 入手先 このイベントは、ItemReceipt取引が作成された日時を示します。このレコードは、元となるReturnAuthorizationに直接紐づいています。 記録 RAに紐づくNetSuiteのItemReceipt取引レコードの作成日。 イベントタイプ explicit | |||
| 返品承認 | 従業員が顧客の返品申請を正式に承認し、プロセスを次の段階へ進めるアクティビティです。通常、返品承認レコードのステータスが「承認待ち」から「入荷待ち」などに変わったことから判定します。 | ||
| 重要な理由 この承認手順を追跡することは、初期審査段階のボトルネックを特定するうえで重要です。ここでの遅延は、顧客への連絡や返品商品の受領までの時間に直接影響します。 入手先 ReturnAuthorizationレコードのシステムノートまたはワークフロー履歴から判定します。具体的には、「Status」フィールドが承認後の状態(例:「入荷待ち」)に更新された時点を確認します。 記録 ReturnAuthorizationレコードのステータスが「承認済み」に変わったことを検出します。 イベントタイプ inferred | |||
| 返品承認のクローズ | すべての処理が完了した後、返品ケースを事務的に終了する最終アクティビティです。Return Authorizationレコードのステータスが「クローズ」に変わったことから判定します。 | ||
| 重要な理由 プロセスの明確な終了点となるこのアクティビティは、エンドツーエンドのサイクルタイムの算出や、返金処理後も長期間未完了のまま残るケースの特定に欠かせません。 入手先 ReturnAuthorizationレコードのシステムノートまたはワークフロー履歴から判定します。「Status」フィールドが「クローズ」などの最終状態に更新された時点を確認します。 記録 ReturnAuthorizationレコードのステータスが「クローズ」に変わったことを検出します。 イベントタイプ inferred | |||
| 返品承認の作成 | 顧客が商品の返品を申請した時点で、返品プロセスが始まります。このアクティビティは、NetSuiteで新しい返品承認(RA)レコードを作成した記録として明示的に取得されます。このレコードが返品ケースの主な識別子になります。 | ||
| 重要な理由 プロセスの開始点となるこのアクティビティは、返品の総サイクルタイムの測定や、一定期間に受け付けた返品申請件数の分析に欠かせません。 入手先 このイベントは、NetSuiteのReturnAuthorizationレコードが作成された日時を示します。通常、このレコードには作成者、日付、初期ステータス(例:「承認待ち」)が記録されます。 記録 NetSuiteのReturnAuthorization取引レコードの作成日。 イベントタイプ explicit | |||
| 返金処理の完了 | 顧客に資金を返す、最終的な金銭決済です。クレジットメモからCustomer Refund取引を作成した記録として明示的に取得されます。 | ||
| 重要な理由 SLAの遵守状況と顧客満足度を測るうえで、このアクティビティは重要です。「クレジットメモの承認」から「返金処理の完了」までの時間は、財務部門の処理速度を直接示します。 入手先 このイベントは、CustomerRefund取引が作成された日時を示します。この取引の「Created From」フィールドから、元のCreditMemoを確認できます。 記録 NetSuiteのCustomerRefund取引レコードの作成日。 イベントタイプ explicit | |||
| クレジットメモの承認 | クレジットメモが正式に承認されたことを示します。高額返金や財務管理の一環として承認が必要な場合があります。クレジットメモのステータス変更から判定し、適用または支払いが可能な状態になったことを確認します。 | ||
| 重要な理由 財務承認が必要な場合、この手順が大きなボトルネックになることがあります。所要時間を分析することで、顧客への返金を遅らせずに財務管理の手順を効率化できます。 入手先 CreditMemoレコードのシステムノートから判定します。具体的には、承認ステータスフィールドが「承認待ち」から「承認済み」または「オープン」に更新された時点を確認します。 記録 CreditMemo取引のステータスが「承認済み」に変わったことを検出します。 イベントタイプ inferred | |||
| クレジットメモの適用 | 現金で返金する代わりに、未決済の顧客請求書へクレジットメモを適用するアクティビティです。クレジットメモの「Applied To」リンクから判定し、クレジットが使用されたことを確認します。 | ||
| 重要な理由 現金での返金とクレジットの適用を区別することは、財務分析において重要です。この経路は、直接返金する場合とは異なる処理結果を示します。 入手先 CreditMemoのシステムノートまたは関連レコードから判定します。具体的には、顧客の残高を相殺するため、Invoice取引に紐づけられた時点を確認します。 記録 CreditMemoがInvoice取引に適用されたことを検出します。 イベントタイプ inferred | |||
| 交換注文の作成 | 返金の代わりに、交換用の新しい販売注文を顧客向けに作成するケースを示すアクティビティです。通常、元の返品承認に紐づくSales Orderの作成記録から取得します。 | ||
| 重要な理由 交換を独立した経路として追跡すると、顧客の選択傾向や、返金と比べた交換処理の効率を分析できます。よく見られる重要なバリアントです。 入手先 このイベントは、新しいSalesOrder取引が作成された日時を示します。ReturnAuthorizationとの紐づけには標準フィールドまたはカスタムフィールドが使われる場合があり、システムの分析が必要です。 記録 ReturnAuthorizationに紐づくSalesOrderの作成日。 イベントタイプ explicit | |||
| 返品商品の検品 | 返品商品の状態を確認する実物検品が完了したことを示す概念上のアクティビティです。NetSuiteには標準の「Inspection」オブジェクトがないため、通常は返品承認またはItem Receiptのカスタムフィールドやステータスの更新から判定します。 | ||
| 重要な理由 検品は大きなボトルネックになることがあります。完了までの時間を追跡することで、担当者の作業状況、判断の一貫性、後続の返金承認への影響を分析できます。 入手先 システムの分析が必要です。ReturnAuthorizationレコードのカスタム「Inspection Status」フィールドの変更から判定できる場合があります。一方、記録されないオフラインの作業として行われている可能性もあります。 記録 返品承認またはItem Receiptのカスタムステータスフィールドの変更から判定します。 イベントタイプ inferred | |||
| 返品承認の却下 | ポリシー違反などを理由に、顧客の返品申請を却下する判断を示します。返品承認レコードのステータスが「却下」または「クローズ」に変わり、その後の処理がないことから判定します。 | ||
| 重要な理由 却下理由を分析すると、コンプライアンスに適合しない返品申請の傾向を把握でき、顧客への説明やポリシーの明確化に役立ちます。理想経路から外れる重要なケースです。 入手先 ReturnAuthorizationレコードのシステムノートまたはワークフロー履歴から判定します。「Status」フィールドが最終状態の「却下」に更新された時点を確認します。 記録 ReturnAuthorizationレコードのステータスが「却下」に変わったことを検出します。 イベントタイプ inferred | |||
| 顧客への通知 | 承認、商品の受領、返金処理の完了など、重要なステータス更新を顧客に知らせる通知を送信したことを示します。通常、レコードのコミュニケーションタブに記録されたシステム生成メールの送信日時から判定します。 | ||
| 重要な理由 顧客満足度を高めるには、適切なタイミングで連絡することが大切です。節目から顧客への通知までの時間を測ることで、顧客体験における課題を特定できます。 入手先 システムの分析が必要です。ReturnAuthorizationまたはCreditMemoのCommunicationサブタブにある送信メールの日時、またはユーザーノートから取得します。 記録 ケースに紐づくメールまたはコミュニケーションログの記録日時。 イベントタイプ inferred | |||
データ抽出ガイド
ステップ
- 保存検索の作成画面を開く:NetSuiteにログインし、「Reports」>「New Search」の順に移動します。「New Saved Search」ページで「取引」をクリックします。
- 主な検索条件を設定する:「Saved Search」の設定ページで、「Criteria」タブの「Standard」サブタブを開き、返品承認レコードを抽出するため、次のフィルターを設定します。
TypeがReturn AuthorizationMain LineがYesDate Createdフィルターを追加し、必要な期間(例:「過去3か月以内」)を指定します。データ量を管理するうえで重要です。
- 属性用の結果列を設定する:「Results」タブを開きます。イベントログの属性となる次のフィールドを追加します。必要に応じて「Custom Label」で分かりやすい名前を設定します。
- ケースID:
Document NumberまたはTranID(Custom Label:ReturnCaseId) - 返品ステータス:
Status(Custom Label:ReturnAuthorizationStatus) - 処理担当者:
Created Byまたは該当するカスタムフィールド(Custom Label:ProcessingAgent) - 部門:
Department(Custom Label:Department) - 返品の種類:
[Your Return Reason Field]などのカスタムフィールド(Custom Label:ReturnType) - 返金額:
Amount(Custom Label:ActualRefundAmount)
- ケースID:
- イベント日時用の数式列を追加する:ここが最も重要な手順です。12個のアクティビティそれぞれに「Formula (Date/Time)」列を追加します。各数式ではCASE文を使い、該当するイベントが発生した場合にのみ日時を返します。各アクティビティに使う数式は「query」セクションを参照してください。
- 固定値の列を追加する:結果に「Formula (Text)」列を2つ追加します。
SourceSystemには、数式'NetSuite'を設定します。LastDataUpdateには、実行日を表す{today}などの数式を設定します。正確なタイムスタンプが必要な場合は、エクスポート時刻を使います。
- 検索を保存してエクスポートする:検索に「ProcessMind Returns Extraction」などの分かりやすい名前を付け、「Save & Run」をクリックします。結果が表示されたら、エクスポートアイコンをクリックして「CSV」を選択します。
- データをイベントログに変換する:エクスポートしたCSVは、返品ケースごとに1行、イベント日時ごとに複数の列がある「横持ち」形式です。これを「縦持ち」のイベントログに変換する必要があります。Microsoft ExcelのPower Query(列のピボット解除)、Python、その他のスクリプトツールを使って変換できます。
- CSVの各行について、日時が空でないイベント列ごとに新しい行を作成します。
- 変換後のテーブルには、
ReturnCaseId、ActivityName、EventTimestampなどの列を含めます。ActivityNameには元の日時列の見出し(例:「Return Authorization Created」)を、EventTimestampにはその列の値を設定します。
- アップロード用に仕上げる:最終的なCSVファイルに、必須のヘッダー
ReturnCaseId、ActivityName、EventTimestamp、SourceSystem、LastDataUpdateと、推奨属性が含まれていることを確認します。これでProcessMindにアップロードできます。
設定
- 検索の種類:保存検索は
取引検索にする必要があります。 - 日付範囲:返品承認の
Date Createdフィールドに日付範囲フィルターを設定してください。データの網羅性と処理速度のバランスを取るため、3~6か月の範囲を推奨します。 - 主なフィルター:返品ケースごとに最初のレコードを1件取得するため、検索条件を
種類がReturn Authorization、Main Lineがはいとなるように設定します。 - カスタムフィールド:この抽出の正確性は、特に「商品検査」などの概念上のイベントや「返品の種類」などの属性について、取引レコードでカスタムフィールドをどのように設定しているかに大きく左右されます。提示されている数式には
{custbody_...}などのプレースホルダーが含まれているため、NetSuiteの設定に合わせて変更してください。 - ユーザー権限:検索を実行するユーザーには、返品承認、商品受領、Credit Memo、顧客返金、受注など、対象となるすべての取引種類の表示権限が必要です。
- 処理速度:返品件数が非常に多いアカウントでは、この詳細な検索の実行に時間がかかる場合があります。システムの利用が少ない時間帯に実行するか、ファイルキャビネットへの自動エクスポートをスケジュールしてください。
クエリの例 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のライセンスがあることを確認します。管理者が「Setup」>「Company」>「Enable Features」>「Analytics」で機能を有効にする必要があります。
- ユーザー権限を設定する:接続に使うユーザーロールに「SuiteAnalytics Connect」権限を付与します。このユーザーには、Transactions、Employees、Customersなど、クエリ対象のすべてのレコードを表示する権限も必要です。
- ODBCドライバーをインストールする:NetSuiteのSuiteAnalytics Connectダウンロードページから、使用するOSに対応したODBCドライバーをダウンロードしてインストールします。
- DSNを設定する:クエリを実行するマシンでデータソース名(DSN)を設定します。Service Data Source、Server Hostname、Port、Role ID、Account ID、認証情報を入力します。
- SQLクライアントを接続する:DBeaverやMicrosoft SQL Server Management StudioなどのSQLクライアントから、設定したDSNを使ってNetSuiteに接続します。
- SQLクエリを準備する:提示されたSQLクエリをクライアントにコピーします。このクエリは、返品・返金プロセスの主なイベントをすべて抽出するように設計されています。
- クエリを調整する:クエリ内のプレースホルダーを変更します。最低限、Common Table Expression(CTE)
ReturnAuthorizationsの日付範囲を更新し、必要な期間を指定してください。NetSuiteの設定に合わせて、CUSTBODY_RETURN_TYPEなどのカスタムフィールド名や特定のステータス値も調整が必要な場合があります。 - クエリを実行する:調整したSQLクエリをNetSuiteのデータベースレプリカに対して実行します。実行時間は日付範囲とデータ量によって異なります。
- データを確認してエクスポートする:クエリの完了後、結果に誤りがないか確認します。結果全体をCSVファイルにエクスポートします。
- アップロード用に仕上げる:CSVファイルのヘッダーが必須属性
ReturnCaseId、ActivityName、EventTimestamp、SourceSystem、LastDataUpdateなどと一致していることを確認します。EventTimestamp列の日付と時刻の形式が統一されていることも確認してください。これでProcessMindにアップロードできます。
設定
- 前提条件:SuiteAnalytics Connectアドオンモジュールを含むNetSuiteライセンスが必要です。接続を実行するユーザーには、「SuiteAnalytics Connect」権限と、取引、エンティティ、従業員レコードへの読み取りアクセス権を持つロールが必要です。
- データソースの設定:NetSuite ODBCドライバーを使ってDSN(データソース名)を設定します。Account ID、Role ID、認証情報が必要です。本番環境のサービスホストは通常
odbcserver.netsuite.comです。 - 日付範囲の指定:Return Authorizationを選択する最初のCTEに、日付範囲フィルターを必ず設定してください。フィルターがないと、すべての返品データを取得しようとして、処理に非常に時間がかかったり、タイムアウトしたりする可能性があります。初回の分析では、3~6か月の範囲を推奨します。
- 主な取引タイプ:このクエリでは、ReturnAuthorization、ItemReceipt、CreditMemo、CustomerRefund、SalesOrd(交換用)の各取引タイプを対象とします。プロセスでこれらの標準オブジェクトを使用していることを確認してください。
- カスタムフィールドへの依存:「Item Inspected」などのアクティビティや「Return Type」などの属性は、カスタムフィールドに記録されていることがよくあります。提示したクエリには
CUSTBODY_INSPECTION_STATUSやCUSTBODY_RETURN_TYPEなどのプレースホルダーがあります。システム内の正しいカスタムフィールドIDを特定し、クエリを修正してください。 - 処理性能に関する注意:この複雑なクエリでは、複数の結合と大規模な
UNION ALL構造を使用します。システムへの影響を抑えるため、業務時間外に実行してください。データ量が非常に多い場合は、短い期間ごとにクエリを実行し、結果を追加していく方法を検討してください。
クエリの例 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%'; 準備はできましたか?
このデータテンプレートを使って、返品・返金処理の改善に取り組みましょう。NetSuiteのワークフローを見直し、業務効率と顧客満足度の向上を始めてください。
返品・返金を見直し、NetSuiteの業務効率を向上
NetSuiteの返品処理サイクルタイムを30%短縮。今日から業務改善を始めましょう。
クレジットカード不要・数分で設定完了