Szablon danych dla procesu Purchase to Pay - Purchase Order
Szablon danych dla procesu Purchase to Pay - Purchase Order
- Zalecane atrybuty do pełnego zbioru danych
- Najważniejsze działania procesu do śledzenia i analizy
- Instrukcja ekstrakcji danych z Oracle Fusion Financials krok po kroku
Atrybuty procesu Purchase to Pay - Purchase Order
| Nazwa | Opis | ||
|---|---|---|---|
|
Czas rozpoczęcia
EventTime
|
Znacznik czasu wskazujący, kiedy wystąpiła dana czynność lub zdarzenie. | ||
|
Opis
Ten atrybut zapisuje dokładną datę i godzinę każdej czynności w procesie. Jest niezbędny do uporządkowania zdarzeń chronologicznie i przeprowadzania analiz opartych na czasie. W process mining czas rozpoczęcia służy do utworzenia dziennika zdarzeń, obliczania czasu realizacji między czynnościami, mierzenia czasu oczekiwania i analizy wyników procesu w różnych okresach. Jest niezbędny w dashboardach dotyczących czasu realizacji i wyników procesu.
Dlaczego to ważne
Ten znacznik czasu pozwala prawidłowo uporządkować zdarzenia i obliczyć wszystkie miary czasu trwania, takie jak czas realizacji i wąskie gardła.
Skąd pobrać
Pola znaczników czasu, takie jak CREATION_DATE i LAST_UPDATE_DATE, z różnych tabel, w tym PO_HEADERS_ALL, PO_ACTION_HISTORY i RCV_SHIPMENT_LINES.
Przykłady
2023-04-15T10:05:00Z2023-04-16T14:30:00Z2023-05-01T09:00:00Z
|
|||
|
Czynność
ActivityName
|
Nazwa konkretnego zdarzenia biznesowego lub kroku, który wystąpił w cyklu życia zamówienia zakupu. | ||
|
Opis
Ten atrybut opisuje konkretne zadanie lub zmianę statusu w procesie, na przykład 'Utworzono zamówienie zakupu' albo 'Przyjęto towary'. Czynności te tworzą sekwencję zdarzeń składających się na przebieg procesu. Analiza kolejności i czasu trwania tych czynności stanowi podstawę process mining. Pozwala zobrazować mapę procesu, wykryć wąskie gardła, znaleźć odstępstwa od standardowej procedury i zmierzyć czas poszczególnych etapów.
Dlaczego to ważne
Czynności tworzą mapę procesu. Ich śledzenie pozwala zobrazować i analizować przebieg procesu, wąskie gardła oraz odstępstwa.
Skąd pobrać
Ustalane na podstawie zmian statusu w tabelach takich jak PO_HEADERS_ALL i PO_ACTION_HISTORY albo na podstawie danych z tabel transakcyjnych, takich jak RCV_TRANSACTIONS dla przyjęć towarów.
Przykłady
Utworzenie zamówienia zakupuAkceptacja zamówienia zakupuPrzyjęto towary
|
|||
|
Zamówienie zakupu
PurchaseOrder
|
Unikalny identyfikator dokumentu zamówienia zakupu, używany jako główny identyfikator sprawy do śledzenia cyklu zakupowego. | ||
|
Opis
Numer zamówienia zakupu to główny identyfikator łączący wszystkie powiązane działania, od utworzenia dokumentu po jego ostateczne zamknięcie. Umożliwia analizę pojedynczej sprawy zakupowej od początku do końca. W process mining każdy unikalny numer zamówienia zakupu odpowiada jednej instancji procesu. Grupowanie danych według tego identyfikatora pomaga analizować różnice w przebiegu procesu, czas realizacji i zgodność dla poszczególnych zamówień.
Dlaczego to ważne
To podstawowy identyfikator sprawy, który łączy powiązane zdarzenia i umożliwia odtworzenie oraz analizę całego cyklu życia zamówienia zakupu.
Skąd pobrać
Oracle Fusion Cloud SCM, moduł Procurement, tabela PO_HEADERS_ALL, kolumna SEGMENT1.
Przykłady
100234510023461002347
|
|||
|
Czas zakończenia
EndTime
|
Znacznik czasu wskazujący, kiedy czynność została zakończona. W przypadku zdarzeń chwilowych często jest taki sam jak czas rozpoczęcia. | ||
|
Opis
W przypadku czynności trwających przez pewien czas oznacza moment ich zakończenia. Dla zdarzeń chwilowych zwykle jest taki sam jak czas rozpoczęcia. Jest niezbędny do obliczenia czasu realizacji poszczególnych czynności. Osobny czas zakończenia pozwala dokładniej analizować czas trwania czynności, który może różnić się od czasu oczekiwania między nimi. Ułatwia odróżnienie aktywnej pracy od przestoju oraz analizę obciążenia zasobów i ich efektywności.
Dlaczego to ważne
Pozwala dokładnie obliczyć czas realizacji czynności, co pomaga analizować efektywność zasobów i wykrywać zadania pochłaniające najwięcej czasu.
Skąd pobrać
W przypadku zdarzeń chwilowych może być taki sam jak czas rozpoczęcia albo wynikać ze znaczników czasu kolejnych zdarzeń. Dla niektórych czynności może być dostępny osobny znacznik czasu zakończenia.
Przykłady
2023-04-15T10:05:00Z2023-04-16T14:45:00Z2023-05-01T09:15:00Z
|
|||
|
Dział
DepartmentName
|
Nazwa działu, który zainicjował zamówienie zakupu lub za nie odpowiada. | ||
|
Opis
Ten atrybut określa jednostkę organizacyjną powiązaną z zakupem, na przykład 'Finanse', 'IT' lub 'Produkcja'. Służy do przypisywania kosztów i sporządzania raportów organizacyjnych. W process mining podział procesu według działu pomaga porównywać wyniki, wykrywać wąskie gardła charakterystyczne dla poszczególnych działów i rozumieć różnice w realizacji procesu w całej organizacji. Wspiera dashboardy takie jak 'Analiza czasu zatwierdzania zamówień zakupu' i 'Trendy zmian w zamówieniach zakupu'.
Dlaczego to ważne
Umożliwia filtrowanie i porównywanie wyników procesu w różnych jednostkach biznesowych, ujawniając problemy lub dobre praktyki charakterystyczne dla poszczególnych działów.
Skąd pobrać
Ustalany na podstawie danych o centrach kosztów w tabelach takich jak PO_DISTRIBUTIONS_ALL, powiązanych z danymi podstawowymi działów.
Przykłady
Operacje ITMarketingBadania i rozwój
|
|||
|
Imię i nazwisko osoby zatwierdzającej
ApproverName
|
Imię i nazwisko użytkownika, który zatwierdził lub odrzucił zamówienie zakupu. | ||
|
Opis
Ten atrybut wskazuje osobę odpowiedzialną za etap zatwierdzania w workflow. Informacje te są zwykle przechowywane w historii działań lub tabeli dziennika workflow powiązanej z zamówieniem zakupu. Analiza danych według osób zatwierdzających wspiera dashboardy 'Analiza czasu zatwierdzania zamówień zakupu' i 'Obciążenie osób zatwierdzających'. Pomaga wykryć wąskie gardła wśród osób lub grup zatwierdzających, sprawiedliwie ocenić obciążenie oraz wskazać możliwości delegowania uprawnień lub przeprojektowania procesu.
Dlaczego to ważne
Wskazuje osoby w ścieżce zatwierdzania, umożliwiając analizę wąskich gardeł, obciążenia i czasu realizacji według osoby zatwierdzającej.
Skąd pobrać
Użytkownik, który wykonał działanie. Informację można znaleźć w PO_ACTION_HISTORY.ACTION_PERFORMED_BY i połączyć z tabelą użytkowników, aby uzyskać pełne imię i nazwisko.
Przykłady
susan.managerdavid.directoremily.finance
|
|||
|
Łączna wartość zamówienia zakupu
PurchaseOrderTotalAmount
|
Łączna wartość pieniężna zamówienia zakupu. | ||
|
Opis
Ten atrybut przedstawia łączny koszt wszystkich pozycji zamówienia zakupu w określonej walucie. To ważna miara finansowa, która pokazuje wartość transakcji realizowanych w procesie. Analiza łącznej wartości zamówienia zakupu pomaga ustalać priorytety działań usprawniających. Na przykład zamówienia o wysokiej wartości można kierować do bardziej szczegółowego zatwierdzenia. Atrybut pozwala też ocenić skutki finansowe, na przykład obliczyć wartość zamówień często zmienianych lub opóźnionych.
Dlaczego to ważne
Pokazuje finansowy wymiar procesu i umożliwia analizę według wartości pieniężnej, na przykład skupienie się na zamówieniach o wysokiej wartości lub ocenę finansowych skutków opóźnień.
Skąd pobrać
Obliczana przez zsumowanie kwot z tabeli PO_LINES_ALL dla danego nagłówka zamówienia albo pobierana z łącznej wartości nagłówka, jeśli jest dostępna.
Przykłady
5250.00120000.50750.99
|
|||
|
Nazwa dostawcy
VendorName
|
Nazwa dostawcy, od którego kupowane są towary lub usługi. | ||
|
Opis
Ten atrybut wskazuje zewnętrznego dostawcę zamówienia zakupu. To ważne dane podstawowe powiązane z nagłówkiem zamówienia. Analiza dostawców jest istotną częścią process mining w P2P. Filtrowanie lub podział danych według dostawcy pozwala analizować terminowość dostaw, porównywać odsetek dostaw na czas i badać odsetek zwrotów towarów, aby wskazać dostawców osiągających lepsze lub gorsze wyniki. Dane te pomagają zarządzać relacjami z dostawcami i planować zakupy strategiczne.
Dlaczego to ważne
Niezbędny do analizy wyników dostawców. Umożliwia porównanie czasu dostawy, odsetka zwrotów i ogólnej rzetelności poszczególnych dostawców.
Skąd pobrać
Powiązanie z PO_HEADERS_ALL.VENDOR_ID do POZ_SUPPLIERS.VENDOR_NAME.
Przykłady
Global Office SuppliesTech Solutions Inc.Advanced Logistics Co.
|
|||
|
Użytkownik
UserName
|
Identyfikator lub nazwa użytkownika, który wykonał daną czynność. | ||
|
Opis
Ten atrybut wskazuje pracownika lub użytkownika systemu odpowiedzialnego za dane zdarzenie, na przykład utworzenie zapotrzebowania, zatwierdzenie zamówienia zakupu lub zaksięgowanie przyjęcia towaru. Dane pochodzą zwykle z pól takich jak 'Created By' lub 'Last Updated By'. Analiza procesu według użytkownika pomaga zrozumieć rozkład obciążenia, ocenić indywidualne wyniki i określić potrzeby szkoleniowe. Jest podstawą dashboardu 'Obciążenie osób zatwierdzających' oraz analizy problemów ze zgodnością związanych z działaniami użytkowników.
Dlaczego to ważne
Przypisuje działania użytkowników do konkretnych osób, umożliwiając analizę obciążenia i wyników pracy oraz określenie potrzeb szkoleniowych.
Skąd pobrać
Połącz z tabelami użytkowników na podstawie identyfikatorów w polach takich jak CREATED_BY lub LAST_UPDATED_BY w tabelach PO_HEADERS_ALL i PO_ACTION_HISTORY.
Przykłady
john.doejane.smithsystem.batch
|
|||
|
Wymagany termin dostawy
RequestedDeliveryDate
|
Termin, do którego zamawiający oczekuje dostawy towarów lub wykonania usług. | ||
|
Opis
Termin jest określony w pozycji zamówienia zakupu i informuje dostawcę o oczekiwanej dacie dostawy. Stanowi punkt odniesienia przy pomiarze terminowości dostaw. Ten atrybut jest niezbędny do obliczenia KPI 'Odsetek dostaw na czas'. Porównanie rzeczywistej daty przyjęcia towaru z wymaganym terminem dostawy pozwala mierzyć i śledzić rzetelność dostawców oraz wykrywać powtarzające się opóźnienia w łańcuchu dostaw.
Dlaczego to ważne
Stanowi punkt odniesienia przy pomiarze terminowości dostaw, czyli ważnym KPI oceny rzetelności dostawców i efektywności łańcucha dostaw.
Skąd pobrać
Znajduje się na poziomie lokalizacji pozycji, w tabeli PO_LINE_LOCATIONS_ALL, w kolumnie NEED_BY_DATE.
Przykłady
2023-05-202023-06-152023-07-01
|
|||
|
Czy dostawa była opóźniona
IsLateDelivery
|
Flaga wskazująca, czy końcowe przyjęcie towaru nastąpiło po wymaganym terminie dostawy. | ||
|
Opis
Ten obliczany atrybut logiczny przyjmuje wartość true, jeśli znacznik czasu działania „Goods Received” jest późniejszy niż wartość atrybutu „Requested Delivery Date” dla danego zamówienia zakupu. Flaga stanowi podstawę KPI „On-Time Delivery Rate”. Ułatwia podział i analizę zamówień opóźnionych oraz dostarczonych na czas, a także badanie przyczyn opóźnień związanych z konkretnymi dostawcami, lokalizacjami lub kategoriami produktów.
Dlaczego to ważne
Bezpośrednio wspiera KPI „On-Time Delivery Rate”, umożliwiając przejrzystą analizę wyników dostawców i terminowości dostaw.
Skąd pobrać
Pole obliczane. Przyjmuje wartość „true”, jeśli znacznik czasu działania „Goods Received” przypada po wartości atrybutu „RequestedDeliveryDate”.
Przykłady
truefalse
|
|||
|
Czy wymaga poprawek
IsRework
|
Flaga wskazująca, czy zamówienie zakupu zmieniono po jego utworzeniu. | ||
|
Opis
To obliczany atrybut logiczny, który przyjmuje wartość true, jeśli w przypadku zamówienia zakupu występuje działanie „Purchase Order Changed”. Ułatwia szybkie wykrywanie zamówień wymagających korekt lub zmian. Flaga upraszcza obliczanie KPI „PO Modification Rate” oraz filtrowanie i analizę zamówień wymagających poprawek. Analiza cech takich zamówień, na przykład dostawców lub zaangażowanych działów, może pomóc ustalić przyczyny nieprawidłowych danych lub zmieniających się wymagań.
Dlaczego to ważne
Bezpośrednio wspiera KPI „PO Modification Rate” i ułatwia analizę niestabilności procesu, oznaczając wszystkie zmienione zamówienia.
Skąd pobrać
Pole obliczane. Przyjmuje wartość „true”, jeśli dziennik zdarzeń dla danego przypadku zawiera działanie „Purchase Order Changed”, w przeciwnym razie „false”.
Przykłady
truefalse
|
|||
|
Czy zatwierdzenie było zgodne z procedurą
IsApprovalCompliant
|
Flaga wskazująca, czy zamówienie zakupu zatwierdzono przed wysłaniem go do dostawcy. | ||
|
Opis
To obliczany atrybut logiczny, który sprawdza przestrzeganie ważnej kontroli wewnętrznej: zamówienie zakupu musi zostać zatwierdzone przed wysłaniem do dostawcy. Atrybut przyjmuje wartość true, jeśli działanie „Purchase Order Approved” nastąpi przed działaniem „Purchase Order Sent to Vendor”. Atrybut jest niezbędny do korzystania z dashboardu „PO Process Compliance Audit” i KPI „PO Approval Compliance Rate”. Ułatwia wykrywanie i mierzenie naruszeń zgodności, wspiera przestrzeganie zasad zakupowych i ogranicza ryzyko nieautoryzowanych wydatków.
Dlaczego to ważne
Bezpośrednio mierzy KPI „PO Approval Compliance Rate” i wskazuje naruszenia kontroli wewnętrznej, gdy zamówienia są wysyłane do dostawców przed zatwierdzeniem.
Skąd pobrać
Pole obliczane. Przyjmuje wartość „true”, jeśli znacznik czasu „Purchase Order Approved” jest wcześniejszy lub równy znacznikowi czasu „Purchase Order Sent to Vendor”.
Przykłady
truefalse
|
|||
|
Jednostka biznesowa
BusinessUnitName
|
Jednostka biznesowa organizacji, która dokonuje zakupu. | ||
|
Opis
Jednostka biznesowa to odrębna część przedsiębiorstwa, często z własną księgą główną i sprawozdawczością finansową. W Oracle Fusion służy przede wszystkim do rozdzielania danych. Analiza wyników procesu według jednostki biznesowej ma duże znaczenie w dużych, międzynarodowych firmach. Umożliwia porównanie efektywności zakupów, zgodności i kosztów w różnych częściach organizacji oraz wskazanie dobrych praktyk i obszarów do usprawnienia.
Dlaczego to ważne
Pozwala dużym organizacjom porównywać efektywność procesu i zgodność w różnych jednostkach operacyjnych.
Skąd pobrać
Informacja o jednostce biznesowej znajduje się zwykle w nagłówku zamówienia: PO_HEADERS_ALL.PRC_BU_ID. Pole jest powiązane z widokiem FUN_ALL_BUSINESS_UNITS_V.
Przykłady
Jednostka biznesowa w USAEMEA VisionAPAC Services
|
|||
|
Kategoria zakupu
PurchaseCategory
|
Klasyfikacja kupowanych towarów lub usług, na przykład 'Sprzęt IT' lub 'Materiały biurowe'. | ||
|
Opis
Ten atrybut przypisuje pozycje zamówienia zakupu do kategorii w hierarchii zakupowej. Klasyfikacja służy do analizy wydatków i zarządzania dostawcami. W process mining podział procesu według kategorii zakupu może ujawnić różnice w przebiegu lub wynikach. Na przykład zatwierdzanie wydatków inwestycyjnych może trwać dłużej niż zatwierdzanie zakupów operacyjnych. Atrybut wspiera dashboard 'Odsetek i przyczyny zwrotów towarów', umożliwiając analizę kategorii najczęściej zwracanych produktów.
Dlaczego to ważne
Umożliwia analizę procesu według rodzaju wydatków i pomaga wykryć różnice w przebiegu, wąskie gardła lub odsetku zwrotów w poszczególnych kategoriach towarów.
Skąd pobrać
Powiązanie z PO_LINES_ALL.CATEGORY_ID do widoku EGP_CATEGORIES_VL.
Przykłady
IT.Sprzęt.LaptopyBiuro.Materiały biurowe.PapierniczeUsługi profesjonalne.Doradztwo
|
|||
|
Miejsce dostawy
DeliveryLocation
|
Miejsce lub adres, pod który należy dostarczyć towary. | ||
|
Opis
Ten atrybut określa adres dostawy pozycji zamówienia zakupu. To ważna informacja logistyczna. Analiza według miejsca dostawy wspiera dashboard 'Efektywność obsługi przyjęć towarów'. Pomaga ustalić, czy przyjęcia w niektórych magazynach lub lokalizacjach trwają dłużej, co może wskazywać na problemy z zasobami lub przebiegiem procesu w danym miejscu.
Dlaczego to ważne
Umożliwia analizę wyników według lokalizacji i pomaga wykryć regionalne lub lokalne wąskie gardła w procesie przyjęcia towarów.
Skąd pobrać
Powiązanie z PO_LINE_LOCATIONS_ALL.SHIP_TO_LOCATION_ID do widoku HR_LOCATIONS_ALL.
Przykłady
Magazyn główny, dok ABudynek 3, recepcjaBiuro w San Francisco, 10. piętro
|
|||
|
Ostatnia aktualizacja danych
LastDataUpdate
|
Znacznik czasu wskazujący, kiedy dane zostały ostatnio pobrane lub odświeżone z systemu źródłowego. | ||
|
Opis
Ten atrybut informuje, jak aktualne są analizowane dane. Zapisuje datę i godzinę ostatniego pobrania danych z Oracle Fusion Financials. Dzięki tej informacji użytkownicy wiedzą, na ile aktualne są analizy i dashboardy. Mogą ocenić, czy uwzględniono najnowsze transakcje.
Dlaczego to ważne
Informuje o aktualności danych, dzięki czemu użytkownicy wiedzą, jak bieżąca jest analiza procesu.
Skąd pobrać
To znacznik czasu generowany i dodawany podczas procesu ekstrakcji i transformacji danych (ETL).
Przykłady
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Status zamówienia zakupu
PurchaseOrderStatus
|
Bieżący status dokumentu zamówienia zakupu. | ||
|
Opis
Ten atrybut wskazuje bieżący etap cyklu życia zamówienia zakupu, na przykład 'Otwarte', 'Zatwierdzone', 'Ostatecznie zamknięte' lub 'Anulowane'. Pokazuje aktualny stan zamówienia. Process mining koncentruje się na sekwencji czynności, ale bieżący status przydaje się do filtrowania spraw. Można na przykład analizować tylko otwarte zamówienia, aby sprawdzić bieżące obciążenie, albo zamknięte, aby ocenić zakończone instancje procesu. Atrybut jest niezbędny w dashboardzie 'Przebieg i status zamówień zakupu'.
Dlaczego to ważne
Pokazuje bieżący stan zamówienia zakupu i pozwala ograniczyć analizę do zamówień aktywnych, zakończonych lub anulowanych.
Skąd pobrać
Oracle Fusion Cloud SCM, tabela PO_HEADERS_ALL, kolumny AUTHORIZATION_STATUS lub DOCUMENT_STATUS.
Przykłady
OTWARTEZATWIERDZONEOSTATECZNIE_ZAMKNIĘTEANULOWANE
|
|||
|
System źródłowy
SourceSystem
|
System informatyczny, z którego pobrano dane. | ||
|
Opis
Ten atrybut wskazuje źródło danych, co jest szczególnie przydatne w środowiskach z wieloma zintegrowanymi systemami. W tym procesie będzie to zwykle 'Oracle Fusion Financials'. Wartość często pozostaje stała w danym zbiorze danych, ale ma znaczenie dla zarządzania danymi, rozwiązywania problemów i śledzenia ich pochodzenia. W analizach łączących dane z wielu źródeł umożliwia filtrowanie i podział według systemu źródłowego.
Dlaczego to ważne
Wskazuje źródło danych, co ma znaczenie dla zarządzania danymi, właściwej interpretacji i integracji z innymi systemami.
Skąd pobrać
Zwykle jest to stała wartość określana i dodawana podczas procesu ekstrakcji i transformacji danych (ETL).
Przykłady
Oracle Fusion FinancialsOracle Cloud SCMOracle Fusion P2P
|
|||
|
Typ zamówienia zakupu
PurchaseOrderType
|
Rodzaj zamówienia zakupu, na przykład 'Standardowe', 'Ramowe' lub 'Kontraktowe'. | ||
|
Opis
Ten atrybut klasyfikuje zamówienie zakupu według celu zakupowego. Różne typy zamówień często podlegają innym zasadom i mają odmienny przebieg. Zamówienie 'Standardowe' dotyczy jednorazowego zakupu, a 'Ramowe' jest długoterminową umową z dostawcą. Analiza według typu zamówienia zakupu pozwala rzetelniej ocenić wyniki procesu. Porównanie czasu realizacji zamówienia standardowego z umową ramową mogłoby prowadzić do mylnych wniosków. Podział umożliwia porównywanie podobnych zamówień.
Dlaczego to ważne
Rozróżnia scenariusze zakupowe i pozwala rzetelnie porównywać wyniki procesu dla podobnych typów zamówień.
Skąd pobrać
Oracle Fusion Cloud SCM, tabela PO_HEADERS_ALL, kolumna TYPE_LOOKUP_CODE.
Przykłady
STANDARDOWERAMOWEKONTRAKTOWE
|
|||
|
Zapotrzebowanie zakupu
PurchaseRequisitionNumber
|
Identyfikator zapotrzebowania zakupu, które poprzedziło zamówienie zakupu i stanowiło jego podstawę. | ||
|
Opis
Zapotrzebowanie zakupu to wewnętrzny dokument służący do zgłaszania potrzeby zakupu towarów lub usług. Ten atrybut łączy zamówienie zakupu z pierwotnym wnioskiem. Numer zapotrzebowania pozwala analizować szerszy przebieg zakupów, począwszy od zgłoszenia potrzeby, a nie dopiero od zamówienia zakupu. Ułatwia pomiar czasu od zgłoszenia do zamówienia oraz ocenę wpływu szczegółów zapotrzebowania na dalszy przebieg procesu.
Dlaczego to ważne
Łączy zamówienie zakupu z pierwotnym wnioskiem i pozwala analizować cały proces od zapotrzebowania po płatność.
Skąd pobrać
Powiązanie przez tabelę PO_DISTRIBUTIONS_ALL, która zawiera REQ_DISTRIBUTION_ID prowadzący do tabeli POR_REQUISITION_LINES_ALL.
Przykłady
PR-2023-05-001PR-2023-05-002PR-2023-05-003
|
|||
Działania w procesie Purchase to Pay - Purchase Order
| Działanie | Opis | ||
|---|---|---|---|
|
Akceptacja zamówienia zakupu
|
Zamówienie zakupu uzyskało wszystkie wymagane akceptacje i może zostać wysłane do dostawcy. To ważny etap, jawnie rejestrowany w historii działań dokumentu. | ||
|
Dlaczego to ważne
Ten ważny etap warunkuje wysłanie zamówienia zakupu do dostawcy. Jest niezbędny do pomiaru czasu akceptacji i sprawdzania zgodności z zasadami wydatków.
Skąd pobrać
Zdarzenie jest rejestrowane w tabeli PO_ACTION_HISTORY, zazwyczaj z wartością ACTION_CODE równą 'APPROVE', lub po zmianie statusu dokumentu w PO_HEADERS_ALL na status zaakceptowany.
Rejestrowanie
Filtruj tabelę PO_ACTION_HISTORY, aby znaleźć końcową czynność 'APPROVE'.
Typ zdarzenia
explicit
|
|||
|
Anulowano zamówienie zakupu
|
Zamówienie zakupu zostało trwale anulowane i nie oczekuje się dalszych transakcji. To jawne działanie zmienia końcowy status dokumentu. | ||
|
Dlaczego to ważne
To negatywny stan końcowy procesu. Analiza anulowań może ujawnić problemy, takie jak zduplikowane zamówienia, zmiany budżetu lub zmiany wymagań projektu.
Skąd pobrać
Działanie jest zapisane w tabeli PO_ACTION_HISTORY z wartością 'CANCEL' w polu ACTION_CODE. Status zamówienia w tabeli PO_HEADERS_ALL jest odpowiednio aktualizowany.
Rejestrowanie
Odfiltruj tabelę PO_ACTION_HISTORY według ACTION_CODE = 'CANCEL'.
Typ zdarzenia
explicit
|
|||
|
Ostatecznie zamknięto zamówienie zakupu
|
Zamówienie zakupu uznaje się za zakończone, gdy towary zostały w pełni przyjęte lub zafakturowane i nie przewiduje się dalszych działań. To jawne działanie ustawia końcowy status zamówienia. | ||
|
Dlaczego to ważne
To zakończenie cyklu życia zamówienia zakupu. Jest to podstawowy pozytywny stan końcowy, a jego śledzenie pozwala mierzyć przepustowość procesu i odsetek zakończonych spraw.
Skąd pobrać
Zdarzenie jest zapisane w tabeli PO_ACTION_HISTORY z wartością 'FINALLY CLOSE' w polu ACTION_CODE. Status zamówienia w tabeli PO_HEADERS_ALL jest również zmieniany na 'Finally Closed'.
Rejestrowanie
Odfiltruj tabelę PO_ACTION_HISTORY według ACTION_CODE = 'FINALLY CLOSE'.
Typ zdarzenia
explicit
|
|||
|
Przyjęto towary
|
Towary fizycznie dostarczono, przeliczono i zarejestrowano w ramach zamówienia zakupu. To zdarzenie transakcyjne aktualizuje stan zapasów i status zamówienia. | ||
|
Dlaczego to ważne
To ważny etap przy pomiarze terminowości dostawcy i całkowitego czasu realizacji. Uruchamia też kolejne działania, takie jak kontrola jakości i dopasowanie faktury.
Skąd pobrać
To jawne zdarzenie zapisane w tabeli RCV_TRANSACTIONS. Odpowiednią transakcję można rozpoznać po wartości 'RECEIVE' w polu TRANSACTION_TYPE.
Rejestrowanie
Użyj pola TRANSACTION_DATE z tabeli RCV_TRANSACTIONS dla rekordów, w których TRANSACTION_TYPE ma wartość 'RECEIVE'.
Typ zdarzenia
explicit
|
|||
|
Utworzenie zamówienia zakupu
|
To oficjalny początek cyklu życia zamówienia zakupu. Dokument zamówienia zakupu zostaje utworzony w wersji roboczej lub ze statusem niekompletnym. System rejestruje zdarzenie, zapisując znacznik czasu utworzenia nowego rekordu nagłówka zamówienia. | ||
|
Dlaczego to ważne
Jako początkowe zdarzenie dla case zamówienia zakupu ta czynność stanowi podstawę obliczania czasu realizacji. Umożliwia ocenę sprawności kolejnych etapów, takich jak akceptacja i komunikacja z dostawcą.
Skąd pobrać
To jawne zdarzenie oparte na polu CREATION_DATE w tabeli PO_HEADERS_ALL dla danego identyfikatora zamówienia zakupu (PO_HEADER_ID).
Rejestrowanie
Użyj znacznika czasu utworzenia z tabeli PO_HEADERS_ALL.
Typ zdarzenia
explicit
|
|||
|
Wysłanie zamówienia zakupu do dostawcy
|
Zaakceptowane zamówienie zakupu zostaje oficjalnie przekazane dostawcy, na przykład pocztą elektroniczną lub przez EDI. Zdarzenie często można wywnioskować ze zmiany statusu lub znacznika czasu w rekordzie komunikacji dotyczącej zamówienia. | ||
|
Dlaczego to ważne
To początek czasu realizacji po stronie dostawcy. Jest to ważny punkt odniesienia przy ocenie dostawcy, od potwierdzenia zamówienia do dostawy.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany statusu dokumentu zamówienia zakupu na 'Open' i uzupełnienia daty komunikacji. Zazwyczaj jest to pole PO_HEADERS_ALL.communicated_date lub powiązany status.
Rejestrowanie
Wywnioskuj zdarzenie ze znacznika czasu aktualizacji statusu komunikacji zamówienia zakupu na 'Communicated'.
Typ zdarzenia
inferred
|
|||
|
Akceptacja zapotrzebowania na zakup
|
Wyznaczona osoba zaakceptowała zapotrzebowanie na zakup, upoważniając dział zakupów do utworzenia zamówienia zakupu. Zdarzenie jest jawnie rejestrowane w historii działań zapotrzebowania. | ||
|
Dlaczego to ważne
Ten etap oznacza zakończenie wewnętrznej akceptacji zapotrzebowania. Opóźnienia mogą bezpośrednio wpłynąć na cały harmonogram zakupów, dlatego warto monitorować czas realizacji.
Skąd pobrać
Zdarzenie jest rejestrowane w historii działań powiązanej z zapotrzebowaniem. Zazwyczaj można je śledzić w tabelach workflow lub w polach statusu akceptacji dokumentu zapotrzebowania.
Rejestrowanie
Rejestrowane jako działanie akceptacyjne w historii workflow danego dokumentu zapotrzebowania.
Typ zdarzenia
explicit
|
|||
|
Odrzucenie zamówienia zakupu
|
Osoba akceptująca odrzuciła zamówienie zakupu i odesłała je do autora w celu wprowadzenia zmian. To jawne zdarzenie w historii działań wskazuje na przerwanie standardowego przebiegu procesu. | ||
|
Dlaczego to ważne
Odrzucenia powodują dodatkową pracę i opóźnienia. Śledzenie tej czynności pomaga ustalić częste przyczyny odrzuceń, potrzeby szkoleniowe lub niejasne wymagania dotyczące akceptacji.
Skąd pobrać
Czynność jest rejestrowana w tabeli PO_ACTION_HISTORY z wartością ACTION_CODE równą 'REJECT' dla odpowiedniego PO_HEADER_ID.
Rejestrowanie
Filtruj tabelę PO_ACTION_HISTORY według ACTION_CODE = 'REJECT'.
Typ zdarzenia
explicit
|
|||
|
Potwierdzenie zamówienia zakupu przez dostawcę
|
Dostawca potwierdził otrzymanie zamówienia zakupu i akceptację jego warunków. Zdarzenie jest często rejestrowane ręcznie przez pracowników działu zakupów na podstawie komunikacji z dostawcą lub elektronicznego potwierdzenia. | ||
|
Dlaczego to ważne
Potwierdzenie od dostawcy daje pewność, że zamówienie dotarło i jest realizowane. Śledzenie tej czynności ułatwia zarządzanie komunikacją z dostawcami i wcześniejsze wykrywanie możliwych problemów z realizacją.
Skąd pobrać
Zdarzenie zazwyczaj można wywnioskować ze zmiany pól statusu potwierdzenia w nagłówku lub pozycjach zamówienia zakupu, na przykład po zmianie PO_HEADERS_ALL.acceptance_status na 'Accepted'.
Rejestrowanie
Wywnioskuj zdarzenie na podstawie aktualizacji pól statusu potwierdzenia zamówienia zakupu.
Typ zdarzenia
inferred
|
|||
|
Potwierdzono wykonanie usług
|
W przypadku zamówień zakupu dotyczących usług ta czynność oznacza potwierdzenie, że usługi wykonano zgodnie z ustaleniami. Potwierdzenie jest często wprowadzane ręcznie lub rejestrowane w karcie odbioru usług. | ||
|
Dlaczego to ważne
To odpowiednik przyjęcia towaru w przypadku usług i warunek konieczny do opłacenia faktury. Opóźnienia w potwierdzeniu wykonania usług mogą prowadzić do nieterminowych płatności i pogorszenia relacji z dostawcami.
Skąd pobrać
Zdarzenie jest zwykle rejestrowane jako przyjęcie dotyczące pozycji usługowej w zamówieniu zakupu. Mogą mu towarzyszyć określone pola lub złożone zapisy przyjęć, które śledzą postęp albo zakończenie usług.
Rejestrowanie
Wskaż transakcje przyjęcia (RCV_TRANSACTIONS) powiązane z pozycjami zamówień zakupu dotyczącymi usług.
Typ zdarzenia
explicit
|
|||
|
Przeprowadzono kontrolę jakości
|
Towary wymagające kontroli jakości zostały sprawdzone i przyjęte albo odrzucone. Czynność odbywa się po wstępnym przyjęciu i jest rejestrowana jako osobna transakcja. | ||
|
Dlaczego to ważne
Ta czynność ma istotne znaczenie dla zarządzania jakością. Analiza czasu kontroli pozwala usprawnić ten etap i ograniczyć opóźnienia w udostępnianiu towarów do użytku.
Skąd pobrać
Zdarzenie jest zapisane w tabeli RCV_TRANSACTIONS. Można je rozpoznać po transakcji z wartością 'ACCEPT' lub 'REJECT' w polu TRANSACTION_TYPE, następującej po transakcji przyjęcia.
Rejestrowanie
Użyj pola TRANSACTION_DATE z tabeli RCV_TRANSACTIONS dla rekordów, w których TRANSACTION_TYPE ma wartość 'ACCEPT' lub 'REJECT'.
Typ zdarzenia
explicit
|
|||
|
Przesłanie zamówienia zakupu do akceptacji
|
Utworzone zamówienie zakupu zostaje przesłane do workflow akceptacji. Oracle Fusion jawnie rejestruje tę czynność, zapisując użytkownika i znacznik czasu przesłania. | ||
|
Dlaczego to ważne
Ta czynność rozpoczyna cykl akceptacji. Analiza czasu od przesłania do akceptacji pomaga wskazać wąskie gardła w wewnętrznym procesie zatwierdzania.
Skąd pobrać
Czynność jest rejestrowana w tabeli PO_ACTION_HISTORY z wartością ACTION_CODE równą 'SUBMIT' dla odpowiedniego PO_HEADER_ID.
Rejestrowanie
Filtruj tabelę PO_ACTION_HISTORY według ACTION_CODE = 'SUBMIT'.
Typ zdarzenia
explicit
|
|||
|
Utworzenie zapotrzebowania na zakup
|
Ta czynność oznacza utworzenie zapotrzebowania na zakup, czyli formalnego wniosku o towary lub usługi, który poprzedza zamówienie zakupu. W Oracle Fusion zdarzenie jest rejestrowane po utworzeniu nowego wpisu w tabeli nagłówków zapotrzebowań. | ||
|
Dlaczego to ważne
Analiza tej czynności pozwala lepiej zrozumieć etap zgłaszania zapotrzebowania. Pomiar czasu od utworzenia zapotrzebowania do utworzenia zamówienia zakupu ujawnia możliwe opóźnienia w przekształcaniu potrzeb wewnętrznych w konkretne zamówienia.
Skąd pobrać
To jawne zdarzenie rejestrowane po zapisaniu nowego zapotrzebowania. Można je wykryć, śledząc znacznik czasu utworzenia w tabeli POR_REQUISITION_HEADERS_ALL.
Rejestrowanie
Zdarzenie jest oparte na dacie utworzenia rekordu w tabeli POR_REQUISITION_HEADERS_ALL.
Typ zdarzenia
explicit
|
|||
|
Utworzono dokument przyjęcia towaru
|
W systemie rozpoczyna się obsługa dokumentu przyjęcia, przygotowująca organizację na fizyczną dostawę towarów. To początek wewnętrznego procesu przyjęcia. | ||
|
Dlaczego to ważne
To przejście od zakupów do logistyki. Analiza czasu od tego momentu do zaksięgowania przyjęcia pozwala wykryć nieefektywności w magazynie lub dziale przyjęć.
Skąd pobrać
To jawne zdarzenie, rejestrowane jako znacznik czasu utworzenia nowego rekordu w tabeli RCV_SHIPMENT_HEADERS powiązanego z zamówieniem zakupu.
Rejestrowanie
Użyj daty utworzenia odpowiedniego rekordu w tabeli RCV_SHIPMENT_HEADERS.
Typ zdarzenia
explicit
|
|||
|
Zmiana zamówienia zakupu
|
Po wstępnym zatwierdzeniu zamówienie zakupu zostało zmodyfikowane, na przykład zmieniono ilość, cenę lub termin dostawy. Oracle Fusion rejestruje tę zmianę, tworząc nową wersję dokumentu. | ||
|
Dlaczego to ważne
Zmiany w zamówieniu zakupu oznaczają konieczność ponownej pracy i mogą wskazywać na błędy w pierwotnym zamówieniu lub zmieniające się potrzeby firmy. Analiza częstotliwości i rodzaju zmian pomaga znaleźć możliwości usprawnienia procesu.
Skąd pobrać
Zdarzenie jest rejestrowane wprost podczas tworzenia nowej wersji dokumentu. Można je rozpoznać po zwiększeniu wartości pola REVISION_NUM w tabeli PO_HEADERS_ALL.
Rejestrowanie
Wskaż każde wystąpienie zwiększenia wartości REVISION_NUM dla PO_HEADER_ID.
Typ zdarzenia
explicit
|
|||
|
Zwrócono towary dostawcy
|
Wcześniej przyjęte towary są odsyłane dostawcy, zwykle z powodu wad, uszkodzeń lub niezgodności dostawy. W module przyjęć zdarzenie jest rejestrowane jako osobna transakcja zwrotu. | ||
|
Dlaczego to ważne
Śledzenie zwrotów pomaga ocenić jakość dostawcy i zgodność dostaw z zamówieniem. Wysoki odsetek zwrotów od danego dostawcy może wskazywać na powtarzające się problemy, które wymagają rozwiązania.
Skąd pobrać
To jawne zdarzenie zapisane w tabeli RCV_TRANSACTIONS z wartością 'RETURN TO VENDOR' w polu TRANSACTION_TYPE.
Rejestrowanie
Użyj pola TRANSACTION_DATE z tabeli RCV_TRANSACTIONS dla rekordów, w których TRANSACTION_TYPE ma wartość 'RETURN TO VENDOR'.
Typ zdarzenia
explicit
|
|||
Instrukcje ekstrakcji danych
Gotowi do rozpoczęcia?
Skorzystaj z tego szablonu, aby usprawnić gromadzenie danych i rozpocząć analizę procesu Purchase to Pay - Purchase Order. Już dziś zacznij usprawniać operacje.
Już dziś usprawnij proces Purchase to Pay - Purchase Order
Łatwo wykryj kosztowne wąskie gardła i skróć czas cyklu o 30%.
Nie trzeba podawać danych karty kredytowej. Już dziś można zacząć usprawniać procesy.