Szablon danych do procesu od zakupu do płatności: obsługa faktur
Szablon danych do procesu od zakupu do płatności: obsługa faktur
To ogólny szablon danych do process mining dla procesu Obsługa faktur w procesie od zakupu do płatności. Aby uzyskać dokładniejsze wskazówki, skorzystaj z szablonów dla konkretnych systemów.
Wybierz konkretny system- Zalecane pola danych do rzetelnej analizy
- Aktywności i etapy procesu do monitorowania
- Wskazówki dotyczące pobierania danych o procesie
Atrybuty procesu od zakupu do płatności: obsługa faktur
| Nazwa | Opis | ||
|---|---|---|---|
| Czas zdarzenia EventTime | Dokładny znacznik czasu wskazujący, kiedy wystąpiła dana czynność lub zdarzenie. | ||
| Opis Czas zdarzenia, nazywany też czasem rozpoczęcia, określa dokładną datę i godzinę wykonania czynności biznesowej. Każda czynność w procesie, od „Otrzymano fakturę” do „Zrealizowano płatność”, ma przypisany znacznik czasu. Te dane chronologiczne są niezbędne do ustalenia kolejności zdarzeń i obliczenia czasu ich trwania. Atrybut ten służy do chronologicznego sortowania zdarzeń i odtworzenia przebiegu każdego case. Stanowi podstawę wszystkich analiz czasu, w tym obliczania czasu między czynnościami, wykrywania wąskich gardeł powodujących straty czasu i monitorowania wyników względem uzgodnionych poziomów usług. Dokładne znaczniki czasu są niezbędne, aby wyniki analizy process mining były wiarygodne. Dlaczego to ważne Określa chronologiczną kolejność zdarzeń i stanowi podstawę obliczeń dotyczących wydajności oraz czasu trwania, takich jak czas cyklu. Skąd pobrać Informacja ta zwykle znajduje się w dziennikach zdarzeń lub w polu „Creation Date” albo „Entry Date” przypisanym do każdej transakcji lub zmiany statusu. Przykłady 2023-10-26T10:00:00Z2024-01-15T14:35:10Z2023-11-01T09:12:05Z | |||
| Nazwa czynności ActivityName | Nazwa konkretnego zdarzenia biznesowego lub zadania, które wystąpiło podczas obsługi faktury. | ||
| Opis Nazwa czynności opisuje pojedynczy krok lub etap obsługi faktury. Przykłady to „Otrzymano fakturę”, „Przekazano fakturę do akceptacji”, „Nałożono blokadę płatności” i „Zrealizowano płatność”. Ten atrybut pokazuje, co działo się z fakturą na kolejnych etapach. W process mining atrybut ten służy do tworzenia mapy procesu, która przedstawia przebieg workflow. Analiza kolejności, częstotliwości i ścieżek czynności pomaga wykryć typowe przebiegi procesu, odstępstwa, wąskie gardła i pętle poprawek. Odpowiednia jakość i szczegółowość nazw czynności są niezbędne do przeprowadzenia użytecznej analizy, na podstawie której można podjąć działania. Dlaczego to ważne Ten atrybut określa kroki procesu. Stanowi podstawę mapy procesu i umożliwia analizę jego przebiegu. Skąd pobrać Informacje te często pochodzą z dzienników zmian statusu, tabel zdarzeń lub kodów transakcji w systemie źródłowym. Przykłady Wprowadzono fakturęZaakceptowano fakturęNałożono blokadę płatnościZrealizowano płatność | |||
| Numer faktury InvoiceNumber | Unikalny identyfikator faktury dostawcy. Służy jako podstawowy klucz do śledzenia faktury przez cały cykl jej obsługi. | ||
| Opis Numer faktury to unikalny kod alfanumeryczny nadawany jej przez dostawcę. W process mining ten atrybut ma podstawowe znaczenie, ponieważ zazwyczaj pełni funkcję identyfikatora case, który pozwala śledzić drogę każdej faktury od otrzymania do płatności. Użycie numeru faktury jako identyfikatora case pozwala połączyć wszystkie powiązane czynności, takie jak „Otrzymano fakturę”, „Zaakceptowano fakturę” i „Zrealizowano płatność”, aby odtworzyć cały proces obsługi konkretnej faktury. Umożliwia to szczegółową analizę czasu trwania, przebiegu i odstępstw dla każdego case. Na tej podstawie można przeprowadzić analizę procesu. Dlaczego to ważne To podstawowy identyfikator case, który łączy powiązane zdarzenia i pozwala prześledzić cały cykl obsługi pojedynczej faktury. Skąd pobrać To podstawowe pole, które zwykle znajduje się w nagłówku tabeli transakcji faktur. Przykłady INV-2024-001239876543210US-5839A-24 | |||
| Ostatnia aktualizacja danych LastDataUpdate | Znacznik czasu wskazujący, kiedy dane dotyczące tego zdarzenia zostały ostatnio odświeżone z systemu źródłowego. | ||
| Opis Ten atrybut zapisuje datę i godzinę ostatniego pobrania lub odświeżenia danych. Jest to pole metadanych informujące o aktualności analizowanego zbioru danych. Informacja ta nie służy bezpośrednio do tworzenia mapy procesu, ale pozwala ocenić aktualność analizy. Ułatwia ustalenie, czy analizowane są dane bieżące, czy migawka z określonego momentu. Ma to znaczenie przy podejmowaniu decyzji operacyjnych. Atrybut pomaga też monitorować stan i częstotliwość działania potoku danych. Dlaczego to ważne Informuje o aktualności danych i pozwala ocenić, jak bieżąca jest analiza procesu. Skąd pobrać Ten znacznik czasu jest zwykle generowany i dodawany do zbioru danych podczas procesu pobierania, przekształcania i ładowania danych (ETL). Przykłady 2024-05-21T04:00:00Z2024-05-20T04:00:00Z2024-05-19T04:00:00Z | |||
| System źródłowy SourceSystem | System, z którego pobrano dane o zdarzeniu. | ||
| Opis Atrybut systemu źródłowego wskazuje aplikację lub platformę, w której zarejestrowano zdarzenie związane z obsługą faktury. W złożonym środowisku IT faktura może przechodzić przez kilka systemów, na przykład rozwiązanie do skanowania, narzędzie workflow i system ERP. Znajomość systemu źródłowego ułatwia interpretację danych i rozwiązywanie problemów z ich jakością. Pozwala też analizować procesy przebiegające w kilku systemach oraz wykrywać problemy z integracją i opóźnienia przy przekazywaniu pracy między aplikacjami. Jest to szczególnie przydatne podczas łączenia danych ze starszych i nowszych systemów. Dlaczego to ważne Informacja o pochodzeniu danych jest niezbędna do ich weryfikacji i analizy procesów obejmujących wiele systemów IT. Skąd pobrać Często jest to stała wartość dodawana podczas pobierania danych albo pole w dziennikach systemowych wskazujące nazwę lub identyfikator aplikacji. Przykłady SAP_ECC_PRODOracle_Fusion_FINCoupa_R34 | |||
| Czas zakończenia EndTime | Znacznik czasu wskazujący, kiedy zakończyła się czynność lub wystąpiło zdarzenie. W przypadku zdarzeń chwilowych jest często taki sam jak czas rozpoczęcia. | ||
| Opis Atrybut czasu zakończenia zapisuje dokładny moment zakończenia kroku procesu. Jest niezbędny do precyzyjnego obliczania czasu trwania czynności, co stanowi podstawowy pomiar w process mining. Porównanie czasu rozpoczęcia i zakończenia pozwala analitykom ustalić, ile trwa każdy krok, wykryć wąskie gardła i wskazać możliwości poprawy wydajności. W analizie czas zakończenia służy do obliczania czasu trwania poszczególnych czynności i całych etapów procesu. Na przykład czas akceptacji faktury można obliczyć, odejmując czas rozpoczęcia od czasu zakończenia czynności „Zaakceptowano fakturę”. Dane te pomagają tworzyć dashboardy wydajności, ustalać wartości odniesienia i monitorować wpływ zmian w procesie. Dlaczego to ważne Umożliwia precyzyjne obliczanie czasu trwania czynności, co jest niezbędne do wykrywania wąskich gardeł i pomiaru sprawności obsługi. Skąd pobrać Informacja ta znajduje się w dziennikach systemowych lub danych transakcyjnych, często w polu „Completion Date”, „Change Date” albo w osobnym polu znacznika czasu zakończenia czynności. Przykłady 2023-10-26T10:05:12Z2024-01-15T15:00:00Z2023-11-01T09:12:05Z | |||
| Kwota faktury InvoiceAmount | Łączna wartość faktury. | ||
| Opis Kwota faktury to łączna wartość faktury obejmująca wszystkie pozycje, podatki i opłaty. Ten podstawowy atrybut finansowy określa wartość każdej sprawy. Często analizuje się go razem z innymi atrybutami, aby sprawdzić jego wpływ na przebieg procesu. Atrybut ten ma znaczenie dla analiz finansowych i ustalania priorytetów. Filtrowanie faktur według kwoty pozwala sprawdzić, czy faktury o wysokiej wartości przechodzą inną, bardziej rygorystyczną ścieżkę zatwierdzania albo częściej się opóźniają. Kwota jest też potrzebna w dashboardach pokazujących łączną wartość obsłużonych faktur oraz w KPI dotyczących wykorzystania rabatów, ponieważ potencjalne oszczędności stanowią procent kwoty faktury. Dlaczego to ważne Umożliwia analizę wpływu finansowego i ustalanie priorytetów dla faktur o wysokiej wartości, a także pozwala sprawdzić, czy kwota faktury wpływa na czas lub przebieg jej obsługi. Skąd pobrać To standardowe pole w nagłówku tabeli transakcji faktur. Przykłady 5250.751200.0025000.0089.99 | |||
| Nazwa dostawcy VendorName | Nazwa dostawcy, który przesłał fakturę. | ||
| Opis Atrybut ten zawiera nazwę podmiotu zewnętrznego, który wystawił fakturę. Pozwala powiązać transakcję finansową z konkretnym dostawcą. Spójne i poprawne dane o dostawcach są niezbędne do rzetelnego raportowania i analizy. W process mining nazwa dostawcy jest ważnym wymiarem analizy. Analitycy mogą filtrować proces, aby sprawdzić obsługę faktur od dostawców o dużym wolumenie lub sprawiających problemy. Można w ten sposób wykryć dostawców, którzy często przesyłają błędne faktury, powodując opóźnienia i dodatkową pracę. Analiza wspiera też zarządzanie wynikami dostawców i wskazywanie możliwości rozwoju programów preferowanych dostawców. Dlaczego to ważne Pozwala analizować wyniki procesu według dostawcy, co ułatwia zarządzanie dostawcami i wykrywanie źródeł problematycznych faktur. Skąd pobrać Informacja ta znajduje się zwykle w nagłówku faktury i jest powiązana z tabelą danych podstawowych dostawców za pomocą identyfikatora dostawcy. Przykłady Globalne artykuły biuroweInnowacyjne rozwiązania techniczneCity Logistics Inc. | |||
| Przyczyna blokady lub odrzucenia BlockOrRejectionReason | Przyczyna zablokowania płatności za fakturę lub jej odrzucenia podczas zatwierdzania. | ||
| Opis Atrybut ten wskazuje konkretną przyczynę wstrzymania obsługi faktury: odrzucenie jej w workflow zatwierdzania albo zablokowanie płatności po zatwierdzeniu. Przyczyną może być między innymi nieprawidłowa ilość, niezgodność ceny, brak numeru PO lub zduplikowana faktura. To jeden z najważniejszych atrybutów w analizie przyczyn źródłowych. Analiza częstotliwości poszczególnych przyczyn pozwala wskazać najczęstsze źródła problemów i nieefektywności w procesie obsługi faktur. Na podstawie tych danych można zająć się przyczynami, na przykład usprawnić komunikację z dostawcami, poprawić zgodność z zasadami dotyczącymi PO lub lepiej przeszkolić pracowników. Dlaczego to ważne Jest niezbędny w analizie przyczyn źródłowych i pomaga wskazać najczęstsze powody opóźnień, ponownej pracy i nieefektywności. Skąd pobrać Informacja ta znajduje się w polach takich jak „Kod przyczyny” lub „Przyczyna wstrzymania” w danych transakcji faktury albo powiązanych dziennikach zatwierdzania. Przykłady Niezgodność cenyNieprawidłowa ilośćZduplikowana fakturaBrak potwierdzenia odbioru towaru | |||
| Termin płatności PaymentDueDate | Data, do której należy opłacić fakturę, aby uniknąć opóźnienia. | ||
| Opis Termin płatności to data wyliczana na podstawie daty faktury i uzgodnionych warunków płatności. Wyznacza ostateczny dzień zapłaty dostawcy, pozwalając uniknąć opóźnienia i związanych z nim kar. Atrybut ten jest podstawą monitorowania terminowości płatności. Służy do obliczania KPI, takich jak wskaźnik płatności dokonanych w terminie, oraz do wykrywania faktur zagrożonych opóźnieniem. Analiza czasu między zatwierdzeniem faktury a terminem płatności pomaga ocenić sprawność planowania i realizacji końcowych etapów płatności. Dlaczego to ważne Jest niezbędny do pomiaru terminowości płatności i analizy przyczyn opóźnień. Skąd pobrać Data ta znajduje się zwykle w szczegółach transakcji faktury. Może być wprowadzona bezpośrednio albo wyliczona na podstawie daty faktury i warunków płatności. Przykłady 2024-06-302024-07-152024-08-01 | |||
| Użytkownik User | Użytkownik, pracownik lub agent systemowy, który wykonał daną czynność. | ||
| Opis Atrybut „Użytkownik” wskazuje osobę lub system automatyczny odpowiedzialny za wykonanie danego kroku w workflow przetwarzania faktury. Może to być pracownik działu zobowiązań, który wprowadził fakturę, menedżer, który ją zatwierdził, albo bot, który dopasował dane. Analiza danych według użytkownika pomaga zrozumieć rozkład obciążenia pracą, wyniki poszczególnych osób i potrzeby szkoleniowe. Pozwala filtrować mapę procesu i sprawdzać, jak różne zespoły lub osoby obsługują faktury oraz czym różnią się ich workflow. Dzięki temu można wskazać osoby osiągające najlepsze wyniki, wykryć problemy z kierowaniem faktur lub ustalić, kto potrzebuje dodatkowego wsparcia albo szkolenia z procedur firmowych. Dlaczego to ważne Ułatwia analizę rozkładu obciążenia pracą, wyników użytkowników oraz różnic w przebiegu procesu między zespołami i poszczególnymi osobami. Skąd pobrać Informacje te są zwykle dostępne w szczegółach transakcji pod nazwami takimi jak „Nazwa użytkownika”, „Wprowadził”, „Zmienił” lub „Zatwierdzający”. Przykłady j.doeSYSTEM_RFCAlice.Smithapprover_pool_1 | |||
| Waluta faktury InvoiceCurrency | Kod waluty, w której podano kwotę faktury, na przykład USD lub EUR. | ||
| Opis Atrybut ten określa walutę, w której wyrażono kwotę faktury. Jest niezbędny w organizacjach działających na rynkach międzynarodowych i współpracujących z dostawcami z różnych krajów. Kod waluty, zwykle zgodny ze standardem ISO 4217, pozwala prawidłowo interpretować dane finansowe. W analizie waluta faktury służy do filtrowania danych według regionu lub kraju. Ma też znaczenie w raportowaniu finansowym, ponieważ kwoty trzeba prawidłowo sumować, często po przeliczeniu na wspólną walutę raportową. Analiza różnic w procesie według waluty może ujawnić złożoność związaną z płatnościami międzynarodowymi lub zarządzaniem ryzykiem walutowym. Dlaczego to ważne Daje niezbędny kontekst dla kwot faktur, umożliwiając rzetelną analizę finansową i segmentację danych w działalności międzynarodowej. Skąd pobrać To standardowe pole w nagłówku tabeli transakcji faktur. Przykłady USDEURGBPJPY | |||
| Data faktury InvoiceDate | Data wystawienia faktury przez dostawcę. | ||
| Opis Data faktury to data podana przez dostawcę na dokumencie. Z perspektywy dostawcy rozpoczyna ona oficjalny cykl płatności i często stanowi podstawę do wyliczenia terminu płatności zgodnie z uzgodnionymi warunkami. Analiza czasu między datą faktury a zdarzeniem „Otrzymano fakturę” lub „Wprowadzono fakturę” pomaga wykryć opóźnienia w przesyłaniu lub rejestrowaniu faktur. To opóźnienie może stanowić istotną, trudną do zauważenia część całkowitego czasu procesu. Skrócenie go może poprawić terminowość płatności i zwiększyć szanse na skorzystanie z rabatów za wcześniejszą zapłatę. Dlaczego to ważne Pozwala zmierzyć opóźnienie między wystawieniem faktury przez dostawcę a jej wprowadzeniem do systemu. Skąd pobrać To standardowe pole daty w danych nagłówka faktury, często opisane jako „Data dokumentu” lub „Data faktury”. Przykłady 2024-05-012024-04-152024-06-10 | |||
| Kod spółki CompanyCode | Identyfikator podmiotu prawnego lub spółki w organizacji, która obsługuje fakturę. | ||
| Opis Kod spółki oznacza konkretny podmiot prawny lub spółkę zależną w ramach większej organizacji. W wielu systemach finansowych transakcje są rozdzielane według kodu spółki na potrzeby księgowości i raportowania. Atrybut ten umożliwia porównywanie różnych jednostek biznesowych. Segmentując mapę procesu według kodu spółki, analitycy mogą porównywać wyniki, wskazywać dobre praktyki w jednej jednostce i wykrywać problemy systemowe w innej. Jest to podstawowy atrybut dla organizacji obejmujących więcej niż jeden podmiot prawny, które chcą zrozumieć różnice w przebiegu procesu i zapewnić zgodność w całej firmie. Dlaczego to ważne Umożliwia porównywanie i ocenę procesów w różnych podmiotach prawnych lub jednostkach biznesowych organizacji. Skąd pobrać To podstawowe pole organizacyjne, które znajduje się zwykle w nagłówku tabel transakcji finansowych. Przykłady 1000US01DE015100 | |||
| Numer zamówienia zakupu PurchaseOrderNumber | Identyfikator zamówienia zakupu (PO), którego dotyczy faktura. | ||
| Opis Numer zamówienia zakupu łączy fakturę z wcześniej zatwierdzonym dokumentem zakupu. To powiązanie ma zasadnicze znaczenie podczas dopasowywania danych. System sprawdza wtedy, czy szczegóły faktury, takie jak ilości i ceny, są zgodne z zamówieniem PO. Atrybut ten pomaga ocenić sprawność dopasowywania faktur do zamówień. Wysoki odsetek faktur powiązanych z PO, które są przetwarzane bez ręcznej interwencji, świadczy o sprawnym procesie zakupowym. Z kolei analiza faktur bez PO może ujawnić zakupy poza ustalonym procesem lub przypadki nieprzestrzegania zasad zakupowych. Obecność lub brak PO to częsty sposób segmentacji procesu i porównywania jego sprawności. Dlaczego to ważne Pozwala rozróżnić faktury powiązane z PO od faktur bez PO. Często są one obsługiwane w różny sposób i osiągają różny poziom sprawności. Skąd pobrać Identyfikator ten znajduje się zwykle w szczegółach pozycji lub nagłówka transakcji faktury i łączy ją z dokumentem zakupu. Przykłady 4500018921PO-2024-7837300000456 | |||
| Status faktury InvoiceStatus | Bieżący stan faktury w workflow jej obsługi. | ||
| Opis Status faktury pokazuje, na jakim etapie cyklu życia znajdowała się faktura w chwili pobrania danych. Typowe statusy to „W trakcie”, „Zatwierdzona”, „Opłacona”, „Odrzucona” lub „Zablokowana”. Atrybut ten przedstawia ogólny bieżący stan faktury. Process mining odtwarza pełny przebieg procesu, natomiast bieżący status przydaje się w dashboardach operacyjnych monitorujących aktualne obciążenie pracą. Ułatwia menedżerom sprawdzenie liczby faktur na poszczególnych etapach, na przykład oczekujących na zatwierdzenie lub zablokowanych. Dzięki temu można wcześniej reagować na sytuację w kolejce faktur i zapobiegać wąskim gardłom oraz opóźnieniom. Dlaczego to ważne Pokazuje bieżące obciążenie pracą i ułatwia monitorowanie liczby faktur na różnych etapach, na przykład oczekujących na zatwierdzenie lub zablokowanych. Skąd pobrać To zwykle pole statusu w tabeli nagłówka faktury, aktualizowane w miarę przechodzenia faktury przez kolejne etapy. Przykłady OpłaconaW trakcieOdrzuconaZatwierdzona do płatności | |||
| Warunki płatności PaymentTerms | Uzgodnione warunki płatności faktury, które określają termin płatności i ewentualne rabaty za wcześniejszą zapłatę. | ||
| Opis Warunki płatności określają zasady zapłaty za fakturę uzgodnione z dostawcą. Zwykle zapisuje się je w standardowym formacie, 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 pełna kwota jest płatna w ciągu 30 dni). Atrybut ten ma znaczenie dla strategii finansowej i analizy wyników. Stanowi podstawę do wyliczenia terminu płatności i wykrywania możliwości skorzystania z rabatu za wcześniejszą zapłatę. Analiza procesu według warunków płatności może pokazać, czy niektóre z nich wiążą się z opóźnieniami oraz czy organizacja skutecznie wykorzystuje dostępne rabaty. Dlaczego to ważne Ma znaczenie przy analizie terminowości płatności i wykrywaniu możliwości skorzystania z rabatów za wcześniejszą zapłatę. Skąd pobrać Informacje te pochodzą zwykle z danych podstawowych dostawcy i są podawane w nagłówku faktury. Przykłady Net 30Net 602% 10, Net 30Płatność przy odbiorze | |||
Proces od zakupu do płatności: obsługa faktur
| Działanie | Opis | ||
|---|---|---|---|
| Odrzucono fakturę | Zdarzenie występuje, gdy osoba akceptująca formalnie odrzuci fakturę, zatrzymując jej dalszy przebieg w workflow. Faktura jest zwykle odsyłana do poprawy lub anulowania, co rozpoczyna pętlę poprawek. | ||
| Dlaczego to ważne Analiza odrzuconych faktur pomaga wykryć przyczyny poprawek, takie jak błędne kodowanie, naruszenie zasad lub problemy z danymi na wcześniejszych etapach. Ograniczenie liczby odrzuceń zwiększa sprawność procesu. Skąd pobrać Jest to jawnie rejestrowana czynność w historii akceptacji faktury lub dzienniku workflow, często wraz z podanym powodem odrzucenia. Rejestrowanie Należy znaleźć zdarzenie zarejestrowane po wybraniu przez osobę akceptującą opcji „Reject” lub „Deny” w workflow. Typ zdarzenia explicit | |||
| Otrzymano fakturę | Oznacza otrzymanie faktury lub jej utworzenie w systemie. To zdarzenie rozpoczyna cykl obsługi faktury, niezależnie od sposobu jej wprowadzenia, na przykład ręcznie, przez portal dostawcy lub za pomocą OCR. | ||
| Dlaczego to ważne To zdarzenie jest niezbędne do pomiaru całkowitego czasu obsługi faktury od początku do końca. Stanowi punkt odniesienia przy ocenie obciążenia pracą i początkowych opóźnień. Skąd pobrać Zdarzenie jest zwykle rejestrowane na podstawie znacznika czasu utworzenia rekordu faktury lub pierwszego wpisu w dzienniku dokumentów. Rejestrowanie Należy użyć daty i godziny utworzenia głównego obiektu faktury lub rachunku dostawcy w systemie źródłowym. Typ zdarzenia explicit | |||
| Uzgodniono fakturę | Oznacza pomyślne uzgodnienie faktury z zamówieniem zakupu oraz, jeśli dotyczy, z potwierdzeniem odbioru towaru. Ten krok, wykonywany automatycznie lub ręcznie, potwierdza zgodność ilości i cen na fakturze z zamówionymi i otrzymanymi towarami. | ||
| Dlaczego to ważne To ważny etap przetwarzania bezpośredniego. Duży odsetek faktur uzgodnionych za pierwszym razem świadczy o sprawnym przebiegu wcześniejszych etapów zakupowych. Skąd pobrać Zdarzenie jest zwykle rejestrowane jako zmiana statusu lub osobny wpis w historii transakcji po pomyślnym zakończeniu weryfikacji uzgodnienia. Rejestrowanie Należy znaleźć zdarzenie lub zmianę statusu wskazującą, że uzgodnienie faktury zakończyło się statusem „Passed”, „Matched” lub „Reconciled”. Typ zdarzenia explicit | |||
| Wykryto rozbieżność przy uzgadnianiu | Zdarzenie występuje, gdy system lub użytkownik wykryje niezgodność między fakturą, zamówieniem zakupu lub potwierdzeniem odbioru towaru. Rozbieżności, na przykład różnice w cenie lub ilości, zwykle wstrzymują fakturę i wymagają ręcznej interwencji. | ||
| Dlaczego to ważne Śledzenie tych zdarzeń jest podstawą analizy przyczyn opóźnień i poprawek. Pomaga wykryć problemy z poprawnością faktur dostawców lub z wewnętrznym procesem zakupowym. Skąd pobrać Zdarzenie można wywnioskować ze zmiany statusu wskazującej niepowodzenie uzgodnienia lub z automatycznego nałożenia przez system blokady związanej z rozbieżnością. Rejestrowanie Należy zarejestrować znacznik czasu zmiany statusu uzgodnienia faktury na „Failed” lub „Discrepancy” albo nałożenia blokady z powodu rozbieżności. Typ zdarzenia inferred | |||
| Zaakceptowano fakturę | Oznacza, że wszystkie wymagane osoby zaakceptowały fakturę w workflow. Ten etap pozwala zaksięgować fakturę i przekazać ją do dalszej obsługi płatności. | ||
| Dlaczego to ważne To ważny etap kończący weryfikację i akceptację. Jest niezbędny do pomiaru czasu akceptacji i sprawdzenia zgodności z zasadami autoryzacji. Skąd pobrać Zdarzenie jest jawnie rejestrowane w historii akceptacji lub dzienniku workflow po uzyskaniu ostatecznej akceptacji. Rejestrowanie Należy użyć znacznika czasu ostatecznej akceptacji z historii akceptacji faktury lub workflow. Typ zdarzenia explicit | |||
| Zaksięgowano fakturę w księdze głównej | Oznacza formalne zdarzenie księgowe, w ramach którego zaakceptowana faktura zostaje ujęta w księdze głównej. Powstaje zobowiązanie finansowe, a faktura przechodzi ze statusu w trakcie obsługi do statusu gotowej do płatności. | ||
| Dlaczego to ważne To ważny etap finansowy, który potwierdza oficjalne ujęcie zobowiązania. Opóźnienia przed tym krokiem mogą wpłynąć na zamknięcie okresu finansowego i poprawność raportowania. Skąd pobrać Jest to jawne zdarzenie transakcyjne rejestrowane w modułach finansowych systemu. Rejestrowanie Należy użyć daty księgowania dokumentu finansowego utworzonego na podstawie faktury. Typ zdarzenia explicit | |||
| Zrealizowano płatność | Oznacza końcowy etap procesu, w którym płatność zostaje zrealizowana, a zobowiązanie z tytułu faktury rozliczone. Zdarzenie potwierdza przekazanie środków dostawcy. | ||
| Dlaczego to ważne To pomyślne zakończenie cyklu Purchase to Pay dla faktury. Jest to zdarzenie, na podstawie którego mierzy się terminowość płatności i całkowity czas procesu. Skąd pobrać Zdarzenie jest rejestrowane na podstawie daty księgowania dokumentu płatności, który rozlicza fakturę. Rejestrowanie Należy użyć daty rozliczenia lub daty płatności z dokumentu finansowego rozliczającego otwartą pozycję dostawcy. Typ zdarzenia explicit | |||
| Anulowano fakturę | Faktura została unieważniona, storniowana lub anulowana i nie będzie dalej obsługiwana ani opłacona. Jest to końcowy status błędnej lub zduplikowanej faktury. | ||
| Dlaczego to ważne Śledzenie anulowań pomaga wykryć problemy z jakością danych, duplikaty i inne błędy na wcześniejszych etapach. Wysoki odsetek anulowań może wskazywać na problemy z fakturami dostawców lub kontrolami wewnętrznymi. Skąd pobrać Jest to jawna zmiana statusu rekordu faktury lub utworzenie powiązanego dokumentu storna. Rejestrowanie Należy znaleźć znacznik czasu zmiany statusu faktury na „Canceled” lub „Voided” albo zaksięgowania dokumentu storna. Typ zdarzenia explicit | |||
| Faktura stała się przeterminowana | Zdarzenie obliczane, które występuje, gdy bieżąca data przekracza termin płatności netto faktury, a faktura pozostaje nieopłacona. Termin płatności wynika z daty faktury i warunków płatności dostawcy. | ||
| Dlaczego to ważne To zdarzenie bezpośrednio wskazuje opóźnione płatności, które mogą pogorszyć relacje z dostawcami i wiązać się z karami. Jest niezbędne do monitorowania i poprawy terminowości płatności. Skąd pobrać Nie jest to jawne zdarzenie systemowe. Należy je obliczyć, porównując datę płatności, a w przypadku nieopłaconej faktury bieżącą datę, z terminem płatności faktury. Rejestrowanie Zdarzenie należy obliczyć za pomocą wyrażenia Typ zdarzenia calculated | |||
| Nałożono blokadę płatności | Na fakturę nałożono blokadę, która uniemożliwia jej opłacenie nawet po akceptacji. Blokada może być nakładana automatycznie na podstawie reguł systemowych lub ręcznie, na przykład z powodu sporu z dostawcą. | ||
| Dlaczego to ważne Blokady płatności często powodują opóźnienia i utratę rabatów. Ustalenie, kiedy i dlaczego są nakładane, pomaga zwiększyć odsetek płatności realizowanych w terminie. Skąd pobrać Zdarzenie jest zwykle rejestrowane jako osobny status lub flaga w rekordzie faktury albo wierszach faktury. Rejestrowanie Należy zarejestrować zdarzenie nałożenia kodu blokady płatności lub statusu wstrzymania na fakturę albo jej wiersze. Typ zdarzenia explicit | |||
| Poprawiono fakturę | Oznacza ręczną zmianę lub poprawkę faktury, często po jej odrzuceniu albo w celu usunięcia wykrytego błędu. To odstępstwo od standardowego procesu bez ręcznej obsługi. | ||
| Dlaczego to ważne Śledzenie poprawek ujawnia nieefektywne działania i ukryte koszty. Wiedza o tym, dlaczego faktury są zmieniane, pomaga zaplanować konkretne usprawnienia procesu i szkolenia. Skąd pobrać Zdarzenie zwykle można wywnioskować z dzienników zmian lub ścieżek audytu, które rejestrują modyfikacje ważnych pól faktury po jej wstępnym wprowadzeniu. Rejestrowanie Należy pobrać znaczniki czasu z dzienników audytu wskazujące zmianę danych faktury, zwłaszcza po jej odrzuceniu lub wstrzymaniu. Typ zdarzenia inferred | |||
| Przekazano fakturę do akceptacji | Oznacza formalne przekazanie faktury do workflow akceptacji po zakończeniu wstępnej weryfikacji i uzgadniania. Zgodnie z ustawionymi regułami biznesowymi faktura trafia do wyznaczonych osób akceptujących. | ||
| Dlaczego to ważne Ten etap rozpoczyna podproces akceptacji. Pomiar czasu od tego zdarzenia do ostatecznej akceptacji pozwala ocenić sprawność workflow i wykryć wąskie gardła. Skąd pobrać W systemach z silnikiem workflow jest to jawnie rejestrowane zdarzenie. Można je też wywnioskować ze zmiany statusu na „Pending Approval”. Rejestrowanie Należy zarejestrować znacznik czasu rozpoczęcia workflow lub zmiany statusu faktury wskazującej, że oczekuje na akceptację. Typ zdarzenia explicit | |||
| Rozwiązano rozbieżność | Oznacza moment, w którym wcześniej wykryta rozbieżność przy uzgadnianiu została ręcznie zbadana i rozwiązana. Faktura może wtedy przejść do kolejnego kroku, na przykład akceptacji lub ponownego uzgodnienia. | ||
| Dlaczego to ważne Czas rozwiązywania rozbieżności ma duży wpływ na całkowity czas obsługi faktury. Analiza tego etapu pomaga ocenić nakład pracy i czas potrzebny na obsługę wyjątków. Skąd pobrać Zdarzenie często można wywnioskować z pierwszej czynności użytkownika, która usuwa blokadę uzgodnienia lub umożliwia ponowne przetworzenie faktury po nieudanym uzgodnieniu. Rejestrowanie Należy znaleźć zdarzenie, w którym zwolniono blokadę związaną z uzgadnianiem lub pomyślnie uzgodniono fakturę po wcześniejszym niepowodzeniu. Typ zdarzenia inferred | |||
| Wprowadzono fakturę | Oznacza zakończenie wstępnego wprowadzania danych. Szczegóły faktury zostały wpisane lub zeskanowane, ale dokument nie został jeszcze zaksięgowany ani przekazany do formalnej akceptacji. Faktura często ma tymczasowy status „wstrzymana” lub „robocza”. | ||
| Dlaczego to ważne Analiza czasu między otrzymaniem a wprowadzeniem faktury pomaga wykryć zaległości na etapie wprowadzania danych. Może też pokazać skuteczność automatycznego odczytu danych. Skąd pobrać Zdarzenie często można wywnioskować z zapisania faktury ze statusem roboczym lub wstrzymanym, zanim zostanie przekazana do workflow. Rejestrowanie Należy zarejestrować znacznik czasu zmiany statusu faktury z nowego na zapisany, wstrzymany lub roboczy. Typ zdarzenia inferred | |||
| Zaplanowano płatność | Zaksięgowana faktura zostaje wybrana i dodana do propozycji płatności lub paczki płatności. Ten krok umieszcza fakturę w kolejce do realizacji płatności w określonym dniu, ale nie oznacza jeszcze faktycznego przekazania środków. | ||
| Dlaczego to ważne To zdarzenie pokazuje końcowy etap procesu. Opóźnienia między zaksięgowaniem a zaplanowaniem płatności mogą prowadzić do utraty rabatów i opóźnionych płatności. Skąd pobrać Zdarzenie jest zwykle rejestrowane po dodaniu faktury do przebiegu płatności, propozycji płatności lub dziennika płatności. Rejestrowanie Należy znaleźć datę utworzenia propozycji płatności lub rekordu paczki płatności zawierającej fakturę. Typ zdarzenia explicit | |||
| Zwolniono blokadę płatności | Oznacza usunięcie wcześniej nałożonej blokady płatności, dzięki czemu faktura ponownie kwalifikuje się do zapłaty. Wskazuje, że rozwiązano problem, który spowodował blokadę. | ||
| Dlaczego to ważne Czas od nałożenia do zwolnienia blokady oznacza opóźnienie w procesie. Analiza tego okresu pomaga wykryć wąskie gardła w rozwiązywaniu problemów. Skąd pobrać Zdarzenie jest rejestrowane po usunięciu statusu lub flagi blokady płatności z rekordu faktury. Rejestrowanie Należy zarejestrować zdarzenie usunięcia kodu blokady płatności lub statusu wstrzymania albo zmiany statusu na odblokowany. Typ zdarzenia explicit | |||
Instrukcje ekstrakcji danych
Metody ekstrakcji zależą od systemu. Szczegółowe instrukcje znajdą Państwo w
naszym przewodniku ETL lub wybierz konkretny proces i system.
Jak zacząć?
Aby rozpocząć ekstrakcję danych, wybierz instrukcję dla używanego systemu. Można też skorzystać z tego ogólnego szablonu jako punktu odniesienia dla dowolnego źródła danych.
Usprawnij obsługę faktur i zwiększ efektywność procesu P2P
Odkryj problemy w procesie, ogranicz koszty i przyspiesz obsługę faktur.
Karta kredytowa nie jest wymagana. Konfiguracja zajmuje tylko 5 minut.