Szablon danych do analizy obsługi faktur zakupowych

Microsoft Dynamics 365
Szablon danych do analizy obsługi faktur zakupowych

Szablon danych do analizy obsługi faktur zakupowych

Ten szablon pomaga zebrać dane potrzebne do analizy i usprawnienia obsługi faktur zakupowych. Zawiera listę najważniejszych atrybutów i działań oraz praktyczne wskazówki dotyczące pozyskiwania danych. Dzięki niemu można przygotować dziennik zdarzeń obejmujący przebieg procesu i dokładniej ocenić jego wyniki.
  • Zalecane atrybuty do zebrania
  • Działania, które warto śledzić
  • Wskazówki dotyczące ekstrakcji danych
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty procesu obsługi faktur zakupowych

Poniżej przedstawiono pola, które warto uwzględnić w dzienniku zdarzeń, aby szczegółowo analizować obsługę faktur zakupowych.
3 Wymagane 6 Zalecane 12 Opcjonalne
Nazwa Opis
Faktura
Invoice
Unikatowy identyfikator każdego dokumentu faktury dostawcy.
Opis

Faktura jest głównym identyfikatorem case. Łączy wszystkie działania od otrzymania faktury do jej opłacenia, dzięki czemu można przeanalizować cały przebieg każdej faktury w procesie obsługi zobowiązań.

W analizie grupowanie zdarzeń według tego identyfikatora to pierwszy krok do odtworzenia przebiegu procesu dla każdej faktury. Umożliwia obliczanie KPI dla poszczególnych case, takich jak całkowity czas procesu, oraz wykrywanie wariantów i wąskich gardeł charakterystycznych dla konkretnych faktur.

Dlaczego to ważne

To niezbędny identyfikator do śledzenia całego cyklu życia faktury i podstawa analiz process mining w obszarze zobowiązań.

Skąd pobrać

Zazwyczaj jest to numer faktury dostawcy z widoku „Vendor invoice” lub powiązanych encji danych w Dynamics 365 Finance.

Przykłady
INV-00125475000921DE-8832-2023
Czas rozpoczęcia
EventTime
Znacznik czasu wskazujący, kiedy wystąpiło działanie lub zdarzenie.
Opis

Ten atrybut określa datę i godzinę każdego działania. Jest niezbędny do chronologicznego uporządkowania zdarzeń i obliczania czasu ich trwania. Stanowi podstawę czasową dziennika zdarzeń.

W analizie czas rozpoczęcia służy do obliczania wszystkich miar związanych z czasem, w tym czasu między działaniami, czasu oczekiwania i całkowitego czasu obsługi case. Pomaga wykrywać wąskie gardła i oceniać wyniki procesu względem SLA.

Dlaczego to ważne

Ten znacznik czasu jest niezbędny do prawidłowego uporządkowania zdarzeń i obliczania miar wydajności, takich jak czas procesu i wąskie gardła.

Skąd pobrać

Pobierany z pól daty utworzenia lub modyfikacji rekordów transakcji, historii workflow albo pól daty księgowania w Dynamics 365.

Przykłady
2023-04-15T09:00:12Z2023-04-18T14:35:00Z2023-05-02T11:21:45Z
Działanie
ActivityName
Nazwa wykonanego kroku procesu biznesowego.
Opis

Ten atrybut zapisuje konkretne działanie lub zdarzenie dotyczące faktury, na przykład „Zarejestrowano fakturę” albo „Zatwierdzono fakturę”. Działania te tworzą węzły na mapie procesu odkrytej na podstawie danych.

Analiza kolejności i częstotliwości działań jest podstawą process mining. Pozwala zobrazować przebieg procesu, wykryć częste i rzadkie ścieżki (warianty) oraz wskazać działania powodujące opóźnienia lub konieczność ponownej pracy.

Dlaczego to ważne

Działania określają, co dzieje się w procesie. Umożliwiają utworzenie mapy procesu oraz analizę jego przebiegu i wariantów.

Skąd pobrać

Dane te często pochodzą ze zmian statusu, historii workflow lub zapisów księgowania dokumentów w module zobowiązań Dynamics 365.

Przykłady
Zarejestrowano fakturęZatwierdzono fakturęUsunięto rozbieżnośćZrealizowano płatność
Dostawca
VendorName
Nazwa dostawcy, który przesłał fakturę.
Opis

Ten atrybut wskazuje dostawcę powiązanego z fakturą. Dane dostawcy obejmują zwykle nazwę, identyfikator i kategorię.

Analiza procesu zobowiązań według dostawcy może ujawnić, którzy dostawcy regularnie przesyłają problematyczne faktury, na przykład z częstymi rozbieżnościami, którzy mają specjalne warunki płatności i z którymi wiążą się długie czasy obsługi. Takie informacje pomagają usprawnić współpracę z dostawcami.

Dlaczego to ważne

Umożliwia analizę procesu według dostawcy i wykrywanie problemów, takich jak częste rozbieżności lub opóźnienia w płatnościach.

Skąd pobrać

Powiązany z nagłówkiem faktury dostawcy, zwykle z encją danych „VendTable” na podstawie numeru konta dostawcy.

Przykłady
Contoso LtdFabrikam IncNorthwind Traders
Kwota faktury
InvoiceAmount
Łączna wartość faktury.
Opis

Oznacza łączną kwotę do zapłaty z tytułu faktury dostawcy. To ważna miara finansowa dla każdego case.

Atrybut ten umożliwia analizę finansową procesu zobowiązań. Można go wykorzystać do ustalania priorytetów faktur o wysokiej wartości, analizy czasu zatwierdzania według progów kwotowych oraz oceny finansowych skutków opóźnień w płatnościach i rabatów za wcześniejszą płatność.

Dlaczego to ważne

Dostarcza kontekstu finansowego i pozwala analizować przebieg procesu w zależności od kwoty, na przykład sprawdzić, czy faktury o wysokiej wartości są obsługiwane inaczej.

Skąd pobrać

Znajduje się w nagłówku faktury dostawcy, często w polu takim jak „InvoiceAmount” w „VendInvoiceInfoTable”.

Przykłady
1500.75250.0012345.50
Numer zamówienia zakupu
PurchaseOrderNumber
Unikalny identyfikator zamówienia zakupu powiązanego z fakturą.
Opis

Ten atrybut łączy fakturę z odpowiadającym jej zamówieniem zakupu (PO). Faktury mogą być powiązane z zamówieniem zakupu lub nie.

Analiza tego atrybutu pozwala rozróżnić faktury powiązane z zamówieniem od pozostałych, które często obsługuje się w inny sposób. Ułatwia też ocenę skuteczności uzgadniania faktur z zamówieniami oraz wykrywanie problemów, gdy dane na fakturze nie zgadzają się z zamówieniem.

Dlaczego to ważne

Pozwala rozróżnić faktury powiązane z zamówieniem zakupu od pozostałych, które są obsługiwane inaczej. Jest też niezbędny do analizy skuteczności uzgadniania.

Skąd pobrać

Dane znajdują się w nagłówku lub wierszach faktury od dostawcy, zwykle w polu „PurchId” tabeli „VendInvoiceInfoTable”.

Przykłady
PO-000432PO-000511
Termin płatności faktury
InvoiceDueDate
Termin, do którego należy opłacić fakturę, obliczony na podstawie warunków płatności.
Opis

Ta data wyznacza termin płatności faktury, który pozwala uniknąć kar i dotrzymać ustaleń z dostawcą. Zwykle jest obliczana na podstawie daty faktury i określonych warunków płatności.

Atrybut ten jest niezbędny do analizy zgodności z warunkami płatności. Porównanie daty „Zrealizowano płatność” z terminem płatności faktury pozwala automatycznie wykrywać opóźnienia, obliczać poziom zgodności i ustalać priorytety płatności, aby utrzymać dobre relacje z dostawcami.

Dlaczego to ważne

Pomaga mierzyć terminowość płatności, dbać o relacje z dostawcami i unikać opłat za opóźnienia.

Skąd pobrać

Pole obliczane na podstawie daty faktury i warunków płatności. Przechowywane w polach takich jak „DueDate” w tabelach transakcji dostawców, na przykład „VendTrans”.

Przykłady
2023-05-152023-06-302023-07-01
Użytkownik
UserName
Użytkownik, który wykonał działanie.
Opis

Wskazuje użytkownika odpowiedzialnego za wykonanie kroku procesu, na przykład zarejestrowanie lub zatwierdzenie faktury. Zwykle jest powiązany z identyfikatorem użytkownika w Dynamics 365.

Analiza pracy użytkowników pomaga określić potrzeby szkoleniowe, rozpoznać osoby osiągające dobre wyniki i ocenić rozkład obciążenia. Jest przydatna w dashboardach dotyczących czasu zatwierdzania i efektywności wykorzystania zasobów. Pozwala kierownikom sprawdzić, które osoby lub zespoły tworzą wąskie gardła.

Dlaczego to ważne

Przypisuje pracę konkretnym osobom, co umożliwia analizę obciążenia i wyników oraz wskazanie potrzeb szkoleniowych.

Skąd pobrać

Zwykle znajduje się w polach „Created by” lub „Modified by” rekordów transakcji albo w historii workflow w Dynamics 365.

Przykłady
j.doea.smithr.williams
Warunki płatności
PaymentTerms
Uzgodnione z dostawcą warunki płatności faktury.
Opis

Ten atrybut określa warunki płatności faktury dostawcy, na przykład „Net 30” (płatność w ciągu 30 dni) lub „2/10 Net 30” (rabat 2% przy płatności w ciągu 10 dni, w przeciwnym razie płatność w ciągu 30 dni).

Analiza według warunków płatności pokazuje, jak różne ustalenia wpływają na terminowość płatności i przepływy pieniężne. Ułatwia wskazanie możliwości uzyskania rabatu za wcześniejszą płatność oraz sprawdzenie, których warunków trudniej dotrzymać.

Dlaczego to ważne

Określa terminy płatności i możliwości uzyskania rabatu, wpływając bezpośrednio na zarządzanie przepływami pieniężnymi i oszczędności.

Skąd pobrać

Znajduje się w danych podstawowych dostawcy lub jest określany w zamówieniu zakupu albo nagłówku faktury. Przechowywany w polach takich jak „PaymTermId”.

Przykłady
Płatność w ciągu 30 dniPłatność w ciągu 60 dni2/10 Net 30
Czy płatność była opóźniona
IsLatePayment
Obliczana flaga wskazująca, czy płatność została wykonana po terminie.
Opis

Ten atrybut logiczny przyjmuje wartość true, jeśli działanie „Wykonano płatność” nastąpiło po terminie płatności faktury. Wskazuje dla danego case, czy nie dotrzymano warunków płatności.

Atrybut ułatwia obliczenie KPI „Wskaźnik zgodności z warunkami płatności”. Można go użyć do filtrowania danych i tworzenia dashboardów pokazujących liczbę oraz wartość opóźnionych płatności. Umożliwia też analizę przyczyn opóźnień w poszczególnych przypadkach.

Dlaczego to ważne

Prosta flaga ułatwiająca analizę płatności niezgodnych z warunkami i obliczanie KPI dotyczących terminowości.

Skąd pobrać

To pole nie pochodzi z systemu źródłowego. Oblicza się je w narzędziu process mining, porównując znacznik czasu działania „Wykonano płatność” z atrybutem „InvoiceDueDate”.

Przykłady
truefalse
Czy wykonano automatycznie
IsAutomated
Flaga wskazująca, czy działanie wykonał automatycznie system.
Opis

Ten atrybut logiczny rozróżnia działania wykonane przez użytkowników od tych realizowanych automatycznie przez system, takich jak automatyczne księgowanie lub uzgadnianie faktur.

Analiza tego atrybutu pozwala mierzyć poziom automatyzacji procesu AP. Ułatwia obliczenie wskaźnika Straight-Through Processing (STP) i wskazanie ręcznych działań, które warto w przyszłości zautomatyzować, aby ograniczyć koszty i czas obsługi.

Dlaczego to ważne

Pomaga mierzyć wskaźnik Straight-Through Processing i wskazywać możliwości zwiększenia automatyzacji oraz efektywności.

Skąd pobrać

Wartość ustala się, sprawdzając, czy użytkownik przypisany do działania jest użytkownikiem systemowym lub wsadowym, na przykład „Admin” albo „BatchUser”.

Przykłady
truefalse
Czy wymagała ponownej pracy
IsRework
Obliczana flaga wskazująca, czy faktura wymagała ponownej pracy.
Opis

Ta flaga logiczna przyjmuje wartość true, jeśli przebieg procesu faktury obejmuje działania związane z ponowną pracą, takie jak „Rozwiązano rozbieżność” lub ponowna walidacja danych faktury po pierwszym niepowodzeniu. Wartość jest obliczana dla całego case.

Atrybut bezpośrednio wspiera KPI „Wskaźnik ponownej pracy z powodu rozbieżności”. Ułatwia filtrowanie i agregowanie faktur wymagających dodatkowej pracy ręcznej, a także ocenę wpływu niskiej jakości danych lub wyjątków w procesie.

Dlaczego to ważne

Bezpośrednio mierzy ponowną pracę, ułatwiając określenie skali wyjątków i nieefektywności procesu.

Skąd pobrać

To pole nie pochodzi z systemu źródłowego. Oblicza się je w narzędziu process mining, sprawdzając, czy w danym case wystąpiły działania wskazujące na ponowną pracę.

Przykłady
truefalse
Kod firmy
CompanyCode
Identyfikator jednostki prawnej obsługującej fakturę.
Opis

Ten atrybut wskazuje konkretną firmę lub jednostkę prawną w organizacji odpowiedzialną za fakturę. W środowiskach obejmujących wiele firm jest to ważny wymiar organizacyjny.

Analiza procesu AP według kodu firmy pozwala porównywać wyniki różnych jednostek biznesowych lub prawnych. Ułatwia wykrycie jednostek, które działają mniej sprawnie, częściej wykonują pracę ponownie lub stosują inne warianty procesu. Dzięki temu można wskazać możliwości standaryzacji i wymiany dobrych praktyk.

Dlaczego to ważne

Umożliwia porównywanie wyników i przebiegu procesu w różnych jednostkach prawnych lub biznesowych organizacji.

Skąd pobrać

Standardowe pole w niemal wszystkich tabelach transakcyjnych Dynamics 365, zwykle o nazwie „DataAreaId”.

Przykłady
USMFDEMFGBSI
Kwota rabatu za wcześniejszą płatność
EarlyPaymentDiscountAmount
Możliwa kwota rabatu, jeśli faktura zostanie opłacona wcześniej.
Opis

Ten atrybut pokazuje kwotę rabatu oferowanego przez dostawcę za wcześniejszą płatność, zgodnie z warunkami płatności.

Dane finansowe są potrzebne do dashboardu „Status rabatów za wcześniejszą płatność”. Pozwalają określić wartość wykorzystanych i utraconych rabatów, a tym samym ocenić korzyści finansowe z usprawnienia zatwierdzania faktur i planowania płatności.

Dlaczego to ważne

Pokazuje finansowe korzyści z usprawnienia procesu i bezpośrednio łączy jego wyniki z oszczędnościami.

Skąd pobrać

Pole obliczane na podstawie kwoty faktury i warunków płatności. Wartość jest dostępna w tabelach takich jak „VendTrans” lub w powiązanych polach rabatu gotówkowego.

Przykłady
30.015.00246.91
Numer przyjęcia towaru
GoodsReceiptNumber
Identyfikator dokumentu przyjęcia towaru powiązanego z fakturą.
Opis

Ten atrybut łączy fakturę z zapisem przyjęcia towarów lub usług. Jest to potrzebne do trójstronnego uzgadniania zamówienia zakupu, przyjęcia towaru i faktury.

Atrybut pozwala analizować skuteczność uzgadniania. Jeśli działanie „Uzgodniono przyjęcie towaru” jest opóźnione lub nie dochodzi do skutku, można użyć tego identyfikatora, aby odnaleźć dokument przyjęcia i sprawdzić, czy problem powstał na etapie zakupów lub odbioru towaru, wpływając na obsługę zobowiązań.

Dlaczego to ważne

Ułatwia analizę skuteczności trójstronnego uzgadniania i wskazanie problemów powstałych na etapie przyjmowania towarów.

Skąd pobrać

Powiązanie przez wiersze zamówienia zakupu. Dane często znajdują się w dziennikach dokumentów dostawy („VendPackingSlipJour”) lub powiązanych tabelach.

Przykłady
GRN-00981GRN-01024
Osoba zatwierdzająca
ApproverName
Użytkownik, który zatwierdził lub odrzucił fakturę na danym etapie.
Opis

Ten atrybut wskazuje osobę podejmującą decyzję o zatwierdzeniu na danym etapie workflow. Przy wieloetapowym zatwierdzaniu faktury poszczególne etapy mogą obsługiwać różne osoby.

Atrybut jest potrzebny do dashboardu „Analiza czasu zatwierdzania faktur”. Analiza według osoby zatwierdzającej pozwala wykryć osoby lub zespoły, które spowalniają proces z powodu obciążenia pracą lub innych czynników. Dzięki temu można podjąć odpowiednie działania, aby skrócić czas zatwierdzania.

Dlaczego to ważne

Umożliwia szczegółową analizę procesu zatwierdzania i pomaga wykryć wąskie gardła na poziomie poszczególnych osób lub zespołów.

Skąd pobrać

Dane pochodzą z dzienników historii workflow („WorkflowTrackingStatusTable”), które zapisują użytkownika kończącego każdy etap zatwierdzania.

Przykłady
David ChenMaria GarciaAP_Manager_Group
Ostatnia aktualizacja danych
LastDataUpdate
Znacznik czasu ostatniego odświeżenia danych z systemu źródłowego.
Opis

Ten atrybut wskazuje, kiedy dziennik zdarzeń został ostatnio zaktualizowany danymi z Microsoft Dynamics 365. Informuje, jak aktualne są analizowane dane.

W dashboardach i bieżącym monitorowaniu znacznik czasu pomaga użytkownikom ocenić, czy widzą najnowsze dane o procesie. Pozwala określić aktualność danych i monitorować poprawność działania potoku danych.

Dlaczego to ważne

Informuje użytkowników o aktualności danych, co pomaga podejmować trafne decyzje biznesowe we właściwym czasie.

Skąd pobrać

To pole metadanych generowane i uzupełniane przez narzędzie do wyodrębniania i ładowania danych (ETL) podczas ich pobierania.

Przykłady
2023-06-01T02:00:00Z2023-06-02T02:00:00Z
Przyczyna rozbieżności
DiscrepancyReason
Kod lub opis przyczyny rozbieżności na fakturze.
Opis

Gdy faktura zostaje wstrzymana lub wykryta zostaje rozbieżność, ten atrybut zapisuje jej przyczynę, na przykład „Niezgodna cena”, „Różnica w ilości” lub „Brak przyjęcia towaru”.

Atrybut służy do analizy „Rozwiązywania rozbieżności i ponownej pracy”. Podział ponownej pracy według przyczyny pozwala znaleźć źródła nieefektywności procesu. Jeśli najczęstszym powodem jest „Niezgodna cena”, może to wskazywać na potrzebę lepszego uzgadniania danych między działem zakupów a dostawcami.

Dlaczego to ważne

Wskazuje przyczynę ponownej pracy, dzięki czemu można ukierunkować usprawnienia procesu i ograniczyć wyjątki oraz ręczną obsługę.

Skąd pobrać

Dane mogą być przechowywane w tabelach wstrzymanych faktur, komentarzach workflow lub dedykowanych polach rejestrujących rozbieżności w module AP.

Przykłady
Niezgodna cenaRóżnica w ilościNieprawidłowe zamówienie zakupu
Status faktury
InvoiceStatus
Bieżący status obsługi faktury.
Opis

Ten atrybut wskazuje ostatni znany stan faktury w procesie, na przykład „W trakcie”, „Zatwierdzona”, „Opłacona” lub „Anulowana”. Pokazuje, na jakim etapie cyklu życia znajduje się faktura.

Process mining odtwarza przebieg procesu na podstawie działań, ale końcowy status przydaje się do weryfikacji danych i tworzenia dashboardów podsumowujących stan wszystkich otwartych faktur. Można na przykład wyfiltrować faktury, które są „Zatwierdzone”, ale jeszcze „Nieopłacone”.

Dlaczego to ważne

Podsumowuje bieżący stan faktury. Ułatwia filtrowanie danych i tworzenie dashboardów według statusu.

Skąd pobrać

Często pochodzi z pól statusu dokumentu lub workflow w module AP.

Przykłady
W trakcieZatwierdzonaOpłaconaAnulowana
System źródłowy
SourceSystem
System, z którego wyodrębniono dane.
Opis

Ten atrybut wskazuje źródło danych o zdarzeniach, którym w tym przypadku jest zwykle „Microsoft Dynamics 365”. Jest szczególnie przydatny, gdy łączone są dane z kilku systemów, na przykład narzędzia do skanowania OCR i D365.

W analizie process mining pomaga śledzić pochodzenie danych, rozwiązywać problemy i rozumieć środowisko technologiczne procesu. Umożliwia filtrowanie zdarzeń po systemie źródłowym.

Dlaczego to ważne

Dostarcza informacji o pochodzeniu danych, niezbędnych do ich weryfikacji i analizy procesów obejmujących wiele systemów.

Skąd pobrać

Zwykle jest to stała wartość („Microsoft Dynamics 365”) dodawana podczas wyodrębniania i przekształcania danych.

Przykłady
Microsoft Dynamics 365 FinanceD365 F&OAX2012
Termin uzyskania rabatu
EarlyPaymentDiscountDate
Ostateczny termin płatności faktury uprawniający do rabatu za wcześniejszą płatność.
Opis

Ten atrybut określa ostatni dzień, w którym można opłacić fakturę, aby otrzymać rabat oferowany przez dostawcę. Termin wynika z daty faktury i części warunków płatności dotyczącej rabatu, na przykład „10” w zapisie „2/10 Net 30”.

Data ta jest podstawą analizy „Statusu rabatów za wcześniejszą płatność”. Porównanie terminu z datą zaplanowania lub wykonania płatności pozwala ustalić, czy rabat został wykorzystany, i mierzyć efektywność finansową.

Dlaczego to ważne

Wyznacza termin uzyskania oszczędności, dlatego pomaga ustalać priorytety płatności i wskazywać możliwości poprawy efektywności.

Skąd pobrać

Data obliczana przez system na podstawie warunków płatności i daty faktury. Jest zapisywana w polach takich jak „CashDiscDate” w tabeli „VendTrans”.

Przykłady
2023-04-252023-05-102023-06-15
Wymagane Zalecane Opcjonalne

Działania w procesie obsługi faktur zakupowych

To najważniejsze etapy i punkty kontrolne, które warto zapisać w dzienniku zdarzeń, aby prawidłowo odkrywać przebieg procesu i analizować jego wyniki.
5 Zalecane 9 Opcjonalne
Działanie Opis
Przekazano fakturę do zatwierdzenia
Faktura zostaje formalnie przekazana do workflow, w którym upoważnione osoby ją weryfikują i zatwierdzają. Rozpoczyna się cykl zatwierdzania.
Dlaczego to ważne

To ważny punkt procesu, od którego mierzy się czas zatwierdzania faktury. Pozwala oddzielić czas wprowadzania danych i dopasowywania od czasu oczekiwania na zatwierdzenie.

Skąd pobrać

To jawne zdarzenie zapisane w historii workflow D365 (WorkflowTrackingStatusTable) dla konkretnego dokumentu faktury. Rejestrowany jest znacznik czasu przekazania.

Rejestrowanie

Wyodrębnij z historii workflow zdarzenie „Submitted” dotyczące faktury.

Typ zdarzenia explicit
Zaksięgowano fakturę
Zatwierdzona faktura zostaje oficjalnie ujęta w księdze głównej, tworząc zobowiązanie finansowe. To ważna i często nieodwracalna operacja księgowa.
Dlaczego to ważne

Księgowanie to ważny etap, po którym faktura może zostać opłacona. Potwierdza zakończenie walidacji i zatwierdzania oraz ujęcie zobowiązania.

Skąd pobrać

To jawna transakcja. Data i godzina księgowania są zapisywane w dzienniku faktur dostawców (VendInvoiceJour) i powiązanych zapisach księgi głównej (GeneralJournalEntry).

Rejestrowanie

Użyj znacznika czasu księgowania z tabel VendInvoiceJour lub GeneralJournalEntry.

Typ zdarzenia explicit
Zarejestrowano fakturę
Oznacza utworzenie w systemie rekordu faktury, ręcznie, przez skanowanie OCR lub elektroniczną wymianę danych (EDI). To początek cyklu przetwarzania faktury.
Dlaczego to ważne

To główne zdarzenie rozpoczynające proces. Czas od tego momentu do płatności pozwala obliczyć całkowity czas obsługi faktury, czyli jeden z KPI procesu.

Skąd pobrać

Zdarzenie można wywnioskować ze znacznika czasu utworzenia (pole CreatedDateTime) rekordu nagłówka faktury w tabelach faktur dostawców oczekujących na przetworzenie lub dziennika faktur, na przykład VendInvoiceInfoTable.

Rejestrowanie

Użyj znacznika czasu utworzenia rekordu nagłówka faktury.

Typ zdarzenia inferred
Zatwierdzono fakturę
Oznacza końcowe zatwierdzenie w workflow, które upoważnia do zaksięgowania faktury i przekazania jej do płatności. To ważny etap przed rozpoczęciem płatności.
Dlaczego to ważne

Oznacza koniec cyklu zatwierdzania. Czas od „Submitted for Approval” do tego działania to ważny KPI, który pomaga wykrywać wąskie gardła i długotrwałe workflow zatwierdzania.

Skąd pobrać

Jawne zdarzenie zapisywane w historii workflow (WorkflowTrackingStatusTable), gdy status workflow zmienia się na „Completed” lub „Approved”.

Rejestrowanie

Wyodrębnij z historii workflow zdarzenie „Approved” lub „Completed” dotyczące faktury.

Typ zdarzenia explicit
Zrealizowano płatność
Płatność zostaje oficjalnie zrealizowana przez zaksięgowanie dziennika płatności. Transakcja ta rozlicza zobowiązanie utworzone przy księgowaniu faktury.
Dlaczego to ważne

To jedno z głównych zdarzeń kończących proces. Służy do obliczania zgodności z warunkami płatności, wykrywania opóźnień i mierzenia całkowitego czasu procesu.

Skąd pobrać

Jawne zdarzenie zapisywane podczas księgowania dziennika płatności. Szczegóły rozliczenia są przechowywane w tabeli transakcji dostawców (VendTrans), która łączy płatność z fakturą.

Rejestrowanie

Użyj daty transakcji z rekordu rozliczenia płatności w VendTrans.

Typ zdarzenia explicit
Anulowano fakturę
Faktura zostaje unieważniona lub anulowana po zaksięgowaniu, zwykle w celu poprawienia błędu. To alternatywny, wyjątkowy punkt końcowy procesu.
Dlaczego to ważne

Śledzenie anulowań pomaga ocenić jakość procesu i częstość błędów. Duża liczba anulowań może wskazywać na problemy systemowe na wcześniejszych etapach.

Skąd pobrać

To jawne zdarzenie. D365 tworzy zapis korygujący lub transakcję uznaniową powiązaną z pierwotnym dziennikiem faktury. Datą anulowania jest data księgowania korekty.

Rejestrowanie

Ustal datę księgowania zapisu korygującego powiązanego z pierwotną fakturą.

Typ zdarzenia explicit
Dopasowano przyjęcie towaru
W przypadku dopasowania trójstronnego to działanie potwierdza odbiór towarów lub usług z faktury przez porównanie jej z dokumentami przyjęcia towaru. Weryfikuje zgodność dostawy z fakturą.
Dlaczego to ważne

Śledzenie tego działania pomaga ocenić sprawność dopasowania trójstronnego i wykryć opóźnienia spowodowane brakiem lub błędami w danych o przyjęciu towaru.

Skąd pobrać

Podobnie jak dopasowanie do PO, zdarzenie to można wywnioskować ze zmian statusu faktury potwierdzających pomyślne dopasowanie do dzienników przyjęcia produktów (Packing Slips).

Rejestrowanie

Szukaj zmian statusu lub oznaczeń potwierdzających pomyślne dopasowanie trójstronne.

Typ zdarzenia inferred
Dopasowano zamówienie zakupu
Przypisanie faktury do jednego lub kilku zamówień zakupu w celu sprawdzenia ilości, cen i warunków. To ważny etap weryfikacji faktur opartych na zamówieniu zakupu (PO).
Dlaczego to ważne

Śledzenie tego działania pozwala mierzyć odsetek faktur dopasowanych za pierwszym razem i wykrywać wąskie gardła w procesie dopasowywania. Błędy na tym etapie często prowadzą do ponownego wyjaśniania rozbieżności.

Skąd pobrać

Zdarzenie można wywnioskować, gdy status dopasowania w rekordzie faktury zmieni się na „Matched” lub gdy pomyślnie zapisano szczegóły dopasowania pozycji. Dane te są zwykle przechowywane w tabelach dotyczących pozycji faktur dostawców.

Rejestrowanie

Wskaż zmiany statusu nagłówka lub pozycji faktury potwierdzające pomyślne dopasowanie do PO.

Typ zdarzenia inferred
Odrzucono fakturę
Osoba zatwierdzająca odrzuca fakturę w workflow i zwykle odsyła ją do osoby, która ją zgłosiła, w celu poprawy lub uzupełnienia informacji. Rozpoczyna się ponowna praca nad fakturą.
Dlaczego to ważne

Śledzenie odrzuceń pomaga ustalić przyczyny opóźnień i ponownej pracy. Może ujawnić problemy z dekretacją faktur, naruszenia zasad lub brak wymaganej dokumentacji.

Skąd pobrać

Jawne zdarzenie zapisywane w historii workflow (WorkflowTrackingStatusTable), gdy osoba zatwierdzająca wybierze działanie „Reject”.

Rejestrowanie

Wyodrębnij z historii workflow zdarzenie „Rejected” dotyczące faktury.

Typ zdarzenia explicit
Rozliczono płatność w banku
Płatność zlecona przez firmę została rozliczona przez bank, co potwierdza uzgodnienie wyciągu bankowego. To końcowe potwierdzenie realizacji płatności.
Dlaczego to ważne

To działanie ostatecznie potwierdza wypływ środków. Analiza czasu między realizacją płatności a jej rozliczeniem jest ważna dla zarządzania środkami pieniężnymi.

Skąd pobrać

Informacje pochodzą z modułów uzgadniania wyciągów bankowych. Zdarzenie można wywnioskować, gdy wiersz wyciągu dotyczący płatności zostanie dopasowany i zaksięgowany w D365.

Rejestrowanie

Wymaga powiązania danych transakcji bankowych (BankStmtISOAccountStatement) z pierwotną płatnością.

Typ zdarzenia inferred
Usunięto rozbieżność
Działanie polegające na zdjęciu blokady lub poprawieniu faktury po wykryciu rozbieżności. Faktura jest gotowa do ponownego przekazania do dopasowania lub zatwierdzenia.
Dlaczego to ważne

To działanie zamyka etap ponownej pracy. Czas usuwania rozbieżności wskazuje sprawność obsługi wyjątków.

Skąd pobrać

Zdarzenie można wywnioskować ze znacznika czasu usunięcia statusu „On Hold” z faktury lub ponownego przekazania jej do workflow po odrzuceniu.

Rejestrowanie

Zapisz znacznik czasu zdjęcia blokady lub ponownego przekazania faktury po odrzuceniu.

Typ zdarzenia inferred
Wykryto rozbieżność
Zdarzenie występuje, gdy faktura nie przechodzi walidacji lub nie zgadza się z zamówieniem zakupu albo przyjęciem towaru, co wymaga ręcznej interwencji. Faktura jest wtedy często blokowana lub otrzymuje odpowiedni status.
Dlaczego to ważne

To działanie rozpoczyna ponowną pracę nad fakturą. Analiza częstotliwości i przyczyn pozwala wykryć nieefektywność procesu, problemy z jakością danych lub problemy po stronie dostawców.

Skąd pobrać

Zdarzenie może być zapisane w historii faktury albo wywnioskowane, gdy faktura otrzyma status „On Hold” z kodem przyczyny związanym z rozbieżnością w dopasowaniu. Sprawdź zmiany statusu nagłówka faktury.

Rejestrowanie

Zapisz znacznik czasu nadania fakturze statusu „On Hold” lub ustawienia oznaczenia rozbieżności.

Typ zdarzenia inferred
Zaplanowano płatność
Zaksięgowana faktura zostaje wybrana i dodana do propozycji płatności lub dziennika płatności, co oznacza zaplanowanie jej do przyszłej realizacji. Wskazuje to zamiar dokonania płatności.
Dlaczego to ważne

To działanie jest ważne przy prognozowaniu przepływów pieniężnych i analizie zgodności z warunkami płatności. Pozwala sprawdzić, czy uwzględniono i zaplanowano rabaty za wcześniejszą płatność.

Skąd pobrać

Zdarzenie można wywnioskować z utworzenia wiersza dziennika płatności (LedgerJournalTrans) zawierającego fakturę. Data transakcji w wierszu wskazuje zaplanowaną datę płatności.

Rejestrowanie

Użyj daty utworzenia wiersza dziennika płatności odwołującego się do faktury.

Typ zdarzenia inferred
Zweryfikowano dane faktury
Oznacza wstępną kontrolę kompletności i poprawności danych faktury przez system lub użytkownika, przed dopasowaniem lub zatwierdzeniem. Może to być automatyczna walidacja systemowa albo ręczna weryfikacja.
Dlaczego to ważne

Śledzenie tego działania pomaga wykryć opóźnienia wynikające z niskiej jakości danych. Duża liczba błędów lub długi czas trwania tego etapu mogą wskazywać na problemy z pozyskiwaniem danych, na przykład niską dokładność OCR.

Skąd pobrać

To często zdarzenie wywnioskowane. Można je ustalić na podstawie znacznika czasu zmiany statusu faktury z „New” lub „Draft” na „Validated” albo „Ready for Matching” bądź na podstawie ostatniej modyfikacji przed przekazaniem do workflow.

Rejestrowanie

Zapisz znacznik czasu zmiany statusu potwierdzającej pomyślną walidację lub zdarzenia aktualizacji przed przekazaniem do workflow.

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje ekstrakcji danych

Jak pobrać dane z Microsoft Dynamics 365

Gotowi do rozpoczęcia?

Skorzystaj z tego szablonu danych, aby usprawnić obsługę faktur zakupowych. Wykorzystaj dane o procesie do wskazania i wdrożenia usprawnień.

Koniec z podwójnymi płatnościami. Usprawnij obsługę faktur zobowiązań.

Wykryj nieefektywne działania, ogranicz opłaty za opóźnienia i zmniejsz koszty obsługi nawet o 60%.

Rozpocznij bezpłatny okres próbny

Bezpłatny okres próbny trwa 14 dni. Nie trzeba podawać danych karty płatniczej.