返品・返金処理のデータテンプレート
返品・返金処理のデータテンプレート
- 収集を推奨するデータ項目
- 記録する主要なプロセスの手順
- データ抽出ガイド
返品・返金処理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| イベント発生時刻 EventTime | 特定のアクティビティまたはイベントが発生した日時を示すタイムスタンプです。 | ||
| 説明 イベント発生時刻はタイムスタンプとも呼ばれ、アクティビティが発生した正確な日時を記録します。イベントログ内の各アクティビティに対応するタイムスタンプにより、イベントの時系列がわかります。 この属性は、時間に基づくあらゆるプロセスマイニング分析に欠かせません。アクティビティ間のサイクルタイムの計算、待ち時間やボトルネックの特定、案件全体の所要時間の測定、サービスレベル合意(SLA)の遵守状況の確認に使います。タイムスタンプの正確さは、パフォーマンス分析の信頼性に直接影響します。 重要な理由 サイクルタイムや待ち時間など、所要時間に基づく指標の計算に欠かせないタイムスタンプです。パフォーマンス分析の基礎となります。 入手先 「SalesTable.createdDateTime」(注文の作成日時)や「WMSJournalTrans.createdDateTime」(倉庫仕訳の作成日時)など、各種テーブルの作成日時または変更日時のフィールドに対応します。 例 2023-10-26T10:00:00Z2023-10-26T14:30:15Z2023-10-27T09:05:42Z | |||
| 返品案件ID ReturnCaseId | 顧客の返品・返金案件を一意に識別し、関連するすべてのアクティビティを結び付けるIDです。 | ||
| 説明 返品案件IDは、返品プロセスの各案件を一意に識別する主要なIDです。返品注文の作成から最終的なクローズまで、特定の顧客の返品または返金申請に関連するすべてのアクティビティを結び付けます。 プロセス分析では、このIDを使って返品ごとの一連の流れを再構成します。プロセスの全期間を追跡し、サイクルタイム全体を測定するとともに、案件ごとの違いを分析できます。すべてのイベント、データ、指標は、このIDを使って集約され、相互に関連付けられます。 重要な理由 各プロセス手順を結び付ける基本の案件IDです。返品の開始から完了までを追跡し、分析できます。 入手先 通常は、返品承認(RMA)番号、または「Sales and marketing」モジュールにある「Returned Order」タイプの販売注文番号です。「SalesType」が「Returned Order」の「SalesTable」などで確認できます。 例 RMA-001234RMA-001235RMA-001236 | |||
| アクティビティ名 ActivityName | 返品・返金プロセスで発生した、特定の業務イベントまたはタスクの名前です。 | ||
| 説明 この属性は、返品・返金の一連の流れにおける特定の手順やイベントを表します。たとえば、「返品注文を作成」「商品を受領」「クレジットノートを転記」などです。各アクティビティは、システムに記録されたプロセス上の個別の時点を示します。 こうしたアクティビティの順序や発生頻度を分析することが、プロセスマイニングの中心です。プロセスマップを可視化し、手順間のボトルネックを特定するとともに、よく見られるバリアントや珍しいバリアントを見つけられます。アクティビティの集合によって、分析対象となるプロセスの範囲が定まります。 重要な理由 プロセスの手順を定義する属性です。プロセスの流れを可視化し、ボトルネックや手戻り、逸脱を特定できます。 入手先 システムイベントから導出する概念上の属性です。「SalesTable」や「WMSJournalTable」などのテーブルにあるステータス変更、または特定のイベントログを、利用者にわかりやすい名前に対応付けて作成できます。 例 返品注文を作成商品を受領処分コードを適用クレジットノートを転記 | |||
| 処分コード DispositionCode | 商品の検査結果と、次に行う処理を示すコードです。 | ||
| 説明 処分コードは、返品商品の品質検査時に割り当てます。「Credit」「Replace」「Scrap」「Return to Customer」など、プロセスの次の手順を決定します。 この属性は、返品プロセスにおける重要な判断ポイントです。処分コード別に分析すると、返品の結果を把握し、商品の廃棄による財務上の影響を追跡できます。また、交換と返金など、解決方法ごとの効率も評価できます。 重要な理由 このコードによって、検査後の返品ケースの処理経路が決まります。プロセスのバリアントと、それぞれが業務に与える影響を分析するうえで重要な項目です。 入手先 品質管理モジュールの主要な項目です。品質オーダーまたは検査オーダーの処理に関連します。 例 CRDTREPL-DSCRAPRTV | |||
| 商品ID ProductId | 返品対象の商品を一意に識別するIDです。 | ||
| 説明 商品IDは、多くの場合SKU(在庫管理単位)で、顧客が返品する商品を特定します。返品オーダーの各明細行には、商品IDが関連付けられています。 商品別の返品分析は、返品率の高い商品を特定するうえで欠かせません。返品率の高さは、品質管理上の問題、不正確な商品説明、製造上の欠陥を示している可能性があります。この分析により、商品に関する調査や改善の優先順位を決められます。 重要な理由 商品ごとの返品を分析し、品質上の問題や返品件数の多い商品を特定できます。 入手先 返品オーダーのSalesLineテーブルにあるItemIdフィールドに該当します。 例 SKU-A-123SKU-B-456SKU-C-789 | |||
| 担当者 ResponsibleUser | 特定のアクティビティを実行した、またはその責任を担うユーザーや従業員です。 | ||
| 説明 この属性は、プロセスの各手順を実行した担当者を示します。商品を受領した倉庫作業員、品質検査担当者、クレジットノートを転記した財務担当者などが該当します。 担当者ごとにプロセスを分析すると、業務負荷の分布や優れた実績を上げている担当者を把握し、トレーニングの必要性を見つけられます。特定の担当者やチームが処理した案件の調査や、職務分掌の適切な運用確認にも利用できます。 重要な理由 業務負荷の分布や個人・チームごとの実績を分析し、トレーニングやリソース配分の改善機会を特定できます。 入手先 「SalesTable.createdBy」などの取引レコードにある「created by」または「modified by」フィールドや、仕訳テーブルに関連付けられたユーザーIDで確認できます。 例 アリス.Wボブ.Jクリス.P | |||
| 返品チャネル ReturnChannel | 顧客が返品を開始した方法またはチャネルです。 | ||
| 説明 この属性は、顧客が返品手続きを開始したチャネルを示します。たとえば、オンラインポータル、店舗、カスタマーサポートへの電話、郵送などです。 返品チャネルごとにプロセスを分析すると、各チャネルのパフォーマンスと効率を評価できます。チャネル間でサイクルタイム、コスト、顧客満足度を比較し、優れた取り組みや投資・改善が必要な領域を特定できます。この情報は、返品チャネル利用状況のパフォーマンスダッシュボードで重要な役割を果たします。 重要な理由 返品チャネルごとのパフォーマンスを比較し、効率や費用対効果の高いチャネルを見極めるのに役立ちます。 入手先 返品オーダーのヘッダー(SalesTable)に保存されている場合や、オーダーを作成したユーザーから特定できる場合があります。カスタムロジックの実装や専用フィールドの追加が必要になることがあります。 例 ウェブポータル店舗内キオスクカスタマーサポート | |||
| 返品理由コード ReturnReasonCode | 商品を返品する理由として顧客が申告した内容です。 | ||
| 説明 返品理由コードには、商品に不具合がある、サイズが合わない、説明と異なる、不要になったなど、顧客が申告した返品理由が記録されます。通常、返品手続きの開始時に収集されます。 返品理由の分析は、根本原因の特定に欠かせません。商品の品質、商品説明、物流に関する問題を特定できます。このデータから得られるインサイトは、今後の返品を減らすための商品設計、マーケティング、サプライチェーン業務の改善に役立ちます。 重要な理由 返品が発生する理由を把握し、返品率の低減や顧客満足度の向上に向けた根本原因分析に役立ちます。 入手先 通常、返品オーダーの明細行に保存されます。返品オーダーのSalesLineテーブルで、理由コードのフィールドを確認してください。 例 不具合商品違い不要になった輸送中の破損 | |||
| SLAステータス SlaStatus | ケースがサービスレベル契約の目標期間内に解決されたかを示します。 | ||
| 説明 この計算属性は、通常、期限内または期限超過のいずれかでSLAの遵守状況を示します。最終アクティビティ(例:返品オーダーのクローズ)のタイムスタンプをRefundSlaTargetDateと比較して判定します。 この属性により、返金解決SLAパフォーマンスなどのダッシュボードで、パフォーマンスを簡単に報告できます。日付を比較する必要がなく、ひと目で分かるステータスを確認できます。すばやく絞り込みや集計を行い、全体の解決SLA遵守率を算出できます。 重要な理由 SLAの遵守状況をひと目で確認でき、期限超過ケースの絞り込みや遅延の根本原因分析に役立ちます。 入手先 派生属性です。最終解決アクティビティのタイムスタンプとRefundSlaTargetDate属性を比較して算出します。 例 期限内期限超過 | |||
| クレジットノートID CreditNoteId | 返金時に作成されるクレジットノート文書を一意に識別するIDです。 | ||
| 説明 返金処理では、クレジットノートまたはクレジットメモと呼ばれる財務文書が作成されます。この属性には、その文書を一意に識別する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 | 返品商品を受け取る倉庫または拠点を識別するIDです。 | ||
| 説明 この属性は、返品商品を処理する物理的な倉庫または返品センターを特定します。拠点によって、プロセス、リソース、パフォーマンスが異なる場合があります。 倉庫別にプロセスを分析すると、拠点間のパフォーマンスを比較できます。返品処理の効率が高い施設の特定、地域ごとのボトルネックの把握、物流ネットワーク全体でのリソース配分やプロセス標準化の判断に役立ちます。 重要な理由 倉庫や返品センター間のパフォーマンスを比較し、地域ごとのボトルネックや優れた取り組みを特定できます。 入手先 入荷ジャーナル(WMSJournalTable)やSalesLineなど、在庫関連の取引にあるInventLocationIdフィールドに保存されています。 例 WH-EASTWH-WESTCENTRAL-DC | |||
| 最終データ更新日時 LastDataUpdate | プロセスのデータが最後に更新された日時を示すタイムスタンプです。 | ||
| 説明 この属性は、ソースシステムからデータを最後に抽出し、プロセスマイニングツールに反映した日時を記録します。分析対象のデータがどの時点のものかを確認できます。 最終データ更新日時を把握することは、分析結果の鮮度を理解するうえで重要です。ダッシュボードや重要業績評価指標(KPI)を正しく読み取るために、リアルタイムのデータなのか、特定の時点のスナップショットなのかを確認できます。業務のモニタリングにも欠かせません。 重要な理由 データの鮮度を示し、プロセスに関するインサイトがどの程度最新かを分析担当者が把握できるようにします。 入手先 データの取り込み処理中に生成、保存されるメタデータ属性です。通常、ETLジョブの完了時刻を示します。 例 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| 実際の返金額 ActualRefundAmount | 顧客に返金された最終的な金額です。 | ||
| 説明 この属性は、顧客に返金されたことが確定した最終金額です。クレジットノートの作成と転記時に記録されます。 財務分析に欠かせない属性で、返金額の差異分析ダッシュボードと返金額正確率のKPIで直接使用されます。このデータを分析すると、返品による財務上の影響や、プロセス中に行われた調整を把握できます。 重要な理由 返品による実際の財務上の影響を示します。返金額の正確性の算出や、財務上の結果の把握に欠かせません。 入手先 転記済みクレジットノートの取引詳細で確認できます。クレジットノートに関するCustTransテーブルおよびCustInvoiceJourテーブルに関連付けられています。 例 99.99135.000.00 | |||
| 終了時刻 EndTime | 特定のアクティビティが完了した日時を示すタイムスタンプです。 | ||
| 説明 終了時刻は、アクティビティが完了した時点を示すタイムスタンプです。開始時刻がアクティビティの開始を示すのに対し、終了時刻は完了を示します。これにより、個々のタスクの処理時間を計算できます。 この属性は、特に「商品を検査」のように所要時間を測定できるタスクの詳細なパフォーマンス分析に欠かせません。開始時刻と終了時刻を比較すると、タスクの実作業時間を正確に測定し、タスク間の待ち時間と区別できます。タスク間だけでなく、個々のアクティビティ内の非効率な箇所も特定できます。 重要な理由 個々のアクティビティの実作業時間を計算し、待ち時間と実際の作業時間を区別できます。 入手先 多くの場合、終了時刻は他のデータから算出する必要があります。たとえば、アクティビティを完了させるステータス変更の「modifiedDateTime」や、次のアクティビティの開始時刻を使います。 例 2023-10-26T10:15:00Z2023-10-26T14:45:20Z2023-10-27T09:55:12Z | |||
| 返品オーダーのステータス ReturnOrderStatus | イベント発生時点における返品オーダー全体のステータスです。 | ||
| 説明 この属性は、返品オーダーのヘッダーの現在のステータス(オープン、請求済み、キャンセル済みなど)を示します。ケースの進行状況を大まかに把握できます。 アクティビティでプロセスの各ステップを詳しく確認できる一方、全体のステータスはケースの絞り込みや分類に役立ちます。たとえば、現在の業務量を把握するためにオープンのケースだけに絞ったり、最終的にキャンセルされたケースのプロセスフローを分析したりできます。 重要な理由 ケースの状態を大まかに把握でき、ケースの絞り込みやキャンセルなどの結果の確認に役立ちます。 入手先 SalesTableのSalesStatusまたはDocumentStatusフィールドにあります。 例 オープンオーダー納品済み請求済みキャンセル済み | |||
| 返品タイプ ReturnType | 返金や交換など、想定される対応結果に基づいて返品を分類します。 | ||
| 説明 この属性は、顧客が希望する、または企業が提示する解決方法に基づいて返品ケースを分類します。一般的なタイプには、金銭の返金、交換品への交換、修理があります。 この分類は、異なるプロセス経路の分析に役立ちます。返金の処理と交換品の発送では、プロセスが大きく異なります。返品タイプ別に分類すると、各対応経路のサイクルタイムやボトルネックをより正確に分析できます。 重要な理由 返金と交換では手順やサイクルタイムが異なるため、想定される対応結果ごとに分析を分類できます。 入手先 返品オーダーのヘッダーにあるカスタムフィールドの場合や、処分コード、交換用販売オーダーの作成など、その後の取引から特定する場合があります。 例 返金交換ストアクレジット | |||
| 返金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です。 | ||
| 説明 顧客IDは、返品に関連付けられた顧客アカウントを一意に識別します。返品取引と、CRMまたは顧客データベース内の特定の顧客を結び付けます。 顧客別に返品を分析すると、返品が異常に多い顧客を特定できます。詐欺行為や継続的な不満の兆候である可能性があります。また、顧客を分類し、たとえば優良顧客に優先返品サービスを提供する際にも役立ちます。 重要な理由 返品プロセスを特定の顧客に結び付けることで、顧客単位の分析や返品傾向、不正の可能性の特定が可能になります。 入手先 返品オーダーのSalesTableにあるCustAccountフィールドです。 例 CUST-00045CUST-00192CUST-00315 | |||
返品・返金処理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| クレジットノートを転記 | クレジットノートが財務元帳に正式に転記され、顧客がクレジットを利用できる状態になります。会社側での返金処理が完了したことを示します。 | ||
| 重要な理由 返金がシステム上で処理されたことを確認する、重要な財務上の節目です。返金に関するSLAの遵守状況を測定する際の主要なアクティビティとなることがよくあります。 入手先 返品注文の請求書仕訳の転記タイムスタンプです。これによりクレジットノートが確定し、返品注文のステータスが「Invoiced」に変わります。 記録 返品注文の請求書仕訳の転記。 イベントタイプ explicit | |||
| 処分コードを適用 | 検査の完了と、返品商品の処理方法の決定を示すアクティビティです。返品明細に「Credit」「Scrap」「Replace」などの処分コードを割り当てます。 | ||
| 重要な理由 返金、交換、返品の却下など、その後のプロセス経路を決める重要な判断ポイントです。ここで遅れが生じると、解決までの時間全体に大きく影響する可能性があります。 入手先 返品注文の明細に関連する在庫取引または仕訳で、DispositionCodeフィールドに値が設定された際に記録されます。 記録 返品注文の明細にDispositionCodeが設定された際の更新イベント。 イベントタイプ explicit | |||
| 商品を受領 | 返品商品を倉庫または指定の返品センターで物理的に受領したことを示します。返品注文に関連付けられた入荷仕訳を転記した際に記録されます。 | ||
| 重要な理由 顧客側の手続きから社内処理へ移る重要な節目です。検査や処分方法の決定など、社内での処理時間を測定する起点になります。 入手先 返品注文の明細に関連付けられたWMS仕訳または商品入荷仕訳の転記タイムスタンプです。在庫取引のステータスが「Registered」または「Received」に更新されます。 記録 返品注文の明細に関連付けられた商品入荷仕訳の転記イベント。 イベントタイプ explicit | |||
| 返品注文をクローズ | 返品注文が最終状態に達し、商品の移動と財務処理がすべて完了したことを示します。通常、クレジットノートの転記後、または交換品の出荷後に完了します。 | ||
| 重要な理由 正常に完了した返品プロセスの主な終了イベントです。作成からこの時点までの期間が、案件全体のサイクルタイムを表します。 入手先 ReturnOrderのステータスフィールドが「Invoiced」や「Closed」などの最終値に変わったことから推定します。以降の処理が予定されていないことを示します。 記録 SalesTable.StatusまたはSalesTable.DocumentStatusフィールドが最終状態に変わること。 イベントタイプ inferred | |||
| 返品注文を作成 | このアクティビティは、システムで返品承認(RMA)または返品注文を作成し、返品プロセスを開始したことを示します。Dynamics 365で新しいReturnOrderレコードが作成された際に記録される明示的なイベントです。 | ||
| 重要な理由 返品プロセス全体の開始イベントです。このアクティビティから他のアクティビティまでの時間を分析すると、プロセス全体のリードタイムを把握し、初期段階のボトルネックを特定できます。 入手先 ReturnOrderヘッダーの作成タイムスタンプから取得します。通常、SalesTypeが「Returned Order」となっているSalesTableで確認できます。 記録 SalesType = 'Returned Order'のSalesTableレコードが作成されたイベント。 イベントタイプ explicit | |||
| クレジットノートを作成 | 処分方法が「Credit」の場合にクレジットノートを作成し、顧客への返金を承認します。プロセスのうち、金銭の精算に関する部分が正式に始まったことを示します。 | ||
| 重要な理由 このアクティビティは、返金が財務上承認されたことを示します。処分方法の決定からクレジットノートの作成までの時間を確認すると、返金開始に関する事務処理の遅れを把握できます。 入手先 元の返品注文に関連付けられた、金額がマイナスの新しいSalesTableレコードの作成から推定できます。または、「Create credit note」バッチジョブの実行から確認できます。 記録 返品注文の請求書を転記するなどして、クレジットノートを作成。 イベントタイプ explicit | |||
| 交換品の注文を作成 | 顧客に交換品を送るため、新しい販売注文を作成します。処分方法が「Replace and Credit」または「Replace and Scrap」の場合に発生します。 | ||
| 重要な理由 このアクティビティから、交換のバリアントが始まります。返金の経路と分けて追跡することで、交換に伴う複雑さやコストを把握できます。 入手先 交換品に対する新しいSalesTableレコードの作成です。多くの場合、自動で作成され、元の返品注文に関連付けられます。 記録 処分方法に基づき、返品注文に関連付けられた新しい販売注文の作成。 イベントタイプ explicit | |||
| 交換品を出荷 | 交換品の梱包明細を転記し、顧客に出荷したことを示します。交換品の出荷プロセスが完了したことを表します。 | ||
| 重要な理由 交換のバリアントにおける重要な節目で、顧客に対する会社の義務を果たしたことを示します。交換のサイクルタイムを追跡するうえで欠かせません。 入手先 交換品の販売注文に対する梱包明細仕訳の転記日です。注文のステータスが「Delivered」に更新されます。 記録 交換品の販売注文に対する梱包明細の転記。 イベントタイプ explicit | |||
| 入荷仕訳を作成 | 倉庫が返品商品の到着を見込んでいることを示すアクティビティです。入荷仕訳を作成し、商品の物理的な受け入れに備えてシステムを整えます。 | ||
| 重要な理由 この手順により、物流の準備と実際の商品の受け入れを区別できます。倉庫の受け入れ準備状況を分析し、返品商品の入荷計画を立てる際に役立ちます。 入手先 JournalTypeが「Arrival」のレコードをWMSJournalTableに作成します。この仕訳は返品注文の明細に関連付けられます。 記録 返品に関するWMSJournalTableレコードの作成タイムスタンプ。 イベントタイプ explicit | |||
| 品質検査オーダーを作成 | 正式な品質検査オーダーが作成され、返品商品に対して所定の検査が必要であることを示します。返品商品の詳細な試験や品質基準との照合が必要な場合によく行われます。 | ||
| 重要な理由 正式な検査プロセスの開始を示すアクティビティです。この時点からの時間を追跡することで、品質保証ワークフローの効率と所要時間を測定できます。 入手先 返品注文に関連付けられたInventQualityOrderTableレコードの作成タイムスタンプ。 記録 InventQualityOrderTableレコードの作成。 イベントタイプ explicit | |||
| 返品注文をキャンセル | 返品注文が完了前にキャンセルされた状態です。顧客からの依頼や、商品が返品されなかったことなどが理由として考えられます。 | ||
| 重要な理由 プロセスが正常に完了しなかった場合の終了状態です。返品がキャンセルされた理由を分析すると、顧客行動やプロセス上の問題を把握できます。 入手先 ReturnOrderのステータスフィールドが「Cancelled」に変わったことから推定します。正常にクローズした注文とは異なる最終状態です。 記録 SalesTable.Statusフィールドが「Cancelled」に変わること。 イベントタイプ 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で取得した認証トークンは、各リクエストのAuthorizationヘッダーにBearerトークンとして含めます。 - 抽出スクリプトを作成します。 ODataリクエストの一覧を順に処理するスクリプトを作成します。スクリプトで認証を処理し、各GETリクエストを実行して、返されたJSONデータを保存します。APIの制限に留意し、必要に応じて待機時間を設けてください。
- APIのページネーションに対応します。 Dynamics 365では、大量の結果が複数ページに分割されます。レスポンスに
@odata.nextLinkプロパティがあるかをスクリプトで確認します。存在する場合は、そのURLに対して次のリクエストを実行し、nextLinkがなくなるまでデータを取得します。 - データを変換して統合します。 12件のAPI呼び出しそれぞれから返されたJSONレスポンスを処理します。各アクティビティについて、
ReturnCaseId、ActivityName、EventTimeなどの属性を含む標準形式のレコードを作成します。たとえば、「返品注文の作成」イベントでは、ReturnOrderNumberをReturnCaseIdに、createdDateTimeをEventTimeに割り当て、ActivityNameには「返品注文の作成」を設定します。変換したレコードを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パラメーターを使って、すべてのAPI呼び出しで期間を指定することが重要です。抽出データを扱いやすい量にするには、まず直近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)レスポンスに対応できるようにします。通常は、指数バックオフや、一定時間待ってから再試行する処理を実装します。
クエリの例 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エンドポイントで直接クエリを実行すると、時間がかかる場合があります。接続は分析クエリ向けに最適化されていますが、数百万行にわたる複雑な結合ではタイムアウトする可能性があります。期間を厳密に絞り込むことをおすすめします。
クエリの例 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%短縮し、顧客満足度を高めます。
クレジットカードは不要です。セットアップは数分で完了します。