> Ciągłe doskonalenie procesów > Zarządzanie kredytami i windykacja należności > Microsoft Dynamics 365 > Szablon danych

Szablon danych do zarządzania kredytami i windykacji

Microsoft Dynamics 365

← Wróć do przewodnika ulepszania procesów

Atrybuty procesu zarządzania kredytami i windykacji(19) Działania w procesie zarządzania kredytami i windykacji(12) Instrukcje wyodrębniania danych(2)

Szablon danych do zarządzania kredytami i windykacji

Ten szablon zawiera wskazówki dotyczące gromadzenia danych potrzebnych do analizy procesu zarządzania kredytami i windykacji. Opisuje wymagane atrybuty, działania do śledzenia oraz praktyczne sposoby wyodrębniania danych. Ułatwia przygotowanie danych i rozpoczęcie analizy procesu za pomocą process mining.

Zalecane atrybuty do zebrania na potrzeby pełnej analizy
Najważniejsze działania w procesie, które warto śledzić, aby dokładnie go odtworzyć
Praktyczne wskazówki dotyczące wyodrębniania danych z systemu

Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Pobierz szablon

Atrybuty procesu zarządzania kredytami i windykacji

Poniżej przedstawiono zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby kompleksowo przeanalizować proces zarządzania kredytami i windykacji.

3 Wymagane 8 Zalecane 8 Opcjonalne

	Nazwa	Opis
	Czas zdarzenia EventTime	Znacznik czasu wskazujący, kiedy wystąpiło konkretne działanie lub zdarzenie.
Opis Czas zdarzenia to dokładna data i godzina zarejestrowania działania w systemie. Jest podstawą process mining, ponieważ zapewnia kolejność chronologiczną potrzebną do odtworzenia przebiegu procesu i obliczenia wskaźników opartych na czasie. Atrybut ten jest niezbędny do analizy czasu trwania, wykrywania wąskich gardeł i monitorowania SLA. Na przykład różnica czasu między zdarzeniami „Wystawiono fakturę” i „Otrzymano płatność” służy do obliczenia Days Sales Outstanding (DSO), ważnego KPI. Bez dokładnych znaczników czasu nie można analizować wyników ani wykrywać wąskich gardeł. Dlaczego to ważne Znacznik czasu jest niezbędny do uporządkowania zdarzeń, odkrycia mapy procesu i obliczenia wskaźników efektywności, takich jak czas cyklu i czas trwania. Skąd pobrać Atrybut pochodzi z różnych pól daty i godziny w tabelach D365, na przykład „CreatedDateTime” w tabeli „CustInvoiceJour” lub „TransDate” w tabeli „CustTrans”, zależnie od działania. Przykłady 2023-01-15T09:30:00Z2023-02-28T14:12:55Z2023-03-20T11:05:10Z
	Nazwa działania ActivityName	Nazwa konkretnego zdarzenia lub zadania, które wystąpiło na danym etapie cyklu życia faktury.
Opis Nazwa działania opisuje konkretny krok lub zdarzenie w procesie zarządzania należnościami i windykacji, na przykład „Wystawiono fakturę”, „Wysłano wezwanie do zapłaty” lub „Otrzymano płatność”. Ten atrybut jest podstawą process mining, ponieważ określa węzły na mapie procesu. Analiza kolejności i częstotliwości działań pokazuje rzeczywisty przebieg procesu i pozwala wykryć pętle poprawek, nieefektywne działania oraz ścieżki niezgodne z procedurą. Atrybut ten służy do tworzenia wszystkich wizualizacji przebiegu procesu i obliczania czasu między jego etapami. Dlaczego to ważne Ten atrybut określa kroki na mapie procesu, dzięki czemu można wizualizować i analizować cykl życia faktury. Skąd pobrać Atrybut ten zwykle powstaje przez przypisanie konkretnych zdarzeń systemowych, zmian statusu lub dat utworzenia rekordów z różnych tabel, takich jak „CustInvoiceJour”, „CustTrans”, „CustCollectionLetterJour” i „CustPaymPromise”, do ustandaryzowanych nazw działań. Przykłady Zaksięgowanie i wysłanie fakturyUtworzenie wezwania do zapłatyZarejestrowano spórOtrzymano płatność
	Numer faktury InvoiceNumber	Unikatowy identyfikator każdej faktury klienta, używany jako główny identyfikator sprawy w procesie zarządzania należnościami.
Opis Numer faktury to ważny atrybut, który jednoznacznie identyfikuje każdą transakcję finansową z klientem. Łączy wszystkie powiązane działania, od wystawienia i zaksięgowania faktury po windykację płatności i końcowe rozliczenie. W process mining numer ten służy do odtworzenia pełnego przebiegu każdej faktury i szczegółowej analizy jej cyklu życia. Traktowanie każdej faktury jako osobnej sprawy pozwala organizacjom wykrywać typowe ścieżki procesu, wąskie gardła i odstępstwa od standardowej procedury. To podstawa obliczania wskaźników, takich jak Days Sales Outstanding, oraz analizy wariantów procesu. Dlaczego to ważne To podstawowy identyfikator sprawy, który łączy wszystkie zdarzenia procesu i umożliwia odtworzenie oraz analizę całego cyklu od wystawienia faktury do otrzymania płatności. Skąd pobrać Zwykle jest to pole „Invoice” z tabeli „CustInvoiceJour” w Microsoft Dynamics 365 Finance. Przykłady INV-0012345CIV-2023-8876SI-9510034
	Kwota faktury InvoiceAmount	Łączna wartość pieniężna faktury.
Opis Kwota faktury oznacza łączną wartość finansową zafakturowanych towarów lub usług. To podstawowy atrybut analizy finansowej procesu. Podział spraw według wartości pozwala sprawdzić, czy faktury o wysokiej wartości przechodzą inną ścieżkę lub są opóźnione. Atrybut ten jest niezbędny w dashboardach „Odpisy nieściągalnych faktur” i „Analiza zarządzania limitami kredytowymi”, które pomagają określić wpływ finansowy i ocenić ryzyko. Dlaczego to ważne Umożliwia analizę wpływu finansowego, ustalanie priorytetów dla faktur o wysokiej wartości oraz sprawdzenie, jak kwota faktury wpływa na przebieg procesu. Skąd pobrać Prawdopodobnie jest to pole „InvoiceAmount” w tabeli „CustInvoiceJour”. Przykłady 1500.7525000.00549.99
	Liczba dni po terminie DaysOverdue	Liczba dni, o które minął termin płatności faktury.
Opis Liczba dni po terminie to obliczany wskaźnik, który mierzy czas od terminu płatności nieopłaconej faktury. Oblicza się go jako różnicę między bieżącą datą a terminem płatności. To ważny KPI dla zespołu windykacyjnego, ponieważ pomaga ustalać priorytety obsługi faktur. Jest głównym wskaźnikiem w dashboardzie „Przeterminowane faktury według segmentu” i podstawą oceny stanu należności oraz skuteczności działań windykacyjnych. Dlaczego to ważne To ważny wskaźnik operacyjny, który pomaga ustalać priorytety działań windykacyjnych i oceniać skalę opóźnień płatności. Skąd pobrać To pole obliczane według reguły: JEŚLI faktura nie została opłacona, TO (Today() - PaymentDueDate), W PRZECIWNYM RAZIE 0. Przykłady 1532910
	Nazwa klienta CustomerName	Nazwa prawna klienta, na którego wystawiono fakturę.
Opis Nazwa klienta wskazuje, którego klienta dotyczy faktura. To podstawowy wymiar filtrowania i segmentacji. Analiza procesu według klienta pomaga wykryć tych, którzy regularnie płacą po terminie, zgłaszają spory lub wymagają intensywnych działań windykacyjnych. Atrybut ten jest ważny w dashboardzie „Czas rozpatrywania sporów” oraz przy szczegółowej analizie kont poszczególnych klientów. Dlaczego to ważne Umożliwia analizę procesu dla poszczególnych klientów, pomaga wykrywać wzorce i zarządzać relacjami z ważnymi lub problematycznymi klientami. Skąd pobrać Informacje te są zwykle pobierane z tabeli „CustTable” na podstawie numeru konta klienta w tabeli „CustInvoiceJour”. Przykłady Contoso Ltd.Adventure WorksFabrikam Inc.
	Poziom windykacji DunningLevel	Wskazuje bieżący etap lub stopień zaawansowania windykacji przeterminowanej faktury.
Opis Poziom windykacji oznacza etap ustrukturyzowanej procedury windykacyjnej, na przykład „Poziom 1: łagodne przypomnienie”, „Poziom 2: formalne wezwanie” lub „Poziom 3: ostateczne ostrzeżenie”. Śledzenie tego atrybutu jest niezbędne do oceny skuteczności strategii windykacyjnej. Dashboard „Skuteczność strategii windykacyjnej” pokazuje, jaki odsetek faktur zostaje opłacony po osiągnięciu każdego poziomu. Dzięki temu można usprawniać workflow windykacji, zwiększać skuteczność odzyskiwania należności i dbać o relacje z klientami. Dlaczego to ważne Pozwala ocenić skuteczność strategii windykacyjnej i sprawdzić, na którym etapie klienci najczęściej dokonują płatności. Skąd pobrać Informacje te można znaleźć w tabelach dotyczących windykacji i wezwań do zapłaty, takich jak „CustCollectionLetterJour”. Przykłady 123 - OstateczneDziałania prawne
	Przypisany windykator CollectorAssigned	Imię i nazwisko windykatora lub członka zespołu odpowiedzialnego za obsługę przeterminowanej faktury.
Opis Ten atrybut wskazuje pracownika odpowiedzialnego za działania windykacyjne dotyczące konkretnej faktury. Jest ważny przy analizie wyników i obciążenia pracą. Filtrowanie mapy procesu lub dashboardów według windykatora pozwala kierownikom oceniać indywidualną produktywność, porównywać strategie windykacji i wskazywać obszary wymagające wsparcia. Atrybut ten jest ważnym wymiarem dashboardów „Produktywność zespołu windykacyjnego” i „Czas rozpatrywania sporów”, ponieważ pozwala przypisać wyniki procesu konkretnym osobom lub zespołom. Dlaczego to ważne Umożliwia analizę wyników zespołu windykacyjnego, pomaga równoważyć obciążenie pracą i wskazuje dobre praktyki przez porównanie skuteczności windykatorów. Skąd pobrać Sprawdź dokumentację Microsoft Dynamics 365. Informacje mogą pochodzić z modułu zarządzania windykacją lub z pól określających osobę odpowiedzialną na kartach klienta albo transakcji. Przykłady Jan KowalskiAnna NowakZespół windykacyjny A
	Segment klienta CustomerSegment	Klasyfikacja klienta, na przykład według wielkości, branży lub znaczenia strategicznego.
Opis Segment klienta to atrybut kategoryczny służący do grupowania klientów w istotne grupy, na przykład „Klienci strategiczni”, „MŚP” lub „Sektor publiczny”. Taka segmentacja jest ważna w analizie strategicznej. Pomaga odpowiedzieć na pytania, takie jak „Czy klienci strategiczni mają niższy DSO?” lub „Czy odpisy częściej występują w określonym segmencie branżowym?”. Atrybut ten jest wykorzystywany bezpośrednio w dashboardach „Trend Days Sales Outstanding”, „Odpisy nieściągalnych faktur” i „Przeterminowane faktury według segmentu”, aby pokazać szerszy obraz niż analiza pojedynczych klientów. Dlaczego to ważne Umożliwia zbiorczą analizę grup klientów, pomaga wykrywać trendy strategiczne i dostosowywać działania windykacyjne do poszczególnych segmentów. Skąd pobrać Często jest to pole niestandardowe lub wartość wyprowadzona z atrybutów tabeli „CustTable” (kartoteki klientów). Przykłady Duże przedsiębiorstwoŚrednie przedsiębiorstwoSektor publicznyPartner
	Status faktury InvoiceStatus	Bieżący status faktury w jej cyklu życia.
Opis Status faktury pokazuje, na jakim etapie procesu znajduje się faktura, na przykład „Otwarta”, „Opłacona”, „Zakwestionowana” lub „Odpisana”. Dziennik działań zawiera szczegółową historię, a bieżący status jest przydatnym atrybutem sprawy do filtrowania i raportowania ogólnego. Analitycy mogą szybko wyodrębnić otwarte, przeterminowane faktury lub przeanalizować cechy wszystkich odpisanych faktur. To prosty sposób na sprawdzenie bieżącego stanu należności. Dlaczego to ważne Ułatwia filtrowanie i analizę faktur według ich bieżącego stanu, na przykład pozwala skupić się na wszystkich otwartych lub zakwestionowanych sprawach. Skąd pobrać Wartość jest wyprowadzana ze statusu rozliczenia transakcji w tabeli „CustTrans”. Otwarta transakcja jest nieopłacona, a zamknięta została rozliczona. Przykłady OtwartaOpłaconaCzęściowo opłaconaOdpisana
	Termin płatności PaymentDueDate	Data, do której zgodnie z umową należy opłacić fakturę.
Opis Termin płatności to ważna data określona w warunkach płatności uzgodnionych z klientem. Stanowi punkt odniesienia przy ustalaniu, czy faktura jest przeterminowana. To główny sygnał do rozpoczęcia działań windykacyjnych, takich jak wysłanie przypomnienia lub wszczęcie formalnej procedury windykacyjnej. W process mining służy do obliczania wskaźnika „Liczba dni po terminie” i sprawdzania zgodności z zasadami windykacji, na przykład tego, czy przypomnienie wysłano w ciągu X dni od upływu terminu płatności. Dlaczego to ważne Ta data jest punktem odniesienia przy ocenie terminowości płatności i wyznacza początek działań związanych z zaległościami i windykacją. Skąd pobrać Zwykle jest to pole „DueDate” w tabeli „CustTrans” lub „CustInvoiceJour”. Przykłady 2023-02-142023-03-312023-04-30
	Czas rozpatrywania sporu DisputeResolutionTime	Czas od pierwszego zarejestrowania sporu z klientem do jego rozwiązania.
Opis Czas rozpatrywania sporu mierzy efektywność procesu obsługi sporów. Oblicza się go jako czas między działaniami „Zarejestrowano spór” i „Rozwiązano spór”. Długi czas rozpatrywania może opóźniać płatność i obniżać zadowolenie klienta. Analiza tego wskaźnika według windykatora lub przyczyny sporu pomaga wykrywać wąskie gardła i obszary wymagające usprawnienia w workflow zarządzania sporami. Dlaczego to ważne Mierzy efektywność obsługi sporów, które często powodują znaczne opóźnienia płatności. Skąd pobrać Oblicza się go jako czas między znacznikami czasu działań „Zarejestrowano spór” i „Rozwiązano spór”. Przykłady 7.215.83.5
	Czy zakwestionowano fakturę IsDisputed	Wartość logiczna wskazująca, czy faktura była kiedykolwiek kwestionowana.
Opis To obliczana flaga ustawiana na true, jeśli sprawa dotycząca faktury zawiera działanie „Zarejestrowano spór”. Ułatwia analizę, ponieważ pozwala szybko filtrować lub porównywać przebieg procesu dla faktur zakwestionowanych i niezakwestionowanych. Można na przykład porównać średni DSO dla obu grup, aby określić wpływ sporów na przepływy pieniężne. Atrybut przydaje się w dashboardach ogólnych i analizach porównawczych. Dlaczego to ważne Ułatwia analizę i filtrowanie oraz porównywanie faktur zakwestionowanych z niezakwestionowanymi. Skąd pobrać To pole obliczane według reguły: JEŚLI sprawa zawiera działanie „Zarejestrowano spór”, TO true, W PRZECIWNYM RAZIE false. Przykłady truefalse
	Kod waluty CurrencyCode	Waluta faktury, na przykład USD lub EUR.
Opis Kod waluty określa walutę transakcji, w której podano kwotę faktury. To ważny atrybut kontekstowy, szczególnie w organizacjach międzynarodowych. Jest niezbędny do prawidłowej interpretacji wartości finansowych. Można go również wykorzystać do sprawdzenia, czy cykle płatności lub problemy z płatnościami są powiązane z określonymi walutami, na przykład ze względu na złożoność wymiany walut lub płatności międzynarodowych. Dlaczego to ważne Zapewnia niezbędny kontekst dla wszystkich wartości pieniężnych i umożliwia analizę procesów obejmujących wiele walut. Skąd pobrać Zwykle jest to pole „CurrencyCode” w tabeli „CustInvoiceJour”. Przykłady USDEURGBPCAD
	Kraj Country	Kraj adresu rozliczeniowego klienta.
Opis Ten atrybut określa kraj przypisany do konta klienta. Jest często używany w analizach geograficznych. Podział KPI procesu, takich jak DSO lub odsetek odpisów, według kraju może ujawnić regionalne różnice w zachowaniach płatniczych klientów, skuteczności windykacji lub warunkach gospodarczych. Na tej podstawie można dostosować działania windykacyjne do regionu lub stosować różne warunki płatności. Dlaczego to ważne Umożliwia analizę geograficzną i wykrywanie regionalnych trendów w zachowaniach płatniczych oraz wynikach procesu windykacji. Skąd pobrać Wartość jest pobierana z kartoteki klienta („CustTable”) i łączona z jego głównym adresem, często zapisanym w tabeli „LogisticsPostalAddress”. Przykłady USADEUGBRCAN
	Limit kredytowy CreditLimit	Maksymalna kwota kredytu przyznana klientowi.
Opis Limit kredytowy to łączna kwota zadłużenia, jaką klient może zaciągnąć. Atrybut ten jest ważny w zarządzaniu ryzykiem. Dashboard „Analiza zarządzania limitami kredytowymi” porównuje tę wartość z kwotami faktur dla zaległych lub odpisanych należności. Analiza pomaga ocenić, czy limity kredytowe są właściwie ustalone i egzekwowane oraz czy klienci, którzy nie spłacają zobowiązań, niedawno otrzymali wyższe limity. Może to wskazywać słabe punkty procesu przyznawania kredytu. Dlaczego to ważne Atrybut ten jest niezbędny do oceny ryzyka i pomaga sprawdzić, czy odpisy wynikają z niewłaściwie zarządzanych lub zbyt niskich limitów kredytowych klientów. Skąd pobrać Wartość jest zwykle przechowywana w kartotece klienta w tabeli „CustTable”. Przykłady 10000.0050000.000.00
	Ostatnia aktualizacja danych LastDataUpdate	Znacznik czasu ostatniego odświeżenia lub aktualizacji danych.
Opis Ten atrybut wskazuje, kiedy ostatnio zaktualizowano zbiór danych na podstawie systemu źródłowego. To ważna metadana dla osób korzystających z analizy process mining, ponieważ informuje o aktualności danych. Wiedza o tym, do jakiego momentu dane są aktualne, pomaga analitykom podejmować świadome decyzje i właściwie interpretować wyniki. Atrybut jest zwykle przypisywany do całego zbioru danych w trakcie jego wczytywania. Dlaczego to ważne Informuje o aktualności danych, dzięki czemu wiadomo, jakiego okresu dotyczą analizy, i można uniknąć decyzji opartych na nieaktualnych informacjach. Skąd pobrać Wartość jest generowana i zapisywana w zbiorze danych przez potok ETL lub potok danych podczas jego uruchomienia. Przykłady 2023-04-01T02:00:00Z2023-04-02T02:00:00Z
	Przyczyna sporu DisputeReason	Powód podany przez klienta, który zakwestionował fakturę.
Opis Klient kwestionujący fakturę zwykle podaje powód, na przykład „Nieprawidłowa cena”, „Uszkodzony towar” lub „Podwójne naliczenie”. Ten atrybut zapisuje przyczynę sporu. Analiza powodów jest ważna przy ustalaniu źródeł problemów. Pomaga wykrywać powtarzające się problemy w procesie od zamówienia do otrzymania płatności, na przykład w działach sprzedaży, wysyłki lub fakturowania. Ograniczenie liczby sporów u źródła jest jednym z głównych celów tej analizy. Bezpośrednio wpływa na DSO, ponieważ pozwala zapobiegać opóźnieniom płatności. Dlaczego to ważne Dostarcza danych potrzebnych do ustalenia przyczyn opóźnień płatności i pomaga wykrywać oraz usuwać problemy na wcześniejszych etapach, które prowadzą do sporów dotyczących faktur. Skąd pobrać Sprawdź dokumentację Microsoft Dynamics 365. Informacje te powinny być dostępne w funkcjach zarządzania sporami lub sprawami. Przykłady Błąd w cenieBrak części zamówionej ilościNie otrzymano produktuUsługa niezgodna z opisem
	System źródłowy SourceSystem	Wskazuje system, z którego pochodzą dane.
Opis Ten atrybut określa aplikację źródłową, w której zarejestrowano dane o zdarzeniu. W tym przypadku będzie to „Microsoft Dynamics 365”. W analizie jednego systemu wartość może się nie zmieniać, ale atrybut jest ważny dla zarządzania danymi, rozwiązywania problemów i przyszłych integracji. Jeśli uwzględnione zostaną dane z innych systemów, na przykład osobnego CRM lub portalu agencji windykacyjnej, pole to pozwoli je rozróżnić i zrozumieć pełny proces obejmujący wiele systemów. Dlaczego to ważne Zapewnia przejrzystość pochodzenia danych, pomaga utrzymać ich jakość i umożliwia analizę w wielu zintegrowanych systemach. Skąd pobrać Zwykle jest to stała wartość dodawana podczas ekstrakcji danych w celu oznaczenia źródła rekordów. Przykłady Microsoft Dynamics 365D365 F&O

Wymagane Zalecane Opcjonalne

Działania w procesie zarządzania kredytami i windykacji

Poniżej przedstawiono najważniejsze kroki i punkty kontrolne, które warto zapisać w dzienniku zdarzeń, aby dokładnie odtworzyć workflow zarządzania kredytami i windykacji.

9 Zalecane 3 Opcjonalne

	Działanie	Opis
	Odpisano fakturę	Uznano, że należności z faktury nie da się odzyskać, i formalnie odpisano ją jako nieściągalny dług. Upoważniony użytkownik wykonuje tę czynność, aby wyksięgować należność i zaksięgować stratę.
Dlaczego to ważne To główny niepomyślny punkt końcowy procesu. Śledzenie odpisów jest niezbędne do analizy ryzyka kredytowego, nieudanej windykacji i strat finansowych. Skąd pobrać Zdarzenie rejestrowane na podstawie konkretnej transakcji dziennika głównego służącej do odpisania nieściągalnego długu i powiązanej z pierwotną fakturą. Znacznikiem czasu jest data księgowania dziennika odpisów. Rejestrowanie Wskaż zapisy dziennika z określonym profilem księgowania odpisów, które odwołują się do faktury. Typ zdarzenia explicit
	Otrzymano płatność	Oznacza, że płatność od klienta wpłynęła i została wprowadzona do systemu, zwykle za pomocą dziennika płatności. Zdarzenie poprzedza ostateczne zaksięgowanie środków i rozliczenie nimi konkretnej faktury.
Dlaczego to ważne To ważny etap przy obliczaniu DSO i analizie przepływów pieniężnych. Czas między tym zdarzeniem a zaksięgowaniem płatności wskazuje na wąskie gardła w procesie rozliczania wpływów. Skąd pobrać Jawne zdarzenie rejestrowane na podstawie daty utworzenia wiersza dziennika płatności klienta (LedgerJournalTrans), zanim zostanie on zaksięgowany. Oznacza datę odnotowania otrzymanej płatności. Rejestrowanie Użyj daty transakcji z wierszy dziennika płatności klienta. Typ zdarzenia explicit
	Rozliczono fakturę	Faktura została w pełni opłacona, a jej saldo wynosi zero, co oznacza pomyślne zakończenie procesu. Ten status można wywnioskować, gdy suma rozliczonych płatności jest równa całkowitej kwocie faktury.
Dlaczego to ważne To główny pomyślny punkt końcowy procesu od kredytu do gotówki. Analiza ścieżek prowadzących do tego zdarzenia pozwala wskazać dobre praktyki i efektywne warianty procesu. Skąd pobrać Zdarzenie można wywnioskować z daty rozliczenia w tabeli rozliczeń klienta (CustSettlement). Występuje, gdy suma pól „AmountCur” i „SettleAmountCur” dla faktury w tabeli CustTrans wynosi zero. Rejestrowanie Wskaż najpóźniejszą datę rozliczenia powiązaną z transakcją faktury, po której saldo faktury wynosi zero. Typ zdarzenia inferred
	Upłynął termin płatności	Zdarzenie wyliczane, które występuje, gdy bieżąca data przekracza termin płatności faktury. Nie odpowiada ono bezpośrednio działaniu użytkownika. Jest ustalane przez porównanie daty systemowej z polem terminu płatności faktury.
Dlaczego to ważne To zdarzenie uruchamia działania windykacyjne. Umożliwia analizę liczby przeterminowanych faktur i terminowości działań, a także monitorowanie KPI, takich jak przestrzeganie zasad windykacji. Skąd pobrać Zdarzenie jest wyliczane przez porównanie bieżącego timestampu z polem „DueDate” w tabeli transakcji klienta (CustTrans). Timestampem zdarzenia jest sama wartość DueDate. Rejestrowanie Utwórz zdarzenie, gdy „NOW()” jest późniejsze niż DueDate faktury. Typ zdarzenia calculated
	Utworzenie wezwania do zapłaty	Oznacza utworzenie formalnego wezwania do zapłaty lub pisma windykacyjnego dotyczącego przeterminowanej faktury. Zdarzenie jest rejestrowane po uruchomieniu okresowego procesu windykacji w Dynamics 365, który tworzy wpisy dla odpowiednich faktur.
Dlaczego to ważne Zdarzenie pozwala śledzić rozpoczęcie i częstotliwość formalnych działań windykacyjnych. Jest niezbędne do pomiaru skuteczności windykacji i zgodności z wewnętrznymi zasadami. Skąd pobrać W tabeli historii windykacji (CustCollectionLetterJour) powstaje jawny rekord. Timestampem jest data utworzenia dziennika wezwania do zapłaty. Rejestrowanie Wyodrębnij zdarzenia utworzenia z tabeli CustCollectionLetterJour i powiąż je z fakturą. Typ zdarzenia explicit
	Wystawienie faktury	Oznacza utworzenie w systemie rekordu faktury sprzedaży przed jej oficjalnym zaksięgowaniem. Zdarzenie jest zwykle rejestrowane, gdy użytkownik finalizuje zamówienie sprzedaży i generuje odpowiadający mu dokument faktury.
Dlaczego to ważne To główne zdarzenie rozpoczynające cykl życia faktury. Czas od tego momentu do otrzymania płatności ma zasadnicze znaczenie przy pomiarze DSO. Skąd pobrać Zdarzenie jest rejestrowane podczas tworzenia faktury w tabeli Sales Invoice Header (SalesInvoiceHeader) lub Sales Table (SalesTable). Czas utworzenia rekordu służy jako timestamp zdarzenia. Rejestrowanie Zapisz timestamp utworzenia rekordu faktury sprzedaży. Typ zdarzenia explicit
	Zaksięgowanie i wysłanie faktury	Oznacza oficjalne ujęcie faktury w księdze głównej i powstanie formalnej należności. Zdarzenie zwykle zbiega się z wysłaniem faktury do klienta i jest rejestrowane po zakończeniu procedury księgowania w Dynamics 365.
Dlaczego to ważne To ważny moment, od którego zaczyna się bieg terminu płatności i naliczanie wieku należności. Opóźnienie między wystawieniem a zaksięgowaniem może wskazywać na nieefektywności w procesie fakturowania. Skąd pobrać Zdarzenie można ustalić na podstawie daty księgowania w dzienniku faktur klienta (CustInvoiceJour) lub zmiany statusu na „Posted”. Najważniejszą daną jest timestamp księgowania. Rejestrowanie Użyj timestampu księgowania z dziennika faktur klienta (CustInvoiceJour). Typ zdarzenia inferred
	Zaksięgowano płatność	Oznacza oficjalne zaksięgowanie płatności klienta w księdze głównej i rozliczenie nią faktury. Zdarzenie jest rejestrowane na podstawie daty księgowania dziennika płatności klienta.
Dlaczego to ważne Kończy etap płatności w procesie. Czas od otrzymania płatności do jej zaksięgowania, czyli opóźnienie w rozliczeniu wpływów, to ważny wskaźnik efektywności działu finansowego. Skąd pobrać Zdarzenie rejestrowane na podstawie znacznika czasu księgowania dziennika płatności klienta (LedgerJournalTrans). Potwierdza, że płatność została w pełni przetworzona w księdze. Rejestrowanie Użyj daty księgowania zaksięgowanego dziennika płatności klienta. Typ zdarzenia explicit
	Zarejestrowano spór	Oznacza, że klient formalnie zakwestionował fakturę, a jej status został odpowiednio zmieniony. Zdarzenie jest zwykle rejestrowane, gdy użytkownik zmienia status faktury na „Zakwestionowana” w module zarządzania windykacją.
Dlaczego to ważne To początek procesu rozpatrywania sporu. Śledzenie tego zdarzenia pozwala mierzyć częstotliwość sporów i czas ich rozwiązywania, co wpływa na zadowolenie klientów i przepływy pieniężne. Skąd pobrać Zdarzenie można wywnioskować ze zmiany statusu transakcji klienta (CustTrans) lub powiązanej tabeli zarządzania sporami (smmCaseDetail). Wymagany jest dziennik zmian statusu ze znacznikami czasu. Rejestrowanie Wykryj, kiedy pole statusu sporu dla transakcji faktury zostaje wypełnione lub zmienione na „Zakwestionowana”. Typ zdarzenia inferred
	Rozwiązano spór	Oznacza zakończenie procesu rozpatrywania sporu, gdy uzgodniono i udokumentowano jego rozwiązanie. Zdarzenie jest rejestrowane, gdy użytkownik zmieni status sporu dotyczącego faktury na „Rozwiązany” lub zamknie powiązaną sprawę.
Dlaczego to ważne Ta czynność kończy podproces rozpatrywania sporu. Czas od zarejestrowania sporu do jego rozwiązania to ważny KPI służący do oceny efektywności zespołu rozpatrującego spory. Skąd pobrać Zdarzenie można wywnioskować ze zmiany statusu transakcji klienta (CustTrans) lub zamknięcia powiązanej sprawy dotyczącej sporu (smmCaseDetail). Czas zmiany statusu jest czasem zdarzenia. Rejestrowanie Wykryj, kiedy pole statusu sporu dla faktury zostaje wyczyszczone lub zmienione na „Rozwiązany”. Typ zdarzenia inferred
	Zarejestrowanie działania windykacyjnego	Oznacza ręczne działanie windykacyjne, takie jak rozmowa telefoniczna lub wiadomość e-mail, zarejestrowane przy kliencie lub fakturze. Zdarzenie jest zapisywane, gdy pracownik windykacji rejestruje kontakt za pomocą funkcji Activities w obszarze roboczym windykacji.
Dlaczego to ważne Zapewnia wgląd w ręczną pracę zespołu windykacji. Zestawienie tych działań z wynikami płatności pomaga ocenić produktywność zespołu i skuteczność poszczególnych metod kontaktu. Skąd pobrać Działanie jest rejestrowane w tabeli Activities (smmActivities) lub powiązanych tabelach zarządzania sprawami dotyczących konta klienta. W miarę możliwości należy powiązać je z konkretną fakturą. Rejestrowanie Zapisz utworzenie rekordów Activity typu „Phone Call” lub „Email” związanych z windykacją. Typ zdarzenia explicit
	Zarejestrowanie obietnicy zapłaty	Klient zobowiązał się do zapłaty w określonym terminie w przyszłości, a obietnica została zapisana w systemie. Zdarzenie jest rejestrowane, gdy pracownik windykacji wprowadza szczegóły obietnicy zapłaty w module windykacyjnym.
Dlaczego to ważne Zdarzenie pozwala śledzić nieformalne ustalenia dotyczące płatności i odsetek ich realizacji. Porównanie obietnic z faktycznymi płatnościami może pomóc prognozować przepływy pieniężne i oceniać wiarygodność klientów. Skąd pobrać Dane są prawdopodobnie zapisywane w tabelach obszaru roboczego windykacji lub zarządzania sprawami, w szczególności w tabelach obsługujących obietnice zapłaty. Czasem zdarzenia jest data utworzenia rekordu obietnicy. Rejestrowanie Rejestruj zdarzenia utworzenia na podstawie tabeli szczegółów sprawy dotyczącej obietnicy zapłaty lub windykacji. Typ zdarzenia explicit

Zalecane Opcjonalne

Instrukcje wyodrębniania danych

Jak pobrać dane z Microsoft Dynamics 365

Kroki

Sprawdź wymagania wstępne: Upewnij się, że organizacja korzysta z Microsoft Dynamics 365 Finance, a funkcja Bring Your Own Database (BYOD) jest skonfigurowana i aktywnie eksportuje encje danych do Azure SQL Database. Potrzebne są dane logowania zapewniające dostęp do odczytu tej bazy.
Wskaż encje danych: Sprawdź, czy wymagane encje danych są eksportowane z Dynamics 365 do BYOD. W tym procesie potrzebne są między innymi: CustInvoiceJour, CustTrans, CustTable, CustCollectionLetterJour, CustSettlement, smmActivities, CustPromisedPayment i CustDispute. Jeśli którejś brakuje, skonfiguruj jej eksport w obszarze roboczym zarządzania danymi Dynamics 365.
Połącz się z bazą BYOD: Użyj klienta SQL, na przykład SQL Server Management Studio (SSMS) lub Azure Data Studio, aby połączyć się z Azure SQL Database skonfigurowaną jako miejsce docelowe BYOD.
Przygotuj zapytanie SQL: Skopiuj pełne zapytanie T-SQL z sekcji query tego dokumentu do klienta SQL. Zapytanie zbiera wymagane działania i atrybuty, a następnie zapisuje je w formacie dziennika zdarzeń.
Ustaw parametry zapytania: Znajdź symbole zastępcze na początku zapytania. Zastąp '{CompanyCode}' identyfikatorem analizowanego podmiotu prawnego w Dynamics 365, na przykład „USMF”. Zastąp '{StartDate}' i '{EndDate}' wybranym zakresem dat w formacie „YYYY-MM-DD”.
Uruchom zapytanie: Uruchom zmodyfikowane zapytanie w bazie BYOD. Czas wykonania zależy od ilości danych w wybranym zakresie dat.
Sprawdź wyniki: Po zakończeniu zapytania w panelu wyników pojawi się dziennik zdarzeń. Każdy wiersz odpowiada konkretnemu działaniu w cyklu zarządzania kredytami i windykacji dla danej faktury. Sprawdź kompletność i poprawność danych.
Wyeksportuj dziennik zdarzeń: Zapisz wyniki zapytania w pliku CSV. Większość klientów SQL ma wbudowaną funkcję eksportu wyników. Kliknij prawym przyciskiem myszy siatkę wyników i wybierz opcję taką jak „Zapisz wyniki jako” lub „Eksportuj”.
Przygotuj plik do wczytania: Sprawdź, czy wyeksportowany plik CSV jest zapisany w kodowaniu UTF-8, a nagłówki kolumn odpowiadają wymaganym atrybutom: InvoiceNumber, ActivityName, EventTime oraz uwzględnionym atrybutom zalecanym. Plik jest gotowy do wczytania do ProcessMind.

Konfiguracja

Wymagania wstępne: Dostęp do instancji Microsoft Dynamics 365 for Finance z skonfigurowaną i działającą funkcją Bring Your Own Database (BYOD). Wymagane są uprawnienia do odczytu docelowej Azure SQL Database.
Encje danych: Wyodrębnianie danych wymaga eksportu kilku standardowych encji danych do BYOD. W eksporcie należy uwzględnić co najmniej CustInvoiceJour, CustTrans, CustTable i CustSettlement. Do wyodrębnienia niektórych działań potrzebne są dodatkowe encje, takie jak CustCollectionLetterJour.
Zakres dat: Aby kontrolować wydajność, należy ograniczyć zapytanie do określonego zakresu dat. Do wstępnej analizy zaleca się dane z 3–6 miesięcy. W zapytaniu służą do tego symbole zastępcze '{StartDate}' i '{EndDate}'.
Filtr firmy: Aby zapewnić spójność danych, zapytanie musi być ograniczone do konkretnego podmiotu prawnego (kodu firmy). Użyj symbolu zastępczego '{CompanyCode}', aby wskazać analizowaną firmę.
Wydajność: W przypadku bardzo dużych zbiorów danych obejmujących wiele lat lub firm zapytanie może wykonywać się długo. Warto uruchamiać je poza godzinami szczytu lub dodać filtry ograniczające zakres danych. Sprawdź, czy w tabelach BYOD istnieją odpowiednie indeksy dla kolumn z datami i kluczami.

Przykładowe zapytanie 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.

Kroki

Wymagania wstępne i konfiguracja środowiska: Upewnij się, że zainstalowano Python 3.8 lub nowszy. Zainstaluj wymagane biblioteki za pomocą pip: pip install pandas requests msal. Potrzebne będą również dane logowania jednostki usługi z dostępem do środowiska Dynamics 365.
Zarejestruj aplikację w Azure AD: Otwórz portal Azure Active Directory. Zarejestruj nową aplikację, aby uzyskać Client ID i Tenant ID. W sekcji „Certyfikaty i wpisy tajne” utwórz nowy klucz tajny klienta. Zapisz bezpiecznie Client ID, Tenant ID i Client Secret.
Przyznaj uprawnienia do API: W ustawieniach „Uprawnienia API” zarejestrowanej aplikacji w Azure AD dodaj uprawnienie. Wybierz „Dynamics ERP” lub podobną pozycję dla Dynamics 365, a następnie przyznaj delegowane uprawnienie „user_impersonation”. Udziel zgody administratora dla organizacji.
Utwórz użytkownika Dynamics 365: Utwórz dedykowanego użytkownika aplikacji w Dynamics 365 Finance and Operations. Powiąż go z Client ID aplikacji Azure AD. Przypisz mu rolę zabezpieczeń z uprawnieniami do odczytu wszystkich wymaganych encji danych, takich jak CustInvoiceJour, CustCollectionLetterJour, CustSettlements i smmActivities.
Skonfiguruj skrypt Python: Skopiuj podany skrypt Python do pliku, na przykład extract_d365_collections.py. Uzupełnij zmienne zastępcze na początku skryptu adresem URL środowiska D365, Tenant ID, Client ID, Client Secret i domyślną firmą (dataAreaId).
Ustaw parametry wyodrębniania danych: Zmień zmienne start_date i end_date w skrypcie, aby określić zakres czasu wyodrębniania danych. Do wstępnej analizy zaleca się okres 3–6 miesięcy.
Uruchom skrypt: Uruchom skrypt w terminalu poleceniem python extract_d365_collections.py. Skrypt uwierzytelni się, odpytuje punkty końcowe OData dla każdego z 12 działań i automatycznie obsłuży stronicowanie API.
Pobierz dane dla każdego działania: Skrypt wykonuje kolejno wywołania API, aby pobrać dane dotyczące wystawiania faktur, księgowania, wezwań do zapłaty, płatności i innych ważnych zdarzeń. Każde zapytanie dotyczy konkretnej encji danych i pobiera tylko niezbędne pola, co ogranicza obciążenie.
Przekształć i połącz dane: Skrypt używa biblioteki pandas do przetwarzania odpowiedzi JSON z każdego wywołania API. Przekształca dane w uporządkowaną tabelę, ujednolica nazwy kolumn, a następnie łączy dane ze wszystkich działań w jeden dziennik zdarzeń.
Oblicz zdarzenia pochodne: Działanie „Minął termin płatności” nie jest bezpośrednio rejestrowane w systemie. Skrypt sprawdza wszystkie faktury przeterminowane w wybranym zakresie dat i tworzy dla każdej z nich odpowiedni wiersz.
Wyeksportuj dziennik zdarzeń: Po przetworzeniu i połączeniu wszystkich danych skrypt zapisuje końcowy dziennik zdarzeń w pliku CSV d365_collections_event_log.csv w tym samym katalogu. Plik jest gotowy do wczytania do narzędzia process mining.

Konfiguracja

Adres URL punktu końcowego API: Podstawowy adres URL środowiska Dynamics 365 Finance and Operations. Powinien mieć format https://[your-environment-name].operations.dynamics.com.
Dane uwierzytelniające: Skrypt wymaga Tenant ID, Client ID i Client Secret z rejestracji aplikacji w Azure Active Directory. Aplikacji należy przyznać uprawnienia do korzystania z Dynamics 365 API.
Filtr firmy (dataAreaId): Dynamics 365 obsługuje wiele firm. Skrypt odpytuje dane konkretnej firmy za pomocą filtra dataAreaId. Ustaw zmienną default_company na właściwy podmiot prawny, na przykład „USMF”.
Zakres dat: Parametry start_date i end_date określają okres wyodrębniania danych. Aby ograniczyć ich ilość i sprawnie zakończyć pobieranie, warto zacząć od ostatnich 3–6 miesięcy. Filtr jest stosowany przede wszystkim do daty utworzenia faktury.
Wydajność: Wyodrębnianie bardzo dużych zbiorów danych przez OData API może trwać długo i podlegać ograniczeniom liczby żądań nakładanym przez Microsoft. W razie problemów z wydajnością warto skrócić zakres dat lub uruchomić pobieranie poza godzinami szczytu.
Wymagania wstępne: Wymagane jest środowisko Python 3.8 lub nowsze z bibliotekami pandas, requests i msal. Powiązany użytkownik Dynamics 365 musi mieć dostęp do odczytu modułów finansowych, sprzedażowych i zarządzania windykacją, w szczególności encji wymienionych w skrypcie.

Przykładowe zapytanie 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.")

Gotowi do rozpoczęcia?

Skorzystaj z tego szablonu, aby przygotować dane i uzyskać przydatne informacje o procesie zarządzania kredytami i windykacji. Już dziś zacznij usprawniać proces, aby szybciej odzyskiwać należności.

Wróć do przewodnika ulepszania procesów

Pobierz szablon

Usprawnij zarządzanie kredytami i windykację, aby szybciej odzyskiwać należności

Popraw przepływy pieniężne, usprawniając cykl od udzielenia kredytu do otrzymania płatności i skracając jego czas o 30%.

Rozpocznij bezpłatny okres próbny

Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.

Szablon danych do zarządzania kredytami i windykacji

Szablon danych do zarządzania kredytami i windykacji

Atrybuty procesu zarządzania kredytami i windykacji

Działania w procesie zarządzania kredytami i windykacji

Instrukcje wyodrębniania danych

Bezpośrednie zapytanie SQL przez Bring Your Own Database (BYOD)

Kroki

Konfiguracja

Przykładowe zapytanie sql

Skrypt Python korzystający z Dynamics 365 OData REST API

Kroki

Konfiguracja

Przykładowe zapytanie python

Gotowi do rozpoczęcia?

Usprawnij zarządzanie kredytami i windykację, aby szybciej odzyskiwać należności