Szablon danych dla procesu obsługi zapotrzebowań zakupowych
Szablon danych dla procesu obsługi zapotrzebowań zakupowych
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia
- Wskazówki dotyczące pobierania danych z Oracle Fusion Financials
Atrybuty procesu obsługi zapotrzebowań zakupowych
| 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
|
|||
Działania w procesie obsługi zapotrzebowań zakupowych
| 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
|
|||
Instrukcje pobierania danych
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%.
Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.