Szablon danych do analizy obsługi faktur w ramach Purchase to Pay
Szablon danych do analizy obsługi faktur w ramach Purchase to Pay
- 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
Atrybuty procesu obsługi faktur w ramach Purchase to Pay
| 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
|
|||
Działania w procesie obsługi faktur w ramach Purchase to Pay
| 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
|
|||
Instrukcje ekstrakcji danych
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.
Nie trzeba podawać danych karty płatniczej. Rozpoczęcie zajmuje kilka minut.