Szablon danych dla procesu obsługi zapotrzebowań zakupowych

Oracle Fusion Financials
Szablon danych dla procesu obsługi zapotrzebowań zakupowych

Szablon danych dla procesu obsługi zapotrzebowań zakupowych

Ten szablon pomaga zebrać dane potrzebne do analizy procesu obsługi zapotrzebowań zakupowych. Zawiera listę najważniejszych atrybutów i działań do śledzenia oraz praktyczne wskazówki dotyczące pobierania danych z Oracle Fusion Financials. Na tej podstawie można przygotować dziennik zdarzeń do analizy process mining.
  • Zalecane atrybuty do zebrania
  • Najważniejsze działania do śledzenia
  • Wskazówki dotyczące pobierania 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 obsługi zapotrzebowań zakupowych

To zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby przeprowadzić analizę procesu obsługi zapotrzebowań zakupowych.
5 Wymagane 7 Zalecane 10 Opcjonalne
Nazwa Opis
Czas zdarzenia
EventTime
Znacznik czasu wskazujący, kiedy wystąpiła dana czynność.
Opis

Czas zdarzenia określa dokładną datę i godzinę wykonania danej czynności. Ten znacznik czasu pozwala uporządkować zdarzenia w kolejności chronologicznej w ramach case. Pochodzi z dat utworzenia lub ostatniej aktualizacji albo ze znaczników czasu konkretnych działań w systemie.

W analizie czas zdarzenia służy do obliczania wszystkich miar opartych na czasie, takich jak czasy cyklu między czynnościami, czas oczekiwania i łączny czas trwania case. Pomaga wykrywać wąskie gardła, mierzyć wyniki względem SLA i analizować przebieg procesu obsługi zapotrzebowań w czasie.

Dlaczego to ważne

Atrybut ten jest niezbędny do obliczania KPI związanych z czasem, prawidłowego porządkowania zdarzeń oraz analizy wyników procesu i wąskich gardeł.

Skąd pobrać

Zazwyczaj dane pochodzą z kolumny LAST_UPDATE_DATE lub CREATION_DATE powiązanej z transakcją albo zmianą statusu. Kolumny te często znajdują się w tabelach takich jak POR_REQUISITION_HEADERS_ALL lub w tabelach historii workflow.

Przykłady
2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
Czynność
ActivityName
Nazwa zdarzenia biznesowego, które wystąpiło na danym etapie procesu obsługi zapotrzebowania.
Opis

Czynność oznacza konkretny etap lub kamień milowy w cyklu życia zapotrzebowania zakupu. Przykłady: „Utworzono zapotrzebowanie”, „Zaakceptowano etap akceptacji” lub „Utworzono zamówienie zakupu”. Czynności są wyznaczane na podstawie zmian statusu, działań użytkowników lub zdarzeń systemowych zapisanych w dziennikach audytowych albo tabelach transakcji systemu źródłowego.

Atrybut ten jest niezbędny do utworzenia mapy procesu, która pokazuje przebieg zapotrzebowań. Analiza kolejności i częstotliwości czynności pomaga wykryć typowe ścieżki, wąskie gardła, pętle poprawek i odstępstwa od standardowej procedury.

Dlaczego to ważne

Stanowi podstawę mapy procesu, która pozwala przedstawić i analizować workflow obsługi zapotrzebowania.

Skąd pobrać

Dane pochodzą z zapisów zmian statusu w tabelach takich jak POR_REQUISITION_HEADERS_ALL, historii transakcji lub dzienników audytowych workflow, na przykład FA_FUSION_SOAINFRA.WFTASK.

Przykłady
Utworzenie zapotrzebowaniaZatwierdzenie na etapie workflowOdrzucenie zapotrzebowaniaUtworzenie zamówienia zakupu
Identyfikator Purchase Requisition
PurchaseRequisitionId
Unikalny identyfikator zapotrzebowania zakupowego, używany jako identyfikator sprawy w procesie.
Opis

Identyfikator zapotrzebowania zakupu łączy wszystkie działania związane z konkretnym wnioskiem o towary lub usługi. Każde zapotrzebowanie otrzymuje unikalny identyfikator podczas tworzenia. Pozostaje on niezmienny przez cały cykl życia zapotrzebowania.

W process mining atrybut ten służy do grupowania powiązanych zdarzeń, takich jak utworzenie, przesłanie, kolejne etapy akceptacji i zamknięcie, w jeden case. Dzięki temu można analizować przebieg zapotrzebowania od początku do końca, tworzyć mapy procesów, obliczać czasy cyklu i porównywać warianty dla poszczególnych wniosków.

Dlaczego to ważne

To podstawowy atrybut do śledzenia zapotrzebowania od początku do końca oraz prowadzenia analiz na poziomie case i obliczania KPI.

Skąd pobrać

Zazwyczaj jest to klucz główny w tabeli nagłówków zapotrzebowań, na przykład POR_REQUISITION_HEADERS_ALL.REQUISITION_HEADER_ID w Oracle Fusion Financials.

Przykłady
100234810023491002350
Data ostatniej aktualizacji danych
LastDataUpdate
Znacznik czasu ostatniego odświeżenia danych z systemu źródłowego.
Opis

Atrybut wskazuje datę i godzinę ostatniego wyodrębnienia danych z Oracle Fusion Financials. Dotyczy całego zbioru danych, a nie poszczególnych zdarzeń.

Analitycy mogą sprawdzić, jak aktualne są dane i kiedy uwzględniono najnowsze transakcje. To ważna metadana przy raportowaniu w dashboard oraz przy weryfikacji, czy analizy opierają się na aktualnych informacjach.

Dlaczego to ważne

Informuje o aktualności danych, dzięki czemu można ocenić, czy analizy uwzględniają najnowsze dostępne informacje.

Skąd pobrać

Znacznik czasu jest generowany i zapisywany podczas wyodrębniania danych, zwykle przez narzędzie ETL lub potok danych.

Przykłady
2023-10-27T02:00:00Z
System źródłowy
SourceSystem
System informatyczny, z którego wyodrębniono dane.
Opis

Atrybut wskazuje źródło danych o procesie. W tym modelu danych będzie to zawsze „Oracle Fusion Financials”.

W środowiskach korzystających z wielu systemów ERP lub systemów zintegrowanych pole to pomaga ustalić pochodzenie danych, rozwiązywać problemy i dbać o ich jakość. Wskazuje, z jakiego źródła pochodzą analizowane zdarzenia procesu.

Dlaczego to ważne

Podaje istotny kontekst dotyczący pochodzenia danych, co ma znaczenie dla zarządzania danymi i łączenia informacji z wielu systemów.

Skąd pobrać

Wartość statyczna dodawana podczas wyodrębniania i przekształcania danych w celu oznaczenia źródła zbioru danych.

Przykłady
Oracle Fusion Financials
Dział
DepartmentName
Dział, do którego należy wnioskodawca.
Opis

Atrybut wskazuje jednostkę organizacyjną osoby, która utworzyła zapotrzebowanie, na przykład finanse, IT lub marketing. Zazwyczaj dane pochodzą z profilu wnioskodawcy w systemie HR.

Analiza według działu to częsty sposób segmentowania danych o procesie. Pomaga wykryć różnice między działami, takie jak wyższy odsetek odrzuceń lub dłuższy czas cyklu. Na tej podstawie można zaplanować działania usprawniające dla konkretnych obszarów. To jeden z wymiarów dashboard „Wskaźniki wyników wnioskodawców”.

Dlaczego to ważne

Umożliwia analizę procesu według jednostki biznesowej i ujawnia różnice w przebiegu, wynikach oraz zgodności w poszczególnych działach.

Skąd pobrać

Zazwyczaj dane pochodzą z profilu wnioskodawcy. Może być konieczne połączenie tabeli zapotrzebowań z tabelą HR lub katalogiem użytkowników zawierającym informacje o dziale.

Przykłady
Dział ITFinanseOperacjeMarketing
Imię i nazwisko wnioskodawcy
RequesterName
Imię i nazwisko pracownika, który utworzył i przesłał zapotrzebowanie zakupu.
Opis

Atrybut wskazuje osobę, która zainicjowała wniosek o towary lub usługi. Informacja ta jest zwykle zapisywana na początku procesu, podczas tworzenia zapotrzebowania.

Analiza wyników procesu według wnioskodawcy jest ważna dla dashboard „Wskaźniki wyników wnioskodawców”. Pozwala wskazać użytkowników lub grupy, które mogą potrzebować dodatkowego szkolenia, na przykład ze względu na częste zmiany, odrzucenia lub długi czas realizacji wniosków. Dzięki temu można spojrzeć na proces z perspektywy osób, które go inicjują.

Dlaczego to ważne

Umożliwia analizę wyników według wnioskodawcy, pomaga określić potrzeby szkoleniowe i wskazać sprawnie działających użytkowników lub działy.

Skąd pobrać

Dane pochodzą z nagłówka zapotrzebowania. Często trzeba połączyć identyfikator wnioskodawcy z tabelą pracowników lub użytkowników. Warto sprawdzić pola związane z PREPARER_ID w POR_REQUISITION_HEADERS_ALL i połączyć je z PER_ALL_PEOPLE_F.

Przykłady
Jan KowalskiAnna NowakEmilia Jones
Jednostka biznesowa
BusinessUnit
Konkretna jednostka biznesowa w organizacji, do której należy zapotrzebowanie.
Opis

Jednostka biznesowa to odrębna jednostka prawna lub funkcjonalna firmy, na potrzeby której składane jest zapotrzebowanie. Jest nadrzędna wobec działu.

Analiza danych według jednostki biznesowej pozwala porównywać wyniki różnych części organizacji na wyższym poziomie. Kierownictwo może sprawdzić, czy nieefektywności dotyczą pojedynczych obszarów, czy całej firmy, i zdecydować, gdzie skupić działania usprawniające. To ważny wymiar filtrowania w większości dashboardów i KPI.

Dlaczego to ważne

Zapewnia ogólny kontekst organizacyjny i pozwala porównywać wyniki oraz prowadzić analizy strategiczne w różnych częściach firmy.

Skąd pobrać

To podstawowe pole organizacyjne w Oracle Fusion, zwykle dostępne w nagłówku zapotrzebowania w tabelach takich jak POR_REQUISITION_HEADERS_ALL.

Przykłady
Jednostka biznesowa Ameryka PółnocnaJednostka biznesowa EuropaCentrala firmy
Łączna kwota zapotrzebowania
RequisitionTotalAmount
Łączna wartość pieniężna zapotrzebowania zakupu.
Opis

Atrybut oznacza sumę wartości wszystkich pozycji w jednym zapotrzebowaniu zakupu. Pozwala ocenić finansową skalę każdego wniosku.

W process mining łączna kwota służy do wielu rodzajów analiz. Można na przykład filtrować zapotrzebowania o wysokiej wartości, które często podlegają innym ścieżkom akceptacji lub dokładniejszej kontroli. W dashboard można sprawdzić, jak wartość zapotrzebowania wiąże się z miarami procesu, takimi jak czas cyklu lub odsetek odrzuceń.

Dlaczego to ważne

Dostarcza kontekstu finansowego, pozwala analizować proces według wartości i ustalać priorytety usprawnień oraz sprawdzać, jak kwota zapotrzebowania wpływa na przebieg procesu.

Skąd pobrać

Wartość znajduje się w nagłówku zapotrzebowania, często w polu takim jak REQUISITION_TOTAL w POR_REQUISITION_HEADERS_ALL. Można ją też obliczyć, sumując kwoty pozycji z POR_REQUISITION_LINES_ALL.

Przykłady
550.0012500.7599.99
Powód odrzucenia
RejectionReason
Powód podany przez osobę akceptującą, gdy zapotrzebowanie lub etap akceptacji zostaje odrzucony.
Opis

Po odrzuceniu zapotrzebowania osoba akceptująca zwykle podaje powód, wybierając pozycję z listy lub wpisując własny komentarz. Atrybut zapisuje to uzasadnienie.

Jest ważny przy analizie przyczyn problemów w procesie. Zasila dashboard „Trendy zmian i odrzuceń”, pokazując, dlaczego wnioski są odrzucane. Analiza powodów pomaga wykryć powtarzające się problemy, takie jak nieprawidłowe konto księgi głównej, przekroczenie budżetu lub naruszenie zasad. Można wtedy podjąć działania, na przykład przeprowadzić szkolenie lub wprowadzić kontrole systemowe.

Dlaczego to ważne

Pokazuje, dlaczego zapotrzebowania są odrzucane, co pozwala ograniczyć poprawki i zwiększyć odsetek spraw obsługiwanych bez dodatkowych interwencji.

Skąd pobrać

Dane pochodzą z komentarzy w workflow lub pól z kodem przyczyny odrzucenia w dzienniku audytowym workflow, na przykład z tabel FA_FUSION_SOAINFRA.WFTASK lub powiązanych tabel komentarzy.

Przykłady
Nieprawidłowe konto księgi głównejPrzekroczono budżet centrum kosztówWybrano dostawcę spoza listy preferowanychZduplikowany wniosek
Status zapotrzebowania
RequisitionStatus
Bieżący lub końcowy status zapotrzebowania zakupu.
Opis

Atrybut wskazuje bieżący stan zapotrzebowania lub jego wynik końcowy, na przykład „Zaakceptowane”, „Odrzucone”, „W trakcie” lub „Zamknięte”. Na podstawie tego pola często wyznacza się wiele czynności w dzienniku zdarzeń.

Atrybut ten zasila dashboard „Przegląd statusów zapotrzebowań”, który pokazuje bieżące obciążenie i zaległości. Służy też do obliczania KPI opartych na wyniku, takich jak odsetek odrzuconych zapotrzebowań, przez filtrowanie case zakończonych określonym statusem.

Dlaczego to ważne

Pokazuje bieżący stan zapotrzebowań i pozwala ustalić wyniki końcowe na potrzeby obliczania KPI.

Skąd pobrać

Pole znajduje się w tabeli nagłówków zapotrzebowań, zwykle jako DOCUMENT_STATUS lub APPROVAL_STATUS w POR_REQUISITION_HEADERS_ALL.

Przykłady
ZAAKCEPTOWANEW TRAKCIEODRZUCONEWYCOFANE
Wymagana data dostawy
RequiredByDate
Data, do której wnioskodawca potrzebuje towarów lub usług.
Opis

Wnioskodawca podaje tę datę jako termin otrzymania zamówionych pozycji. Jest to wewnętrzny cel SLA dla procesu zakupowego.

Atrybut ten stanowi podstawę dashboard „Terminowość względem wymaganej daty dostawy” oraz KPI „Odsetek realizacji do wymaganej daty”. Porównanie tej daty z datą utworzenia zamówienia zakupu lub datą odbioru towarów pokazuje, w jakim stopniu proces zakupowy spełnia potrzeby klientów wewnętrznych i pomaga wykryć powtarzające się opóźnienia.

Dlaczego to ważne

Pozwala mierzyć wyniki procesu względem wewnętrznych terminów i sprawdzać, czy zakupy zaspokajają potrzeby firmy na czas.

Skąd pobrać

Zazwyczaj jest zapisana na poziomie pozycji zapotrzebowania, w tabelach takich jak POR_REQUISITION_LINES_ALL, w polu NEED_BY_DATE.

Przykłady
2023-11-012023-12-152024-01-31
Czy obsłużono bez dodatkowych interwencji
IsStraightThrough
Flaga wskazująca, czy zapotrzebowanie zaakceptowano bez zmian i odrzuceń.
Opis

Ta obliczana flaga wskazuje zapotrzebowania, które przeszły od przesłania do akceptacji bez pętli poprawek, takich jak zmiany lub odrzucenia. Oznacza prawidłowy przebieg procesu dla danego case.

Atrybut ten stanowi podstawę KPI „Odsetek zapotrzebowań obsłużonych bez dodatkowych interwencji”. Analiza cech takich zapotrzebowań, na przykład działów, wnioskodawców lub rodzajów, może ujawnić dobre praktyki i możliwości automatyzacji. Analiza pozostałych przypadków pomaga ustalić główne przyczyny nieefektywności.

Dlaczego to ważne

Bezpośrednio mierzy sprawność procesu i stanowi podstawę KPI „Odsetek zapotrzebowań obsłużonych bez dodatkowych interwencji”, pomagając wskazać przyczyny poprawek.

Skąd pobrać

Atrybut jest obliczany podczas przekształcania danych. Flaga ma wartość true, jeśli nie występują czynności „Zmieniono zapotrzebowanie” ani „Odrzucono etap akceptacji”.

Przykłady
truefalse
Czy wykonano automatycznie
IsAutomated
Flaga wskazująca, czy system wykonał czynność automatycznie.
Opis

Atrybut wskazuje zdarzenia procesu wykonane przez użytkownika systemowego lub agenta automatyzującego, a nie przez człowieka. Mogą to być na przykład systemowe zmiany statusu lub automatyczna akceptacja pozycji o niskiej wartości.

Analiza tego atrybutu pozwala określić poziom automatyzacji procesu. Można porównać szybkość i sprawność czynności automatycznych z ręcznymi oraz wskazać kolejne możliwości automatyzacji.

Dlaczego to ważne

Pomaga mierzyć poziom automatyzacji procesu i wskazywać czynności ręczne, które można zautomatyzować.

Skąd pobrać

Wartość jest wyznaczana przez sprawdzenie, czy użytkownik przypisany do czynności jest kontem systemowym lub usługowym. Wymaga to listy znanych identyfikatorów użytkowników systemowych.

Przykłady
truefalse
Czy zmieniono
IsAmendedFlag
Wartość logiczna ustawiona na true, jeśli zapotrzebowanie zmieniono co najmniej raz.
Opis

Ten obliczany atrybut wskazuje, czy zapotrzebowanie zmieniono po jego pierwszym przesłaniu. Wartość jest wyznaczana na podstawie obecności czynności „Zmieniono zapotrzebowanie” w historii case.

Flaga ułatwia analizę i obliczanie KPI. Służy bezpośrednio do obliczania KPI „Odsetek zmienionych zapotrzebowań” oraz wskazywania case, które nie zostały obsłużone bez dodatkowych interwencji. Ułatwia filtrowanie i porównywanie miar procesu dla zapotrzebowań zmienionych i niezmienionych.

Dlaczego to ważne

Ułatwia obliczanie odsetka zmian i porównywanie zapotrzebowań zmienionych z niezmienionymi.

Skąd pobrać

Atrybutu nie ma w systemie źródłowym. Jest obliczany podczas przekształcania danych na podstawie obecności czynności związanych ze zmianą w dzienniku zdarzeń.

Przykłady
truefalse
Nazwa dostawcy
SupplierName
Nazwa sugerowanego lub wstępnie wybranego dostawcy towarów lub usług.
Opis

Atrybut wskazuje dostawcę, od którego mają zostać kupione towary lub usługi. Dostawcę może wskazać wnioskodawca albo system na podstawie katalogów lub wcześniejszych umów.

Analiza według dostawcy może ujawnić istotne wzorce zakupowe. Można na przykład sprawdzić, czy zapotrzebowania dotyczące określonych dostawców są dłużej akceptowane lub częściej odrzucane. Informacje te mogą pomóc w zarządzaniu relacjami z dostawcami i planowaniu zakupów.

Dlaczego to ważne

Umożliwia analizę wyników procesu według dostawcy, co może pomóc w planowaniu zakupów i zarządzaniu relacjami z dostawcami.

Skąd pobrać

Pole znajduje się w tabeli pozycji zapotrzebowania POR_REQUISITION_LINES_ALL. Często jest powiązane przez VENDOR_ID z tabelą dostawców, taką jak POZ_SUPPLIERS.

Przykłady
Office Supplies Inc.Global Tech SolutionsCreative Marketing Agency
Nazwa użytkownika
UserName
Nazwa użytkownika, który wykonał daną czynność, na przykład osoby akceptującej lub edytującej.
Opis

Imię i nazwisko wnioskodawcy wskazuje osobę inicjującą proces, a nazwa użytkownika określa, kto wykonał konkretne zdarzenie, na przykład zaakceptował lub odrzucił wniosek. Ma to szczególne znaczenie w workflow z wieloma etapami akceptacji, w które zaangażowane są różne osoby.

Atrybut ten pomaga analizować wąskie gardła w procesie akceptacji oraz mierzyć wyniki poszczególnych osób i zespołów akceptujących. Wspiera dashboard „Wąskie gardła w workflow akceptacji”, ponieważ pozwala analizować czas obsługi przez każdą osobę w łańcuchu akceptacji.

Dlaczego to ważne

Wskazuje osobę odpowiedzialną za każde zdarzenie. Jest to ważne przy analizie czasu przekazania sprawy, wyników osób akceptujących i przydziału zasobów.

Skąd pobrać

Dane pochodzą z historii workflow lub tabel dziennika audytowego, takich jak FA_FUSION_SOAINFRA.WFTASK, w których zapisywany jest użytkownik wykonujący dane zadanie.

Przykłady
Dawid LeeZuzanna ChenMichał Brown
Numer zamówienia zakupu
PurchaseOrderNumber
Identyfikator zamówienia zakupu utworzonego na podstawie zaakceptowanego zapotrzebowania.
Opis

Atrybut łączy zapotrzebowanie zakupu z utworzonym na jego podstawie zamówieniem zakupu. Po pełnej akceptacji zapotrzebowanie jest zwykle przekształcane w jedno lub więcej zamówień wysyłanych do dostawcy.

Identyfikator pozwala śledzić dalszy przebieg procesu po złożeniu zapotrzebowania. Umożliwia obliczenie KPI „Czas od zapotrzebowania do zamówienia zakupu” i zasila dashboard „Czas cyklu od zapotrzebowania do zamówienia zakupu”. Pozwala też połączyć dane o zapotrzebowaniu z danymi o późniejszych etapach obsługi zamówienia i faktury, aby analizować cały proces Purchase-to-Pay.

Dlaczego to ważne

Łączy zapotrzebowanie z późniejszym zamówieniem zakupu, umożliwiając pomiar czasu od zapotrzebowania do zamówienia oraz analizę całego procesu.

Skąd pobrać

Informacja jest dostępna po utworzeniu zamówienia zakupu. Zazwyczaj można ją znaleźć w odwołaniach do zapotrzebowania w tabelach dystrybucji zamówień, takich jak PO_DISTRIBUTIONS_ALL, które wskazują powiązaną pozycję zapotrzebowania.

Przykłady
PO-2023-5832PO-2023-5833PO-2023-5834
Opis pozycji
ItemDescription
Opis produktu lub usługi zamawianych w ramach pozycji zapotrzebowania.
Opis

Atrybut zawiera tekstowy opis zamawianej pozycji. Podaje szczegóły dotyczące wnioskowanych towarów lub usług.

Opis pozycji często ma nieustrukturyzowaną formę, ale dostarcza cennych informacji do analizy. Można go użyć do filtrowania zapotrzebowań dotyczących konkretnych zakupów, których nie da się wyodrębnić na podstawie rodzaju zapotrzebowania. Analityk może na przykład wyszukać wszystkie zapotrzebowania zawierające frazę „licencja na oprogramowanie”, aby sprawdzić ich przebieg i czas cyklu.

Dlaczego to ważne

Podaje szczegóły dotyczące zamawianych produktów lub usług, umożliwiając dokładniejsze filtrowanie i analizę konkretnych zakupów.

Skąd pobrać

Pole znajduje się w tabeli pozycji zapotrzebowania POR_REQUISITION_LINES_ALL, na przykład w ITEM_DESCRIPTION.

Przykłady
Laptop 15 cali, 16 GB RAMUsługi konsultingowe, projekt na IV kwartałCoroczne odnowienie serwisu oprogramowania
Rodzaj zapotrzebowania
RequisitionType
Kategoria zapotrzebowania, na przykład wniosek o towary lub usługi.
Opis

Atrybut klasyfikuje zapotrzebowanie według rodzaju zamawianych produktów lub usług. Typowe kategorie to towary, usługi i wydatki inwestycyjne. Rodzaj może wpływać na wymaganą ścieżkę akceptacji i strategię zakupową.

Rodzaj zapotrzebowania to przydatny wymiar filtrowania i porównywania danych. Można na przykład sprawdzić, czy akceptacja zapotrzebowań na usługi trwa dłużej niż w przypadku zapotrzebowań na towary. Analiza pokazuje, czy różne rodzaje wniosków wiążą się z odmiennym przebiegiem procesu lub wąskimi gardłami.

Dlaczego to ważne

Pozwala podzielić analizę według rodzaju zakupu i sprawdzić różnice między procesem zakupu towarów i usług.

Skąd pobrać

Rodzaj jest często określany na podstawie typu lub kategorii pozycji wybranej podczas tworzenia zapotrzebowania. Może być zapisany w tabeli pozycji zapotrzebowania POR_REQUISITION_LINES_ALL.

Przykłady
TowaryUsługiWydatki inwestycyjne
Ścieżka akceptacji w workflow
ApprovalWorkflowPath
Zdefiniowana kolejność osób lub grup akceptujących zapotrzebowanie.
Opis

Atrybut określa standardową, oczekiwaną ścieżkę akceptacji zapotrzebowania zgodnie z zasadami firmy. Uwzględnia takie czynniki jak kwota, rodzaj zapotrzebowania i dział. Opisuje model procesu docelowego.

Ścieżka akceptacji w workflow jest podstawą analizy zgodności i realizacji procesu. Zasila dashboard „Analiza zgodności i odstępstw” oraz KPI „Wskaźnik zgodności zapotrzebowań”, ponieważ pozwala porównać faktyczne etapy akceptacji z wymaganą ścieżką. Odstępstwa mogą wskazywać na naruszenie zasad lub nieefektywność procesu.

Dlaczego to ważne

Umożliwia sprawdzenie zgodności przez porównanie faktycznego przebiegu procesu z wymaganą hierarchią akceptacji i wskazanie zapotrzebowań, które jej nie spełniają.

Skąd pobrać

Informacje te są skonfigurowane w Oracle Fusion BPM Worklist lub Approval Management Engine (AMX). Ustalenie zdefiniowanej ścieżki dla każdego zapotrzebowania może być złożone i wymagać odpytywania tabel konfiguracyjnych.

Przykłady
Kierownik > Dyrektor > Wiceprezes ds. finansówWłaściciel centrum kosztów > Dział bezpieczeństwa ITKierownik > Kierownik działu
Waluta
CurrencyCode
Kod waluty, w której podano kwotę zapotrzebowania, na przykład USD lub EUR.
Opis

Atrybut określa walutę, w której wyrażono łączną kwotę zapotrzebowania. W organizacjach działających na wielu rynkach zapotrzebowania mogą być składane w różnych walutach.

Informacja ta jest niezbędna do prawidłowej interpretacji i agregowania danych finansowych. W analizach kwot należy uwzględnić kod waluty, aby poprawnie je porównywać, na przykład przez filtrowanie do jednej waluty lub przeliczenie wszystkich kwot na wspólną walutę.

Dlaczego to ważne

Pozwala prawidłowo analizować i raportować dane finansowe, szczególnie w międzynarodowych organizacjach korzystających z wielu walut.

Skąd pobrać

Zazwyczaj znajduje się w tabeli nagłówków zapotrzebowań, obok pól z kwotami, na przykład w POR_REQUISITION_HEADERS_ALL.

Przykłady
USDEURGBPJPY
Wymagane Zalecane Opcjonalne

Działania w procesie obsługi zapotrzebowań zakupowych

To najważniejsze kroki i punkty kontrolne, które warto uwzględnić w dzienniku zdarzeń, aby dokładnie odkryć przebieg procesu obsługi zapotrzebowań zakupowych.
6 Zalecane 6 Opcjonalne
Działanie Opis
Odrzucenie zapotrzebowania
Oznacza ostateczne odrzucenie zapotrzebowania i zakończenie procesu dla danego wniosku. Zdarzenie można wywnioskować ze zmiany ogólnego statusu zapotrzebowania na „Rejected”.
Dlaczego to ważne

To końcowy etap nieudanej sprawy. Analiza takich przypadków jest niezbędna do zrozumienia KPI „Requisition Rejection Rate” i przyczyn niepowodzeń.

Skąd pobrać

Zdarzenie można wywnioskować ze zmiany statusu dokumentu na „REJECTED” w tabeli POR_REQUISITION_HEADERS_ALL.

Rejestrowanie

Ustal znacznik czasu pierwszego ustawienia statusu dokumentu na „Rejected”.

Typ zdarzenia inferred
Przesłanie zapotrzebowania
Oznacza przesłanie przez użytkownika wypełnionego zapotrzebowania do workflow zatwierdzania. Zdarzenie jest rejestrowane, gdy status zapotrzebowania zmienia się z „Incomplete” lub „Draft” na status oznaczający oczekiwanie na zatwierdzenie.
Dlaczego to ważne

To działanie rozpoczyna cykl zatwierdzania. Jest ważnym punktem pomiaru czasu zatwierdzania zapotrzebowania i całkowitego czasu realizacji.

Skąd pobrać

Zdarzenie można wywnioskować ze zmiany statusu w tabeli POR_REQUISITION_HEADERS_ALL, na przykład na „PENDING APPROVAL”. Data przesłania jest często zapisywana również w osobnym polu.

Rejestrowanie

Ustal znacznik czasu pierwszej zmiany statusu dokumentu na „Pending Approval”.

Typ zdarzenia inferred
Utworzenie zamówienia zakupu
Zdarzenie występuje, gdy zatwierdzona pozycja zapotrzebowania zostaje wykorzystana do utworzenia zamówienia zakupu. Łączy proces obsługi zapotrzebowania z kolejnym etapem procesu zakupowego.
Dlaczego to ważne

To ważny punkt pomiaru czasu od zapotrzebowania do PO. Opóźnienia na tym etapie wskazują na wąskie gardła przy przekazywaniu sprawy z etapu zatwierdzania do zakupów.

Skąd pobrać

Jest to jawne zdarzenie. Powiązanie zapotrzebowania z zamówieniem zakupu jest przechowywane w tabelach takich jak PO_LINE_LOCATIONS_ALL, która zawiera odwołanie do identyfikatora źródłowej pozycji zapotrzebowania.

Rejestrowanie

Znajdź datę utworzenia zamówienia zakupu powiązanego z danym identyfikatorem Requisition ID.

Typ zdarzenia explicit
Utworzenie zapotrzebowania
Rozpoczyna proces zakupowy. Użytkownik po raz pierwszy zapisuje nowe zapotrzebowanie zakupowe. Zdarzenie jest zwykle rejestrowane w systemie jako jawny wpis z odpowiednim znacznikiem czasu.
Dlaczego to ważne

To główne zdarzenie rozpoczynające proces obsługi zapotrzebowania. Analiza czasu od utworzenia do przesłania może ujawnić opóźnienia w formalizowaniu wniosków.

Skąd pobrać

Zdarzenie jest rejestrowane w tabeli POR_REQUISITION_HEADERS_ALL na podstawie kolumny creation_date, gdy zostaje wygenerowany nowy identyfikator Requisition ID.

Rejestrowanie

Użyj znacznika czasu utworzenia rekordu nagłówka zapotrzebowania.

Typ zdarzenia explicit
Zamknięcie zapotrzebowania
Oznacza zakończenie cyklu życia zapotrzebowania. Wszystkie jego pozycje zostały zrealizowane, na przykład przekształcone w PO, lub anulowane. Zdarzenie można wywnioskować z końcowej zmiany statusu.
Dlaczego to ważne

To główne zdarzenie oznaczające pomyślne zakończenie procesu. Potwierdza, że zapotrzebowanie zostało w pełni obsłużone i nie wymaga dalszych działań.

Skąd pobrać

Zdarzenie można wywnioskować ze zmiany statusu nagłówka zapotrzebowania na „CLOSED” w tabeli POR_REQUISITION_HEADERS_ALL.

Rejestrowanie

Ustal znacznik czasu zmiany statusu dokumentu zapotrzebowania na „Closed”.

Typ zdarzenia inferred
Zatwierdzenie zapotrzebowania
Oznacza końcowe zatwierdzenie zapotrzebowania zakupowego po pomyślnym przejściu wszystkich etapów workflow. Zdarzenie można wywnioskować ze zmiany ogólnego statusu zapotrzebowania na „Approved”.
Dlaczego to ważne

To ważny punkt procesu, który oznacza, że zapotrzebowanie jest gotowe do realizacji zakupów. Wyznacza koniec okresu mierzonego jako całkowity czas zatwierdzania zapotrzebowania.

Skąd pobrać

Zdarzenie można wywnioskować ze zmiany statusu dokumentu na „APPROVED” w tabeli POR_REQUISITION_HEADERS_ALL. Data zmiany statusu jest czasem zdarzenia.

Rejestrowanie

Ustal znacznik czasu pierwszego ustawienia statusu dokumentu na „Approved”.

Typ zdarzenia inferred
Odrzucenie na etapie workflow
Osoba zatwierdzająca odrzuca zapotrzebowanie. Zwykle wraca ono wtedy do osoby przygotowującej w celu poprawy albo proces zostaje zakończony. Działanie jest jawnie rejestrowane w historii workflow.
Dlaczego to ważne

To działanie jest jedną z głównych przyczyn dodatkowej pracy i opóźnień. Analiza odrzuceń pomaga wykryć problemy ze zgodnością, budżetem lub niejasnym uzasadnieniem.

Skąd pobrać

Dane pochodzą z historii działań związanych z zatwierdzaniem zapotrzebowania. System workflow rejestruje działanie „REJECT” wraz ze znacznikiem czasu.

Rejestrowanie

Użyj znacznika czasu działania „REJECT” z dziennika historii działań workflow.

Typ zdarzenia explicit
Rozpoczęcie etapu zatwierdzania
Oznacza moment przypisania zapotrzebowania do konkretnej osoby zatwierdzającej lub grupy zatwierdzającej w workflow. Informacja pochodzi z dziennika transakcji silnika workflow.
Dlaczego to ważne

To działanie jest niezbędne do obliczenia czasu oczekiwania na każdym etapie zatwierdzania. Pomaga wskazać wąskie gardła związane z konkretnymi osobami lub poziomami zatwierdzania.

Skąd pobrać

Dane pochodzą z tabel workflow Oracle Fusion, w których rejestrowane są zadania przypisane użytkownikom. Wykorzystywany jest znacznik czasu przypisania zadania do zatwierdzenia.

Rejestrowanie

Użyj znacznika czasu utworzenia zadania w historii workflow dla danego zapotrzebowania.

Typ zdarzenia explicit
Wycofanie zapotrzebowania
Zdarzenie występuje, gdy wnioskodawca anuluje lub wycofuje przesłane zapotrzebowanie przed jego pełnym zatwierdzeniem. Zwykle jest to jawne działanie użytkownika, które zmienia status.
Dlaczego to ważne

Śledzenie wycofań pomaga ustalić przyczyny przedwczesnego zakończenia procesu, takie jak zmiana potrzeb biznesowych lub poprawianie błędów po przesłaniu.

Skąd pobrać

Zdarzenie można wywnioskować ze zmiany statusu na „WITHDRAWN” w tabeli POR_REQUISITION_HEADERS_ALL. Działanie jest zapisywane w historii operacji dotyczących zapotrzebowania.

Rejestrowanie

Wykryj znacznik czasu zmiany statusu zapotrzebowania na „Withdrawn”.

Typ zdarzenia inferred
Zatwierdzenie na etapie workflow
Oznacza zatwierdzenie zapotrzebowania przez konkretną osobę na przypisanym jej etapie workflow. Zdarzenie jest jawnie rejestrowane w historii zatwierdzania.
Dlaczego to ważne

Śledzenie poszczególnych etapów zatwierdzania pozwala odwzorować rzeczywistą ścieżkę i zmierzyć czas obsługi na każdym poziomie hierarchii.

Skąd pobrać

Dane pochodzą z historii działań związanych z zatwierdzaniem zapotrzebowania, zwykle przechowywanej w tabelach workflow (WF) lub Human Capital Management (HCM), które obsługują hierarchie zatwierdzania.

Rejestrowanie

Użyj znacznika czasu działania „APPROVE” z dziennika historii działań workflow.

Typ zdarzenia explicit
Zmiana zapotrzebowania
Zdarzenie oznacza, że użytkownik zmienił zapotrzebowanie po jego pierwszym przesłaniu. Często wymaga to ponownego rozpoczęcia procesu zatwierdzania. Można je wykryć, śledząc zmiany ważnych pól danych lub utworzenie nowej wersji zapotrzebowania.
Dlaczego to ważne

Częste zmiany wskazują na problemy z jakością danych lub zmieniające się wymagania, co prowadzi do dodatkowej pracy i opóźnień. To zdarzenie bezpośrednio wspiera pomiar KPI „Requisition Amendment Rate”.

Skąd pobrać

Zdarzenie można wywnioskować, śledząc numery wersji zapotrzebowania lub wykrywając zmianę statusu na „Incomplete” po jego przesłaniu. Modyfikacje mogą być również rejestrowane w dziennikach zmian lub tabelach ścieżki audytu.

Rejestrowanie

Ustal znaczniki czasu utworzenia nowych wersji tego samego zapotrzebowania po jego przesłaniu.

Typ zdarzenia inferred
Zwrócenie zapotrzebowania do poprawy
Osoba zatwierdzająca zwraca zapotrzebowanie do osoby przygotowującej, aby uzyskać dodatkowe informacje lub wprowadzić drobne poprawki, ale formalnie go nie odrzuca. Zwykle jest to jawne działanie w systemie workflow.
Dlaczego to ważne

Zdarzenie wskazuje na potrzebę wyjaśnień i rozpoczyna pętlę poprawek, która wydłuża czas realizacji. Rozróżnienie zwrotów od odrzuceń pozwala lepiej zrozumieć problemy w procesie.

Skąd pobrać

Dane pochodzą z historii działań związanych z zatwierdzaniem zapotrzebowania. System workflow rejestruje działanie „RETURN” lub podobne wraz ze znacznikiem czasu.

Rejestrowanie

Użyj znacznika czasu działania „RETURN” lub „Request for Information” z historii workflow.

Typ zdarzenia explicit
Zalecane Opcjonalne

Instrukcje pobierania danych

Jak pobrać dane z Oracle Fusion Financials

Gotowi do rozpoczęcia?

Skorzystaj z tego szablonu, aby rozpocząć usprawnianie procesu obsługi zapotrzebowań zakupowych i znaleźć możliwości zwiększenia efektywności. Przygotuj się na usprawnienie operacji zakupowych.

Skróć czas obsługi zapotrzebowań zakupowych o 30%

Usprawnij obsługę zapotrzebowań w Oracle P2P i skróć czas procesu o 30%.

Rozpocznij okres próbny

Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.