返品・返金処理用データテンプレート
返品・返金処理用データテンプレート
- 収集を推奨するデータ項目
- 追跡すべき主要なプロセス手順
- データ抽出ガイド
返品・返金処理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| イベント時刻 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」などのテーブルにおけるステータス変更、または特定のイベントログを、利用しやすい名称にマッピングして生成できます。 例 返品注文を作成商品を受領処分コードを適用クレジットノートを転記 | |||
| 処分コード DispositionCode | 商品の検査結果と、次に実行するアクションを示すコードです。 | ||
| 説明 処分コードは、返品商品の品質検査中に割り当てられます。次のプロセスステップを決定し、「クレジット」、「交換」、「廃棄」、「顧客へ返送」などを指定します。 この属性は、返品プロセスにおける重要な判断ポイントです。処分コード別に分析することで、返品の結果を把握し、商品の廃棄による財務的影響を追跡するとともに、交換と返金など、異なる解決経路の効率を評価できます。 重要な理由 このコードによって、検査後に返品ケースが進む経路が決まるため、プロセスバリアントとその業務上の結果を分析するうえで重要です。 入手先 品質管理モジュールの主要フィールドです。品質注文または検査注文の処理に関連付けられます。 例 CRDTREPL-DSCRAPRTV | |||
| 商品ID ProductId | 返品対象商品の一意の識別子です。 | ||
| 説明 商品IDは、多くの場合、在庫保管単位(SKU)であり、顧客が返品する特定の商品を識別します。返品注文の各明細行には、商品IDが関連付けられます。 商品別に返品を分析することは、返品率の高い商品を特定するうえで欠かせません。これは、品質管理上の問題、商品説明の不正確さ、製造上の欠陥を示している可能性があります。この分析により、商品に関する調査と改善の優先順位を決められます。 重要な理由 商品単位で返品を分析し、品質問題や返品件数の多い商品を特定できます。 入手先 返品注文の「SalesLine」テーブルにある「ItemId」フィールドに対応します。 例 SKU-A-123SKU-B-456SKU-C-789 | |||
| 担当ユーザー ResponsibleUser | 特定のアクティビティを実行した、またはその責任を担うユーザーや従業員です。 | ||
| 説明 この属性は、プロセスステップの実行を担当した個人を識別します。商品を受領した倉庫作業員、品質検査担当者、クレジットノートを転記した経理担当者などが該当します。 ユーザー別にプロセスを分析すると、業務量の分布を把握し、優れた成果を上げている担当者を特定するとともに、トレーニングの必要性を見つけられます。特定の個人やチームが処理したケースの調査や、職務分掌の適切な運用確認にも利用できます。 重要な理由 業務量の分布、個人またはチームごとのパフォーマンスを分析し、トレーニングやリソース配分の機会を特定できます。 入手先 「SalesTable.createdBy」などの取引レコードの「created by」または「modified by」フィールド、あるいは仕訳テーブルに関連付けられたユーザーIDに格納されています。 例 Alice.WBob.JChris.P | |||
| 返品チャネル ReturnChannel | 顧客が返品を開始した方法またはチャネルです。 | ||
| 説明 顧客が返品プロセスを開始する際に使ったチャネルを示します。たとえば、「オンラインポータル」、「店舗」、「カスタマーサービスへの電話」、「メール」などです。 返品チャネル別にプロセスを分析すると、各チャネルのパフォーマンスと効率を評価できます。チャネル間でサイクルタイム、コスト、顧客満足度を比較し、優れた取り組みや投資・改善が必要な領域を特定できます。これは「返品チャネル利用パフォーマンス」ダッシュボードの基盤となります。 重要な理由 返品チャネル間のパフォーマンスを比較し、効率と費用対効果の高いチャネルを最適化できます。 入手先 返品注文ヘッダー(「SalesTable」)に保存されるか、注文を作成したユーザーから導出される場合があります。カスタムロジックまたは専用フィールドが必要になることがあります。 例 ウェブポータル店舗内キオスクカスタマーサポート | |||
| 返品理由コード ReturnReasonCode | 顧客が商品を返品する理由として申告した内容です。 | ||
| 説明 返品理由コードは、顧客が申告した返品理由を記録します。「商品不良」、「サイズ違い」、「説明と異なる」、「不要になった」などが該当します。通常は、返品開始時に収集されます。 返品理由の分析は、根本原因分析に欠かせません。商品の品質問題、商品説明の不備、物流上のミスを特定できます。このデータから得られる知見を、商品設計、マーケティング、サプライチェーン業務の改善に役立てることで、将来の返品を減らせます。 重要な理由 返品が発生する理由を把握し、返品率の低減と顧客満足度の向上につながる根本原因分析を可能にします。 入手先 通常は返品注文の明細行レベルに保存されます。「SalesLine」テーブルで返品注文の理由コードフィールドを確認してください。 例 DEFECTWRONG_ITEMNO_LONGER_WANTEDDAMAGED_IN_TRANSIT | |||
| SLAステータス SlaStatus | ケースがSLAの目標期間内に解決されたかを示します。 | ||
| 説明 SLA遵守状況を「期限内」または「遅延」などの簡潔なステータスで示す、計算された属性です。通常は、最終アクティビティ(例:「返品注文をクローズ済み」)のタイムスタンプと「RefundSlaTargetDate」を比較して判定します。 この属性により、「返金解決SLAパフォーマンス」などのダッシュボードで、パフォーマンスを簡単にレポートできます。ユーザーが日付を比較しなくても、直接かつ分かりやすいステータスを確認できます。遅延ケースをすばやくフィルタリング・集計し、「解決SLA遵守率」を計算できます。 重要な理由 SLA遵守状況をひと目で確認できる簡潔な指標となり、遅延ケースのフィルタリングや遅延の根本原因分析を容易にします。 入手先 最終解決アクティビティのタイムスタンプと「RefundSlaTargetDate」属性を比較して計算する、導出属性です。 例 期限内遅延 | |||
| クレジットノートID CreditNoteId | 返金のために作成されたクレジットノート文書の一意の識別子です。 | ||
| 説明 返金を処理すると、クレジットノートまたはクレジットメモと呼ばれる財務文書が生成されます。この属性には、その文書の一意のIDが保存されます。 このIDにより、業務上の返品プロセスと会計システムの財務記録を直接結び付けられます。監査や財務差異の詳細調査に役立ち、返品ケースを決済に使用された特定の財務取引まで追跡できます。 重要な理由 業務上の返品プロセスを対応する財務取引に結び付けるため、監査や財務照合に欠かせません。 入手先 クレジットノート番号は通常、「CustInvoiceJour」テーブルの「InvoiceId」フィールドに記載されています。取引タイプは「Credit note」です。返品注文に関連付けることができます。 例 CN-10056CN-10057CN-10058 | |||
| ソースシステム SourceSystem | イベントデータを抽出した情報システムです。 | ||
| 説明 データの発生元となる情報システムを識別する属性です。この場合、主に「Microsoft Dynamics 365」となります。 大規模な組織では、1つのプロセスが複数のシステムにまたがる場合があります。各イベントのソースシステムを指定することは、データガバナンス、データ抽出時の問題のトラブルシューティング、プロセスを支える技術環境の把握に欠かせません。分析対象データの出所を確認できます。 重要な理由 データの出所に関する重要な背景情報を提供し、データガバナンス、検証、プロセスのシステム環境の把握に役立ちます。 入手先 通常は、データの抽出、変換、読み込み(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 | 特定のアクティビティが完了した時点を示すタイムスタンプです。 | ||
| 説明 終了時刻は、アクティビティの完了時刻を表します。StartTimeが開始を示すのに対し、EndTimeは終了を示すため、そのタスクの処理時間を計算できます。 この属性は、特に「商品を検査」のように所要時間を測定できるタスクの詳細なパフォーマンス分析に欠かせません。StartTimeとEndTimeを比較することで、タスクの実作業時間を正確に測定し、タスク間の待機時間と区別できます。これにより、タスク間だけでなく、個々のアクティビティ内の非効率も特定できます。 重要な理由 個々のアクティビティの実作業時間を計算し、待機時間と実際の作業時間を区別できます。 入手先 導出が必要になることが多い項目です。たとえば、アクティビティを完了させるステータス変更の「modifiedDateTime」や、後続アクティビティのStartTimeを使用できます。 例 2023-10-26T10:15:00Z2023-10-26T14:45:20Z2023-10-27T09:55:12Z | |||
| 返品タイプ ReturnType | 返金や交換など、想定される結果に基づいて返品を分類します。 | ||
| 説明 顧客が求める、または会社が提示する解決方法に基づいて返品ケースを分類する属性です。一般的なタイプには、金銭による「返金」、商品との「交換」、「修理」があります。 この分類は、異なるプロセス経路を分析する際に役立ちます。返金を行うプロセスと交換品を発送するプロセスでは、手順が大きく異なります。返品タイプ別に分けることで、各解決経路に固有のサイクルタイムやボトルネックをより正確に分析できます。 重要な理由 返金と交換ではステップやサイクルタイムが異なるため、想定される結果に基づいて分析を分けられます。 入手先 返品注文ヘッダーのカスタムフィールドであるか、処分コードや交換販売注文の作成など、後続の取引に基づいて導出される場合があります。 例 返金交換ストアクレジット | |||
| 返品注文ステータス ReturnOrderStatus | イベント発生時点における返品注文全体のステータスです。 | ||
| 説明 返品注文ヘッダーの現在のステータスを示す属性です。「オープン」、「請求済み」、「キャンセル済み」などがあります。ケースがライフサイクルのどの段階にあるかを大まかに把握できます。 アクティビティが詳細なプロセスステップを示すのに対し、全体ステータスはケースのフィルタリングやセグメント化に役立ちます。たとえば、現在の業務量を把握するために「オープン」ケースだけに絞り込んだり、最終的に「キャンセル済み」となったケースのプロセスフローを分析したりできます。 重要な理由 ケースの状態を大まかに把握できるため、ケースのフィルタリングやキャンセルなどの結果の理解に役立ちます。 入手先 「SalesTable」の「SalesStatus」または「DocumentStatus」フィールドに格納されています。 例 未処理の注文配送済み請求済みキャンセル済み | |||
| 返金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遵守率を測定する際の主要なアクティビティになることがよくあります。 入手先 返品注文の請求書仕訳を転記したタイムスタンプです。これによりクレジットノートが確定し、返品注文のステータスが「Invoiced」に変わります。 取得 返品注文の請求書仕訳を転記したイベントです。 イベントタイプ explicit | |||
| 処分コードを適用 | 検査の完了と、返品商品をどう扱うかの判断を示すアクティビティです。返品明細行に「Credit」、「Scrap」、「Replace」などの処分コードを割り当てます。 | ||
| 重要な理由 返金、交換、返品却下のいずれに進むかを決める重要な判断ポイントです。ここでの遅延は、解決までの全体時間に大きく影響する可能性があります。 入手先 返品注文の明細行にある在庫トランザクションまたは関連仕訳のDispositionCodeフィールドに値が設定された時点で記録されます。 取得 返品注文の明細行にDispositionCodeが設定された際の更新イベントです。 イベントタイプ explicit | |||
| 商品を受領 | 倉庫または指定された返品センターで返品商品を実際に受領したことを示します。返品注文に関連付けられた入荷仕訳が転記された時点で記録されます。 | ||
| 重要な理由 これは、プロセスが顧客側のアクションから社内処理へ移行する重要な節目です。検査や処分など、社内での処理時間を計測する際の起点になります。 入手先 返品注文の明細行に関連付けられたWMS仕訳または商品入荷仕訳の転記タイムスタンプです。在庫トランザクションのステータスが「Registered」または「Received」に更新されます。 取得 返品注文の明細行に関連付けられた商品入荷仕訳を転記したイベントです。 イベントタイプ explicit | |||
| 返品注文をクローズ済み | 返品注文が最終状態に達し、物理的および財務的なすべての取引が完了したことを示します。通常は、クレジットノートの転記後、または交換品の発送後に発生します。 | ||
| 重要な理由 これは、返品プロセスが正常に完了したことを示す主要な終了イベントです。作成からこの時点までの期間が、ケース全体のサイクルタイムとなります。 入手先 ReturnOrderのステータスフィールドが「請求済み」や「クローズ済み」などの終了値に変わったことから推定されます。これ以上の処理が予定されていないことを示します。 取得 SalesTable.StatusまたはSalesTable.DocumentStatusフィールドを最終状態に変更します。 イベントタイプ inferred | |||
| 返品注文を作成 | このアクティビティは返品プロセスの開始を示します。システムでReturn Material Authorization(RMA)または返品注文が作成される段階です。Dynamics 365で新しいReturnOrderレコードが作成された時点で、明示的なイベントとして記録されます。 | ||
| 重要な理由 これは返品プロセス全体の主な開始イベントです。このアクティビティから他のアクティビティまでの時間を分析することで、プロセス全体のリードタイムを把握し、初期段階のボトルネックを特定できます。 入手先 このイベントは、ReturnOrderヘッダーの作成タイムスタンプから取得します。通常、SalesTypeが「Returned Order」であるSalesTableに記録されています。 取得 SalesType = 'Returned Order'のSalesTableレコードが作成されたイベントです。 イベントタイプ explicit | |||
| クレジットノートを作成 | 「Credit」の処分コードに基づいてクレジットノートを生成し、お客様への返金を承認します。財務上の精算プロセスが正式に始まる段階です。 | ||
| 重要な理由 財務上の返金が承認されたことを示すアクティビティです。処分コードの適用からクレジットノートの作成までの時間を確認することで、返金開始における管理上の遅延を把握できます。 入手先 元の返品注文に関連付けられたマイナス値の新しいSalesTableレコードの作成、または「Create credit note」バッチジョブの実行から推定できます。 取得 クレジットノートの作成です。通常は返品注文の請求書を転記することで行われます。 イベントタイプ explicit | |||
| 交換品を発送済み | 交換品の梱包明細が転記され、顧客への発送が完了したことを示します。これにより、交換履行プロセスが完了します。 | ||
| 重要な理由 これは交換バリアントにおける重要なマイルストーンであり、顧客に対する会社の義務を果たしたことを示します。交換にかかるサイクルタイムを追跡するうえで重要です。 入手先 交換販売注文の梱包明細仕訳の転記日です。これにより、注文ステータスが「配送済み」に更新されます。 取得 交換販売注文の梱包明細を転記します。 イベントタイプ explicit | |||
| 交換注文を作成 | お客様に交換商品を送るため、新しい販売注文を作成します。処分アクションが「Replace and Credit」または「Replace and Scrap」の場合に発生します。 | ||
| 重要な理由 このアクティビティは、交換プロセスのバリアントを開始します。この経路を返金経路とは別に追跡することは、交換に伴う複雑さとコストを把握するうえで欠かせません。 入手先 交換品用の新しいSalesTableレコードを作成します。多くの場合、自動的に生成され、元の返品注文に関連付けられます。 取得 処分アクションを介して返品注文に関連付けられた新しい販売注文を作成します。 イベントタイプ explicit | |||
| 入荷仕訳を作成 | 倉庫が返品商品の到着を予定していることを示すアクティビティです。入荷仕訳を作成し、商品の実物を受け入れる準備をシステム上で整えます。 | ||
| 重要な理由 この手順により、物流上の準備と実際の入荷を区別できます。倉庫の受け入れ準備や返品入荷の計画を分析する際に役立ちます。 入手先 JournalTypeが「Arrival」であるWMSJournalTableレコードの作成です。仕訳は返品注文の明細行に関連付けられます。 取得 返品に関するWMSJournalTableレコードの作成タイムスタンプです。 イベントタイプ explicit | |||
| 品質注文を生成 | 正式な品質注文を作成し、返品商品に対して体系的な検査が必要であることを示します。返品商品に詳細なテストや品質基準に基づくチェックが必要な場合によく使われます。 | ||
| 重要な理由 正式な検査プロセスの開始を示すアクティビティです。この時点からの時間を追跡することで、品質保証ワークフローの効率と所要時間を測定できます。 入手先 返品注文に関連付けられたInventQualityOrderTableレコードの作成タイムスタンプです。 取得 InventQualityOrderTableレコードの作成です。 イベントタイプ explicit | |||
| 返品注文をキャンセル済み | 返品注文が完了前にキャンセルされました。顧客からの依頼や、商品が返送されなかったことが原因となる場合があります。 | ||
| 重要な理由 これは、プロセスが正常に完了しなかった場合の代替的な終了を示します。返品がキャンセルされた理由を分析することで、顧客行動やプロセス上の問題を把握できます。 入手先 ReturnOrderのステータスフィールドが「キャンセル済み」に変わったことから推定されます。正常にクローズされた注文とは異なる終了状態です。 取得 SalesTable.Statusフィールドを「キャンセル済み」に変更します。 イベントタイプ inferred | |||
| 返品注文を確認 | システム内で返品注文を正式に確認することを示し、通常は後続処理を開始します。一般的には、ReturnOrderヘッダーに対する明示的なアクションまたはステータス変更として記録されます。 | ||
| 重要な理由 確認は、物流を開始する前の重要な手順です。作成から確認までの遅延は、管理業務またはシステムに関する滞留を示している可能性があります。 入手先 返品注文に対する「Confirmation」仕訳の転記、またはSalesTableのDocumentStatusフィールドの変更によって特定できます。 取得 返品注文に対して「Confirm sales order」機能を実行したイベントです。 イベントタイプ explicit | |||
抽出ガイド
ステップ
- 前提条件:Azure Active Directoryにアプリケーションを登録します。 Dynamics 365 APIへ接続する前に、Azure ADテナントへアプリケーションを登録する必要があります。このアプリケーションに、Dynamics 365 Finance & Operationsへアクセスする委任アクセス許可を付与します。例として、
Financials.ReadWrite.Allまたはカスタムアクセス許可を使用します。 - 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で取得した認証トークンは、各リクエストの認証ヘッダーにBearerトークンとして含めます。 - 抽出スクリプトを作成します。 ODataリクエストの一覧を順番に処理するスクリプトを作成します。認証、各GETリクエストの実行、取得したJSONデータの保存を処理できるようにします。APIの制限を確認し、必要に応じて待機時間を設けてください。
- APIのページネーションを処理します。 Dynamics 365では、大量の結果が複数ページに分割されます。スクリプトでレスポンス内の
@odata.nextLinkプロパティを確認します。存在する場合は、そのURLへ続けてリクエストを送り、nextLinkが返されなくなるまで次のページを取得します。 - データを変換して統合します。 12件のAPI呼び出しそれぞれから返されたJSONレスポンスを処理します。各アクティビティについて、
ReturnCaseId、ActivityName、EventTimeなどを含む標準化されたレコードを作成します。たとえば「Return Order Created」イベントでは、ReturnOrderNumberをReturnCaseIdにマッピングし、ActivityNameに「Return Order Created」を設定し、createdDateTimeをEventTimeにマッピングします。すべての呼び出しで変換したレコードを、1つのリストまたはテーブルにまとめます。 - タイムスタンプを整形して標準化します。 すべての
EventTimeを、YYYY-MM-DDTHH:MM:SSZのようなUTC形式に統一します。タイムスタンプが欠落または無効なレコードについても、必要に応じて処理します。 - 最終イベントログをエクスポートします。 すべてのデータを収集し、1つの統合データセットに変換したら、CSVファイルへエクスポートします。列見出しがProcessMindの要件(
ReturnCaseId、ActivityName、EventTime、ResponsibleUser、DispositionCodeなど)と一致していることを確認します。これでファイルをアップロードできる状態になります。
設定
- APIエンドポイントURL:Dynamics 365 Finance & OperationsインスタンスのベースURLです。
https://[YourEnvironmentName].dynamics.com/dataの形式です。 - Azure ADアプリケーション:Azure ADにクライアントIDとシークレットを持つアプリケーションを登録する必要があります。Dynamics 365のデータエンティティへアクセスするAPIアクセス許可が必要です。
- 日付範囲のフィルタリング:関連する日付項目(
createdDateTimeやmodifiedDateTimeなど)に対して、ODataの$filterパラメーターで日付範囲を指定することが重要です。抽出量を抑えるため、通常は過去3~6か月のデータから始めます。 - 会社フィルター:特定の法人のデータを抽出するには、
cross-company=trueクエリパラメーターを含めたうえで、dataAreaId項目に対して$filterを使用します。例:?cross-company=true&$filter=dataAreaId eq '[YourCompanyCode]'。 - ページネーションの設定:リクエストに
Prefer: odata.maxpagesize=[value]ヘッダーを指定し、1ページあたりのレコード数を制御します。一般的には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環境でTabular Data Stream(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か月の日付範囲を推奨します。 - 会社フィルター:記載されたクエリは、ユーザーがアクセスできるすべての法人を対象に実行されます。1社のみを分析する場合は、
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}'; 準備はできましたか?
このテンプレートを使ってデータ収集を効率化し、返品・返金処理を改善するための具体的な情報を見つけ出してください。処理の迅速化と顧客満足度の向上に向けた取り組みを、今すぐ始められます。
返品・返金の遅延を解消:今すぐプロセスを最適化
サイクルタイムを30%短縮し、顧客満足度を高めます。
クレジットカードは不要です。設定は数分で完了します。