Szablon danych do analizy obsługi zamówień sprzedaży w procesie od zamówienia do płatności
Szablon danych do analizy obsługi zamówień sprzedaży w procesie od zamówienia do płatności
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia w analizie
- Wskazówki dotyczące ekstrakcji danych
Atrybuty procesu obsługi zamówień sprzedaży od zamówienia do płatności
| Nazwa | Opis | ||
|---|---|---|---|
|
Czas zdarzenia
EventTime
|
Timestamp wskazujący, kiedy wystąpiło dane działanie. | ||
|
Opis
Czas zdarzenia, czyli timestamp, określa dokładną datę i godzinę wykonania działania. Zapisuje na przykład moment utworzenia zamówienia, wysłania faktury lub otrzymania płatności. Te dane czasowe są podstawą process mining. Atrybut służy do chronologicznego porządkowania zdarzeń w każdym case, co pozwala prawidłowo odtworzyć przebieg procesu. Na jego podstawie oblicza się również czas trwania i wyniki, takie jak czas między działaniami, łączny czas obsługi case oraz opóźnienia i wąskie gardła.
Dlaczego to ważne
Określa chronologiczną kolejność zdarzeń i stanowi podstawę analizy wyników w czasie, w tym czasu realizacji i identyfikacji wąskich gardeł.
Skąd pobrać
Dane pochodzą z różnych pól dat w tabelach Oracle EBS, na przykład CREATION_DATE w OE_ORDER_HEADERS_ALL, ACTUAL_SHIPMENT_DATE w WSH_DELIVERY_DETAILS lub TRX_DATE w RA_CUSTOMER_TRX_ALL.
Przykłady
2023-04-15T10:30:00Z2023-04-18T14:00:00Z2023-05-01T09:15:00Z
|
|||
|
Nazwa działania
ActivityName
|
Nazwa konkretnego zdarzenia biznesowego lub kroku, który wystąpił w cyklu obsługi zamówienia sprzedaży. | ||
|
Opis
Ten atrybut zapisuje nazwę każdego działania wykonanego w ramach zamówienia sprzedaży, na przykład „Zaksięgowano zamówienie”, „Wysłano towary” lub „Otrzymano płatność”. Działania te wyznaczają najważniejsze etapy procesu Order to Cash. Analiza kolejności i częstotliwości działań stanowi podstawę process mining. Umożliwia odkrycie rzeczywistego przebiegu procesu, w tym typowych ścieżek, odstępstw i wąskich gardeł. Na podstawie tych danych powstaje mapa procesu, która służy do jego analizy.
Dlaczego to ważne
Określa kroki na mapie procesu, niezbędne do przedstawienia i analizy jego przebiegu.
Skąd pobrać
To pole pojęciowe wyliczane na podstawie zdarzeń, statusów i dat transakcji z różnych systemów źródłowych, między innymi z modułów Order Management, Shipping Execution i Accounts Receivable.
Przykłady
Utworzenie zamówienia sprzedażyWysłanie towaruUtworzenie fakturyOtrzymanie płatności
|
|||
|
Zamówienie sprzedaży
SalesOrder
|
Unikalny identyfikator zamówienia sprzedaży klienta, który pełni funkcję głównego case w procesie Order to Cash. | ||
|
Opis
Numer zamówienia sprzedaży jednoznacznie identyfikuje każde zamówienie klienta przez cały okres jego obsługi, od utworzenia do ostatecznego zamknięcia. Łączy wszystkie powiązane działania, takie jak księgowanie, wysyłka, fakturowanie i płatność. W process mining ten atrybut jest niezbędny do odtworzenia pełnego przebiegu każdego zamówienia. Grupując wszystkie zdarzenia pod jednym numerem zamówienia sprzedaży, analitycy mogą zobaczyć cały przebieg procesu, wykrywać różnice między zamówieniami i mierzyć KPI, takie jak czas realizacji czy terminowość dostawy dla poszczególnych case.
Dlaczego to ważne
To Case ID, niezbędny do powiązania wszystkich zdarzeń procesu i analizy pełnego cyklu obsługi zamówienia.
Skąd pobrać
Klucz główny zamówienia sprzedaży, zwykle dostępny w tabelach Oracle Order Management, na przykład w polu OE_ORDER_HEADERS_ALL.HEADER_ID.
Przykłady
685127103482459
|
|||
|
Łączna wartość zamówienia
TotalOrderAmount
|
Łączna wartość pieniężna zamówienia sprzedaży. | ||
|
Opis
Ten atrybut przedstawia łączną wartość wszystkich pozycji zamówienia sprzedaży w walucie transakcji. Jest ważnym wskaźnikiem finansowym dla każdego case. Analiza wyników procesu według wartości zamówienia pomaga ustalać priorytety działań usprawniających. Można na przykład sprawdzić, czy zamówienia o wysokiej wartości częściej się opóźniają lub wymagają poprawek niż zamówienia o niższej wartości. Ułatwia to również ocenę skutków finansowych, na przykład oszacowanie wartości zamówień zablokowanych na danym wąskim gardle.
Dlaczego to ważne
Umożliwia finansową analizę procesu, pomaga ustalać priorytety dla zamówień o wysokiej wartości i oszacować pieniężne skutki nieefektywności.
Skąd pobrać
Wartość jest zwykle obliczana przez zsumowanie kwot pozycji danego zamówienia. Kwoty pozycji znajdują się w tabelach takich jak OE_ORDER_LINES_ALL.
Przykłady
5450.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. Jest jednym z głównych wymiarów analizy wyników procesu. Filtrując proces według klienta lub dzieląc wyniki na grupy, analitycy mogą sprawdzić, którzy klienci mają najdłuższy czas realizacji, najczęściej wymagają poprawek lub najczęściej opóźniają płatności. Takie informacje pomagają poprawiać relacje z klientami, dostosowywać poziom obsługi i lepiej rozumieć ich zachowania.
Dlaczego to ważne
Umożliwia analizę z perspektywy klienta, aby wykrywać różnice w wynikach, poprawiać obsługę i porównywać zachowania płatnicze klientów.
Skąd pobrać
Wartość uzyskuje się przez połączenie SOLD_TO_ORG_ID z OE_ORDER_HEADERS_ALL z tabelami HZ_CUST_ACCOUNTS i HZ_PARTIES, aby pobrać nazwę podmiotu.
Przykłady
Global Tech Inc.Innovate Solutions LLCPioneer Corp
|
|||
|
Nazwa użytkownika
UserName
|
Użytkownik, który wykonał działanie. | ||
|
Opis
Wskazuje użytkownika odpowiedzialnego za wykonanie danego kroku procesu. Może to być przedstawiciel handlowy, który utworzył zamówienie, analityk kredytowy, który przeprowadził weryfikację, lub pracownik, który wystawił fakturę. Analiza działań według użytkowników pomaga określić potrzeby szkoleniowe, wskazać osoby lub zespoły osiągające dobre wyniki oraz ocenić rozkład obciążenia pracą. Jest też istotna przy analizie zgodności i ścieżki audytowej, na przykład podczas badania nieuprawnionych działań lub powtarzających się poprawek związanych z konkretnymi użytkownikami.
Dlaczego to ważne
Umożliwia analizę wyników pracy użytkowników, rozkładu obciążenia i przestrzegania zasad zgodności. Pomaga ustalić, kto wykonał dane działanie.
Skąd pobrać
Dane pochodzą z pól dotyczących użytkownika, takich jak CREATED_BY lub LAST_UPDATED_BY, w różnych tabelach Oracle EBS. Aby pobrać pełną nazwę użytkownika, często trzeba połączyć je z tabelą FND_USER.
Przykłady
JSMITHRWILLIAMSCDAVIS
|
|||
|
Potwierdzona data dostawy
ConfirmedDeliveryDate
|
Uzgodniona data, do której towary mają zostać dostarczone klientowi. | ||
|
Opis
Ten atrybut przechowuje datę dostawy obiecaną lub potwierdzoną klientowi. Jest punktem odniesienia przy pomiarze terminowości dostaw. W process mining datę tę porównuje się z rzeczywistym timestampem dostawy, zapisanym przy działaniu „Dostarczono towary”, aby obliczyć KPI „Wskaźnik terminowości dostaw”. Analiza odchyleń pomaga wykrywać powtarzające się problemy w logistyce, zarządzaniu zapasami lub planowaniu produkcji, które powodują opóźnienia.
Dlaczego to ważne
To punkt odniesienia przy pomiarze terminowości dostaw, ważnego KPI wpływającego na zadowolenie klientów i sprawność operacyjną.
Skąd pobrać
Data znajduje się zwykle w polu LATEST_ACCEPTABLE_DATE lub REQUEST_DATE na poziomie pozycji zamówienia w tabeli OE_ORDER_LINES_ALL.
Przykłady
2023-05-102023-06-012023-07-20
|
|||
|
Status zamówienia
OrderStatus
|
Bieżący lub historyczny status zamówienia sprzedaży albo jego pozycji. | ||
|
Opis
Ten atrybut zapisuje status zamówienia sprzedaży w różnych momentach, na przykład „Wprowadzone”, „Zaksięgowane”, „Zamknięte” lub „Anulowane”. Statusy często bezpośrednio odpowiadają działaniom w procesie. Śledzenie statusu zamówień pozwala tworzyć dashboardy pokazujące bieżący stan wszystkich aktywnych zamówień. Menedżerowie mogą monitorować portfel zamówień, wykrywać te, których obsługa utknęła, i reagować na wyjątki. Zmiany statusu często służą do definiowania działań na mapie procesu.
Dlaczego to ważne
Pokazuje stan portfela zamówień sprzedaży, pomagając wykrywać zamówienia, których obsługa utknęła, i zarządzać wyjątkami w procesie.
Skąd pobrać
Zwykle znajduje się w kolumnie FLOW_STATUS_CODE w tabelach OE_ORDER_HEADERS_ALL i OE_ORDER_LINES_ALL.
Przykłady
ZAKSIĘGOWANEOCZEKUJE_NA_WYSYŁKĘWYSŁANEZAMKNIĘTEANULOWANE
|
|||
|
Termin płatności
PaymentDueDate
|
Wyliczona data, do której klient powinien opłacić fakturę. | ||
|
Opis
Termin płatności to konkretna data, do której należy opłacić fakturę. Oblicza się go na podstawie daty wystawienia faktury i uzgodnionych warunków płatności. Jest datą docelową dla działania „Otrzymano płatność”. Atrybut ten służy do obliczania KPI „Wskaźnik zgodności z warunkami płatności” przez porównanie terminu z datą faktycznej płatności. Analiza odchyleń pomaga zespołowi windykacyjnemu ustalać priorytety, wykrywać klientów regularnie płacących po terminie i oceniać skuteczność procesu przypominania o płatności.
Dlaczego to ważne
Wyznacza termin otrzymania płatności, umożliwiając pomiar jej terminowości i sprawdzenie, czy klient przestrzega uzgodnionych warunków.
Skąd pobrać
Znajduje się w polu DUE_DATE tabeli AR_PAYMENT_SCHEDULES_ALL, powiązanej z transakcją faktury.
Przykłady
2023-06-152023-07-012023-08-30
|
|||
|
Warunki płatności
PaymentTerms
|
Uzgodnione warunki określające, kiedy klient powinien zapłacić za towary lub usługi. | ||
|
Opis
Warunki płatności określają zasady opłacania faktury, na przykład „30 dni”, „60 dni” lub „płatność przy odbiorze”. Atrybut ten ma podstawowe znaczenie dla zarządzania należnościami i przepływami pieniężnymi. Analiza wyników procesu według warunków płatności pomaga ustalić, czy klienci korzystający z określonych warunków częściej płacą po terminie. Informacje te służą do oceny ryzyka finansowego, optymalizacji działań windykacyjnych i sprawdzania skuteczności oferowanych warunków płatności. To ważny wymiar dashboardu „Monitorowanie zgodności z warunkami płatności”.
Dlaczego to ważne
Pomaga analizować zachowania płatnicze, monitorować przepływy pieniężne i oceniać ryzyko finansowe związane z różnymi umowami z klientami.
Skąd pobrać
Dane znajdują się w tabeli RA_TERMS, powiązanej przez TERM_ID z tabelami takimi jak RA_CUSTOMER_TRX_ALL (faktury) lub OE_ORDER_HEADERS_ALL (zamówienia).
Przykłady
30 dni60 dniPłatność przy odbiorze
|
|||
|
Dostawa na czas
IsOnTimeDelivery
|
Flaga wskazująca, czy zamówienie dostarczono w potwierdzonym terminie lub wcześniej. | ||
|
Opis
Ten wyliczany atrybut logiczny (True/False) wskazuje, czy dotrzymano terminu dostawy zamówienia. Jego wartość ustala się przez porównanie timestampu działania „Dostarczono towary” z „Potwierdzoną datą dostawy”. Atrybut ten bezpośrednio wspiera KPI „Wskaźnik terminowości dostaw”. Ułatwia analizę i tworzenie dashboardów, ponieważ dla każdego zamówienia podaje jednoznaczny wynik. Można łatwo filtrować i grupować dane, aby wykrywać cechy opóźnionych dostaw, takie jak często występujące produkty, klienci lub metody wysyłki.
Dlaczego to ważne
Bezpośrednio mierzy poziom obsługi klienta i niezawodność realizacji, ułatwiając obliczanie i prezentację KPI terminowości dostaw.
Skąd pobrać
To pole wyliczane według reguły: IF ('Goods Delivered' EventTime <= ConfirmedDeliveryDate) THEN True ELSE False.
Przykłady
truefalse
|
|||
|
Ilość w zamówieniu
OrderQuantity
|
Liczba sztuk produktu zamówionych w danej pozycji zamówienia sprzedaży. | ||
|
Opis
Ten atrybut określa liczbę sztuk danego produktu zamówionych przez klienta w konkretnej pozycji zamówienia sprzedaży. Pokazuje wielkość transakcji na poziomie pozycji. Ilość w zamówieniu można wykorzystać do sprawdzenia, czy przebieg procesu zależy od wielkości zamówienia. Bardzo duże lub małe zamówienia mogą na przykład przebiegać innymi ścieżkami albo napotykać inne rodzaje opóźnień. Ilość dostarcza też kontekstu dla innych wskaźników, takich jak wartość zamówienia.
Dlaczego to ważne
Pokazuje skalę zamówienia i pozwala analizować wpływ jego wielkości na sprawność procesu oraz sposób realizacji.
Skąd pobrać
Znajduje się w polu ORDERED_QUANTITY tabeli OE_ORDER_LINES_ALL.
Przykłady
102501
|
|||
|
Metoda wysyłki
ShippingMethod
|
Sposób transportu lub przewoźnik dostarczający towary klientowi. | ||
|
Opis
Ten atrybut określa sposób transportu lub poziom usługi, na przykład „transport drogowy”, „ekspres lotniczy” lub „kurier lokalny”. Wpływa zarówno na czas dostawy, jak i jej koszt. Analiza procesu według tego atrybutu pozwala oceniać skuteczność różnych metod wysyłki. Na przykład dashboard „Wyniki metod wysyłki” porównuje czas od działania „Wysłano towary” do „Dostarczono towary” dla każdej metody. Ułatwia to optymalizację logistyki pod kątem szybkości, kosztów i niezawodności.
Dlaczego to ważne
Umożliwia ocenę przewoźników i opcji wysyłki pod kątem kosztów, szybkości i niezawodności.
Skąd pobrać
Zwykle jest zapisany jako SHIPPING_METHOD_CODE w tabelach takich jak WSH_DELIVERY_DETAILS lub OE_ORDER_LINES_ALL.
Przykłady
UPS, transport drogowyFedEx, ekspresowa dostawa następnego dniaDHL Express Worldwide
|
|||
|
Numer produktu
ProductNumber
|
Unikalny identyfikator produktu lub pozycji w zamówieniu sprzedaży. | ||
|
Opis
Ten atrybut wskazuje konkretny materiał, produkt lub usługę objęte sprzedażą. Umożliwia analizę na bardziej szczegółowym poziomie niż nagłówek zamówienia sprzedaży. Analiza procesu według produktu pomaga wykrywać problemy dotyczące konkretnych produktów. Niektóre z nich mogą na przykład wymagać dłuższej realizacji z powodu złożonej produkcji lub zaopatrzenia, a inne częściej wiązać się z błędami wysyłki lub reklamacjami klientów. Pozwala to ukierunkować działania usprawniające w łańcuchu dostaw i zarządzaniu produktami.
Dlaczego to ważne
Umożliwia analizę na poziomie produktu i wykrywanie pozycji powodujących opóźnienia, poprawki lub inne nieefektywności procesu.
Skąd pobrać
Wartość pochodzi z INVENTORY_ITEM_ID w tabeli OE_ORDER_LINES_ALL. Pole można połączyć z tabelą MTL_SYSTEM_ITEMS_B, aby pobrać numer lub opis produktu.
Przykłady
AS54888CM15001SV20100
|
|||
|
Ostatnia aktualizacja danych
LastDataUpdate
|
Timestamp ostatniego odświeżenia danych z systemu źródłowego. | ||
|
Opis
Ten atrybut wskazuje, kiedy ostatnio wyodrębniono dane z Oracle E-Business Suite i załadowano je do narzędzia process mining. Informuje o aktualności analizowanych danych. Dzięki temu użytkownicy wiedzą, jak aktualne są wyświetlane wyniki. Mogą sprawdzić, czy analizują informacje bieżące, czy migawkę z określonego momentu, co ma znaczenie przy podejmowaniu decyzji operacyjnych.
Dlaczego to ważne
Informuje o aktualności danych, co pomaga ocenić wiarygodność analizy i podejmować decyzje we właściwym czasie.
Skąd pobrać
Ten timestamp jest generowany i dodawany podczas procesu ekstrakcji, transformacji i ładowania danych (ETL).
Przykłady
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Płatność w terminie
IsPaymentOnTime
|
Flaga wskazująca, czy płatność wpłynęła w terminie płatności lub wcześniej. | ||
|
Opis
Ten wyliczany atrybut logiczny powstaje przez porównanie timestampu działania „Otrzymano płatność” z terminem płatności odpowiedniej faktury. W prosty sposób wskazuje, czy płatność była terminowa. Flaga stanowi podstawę KPI „Wskaźnik zgodności z warunkami płatności”. Ułatwia tworzenie dashboardów i raportów monitorujących zachowania płatnicze klientów oraz skuteczność procesu obsługi należności. Pozwala szybko podzielić płatności na terminowe i opóźnione oraz analizować czynniki, które mogły mieć na nie wpływ, takie jak typ klienta lub warunki płatności.
Dlaczego to ważne
Bezpośrednio mierzy przestrzeganie warunków płatności, co ma znaczenie dla zarządzania przepływami pieniężnymi i oceny wiarygodności finansowej klientów.
Skąd pobrać
To pole wyliczane według reguły: IF ('Payment Received' EventTime <= PaymentDueDate) THEN True ELSE False.
Przykłady
truefalse
|
|||
|
Przyczyna anulowania
CancellationReason
|
Zapisana przyczyna anulowania zamówienia sprzedaży lub jego pozycji. | ||
|
Opis
Gdy zamówienie sprzedaży zostaje anulowane, ten atrybut zapisuje podaną przyczynę. Przykładowe przyczyny to „Prośba klienta”, „Brak towaru” lub „Blokada kredytowa”. Dane te są niezbędne do analizy przyczyn źródłowych anulowań zamówień. Dashboard „Wskaźnik i przyczyny anulowania zamówień sprzedaży” wykorzystuje ten atrybut do wskazania głównych powodów anulowań. Dzięki temu firma może podjąć ukierunkowane działania, aby ograniczyć utratę klientów, poprawić prognozowanie zapasów lub zmienić zasady kredytowe.
Dlaczego to ważne
Pokazuje, dlaczego zamówienia są anulowane, i umożliwia analizę przyczyn źródłowych, aby ograniczyć utratę sprzedaży i poprawić utrzymanie klientów.
Skąd pobrać
Informacja jest często zapisywana w polu kodu przyczyny, na przykład CANCELLED_REASON, które może znajdować się w tabeli OE_ORDER_LINES_ALL lub powiązanej tabeli zmian zamówień.
Przykłady
Produkt wycofany ze sprzedażyAnulowanie przez klientaZduplikowane zamówienie
|
|||
|
System źródłowy
SourceSystem
|
System, z którego wyodrębniono dane. | ||
|
Opis
Ten atrybut wskazuje źródłowy system informatyczny, z którego pochodzą dane o zdarzeniach. W tym procesie będzie to zawsze „Oracle E-Business Suite”. W środowisku korzystającym z wielu systemów pole to ma zasadnicze znaczenie dla śledzenia pochodzenia danych i rozwiązywania problemów. Nawet gdy używany jest tylko jeden system, dostarcza ważnego kontekstu dla modelu danych i pomaga ujednolicić proces pobierania danych.
Dlaczego to ważne
Informuje o pochodzeniu danych, ułatwiając ich śledzenie i prawidłową interpretację, zwłaszcza w środowisku z wieloma systemami.
Skąd pobrać
Zwykle jest to stała wartość dodawana podczas procesu ekstrakcji, transformacji i ładowania danych (ETL), która oznacza ich źródło.
Przykłady
Oracle E-Business SuiteOracle EBS R12
|
|||
|
Waluta
Currency
|
Kod waluty, w której wyrażono wartości pieniężne zamówienia sprzedaży. | ||
|
Opis
Atrybut waluty określa, w jakiej walucie podano kwoty zamówienia, na przykład USD, EUR lub JPY. Dostarcza kontekstu potrzebnego do interpretacji danych finansowych dotyczących zamówienia. Ma to znaczenie w międzynarodowych organizacjach, które przeprowadzają transakcje w różnych walutach. Pozwala prawidłowo interpretować wskaźniki finansowe, takie jak „Łączna wartość zamówienia”, i w razie potrzeby przeliczać waluty na potrzeby raportów zbiorczych.
Dlaczego to ważne
Dostarcza kontekstu dla wszystkich wartości pieniężnych, co pozwala prawidłowo analizować dane finansowe, zwłaszcza w firmach działających na wielu rynkach.
Skąd pobrać
Znajduje się w polu TRANSACTIONAL_CURR_CODE tabeli OE_ORDER_HEADERS_ALL.
Przykłady
USDEURGBP
|
|||
|
Wymagało poprawek
IsRework
|
Flaga wskazująca, czy zamówienie sprzedaży wymagało poprawek, na przykład ponownego potwierdzenia lub aktualizacji. | ||
|
Opis
Ten wyliczany atrybut logiczny oznacza case zawierające wzorce wskazujące na poprawki. Można je wykrywać, identyfikując pętle na mapie procesu, na przykład wielokrotne zaksięgowanie tego samego zamówienia, lub konkretne zdarzenia zmian zapisane w systemie. Flaga służy do obliczania KPI „Wskaźnik poprawek w zamówieniach sprzedaży” i zasilania dashboardu „Analiza poprawek w zamówieniach sprzedaży”. Analitycy mogą łatwo wyodrębnić i zbadać zamówienia odbiegające od standardowego przebiegu, oszacować wpływ poprawek na czas realizacji i koszty oraz ustalić przyczyny nieefektywnych pętli.
Dlaczego to ważne
Pomaga mierzyć nieefektywność procesu, wskazując zamówienia wymagające ręcznych zmian. Umożliwia analizę przyczyn i skutków poprawek.
Skąd pobrać
Wartość jest obliczana podczas transformacji danych przez wykrywanie sekwencji działań tworzących pętlę, na przykład gdy „Zaksięgowano zamówienie” występuje więcej niż raz w tym samym case.
Przykłady
truefalse
|
|||
Działania w procesie obsługi zamówień sprzedaży od zamówienia do płatności
| Działanie | Opis | ||
|---|---|---|---|
|
Otrzymanie płatności
|
To działanie występuje, gdy płatność klienta zostaje otrzymana i przypisana w systemie do odpowiedniej faktury. Jest to jawna transakcja finansowa rejestrowana w module Accounts Receivable. | ||
|
Dlaczego to ważne
Ten etap ma zasadnicze znaczenie dla monitorowania przepływów pieniężnych, wskaźnika Days Sales Outstanding (DSO) i przestrzegania terminów płatności. Jest to ważny punkt końcowy przy pomiarze czasu cyklu finansowego.
Skąd pobrać
Zdarzenie jest jawnie rejestrowane w tabeli AR_RECEIVABLE_APPLICATIONS_ALL. Kolumna APPLY_DATE zawiera timestamp przypisania wpłaty do faktury.
Rejestrowanie
Użyj kolumny APPLY_DATE z tabeli AR_RECEIVABLE_APPLICATIONS_ALL dla danej faktury.
Typ zdarzenia
explicit
|
|||
|
Przydzielenie zapasów
|
To działanie oznacza zarezerwowanie zapasów dla pozycji zamówienia, aby wymagana ilość była dostępna do kompletacji. Zazwyczaj można je wywnioskować ze zmiany statusu pozycji zamówienia wskazującej, że jest gotowa do przekazania do magazynu. | ||
|
Dlaczego to ważne
Ten etap pozwala ocenić gotowość do realizacji zamówienia. Opóźnienia mogą wskazywać braki zapasów, problemy z zaopatrzeniem lub nieefektywny proces przydziału.
Skąd pobrać
Zdarzenie można wywnioskować ze zmian statusu w tabeli WSH_DELIVERY_DETAILS. Występuje, gdy status pozycji zmienia się na „Ready to Release”. Timestamp pochodzi z powiązanej aktualizacji statusu.
Rejestrowanie
Zdarzenie można wywnioskować ze zmiany statusu pozycji w tabeli WSH_DELIVERY_DETAILS na „Ready to Release”.
Typ zdarzenia
inferred
|
|||
|
Utworzenie faktury
|
To zdarzenie oznacza utworzenie faktury należności za wysłane towary. Jest rejestrowane podczas procesu AutoInvoice, który pobiera dane z modułów Order Management i Shipping i przekazuje je do modułu Receivables. | ||
|
Dlaczego to ważne
To działanie rozpoczyna finansową część procesu. Od tego momentu mierzy się czas od wystawienia faktury do otrzymania płatności oraz monitoruje efektywność fakturowania.
Skąd pobrać
To jawna transakcja zapisywana w tabeli RA_CUSTOMER_TRX_ALL w module Oracle Receivables. Timestamp zdarzenia określa kolumna TRX_DATE lub CREATION_DATE.
Rejestrowanie
Użyj kolumny TRX_DATE z tabeli RA_CUSTOMER_TRX_ALL.
Typ zdarzenia
explicit
|
|||
|
Utworzenie zamówienia sprzedaży
|
To zdarzenie oznacza utworzenie zamówienia sprzedaży w systemie. Jest rejestrowane, gdy użytkownik zapisuje nowy nagłówek zamówienia, i formalnie rozpoczyna proces Order to Cash. | ||
|
Dlaczego to ważne
To główne zdarzenie rozpoczynające proces. Analiza czasu od tego momentu do kolejnych działań pozwala mierzyć całkowity czas cyklu Order to Cash.
Skąd pobrać
Zdarzenie pochodzi z tabeli OE_ORDER_HEADERS_ALL w module Oracle Order Management. Jawny timestamp tego działania znajduje się w kolumnie CREATION_DATE.
Rejestrowanie
Użyj kolumny CREATION_DATE z tabeli OE_ORDER_HEADERS_ALL.
Typ zdarzenia
explicit
|
|||
|
Wysłanie towaru
|
Oznacza zakończenie potwierdzenia wysyłki, gdy towary fizycznie opuszczają magazyn. To jawne zdarzenie w module wysyłkowym aktualizuje zapasy i zmienia status zamówienia. | ||
|
Dlaczego to ważne
To ważny etap realizacji, który służy do pomiaru terminowości wysyłek. Uruchamia również procesy fakturowania i ujmowania przychodów.
Skąd pobrać
Zdarzenie jest rejestrowane jako jawna transakcja w Oracle Shipping Execution. Timestamp znajduje się w kolumnie INITIAL_PICKUP_DATE tabeli WSH_NEW_DELIVERIES lub można go wywnioskować ze zmiany statusu w tabeli WSH_DELIVERY_DETAILS na „Shipped”.
Rejestrowanie
Użyj daty potwierdzenia wysyłki z tabeli WSH_DELIVERY_DETAILS lub WSH_NEW_DELIVERIES.
Typ zdarzenia
explicit
|
|||
|
Zamknięcie zamówienia
|
To działanie oznacza ostateczne zakończenie obsługi zamówienia sprzedaży po pomyślnej wysyłce, zafakturowaniu i zamknięciu wszystkich jego pozycji. Jest to jawna aktualizacja statusu nagłówka zamówienia. | ||
|
Dlaczego to ważne
To główny punkt końcowy potwierdzający pomyślną realizację procesu Order to Cash. Zawiera końcowy timestamp potrzebny do obliczenia całkowitego czasu cyklu dla zrealizowanych zamówień.
Skąd pobrać
Zdarzenie jest rejestrowane w tabeli OE_ORDER_HEADERS_ALL, gdy FLOW_STATUS_CODE zmienia się na „CLOSED”. Timestampem zdarzenia jest LAST_UPDATE_DATE dla tej zmiany statusu.
Rejestrowanie
Timestamp aktualizacji tabeli OE_ORDER_HEADERS_ALL, w której FLOW_STATUS_CODE przyjmuje wartość „CLOSED”.
Typ zdarzenia
explicit
|
|||
|
Zatwierdzenie zamówienia
|
Oznacza formalne potwierdzenie zamówienia sprzedaży, które staje się aktywne i może przejść do kolejnych etapów, takich jak zaopatrzenie i wysyłka. W Oracle EBS jest to jawne działanie zmieniające status zamówienia z „Entered” na „Booked”. | ||
|
Dlaczego to ważne
Zatwierdzenie to ważny etap, który formalnie kieruje zamówienie do realizacji. Opóźnienie między utworzeniem a zatwierdzeniem może wskazywać problemy z wprowadzaniem danych, akceptacją lub wstępną weryfikacją.
Skąd pobrać
Zdarzenie pochodzi z tabeli OE_ORDER_HEADERS_ALL. Występuje, gdy BOOKED_FLAG przyjmuje wartość „Y”, a jego timestamp jest zapisywany w kolumnie BOOKED_DATE.
Rejestrowanie
Użyj kolumny BOOKED_DATE z tabeli OE_ORDER_HEADERS_ALL.
Typ zdarzenia
explicit
|
|||
|
Anulowanie zamówienia
|
Oznacza anulowanie całego zamówienia sprzedaży przed zakończeniem jego realizacji. To jawne zdarzenie kończy workflow obsługi zamówienia. | ||
|
Dlaczego to ważne
To ważny punkt końcowy procesu, związany z wyjątkami. Analiza częstotliwości anulowań, czasu ich występowania i przyczyn pomaga wykrywać utratę przychodów oraz problemy z procesem lub produktem.
Skąd pobrać
Zdarzenie jest rejestrowane w tabeli OE_ORDER_HEADERS_ALL, gdy FLOW_STATUS_CODE ma wartość 'CANCELLED', a CANCELLED_FLAG ma wartość 'Y'. Jako timestamp można wykorzystać LAST_UPDATE_DATE.
Rejestrowanie
Timestamp ustawienia CANCELLED_FLAG na 'Y' w tabeli OE_ORDER_HEADERS_ALL.
Typ zdarzenia
explicit
|
|||
|
Dostarczenie towaru
|
To działanie oznacza, że przesyłka dotarła do klienta. Standardowy Oracle EBS nie rejestruje tego zdarzenia, dlatego zazwyczaj trzeba je wywnioskować lub zaimportować z zewnętrznych systemów przewoźników. | ||
|
Dlaczego to ważne
Zdarzenie jest niezbędne do pomiaru KPI terminowości dostaw i analizy pełnego doświadczenia klienta. Różnica między wysyłką a dostawą pokazuje wyniki pracy przewoźnika.
Skąd pobrać
Wymaga analizy systemów. Dane te nie są dostępne bezpośrednio w Oracle EBS. Należy pobrać je z zewnętrznych źródeł danych przewoźnika lub platform logistycznych zintegrowanych z systemem.
Rejestrowanie
Zdarzenie można wywnioskować z danych przewoźnika lub oszacować na podstawie standardowego czasu transportu od „Goods Shipped”.
Typ zdarzenia
inferred
|
|||
|
Przeprowadzenie kontroli kredytowej
|
To działanie oznacza zakończenie kontroli kredytowej klienta dla danego zamówienia. Często jest rejestrowane w chwili zwolnienia blokady kontroli kredytowej, jeśli została nałożona, co pozwala kontynuować obsługę zamówienia. | ||
|
Dlaczego to ważne
Opóźnienia kontroli kredytowej często tworzą wąskie gardło i wstrzymują cały proces realizacji zamówienia. Monitorowanie tego działania pomaga wykryć nieefektywności w kontrolach finansowych i procesie akceptacji.
Skąd pobrać
Zdarzenie można wywnioskować z tabeli OE_ORDER_HOLDS_ALL, identyfikując timestamp zwolnienia blokady „Credit Check Hold” dla danego nagłówka zamówienia.
Rejestrowanie
Użyj timestampu zwolnienia blokady związanej z kontrolą kredytową z tabeli OE_ORDER_HOLDS_ALL.
Typ zdarzenia
inferred
|
|||
|
Wysłanie faktury do klienta
|
To działanie oznacza przekazanie faktury klientowi w formie papierowej lub elektronicznej. Zazwyczaj trzeba je wywnioskować, ponieważ nie zawsze jest rejestrowane jako osobne zdarzenie po utworzeniu faktury. | ||
|
Dlaczego to ważne
Od tego momentu zaczyna biec uzgodniony termin płatności klienta. Opóźnienie między utworzeniem a wysłaniem faktury może pogorszyć przepływy pieniężne i prowadzić do nieterminowych płatności.
Skąd pobrać
Zdarzenie można wywnioskować z kolumny LAST_PRINTED_DATE w tabeli RA_CUSTOMER_TRX_ALL. W przypadku faktur elektronicznych może być konieczna analiza dzienników zewnętrznego systemu dostarczania dokumentów.
Rejestrowanie
Użyj kolumny LAST_PRINTED_DATE z tabeli RA_CUSTOMER_TRX_ALL lub dzienników narzędzi zewnętrznych.
Typ zdarzenia
inferred
|
|||
|
Zamknięcie pozycji zamówienia
|
Oznacza zakończenie obsługi pojedynczej pozycji zamówienia sprzedaży, w tym wysyłki i fakturowania. Jest to jawna zmiana statusu zarządzana przez workflow. | ||
|
Dlaczego to ważne
Monitorowanie zamknięcia poszczególnych pozycji pomaga analizować częściowe wysyłki i wykrywać problemy dotyczące konkretnych produktów lub ścieżek realizacji, zanim zostanie zamknięte całe zamówienie.
Skąd pobrać
Zdarzenie jest rejestrowane w tabeli OE_ORDER_LINES_ALL, gdy FLOW_STATUS_CODE zmienia się na „CLOSED”. Timestampem może być LAST_UPDATE_DATE dla tej zmiany statusu.
Rejestrowanie
Timestamp aktualizacji tabeli OE_ORDER_LINES_ALL, w której FLOW_STATUS_CODE przyjmuje wartość „CLOSED”.
Typ zdarzenia
explicit
|
|||
|
Zwolnienie do kompletacji
|
To zdarzenie oznacza przekazanie pozycji zamówienia do magazynu, aby można było rozpocząć kompletację. Jawne działanie tworzy listy kompletacyjne i udostępnia zamówienie pracownikom magazynu. | ||
|
Dlaczego to ważne
To działanie rozpoczyna fizyczną realizację zamówienia. Analiza czasu od tego momentu do „Goods Shipped” pokazuje efektywność pracy magazynu i potencjalne wąskie gardła podczas kompletacji.
Skąd pobrać
To jawne zdarzenie rejestrowane w module Oracle Shipping Execution. Można je rozpoznać po zmianie statusu szczegółów dostawy w tabeli WSH_DELIVERY_DETAILS na „Released to Warehouse” lub „Transactable”.
Rejestrowanie
Timestamp zmiany wartości WSH_DELIVERY_DETAILS.RELEASED_STATUS na „S” (Submitted).
Typ zdarzenia
explicit
|
|||
Instrukcje ekstrakcji danych
Gotowi do rozpoczęcia?
Ten szablon zawiera wszystko, czego potrzeba, aby rozpocząć usprawnianie obsługi zamówień sprzedaży w procesie od zamówienia do płatności. Już dziś można zacząć zmieniać proces i zwiększać jego efektywność.
Usprawnij obsługę zamówień sprzedaży w procesie od zamówienia do płatności już dziś!
Wskaż nieefektywne działania i skróć czas procesu od zamówienia do płatności o 30%.
Karta kredytowa nie jest wymagana. Okres próbny trwa 14 dni.