Szablon danych do procesu Purchase to Pay: przetwarzanie faktur
Szablon danych do procesu Purchase to Pay: przetwarzanie faktur
- Zalecane atrybuty do zebrania
- Najważniejsze czynności do śledzenia
- Wskazówki dotyczące pobierania danych z Coupa
Atrybuty procesu Purchase to Pay: przetwarzanie faktur
| 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, określa dokładną datę i godzinę wykonania czynności. Stanowi podstawę chronologicznego uporządkowania wszystkich zdarzeń w dzienniku procesu dla każdego case. Ten atrybut jest niezbędny do analiz czasowych w process mining. Służy do obliczania czasu między czynnościami, określania czasu trwania wąskich gardeł, mierzenia czasu oczekiwania i analizy wyników procesu w różnych okresach. Dokładne znaczniki czasu są konieczne do tworzenia realistycznych modeli procesów i wyliczania miarodajnych KPI.
Dlaczego to ważne
Dostarcza danych chronologicznych potrzebnych do obliczania czasu trwania, czasu realizacji i czasu oczekiwania, które są podstawą analizy efektywności.
Skąd pobrać
Dane te są zapisywane w ścieżce audytu lub dziennikach historii obiektów faktur w Coupa. Każde zarejestrowane działanie lub zmiana statusu ma przypisany znacznik czasu.
Przykłady
2023-10-26T10:00:00Z2023-11-05T14:32:15Z2023-11-15T09:01:45Z
|
|||
|
Numer faktury
InvoiceNumber
|
Unikalny identyfikator faktury dostawcy. Służy jako główny klucz do śledzenia faktury przez cały cykl jej obsługi. | ||
|
Opis
Numer faktury to unikalny identyfikator nadany dokumentowi przez dostawcę. W process mining pełni funkcję identyfikatora case, który łączy wszystkie powiązane działania, od otrzymania i weryfikacji faktury po jej akceptację i płatność. Analiza procesu według numeru faktury pozwala prześledzić obsługę każdego dokumentu od początku do końca. Ułatwia wykrywanie różnic w przebiegu procesu, dokładny pomiar czasu realizacji oraz wskazanie faktur, których obsługa napotkała opóźnienia, blokady lub wyjątki. To podstawowy atrybut szczegółowej analizy efektywności obsługi faktur.
Dlaczego to ważne
To niezbędny identyfikator case, który łączy wszystkie zdarzenia dotyczące jednej faktury i umożliwia spójną analizę procesu od początku do końca.
Skąd pobrać
To podstawowe pole obiektu faktury w Coupa. Można je znaleźć w szczegółach nagłówka faktury w interfejsie użytkownika lub pobrać za pomocą Invoices API.
Przykłady
INV-2023-00123785549-APO45001-INV
|
|||
|
Czynność
ActivityName
|
Nazwa konkretnego zdarzenia biznesowego lub zadania, które wystąpiło podczas obsługi faktury. | ||
|
Opis
Nazwa czynności opisuje etap workflow obsługi faktury, na przykład „Utworzenie faktury”, „Przekazanie faktury do akceptacji” lub „Realizacja płatności”. Każda czynność oznacza konkretny moment, w którym zmienił się status faktury lub osoba za nią odpowiedzialna. W process mining sekwencja czynności tworzy mapę przebiegu procesu. Analiza pozwala zobaczyć rzeczywisty przebieg, wykryć częste i rzadkie ścieżki, wskazać wąskie gardła, w których czynności trwają zbyt długo, oraz znaleźć niezgodne z zasadami lub nieefektywne etapy, takie jak pętle poprawek.
Dlaczego to ważne
Ten atrybut jest niezbędny do utworzenia mapy procesu oraz wizualizacji i analizy rzeczywistego workflow obsługi faktur.
Skąd pobrać
Atrybut ten zwykle pochodzi z dzienników zdarzeń, ścieżek audytu lub zmian statusu w module faktur Coupa. Często wymaga przypisania zmian statusu lub konkretnych działań użytkownika do zdefiniowanych nazw czynności.
Przykłady
Przekazanie faktury do obsługiAkceptacja fakturyZablokowanie fakturyRealizacja płatności
|
|||
|
Łączna kwota faktury
InvoiceTotalAmount
|
Całkowita wartość faktury, obejmująca podatki i inne opłaty. | ||
|
Opis
Atrybut ten określa łączną kwotę do zapłaty z faktury. To podstawowa dana finansowa wykorzystywana w wielu analizach. Analiza procesu według kwoty faktury może ujawnić istotne zależności. Na przykład faktury o wysokiej wartości mogą wymagać bardziej szczegółowej akceptacji, co może wydłużyć czas realizacji. Kwota pozwala też ocenić finansowy wpływ nieefektywności procesu, na przykład wartość faktur obecnie zablokowanych lub opóźnionych.
Dlaczego to ważne
Zapewnia kontekst finansowy potrzebny do analizy zmian w przebiegu procesu zależnie od wartości faktury oraz oceny finansowych skutków opóźnień.
Skąd pobrać
To standardowe pole obiektu faktury w Coupa, zwykle nazwane „Total” lub „Total Amount”.
Przykłady
1500.75250.0012345.50
|
|||
|
Nazwa dostawcy
VendorName
|
Nazwa dostawcy, który przesłał fakturę. | ||
|
Opis
Nazwa dostawcy wskazuje partnera biznesowego, od którego zakupiono towary lub usługi. To ważny kontekst przy analizie terminowości płatności i relacji z dostawcami. Atrybut ten pozwala analizować proces obsługi faktur według dostawcy. Pomaga odpowiedzieć na pytania: „U których dostawców obsługa faktur trwa najdłużej?” i „Czy płatności na rzecz wybranych dostawców strategicznych są regularnie realizowane w terminie?”. Analiza według dostawcy jest niezbędna dla dashboardu „Terminowość płatności dla dostawców” i skutecznego zarządzania relacjami z dostawcami.
Dlaczego to ważne
Pozwala analizować proces według dostawcy, co pomaga zarządzać relacjami z dostawcami i wykrywać problemy dotyczące konkretnych partnerów.
Skąd pobrać
Informacja ta należy do podstawowych danych faktury w Coupa i jest pobierana z obiektu dostawcy.
Przykłady
Global Office SuppliesTech Solutions Inc.Creative Marketing Agency
|
|||
|
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. To powiązanie jest podstawą dopasowania faktury do PO, które w wielu organizacjach stanowi ważny etap jej weryfikacji. W process mining atrybut ten jest niezbędny do analizy dopasowania faktur do PO i usuwania rozbieżności. Pozwala filtrować faktury powiązane z konkretnymi zamówieniami i jest potrzebny do dashboardu „Przegląd rozbieżności przy dopasowaniu do PO”. Duży odsetek faktur bez numeru PO może wskazywać na zakupy poza ustalonym procesem lub niezgodność z zasadami zakupowymi.
Dlaczego to ważne
Łączy fakturę z procesem zakupowym, umożliwiając analizę skuteczności dopasowania do PO i obsługi rozbieżności.
Skąd pobrać
To standardowe pole obiektu pozycji faktury w Coupa, służące do powiązania pozycji faktury z pozycjami PO.
Przykłady
PO4500123PO4500456PO4500789
|
|||
|
Status faktury
InvoiceStatus
|
Bieżący stan faktury w workflow obsługi. | ||
|
Opis
Status faktury pokazuje jej bieżący etap, na przykład „pending approval”, „approved”, „on hold” lub „paid”. Jest to atrybut dynamiczny, który zmienia się w miarę przechodzenia faktury przez proces. Atrybut ten jest ważny dla dashboardów monitorowania operacyjnego, takich jak „Przepustowość i status obsługi faktur”. Pozwala śledzić liczbę otwartych faktur i ich rozkład na poszczególnych etapach. Analiza zmian statusu w czasie jest również jednym z głównych źródeł atrybutu „ActivityName”.
Dlaczego to ważne
Pokazuje bieżące położenie faktury w workflow, co ma znaczenie dla dashboardów operacyjnych i śledzenia statusu.
Skąd pobrać
To podstawowe pole statusu obiektu faktury w Coupa.
Przykłady
Oczekuje na akceptacjęZatwierdzenieUnieważnienieOpłacenie
|
|||
|
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 termin zapłaty dostawcy. Atrybut ten stanowi punkt odniesienia przy pomiarze terminowości płatności. Służy bezpośrednio do obliczania KPI „Odsetek płatności zrealizowanych w terminie” przez porównanie terminu z faktyczną datą realizacji płatności. Analiza odchyleń pomaga wykryć systemowe przyczyny opóźnień oraz ocenić ich wpływ na relacje z dostawcami i ewentualne odsetki za zwłokę.
Dlaczego to ważne
To podstawowy punkt odniesienia przy pomiarze terminowości płatności. Pomaga zarządzać relacjami z dostawcami i unikać kar.
Skąd pobrać
Coupa zwykle wylicza tę datę na podstawie pól „Invoice Date” i „Payment Terms”. Powinna być dostępna w rekordzie faktury.
Przykłady
2023-11-302023-12-152024-01-10
|
|||
|
Użytkownik
User
|
Użytkownik lub agent systemowy, który wykonał daną czynność. | ||
|
Opis
Atrybut ten wskazuje osobę lub system automatyczny odpowiedzialny za wykonanie konkretnego etapu procesu, na przykład akceptację faktury lub usunięcie blokady. Zwykle jest reprezentowany przez identyfikator użytkownika, nazwę lub adres e-mail. Analiza procesu według użytkownika pomaga ocenić pracę zespołu i rozkład obciążenia oraz wskazać potrzeby szkoleniowe. Jest niezbędna do analizy wąskich gardeł, ponieważ może ujawnić, że opóźnienia dotyczą konkretnych osób akceptujących lub zespołów. Pozwala też odróżnić czynności ręczne od automatycznych.
Dlaczego to ważne
Umożliwia analizę obciążenia, wskazuje wąskie gardła związane z konkretnymi użytkownikami lub zespołami oraz pomaga ocenić efektywność pracy i zgodność z zasadami.
Skąd pobrać
Informacje o użytkowniku są zwykle zapisywane przy każdej czynności w ścieżce audytu lub historii faktury w Coupa.
Przykłady
john.doe@company.comjane.smithSystem.Automation
|
|||
|
Czy płatność terminowa
IsOnTimePayment
|
Informacja logiczna, czy fakturę opłacono w terminie lub przed terminem płatności. | ||
|
Opis
Ten obliczany atrybut wskazuje dla każdej faktury, czy płatność była terminowa. Jego wartość ustala się przez porównanie znacznika czasu czynności „Wykonano płatność” z terminem płatności. Jeśli płatność nastąpiła w terminie lub wcześniej, wartość wynosi „prawda”. Wskaźnik ten upraszcza obliczanie KPI „Odsetek płatności terminowych”. Ułatwia filtrowanie i analizę cech opóźnionych płatności, takich jak dostawcy, działy lub kwoty faktur, które najczęściej wiążą się z opóźnieniami.
Dlaczego to ważne
Ułatwia analizę terminowości płatności i stanowi podstawę do obliczania KPI „Odsetek płatności terminowych”.
Skąd pobrać
To obliczany atrybut. Logika: „Data wykonania płatności” <= „Termin płatności”. Obliczenie wykonuje się w narzędziu process mining.
Przykłady
truefalse
|
|||
|
Czy zautomatyzowano
IsAutomated
|
Informacja, czy czynność wykonał system automatyczny, czy użytkownik. | ||
|
Opis
Ten atrybut logiczny rozróżnia zadania wykonywane automatycznie przez system, takie jak automatyczne dopasowanie do zamówienia zakupu (PO) lub księgowanie generowane przez system, od zadań wykonywanych ręcznie przez użytkownika. Analiza tego atrybutu pozwala zmierzyć poziom automatyzacji workflow przetwarzania faktur. Można ocenić efekty wdrożonych rozwiązań, wskazać czynności nadal wykonywane ręcznie, które można zautomatyzować, oraz porównać wydajność i liczbę błędów w czynnościach automatycznych i ręcznych. Pomaga to ustalić rzeczywiste koszty i efektywność procesu.
Dlaczego to ważne
Pomaga mierzyć poziom automatyzacji procesu, wskazywać możliwości dalszej automatyzacji i oceniać wpływ działających botów.
Skąd pobrać
Zazwyczaj ustala się to, sprawdzając, czy pole „User” powiązane z czynnością wskazuje konto systemowe lub usługowe, czy konto użytkownika.
Przykłady
truefalse
|
|||
|
Data faktury
InvoiceDate
|
Data widniejąca na fakturze dostawcy. | ||
|
Opis
Data faktury to data nadana jej przez dostawcę. Zazwyczaj wyznacza początek cyklu płatności i służy do obliczenia terminu płatności zgodnie z warunkami płatności. Atrybut ten jest punktem wyjścia dla wielu obliczeń czasu trwania procesu. Jest niezbędny do ustalenia terminu płatności i sprawdzenia, czy faktura kwalifikuje się do rabatu za wcześniejszą płatność. Różnica między datą faktury a datą jej wprowadzenia do systemu może ujawnić opóźnienia w wystawianiu lub odbiorze faktur.
Dlaczego to ważne
To podstawowa data używana do obliczania terminów płatności. Jest też punktem odniesienia przy ocenie terminowości płatności i wykorzystania rabatów.
Skąd pobrać
To standardowe, wymagane pole obiektu Invoice w Coupa.
Przykłady
2023-10-152023-11-012023-12-20
|
|||
|
Kod spółki
CompanyCode
|
Identyfikator jednostki prawnej lub spółki odpowiedzialnej za fakturę. | ||
|
Opis
Kod spółki oznacza konkretną jednostkę prawną w ramach większej organizacji. Faktury są księgowane na kod spółki na potrzeby rachunkowości finansowej i sprawozdawczości. Atrybut ten pozwala filtrować i analizować procesy według jednostki prawnej. Umożliwia porównanie wyników procesu w różnych częściach firmy i odpowiedź na pytania, takie jak: „Czy proces akceptacji faktur w spółce amerykańskiej różni się od procesu w spółce niemieckiej?”. Ma to szczególne znaczenie w dużych, międzynarodowych organizacjach.
Dlaczego to ważne
Umożliwia porównywanie procesów i wyników między jednostkami prawnymi lub jednostkami biznesowymi w organizacji.
Skąd pobrać
To podstawowe pole księgowe obiektu Invoice w Coupa, często wymagane do zaksięgowania dokumentu.
Przykłady
1000US01DE01
|
|||
|
Ostatnia aktualizacja danych
LastDataUpdate
|
Znacznik czasu wskazujący, kiedy ostatnio odświeżono dane o tym zdarzeniu z systemu źródłowego. | ||
|
Opis
Atrybut ten zapisuje, kiedy dane zostały ostatnio pobrane i wczytane do narzędzia process mining. Informuje o aktualności analizy i pomaga ocenić, na ile aktualne są dane prezentowane na dashboardach. Informacja o czasie ostatniej aktualizacji jest ważna przy monitorowaniu operacyjnym. Pozwala ocenić aktualność danych i uniknąć podejmowania decyzji na podstawie nieaktualnego obrazu procesu.
Dlaczego to ważne
Informuje o aktualności i przydatności danych procesowych, dzięki czemu można ocenić, jak aktualna jest analiza.
Skąd pobrać
Ten znacznik czasu jest generowany i dodawany do zbioru danych podczas procesu pobierania i przekształcania danych (ETL).
Przykłady
2024-05-20T04:00:00Z2024-05-19T04:00:00Z
|
|||
|
Powód odrzucenia
RejectionReason
|
Powód podany przy odrzuceniu faktury na etapie akceptacji. | ||
|
Opis
Osoba akceptująca, która odrzuca fakturę, zazwyczaj podaje przyczynę, na przykład „Nieprawidłowa kwota” lub „Zduplikowana faktura”. Atrybut ten przechowuje przyczynę w formie tekstu lub kodu. Te dane są bardzo przydatne przy analizie źródeł opóźnień i ponownej pracy na etapie akceptacji. Analiza częstotliwości poszczególnych powodów odrzucenia pozwala wykryć problemy systemowe na wcześniejszych etapach procesu, takie jak błędne dane zamówienia zakupu (PO) lub nieprawidłowości w fakturach dostawców. Informacje te wspierają analizę w dashboardzie „Analiza wąskich gardeł w akceptacji faktur”.
Dlaczego to ważne
Pozwala bezpośrednio ustalić przyczyny odrzucania faktur, wskazać obszary wymagające usprawnienia i ograniczyć ponowną pracę.
Skąd pobrać
Dane są zapisywane, gdy użytkownik wybiera w workflow akceptacji opcję „Odrzuć”. Często trafiają do komentarzy lub ścieżki audytu.
Przykłady
Nieprawidłowa ilośćCena niezgodna z zamówieniem zakupu (PO)Ponowne przesłanie tej samej faktury
|
|||
|
Powód wstrzymania
HoldReason
|
Przyczyna wstrzymania faktury lub zablokowania płatności. | ||
|
Opis
Powód wstrzymania wyjaśnia, dlaczego faktura nie może przejść do płatności. Przykłady to „Niezgodna ilość” lub „Oczekiwanie na potwierdzenie odbioru towarów”. Informacja ta pomaga ustalić przyczyny opóźnień w płatnościach. Atrybut ten stanowi podstawę dashboardu „Analiza przyczyn blokad płatności”. Grupując i zliczając poszczególne powody wstrzymania, można wskazać najczęstsze problemy zakłócające proces płatności. Dzięki temu można wprowadzić ukierunkowane usprawnienia, zapobiegać kolejnym blokadom i przyspieszyć płatności.
Dlaczego to ważne
Wyjaśnia przyczyny opóźnień płatności i umożliwia analizę ich źródeł, aby ograniczyć liczbę blokad oraz skrócić czas ich trwania.
Skąd pobrać
Gdy faktura zostaje wstrzymana w Coupa, zazwyczaj wybiera się lub wpisuje powód. Dane te są powiązane ze statusem wstrzymania faktury.
Przykłady
Niezgodność ceny z zamówieniem zakupu (PO)Oczekiwanie na potwierdzenie odbioru towarówZduplikowana faktura
|
|||
|
System źródłowy
SourceSystem
|
System, z którego pobrano dane o zdarzeniu. | ||
|
Opis
Atrybut „System źródłowy” wskazuje aplikację lub platformę, w której zarejestrowano czynność związaną z obsługą faktury. Głównym systemem jest Coupa, ale faktury lub powiązane dane mogą pochodzić również z innych zintegrowanych systemów, takich jak ERP lub portal dostawcy. Informacja ta pomaga analizować złożone środowiska IT i ustalić, jak poszczególne systemy wpływają na cały proces. Ułatwia diagnozowanie problemów z jakością danych, analizę przekazywania spraw między systemami oraz badanie procesów obejmujących wiele aplikacji.
Dlaczego to ważne
Wyjaśnia pochodzenie danych, co jest niezbędne do rozwiązywania problemów i analizy procesów obejmujących wiele zintegrowanych systemów.
Skąd pobrać
Zwykle jest to stała wartość dodawana podczas pobierania danych, która wskazuje ich źródło. W przypadku Coupa należy ustawić wartość „Coupa”.
Przykłady
CoupaSAP S/4HANAOracle Fusion
|
|||
|
Waluta
CurrencyCode
|
Kod waluty ISO określający walutę kwoty faktury. | ||
|
Opis
Kod waluty określa jednostkę pieniężną, w której podano wartości na fakturze, na przykład USD, EUR lub GBP. Jest niezbędny dla organizacji działających na wielu rynkach i obsługujących faktury w różnych walutach. W analizie atrybut ten pozwala prawidłowo interpretować i agregować dane finansowe. Dashboardy i KPI muszą filtrować kwoty według waluty lub przeliczać je na wspólną walutę, aby prezentować miarodajne podsumowania. Zapobiega to błędnemu sumowaniu kwot w różnych walutach i umożliwia analizę procesu dla każdej waluty osobno.
Dlaczego to ważne
Zapewnia kontekst niezbędny do prawidłowej analizy i raportowania danych finansowych w środowisku wielowalutowym.
Skąd pobrać
To standardowe pole obiektu faktury w Coupa, zwykle powiązane z dostawcą lub wskazane bezpośrednio na fakturze.
Przykłady
USDEURGBP
|
|||
|
Warunki płatności
PaymentTerms
|
Uzgodnione warunki płatności za fakturę, na przykład „Net 30” lub „2% 10, Net 30”. | ||
|
Opis
Warunki płatności określają zasady rozliczeń z dostawcą, w tym termin płatności i dostępne rabaty za wcześniejszą zapłatę. Zwykle są ustalane w danych podstawowych dostawcy i przypisywane do faktur. Atrybut ten jest niezbędny do obliczania terminu płatności i wykrywania możliwości uzyskania rabatu za wcześniejszą zapłatę. Jest bezpośrednim źródłem danych dla dashboardu „Monitorowanie rabatów za wcześniejszą płatność” i powiązanego KPI. Analiza według warunków płatności może ujawnić, czy niektóre z nich wiążą się z opóźnieniami.
Dlaczego to ważne
Stanowi podstawę do obliczania terminów płatności i wykrywania możliwości uzyskania rabatu za wcześniejszą zapłatę, co bezpośrednio wpływa na kapitał obrotowy.
Skąd pobrać
To standardowe pole w Coupa, zwykle pobierane z rekordu dostawcy i przypisywane do faktury.
Przykłady
Net 3060 dni netto2% w ciągu 10 dni, 30 dni netto
|
|||
|
Wykorzystano rabat
EarlyPaymentDiscountCaptured
|
Informacja, czy skorzystano z dostępnego rabatu za wcześniejszą płatność. | ||
|
Opis
Ten atrybut logiczny wskazuje, czy organizacja opłaciła fakturę w terminie uprawniającym do rabatu określonym w warunkach płatności, na przykład w ciągu 10 dni przy warunkach „2% w ciągu 10 dni, 30 dni netto”. To podstawowy miernik dashboardu „Monitorowanie rabatów za wcześniejszą płatność” i powiązanego z nim KPI. Analiza przypadków, w których wartość wynosi „fałsz”, pozwala wykryć utracone oszczędności. Można sprawdzić, dlaczego faktury uprawniające do rabatu nie są przetwarzane wystarczająco szybko, i wprowadzić zmiany, które pomogą częściej korzystać z rabatów oraz lepiej zarządzać kapitałem obrotowym.
Dlaczego to ważne
Bezpośrednio mierzy korzyści finansowe wynikające ze sprawnego przetwarzania faktur i pomaga wykrywać utracone oszczędności.
Skąd pobrać
To obliczany atrybut. Sprawdza, czy data płatności mieści się w okresie rabatowym określonym w polu „Warunki płatności” oraz czy rabat został faktycznie naliczony.
Przykłady
truefalse
|
|||
Czynności w procesie Purchase to Pay: przetwarzanie faktur
| Działanie | Opis | ||
|---|---|---|---|
|
Akceptacja faktury
|
To zdarzenie oznacza pomyślne przejście przez fakturę wszystkich wymaganych etapów workflow akceptacji. Jest rejestrowane w historii akceptacji, gdy ostatnia wymagana osoba akceptująca podejmie pozytywną decyzję. | ||
|
Dlaczego to ważne
Ten etap kończy cykl akceptacji i umożliwia przekazanie faktury do obsługi płatności. Jest niezbędny do pomiaru czasu akceptacji i ogólnej efektywności procesu.
Skąd pobrać
To jawne zdarzenie odczytywane z dziennika historii akceptacji lub ze zmiany statusu nagłówka faktury na „approved”. Dokładny znacznik czasu wskazuje ostatnia decyzja akceptacyjna w dzienniku.
Rejestrowanie
Należy zapisać znacznik czasu ostatniej decyzji akceptacyjnej w historii akceptacji.
Typ zdarzenia
explicit
|
|||
|
Przekazanie faktury do akceptacji
|
Oznacza moment, w którym faktura po wstępnej weryfikacji trafia do formalnego workflow akceptacji. Zwykle można to wywnioskować ze zmiany statusu wskazującej, że faktura oczekuje na działanie jednego lub kilku akceptujących. | ||
|
Dlaczego to ważne
To zdarzenie rozpoczyna pomiar czasu akceptacji. Jest niezbędne do analizy wąskich gardeł w hierarchii akceptacji i stanowi podstawę dashboardu „Analiza wąskich gardeł w akceptacji faktur”.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany statusu faktury na „pending approval” lub podobny. Oznacza je również utworzenie pierwszego wpisu w historii akceptacji faktury.
Rejestrowanie
Należy zapisać znacznik czasu zmiany statusu faktury na „Pending Approval” lub utworzenia pierwszego wpisu akceptacji.
Typ zdarzenia
inferred
|
|||
|
Przekazanie faktury do płatności
|
Zatwierdzona faktura zostaje oznaczona jako gotowa do zapłaty, a jej dane finansowe są często przekazywane do zewnętrznego systemu ERP. Zdarzenie można zwykle wywnioskować z flagi statusu integracji lub zmiany głównego statusu faktury. | ||
|
Dlaczego to ważne
Ten etap oznacza przekazanie obsługi z działu zobowiązań do działu skarbu lub zespołu płatności. Opóźnienia przed tym momentem wpływają na efektywność obsługi zobowiązań, a późniejsze opóźnienia na pracę działu skarbu i relacje z dostawcami.
Skąd pobrać
Zdarzenie można często wywnioskować ze zmiany statusu na „approved for payment” lub ustawienia flagi „exported” na true. Informacje te są dostępne w obiekcie nagłówka faktury.
Rejestrowanie
Należy wykryć znacznik czasu zmiany statusu faktury na „Approved for Payment” lub ustawienia flagi eksportu.
Typ zdarzenia
inferred
|
|||
|
Realizacja płatności
|
To zdarzenie oznacza ostatni etap procesu: płatność zostaje zrealizowana i wysłana do dostawcy. Informację tę można odczytać ze statusu powiązanego rekordu płatności w Coupa Payments lub zintegrowanym systemie płatniczym. | ||
|
Dlaczego to ważne
Jako ostateczny koniec procesu to zdarzenie jest niezbędne do obliczenia całkowitego czasu realizacji od początku do końca oraz KPI „Odsetek płatności zrealizowanych w terminie”.
Skąd pobrać
Zdarzenie można wywnioskować z rekordu płatności powiązanego z fakturą. Status „paid” lub „completed” albo wypełnione pole „payment date” oznacza, że płatność została zrealizowana.
Rejestrowanie
Należy użyć pola „payment date” z rekordu płatności powiązanego z fakturą.
Typ zdarzenia
inferred
|
|||
|
Utworzenie faktury
|
To zdarzenie oznacza utworzenie rekordu faktury w systemie Coupa. Jest rejestrowane w chwili utworzenia nowego obiektu faktury, na przykład przez ręczne wprowadzenie danych, zintegrowaną sieć dostawców, taką jak Coupa Supplier Portal, lub automatyczne skanowanie OCR. | ||
|
Dlaczego to ważne
Jako początek cyklu życia faktury to zdarzenie jest niezbędne do pomiaru całkowitego czasu obsługi od początku do końca. Stanowi punkt odniesienia dla analizy czasu realizacji i przepustowości na kolejnych etapach.
Skąd pobrać
To jawne zdarzenie odczytywane ze znacznika czasu utworzenia rekordu faktury. W modelu danych Coupa odpowiada mu znacznik czasu „created-at” w obiekcie nagłówka faktury.
Rejestrowanie
Należy użyć znacznika czasu utworzenia rekordu faktury.
Typ zdarzenia
explicit
|
|||
|
Dopasowanie faktury do PO
|
To zdarzenie oznacza, że system prawidłowo dopasował pozycje faktury do odpowiednich pozycji zamówienia zakupu. Można je wywnioskować ze zmiany pola statusu dopasowania faktury, która wskazuje na pomyślną weryfikację względem PO. | ||
|
Dlaczego to ważne
Pomyślne automatyczne dopasowanie świadczy o sprawnym procesie, który nie wymaga ręcznej obsługi. Śledzenie tego zdarzenia pozwala ocenić skuteczność automatyzacji i odsetek spraw obsługiwanych bezpośrednio, bez ręcznej interwencji.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany statusu dopasowania faktury na „matched”. Obiekt faktury w Coupa zawiera flagi i statusy informujące o wyniku próby dopasowania do PO.
Rejestrowanie
Należy wykryć znacznik czasu, w którym status dopasowania faktury do PO zmienia się na „Matched”.
Typ zdarzenia
inferred
|
|||
|
Odblokowanie faktury
|
Wcześniejsza blokada faktury została usunięta, dzięki czemu może ona przejść do obsługi płatności. Podobnie jak założenie blokady, jest to jawne działanie zapisywane w ścieżce audytu faktury. | ||
|
Dlaczego to ważne
Czas między założeniem a usunięciem blokady jest niezbędny do obliczenia KPI „Średni czas blokady płatności”. To zdarzenie kończy okres opóźnienia, a analiza przyczyn odblokowania może wskazać możliwości szybszego rozwiązania problemu.
Skąd pobrać
To jawne zdarzenie zapisane w historii faktury lub dziennikach audytowych jako odrębne działanie użytkownika lub systemu.
Rejestrowanie
Należy odfiltrować w historii faktury wpisy „hold released” lub podobne zdarzenia systemowe.
Typ zdarzenia
explicit
|
|||
|
Odrzucenie faktury
|
Osoba akceptująca formalnie odrzuciła fakturę, zatrzymując jej dalszą obsługę w workflow. Jest to jawne działanie zapisywane w historii akceptacji faktury wraz z informacją, kto i kiedy ją odrzucił. | ||
|
Dlaczego to ważne
Odrzucenia powodują konieczność ponownej pracy i znacznie wydłużają czas realizacji. Analiza ich częstotliwości i przyczyn pomaga usprawnić proces oraz obliczyć KPI „Odsetek akceptacji za pierwszym razem”.
Skąd pobrać
To jawne zdarzenie zapisane w dzienniku historii akceptacji faktury. Każdy etap akceptacji ma własny wpis zawierający status, znacznik czasu i działanie osoby akceptującej.
Rejestrowanie
Należy odfiltrować w historii akceptacji wpisy z działaniem „reject” lub „rejected”.
Typ zdarzenia
explicit
|
|||
|
Przekazanie faktury do obsługi
|
Oznacza formalne przekazanie nowo utworzonej faktury do workflow obsługi. Zwykle użytkownik wykonuje tę czynność po wprowadzeniu i sprawdzeniu wszystkich początkowych danych. Zdarzenie można odczytać ze ścieżki audytu, gdy status faktury zmienia się z wersji roboczej na przesłaną. | ||
|
Dlaczego to ważne
To zdarzenie pozwala odróżnić czas wprowadzania danych od czasu aktywnej obsługi. Analiza czasu między „Utworzeniem faktury” a tym zdarzeniem pomaga wykryć opóźnienia na początkowym etapie wprowadzania danych.
Skąd pobrać
Należy śledzić zmianę statusu faktury z „draft” lub „new” na „submitted” lub „pending approval”. Informacje te są dostępne w historii faktury lub tabelach dziennika audytowego Coupa.
Rejestrowanie
Należy zapisać znacznik czasu, w którym status faktury po raz pierwszy zmienia się na „submitted”.
Typ zdarzenia
explicit
|
|||
|
Rozpoczęcie usuwania rozbieżności
|
Oznacza rozpoczęcie ręcznej interwencji w celu usunięcia rozbieżności przy dopasowaniu do PO. Trudno zarejestrować to zdarzenie bezpośrednio, dlatego często wnioskuje się o nim na podstawie pierwszej czynności użytkownika po wykryciu niezgodności, na przykład dodania komentarza lub edycji faktury. | ||
|
Dlaczego to ważne
Pomiar czasu od wykrycia rozbieżności do rozpoczęcia jej usuwania pomaga wskazać opóźnienia w przydzielaniu lub obsłudze wyjątków. To ważny element dashboardu „Przegląd rozbieżności przy dopasowaniu do PO”.
Skąd pobrać
Pozyskanie tych danych może być trudne i wymagać zaawansowanego wnioskowania. Można je uzyskać, wyszukując znacznik czasu pierwszego komentarza użytkownika, edycji lub przypisania zadania dotyczącego faktury po tym, jak status dopasowania wskazał niepowodzenie.
Rejestrowanie
Należy znaleźć pierwsze zdarzenie zmiany zainicjowane przez użytkownika po zdarzeniu „Wykrycie rozbieżności przy dopasowaniu”.
Typ zdarzenia
inferred
|
|||
|
Unieważnienie faktury
|
Faktura została anulowana i nie będzie dalej obsługiwana ani opłacona. Jest to jawna, końcowa zmiana statusu faktury, odczytywana bezpośrednio z pola statusu w systemie. | ||
|
Dlaczego to ważne
To alternatywny, niepomyślny koniec procesu. Analiza przyczyn unieważniania faktur może ujawnić problemy na wcześniejszych etapach zakupów lub komunikacji z dostawcami.
Skąd pobrać
To jawne zdarzenie rejestrowane, gdy status faktury zmienia się na „voided”. Jest to standardowy status w module zarządzania fakturami Coupa.
Rejestrowanie
Należy zapisać znacznik czasu zmiany statusu faktury na „Voided”.
Typ zdarzenia
explicit
|
|||
|
Wykrycie rozbieżności przy dopasowaniu
|
Zdarzenie występuje, gdy system nie może automatycznie dopasować faktury do zamówienia zakupu z powodu rozbieżności w ilości, cenie lub innych danych. Można je wywnioskować ze zmiany statusu faktury na wymagający ręcznej interwencji, na przykład „unmatched” lub „mismatched”. | ||
|
Dlaczego to ważne
To zdarzenie rozpoczyna obsługę wyjątku, która często powoduje opóźnienia. Analiza częstotliwości i przyczyn wyjątków pomaga zwiększyć odsetek faktur dopasowanych za pierwszym razem i ograniczyć nakład pracy ręcznej.
Skąd pobrać
Zdarzenie można wywnioskować ze statusu dopasowania faktury. Status „unmatched”, „mismatched” lub podobny oznacza rozbieżność wymagającą ręcznej weryfikacji. Informacja ta jest zapisywana w obiekcie faktury.
Rejestrowanie
Należy wykryć znacznik czasu, w którym status dopasowania do PO zmienia się na wartość oznaczającą niepowodzenie.
Typ zdarzenia
inferred
|
|||
|
Zablokowanie faktury
|
Oznacza zablokowanie faktury, które uniemożliwia jej opłacenie. Jest to jawne zdarzenie, zwykle zapisywane w historii faktury lub ścieżce audytu, często wraz z przyczyną blokady. | ||
|
Dlaczego to ważne
To zdarzenie, równoważne blokadzie płatności, jest częstą przyczyną opóźnień. Śledzenie momentu założenia blokady to pierwszy krok do analizy jej przyczyn i czasu trwania oraz obliczenia KPI „Odsetek zablokowanych płatności”.
Skąd pobrać
To jawne zdarzenie zapisane w historii faktury lub dziennikach audytowych. Coupa rejestruje działania użytkowników i systemu, w tym zakładanie blokad.
Rejestrowanie
Należy odfiltrować w historii faktury wpisy „hold placed” lub podobne zdarzenia systemowe.
Typ zdarzenia
explicit
|
|||
|
Zaplanowanie płatności
|
Faktura została uwzględniona w paczce płatności zaplanowanej do realizacji w przyszłości. Zdarzenie można wywnioskować z powiązania faktury z przebiegiem płatności lub obiektem paczki płatności w systemie. | ||
|
Dlaczego to ważne
To zdarzenie pokazuje końcowy etap procesu i pozwala odróżnić fakturę gotową do zapłaty od płatności, której realizację już rozpoczęto. Pomaga też prognozować przepływy pieniężne.
Skąd pobrać
Zdarzenie można wywnioskować z utworzenia rekordu płatności lub paczki zawierającej identyfikator faktury. Odpowiedni termin wskazuje pole „scheduled payment date” w obiekcie płatności.
Rejestrowanie
Należy użyć daty utworzenia rekordu paczki płatności powiązanej z fakturą.
Typ zdarzenia
inferred
|
|||
Instrukcje pobierania danych
Gotowi do rozpoczęcia?
Skorzystaj z tego szablonu, aby przygotować dane i uzyskać wgląd w przetwarzanie faktur w Coupa. Już dziś rozpocznij usprawnianie operacji P2P.
Zwiększ efektywność: usprawnij przetwarzanie faktur P2P
Wskaż wąskie gardła i skróć czas przetwarzania faktur o 30%.
Nie trzeba podawać danych karty płatniczej. Konfiguracja zajmuje kilka minut.