> Průběžné zlepšování procesů > Správa úvěrů a vymáhání pohledávek > Microsoft Dynamics 365 > Datová šablona

Datová šablona pro správu úvěrů a vymáhání pohledávek

Microsoft Dynamics 365

Atributy správy úvěrů a vymáhání pohledávek(19) Aktivity správy úvěrů a vymáhání pohledávek(12) Návody k extrakci dat(2)

Datová šablona pro správu úvěrů a vymáhání pohledávek

Tato šablona vám pomůže shromáždit data potřebná k analýze procesu správy úvěrů a vymáhání pohledávek. Obsahuje přehled důležitých datových atributů, aktivit, které je vhodné sledovat, a praktické pokyny k extrakci dat. Usnadní vám přípravu dat a pomůže rychleji začít s process mining.

Doporučené atributy pro podrobnou analýzu
Důležité aktivity procesu pro přesné zjištění jeho průběhu
Praktické pokyny k extrakci dat ze systému

Pracujete se záznamy událostí poprvé? Přečtěte si, jak vytvořit záznam událostí pro process mining.

Stáhnout šablonu

Atributy správy úvěrů a vymáhání pohledávek

Toto jsou doporučená datová pole, která zahrňte do záznamu událostí, abyste mohli podrobně analyzovat proces správy úvěrů a vymáhání pohledávek.

3 Povinné 8 Doporučené 8 Volitelné

	Název	Popis
	Čas události EventTime	Časové razítko udávající, kdy došlo ke konkrétní aktivitě nebo události.
Popis Čas události je přesné datum a čas, kdy byla aktivita zaznamenána v systému. Jde o základ process mining, protože poskytuje chronologické pořadí potřebné k sestavení průběhu procesu a výpočtu časových ukazatelů. Tento atribut je nezbytný pro analýzu dob trvání, hledání úzkých míst a sledování SLA. Například rozdíl mezi událostmi „Vygenerována faktura“ a „Platba přijata“ slouží k výpočtu doby inkasa pohledávek (DSO), důležitého obchodního KPI. Bez přesných časových razítek nelze analyzovat výkonnost ani určit úzká místa. Proč je to důležité Toto časové razítko je nezbytné pro seřazení událostí, zjištění mapy procesu a výpočet ukazatelů výkonnosti, například dob cyklu a dob trvání. Kde data získat Tento atribut se podle konkrétní aktivity získává z různých polí data a času v tabulkách D365, například z „CreatedDateTime“ v „CustInvoiceJour“ nebo z „TransDate“ v „CustTrans“. Příklady 2023-01-15T09:30:00Z2023-02-28T14:12:55Z2023-03-20T11:05:10Z
	Číslo faktury InvoiceNumber	Jedinečný identifikátor každé zákaznické faktury, který slouží jako hlavní identifikátor případu v procesu správy pohledávek.
Popis Číslo faktury je důležitý atribut, který jednoznačně identifikuje každou finanční transakci se zákazníkem. Propojuje všechny související aktivity, od vytvoření a zaúčtování faktury až po inkaso platby a konečné vypořádání. V process mining se toto číslo používá k rekonstrukci průběhu každé faktury od začátku do konce a k podrobné analýze jejího životního cyklu. Pokud organizace sleduje každou fakturu jako samostatný případ, může určit obvyklé cesty procesem, úzká místa a odchylky od standardního postupu. Tento atribut je základem pro výpočet důležitých ukazatelů, například doby inkasa pohledávek (DSO), i pro analýzu variant procesu. Proč je to důležité Jde o nezbytné ID případu, které propojuje všechny události procesu a umožňuje rekonstruovat a analyzovat celý životní cyklus od fakturace po inkaso. Kde data získat Obvykle jde o pole „Invoice“ v tabulce „CustInvoiceJour“ v Microsoft Dynamics 365 Finance. Příklady INV-0012345CIV-2023-8876SI-9510034
	Název aktivity ActivityName	Název konkrétní události nebo úkolu, který nastal v určitém okamžiku životního cyklu faktury.
Popis Název aktivity popisuje konkrétní krok nebo událost v procesu správy pohledávek a vymáhání, například „Vygenerována faktura“, „Odeslán upomínkový dopis“ nebo „Platba přijata“. Tento atribut je pro process mining zásadní, protože určuje uzly v mapě procesu. Analýza pořadí a četnosti aktivit odhalí skutečný průběh procesu a pomůže najít opakované kroky, neefektivní postupy a odchylky od pravidel. Podporuje všechny vizualizace průběhu procesu a slouží k výpočtu doby trvání mezi jednotlivými fázemi. Proč je to důležité Tento atribut určuje kroky v mapě procesu a umožňuje vizualizovat a analyzovat životní cyklus faktury. Kde data získat Tento atribut se obvykle odvozuje mapováním konkrétních systémových událostí, změn stavu nebo dat vytvoření záznamů v různých tabulkách, například „CustInvoiceJour“, „CustTrans“, „CustCollectionLetterJour“ a „CustPaymPromise“, na standardizované názvy aktivit. Příklady Faktura zaúčtována a odeslánaVytvořena upomínkaSpor zaevidovánPlatba přijata
	Částka faktury InvoiceAmount	Celková peněžní hodnota faktury.
Popis Částka faktury představuje celkovou finanční hodnotu fakturovaného zboží nebo služeb. Jde o základní atribut pro finanční analýzu procesu. Umožňuje rozdělit případy podle hodnoty a zjistit, zda se faktury s vysokou částkou zpracovávají jinak nebo se u nich častěji vyskytují prodlevy. Tento atribut je důležitý pro dashboardy „Odpisy nedobytných faktur“ a „Analýza správy úvěrových limitů“, které pomáhají vyčíslit finanční dopad a posoudit riziko. Proč je to důležité Umožňuje analyzovat finanční dopady, upřednostnit faktury s vysokou částkou a zjistit, jak hodnota faktury ovlivňuje průběh procesu. Kde data získat Pravděpodobně jde o pole „InvoiceAmount“ v tabulce „CustInvoiceJour“. Příklady 1500.7525000.00549.99
	Datum splatnosti platby PaymentDueDate	Datum, do kterého má být podle smlouvy faktura uhrazena.
Popis Datum splatnosti platby je důležitý časový údaj stanovený podle platebních podmínek dohodnutých se zákazníkem. Slouží jako základ pro určení, zda je faktura po splatnosti. Je také hlavním spouštěčem činností vymáhání, například odeslání upomínky nebo zahájení formálního upomínkového řízení. V process mining se používá k výpočtu počtu dní po splatnosti a ke kontrole dodržování pravidel pro upomínání, například zda byla upomínka odeslána do X dnů od data splatnosti. Proč je to důležité Toto datum slouží jako měřítko včasnosti plateb a spouští všechny činnosti související s prodlením a vymáháním. Kde data získat Obvykle jde o pole „DueDate“ v tabulce „CustTrans“ nebo „CustInvoiceJour“. Příklady 2023-02-142023-03-312023-04-30
	Název zákazníka CustomerName	Oficiální název zákazníka, kterému byla faktura vystavena.
Popis Název zákazníka určuje konkrétního klienta spojeného s fakturou. Jde o hlavní rozměr pro filtrování a segmentaci. Analýza podle zákazníka pomáhá odhalit klienty, kteří opakovaně platí pozdě, rozporují faktury nebo vyžadují rozsáhlé vymáhání. Tento atribut je důležitý pro dashboard „Doba řešení sporů“ i pro podrobnou analýzu konkrétních zákaznických účtů. Proč je to důležité Umožňuje analyzovat procesy podle jednotlivých zákazníků, odhalovat vzorce a lépe spravovat vztahy s důležitými nebo problémovými účty. Kde data získat Tyto údaje se obvykle připojují z tabulky „CustTable“ pomocí čísla zákaznického účtu v tabulce „CustInvoiceJour“. Příklady Contoso Ltd.Adventure WorksFabrikam Inc.
	Počet dní po splatnosti DaysOverdue	Počet dní, o které je faktura po splatnosti.
Popis Počet dní po splatnosti je vypočítaný ukazatel, který měří dobu od data splatnosti nezaplacené faktury. Vypočítá se jako aktuální datum minus datum splatnosti. Jde o důležitý ukazatel výkonnosti týmu vymáhání, protože pomáhá určit, na které faktury se zaměřit. Je hlavním ukazatelem v dashboardu „Faktury po splatnosti podle segmentu“ a slouží k posouzení stavu pohledávek i účinnosti vymáhání. Proč je to důležité Jde o důležitý provozní ukazatel, který pomáhá určit priority při vymáhání a měřit závažnost prodlení s platbou. Kde data získat Jde o vypočítané pole. Logika: IF Invoice is unpaid THEN (Today() - PaymentDueDate) ELSE 0. Příklady 1532910
	Přiřazen pracovník vymáhání CollectorAssigned	Jméno pracovníka nebo člena týmu, který odpovídá za správu faktury po splatnosti.
Popis Tento atribut určuje zaměstnance odpovědného za vymáhání konkrétní faktury. Je důležitý pro analýzu výkonnosti a pracovního vytížení. Pokud vedoucí filtrují mapu procesu nebo dashboardy podle pracovníka vymáhání, mohou posoudit individuální produktivitu, porovnat strategie vymáhání a určit, kde je potřeba další vedení. Tento atribut je důležitým rozměrem dashboardů „Produktivita týmu vymáhání“ a „Doba řešení sporů“, protože umožňuje přiřadit výsledky procesu konkrétním lidem nebo týmům. Proč je to důležité Umožňuje analyzovat výkonnost týmu vymáhání, pomáhá vyvažovat pracovní vytížení a porovnáním efektivity jednotlivých pracovníků odhaluje osvědčené postupy. Kde data získat Podívejte se do dokumentace Microsoft Dynamics 365. Údaj může být propojen s modulem správy vymáhání nebo s poli odpovědnosti uživatele v záznamech zákazníka či transakce. Příklady John SmithEmily JonesTým vymáhání A
	Segment zákazníka CustomerSegment	Zařazení zákazníka například podle velikosti, oboru nebo strategického významu.
Popis Segment zákazníka je kategoriální atribut, který seskupuje zákazníky do smysluplných skupin, například „Strategičtí zákazníci“, „Malé a střední podniky“ nebo „Veřejná správa“. Toto členění je důležité pro strategickou analýzu. Pomáhá odpovědět na otázky, jako například: „Mají strategičtí zákazníci kratší DSO?“ nebo „Jsou odpisy častější v některém oboru?“. Atribut se přímo používá v dashboardech „Vývoj doby inkasa pohledávek“, „Odpisy nedobytných faktur“ a „Faktury po splatnosti podle segmentu“ a poskytuje přehled nad rámec jednotlivých zákazníků. Proč je to důležité Umožňuje souhrnnou analýzu skupin zákazníků, odhalování strategických trendů a přizpůsobení postupů vymáhání jednotlivým segmentům. Kde data získat Často jde o vlastní pole nebo údaj odvozený z atributů v tabulce „CustTable“, tedy hlavní tabulce zákazníků. Příklady Velké podnikyStřední podnikyVeřejný sektorPartner
	Stav faktury InvoiceStatus	Aktuální stav faktury v jejím životním cyklu.
Popis Stav faktury ukazuje, v jaké fázi procesu se faktura nachází, například „Otevřená“, „Zaplacená“, „Rozporovaná“ nebo „Odepsaná“. Protokol aktivit poskytuje podrobnou historii, zatímco aktuální stav je užitečný atribut na úrovni případu pro filtrování a souhrnné přehledy. Analytici mohou rychle vybrat pouze otevřené faktury po splatnosti nebo analyzovat vlastnosti všech odepsaných faktur. Jde o jednoduchý způsob, jak zjistit aktuální stav pohledávek. Proč je to důležité Umožňuje rychle filtrovat a analyzovat faktury podle jejich aktuálního stavu, například zobrazit všechny otevřené nebo rozporované případy. Kde data získat Odvozuje se od stavu vypořádání transakcí v tabulce „CustTrans“. Otevřená transakce není zaplacená, uzavřená transakce je vypořádaná. Příklady OtevřenáZaplacenáČástečně zaplacenáOdepsaná
	Úroveň upomínkového řízení DunningLevel	Označuje aktuální fázi nebo závažnost upomínkového řízení u faktury po splatnosti.
Popis Úroveň upomínkového řízení označuje fázi strukturovaného postupu, například „Úroveň 1: Přátelská upomínka“, „Úroveň 2: Formální výzva“ nebo „Úroveň 3: Poslední upozornění“. Sledování tohoto atributu je důležité pro vyhodnocení úspěšnosti strategie vymáhání. Dashboard „Účinnost strategie upomínání“ pomocí tohoto atributu ukazuje, jaké procento faktur je uhrazeno po dosažení jednotlivých úrovní. Firmy tak mohou upravit workflow upomínání, aby účinněji zajistily úhradu a zároveň zachovaly dobré vztahy se zákazníky. Proč je to důležité Pomáhá měřit účinnost strategie upomínání a zjistit, v jaké fázi zákazníci nejčastěji platí. Kde data získat Tyto údaje najdete v tabulkách souvisejících s vymáháním a upomínkovými dopisy, například „CustCollectionLetterJour“. Příklady 123 - PosledníPrávní kroky
	Byla faktura rozporována IsDisputed	Logická hodnota označující, zda byla faktura někdy rozporována.
Popis Jde o vypočítaný příznak, který se nastaví na true, pokud případ faktury obsahuje aktivitu „Spor zaevidován“. Uživatelé tak mohou snadno filtrovat průběh procesu u rozporovaných a nerozporovaných faktur nebo je porovnávat. Lze například porovnat průměrné DSO u rozporovaných a nerozporovaných faktur a vyčíslit dopad sporů na cash flow. Tento atribut se hodí pro souhrnné přehledy v dashboardu i srovnávací analýzu. Proč je to důležité Zjednodušuje analýzu a filtrování, protože umožňuje snadno porovnat rozporované a nerozporované faktury. Kde data získat Jde o vypočítané pole. Logika: IF the case contains a 'Dispute Registered' activity THEN true ELSE false. Příklady truefalse
	Doba řešení sporu DisputeResolutionTime	Doba od prvního zaevidování zákaznického sporu do jeho vyřešení.
Popis Doba řešení sporu měří efektivitu procesu vyřizování sporů. Vypočítá se jako doba mezi aktivitami „Spor zaevidován“ a „Spor vyřešen“. Dlouhé řešení může zpozdit platbu a snížit spokojenost zákazníků. Analýza tohoto ukazatele podle pracovníka vymáhání nebo důvodu sporu pomáhá najít úzká místa a možnosti zlepšení workflow správy sporů. Proč je to důležité Měří efektivitu procesu vyřizování sporů, které často způsobují výrazné prodlevy v platbách. Kde data získat Vypočítá se jako doba mezi časovými razítky aktivit „Spor zaevidován“ a „Spor vyřešen“. Příklady 7.215.83.5
	Důvod sporu DisputeReason	Důvod, který zákazník uvedl při rozporování faktury.
Popis Když zákazník rozporuje fakturu, obvykle uvede důvod, například „Nesprávná cena“, „Poškozené zboží“ nebo „Duplicitní fakturace“. Tento atribut zaznamenává uvedený důvod. Analýza důvodů sporů je důležitá pro hledání příčin problémů. Pomáhá odhalit opakující se potíže v procesu od objednávky po inkaso, například v prodeji, expedici nebo fakturaci. Odstranění příčin sporů přímo ovlivňuje DSO, protože předchází prodlevám v platbách. Proč je to důležité Poskytuje důležité údaje pro hledání příčin prodlev v platbách a pomáhá odhalit a napravit problémy v předchozích fázích, které vedou ke sporům o faktury. Kde data získat Podívejte se do dokumentace Microsoft Dynamics 365. Tento údaj bývá součástí funkcí pro správu sporů nebo případů. Příklady Chybná cenaNedodané množstvíProdukt nebyl doručenSlužba neodpovídá popisu
	Kód měny CurrencyCode	Měna faktury, například USD nebo EUR.
Popis Kód měny určuje měnu, ve které je vyjádřena částka faktury. Jde o důležitý kontextový atribut, zejména pro mezinárodní organizace. Je nezbytný pro správnou interpretaci finančních hodnot a může pomoci zjistit, zda platební cykly nebo problémy souvisejí s konkrétní měnou, například kvůli směně měn nebo zpracování mezinárodních plateb. Proč je to důležité Poskytuje nezbytný kontext pro všechny peněžní hodnoty a umožňuje analyzovat procesy zahrnující více měn. Kde data získat Obvykle jde o pole „CurrencyCode“ v tabulce „CustInvoiceJour“. Příklady USDEURGBPCAD
	Poslední aktualizace dat LastDataUpdate	Časové razítko posledního obnovení nebo aktualizace dat.
Popis Tento atribut udává, kdy byla datová sada naposledy aktualizována ze zdrojového systému. Pro uživatele analýzy process mining jde o důležitá metadata, která poskytují kontext o aktuálnosti dat. Pokud analytici vědí, k jakému okamžiku jsou data aktuální, mohou se lépe rozhodovat a správně vyhodnotit rozsah svých zjištění. Atribut se obvykle při načítání dat přiřazuje celé datové sadě. Proč je to důležité Informuje uživatele o aktuálnosti dat. Analýza tak vychází ze známého časového období a rozhodnutí se neopírají o zastaralé informace. Kde data získat Tuto hodnotu při spuštění vytvoří a přidá do datové sady ETL nebo datový proces. Příklady 2023-04-01T02:00:00Z2023-04-02T02:00:00Z
	Úvěrový limit CreditLimit	Maximální výše úvěru schválená zákazníkovi.
Popis Úvěrový limit je celková výše dluhu, kterou může zákazník čerpat. Tento atribut je důležitý pro řízení rizik. Dashboard „Analýza správy úvěrových limitů“ porovnává tuto hodnotu s částkami faktur u účtů v prodlení nebo s odepsanými pohledávkami. Analýza pomáhá určit, zda jsou úvěrové limity nastaveny správně a zda se dodržují. Ukáže také, zda zákazníci, kteří nesplácejí, nedávno získali vyšší limit, což může upozornit na nedostatky ve schvalování úvěrů. Proč je to důležité Tento atribut je důležitý pro posouzení rizika a pomáhá zjistit, zda odpisy souvisejí se špatně nastavenými nebo nedostatečně spravovanými úvěrovými limity zákazníků. Kde data získat Tato hodnota se obvykle ukládá v hlavním záznamu zákazníka v tabulce „CustTable“. Příklady 10000.0050000.000.00
	Zdrojový systém SourceSystem	Určuje systém, ze kterého data pocházejí.
Popis Tento atribut určuje zdrojovou aplikaci, ve které byla data události zaznamenána. V tomto případě jde o „Microsoft Dynamics 365“. Při analýze jediného systému se může zdát, že se hodnota nemění, je však důležitá pro správu dat, řešení problémů a budoucí integrace. Pokud by se zahrnula data z dalších systémů, například samostatného CRM nebo portálu inkasní agentury, toto pole by pomohlo zdroje rozlišit a pochopit celý proces napříč systémy. Proč je to důležité Zajišťuje přehled o původu dat a je nezbytný pro udržení jejich kvality i analýzu napříč propojenými systémy. Kde data získat Obvykle jde o statickou hodnotu, která se přidává při extrakci dat a označuje původ záznamů. Příklady Microsoft Dynamics 365D365 F&O
	Země Country	Země fakturační adresy zákazníka.
Popis Tento atribut určuje zemi spojenou se zákaznickým účtem. Jde o běžný rozměr geografické analýzy. Rozdělení procesních KPI, například DSO nebo míry odpisů, podle země může odhalit regionální rozdíly v platebním chování zákazníků, účinnosti vymáhání nebo ekonomických podmínkách. Na základě těchto zjištění lze přizpůsobit postupy vymáhání jednotlivým oblastem nebo pro ně nastavit jiné platební podmínky. Proč je to důležité Umožňuje geografickou analýzu a pomáhá odhalit regionální trendy v platebním chování a výkonnosti procesu vymáhání. Kde data získat Údaj se získává propojením hlavního záznamu zákazníka („CustTable“) s jeho primární adresou, která bývá v tabulce „LogisticsPostalAddress“. Příklady USADEUGBRCAN

Povinné Doporučené Volitelné

Aktivity správy úvěrů a vymáhání pohledávek

Toto jsou důležité kroky a milníky procesu, které zachyťte v záznamu událostí, abyste mohli přesně zjistit průběh workflow správy úvěrů a vymáhání pohledávek.

9 Doporučené 3 Volitelné

	Aktivita	Popis
	Faktura odepsána	Faktura byla označena za nedobytnou a formálně odepsána jako nedobytná pohledávka. Jde o výslovný úkon oprávněného uživatele, který pohledávku vyřadí a zaúčtuje ztrátu.
Proč je to důležité Jde o hlavní neúspěšný konec procesu. Sledování odpisů je důležité pro pochopení úvěrového rizika, neúspěšného vymáhání a finančních ztrát. Kde data získat Událost se zaznamenává z konkrétní transakce hlavního deníku použité k odpisu nedobytné pohledávky, která je propojena s původní fakturou. Časovým razítkem je datum zaúčtování odpisového deníku. Zachycení Vyhledejte položky deníku s konkrétním profilem zaúčtování odpisu, které odkazují na fakturu. Typ události explicit
	Faktura uhrazena	Faktura je plně zaplacená a její zůstatek je nulový, což označuje úspěšné dokončení procesu. Tento stav se odvozuje v případě, že součet přiřazených plateb odpovídá celkové částce faktury.
Proč je to důležité Jde o hlavní úspěšný konec procesu od objednávky po inkaso. Analýza cest, které k němu vedou, odhalí osvědčené postupy a efektivní varianty procesu. Kde data získat Událost se odvozuje od data vypořádání v tabulce vypořádání zákaznických transakcí (CustSettlement). Nastane, když součet polí „AmountCur“ a „SettleAmountCur“ pro fakturu v tabulce CustTrans dosáhne nuly. Zachycení Určete nejpozdější datum vypořádání související s fakturační transakcí, po kterém je její zůstatek nulový. Typ události inferred
	Faktura zaúčtována a odeslána	Označuje oficiální zaúčtování faktury do hlavní knihy, čímž vznikne formální pohledávka. Tato událost obvykle nastane současně s odesláním faktury zákazníkovi a zaznamená se po dokončení účtovací rutiny v Dynamics 365.
Proč je to důležité Jde o důležitý milník, od kterého se počítá splatnost a doba po splatnosti. Zpoždění mezi vystavením a zaúčtováním může odhalit neefektivitu fakturace. Kde data získat Událost lze odvodit z data zaúčtování v deníku zákaznických faktur (CustInvoiceJour) nebo ze změny stavu na „Posted“. Rozhodující je časové razítko zaúčtování. Zachycení Použijte časové razítko zaúčtování z deníku zákaznických faktur (CustInvoiceJour). Typ události inferred
	Platba přijata	Označuje přijetí platby od zákazníka a její zadání do systému, obvykle prostřednictvím platebního deníku. K této události dochází před konečným zaúčtováním a přiřazením platby ke konkrétní faktuře.
Proč je to důležité Jde o důležitý milník pro výpočet DSO a pochopení cash flow. Čas mezi touto událostí a událostí Platba zaúčtována odhaluje úzká místa v procesu přiřazování plateb. Kde data získat Jde o výslovně zaznamenanou událost, která vychází z data vytvoření řádku platebního deníku zákazníka (LedgerJournalTrans), ještě před jeho zaúčtováním. Udává datum, kdy byla platba zaznamenána jako přijatá. Zachycení Použijte datum transakce z řádků platebního deníku zákazníka. Typ události explicit
	Platba zaúčtována	Označuje oficiální zaúčtování platby zákazníka do hlavní knihy a její přiřazení k úhradě faktury. Událost se zaznamenává podle data zaúčtování platebního deníku zákazníka.
Proč je to důležité Tímto se dokončuje část procesu týkající se platby. Doba mezi přijetím a zaúčtováním platby, tedy prodleva při zpracování přijatých plateb, je důležitým ukazatelem efektivity finančního oddělení. Kde data získat Událost se zaznamenává podle časového razítka zaúčtování platebního deníku zákazníka (LedgerJournalTrans). Potvrzuje, že platba byla v účetní knize plně zpracována. Zachycení Použijte datum zaúčtování zaúčtovaného platebního deníku zákazníka. Typ události explicit
	Spor zaevidován	Znamená, že zákazník fakturu oficiálně rozporoval a její stav byl odpovídajícím způsobem změněn. Obvykle se tato událost zaznamená, když uživatel v modulu správy vymáhání změní stav faktury na „Rozporováno“.
Proč je to důležité Tímto bodem začíná proces řešení sporu. Sledování této události pomáhá měřit četnost sporů a dobu jejich řešení, což má vliv na spokojenost zákazníků i cash flow. Kde data získat Událost se odvozuje ze změny stavu zákaznické transakce (CustTrans) nebo související tabulky správy sporů (smmCaseDetail). Je nutné mít k dispozici protokol změn stavu s časovými razítky. Zachycení Určete, kdy se pole stavu sporu u fakturační transakce vyplní nebo změní na „Rozporováno“. Typ události inferred
	Uplynul termín splatnosti	Vypočítaná událost, která nastane, když aktuální datum překročí datum splatnosti faktury. Neodpovídá přímé činnosti uživatele, odvozuje se porovnáním systémového data s polem data splatnosti faktury.
Proč je to důležité Tato událost spouští veškeré činnosti spojené s vymáháním pohledávek. Umožňuje analyzovat počet faktur po splatnosti a včasnost upomínek a sledovat KPI, například dodržování pravidel upomínání. Kde data získat Událost se vypočítá porovnáním aktuálního časového razítka s polem „DueDate“ v tabulce zákaznických transakcí (CustTrans). Čas události odpovídá hodnotě DueDate. Zachycení Vytvořte událost, když je hodnota „NOW()“ pozdější než DueDate faktury. Typ události calculated
	Vystavena faktura	Označuje vytvoření záznamu prodejní faktury v systému před jejím oficiálním zaúčtováním. Tato činnost se obvykle zaznamená jako samostatná událost, když uživatel dokončí prodejní objednávku a vytvoří příslušný fakturační doklad.
Proč je to důležité Jde o hlavní počáteční událost životního cyklu faktury. Doba od tohoto okamžiku do úhrady je důležitá pro měření doby inkasa pohledávek. Kde data získat Při vytvoření faktury se událost zaznamená do tabulky Sales Invoice Header (SalesInvoiceHeader) nebo Sales Table (SalesTable). Čas vytvoření záznamu slouží jako čas události. Zachycení Zaznamenejte čas vytvoření záznamu prodejní faktury. Typ události explicit
	Vytvořena upomínka	Označuje vytvoření formální upomínky nebo výzvy k úhradě faktury po splatnosti. Událost se zaznamená při spuštění pravidelného procesu upomínání v Dynamics 365, který vytvoří záznamy upomínek pro příslušné faktury.
Proč je to důležité Sleduje zahájení a četnost formálního vymáhání pohledávek. Je nezbytná pro měření účinnosti upomínání a dodržování interních pravidel vymáhání. Kde data získat V tabulce historie upomínek (CustCollectionLetterJour) se vytvoří samostatný záznam. Časovým razítkem je datum vytvoření deníku upomínky. Zachycení Načtěte události vytvoření z tabulky CustCollectionLetterJour a propojte je s příslušnou fakturou. Typ události explicit
	Spor vyřešen	Označuje konec procesu řešení sporu, kdy bylo nalezeno a zaznamenáno řešení. Událost se zaznamená, když uživatel změní stav sporu u faktury na „Vyřešeno“ nebo uzavře související případ sporu.
Proč je to důležité Tato aktivita uzavírá dílčí proces řešení sporu. Doba od zaevidování sporu do jeho vyřešení je důležitým KPI pro měření efektivity týmu, který spory řeší. Kde data získat Událost se odvozuje ze změny stavu zákaznické transakce (CustTrans) nebo z uzavření souvisejícího případu sporu (smmCaseDetail). Čas události určuje časové razítko změny stavu. Zachycení Určete, kdy se pole stavu sporu u faktury vymaže nebo změní na „Vyřešeno“. Typ události inferred
	Vytvořen příslib platby	Zákazník se zavázal zaplatit v konkrétní budoucí den a tento příslib byl zaznamenán v systému. Událost se zaznamená, když pracovník vymáhání zadá v modulu pro vymáhání pohledávek údaje o příslibu platby.
Proč je to důležité Sleduje neformální dohody o platbě a míru jejich dodržení. Porovnání příslibů se skutečnými platbami může pomoci při předpovědi peněžního toku a hodnocení spolehlivosti zákazníků. Kde data získat Záznam se pravděpodobně ukládá do tabulek pracovního prostoru pro vymáhání pohledávek nebo správy případů, konkrétně do tabulek souvisejících s funkcí příslibu platby. Čas události odpovídá datu vytvoření záznamu příslibu. Zachycení Zaznamenejte události vytvoření z tabulky s podrobnostmi o příslibu platby nebo případu vymáhání. Typ události explicit
	Zaznamenána činnost při vymáhání	Představuje ruční úkon při správě pohledávek, například telefonát nebo e-mail zaznamenaný u zákazníka či faktury. Záznam vznikne, když pracovník správy pohledávek použije funkci Aktivity v pracovním prostoru pro správu pohledávek.
Proč je to důležité Zpřehledňuje ruční práci týmu pro vymáhání pohledávek. Porovnáním těchto činností s úspěšností plateb lze měřit produktivitu týmu i účinnost různých způsobů kontaktování zákazníků. Kde data získat Zaznamenává se v tabulce Activities (smmActivities) nebo v souvisejících tabulkách správy případů propojených se zákaznickým účtem. Pokud možno propojte aktivitu s konkrétní fakturou. Zachycení Zachyťte vytvoření záznamů Activity, jejichž typ je „Phone Call“ nebo „Email“ a které souvisejí se správou pohledávek. Typ události explicit

Doporučené Volitelné

Návody k extrakci dat

Jak získat data z Microsoft Dynamics 365

Kroky

Ověřte předpoklady: Zkontrolujte, že vaše organizace používá Microsoft Dynamics 365 Finance a má nastavenou a aktivní funkci Bring Your Own Database (BYOD), která exportuje datové entity do Azure SQL Database. Budete potřebovat přihlašovací údaje s přístupem pro čtení k této databázi Azure SQL.
Určete datové entity: Ověřte, že se z Dynamics 365 do BYOD exportují potřebné datové entity. Pro tento proces jsou důležité entity CustInvoiceJour, CustTrans, CustTable, CustCollectionLetterJour, CustSettlement, smmActivities, CustPromisedPayment a CustDispute. Pokud některá chybí, nastavte její export v pracovním prostoru Data Management v Dynamics 365.
Připojte se k databázi BYOD: Pomocí SQL klienta, například SQL Server Management Studio (SSMS) nebo Azure Data Studio, se připojte k databázi Azure SQL, která slouží jako cíl BYOD.
Připravte dotaz SQL: Zkopírujte celý dotaz T-SQL z části query tohoto dokumentu do svého SQL klienta. Dotaz shromáždí všechny požadované aktivity a atributy do jednoho záznamu událostí.
Nastavte parametry dotazu: Najděte zástupné hodnoty na začátku dotazu. Nahraďte '{CompanyCode}' ID cílové právnické osoby v Dynamics 365, například „USMF“. Hodnoty '{StartDate}' a '{EndDate}' nahraďte požadovaným časovým obdobím ve formátu „YYYY-MM-DD“.
Spusťte dotaz: Spusťte upravený dotaz nad databází BYOD. Doba zpracování závisí na objemu dat ve zvoleném období.
Zkontrolujte výsledky: Po dokončení dotazu se v panelu výsledků zobrazí záznam událostí. Každý řádek představuje konkrétní aktivitu v průběhu správy úvěru a vymáhání pohledávek u jedné faktury. Ověřte úplnost a správnost dat.
Exportujte záznam událostí: Exportujte výsledky dotazu do souboru CSV. Většina SQL klientů má funkci pro export výsledků. Klikněte pravým tlačítkem na mřížku výsledků a vyhledejte možnost jako „Save Results As“ nebo „Export“.
Připravte data k nahrání: Zkontrolujte, že exportovaný soubor CSV používá kódování UTF-8 a že názvy sloupců odpovídají požadovaným atributům: InvoiceNumber, ActivityName, EventTime a všem doporučeným atributům, které jste zahrnuli. Soubor je připravený k nahrání do ProcessMind.

Konfigurace

Předpoklady: Přístup k instanci Microsoft Dynamics 365 for Finance s nastavenou a funkční funkcí Bring Your Own Database (BYOD). Pro cílovou databázi Azure SQL jsou nutná oprávnění ke čtení.
Datové entity: Extrakce vyžaduje export několika standardních datových entit do BYOD. Ověřte, že exportní úloha BYOD zahrnuje alespoň CustInvoiceJour, CustTrans, CustTable a CustSettlement. Pro konkrétní aktivity jsou potřeba i další entity, například CustCollectionLetterJour.
Časové období: Kvůli výkonu je důležité omezit dotaz na konkrétní časové období. Pro první analýzu doporučujeme data za 3 až 6 měsíců. Dotaz k tomu používá zástupné hodnoty '{StartDate}' a '{EndDate}'.
Filtr společnosti: Kvůli konzistenci dat musí být dotaz omezen na konkrétní právnickou osobu (kód společnosti). Pomocí zástupné hodnoty '{CompanyCode}' určete analyzovanou společnost.
Dopad na výkon: U velmi rozsáhlých datových sad pokrývajících několik let nebo společností může zpracování dotazu trvat dlouho. Spusťte jej mimo špičku nebo přidejte další filtry, které omezí rozsah dat. V tabulkách BYOD ověřte správné indexování datových a klíčových sloupců.

Ukázkový dotaz sql

WITH BaseInvoices AS (
    SELECT 
        cj.INVOICEID AS InvoiceNumber,
        cj.INVOICEDATE AS InvoiceDate,
        cj.DUEDATE AS PaymentDueDate,
        cj.INVOICEAMOUNTMST AS InvoiceAmount,
        ct.NAME AS CustomerName,
        ct.CUSTGROUP AS CustomerSegment,
        -- The collector assignment can be complex. This is a common approach.
        -- It assumes the collector is assigned at the customer level in CustTable.
        -- Your configuration may differ, for example using collection pools.
        col.NAME AS CollectorAssigned,
        cj.DATAAREAID
    FROM 
        dbo.CustInvoiceJour cj
    JOIN 
        dbo.CustTable ct ON cj.INVOICECUST = ct.ACCOUNTNUM AND cj.DATAAREAID = ct.DATAAREAID
    LEFT JOIN 
        -- Placeholder for how collector might be identified. You may need to join to a different table.
        dbo.CollectionsAgent col ON ct.COLLECTIONAGENT = col.AGENTID
    WHERE 
        cj.DATAAREAID = '{CompanyCode}'
        AND cj.INVOICEDATE BETWEEN '{StartDate}' AND '{EndDate}'
)

-- 1. Invoice Generated
SELECT 
    bi.InvoiceNumber AS InvoiceNumber,
    'Invoice Generated' AS ActivityName,
    cj.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    0 AS DunningLevel, 
    'Generated' AS InvoiceStatus,
    0 AS DaysOverdue
FROM 
    BaseInvoices bi
JOIN
    dbo.CustInvoiceJour cj ON bi.InvoiceNumber = cj.INVOICEID AND bi.DATAAREAID = cj.DATAAREAID

UNION ALL

-- 2. Invoice Posted and Sent
SELECT 
    bi.InvoiceNumber AS InvoiceNumber,
    'Invoice Posted and Sent' AS ActivityName,
    bi.InvoiceDate AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    0 AS DunningLevel,
    'Posted' AS InvoiceStatus,
    0 AS DaysOverdue
FROM 
    BaseInvoices bi

UNION ALL

-- 3. Payment Due Date Passed
SELECT
    bi.InvoiceNumber AS InvoiceNumber,
    'Payment Due Date Passed' AS ActivityName,
    bi.PaymentDueDate AS EventTime, -- The event happens on the due date
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    0 AS DunningLevel,
    'Overdue' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, GETUTCDATE()) AS DaysOverdue
FROM
    BaseInvoices bi
JOIN 
    dbo.CustTrans ct ON bi.InvoiceNumber = ct.INVOICE AND bi.DATAAREAID = ct.DATAAREAID
WHERE
    bi.PaymentDueDate < GETUTCDATE()
    AND ct.CLOSED = '1900-01-01 00:00:00.000' -- Logic to find open/unsettled transactions

UNION ALL

-- 4. Dunning Letter Generated
SELECT 
    clj.INVOICEID AS InvoiceNumber,
    'Dunning Letter Generated' AS ActivityName,
    clj.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    clj.COLLECTIONLETTERCODE AS DunningLevel,
    'In Dunning' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, clj.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustCollectionLetterJour clj
JOIN
    BaseInvoices bi ON clj.INVOICEID = bi.InvoiceNumber AND clj.DATAAREAID = bi.DATAAREAID

UNION ALL

-- 5. Collection Activity Logged
-- This assumes smmActivities are used and linked to the customer.
-- Linking directly to an invoice can be difficult.
SELECT 
    bi.InvoiceNumber AS InvoiceNumber,
    'Collection Activity Logged' AS ActivityName,
    sa.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'In Collections' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, sa.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.smmActivities sa
JOIN
    dbo.CustTable ct ON sa.PARTY = ct.PARTY
JOIN
    BaseInvoices bi ON ct.ACCOUNTNUM = (SELECT TOP 1 INVOICECUST FROM dbo.CustInvoiceJour WHERE INVOICEID = bi.InvoiceNumber AND DATAAREAID = bi.DATAAREAID) AND ct.DATAAREAID = bi.DATAAREAID
WHERE
    sa.DATAAREAID = '{CompanyCode}' AND sa.CREATEDDATETIME > bi.InvoiceDate

UNION ALL

-- 6. Payment Promise Created
SELECT 
    bi.InvoiceNumber,
    'Payment Promise Created' AS ActivityName,
    cpp.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Payment Promised' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cpp.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustPromisedPayment cpp
JOIN 
    dbo.CustTrans ct ON cpp.TRANSACTIONREFRECID = ct.RECID AND cpp.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID

UNION ALL

-- 7. Dispute Registered
SELECT 
    bi.InvoiceNumber,
    'Dispute Registered' AS ActivityName,
    cd.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Disputed' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cd.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustDispute cd
JOIN 
    dbo.CustTrans ct ON cd.CUSTTRANSRECID = ct.RECID AND cd.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE
    cd.STATUS = 1 -- Assuming 1 means opened/registered

UNION ALL

-- 8. Dispute Resolved
SELECT 
    bi.InvoiceNumber,
    'Dispute Resolved' AS ActivityName,
    cd.MODIFIEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Posted' AS InvoiceStatus, -- Status returns to normal after resolution
    DATEDIFF(day, bi.PaymentDueDate, cd.MODIFIEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustDispute cd
JOIN 
    dbo.CustTrans ct ON cd.CUSTTRANSRECID = ct.RECID AND cd.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE
    cd.STATUS = 2 -- Assuming 2 means closed/resolved

UNION ALL

-- 9. Payment Received (Journal Created, not yet posted)
-- This can be difficult to capture accurately and link to a specific invoice before settlement.
-- This is an approximation based on journal creation.
SELECT 
    bi.InvoiceNumber,
    'Payment Received' AS ActivityName,
    cpjl.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Payment Pending' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cpjl.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustomerPaymentJournalLineEntity cpjl
JOIN
    BaseInvoices bi ON cpjl.AccountDisplayValue = (SELECT TOP 1 INVOICECUST FROM dbo.CustInvoiceJour WHERE INVOICEID = bi.InvoiceNumber AND DATAAREAID = bi.DATAAREAID) AND cpjl.Company = bi.DATAAREAID
WHERE
    cpjl.CREATEDDATETIME >= bi.InvoiceDate

UNION ALL

-- 10. Payment Posted (Settlement Transaction)
-- Captures each partial or full payment application
SELECT 
    bi.InvoiceNumber,
    'Payment Posted' AS ActivityName,
    cs.TRANSDATE AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Partially Paid' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cs.TRANSDATE) AS DaysOverdue
FROM 
    dbo.CustSettlement cs
JOIN 
    dbo.CustTrans ct ON cs.TRANSRECID = ct.RECID AND cs.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE 
    cs.SETTLEAMOUNTCUR > 0

UNION ALL

-- 11. Invoice Settled
SELECT 
    bi.InvoiceNumber,
    'Invoice Settled' AS ActivityName,
    ct.CLOSEDDATE AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Settled' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, ct.CLOSEDDATE) AS DaysOverdue
FROM 
    dbo.CustTrans ct
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE 
    ct.CLOSEDDATE <> '1900-01-01 00:00:00.000'
    AND ct.TRANSTYPE = 11 -- Enum for Sales Invoice

UNION ALL

-- 12. Invoice Written Off
SELECT
    bi.InvoiceNumber,
    'Invoice Written Off' AS ActivityName,
    ct.TRANSDATE AS EventTime, -- The date of the write-off transaction
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Written Off' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, ct.TRANSDATE) AS DaysOverdue
FROM
    dbo.CustTrans ct
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE 
    ct.TRANSTYPE = 19; -- Enum for Write-off. This may vary based on configuration.

Kroky

Ověřte předpoklady a připravte prostředí: Zkontrolujte, že máte nainstalovaný Python 3.8 nebo novější. Potřebné knihovny nainstalujte pomocí pip: pip install pandas requests msal. Budete také potřebovat přihlašovací údaje servisního principálu s přístupem k prostředí Dynamics 365.
Zaregistrujte aplikaci v Azure AD: Otevřete portál Azure Active Directory. Zaregistrujte novou aplikaci a získejte Client ID a Tenant ID. V části „Certificates & secrets“ vytvořte pro aplikaci nový client secret. Client ID, Tenant ID a Client Secret bezpečně uložte.
Udělejte aplikaci oprávnění k API: V nastavení „API permissions“ zaregistrované aplikace v Azure AD přidejte oprávnění. Vyberte „Dynamics ERP“ nebo podobnou položku pro Dynamics 365 a poté přidejte delegované oprávnění „user_impersonation“. Udělte souhlas správce pro svou organizaci.
Vytvořte uživatele Dynamics 365: V Dynamics 365 Finance and Operations vytvořte vyhrazeného uživatele aplikace. Propojte ho s Client ID aplikace Azure AD. Přiřaďte mu bezpečnostní roli s oprávněním ke čtení všech požadovaných datových entit, například CustInvoiceJour, CustCollectionLetterJour, CustSettlements a smmActivities.
Nastavte Python skript: Zkopírujte poskytnutý Python skript do souboru, například extract_d365_collections.py. Doplňte zástupné proměnné na začátku skriptu: URL prostředí D365, Tenant ID, Client ID, Client Secret a výchozí společnost (dataAreaId).
Nastavte parametry extrakce: Upravte proměnné start_date a end_date ve skriptu a určete tak časové období pro extrakci dat. Pro první analýzu doporučujeme 3 až 6 měsíců.
Spusťte skript: Spusťte skript v terminálu příkazem python extract_d365_collections.py. Skript se ověří, načte data z koncových bodů OData pro všech 12 aktivit a automaticky zpracuje stránkování API.
Načtěte data pro jednotlivé aktivity: Skript postupně volá API a načítá data o vytvoření a zaúčtování faktur, upomínkách, platbách a dalších důležitých událostech. Každý dotaz cílí na konkrétní datovou entitu a vybírá pouze potřebná pole, aby omezil zátěž.
Transformujte a spojte data: Skript pomocí knihovny pandas zpracuje odpověď JSON z každého volání API. Převede data do strukturované tabulky, sjednotí názvy sloupců a spojí data ze všech aktivit do jednoho záznamu událostí.
Vypočítejte odvozené události: Aktivita „Uplynulo datum splatnosti“ není v systému zaznamenána přímo. Skript ji vypočítá tak, že projde všechny faktury po splatnosti ve zvoleném období a vytvoří pro každou odpovídající řádek.
Exportujte záznam událostí: Po zpracování a spojení všech dat skript uloží výsledný záznam událostí do souboru CSV d365_collections_event_log.csv ve stejné složce. Soubor je připravený k nahrání do nástroje process mining.

Konfigurace

URL koncového bodu API: Základní URL vašeho prostředí Dynamics 365 Finance and Operations. Zadejte ji ve formátu https://[your-environment-name].operations.dynamics.com.
Přihlašovací údaje: Skript vyžaduje Tenant ID, Client ID a Client Secret z registrace aplikace v Azure Active Directory. Této aplikaci musíte udělit oprávnění k přístupu k API Dynamics 365.
Filtr společnosti (dataAreaId): Dynamics 365 podporuje více společností. Skript je nastavený tak, aby načítal data pro konkrétní společnost pomocí filtru dataAreaId. Nastavte proměnnou default_company na správnou právnickou osobu, například „USMF“.
Časové období: Parametry start_date a end_date určují období extrakce. Doporučujeme začít s nedávným obdobím 3 až 6 měsíců, abyste omezili objem dat a zajistili včasnou extrakci. Filtr se uplatňuje především na datum vytvoření faktury.
Dopad na výkon: Extrakce velmi rozsáhlých datových sad přes API OData může trvat dlouho a Microsoft může omezit počet volání API. Pokud narazíte na problémy s výkonem, zkraťte časové období nebo spusťte extrakci mimo špičku.
Předpoklady: Je potřeba prostředí Python 3.8 nebo novější s knihovnami pandas, requests a msal. Příslušný uživatel Dynamics 365 musí mít přístup ke čtení modulů financí, prodeje a správy pohledávek, zejména entit uvedených ve skriptu.

Ukázkový dotaz python

import requests
import pandas as pd
import msal
import json
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># --- Configuration --- 
D365_HOST = class="hl-string">"https://[your-d365-environment-url].operations.dynamics.com"
TENANT_ID = class="hl-string">"[Your Tenant ID]"
CLIENT_ID = class="hl-string">"[Your Client ID]"
CLIENT_SECRET = class="hl-string">"[Your Client Secret]"

class=class="hl-string">"hl-comment"># Date range for the extraction
start_date = class="hl-string">"2023-01-01"
end_date = class="hl-string">"2023-06-30"
default_company = class="hl-string">"[Your Company ID, e.g., USMF]"

class=class="hl-string">"hl-comment"># MSAL configuration
authority = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}"
scope = [fclass="hl-string">"{D365_HOST}/.default"]

class=class="hl-string">"hl-comment"># --- Authentication --- 
app = msal.ConfidentialClientApplication(CLIENT_ID, authority=authority, client_credential=CLIENT_SECRET)
result = app.acquire_token_silent(scope, account=None)

if not result:
    result = app.acquire_token_for_client(scopes=scope)

if class="hl-string">"access_token" not in result:
    raise Exception(class="hl-string">"Could not obtain access token: " + result.get(class="hl-string">"error_description"))

access_token = result[class="hl-string">'access_token']
headers = {
    class="hl-string">'Authorization': class="hl-string">'Bearer ' + access_token,
    class="hl-string">'Content-Type': class="hl-string">'application/json',
    class="hl-string">'Accept': class="hl-string">'application/json'
}

class=class="hl-string">"hl-comment"># --- Data Fetching Function --- 
def get_odata_data(entity_url):
    all_records = []
    url = entity_url
    while url:
        try:
            response = requests.get(url, headers=headers, params={class="hl-string">'cross-company': class="hl-string">'true'})
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an HTTPError for bad responses (4xx or 5xx)
            data = response.json()
            all_records.extend(data.get(class="hl-string">'value', []))
            url = data.get(class="hl-string">'@odata.nextLink')
        except requests.exceptions.HTTPError as err:
            print(fclass="hl-string">"HTTP Error fetching data: {err}")
            print(fclass="hl-string">"Response content: {err.response.text}")
            break
        except json.JSONDecodeError:
            print(fclass="hl-string">"Failed to decode JSON from response: {response.text}")
            break
    return all_records

class=class="hl-string">"hl-comment"># --- Main Extraction Logic --- 
all_events = []

print(class="hl-string">"1. Extracting 'Invoice Generated' and 'Invoice Posted'...")
invoice_entity_url = fclass="hl-string">"{D365_HOST}/data/CustInvoiceJours?$filter=dataAreaId eq '{default_company}' and InvoiceDate ge {start_date}T00:00:00Z and InvoiceDate le {end_date}T23:59:59Z&$select=InvoiceNumber,InvoiceDate,createdDateTime,DueDate,InvoiceAmount,SalesOrderNumber,InvoiceCustomerAccountNumber,CustomerName,dataAreaId"
invoices = get_odata_data(invoice_entity_url)
if invoices:
    df_invoices = pd.DataFrame(invoices)
    df_invoices[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Generated'
    df_invoices[class="hl-string">'EventTime'] = pd.to_datetime(df_invoices[class="hl-string">'createdDateTime']).dt.tz_localize(None)
    df_invoices.rename(columns={class="hl-string">'InvoiceNumber': class="hl-string">'InvoiceNumber', class="hl-string">'InvoiceAmount': class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName': class="hl-string">'CustomerName', class="hl-string">'DueDate': class="hl-string">'PaymentDueDate'}, inplace=True)
    all_events.append(df_invoices[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate']])

    df_posted = df_invoices.copy()
    df_posted[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Posted and Sent'
    df_posted[class="hl-string">'EventTime'] = pd.to_datetime(df_posted[class="hl-string">'InvoiceDate']).dt.tz_localize(None)
    all_events.append(df_posted[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate']])

    print(class="hl-string">"2. Calculating 'Payment Due Date Passed'...")
    df_due_passed = df_invoices[pd.to_datetime(df_invoices[class="hl-string">'PaymentDueDate']).dt.date < datetime.now().date()].copy()
    df_due_passed[class="hl-string">'ActivityName'] = class="hl-string">'Payment Due Date Passed'
    df_due_passed[class="hl-string">'EventTime'] = pd.to_datetime(df_due_passed[class="hl-string">'PaymentDueDate']) + timedelta(days=1)
    all_events.append(df_due_passed[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate']])

print(class="hl-string">"3. Extracting 'Dunning Letter Generated'...")
dunning_entity_url = fclass="hl-string">"{D365_HOST}/data/CustCollectionLetterJours?$filter=dataAreaId eq '{default_company}' and CollectionLetterDate ge {start_date}T00:00:00Z and CollectionLetterDate le {end_date}T23:59:59Z&$select=InvoiceNumber,CollectionLetterCode,CollectionLetterDate"
dunning_letters = get_odata_data(dunning_entity_url)
if dunning_letters:
    df_dunning = pd.DataFrame(dunning_letters)
    df_dunning[class="hl-string">'ActivityName'] = class="hl-string">'Dunning Letter Generated'
    df_dunning[class="hl-string">'EventTime'] = pd.to_datetime(df_dunning[class="hl-string">'CollectionLetterDate']).dt.tz_localize(None)
    df_dunning.rename(columns={class="hl-string">'InvoiceNumber': class="hl-string">'InvoiceNumber', class="hl-string">'CollectionLetterCode': class="hl-string">'DunningLevel'}, inplace=True)
    all_events.append(df_dunning[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'DunningLevel']])

print(class="hl-string">"4. Extracting 'Payment Received' and 'Payment Posted'...")
settlements_entity_url = f"{D365_HOST}/data/CustSettlements?$filter=dataAreaId eq class="hl-string">'{default_company}' and TransDate ge {start_date}T00:00:00Z and TransDate le {end_date}T23:59:59Z&$select=OffsetRecId,TransDate,createdDateTime,SettlementAmountCur
&expand=CustInvoiceJour($select=InvoiceNumber)"
settlements = get_odata_data(settlements_entity_url)
if settlements:
    class=class="hl-string">"hl-comment"># Flatten the expanded data
    flat_settlements = []
    for s in settlements:
        if s.get(class="hl-string">'CustInvoiceJour'):
            s[class="hl-string">'InvoiceNumber'] = s[class="hl-string">'CustInvoiceJour'][class="hl-string">'InvoiceNumber']
            flat_settlements.append(s)

    df_settlements = pd.DataFrame(flat_settlements)
    df_received = df_settlements.copy()
    df_received[class="hl-string">'ActivityName'] = class="hl-string">'Payment Received'
    df_received[class="hl-string">'EventTime'] = pd.to_datetime(df_received[class="hl-string">'createdDateTime']).dt.tz_localize(None)
    all_events.append(df_received[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])
    
    df_posted_payment = df_settlements.copy()
    df_posted_payment[class="hl-string">'ActivityName'] = class="hl-string">'Payment Posted'
    df_posted_payment[class="hl-string">'EventTime'] = pd.to_datetime(df_posted_payment[class="hl-string">'TransDate']).dt.tz_localize(None)
    all_events.append(df_posted_payment[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

class=class="hl-string">"hl-comment"># Note: Other activities like Disputes, Promises, Write-offs often involve custom entities or status fields.
class=class="hl-string">"hl-comment"># The following are conceptual examples assuming certain fields exist.
class=class="hl-string">"hl-comment"># You MUST adapt these to your specific D365 configuration.

print(class="hl-string">"5. Extracting 'Dispute Registered' and 'Dispute Resolved' (Conceptual)... ")
class=class="hl-string">"hl-comment"># Assuming a status field class="hl-string">'CollectionStatus' on the invoice indicates a dispute.
class=class="hl-string">"hl-comment"># This would ideally be sourced from an audit trail if available. This example assumes a snapshot.
dispute_entity_url = fclass="hl-string">"{D365_HOST}/data/CustInvoiceJours?$filter=dataAreaId eq '{default_company}' and (CollectionStatus eq 'Disputed' or CollectionStatus eq 'Resolved') and modifiedDateTime ge {start_date}T00:00:00Z&$select=InvoiceNumber,CollectionStatus,modifiedDateTime"
disputes = get_odata_data(dispute_entity_url)
if disputes:
    df_disputes = pd.DataFrame(disputes)
    df_disputes[class="hl-string">'ActivityName'] = df_disputes[class="hl-string">'CollectionStatus'].apply(lambda x: class="hl-string">'Dispute Registered' if x == class="hl-string">'Disputed' else class="hl-string">'Dispute Resolved')
    df_disputes[class="hl-string">'EventTime'] = pd.to_datetime(df_disputes[class="hl-string">'modifiedDateTime']).dt.tz_localize(None)
    all_events.append(df_disputes[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

print(class="hl-string">"6. Extracting 'Payment Promise Created' (Conceptual)... ")
promise_entity_url = fclass="hl-string">"{D365_HOST}/data/CustPromisedPayments?$filter=dataAreaId eq '{default_company}' and createdDateTime ge {start_date}T00:00:00Z&$select=Invoice,createdDateTime,PromisedDate,PromisedAmount&$expand=CustInvoiceJour($select=InvoiceNumber)"
promises = get_odata_data(promise_entity_url)
if promises:
    flat_promises = []
    for p in promises:
        if p.get(class="hl-string">'CustInvoiceJour'):
            p[class="hl-string">'InvoiceNumber'] = p[class="hl-string">'CustInvoiceJour'][class="hl-string">'InvoiceNumber']
            flat_promises.append(p)
    df_promises = pd.DataFrame(flat_promises)
    df_promises[class="hl-string">'ActivityName'] = class="hl-string">'Payment Promise Created'
    df_promises[class="hl-string">'EventTime'] = pd.to_datetime(df_promises[class="hl-string">'createdDateTime']).dt.tz_localize(None)
    all_events.append(df_promises[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])
    
print(class="hl-string">"7. Extracting 'Collection Activity Logged' (Conceptual)... ")
class=class="hl-string">"hl-comment"># Linking activities to invoices can be indirect, often through the customer account.
activity_entity_url = fclass="hl-string">"{D365_HOST}/data/smmActivities?$filter=dataAreaId eq '{default_company}' and StartDateTime ge {start_date}T00:00:00Z and Purpose eq '[Your Collection Activity Purpose]'&$select=ActivityNumber,ParentRecordEntityName,ParentRecordRecId,StartDateTime,ResponsibleWorkerName&$expand=CustTable($select=AccountNumber)"
activities = get_odata_data(activity_entity_url)
class=class="hl-string">"hl-comment"># This section requires custom logic to map customer-level activities to open invoices at that time.
class=class="hl-string">"hl-comment"># A simplified approach is omitted here due to its complexity.

print(class="hl-string">"8. Identifying 'Invoice Settled' (Conceptual)... ")
settled_entity_url = fclass="hl-string">"{D365_HOST}/data/CustInvoiceJours?$filter=dataAreaId eq '{default_company}' and Status eq 'Paid' and LastSettlementDate ge {start_date}T00:00:00Z&$select=InvoiceNumber,LastSettlementDate"
settled_invoices = get_odata_data(settled_entity_url)
if settled_invoices:
    df_settled = pd.DataFrame(settled_invoices)
    df_settled[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Settled'
    df_settled[class="hl-string">'EventTime'] = pd.to_datetime(df_settled[class="hl-string">'LastSettlementDate']).dt.tz_localize(None)
    all_events.append(df_settled[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

print(class="hl-string">"9. Identifying 'Invoice Written Off' (Conceptual)... ")
class=class="hl-string">"hl-comment"># This is identified by a specific type of transaction in CustTrans.
writeoff_entity_url = fclass="hl-string">"{D365_HOST}/data/CustTrans?$filter=dataAreaId eq '{default_company}' and TransType eq 'WriteOff' and TransDate ge {start_date}T00:00:00Z&$select=Invoice,TransDate,Txt"
writeoffs = get_odata_data(writeoff_entity_url)
if writeoffs:
    df_writeoffs = pd.DataFrame(writeoffs)
    df_writeoffs.rename(columns={class="hl-string">'Invoice': class="hl-string">'InvoiceNumber'}, inplace=True)
    df_writeoffs[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Written Off'
    df_writeoffs[class="hl-string">'EventTime'] = pd.to_datetime(df_writeoffs[class="hl-string">'TransDate']).dt.tz_localize(None)
    all_events.append(df_writeoffs[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

class=class="hl-string">"hl-comment"># --- Final Processing --- 
if all_events:
    print(class="hl-string">"Combining all events...")
    final_df = pd.concat(all_events, ignore_index=True)
    final_df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'], inplace=True)
    
    class=class="hl-string">"hl-comment"># Fill forward attributes for a complete log
    attributes_to_fill = [class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate', class="hl-string">'DunningLevel']
    for attr in attributes_to_fill:
        if attr not in final_df.columns:
            final_df[attr] = None
    
    final_df[attributes_to_fill] = final_df.groupby(class="hl-string">'InvoiceNumber')[attributes_to_fill].fillna(method=class="hl-string">'ffill').fillna(method=class="hl-string">'bfill')
    
    final_df = final_df.dropna(subset=[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime'])
    
    output_filename = class="hl-string">'d365_collections_event_log.csv'
    final_df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f')
    print(fclass="hl-string">"Event log successfully created: {output_filename}")
else:
    print(class="hl-string">"No events were extracted. Please check your configuration and date range.")

Chcete začít?

Pomocí této šablony připravíte data a získáte užitečný přehled o správě úvěrů a vymáhání pohledávek. Začněte zlepšovat proces a zrychlete cash flow.

Zpět na průvodce zlepšováním

Stáhnout šablonu

Zlepšete správu úvěrů a vymáhání pohledávek a získejte peníze rychleji

Zlepšete cash flow zefektivněním procesu od úvěru po inkaso a zkraťte jeho dobu o 30 %.

Spustit zkušební verzi

Platební kartu nepotřebujete. Nastavení zabere jen několik minut.

Datová šablona pro správu úvěrů a vymáhání pohledávek

Datová šablona pro správu úvěrů a vymáhání pohledávek

Atributy správy úvěrů a vymáhání pohledávek

Aktivity správy úvěrů a vymáhání pohledávek

Návody k extrakci dat

Přímý dotaz SQL přes Bring Your Own Database (BYOD)

Kroky

Konfigurace

Ukázkový dotaz sql

Python skript využívající REST API OData v Dynamics 365

Kroky

Konfigurace

Ukázkový dotaz python

Chcete začít?

Zlepšete správu úvěrů a vymáhání pohledávek a získejte peníze rychleji