Szablon danych dla procesu Order to Cash: rozliczanie i fakturowanie
Szablon danych dla procesu Order to Cash: rozliczanie i fakturowanie
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia
- Wskazówki dotyczące pozyskiwania danych z Microsoft Dynamics 365
Atrybuty procesu Order to Cash: rozliczanie i fakturowanie
| Nazwa | Opis | ||
|---|---|---|---|
|
Numer faktury
InvoiceNumber
|
Unikalny identyfikator każdej faktury klienta, używany jako główny identyfikator case w procesie fakturowania. | ||
|
Opis
Numer faktury jest głównym kluczem, który łączy wszystkie czynności dotyczące jednego dokumentu rozliczeniowego. Umożliwia analizę całego cyklu życia faktury, od wystawienia i zatwierdzenia po płatność klienta i ostateczne zamknięcie. Użycie numeru faktury jako identyfikatora case sprawia, że każdy wpis w dzienniku zdarzeń odpowiada konkretnej fakturze. Pozwala to szczegółowo analizować warianty procesu, obliczać czas jego trwania i monitorować wyniki poszczególnych transakcji fakturowania.
Dlaczego to ważne
Ten atrybut jest niezbędny do śledzenia całego cyklu życia faktury oraz analizy efektywności procesu, wąskich gardeł i odstępstw dla każdego dokumentu.
Skąd pobrać
Numer faktury znajduje się zwykle w module Sales and marketing, w tabelach takich jak CustInvoiceJour (pole InvoiceId), lub jest udostępniany przez jednostki danych, takie jak SalesInvoiceHeaderV2.
Przykłady
CIV-001254INV-2023-9876US-004321
|
|||
|
Czas zdarzenia
EventTime
|
Dokładny znacznik czasu wskazujący, kiedy wystąpiła dana czynność lub zdarzenie. | ||
|
Opis
Czas zdarzenia, nazywany również znacznikiem czasu, określa dokładną datę i godzinę każdej czynności w procesie. Dane te są niezbędne do analiz process mining opartych na czasie. Służą do obliczania czasu między czynnościami, mierzenia całkowitego czasu trwania case i analizy wyników procesu w czasie. Dokładne i wiarygodne znaczniki czasu są podstawą KPI, takich jak Days Sales Outstanding i czas wystawienia faktury.
Dlaczego to ważne
To podstawowy atrybut w analizie wyników i czasu. Umożliwia obliczanie czasu między czynnościami, czasu trwania i przepustowości, a tym samym pomiar efektywności procesu.
Skąd pobrać
Znaczniki czasu pochodzą z różnych pól daty i godziny w tabelach Dynamics 365. Przykładem jest CreatedDateTime w tabeli CustInvoiceJour, używane przy wystawianiu faktury, lub znaczniki czasu z historii workflow.
Przykłady
2023-04-15T10:22:15Z2023-05-01T14:05:00Z2023-05-10T09:00:30Z
|
|||
|
Nazwa czynności
ActivityName
|
Nazwa czynności biznesowej lub zdarzenia, które wystąpiło na określonym etapie cyklu życia faktury. | ||
|
Opis
Ten atrybut opisuje konkretny etap lub kamień milowy procesu fakturowania, na przykład „Wystawiono fakturę”, „Zatwierdzono fakturę” lub „Otrzymano płatność od klienta”. Kolejność tych czynności tworzy przebieg procesu. Analiza czynności jest podstawą process mining, ponieważ pozwala odkrywać modele procesu, identyfikować warianty i mierzyć wyniki między poszczególnymi etapami.
Dlaczego to ważne
Atrybut określa etapy procesu, umożliwiając wizualizację map procesu, analizę wariantów oraz wykrywanie wąskich gardeł i odstępstw od standardowego przebiegu.
Skąd pobrać
Ten atrybut jest zwykle wyznaczany na podstawie wielu źródeł, takich jak pola zmiany statusu (np. DocumentState), uzupełnione pola daty lub dzienniki historii workflow w Microsoft Dynamics 365.
Przykłady
Wystawiono fakturęZatwierdzono fakturęOtrzymano płatność od klientaWystawiono fakturę korygującą
|
|||
|
Dział
Department
|
Dział firmy powiązany z użytkownikiem lub czynnością. | ||
|
Opis
Ten atrybut przypisuje czynność lub użytkownika do określonego działu, na przykład „Należności” lub „Sprzedaż”. Pozwala oceniać wyniki procesu na wyższym poziomie niż pojedynczy użytkownik. Analiza w podziale na działy pomaga zrozumieć przekazywanie pracy między zespołami, porównać ich efektywność i wykryć wąskie gardła na poziomie działów. Takie dane są potrzebne w dashboardzie „Obciążenie pracą w dziale fakturowania”.
Dlaczego to ważne
Umożliwia analizę wyników na poziomie organizacji, porównanie efektywności zespołów i ocenę wpływu przekazywania pracy między działami na proces.
Skąd pobrać
Informacja ta zwykle nie występuje bezpośrednio w transakcji faktury. Można ją uzyskać, łącząc identyfikator UserResponsible z katalogiem pracowników lub użytkowników, który zawiera dane o działach.
Przykłady
NależnościFinanseOperacje fakturowania
|
|||
|
Kwota faktury
InvoiceAmount
|
Łączna wartość faktury. | ||
|
Opis
Ten atrybut określa łączną kwotę należną z tytułu faktury. Jest ważnym miernikiem w analizie finansowej i pozwala dzielić faktury według wartości. Można na przykład skupić się na fakturach o wysokiej wartości, aby sprawdzić, jak przebiega ich opłacanie lub czy ich zatwierdzanie trwa dłużej. Atrybut ten służy też do obliczania łącznej wartości nieopłaconych faktur i wskaźnika DSO.
Dlaczego to ważne
Umożliwia analizę wpływu finansowego. Można filtrować i dzielić procesy według wartości pieniężnej, aby nadać priorytet fakturom o wysokiej wartości i sprawdzić, jak przebiega ich obsługa.
Skąd pobrać
Dane znajdują się w tabeli CustInvoiceJour, zwykle w polu takim jak InvoiceAmount. Są też dostępne w powiązanych tabelach transakcji.
Przykłady
5430.5012500.00750.25
|
|||
|
Nazwa klienta
CustomerName
|
Nazwa klienta, na którego wystawiono fakturę. | ||
|
Opis
Nazwa klienta to czytelny dla użytkownika identyfikator firmy lub osoby, na którą wystawiono fakturę. W analizie process mining pozwala podzielić proces fakturowania według klientów. Można sprawdzić, którzy klienci regularnie płacą w terminie, którzy często się spóźniają oraz czy określone grupy klientów napotykają nietypowe zmiany lub opóźnienia w procesie. Atrybut ten jest przydatny w dashboardach dotyczących terminowości płatności klientów i analizy Days Sales Outstanding.
Dlaczego to ważne
Pozwala analizować procesy w podziale na klientów, aby wykrywać charakterystyczne dla nich zachowania, wzorce płatności i problemy w procesie.
Skąd pobrać
Informację tę uzyskuje się przez połączenie danych faktury z danymi podstawowymi klienta, zwykle z tabelą CustTable, na podstawie numeru konta klienta.
Przykłady
Contoso Ltd.Fabrikam, Inc.Northwind Traders
|
|||
|
Status faktury
InvoiceStatus
|
Bieżący status faktury w cyklu jej obsługi (np. otwarta, opłacona, anulowana). | ||
|
Opis
Ten atrybut pokazuje bieżący stan faktury. Informuje, czy faktura oczekuje na płatność, została w pełni opłacona, jest przeterminowana czy została anulowana za pomocą faktury korygującej. Można go użyć do filtrowania spraw i analizowania tylko otwartych faktur albo do sprawdzenia wyniku obsługi zamkniętej faktury. Pomaga ocenić bieżące obciążenie pracą i stan należności.
Dlaczego to ważne
Szybko pokazuje bieżący stan faktury. Ułatwia filtrowanie spraw i analizę wyników poszczególnych wariantów procesu.
Skąd pobrać
Status można ustalić na podstawie stanu płatności faktury, na przykład sprawdzając, czy saldo powiązanego rekordu CustTrans wynosi zero. Nie zawsze istnieje jedno pole „status”.
Przykłady
OtwartaOpłaconaPrzeterminowanaAnulowana
|
|||
|
Termin płatności
PaymentDueDate
|
Data, do której klient powinien opłacić fakturę. | ||
|
Opis
Termin płatności to ważna data obliczana na podstawie daty wystawienia faktury i warunków płatności klienta. Stanowi punkt odniesienia przy ocenie terminowości płatności. Atrybut ten jest niezbędny w dashboardzie „Analiza przestrzegania warunków płatności” oraz przy obliczaniu KPI, takich jak „Odsetek płatności w terminie” i „Days Sales Outstanding”. Porównanie terminu z datą faktycznej płatności pozwala ocenić zachowania płatnicze klientów i skuteczność procesu windykacji.
Dlaczego to ważne
To punkt odniesienia przy ocenie terminowości płatności. Jest niezbędny do obliczania odsetka płatności w terminie i analizy przestrzegania warunków płatności przez klientów.
Skąd pobrać
Dane znajdują się zwykle w tabeli CustInvoiceJour, w polu takim jak DueDate.
Przykłady
2023-05-152023-06-302023-07-01
|
|||
|
Użytkownik odpowiedzialny
UserResponsible
|
Użytkownik lub pracownik odpowiedzialny za wykonanie określonej czynności. | ||
|
Opis
Ten atrybut wskazuje osobę, która wykonała daną czynność w procesie fakturowania, na przykład zatwierdziła fakturę lub rozliczyła płatność. Jest przydatny do analizy obciążenia pracą i porównywania wyników, a także do określania potrzeb szkoleniowych. Na przykład dashboard „Obciążenie pracą w dziale fakturowania” korzysta z tego atrybutu, aby sprawdzić, czy praca jest równomiernie rozłożona i czy niektóre osoby nie stają się wąskim gardłem. Pomaga też analizować przydział zasobów i efektywność.
Dlaczego to ważne
Umożliwia analizę na poziomie zasobów, pomaga wykrywać wąskie gardła, mierzyć wyniki poszczególnych osób i zespołów oraz analizować rozkład obciążenia pracą w dziale fakturowania.
Skąd pobrać
Dane można pobrać z dzienników historii workflow (np. WorkflowTrackingStatusTable) lub z pól określających właściciela, takich jak Owner lub ModifiedBy, w odpowiednich tabelach.
Przykłady
John SmithAlicia BakerAdministrator systemu
|
|||
|
Czy płatność wpłynęła w terminie
IsOnTimePayment
|
Wskaźnik informujący, czy płatność od klienta wpłynęła w terminie lub przed terminem. | ||
|
Opis
Ten obliczany atrybut logiczny porównuje znacznik czasu zdarzenia „Otrzymano płatność od klienta” z terminem płatności. Oznacza każdą fakturę jako opłaconą w terminie lub po terminie. Jest podstawą do obliczania KPI „Odsetek płatności w terminie” i jest często wykorzystywany w dashboardzie „Analiza przestrzegania warunków płatności”. Jednoznaczny wynik ułatwia analizę i raportowanie terminowości płatności.
Dlaczego to ważne
Bezpośrednio mierzy, czy klienci przestrzegają warunków płatności, i stanowi podstawę KPI „Odsetek płatności w terminie”. Ułatwia ocenę skuteczności windykacji.
Skąd pobrać
Tego atrybutu nie ma w systemie źródłowym. Oblicza się go podczas transformacji danych, porównując datę płatności z wartością PaymentDueDate.
Przykłady
truefalse
|
|||
|
Czy wymagała ponownej pracy
IsRework
|
Wskaźnik informujący, czy obsługa faktury wymagała ponownej pracy, na przykład wielokrotnego zatwierdzania. | ||
|
Opis
Ten obliczany atrybut logiczny oznacza faktury, których obsługa wymagała ponownej pracy. Może to oznaczać na przykład kilka zdarzeń „Faktura zatwierdzona” lub cofnięcie płatności. Atrybut służy do obsługi dashboardu „Analiza ponownej pracy przy fakturach” i KPI „Odsetek faktur wymagających ponownej pracy”. Wyodrębnienie takich spraw pozwala analizować przyczyny, które często wskazują na nieefektywność procesu, problemy z jakością danych lub braki w szkoleniach.
Dlaczego to ważne
Wskaźnik ten pokazuje nieefektywność procesu, oznaczając sprawy z powtarzającymi się lub korygującymi działaniami. Pomaga ustalić źródła strat i opóźnień.
Skąd pobrać
Ten atrybut nie jest dostępny w systemie źródłowym. Oblicza się go w warstwie transformacji danych, sprawdzając, czy w danej sprawie powtarzały się czynności lub wystąpiły określone wzorce ponownej pracy.
Przykłady
truefalse
|
|||
|
Data ostatniej aktualizacji danych
LastDataUpdate
|
Znacznik czasu wskazujący, kiedy dane dotyczące tego zdarzenia zostały ostatnio odświeżone z systemu źródłowego. | ||
|
Opis
Ten atrybut zapisuje datę ostatniej ekstrakcji lub aktualizacji danych z Microsoft Dynamics 365. Jest to pole metadanych, które pozwala ocenić aktualność analizowanych danych. Dzięki niemu analitycy i użytkownicy biznesowi wiedzą, czy korzystają z najnowszych informacji. Pomaga też planować odświeżanie danych i oceniać wiarygodność analizy.
Dlaczego to ważne
Pozwala ocenić aktualność danych, co ma znaczenie dla zarządzania danymi, planowania odświeżania dashboardów i zaufania do aktualności uzyskanych wniosków.
Skąd pobrać
Ten atrybut jest generowany i zapisywany w zbiorze danych podczas procesu ekstrakcji, transformacji i ładowania (ETL).
Przykłady
2023-06-20T05:00:00Z2023-06-21T05:00:00Z
|
|||
|
Days Sales Outstanding
DaysSalesOutstanding
|
Liczba dni od wystawienia faktury do otrzymania płatności od klienta. | ||
|
Opis
Days Sales Outstanding (DSO) to miernik finansowy określający średnią liczbę dni potrzebnych firmie na otrzymanie płatności po dokonaniu sprzedaży. Ten obliczany atrybut wyznacza ten okres dla każdej faktury. Jest głównym miernikiem w dashboardzie „Analiza trendu Days Sales Outstanding” i KPI „DSO”. Analiza DSO pomaga zarządzać przepływami pieniężnymi i oceniać efektywność udzielania kredytu kupieckiego oraz windykacji.
Dlaczego to ważne
To ważny KPI służący do oceny stanu przepływów pieniężnych firmy i efektywności windykacji. Pokazuje, jak szybko przychody zamieniają się w gotówkę.
Skąd pobrać
Tego atrybutu nie ma w systemie źródłowym. Oblicza się go jako czas między czynnością „Wystawiono fakturę” a czynnością „Otrzymano płatność od klienta”.
Przykłady
284592
|
|||
|
Numer zamówienia sprzedaży
SalesOrderNumber
|
Identyfikator zamówienia sprzedaży, na podstawie którego wystawiono fakturę. | ||
|
Opis
Numer zamówienia sprzedaży łączy proces fakturowania z wcześniejszym procesem sprzedaży. To połączenie jest przydatne w analizie Order-to-Cash obejmującej cały proces. Analitycy mogą sprawdzić, jak problemy w sprzedaży i realizacji zamówienia, takie jak zmiany w zamówieniu lub opóźnienia w wysyłce, wpływają na cykl fakturowania. Można na przykład ustalić, czy faktury za złożone zamówienia sprzedaży są opłacane później.
Dlaczego to ważne
Łączy proces fakturowania z wcześniejszym procesem sprzedaży. Umożliwia analizę Order-to-Cash obejmującą cały proces i pomaga ustalić źródła problemów z fakturowaniem.
Skąd pobrać
Dane znajdują się w nagłówku faktury lub w szczegółach jej pozycji i wskazują powiązane zamówienie sprzedaży. W tabeli CustInvoiceJour należy szukać pola takiego jak SalesId.
Przykłady
SO-009876SO-010234US-SO-00543
|
|||
|
System źródłowy
SourceSystem
|
System, z którego pobrano dane. | ||
|
Opis
Ten atrybut wskazuje źródło danych o procesie. W tym przypadku oznacza, że dane pochodzą z Microsoft Dynamics 365. Ma to znaczenie w środowiskach korzystających z wielu systemów, ponieważ pozwala rozróżnić źródła danych i zachować przejrzystość ich pochodzenia. Ułatwia też weryfikację danych i rozwiązywanie problemów.
Dlaczego to ważne
Informacja o źródle danych jest niezbędna do zarządzania danymi i ich weryfikacji, a także do łączenia danych z wielu systemów firmowych.
Skąd pobrać
To stała wartość dodawana do zbioru danych podczas ich ekstrakcji i transformacji, która oznacza źródło danych.
Przykłady
Microsoft Dynamics 365 FinanceD365 F&O
|
|||
|
Waluta
Currency
|
Kod waluty, w której podano kwotę faktury (np. USD, EUR). | ||
|
Opis
Ten atrybut określa walutę, w której wyrażono kwotę faktury. Jest niezbędny w organizacjach międzynarodowych, które rozliczają się w różnych walutach. Bez tej informacji sumowanie i porównywanie kwot faktur nie miałoby sensu. Atrybut umożliwia prawidłowe przeliczanie walut oraz rzetelne raportowanie i analizę finansową w różnych regionach.
Dlaczego to ważne
Dostarcza niezbędnego kontekstu dla mierników finansowych, takich jak kwota faktury. Zapobiega błędnemu sumowaniu i umożliwia rzetelną analizę w środowisku wielowalutowym.
Skąd pobrać
Dane znajdują się w tabeli CustInvoiceJour, zwykle w polu takim jak CurrencyCode.
Przykłady
USDEURGBP
|
|||
|
Warunki płatności
PaymentTerms
|
Uzgodnione zasady płatności za fakturę (np. 30 lub 60 dni). | ||
|
Opis
Warunki płatności określają, kiedy klient powinien opłacić fakturę. Atrybut ten służy do obliczania terminu płatności i jest ważnym wymiarem analizy zachowań płatniczych. Dashboard „Analiza przestrzegania warunków płatności” wykorzystuje go do grupowania klientów i faktur. Dzięki temu można sprawdzić, które warunki płatności są skuteczniejsze lub wiążą się z częstszymi opóźnieniami.
Dlaczego to ważne
Wyjaśnia, dlaczego termin płatności przypada na określoną datę. Pozwala też podzielić dane, aby sprawdzić, czy wybrane warunki płatności wiążą się z opóźnieniami.
Skąd pobrać
Informacja ta jest zwykle zapisana w danych podstawowych klienta, a następnie kopiowana do nagłówka faktury. W tabeli CustInvoiceJour należy szukać pola Payment lub PaymTermId.
Przykłady
30 dni60 dniPłatność przy odbiorze
|
|||
|
Wymaga ręcznej interwencji
RequiresManualIntervention
|
Wskaźnik informujący, czy podczas rozliczania płatności konieczna była ręczna korekta. | ||
|
Opis
Ten atrybut logiczny oznacza płatności, które podczas rozliczania wymagały ręcznej interwencji lub korekty. Jest ważny przy obliczaniu KPI „Odsetek rozbieżności przy rozliczaniu płatności”, ponieważ pomaga ocenić poprawność księgowania płatności i poziom automatyzacji. Ustalenie przyczyn ręcznej interwencji, takich jak brak informacji o płatności lub rozbieżności w kwocie, może pomóc usprawnić proces i zwiększyć odsetek płatności przetwarzanych bez ręcznej obsługi.
Dlaczego to ważne
Pomaga wykrywać problemy i nieścisłości podczas rozliczania płatności. Jest to ważne przy zwiększaniu automatyzacji i ograniczaniu pracy ręcznej.
Skąd pobrać
Informację tę można czasem ustalić na podstawie użytkownika, który zaksięgował płatność, jeśli nie jest to użytkownik systemowy, lub na podstawie kodów przyczyn użytych podczas uzgadniania płatności. Szczegóły można znaleźć w dokumentacji Microsoft Dynamics 365.
Przykłady
truefalse
|
|||
Działania w procesie Order to Cash: rozliczanie i fakturowanie
| Działanie | Opis | ||
|---|---|---|---|
|
Otrzymano płatność od klienta
|
Ta czynność oznacza utworzenie zapisu w dzienniku dokumentującego płatność otrzymaną od klienta. Potwierdza otrzymanie środków, ale nie ich przypisanie do konkretnej faktury. | ||
|
Dlaczego to ważne
To początek pomiaru czasu rozliczenia płatności. Pozwala odróżnić otrzymanie środków od ich uzgodnienia z nieopłaconymi fakturami.
Skąd pobrać
Zdarzenie można odczytać z utworzenia lub zaksięgowania dziennika płatności klienta. Jest ono rejestrowane między innymi w tabeli LedgerJournalTrans, a po zaksięgowaniu tworzy transakcję klienta w CustTrans.
Rejestrowanie
Użyj znacznika czasu zaksięgowania dziennika płatności klienta z tabeli LedgerJournalTable.
Typ zdarzenia
explicit
|
|||
|
Rozliczono płatność z fakturą
|
Oznacza rozliczenie płatności klienta z konkretną fakturą, co zmniejsza jej saldo należności. W Dynamics 365 jest to osobny etap, który łączy transakcję płatności z transakcją faktury. | ||
|
Dlaczego to ważne
To ważny etap przy dokładnym obliczaniu DSO i ocenie efektywności zespołu rozliczającego płatności. Oznacza moment, w którym płatność zostaje w pełni uzgodniona z wystawioną fakturą.
Skąd pobrać
Zdarzenie jest rejestrowane w tabeli CustSettlement. Pole daty rozliczenia w tej tabeli zawiera znacznik czasu przypisania konkretnej płatności do konkretnej transakcji faktury.
Rejestrowanie
Użyj pola TransDate lub CreatedDateTime z tabeli CustSettlement.
Typ zdarzenia
explicit
|
|||
|
Upłynął termin płatności
|
Zdarzenie wyliczane, które występuje, gdy upływa termin płatności faktury, a płatność nie została w pełni rozliczona. Nie odpowiada ono transakcji w systemie, lecz jest wyznaczane na podstawie istniejących danych. | ||
|
Dlaczego to ważne
To zdarzenie ma zasadnicze znaczenie przy analizie terminowości płatności i wykrywaniu faktur, które stają się przeterminowane. Wyznacza moment rozpoczęcia działań związanych z odzyskiwaniem należności i monitowaniem.
Skąd pobrać
Zdarzenie nie jest rejestrowane bezpośrednio. Wylicza się je na podstawie pola DueDate z tabeli CustInvoiceJour. Znacznikiem czasu zdarzenia jest sam termin płatności.
Rejestrowanie
Utwórz zdarzenie, którego znacznikiem czasu jest wartość pola CustInvoiceJour.DueDate.
Typ zdarzenia
calculated
|
|||
|
Wysłano fakturę do klienta
|
Ta czynność oznacza moment wysłania faktury klientowi, elektronicznie lub w formie papierowej. W Dynamics 365 może to być jawne zdarzenie, jeśli fakturę wysłano przez systemową pocztę e-mail. Jeśli śledzenie wysyłki nie jest włączone, zdarzenie można wywnioskować z momentu zaksięgowania faktury. | ||
|
Dlaczego to ważne
Pozwala ocenić sprawność dostarczania faktur. Opóźnienie między zatwierdzeniem a wysłaniem faktury niepotrzebnie wydłuża cykl płatności.
Skąd pobrać
Jeśli używana jest funkcja poczty e-mail w D365, zdarzenie można odczytać z dzienników poczty, takich jak SysOutgoingEmailTable. W przeciwnym razie moment wysłania często przyjmuje się jako czas zaksięgowania faktury z tabeli CustInvoiceJour.
Rejestrowanie
Jeśli jest dostępny, użyj znacznika czasu z dziennika poczty e-mail. W przeciwnym razie użyj znacznika czasu zaksięgowania faktury.
Typ zdarzenia
inferred
|
|||
|
Wystawiono fakturę
|
Oznacza utworzenie i zaksięgowanie faktury sprzedaży w systemie. Jest to jawna transakcja w Dynamics 365, która tworzy dokument księgowy oraz zapisy finansowe w księdze pomocniczej należności. | ||
|
Dlaczego to ważne
To oficjalny początek cyklu fakturowania. Zdarzenie ma zasadnicze znaczenie przy śledzeniu wskaźnika Days Sales Outstanding (DSO) i całkowitego czasu trwania procesu.
Skąd pobrać
Zdarzenie rejestruje się na podstawie znacznika czasu utworzenia zaksięgowanego rekordu faktury sprzedaży w tabeli CustInvoiceJour. Podczas księgowania odpowiednie transakcje finansowe są tworzone w tabelach GeneralJournalEntry i LedgerEntry.
Rejestrowanie
Dla zaksięgowanej faktury użyj pola CreatedDateTime z tabeli CustInvoiceJour.
Typ zdarzenia
explicit
|
|||
|
Zamknięto fakturę
|
Ta czynność oznacza końcowy stan faktury, której saldo wynosi zero, ponieważ została w pełni opłacona lub rozliczona fakturami korygującymi. Nie jest to bezpośrednia transakcja, lecz stan wywnioskowany na podstawie statusu finansowego faktury. | ||
|
Dlaczego to ważne
To zdarzenie oznacza pomyślne zakończenie cyklu Order to Cash dla pojedynczej faktury. Czas potrzebny na osiągnięcie tego stanu jest jednym z głównych mierników ogólnej efektywności procesu.
Skąd pobrać
Zdarzenie można wywnioskować, sprawdzając, czy saldo transakcji faktury w tabeli CustTrans wynosi zero. Ustala się to przez porównanie kwoty faktury z łączną kwotą rozliczeń.
Rejestrowanie
Wyznacz zdarzenie na podstawie rekordów CustTrans, w których AmountCur jest równe SettleAmountCur. Znacznikiem czasu jest data ostatniego rozliczenia.
Typ zdarzenia
inferred
|
|||
|
Zatwierdzono fakturę
|
Oznacza zakończenie wewnętrznej weryfikacji i formalne zatwierdzenie faktury. Zdarzenie rejestruje system workflow Dynamics 365. Oznacza ono, że faktura jest gotowa do wysłania klientowi. | ||
|
Dlaczego to ważne
To ważny etap przy pomiarze czasu zatwierdzania. Opóźnienia na tym etapie mogą bezpośrednio wydłużyć czas oczekiwania na płatność od klienta.
Skąd pobrać
Zdarzenie jest rejestrowane w tabelach historii workflow, takich jak WorkflowTrackingStatusTable, jako zakończenie lub zatwierdzenie konkretnej instancji workflow faktury.
Rejestrowanie
Wyodrębnij zdarzenia workflow, dla których status ma wartość 'Approved' lub 'Completed'.
Typ zdarzenia
explicit
|
|||
|
Cofnięto płatność
|
Ta czynność oznacza cofnięcie wcześniej zaksięgowanej płatności klienta. Może do niego dojść z powodu błędnego księgowania, braku wystarczających środków lub innych problemów z płatnością. | ||
|
Dlaczego to ważne
Cofnięte płatności wskazują na błędy operacyjne lub problemy z płatnościami klientów. Analiza ich częstotliwości pomaga znaleźć przyczyny i poprawić dokładność rozliczania płatności.
Skąd pobrać
Zdarzenie jest rejestrowane jako storno transakcji w księdze głównej. Cofnięty zapis dziennika można zidentyfikować w tabeli GeneralJournalEntry, zwykle na podstawie odpowiedniej flagi lub powiązania z pierwotną transakcją.
Rejestrowanie
Znajdź zapisy dziennika oznaczone flagą storna lub odwołujące się do cofniętej transakcji.
Typ zdarzenia
explicit
|
|||
|
Przekazano fakturę do zatwierdzenia
|
Ta czynność oznacza przekazanie wystawionej faktury do formalnego workflow zatwierdzania. Jest to częsta praktyka w organizacjach, w których przed wysłaniem faktury klientowi wymagane jest sprawdzenie jej przez kierownictwo. Zdarzenie jest rejestrowane jako osobny etap w silniku workflow D365. | ||
|
Dlaczego to ważne
Śledzenie przekazania faktury do zatwierdzenia pozwala oddzielić czas jej wystawienia od czasu oczekiwania na zatwierdzenie. To pierwszy krok w analizie efektywności wewnętrznej weryfikacji i kontroli.
Skąd pobrać
Zdarzenie można odczytać z tabel historii workflow, takich jak WorkflowTrackingStatusTable, filtrując wpisy dotyczące przekazania dokumentu faktury do zatwierdzenia.
Rejestrowanie
Wyodrębnij zdarzenia workflow, dla których status ma wartość 'Submitted'.
Typ zdarzenia
explicit
|
|||
|
Wysłano przypomnienie o płatności
|
Oznacza wysłanie do klienta monitu lub wezwania do zapłaty dotyczącego przeterminowanej faktury. Dynamics 365 obsługuje formalny proces monitowania, który generuje i rejestruje taką korespondencję. | ||
|
Dlaczego to ważne
Śledzenie przypomnień pozwala ocenić skuteczność procesu monitowania i sprawdzić, ile przypomnień trzeba wysłać przed otrzymaniem płatności.
Skąd pobrać
Jest to jawne zdarzenie, które można odczytać z daty utworzenia dziennika wezwania do zapłaty w tabeli CustCollectionLetterJour. Dziennik jest powiązany z transakcją przeterminowanej faktury.
Rejestrowanie
Użyj znacznika czasu utworzenia z tabeli CustCollectionLetterJour.
Typ zdarzenia
explicit
|
|||
|
Wystawiono fakturę korygującą
|
Oznacza utworzenie faktury korygującej, zwykle w celu poprawienia błędu w fakturze, uwzględnienia zmiany ceny lub zwrotu towaru. Faktura korygująca zmniejsza wartość pierwotnej faktury. | ||
|
Dlaczego to ważne
Częste wystawianie faktur korygujących może wskazywać na problemy systemowe w realizacji zamówień lub fakturowaniu. Analiza przyczyn ich wystawiania pomaga usprawnić proces i ograniczyć utratę przychodów.
Skąd pobrać
Jest to jawna transakcja rejestrowana w tabeli CustInvoiceJour jako nowa zaksięgowana faktura z kwotą ujemną. Często jest powiązana z pierwotną fakturą za pomocą pola referencyjnego.
Rejestrowanie
Znajdź w tabeli CustInvoiceJour rekordy z ujemną kwotą całkowitą i powiąż je z pierwotną fakturą.
Typ zdarzenia
explicit
|
|||
|
Zrealizowano zamówienie sprzedaży
|
Ta czynność oznacza, że towary zostały wysłane lub usługi wykonane w ramach zamówienia sprzedaży, co rozpoczyna proces fakturowania. W Microsoft Dynamics 365 zdarzenie to można zwykle wywnioskować z zaksięgowania dokumentu wydania lub dokumentu dostawy, które zmienia status powiązanych pozycji zamówienia sprzedaży. | ||
|
Dlaczego to ważne
To zdarzenie wyznacza początek pomiaru czasu wystawienia faktury. Analiza opóźnienia między realizacją zamówienia a wystawieniem faktury pomaga wykryć problemy administracyjne, które mogą wpływać na przepływy pieniężne.
Skąd pobrać
Zdarzenie można wywnioskować z daty utworzenia zapisu dziennika dokumentu wydania powiązanego z zamówieniem sprzedaży. Wykorzystywane są między innymi tabele CustPackingSlipJour i CustPackingSlipTrans, powiązane z zamówieniem, na podstawie którego wystawiono fakturę.
Rejestrowanie
Ustal najpóźniejszą datę zaksięgowania dokumentu wydania dla zamówienia sprzedaży powiązanego z fakturą.
Typ zdarzenia
inferred
|
|||
Instrukcje pozyskiwania danych
Gotowi do rozpoczęcia?
Skorzystaj z tego szablonu, aby rozpocząć optymalizację rozliczania i fakturowania. Zapewnij zespołowi dane potrzebne do usprawnienia pracy i poprawy przepływów pieniężnych.
Ogranicz opóźnienia w rozliczaniu: usprawnij proces Order to Cash i fakturowanie
Skróć czas cyklu rozliczeniowego o 30% i szybciej uzyskaj pełniejszy obraz sytuacji finansowej.
Nie trzeba podawać danych karty płatniczej. Bezpłatny okres próbny trwa 14 dni.