Adatsablon a visszáru- és visszatérítés-kezeléshez
Adatsablon a visszáru- és visszatérítés-kezeléshez
- Javasolt adatmezők
- Követendő folyamatlépések
- Útmutató az adatok kinyeréséhez
A visszáru- és visszatérítés-kezelés attribútumai
| Név | Leírás | ||
|---|---|---|---|
| Esemény időpontja EventTime | Az az időbélyeg, amely megadja, mikor történt egy adott tevékenység vagy esemény. | ||
| Leírás Az esemény időpontja, vagyis az időbélyeg rögzíti a tevékenység pontos dátumát és időpontját. Az eseménynapló minden tevékenységéhez tartozik időbélyeg, amely megadja az események időrendi sorrendjét. Ez az attribútum minden időalapú process mining elemzéshez szükséges. Segítségével kiszámítható a tevékenységek közötti átfutási idő, feltárhatók a várakozási idők és a szűk keresztmetszetek, mérhető az ügy teljes időtartama, valamint ellenőrizhető a szolgáltatási szintre vonatkozó megállapodások (SLA-k) betartása. Az időbélyegek pontossága közvetlenül befolyásolja a teljesítményelemzés megbízhatóságát. Miért fontos? Ez az időbélyeg szükséges az időtartam-alapú mutatók, például az átfutási és várakozási idők kiszámításához, amelyek alapvetőek a teljesítmény elemzéséhez. Hol szerezhető be? Különböző táblák létrehozási vagy módosítási dátummezőinek felel meg, például a rendelés létrehozásakor a 'SalesTable.createdDateTime', a raktári naplóknál pedig a 'WMSJournalTrans.createdDateTime' mezőnek. Példák 2023-10-26T10:00:00Z2023-10-26T14:30:15Z2023-10-27T09:05:42Z | |||
| Visszaküldési ügy azonosítója ReturnCaseId | A vásárló visszaküldési és visszatérítési ügyének egyedi azonosítója, amely összekapcsolja a kapcsolódó tevékenységeket. | ||
| Leírás A visszaküldési ügy azonosítója minden egyes visszaküldési folyamat egyedi azonosítója. Összekapcsolja az adott vásárló visszaküldéséhez vagy visszatérítési kérelméhez tartozó összes tevékenységet, a visszaküldési rendelés létrehozásától a végleges lezárásig. A folyamatelemzés során ez az azonosító teszi lehetővé az egyes visszaküldések teljes útjának rekonstruálását. Segítségével nyomon követhető a teljes életciklus, mérhető a teljes átfutási idő, és összehasonlíthatók az egyes ügyek eltérései. Az események, adatok és mutatók mind ehhez az azonosítóhoz kapcsolódnak. Miért fontos? Ez az ügy egyedi azonosítója, amely összekapcsolja a folyamat összes lépését, így minden visszaküldés az elejétől a végéig nyomon követhető és elemezhető. Hol szerezhető be? Ez általában a Return Material Authorization (RMA) száma vagy a 'Sales and marketing' modul 'Returned Order' típusú értékesítési rendelésének száma. A SalesTable táblában található, ahol a SalesType értéke 'Returned Order'. Példák RMA-001234RMA-001235RMA-001236 | |||
| Tevékenység neve ActivityName | A visszaküldési és visszatérítési folyamatban végrehajtott konkrét üzleti esemény vagy feladat neve. | ||
| Leírás Ez az attribútum a visszaküldési és visszatérítési folyamat egy konkrét lépését vagy eseményét írja le, például: 'Visszaküldési rendelés létrehozva', 'Termék átvéve' vagy 'Jóváíró bizonylat könyvelve'. Minden tevékenység a rendszerben rögzített, önálló folyamatlépést jelöl. A tevékenységek sorrendjének és gyakoriságának elemzése a process mining alapja. Segítségével megjeleníthetők a folyamatok térképei, feltárhatók a lépések közötti szűk keresztmetszetek, és azonosíthatók a gyakori, illetve ritka folyamatváltozatok. A tevékenységek összessége határozza meg az elemzett folyamat körét. Miért fontos? Meghatározza a folyamat lépéseit, így megjeleníthető a folyamat menete, és feltárhatók a szűk keresztmetszetek, az újramunkálás és az eltérések. Hol szerezhető be? Ez egy rendszereseményekből származtatott fogalmi attribútum. A SalesTable és a WMSJournalTable táblák állapotváltozásainak vagy konkrét eseménynaplóknak a felhasználóbarát nevekre történő leképezésével hozható létre. Példák Visszaküldési rendelés létrehozvaTermék átvéveRendelkezési kód megadvaJóváíró bizonylat könyvelve | |||
| Felelős felhasználó ResponsibleUser | Az a felhasználó vagy alkalmazott, aki végrehajtott egy adott tevékenységet, vagy aki azért felel. | ||
| Leírás Ez az attribútum azonosítja a folyamatlépés végrehajtásáért felelős személyt. Lehet például a terméket átvevő raktári dolgozó, a minőségellenőr vagy a jóváíró bizonylatot könyvelő pénzügyi ügyintéző. A felhasználók szerinti elemzés segít megérteni a munkaterhelés eloszlását, azonosítani a kiemelkedő teljesítményt nyújtókat és feltárni a képzési igényeket. Arra is használható, hogy megvizsgálja az egyes személyek vagy csapatok által kezelt ügyeket, és ellenőrizze a feladatkörök megfelelő elkülönítését. Miért fontos? Lehetővé teszi a munkaterhelés, az egyéni és csapatteljesítmény elemzését, valamint a képzési és erőforrás-elosztási lehetőségek feltárását. Hol szerezhető be? A tranzakciós rekordok 'created by' vagy 'modified by' mezőiben található, például a 'SalesTable.createdBy' mezőben vagy a naplótáblákhoz kapcsolódó felhasználói azonosítók között. Példák Alice.WBob.JChris.P | |||
| Rendelkezési kód DispositionCode | A termékellenőrzés eredményét és a következő teendőt jelölő kód. | ||
| Leírás A rendelkezési kódot a visszaküldött termék minőségellenőrzése során adják meg. Meghatározza a folyamat következő lépését, például 'Credit', 'Replace', 'Scrap' vagy 'Return to Customer'. Ez az attribútum fontos döntési pont a visszaküldési folyamatban. A rendelkezési kódok szerinti elemzés megmutatja a visszaküldések kimenetelét, a termékek selejtezésének pénzügyi hatását, valamint az egyes megoldási útvonalak, például a csere és a visszatérítés hatékonyságát. Miért fontos? Ez a kód határozza meg, milyen útvonalon halad tovább a visszáru az ellenőrzés után. Ezért fontos a folyamatváltozatok és azok üzleti eredményeinek elemzéséhez. Hol szerezhető be? Ez a minőségirányítási modul egyik fontos mezője. A Quality Order vagy Inspection Order feldolgozásához kapcsolódik. Példák CRDTREPL-DSCRAPRTV | |||
| Termékazonosító ProductId | A visszaküldött termék egyedi azonosítója. | ||
| Leírás A Product ID, gyakran a Stock Keeping Unit (SKU), azonosítja a vásárló által visszaküldött konkrét terméket. Minden visszaküldési rendelési sorhoz tartozik Product ID. A termékenkénti visszaküldések elemzésével azonosíthatók a gyakran visszaküldött termékek. Ennek oka lehet minőség-ellenőrzési probléma, pontatlan termékleírás vagy gyártási hiba. Az elemzés segít rangsorolni a termékekkel kapcsolatos vizsgálatokat és fejlesztéseket. Miért fontos? Termékenként elemzi a visszaküldéseket, így azonosíthatók a minőségi problémás vagy gyakran visszaküldött termékek. Hol szerezhető be? A visszaküldési rendelés „SalesLine” táblájának „ItemId” mezőjének felel meg. Példák SKU-A-123SKU-B-456SKU-C-789 | |||
| Visszaküldési csatorna ReturnChannel | Az a mód vagy csatorna, amelyen keresztül a vásárló elindította a visszaküldést. | ||
| Leírás Ez az attribútum azt jelzi, melyik csatornán indította el a vásárló a visszaküldést, például „Online portál”, „Üzletben”, „Ügyfélszolgálati hívás” vagy „Postai úton”. A visszaküldési csatorna szerinti elemzés segít összehasonlítani az egyes csatornák teljesítményét és hatékonyságát. A vállalat összevetheti a ciklusidőket, a költségeket és a vásárlói elégedettséget, így azonosíthatja a bevált gyakorlatokat és a fejlesztendő területeket. Ez az adat a „Return Channel Utilization Performance” dashboard alapja. Miért fontos? Lehetővé teszi a különböző visszaküldési csatornák teljesítményének összehasonlítását, így kiválaszthatók a leghatékonyabb és legköltségkímélőbb csatornák. Hol szerezhető be? Ez az adat a visszaküldési rendelés fejlécében („SalesTable”) lehet, vagy a rendelést létrehozó felhasználó alapján származtatható. Előfordulhat, hogy egyedi logikára vagy külön mezőre van szükség. Példák Webes portálÜzleti kioszkÜgyfélszolgálat | |||
| Visszaküldési ok kódja ReturnReasonCode | A vásárló által megadott ok, amiért visszaküldi a terméket. | ||
| Leírás A Return Reason Code rögzíti a vásárló által megadott visszaküldési okot, például: „Hibás termék”, „Nem megfelelő méret”, „Nem felel meg a leírásnak” vagy „Már nincs rá szükség”. Ezt az adatot általában a visszaküldés elindításakor veszik fel. A visszaküldési okok elemzése segít feltárni a problémák kiváltó okait. A vállalat így azonosíthatja a termékminőségi gondokat, a pontatlan termékleírásokat és a logisztikai hibákat. Az adatok alapján fejleszthető a terméktervezés, a marketing és az ellátási lánc működése, így csökkenthető a jövőbeni visszaküldések száma. Miért fontos? Megmutatja, miért küldik vissza a termékeket. Az okok feltárásával csökkenthető a visszaküldések aránya és javítható a vásárlói elégedettség. Hol szerezhető be? Ez az adat általában a visszaküldési rendelés sorában található. A visszaküldési rendelésekhez tartozó okkódmezőket a „SalesLine” táblában keresse. Példák DEFECTWRONG_ITEMNO_LONGER_WANTEDDAMAGED_IN_TRANSIT | |||
| Befejezés időpontja EndTime | Az az időbélyeg, amely megadja, mikor fejeződött be egy adott tevékenység. | ||
| Leírás A befejezés időpontja a tevékenység lezárásának időbélyege. A StartTime a kezdetet, az EndTime pedig a befejezést jelöli, így kiszámítható az adott feladat feldolgozási ideje. Ez az attribútum különösen fontos a részletes teljesítményelemzéshez, főként a mérhető időtartamú feladatoknál, például a 'Termék ellenőrzése' tevékenységnél. A StartTime és az EndTime összevetésével pontosan mérhető a feladat tényleges feldolgozási ideje, és elkülöníthető a feladatok közötti várakozástól. Így az egyes tevékenységeken belüli hatékonysági problémák is feltárhatók, nem csak a lépések közötti késedelmek. Miért fontos? Segítségével kiszámítható az egyes tevékenységek tényleges feldolgozási ideje, és elkülöníthető a várakozás a tényleges munkavégzéstől. Hol szerezhető be? Ezt az értéket gyakran származtatni kell. Például lehet egy tevékenységet lezáró állapotváltozás 'modifiedDateTime' értéke, vagy a következő tevékenység StartTime értéke. Példák 2023-10-26T10:15:00Z2023-10-26T14:45:20Z2023-10-27T09:55:12Z | |||
| Forrásrendszer SourceSystem | Az az informatikai rendszer, amelyből az eseményadatokat kinyerték. | ||
| Leírás Ez az attribútum azonosítja azt a forrásrendszert, ahonnan az adatok származnak. Ebben az esetben ez jellemzően a 'Microsoft Dynamics 365'. Nagyobb szervezeteknél egy folyamat több rendszeren is áthaladhat. Az események forrásrendszerének megadása fontos az adatirányítás, az adatkinyerési problémák elhárítása és a folyamatot támogató rendszerek megértése szempontjából. Megerősíti az elemzett adatok eredetét. Miért fontos? Fontos információt ad az adatok eredetéről, ami szükséges az adatirányításhoz, az ellenőrzéshez és a folyamatot támogató rendszerek megértéséhez. Hol szerezhető be? Ez általában az adatkinyerés, -átalakítás és -betöltés (ETL) során hozzáadott állandó érték, amely az adatkészlet forrását jelöli. Példák Microsoft Dynamics 365 F&OD365-PROD | |||
| Igényelt visszatérítési összeg RequestedRefundAmount | A vásárló által igényelt visszatérítés teljes összege. | ||
| Leírás Ez az attribútum a visszaküldési folyamat kezdetén igényelt vagy várható visszatérítés összegét jelöli. Az összeg általában a visszaküldött termékek eredeti vételárán alapul. Ez az érték szolgál viszonyítási alapként a „Refund Amount Discrepancy Analysis” elemzéshez. Az igényelt és a ténylegesen visszatérített összeg összevetésével feltárhatók az eltérések, például a készlet-visszavételezési díjak, a sérült termékek utáni részleges visszatérítések vagy más korrekciók. Így ellenőrizhető a pénzügyi pontosság és a szabályzat betartása. Miért fontos? A tényleges visszatérítési összeggel összevetve viszonyítási alapot ad a pénzügyi pontosság méréséhez. Hol szerezhető be? Ez általában a visszaküldött tétel eredeti értékesítési rendelési sorának sorösszege vagy teljes összege, amely a „SalesLine.LineAmount” mezőben található. Példák 99.99150.0024.50 | |||
| Jóváíró számla azonosítója CreditNoteId | A visszatérítéshez létrehozott jóváíró számla egyedi azonosítója. | ||
| Leírás A visszatérítés feldolgozásakor jóváíró számla vagy jóváíró bizonylat készül. Ez az attribútum tárolja a dokumentum egyedi azonosítóját. Az azonosító közvetlen kapcsolatot teremt a visszaküldési folyamat és a könyvelési rendszer pénzügyi nyilvántartásai között. Auditáláskor és a pénzügyi eltérések részletes vizsgálatakor is hasznos: segítségével az elemző egészen az ügyet lezáró pénzügyi tranzakcióig követheti a visszaküldést. Miért fontos? Összekapcsolja a visszaküldési folyamatot a hozzá tartozó pénzügyi tranzakcióval, ami fontos az auditáláshoz és a pénzügyi egyeztetéshez. Hol szerezhető be? A jóváíró számla száma általában a „CustInvoiceJour” tábla „InvoiceId” mezőjében található, ahol a tranzakció típusa „Credit note”. Ez az adat összekapcsolható a visszaküldési rendeléssel. Példák CN-10056CN-10057CN-10058 | |||
| Megfelel a szabályzatnak IsPolicyAdherent | Jelzi, hogy a visszaküldés jóváhagyása megfelel-e a meghatározott visszaküldési szabályzatnak. | ||
| Leírás Ez a számított logikai attribútum jelzi, hogy a visszaküldés megfelel-e a vállalat visszaküldési szabályzatában meghatározott összes feltételnek. Az érték olyan tényezőktől függhet, mint a visszaküldési határidő, a termék állapota vagy a visszaküldés oka. Ez az attribútum közvetlenül támogatja a „Return Approval Compliance Overview” dashboardot és a „Compliant Return Approval Rate” KPI-t. Segítségével mérhető a szabályzat betartása, azonosíthatók a kivételként jóváhagyott ügyek, és elemezhetők a kivételek okai, illetve gyakorisága. Ez fontos az irányítás és a költségek ellenőrzése szempontjából. Miért fontos? Közvetlenül méri az üzleti szabályok betartását. Segít azonosítani és csökkenteni a szabályzatnak nem megfelelő jóváhagyásokat, amelyek bevételkiesést okozhatnak. Hol szerezhető be? Ez származtatott attribútum. Kiszámításához a visszaküldés adatait, például a visszaküldés és a vásárlás dátumát, valamint a visszaküldés okát kell összevetni az előre meghatározott üzleti szabályokkal. Példák truefalse | |||
| Raktárazonosító WarehouseId | Annak a raktárnak vagy telephelynek az azonosítója, ahová a visszaküldött termék érkezik. | ||
| Leírás Ez az attribútum azonosítja azt a fizikai raktárat vagy visszáru-központot, ahol a visszaküldött terméket feldolgozzák. Az egyes helyszíneken eltérhetnek a folyamatok, az erőforrások és a teljesítményszintek. A raktárankénti elemzés lehetővé teszi a helyszínek teljesítményének összehasonlítását. Segít megállapítani, mely telephelyek dolgozzák fel a leghatékonyabban a visszaküldéseket, feltárni a regionális szűk keresztmetszeteket, és megalapozni az erőforrások elosztásáról, valamint a logisztikai hálózat folyamatainak egységesítéséről szóló döntéseket. Miért fontos? Lehetővé teszi a raktárak és visszáru-központok teljesítményének összehasonlítását, így feltárhatók a regionális szűk keresztmetszetek és a bevált gyakorlatok. Hol szerezhető be? Ez az adat a készletmozgásokhoz kapcsolódó tranzakciók „InventLocationId” mezőjében található, például az érkezési naplóban („WMSJournalTable”) vagy a „SalesLine” táblában. Példák WH-EASTWH-WESTCENTRAL-DC | |||
| SLA-állapot SlaStatus | Jelzi, hogy az ügyet az SLA-ban meghatározott határidőn belül rendezték-e. | ||
| Leírás Ez a számított attribútum egyszerűen jelzi, hogy az SLA teljesült-e, jellemzően „Határidőre” vagy „Késve” értékkel. Az érték a végső tevékenység, például a „Return Order Closed” időbélyegének és a „RefundSlaTargetDate” értékének összevetésével állapítható meg. Az attribútum egyszerűsíti a teljesítmény riportolását az olyan dashboardokon, mint a „Refund Resolution SLA Performance”. A dátumok összehasonlítása helyett közvetlenül, könnyen értelmezhető állapotot mutat. Így gyorsan szűrhetők és összesíthetők az ügyek a „Resolution SLA Adherence Rate” kiszámításához. Miért fontos? Egy pillantással jelzi, hogy teljesült-e az SLA. Könnyű vele kiszűrni a késedelmes ügyeket és elemezni a csúszások kiváltó okait. Hol szerezhető be? Ez származtatott attribútum, amelyet a végső rendezési tevékenység időbélyegének és a „RefundSlaTargetDate” attribútumnak az összevetésével számítanak ki. Példák HatáridőreKésve | |||
| Tényleges visszatérítési összeg ActualRefundAmount | A vásárlónak ténylegesen visszatérített végleges összeg. | ||
| Leírás Ez az attribútum a vásárlónak visszatérített, végleges és jóváhagyott összeget jelöli. Az értéket a jóváíró számla létrehozásakor és könyvelésekor rögzítik. Ez az adat fontos a pénzügyi elemzéshez, és közvetlenül felhasználható a „Refund Amount Discrepancy Analysis” dashboardon, valamint a „Refund Amount Accuracy Rate” KPI számításához. Elemzésével felmérhető a visszaküldések pénzügyi hatása és a folyamat során végrehajtott korrekciók. Miért fontos? A visszaküldés tényleges pénzügyi hatását mutatja. Ebből számítható ki a visszatérítések pontossága, és megérthetők a pénzügyi eredmények. Hol szerezhető be? Ez az érték a könyvelt jóváíró számla tranzakciós adatai között található. A jóváíró számlához a „CustTrans” és a „CustInvoiceJour” tábla kapcsolódik. Példák 99.99135.000.00 | |||
| Utolsó adatfrissítés LastDataUpdate | Az az időbélyeg, amely megadja, mikor frissítették utoljára a folyamat adatait. | ||
| Leírás Ez az attribútum rögzíti, mikor nyerték ki utoljára az adatokat a forrásrendszerből, és mikor frissítették őket a process mining eszközben. Megmutatja, mennyire frissek az elemzett adatok. Az utolsó adatfrissítés időpontja segít megítélni, mennyire naprakész az elemzés. A dashboardok és KPI-ok értelmezésekor így tudható, hogy valós idejű adatokat vagy egy adott időpontban készült pillanatképet lát-e. Ez fontos a működés nyomon követéséhez. Miért fontos? Jelzi az adatok frissességét, így az elemzők tudják, mennyire aktuálisak a folyamatra vonatkozó elemzési eredmények. Hol szerezhető be? Ez egy metaadat-attribútum, amely az adatbetöltési folyamat során jön létre és tárolódik. Jellemzően az ETL-feladat befejezésének időbélyegét jelöli. Példák 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Vásárlóazonosító CustomerId | A visszaküldést kezdeményező vásárló egyedi azonosítója. | ||
| Leírás A Customer ID a visszaküldéshez kapcsolódó vásárlói fiók egyedi azonosítója. Ez köti össze a visszaküldési tranzakciót egy adott vásárlóval a CRM-ben vagy a vásárlói adatbázisban. A vásárlónkénti visszaküldések elemzésével azonosíthatók azok, akik a szokásosnál gyakrabban küldenek vissza termékeket. Ez csalásra vagy tartós elégedetlenségre utalhat. Az adatok a vásárlók csoportosítására is használhatók, például kiemelt visszaküldési szolgáltatás ajánlható a nagy értékű vásárlóknak. Miért fontos? A visszaküldési folyamatot egy adott vásárlóhoz kapcsolja, így elemezhetők a vásárlói szintű mintázatok és az esetleges csalások. Hol szerezhető be? Ez a visszaküldési rendelés „SalesTable” táblájának „CustAccount” mezője. Példák CUST-00045CUST-00192CUST-00315 | |||
| Visszaküldés típusa ReturnType | A visszaküldést a várt eredmény, például visszatérítés vagy csere alapján sorolja be. | ||
| Leírás Ez az attribútum a vásárló által kért vagy a vállalat által felajánlott megoldás szerint sorolja be a visszaküldési ügyet. A gyakori típusok közé tartozik a pénzvisszatérítés, a termék cseréje vagy a javítás. A besorolás segít a különböző folyamatútvonalak elemzésében. A visszatérítés folyamata jelentősen eltér a csereáru kiszállításától. A visszaküldés típusa szerinti csoportosítással pontosabban elemezhetők az egyes megoldási módok ciklusidejei és szűk keresztmetszetei. Miért fontos? A kívánt eredmény szerint csoportosítja az elemzést, mivel a visszatérítés és a csere folyamata, illetve ciklusideje eltér. Hol szerezhető be? Ez lehet egyedi mező a visszaküldési rendelés fejlécében, vagy származtatható a rendelkezési kódból, illetve későbbi tranzakciókból, például egy csereáruhoz tartozó értékesítési rendelés létrehozásából. Példák VisszatérítésCsereVásárlási utalvány | |||
| Visszaküldési rendelés állapota ReturnOrderStatus | A visszaküldési rendelés eseménykori általános állapota. | ||
| Leírás Ez az attribútum a visszaküldési rendelés fejlécének aktuális állapotát jelzi, például „Nyitott”, „Számlázott” vagy „Törölt”. Áttekintést ad arról, hol tart az ügy a folyamatban. A tevékenységek a folyamat részletes lépéseit mutatják, az általános állapot pedig az ügyek szűrésére és csoportosítására alkalmas. Az elemző például csak a „Nyitott” ügyekre szűrhet, hogy felmérje az aktuális munkaterhelést, vagy megvizsgálhatja a végül „Törölt” ügyek folyamatát. Miért fontos? Röviden összefoglalja az ügy állapotát. Segítségével szűrhetők az ügyek, és elemezhetők például a törléssel végződő esetek. Hol szerezhető be? Ez az adat a „SalesTable” „SalesStatus” vagy „DocumentStatus” mezőjében található. Példák Nyitott rendelésKiszállítvaSzámlázvaTörölve | |||
| Visszatérítési SLA céldátuma RefundSlaTargetDate | Az a céldátum, ameddig a visszaküldési és visszatérítési ügyet teljesen le kell zárni. | ||
| Leírás Ez az attribútum határozza meg a visszaküldési ügy rendezésére vonatkozó Service Level Agreement (SLA) határidejét. Eddigre kell a vásárlónak végleges megoldást kapnia, például könyvelt visszatérítést vagy feladott csereárut. A céldátum alapján mérhető, hogy a teljesítés megfelel-e a szolgáltatási vállalásoknak. Ezt használja a „Resolution SLA Adherence Rate” KPI számítása és a „Refund Resolution SLA Performance” dashboard. A céldátum és a folyamat tényleges befejezési dátumának összevetésével azonosíthatók az SLA-túllépések, és időben kezelhetők az elhúzódó ügyek. Miért fontos? Viszonyítási alapot ad a folyamat teljesítményének méréséhez, így nyomon követhető az SLA betartása és azonosíthatók a késedelmes ügyek. Hol szerezhető be? Lehet, hogy nincs hozzá szabványos mező. Gyakran a visszaküldés létrehozásának dátumához hozzáadott, előre meghatározott SLA-időszak alapján számítják ki, például 14 nap hozzáadásával. Egyedi mezőben is tárolható. Példák 2023-11-10T23:59:59Z2023-11-15T23:59:59Z | |||
A visszáru- és visszatérítés-kezelés tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
| Jóváíró bizonylat könyvelve | A jóváíró bizonylatot hivatalosan könyvelik a pénzügyi főkönyvekbe, így a jóváírás elérhetővé válik a vásárló számára. A vállalat szempontjából ezzel lezárul a visszatérítés. | ||
| Miért fontos? Ez fontos pénzügyi mérföldkő, amely megerősíti, hogy a visszatérítést feldolgozták a rendszerben. Gyakran ez az egyik fő tevékenység a visszatérítési SLA betartásának méréséhez. Hol szerezhető be? A visszaküldési rendelés számlanaplójának könyvelési időbélyege, amely véglegesíti a jóváíró bizonylatot. A visszaküldési rendelés állapota 'Invoiced' értékre változik. Rögzítés A visszaküldési rendelés számlanaplójának könyvelése. Eseménytípus explicit | |||
| Rendelkezési kód megadva | Ez a tevékenység az ellenőrzés végét és a visszaküldött termékkel kapcsolatos döntést jelzi. A visszaküldési rendelés sorához olyan rendelkezési kódot rendelnek, mint a 'Credit', 'Scrap' vagy 'Replace'. | ||
| Miért fontos? Ez fontos döntési pont, amely meghatározza a folyamat további útját: visszatérítés, csere vagy elutasítás következik-e. Az itt jelentkező késedelem jelentősen növelheti a teljes ügyintézési időt. Hol szerezhető be? Az esemény akkor rögzül, amikor a DispositionCode mező értéket kap a visszaküldési rendelés sorához tartozó készlettranzakcióban vagy kapcsolódó naplóban. Rögzítés A visszaküldési rendelés sorához tartozó DispositionCode beállításának frissítési eseménye. Eseménytípus explicit | |||
| Termék átvéve | A visszaküldött termék fizikai átvételét jelzi a raktárban vagy a kijelölt visszáru-központban. Akkor rögzül, amikor a visszaküldési rendeléshez tartozó beérkezési naplót könyvelik. | ||
| Miért fontos? Ez fontos mérföldkő: a folyamat a vásárlói teendőkről a belső feldolgozásra vált. Ettől az időponttól számíthatók a belső kezelési idők, például az ellenőrzés és a rendelkezésre vonatkozó döntés ideje. Hol szerezhető be? A ReturnOrder sorához tartozó WMS Journal vagy Item Arrival Journal könyvelési időbélyege. Ez a készlettranzakciók állapotát 'Registered' vagy 'Received' értékre módosítja. Rögzítés A visszaküldési rendelés sorához kapcsolódó Item Arrival Journal könyvelési eseménye. Eseménytípus explicit | |||
| Visszaküldési rendelés létrehozva | Ez a tevékenység jelzi a visszaküldési folyamat kezdetét: a rendszerben létrejön egy Return Material Authorization (RMA) vagy egy visszaküldési rendelés. A Dynamics 365 ezt az eseményt az új ReturnOrder rekord létrehozásakor rögzíti. | ||
| Miért fontos? Ez a teljes visszaküldési folyamat elsődleges kezdő eseménye. Az eseménytől a többi tevékenységig eltelt idő elemzésével meghatározható a folyamat teljes átfutási ideje, és feltárhatók a kezdeti szakasz szűk keresztmetszetei. Hol szerezhető be? Az esemény a ReturnOrder fejléc létrehozási időbélyegéből olvasható ki. Ez jellemzően a SalesTable táblában található, ahol a SalesType értéke 'Returned Order'. Rögzítés A SalesTable rekord létrehozási eseménye, ahol a SalesType = 'Returned Order'. Eseménytípus explicit | |||
| Visszaküldési rendelés lezárva | A visszaküldési rendelés elérte a végső állapotát, vagyis minden fizikai és pénzügyi tranzakció lezárult. Ez általában a jóváíró bizonylat könyvelése vagy a pótló termék feladása után történik. | ||
| Miért fontos? Ez a sikeresen lezárt visszaküldési folyamat elsődleges záró eseménye. A létrehozástól eddig eltelt idő adja az ügy teljes átfutási idejét. Hol szerezhető be? A ReturnOrder állapotmezőjének végső értékre, például 'Invoiced' vagy 'Closed' értékre változásából lehet következtetni rá. Ez azt jelzi, hogy nincs szükség további feldolgozásra. Rögzítés A SalesTable.Status vagy SalesTable.DocumentStatus mező végső állapotra változása. Eseménytípus inferred | |||
| Beérkezési napló létrehozva | Ez a tevékenység jelzi, hogy a raktár számít a visszaküldött termék beérkezésére. A beérkezési napló létrehozásával a rendszer felkészül az áru fizikai átvételére. | ||
| Miért fontos? Ez a lépés elválasztja a logisztikai előkészítést a termék tényleges átvételétől. Segít felmérni a raktár felkészültségét és megtervezni a visszaküldött termékek fogadását. Hol szerezhető be? A WMSJournalTable táblában létrejön egy 'Arrival' JournalType értékű rekord. A napló a visszaküldési rendelés sorához kapcsolódik. Rögzítés A visszaküldéshez tartozó WMSJournalTable rekord létrehozási időbélyege. Eseménytípus explicit | |||
| Jóváíró bizonylat létrehozva | 'Credit' rendelkezési döntés esetén jóváíró bizonylat készül, amely engedélyezi a vásárló visszatérítését. Ezzel kezdődik a folyamat pénzügyi elszámolási szakasza. | ||
| Miért fontos? Ez a tevékenység jelzi a pénzügyi visszatérítés jóváhagyását. A rendelkezési döntés és a jóváíró bizonylat létrehozása között eltelt idő megmutatja a visszatérítés elindításának adminisztratív késedelmét. Hol szerezhető be? Az eseményre az eredeti visszaküldési rendeléshez kapcsolódó, negatív értékű új SalesTable rekord létrejöttéből lehet következtetni, vagy a 'Create credit note' kötegelt feladat futtatásából. Rögzítés Jóváíró bizonylat létrehozása, gyakran a visszaküldési rendelés számlájának könyvelésével. Eseménytípus explicit | |||
| Minőségellenőrzési rendelés létrehozva | Létrejön a hivatalos minőségellenőrzési rendelés, amely jelzi, hogy a visszaküldött terméket szabályozott ellenőrzésnek kell alávetni. Ez gyakori, ha a visszaküldött terméket részletesen meg kell vizsgálni, vagy minőségi előírások szerint kell ellenőrizni. | ||
| Miért fontos? Ez a tevékenység jelzi a hivatalos ellenőrzési folyamat kezdetét. Az ettől az időponttól eltelt idő mérésével felmérhető a minőségbiztosítási munkafolyamat hatékonysága és időtartama. Hol szerezhető be? A visszaküldési rendeléshez kapcsolódó InventQualityOrderTable rekord létrehozási időbélyege. Rögzítés InventQualityOrderTable rekord létrehozása. Eseménytípus explicit | |||
| Pótló rendelés létrehozva | Új értékesítési rendelés jön létre, hogy pótló terméket küldjenek a vásárlónak. Erre akkor kerül sor, ha a rendelkezési művelet értéke 'Replace and Credit' vagy 'Replace and Scrap'. | ||
| Miért fontos? Ez a tevékenység elindítja a cserefolyamatot. A visszatérítési útvonaltól elkülönítve kell követni, hogy megérthetők legyenek a cserefolyamatok sajátosságai és költségei. Hol szerezhető be? Új SalesTable rekord jön létre a pótló termékhez. A rekord gyakran automatikusan készül, és az eredeti visszaküldési rendeléshez kapcsolódik. Rögzítés Új értékesítési rendelés létrehozása, amely a rendelkezési műveleten keresztül kapcsolódik a visszaküldési rendeléshez. Eseménytípus explicit | |||
| Pótló termék feladva | A pótló termék csomagjegyzékét könyvelik, ami jelzi, hogy a terméket feladták a vásárlónak. Ezzel lezárul a csere teljesítése. | ||
| Miért fontos? Ez fontos mérföldkő a cserefolyamatban, mert jelzi, hogy a vállalat teljesítette a vásárlóval szembeni kötelezettségét. A cserefolyamat átfutási idejének méréséhez is szükséges. Hol szerezhető be? A pótló termék értékesítési rendeléséhez tartozó csomagjegyzék-napló könyvelési dátuma. A rendelés állapota 'Delivered' értékre változik. Rögzítés A pótló termék értékesítési rendeléséhez tartozó csomagjegyzék könyvelése. Eseménytípus explicit | |||
| Visszaküldési rendelés megerősítve | A visszaküldési rendelés rendszerbeli hivatalos megerősítését jelzi, amely gyakran elindítja a további műveleteket. Ez általában a ReturnOrder fejlécen rögzített műveletként vagy állapotváltozásként jelenik meg. | ||
| Miért fontos? A megerősítés a logisztikai folyamat megkezdésének feltétele. A létrehozás és a megerősítés közötti késedelem adminisztratív vagy rendszerbeli torlódásra utalhat. Hol szerezhető be? Az esemény a visszaküldési rendelés 'Confirmation' naplóbejegyzéséből vagy a SalesTable DocumentStatus mezőjének változásából azonosítható. Rögzítés A visszaküldési rendeléshez tartozó 'Confirm sales order' funkció végrehajtása. Eseménytípus explicit | |||
| Visszaküldési rendelés törölve | A visszaküldési rendelést a folyamat befejezése előtt törlik. Ennek oka lehet a vásárló kérése, vagy az, hogy a terméket végül nem küldték vissza. | ||
| Miért fontos? Ez a folyamat sikertelen, alternatív lezárását jelzi. A törlés okainak elemzése betekintést adhat a vásárlói viselkedésbe vagy a folyamat hibáiba. Hol szerezhető be? A ReturnOrder állapotmezőjének 'Cancelled' értékre változásából lehet következtetni rá. Ez eltér a sikeresen lezárt rendelés végállapotától. Rögzítés A SalesTable.Status mező 'Cancelled' értékre változása. Eseménytípus inferred | |||
Útmutatók az adatok kinyeréséhez
Lépések
- Előfeltétel: regisztráljon alkalmazást az Azure Active Directoryban. Mielőtt csatlakozna a Dynamics 365 API-hoz, regisztrálnia kell egy alkalmazást az Azure AD-bérlőjében. Adjon az alkalmazásnak delegált jogosultságot a Dynamics 365 Finance & Operations eléréséhez, például
Financials.ReadWrite.Allvagy egy egyéni jogosultságot. - Állítsa be az alkalmazásazonosítót a Dynamics 365-ben. A Dynamics 365-ben lépjen a System administration > Setup > Azure Active Directory applications menüpontra. Adja hozzá az Azure AD-ben regisztrált alkalmazás Application (client) ID azonosítóját, majd rendelje hozzá egy olyan felhasználói fiókhoz, amely rendelkezik a szükséges biztonsági szerepkörökkel az adatok olvasásához.
- Szerezzen OAuth 2.0 hozzáférési tokent. Írjon például PowerShell- vagy Python-szkriptet a Microsoft identity platform végpontjához való hitelesítéshez. Az alkalmazás hitelesítő adataival, a client ID és a secret használatával kérjen hozzáférési tokent a Dynamics 365 erőforrás-URL-jéhez.
- Keresse meg a Dynamics 365-környezet URL-jét. Keresse meg a Dynamics 365-környezet alap-URL-jét. A Web API-végpont általában így néz ki:
https://[YourD365FinanceAndOpsURL].dynamics.com/data. - Állítsa össze és futtassa az OData API-kéréseket. A 12 szükséges tevékenység mindegyikéhez állítson össze egy külön OData GET-kérés URL-jét. A
$selectparaméterrel csak a szükséges oszlopokat kérje le, a$filterparaméterrel pedig adja meg az időszakot és az esetleges állapotfeltételeket. A 3. lépésben kapott hitelesítési tokent minden kérés engedélyezési fejlécében Bearer tokenként kell megadni. - Készítsen adatkinyerő szkriptet. Írjon szkriptet, amely végigmegy az OData-kérések listáján. A szkript kezelje a hitelesítést, hajtsa végre az egyes GET-kéréseket, és mentse az eredményül kapott JSON-adatokat. Vegye figyelembe az API korlátait, és szükség esetén iktasson be szüneteket.
- Kezelje az API lapozását. A Dynamics 365 nagy adathalmazok esetén lapozza az eredményeket. A szkript ellenőrizze, hogy a válasz tartalmazza-e az
@odata.nextLinktulajdonságot. Ha igen, kérje le a következő adatok oldalát az adott URL-ről, és folytassa ezt addig, amíg már nem érkeziknextLink. - Alakítsa át és egyesítse az adatokat. Dolgozza fel mind a 12 API-hívás JSON-válaszát. Minden tevékenységhez hozzon létre egységes rekordot, amely tartalmazza a
ReturnCaseId,ActivityName,EventTimeés további attribútumokat. A 'Return Order Created' eseménynél például rendelje aReturnOrderNumberértékét aReturnCaseIdmezőhöz, állítsa azActivityNameértékét 'Return Order Created'-re, acreatedDateTimeértékét pedig rendelje azEventTimemezőhöz. Egyesítse az átalakított rekordokat egyetlen listába vagy táblázatba. - Tisztítsa és egységesítse az időbélyegeket. Gondoskodjon róla, hogy minden
EventTimeérték azonos formátumú legyen, lehetőleg UTC-időzónában, példáulYYYY-MM-DDTHH:MM:SSZformátumban. Kezelje a hiányzó vagy érvénytelen időbélyegű rekordokat is. - Exportálja a végleges eseménynaplót. Miután az összes adatot összegyűjtötte és egységes adathalmazzá alakította, exportálja CSV-fájlba. Az oszlopfejlécek feleljenek meg a ProcessMind követelményeinek:
ReturnCaseId,ActivityName,EventTime,ResponsibleUser,DispositionCodestb. A fájl ezután feltölthető.
Konfiguráció
- API-végpont URL-je: A Dynamics 365 Finance & Operations-példány alap-URL-je. Formátuma:
https://[YourEnvironmentName].dynamics.com/data. - Azure AD-alkalmazás: Regisztráljon egy alkalmazást az Azure AD-ben, és állítson be hozzá client ID-t és secretet. Az alkalmazásnak API-jogosultságokra van szüksége a Dynamics 365-adatentitások eléréséhez.
- Dátumtartomány szűrése: Minden API-hívásnál kötelező dátumtartományt megadni az OData
$filterparaméterével, egy releváns dátummező, például acreatedDateTimevagy amodifiedDateTimealapján. Kiindulásként érdemes az elmúlt 3–6 hónap adatait lekérni, hogy az adatmennyiség kezelhető maradjon. - Vállalati szűrő: Ha egy adott jogi személy adatait szeretné kinyerni, adja hozzá a
cross-company=truelekérdezési paramétert, majd szűrjön adataAreaIdmezőre a$filterhasználatával. Például:?cross-company=true&$filter=dataAreaId eq '[YourCompanyCode]'. - Lapozási beállítás: A kérésben a
Prefer: odata.maxpagesize=[value]fejléc segítségével szabályozhatja az oldalanként visszaadott rekordok számát. Gyakori érték az1000–5000. Ezzel csökkentheti a nagy adatentitások lekérésekor fellépő API-időtúllépések kockázatát. - API-korlátozás: Vegye figyelembe a Dynamics 365 API szolgáltatásvédelmi korlátait. Az adatkinyerő szkript kezelje a
429 (Too Many Requests)válaszokat, például exponenciális várakozással vagy egyszerű szüneteltetéssel és újrapróbálkozással.
Példa-lekérdezés 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 Lépések
- A TDS-végpont engedélyezése: Ellenőrizze, hogy a Tabular Data Stream (TDS) végpont engedélyezve van-e a Dynamics 365 Dataverse-környezetben. Ezt a rendszergazda a Power Platform admin centerben engedélyezheti az Environment > Settings > Features menüpontban.
- A környezet URL-jének megkeresése: Keresse meg a környezet URL-jét. Általában ilyen formátumú:
yourorg.crm.dynamics.com. A TDS-végpont kiszolgálóneve ugyanez az URL az 5558-as porttal, példáulyourorg.crm.dynamics.com,5558. - Csatlakozás SQL-klienssel: Használjon TDS-t támogató SQL-klienst, például SQL Server Management Studio (SSMS) vagy Azure Data Studio alkalmazást.
- Hitelesítés: A Dataverse-környezetben megfelelő jogosultságokkal rendelkező Azure Active Directory-fiókjával csatlakozzon a kiszolgálóhoz. Ez általában System Administrator vagy System Customizer szerepkört jelent.
- A lekérdezés előkészítése: Másolja a dokumentum
queryszakaszában található teljes SQL-lekérdezést az SQL-kliens új lekérdezési ablakába. - Paraméterek beállítása: Keresse meg a lekérdezésben a helyőrzőket. Cserélje le a
'{StartDate}'és'{EndDate}'értékeket a kívánt adatkinyerési időszakra, például'2023-01-01'és'2023-12-31'értékre. A helyőrző státusz- és rendelkezési kódokat is igazítsa a Dynamics 365 saját beállításaihoz. - A lekérdezés futtatása: Futtassa a módosított lekérdezést a Dataverse-adatbázison. A futási idő az adatmennyiségtől és a kiválasztott időszaktól függ.
- Az eredmények ellenőrzése: A lekérdezés lefutása után ellenőrizze, hogy az eredményhalmaz tartalmazza-e a várt oszlopokat:
ReturnCaseId,ActivityName,EventTimeés az ajánlott attribútumok. - Az eseménynapló exportálása: Exportálja a lekérdezés eredményét CSV-fájlba. A legtöbb SQL-kliens beépített funkcióval menti fájlba az eredményeket. UTF-8 kódolást használjon.
- Feltöltés a ProcessMindba: Az exportált CSV-fájl feltölthető a ProcessMindba új eseménynaplóként, és felhasználható a folyamat process mining elemzéséhez.
Konfiguráció
- Előfeltételek: Olyan felhasználói fiókra van szüksége, amely legalább olvasási hozzáféréssel rendelkezik a releváns Dataverse-táblákhoz, például a SalesTable, SalesLine és CustInvoiceJour táblákhoz. A jogosultságokat általában biztonsági szerepkörök, például System Administrator vagy megfelelő táblajogosultságokkal rendelkező egyéni szerepkörök kezelik.
- TDS-végpont: A Dataverse TDS-végpontot engedélyezni kell a környezetben. Ezzel közvetlen, csak olvasási SQL-lekérdezéseket futtathat a Dataverse-adatbázison.
- Dátumtartomány: A lekérdezés a
'{StartDate}'és'{EndDate}'helyőrzőket tartalmazza. Az első elemzéshez 3–6 hónapos időszakot javaslunk. Ez reprezentatív adathalmazt ad anélkül, hogy teljesítményproblémát okozna. - Vállalati szűrő: A lekérdezés alapértelmezés szerint minden olyan jogi személyre (vállalatra) lefut, amelyhez a felhasználónak hozzáférése van. Ha egyetlen vállalatot szeretne elemezni, vegye ki a megjegyzésből a
UNION ALLutasítás minden részében aDATAAREAIDmezőre szűrőWHEREfeltételt, és adja meg a vállalat azonosítóját. Például:AND st.DATAAREAID = '[YourCompanyID]'. - Egyéni logika helyőrzői: A lekérdezés olyan helyőrzőket tartalmaz, mint a rendelkezési kódokhoz használt
[YourReplaceCode1], valamint a csere-megrendelések összekapcsolására vonatkozó megjegyzéseket. Ezeket a saját üzleti folyamata és Dynamics 365-beállítása szerint kell megadni. - Teljesítmény: Nagy adathalmazok közvetlen lekérdezése a TDS-végponton lassú lehet. A kapcsolat elemzési lekérdezésekre van optimalizálva, de a több millió sort érintő összetett összekapcsolások időtúllépést okozhatnak. Javasoljuk, hogy szűk dátumtartományt használjon.
Példa-lekérdezés 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}'; Készen áll a kezdésre?
Használja ezt a sablont az adatgyűjtés egyszerűsítéséhez, és tárja fel, hogyan fejlesztheti a visszáru- és visszatérítés-kezelést. Kezdje el még ma, hogy gyorsabbá tegye az ügyintézést és növelje az ügyfelek elégedettségét.
Szüntesse meg a visszáru- és visszatérítési késéseket, fejlessze a folyamatot még ma
Csökkentse 30%-kal az átfutási időt, és javítsa az ügyfelek elégedettségét.
Nincs szükség bankkártyára. A beállítás csak néhány percet vesz igénybe.