Szablon danych dla procesu Order to Cash - fakturowanie i wystawianie faktur

Oracle Fusion Financials
Szablon danych dla procesu Order to Cash - fakturowanie i wystawianie faktur

Szablon danych dla procesu Order to Cash - fakturowanie i wystawianie faktur

Ten szablon zawiera wskazówki dotyczące pobierania danych potrzebnych do analizy procesu Order to Cash - fakturowanie i wystawianie faktur. Opisuje wymagane atrybuty, działania do śledzenia oraz praktyczne sposoby ekstrakcji danych. Korzystając z szablonu, można przygotować zestaw danych do process mining i optymalizacji procesu.
  • Zalecane atrybuty do zebrania
  • Działania, które warto śledzić
  • Wskazówki dotyczące ekstrakcji danych z Oracle Fusion Financials
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty procesu Order to Cash - fakturowanie i wystawianie faktur

Poniżej wymieniono zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń do analizy procesu Order to Cash - fakturowanie i wystawianie faktur.
3 Wymagane 5 Zalecane 14 Opcjonalne
Nazwa Opis
Godzina rozpoczęcia
EventTimestamp
Dokładna data i godzina wystąpienia danego działania lub zdarzenia.
Opis

Znacznik czasu zdarzenia zapisuje dokładny moment wykonania działania. Określa kolejność zdarzeń dla każdej faktury, co jest niezbędne do odtworzenia przebiegu procesu i przeprowadzania analiz czasowych.

Na tym atrybucie opierają się obliczenia czasu trwania i efektywności. Pozwala mierzyć odstępy między działaniami, obliczać pełny czas cyklu, sprawdzać terminowość płatności i analizować zmiany w czasie. KPI, takie jak „Średni czas zatwierdzania faktury” i „Pełny czas cyklu faktury”, są obliczane bezpośrednio na podstawie tych znaczników czasu.

Dlaczego to ważne

Znaczniki czasu są niezbędne do obliczania miar efektywności, w tym czasu cyklu, opóźnień i dotrzymywania terminów. Stanowią podstawę ilościowej analizy procesu.

Skąd pobrać

Dane pochodzą z różnych pól daty w tabelach Oracle Fusion Financials, na przykład z CREATION_DATE w RA_CUSTOMER_TRX_ALL lub znaczników czasu aktualizacji statusu w tabelach workflow.

Przykłady
2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-20T11:25:10Z
Numer faktury
InvoiceNumber
Unikalny identyfikator każdej faktury, używany jako główny identyfikator sprawy do śledzenia wszystkich powiązanych działań.
Opis

Numer faktury stanowi podstawę analizy procesu fakturowania. Pełni funkcję identyfikatora sprawy i łączy wszystkie zdarzenia, od utworzenia faktury po jej opłacenie i zamknięcie. Dzięki temu można prześledzić cały cykl życia pojedynczego dokumentu.

W process mining analiza według numeru faktury pozwala wizualizować warianty procesu, obliczać czas cyklu dla poszczególnych faktur oraz wykrywać wąskie gardła i powtarzające się etapy, które dotyczą konkretnych transakcji. Numer ten jest niezbędny w dashboardach, takich jak „Pełny czas cyklu faktury”, oraz przy obliczaniu podstawowych KPI, na przykład Days Sales Outstanding (DSO) dla każdej faktury.

Dlaczego to ważne

Ten atrybut łączy wszystkie powiązane działania dotyczące fakturowania i płatności w jedną sprawę, co umożliwia pełną i dokładną analizę cyklu życia faktury.

Skąd pobrać

Zwykle jest to numer transakcji (TRX_NUMBER) z tabeli RA_CUSTOMER_TRX_ALL w Oracle Fusion Financials.

Przykłady
INV-1002345983451CM-55432
Nazwa działania
ActivityName
Nazwa konkretnego zdarzenia biznesowego lub zadania, które wystąpiło w danym momencie cyklu życia faktury.
Opis

Nazwa działania opisuje etap procesu fakturowania, na przykład „Utworzenie faktury”, „Zatwierdzenie faktury” lub „Otrzymanie płatności od klienta”. Zdarzenia te tworzą sekwencję działań składających się na przebieg procesu dla każdej faktury.

Ten atrybut jest podstawą odkrywania procesów. Narzędzie process mining wykorzystuje go do tworzenia wizualnej mapy rzeczywistego przebiegu obsługi faktur. Służy do analizy wariantów procesu, wykrywania powtórnych etapów, takich jak kolejne rundy zatwierdzania, oraz mierzenia częstotliwości i czasu trwania poszczególnych etapów. Wszystkie dashboardy i KPI korzystają z tego atrybutu, aby pokazać przebieg procesu.

Dlaczego to ważne

Ten atrybut określa etapy na mapie procesu, dzięki czemu można wizualizować i analizować workflow faktury oraz wykrywać jego nieefektywne elementy.

Skąd pobrać

Informacje te pochodzą z różnych tabel i zmian statusu w Oracle Fusion Financials, na przykład z tabel historii workflow (m.in. dotyczących zatwierdzania) oraz pól statusu transakcji.

Przykłady
Utworzono fakturęZatwierdzono fakturęOtrzymano płatność od klientaZamknięto fakturę
Jednostka biznesowa
BusinessUnit
Jednostka organizacji, która wystawiła fakturę.
Opis

Jednostka biznesowa to część organizacji odpowiedzialna za transakcję. W dużych przedsiębiorstwach jest to ważny element danych wykorzystywany do podziału i raportowania finansowego.

Atrybut ten pozwala porównywać efektywność procesu w różnych częściach firmy. Można na przykład sprawdzić, czy DSO znacznie różni się między jednostkami biznesowymi albo czy w jednej z nich częściej trzeba poprawiać faktury. Dzięki temu działania usprawniające można skierować tam, gdzie są najbardziej potrzebne.

Dlaczego to ważne

Umożliwia porównanie efektywności różnych jednostek organizacyjnych oraz wskazanie dobrych praktyk i obszarów wymagających poprawy.

Skąd pobrać

Dane są dostępne w tabelach transakcji, takich jak RA_CUSTOMER_TRX_ALL, często w polu ORG_ID powiązanym z definicjami jednostek biznesowych.

Przykłady
Konsulting w USAProdukcja w regionie EMEAUsługi w regionie APAC
Kwota faktury
InvoiceAmount
Łączna wartość faktury.
Opis

Ten atrybut określa łączną kwotę do zapłaty z faktury. Jest ważną miarą finansową, która pokazuje wartość środków przepływających przez proces fakturowania.

W analizie kwota faktury służy do ustalania priorytetów dla transakcji o wysokiej wartości, obliczania łącznej wartości nieuregulowanych należności oraz ważenia KPI, takich jak Days Sales Outstanding (DSO). Umożliwia podział procesu według wpływu finansowego, na przykład sprawdzenie, czy faktury o wysokiej wartości przechodzą inną ścieżkę zatwierdzania lub dłużej czekają na płatność.

Dlaczego to ważne

Zapewnia kontekst finansowy dla każdej sprawy. Umożliwia analizę według wartości, ustalanie priorytetów dla faktur o wysokiej wartości i obliczanie finansowych KPI.

Skąd pobrać

Wartość znajduje się w tabeli RA_CUSTOMER_TRX_ALL, prawdopodobnie w polu INVOICE_AMOUNT lub powiązanym polu określającym łączną wartość transakcji.

Przykłady
5000.001250.75250000.00
Nazwa klienta
CustomerName
Nazwa klienta lub podmiotu, na który wystawiono fakturę.
Opis

Ten atrybut wskazuje klienta powiązanego z fakturą. Jest podstawowym wymiarem do filtrowania i dzielenia danych o procesie na segmenty.

Analiza według nazwy klienta pomaga ustalić, którzy klienci najdłużej regulują płatności, najczęściej kwestionują faktury i regularnie płacą w terminie. Ma to znaczenie dla dashboardu „Trend DSO” oraz przy dostosowywaniu działań windykacyjnych do zachowań poszczególnych klientów.

Dlaczego to ważne

Umożliwia analizę procesu według klienta, ujawniając różnice w zachowaniach i terminach płatności oraz potencjalne problemy w relacjach, które wpływają na przepływy pieniężne.

Skąd pobrać

Dane uzyskuje się przez połączenie tabeli transakcji (RA_CUSTOMER_TRX_ALL) z tabelami danych podstawowych klientów, takimi jak HZ_PARTIES.

Przykłady
Global Tech Inc.Innovate Solutions LLCApex Manufacturing
Status faktury
InvoiceStatus
Bieżący status faktury w jej cyklu życia, na przykład „Otwarta”, „Zamknięta” lub „Sporną”.
Opis

Status faktury pokazuje, na jakim etapie procesu znajduje się faktura. Typowe statusy to otwarta (nieopłacona), zamknięta (opłacona), sporna lub unieważniona.

Atrybut ten przydaje się do monitorowania procesu na wysokim poziomie i filtrowania danych. Na przykład dashboard „Prognoza przepływów pieniężnych w czasie rzeczywistym” wykorzystuje status do kategoryzowania nieuregulowanych kwot. Ułatwia szybkie wskazanie faktur przeterminowanych, spornych lub w pełni rozliczonych.

Dlaczego to ważne

Pozwala szybko sprawdzić bieżący stan faktury oraz sprawnie filtrować i kategoryzować dane na potrzeby raportowania finansowego i zarządzania operacyjnego.

Skąd pobrać

Dane pochodzą z pól statusu w tabelach takich jak RA_CUSTOMER_TRX_ALL lub AR_PAYMENT_SCHEDULES_ALL, na przykład z pola STATUS.

Przykłady
OtwartaZamkniętaSpornąOczekiwanie na zatwierdzenie
Termin płatności
DueDate
Data, do której należy opłacić fakturę.
Opis

Termin płatności to atrybut daty określający, do kiedy należy zapłacić fakturę zgodnie z warunkami płatności.

Jest niezbędny do monitorowania należności i kondycji finansowej. Stanowi punkt odniesienia przy obliczaniu KPI „Odsetek płatności w terminie” oraz tworzeniu raportów o przeterminowanych należnościach. W dashboardach służy do prognozowania przepływów pieniężnych na podstawie oczekiwanych terminów płatności i wskazywania faktur wymagających działań windykacyjnych.

Dlaczego to ważne

To podstawowy punkt odniesienia przy ocenie terminowości płatności, obliczaniu DSO i monitorowaniu wieku należności.

Skąd pobrać

Pole DUE_DATE znajduje się zwykle w tabeli AR_PAYMENT_SCHEDULES_ALL.

Przykłady
2023-05-302023-06-152023-07-01
Czas cyklu faktury
InvoiceCycleTime
Łączny czas od utworzenia faktury do jej zamknięcia.
Opis

Ten atrybut mierzy pełny czas trwania cyklu życia pojedynczej faktury. Oblicza się go jako różnicę między pierwszym działaniem, zwykle „Utworzenie faktury”, a ostatnim, czyli „Zamknięcie faktury”.

Miara ta pokazuje ogólną efektywność procesu. Jest podstawą dashboardu „Pełny czas cyklu faktury”. Analiza według różnych wymiarów, takich jak klient lub jednostka biznesowa, pozwala ustalić, które faktury są obsługiwane najdłużej i zbadać przyczyny opóźnień.

Dlaczego to ważne

Zapewnia jedną miarę ogólnego tempa procesu i pomaga szybko wskazać faktury, których obsługa od początku do końca trwa najdłużej.

Skąd pobrać

Jest to miara obliczana jako różnica między maksymalną i minimalną wartością EventTimestamp dla każdego unikalnego InvoiceNumber.

Przykłady
45 dni 8 godzin32 dni 2 godziny90 dni 12 godzin
Czy opłacono w terminie
IsPaidOnTime
Wartość logiczna wskazująca, czy faktura została opłacona w terminie lub przed terminem płatności.
Opis

Ten obliczany atrybut wskazuje, czy płatność była terminowa. Wartość jest ustalana przez porównanie daty działania „Otrzymanie płatności od klienta” z atrybutem „Termin płatności” faktury.

Wskaźnik ten ułatwia analizę i raportowanie KPI „Odsetek płatności w terminie”. Pozwala filtrować i dzielić dane na segmenty, aby sprawdzić, jakie czynniki, takie jak klient, region lub kwota faktury, wiążą się z opóźnieniami. Jest to ważna miara skuteczności działań windykacyjnych.

Dlaczego to ważne

Ułatwia pomiar skuteczności działań windykacyjnych i analizę czynników wpływających na terminowe lub opóźnione płatności.

Skąd pobrać

Wartość oblicza się, porównując znacznik czasu ostatniej płatności z atrybutem DueDate. Reguła: PaymentTimestamp <= DueDate.

Przykłady
truefalse
Czy wymaga ponownej pracy
IsRework
Wartość logiczna wskazująca, czy działanie oznacza ponowną pracę, na przykład powtórne zatwierdzenie lub korektę.
Opis

Ten obliczany atrybut oznacza działania, które wiążą się ze zbędną lub powtarzaną pracą. Przykładem jest odrzucenie faktury, a następnie ponowne przekazanie jej do zatwierdzenia albo wprowadzenie korekty po jej utworzeniu.

Oznaczenie ponownej pracy ułatwia określenie jej wpływu na proces. KPI „Odsetek faktur wymagających poprawek” jest obliczany bezpośrednio na podstawie tego atrybutu. Dashboardy mogą pokazywać częstotliwość poprawek i dodatkowy czas cyklu, który powodują, co pomaga wskazać źródła nieefektywności i błędów.

Dlaczego to ważne

Bezpośrednio mierzy nieefektywność procesu, oznaczając zbędną lub powtarzaną pracę. Ułatwia określenie kosztów i czasu traconych z powodu problemów z jakością.

Skąd pobrać

Wartość jest obliczana podczas przekształcania danych na podstawie sekwencji działań. Na przykład jeśli działanie „Zatwierdzenie faktury” następuje po „Odrzuceniu faktury” w tej samej sprawie, jest oznaczane jako ponowna praca.

Przykłady
truefalse
Data faktury
InvoiceDate
Oficjalna data wystawienia faktury.
Opis

Data faktury, nazywana również datą transakcji, to data widniejąca na dokumencie. Od niej rozpoczyna się obliczanie terminu płatności.

Jest niezbędna do obliczania Days Sales Outstanding (DSO), czyli czasu od daty faktury do daty płatności. Różni się od daty utworzenia faktury w systemie i wyznacza oficjalny początek cyklu płatności z perspektywy klienta.

Dlaczego to ważne

Wyznacza oficjalny początek cyklu życia faktury i stanowi punkt odniesienia przy obliczaniu KPI Days Sales Outstanding (DSO).

Skąd pobrać

Pole TRX_DATE znajduje się w tabeli RA_CUSTOMER_TRX_ALL.

Przykłady
2023-04-142023-05-182023-06-25
Days Sales Outstanding
DaysSalesOutstanding
Liczba dni między datą faktury a datą otrzymania płatności.
Opis

Days Sales Outstanding (DSO) to miara finansowa określająca średni czas oczekiwania na płatność od momentu wystawienia faktury. Ten atrybut oblicza DSO dla każdej faktury osobno.

Łączny DSO jest ważnym KPI, ale obliczenie go dla poszczególnych faktur pozwala przeprowadzić bardziej szczegółową analizę. Można na tej podstawie tworzyć dashboardy trendów, wskazywać cechy faktur o wysokim DSO i mierzyć finansowy wpływ opóźnień w procesie. Tak szczegółowe dane pomagają ustalić, co wpływa na łączny KPI DSO.

Dlaczego to ważne

Oblicza ważną miarę przepływów pieniężnych dla każdej faktury, umożliwiając szczegółową analizę czynników wpływających na czas uzyskania płatności i wyniki finansowe.

Skąd pobrać

Wartość oblicza się jako różnicę między znacznikiem czasu działania „Otrzymanie płatności od klienta” a atrybutem „Data faktury”.

Przykłady
356228
Dział fakturowania
BillingDepartment
Wewnętrzny dział lub zespół odpowiedzialny za wystawianie faktur i zarządzanie nimi.
Opis

Ten atrybut wskazuje konkretny zespół lub dział organizacji, który obsługiwał proces fakturowania. Zapewnia dodatkowy kontekst organizacyjny do analizy.

Podział procesu według działu fakturowania pozwala porównać efektywność i dokładność pracy różnych zespołów. Pomaga wskazać działy, w których częściej trzeba poprawiać faktury, cykle zatwierdzania trwają dłużej lub DSO jest wyższe. Dzięki temu można zaplanować szkolenia lub ujednolicić proces.

Dlaczego to ważne

Umożliwia porównanie efektywności zespołów wewnętrznych oraz wskazanie dobrych praktyk, potrzeb kadrowych i obszarów wymagających usprawnienia procesu.

Skąd pobrać

Informacje te można uzyskać na podstawie użytkownika, który utworzył fakturę, łącząc jego konto z przypisanym działem w systemie HR, na przykład przez PER_ALL_ASSIGNMENTS_F.

Przykłady
Fakturowanie korporacyjneZespół ds. fakturowania usługFakturowanie sprzedaży produktów
Godzina zakończenia
EventEndTime
Dokładna data i godzina zakończenia danego działania lub zdarzenia.
Opis

Godzina zakończenia zdarzenia wskazuje moment, w którym działanie dobiegło końca. Wiele zdarzeń jest natychmiastowych, ale niektóre, takie jak „Zatwierdzanie faktury”, trwają określony czas: od przekazania faktury do momentu podjęcia decyzji.

Godzina zakończenia pozwala dokładnie obliczyć czas przetwarzania działania. Dzięki temu można sprawdzić, ile czasu użytkownicy poświęcają na konkretne zadania. Zwiększa też dokładność analizy wąskich gardeł, ponieważ pozwala odróżnić czas oczekiwania od faktycznej pracy.

Dlaczego to ważne

Pozwala dokładnie obliczyć czas przetwarzania działań i odróżnić czas aktywnej pracy od oczekiwania. Jest to niezbędne przy szczegółowej analizie wąskich gardeł.

Skąd pobrać

Często jest wyznaczana na podstawie godziny rozpoczęcia kolejnego działania w procesie. Dla niektórych działań dedykowane pole godziny zakończenia może być dostępne w dziennikach workflow.

Przykłady
2023-04-15T09:05:12Z2023-04-18T15:00:00Z2023-05-20T11:25:45Z
Metoda płatności
PaymentMethod
Sposób, w jaki klient dokonał płatności, na przykład przelewem bankowym lub kartą kredytową.
Opis

Ten atrybut określa, w jaki sposób klient opłacił fakturę. Informacja ta może pomóc w analizie trendów i kosztów płatności.

Poszczególne metody płatności mogą różnić się czasem przetwarzania i kosztami transakcji. Analiza według metody płatności pomaga sprawdzić, czy niektóre sposoby częściej powodują błędy uzgodnień lub opóźnienia. Może też pomóc zachęcić klientów do korzystania z wydajniejszych kanałów płatności.

Dlaczego to ważne

Pomaga analizować sprawność obsługi płatności, koszty transakcji i liczbę błędów uzgodnień dla różnych kanałów płatności.

Skąd pobrać

Dane znajdują się w tabelach potwierdzeń wpływu środków, takich jak AR_CASH_RECEIPTS_ALL, które zawierają pole określające metodę płatności.

Przykłady
ACHPrzelew bankowyKarta kredytowaCzek
Ostatnia aktualizacja danych
LastDataUpdate
Znacznik czasu wskazujący, kiedy ostatnio odświeżono dane o tym zdarzeniu lub pobrano je z systemu źródłowego.
Opis

Ten atrybut zawiera znacznik czasu ostatniego pobrania danych. Jest to pole metadanych, które pozwala ocenić aktualność analizowanych danych.

Analitycy sprawdzają tę informację, aby upewnić się, że pracują na aktualnych danych i wiedzieć, kiedy zostały one pobrane. Ma to szczególne znaczenie w przypadku dashboardów określanych jako działające „w czasie rzeczywistym” lub niemal w czasie rzeczywistym, ponieważ pokazuje ewentualne opóźnienie w dostępie do danych.

Dlaczego to ważne

Informuje użytkowników o aktualności danych, dzięki czemu analizy i wnioski można oprzeć na informacjach o znanym i akceptowalnym stopniu aktualności.

Skąd pobrać

To pole metadanych jest generowane podczas pobierania, przekształcania i ładowania danych (ETL). Zwykle odpowiada godzinie uruchomienia potoku danych.

Przykłady
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Powód sporu
DisputeReason
Powód, dla którego klient zakwestionował fakturę.
Opis

Gdy klient kwestionuje fakturę, rejestrowany jest powód sporu. Może on dotyczyć ceny, ilości, jakości usługi lub innych kwestii.

Analiza powodów sporów pomaga ustalić ich źródło. Wiedza o najczęstszych przyczynach pozwala firmie rozwiązywać problemy związane z cenami, realizacją zamówień lub jakością danych. Może to skrócić średni czas rozstrzygania sporów dotyczących faktur i poprawić zadowolenie klientów.

Dlaczego to ważne

Ujawnia bezpośrednie przyczyny opóźnień w płatnościach i niezadowolenia klientów, dzięki czemu firma może rozwiązywać problemy systemowe.

Skąd pobrać

Informacje te mogą być przechowywane w Oracle Collections lub powiązanym module zarządzania sporami. Mogą znajdować się w osobnej tabeli sporów albo w polu kodu przyczyny w samej transakcji.

Przykłady
Nieprawidłowa cenaNiezgodna ilośćUszkodzony towarZduplikowana faktura
Region
Region
Region geograficzny powiązany z klientem lub transakcją.
Opis

Region określa geograficzny kontekst faktury, zwykle na podstawie lokalizacji klienta. Umożliwia analizę przestrzenną efektywności procesu.

Analiza według regionu może ujawnić różnice wynikające z lokalnych przepisów, warunków rynkowych lub pracy zespołów regionalnych. Dashboardy, takie jak „Trend DSO” i „Pełny czas cyklu faktury”, można podzielić według regionu, aby sprawdzić, czy w niektórych obszarach występują szczególne trudności z uzyskaniem płatności.

Dlaczego to ważne

Umożliwia podział procesu według regionu, co pomaga wykrywać różnice w efektywności, zachowaniach klientów i zgodności z przepisami.

Skąd pobrać

Dane pochodzą zwykle z adresu klienta zapisanego w TCA (HZ_LOCATIONS, HZ_PARTY_SITES). Nie jest to bezpośrednie pole na fakturze.

Przykłady
Ameryka PółnocnaEuropaAzja i Pacyfik
System źródłowy
SourceSystem
System ewidencyjny, z którego pobrano dane o zdarzeniach.
Opis

Ten atrybut wskazuje aplikację źródłową, z której pochodzą dane. W przypadku tego procesu będzie to zwykle Oracle Fusion Financials, ale można też wskazać konkretny moduł, na przykład Oracle Receivables (AR).

W środowiskach z wieloma zintegrowanymi systemami pole to pomaga rozróżniać źródła danych i ma istotne znaczenie dla ich walidacji oraz nadzoru. Pozwala upewnić się, że analiza obejmuje właściwy, zamierzony zbiór danych.

Dlaczego to ważne

Wskazuje źródło danych, co ma znaczenie dla nadzoru nad danymi, rozwiązywania problemów i potwierdzenia, że analiza opiera się na właściwym systemie ewidencyjnym.

Skąd pobrać

Zwykle jest to stała wartość („Oracle Fusion Financials”) dodawana podczas pobierania i przekształcania danych.

Przykłady
Oracle Fusion FinancialsOracle AR CloudFusion Apps
Użytkownik
User
Pracownik lub użytkownik systemu, który wykonał dane działanie.
Opis

Atrybut „Użytkownik” wskazuje osobę lub agenta automatycznego odpowiedzialnego za wykonanie danego etapu procesu. Może to być osoba, która utworzyła fakturę, kierownik, który ją zatwierdził, albo pracownik windykacji, który wysłał przypomnienie.

Analiza według użytkownika pomaga wskazać potrzeby szkoleniowe, rozkład obciążenia pracą i różnice w efektywności między osobami lub zespołami. Może ujawnić, czy określeni użytkownicy popełniają więcej błędów albo czy konkretni zatwierdzający regularnie tworzą wąskie gardła.

Dlaczego to ważne

Wskazuje odpowiedzialność za poszczególne etapy procesu i umożliwia analizę efektywności użytkowników, równoważenie obciążenia pracą oraz określenie potrzeb szkoleniowych.

Skąd pobrać

Dane pochodzą z pól identyfikatora użytkownika, takich jak CREATED_BY lub LAST_UPDATED_BY, w różnych tabelach transakcji i workflow. Następnie identyfikator jest łączony z tabelami katalogu użytkowników, na przykład PER_ALL_PEOPLE_F, aby pobrać nazwisko użytkownika.

Przykłady
john.smithjane.doeCollectionsBot
Warunki płatności
PaymentTerms
Uzgodnione zasady płatności za fakturę, na przykład „Net 30” lub „2% 10, Net 30”.
Opis

Warunki płatności określają zasady i terminy opłacania faktury, w tym ewentualne rabaty za wcześniejszą płatność. Informacje te są niezbędne do zarządzania należnościami i przepływami pieniężnymi.

Atrybut ten pozwala prawidłowo obliczyć termin płatności i wskazać możliwość skorzystania z rabatu za wcześniejszą zapłatę. KPI „Wykorzystanie rabatów za wcześniejszą płatność” zależy bezpośrednio od tych danych, ponieważ na ich podstawie określa się, które faktury kwalifikowały się do rabatu.

Dlaczego to ważne

Określa zasady płatności za fakturę, wpływa bezpośrednio na obliczanie terminu płatności i pozwala monitorować wykorzystanie rabatów za wcześniejszą zapłatę.

Skąd pobrać

Dane znajdują się w tabeli RA_TERMS i są powiązane z transakcją przez term_id w tabeli RA_CUSTOMER_TRX_ALL.

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

Działania w procesie Order to Cash - fakturowanie i wystawianie faktur

To najważniejsze kroki procesu i punkty kontrolne, które warto uwzględnić w dzienniku zdarzeń, aby dokładnie odtworzyć przebieg procesu.
6 Zalecane 7 Opcjonalne
Działanie Opis
Otrzymano płatność od klienta
Płatność od klienta została wprowadzona do systemu jako wpływ gotówkowy. Na tym etapie może jeszcze nie być przypisana do konkretnej faktury.
Dlaczego to ważne

To ważny etap oznaczający wpływ środków. Czas między otrzymaniem płatności a przypisaniem jej do faktury wskazuje na sprawność zarządzania gotówką.

Skąd pobrać

Zdarzenie jest rejestrowane przy utworzeniu rekordu w tabeli AR_CASH_RECEIPTS_ALL. Pole receipt_date wskazuje datę przetworzenia płatności.

Rejestrowanie

Użyj wartości creation_date lub receipt_date z tabeli AR_CASH_RECEIPTS_ALL.

Typ zdarzenia explicit
Przypisano płatność do faktury
Otrzymana płatność od klienta została prawidłowo dopasowana do konkretnej faktury i zmniejszyła jej saldo. Jest to odrębny rekord transakcji.
Dlaczego to ważne

To działanie potwierdza prawidłowe przypisanie środków, niezbędne do sporządzania dokładnych raportów o zaległościach i sprawozdań finansowych. Na tym etapie wpływ zostaje rozliczony z należnością.

Skąd pobrać

Zdarzenie jest rejestrowane w tabeli AR_RECEIVABLE_APPLICATIONS_ALL. Pola apply_date i gl_date wskazują, kiedy nastąpiło przypisanie płatności.

Rejestrowanie

Użyj wartości apply_date z tabeli AR_RECEIVABLE_APPLICATIONS_ALL, która łączy wpływ gotówkowy z fakturą.

Typ zdarzenia explicit
Utworzono fakturę
Pierwsze utworzenie transakcji faktury w systemie, zwykle ze statusem roboczym lub niekompletnym. Zdarzenie jest rejestrowane, gdy użytkownik po raz pierwszy zapisuje nowy rekord faktury w module Accounts Receivable.
Dlaczego to ważne

To zdarzenie wyznacza początek procesu fakturowania. Analiza czasu od utworzenia do zakończenia pozwala wykryć opóźnienia przy wprowadzaniu danych lub problemy z wydajnością systemu.

Skąd pobrać

Zdarzenie można odczytać z daty utworzenia transakcji w tabeli RA_CUSTOMER_TRX_ALL. Początkowy status to często „Incomplete”.

Rejestrowanie

Użyj wartości creation_date z tabeli RA_CUSTOMER_TRX_ALL dla danego numeru faktury.

Typ zdarzenia explicit
Wysłano fakturę do klienta
Faktura została dostarczona klientowi wybraną przez niego metodą, na przykład e-mailem lub pocztą. System często zapisuje znacznik czasu wykonania tej czynności.
Dlaczego to ważne

To działanie rozpoczyna bieg terminu płatności. Pomiar czasu od akceptacji do dostarczenia faktury pozwala ocenić sprawność jej dystrybucji.

Skąd pobrać

Zdarzenie można ustalić na podstawie pola „last_printed_date” w tabeli RA_CUSTOMER_TRX_ALL lub dzienników Oracle Business Intelligence Publisher, jeśli faktura jest dostarczana elektronicznie.

Rejestrowanie

Użyj znacznika czasu z dziennika dostarczenia lub wydruku powiązanego z fakturą.

Typ zdarzenia inferred
Zamknięto fakturę
Faktura została w pełni opłacona i rozliczona, a jej cykl życia dobiegł końca. Zdarzenie to jest zwykle wnioskowane na podstawie wyzerowania salda pozostałego do zapłaty i aktualizacji statusu faktury.
Dlaczego to ważne

To końcowe rozliczenie faktury, które oznacza zakończenie procesu. Łączny czas do osiągnięcia tego stanu to pełny czas cyklu, jeden z podstawowych KPI procesu fakturowania.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie tabeli AR_PAYMENT_SCHEDULES_ALL, gdy status zmienia się na 'CLOSED', a wartość pola amount_due_remaining wynosi zero. Pole 'gl_date_closed' wskazuje datę zamknięcia.

Rejestrowanie

Dla danej faktury należy użyć wartości gl_date_closed z tabeli AR_PAYMENT_SCHEDULES_ALL.

Typ zdarzenia inferred
Zatwierdzono fakturę
Faktura uzyskała wszystkie wymagane akceptacje i jest gotowa do wysłania klientowi. Zdarzenie jest rejestrowane po pomyślnym zakończeniu workflow akceptacji i aktualizacji statusu faktury.
Dlaczego to ważne

To ważny etap, od którego zależy dostarczenie faktury klientowi. Opóźnienia bezpośrednio wpływają na moment rozpoczęcia biegu terminu płatności, a tym samym na wskaźnik Days Sales Outstanding (DSO).

Skąd pobrać

Zdarzenie można ustalić na podstawie końcowej aktualizacji statusu faktury lub znacznika czasu zakończenia powiązanego zadania workflow BPM.

Rejestrowanie

Zapisz znacznik czasu zmiany statusu akceptacji faktury na „Approved”.

Typ zdarzenia inferred
Nadszedł termin płatności
Minął umowny termin płatności faktury. Nie jest to zdarzenie transakcyjne, lecz wartość obliczana na podstawie warunków płatności faktury i bieżącej daty.
Dlaczego to ważne

To obliczane zdarzenie ma podstawowe znaczenie dla analizy zaległości i obliczania DSO. Pozwala odróżnić faktury opłacone w terminie od przeterminowanych i odpowiednio ukierunkować działania windykacyjne.

Skąd pobrać

To zdarzenie jest obliczane. Występuje, gdy bieżąca data jest późniejsza niż wartość pola due_date w tabeli AR_PAYMENT_SCHEDULES_ALL dla danej faktury.

Rejestrowanie

Obliczane przez porównanie bieżącej daty z wartością pola due_date w tabeli AR_PAYMENT_SCHEDULES_ALL.

Typ zdarzenia calculated
Odrzucono fakturę
Osoba zatwierdzająca odrzuciła fakturę, zwykle z powodu błędów w danych, takich jak ceny lub ilości. Faktura wraca wtedy do poprawy, co powoduje konieczność ponownej pracy.
Dlaczego to ważne

Śledzenie odrzuceń pozwala wykryć problemy z poprawnością faktur i kontrolami wewnętrznymi. Analiza częstotliwości i przyczyn odrzuceń pomaga wskazać obszary wymagające usprawnienia procesu lub szkoleń.

Skąd pobrać

Zdarzenie można ustalić na podstawie aktualizacji statusu transakcji faktury lub wyniku „Rejected” w zadaniu workflow BPM.

Rejestrowanie

Zapisz znacznik czasu zmiany statusu akceptacji faktury na „Rejected”.

Typ zdarzenia inferred
Przekazano fakturę do akceptacji
Faktura zostaje formalnie przekazana do workflow akceptacji, jeśli taki workflow skonfigurowano. Zdarzenie jest rejestrowane, gdy status faktury zmienia się na oczekujący na akceptację, co uruchamia powiadomienia dla wyznaczonych osób zatwierdzających.
Dlaczego to ważne

To początek cyklu akceptacji. Śledzenie tego działania jest niezbędne do pomiaru i analizy czasu akceptacji, który wpływa na całkowity czas obsługi faktury.

Skąd pobrać

Zdarzenie można ustalić na podstawie zmiany statusu transakcji faktury lub odczytać z tabel workflow Oracle Business Process Management (BPM), które rejestrują rozpoczęcie zadania akceptacji.

Rejestrowanie

Ustal znacznik czasu zmiany statusu akceptacji faktury na „Pending” lub podobny.

Typ zdarzenia inferred
Rozpoczęto postępowanie reklamacyjne
Klient formalnie zakwestionował fakturę, a w systemie utworzono sprawę reklamacyjną. Zdarzenie jest zwykle rejestrowane przez zmianę statusu harmonogramu płatności faktury.
Dlaczego to ważne

Reklamacja wstrzymuje proces płatności i wymaga ręcznej obsługi. Analiza częstotliwości reklamacji i czasu ich rozpatrywania pomaga ustalić przyczyny, takie jak błędy cenowe lub problemy z dostawą.

Skąd pobrać

Zdarzenie można ustalić, gdy pole statusu w tabeli AR_PAYMENT_SCHEDULES_ALL przyjmuje status reklamacji, lub na podstawie rekordów utworzenia w tabeli AR_DISPUTE_HISTORY.

Rejestrowanie

Ustal, kiedy dla harmonogramu płatności faktury aktywowano znacznik lub status reklamacji.

Typ zdarzenia inferred
Skorygowano fakturę
Wprowadzono zmianę kwoty faktury, na przykład odpisanie należności lub korektę kredytową. Jest to jawna transakcja zmieniająca saldo faktury.
Dlaczego to ważne

Korekty często wynikają z reklamacji, ustępstw lub konieczności poprawienia danych. Analiza ich częstotliwości i wartości może ujawnić problemy w procesie order-to-cash.

Skąd pobrać

Zdarzenie jest rejestrowane w tabeli AR_ADJUSTMENTS_ALL. Datę zdarzenia wyznacza wartość creation_date rekordu korekty.

Rejestrowanie

Użyj wartości creation_date z tabeli AR_ADJUSTMENTS_ALL dla danej faktury.

Typ zdarzenia explicit
Wysłano przypomnienie o płatności
Do klienta wysłano wezwanie do zapłaty lub przypomnienie dotyczące przeterminowanej faktury. Moduł windykacyjny rejestruje tę czynność.
Dlaczego to ważne

Śledzenie przypomnień pozwala ocenić skuteczność windykacji i sprawdzić, które strategie prowadzą do szybszych płatności.

Skąd pobrać

Zdarzenie jest rejestrowane w module Oracle Advanced Collections. Tabele historii wezwań do zapłaty, takie jak IEX_DUNNINGS, zapisują datę i poziom wysłanego przypomnienia.

Rejestrowanie

Odczytaj dane z tabel historii wezwań do zapłaty i powiąż transakcję windykacyjną z fakturą.

Typ zdarzenia explicit
Zakończono fakturę
Oznacza zakończenie wprowadzania danych faktury i gotowość transakcji do weryfikacji oraz księgowania. Zdarzenie można zwykle wykryć, gdy status faktury zmienia się z „Incomplete” na „Complete”.
Dlaczego to ważne

Ten etap oznacza koniec wprowadzania danych. Czas między utworzeniem a zakończeniem faktury może wskazywać, jak sprawnie dział obsługi faktur wprowadza i weryfikuje dane.

Skąd pobrać

Zdarzenie można ustalić na podstawie zmiany statusu transakcji faktury w tabeli RA_CUSTOMER_TRX_ALL. Należy znaleźć znacznik czasu aktualizacji statusu na „Complete”.

Rejestrowanie

Śledź historię statusów transakcji w tabeli RA_CUSTOMER_TRX_ALL lub powiązanych tabelach workflow.

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje ekstrakcji danych

Jak pobrać dane z Oracle Fusion Financials

Gotowi do rozpoczęcia?

Wykorzystaj ten szablon do przygotowania danych, usprawnienia procesu Order to Cash - fakturowanie i wystawianie faktur oraz skrócenia czasu konwersji należności na gotówkę. Już teraz sprawdź dane i popraw efektywność operacji w Oracle Fusion Financials.

Zacznij optymalizować fakturowanie w Oracle

Skróć cykl fakturowania o 30% i popraw przepływy pieniężne dzięki naszemu rozwiązaniu.

Rozpocznij okres próbny

Nie trzeba podawać danych karty płatniczej. Konfiguracja zajmuje kilka minut.