> Průběžné zlepšování procesů > Fakturace v procesu od objednávky po platbu > Microsoft Dynamics 365 > Datová šablona

Šablona dat pro proces od objednávky k platbě: fakturace a vystavování faktur

Microsoft Dynamics 365

Atributy procesu od objednávky k platbě: fakturace a vystavování faktur(18) Aktivity procesu od objednávky k platbě: fakturace a vystavování faktur(12) Návody k získání dat(2)

Šablona dat pro proces od objednávky k platbě: fakturace a vystavování faktur

Tato šablona vám ukáže, jaká data shromáždit pro analýzu procesu od objednávky k platbě, včetně fakturace a vystavování faktur. Najdete v ní doporučené atributy pro záznam událostí, aktivity, které je vhodné sledovat, i praktické pokyny k získání těchto dat. Pomůže vám rychle připravit data pro process mining.

Doporučené atributy ke shromáždění
Aktivity, které je vhodné sledovat
Pokyny k získání dat z Microsoft Dynamics 365

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 procesu od objednávky k platbě: fakturace a vystavování faktur

Toto jsou doporučená datová pole pro záznam událostí, který použijete k podrobné analýze procesu od objednávky k platbě, včetně fakturace a vystavování faktur.

3 Povinné 6 Doporučené 9 Volitelné

	Název	Popis
	Číslo faktury InvoiceNumber	Jedinečný identifikátor každé zákaznické faktury, který slouží jako hlavní identifikátor případu ve fakturačním procesu.
Popis Číslo faktury je hlavním identifikátorem, který sdružuje všechny činnosti související s jedním fakturačním dokladem. Umožňuje analyzovat celý životní cyklus faktury, od vystavení a schválení až po platbu zákazníka a konečné uzavření. Pokud ho použijete jako ID případu, každý záznam událostí se vztahuje ke konkrétní faktuře. Můžete tak podrobně analyzovat varianty, vypočítat dobu cyklu a sledovat výkonnost jednotlivých fakturačních transakcí. Proč je to důležité Tento atribut je nezbytný pro sledování celého životního cyklu faktury a analýzu efektivity procesu, úzkých míst i odchylek u každého fakturačního dokladu. Kde data získat Tento údaj se obvykle nachází v modulu Prodej a marketing, například v tabulce CustInvoiceJour (pole InvoiceId), nebo je dostupný prostřednictvím datových entit, jako je SalesInvoiceHeaderV2. Příklady CIV-001254INV-2023-9876US-004321
	Čas události EventTime	Přesné časové razítko, které udává, kdy došlo ke konkrétní činnosti nebo události.
Popis Čas události, označovaný také jako časové razítko, zaznamenává přesné datum a čas každé činnosti v procesu. Je nezbytný pro všechny časové analýzy v process miningu. Používá se k výpočtu doby mezi činnostmi, celkové doby případu a výkonnosti procesu v čase. Přesná a spolehlivá časová razítka jsou základem KPI, jako jsou Days Sales Outstanding a doba vystavení faktury. Proč je to důležité Tento atribut je základem analýzy výkonnosti a času. Umožňuje vypočítat dobu mezi kroky, celkovou dobu trvání i průchodnost a měřit tak efektivitu procesu. Kde data získat Časová razítka pocházejí z různých polí data a času v tabulkách Dynamics 365. Například pro vystavení faktury lze použít CreatedDateTime v tabulce CustInvoiceJour, případně konkrétní časová razítka z historie workflow. Příklady 2023-04-15T10:22:15Z2023-05-01T14:05:00Z2023-05-10T09:00:30Z
	Název činnosti ActivityName	Název obchodní činnosti nebo události, která nastala v určitém okamžiku životního cyklu faktury.
Popis Tento atribut popisuje konkrétní krok nebo milník ve fakturačním procesu, například „Faktura vystavena“, „Faktura schválena“ nebo „Platba od zákazníka přijata“. Posloupnost těchto činností tvoří průběh procesu. Analýza činností je základem process miningu. Umožňuje odhalovat modely procesů a jejich varianty a měřit výkonnost mezi jednotlivými kroky. Proč je to důležité Určuje jednotlivé kroky procesu a umožňuje zobrazit mapy procesů, analyzovat varianty a odhalit úzká místa nebo odchylky od stanoveného postupu. Kde data získat Tento atribut se obvykle odvozuje z více zdrojů, například z polí změny stavu (např. DocumentState), vyplněných polí s datem nebo záznamů historie workflow v Microsoft Dynamics 365. Příklady Faktura vystavenaFaktura schválenaPlatba od zákazníka přijataVystaven dobropis
	Částka faktury InvoiceAmount	Celková peněžní hodnota faktury.
Popis Tento atribut udává celkovou částku k úhradě na faktuře. Jde o důležitý ukazatel pro finanční analýzu, který umožňuje rozdělit faktury podle hodnoty. Analytici se například mohou zaměřit na faktury s vysokou hodnotou a zjistit, jak se u nich liší platební chování nebo zda jejich schvalování trvá déle. Údaj je také základem pro výpočet celkové hodnoty neuhrazených faktur a DSO. Proč je to důležité Umožňuje analyzovat finanční dopad a filtrovat i rozdělovat procesy podle peněžní hodnoty. Můžete tak upřednostnit faktury s vysokou hodnotou a porozumět jejich specifickému průběhu. Kde data získat Najdete ji v tabulce CustInvoiceJour, obvykle v poli, jako je InvoiceAmount. Dostupná je také v souvisejících transakčních tabulkách. Příklady 5430.5012500.00750.25
	Datum splatnosti PaymentDueDate	Datum, do kterého má zákazník fakturu zaplatit.
Popis Datum splatnosti je důležitý údaj, který se vypočítává z data vystavení faktury a platebních podmínek zákazníka. Slouží jako základ pro měření včasnosti plateb. Je nezbytný pro dashboard „Analýza dodržování platebních podmínek“ a pro výpočet KPI, jako jsou „Podíl včas uhrazených faktur“ a „Days Sales Outstanding“. Porovnáním data splatnosti se skutečným datem úhrady zjistíte, jak zákazníci platí a jak efektivní je proces vymáhání pohledávek. Proč je to důležité Jde o základní údaj pro měření platební výkonnosti. Je nezbytný pro výpočet podílu včas uhrazených faktur a analýzu dodržování platebních podmínek zákazníků. Kde data získat Obvykle ho najdete v tabulce CustInvoiceJour v poli, jako je DueDate. Příklady 2023-05-152023-06-302023-07-01
	Název zákazníka CustomerName	Název zákazníka, kterému byla faktura vystavena.
Popis Název zákazníka poskytuje snadno čitelnou identifikaci firmy nebo osoby, které je faktura vystavena. V rámci process mining analýzy umožňuje rozdělit fakturační proces podle zákazníků. Můžete tak zjistit, kteří zákazníci pravidelně platí včas, kteří se často opozdí nebo zda se u některých skupin zákazníků objevují odlišné varianty procesu či zpoždění. Tento údaj je důležitý pro dashboardy zaměřené na platební chování zákazníků a analýzu Days Sales Outstanding. Proč je to důležité Umožňuje analyzovat proces podle zákazníků a odhalit jejich specifické chování, platební vzorce nebo problémy v procesu. Kde data získat Údaj se získá propojením dat faktury s tabulkou kmenových dat zákazníků, obvykle CustTable, podle čísla zákaznického účtu. Příklady Contoso Ltd.Fabrikam, Inc.Northwind Traders
	Oddělení Department	Obchodní oddělení přiřazené uživateli nebo činnosti.
Popis Tento atribut přiřazuje činnost nebo uživatele ke konkrétnímu organizačnímu oddělení, například k oddělení pohledávek nebo prodeje. Umožňuje sledovat výkon procesu na vyšší úrovni než u jednotlivých uživatelů. Analýza podle oddělení pomáhá porozumět předávání práce mezi týmy, porovnat jejich efektivitu a odhalit úzká místa na úrovni oddělení. Tyto údaje využívá dashboard „Vytížení oddělení fakturace“. Proč je to důležité Umožňuje analyzovat výkon na úrovni organizace, porovnávat efektivitu různých týmů a sledovat, jak předávání práce mezi odděleními ovlivňuje proces. Kde data získat Tento údaj obvykle není přímo uveden v transakci faktury. Získá se propojením ID UserResponsible se záznamem zaměstnance nebo uživatele, který obsahuje informace o oddělení. Příklady PohledávkyFinanceProvoz fakturace
	Odpovědný uživatel UserResponsible	Uživatel nebo zaměstnanec odpovědný za provedení konkrétní činnosti.
Popis Tento atribut označuje osobu, která provedla konkrétní úkol ve fakturačním procesu, například schválila fakturu nebo zaúčtovala platbu. Je důležitý pro analýzu vytížení, porovnání výkonu a zjištění potřeb školení. Dashboard „Vytížení oddělení fakturace“ například využívá tento atribut ke zjištění, zda je práce rozdělená rovnoměrně, nebo zda některý uživatel představuje úzké místo. Pomáhá také porozumět rozdělení zdrojů a efektivitě. Proč je to důležité Umožňuje analyzovat proces na úrovni zdrojů, odhalovat úzká místa, měřit výkon jednotlivců i týmů a sledovat rozložení pracovní zátěže v oddělení fakturace. Kde data získat Údaj lze získat z protokolů historie workflow (například WorkflowTrackingStatusTable) nebo z polí vlastníka, jako jsou Owner či ModifiedBy, v příslušných tabulkách. Příklady John SmithAlicia BakerSprávce systému
	Stav faktury InvoiceStatus	Aktuální stav faktury v průběhu jejího životního cyklu (například otevřená, uhrazená nebo stornovaná).
Popis Tento atribut ukazuje, v jakém stavu se faktura právě nachází. Udává, zda čeká na úhradu, byla plně uhrazena, je po splatnosti nebo byla stornována dobropisem. Můžete podle něj filtrovat případy a analyzovat pouze otevřené faktury nebo ověřit konečný výsledek uzavřené faktury. Pomáhá porozumět aktuálnímu objemu práce i finančnímu stavu pohledávek. Proč je to důležité Rychle ukazuje aktuální stav faktury. Můžete podle něj filtrovat případy a porozumět výsledkům různých variant procesu. Kde data získat Stav lze odvodit z platebního stavu faktury, například ověřením, zda je zůstatek v souvisejícím záznamu CustTrans nulový. Samostatné pole „stav“ nemusí být vždy k dispozici. Příklady OtevřenáUhrazenáPo splatnostiStornovaná
	Bylo nutné přepracování IsRework	Příznak označující, zda proces faktury zahrnoval opakované zpracování, například vícenásobné schvalování.
Popis Jde o vypočítaný booleovský atribut, který označuje faktury, u nichž bylo nutné opakované zpracování. To lze definovat například jako více událostí „Faktura schválena“ nebo storna plateb. Atribut je určen pro dashboard „Analýza opakovaného zpracování faktur“ a KPI „Míra opakovaného zpracování faktur“. Analytici mohou tyto případy oddělit a zkoumat příčiny opakovaného zpracování, které často souvisejí s neefektivitou procesu, problémy s kvalitou dat nebo nedostatečným školením. Proč je to důležité Tento příznak přímo ukazuje neefektivitu procesu tím, že označuje případy s opakovanými nebo opravnými kroky. Pomáhá tak určit příčiny plýtvání a zpoždění. Kde data získat Tento atribut není ve zdrojovém systému k dispozici. Vypočítává se ve vrstvě transformace dat na základě opakovaných činností nebo konkrétních vzorců přepracování v rámci případu. Příklady truefalse
	Číslo prodejní objednávky SalesOrderNumber	Identifikátor prodejní objednávky, na jejímž základě byla vystavena faktura.
Popis Číslo prodejní objednávky propojuje fakturační proces s předcházejícím prodejním procesem. Toto propojení je cenné pro širší analýzu procesu Order-to-Cash od začátku do konce. Analytici mohou zkoumat, jak problémy v prodeji a plnění objednávek, například změny objednávky nebo zpoždění dodávky, ovlivňují fakturační cyklus. Lze tak například zjistit, zda se faktury za složitější prodejní objednávky hradí déle. Proč je to důležité Tento atribut propojuje fakturační proces s předcházejícím prodejním procesem. Umožňuje tak podrobnější analýzu Order-to-Cash od začátku do konce a pomáhá odhalit příčiny problémů s fakturací. Kde data získat Najdete ho v hlavičce faktury nebo v podrobnostech řádku, kde odkazuje na prodejní objednávku. V tabulce CustInvoiceJour hledejte pole, jako je SalesId. Příklady SO-009876SO-010234US-SO-00543
	Days Sales Outstanding DaysSalesOutstanding	Počet dní mezi vystavením faktury a přijetím platby od zákazníka.
Popis Days Sales Outstanding (DSO) je finanční ukazatel, který měří průměrný počet dní potřebných k inkasu platby po uskutečnění prodeje. Tento vypočítaný atribut určuje dobu pro každou jednotlivou fakturu. Je hlavním ukazatelem pro dashboard „Analýza trendu Days Sales Outstanding“ a KPI „DSO“. Analýza DSO pomáhá řídit peněžní tok a hodnotit efektivitu správy úvěrů a vymáhání pohledávek. Proč je to důležité Jde o důležitý KPI pro měření stavu peněžního toku společnosti a efektivity procesu vymáhání pohledávek. Ukazuje, jak rychle se tržby mění na hotovost. Kde data získat Tento atribut není ve zdrojovém systému. Vypočítává se jako doba mezi činnostmi „Faktura vystavena“ a „Platba od zákazníka přijata“. Příklady 284592
	Měna Currency	Kód měny, ve které je uvedena částka faktury (například USD nebo EUR).
Popis Tento atribut určuje měnu, ve které je částka faktury vyjádřena. Je nezbytný pro mezinárodní organizace pracující s různými měnami. Bez této informace by sčítání nebo porovnávání částek faktur nedávalo smysl. Umožňuje správný přepočet měn a přesné finanční výkaznictví i analýzu napříč regiony. Proč je to důležité Poskytuje nezbytný kontext pro finanční ukazatele, jako je částka faktury. Zabraňuje nesprávnému sčítání a umožňuje přesnou analýzu v prostředí s více měnami. Kde data získat Najdete ji v tabulce CustInvoiceJour, obvykle v poli, jako je CurrencyCode. Příklady USDEURGBP
	Platba byla včas IsOnTimePayment	Příznak označující, zda byla platba zákazníka přijata nejpozději v den splatnosti.
Popis Tento vypočítaný booleovský atribut porovnává časové razítko události „Platba od zákazníka přijata“ s datem splatnosti. U každé faktury označuje, zda byla uhrazena včas, nebo se zpožděním. Je základem pro výpočet KPI „Podíl včas uhrazených faktur“ a hojně se využívá v dashboardu „Analýza dodržování platebních podmínek“. Poskytuje jednoznačný výsledek platební výkonnosti a zjednodušuje analýzu i vykazování. Proč je to důležité Přímo měří, zda zákazníci dodržují platební podmínky, a slouží jako základ KPI „Podíl včas uhrazených faktur“. Zjednodušuje tak analýzu efektivity vymáhání pohledávek. Kde data získat Tento atribut není ve zdrojovém systému. Vypočítává se při transformaci dat porovnáním data platby s PaymentDueDate. Příklady truefalse
	Platební podmínky PaymentTerms	Dohodnuté podmínky úhrady faktury (například 30 nebo 60 dní).
Popis Platební podmínky určují, kdy má zákazník fakturu zaplatit. Tento atribut se používá k výpočtu data splatnosti a je důležitým hlediskem při analýze platebního chování. Dashboard „Analýza dodržování platebních podmínek“ podle tohoto atributu seskupuje zákazníky a faktury. Můžete tak zjistit, zda jsou některé platební podmínky účinnější nebo zda souvisejí s častějším opožděným placením. Proč je to důležité Vysvětluje, proč je faktura splatná v určitém termínu, a umožňuje rozdělit analýzu podle platebních podmínek. Zjistíte tak, zda některé podmínky souvisejí s opožděnými platbami. Kde data získat Údaj se obvykle ukládá do kmenového záznamu zákazníka a následně se kopíruje do hlavičky faktury. V tabulce CustInvoiceJour hledejte pole Payment nebo PaymTermId. Příklady Splatnost do 30 dnůSplatnost do 60 dnůSplatnost při doručení
	Poslední aktualizace dat LastDataUpdate	Časové razítko poslední aktualizace dat této události ze zdrojového systému.
Popis Tento atribut zaznamenává, kdy byla data naposledy extrahována nebo aktualizována ze systému Microsoft Dynamics 365. Jde o metadata důležitá pro posouzení aktuálnosti analyzovaných dat. Analytici i uživatelé z byznysu tak vědí, zda pracují s nejnovějšími informacemi. Údaj je také důležitý pro plánování obnovy dat a spolehlivost analýzy. Proč je to důležité Uživatelé díky němu vědí, jak jsou data aktuální. To je důležité pro správu dat, plánování obnovy dashboardů i důvěru v aktuálnost získaných poznatků. Kde data získat Tento atribut se vytvoří a připojí k datové sadě při procesu extrakce, transformace a načítání dat (ETL). Příklady 2023-06-20T05:00:00Z2023-06-21T05:00:00Z
	Vyžaduje ruční zásah RequiresManualIntervention	Příznak označující, zda bylo při přiřazení platby k faktuře nutné ruční upravení.
Popis Tento booleovský atribut označuje platby, které při přiřazení k faktuře vyžadovaly ruční zásah nebo opravu. Je důležitý pro KPI „Míra nesrovnalostí při přiřazování plateb“, protože pomáhá měřit přesnost a míru automatizace účtování plateb. Zjištění příčin ručních zásahů, například chybějících údajů o platbě nebo nesrovnalostí v platbě, může vést ke zlepšení procesu a zvýšení podílu plně automatického zpracování. Proč je to důležité Tento atribut pomáhá odhalit překážky a nepřesnosti při přiřazování plateb k fakturám. To je důležité pro zvýšení automatizace a omezení ruční práce. Kde data získat Informaci lze odvodit z uživatele, který platbu zaúčtoval, pokud nejde o systémového uživatele, nebo z konkrétních kódů důvodů použitých při párování plateb. Podrobnosti najdete v dokumentaci Microsoft Dynamics 365. Příklady truefalse
	Zdrojový systém SourceSystem	Systém, ze kterého byla data získána.
Popis Tento atribut označuje původ procesních dat. V tomto případě určuje, že data pocházejí ze systému Microsoft Dynamics 365. V prostředí s více systémy je to důležité pro rozlišení zdrojů dat a zajištění jejich dohledatelnosti, což usnadňuje ověřování dat i řešení problémů. Proč je to důležité Poskytuje důležitý kontext o původu dat, který je nezbytný pro správu a ověřování dat i pro slučování dat z více podnikových systémů. Kde data získat Jde o statickou hodnotu, která se přidává při extrakci a transformaci dat a označuje původ datové sady. Příklady Microsoft Dynamics 365 FinanceD365 F&O

Povinné Doporučené Volitelné

Aktivity procesu od objednávky k platbě: fakturace a vystavování faktur

Toto jsou důležité kroky a milníky, které je třeba zaznamenat do záznamu událostí pro přesné zjišťování a analýzu procesů.

7 Doporučené 5 Volitelné

	Aktivita	Popis
	Faktura odeslána zákazníkovi	Tato činnost označuje okamžik, kdy byla faktura odeslána zákazníkovi elektronicky nebo fyzicky. V Dynamics 365 může jít o výslovně zaznamenanou událost, pokud se faktura odesílá e-mailem ze systému. Pokud se odeslání samostatně nesleduje, lze je odvodit z času zaúčtování.
Proč je to důležité Měří efektivitu doručování faktur. Prodleva mezi schválením a odesláním zbytečně prodlužuje platební cyklus. Kde data získat Pokud používáte e-mailové funkce D365, lze událost zaznamenat přímo z e-mailových záznamů, například v SysOutgoingEmailTable. Jinak se často odvozuje z času zaúčtování faktury v CustInvoiceJour. Zachycení Pokud je k dispozici, použijte časové razítko z e-mailového záznamu. Jinak použijte časové razítko zaúčtování faktury. Typ události inferred
	Faktura schválena	Označuje dokončení interní kontroly a formální schválení faktury. Událost zaznamenává systém workflow Dynamics 365 a znamená, že fakturu lze odeslat zákazníkovi.
Proč je to důležité Jde o důležitý milník při měření doby schvalování. Prodlení v této fázi může přímo prodloužit dobu do přijetí platby od zákazníka. Kde data získat Událost se zaznamenává v tabulkách historie workflow, například WorkflowTrackingStatusTable, jako dokončení nebo schválení konkrétní instance workflow faktury. Zachycení Získejte záznamy událostí workflow, u kterých má stav hodnotu 'Approved' nebo 'Completed'. Typ události explicit
	Faktura uzavřena	Tato činnost označuje konečný stav faktury, kdy je její zůstatek nulový, protože byla plně uhrazena nebo vypořádána dobropisy. Nejde o přímou transakci, ale o stav odvozený z finančních údajů faktury.
Proč je to důležité Tato událost označuje úspěšné dokončení cyklu Order to Cash u jedné faktury. Doba do dosažení tohoto stavu je hlavním ukazatelem celkové efektivity procesu. Kde data získat Stav se odvozuje kontrolou zůstatku transakce faktury v tabulce CustTrans. Zůstatek je nulový, pokud se částka faktury rovná celkové částce vypořádaných plateb. Zachycení Odvoďte událost ze záznamů CustTrans, kde se AmountCur rovná SettleAmountCur. Časovým razítkem je datum posledního vypořádání. Typ události inferred
	Faktura vystavena	Označuje vytvoření a zaúčtování prodejní faktury v systému. Jde o výslovně zaznamenanou transakci v Dynamics 365, která vytvoří právní doklad a finanční zápisy v pomocné knize pohledávek.
Proč je to důležité Tímto okamžikem oficiálně začíná fakturační cyklus. Jde o důležitou událost pro sledování Days Sales Outstanding (DSO) i celkové doby trvání procesu. Kde data získat Událost se zaznamenává podle časového razítka vytvoření zaúčtované prodejní faktury v tabulce CustInvoiceJour. Při zaúčtování vznikají odpovídající finanční transakce v tabulkách GeneralJournalEntry a LedgerEntry. Zachycení U zaúčtované faktury použijte pole CreatedDateTime z tabulky CustInvoiceJour. Typ události explicit
	Nastalo datum splatnosti	Jde o vypočítanou událost, která nastane v den splatnosti faktury, pokud platba nebyla plně přiřazena. Neodpovídá transakci v systému, ale odvozuje se z existujících dat.
Proč je to důležité Tato událost je důležitá pro analýzu včasných plateb a odhalení faktur, které se dostávají po splatnosti. Slouží jako podnět k zahájení vymáhání pohledávky a upomínání. Kde data získat Událost se nezaznamenává přímo. Vypočítá se z pole DueDate v tabulce CustInvoiceJour. Časovým razítkem události je samotné datum splatnosti. Zachycení Vytvořte událost, jejíž časové razítko odpovídá hodnotě pole CustInvoiceJour.DueDate. Typ události calculated
	Platba od zákazníka přijata	Tato činnost označuje vytvoření deníkového záznamu o přijaté platbě od zákazníka. Znamená, že peníze byly přijaty, ale zatím nebyly přiřazeny ke konkrétní faktuře.
Proč je to důležité Jde o výchozí bod pro měření doby přiřazení platby. Umožňuje rozlišit přijetí peněz od jejich následného odsouhlasení s neuhrazenými fakturami. Kde data získat Událost se získává z vytvoření nebo zaúčtování deníku zákaznických plateb. Zaznamenává se například v tabulce LedgerJournalTrans a při zaúčtování se vytvoří zákaznická transakce v CustTrans. Zachycení Použijte časové razítko zaúčtování deníku zákaznických plateb z tabulky LedgerJournalTable. Typ události explicit
	Platba přiřazena k faktuře	Označuje vypořádání zákaznické platby s konkrétní fakturou, čímž se sníží její neuhrazený zůstatek. V Dynamics 365 jde o samostatný krok, který propojí transakci platby s transakcí faktury.
Proč je to důležité Jde o důležitý milník pro přesný výpočet DSO a vyhodnocení efektivity týmu, který zpracovává platby. Označuje okamžik, kdy je platba plně odsouhlasena s fakturovanou částkou. Kde data získat Událost se zaznamenává v tabulce CustSettlement. Pole data vypořádání v této tabulce poskytuje časové razítko přiřazení konkrétní platby ke konkrétní faktuře. Zachycení Použijte TransDate nebo CreatedDateTime z tabulky CustSettlement. Typ události explicit
	Faktura odeslána ke schválení	Tato činnost označuje odeslání vystavené faktury do formálního schvalovacího workflow. Běžně se používá v organizacích, kde musí vedení fakturu před odesláním zákazníkovi zkontrolovat. Ve workflow enginu D365 se zaznamenává jako samostatný krok.
Proč je to důležité Sledování odeslání ke schválení umožňuje oddělit dobu vystavení faktury od čekání na schválení. Jde o první krok při analýze efektivity interní kontroly a schvalování. Kde data získat Událost se získává z tabulek historie workflow, například WorkflowTrackingStatusTable, filtrováním událostí odeslání souvisejících s dokladem faktury. Zachycení Získejte záznamy událostí workflow, u kterých má stav hodnotu 'Submitted'. Typ události explicit
	Odeslána upomínka	Označuje odeslání upomínky nebo výzvy k úhradě zákazníkovi kvůli faktuře po splatnosti. Dynamics 365 obsahuje formální proces upomínání, který tyto zprávy vytváří a zaznamenává.
Proč je to důležité Sledování upomínek pomáhá vyhodnotit účinnost procesu upomínání a zjistit, kolik upomínek je potřeba před přijetím platby. Kde data získat Jde o výslovně zaznamenanou událost, kterou lze získat z data vytvoření deníku upomínek v tabulce CustCollectionLetterJour. Deník je propojen s transakcí faktury po splatnosti. Zachycení Použijte časové razítko vytvoření z tabulky CustCollectionLetterJour. Typ události explicit
	Platba stornována	Tato činnost označuje storno dříve zaúčtované zákaznické platby. Může k němu dojít kvůli chybě při zaúčtování, nedostatku prostředků nebo jinému problému s platbou.
Proč je to důležité Storna plateb upozorňují na provozní chyby nebo problémy s platbami zákazníků. Analýza jejich četnosti pomáhá odhalit příčiny a zpřesnit přiřazování plateb. Kde data získat Událost se zaznamenává jako storno transakce v hlavní knize. Stornovaný deník lze identifikovat v GeneralJournalEntry, často pomocí příznaku nebo vazby na původní transakci. Zachycení Vyhledejte deníkové záznamy s příznakem storna nebo odkazem na stornovanou transakci. Typ události explicit
	Prodejní objednávka vyřízena	Tato činnost označuje okamžik, kdy bylo zboží odesláno nebo byla poskytnuta služba v rámci prodejní objednávky a může začít fakturace. V Microsoft Dynamics 365 se obvykle odvozuje od zaúčtování dodacího listu, které změní stav příslušných řádků prodejní objednávky.
Proč je to důležité Tato událost je výchozím bodem pro měření doby vystavení faktury. Znalost prodlevy mezi vyřízením objednávky a vystavením faktury pomáhá odhalit administrativní úzká místa, která mohou ovlivnit cash flow. Kde data získat Událost se odvozuje od data vytvoření záznamu dodacího listu propojeného s prodejní objednávkou. Používají se například tabulky CustPackingSlipJour a CustPackingSlipTrans, které souvisejí s prodejní objednávkou, na jejímž základě byla faktura vystavena. Zachycení Určete nejnovější datum zaúčtování dodacího listu pro prodejní objednávku spojenou s fakturou. Typ události inferred
	Vystaven dobropis	Označuje vytvoření dobropisu, obvykle kvůli opravě chyby ve fakturaci, úpravě ceny nebo vrácení zboží. Dobropis je v podstatě záporná faktura.
Proč je to důležité Časté vystavování dobropisů může ukazovat na systémové problémy při vyřizování objednávek nebo fakturaci. Analýza důvodů jejich vystavení je důležitá pro zlepšování procesů a omezení ztrát výnosů. Kde data získat Jde o výslovně zaznamenanou transakci. V tabulce CustInvoiceJour se uloží jako nová zaúčtovaná faktura se zápornou částkou. Často je propojena s původní fakturou pomocí referenčního pole. Zachycení V tabulce CustInvoiceJour vyhledejte záznamy se zápornou celkovou částkou a propojte je s původní fakturou. Typ události explicit

Doporučené Volitelné

Návody k získání dat

Jak získat data z Microsoft Dynamics 365

Kroky

Otevřete pracovní prostor Data Management: Přihlaste se do Microsoft Dynamics 365 Finance and Operations. Pomocí vyhledávacího pole najděte pracovní prostor Data management a otevřete ho. Slouží jako centrální místo pro import a export dat.
Vytvořte nový exportní projekt: V pracovním prostoru Data management klikněte na dlaždici Export a vytvořte projekt pro export dat. Zadejte výstižný název, například ProcessMind_O2C_Billing_Export, a popis.
Vyberte cílový formát dat: V nastavení projektu určete Target data format. Pro kompatibilitu s většinou nástrojů na transformaci dat vyberte CSV. Podle potřeby upravte nastavení formátu a zvolte běžný oddělovač a znak pro uzavření textu.
Přidejte požadované datové entity: Tento krok je nejdůležitější. Do projektu přidejte několik standardních datových entit, abyste zachytili všechny potřebné aktivity. U každé entity klikněte na Add entity a vyhledejte její název uvedený v části Query/Script. Přidejte tyto entity: Sales invoice headers V2, Sales packing slip headers, Workflow tracking status table, CustPaymentJournalLineEntity, Customer settlement a Dunning history letters.
Nastavte filtry entit: Pomocí filtrů omezte data na požadovaný rozsah. Minimálně filtrujte Sales invoice headers V2 podle pole InvoiceDate na konkrétní období, například posledních 6 měsíců. Omezte také data na právnické osoby (společnosti), které chcete analyzovat.
Spusťte export: Po přidání všech entit a nastavení filtrů klikněte v podokně akcí na tlačítko Export. Systém vytvoří úlohu a začne data zpracovávat na pozadí.
Sledujte průběh a stáhněte data: Průběh úlohy můžete sledovat v části Job history. Po úspěšném dokončení stáhněte exportovaný balíček dat. Bude ve formátu ZIP a bude obsahovat samostatný soubor CSV pro každou datovou entitu.
Rozbalte balíček: Rozbalte stažený soubor ZIP do místní složky. Získáte několik souborů CSV, jeden pro každou entitu.
Transformujte a spojte data: Surové soubory je třeba převést do jednoho záznamu událostí. Použijte nástroj pro přípravu dat, například Power Query, Python nebo pracovní databázovou oblast. V každém zdrojovém souboru vytvořte požadované sloupce: InvoiceNumber (ID případu), ActivityName (pevně zadaný název události, například „Vystavení faktury“) a EventTime (odpovídající datumové pole ze zdrojového souboru). Namapujte také další atributy, například InvoiceAmount a CustomerName.
Spojte transformovaná data: Pomocí operace union nebo append spojte transformovaná data ze všech zdrojových souborů do jedné tabulky. Vznikne tak jednotný záznam událostí, v němž každý řádek představuje jednu aktivitu v životním cyklu faktury.
Připravte soubor k nahrání: Zkontrolujte, že výsledný soubor CSV obsahuje správné názvy sloupců (InvoiceNumber, ActivityName, EventTime atd.) a že sloupec EventTime používá jednotný formát časového razítka, například YYYY-MM-DD HH:MI:SS. Soubor je nyní připravený k nahrání do ProcessMind.

Konfigurace

Datové entity: Export využívá sadu standardních datových entit D365. Mezi důležité entity patří Sales invoice headers V2 (faktury a dobropisy), Sales packing slip headers (vyřízení objednávek), CustPaymentJournalLineEntity (platby), Customer settlement (přiřazení plateb) a Workflow tracking status table (schvalování).
Formát exportu: Doporučeným cílovým formátem dat je CSV, který je široce kompatibilní s nástroji na transformaci dat.
Filtr období: U hlavních entit je důležité nastavit filtr období, zejména u Sales invoice headers V2 podle pole InvoiceDate. Doporučujeme rozsah 3 až 6 měsíců. Export zůstane přehledný a zároveň poskytne dostatek dat k analýze.
Filtr společnosti: Export omezte na konkrétní právnickou osobu nebo kód společnosti, kterou analyzujete. Zajistíte tak relevantní data a zmenšíte objem exportu.
Příprava a transformace dat: Po exportu je nutné data zpracovat mimo Dynamics 365. Exportované soubory spojte a upravte do podoby jednoho záznamu událostí. Obvykle k tomu slouží Power BI (Power Query), Python nebo SQL.
Předpoklady: Uživatel, který export spouští, musí mít v Dynamics 365 přiřazené odpovídající role zabezpečení. Obvykle potřebuje roli s oprávněním k pracovnímu prostoru Data management a přístup k požadovaným datovým entitám.

Ukázkový dotaz config

The following configuration outlines the data entities and field mappings required for the export project within the Dynamics 365 Data Management Framework. A post-processing script or tool is required to union these outputs into a single event log.

**1. Activity: Sales Order Fulfilled**
*   **Entity Name:** `Sales packing slip headers`
*   **Mapping:**
    *   `InvoiceNumber`: Use `SalesOrderNumber` as a key to later join to the invoice data and find the corresponding `InvoiceNumber`.
    *   `ActivityName`: 'Sales Order Fulfilled' (Hardcoded Value)
    *   `EventTime`: `DeliveryDate`
    *   `UserResponsible`: `CreatedBy`

**2. Activity: Invoice Generated**
*   **Entity Name:** `Sales invoice headers V2`
*   **Filter:** `InvoiceType` is not 'CreditNote'.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Invoice Generated' (Hardcoded Value)
    *   `EventTime`: `InvoiceDate` and `CreatedTime`
    *   `InvoiceAmount`: `TotalInvoiceAmount`
    *   `CustomerName`: `InvoiceCustomerName`
    *   `UserResponsible`: `CreatedBy`
    *   `PaymentDueDate`: `DueDate`
    *   `InvoiceStatus`: `DocumentState`

**3. Activities: Invoice Submitted for Approval & Invoice Approved**
*   **Entity Name:** `Workflow tracking status table`
*   **Filter:** `ContextTableName` is 'CustInvoiceJour'.
*   **Mapping:**
    *   `InvoiceNumber`: Join `ContextRecId` to `RecId` from `Sales invoice headers V2` to get the `InvoiceNumber`.
    *   `ActivityName`: Use a conditional rule, if `TrackingStatus` is 'Submitted', set to 'Invoice Submitted for Approval'; if 'Approved', set to 'Invoice Approved'.
    *   `EventTime`: `CreatedDateTime`
    *   `UserResponsible`: `User`

**4. Activity: Invoice Sent to Customer**
*   **Note:** This is an inferred event. The posting date is used as a proxy.
*   **Entity Name:** `Sales invoice headers V2`
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Invoice Sent to Customer' (Hardcoded Value)
    *   `EventTime`: `PostedDateTime` (or equivalent posting timestamp)

**5. Activity: Payment Due Date Reached**
*   **Note:** This is a calculated event generated during post-processing.
*   **Source Entity:** `Sales invoice headers V2`
*   **Logic:** For each invoice where the `DueDate` has passed and the invoice is not fully settled.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Payment Due Date Reached' (Hardcoded Value)
    *   `EventTime`: `DueDate`

**6. Activity: Payment Reminder Issued**
*   **Entity Name:** `Dunning history letters`
*   **Mapping:**
    *   `InvoiceNumber`: Join from the dunning history to the customer transactions to find the related `InvoiceNumber`.
    *   `ActivityName`: 'Payment Reminder Issued' (Hardcoded Value)
    *   `EventTime`: `DunningLetterDate`
    *   `UserResponsible`: `CreatedBy`

**7. Activity: Customer Payment Received**
*   **Entity Name:** `CustPaymentJournalLineEntity`
*   **Mapping:**
    *   `InvoiceNumber`: The `Invoice` field may be populated, but often settlements are needed to link payments to invoices. This might require staging the payment data first.
    *   `ActivityName`: 'Customer Payment Received' (Hardcoded Value)
    *   `EventTime`: `ReceivedDate` or `DocumentDate`
    *   `UserResponsible`: `CreatedBy`

**8. Activity: Cash Applied to Invoice**
*   **Entity Name:** `Customer settlement`
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Cash Applied to Invoice' (Hardcoded Value)
    *   `EventTime`: `TransDate`
    *   `UserResponsible`: `CreatedBy`

**9. Activity: Payment Reversed**
*   **Source Entity:** `Customer settlement`
*   **Logic:** Filter for transactions where a settlement was later reversed. This may require looking for cancellation markers.
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Payment Reversed' (Hardcoded Value)
    *   `EventTime`: Reversal transaction timestamp.

**10. Activity: Credit Note Issued**
*   **Entity Name:** `Sales invoice headers V2`
*   **Filter:** `InvoiceType` is 'CreditNote'.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Credit Note Issued' (Hardcoded Value)
    *   `EventTime`: `InvoiceDate`
    *   `InvoiceAmount`: `TotalInvoiceAmount` (will be negative)
    *   `CustomerName`: `InvoiceCustomerName`
    *   `UserResponsible`: `CreatedBy`

**11. Activity: Invoice Closed**
*   **Note:** This is an inferred event based on settlement data.
*   **Source Entity:** `Customer settlement`
*   **Logic:** Use the latest `TransDate` for an invoice from the settlement data where the invoice balance becomes zero.
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Invoice Closed' (Hardcoded Value)
    *   `EventTime`: The latest `TransDate` that resulted in the invoice being fully settled.

Kroky

Předpoklady: Nainstalujte Python 3.6 nebo novější a knihovny requests a pandas. Budete také potřebovat přihlašovací údaje servisního principálu (registrace aplikace) v Azure Active Directory, kterému byl udělen přístup k prostředí Dynamics 365 Finance & Operations.
Registrace aplikace: V Azure AD zaregistrujte novou aplikaci. Vytvořte tajný klíč klienta a poznamenejte si ID aplikace (klienta), ID adresáře (tenanta) a tajný klíč klienta. V Dynamics 365 přidejte ID aplikace v části System administration > Setup > Azure Active Directory applications a přidělte jí odpovídající uživatelská oprávnění ke čtení požadovaných datových entit.
Nastavte skript: Otevřete dodaný Python skript. Vyplňte konfigurační proměnné v jeho horní části, včetně d365_url, tenant_id, client_id, client_secret, company, start_date a end_date. Hodnota d365_url má být základní URL vašeho prostředí Dynamics 365, například https://your-d365-instance.operations.dynamics.com.
Ověření: Skript obsahuje funkci get_access_token, která pomocí vašich přihlašovacích údajů automaticky vyžádá přístupový token OAuth2 od platformy Microsoft Identity. Tento token slouží k autorizaci dalších volání API.
Získání dat: Spusťte skript v terminálu příkazem python your_script_name.py. Nejprve načte všechny zaúčtované prodejní faktury (CustInvoiceJour) v zadaném období. U každé faktury pak provede další volání API a získá související data o platbách, párování, dobropisech a historii workflow.
Vytvoření aktivit: Skript zpracuje surová data z několika koncových bodů API. Výslovně vytvoří řádek pro každou z 12 požadovaných aktivit. Například pro událost „Vystavení faktury“ použije entitu CustInvoiceJour a z entity CustSettlement načte data pro události „Přiřazení platby k faktuře“.
Odvozené události: Události jako „Uplynutí data splatnosti“ a „Uzavření faktury“ nejsou v Dynamics 365 přímými transakcemi. Skript je odvodí z data splatnosti faktury, jejího stavu a historie párování a přidá odpovídající záznamy do záznamu událostí.
Stránkování výsledků: Pomocná funkce fetch_all_data automaticky zpracovává stránkování. Rozhraní OData API Dynamics 365 vrací omezený počet záznamů na stránku. Funkce proto postupuje podle odkazu @odata.nextLink v odpovědi API a načte celý soubor dat.
Transformace a výstup dat: Po shromáždění všech událostí skript sestaví jeden seznam, převede ho na pandas DataFrame a sjednotí názvy sloupců na InvoiceNumber, ActivityName, EventTime a další požadované atributy.
Export do CSV: Nakonec skript uloží výsledný DataFrame do souboru CSV s názvem d365_billing_event_log.csv. Soubor je připravený k nahrání do ProcessMind nebo jiného nástroje pro process mining.

Konfigurace

URL D365: Základní URL instance Dynamics 365 Finance & Operations. Jde o hlavní koncový bod pro všechna volání API.
Přihlašovací údaje Azure AD: K ověření jsou potřeba hodnoty client_id, client_secret a tenant_id. Musí patřit aplikaci s přístupem pro čtení příslušných entit D365.
Společnost: Zadejte DataAreaId, který odpovídá právnické osobě v Dynamics 365, z níž chcete získat data, například „USMF“.
Období: Pomocí hodnot start_date a end_date omezte rozsah exportu. Pro první analýzu doporučujeme období 3 až 6 měsíců. Získáte dostatek variant průběhu procesu a zároveň udržíte objem dat na zvládnutelné úrovni.
Hlavní entity OData: Skript se dotazuje především na tyto entity: CustInvoiceJours, CustSettlements, CustTrans, CustCollectionLetterJours a WorkflowTrackingStatusTables. Ověřte, že nastavený uživatel má oprávnění ke čtení všech těchto entit.
Výkon: Získávání dat za dlouhé období nebo z velmi velké společnosti může být pomalé, protože skript provádí několik volání API za sebou. Doporučujeme spouštět ho mimo špičku a začít s kratším obdobím, abyste odhadli celkovou dobu běhu.

Ukázkový dotaz python

import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- Configuration ---
d365_url = class="hl-string">"https://[your-d365-instance].operations.dynamics.com" class=class="hl-string">"hl-comment"># Your D365 F&O URL
tenant_id = class="hl-string">"[Your Tenant ID]"
client_id = class="hl-string">"[Your Client ID]"
client_secret = class="hl-string">"[Your Client Secret]"
company = class="hl-string">"[Your Company DataAreaId, e.g., USMF]"
start_date = class="hl-string">"2023-01-01"
end_date = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- Authentication ---
def get_access_token():
    url = fclass="hl-string">"https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token"
    payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': client_id,
        class="hl-string">'client_secret': client_secret,
        class="hl-string">'scope': fclass="hl-string">"{d365_url}/.default"
    }
    response = requests.post(url, data=payload)
    response.raise_for_status()
    return response.json()[class="hl-string">'access_token']

class=class="hl-string">"hl-comment"># --- OData Helper ---
def fetch_all_data(access_token, resource_path):
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    full_url = fclass="hl-string">"{d365_url}/data/{resource_path}"
    results = []
    while full_url:
        response = requests.get(full_url, headers=headers)
        response.raise_for_status()
        data = response.json()
        results.extend(data[class="hl-string">'value'])
        full_url = data.get(class="hl-string">'@odata.nextLink')
    return results

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def main():
    print(class="hl-string">"Acquiring access token...")
    token = get_access_token()
    event_log = []
    today = datetime.now(timezone.utc).date()

    print(class="hl-string">"Fetching Invoices and Credit Notes...")
    invoice_filter = fclass="hl-string">"$filter=InvoiceDate ge {start_date} and InvoiceDate le {end_date}"
    invoice_fields = class="hl-string">"$select=InvoiceNumber,InvoiceDate,SalesOrderNumber,InvoiceAmount,CustomerAccount,Due_Date,WorkerSalespersonName,createdDateTime,RecId,SalesInvoiceHeader_SalesStatus"
    invoices = fetch_all_data(token, fclass="hl-string">"CustInvoiceJours?cross-company=true&{invoice_filter}&{invoice_fields}")

    class=class="hl-string">"hl-comment"># Create a lookup for invoice RecIds for workflow queries
    invoice_recid_map = {inv[class="hl-string">'RecId']: inv[class="hl-string">'InvoiceNumber'] for inv in invoices}

    for inv in invoices:
        case_id = inv[class="hl-string">'InvoiceNumber']
        invoice_amount = inv[class="hl-string">'InvoiceAmount']
        customer_name = inv.get(class="hl-string">'CustomerAccount', class="hl-string">'') class=class="hl-string">"hl-comment"># Placeholder, join to CustTable for name
        user_responsible = inv.get(class="hl-string">'WorkerSalespersonName', class="hl-string">'System')
        due_date = inv.get(class="hl-string">'Due_Date')
        invoice_status = inv.get(class="hl-string">'SalesInvoiceHeader_SalesStatus', class="hl-string">'Open')

        class=class="hl-string">"hl-comment"># Activity: Invoice Generated / Credit Note Issued
        activity_name = class="hl-string">'Credit Note Issued' if invoice_amount < 0 else class="hl-string">'Invoice Generated'
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': activity_name,
            class="hl-string">'EventTime': inv[class="hl-string">'createdDateTime'],
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })

        class=class="hl-string">"hl-comment"># Activity: Invoice Sent to Customer (proxy)
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Invoice Sent to Customer',
            class="hl-string">'EventTime': inv[class="hl-string">'InvoiceDate'],
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })
        
        class=class="hl-string">"hl-comment"># Activity: Sales Order Fulfilled (proxy via invoice date, complex to get actual packing slip date)
        class=class="hl-string">"hl-comment"># A more accurate query would trace SalesInvoiceLinesV2 -> SalesOrderLines -> CustPackingSlipJour
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Sales Order Fulfilled',
            class="hl-string">'EventTime': inv[class="hl-string">'InvoiceDate'], class=class="hl-string">"hl-comment"># Using InvoiceDate as a proxy
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })

        class=class="hl-string">"hl-comment"># Activity: Payment Due Date Reached (calculated)
        if due_date and pd.to_datetime(due_date).date() < today and invoice_status != class="hl-string">'Paid':
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Payment Due Date Reached',
                class="hl-string">'EventTime': due_date,
                class="hl-string">'InvoiceAmount': invoice_amount,
                class="hl-string">'CustomerName': customer_name,
                class="hl-string">'UserResponsible': class="hl-string">'System',
                class="hl-string">'Department': class="hl-string">'Finance',
                class="hl-string">'PaymentDueDate': due_date,
                class="hl-string">'InvoiceStatus': invoice_status
            })

    print(class="hl-string">"Fetching Settlements for Cash Applied and Invoice Closed events...")
    settlement_filter = fclass="hl-string">"$filter=InvoiceDate ge {start_date} and InvoiceDate le {end_date}"
    settlement_fields = class="hl-string">"$select=InvoiceNumber,SettlementDate,OffsetTransactionVoucher,OffsetRecId,CanBeReversed"
    settlements = fetch_all_data(token, fclass="hl-string">"CustSettlements?cross-company=true&{settlement_filter}&{settlement_fields}")

    class=class="hl-string">"hl-comment"># Group settlements by invoice
    settlements_by_invoice = pd.DataFrame(settlements).groupby(class="hl-string">'InvoiceNumber')

    for case_id, group in settlements_by_invoice:
        last_settlement = group.sort_values(class="hl-string">'SettlementDate').iloc[-1]

        for _, settlement in group.iterrows():
            class=class="hl-string">"hl-comment"># Activity: Cash Applied to Invoice
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Cash Applied to Invoice',
                class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'],
                class="hl-string">'UserResponsible': class="hl-string">'System',
                class=class="hl-string">"hl-comment"># Add other attributes from original invoice if needed
            })

            class=class="hl-string">"hl-comment"># Activity: Customer Payment Received (date of original payment)
            class=class="hl-string">"hl-comment"># This requires a second hop to CustTrans using OffsetRecId
            class=class="hl-string">"hl-comment"># For simplicity, we use settlement date as a proxy. A full implementation would query CustTrans.
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Customer Payment Received',
                class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'], class=class="hl-string">"hl-comment"># Proxy timestamp
                class="hl-string">'UserResponsible': class="hl-string">'System',
            })

            class=class="hl-string">"hl-comment"># Activity: Payment Reversed (if applicable)
            if settlement[class="hl-string">'CanBeReversed']: class=class="hl-string">"hl-comment"># A simplistic check, real logic is more complex
                 event_log.append({
                    class="hl-string">'InvoiceNumber': case_id,
                    class="hl-string">'ActivityName': class="hl-string">'Payment Reversed',
                    class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'], class=class="hl-string">"hl-comment"># Reversal date would be different in reality
                    class="hl-string">'UserResponsible': class="hl-string">'System',
                 })
        
        class=class="hl-string">"hl-comment"># Activity: Invoice Closed (inferred from last settlement)
        class=class="hl-string">"hl-comment"># This logic assumes the invoice is fully paid by the last settlement. A robust check would sum amounts.
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Invoice Closed',
            class="hl-string">'EventTime': last_settlement[class="hl-string">'SettlementDate'],
            class="hl-string">'UserResponsible': class="hl-string">'System',
        })

    print(class="hl-string">"Fetching Payment Reminders...")
    reminder_filter = fclass="hl-string">"$filter=CollectionLetterDate ge {start_date} and CollectionLetterDate le {end_date}"
    reminders = fetch_all_data(token, fclass="hl-string">"CustCollectionLetterJours?cross-company=true&{reminder_filter}")
    for rem in reminders:
        class=class="hl-string">"hl-comment"># Linking reminders to invoices can be complex. This is a simplified approach.
        if rem.get(class="hl-string">'InvoiceNum'):
            event_log.append({
                class="hl-string">'InvoiceNumber': rem[class="hl-string">'InvoiceNum'],
                class="hl-string">'ActivityName': class="hl-string">'Payment Reminder Issued',
                class="hl-string">'EventTime': rem[class="hl-string">'CollectionLetterDate'],
                class="hl-string">'UserResponsible': rem.get(class="hl-string">'UserId', class="hl-string">'System'),
            })

    print(class="hl-string">"Fetching Workflow History...")
    class=class="hl-string">"hl-comment"># This is a complex query. It requires knowing the TableId for CustInvoiceJour (e.g., 523)
    class=class="hl-string">"hl-comment"># The filter below is illustrative and needs to be adapted for your specific workflow setup.
    workflow_filter = fclass="hl-string">"$filter=createdDateTime ge {start_date}T00:00:00Z"
    wf_history = fetch_all_data(token, fclass="hl-string">"WorkflowTrackingStatusTables?cross-company=true&{workflow_filter}")
    for item in wf_history:
        if item.get(class="hl-string">'ContextRecId') in invoice_recid_map:
            case_id = invoice_recid_map[item[class="hl-string">'ContextRecId']]
            activity_name = None
            if item[class="hl-string">'TrackingStatus'] == class="hl-string">'Submitted':
                activity_name = class="hl-string">'Invoice Submitted for Approval'
            elif item[class="hl-string">'TrackingStatus'] == class="hl-string">'Approved':
                activity_name = class="hl-string">'Invoice Approved'
            
            if activity_name:
                event_log.append({
                    class="hl-string">'InvoiceNumber': case_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTime': item[class="hl-string">'createdDateTime'],
                    class="hl-string">'UserResponsible': item.get(class="hl-string">'User', class="hl-string">'System'),
                })

    print(fclass="hl-string">"Total events extracted: {len(event_log)}")
    if not event_log:
        print(class="hl-string">"No events found for the given criteria.")
        return

    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'])
    df.to_csv(class="hl-string">'d365_billing_event_log.csv', index=False)
    print(class="hl-string">"Event log saved to d365_billing_event_log.csv")

if __name__ == class="hl-string">"__main__":
    main()

Chcete začít?

Pomocí této šablony můžete začít zlepšovat fakturaci a vystavování faktur. Poskytněte týmu přehled, který potřebuje ke zvýšení efektivity a zlepšení cash flow.

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

Stáhnout šablonu

Omezte zpoždění fakturace a zlepšete proces od objednávky k platbě ještě dnes

Zkraťte fakturační cyklus o 30 % a získejte přehled o financích rychleji.

Začněte se zkušební verzí zdarma

Bez nutnosti zadávat platební kartu. Zkušební verze na 14 dní zdarma.

Šablona dat pro proces od objednávky k platbě: fakturace a vystavování faktur

Šablona dat pro proces od objednávky k platbě: fakturace a vystavování faktur

Atributy procesu od objednávky k platbě: fakturace a vystavování faktur

Aktivity procesu od objednávky k platbě: fakturace a vystavování faktur

Návody k získání dat

Export datových entit z Microsoft Dynamics 365

Kroky

Konfigurace

Ukázkový dotaz config

Python skript využívající webové API OData Dynamics 365

Kroky

Konfigurace

Ukázkový dotaz python

Chcete začít?

Omezte zpoždění fakturace a zlepšete proces od objednávky k platbě ještě dnes