Szablon danych do analizy obsługi faktur w ramach Purchase to Pay

Microsoft Dynamics 365
Szablon danych do analizy obsługi faktur w ramach Purchase to Pay

Szablon danych do analizy obsługi faktur w ramach Purchase to Pay

Ten szablon wskazuje, jak wyodrębnić dane potrzebne do analizy obsługi faktur w ramach Purchase to Pay w Microsoft Dynamics 365. Zawiera listę atrybutów do zebrania, działań do śledzenia oraz praktyczne wskazówki dotyczące ekstrakcji danych. Dzięki niemu można zgromadzić informacje potrzebne do szczegółowej analizy i optymalizacji procesu.
  • Zalecane atrybuty do szczegółowej analizy
  • Najważniejsze działania do śledzenia na każdym etapie obsługi faktury
  • Wskazówki dotyczące wyodrębniania danych z Microsoft Dynamics 365
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty procesu obsługi faktur w ramach Purchase to Pay

Poniżej wymieniono zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby szczegółowo analizować obsługę faktur w ramach Purchase to Pay.
5 Wymagane 7 Zalecane 10 Opcjonalne
Nazwa Opis
Czas zdarzenia
EventTime
Dokładny znacznik czasu wskazujący, kiedy wystąpiła dana czynność lub zdarzenie.
Opis

Czas zdarzenia, czyli znacznik czasu, zapisuje dokładną datę i godzinę wykonania czynności. To ważny element dziennika zdarzeń, który pozwala ustalić kolejność czynności i obliczyć czas ich trwania.

W analizie znacznik czasu stanowi podstawę wszystkich miar związanych z czasem. Służy do obliczania czasu trwania czynności, czasu między etapami, na przykład zatwierdzania, oraz całkowitego czasu obsługi każdej faktury. Umożliwia także analizę trendów w czasie.

Dlaczego to ważne

Ten znacznik czasu jest niezbędny do ustalenia kolejności zdarzeń, obliczania czasów realizacji i czasu trwania oraz wykrywania wąskich gardeł procesu.

Skąd pobrać

Dane pochodzą z pól daty i czasu w różnych tabelach, takich jak createdDateTime lub modifiedDateTime w tabelach VendInvoiceInfoTable, VendTrans i tabelach historii workflow.

Przykłady
2023-04-15T09:00:12Z2023-05-20T14:30:00Z2023-06-01T11:05:45Z
Nazwa czynności
ActivityName
Nazwa konkretnego zdarzenia biznesowego lub zadania, które wystąpiło w danym momencie procesu obsługi faktury.
Opis

Nazwa czynności opisuje konkretny etap lub zmianę statusu w procesie obsługi faktury, na przykład „Faktura zarejestrowana”, „Faktura przekazana do zatwierdzenia” lub „Płatność zrealizowana”. Te dane są niezbędne do utworzenia mapy procesu i zrozumienia kolejności zdarzeń.

Analiza tego atrybutu pokazuje przebieg procesu, typowe ścieżki oraz odstępstwa i wąskie gardła. Służy do obliczania czasu między czynnościami, na przykład od zatwierdzenia do zaksięgowania, oraz do mierzenia częstotliwości zdarzeń, takich jak odrzucenia lub blokady płatności.

Dlaczego to ważne

Określa etapy na mapie procesu, umożliwiając wizualizację jego przebiegu i analizę przejść między czynnościami.

Skąd pobrać

Ten atrybut jest zwykle wyznaczany na podstawie kombinacji pól statusu, typów transakcji lub wpisów w dzienniku zmian w różnych tabelach Dynamics 365 związanych z obsługą faktur.

Przykłady
Faktura przekazana do zatwierdzeniaWykryto rozbieżność przy uzgadnianiuPłatność zrealizowana
Numer faktury
InvoiceNumber
Unikatowy identyfikator każdej faktury dostawcy, używany jako główny identyfikator case do śledzenia jej przebiegu.
Opis

Numer faktury to unikatowy klucz łączący wszystkie czynności związane z pojedynczą fakturą dostawcy. Umożliwia śledzenie jej przebiegu od otrzymania i rejestracji, przez uzgadnianie i zatwierdzanie, aż po płatność.

W analizie process mining ten atrybut ma podstawowe znaczenie. Określa case i pozwala odtworzyć przebieg procesu dla każdej faktury. Dzięki temu można obliczyć całkowity czas obsługi, wykryć warianty procesu oraz analizować cechy i wyniki dotyczące poszczególnych faktur.

Dlaczego to ważne

To podstawowy identyfikator case, który łączy powiązane zdarzenia i umożliwia analizę całego cyklu obsługi każdej faktury.

Skąd pobrać

Zazwyczaj znajduje się w głównej tabeli faktur dostawców, takiej jak VendInvoiceInfoTable, w polu Num.

Przykłady
INV-10056773245-AUS-001-98432
Ostatnia aktualizacja danych
LastDataUpdate
Znacznik czasu wskazujący, kiedy ostatnio odświeżono dane procesu z systemu źródłowego.
Opis

Ten atrybut zapisuje datę ostatniego wyodrębnienia i aktualizacji zbioru danych z Microsoft Dynamics 365. Zazwyczaj ma tę samą wartość dla wszystkich rekordów w ramach jednego wczytania danych.

Informacja ta pozwala ocenić aktualność analizowanych danych. Pokazuje, jak aktualne są wnioski dotyczące procesu, a także pomaga zarządzać harmonogramem odświeżania danych i weryfikować ich przepływ.

Dlaczego to ważne

Informuje o aktualności danych, dzięki czemu wiadomo, jak świeża jest analiza i kiedy można oczekiwać kolejnej aktualizacji.

Skąd pobrać

Ten znacznik czasu jest generowany i dodawany do zbioru przez proces wyodrębniania danych lub ETL podczas jego uruchomienia.

Przykłady
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
System źródłowy
SourceSystem
System, z którego wyodrębniono dane o zdarzeniach.
Opis

Ten atrybut wskazuje aplikację źródłową, z której pochodzą dane o czynnościach. W tym procesie będzie to zazwyczaj „Microsoft Dynamics 365”.

W środowiskach korzystających z wielu systemów, na przykład z zewnętrznego rozwiązania OCR lub do przechwytywania danych, to pole pomaga ustalić, w którym systemie odbywa się każdy etap procesu. Ułatwia śledzenie pochodzenia danych i diagnozowanie problemów z ich wyodrębnianiem.

Dlaczego to ważne

Dostarcza ważnych informacji o pochodzeniu danych, co pomaga je weryfikować i zrozumieć, z jakich systemów korzysta proces.

Skąd pobrać

To stała wartość „Microsoft Dynamics 365”, dodawana podczas przekształcania danych w celu oznaczenia źródła zbioru.

Przykłady
Microsoft Dynamics 365
Czas zakończenia
EndTime
Dokładny znacznik czasu wskazujący, kiedy zakończono daną czynność lub zdarzenie.
Opis

Czas zakończenia wskazuje, kiedy dana czynność dobiegła końca. W połączeniu z czasem rozpoczęcia (EventTime) pozwala dokładnie obliczyć czas trwania każdego kroku.

Atrybut ten jest niezbędny do obliczania czasu przetwarzania (ProcessingTime) dla każdej czynności, ważnego miernika w analizie wyników. Pomaga precyzyjnie wskazać kroki, które zajmują najwięcej czasu, i ukierunkować działania usprawniające. Można na przykład zmierzyć dokładny czas ręcznego kodowania lub zatwierdzania.

Dlaczego to ważne

Umożliwia bezpośrednie obliczanie czasu przetwarzania poszczególnych czynności, co pomaga wskazać najbardziej czasochłonne kroki procesu.

Skąd pobrać

Podobnie jak StartTime, wartość pochodzi z różnych pól daty i czasu. W przypadku niektórych czynności może to być StartTime następnej czynności. W innych przypadkach będzie to konkretny znacznik czasu zakończenia.

Przykłady
2023-04-15T09:15:20Z2023-05-20T18:00:00Z2023-06-01T11:05:45Z
Kwota faktury
InvoiceAmount
Łączna kwota należności z faktury.
Opis

Ten atrybut określa łączną kwotę do zapłaty podaną na fakturze od dostawcy. To podstawowa dana finansowa dla każdej sprawy.

Kwota faktury jest często wykorzystywana do segmentacji i analizy. Pozwala sprawdzić, czy faktury o wysokiej wartości przechodzą bardziej rygorystyczny proces zatwierdzania lub są przetwarzane dłużej. W dashboardach służy też do analizy liczby faktur według wartości. Można ją również agregować, aby obliczyć łączną wartość analizowanych wydatków.

Dlaczego to ważne

Umożliwia analizę według wartości finansowej, pomaga ustalać priorytety usprawnień dotyczących faktur o wysokiej wartości i lepiej rozumieć czynniki wpływające na koszty.

Skąd pobrać

Znajduje się w tabeli nagłówków faktur, na przykład VendInvoiceInfoTable, w polu takim jak InvoiceAmount lub Amount.

Przykłady
1500.00250.7512500.50
Numer dostawcy
VendorNumber
Unikalny identyfikator dostawcy, który przesłał fakturę.
Opis

Numer dostawcy to kod, który jednoznacznie identyfikuje dostawcę w danych podstawowych. Łączy transakcję faktury z konkretnym dostawcą, umożliwiając analizę według dostawców.

Ten atrybut jest niezbędny do segmentowania danych o procesie według dostawcy. Pomaga odpowiedzieć na pytania, takie jak: „Którzy dostawcy najdłużej czekają na zatwierdzenie faktury?” lub „Czy rozbieżności przy uzgadnianiu częściej dotyczą określonych dostawców?”. Analiza wyników według dostawców może wskazać możliwości współpracy z nimi i usprawnienia procesu.

Dlaczego to ważne

Umożliwia filtrowanie danych i analizę przyczyn źródłowych według dostawcy, co pomaga wykrywać problemy z wynikami lub wzorce związane z konkretnymi dostawcami.

Skąd pobrać

Zazwyczaj znajduje się w nagłówku tabeli faktur od dostawców, takiej jak VendInvoiceInfoTable, powiązanej z głównymi danymi dostawców w tabeli VendTable.

Przykłady
V-1001V-2050V-8342
Numer zamówienia zakupu
PurchaseOrderNumber
Identyfikator zamówienia zakupu (PO), którego dotyczy faktura.
Opis

Numer zamówienia zakupu łączy fakturę z pierwotnym dokumentem zakupu. Ma to istotne znaczenie w procesach, w których porównuje się dwa lub trzy dokumenty: fakturę, zamówienie zakupu i potwierdzenie odbioru towaru.

Ten atrybut umożliwia analizę faktur powiązanych z zamówieniem zakupu i faktur bez takiego powiązania, które często przechodzą inną ścieżkę procesu. Pomaga ocenić skuteczność uzgadniania, badać rozbieżności i mierzyć odsetek faktur powiązanych z zamówieniem, które są przetwarzane bez ręcznej interwencji.

Dlaczego to ważne

Pozwala odróżnić faktury powiązane z zamówieniem zakupu od pozostałych. To jedno z głównych źródeł różnic w przebiegu procesu i ważny element analizy uzgadniania.

Skąd pobrać

Znajduje się w tabeli nagłówków faktur, takiej jak VendInvoiceInfoTable, często w polu PurchId.

Przykłady
PO-001234PO-005678PO-009101
Status faktury
InvoiceStatus
Bieżący status faktury w chwili wyodrębnienia danych.
Opis

Status faktury określa jej bieżący etap w cyklu życia, na przykład „Oczekuje na zatwierdzenie”, „Zatwierdzona”, „Zaksięgowana” lub „Opłacona”. Pokazuje, na jakim etapie znajduje się faktura.

Atrybut ten służy przede wszystkim do tworzenia dashboardów operacyjnych, które pokazują bieżące obciążenie pracą i zaległości. Pomaga kierownikom sprawdzić, ile faktur znajduje się na poszczególnych etapach procesu, co ułatwia przydzielanie zasobów i monitorowanie operacji. Jest podstawą dashboardu „Przepustowość i status przetwarzania faktur”.

Dlaczego to ważne

Pokazuje bieżący stan wszystkich faktur. Ułatwia monitorowanie operacji i obciążenia pracą oraz wykrywanie aktualnych wąskich gardeł.

Skąd pobrać

Zazwyczaj wynika z pól statusu w głównej tabeli faktur, takiej jak VendInvoiceInfoTable.

Przykłady
Oczekuje na zatwierdzenieZaksięgowanaOpłacona
Termin płatności
PaymentDueDate
Data, do której należy opłacić fakturę zgodnie z uzgodnionymi warunkami płatności.
Opis

Termin płatności jest obliczany na podstawie daty faktury i warunków płatności uzgodnionych z dostawcą. To umowny termin zapłaty.

Data ta ma istotne znaczenie przy ocenie wyników finansowych i zarządzaniu relacjami z dostawcami. Służy jako punkt odniesienia przy obliczaniu KPI „Odsetek płatności terminowych”, który porównuje termin płatności z datą faktycznego wykonania płatności. Analiza pomaga wykrywać systemowe przyczyny opóźnień, które mogą pogorszyć relacje z dostawcami lub uniemożliwić skorzystanie ze skonta za wcześniejszą płatność.

Dlaczego to ważne

To punkt odniesienia przy ocenie terminowości płatności, ważny KPI dotyczący kondycji finansowej i relacji z dostawcami.

Skąd pobrać

System często oblicza tę datę i zapisuje ją w tabeli transakcji dostawców, takiej jak VendTrans, na podstawie daty faktury i warunków płatności.

Przykłady
2023-05-152023-06-302023-07-20
Użytkownik
User
Identyfikator lub nazwa użytkownika, który wykonał daną czynność.
Opis

Ten atrybut wskazuje pracownika lub użytkownika systemu odpowiedzialnego za wykonanie danego kroku procesu. W przypadku kroków zautomatyzowanych może to być konto systemowe lub serwisowe.

Analiza procesu według użytkownika pomaga ocenić rozkład obciążenia pracą, określić potrzeby szkoleniowe i porównać wyniki poszczególnych osób lub zespołów. Jest też ważna przy analizie pętli poprawek, w których zadanie jest przekazywane między użytkownikami, oraz przy badaniu różnic w sposobie wykonywania tego samego zadania.

Dlaczego to ważne

Umożliwia analizę wyników i obciążenia pracą według użytkownika lub zespołu, a także pomaga określić poziom automatyzacji i źródła poprawek.

Skąd pobrać

Dane pochodzą z pól identyfikatora użytkownika w tabelach transakcji lub historii workflow, takich jak createdby lub modifiedby. Mogą też znajdować się w tabelach śledzenia workflow.

Przykłady
j.doea.smithAX_Admin
Czy płatność była terminowa
IsOnTimePayment
Obliczana flaga wskazująca, czy fakturę opłacono w terminie lub przed terminem płatności.
Opis

Ten atrybut logiczny jest wyliczany przez porównanie znacznika czasu czynności „Wykonano płatność” z terminem płatności. Jeśli data płatności jest wcześniejsza lub równa terminowi płatności, wartość wynosi true. W przeciwnym razie wynosi false.

Atrybut ten bezpośrednio wspiera KPI „Odsetek płatności terminowych” i dashboard „Zgodność z warunkami płatności”. Ułatwia analizę, ponieważ dla każdej faktury podaje jednoznaczny wynik. Można łatwo filtrować opóźnione płatności i badać ich przyczyny według dostawcy, działu lub kraju.

Dlaczego to ważne

Bezpośrednio mierzy zgodność z warunkami płatności, ułatwiając obliczanie KPI dotyczącego odsetka płatności terminowych i powiązane analizy.

Skąd pobrać

Atrybut ten jest obliczany na etapie transformacji danych. Zastosowana reguła: (znacznik czasu czynności „Wykonano płatność”) <= (termin płatności).

Przykłady
truefalse
Czy zautomatyzowano
IsAutomated
Flaga wskazująca, czy czynność wykonał automatycznie system, czy użytkownik.
Opis

Ten atrybut logiczny (true/false) odróżnia zdarzenia wykonywane przez system od zadań realizowanych ręcznie przez użytkownika. Na przykład uzgadnianie faktury może być zautomatyzowane, a obsługa rozbieżności wykonywana ręcznie.

Analiza tego atrybutu pomaga określić poziom automatyzacji procesu. Umożliwia ocenę skuteczności wdrożonych rozwiązań, wskazuje pozostałe ręczne wąskie gardła i pokazuje możliwości dalszej automatyzacji, która może usprawnić proces i ograniczyć liczbę błędów.

Dlaczego to ważne

Pomaga ocenić poziom automatyzacji procesu, wskazać ręczne wąskie gardła i znaleźć możliwości zwiększenia efektywności.

Skąd pobrać

Zazwyczaj wartość ustala się na podstawie atrybutu „Użytkownik”. Jeśli użytkownik jest znanym kontem systemowym lub serwisowym, flaga przyjmuje wartość true.

Przykłady
truefalse
Dział
Department
Centrum kosztów lub dział, do którego przypisano koszty faktury.
Opis

Dział wskazuje jednostkę organizacyjną lub centrum kosztów odpowiedzialne za wydatek ujęty na fakturze. Zazwyczaj jest określany podczas kodowania faktury.

Analiza procesu według działu pomaga zrozumieć różnice w wydatkach, czasie zatwierdzania i zgodności z zasadami. Ułatwia wskazanie działów, w których występuje najwięcej wyjątków dotyczących faktur lub najdłużej trwają cykle zatwierdzania. To podstawa do ukierunkowanej komunikacji i szkoleń.

Dlaczego to ważne

Umożliwia analizę kosztów i procesu według działu, pokazując różnice w wynikach i zgodności w całej organizacji.

Skąd pobrać

Dane pochodzą z wymiarów finansowych powiązanych z pozycjami lub nagłówkiem faktury. Wymaga to odpytywania struktur danych dotyczących wymiarów.

Przykłady
SprzedażMarketingOperacje IT
Kod firmy
CompanyCode
Identyfikator podmiotu prawnego lub firmy w organizacji, która przetwarza fakturę.
Opis

Kod firmy wskazuje konkretny podmiot prawny odpowiedzialny finansowo za fakturę. W organizacji obejmującej wiele firm jest to ważna dana do segmentacji finansowej.

Atrybut ten pozwala filtrować i porównywać procesy w różnych podmiotach prawnych. Może ujawnić, czy wyniki procesu, zasady lub wąskie gardła dotyczą konkretnych firm w grupie, co ułatwia lokalne usprawnianie procesów.

Dlaczego to ważne

Umożliwia segmentowanie analizy procesu według podmiotu prawnego, co ma duże znaczenie w organizacjach obejmujących wiele firm.

Skąd pobrać

To standardowe pole w większości tabel finansowych Dynamics 365, często nazywane DataAreaId.

Przykłady
USMFDEMFGBSI
Łączny czas cyklu
TotalCycleTime
Łączny czas przetwarzania pojedynczej faktury od jej otrzymania do zapłaty.
Opis

Łączny czas cyklu mierzy cały czas, jaki faktura spędza w procesie. Oblicza się go jako różnicę między pierwszą czynnością (np. „Zarejestrowano fakturę”) a ostatnią (np. „Wykonano płatność”) dla danego numeru faktury.

To podstawowy KPI służący do oceny ogólnej efektywności procesu. Pokazuje wyniki w ujęciu ogólnym i jest wykorzystywany w dashboardzie „Czas realizacji faktury od początku do końca”. Analiza trendów i segmentacja według atrybutów, takich jak dostawca lub kwota, pomagają wskazać obszary wymagające usprawnień.

Dlaczego to ważne

To podstawowy KPI pokazujący ogólne tempo i efektywność procesu oraz podsumowujący wyniki dla każdej faktury.

Skąd pobrać

Wartość oblicza się dla każdej sprawy w narzędziu process mining lub podczas przygotowania danych. Jest to różnica między znacznikami czasu pierwszego i ostatniego zdarzenia dla każdego CaseId.

Przykłady
P15DP22DT5H30MP7D
Powód blokady płatności
PaymentBlockReason
Kod wyjaśniający, dlaczego zablokowano płatność za fakturę.
Opis

Blokada płatności uniemożliwia opłacenie faktury. Ten atrybut zapisuje powód blokady, zwykle w postaci standardowego kodu wybranego przez użytkownika, na przykład „Kwestionowane opłaty” lub „Oczekiwanie na odbiór towaru”.

Atrybut ten jest niezbędny do dashboardu „Częstotliwość i czas trwania blokad płatności”. Analiza najczęstszych powodów blokad pomaga wykryć problemy u źródła w procesie P2P. Ich rozwiązanie może znacznie ograniczyć opóźnienia w płatnościach i poprawić relacje z dostawcami.

Dlaczego to ważne

Wyjaśnia, dlaczego płatności są celowo wstrzymywane, i pomaga wykrywać oraz rozwiązywać wcześniejsze problemy powodujące blokady.

Skąd pobrać

Zazwyczaj jest to pole w rekordzie transakcji dostawcy lub faktury, powiązane ze statusem blokady płatności. Należy szukać go w tabelach takich jak VendTrans.

Przykłady
Spór dotyczący jakościOczekiwanie na notę kredytowąBlokada ręczna
Powód odrzucenia
RejectionReason
Powód podany przez osobę zatwierdzającą, która odrzuciła fakturę.
Opis

Gdy faktura zostaje odrzucona w workflow zatwierdzania, osoba zatwierdzająca zazwyczaj podaje powód. Ten atrybut zapisuje wyjaśnienie, które może mieć postać predefiniowanego kodu lub dowolnego tekstu.

To ważny atrybut dashboardu „Analiza odrzuconych faktur”. Dostarcza informacji potrzebnych do ustalenia przyczyn odrzuceń, takich jak „Nieprawidłowy numer zamówienia zakupu”, „Zduplikowana faktura” lub „Niezgodna cena”. Analiza powodów pomaga ustalić priorytety działań ograniczających liczbę odrzuceń.

Dlaczego to ważne

Pokazuje bezpośrednio, dlaczego faktury są odrzucane, co pozwala ograniczyć poprawki i zwiększyć odsetek spraw załatwianych prawidłowo za pierwszym razem.

Skąd pobrać

Zazwyczaj znajduje się w komentarzach lub dziennikach historii tabel przetwarzania workflow.

Przykłady
Nieprawidłowa ilośćZduplikowana fakturaPrzekroczony limit zatwierdzania
Rodzaj rozbieżności
MatchingDiscrepancyType
Określa rodzaj niezgodności wykrytej podczas uzgadniania faktury z zamówieniem zakupu.
Opis

Gdy podczas uzgadniania dwóch lub trzech dokumentów wystąpi rozbieżność, ten atrybut określa jej rodzaj, na przykład „Niezgodna cena”, „Niezgodna ilość” lub „Brak potwierdzenia odbioru towaru”.

Dane te są podstawą dashboardu „Czas rozwiązywania rozbieżności przy uzgadnianiu”. Analiza częstotliwości poszczególnych rodzajów rozbieżności pozwala ustalić przyczyny niepowodzeń uzgadniania. Częste niezgodności cen mogą na przykład wskazywać na nieaktualne dane podstawowe, a niezgodności ilości mogą wynikać z problemów z dostawą.

Dlaczego to ważne

Klasyfikuje niepowodzenia uzgadniania, umożliwiając analizę przyczyn źródłowych, ograniczenie liczby rozbieżności i zwiększenie odsetka spraw przetwarzanych bez ręcznej interwencji.

Skąd pobrać

Informacje te mogą być przechowywane w osobnej tabeli dziennika uzgadniania lub wyjątków. Mogą też wymagać ustalenia na podstawie komunikatów o statusie lub komentarzy w workflow.

Przykłady
Niezgodna cenaNiezgodna ilośćBrak potwierdzenia odbioru towaru
Waluta faktury
InvoiceCurrency
Kod waluty, w której podano kwotę faktury, np. USD lub EUR.
Opis

Waluta faktury określa, w jakiej walucie podano jej kwotę. Ma to znaczenie dla międzynarodowych organizacji współpracujących z dostawcami z różnych krajów.

Atrybut ten uzupełnia informację o kwocie faktury i służy do filtrowania oraz raportowania, zwłaszcza w operacjach globalnych. Pozwala prawidłowo interpretować wartości finansowe i analizować je według waluty lub przeliczać na wspólną walutę raportową.

Dlaczego to ważne

Zapewnia niezbędny kontekst dla kwot finansowych, dzięki czemu wartości faktur z różnych regionów można prawidłowo interpretować i analizować.

Skąd pobrać

Znajduje się w tabeli nagłówków faktur, obok kwoty, na przykład w polu CurrencyCode tabeli VendInvoiceInfoTable.

Przykłady
USDEURGBP
Warunki płatności
PaymentTerms
Warunki płatności uzgodnione z dostawcą, na przykład „Net 30” lub „2% 10, Net 30”.
Opis

Warunki płatności określają uzgodnione zasady regulowania należności wobec dostawcy, w tym termin płatności i ewentualne rabaty. Informacje te pochodzą zazwyczaj z danych podstawowych dostawcy lub zamówienia zakupu.

Atrybut ten uzupełnia informacje o terminie płatności i KPI dotyczącym odsetka płatności terminowych. Analiza związku między określonymi warunkami płatności a opóźnieniami może ujawnić problemy operacyjne. Pomaga też planować finanse i efektywnie zarządzać kapitałem obrotowym.

Dlaczego to ważne

Uzupełnia informacje o terminach płatności i pomaga analizować finansowe skutki terminów płatności oraz wykorzystania rabatów.

Skąd pobrać

Informacje te są przechowywane w danych podstawowych dostawcy (VendTable) i kopiowane do tabel transakcji, takich jak VendInvoiceInfoTable.

Przykłady
Net 30Net 602% 10, Net 30
Wymagane Zalecane Opcjonalne

Działania w procesie obsługi faktur w ramach Purchase to Pay

To najważniejsze kroki i punkty kontrolne, które warto rejestrować w dzienniku zdarzeń, aby prawidłowo odkrywać i analizować workflow obsługi faktur.
6 Zalecane 8 Opcjonalne
Działanie Opis
Faktura przekazana do zatwierdzenia
To zdarzenie oznacza formalne przekazanie faktury do workflow w celu weryfikacji i zatwierdzenia. Silnik workflow Dynamics 365 jawnie rejestruje to przekazanie.
Dlaczego to ważne

To punkt początkowy pomiaru całego cyklu zatwierdzania. Pozwala ustalić, jak długo faktury czekają na rozpoczęcie zatwierdzania, i stanowi punkt odniesienia dla KPI związanych z tym etapem.

Skąd pobrać

Jest to jawne zdarzenie rejestrowane w tabelach historii workflow, np. WorkflowTrackingStatusTable, gdy faktura zostaje przekazana do workflow.

Rejestrowanie

Znacznik czasu utworzenia rekordu przekazania do workflow w historii workflow.

Typ zdarzenia explicit
Faktura uzgodniona z zamówieniem zakupu
Oznacza pomyślne zakończenie uzgadniania, gdy dane faktury są zgodne z zamówieniem zakupu i informacjami o przyjęciu towaru. Zdarzenie wnioskuje się, gdy status uzgadniania faktury zmienia się na „Passed”.
Dlaczego to ważne

Pomyślne uzgodnienie to ważny etap w przypadku faktur powiązanych z zamówieniem zakupu. Potwierdza zasadność obciążenia przed płatnością. Jest też niezbędne do śledzenia efektywności uzgadniania i poziomu automatyzacji.

Skąd pobrać

Zdarzenie wnioskuje się na podstawie zmiany pola statusu uzgadniania w nagłówku lub pozycjach faktury dostawcy, np. w tabeli VendInvoiceInfoTable, na wartość „Passed” lub „Successfully Matched”.

Rejestrowanie

Znacznik czasu zmiany statusu na „Passed” w szczegółach weryfikacji uzgodnienia faktury.

Typ zdarzenia inferred
Faktura zaksięgowana
To formalne zdarzenie księgowe, podczas którego zatwierdzona faktura zostaje ujęta w księdze głównej, tworząc zobowiązanie. Jest to jawne zdarzenie transakcyjne w systemie.
Dlaczego to ważne

Księgowanie to ostatni etap przed płatnością i ważny punkt kontroli finansowej. Czas od „Faktura zatwierdzona” do „Faktura zaksięgowana” mierzy efektywność końcowych czynności księgowych.

Skąd pobrać

Jest to jawne zdarzenie rejestrowane podczas tworzenia zaksięgowanej transakcji dostawcy w tabelach takich jak VendTrans oraz powiązanych rekordach GeneralJournalEntry i LedgerEntry.

Rejestrowanie

Znacznik czasu utworzenia rekordu w tabeli transakcji dostawcy (VendTrans).

Typ zdarzenia explicit
Faktura zarejestrowana
To wstępne wprowadzenie faktury do systemu, które tworzy jej rekord przed uzupełnieniem wszystkich danych. Zdarzenie jest rejestrowane po utworzeniu nowego rekordu w dzienniku rejestru faktur dostawców.
Dlaczego to ważne

To zdarzenie oznacza formalny początek procesu obsługi faktury. Analiza czasu od tego momentu pozwala zmierzyć całkowity czas obsługi i wykryć opóźnienia na wczesnym etapie.

Skąd pobrać

Jest to jawne zdarzenie rejestrowane podczas tworzenia rekordu w rejestrze faktur dostawców, zwykle w tabeli VendInvoiceRegisterJournalTable lub podobnej tabeli faktur oczekujących.

Rejestrowanie

Znacznik czasu utworzenia rekordu w dzienniku rejestru faktur dostawców.

Typ zdarzenia explicit
Faktura zatwierdzona
Oznacza ostateczne zatwierdzenie faktury w workflow, które uprawnia do jej zaksięgowania i opłacenia. Silnik workflow jawnie rejestruje to zdarzenie po zakończeniu procesu.
Dlaczego to ważne

To ważny etap kończący proces zatwierdzania. Czas od zdarzenia „Faktura przekazana do zatwierdzenia” do tego momentu mierzy efektywność zatwierdzania i pomaga wykryć wąskie gardła.

Skąd pobrać

Jest to jawne zdarzenie rejestrowane w tabelach historii workflow, np. WorkflowTrackingStatusTable, gdy status workflow zmienia się na „Approved”.

Rejestrowanie

Znacznik czasu wpisu ze statusem „Approved” w historii workflow.

Typ zdarzenia explicit
Płatność zrealizowana
To ostatnie zdarzenie oznacza zaksięgowanie dziennika płatności, które tworzy płatność i rozlicza fakturę. Jest to jawne zdarzenie transakcyjne zamykające cykl obsługi faktury.
Dlaczego to ważne

To zdarzenie oznacza pomyślne zakończenie procesu od faktury do płatności. Stanowi podstawę do pomiaru „Odsetka płatności zrealizowanych w terminie” i całkowitego czasu obsługi od początku do końca.

Skąd pobrać

Jest to jawne zdarzenie rejestrowane podczas księgowania dziennika płatności. Informacje o rozliczeniu są zapisywane w tabelach takich jak VendSettlement, które łączą płatność z fakturą.

Rejestrowanie

Znacznik czasu zaksięgowania dziennika płatności rozliczającego transakcję dostawcy.

Typ zdarzenia explicit
Dane faktury wprowadzone
Oznacza zakończenie wprowadzania danych faktury, w tym danych nagłówka i pozycji, przed przekazaniem jej do uzgadniania lub zatwierdzenia. Zdarzenie często wnioskuje się na podstawie zmiany statusu faktury z „nowa” lub „zarejestrowana” na „gotowa do przetwarzania”.
Dlaczego to ważne

Śledzenie tego zdarzenia pozwala ocenić efektywność wprowadzania danych, ręcznego lub automatycznego (OCR). Opóźnienia na tym etapie mogą wydłużyć cały proces.

Skąd pobrać

Zdarzenie wnioskuje się na podstawie zmian statusu rekordu oczekującej faktury dostawcy, np. w tabeli VendInvoiceInfoTable. Występuje, gdy uzupełniono wszystkie wymagane pola i faktura jest gotowa do kolejnego etapu.

Rejestrowanie

Wykryj zmianę statusu w tabeli oczekujących faktur, która oznacza zakończenie wprowadzania danych.

Typ zdarzenia inferred
Faktura odrzucona
Oznacza odrzucenie faktury przez osobę zatwierdzającą. Proces zostaje wstrzymany, a faktura jest zwykle zwracana do poprawy. Silnik workflow jawnie rejestruje odrzucenie.
Dlaczego to ważne

Śledzenie odrzuceń pozwala określić skalę poprawek i wykryć częste przyczyny problemów, takie jak błędne kodowanie lub naruszenie zasad. Wspiera to bezpośrednio KPI „Odsetek odrzuconych faktur”.

Skąd pobrać

Jest to jawne zdarzenie rejestrowane w tabelach historii workflow, np. WorkflowTrackingStatusTable, gdy status workflow zmienia się na „Rejected” lub „Canceled”.

Rejestrowanie

Znacznik czasu wpisu ze statusem „Rejected” w historii workflow.

Typ zdarzenia explicit
Faktura zakodowana
To zdarzenie oznacza przypisanie kont księgi głównej do pozycji faktury. Zazwyczaj wnioskuje się je na podstawie utworzenia lub zatwierdzenia rozksięgowań powiązanych z fakturą.
Dlaczego to ważne

Kodowanie ma istotne znaczenie dla poprawności finansowej. Pomiar czasu kodowania faktur pomaga wykryć wąskie gardła w procesie weryfikacji księgowej i wspiera KPI „Średni czas od wprowadzenia danych do zakodowania”.

Skąd pobrać

Zdarzenie wnioskuje się na podstawie utworzenia i zatwierdzenia rekordów w tabelach rozksięgowań księgowych, np. AccountingDistribution, powiązanych z oczekującą fakturą dostawcy.

Rejestrowanie

Znacznik czasu zapisania i zatwierdzenia rozksięgowań księgowych dla faktury.

Typ zdarzenia inferred
Płatność zaplanowana
To zdarzenie występuje, gdy zaksięgowana faktura zostaje uwzględniona w propozycji płatności lub dzienniku płatności, ale płatność nie została jeszcze zrealizowana. Jest to jawne działanie, które tworzy wiersz dziennika płatności.
Dlaczego to ważne

To moment przejścia od zobowiązań do operacji skarbowych. Analiza tego etapu może ujawnić opóźnienia między zaksięgowaniem faktury a rozpoczęciem płatności.

Skąd pobrać

Jest to jawne zdarzenie rejestrowane podczas tworzenia wiersza w dzienniku płatności (LedgerJournalTrans), który rozlicza zaksięgowaną transakcję dostawcy.

Rejestrowanie

Znacznik czasu utworzenia wiersza dziennika płatności odwołującego się do faktury.

Typ zdarzenia explicit
Rozbieżność przy uzgadnianiu obsłużona
Oznacza usunięcie wcześniej wykrytej rozbieżności przy uzgadnianiu, dzięki czemu faktura może przejść do kolejnego etapu. Zdarzenie wnioskuje się, gdy fakturę ze statusem uzgadniania „Failed” uzgodniono ponownie lub ręcznie zatwierdzono wyjątek.
Dlaczego to ważne

To zdarzenie kończy podproces wyjaśniania rozbieżności. Czas od zdarzenia „Wykryto rozbieżność przy uzgadnianiu” do tego momentu jest ważnym KPI efektywności jej usuwania.

Skąd pobrać

Zdarzenie wnioskuje się na podstawie pomyślnego uzgodnienia („Faktura uzgodniona z zamówieniem zakupu”), które następuje po wykryciu rozbieżności przy uzgadnianiu dla tej samej faktury.

Rejestrowanie

Znajdź znacznik czasu statusu „Passed”, który następuje po znaczniku czasu statusu „Failed”.

Typ zdarzenia inferred
Ustawiono blokadę płatności
To zdarzenie występuje, gdy faktura zostaje zablokowana, co uniemożliwia jej opłacenie. Jest rejestrowane jako zmiana pola blokady płatności lub wstrzymania w zaksięgowanym rekordzie faktury.
Dlaczego to ważne

Blokady płatności często powodują opóźnienia. Analiza tego, kiedy i dlaczego są nakładane, pomaga poprawić terminowość płatności i relacje z dostawcami.

Skąd pobrać

Zdarzenie wnioskuje się na podstawie zmiany pola wstrzymania lub blokady płatności w zaksięgowanej transakcji dostawcy (VendTrans). Znacznik czasu można pobrać z dziennika zmian.

Rejestrowanie

Znacznik czasu aktualizacji, która ustawia blokadę płatności w transakcji dostawcy.

Typ zdarzenia inferred
Usunięto blokadę płatności
Oznacza usunięcie blokady płatności, dzięki czemu faktura może zostać uwzględniona w harmonogramie płatności. Zdarzenie jest rejestrowane, gdy pole blokady płatności zostaje wyczyszczone lub zmienione na stan bez blokady.
Dlaczego to ważne

Mierzy czas potrzebny na rozwiązanie problemów powodujących wstrzymanie płatności. Długi okres między nałożeniem a usunięciem blokady wskazuje na nieefektywne rozwiązywanie problemów.

Skąd pobrać

Zdarzenie wnioskuje się na podstawie zmiany, która czyści pole wstrzymania lub blokady płatności w zaksięgowanej transakcji dostawcy (VendTrans). Znacznik czasu można pobrać z dziennika zmian.

Rejestrowanie

Znacznik czasu aktualizacji, która usuwa blokadę płatności w transakcji dostawcy.

Typ zdarzenia inferred
Wykryto rozbieżność przy uzgadnianiu
To zdarzenie występuje, gdy uzgadnianie faktury kończy się niepowodzeniem z powodu rozbieżności między fakturą, zamówieniem zakupu lub przyjęciem towaru. Jest rejestrowane, gdy status uzgadniania faktury zmienia się na „Failed” lub „Discrepancy”.
Dlaczego to ważne

Ustalenie, kiedy i dlaczego pojawiają się rozbieżności, ma zasadnicze znaczenie dla KPI „Odsetek rozbieżności przy uzgadnianiu”. To zdarzenie oznacza początek ich wyjaśniania, które często powoduje znaczne opóźnienia.

Skąd pobrać

Zdarzenie wnioskuje się na podstawie zmiany pola statusu uzgadniania faktury dostawcy, np. w tabeli VendInvoiceInfoTable, na wartość „Failed”. Często rejestrowana jest również przyczyna niepowodzenia.

Rejestrowanie

Znacznik czasu zmiany statusu na „Failed” lub „Discrepancy” podczas uzgadniania.

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje ekstrakcji danych

Jak pobrać dane z Microsoft Dynamics 365

Gotowi, aby zacząć?

Skorzystajcie z tego szablonu, aby rozpocząć pracę z process mining i znaleźć sposoby na szybszą oraz dokładniejszą obsługę faktur. Usprawnijcie operacje już dziś.

Zacznij optymalizować obsługę faktur w ramach Purchase to Pay

Wykryj nieefektywności i skróć czas obsługi faktur o 30% lub więcej.

Rozpocznij okres próbny

Nie trzeba podawać danych karty płatniczej. Rozpoczęcie zajmuje kilka minut.