Szablon danych dla procesu Order to Cash, obsługi zamówień sprzedaży

Oracle Fusion Financials
Szablon danych dla procesu Order to Cash, obsługi zamówień sprzedaży

Szablon danych dla procesu Order to Cash, obsługi zamówień sprzedaży

Ten szablon pomaga zebrać dane potrzebne do analizy procesu Order to Cash, czyli obsługi zamówień sprzedaży. Zawiera listę atrybutów do uwzględnienia i najważniejszych aktywności do śledzenia, aby uzyskać pełny obraz procesu. Znajdą w nim Państwo również praktyczne wskazówki dotyczące pobierania danych z systemu źródłowego, które ułatwią rozpoczęcie pracy.
  • Zalecane atrybuty do zebrania
  • Najważniejsze aktywności do śledzenia
  • Praktyczne wskazówki dotyczące pobierania danych
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty procesu Order to Cash, obsługi zamówień sprzedaży

Poniżej przedstawiono zalecane pola danych do uwzględnienia w dzienniku zdarzeń, aby przeprowadzić analizę procesu Order to Cash, obsługi zamówień sprzedaży.
3 Wymagane 8 Zalecane 12 Opcjonalne
Nazwa Opis
Zamówienie sprzedaży
SalesOrder
Unikatowy identyfikator zamówienia sprzedaży, który pełni funkcję głównego case w procesie od zamówienia do otrzymania płatności.
Opis

Numer zamówienia sprzedaży jednoznacznie identyfikuje każde zamówienie klienta przez cały cykl jego obsługi. Łączy wszystkie powiązane zdarzenia, od utworzenia i potwierdzenia zamówienia po jego realizację, fakturowanie i otrzymanie płatności.

W process mining ten atrybut służy do grupowania powiązanych zdarzeń w jeden case. Analiza według numeru zamówienia sprzedaży daje pełny obraz procesu od początku do końca. Umożliwia obliczanie całkowitego czasu cyklu, identyfikowanie wariantów procesu dla poszczególnych zamówień i śledzenie ich obsługi w różnych działach i systemach.

Dlaczego to ważne

To identyfikator case. Łączy wszystkie zdarzenia procesu, dzięki czemu można prześledzić obsługę pojedynczego zamówienia klienta od początku do końca.

Skąd pobrać

Ten identyfikator znajduje się zwykle w tabeli nagłówków zamówień sprzedaży w Oracle Fusion, na przykład DOO_HEADERS_ALL. Więcej informacji można znaleźć w dokumentacji Oracle Fusion Financials.

Przykłady
SO-100567SO-100568SO-100569
Czas zdarzenia
EventTime
Znacznik czasu określający, kiedy wystąpiło konkretne działanie lub zdarzenie związane z zamówieniem sprzedaży.
Opis

Ten atrybut zawiera datę i godzinę każdego działania w procesie, dzięki czemu można ustalić chronologiczną kolejność zdarzeń. Stanowi podstawę czasowej analizy procesu i wskazuje dokładnie, kiedy wykonano każdy krok.

W process mining atrybut EventTime jest niezbędny do obliczania czasu cyklu, czasu między działaniami i całkowitego czasu obsługi case. Umożliwia analizę wydajności, wykrywanie wąskich gardeł na podstawie czasu oczekiwania oraz monitorowanie zgodności z umowami SLA dotyczącymi terminowości. Dokładność tego atrybutu wpływa na wszystkie KPI i dashboardy oparte na czasie.

Dlaczego to ważne

Ten znacznik czasu jest niezbędny do chronologicznego uporządkowania zdarzeń i obliczania wszystkich miar czasu, takich jak czas cyklu i czas trwania.

Skąd pobrać

To atrybut pochodny, pobierany z różnych pól znaczników czasu w tabelach Oracle Fusion, takich jak data utworzenia zamówienia, wysyłki, faktury i płatności.

Przykłady
2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z
Nazwa działania
ActivityName
Nazwa konkretnego zdarzenia biznesowego lub zadania, które wystąpiło w procesie obsługi zamówienia sprzedaży.
Opis

Ten atrybut opisuje krok wykonany w określonym momencie obsługi zamówienia sprzedaży, na przykład „Utworzono zamówienie sprzedaży”, „Wysłano towary” lub „Otrzymano płatność”. Kolejność działań tworzy przebieg procesu dla każdego case.

Analiza atrybutu ActivityName jest podstawą process mining. Umożliwia wizualizację mapy procesu, odkrywanie różnych wariantów procesu i wykrywanie wąskich gardeł, w których gromadzą się case. Pozwala obliczać czas między kolejnymi krokami i zrozumieć przebieg operacyjny procesu od zamówienia do otrzymania płatności.

Dlaczego to ważne

Ten atrybut określa kroki na mapie procesu i umożliwia wizualizację oraz analizę jego przebiegu.

Skąd pobrać

To atrybut pochodny. Powstaje przez przypisanie statusów transakcji lub typów zdarzeń z różnych tabel Oracle Fusion, na przykład statusu zamówienia, wysyłki lub faktury, do ustandaryzowanej listy nazw działań.

Przykłady
Utworzenie zamówienia sprzedażyWysłanie towarówUtworzenie fakturyOtrzymano płatność
Czy zautomatyzowano
IsAutomated
Wskaźnik określający, czy działanie wykonał automatycznie system, czy ręcznie użytkownik.
Opis

Ten atrybut logiczny odróżnia zdarzenia wywołane przez system, na przykład automatyczną kontrolę kredytową lub fakturę wygenerowaną przez system, od działań użytkownika. Zwykle ustala się go na podstawie nazwy użytkownika przypisanej do działania. Ogólny identyfikator systemowy oznacza automatyzację.

Analiza tego atrybutu pozwala zmierzyć poziom automatyzacji procesu i stanowi bezpośrednią podstawę KPI „Odsetek zamówień wymagających ręcznych poprawek”. Może wskazać możliwości dalszej automatyzacji, pokazując, które ręczne kroki zajmują najwięcej czasu lub najczęściej prowadzą do błędów.

Dlaczego to ważne

Pomaga zmierzyć poziom automatyzacji procesu i wskazać możliwości ograniczenia kosztownych działań ręcznych.

Skąd pobrać

To pole pochodne, zwykle wyznaczane na podstawie reguły dotyczącej atrybutu UserName. Na przykład jeśli użytkownikiem jest „SYSTEM” lub „BATCH”, temu polu przypisuje się wartość true.

Przykłady
truefalse
Kanał sprzedaży
SalesChannel
Kanał, którym wpłynęło zamówienie sprzedaży.
Opis

Ten atrybut określa źródło zamówienia sprzedaży, na przykład „Sprzedaż internetowa”, „Sprzedaż bezpośrednia”, „Partner” lub „EDI”. Informuje, w jaki sposób zamówienie trafiło do organizacji.

Podział procesu według kanału sprzedaży jest ważny dla dashboardu „Przegląd wyników kanałów sprzedaży”. Ułatwia porównanie wydajności, czasu cyklu i liczby błędów w poszczególnych kanałach oraz wskazanie tych, które działają najskuteczniej lub wymagają ulepszenia procesów albo dalszej automatyzacji.

Dlaczego to ważne

Umożliwia analizę wyników według kanału i wskazanie kanałów, w których obsługa zamówień jest najbardziej i najmniej wydajna.

Skąd pobrać

Informacja może być przechowywana w osobnym polu nagłówka zamówienia sprzedaży. Więcej informacji można znaleźć w dokumentacji Oracle Fusion Financials.

Przykłady
Sprzedaż bezpośredniaPortal internetowyEDISprzedawca
Łączna wartość zamówienia sprzedaży
SalesOrderTotalAmount
Łączna wartość pieniężna zamówienia sprzedaży.
Opis

Ten atrybut określa łączną kwotę należną od klienta za całe zamówienie sprzedaży. Obejmuje sumę wszystkich pozycji, podatków i innych opłat przed uwzględnieniem rabatów.

W analizie procesu atrybut ten umożliwia process mining według wartości zamówienia. Pozwala podzielić zamówienia na grupy, na przykład o wysokiej i niskiej wartości, i sprawdzić, czy przebiegają innymi ścieżkami lub mają różny czas cyklu. Pomaga też ustalać priorytety ulepszania procesów, koncentrując się na przypadkach o największym znaczeniu finansowym.

Dlaczego to ważne

Umożliwia analizę wpływu finansowego, ustalanie priorytetów ulepszania procesów dla zamówień o wysokiej wartości i rozpoznawanie czynników kosztowych.

Skąd pobrać

Dane znajdują się zwykle w tabelach nagłówków zamówień sprzedaży w Oracle Fusion. Więcej informacji można znaleźć w dokumentacji Oracle Fusion Financials.

Przykłady
5250.00125000.75980.50
Nazwa klienta
CustomerName
Nazwa klienta, który złożył zamówienie sprzedaży.
Opis

Ten atrybut wskazuje nazwę prawną klienta powiązanego z zamówieniem sprzedaży. Umożliwia analizę procesu z perspektywy klienta i podział danych na grupy.

Analiza według klienta pomaga ustalić, czy obsługa zamówień niektórych klientów trwa dłużej, wymaga częstszych poprawek lub odbiega od standardowego przebiegu. Te informacje można wykorzystać do poprawy obsługi klienta, dostosowania procesów do potrzeb najważniejszych klientów i zbadania problemów wpływających na ich zadowolenie.

Dlaczego to ważne

Umożliwia analizę procesu z perspektywy klienta, wykrywanie problemów dotyczących konkretnych klientów i poprawę ich zadowolenia.

Skąd pobrać

Dane pochodzą z tabel głównych danych klientów, na przykład HZ_PARTIES, i są łączone z zamówieniem sprzedaży za pomocą identyfikatora klienta.

Przykłady
Global Corp Inc.Innovate Solutions Ltd.Tech Services LLC
Nazwa użytkownika
UserName
Nazwa lub identyfikator użytkownika, który wykonał działanie.
Opis

Ten atrybut wskazuje pracownika lub użytkownika systemu odpowiedzialnego za wykonanie konkretnego kroku procesu. Można go wykorzystać do analizy wydajności poszczególnych użytkowników, rozkładu obciążenia pracą i przestrzegania standardowych procedur.

Analiza według użytkownika pomaga rozpoznać potrzeby szkoleniowe, wskazać osoby lub zespoły osiągające dobre wyniki oraz zbadać odstępstwa związane z działaniami konkretnych użytkowników. Atrybut jest również przydatny przy kontroli zgodności i audycie, ponieważ pozwala ustalić, kto wykonał poszczególne działania.

Dlaczego to ważne

Umożliwia analizę wydajności użytkowników i rozkładu obciążenia pracą oraz wykrywanie powtarzających się ręcznych poprawek związanych z konkretnymi osobami.

Skąd pobrać

Dane pochodzą zwykle z pól takich jak CREATED_BY lub LAST_UPDATED_BY w tabelach transakcyjnych Oracle Fusion. Pola te są często powiązane z tabelą użytkowników, na przykład FND_USER.

Przykłady
john.smithjane.doesystem_batch_user
Oczekiwana data dostawy
RequestedDeliveryDate
Data dostawy zamówienia wskazana przez klienta.
Opis

Ten atrybut zawiera datę, w której klient chce otrzymać towary. Jest to ważny cel do pomiaru realizacji zamówienia w procesie od zamówienia do otrzymania płatności.

Data ta jest niezbędna do obliczania KPI „Odsetek dostaw na czas” i obsługi dashboardu „Poziom usług dostawy (SLA)”. Porównanie jej z atrybutem ActualDeliveryDate pozwala ocenić, czy organizacja spełnia oczekiwania klientów, i ustalić przyczyny opóźnień.

Dlaczego to ważne

Stanowi punkt odniesienia przy pomiarze terminowości dostaw i zgodności z umową SLA dotyczącą poziomu obsługi klienta.

Skąd pobrać

Dane znajdują się zwykle w tabelach pozycji zamówień sprzedaży w Oracle Fusion. Więcej informacji można znaleźć w dokumentacji Oracle Fusion Financials.

Przykłady
2023-05-202023-06-012023-05-25
Rzeczywista data dostawy
ActualDeliveryDate
Data faktycznego dostarczenia towarów klientowi.
Opis

Ten atrybut zapisuje końcową datę dostawy, która oznacza zakończenie realizacji zamówienia. Jest to rzeczywisty wynik, z którym porównuje się daty planowane lub wskazane przez klienta.

Porównanie tej daty z RequestedDeliveryDate pozwala obliczyć terminowość dostaw. Atrybut jest niezbędny do obliczania KPI „Odsetek dostaw na czas” i obsługi dashboardu „SLA dostaw”. Umożliwia ocenę skuteczności logistyki i łańcucha dostaw.

Dlaczego to ważne

To rzeczywista data dostawy, używana do obliczania terminowości i oceny realizacji zamówienia względem oczekiwań klienta.

Skąd pobrać

Dane pochodzą z tabel transakcyjnych dotyczących wysyłki i dostawy w Oracle Fusion. Więcej informacji można znaleźć w dokumentacji Oracle Fusion Financials.

Przykłady
2023-05-202023-06-032023-05-25
Termin płatności
PaymentDueDate
Data, do której klient powinien opłacić fakturę.
Opis

Termin płatności oblicza się na podstawie daty faktury i warunków płatności uzgodnionych z klientem. Wyznacza on datę, do której należy otrzymać płatność.

Atrybut ten jest niezbędny do obliczania KPI „Odsetek płatności otrzymanych w terminie”. Porównanie PaymentDueDate z datą faktycznego otrzymania płatności pozwala ustalić, czy płatność wpłynęła na czas. Ułatwia to monitorowanie należności i zarządzanie przepływami pieniężnymi.

Dlaczego to ważne

Wyznacza termin używany do obliczania odsetka płatności otrzymanych na czas, który mierzy efektywność przepływów pieniężnych.

Skąd pobrać

Dane znajdują się w tabelach należności lub faktur w Oracle Fusion, na przykład AR_PAYMENT_SCHEDULES_ALL.

Przykłady
2023-06-192023-07-012023-06-25
Czy dostarczono na czas
IsOnTimeDelivery
Obliczany wskaźnik przyjmujący wartość true, jeśli dostawa nastąpiła w dniu wskazanym przez klienta lub wcześniej.
Opis

Ten atrybut logiczny jest wyznaczany przez porównanie ActualDeliveryDate z RequestedDeliveryDate. W prosty sposób wskazuje wynik dostawy dla danego case.

Wskaźnik ten stanowi podstawę do obliczania zbiorczego KPI „Odsetek dostaw na czas”. Ułatwia filtrowanie i analizę, pozwalając szybko wyodrębnić wszystkie opóźnione zamówienia i zbadać przyczyny opóźnień.

Dlaczego to ważne

Bezpośrednio mierzy, czy realizacja zamówienia spełnia oczekiwania klienta, i ułatwia analizę opóźnionych zamówień.

Skąd pobrać

To pole obliczane według reguły: ActualDeliveryDate <= RequestedDeliveryDate.

Przykłady
truefalse
Czy faktura została skorygowana
IsInvoiceCorrected
Flaga wskazująca, czy fakturę skorygowano lub zmieniono po jej utworzeniu.
Opis

Ten atrybut logiczny ma wartość true, jeśli faktura przeszła pętlę korekty, co wskazuje obecność aktywności „Skorygowano fakturę”. Oznacza przypadki, w których na etapie fakturowania konieczne były dodatkowe prace.

To ważna dana wejściowa dla dashboardu „Analiza poprawności faktur i dodatkowych prac” oraz KPI „Wskaźnik korekt faktur”. Pozwala określić skalę błędów w fakturowaniu i przeanalizować ich przyczyny, aby ograniczyć pracę ręczną i opóźnienia w płatnościach.

Dlaczego to ważne

Wykrywa dodatkowe prace związane z fakturami, które mogą wskazywać na nieefektywność procesu, problemy z jakością danych i ryzyko opóźnień w płatnościach.

Skąd pobrać

To pole obliczane. Zwykle ma wartość true dla danego przypadku, jeśli w jego dzienniku zdarzeń występuje aktywność „Skorygowano fakturę”.

Przykłady
falsetrue
Czy płatność była opóźniona
IsLatePayment
Obliczany wskaźnik przyjmujący wartość true, jeśli płatność wpłynęła po terminie.
Opis

Ten atrybut logiczny jest wyznaczany przez porównanie faktycznej daty otrzymania płatności z PaymentDueDate. Wskazuje, czy faktura została opłacona w terminie.

Atrybut służy do obliczania KPI „Odsetek płatności otrzymanych w terminie”. Ułatwia podział płatności na terminowe i opóźnione oraz analizę cech klientów płacących po terminie, częstych przyczyn opóźnień i ich wpływu na kapitał obrotowy.

Dlaczego to ważne

Bezpośrednio mierzy skuteczność ściągania należności i ułatwia analizę płatności przeterminowanych.

Skąd pobrać

To pole obliczane. Zastosowana logika: PaymentReceivedDate > PaymentDueDate.

Przykłady
falsetrue
Jednostka biznesowa
BusinessUnitName
Nazwa wewnętrznej jednostki biznesowej odpowiedzialnej za zamówienie sprzedaży.
Opis

Ten atrybut wskazuje konkretny dział lub jednostkę operacyjną firmy odpowiedzialną za transakcję. Umożliwia porównywanie wyników różnych części organizacji.

Podział procesu według jednostki biznesowej pomaga wykrywać różnice w wydajności, kosztach i zgodności w całej firmie. Analiza może wskazać dobre praktyki stosowane w jednostkach osiągających lepsze wyniki, które warto upowszechnić, oraz jednostki wymagające ukierunkowanego ulepszenia procesów.

Dlaczego to ważne

Umożliwia porównywanie wyników i analizę spójności procesów w różnych jednostkach organizacji.

Skąd pobrać

Informacja jest zwykle dostępna w nagłówku zamówienia sprzedaży i powiązana ze strukturą organizacyjną zdefiniowaną w Oracle Fusion.

Przykłady
Jednostka biznesowa, Ameryka PółnocnaJednostka biznesowa, EMEAUsługi globalne
Kraj klienta
CustomerCountry
Kraj, w którym znajduje się klient.
Opis

Ten atrybut określa kraj na podstawie adresu dostawy lub adresu rozliczeniowego klienta. Umożliwia analizę geograficzną.

Podział procesu według kraju może ujawnić regionalne różnice w wynikach, czasie cyklu lub terminowości płatności. Pomaga zrozumieć, jak lokalne przepisy, wyzwania logistyczne i warunki rynkowe wpływają na proces od zamówienia do otrzymania płatności.

Dlaczego to ważne

Umożliwia analizę geograficzną i wykrywanie regionalnych różnic w wydajności procesu, zgodności i zachowaniach klientów.

Skąd pobrać

Dane pochodzą z tabel głównych danych klientów, takich jak HZ_LOCATIONS i HZ_PARTY_SITES, powiązanych z zamówieniem sprzedaży.

Przykłady
USANiemcyJaponia
Metoda wysyłki
ShippingMethod
Metoda lub przewoźnik używany do wysyłki towarów do klienta.
Opis

Ten atrybut określa przewoźnika lub poziom usługi dostawy, na przykład „Transport drogowy”, „Ekspres lotniczy” lub „Kurier lokalny”.

Informacja ta jest niezbędna do obsługi dashboardu „Terminowość dostaw według metody wysyłki”. Umożliwia porównanie terminowości dostaw i kosztów wysyłki dla różnych metod i przewoźników, co pomaga optymalizować logistykę i wybór dostawców.

Dlaczego to ważne

Ułatwia analizę logistyki przez porównanie wyników różnych przewoźników i metod wysyłki.

Skąd pobrać

Dane są dostępne w tabelach wysyłki i realizacji w Oracle Fusion. Więcej informacji można znaleźć w dokumentacji Oracle Fusion Financials.

Przykłady
FedEx, przesyłka naziemnaUPS, dostawa lotnicza następnego dniaDHL, przesyłka międzynarodowa
Nazwa produktu
ProductName
Nazwa sprzedawanego produktu lub usługi.
Opis

Ten atrybut określa produkt lub usługę w pozycji zamówienia sprzedaży. Jeśli zamówienie zawiera kilka pozycji, case można analizować na poziomie pozycji albo agregować ten atrybut na poziomie nagłówka.

Analiza według produktu pomaga ustalić, czy niektóre produkty wiążą się z bardziej złożonym lub problematycznym przebiegiem procesu, na przykład częstymi opóźnieniami dostaw lub problemami z płatnościami. Te informacje mogą pomóc w zarządzaniu produktami i planowaniu łańcucha dostaw.

Dlaczego to ważne

Umożliwia analizę wyników procesu dla różnych produktów i wskazuje te, których realizacja lub fakturowanie może przebiegać bardziej złożoną ścieżką.

Skąd pobrać

Dane pochodzą z tabel pozycji zamówień sprzedaży połączonych z tabelą głównych danych produktów. Więcej informacji można znaleźć w dokumentacji Oracle Fusion Financials.

Przykłady
Standardowy moduł X1Pakiet usług premiumKomponent Y2-B
Numer faktury
InvoiceNumber
Unikatowy identyfikator faktury klienta.
Opis

Ten atrybut to unikatowy numer nadany fakturze wystawionej na podstawie zamówienia sprzedaży. Łączy działania związane ze sprzedażą i realizacją z finansowym rozliczeniem transakcji.

Głównym identyfikatorem case jest numer zamówienia sprzedaży, ale numer faktury jest niezbędny do analizy fakturowania i płatności. Ułatwia śledzenie korekt faktur, sporów i statusu płatności oraz obsługę dashboardów, takich jak „Dokładność faktur i analiza poprawek”.

Dlaczego to ważne

Łączy proces z obsługą należności i jest niezbędny do analizy poprawek faktur oraz cykli płatności.

Skąd pobrać

Dane są dostępne w tabelach transakcyjnych należności w Oracle Fusion, takich jak RA_CUSTOMER_TRX_ALL.

Przykłady
INV-93485INV-93486INV-93487
Ostatnia aktualizacja danych
LastUpdateDate
Znacznik czasu wskazujący, kiedy dane tego zdarzenia zostały ostatnio odświeżone z systemu źródłowego.
Opis

Ten atrybut zapisuje, kiedy dane zostały ostatnio wyodrębnione lub zaktualizowane w zbiorze danych do process mining. Informuje, jak aktualne są analizowane dane.

Dzięki tej informacji użytkownicy wiedzą, na jak świeżych danych opiera się analiza procesu. Ułatwia to określenie oczekiwań dotyczących aktualności danych oraz planowanie i monitorowanie harmonogramu ich odświeżania.

Dlaczego to ważne

Informuje o aktualności danych, dzięki czemu wiadomo, jak aktualna jest analiza procesu.

Skąd pobrać

Ta wartość jest generowana i zapisywana w zbiorze danych podczas każdego cyklu wyodrębniania i przekształcania danych.

Przykłady
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
System źródłowy
SourceSystemIdentifier
Określa system źródłowy, z którego wyodrębniono dane o zdarzeniu.
Opis

Ten atrybut wskazuje pochodzenie danych. Jest szczególnie przydatny, gdy w procesie od zamówienia do otrzymania płatności uczestniczy kilka systemów. Na przykład dane o zamówieniach mogą pochodzić z Oracle Fusion, a dane o wysyłce z systemu zewnętrznego operatora logistycznego.

W analizie atrybut pomaga ustalić pochodzenie danych i filtrować widok procesu według zdarzeń z wybranych systemów. Jest też przydatny przy weryfikacji danych i wykrywaniu fragmentacji procesu między różnymi środowiskami IT.

Dlaczego to ważne

Informuje o pochodzeniu danych, co ułatwia zarządzanie danymi i rozwiązywanie problemów w środowiskach korzystających z wielu systemów.

Skąd pobrać

Zwykle jest to stała wartość dodawana podczas wyodrębniania i przekształcania danych, która oznacza źródło zbioru danych.

Przykłady
Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP
Typ zamówienia
OrderType
Klasyfikacja zamówienia sprzedaży, na przykład „Zamówienie standardowe” lub „Zamówienie zwrotu”.
Opis

Typ zamówienia służy do klasyfikowania zamówień sprzedaży według ich celu biznesowego. Typowe kategorie to standardowa sprzedaż, zamówienia serwisowe, autoryzacje zwrotu materiałów (RMA) i zamówienia wewnętrzne.

Analiza procesu według typu zamówienia jest ważna, ponieważ poszczególne typy często mają odrębny przebieg i cele dotyczące wyników. Podział ten pomaga rozpoznać zamierzone i oczekiwane różnice w procesie, aby nie uznać ich błędnie za odstępstwa.

Dlaczego to ważne

Umożliwia oddzielną analizę prawidłowych przebiegów procesu, na przykład zamówień standardowych i zwrotów, co pozwala rzetelnie porównywać wyniki.

Skąd pobrać

Informacja jest zwykle dostępna jako pole w tabeli nagłówków zamówień sprzedaży w Oracle Fusion. Więcej informacji można znaleźć w dokumentacji Oracle Fusion Financials.

Przykłady
Standardowe zamówienie sprzedażyAutoryzacja zwrotuZamówienie serwisowe
Warunki płatności
PaymentTerms
Uzgodnione warunki płatności klienta.
Opis

Ten atrybut określa warunki, na jakich klient powinien opłacić fakturę, na przykład „30 dni” lub „60 dni”. Na ich podstawie oblicza się PaymentDueDate.

Podział analizy według warunków płatności pomaga wyjaśnić różnice w czasie od faktury do płatności. Dostarcza kontekstu dla KPI „Odsetek płatności otrzymanych w terminie”, ponieważ różne warunki naturalnie wiążą się z innymi zachowaniami płatniczymi. Informacje te mogą pomóc w ustalaniu polityki kredytowej i prognozowaniu przepływów pieniężnych.

Dlaczego to ważne

Dostarcza kontekstu do analizy zachowań płatniczych i pomaga wyjaśnić różnice w czasie od wystawienia faktury do otrzymania płatności.

Skąd pobrać

Dane są dostępne na poziomie zamówienia sprzedaży lub konta klienta w Oracle Fusion. Więcej informacji można znaleźć w dokumentacji Oracle Fusion Financials.

Przykłady
30 dni60 dniPłatność przy odbiorze
Wymagane Zalecane Opcjonalne

Aktywności w procesie Order to Cash, obsłudze zamówień sprzedaży

To najważniejsze etapy i punkty kontrolne, które warto rejestrować w dzienniku zdarzeń, aby rzetelnie odkrywać przebieg procesu i oceniać jego efektywność.
6 Zalecane 8 Opcjonalne
Działanie Opis
Otrzymano płatność
To zdarzenie oznacza, że płatność klienta wpłynęła i została rozliczona z fakturą w module należności. Rejestruje się je po zaksięgowaniu rozliczenia wpływu środków.
Dlaczego to ważne

To ważny punkt pomiaru KPI „Całkowity czas cyklu od zamówienia do otrzymania płatności” oraz „Odsetek płatności otrzymanych w terminie”. Oznacza zamianę sprzedaży na środki pieniężne.

Skąd pobrać

W Oracle Accounts Receivable jest to jawnie rejestrowane zdarzenie. Zapis trafia do tabel wpływów środków, takich jak AR_RECEIVABLE_APPLICATIONS_ALL, gdy wpływ zostaje rozliczony z fakturą.

Rejestrowanie

Dane pochodzą ze znacznika czasu pola „apply date” rekordu rozliczenia wpływu środków w module AR.

Typ zdarzenia explicit
Potwierdzenie zamówienia
Ten ważny etap oznacza, że zamówienie sprzedaży przeszło wszystkie wstępne kontrole, w tym kontrolę kredytową, i może zostać przekazane do realizacji. Zdarzenie można zwykle wywnioskować, gdy status zamówienia zmienia się na przykład na „Awaiting Shipping” lub „Scheduled”.
Dlaczego to ważne

Ta aktywność jest ważnym etapem przy obliczaniu „Average Order Confirmation Time”. Oznacza przekazanie zamówienia z etapu wprowadzania do realizacji.

Skąd pobrać

Zdarzenie można wywnioskować ze zmiany statusu nagłówka lub pozycji zamówienia sprzedaży na wartość oznaczającą gotowość do realizacji, na przykład „Awaiting Shipping”. Należy sprawdzić kolumny statusu w tabelach DOO_HEADERS_ALL lub DOO_FULFILL_LINES_ALL.

Rejestrowanie

Wartość jest wyznaczana na podstawie znacznika czasu zmiany statusu zamówienia na potwierdzone lub zaplanowane.

Typ zdarzenia inferred
Utworzenie faktury
Ta aktywność oznacza utworzenie faktury dla klienta w module Accounts Receivable. Zwykle uruchamia ją zdarzenie potwierdzenia wysyłki. Powstaje rekord faktury z unikalnym numerem i datą utworzenia.
Dlaczego to ważne

Oznacza oficjalny początek cyklu ściągania należności. Stanowi podstawę do pomiaru „Invoice to Payment Time” i ogólnej sprawności przepływów pieniężnych.

Skąd pobrać

To jawne zdarzenie w Oracle Accounts Receivable (AR). Rekord faktury jest tworzony w tabeli RA_CUSTOMER_TRX_ALL i zawiera datę transakcji.

Rejestrowanie

Dane pochodzą z daty utworzenia transakcji faktury w module AR.

Typ zdarzenia explicit
Utworzenie zamówienia sprzedaży
Ta aktywność rozpoczyna proces obsługi zamówienia sprzedaży. Oznacza moment wprowadzenia nowego zamówienia do Oracle Fusion. Zdarzenie jest zwykle rejestrowane, gdy użytkownik zapisuje nowy rekord zamówienia w module Order Management.
Dlaczego to ważne

Jako początek procesu ta aktywność jest niezbędna do pomiaru całkowitego czasu cyklu Order to Cash i analizy liczby przyjmowanych zamówień.

Skąd pobrać

Zdarzenie jest rejestrowane podczas tworzenia rekordu zamówienia sprzedaży w Order Management Cloud. Znaczników czasu utworzenia należy szukać w tabeli DOO_HEADERS_ALL.

Rejestrowanie

Dane pochodzą ze znacznika czasu utworzenia rekordu nagłówka zamówienia sprzedaży.

Typ zdarzenia explicit
Wysłanie towarów
Ta aktywność oznacza, że towary opuściły magazyn i są w drodze do klienta. Jest rejestrowana po przetworzeniu transakcji potwierdzenia wysyłki w Oracle Shipping.
Dlaczego to ważne

To ważny etap, który oznacza zakończenie realizacji zamówienia i uruchamia fakturowanie. Jest niezbędny do pomiaru terminowości wysyłek i czasu dostawy.

Skąd pobrać

To jawne zdarzenie rejestrowane w Oracle Shipping Execution. Transakcja potwierdzenia wysyłki tworzy rekord w tabelach wysyłkowych, takich jak WSH_DELIVERY_DETAILS, zawierający datę wysyłki.

Rejestrowanie

Dane pochodzą ze znacznika czasu „actual ship date” w rekordzie szczegółów dostawy powiązanym z pozycją zamówienia.

Typ zdarzenia explicit
Zamknięto zamówienie
Ostatnie zdarzenie w procesie. Oznacza, że wszystkie pozycje zamówienia sprzedaży zostały zrealizowane, zafakturowane i zamknięte. Status nagłówka zamówienia zmienia się na „Closed”.
Dlaczego to ważne

To zdarzenie oznacza pomyślne zakończenie cyklu życia zamówienia sprzedaży. Jest potrzebne do obliczania czasu trwania procesu od początku do końca oraz wykrywania zamówień, które nigdy nie zostają zamknięte.

Skąd pobrać

Zdarzenie można wywnioskować ze zmiany statusu nagłówka zamówienia sprzedaży na „Closed” w tabeli DOO_HEADERS_ALL. Znacznik czasu tej ostatniej zmiany statusu wyznacza moment zdarzenia.

Rejestrowanie

Ustalane na podstawie znacznika czasu zmiany statusu nagłówka zamówienia sprzedaży na „Closed”.

Typ zdarzenia inferred
Anulowano zamówienie
Oznacza anulowanie zamówienia sprzedaży przed wysłaniem wszystkich towarów. Może do niego dojść z różnych przyczyn, a końcowy status zamówienia to „Cancelled”.
Dlaczego to ważne

To istotna ścieżka wyjątkowa. Analiza anulowanych zamówień pomaga ustalić przyczyny, takie jak brak towaru, problemy z ceną lub zmiana decyzji klienta, i wskazać możliwości ulepszenia procesów.

Skąd pobrać

Zdarzenie można wywnioskować ze zmiany statusu nagłówka lub pozycji zamówienia sprzedaży na „Cancelled”. Moment zdarzenia określa znacznik czasu tej zmiany.

Rejestrowanie

Ustalane na podstawie znacznika czasu zmiany statusu nagłówka lub pozycji zamówienia na „Cancelled”.

Typ zdarzenia inferred
Dostarczenie towarów
Oznacza, że klient otrzymał przesyłkę. Informacje te często pochodzą od zewnętrznego przewoźnika i są przekazywane do Oracle Fusion. Zdarzenie można też wywnioskować na podstawie standardowego czasu transportu liczonego od daty wysyłki.
Dlaczego to ważne

Ta aktywność jest niezbędna do obliczenia KPI „On-Time Delivery Rate” i rzetelnego pomiaru poziomu obsługi klienta.

Skąd pobrać

Zdarzenie często nie jest dostępne natywnie w Oracle. Można je rejestrować, jeśli skonfigurowano integrację z przewoźnikiem, albo obliczyć, dodając standardowy czas transportu do daty „Goods Shipped”. Wymaga to analizy systemu.

Rejestrowanie

Zdarzenie można wywnioskować z danych przekazywanych przez przewoźnika lub obliczyć na podstawie daty wysyłki i średniego czasu transportu.

Typ zdarzenia inferred
Kompletacja towarów
Oznacza fizyczne pobranie towarów z magazynu w celu realizacji zamówienia. To ważny etap logistyki, zwykle rejestrowany w module zarządzania magazynem lub wysyłką.
Dlaczego to ważne

Ta aktywność zapewnia wgląd w operacje magazynowe. Opóźnienia między rezerwacją zapasów a kompletacją mogą wskazywać na problemy z zasobami lub wąskie gardła w procesie magazynowym.

Skąd pobrać

Zdarzenie jest rejestrowane w modułach Oracle Fusion Cloud SCM (Supply Chain Management). Można je wywnioskować ze zmiany statusu fali kompletacyjnej lub listy kompletacyjnej powiązanej z pozycją zamówienia sprzedaży.

Rejestrowanie

Zdarzenie można wywnioskować ze znacznika czasu zakończenia transakcji kompletacji w modułach SCM.

Typ zdarzenia inferred
Korekta faktury
Występuje, gdy wcześniej wystawiona faktura zostaje zmieniona, wystawiona ponownie lub skorygowana z powodu błędów albo sporu z klientem. Zwykle rejestruje się to przez wystawienie faktury korygującej lub nowej wersji faktury.
Dlaczego to ważne

Śledzenie korekt faktur jest ważne przy obliczaniu KPI „Odsetek faktur wymagających ponownej obsługi”. Wskaźnik ten pokazuje problemy w procesie fakturowania, które mogą opóźniać płatności i zwiększać koszty administracyjne.

Skąd pobrać

Zdarzenie można wywnioskować z wystawienia faktury korygującej powiązanej z fakturą pierwotną albo kolejnej wersji tej samej faktury w tabeli RA_CUSTOMER_TRX_ALL.

Rejestrowanie

Ustalane przez identyfikację faktur korygujących lub faktur odwołujących się do wcześniejszej transakcji fakturowej.

Typ zdarzenia inferred
Nałożenie blokady kredytowej
Ta aktywność występuje, gdy zamówienie sprzedaży zostaje automatycznie lub ręcznie zablokowane z powodu niezaliczonej kontroli kredytowej lub innego problemu związanego z kredytem. Zdarzenie jest zwykle rejestrowane jako zmiana statusu blokady zamówienia w systemie.
Dlaczego to ważne

Śledzenie blokad kredytowych pomaga ustalić przyczyny opóźnień w obsłudze zamówień i zmierzyć sprawność procesu ich zwalniania.

Skąd pobrać

Zdarzenie można wywnioskować z nałożenia blokady na zamówienie sprzedaży. Zwykle jest ono rejestrowane w tabelach dotyczących blokad, takich jak DOO_HOLDS_ALL, powiązanych z zamówieniem.

Rejestrowanie

Zdarzenie można wywnioskować z utworzenia rekordu w tabeli blokad zamówień z typem blokady „Credit”.

Typ zdarzenia inferred
Przeprowadzenie kontroli kredytowej
Oznacza sprawdzenie zdolności kredytowej klienta. W workflow obsługi zamówienia może to być etap automatyczny lub ręczny. Jego zakończenie jest zwykle rejestrowane jako zmiana statusu lub ukończone zadanie.
Dlaczego to ważne

Analiza czasu kontroli kredytowej pomaga wykryć wąskie gardła w zatwierdzaniu zamówień. Jest niezbędna do obliczenia KPI „Credit Check to Confirmed Time”.

Skąd pobrać

Zdarzenie można wywnioskować ze zmian statusu zamówienia sprzedaży, na przykład przejścia do statusu „Pending Credit Approval”, albo odczytać z jawnego wpisu w dzienniku zdarzeń funkcji zarządzania kredytowego.

Rejestrowanie

Zdarzenie można wywnioskować ze zmian statusu zamówienia lub znaczników czasu powiązanych z zadaniami kontroli kredytowej.

Typ zdarzenia inferred
Rezerwacja zapasów
Ta aktywność oznacza przydzielenie lub zarezerwowanie zapasów fizycznych na potrzeby realizacji pozycji zamówienia sprzedaży. System rezerwuje określone towary, aby były dostępne, gdy zamówienie będzie gotowe do kompletacji.
Dlaczego to ważne

Śledzenie tej aktywności pomaga analizować KPI „Inventory Allocation Lead Time” i wykrywać opóźnienia między potwierdzeniem zamówienia a zabezpieczeniem towarów.

Skąd pobrać

Zdarzenie jest często rejestrowane w modułach zarządzania zapasami lub realizacji łańcucha dostaw. Można je wywnioskować ze zmian statusu pozycji realizacji, które wskazują, że zapasy zostały określone lub zarezerwowane.

Rejestrowanie

Zdarzenie można wywnioskować ze zmian statusu pozycji realizacji związanych z rezerwacją zapasów lub planowaniem.

Typ zdarzenia inferred
Zamknięto pozycję zamówienia
Oznacza ostateczne zamknięcie pojedynczej pozycji zamówienia sprzedaży. Pozycja została w pełni wysłana i zafakturowana, a dalsze transakcje nie są już oczekiwane. System zmienia jej status na „Closed”.
Dlaczego to ważne

Zamknięcie pozycji zamówienia oznacza wypełnienie wszystkich zobowiązań umownych dotyczących danego towaru. Analiza pozwala wykryć zamówienia, które pozostają otwarte długo po realizacji i otrzymaniu płatności.

Skąd pobrać

Zdarzenie można wywnioskować ze zmiany statusu pozycji realizacji na „Closed” w tabeli DOO_FULFILL_LINES_ALL. Znacznik czasu tej zmiany wyznacza moment zdarzenia.

Rejestrowanie

Ustalane na podstawie znacznika czasu zmiany statusu pozycji realizacji na „Closed”.

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje pobierania danych

Jak pobrać dane z Oracle Fusion Financials

Gotowi do rozpoczęcia?

Skorzystaj z tego szablonu, aby usprawnić zbieranie danych i rozpocząć pracę z process mining. Już dziś zacznij optymalizować proces Order to Cash, obsługę zamówień sprzedaży.

Już dziś usprawnij proces Order to Cash, obsługę zamówień sprzedaży

Łatwo wykryj wąskie gardła i skróć czas cyklu Order to Cash o 30%.

Rozpocznij okres próbny

Nie trzeba podawać danych karty płatniczej. Okres próbny trwa 14 dni.