返品・返金処理用データテンプレート
返品・返金処理用データテンプレート
- 収集を推奨する属性
- 追跡すべき主要なアクティビティ
- NetSuiteからの抽出ガイド
返品・返金処理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 返品プロセス内で発生した特定の業務イベントまたは手順の名称です。例:「Item Inspected」や「Refund Processed」などです。 | ||
| 説明 アクティビティ名は、返品・返金のライフサイクルにおける個別の手順または節目を表します。これらのイベントをタイムスタンプ順に並べてプロセスフローを構築します。アクティビティの順序と頻度を分析すると、最も一般的なプロセス経路、手順間のボトルネック、やり直しや繰り返しのアクティビティを特定できます。例として、「Return Authorization Created」、「Item Received」、「Credit Memo Approved」などがあります。 重要な理由 この属性がプロセスの手順を定義します。プロセスマップの可視化、フローの違いの分析、ボトルネックややり直しループの特定に欠かせません。 入手先 通常、Return AuthorizationやCredit Memoなどの取引レコードのステータス変更、またはシステムノートやカスタムイベントログに記録された特定のユーザー操作から取得します。 例 返品承認が作成されました商品を受領しました商品の検査が完了しました返金が処理されました返品承認がクローズされました | |||
| イベントタイムスタンプ 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サブリストのユーザーフィールドから取得できます。 例 Alice JohnsonBob WilliamsCharlie Brown | |||
| 実際の返金額 ActualRefundAmount | 顧客へ実際に返金された最終的な金額です。 | ||
| 説明 Credit Memoまたは返金取引に記録された、顧客へ付与または返金された実際の金額を示します。再入庫手数料、送料、破損品への一部返金などの調整により、依頼額と異なる場合があります。「返金額差異率」KPIの算出や財務報告に欠かせない属性です。 重要な理由 返品がもたらす実際の財務的影響を示します。財務照合や返金の正確性分析に欠かせません。 入手先 Return Authorizationから生成されたCredit Memo取引の「Total」フィールドから取得します。 例 99.99140.000.00 | |||
| 返品ステータス ReturnAuthorizationStatus | 返品承認の現在のステータスです。例:「Pending Approval」、「Approved」、「Closed」などです。 | ||
| 説明 この属性は、返品ケースのライフサイクルにおける現在の状態を示します。返品の進捗を把握し、ケースを分類するための基本情報です。たとえば、「Pending Receipt」ステータスに費やした時間を分析すると配送の遅延を把握でき、「Pending Approval」が長い場合は社内のボトルネックが疑われます。また、「Closed」や「Rejected」など、返品の最終結果を判断するためにも使われます。 重要な理由 各返品がプロセスのどの段階にあるかを把握できます。ケースの分布、ステータスごとの滞留時間、プロセスの結果を分析できます。 入手先 NetSuiteのReturn Authorizationレコードにある「Status」または同等のフィールドに対応します。 例 承認待ち受領待ち承認済み却下クローズ | |||
| 返品種別 ReturnType | 顧客が申告した理由に基づく返品の分類です。 | ||
| 説明 返品種別は、「Defective Item」、「Wrong Size」、「Changed Mind」、「Not as Described」など、返品の根本的な理由に基づいて返品を分類します。この分類は根本原因分析に欠かせません。返品種別ごとにプロセス指標を分析すると、製品品質の問題、商品説明の不正確さ、出荷処理の誤りを特定できます。「返品パフォーマンス:種別・チャネル別」ダッシュボードの主要な属性です。 重要な理由 返品の根本原因を特定し、製品、マーケティング上の商品説明、出荷処理を対象とした改善につなげられます。返品件数の削減にも役立ちます。 入手先 通常、Return Authorizationフォームで返品理由を記録するカスタムフィールド、または標準のリスト/レコードフィールドです。 例 製品不良誤った商品を発送顧客の不満サイズまたは色が違う | |||
| 部門 Department | 特定の段階で返品ケースの処理を担当する業務部門またはチームです。 | ||
| 説明 この属性は、アクティビティを「Customer Service」、「Warehouse」、「Finance」などの特定部門に割り当てます。チーム間の引き継ぎを把握し、部門ごとのボトルネックを特定するうえで欠かせません。ケースが特定部門内で処理される時間や、その部門を待つ時間を分析することで、遅延の原因を特定し、リソース配分を最適化できます。「部門別返品プロセスパフォーマンス」ダッシュボードの主要な分析軸です。 重要な理由 機能領域別にプロセスパフォーマンスを分析し、部門間の引き継ぎ遅延や部門ごとのボトルネックを明らかにできます。 入手先 アクティビティに関連付けられたユーザーまたは従業員レコード、あるいは取引自体の「Department」フィールドから取得できます。NetSuiteの従業員レコードで設定されていることが多い項目です。 例 倉庫カスタマーサポート財務品質保証 | |||
| SLA準拠 IsSlaCompliant | 返金が定義されたSLA目標時間内に処理されたかどうかを示す、計算されたフラグです。 | ||
| 説明 このブール属性は、「返金処理済み」タイムスタンプと「返金SLA目標日」を比較して算出します。返金が目標日以前に処理されていればtrue、それ以外はfalseです。このフラグにより、「返金SLAコンプライアンス監視」ダッシュボードなどのコンプライアンスレポートやダッシュボードを簡単に作成でき、「返金SLA達成率」KPIの計算にも使用できます。 重要な理由 ケースごとのSLA実績を明確な二値で示すため、コンプライアンス率を継続的に追跡、報告、分析しやすくなります。 入手先 この属性は、データ変換時またはプロセスマイニングツール内で計算します。ロジックは次のとおりです: 例 truefalse | |||
| ポリシー遵守状況 ReturnPolicyAdherence | 返品が定められた社内返品ポリシーに適合しているかどうかを示します。 | ||
| 説明 返品期間、商品の状態、購入証明など、あらかじめ定めた基準をすべて満たしているかを示す真偽値またはカテゴリ属性です。コンプライアンスの監視や例外管理に使います。「返品ポリシー遵守の例外」ダッシュボードは、この属性を使って特別な対応や確認が必要なケースを明らかにします。リスクを抑え、ルールを一貫して適用するうえで役立ちます。 重要な理由 返品ポリシーの監視と徹底に役立ち、ポリシーに適合しない返品による財務リスクを抑え、公平性と一貫性を確保します。 入手先 ほぼ確実にカスタムフィールドです。Return Authorizationレコード上のチェックボックスまたはリストとして、ワークフローで管理されている可能性があります。 例 適合不適合・期間外例外承認済み | |||
| 商品識別子 ProductIdentifier | 返品される商品の一意の識別子です。SKUやItem Numberなどがあります。 | ||
| 説明 この属性は、返品対象となった具体的な商品を識別します。商品単位で返品を分析することは、返品率の高い商品を特定するうえで重要です。品質不良、商品説明の不足、その他の問題が示唆される場合があります。このデータを使って商品のパフォーマンスを詳しく分析し、商品開発、調達、マーケティングに関する意思決定に役立てられます。 重要な理由 返品プロセスのデータを特定の商品に紐づけ、商品に関する問題の根本原因分析を可能にします。全体の返品率の低減にも役立ちます。 入手先 Return Authorizationレコードの「Items」サブリストにあります。「Item」フィールドに対応します。 例 SKU-TEE-BL-LPROD-00543ITEM-987123 | |||
| 自動処理 IsAutomated | アクティビティがシステムによって自動的に実行されたかどうかを示すブール値のフラグです。 | ||
| 説明 この属性は、アクティビティがユーザーによって実行されたのか、自動システム、スクリプト、ワークフローによって実行されたのかを示します。たとえば、最初の「返品承認作成」イベントは顧客ポータル経由で自動実行され、「商品検査」は手動アクティビティとして処理される場合があります。自動化の状況を追跡すると、手動ステップを自動化できる箇所を見つけ、既存の自動化による効率向上を測定できます。 重要な理由 手動タスクと自動タスクを区別できます。自動化の候補を見つけ、デジタルトランスフォーメーションの取り組みの効果を測定するうえで役立ちます。 入手先 イベントに関連付けられたユーザーから推定できます。NetSuiteで生成されたイベントには、特定のシステムユーザーまたはスクリプトIDが関連付けられていることがよくあります。 例 truefalse | |||
| 返品チャネル ReturnChannel | 元の購入または返品依頼が行われたチャネルです。 | ||
| 説明 返品チャネルは、返品の発生元を示します。例として「Online」、「In-Store」、「Marketplace」などがあります。チャネルごとに返品プロセス、コスト、顧客の期待が異なる場合があります。チャネル別にパフォーマンスを分析すると、各プロセスを最適化し、リソースを適切に配分し、チャネル固有の問題を把握できます。「返品パフォーマンス:種別・チャネル別」ダッシュボードの主要な属性です。 重要な理由 異なる業務チャネル間でパフォーマンスを比較し、返品の開始方法や処理方法に固有の非効率な点や優れた方法を明らかにできます。 入手先 多くの場合、返品に関連付けられた元のSales Orderレコードから取得します。「Channel」または「Location」フィールドに保存されている可能性があります。 例 ウェブストア小売店舗Amazonマーケットプレイス電話注文 | |||
| 返品商品の状態 ReturnCondition | 検査時点で評価した返品商品の状態です。「New」、「Damaged」、「Used」などがあります。 | ||
| 説明 この属性は、返品商品の実物検査の結果を記録します。状態によって、全額返金、商品の再入庫、廃棄などの後続処理が決まります。この評価の一貫性と処理時間を分析するのが「返品状態評価の品質」ダッシュボードの目的です。財務照合と在庫管理にも欠かせません。 重要な理由 返品の財務的な結果と、その後の在庫処理に直接影響します。評価にばらつきがあると、財務上の損失やプロセスのやり直しにつながる可能性があります。 入手先 通常、Item ReceiptレコードまたはReturn Authorizationレコードのカスタムフィールドです。検査時に倉庫担当者が入力します。 例 再販売可能箱内で破損使用済み・良好な状態部品不足 | |||
| 返金SLA目標日 RefundSlaTargetDate | サービスレベル合意に基づき、返金処理を完了する予定の目標日です。 | ||
| 説明 返金SLA目標日は、返金処理に関する顧客への約束を表す、計算されたタイムスタンプです。通常は、「商品受領」や「返金承認」などの主要なイベントに、5営業日などのあらかじめ定めた期間を加算して算出します。この属性は、「返金SLAコンプライアンス監視」ダッシュボードと「返金SLA達成率」KPIに欠かせません。これにより、約束どおりに処理できているかを測定できます。 重要な理由 顧客への約束に対する実績を定量的に測定できます。顧客満足度と信頼を維持するうえで重要です。 入手先 通常の標準項目ではありません。「商品受領日」などの主要なタイムスタンプに、5日間などのあらかじめ定めたSLA期間を加算して算出する必要があります。 例 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は、返品取引を特定の顧客に紐づけます。返品頻度の高い顧客を特定するなど、顧客中心の分析が可能になります。これは、不満や不正行為の兆候を把握する際にも役立ちます。また、顧客の種別や価値に基づいてプロセスパフォーマンスを分類し、重要顧客へのサービスを優先できます。 重要な理由 顧客単位で返品行動を分析し、顧客セグメントや顧客生涯価値などの属性に基づいてプロセスを分類できます。 入手先 NetSuiteのReturn Authorizationレコードのヘッダーにある「Customer」または「Entity」フィールドです。 例 CUST-001CUST-002CUST-003 | |||
返品・返金処理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| クレジットメモが作成されました | クレジットメモを作成し、返品に関する財務処理を開始したことを示すアクティビティです。この書類には顧客へ返金する金額が記載され、商品を受領して承認した後、Return Authorizationから作成されます。 | ||
| 重要な理由 クレジットメモの作成は、財務処理における重要な節目です。商品の受領からクレジットメモ作成までの時間から、検査からクレジット処理までの効率を把握できます。 入手先 このイベントは、CreditMemo取引が作成された日時です。クレジットメモの「Created From」フィールドからReturnAuthorizationへ遡れます。 取得 NetSuiteのCreditMemo取引の作成日 イベントタイプ explicit | |||
| 商品を受領しました | 倉庫または処理センターで返品商品を実際に受け取ったことを示すアクティビティです。NetSuiteでは、元の返品承認に紐づくItem Receipt取引を作成することで明示的に記録されます。 | ||
| 重要な理由 これは、顧客側の対応から社内処理へ移行する重要な節目です。「Return Approved」から「Item Received」までの時間は顧客の返品速度を示し、このイベント以降の時間は社内の処理効率を示します。 入手先 このイベントは、ItemReceipt取引が作成された日時です。このレコードは、元のReturnAuthorizationに直接紐づきます。 取得 RAに紐づくNetSuiteのItemReceipt取引の作成日 イベントタイプ explicit | |||
| 返品承認がクローズされました | すべての処理が完了した後、返品ケースを管理上クローズする最終アクティビティです。Return Authorizationレコードの最終ステータスが「Closed」に変更されたことから推定します。 | ||
| 重要な理由 プロセスの明確な終点となるこのアクティビティは、エンドツーエンドの処理時間を算出し、返金処理後も長期間オープンのまま残っているケースを特定するうえで欠かせません。 入手先 ReturnAuthorizationレコードのシステムノートまたはワークフロー履歴から推定します。「Status」フィールドが「Closed」などの最終状態に更新された時点です。 取得 ReturnAuthorizationレコードのステータスが「Closed」に変更されたことを検出 イベントタイプ inferred | |||
| 返品承認が作成されました | 顧客が商品の返品を依頼した時点で、返品プロセスの開始を示すアクティビティです。NetSuiteでは、新しい返品承認(RA)レコードの作成によって明示的に記録されます。このレコードが返品の主なケース識別子になります。 | ||
| 重要な理由 プロセスの開始点となるこのアクティビティは、返品サイクル全体の処理時間を測定し、時間の経過に伴う返品依頼数を分析するうえで欠かせません。 入手先 このイベントは、NetSuiteでReturnAuthorizationレコードが作成された日時です。通常、このレコードにはユーザー、日付、初期ステータス(例:「Pending Approval」)が記録されます。 取得 NetSuiteのReturnAuthorization取引レコードの作成日 イベントタイプ explicit | |||
| 返品承認が承認されました | 従業員が顧客の返品依頼を正式に承認し、プロセスを次の段階へ進められる状態になったことを示すアクティビティです。通常、Return Authorizationレコードのステータスが「Pending Approval」から「Pending Receipt」などに変わったことから推定します。 | ||
| 重要な理由 この承認手順を追跡することは、初期確認段階のボトルネックを特定するうえで重要です。ここでの遅延は、顧客への連絡や返品商品の受け取りにかかる時間へ直接影響します。 入手先 ReturnAuthorizationレコードのシステムノートまたはワークフロー履歴から推定します。具体的には、「Status」フィールドが承認済みの状態(例:「Pending Receipt」)に更新された時点です。 取得 ReturnAuthorizationレコードのステータスが「Approved」に変更されたことを検出 イベントタイプ inferred | |||
| 返金が処理されました | 顧客へ資金を返還する最終的な財務決済です。Credit Memoから生成されるCustomer Refund取引の作成によって明示的に記録されます。 | ||
| 重要な理由 このアクティビティは、SLA遵守状況と顧客満足度を測定するうえで重要です。「Credit Memo Approved」から「Refund Processed」までの時間は、財務部門や資金管理部門の処理速度を直接示します。 入手先 このイベントは、CustomerRefund取引が作成された日時です。この取引の「Created From」フィールドからCreditMemoへ遡れます。 取得 NetSuiteのCustomerRefund取引の作成日 イベントタイプ explicit | |||
| クレジットメモが承認されました | クレジットメモを正式に承認したことを示します。高額な返金や財務統制の一環として必要になることがあります。Credit Memoレコードのステータス変更から推定し、適用または支払いが可能な状態になったことを示します。 | ||
| 重要な理由 財務承認が必要な場合、この手順が大きなボトルネックになる可能性があります。所要時間を分析することで、顧客への返金を遅らせずに財務統制を効率化できます。 入手先 CreditMemoレコードのシステムノートから推定します。具体的には、承認ステータスフィールドが「Pending Approval」から「Approved」または「Open」に更新された時点です。 取得 CreditMemo取引のステータスが「Approved」に変更されたことを検出 イベントタイプ inferred | |||
| クレジットメモが適用されました | 現金で返金する代わりに、クレジットメモを未決済の顧客請求書へ適用する処理を示すアクティビティです。Credit Memoの「Applied To」リンクから推定し、クレジットが使用されたことを示します。 | ||
| 重要な理由 現金による返金とクレジットの適用を区別することは、財務分析において重要です。この経路は、直接返金とは異なるプロセスの完了方法を示します。 入手先 CreditMemoのシステムノートまたは関連レコードから推定します。具体的には、顧客残高を相殺するためにInvoice取引へ紐づけられた時点です。 取得 CreditMemoがInvoice取引に適用されたことを検出 イベントタイプ inferred | |||
| 交換注文が作成されました | 返金の代わりに顧客向けの新しい販売注文を作成する交換処理を示すアクティビティです。通常、元の返品承認に紐づくSales Orderの作成によって記録されます。 | ||
| 重要な理由 交換を別の経路として追跡すると、顧客の選好や、返金処理と比較した交換処理の効率を分析できます。一般的で重要な分岐です。 入手先 このイベントは、新しいSalesOrder取引が作成された日時です。ReturnAuthorizationとのリンクは標準フィールドまたはカスタムフィールドに設定されている可能性があるため、システム分析が必要です。 取得 ReturnAuthorizationに紐づくSalesOrderの作成日 イベントタイプ explicit | |||
| 商品の検査が完了しました | 返品商品の状態を確認する実物検査が完了したことを示す概念上のアクティビティです。NetSuiteには標準の「Inspection」オブジェクトがないため、通常はReturn AuthorizationまたはItem Receiptのカスタムフィールドやステータス更新から推定します。 | ||
| 重要な理由 検査は大きなボトルネックになることが少なくありません。完了時間を追跡することは、担当者のパフォーマンス、判断の一貫性、後続の返金承認への影響を分析するうえで重要です。 入手先 システム分析が必要です。ReturnAuthorizationレコードのカスタム「Inspection Status」フィールドの変更から推定できる場合があります。また、記録されないオフラインのプロセスである可能性もあります。 取得 Return AuthorizationまたはItem Receiptのカスタムステータスフィールドの変更から推定 イベントタイプ inferred | |||
| 返品承認が却下されました | 顧客の返品依頼を認めない判断を示します。多くの場合、ポリシー違反が理由です。このイベントは、追加処理を伴わずにReturn Authorizationレコードのステータスが「Rejected」または「Closed」に変更されたことから推定します。 | ||
| 重要な理由 却下理由を分析すると、返品ポリシーに適合しない依頼の共通要因を特定できます。その結果を顧客とのコミュニケーションやポリシーの明確化に役立てられます。これは通常のプロセスからの重要な逸脱です。 入手先 ReturnAuthorizationレコードのシステムノートまたはワークフロー履歴から推定します。「Status」フィールドが最終状態である「Rejected」に更新された時点です。 取得 ReturnAuthorizationレコードのステータスが「Rejected」に変更されたことを検出 イベントタイプ inferred | |||
| 顧客に通知しました | 承認、商品の受領、返金処理完了など、重要なステータス更新を顧客へ通知したことを示します。通常、レコードのコミュニケーションタブに記録されたシステム生成メールのタイムスタンプから推定します。 | ||
| 重要な理由 適時のコミュニケーションは、顧客満足度を左右します。節目から顧客への通知までの遅れを測定すると、顧客体験における不足を特定できます。 入手先 システム分析が必要です。ReturnAuthorizationまたはCreditMemoのCommunicationサブタブにある送信メールまたはユーザーノートのタイムスタンプから取得します。 取得 ケースに紐づくメールまたはコミュニケーションログのエントリのタイムスタンプ イベントタイプ inferred | |||
抽出ガイド
ステップ
- 保存検索の作成画面を開く:NetSuiteにログインし、「レポート」>「新規検索」に移動します。「新規保存検索」ページで「トランザクション」をクリックします。
- 基本条件を設定する:「保存検索の設定」ページの「条件」タブにある「標準」サブタブで、返品承認レコードだけを抽出するため、次のフィルターを設定します:
TypeはReturn AuthorizationMain LineはYesDate Createdフィルターを追加し、「過去3か月以内」など、希望する期間を設定します。データ量を管理するうえで重要です。
- 属性用の結果列を設定する:「結果」タブに移動し、イベントログの属性となる次のフィールドを追加します。必要に応じて「カスタムラベル」で分かりやすい名前に変更してください。
- ケースID:
Document NumberまたはTranID(カスタムラベル:ReturnCaseId) - 返品ステータス:
Status(カスタムラベル:ReturnAuthorizationStatus) - 処理担当者:
Created Byまたは該当するカスタムフィールド(カスタムラベル:ProcessingAgent) - 部門:
Department(カスタムラベル:Department) - 返品タイプ:
[Your Return Reason Field]などのカスタムフィールド(カスタムラベル:ReturnType) - 返金額:
Amount(カスタムラベル:ActualRefundAmount)
- ケースID:
- イベントタイムスタンプ用の計算列を追加する:最も重要なステップです。12個のアクティビティごとに、「計算式(日付/時刻)」列を追加します。各計算式ではCASE文を使い、該当するイベントが発生した場合にのみタイムスタンプを返します。各アクティビティで使用する正確な計算式は「query」セクションを参照してください。
- 固定列を追加する:結果に「計算式(テキスト)」列を2つ追加します:
SourceSystemには、'NetSuite'という計算式を使用します。LastDataUpdateには、{today}のように実行日を表す計算式を使用します。正確なタイムスタンプが必要な場合は、エクスポート時刻になります。
- 検索を保存してエクスポートする:検索に「ProcessMind Returns Extraction」などの分かりやすい名前を付け、「保存して実行」をクリックします。結果が表示されたら、エクスポートアイコンをクリックして「CSV」を選択します。
- データをイベントログに変換する:エクスポートしたCSVは、返品ケースごとに1行、多数のイベントタイムスタンプ列を持つワイド形式です。Microsoft Excel Power Query(列のピボット解除)、Python、その他のスクリプトツールを使い、ロング形式のイベントログに変換してください。
- CSVの各行について、空でないイベントタイムスタンプ列ごとに新しい行を1行作成します。
- 変換後のテーブルには、
ReturnCaseId、ActivityName、EventTimestampなどの列を含めます。ActivityNameには元のタイムスタンプ列の見出し(例:「返品承認作成」)を設定し、EventTimestampにはその列の値を設定します。
- アップロード用に仕上げる:最終CSVに、
ReturnCaseId、ActivityName、EventTimestamp、SourceSystem、LastDataUpdateおよび推奨属性のヘッダーが含まれていることを確認します。これでProcessMindにアップロードできます。
設定
- 検索の種類:Saved Searchは
取引検索である必要があります。 - 日付範囲:返品承認の
Date Createdフィールドに日付範囲フィルターを適用することが重要です。データの完全性とパフォーマンスのバランスを取るため、3~6か月の範囲を推奨します。 - 主要フィルター:返品ケースごとに最初のレコードを1件だけ取得できるよう、
種類がReturn Authorization、Main Lineがはいになるよう検索を絞り込みます。 - カスタムフィールド:この抽出の正確性は、特に「商品検査済み」などの概念的なイベントや「返品の種類」などの属性について、取引レコードで組織がカスタムフィールドをどの程度使用しているかに大きく左右されます。提供されている数式には
{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クエリを準備する:「query」セクションに記載されたSQLクエリをクライアントにコピーします。このクエリは、返品・返金プロセスの主要イベントをすべて抽出するよう設計されています。
- クエリをカスタマイズする:クエリ内のプレースホルダー値を変更します。少なくとも、
ReturnAuthorizations共通テーブル式(CTE)の日付範囲を更新し、対象期間を絞り込む必要があります。CUSTBODY_RETURN_TYPEなどのカスタムフィールド名や、特定のステータス値をNetSuiteの設定に合わせて変更する場合もあります。 - クエリを実行する:NetSuiteのデータベースレプリカに対して、カスタマイズしたSQLクエリを実行します。実行時間は期間とデータ量によって異なります。
- データを確認してエクスポートする:クエリが完了したら、結果が正しいことを確認します。結果セット全体をCSVファイルにエクスポートします。
- アップロード用に仕上げる:CSVファイルのヘッダーが、
ReturnCaseId、ActivityName、EventTimestamp、SourceSystem、LastDataUpdateなどの必要な属性と一致していることを確認します。EventTimestamp列が一貫した日付/時刻形式になっていることも確認してください。これでProcessMindにアップロードできます。
設定
- 前提条件:SuiteAnalytics Connectアドオンモジュールを含むNetSuiteライセンスが必要です。接続を実行するユーザーには、「SuiteAnalytics Connect」権限と、トランザクション、エンティティ、従業員レコードへの読み取りアクセス権を持つロールが必要です。
- データソース設定:NetSuite ODBCドライバーを使ってDSN(データソース名)を設定する必要があります。Account ID、Role 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%'; 準備はできましたか?
このデータテンプレートを使って、返品・返金処理を改善しましょう。NetSuiteのワークフローを今すぐ最適化し、業務効率と顧客満足度を高めてください。
返品・返金を今すぐ改善し、NetSuiteの効率を高める
NetSuiteの返品サイクルタイムを30%短縮。今すぐ業務改善を始めてください。
クレジットカード不要・数分でセットアップ