Szablon danych do analizy obsługi faktur w procesie od zakupu do płatności
Szablon danych do analizy obsługi faktur w procesie od zakupu do płatności
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia
- Wskazówki dotyczące pobierania danych z Oracle Fusion Financials
Atrybuty obsługi faktur w procesie od zakupu do płatności
| Nazwa | Opis | ||
|---|---|---|---|
|
Numer faktury
InvoiceNumber
|
Unikalny identyfikator faktury od dostawcy. | ||
|
Opis
Numer faktury jest głównym identyfikatorem case. Łączy wszystkie czynności i zdarzenia dotyczące jednej faktury od dostawcy, od jej utworzenia po końcową płatność. Każda faktura jest traktowana w analizie procesu jako osobny case. W process mining ten atrybut jest niezbędny do odtworzenia całego przebiegu obsługi każdej faktury. Umożliwia analizę przepływów procesu, czasu realizacji i różnic między fakturami. Pozwala połączyć takie czynności jak weryfikacja, akceptacja i płatność w spójny obraz procesu.
Dlaczego to ważne
To niezbędny identyfikator case, który łączy wszystkie powiązane etapy procesu i pozwala prześledzić cały cykl obsługi faktury.
Skąd pobrać
Zazwyczaj znajduje się w kolumnie INVOICE_NUM tabeli AP_INVOICES_ALL.
Przykłady
INV-2023-001987654321ACME-FIN-5501
|
|||
|
Czas rozpoczęcia
EventTime
|
Znacznik czasu wskazujący, kiedy wystąpiła czynność lub zdarzenie. | ||
|
Opis
Ten atrybut zawiera datę i godzinę każdej czynności w procesie obsługi faktury. Jest niezbędny do analizy czasu, w tym obliczania czasu realizacji, czasu trwania i oczekiwania między etapami. Narzędzia process mining porządkują zdarzenia chronologicznie według tego znacznika czasu, aby odtworzyć dokładną kolejność czynności dla każdej faktury. Umożliwia to obliczanie KPI, takich jak średni czas obsługi faktury, i wskazanie etapów, które zajmują najwięcej czasu.
Dlaczego to ważne
Ten znacznik czasu jest niezbędny do obliczania miar wydajności związanych z czasem, takich jak czas realizacji i wąskie gardła.
Skąd pobrać
Znacznik czasu jest wyznaczany na podstawie różnych pól daty w tabelach Oracle Fusion, takich jak CREATION_DATE lub LAST_UPDATE_DATE w tabelach AP_INVOICES_ALL oraz powiązanych tabelach workflow i płatności.
Przykłady
2023-04-15T10:00:00Z2023-04-16T14:35:10Z2023-04-20T09:05:00Z
|
|||
|
Czynność
ActivityName
|
Nazwa czynności biznesowej lub zdarzenia, które wystąpiło w procesie obsługi faktury. | ||
|
Opis
Ten atrybut opisuje konkretny etap lub zmianę statusu w cyklu obsługi faktury, na przykład „Utworzenie faktury”, „Akceptacja faktury” lub „Realizacja płatności”. Z takich zdarzeń składa się przebieg procesu. Analiza kolejności i częstotliwości czynności stanowi podstawę process mining. Pomaga odkryć rzeczywisty przebieg procesu, wskazać wąskie gardła powodujące opóźnienia oraz wykryć odstępstwa i cykle poprawek, na przykład odrzucenie faktury po jej akceptacji.
Dlaczego to ważne
Określa etapy procesu, co pozwala wizualizować mapę procesu, analizować różnice w jego przebiegu i wskazywać wąskie gardła.
Skąd pobrać
Ten atrybut jest zwykle wyznaczany na podstawie połączenia pól statusu, tabel audytowych lub dzienników workflow w Oracle Fusion Financials, takich jak AP_INVOICES_ALL.WFAPPROVAL_STATUS lub powiązane tabele workflow.
Przykłady
Weryfikacja fakturyNałożenie blokady na fakturęAkceptacja fakturyRealizacja płatności
|
|||
|
Czas zakończenia
EndTime
|
Znacznik czasu wskazujący, kiedy czynność lub zdarzenie zostało zakończone. | ||
|
Opis
Czas zakończenia wskazuje, kiedy zakończyła się dana czynność. Czas rozpoczęcia oznacza jej początek, a czas zakończenia pozwala dokładnie obliczyć czas trwania. Różnica między czasem zakończenia a czasem rozpoczęcia określa czas realizacji każdej czynności. Ułatwia szczegółową analizę wyników i odróżnienie aktywnej pracy od oczekiwania. Można na przykład zmierzyć, ile czasu osoba akceptująca faktycznie poświęciła na akceptację, a ile faktura czekała w jej kolejce.
Dlaczego to ważne
Pozwala dokładnie obliczyć czas realizacji czynności i oddzielić czas aktywnej pracy od czasu oczekiwania.
Skąd pobrać
To atrybut koncepcyjny wyznaczany na podstawie czasu rozpoczęcia kolejnego zdarzenia w sekwencji dla danego case.
Przykłady
2023-04-15T10:05:12Z2023-04-16T15:00:00Z2023-04-20T09:15:30Z
|
|||
|
Kod spółki
CompanyCode
|
Identyfikator jednostki prawnej lub spółki obsługującej fakturę. | ||
|
Opis
Kod spółki wskazuje konkretną jednostkę organizacji, która odpowiada finansowo za fakturę. W organizacjach obejmujących wiele spółek jest to podstawowa informacja organizacyjna. Atrybut ten pozwala analizować proces osobno dla każdej jednostki prawnej. Ułatwia porównywanie wyników procesu w różnych częściach firmy, wykrywanie wąskich gardeł lub problemów ze zgodnością dotyczących konkretnych jednostek oraz raportowanie KPI na poziomie spółki. Kod spółki często wpływa również na wybór właściwego workflow zatwierdzania.
Dlaczego to ważne
Umożliwia porównywanie procesów i wyników między różnymi jednostkami prawnymi lub jednostkami biznesowymi organizacji.
Skąd pobrać
Zwykle jest to pole LEGAL_ENTITY_ID lub podobne w tabeli AP_INVOICES_ALL. Można je połączyć z tabelami księgi głównej, aby uzyskać kod lub nazwę.
Przykłady
1001US01DE01
|
|||
|
Kwota faktury
InvoiceAmount
|
Łączna wartość pieniężna faktury. | ||
|
Opis
Kwota faktury to łączna suma należna dostawcy, podana na fakturze. Ten istotny atrybut finansowy wpływa na przebieg całego procesu. Często decyduje o ścieżce zatwierdzania, poziomie kontroli i priorytecie płatności. W analizie process mining kwota faktury jest ważnym wymiarem filtrowania i segmentacji. Analitycy mogą na przykład porównać obsługę faktur o wysokiej i niskiej wartości, aby sprawdzić, czy przebiega ona różnymi ścieżkami lub czy czas realizacji znacząco się różni. Atrybut ten jest również niezbędny do obliczania finansowych KPI i oceny kosztów nieefektywności procesu, takich jak opóźnione płatności.
Dlaczego to ważne
Ta wartość ma znaczenie w analizie finansowej, przy badaniu odchyleń w procesie zależnych od kwoty oraz przy obliczaniu KPI, takich jak wskaźnik zgodności zatwierdzania.
Skąd pobrać
Wartość znajduje się w kolumnie INVOICE_AMOUNT tabeli AP_INVOICES_ALL.
Przykłady
1500.00250.75125000.50
|
|||
|
Nazwa dostawcy
VendorName
|
Nazwa dostawcy, który wystawił fakturę. | ||
|
Opis
Ten atrybut wskazuje dostawcę, od którego pochodzi faktura. Informacje o dostawcy zapewniają ważny kontekst biznesowy dla transakcji finansowej. Analiza procesu według dostawcy może ujawnić istotne informacje o relacjach z dostawcami i ich wynikach. Można na przykład sprawdzić, czy faktury od określonych dostawców częściej zawierają niezgodności przy dopasowaniu, są blokowane lub obsługiwane z opóźnieniem. Te informacje pomagają usprawnić wdrażanie dostawców, komunikację z nimi i efektywność całego łańcucha dostaw. Służą również do wykrywania potencjalnych podwójnych płatności.
Dlaczego to ważne
Umożliwia analizę procesu dla poszczególnych dostawców i pomaga wykryć problemy z konkretnymi dostawcami, które powodują opóźnienia lub wyjątki.
Skąd pobrać
Dane znajdują się w tabeli POZ_SUPPLIERS. Tabela faktur AP_INVOICES_ALL zawiera pole VENDOR_ID, które można wykorzystać do połączenia z tabelą dostawców.
Przykłady
Acme CorporationGlobal Tech Inc.Office Supplies Co.
|
|||
|
Nazwa użytkownika
UserName
|
Nazwa użytkownika, który wykonał daną czynność. | ||
|
Opis
Ten atrybut wskazuje konkretnego użytkownika lub agenta systemowego odpowiedzialnego za wykonanie czynności, na przykład weryfikację faktury, nałożenie blokady lub zatwierdzenie płatności. Pozwala uwzględnić w analizie zasoby ludzkie i systemowe. Analiza według użytkownika pomaga ocenić rozkład obciążenia pracą, wskazać osoby osiągające najlepsze wyniki oraz wykryć potrzeby szkoleniowe lub problemy ze zgodnością. Można na przykład sprawdzić, czy określeni użytkownicy często uczestniczą w pętlach poprawek albo czy konkretne etapy zatwierdzania zawsze obsługuje ta sama osoba, co może prowadzić do powstania pojedynczego punktu awarii.
Dlaczego to ważne
Umożliwia analizę efektywności zasobów, równoważenie obciążenia pracą oraz sprawdzenie, którzy użytkownicy lub zespoły uczestniczą w poszczególnych etapach procesu.
Skąd pobrać
Informacje te są często przechowywane w kolumnach audytowych, takich jak CREATED_BY lub LAST_UPDATED_BY, w tabelach takich jak AP_INVOICES_ALL albo w powiązanych logach workflow.
Przykłady
john.doejane.smithSystem.Admin
|
|||
|
Status faktury
InvoiceStatus
|
Bieżący status faktury w cyklu jej obsługi. | ||
|
Opis
Ten atrybut pokazuje ostatni znany stan faktury, na przykład „Zatwierdzona”, „Wymaga ponownej weryfikacji”, „Opłacona” lub „Anulowana”. Informuje, na jakim etapie procesu znajduje się faktura w danym momencie. Status faktury jest niezbędny w dashboardzie „Bieżący rozkład statusów faktur”. Pomaga osobom zarządzającym operacjami wykrywać zaległości i monitorować ogólną sprawność procesu obsługi faktur. Analiza zmian statusów w czasie pozwala również uzyskać uproszczony obraz przebiegu procesu.
Dlaczego to ważne
Pokazuje bieżący stan faktur, co jest niezbędne w dashboardach operacyjnych służących do monitorowania zaległości i obciążenia pracą.
Skąd pobrać
Należy sprawdzić dokumentację Oracle Fusion Financials. Status można ustalić na podstawie pól takich jak WFAPPROVAL_STATUS w tabeli AP_INVOICES_ALL lub powiązanych tabelach zatwierdzania i płatności.
Przykłady
ZatwierdzonaOpłaconaAnulowanaWymagana ponowna weryfikacja
|
|||
|
Termin płatności
PaymentDueDate
|
Data, do której należy zapłacić dostawcy za fakturę. | ||
|
Opis
Termin płatności jest wyznaczany na podstawie warunków płatności uzgodnionych z dostawcą. To ostateczny termin zapłaty, który pozwala uniknąć kar, utrzymać dobre relacje z dostawcą i skorzystać z ewentualnych rabatów za wcześniejszą płatność. Ten atrybut jest niezbędny w dashboardzie „Terminowość płatności” i powiązanym z nim KPI. Porównanie znacznika czasu wykonania płatności z terminem płatności pozwala określić, czy płatność była terminowa, czy opóźniona. Dzięki temu organizacja może monitorować terminowość płatności i ją poprawiać.
Dlaczego to ważne
To punkt odniesienia przy pomiarze terminowości płatności, ważnego KPI w zarządzaniu dostawcami i ocenie kondycji finansowej.
Skąd pobrać
Data jest często dostępna w tabelach harmonogramów płatności, takich jak AP_PAYMENT_SCHEDULES_ALL, powiązanych z fakturą.
Przykłady
2023-05-152023-06-012023-06-30
|
|||
|
Czy płatność była terminowa
IsOnTimePayment
|
Wartość logiczna wskazująca, czy faktura została opłacona do terminu płatności. | ||
|
Opis
Wartość tego atrybutu jest ustawiana na true, jeśli płatność została zrealizowana w terminie płatności lub wcześniej, a w przeciwnym razie na false. Pozwala w prosty i czytelny sposób sklasyfikować każdą opłaconą fakturę. Ten obliczany atrybut bezpośrednio wspiera KPI „Wskaźnik terminowych płatności” i powiązany z nim dashboard. Ułatwia analizę, ponieważ pozwala filtrować, zliczać i wizualizować udział płatności opóźnionych i terminowych bez każdorazowego porównywania dat. Dzięki temu można szybko ocenić skalę opóźnień i śledzić zmiany w czasie.
Dlaczego to ważne
Ułatwia analizę terminowości płatności i bezpośrednio służy do obliczania KPI „Wskaźnik terminowych płatności”.
Skąd pobrać
To obliczany atrybut, wyznaczany przez porównanie znacznika czasu czynności „Płatność zrealizowana” z atrybutem „PaymentDueDate”.
Przykłady
truefalse
|
|||
|
Czy wystąpiły poprawki
IsRework
|
Wartość logiczna wskazująca, czy czynność należy do pętli poprawek. | ||
|
Opis
Wartość tego atrybutu jest ustawiana na true dla czynności wskazujących na odejście od optymalnego przebiegu procesu, takich jak „Faktura poprawiona” lub ponowne wystąpienie czynności „Faktura zweryfikowana” po odrzuceniu. Pozwala jawnie oznaczać i mierzyć nieefektywne pętle procesu. Ten atrybut jest niezbędny w dashboardzie „Wskaźnik poprawek i obsługi wyjątków”. Oznaczenie czynności związanych z poprawkami ułatwia analitykom określenie ich liczby i kosztów, wykrycie przyczyn oraz pomiar efektów działań usprawniających proces, których celem jest poprawne wykonanie pracy za pierwszym razem.
Dlaczego to ważne
Pozwala jednoznacznie wskazać i zmierzyć poprawki, co ułatwia analizę częstotliwości, przyczyn i wpływu nieefektywności procesu.
Skąd pobrać
To obliczany atrybut. Logikę określa się podczas transformacji danych, aby wykrywać sekwencje czynności składające się na poprawki.
Przykłady
truefalse
|
|||
|
Data faktury
InvoiceDate
|
Data podana na fakturze dostawcy. | ||
|
Opis
Ten atrybut wskazuje datę oficjalnego wystawienia faktury przez dostawcę. Jest to ważna informacja z dokumentu źródłowego, wykorzystywana do obliczenia terminu płatności na podstawie uzgodnionych warunków. Data faktury nie zawsze wyznacza początek procesu wewnętrznego, ale stanowi ważny kontekst. W połączeniu z nazwą dostawcy i kwotą faktury pomaga wykrywać potencjalne duplikaty. Analiza czasu między datą faktury a datą jej wprowadzenia do systemu może również ujawnić nieefektywności w obsłudze korespondencji lub rejestrowaniu faktur.
Dlaczego to ważne
To ważna informacja przy wykrywaniu duplikatów faktur i obliczaniu terminów płatności.
Skąd pobrać
To standardowe pole INVOICE_DATE w tabeli AP_INVOICES_ALL.
Przykłady
2023-04-102023-05-012023-05-25
|
|||
|
Data ostatniej aktualizacji danych
LastUpdateDate
|
Znacznik czasu wskazujący, kiedy rekord został ostatnio zaktualizowany w systemie źródłowym. | ||
|
Opis
Ten atrybut wskazuje, kiedy dane źródłowe w Oracle Fusion Financials zostały ostatnio zmodyfikowane. Służy do obsługi przyrostowego ładowania danych i zapewnienia aktualności modelu process mining. Ten techniczny znacznik czasu nie służy bezpośrednio do analizy przebiegu procesu, ale pomaga utrzymać aktualność i integralność danych. Dzięki niemu potoki danych mogą pobierać tylko nowe lub zmienione rekordy od ostatniej aktualizacji, ograniczając obciążenie systemu źródłowego.
Dlaczego to ważne
Pozwala wydajnie uruchamiać potoki danych i ładować dane przyrostowo, dzięki czemu analiza procesu pozostaje aktualna bez ponownego wczytywania całości.
Skąd pobrać
W wielu tabelach Oracle Fusion, w tym AP_INVOICES_ALL, występuje jako LAST_UPDATE_DATE.
Przykłady
2023-05-20T11:00:00Z2023-05-21T16:45:00Z
|
|||
|
Imię i nazwisko osoby zatwierdzającej
ApproverName
|
Imię i nazwisko osoby, która zatwierdziła lub odrzuciła fakturę. | ||
|
Opis
Ten atrybut wskazuje osobę, która podjęła decyzję na etapie zatwierdzania. Jest rejestrowany przy czynnościach takich jak „Faktura zatwierdzona” lub „Faktura odrzucona”. W analizie imię i nazwisko osoby zatwierdzającej służy do oceny obciążenia pracą osób zatwierdzających, pomiaru czasu zatwierdzania przez poszczególne osoby oraz kontroli zgodności z zasadami zatwierdzania. Na potrzeby KPI „Wskaźnik zgodności zatwierdzania” można porównać ten atrybut z zasadami delegowania uprawnień, które zależą od kwoty faktury i kodu spółki.
Dlaczego to ważne
Atrybut ten jest niezbędny do analizy czasu zatwierdzania, kontroli zgodności z matrycą uprawnień oraz oceny rozkładu obciążenia pracą.
Skąd pobrać
Informacje te znajdują się w tabelach workflow lub historii zatwierdzania Oracle Fusion powiązanych z obiektem faktury.
Przykłady
David WilsonSarah JohnsonMichael Brown
|
|||
|
Numer zamówienia zakupu
PurchaseOrderNumber
|
Identyfikator zamówienia zakupu powiązanego z fakturą. | ||
|
Opis
Ten atrybut łączy fakturę z odpowiednim zamówieniem zakupu (PO), na podstawie którego zamówiono towary lub usługi. Faktury mogą być powiązane z zamówieniem zakupu lub wystawione bez niego. Analiza według numeru PO łączy obsługę faktur z zakupową częścią procesu P2P. Pomaga ocenić zgodność procesu zakupowego z zasadami i sprawdzić, czy problemy z fakturami, takie jak niezgodności przy dopasowaniu, wynikają z błędów w pierwotnym zamówieniu. Obecność lub brak numeru PO to podstawowy sposób podziału i analizy różnych ścieżek obsługi faktur.
Dlaczego to ważne
Łączy fakturę z procesem zakupowym i pozwala analizować przepływy faktur powiązanych z PO oraz faktur bez PO.
Skąd pobrać
Informacje można uzyskać, łącząc pozycje faktury z tabeli AP_INVOICE_LINES_ALL z rozdziałami zamówienia zakupu za pomocą pola PO_DISTRIBUTION_ID.
Przykłady
PO-2023-5001600789PO-FIN-9981
|
|||
|
Powód blokady
HoldReason
|
Powód nałożenia blokady na fakturę lub wstrzymania płatności. | ||
|
Opis
Ten atrybut wskazuje powód zablokowania faktury, na przykład „Niezgodna cena”, „Niezgodna ilość” lub „Oczekiwanie na potwierdzenie odbioru towaru”. Wyjaśnia, dlaczego standardowy przebieg procesu został przerwany. Atrybut ten jest głównym wymiarem dashboardu „Trendy i analiza blokad płatności”. Analiza częstotliwości poszczególnych powodów blokad pozwala firmie wykrywać i usuwać ich źródła, takie jak problemy w procesie zakupowym lub błędy na fakturach dostawców. W efekcie można ograniczyć opóźnienia w obsłudze.
Dlaczego to ważne
Wskazuje przyczynę blokady płatności, co pozwala wprowadzać ukierunkowane usprawnienia i ograniczać liczbę blokad oraz opóźnień w płatnościach.
Skąd pobrać
Informacje o blokadach są zwykle przechowywane w tabeli AP_HOLDS_ALL, powiązanej z fakturą i zawierającej powód lub kod blokady.
Przykłady
Niezgodna cenaZafakturowana ilość przekracza ilość odebranąNieprawidłowy numer zamówienia zakupu
|
|||
|
Powód niezgodności przy dopasowaniu
MatchingDiscrepancyReason
|
Szczegółowy powód niezgodności między fakturą, zamówieniem zakupu i potwierdzeniem odbioru. | ||
|
Opis
Ten atrybut określa, dlaczego faktura nie przeszła automatycznego dopasowania. Typowe powody to różnice w cenie, ilości lub kodach pozycji między fakturą a powiązanym zamówieniem zakupu lub potwierdzeniem odbioru towaru. Informacje te są niezbędne w dashboardzie „Wskaźnik niezgodności przy dopasowaniu faktur”. Klasyfikacja i analiza przyczyn niezgodności pozwalają firmom wykrywać powtarzające się problemy w procesach zakupowych lub odbioru towarów. Dzięki temu można podjąć działania naprawcze i zwiększyć odsetek faktur obsługiwanych bez ręcznej interwencji.
Dlaczego to ważne
Wyjaśnia, dlaczego faktury nie przechodzą automatycznego dopasowania. Pomaga poprawić skuteczność dopasowania za pierwszym razem i ograniczyć ręczne poprawki.
Skąd pobrać
Należy sprawdzić dokumentację Oracle Fusion Financials. Informacja może być zapisana jako konkretny rodzaj powodu blokady w tabeli AP_HOLDS_ALL lub w powiązanych tabelach szczegółów dopasowania.
Przykłady
Cena jednostkowa różni się od ceny w zamówieniu zakupuZafakturowana ilość > odebrana ilośćNieprawidłowa pozycja na fakturze
|
|||
|
System źródłowy
SourceSystem
|
Wskazuje system źródłowy, w którym zarejestrowano dane o zdarzeniu. | ||
|
Opis
Ten atrybut określa aplikację lub moduł źródłowy, który wygenerował dane, na przykład Oracle Fusion Financials. W środowiskach z wieloma zintegrowanymi systemami pozwala ustalić, z którego z nich pochodzi dany etap procesu. Informacja o systemie źródłowym przydaje się do weryfikacji danych, rozwiązywania problemów i analizy różnic w procesie, które mogą wynikać z użycia konkretnego systemu. Ułatwia orientację w złożonym środowisku IT, w którym obsługa faktury może obejmować kilka aplikacji.
Dlaczego to ważne
Informacja o pochodzeniu danych jest przydatna w zarządzaniu danymi, rozwiązywaniu problemów i analizie zachowania procesu w poszczególnych systemach.
Skąd pobrać
Często jest to stała wartość dodawana podczas wyodrębniania danych, która określa ich źródło.
Przykłady
Oracle Fusion FinancialsOracle Payables Cloud
|
|||
|
Waluta
InvoiceCurrencyCode
|
Waluta, w której wyrażono kwotę faktury. | ||
|
Opis
Ten atrybut określa walutę faktury, na przykład USD, EUR lub GBP. Stanowi niezbędny kontekst dla pola kwoty faktury. W organizacji działającej na wielu rynkach analiza faktur według waluty ma znaczenie dla sprawozdawczości finansowej i badania różnic w procesie między regionami. Pozwala prawidłowo interpretować wartości pieniężne oraz analizować praktyki płatnicze i progi zatwierdzania dla poszczególnych walut.
Dlaczego to ważne
Zapewnia niezbędny kontekst dla kwot finansowych i pozwala prawidłowo je interpretować oraz analizować, szczególnie w organizacjach międzynarodowych.
Skąd pobrać
Wartość znajduje się w kolumnie INVOICE_CURRENCY_CODE tabeli AP_INVOICES_ALL.
Przykłady
USDEURGBPCAD
|
|||
Działania w procesie obsługi faktur od zakupu do płatności
| Działanie | Opis | ||
|---|---|---|---|
|
Akceptacja faktury
|
Wszyscy wymagani uczestnicy workflow zaakceptowali fakturę. Jest ona gotowa do zaksięgowania i zaplanowania płatności. | ||
|
Dlaczego to ważne
To ważny etap oznaczający zakończenie procesu akceptacji. Opóźnienia przed tym etapem często wskazują na wąskie gardła.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany APPROVAL_STATUS w tabeli AP_INVOICES_ALL na końcowy status akceptacji, taki jak „Approved” lub „Workflow Approved”. Znacznik czasu można uzyskać z historii audytu tego pola.
Rejestrowanie
Zdarzenie można wywnioskować ze zmiany AP_INVOICES_ALL.APPROVAL_STATUS na „Approved”.
Typ zdarzenia
inferred
|
|||
|
Przekazanie faktury do akceptacji
|
Faktura trafia do workflow akceptacji zgodnie ze skonfigurowanymi regułami biznesowymi. Rozpoczyna się formalny cykl akceptacji. | ||
|
Dlaczego to ważne
Rozpoczyna ważny etap procesu. Rejestrowanie czasu rozpoczęcia jest niezbędne do pomiaru i usprawniania „Czasu cyklu akceptacji faktury”.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany statusu w tabeli AP_INVOICES_ALL, gdy APPROVAL_STATUS przyjmuje wartość taką jak „Initiated” lub „Pending Approval”. Zdarzenie może być też zapisane w tabelach workflow.
Rejestrowanie
Zdarzenie można wywnioskować ze zmiany AP_INVOICES_ALL.APPROVAL_STATUS na „Initiated”.
Typ zdarzenia
inferred
|
|||
|
Realizacja płatności
|
Końcowe potwierdzenie, że płatność została zrealizowana i rozliczona. W przypadku czeków jest to data ich rozliczenia, a w przypadku płatności elektronicznych potwierdzenie z banku. | ||
|
Dlaczego to ważne
To ostatnia czynność w cyklu obsługi faktury, która oznacza pomyślne zakończenie procesu. Stanowi punkt końcowy przy obliczaniu „Średniego czasu obsługi faktury” i „Odsetka płatności zrealizowanych w terminie”.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany statusu płatności na „Cleared” lub „Reconciled” w tabeli AP_CHECKS_ALL (na podstawie CLEARED_DATE) albo z danych o uzgodnieniu bankowym w module Cash Management (CE_STATEMENT_LINES).
Rejestrowanie
Zdarzenie można wywnioskować ze zmian statusu w AP_CHECKS_ALL lub uzgodnienia w module CE.
Typ zdarzenia
inferred
|
|||
|
Utworzenie faktury
|
Utworzenie rekordu faktury w systemie, ręcznie, przez skanowanie lub w wyniku przesłania elektronicznego. Zdarzenie jest zwykle rejestrowane w chwili dodania nowego wiersza do głównej tabeli faktur. | ||
|
Dlaczego to ważne
To początek cyklu obsługi faktury. Analiza czasu od tego zdarzenia pozwala ocenić sprawność wprowadzania danych i opóźnienia na początku procesu.
Skąd pobrać
W Oracle Fusion Financials odpowiada temu znacznik czasu utworzenia rekordu w tabeli AP_INVOICES_ALL, a dokładniej wartość w kolumnie CREATION_DATE.
Rejestrowanie
Znacznik czasu utworzenia rekordu w AP_INVOICES_ALL.
Typ zdarzenia
explicit
|
|||
|
Uzgodnienie faktury z zamówieniem zakupu
|
Ta czynność oznacza pomyślne uzgodnienie pozycji faktury z odpowiadającą jej pozycją zamówienia zakupu. Potwierdza, że zafakturowane towary lub usługi zostały zamówione. Zdarzenie jest zwykle wynikiem działania automatycznego lub ręcznego zarejestrowanego w systemie. | ||
|
Dlaczego to ważne
To ważny etap uzgadniania trójstronnego, które obejmuje zamówienie zakupu, potwierdzenie odbioru i fakturę. Błędy na tym etapie są częstą przyczyną wyjątków i opóźnień.
Skąd pobrać
Zdarzenie można wywnioskować z utworzenia rekordów w tabeli AP_INVOICE_DISTRIBUTIONS_ALL, które łączą fakturę z dystrybucją zamówienia zakupu (PO_DISTRIBUTION_ID). Można też wykorzystać status uzgodnienia pozycji w tabeli AP_INVOICE_LINES_ALL.
Rejestrowanie
Zdarzenie można wywnioskować z uzupełnienia danych o dystrybucji zamówienia zakupu w pozycjach faktury.
Typ zdarzenia
inferred
|
|||
|
Zaksięgowanie faktury
|
Faktura zostaje zaksięgowana w księdze głównej, a system tworzy zapisy księgowe. Zdarzenie potwierdza formalne ujęcie skutków finansowych faktury. | ||
|
Dlaczego to ważne
To ważny punkt kontroli finansowej i warunek realizacji płatności. Potwierdza, że faktura została zweryfikowana i zaakceptowana oraz jest gotowa do rozliczenia.
Skąd pobrać
Zdarzenie można wywnioskować ze statusu w tabeli AP_INVOICE_DISTRIBUTIONS_ALL (ACCRUAL_POSTED_FLAG = 'Y') lub sprawdzając odpowiadające mu zapisy księgowe w tabelach księgi głównej, takich jak XLA_AE_HEADERS.
Rejestrowanie
Zdarzenie można wywnioskować na podstawie flag w AP_INVOICE_DISTRIBUTIONS_ALL lub powiązanych zapisów w księdze głównej.
Typ zdarzenia
inferred
|
|||
|
Anulowanie faktury
|
Faktura została unieważniona lub anulowana i nie będzie dalej obsługiwana ani opłacona. To końcowy status procesu. | ||
|
Dlaczego to ważne
To ważny punkt końcowy dla faktur, które nie prowadzą do płatności. Analiza anulowań może ujawnić problemy z duplikatami faktur lub błędnymi zgłoszeniami dostawców.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany statusu w AP_INVOICES_ALL. Kolumna CANCELLED_DATE zawiera znacznik czasu anulowania.
Rejestrowanie
Pole CANCELLED_DATE w tabeli AP_INVOICES_ALL zostaje uzupełnione.
Typ zdarzenia
explicit
|
|||
|
Nałożenie blokady na fakturę
|
Ogólne zdarzenie oznaczające nałożenie dowolnej blokady na fakturę, która uniemożliwia przejście do płatności. Przyczyną mogą być problemy z uzgadnianiem, niewystarczające środki lub ręczna interwencja. | ||
|
Dlaczego to ważne
Blokada bezpośrednio wydłuża czas realizacji i może prowadzić do opóźnień w płatnościach. Analiza blokad pomaga wykrywać i rozwiązywać problemy systemowe w procesie oraz wspiera analizę „Trendów blokad płatności”.
Skąd pobrać
Zdarzenie jest jawnie rejestrowane w tabeli AP_HOLDS_ALL. Każdy wiersz oznacza blokadę i zawiera datę jej utworzenia (HOLD_DATE) oraz przyczynę.
Rejestrowanie
Utworzenie rekordu w tabeli AP_HOLDS_ALL.
Typ zdarzenia
explicit
|
|||
|
Odrzucenie faktury
|
Osoba akceptująca odrzuciła fakturę w trakcie workflow akceptacji. Zwykle faktura wraca do poprawy lub zostaje anulowana, co rozpoczyna cykl poprawek. | ||
|
Dlaczego to ważne
To niekorzystny wynik, który często prowadzi do poprawek i wydłuża czas realizacji. Śledzenie odrzuceń pomaga wykrywać problemy z jakością faktur lub zgodnością z zamówieniami zakupu.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany APPROVAL_STATUS w tabeli AP_INVOICES_ALL na „Rejected”. Historia workflow zawiera informacje o tym, kto i kiedy odrzucił fakturę.
Rejestrowanie
Zdarzenie można wywnioskować ze zmiany AP_INVOICES_ALL.APPROVAL_STATUS na „Rejected”.
Typ zdarzenia
inferred
|
|||
|
Poprawienie faktury
|
Zdarzenie występuje, gdy użytkownik modyfikuje fakturę, często po jej odrzuceniu lub w celu poprawienia błędu we wprowadzonych danych. To ręczny etap poprawek w procesie. | ||
|
Dlaczego to ważne
Ta czynność wyraźnie wskazuje na konieczność poprawek. Analiza jej częstotliwości pozwala ocenić nieefektywność procesu i obliczyć KPI „Odsetek faktur wymagających poprawek”.
Skąd pobrać
Zdarzenie można wywnioskować, śledząc istotne zmiany rekordu faktury w AP_INVOICES_ALL po jej weryfikacji lub przekazaniu do akceptacji. Potrzebne będą znacznik czasu LAST_UPDATE_DATE i dane ze ścieżki audytu.
Rejestrowanie
Zdarzenie można wywnioskować, porównując LAST_UPDATE_DATE po odrzuceniu faktury lub nałożeniu blokady.
Typ zdarzenia
inferred
|
|||
|
Utworzenie płatności
|
System wygenerował dyspozycję płatności za fakturę. Może to oznaczać utworzenie czeku, pliku elektronicznego przelewu (EFT) lub innego instrumentu płatniczego. | ||
|
Dlaczego to ważne
Na tym etapie organizacja przeznacza środki na płatność. To ważny moment tuż przed wypływem pieniędzy z rachunku bankowego.
Skąd pobrać
Zdarzenie jest rejestrowane w tabeli AP_CHECKS_ALL, która przechowuje informacje o wszystkich płatnościach. Pole CHECK_DATE wskazuje datę utworzenia dokumentu płatniczego.
Rejestrowanie
Utworzenie rekordu w tabeli AP_CHECKS_ALL.
Typ zdarzenia
explicit
|
|||
|
Weryfikacja faktury
|
Oznacza, że faktura przeszła systemowe kontrole kompletności i poprawności danych w nagłówku oraz pozycjach. Zdarzenie często można wywnioskować ze zmiany statusu rekordu faktury. | ||
|
Dlaczego to ważne
Ważny etap przed uzgadnianiem i akceptacją. Opóźnienia mogą wskazywać na problemy z jakością danych faktury lub konfiguracją systemu.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany statusu faktury na „Validated” w tabeli AP_INVOICES_ALL. Można wykorzystać historię zmian lub ścieżkę audytu kolumny VALIDATION_STATUS.
Rejestrowanie
Zdarzenie można wywnioskować ze zmiany pola AP_INVOICES_ALL.VALIDATION_STATUS.
Typ zdarzenia
inferred
|
|||
|
Wykrycie rozbieżności przy uzgadnianiu
|
Zdarzenie występuje, gdy system lub użytkownik wykryje niezgodność między fakturą, zamówieniem zakupu i danymi o odbiorze, na przykład dotyczącą ceny lub ilości. Często skutkuje to nałożeniem blokady na fakturę. | ||
|
Dlaczego to ważne
Wskazuje wyjątki w procesie, które wymagają ręcznej obsługi. Śledzenie tych zdarzeń jest niezbędne do obliczania KPI „Odsetek rozbieżności przy uzgadnianiu faktur” i analizy przyczyn źródłowych.
Skąd pobrać
Zdarzenie jest często rejestrowane jako nałożenie na fakturę blokady określonego typu. W tabeli AP_HOLDS_ALL należy sprawdzić typy blokad związane z uzgadnianiem, na przykład „QTY REC” lub „PRICE”. Znacznik czasu wskazuje pole HOLD_DATE.
Rejestrowanie
Utworzenie rekordu w AP_HOLDS_ALL z typem blokady związanym z uzgadnianiem.
Typ zdarzenia
explicit
|
|||
|
Zaplanowanie płatności
|
Faktura zostaje wybrana i uwzględniona w zleceniu płatności, często nazywanym przebiegiem lub paczką płatności. Trafia do kolejki płatności. | ||
|
Dlaczego to ważne
To etap między zaksięgowaniem a realizacją płatności. Czas jego trwania wpływa na prognozowanie przepływów pieniężnych i możliwość skorzystania ze skonta za wcześniejszą płatność.
Skąd pobrać
Zdarzenie jest rejestrowane w tabeli AP_INVOICE_PAYMENTS_ALL po utworzeniu rekordu płatności, zanim zostanie ona potwierdzona jako zrealizowana. Można je też znaleźć w tabelach paczek płatności, takich jak IBY_PAYMENT_PROCESS_REQUESTS.
Rejestrowanie
Utworzenie rekordu zaplanowanej płatności w AP_INVOICE_PAYMENTS_ALL.
Typ zdarzenia
explicit
|
|||
|
Zwolnienie blokady faktury
|
To zdarzenie oznacza usunięcie blokady nałożonej wcześniej na fakturę. Użytkownik lub proces automatyczny podejmuje działanie, które odblokowuje fakturę i pozwala jej przejść do kolejnych etapów. | ||
|
Dlaczego to ważne
Czas od nałożenia do zwolnienia blokady jest ważną miarą sprawności obsługi wyjątków. Wspiera obliczanie KPI „Średni czas rozwiązania wyjątku”.
Skąd pobrać
Zdarzenie jest rejestrowane w tabeli AP_HOLDS_ALL. Po zwolnieniu blokady uzupełniane są pola RELEASE_LOOKUP_CODE i RELEASE_REASON oraz LAST_UPDATE_DATE.
Rejestrowanie
Aktualizacja rekordu w tabeli AP_HOLDS_ALL oznaczająca zwolnienie blokady.
Typ zdarzenia
explicit
|
|||
Instrukcje pobierania danych
Gotowi do rozpoczęcia?
Przygotuj dane za pomocą tego szablonu i rozpocznij usprawnianie obsługi faktur. Analiza pozwoli uzyskać przydatne informacje i zwiększyć efektywność organizacji.
Usprawnij obsługę faktur P2P i skróć cykl o 30%
Usuń wąskie gardła w Oracle Fusion Financials i skróć czas cyklu o 30%.
Nie trzeba podawać danych karty płatniczej. Pierwsze wyniki można zobaczyć w ciągu kilku dni.