Szablon danych dla procesu Purchase to Pay: zapotrzebowanie
Szablon danych dla procesu Purchase to Pay: zapotrzebowanie
- Zalecane atrybuty do szczegółowej analizy
- Działania, które warto śledzić podczas odkrywania procesu
- Wskazówki dotyczące ekstrakcji danych z SAP S/4HANA
Atrybuty procesu Purchase to Pay: zapotrzebowanie
| Nazwa | Opis | ||
|---|---|---|---|
| Czas zdarzenia EventTime | Dokładna data i godzina wystąpienia danego działania. | ||
| Opis Czas zdarzenia to znacznik czasu wskazujący, kiedy miało miejsce dane działanie. Jest niezbędny do chronologicznego uporządkowania zdarzeń w ramach sprawy i stanowi podstawę obliczania czasu trwania oraz wyników w process mining. Na przykład różnica między zdarzeniami „Przekazano zapotrzebowanie do akceptacji” i „Zaakceptowano zapotrzebowanie” określa czas akceptacji. Dokładne znaczniki czasu są niezbędne do analizy wyników procesu, wykrywania opóźnień i monitorowania dotrzymywania uzgodnionych poziomów usług. Ten atrybut umożliwia tworzenie dashboardów, które pokazują czas realizacji, wskazują zapotrzebowania oczekujące na obsługę i porównują wyniki w różnych okresach. Dlaczego to ważne Znacznik czasu pozwala uporządkować zdarzenia, obliczać czas realizacji oraz analizować wyniki procesu i wąskie gardła. Skąd pobrać Znaczniki czasu pochodzą zwykle z nagłówków dokumentów zmian (CDHDR-UDATE, CDHDR-UTIME) lub dzienników zdarzeń workflow. Przykłady 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| Identyfikator zapotrzebowania zakupowego PurchaseRequisitionId | Unikalny identyfikator dokumentu zapotrzebowania zakupowego. | ||
| Opis Identyfikator zapotrzebowania zakupowego to klucz główny, który jednoznacznie wskazuje każde zapotrzebowanie na towary lub usługi w SAP S/4HANA. Jest centralnym identyfikatorem sprawy, który łączy wszystkie działania i zmiany dotyczące danego zapotrzebowania, od jego utworzenia po stan końcowy, taki jak akceptacja, odrzucenie lub przekształcenie w zamówienie zakupu. W process mining ten atrybut jest niezbędny do odtworzenia pełnego cyklu życia każdego zapotrzebowania. Grupowanie powiązanych zdarzeń pod jednym identyfikatorem pozwala dokładnie mierzyć czas realizacji, śledzić zmiany statusu i analizować różne ścieżki procesu akceptacji. Dlaczego to ważne To podstawowy identyfikator sprawy, który łączy wszystkie powiązane etapy procesu i pozwala uzyskać pełny, spójny obraz cyklu życia zapotrzebowania. Skąd pobrać To numer zapotrzebowania zakupowego z pola BANFN w tabeli EBAN. Przykłady 100178901001789110017892 | |||
| Nazwa działania ActivityName | Nazwa działania biznesowego, które miało miejsce na danym etapie procesu obsługi zapotrzebowania. | ||
| Opis Nazwa działania opisuje konkretne zdarzenie lub zadanie w cyklu życia zapotrzebowania zakupowego. Działania są wyznaczane na podstawie dzienników systemowych, takich jak dokumenty zmian i historia workflow. Obejmują ważne etapy procesu, na przykład „Utworzono zapotrzebowanie”, „Rozpoczęto etap akceptacji” lub „Utworzono zamówienie zakupu”. Analiza działań pozwala zobrazować przebieg procesu, wskazać wąskie gardła i zmierzyć czas spędzony na poszczególnych etapach. Znajomość kolejności i częstotliwości działań, takich jak „Zmieniono zapotrzebowanie” lub „Odrzucono zapotrzebowanie”, pomaga wykrywać nieefektywne etapy i obszary wymagające usprawnienia. Dlaczego to ważne Określa etapy procesu i stanowi podstawę mapy procesu. Umożliwia analizę przebiegu, wariantów i wąskich gardeł. Skąd pobrać To atrybut pochodny, zwykle tworzony na podstawie interpretacji danych z tabel dokumentów zmian (CDHDR, CDPOS) i dzienników workflow (np. SWWLOGHIST). Przykłady Utworzono zapotrzebowanieZakończono etap akceptacjiZaakceptowano zapotrzebowanieUtworzono zamówienie zakupu | |||
| Dział Department | Dział lub centrum kosztów, na które przypisywane są koszty zapotrzebowania. | ||
| Opis Atrybut działu, często reprezentowany w SAP przez centrum kosztów, wskazuje jednostkę biznesową odpowiedzialną za zakup. To ważna informacja finansowa i organizacyjna przypisywana na poziomie pozycji zapotrzebowania. W process mining atrybut ten jest niezbędny do analizy wyników poszczególnych działów. Umożliwia tworzenie dashboardów porównujących takie wskaźniki jak czas realizacji, częstotliwość zmian i odsetek odrzuceń. Dzięki temu można wskazać działy osiągające dobre wyniki, których praktyki warto wdrożyć w innych jednostkach, oraz te, które potrzebują dodatkowych szkoleń lub wsparcia w obsłudze procesu. Dlaczego to ważne Umożliwia porównanie wyników jednostek biznesowych. Różnice w czasie realizacji lub odsetku odrzuceń pomagają wskazać dobre praktyki i obszary wymagające usprawnienia. Skąd pobrać To centrum kosztów, zwykle zapisane w polu KOSTL tabeli przypisań kont EBKN. Przykłady FIN-1001IT-2005MKT-3010 | |||
| Identyfikator osoby akceptującej ApproverId | Identyfikator użytkownika, który zaakceptował lub odrzucił zapotrzebowanie na danym etapie. | ||
| Opis Identyfikator osoby akceptującej wskazuje użytkownika, który zaakceptował lub odrzucił zapotrzebowanie. W odróżnieniu od ogólnego identyfikatora użytkownika dotyczy wyłącznie osób podejmujących decyzje w workflow akceptacji. Rejestrowanie tych informacji jest niezbędne do szczegółowej analizy procesu akceptacji. Atrybut ten pozwala analizować sposób podejmowania decyzji, na przykład wskazać kierowników, którzy długo akceptują zapotrzebowania lub często je odrzucają. Jest podstawą dashboardów pokazujących czas poszczególnych etapów akceptacji i wąskie gardła workflow. Pomaga ustalić, które osoby lub role powodują opóźnienia. Dlaczego to ważne Wskazuje osobę podejmującą decyzję na danym etapie akceptacji. Umożliwia szczegółową analizę czasu akceptacji i wąskich gardeł według osoby lub roli. Skąd pobrać Informacje te są zwykle pobierane z tabel SAP Business Workflow, takich jak SWW_WI2OBJ i SWWLOGHIST, które łączą elementy pracy z użytkownikiem kończącym zadanie. Przykłady MJOHNSONCWILLIAMSLBLACK | |||
| Identyfikator użytkownika UserId | Identyfikator użytkownika, który utworzył zapotrzebowanie lub wykonał określone działanie. | ||
| Opis Identyfikator użytkownika wskazuje pracownika lub użytkownika systemu odpowiedzialnego za dane zdarzenie w cyklu życia zapotrzebowania. Może to być osoba, która utworzyła zapotrzebowanie, kierownik, który je zaakceptował, lub pracownik, który je zmienił. W przypadku kroków zautomatyzowanych może to być identyfikator użytkownika systemowego lub wsadowego. Analiza według identyfikatora użytkownika pomaga zrozumieć sposób pracy poszczególnych osób, rozkład obciążenia i zgodność z procedurami. Ułatwia wskazanie potrzeb szkoleniowych, rozpoznanie osób osiągających dobre wyniki i ustalenie odpowiedzialności w procesie. W połączeniu z danymi podstawowymi użytkowników wspiera też analizę wyników poszczególnych działów. Dlaczego to ważne Umożliwia analizę wyników pracy użytkowników, rozkładu obciążenia i zgodności z procedurami. Pomaga wskazać potrzeby szkoleniowe i wąskie gardła związane z zasobami. Skąd pobrać Identyfikator twórcy znajduje się w polu EBAN-ERNAM. W przypadku późniejszych zmian jest zapisany w CDHDR-USERNAME, a w przypadku akceptacji w dziennikach workflow. Przykłady JSMITHRROEWF-BATCH | |||
| Status zapotrzebowania RequisitionStatus | Bieżący status przetwarzania lub akceptacji zapotrzebowania zakupowego. | ||
| Opis Status zapotrzebowania wskazuje jego bieżący etap cyklu życia. W SAP często określa go wskaźnik zwalniania, który informuje, czy zapotrzebowanie jest zablokowane, w trakcie akceptacji, częściowo zaakceptowane czy w pełni zaakceptowane. Status zmienia się w miarę przechodzenia zapotrzebowania przez workflow. Śledzenie statusu w czasie pozwala zrozumieć przebieg procesu i ustalić, gdzie oraz jak długo zapotrzebowania oczekują na obsługę. Analiza przejść między statusami pokazuje szczegółowo przebieg akceptacji i jego warianty. Dlaczego to ważne Wskazuje bieżący stan zapotrzebowania. Pozwala śledzić postęp, wykrywać wąskie gardła i analizować przebieg procesu. Skąd pobrać Status zwalniania jest często określany przez wskaźnik zwalniania, zapisany w polu FRGZU tabeli EBAN. Przykłady B1S | |||
| Typ zapotrzebowania RequisitionType | Kod klasyfikujący zapotrzebowanie zakupowe, na przykład jako zapotrzebowanie na standardowe materiały, usługi lub wydatki inwestycyjne. | ||
| Opis Typ zapotrzebowania, nazywany w SAP również typem dokumentu, to pole konfiguracyjne służące do klasyfikowania zapotrzebowań zakupowych. Różne typy mogą uruchamiać inne workflow akceptacji, mieć odrębne ustawienia pól i odpowiadać różnym celom biznesowym, takim jak zakup standardowych materiałów magazynowych, usług zewnętrznych lub środków trwałych. Analiza procesu według typu zapotrzebowania pozwala sprawdzić, jak obsługiwane są różne rodzaje wniosków. Umożliwia porównanie wyników, czasu realizacji i ścieżek akceptacji między kategoriami. Dzięki temu można ustalić, które typy zapotrzebowań są obsługiwane mniej sprawnie i gdzie warto wprowadzić usprawnienia. Dlaczego to ważne Klasyfikuje zapotrzebowania i umożliwia ich porównywanie. Pomaga sprawdzić, czy różne typy wniosków mają odmienne przebiegi procesu, wąskie gardła lub czas realizacji. Skąd pobrać To pole typu dokumentu BSART w tabeli EBAN. Przykłady NBFORV | |||
| Wartość zapotrzebowania RequisitionAmount | Łączna wartość pieniężna zapotrzebowania zakupowego. | ||
| Opis Wartość zapotrzebowania oznacza łączny szacowany koszt zamawianych towarów lub usług. Często wpływa na złożoność i długość workflow akceptacji. Zapotrzebowania o wyższej wartości zwykle wymagają akceptacji na większej liczbie poziomów. Analiza tego atrybutu pozwala podzielić proces według wartości. Ułatwia odpowiedź na pytania, takie jak: „Czy akceptacja zapotrzebowań o wysokiej wartości trwa dłużej?” lub „Jaka jest wartość zapotrzebowań często odrzucanych?”. To ważny wymiar analizy finansowego wpływu nieefektywności procesu. Dlaczego to ważne Pozwala podzielić proces według wpływu finansowego. Wartość często wiąże się ze złożonością akceptacji i czasem realizacji, dlatego jest ważnym wymiarem analizy procesu. Skąd pobrać Łączna wartość znajduje się w polu GFWERT tabeli EBAN. Wartość pozycji jest zapisana w polu EBAN-PREIS. Przykłady 1500.0075000.50250.75 | |||
| Czas zakończenia EndTime | Dokładna data i godzina zakończenia danego działania. | ||
| Opis EndTime to znacznik czasu określający, kiedy zakończyło się działanie. Wiele zdarzeń generowanych przez system jest natychmiastowych, więc StartTime i EndTime mają tę samą wartość. Zadania wykonywane przez ludzi, takie jak zatwierdzanie, mogą mieć różne godziny rozpoczęcia i zakończenia. EndTime wskazuje moment zakończenia pracy. Oddzielny EndTime pozwala dokładniej mierzyć czas aktywnej pracy i czas oczekiwania. W połączeniu ze StartTime służy do obliczania miary ProcessingTime. Taka szczegółowość ułatwia analizę wykorzystania zasobów i efektywności zadań wykonywanych ręcznie. Dlaczego to ważne Oznacza moment zakończenia działania. Pozwala obliczyć czas aktywnej pracy i dokładniej określić czas trwania zadania. Skąd pobrać Wartość pochodzi z dzienników workflow, które mogą rejestrować zarówno utworzenie elementu pracy (StartTime), jak i jego zakończenie (EndTime). Przykłady 2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z | |||
| Czy ponowne przetwarzanie IsRework | Flaga wskazująca, czy działanie oznacza ponowne przetwarzanie, na przykład zmianę zapotrzebowania po jego przesłaniu. | ||
| Opis Is Rework to obliczana flaga logiczna, która wskazuje działania oznaczające pracę bez wartości dodanej lub powtarzanie czynności. Typowym przykładem w tym procesie jest zdarzenie „Zmieniono zapotrzebowanie” po przesłaniu go do zatwierdzenia. W takiej sytuacji proces zatwierdzania trzeba rozpocząć ponownie. Atrybut ten pozwala zmierzyć skalę ponownego przetwarzania i jego wpływ na całkowity czas realizacji. Dashboard Requisition Amendment and Rework Rate wykorzystuje tę flagę do wskazywania nieefektywności procesu. Ograniczenie ponownego przetwarzania często jest jednym z głównych celów inicjatyw usprawniających procesy, ponieważ pozwala bezpośrednio zaoszczędzić czas i nakład pracy. Dlaczego to ważne Oznacza działania będące stratą czasu lub powtarzaniem pracy. Pozwala bezpośrednio mierzyć skalę ponownego przetwarzania i jego wpływ na efektywność procesu. Skąd pobrać Jest to atrybut obliczany. Zwykle oznacza jako ponowne przetwarzanie każde zdarzenie „Zmieniono zapotrzebowanie”, które wystąpiło po pierwszym zdarzeniu „Przesłano zapotrzebowanie do zatwierdzenia”. Przykłady truefalse | |||
| Data ostatniej aktualizacji danych LastDataUpdate | Znacznik czasu wskazujący, kiedy dane tego rekordu zostały ostatnio odświeżone z systemu źródłowego. | ||
| Opis Ten atrybut zapisuje datę i godzinę ostatniego pobrania lub aktualizacji danych z systemu źródłowego. To ważna metadana, która informuje o aktualności analizowanych danych. Analitycy i użytkownicy biznesowi mogą sprawdzić, czy dane o procesie odzwierciedlają bieżący stan operacji. Przy analizie procesu aktualność danych ma podstawowe znaczenie dla podejmowania świadomych decyzji. Atrybut ten pomaga ustalić, jak aktualnych danych można oczekiwać, i upewnić się, że wnioski opierają się na danych wystarczająco aktualnych dla danej analizy. Dlaczego to ważne Informuje o aktualności danych, co pozwala ocenić wiarygodność analizy i podejmować decyzje biznesowe we właściwym czasie. Skąd pobrać Znacznik czasu jest generowany i dodawany podczas procesu ekstrakcji, transformacji i ładowania danych (ETL). Przykłady 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Nazwa etapu zatwierdzania ApprovalStepName | Nazwa lub opis konkretnego etapu zatwierdzania w workflow. | ||
| Opis Nazwa etapu zatwierdzania to czytelny dla użytkownika opis konkretnego etapu workflow, na przykład „Zatwierdzenie przez kierownika” lub „Zatwierdzenie przez wiceprezesa ds. finansów”. Jest bardziej szczegółowa niż ogólne zdarzenie „Zakończono etap zatwierdzania”. Atrybut ten jest niezbędny w dashboardach Approval Step Cycle Time i Workflow Bottleneck Analysis. Pozwala szczegółowo przeanalizować proces zatwierdzania, wskazać etapy powodujące największe opóźnienia i ustalić, gdzie gromadzą się zadania. Taki poziom szczegółowości ułatwia podjęcie działań w konkretnych miejscach i usprawnienie ścieżki zatwierdzania. Dlaczego to ważne Dostarcza szczegółowych informacji o etapach zatwierdzania, dzięki czemu można precyzyjnie wskazać wąskie gardła w wielopoziomowym workflow zatwierdzania. Skąd pobrać Informacja pochodzi z opisu zadania workflow. Można go znaleźć, łącząc dziennik workflow z tabelami definicji zadań, takimi jak T528T. Przykłady Zatwierdzenie przez kierownikaZatwierdzenie przez dyrektoraZatwierdzenie przez wiceprezesa ds. finansów | |||
| Numer zamówienia zakupu PurchaseOrderNumber | Numer zamówienia zakupu utworzonego na podstawie zapotrzebowania. | ||
| Opis Numer zamówienia zakupu identyfikuje oficjalny dokument zakupowy utworzony na podstawie zaakceptowanego zapotrzebowania. Utworzenie zamówienia zakupu jest często pomyślnym zakończeniem obsługi zapotrzebowania. Oznacza, że wniosek przekształcono w formalne zamówienie u dostawcy. Ten atrybut jest niezbędny do pomiaru KPI czasu od zapotrzebowania do zamówienia zakupu oraz ogólnego współczynnika konwersji. Łączy proces zgłaszania zapotrzebowania z dalszym procesem zakupowym, umożliwiając analizę całego cyklu Purchase-to-Pay. Dlaczego to ważne Łączy zapotrzebowanie z kolejnym dokumentem zakupowym i umożliwia pomiar współczynnika konwersji oraz czasu od zapotrzebowania do zamówienia zakupu. Skąd pobrać Po utworzeniu zamówienia zakupu na podstawie pozycji zapotrzebowania jego numer znajduje się w polu EBELN tabeli EBAN. Przykłady 450001789045000178914500017892 | |||
| Poziom pilności UrgencyLevel | Klasyfikacja pilności zapotrzebowania, która może wpływać na priorytet jego obsługi. | ||
| Opis Poziom pilności określa priorytet zapotrzebowania na zakup. Nie ma do tego standardowego, dedykowanego pola, ale niektóre organizacje wykorzystują na przykład numer śledzenia zapotrzebowania. Dzięki temu wnioskodawcy mogą oznaczać pilne potrzeby wymagające szybszej obsługi. Analiza wpływu pilności pozwala ocenić, czy proces rzeczywiście nadaje priorytet krytycznym zapotrzebowaniom. Dashboard Urgency Level Impact Analysis wykorzystuje ten atrybut do porównania czasu realizacji i wskaźników zatwierdzeń dla zapotrzebowań pilnych i standardowych. Ułatwia to sprawdzenie, czy obsługa priorytetowa działa zgodnie z założeniami. Dlaczego to ważne Pozwala analizować różnice w wynikach procesu dla zapotrzebowań o wysokim priorytecie i sprawdzić, czy pilne sprawy są rzeczywiście obsługiwane szybciej. Skąd pobrać Nie ma standardowego pola określającego pilność. Niektóre firmy wykorzystują w tym celu numer śledzenia zapotrzebowania (EBAN-BEDAR). Informacja może też znajdować się w polu niestandardowym. Przykłady WysokiŚredniNiski | |||
| Przyczyna odrzucenia RejectionReason | Powód podany przy odrzuceniu zapotrzebowania zakupowego. | ||
| Opis Przyczyna odrzucenia wyjaśnia, dlaczego osoba akceptująca odrzuciła zapotrzebowanie zakupowe. Powodem może być przekroczenie budżetu, nieprawidłowe informacje, niezgodność z zasadami lub powielenie innego wniosku. Informacja ta pomaga zrozumieć, dlaczego proces się nie powiódł. Analiza przyczyn odrzuceń pozwala ustalić źródła nieefektywności i poprawek. Jeśli na przykład częstym powodem jest „Nieprawidłowe centrum kosztów”, może to wskazywać na potrzebę lepszego przeszkolenia użytkowników lub walidacji w systemie. Atrybut ten stanowi podstawę dashboardu analizy odrzuceń zapotrzebowań i pomaga precyzyjnie zaplanować usprawnienia procesu. Dlaczego to ważne Wskazuje przyczyny niepowodzeń procesu i pozwala ograniczyć poprawki oraz zwiększyć odsetek zapotrzebowań poprawnych za pierwszym razem. Skąd pobrać Często nie jest to standardowe pole. Informacja może być zapisana w elementach kontenera workflow, długim opisie zapotrzebowania lub polach niestandardowych. Przykłady Przekroczono budżetNieprawidłowy dostawcaPowielony wniosek | |||
| System źródłowy SourceSystem | Wskazuje konkretną instancję SAP S/4HANA, z której wyodrębniono dane. | ||
| Opis Atrybut systemu źródłowego wskazuje system, w którym powstały dane o procesie. W organizacjach korzystających z wielu instancji SAP, na przykład osobnych systemów do rozwoju, zapewniania jakości i produkcji albo systemów dla różnych regionów, pole to zapewnia niezbędny kontekst i wspiera zarządzanie danymi. Pozwala odróżniać dane z różnych źródeł, zapobiega błędnemu łączeniu ich w zestawieniach i umożliwia analizę poszczególnych systemów. Jest wymagany do zachowania pochodzenia danych i możliwości ich śledzenia. Dlaczego to ważne Dostarcza informacji o pochodzeniu danych i wspiera zarządzanie nimi. Ma to szczególne znaczenie w środowiskach z wieloma systemami, gdzie trzeba zapewnić możliwość śledzenia danych. Skąd pobrać Zwykle jest to identyfikator systemu SAP (SID), który można pobrać ze zmiennych systemowych lub tabel konfiguracyjnych. Przykłady S4PECCS4H_PROD_01 | |||
| Waluta Currency | Kod waluty, w której podano wartość zapotrzebowania. | ||
| Opis Ten atrybut określa walutę, w której wyrażono wartość zapotrzebowania, na przykład USD, EUR lub JPY. Dostarcza kontekstu niezbędnego do interpretacji wartości, szczególnie w międzynarodowych organizacjach korzystających z wielu walut. Dokładna analiza finansowa i raportowanie wymagają uwzględnienia waluty. Przed zsumowaniem lub porównaniem wartości zapotrzebowań należy przeliczyć je na wspólną walutę. Ten atrybut jest niezbędny do wykonania takiego przeliczenia. Dlaczego to ważne Uzupełnia informację o wartości zapotrzebowania i umożliwia dokładną analizę finansową oraz porównania w środowiskach wielowalutowych. Skąd pobrać To pole WAERS w tabeli EBAN. Przykłady USDEURGBP | |||
| Wykonane automatycznie IsAutomated | Wskaźnik informujący, czy działanie wykonał użytkownik systemowy, a nie człowiek. | ||
| Opis Atrybut Is Automated to flaga logiczna, która przyjmuje wartość true, jeśli działanie wykonał użytkownik systemowy lub użytkownik wsadowy, na przykład „WF-BATCH” w przypadku działań workflow. Pozwala odróżnić kroki wykonywane ręcznie od tych realizowanych automatycznie. Atrybut ten jest niezbędny do pomiaru poziomu automatyzacji procesu obsługi zapotrzebowań oraz obliczania KPI „Automated Approval Rate”. Analitycy mogą filtrować kroki ręczne i automatyczne, porównywać ich efektywność oraz wskazywać możliwości dalszej automatyzacji, która ograniczy czas przetwarzania i nakład pracy ręcznej. Dlaczego to ważne Pozwala odróżnić działania wykonywane przez ludzi od działań systemowych. Jest to potrzebne do pomiaru poziomu automatyzacji i wskazywania zadań ręcznych, które można zautomatyzować. Skąd pobrać Jest to atrybut pochodny, zwykle wyznaczany na podstawie reguły sprawdzającej, czy identyfikator użytkownika przypisany do zdarzenia znajduje się na liście znanych użytkowników systemowych lub wsadowych. Przykłady truefalse | |||
| Wymagana data dostawy RequiredByDate | Data, do której wnioskodawca potrzebuje zamówionych towarów lub usług. | ||
| Opis Wymagana data dostawy, nazywana w SAP datą dostawy, określa, kiedy potrzebne są towary lub usługi z danej pozycji zapotrzebowania. Ustala ją wnioskodawca i stanowi ona termin docelowy dla całego procesu zakupowego. Ten atrybut jest niezbędny do obliczenia KPI „Odsetek zapotrzebowań zrealizowanych na czas”. Porównanie wymaganej daty dostawy z datą ostatecznej akceptacji lub utworzenia zamówienia zakupu pozwala ocenić, czy organizacja dotrzymuje wewnętrznych poziomów usług i odpowiada na potrzeby biznesowe. Analiza zapotrzebowań, których nie udało się zrealizować w terminie, może ujawnić systemowe opóźnienia w procesie zakupowym. Dlaczego to ważne Określa docelowy termin realizacji zapotrzebowania. Umożliwia pomiar terminowości dostaw i zgodności z wewnętrznymi poziomami usług. Skąd pobrać To data dostawy na poziomie pozycji, zapisana w polu LFDAT tabeli EBAN. Przykłady 2023-11-152023-12-012024-01-20 | |||
Działania w procesie Purchase to Pay: zapotrzebowanie
| Działanie | Opis | ||
|---|---|---|---|
| Odrzucono zapotrzebowanie | Oznacza ostateczne odrzucenie zapotrzebowania zakupowego przez osobę akceptującą, które zatrzymuje proces. Zdarzenie jest rejestrowane przez określoną zmianę statusu wskazującą na odrzucenie. | ||
| Dlaczego to ważne To zdarzenie oznacza niepowodzenie procesu. Analiza częstotliwości i przyczyn odrzuceń oraz etapów, na których do nich dochodzi, pomaga wykryć problemy ze zgodnością z zasadami, budżetem lub jakością wniosków. Skąd pobrać Zdarzenie jest wnioskowane na podstawie zmiany statusu w tabeli EBAN. Status przetwarzania (PROCSTAT) lub wskaźnik zwalniania przyjmuje wartość jednoznacznie oznaczającą „Odrzucono”. Rejestrowanie Należy ustalić na podstawie dokumentów zmian znacznik czasu, w którym ogólny status w tabeli EBAN zmienia się na „Odrzucono”. Typ zdarzenia inferred | |||
| Utworzono zamówienie zakupu | Oznacza utworzenie zamówienia zakupu powiązanego z pozycją zapotrzebowania. To jawne zdarzenie systemowe łączy zapotrzebowanie z kolejnym dokumentem zakupowym. | ||
| Dlaczego to ważne To ważny etap i pomyślny rezultat procesu obsługi zapotrzebowania. Czas od akceptacji zapotrzebowania do utworzenia zamówienia zakupu to istotny KPI efektywności zakupów. Skąd pobrać Zdarzenie jest rejestrowane bezpośrednio po utworzeniu pozycji zamówienia zakupu. Powiązanie jest zapisane w tabeli EKPO (pozycja zamówienia zakupu), która zawiera numer zapotrzebowania źródłowego (BANFN) i numer jego pozycji (BNFPO). Rejestrowanie Należy połączyć tabelę EKPO z tabelą EBAN na podstawie numeru zapotrzebowania i pozycji. Datę utworzenia pozycji zamówienia zakupu należy przyjąć jako moment zdarzenia. Typ zdarzenia explicit | |||
| Utworzono zapotrzebowanie | Oznacza utworzenie dokumentu zapotrzebowania zakupowego w systemie. Zdarzenie jest rejestrowane w chwili pierwszego zapisania nowego zapotrzebowania przez użytkownika, wraz ze znacznikiem czasu utworzenia. | ||
| Dlaczego to ważne To podstawowy punkt początkowy analizy cyklu życia zapotrzebowania. Pozwala mierzyć czas realizacji całego procesu, od rozpoznania potrzeby do ostatecznej akceptacji lub przekształcenia zapotrzebowania w zamówienie zakupu. Skąd pobrać Zdarzenie jest rejestrowane bezpośrednio na podstawie tabeli EBAN, z wykorzystaniem pól daty utworzenia (ERDAT) i godziny utworzenia (ERZEIT) dla danego numeru zapotrzebowania zakupowego (BANFN). Rejestrowanie Dla każdego zapotrzebowania (BANFN) należy użyć pól znacznika czasu utworzenia (ERDAT, ERZEIT) z tabeli EBAN. Typ zdarzenia explicit | |||
| Zaakceptowano zapotrzebowanie | Oznacza pełną i ostateczną akceptację zapotrzebowania zakupowego, które może zostać przekształcone w zamówienie zakupu. Zdarzenie jest wnioskowane, gdy ogólny status zwalniania osiąga końcowy stan akceptacji. | ||
| Dlaczego to ważne To ważny etap potwierdzający pomyślne zakończenie procesu i częsty punkt końcowy analizy czasu realizacji. Oznacza, że zapotrzebowanie przeszło wszystkie kontrole i dział zakupów może je obsłużyć. Skąd pobrać Zdarzenie jest wnioskowane na podstawie zmiany statusu w tabeli EBAN, w szczególności gdy ogólny wskaźnik zwalniania (FRGZU) lub status przetwarzania (PROCSTAT) zostaje ustawiony na końcową wartość „Zaakceptowano”. Rejestrowanie Należy ustalić znacznik czasu zastosowania ostatniego kodu zwalniania lub zmiany ogólnego statusu zapotrzebowania na „Zaakceptowano”. Typ zdarzenia inferred | |||
| Zakończono etap akceptacji | Zdarzenie występuje, gdy osoba akceptująca podejmuje pozytywną decyzję dotyczącą zapotrzebowania, kończąc jeden z etapów wielopoziomowego workflow akceptacji. Jest wnioskowane na podstawie zmiany statusu zwalniania zapotrzebowania. | ||
| Dlaczego to ważne To zdarzenie umożliwia szczegółową analizę workflow akceptacji i pomiar czasu trwania każdego etapu. Pomaga wskazać sprawnie działające osoby akceptujące oraz wąskie gardła procesu. Skąd pobrać Zdarzenie jest wnioskowane na podstawie dokumentów zmian (CDHDR/CDPOS) dla tabeli EBAN. Zmiana statusu kodu zwalniania (np. w polu FRGZU) z niezwolnionego na zwolniony dla danego kodu oznacza wystąpienie tego zdarzenia. Rejestrowanie Należy śledzić zmiany pól statusu zwalniania w tabeli EBAN dla każdego kodu zwalniania określonego w strategii. Typ zdarzenia inferred | |||
| Zamknięto zapotrzebowanie | Oznacza, że pozycja zapotrzebowania została w pełni obsłużona i nie można już utworzyć na jej podstawie kolejnych zamówień zakupu. Status jest zwykle ustawiany automatycznie po zamówieniu całej wymaganej ilości. | ||
| Dlaczego to ważne To zdarzenie oznacza pomyślne zakończenie cyklu życia pozycji zapotrzebowania. Potwierdza, że potrzeba biznesowa została w pełni przełożona na zamówienie zakupu. Skąd pobrać Zdarzenie jest wnioskowane na podstawie tabeli EBAN. Występuje po ustawieniu wskaźnika „Zamknięto” (EBAKZ), zwykle gdy ilość zamówiona w zamówieniach zakupu jest równa ilości z zapotrzebowania. Rejestrowanie Należy znaleźć w dokumentach zmian zdarzenie ustawienia wskaźnika „Zamknięto” (EBAKZ) w tabeli EBAN. Typ zdarzenia inferred | |||
| Przekazano zapotrzebowanie do akceptacji | Oznacza moment formalnego przekazania zapotrzebowania przez wnioskodawcę, co uruchamia workflow akceptacji. Zdarzenie jest zwykle wnioskowane na podstawie ustalenia strategii zwalniania zapotrzebowania i zmiany jego statusu na „W trakcie akceptacji”. | ||
| Dlaczego to ważne To ważny etap, od którego mierzy się KPI czasu akceptacji. Analiza czasu między utworzeniem a przekazaniem zapotrzebowania może ujawnić opóźnienia na etapie jego przygotowania. Skąd pobrać Zdarzenie jest wnioskowane na podstawie dokumentów zmian (CDHDR/CDPOS) dla tabeli EBAN, w szczególności po uzupełnieniu pól strategii zwalniania (np. FRGST) lub zmianie statusu ogólnego (PROCSTAT) na wskazujący, że trwa akceptacja. Rejestrowanie Należy znaleźć pierwszy wpis w dokumentach zmian, który wskazuje na rozpoczęcie workflow akceptacji lub zmianę statusu na „W trakcie akceptacji”. Typ zdarzenia inferred | |||
| Przypisano źródło zaopatrzenia | Oznacza przypisanie przez kupca konkretnego dostawcy, umowy lub rekordu informacyjnego do zaakceptowanej pozycji zapotrzebowania. To ważny etap przygotowania zapotrzebowania do utworzenia zamówienia zakupu. | ||
| Dlaczego to ważne Ten etap łączy akceptację z zamówieniem. Pomiar czasu przypisania źródła zaopatrzenia pomaga wykryć opóźnienia wynikające z obciążenia kupców i ocenić sprawność procesu wyboru źródła. Skąd pobrać Zdarzenie jest wnioskowane po wprowadzeniu wartości w polach tabeli EBAN związanych ze źródłem zaopatrzenia, takich jak stały dostawca (LIFNR), rekord informacyjny (INFNR) lub umowa (KONNR). Rejestrowanie Należy śledzić uzupełnianie pól takich jak LIFNR, INFNR lub KONNR w tabeli EBAN na podstawie dokumentów zmian. Typ zdarzenia inferred | |||
| Rozpoczęto etap akceptacji | Oznacza, że zapotrzebowanie oczekuje na działanie konkretnej osoby akceptującej lub grupy akceptującej. Zdarzenie jest wnioskowane, gdy status zapotrzebowania wskazuje, że oczekuje ono na określony kod zwalniania. | ||
| Dlaczego to ważne To zdarzenie pomaga wskazać wąskie gardła w łańcuchu akceptacji. Analiza czasu trwania tego stanu pozwala wykryć zapotrzebowania, których obsługa utknęła, oraz przeciążone osoby akceptujące. Skąd pobrać Zdarzenie jest wnioskowane na podstawie pól statusu zwalniania w tabeli EBAN (np. FRGZU) i konfiguracji strategii zwalniania. Rozpoczyna się, gdy określony kod zwalniania staje się kolejnym kodem do obsłużenia. Rejestrowanie Należy ustalić, kiedy zapotrzebowanie przechodzi do stanu oczekiwania na akceptację dla określonego kodu zwalniania, na podstawie dzienników workflow lub pól statusu. Typ zdarzenia inferred | |||
| Wycofano zapotrzebowanie | Zdarzenie występuje, gdy pierwotny wnioskodawca anuluje lub usuwa zapotrzebowanie przed zakończeniem jego obsługi. Zwykle jest to bezpośrednie działanie, które ustawia wskaźnik usunięcia dla pozycji zapotrzebowania. | ||
| Dlaczego to ważne Śledzenie wycofań pomaga zrozumieć zmienność popytu i przyczyny anulowania. Wycofanie kończy cykl życia zapotrzebowania i uniemożliwia jego dalszą obsługę. Skąd pobrać Zdarzenie jest rejestrowane bezpośrednio po ustawieniu wskaźnika usunięcia (LOEKZ) dla pozycji zapotrzebowania w tabeli EBAN. Zmiana jest zapisywana w CDHDR/CDPOS. Rejestrowanie Należy znaleźć zdarzenie, w którym wskaźnik usunięcia (LOEKZ) w tabeli EBAN przyjmuje wartość „L”. Typ zdarzenia explicit | |||
| Zmieniono zapotrzebowanie | Zdarzenie występuje, gdy po utworzeniu zapotrzebowania użytkownik zmienia istotne pole, na przykład ilość, cenę lub materiał. Zmiana jest rejestrowana bezpośrednio w systemie dokumentów zmian SAP. | ||
| Dlaczego to ważne Śledzenie zmian pozwala wykrywać pętle poprawek i oceniać ich wpływ na czas realizacji. Częste zmiany mogą wskazywać na problemy z jakością danych lub zmieniające się wymagania. Warto uwzględnić te obszary przy ulepszaniu procesów. Skąd pobrać Zmiany w tabeli EBAN są rejestrowane bezpośrednio w tabelach dokumentów zmian SAP (CDHDR i CDPOS). Każda zmiana śledzonego pola tworzy wpis. Rejestrowanie Należy wyodrębnić zdarzenia zmian z CDHDR/CDPOS, w których klasa obiektu dla zapotrzebowań zakupowych to BANF. Typ zdarzenia explicit | |||
| Zresetowano akceptację | Oznacza zresetowanie całego workflow akceptacji, często z powodu istotnej zmiany zapotrzebowania. Proces akceptacji rozpoczyna się wtedy ponownie od pierwszego poziomu. | ||
| Dlaczego to ważne To zdarzenie wskazuje na poważne poprawki, które znacznie wydłużają czas realizacji. Ustalenie przyczyn resetowania akceptacji pozwala usprawnić proces i ograniczyć opóźnienia. Skąd pobrać Zdarzenie jest wnioskowane na podstawie dokumentów zmian (CDHDR/CDPOS) dotyczących tabeli EBAN. Wykrywa się je, gdy pola statusu zwalniania, takie jak FRGKZ lub FRGZU, zostają wyczyszczone po częściowym lub pełnym uzupełnieniu. Rejestrowanie W dziennikach zmian należy znaleźć przejście statusu zwalniania ze stanu zwolnionego do stanu niezwolnionego. Typ zdarzenia inferred | |||
Instrukcje ekstrakcji danych
Kroki
- Wymagania wstępne: Upewnij się, że użytkownik ma odpowiednie uprawnienia w SAP S/4HANA do korzystania z wymaganych widoków CDS. Zwykle obejmuje to uprawnienia do obiektów takich jak S_TABU_NAM oraz dostęp do narzędzi wyświetlania danych.
- Wybór metody dostępu do systemu: Ustal, jak połączyć się z bazą danych SAP S/4HANA, aby wykonywać zapytania SQL. Można użyć między innymi SAP HANA Studio, środowiska Eclipse z ADT (ABAP Development Tools) lub zewnętrznego klienta SQL, takiego jak DBeaver, który łączy się przez klienta bazy danych SAP HANA.
- Przegląd zapytania SQL: Zapoznaj się z dostarczonym skryptem SQL. Wykorzystuje on Common Table Expressions (CTE) do pobrania danych o różnych działaniach, a następnie łączy je w jeden dziennik zdarzeń.
- Uzupełnienie symboli zastępczych: Znajdź symbole zastępcze w zapytaniu i zastąp je właściwymi wartościami. Ustaw zakres dat ekstrakcji w formacie
[YYYY-MM-DD]i podaj odpowiednie kody spółek ([Your Company Code]). - Wykonanie zapytania: Uruchom pełne, uzupełnione zapytanie SQL na bazie danych SAP S/4HANA. W zależności od ilości danych i wybranego zakresu dat wykonanie może potrwać.
- Wstępna kontrola danych: Po zakończeniu zapytania sprawdź kilka pierwszych wierszy wyników. Upewnij się, że wszystkie kolumny, takie jak PurchaseRequisitionId, ActivityName i EventTime, zawierają oczekiwane wartości i mają prawidłowy format.
- Weryfikacja transformacji danych: Zapytanie przygotowuje dane w formacie odpowiednim do process mining. Funkcje
CASTiCONCATzapewniają spójność typów danych. Po wykonaniu zapytania nie powinny być potrzebne większe dodatkowe transformacje. - Eksport dziennika zdarzeń: Wyeksportuj cały zestaw wyników z klienta SQL do pliku CSV. Ustaw kodowanie UTF-8, aby uniknąć problemów z wyświetlaniem znaków.
- Przygotowanie pliku do przesłania: Przed przesłaniem pliku do narzędzia process mining sprawdź, czy plik CSV ma prawidłowe nagłówki (
PurchaseRequisitionId,ActivityName,EventTimeitd.) oraz czy format daty i godziny w kolumnieEventTimejest spójny i obsługiwany przez platformę docelową. - Przesłanie danych do ProcessMind: Prześlij gotowy plik CSV do projektu ProcessMind. Skonfiguruj projekt, przypisując
PurchaseRequisitionIddo identyfikatora sprawy,ActivityNamedo działania, aEventTimedo znacznika czasu.
Konfiguracja
- Podstawowe widoki CDS: Ekstrakcja wykorzystuje przede wszystkim
I_PurchaseRequisitionAPI01do pobierania podstawowych danych o zapotrzebowaniach,I_ChangeDocumentiI_ChangeDocumentItemdo śledzenia zmian i aktualizacji statusu orazI_PurchaseOrderItemAPI01do powiązania danych z zamówieniami zakupu. - Uprawnienia: Użytkownik wykonujący zapytanie musi mieć dostęp do odczytu wymienionych widoków CDS. W sprawie wymaganych ról i uprawnień należy skontaktować się z zespołem ds. bezpieczeństwa SAP.
- Filtrowanie według zakresu dat: Należy ograniczyć ilość danych, stosując filtr daty utworzenia zapotrzebowania (
CreationDate). Na potrzeby wstępnej analizy zaleca się zakres od 3 do 6 miesięcy. - Filtrowanie organizacyjne: Filtruj dane według
CompanyCode, aby analizować proces we właściwej jednostce biznesowej. Można też użyćPurchaseRequisitionType, aby skupić się na wybranych procesach zakupowych, na przykład zakupie standardowych towarów lub usług. - Konfiguracja dokumentów zmian: Rejestrowanie działań takich jak „Zmieniono zapotrzebowanie” i poszczególnych etapów zatwierdzania zależy od tego, czy w systemie SAP włączono rejestrowanie zmian dla odpowiednich pól. Jeśli brakuje tych zdarzeń, należy sprawdzić konfigurację systemu dla tabeli EBAN.
- Wydajność: W dużych systemach, w których są miliony zapotrzebowań, wykonywanie zapytania za długi okres może obciążyć system. Warto uruchamiać je poza godzinami szczytu lub w środowisku nieprodukcyjnym z niedawno odświeżonymi danymi.
Przykładowe zapytanie sql
WITH REQUISITIONS AS (
SELECT
PurchaseRequisition,
PurchaseRequisitionType,
PurReqnDescription,
CreatedByUser,
CreationDate,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS CreationTimestamp,
SourceOfSupplyIsAssigned
FROM I_PurchaseRequisitionAPI01
WHERE CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
AND CompanyCode IN ('[Your Company Code]')
),
CHANGE_DOCS AS (
SELECT
ObjectValue AS PurchaseRequisition,
UserName,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS ChangeTimestamp,
FieldName,
ValueNew,
ValueOld
FROM I_ChangeDocument AS H
JOIN I_ChangeDocumentItem AS I
ON H.ChangeDocument = I.ChangeDocument
WHERE H.Objectclass = 'EINKBELEG'
AND H.CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
)
-- 1. Requisition Created
SELECT
R.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Created' AS "ActivityName",
R.CreationTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM REQUISITIONS AS R
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON R.PurchaseRequisition = I.PurchaseRequisition
UNION ALL
-- 2. Requisition Submitted For Approval & 5. Approval Step Started
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
CASE
WHEN C.ValueOld = ''
THEN 'Requisition Submitted For Approval'
ELSE 'Approval Step Started'
END AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R
ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew != ''
UNION ALL
-- 3. Requisition Amended
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Amended' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('MENGE', 'PREIS', 'MATNR', 'LIFNR', 'INFNR')
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 4. Approval Reset
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Reset' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueOld != '' AND C.ValueNew = ''
UNION ALL
-- 6. Approval Step Completed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Step Completed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew IN ('1', '2', '3', '4', '5', '6', '7') -- Adjust release codes as per your config
UNION ALL
-- 7. Requisition Approved
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Approved' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGKE' AND C.ValueNew = '2' -- Final release indicator '2' is common for approved
UNION ALL
-- 8. Requisition Rejected
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Rejected' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew = 'B' -- 'B' for Blocked/Rejected is a common setting
UNION ALL
-- 9. Requisition Withdrawn
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Withdrawn' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'LOEKZ' AND C.ValueNew = 'X'
UNION ALL
-- 10. Source of Supply Assigned
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Source of Supply Assigned' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('LIFNR', 'INFNR') AND C.ValueNew != ''
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 11. Purchase Order Created
SELECT DISTINCT
I.PurchaseRequisition AS "PurchaseRequisitionId",
'Purchase Order Created' AS "ActivityName",
CAST(CONCAT(H.PurchaseOrderDate, 'T', LPAD(H.CreationTime, 6, '0')) AS TIMESTAMP) AS "EventTime",
H.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.OrderPriceUnit * I.OrderQuantity AS "RequisitionAmount",
'PO Created' AS "RequisitionStatus"
FROM I_PurchaseOrderItemAPI01 AS I
JOIN I_PurchaseOrderAPI01 AS H
ON I.PurchaseOrder = H.PurchaseOrder
JOIN REQUISITIONS AS R
ON I.PurchaseRequisition = R.PurchaseRequisition
WHERE I.PurchaseRequisition IS NOT NULL AND I.PurchaseRequisition != ''
UNION ALL
-- 12. Requisition Closed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Closed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'EBAKZ' AND C.ValueNew = 'X' Kroki
- Potwierdź, że dostępny jest bezpośredni dostęp do odczytu schematu SAP HANA zawierającego EBAN i EBKN. Ustal też, jakich obiektów dokumentów zmian i dokumentów zakupowych używa system do rejestrowania zmian zapotrzebowań, procesu zwalniania, przypisania źródła, odwołań do zamówień zakupu i zamknięcia. Ponieważ obiekty i pola mogą się różnić w zależności od wersji i konfiguracji, zastąp każdy symbol zastępczy w nawiasach kwadratowych odpowiednim obiektem lub polem z Państwa systemu.
- W SAP GUI użyj transakcji SE16H lub zatwierdzonego narzędzia administracji bazą danych, aby sprawdzić tabele EBAN i EBKN, zweryfikować pola klucza zapotrzebowania oraz potwierdzić dostępność pól daty, godziny, użytkownika, statusu, usunięcia, zwolnienia, przypisania konta i odwołania do dokumentu zakupu. Definicje pól sprawdź w SE11 lub słowniku danych SAP. Podczas testów nie ujawniaj danych produkcyjnych.
- Ustal skonfigurowane źródło dokumentów zmian dla zmian zapotrzebowania i zatwierdzeń. Zapytanie wymaga znormalizowanego źródła zmian o nazwie [Your requisition change document source], zawierającego numer zapotrzebowania, numer pozycji, zmienione pole, starą wartość, nową wartość, datę i godzinę zmiany oraz użytkownika. Przed wykonaniem zapytania powiąż to źródło z odpowiednimi tabelami dokumentów zmian lub widokiem CDS w Państwa systemie.
- Ustal skonfigurowane źródło workflow lub zwolnień dla przesłania do zatwierdzenia, resetu zatwierdzenia, rozpoczęcia i zakończenia etapu zatwierdzania, ostatecznego zatwierdzenia oraz odrzucenia. Zapytanie wymaga źródła [Your requisition approval event source], zawierającego po jednym wierszu dla każdej zmiany statusu lub zwolnienia oraz pola: numer zapotrzebowania, numer pozycji, typ zdarzenia, kod zwolnienia lub grupa zatwierdzająca, osoba zatwierdzająca, data i godzina zdarzenia oraz status. Powiąż je z mechanizmem zapisu zwolnień lub workflow używanym w konfiguracji S/4HANA.
- Ustal źródła przypisania źródła, odwołania do zamówienia zakupu i zamknięcia. Zapytanie wymaga źródeł [Your requisition source assignment source], [Your requisition purchase order reference source] i [Your requisition closure source]. Powiąż te symbole zastępcze z zatwierdzonymi tabelami lub widokami w Państwa systemie. Utworzenie zamówienia zakupu musi wynikać z jawnego odwołania z pozycji zamówienia do pozycji zapotrzebowania, a nie z niepowiązanej aktywności zakupowej.
- Ustaw zakres ekstrakcji za pomocą parametrów [Start date] i [End date]. Przy pierwszym uruchomieniu zaleca się zakres od trzech do sześciu miesięcy. Szerszego zakresu należy użyć dopiero po sprawdzeniu wydajności bazy danych i liczby zdarzeń. Zapytanie filtruje daty utworzenia i zdarzeń, zachowując identyfikator zapotrzebowania jako identyfikator sprawy.
- Wykonaj zapytanie w zatwierdzonym kliencie SQL połączonym z SAP HANA. Zmieniaj wyłącznie dane połączenia poza zapytaniem, parametry dat, filtry specyficzne dla firmy oraz jawnie opisane symbole zastępcze źródeł i pól. Zachowaj dokładne nazwy kolumn wynikowych: PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount i RequisitionStatus.
- Sprawdź duplikaty zdarzeń, precyzję znaczników czasu, obsługę stref czasowych oraz szczegółowość danych na poziomie pozycji lub dokumentu. Zapytanie tworzy identyfikatory spraw na poziomie dokumentu, a kontekst pozycji uwzględnia wewnętrznie. Jeśli kilka pozycji ma to samo działanie i znacznik czasu, zachowaj osobne wiersze, chyba że projekt ProcessMind wyraźnie wymaga usunięcia duplikatów.
- Sprawdź, czy każde wymagane działanie występuje jako wartość ActivityName, pole EventTime jest wypełnione i zawiera wiarygodne chronologicznie dane, a wymagany identyfikator sprawy nie jest pusty. Porównaj liczbę rekordów z raportami SAP lub zatwierdzonymi wyciągami operacyjnymi dla tego samego zakresu dat.
- Wyeksportuj wyniki do pliku CSV w kodowaniu UTF-8 lub innym obsługiwanym przez ProcessMind formacie tabelarycznym. Dodaj wiersz nagłówkowy, zachowaj znaczniki czasu zgodne z ISO, pozostaw puste wartości jako puste pola i prześlij plik, przypisując PurchaseRequisitionId do identyfikatora sprawy, ActivityName do kolumny działania, a EventTime do kolumny znacznika czasu.
Konfiguracja
- Identyfikator sprawy: Użyj numeru dokumentu zapotrzebowania na zakup z tabeli EBAN jako PurchaseRequisitionId. Jeśli proces jest skonfigurowany na poziomie pozycji, użyj udokumentowanego klucza złożonego, na przykład numeru zapotrzebowania i numeru pozycji, i stosuj go do każdego zdarzenia.
- Główne źródło: EBAN zawiera dane pozycji zapotrzebowania. EBKN służy do pobierania przypisania konta oraz uzupełniania danych o dziale lub miejscu powstawania kosztów. Przed wykonaniem zapytania sprawdź dokładne nazwy i typy pól w słowniku danych SAP.
- Źródła zdarzeń: Zapytanie celowo zawiera opisowe symbole zastępcze dla źródeł zmian, zatwierdzeń, przypisania źródła, odwołania do zamówienia zakupu i zamknięcia. Źródła te zależą od wersji S/4HANA, projektu workflow, procedury zwolnień, aktywnych funkcji biznesowych i rozszerzeń klienta.
- Zakres dat: Zacznij od trzech do sześciu miesięcy. Jeśli to możliwe, ogranicz zakres do pól daty z indeksem lub umożliwiających eliminację partycji. Przy ładowaniu przyrostowym nakładaj na siebie zakresy ekstrakcji na tyle, by uwzględnić opóźnione zmiany, a następnie usuwaj duplikaty na podstawie sprawy, działania, znacznika czasu, pozycji i klucza zdarzenia źródłowego.
- Filtry biznesowe: Skonfiguruj [Company code filter], [Document type filter], [Purchasing group filter] i [Plant filter] tylko wtedy, gdy odpowiednie pola są dostępne, a ich znaczenie biznesowe zostało potwierdzone. Jeśli celem jest uchwycenie pełnego cyklu procesu, nie filtruj według statusu.
- Mapowanie statusów: Skonfiguruj wartości dla statusów In Approval, final approved, rejected, reset, pending release code i closed zgodnie ze strategią zwolnień lub konfiguracją workflow w systemie docelowym. Nie zakładaj, że ten sam kod statusu obowiązuje we wszystkich systemach SAP.
- Mapowanie zmian: Uwzględnij zmiany ilości, ceny, materiału, daty dostawy, przypisania konta i innych pól uznanych w Państwa procesie za istotne. Zapytanie zawiera jawne warunki dla wymienionych pól i wymaga, aby źródło udostępniało nazwę zmienionego pola.
- Obsługa znaczników czasu: Połącz datę i godzinę zdarzenia w strefie czasowej bazy danych, a następnie opisz ewentualną konwersję do UTC. Jeśli źródło przechowuje tylko datę, użyj północy wyłącznie wtedy, gdy nie ma dokładniejszego znacznika czasu, i odnotuj to ograniczenie.
- Wydajność: Ogranicz początkową ekstrakcję według daty i zakresu biznesowego, wybieraj tylko wymagane kolumny, unikaj nieograniczonych złączeń z dużymi historiami zmian lub workflow i sprawdź plan wykonania HANA. Jeśli ekstrakcja ma być powtarzana, przygotuj znormalizowane źródła zdarzeń w tabelach pośrednich.
- Uprawnienia i wymagania wstępne: Uzyskaj uprawnienia do odczytu tabel EBAN, EBKN, skonfigurowanych źródeł zmian i workflow, danych o przypisaniu źródła, odwołaniach do zamówień zakupu i zamknięciu. Potwierdź, że bezpośredni dostęp do bazy danych jest zatwierdzony, wymagane funkcje zakupowe i workflow są aktywne oraz dostępna jest wymagana licencja na bazę danych SAP HANA lub odpowiednie narzędzia administracyjne.
- Bezpieczeństwo: Stosuj zasadę minimalnych uprawnień, chroń identyfikatory użytkowników i osób zatwierdzających oraz przestrzegaj wewnętrznych zasad ekstrakcji danych zakupowych i finansowych.
Przykładowe zapytanie sql
WITH
base_items AS (
SELECT
eban.[Purchase requisition number field] AS PurchaseRequisitionId,
eban.[Purchase requisition item field] AS RequisitionItem,
eban.[Creation date field] AS CreationDate,
eban.[Creation time field] AS CreationTime,
eban.[Created by field] AS CreatedBy,
eban.[Requisition type field] AS RequisitionType,
eban.[Company code field] AS CompanyCode,
eban.[Plant field] AS Plant,
eban.[Purchasing group field] AS PurchasingGroup,
eban.[Quantity field] AS Quantity,
eban.[Net price field] AS NetPrice,
eban.[Currency field] AS Currency,
eban.[Material field] AS Material,
eban.[Deletion indicator field] AS DeletionIndicator,
eban.[Overall release status field] AS OverallReleaseStatus,
eban.[Item processing status field] AS ItemProcessingStatus,
ebkn.[Cost center field] AS CostCenter,
ebkn.[Department field] AS Department,
CAST(eban.[Quantity field] * eban.[Net price field] AS DECIMAL(19,4)) AS RequisitionAmount
FROM [Your SAP schema].EBAN eban
LEFT JOIN [Your SAP schema].EBKN ebkn
ON ebkn.[Purchase requisition number field] = eban.[Purchase requisition number field]
AND ebkn.[Purchase requisition item field] = eban.[Purchase requisition item field]
WHERE eban.[Creation date field] BETWEEN '[Start date]' AND '[End date]'
AND ('[Company code filter]' = '' OR eban.[Company code field] = '[Company code filter]')
AND ('[Document type filter]' = '' OR eban.[Requisition type field] = '[Document type filter]')
AND ('[Purchasing group filter]' = '' OR eban.[Purchasing group field] = '[Purchasing group filter]')
AND ('[Plant filter]' = '' OR eban.[Plant field] = '[Plant filter]')
),
created_events AS (
SELECT
PurchaseRequisitionId,
'Requisition Created' AS ActivityName,
TO_TIMESTAMP(CAST(CreationDate AS NVARCHAR(8)) || LPAD(COALESCE(CAST(CreationTime AS NVARCHAR(6)), '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CreatedBy AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
RequisitionType,
Department,
RequisitionAmount,
'Created' AS RequisitionStatus
FROM base_items
),
submitted_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Submitted For Approval' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Requester or submitter field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'SUBMITTED'
OR a.[Status field] = 'In Approval'
),
amended_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Amended' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Amended' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] IN ('QUANTITY', 'PRICE', 'MATERIAL', 'DELIVERY_DATE', 'ACCOUNT_ASSIGNMENT')
),
reset_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Reset' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'RESET'
OR a.[Status field] = 'Approval Reset'
),
step_started_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Started' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_STARTED'
OR a.[Status field] = 'Pending Release'
),
step_completed_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Completed' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_COMPLETED'
OR a.[Status field] = 'Step Approved'
),
approved_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Approved' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'FINAL_APPROVED'
OR a.[Status field] = 'Approved'
),
rejected_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Rejected' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'REJECTED'
OR a.[Status field] = 'Rejected'
),
withdrawn_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Withdrawn' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Withdrawn' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] = 'DELETION_INDICATOR'
AND c.[New value field] IS NOT NULL
AND c.[New value field] <> ''
),
source_assigned_events AS (
SELECT
b.PurchaseRequisitionId,
'Source of Supply Assigned' AS ActivityName,
TO_TIMESTAMP(CAST(s.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(s.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
s.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Source Assigned' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition source assignment source] s
ON s.[Purchase requisition number field] = b.PurchaseRequisitionId
AND s.[Purchase requisition item field] = b.RequisitionItem
WHERE s.[Source identifier field] IS NOT NULL
AND s.[Source identifier field] <> ''
),
purchase_order_events AS (
SELECT
b.PurchaseRequisitionId,
'Purchase Order Created' AS ActivityName,
TO_TIMESTAMP(CAST(p.[Purchase order creation date field] AS NVARCHAR(8)) || LPAD(CAST(p.[Purchase order creation time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
p.[Purchase order creator field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Purchase Order Created' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition purchase order reference source] p
ON p.[Purchase requisition number field] = b.PurchaseRequisitionId
AND p.[Purchase requisition item field] = b.RequisitionItem
WHERE p.[Purchase order number field] IS NOT NULL
AND p.[Purchase order number field] <> ''
),
closed_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Closed' AS ActivityName,
TO_TIMESTAMP(CAST(cl.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(cl.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
cl.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
cl.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition closure source] cl
ON cl.[Purchase requisition number field] = b.PurchaseRequisitionId
AND cl.[Purchase requisition item field] = b.RequisitionItem
WHERE cl.[Event type field] = 'CLOSED'
OR cl.[Status field] = 'Closed'
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM created_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM submitted_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM amended_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM reset_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_started_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_completed_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM approved_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM rejected_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM withdrawn_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM source_assigned_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM purchase_order_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM closed_events
ORDER BY PurchaseRequisitionId, EventTime, ActivityName; Gotowi do rozpoczęcia?
Skorzystaj z tego szablonu, aby przygotować dane i wykorzystać process mining do analizy procesu Purchase to Pay: zapotrzebowanie. Zacznij usprawniać proces już dziś.
Ogranicz opóźnienia w obsłudze zapotrzebowań P2P. Usprawnij workflow.
Usprawnij procesy, skróć czas realizacji i ogranicz czas cyklu o 30%.
Karta kredytowa nie jest wymagana. Konfiguracja zajmuje 5 minut.