Šablona dat pro zpracování vrácení a refundací
Šablona dat pro zpracování vrácení a refundací
- Doporučená datová pole ke sběru
- Důležité kroky procesu ke sledování
- Pokyny k extrakci dat
Atributy zpracování vrácení a refundací
| Název | Popis | ||
|---|---|---|---|
| Čas události EventTime | Časové razítko udávající, kdy došlo ke konkrétní činnosti nebo události. | ||
| Popis Čas události neboli časové razítko zaznamenává přesné datum a čas provedení činnosti. Každá činnost v záznamu událostí má odpovídající časové razítko, které určuje chronologické pořadí událostí. Tento atribut je zásadní pro veškerou časovou analýzu v process miningu. Používá se k výpočtu doby průchodu mezi činnostmi, odhalení čekání a úzkých míst, měření celkové doby případu a kontroly dodržování dohod o úrovni služeb (SLA). Přesnost časových razítek přímo ovlivňuje spolehlivost analýzy výkonnosti. Proč je to důležité Časové razítko je nezbytné pro výpočet všech ukazatelů založených na délce trvání, například doby průchodu a čekání, které jsou základem analýzy výkonnosti. Kde data získat Odpovídá polím data vytvoření nebo změny v různých tabulkách, například 'SalesTable.createdDateTime' při vytvoření objednávky nebo 'WMSJournalTrans.createdDateTime' u skladových deníků. Příklady 2023-10-26T10:00:00Z2023-10-26T14:30:15Z2023-10-27T09:05:42Z | |||
| ID případu vrácení ReturnCaseId | Jedinečný identifikátor případu vrácení a refundace zákazníka, který propojuje všechny související činnosti. | ||
| Popis ID případu vrácení slouží jako hlavní identifikátor každého jednotlivého procesu vrácení. Propojuje všechny činnosti související s konkrétním vrácením zboží nebo žádostí o refundaci, od vytvoření objednávky na vrácení až po její konečné uzavření. Při analýze procesu je toto ID zásadní pro sestavení celé cesty každého vrácení. Umožňuje sledovat celý životní cyklus, měřit celkovou dobu průchodu a porovnávat rozdíly mezi jednotlivými případy. Pomocí tohoto identifikátoru se sdružují a propojují všechny události, data a ukazatele. Proč je to důležité Jde o hlavní identifikátor případu, který propojuje všechny kroky procesu a umožňuje sledovat a analyzovat každé vrácení od začátku do konce. Kde data získat Obvykle jde o číslo autorizace vrácení materiálu (RMA) nebo číslo prodejní objednávky typu 'Returned Order' v modulu 'Sales and marketing'. Najdete ho například v tabulce 'SalesTable', kde má 'SalesType' hodnotu 'Returned Order'. Příklady RMA-001234RMA-001235RMA-001236 | |||
| Název činnosti ActivityName | Název konkrétní obchodní události nebo úkolu, který proběhl v procesu vrácení a refundace. | ||
| Popis Tento atribut popisuje konkrétní krok nebo událost v průběhu vrácení a refundace, například 'Vytvoření objednávky na vrácení', 'Přijetí zboží' nebo 'Zaúčtování dobropisu'. Každá činnost představuje samostatný bod procesu zaznamenaný v systému. Analýza pořadí a četnosti těchto činností je základem process miningu. Umožňuje zobrazit procesní mapy, odhalit úzká místa mezi kroky a najít běžné i méně obvyklé varianty procesu. Soubor činností vymezuje rozsah analyzovaného procesu. Proč je to důležité Určuje jednotlivé kroky procesu a umožňuje zobrazit jeho průběh a odhalit úzká místa, opakovanou práci i odchylky. Kde data získat Jde o koncepční atribut odvozený ze systémových událostí. Lze ho vytvořit mapováním změn stavů v tabulkách, jako jsou 'SalesTable' a 'WMSJournalTable', nebo přiřazením srozumitelných názvů konkrétním záznamům událostí. Příklady Vytvoření objednávky na vráceníPřijetí zbožíPřiřazení kódu způsobu vyřízeníZaúčtování dobropisu | |||
| ID produktu ProductId | Jedinečný identifikátor vraceného produktu. | ||
| Popis ID produktu, často označované jako skladová jednotka (SKU), určuje konkrétní zboží, které zákazník vrací. Každý řádek vratkové objednávky je přiřazen k ID produktu. Analýza vrácení podle produktů pomáhá odhalit zboží s vysokou mírou vrácení. Může jít o známku problémů s kontrolou kvality, nepřesného popisu produktu nebo výrobních vad. Tato analýza pomáhá určit, které produkty je třeba prověřit a zlepšit. Proč je to důležité Umožňuje analyzovat vrácení podle jednotlivých produktů a odhalit zboží s problémy s kvalitou nebo vysokým počtem vrácení. Kde data získat Odpovídá poli 'ItemId' v tabulce 'SalesLine' pro vratkovou objednávku. Příklady SKU-A-123SKU-B-456SKU-C-789 | |||
| Kanál vrácení ReturnChannel | Způsob nebo kanál, kterým zákazník zahájil vrácení. | ||
| Popis Tento atribut určuje kanál, kterým zákazník zahájil vrácení, například „Online portál“, „Prodejna“, „Telefonát na zákaznickou podporu“ nebo „Pošta“. Rozdělení analýzy procesu podle kanálu vrácení umožňuje porovnat výkonnost a efektivitu jednotlivých kanálů. Firma může porovnat dobu zpracování, náklady a spokojenost zákazníků a určit, které postupy se osvědčují a kam se vyplatí investovat nebo kde je třeba proces zlepšit. Tento údaj je důležitý pro dashboard „Výkonnost využití kanálů vrácení“. Proč je to důležité Umožňuje porovnat výkonnost různých kanálů vrácení a určit, které z nich jsou nejefektivnější a nákladově nejvýhodnější. Kde data získat Tyto údaje mohou být uloženy v záhlaví vratkové objednávky ('SalesTable') nebo odvozeny od uživatele, který objednávku vytvořil. Může být potřeba vlastní logika nebo samostatné pole. Příklady Webový portálSamoobslužný kiosek v prodejněZákaznická podpora | |||
| Kód důvodu vrácení ReturnReasonCode | Důvod, který zákazník uvedl pro vrácení zboží. | ||
| Popis Kód důvodu vrácení zaznamenává důvod, který zákazník uvedl, například „Vadné zboží“, „Nesprávná velikost“, „Neodpovídá popisu“ nebo „Už není potřeba“. Tyto údaje se obvykle zaznamenávají při zahájení vrácení. Analýza důvodů vrácení pomáhá odhalit jejich příčiny. Firmy díky ní mohou zjistit problémy s kvalitou výrobků, nepřesné popisy nebo chyby v logistice. Zjištění z těchto dat mohou vést ke změnám v návrhu výrobků, marketingu i provozu dodavatelského řetězce a pomoci snížit počet budoucích vrácení. Proč je to důležité Ukazuje, proč zákazníci zboží vracejí. Díky tomu lze hledat příčiny, snížit počet vrácení a zvýšit spokojenost zákazníků. Kde data získat Tento údaj se obvykle ukládá na úrovni řádku vratkové objednávky. U vratkových objednávek hledejte pole s kódem důvodu v tabulce 'SalesLine'. Příklady VADANESPRÁVNÉ_ZBOŽÍJIŽ_NENÍ_POTŘEBAPOŠKOZENO_PŘI_PŘEPRAVĚ | |||
| Kód způsobu vyřízení DispositionCode | Kód označující výsledek kontroly zboží a další postup. | ||
| Popis Kód způsobu vyřízení se přiřazuje během kontroly kvality vráceného zboží. Určuje další krok procesu, například 'Credit', 'Replace', 'Scrap' nebo 'Return to Customer'. Tento atribut představuje důležitý rozhodovací bod v procesu vrácení. Analýza podle kódu způsobu vyřízení pomáhá porozumět výsledkům vrácení, sledovat finanční dopad vyřazení zboží a porovnávat efektivitu různých způsobů vyřízení, například výměny a refundace. Proč je to důležité Tento kód určuje, jakou cestou se případ vrácení vydá po kontrole. Je proto důležitý při analýze variant procesu a jejich obchodních dopadů. Kde data získat Jde o důležité pole v modulu řízení kvality. Souvisí se zpracováním Quality Order nebo Inspection Order. Příklady CRDTREPL-DSCRAPRTV | |||
| Odpovědný uživatel ResponsibleUser | Uživatel nebo zaměstnanec, který provedl konkrétní činnost nebo za ni odpovídá. | ||
| Popis Tento atribut určuje osobu odpovědnou za provedení kroku procesu. Může jít o skladníka, který převzal zboží, pracovníka kontroly kvality nebo účetního, který zaúčtoval dobropis. Analýza procesu podle uživatelů pomáhá porozumět rozložení pracovní zátěže, určit pracovníky s nejlepšími výsledky a odhalit potřebu školení. Lze ji využít také k prověření případů zpracovaných konkrétními osobami nebo týmy a ke kontrole řádného rozdělení odpovědností. Proč je to důležité Umožňuje analyzovat rozložení pracovní zátěže a výkonnost jednotlivců i týmů a odhalit příležitosti ke školení nebo lepšímu rozdělení zdrojů. Kde data získat Najdete ho v polích 'created by' nebo 'modified by' v záznamech transakcí, například v 'SalesTable.createdBy' nebo v propojených ID uživatelů v tabulkách deníků. Příklady Alice.WBob.JChris.P | |||
| Čas ukončení EndTime | Časové razítko udávající, kdy byla konkrétní činnost dokončena. | ||
| Popis Čas ukončení označuje okamžik dokončení činnosti. Zatímco StartTime označuje její začátek, EndTime její konec. Díky tomu lze vypočítat dobu zpracování konkrétního úkolu. Tento atribut je důležitý pro podrobnou analýzu výkonnosti, zejména u úkolů s měřitelnou délkou trvání, jako je 'Kontrola zboží'. Porovnáním StartTime a EndTime mohou analytici přesně změřit aktivní dobu zpracování úkolu a odlišit ji od čekání mezi úkoly. Pomáhá to odhalit neefektivitu přímo v jednotlivých činnostech, nejen mezi nimi. Proč je to důležité Umožňuje vypočítat aktivní dobu zpracování jednotlivých činností a odlišit čekání od skutečné práce. Kde data získat Tuto hodnotu je často nutné odvodit. Může jít například o 'modifiedDateTime' změny stavu, která činnost ukončuje, nebo o StartTime následující činnosti. Příklady 2023-10-26T10:15:00Z2023-10-26T14:45:20Z2023-10-27T09:55:12Z | |||
| Cílové datum vyřízení refundace podle SLA RefundSlaTargetDate | Datum, do kterého má být případ vrácení a refundace plně vyřešen. | ||
| Popis Tento atribut určuje termín SLA pro vyřízení případu vrácení. Do tohoto data by měl zákazník obdržet konečné řešení, například zaúčtovanou refundaci nebo odeslaný náhradní výrobek. Cílové datum je důležité pro sledování plnění závazků vůči zákazníkům. Používá se k výpočtu KPI „Míra dodržení SLA při vyřízení“ a k naplnění dashboardu „Výkonnost vyřízení refundací podle SLA“. Porovnáním tohoto data se skutečným datem dokončení procesu může firma odhalit nedodržené termíny SLA a včas řešit případy, které zůstávají otevřené příliš dlouho. Proč je to důležité Slouží jako měřítko výkonnosti procesu. Umožňuje sledovat dodržování SLA a odhalovat případy vyřízené po termínu. Kde data získat Nemusí jít o standardní pole. Často se vypočítává jako datum vytvoření vratky plus předem stanovená lhůta SLA, například 14 dní. Může být uloženo ve vlastním poli. Příklady 2023-11-10T23:59:59Z2023-11-15T23:59:59Z | |||
| Dodržuje pravidla IsPolicyAdherent | Příznak, který označuje, zda schválení vrácení odpovídá stanoveným pravidlům pro vrácení. | ||
| Popis Tento vypočítaný logický atribut označuje, zda vrácení splňuje všechna kritéria stanovená firemními pravidly. Může zohledňovat například lhůtu pro vrácení, stav zboží nebo důvod vrácení. Atribut přímo podporuje dashboard „Přehled souladu schválení vrácení s pravidly“ a KPI „Míra schválení vrácení v souladu s pravidly“. Firma díky němu může měřit dodržování pravidel, odhalovat výjimky a analyzovat jejich důvody i četnost. To je důležité pro řízení a kontrolu nákladů. Proč je to důležité Přímo měří dodržování firemních pravidel. Pomáhá odhalit a omezit schválení vrácení, která s nimi nejsou v souladu a mohou vést ke ztrátě tržeb. Kde data získat Jde o odvozený atribut. Jeho výpočet vyžaduje porovnání údajů o vrácení, například data vrácení oproti datu nákupu nebo důvodu vrácení, s předem stanovenými obchodními pravidly. Příklady truefalse | |||
| ID dobropisu CreditNoteId | Jedinečný identifikátor dobropisu vystaveného při refundaci. | ||
| Popis Při zpracování refundace se vystaví finanční doklad, například dobropis. Tento atribut uchovává jeho jedinečné ID. ID přímo propojuje provozní proces vrácení s finančními záznamy v účetním systému. Hodí se při auditu i podrobnějším prověřování finančních rozdílů. Analytik díky němu může dohledat konkrétní finanční transakci, kterou byl případ vrácení vypořádán. Proč je to důležité Propojuje provozní proces vrácení s odpovídající finanční transakcí. To je důležité pro audit a finanční odsouhlasení. Kde data získat Číslo dobropisu se obvykle nachází v poli 'InvoiceId' tabulky 'CustInvoiceJour', kde je typ transakce 'Credit note'. Lze ho propojit s vratkovou objednávkou. Příklady CN-10056CN-10057CN-10058 | |||
| ID skladu WarehouseId | Identifikátor skladu nebo místa, kam je vrácené zboží přijato. | ||
| Popis Tento atribut určuje konkrétní fyzický sklad nebo centrum pro vrácené zboží, kde se zpracovává vrácený produkt. Jednotlivá místa se mohou lišit procesy, zdroji i výkonností. Analýza procesu podle skladů umožňuje porovnávat výkonnost jednotlivých míst. Pomáhá zjistit, která provozovna zpracovává vratky nejefektivněji, odhalit regionální úzká místa a rozhodovat o rozdělení zdrojů i sjednocení procesů v logistické síti. Proč je to důležité Umožňuje porovnat výkonnost různých skladů nebo center pro vrácené zboží a odhalit regionální úzká místa či osvědčené postupy. Kde data získat Tento údaj se ukládá v poli 'InventLocationId' v transakcích souvisejících se zásobami, například v deníku příjmu ('WMSJournalTable') nebo v tabulce 'SalesLine'. Příklady WH-EASTWH-WESTCENTRAL-DC | |||
| ID zákazníka CustomerId | Jedinečný identifikátor zákazníka, který zahájil vrácení. | ||
| Popis ID zákazníka je jedinečný identifikátor zákaznického účtu spojeného s vrácením. Propojuje vratkovou transakci s konkrétním zákazníkem v CRM nebo zákaznické databázi. Analýza vrácení podle zákazníků pomáhá odhalit zákazníky s neobvykle vysokým počtem vrácení, což může ukazovat na podvodné jednání nebo dlouhodobou nespokojenost. Údaje lze využít také k segmentaci zákazníků, například k nabídce nadstandardních služeb při vrácení zákazníkům s vysokou hodnotou. Proč je to důležité Propojuje proces vrácení s konkrétním zákazníkem. Umožňuje analyzovat vrácení na úrovni zákazníků a odhalovat jejich vzorce nebo možné podvody. Kde data získat Jde o pole 'CustAccount' v tabulce 'SalesTable' pro vratkovou objednávku. Příklady CUST-00045CUST-00192CUST-00315 | |||
| Poslední aktualizace dat LastDataUpdate | Časové razítko udávající, kdy byla data procesu naposledy aktualizována. | ||
| Popis Tento atribut zaznamenává datum a čas posledního získání dat ze zdrojového systému a jejich aktualizace v nástroji pro process mining. Ukazuje, jak aktuální jsou analyzovaná data. Znalost času poslední aktualizace pomáhá posoudit aktuálnost analýzy. Uživatelé díky ní mohou správně interpretovat dashboardy a KPI a vědí, zda pracují s aktuálními daty, nebo se snímkem z určitého okamžiku. To je důležité pro provozní sledování. Proč je to důležité Ukazuje aktuálnost dat, takže analytici vědí, jak současné jsou jejich poznatky o procesu. Kde data získat Jde o atribut metadat vytvořený a uložený při načítání dat. Obvykle představuje časové razítko dokončení úlohy ETL. Příklady 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Požadovaná částka refundace RequestedRefundAmount | Celková částka refundace, kterou zákazník požaduje. | ||
| Popis Tento atribut představuje původní částku refundace požadovanou nebo očekávanou na začátku procesu vrácení. Obvykle vychází z původní kupní ceny vraceného zboží. Tato hodnota slouží jako základ pro „Analýzu rozdílu částek refundace“. Porovnáním požadované a skutečně vyplacené částky může firma odhalit rozdíly způsobené poplatky za opětovné naskladnění, částečnou refundací poškozeného zboží nebo jinými úpravami. Pomáhá tak kontrolovat správnost finančních údajů a dodržování pravidel. Proč je to důležité Slouží jako základ pro kontrolu finanční správnosti při porovnání se skutečně zpracovanou částkou refundace. Kde data získat Obvykle jde o částku na řádku nebo celkovou částku původního řádku prodejní objednávky, který se vrací. Najdete ji v poli 'SalesLine.LineAmount'. Příklady 99.99150.0024.50 | |||
| Skutečná částka refundace ActualRefundAmount | Konečná částka refundace vyplacená zákazníkovi. | ||
| Popis Tento atribut představuje konečnou potvrzenou částku refundace vyplacenou zákazníkovi. Zaznamenává se při vytvoření a zaúčtování dobropisu. Jde o důležitý údaj pro finanční analýzu. Používá se přímo v dashboardu „Analýza rozdílu částek refundace“ a v KPI „Míra přesnosti částek refundace“. Analýza těchto dat pomáhá pochopit finanční dopad vrácení i úpravy provedené během procesu. Proč je to důležité Vyjadřuje skutečný finanční dopad vrácení. Je důležitý pro výpočet přesnosti refundací a pochopení finančních výsledků. Kde data získat Tuto hodnotu najdete v podrobnostech zaúčtované dobropisové transakce. Souvisí s tabulkami 'CustTrans' a 'CustInvoiceJour' pro dobropis. Příklady 99.99135.000.00 | |||
| Stav SLA SlaStatus | Označuje, zda byl případ vyřešen v termínu stanoveném SLA. | ||
| Popis Tento vypočítaný atribut jednoduše označuje, zda bylo SLA dodrženo, obvykle jako „Včas“ nebo „Po termínu“. Určuje se porovnáním časového razítka poslední aktivity, například „Vratková objednávka uzavřena“, s údajem 'RefundSlaTargetDate'. Atribut zjednodušuje vykazování výkonnosti v dashboardech, jako je „Výkonnost vyřízení refundací podle SLA“. Uživatelé nemusí porovnávat data, protože stav je uveden přímo a srozumitelně. Lze tak rychle filtrovat a agregovat případy a vypočítat celkovou „Míru dodržení SLA při vyřízení“. Proč je to důležité Poskytuje přehledný ukazatel dodržení SLA. Usnadňuje filtrování případů po termínu a analýzu příčin zpoždění. Kde data získat Jde o odvozený atribut, který se vypočítá porovnáním časového razítka aktivity konečného vyřízení s atributem 'RefundSlaTargetDate'. Příklady VčasPo termínu | |||
| Stav vratkové objednávky ReturnOrderStatus | Celkový stav vratkové objednávky v okamžiku události. | ||
| Popis Tento atribut označuje aktuální stav záhlaví vratkové objednávky, například „Otevřená“, „Fakturovaná“ nebo „Zrušená“. Poskytuje přehled o tom, v jaké fázi se případ nachází. Aktivity zachycují jednotlivé kroky procesu, zatímco celkový stav se hodí k filtrování a segmentaci případů. Analytik se může zaměřit například jen na „Otevřené“ případy, aby zjistil aktuální objem práce, nebo analyzovat průběh případů, které byly nakonec „Zrušeny“. Proč je to důležité Poskytuje souhrnný přehled o stavu případu. Usnadňuje filtrování případů a analýzu výsledků, například zrušení. Kde data získat Tento údaj najdete v poli 'SalesStatus' nebo 'DocumentStatus' tabulky 'SalesTable'. Příklady Otevřená objednávkaDoručenoFakturovánoZrušeno | |||
| Typ vrácení ReturnType | Zařazuje vrácení podle očekávaného výsledku, například refundace nebo výměna. | ||
| Popis Tento atribut klasifikuje případ vrácení podle typu řešení, které zákazník požaduje nebo firma nabízí. Mezi běžné typy patří peněžní „Refundace“, výměna za „Náhradní výrobek“ nebo „Oprava“. Tato klasifikace usnadňuje analýzu různých průběhů procesu. Proces vyplacení refundace se výrazně liší od procesu odeslání náhradního výrobku. Rozdělení podle typu vrácení umožňuje přesněji analyzovat dobu zpracování a úzká místa pro jednotlivé způsoby řešení. Proč je to důležité Umožňuje rozdělit analýzu podle zamýšleného výsledku, protože procesy refundace a výměny mají odlišné kroky i dobu zpracování. Kde data získat Může jít o vlastní pole v záhlaví vratkové objednávky nebo o údaj odvozený z kódu dispozice či z následných transakcí, například z vytvoření nové prodejní objednávky na náhradní výrobek. Příklady RefundaceNáhradní výrobekKredit na zákaznickém účtu | |||
| Zdrojový systém SourceSystem | Informační systém, ze kterého byla data událostí získána. | ||
| Popis Tento atribut určuje zdrojový informační systém, ze kterého data pocházejí. V tomto případě půjde především o 'Microsoft Dynamics 365'. Ve větších organizacích může proces probíhat v několika systémech. Uvedení zdrojového systému u každé události je důležité pro správu dat, řešení problémů při jejich získávání a pochopení používaných technologií. Potvrzuje původ analyzovaných dat. Proč je to důležité Poskytuje důležitý kontext o původu dat, který je nezbytný pro správu a ověřování dat i pochopení systémů zapojených do procesu. Kde data získat Obvykle jde o statickou hodnotu přidanou při extrakci, transformaci a načítání dat (ETL), která označuje původ datové sady. Příklady Microsoft Dynamics 365 F&OD365-PROD | |||
Aktivity při zpracování vrácení a refundací
| Aktivita | Popis | ||
|---|---|---|---|
| Přijetí zboží | Označuje fyzické převzetí vráceného zboží ve skladu nebo určeném centru pro vrácení. Zaznamená se při zaúčtování příjmového deníku propojeného s objednávkou na vrácení. | ||
| Proč je to důležité Jde o důležitý milník, který převádí proces od činnosti zákazníka k internímu zpracování. Od tohoto okamžiku se počítá doba interní manipulace, například kontroly a určení způsobu vyřízení. Kde data získat Časové razítko zaúčtování WMS Journal nebo Item Arrival Journal propojeného s řádkem ReturnOrder. Tím se aktualizují skladové transakce na stav 'Registered' nebo 'Received'. Zachycení Událost zaúčtování Item Arrival Journal propojeného s řádkem objednávky na vrácení. Typ události explicit | |||
| Přiřazení kódu způsobu vyřízení | Tato činnost označuje dokončení kontroly a rozhodnutí o dalším naložení s vráceným zbožím. Řádku vrácení se přiřadí kód způsobu vyřízení, například 'Credit', 'Scrap' nebo 'Replace'. | ||
| Proč je to důležité Jde o důležitý rozhodovací bod, který určuje další průběh procesu, například refundaci, výměnu nebo zamítnutí. Prodlevy v této fázi mohou výrazně prodloužit celkovou dobu vyřízení. Kde data získat Událost se zaznamená při vyplnění pole DispositionCode v transakci zásob pro řádek objednávky na vrácení nebo v souvisejícím deníku. Zachycení Událost aktualizace, při které se pro řádek objednávky na vrácení nastaví DispositionCode. Typ události explicit | |||
| Uzavření objednávky na vrácení | Objednávka na vrácení dosáhla konečného stavu. Všechny fyzické i finanční transakce jsou dokončeny. K tomu obvykle dojde po zaúčtování dobropisu nebo odeslání náhradního zboží. | ||
| Proč je to důležité Jde o hlavní koncovou událost úspěšně dokončeného procesu vrácení. Doba od vytvoření objednávky do tohoto okamžiku představuje celkovou dobu vyřízení případu. Kde data získat Událost se odvozuje od změny pole stavu ReturnOrder na konečnou hodnotu, například 'Invoiced' nebo 'Closed'. Znamená to, že se neočekává další zpracování. Zachycení Změna pole SalesTable.Status nebo SalesTable.DocumentStatus na konečný stav. Typ události inferred | |||
| Vytvoření objednávky na vrácení | Tato činnost označuje zahájení procesu vrácení, kdy se v systému vytvoří autorizace vrácení materiálu (RMA) nebo objednávka na vrácení. Jde o explicitní událost zaznamenanou při vytvoření nového záznamu ReturnOrder v Dynamics 365. | ||
| Proč je to důležité Jde o hlavní počáteční událost celého procesu vrácení. Analýza doby od této činnosti k dalším krokům ukáže celkovou dobu průchodu procesem a pomůže odhalit úzká místa v jeho počáteční fázi. Kde data získat Událost se zaznamenává podle časového razítka vytvoření hlavičky ReturnOrder. Obvykle ji najdete v tabulce SalesTable, kde má SalesType hodnotu 'Returned Order'. Zachycení Událost vytvoření záznamu SalesTable s hodnotou SalesType = 'Returned Order'. Typ události explicit | |||
| Zaúčtování dobropisu | Dobropis se oficiálně zaúčtuje do účetních knih a zákazník jej může využít. Z pohledu společnosti tím končí proces refundace. | ||
| Proč je to důležité Jde o důležitý finanční milník, který potvrzuje zpracování refundace v systému. Často slouží jako hlavní činnost pro měření dodržování SLA při refundacích. Kde data získat Časové razítko zaúčtování fakturačního deníku k objednávce na vrácení, kterým se dokončí dobropis. Stav objednávky na vrácení se změní na 'Invoiced'. Zachycení Zaúčtování fakturačního deníku objednávky na vrácení. Typ události explicit | |||
| Odeslání náhradního zboží | Zaúčtuje se dodací list náhradního zboží, což znamená, že bylo odesláno zákazníkovi. Tím končí vyřízení výměny. | ||
| Proč je to důležité Jde o důležitý milník varianty s výměnou, který potvrzuje splnění závazku společnosti vůči zákazníkovi. Je důležitý pro sledování doby vyřízení výměny. Kde data získat Datum zaúčtování deníku dodacího listu k prodejní objednávce náhradního zboží. Stav objednávky se tím změní na 'Delivered'. Zachycení Zaúčtování dodacího listu k prodejní objednávce náhradního zboží. Typ události explicit | |||
| Potvrzení objednávky na vrácení | Označuje formální potvrzení objednávky na vrácení v systému, které často spouští navazující logiku. Obvykle se zaznamenává jako explicitní akce nebo změna stavu hlavičky ReturnOrder. | ||
| Proč je to důležité Potvrzení je důležitým krokem před zahájením logistiky. Prodleva mezi vytvořením a potvrzením může ukazovat na administrativní nebo systémové nedodělky. Kde data získat Událost lze určit podle zaúčtování deníku 'Confirmation' pro objednávku na vrácení nebo podle změny pole DocumentStatus v tabulce SalesTable. Zachycení Provedení funkce 'Confirm sales order' pro objednávku na vrácení. Typ události explicit | |||
| Vytvoření dobropisu | Na základě způsobu vyřízení 'Credit' se vystaví dobropis, který opravňuje k refundaci zákazníkovi. Tím formálně začíná finanční vypořádání případu. | ||
| Proč je to důležité Tato činnost označuje schválení finanční refundace. Doba mezi určením způsobu vyřízení a vytvořením dobropisu ukazuje na administrativní prodlevy při zahájení refundace. Kde data získat Událost lze odvodit z vytvoření nového záznamu SalesTable se zápornou hodnotou, propojeného s původní objednávkou na vrácení, nebo spuštěním dávkové úlohy 'Create credit note'. Zachycení Vytvoření dobropisu, často zaúčtováním faktury k objednávce na vrácení. Typ události explicit | |||
| Vytvoření objednávky na náhradní zboží | Vytvoří se nová prodejní objednávka, podle které se zákazníkovi odešle náhradní zboží. K této činnosti dochází, když je způsob vyřízení 'Replace and Credit' nebo 'Replace and Scrap'. | ||
| Proč je to důležité Tato činnost zahajuje variantu procesu s výměnou. Samostatné sledování této cesty oproti refundaci je důležité pro pochopení náročnosti a nákladů výměn. Kde data získat Vytvoření nového záznamu SalesTable pro náhradní zboží. Záznam se často vytvoří automaticky a propojí s původní objednávkou na vrácení. Zachycení Vytvoření nové prodejní objednávky propojené s objednávkou na vrácení prostřednictvím způsobu vyřízení. Typ události explicit | |||
| Vytvoření příjmového deníku | Tato činnost znamená, že sklad očekává příjem vráceného zboží. Vytvoří se příjmový deník, který připraví systém na fyzické převzetí zboží. | ||
| Proč je to důležité Tento krok odděluje logistickou přípravu od skutečného fyzického příjmu. Pomáhá vyhodnotit připravenost skladu a plánovat příjem vráceného zboží. Kde data získat Vytvoření záznamu v WMSJournalTable s hodnotou JournalType 'Arrival'. Deník je propojen s řádkem objednávky na vrácení. Zachycení Časové razítko vytvoření záznamu WMSJournalTable pro vrácené zboží. Typ události explicit | |||
| Vytvoření příkazu ke kontrole kvality | Vytvoří se formální příkaz ke kontrole kvality, který znamená, že vrácené zboží musí projít strukturovanou kontrolou. To je běžné u vráceného zboží, které vyžaduje podrobné testování nebo ověření podle standardů kvality. | ||
| Proč je to důležité Tato činnost označuje zahájení formální kontroly. Sledováním doby od tohoto okamžiku lze měřit efektivitu a délku workflow kontroly kvality. Kde data získat Časové razítko vytvoření záznamu v InventQualityOrderTable propojeného s objednávkou na vrácení. Zachycení Vytvoření záznamu InventQualityOrderTable. Typ události explicit | |||
| Zrušení objednávky na vrácení | Objednávka na vrácení se zruší před dokončením. Důvodem může být žádost zákazníka nebo skutečnost, že zboží nebylo nikdy vráceno. | ||
| Proč je to důležité Jde o alternativní, neúspěšné ukončení procesu. Analýza důvodů zrušení vrácení může přinést poznatky o chování zákazníků nebo nedostatcích procesu. Kde data získat Událost se odvozuje od změny pole stavu ReturnOrder na 'Cancelled'. Jde o samostatný konečný stav, odlišný od úspěšně uzavřené objednávky. Zachycení Změna pole SalesTable.Status na 'Cancelled'. Typ události inferred | |||
Návody k extrakci
Kroky
- Předpoklad: Zaregistrujte aplikaci v Azure Active Directory. Než se připojíte k API Dynamics 365, zaregistrujte aplikaci ve svém tenantovi Azure AD. Udělte jí delegovaná oprávnění pro přístup k Dynamics 365 Finance & Operations, například
Financials.ReadWrite.Allnebo vlastní oprávnění. - Nastavte ID aplikace v Dynamics 365. V Dynamics 365 přejděte do System administration > Setup > Azure Active Directory applications. Přidejte ID aplikace (klienta) z registrace aplikace v Azure AD a přiřaďte ji k uživatelskému účtu s potřebnými bezpečnostními rolemi pro čtení požadovaných datových entit.
- Získejte přístupový token OAuth 2.0. Napište skript, například v PowerShellu nebo Pythonu, který se ověří vůči koncovému bodu platformy Microsoft identity. Pomocí přihlašovacích údajů aplikace (ID klienta a tajného klíče) požádejte o přístupový token pro URL prostředku Dynamics 365.
- Zjistěte URL svého prostředí Dynamics 365. Najděte základní URL prostředí Dynamics 365. Koncový bod Web API obvykle vypadá takto:
https://[YourD365FinanceAndOpsURL].dynamics.com/data. - Sestavte a spusťte požadavky OData API. Pro každou z 12 požadovaných aktivit sestavte konkrétní URL požadavku OData GET. Pomocí
$selectnačtěte pouze požadované sloupce a pomocí$filterurčete časové období a případné podmínky stavu. Token získaný ve 3. kroku přidejte do autorizační hlavičky každého požadavku jako Bearer token. - Vytvořte skript pro extrakci. Napište skript, který postupně zpracuje seznam požadavků OData. Skript musí zajistit ověření, odeslat každý požadavek GET a uložit vrácená data JSON. Sledujte limity API a v případě potřeby zařaďte prodlevy.
- Zpracujte stránkování API. Dynamics 365 rozděluje rozsáhlé výsledky do stránek. Skript musí v odpovědi kontrolovat vlastnost
@odata.nextLink. Pokud je k dispozici, odešle další požadavek na uvedenou URL a načte následující stránku. Takto pokračuje, dokud senextLinkpřestane vracet. - Transformujte a spojte data. Zpracujte odpovědi JSON ze všech 12 volání API. Pro každou aktivitu vytvořte záznam ve sjednoceném formátu, který obsahuje
ReturnCaseId,ActivityName,EventTimea další atributy. Například u události „Vytvoření objednávky na vrácení“ namapujteReturnOrderNumbernaReturnCaseId, nastavteActivityNamena „Vytvoření objednávky na vrácení“ a namapujtecreatedDateTimenaEventTime. Transformované záznamy ze všech volání spojte do jednoho seznamu nebo tabulky. - Vyčistěte a sjednoťte časová razítka. Zajistěte, aby všechny hodnoty
EventTimeměly jednotný formát, nejlépe UTC ve formátuYYYY-MM-DDTHH:MM:SSZ. Podle potřeby ošetřete záznamy s chybějícími nebo neplatnými časovými razítky. - Exportujte výsledný záznam událostí. Po shromáždění a transformaci všech dat do jedné sjednocené datové sady ji exportujte do souboru CSV. Záhlaví sloupců musí odpovídat požadavkům ProcessMind:
ReturnCaseId,ActivityName,EventTime,ResponsibleUser,DispositionCodeatd. Soubor je nyní připraven k nahrání.
Konfigurace
- URL koncového bodu API: Základní URL vaší instance Dynamics 365 Finance & Operations. Má formát
https://[YourEnvironmentName].dynamics.com/data. - Aplikace Azure AD: Aplikaci je třeba zaregistrovat v Azure AD a nastavit pro ni ID klienta a tajný klíč. Potřebuje oprávnění API pro přístup k datovým entitám Dynamics 365.
- Filtrování podle časového období: V každém volání API je nutné pomocí parametru OData
$filternastavit časové období podle příslušného datového pole, napříkladcreatedDateTimenebomodifiedDateTime. Pro začátek se obvykle hodí data za poslední 3 až 6 měsíců, aby extrakce zůstala přehledná. - Filtr společnosti: Chcete-li extrahovat data pro konkrétní právní subjekt, přidejte parametr dotazu
cross-company=truea poté použijte$filterpro poledataAreaId. Například?cross-company=true&$filter=dataAreaId eq '[YourCompanyCode]'. - Nastavení stránkování: V požadavcích použijte hlavičku
Prefer: odata.maxpagesize=[value]a určete počet záznamů na stránku. Běžně se používá hodnota od1000do5000. Pomáhá to předcházet vypršení časového limitu API u rozsáhlých entit. - Omezení počtu požadavků API: Počítejte s limity ochrany služeb API Dynamics 365. Skript pro extrakci musí umět zpracovat odpovědi
429 (Too Many Requests), obvykle pomocí exponenciálního prodlužování prodlev nebo jednoduchého opakování požadavku po pauze.
Ukázkový dotaz 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 Kroky
- Povolte koncový bod TDS: Ověřte, že je v prostředí Dynamics 365 Dataverse povolen koncový bod Tabular Data Stream (TDS). Správce systému ho může zapnout v centru pro správu Power Platform v části Environment > Settings > Features.
- Zjistěte URL prostředí: Najděte URL svého prostředí. Obvykle vypadá takto:
yourorg.crm.dynamics.com. Název serveru koncového bodu TDS tvoří tato URL a port 5558, napříkladyourorg.crm.dynamics.com,5558. - Připojte se pomocí SQL klienta: Použijte SQL klienta s podporou TDS, například SQL Server Management Studio (SSMS) nebo Azure Data Studio.
- Ověřte svou totožnost: Připojte se k serveru pomocí účtu Azure Active Directory s odpovídajícími oprávněními v prostředí Dataverse, obvykle role System Administrator nebo System Customizer.
- Připravte dotaz: Zkopírujte celý SQL dotaz z části
querytohoto dokumentu do nového okna dotazu v SQL klientovi. - Nastavte parametry: Najděte v dotazu zástupné symboly. Nahraďte
'{StartDate}'a'{EndDate}'požadovaným časovým obdobím extrakce, například'2023-01-01'a'2023-12-31'. Upravte také případné zástupné hodnoty stavových kódů nebo kódů způsobu vyřízení podle konfigurace Dynamics 365. - Spusťte dotaz: Spusťte upravený dotaz nad databází Dataverse. Doba zpracování závisí na objemu dat a zvoleném časovém období.
- Zkontrolujte výsledky: Po dokončení dotazu ověřte, že vrácená datová sada obsahuje očekávané sloupce:
ReturnCaseId,ActivityName,EventTimea doporučené atributy. - Exportujte záznam událostí: Exportujte výsledky dotazu do souboru CSV. Většina SQL klientů nabízí funkci pro přímé uložení výsledků do souboru. Uložte jej v kódování UTF-8.
- Nahrajte data do ProcessMind: Exportovaný soubor CSV je připraven k nahrání do ProcessMind jako nový záznam událostí pro analýzu pomocí process mining.
Konfigurace
- Předpoklady: Potřebujete uživatelský účet s alespoň oprávněním ke čtení příslušných tabulek Dataverse (např. SalesTable, SalesLine, CustInvoiceJour). Oprávnění se obvykle spravují pomocí bezpečnostních rolí, například System Administrator, nebo vlastní role s dostatečnými oprávněními k tabulkám.
- Koncový bod TDS: V prostředí musí být povolen koncový bod TDS Dataverse. Umožňuje spouštět nad databází Dataverse přímé SQL dotazy pouze pro čtení.
- Časové období: Dotaz obsahuje zástupné symboly
'{StartDate}'a'{EndDate}'. Pro úvodní analýzu doporučujeme období 3 až 6 měsíců. Získáte reprezentativní datovou sadu a předejdete problémům s výkonem. - Filtr společnosti: Dotaz v současné podobě prohledá všechny právní subjekty (společnosti), ke kterým má uživatel přístup. Chcete-li analyzovat jednu společnost, odkomentujte a přidejte klauzuli
WHEREfiltrující poleDATAAREAIDv každé části příkazuUNION ALL, napříkladAND st.DATAAREAID = '[YourCompanyID]'. - Zástupné symboly pro vlastní logiku: Dotaz obsahuje zástupné symboly jako
[YourReplaceCode1]pro kódy způsobu vyřízení a poznámky k propojení náhradních objednávek. Nastavte je podle konkrétního procesu a konfigurace Dynamics 365. - Výkon: Přímé dotazy na koncový bod TDS mohou být u rozsáhlých datových sad pomalé. Připojení je optimalizováno pro analytické dotazy, ale složitá spojení milionů řádků mohou překročit časový limit. Doporučujeme použít přísné filtry časového období.
Ukázkový dotaz 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}'; Chcete začít?
Pomocí této šablony si usnadníte sběr dat a začnete odhalovat možnosti, jak zlepšit proces vrácení a refundace. Začněte ještě dnes a zkraťte dobu zpracování i zvyšte spokojenost zákazníků.
Omezte prodlevy při vrácení a refundacích. Optimalizujte proces ještě dnes
Zkraťte dobu zpracování o 30 % a zlepšete spokojenost zákazníků.
Platební kartu nepotřebujete. Nastavení zabere jen několik minut.