> Ciągłe doskonalenie procesów > Od zapotrzebowania do płatności: zapotrzebowanie > SAP ECC > Szablon danych

Szablon danych procesu zapotrzebowania od zakupu do płatności

SAP ECC

← Wróć do przewodnika ulepszania procesów

Atrybuty procesu zapotrzebowania od zakupu do płatności(19) Działania w procesie zapotrzebowania od zakupu do płatności(13) Instrukcje ekstrakcji danych(2)

Szablon danych procesu zapotrzebowania od zakupu do płatności

Szablon zawiera wskazówki dotyczące gromadzenia danych potrzebnych do analizy procesu zapotrzebowania od zakupu do płatności. Opisuje pola danych do zebrania, działania do śledzenia oraz sposoby pobierania tych informacji z systemu źródłowego. Można z niego skorzystać, aby przygotować dane do analizy process mining.

Zalecane atrybuty do zebrania
Działania do śledzenia
Wskazówki dotyczące ekstrakcji danych z SAP ECC

Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Pobierz szablon

Atrybuty procesu zapotrzebowania od zakupu do płatności

Poniżej przedstawiono zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby dokładnie analizować proces zapotrzebowania od zakupu do płatności.

5 Wymagane 5 Zalecane 9 Opcjonalne

	Nazwa	Opis
	Czas zdarzenia EventTime	Znacznik czasu wskazujący, kiedy wystąpiła dana czynność.
Opis Czas zdarzenia określa dokładną datę i godzinę wykonania danej czynności. Ten znacznik czasu jest podstawą analiz czasowych w process mining, takich jak obliczanie czasu trwania procesu, identyfikowanie wąskich gardeł i ocena jego wyników. W procesie obsługi zapotrzebowań zakupowych ten atrybut pozwala obliczać KPI, takie jak „Średni czas zatwierdzania zapotrzebowania” i „Czas do utworzenia zamówienia zakupu”. Umożliwia też tworzenie dashboardów pokazujących czas trwania poszczególnych etapów, na przykład analizę cyklu zatwierdzania zapotrzebowania. Dostarcza danych potrzebnych do pomiaru czasu między dowolnymi punktami procesu. Dlaczego to ważne Ten znacznik czasu jest niezbędny do obliczania czasu trwania, analizy wyników procesu i wykrywania wąskich gardeł związanych z czasem. Skąd pobrać Dane znajdują się w tabeli nagłówków dokumentów zmian CDHDR, w polach UDATE i UTIME. Przykłady 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
	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 ECC. Pełni funkcję centralnego identyfikatora case i łączy wszystkie działania oraz zmiany dotyczące danego zapotrzebowania, od jego utworzenia po ostateczne rozstrzygnięcie, na przykład przekształcenie w zamówienie zakupu lub zamknięcie. W process mining ten identyfikator jest niezbędny do odtworzenia pełnego cyklu życia każdego zapotrzebowania. Śledząc go, analitycy mogą wizualizować cały przebieg procesu, mierzyć czas między etapami i analizować różnice w obsłudze poszczególnych zapotrzebowań. Pozwala to uzyskać spójny obraz całego procesu. Dlaczego to ważne To podstawowy identyfikator, który łączy wszystkie powiązane zdarzenia procesu w jeden case i umożliwia analizę procesu od początku do końca. Skąd pobrać Znajduje się w tabeli EBAN, w polu BANFN. Przykłady 100234567810023456791002345680
	Nazwa działania ActivityName	Nazwa działania biznesowego, które miało miejsce w określonym czasie.
Opis Ten atrybut opisuje konkretny etap lub zdarzenie w cyklu życia zapotrzebowania zakupowego, na przykład „Utworzono zapotrzebowanie”, „Przekazano do akceptacji” lub „Utworzono zamówienie zakupu”. Działania te są zazwyczaj ustalane na podstawie zmian statusu, dzienników workflow lub dokumentów zmian w SAP. Analiza kolejności i częstotliwości działań stanowi podstawę process mining. Umożliwia odkrywanie rzeczywistego przebiegu procesu, w tym typowych ścieżek, odstępstw i wąskich gardeł. Jest to niezbędne do tworzenia dashboardów, takich jak mapa procesu obsługi zapotrzebowań od początku do końca, oraz obliczania KPI związanych z poprawkami i zgodnością. Dlaczego to ważne Określa etapy procesu, umożliwiając wizualizację map procesu i analizę różnic w ich przebiegu. Skąd pobrać Na podstawie tabel dokumentów zmian CDHDR i CDPOS, dzienników workflow lub pól statusu, takich jak EBAN-STATU. Przykłady Utworzono zapotrzebowanieZaakceptowano etapOdrzucono zapotrzebowanieUtworzono zamówienie zakupu
	Data ostatniej aktualizacji danych LastDataUpdate	Znacznik czasu ostatniego odświeżenia danych lub ich pobrania z systemu źródłowego.
Opis Ten atrybut wskazuje, kiedy zbiór danych został ostatnio zaktualizowany. Jest to stały znacznik czasu przypisywany do całego zbioru przy każdym załadowaniu danych. Informuje, jak aktualne są dane używane w analizie. Przy podejmowaniu decyzji na podstawie dashboardu lub analizy process mining ważne jest, by wiedzieć, kiedy dane zostały zebrane. Ten atrybut pokazuje wszystkim zainteresowanym, jaki okres obejmują wyświetlane dane, i pomaga uniknąć wniosków opartych na nieaktualnych informacjach. Dlaczego to ważne Informuje o aktualności danych, co ma znaczenie dla trafności i dokładności analizy procesu. Skąd pobrać To stała wartość oznaczająca czas pobrania danych, dodawana podczas procesu ETL. Przykłady 2024-01-15T04:00:00Z2024-01-16T04:00:00Z
	System źródłowy SourceSystem	Wskazuje system źródłowy, z którego pobrano dane.
Opis Ten atrybut określa pochodzenie danych o procesie, na przykład „SAP ECC Production” lub „S4HANA QA”. Zwykle jest to stała wartość dodawana podczas ekstrakcji danych, która zapewnia kontekst, zwłaszcza gdy dane pochodzą z wielu systemów. W analizie procesu pozwala rozróżnić dane z różnych źródeł i uniknąć zniekształceń wynikających z łączenia danych ze środowisk produkcyjnych, testowych i deweloperskich. To podstawowe metadane potrzebne do zarządzania danymi i śledzenia ich pochodzenia. Dlaczego to ważne Zapewnia kontekst dotyczący pochodzenia danych, ułatwia śledzenie ich źródła i analizę danych z wielu systemów. Skąd pobrać To stała wartość dodawana zwykle podczas procesu ekstrakcji, transformacji i ładowania danych (ETL). Przykłady SAP_ECC_PRODS4HANA_EU_100ECC_US_FINANCE
	Dział Department	Dział zgłaszającego lub centrum kosztów przypisane do zapotrzebowania.
Opis Ten atrybut wskazuje jednostkę biznesową lub dział, który zainicjował zapotrzebowanie zakupowe. Informacje te pochodzą zwykle z profilu zgłaszającego lub z centrum kosztów przypisanego do pozycji zapotrzebowania. Analiza procesu według działów pozwala porównać wyniki w różnych częściach organizacji. To podstawowy wymiar dashboardu „Czas cyklu zatwierdzania zapotrzebowania” i KPI „Różnice w czasie zatwierdzania między działami”. Pomaga wskazać działy, w których proces przebiega sprawnie, oraz te, które mogą potrzebować usprawnień lub dodatkowych zasobów. Dlaczego to ważne Umożliwia porównanie wyników jednostek biznesowych i wskazanie wąskich gardeł oraz niespójności w procesie poszczególnych działów. Skąd pobrać Atrybut można wyznaczyć, łącząc zgłaszającego (EBAN-AFNAM) z danymi podstawowymi użytkowników (SU01) albo korzystając z centrum kosztów (EBKN-KOSTL) przypisanego do konta zapotrzebowania. Przykłady FinanseOperacje ITMarketingProdukcja
	Łączna wartość zapotrzebowania TotalRequisitionValue	Łączna wartość pieniężna wszystkich pozycji zapotrzebowania zakupowego.
Opis Ten atrybut określa łączną wartość zapotrzebowania zakupowego. Wartość często wpływa na wymagany workflow zatwierdzania. Zapotrzebowania o wyższej wartości zwykle wymagają dokładniejszej weryfikacji i większej liczby zatwierdzeń. Analiza według wartości pokazuje, jak wpływ finansowy wiąże się z przebiegiem procesu. Można sprawdzić, czy zatwierdzanie zapotrzebowań o wysokiej wartości trwa dłużej, czy są one częściej odrzucane albo czy przebiegają inną ścieżką. To także podstawowa miara przepływu finansowego w procesie zakupowym. Dlaczego to ważne Pozwala powiązać przebieg procesu ze skutkami finansowymi, co pomaga analizować ryzyko i złożoność zatwierdzania. Skąd pobrać Suma wartości wszystkich pozycji. Wartość pozycji znajduje się w tabeli EBAN, w polu GSWER. Walutę określa pole EBAN-WAERS. Przykłady 1500.00250.50125000.00
	Nazwa użytkownika User	Identyfikator użytkownika, który wykonał daną czynność.
Opis Ten atrybut wskazuje użytkownika odpowiedzialnego za zdarzenie, na przykład utworzenie zapotrzebowania, zatwierdzenie etapu lub zmianę dokumentu. W SAP jest to zwykle identyfikator użytkownika. Analiza według użytkownika pomaga określić potrzeby szkoleniowe, ocenić wyniki pracy poszczególnych osób i wykryć potencjalne źródła błędów przy wprowadzaniu danych. Atrybut ten jest potrzebny w dashboardach, takich jak „Liczba utworzonych zapotrzebowań według zgłaszającego”, a także do analizy rozkładu obciążenia pracą i zgodności z zasadą rozdziału obowiązków. Dlaczego to ważne Przypisuje czynności do konkretnych osób, umożliwiając analizę wyników pracy, obciążenia, zgodności i potrzeb szkoleniowych. Skąd pobrać Dane o zmianach znajdują się w tabeli nagłówków dokumentów zmian CDHDR, w polu USERNAME. Twórcę zapotrzebowania wskazuje pole ERNAM w tabeli EBAN. Przykłady SMITHJR.DOEUSER123
	Status zapotrzebowania RequisitionStatus	Bieżący status realizacji zapotrzebowania zakupowego.
Opis Ten atrybut wskazuje ogólny status zapotrzebowania w danym momencie, na przykład „W trakcie zatwierdzania”, „Zatwierdzone”, „Odrzucone” lub „Zamknięte”. W SAP status jest często zapisany jako kod. Śledzenie statusu pozwala ustalić, jak zakończyła się obsługa zapotrzebowania. Atrybut ten bezpośrednio wspiera dashboard „Wyniki obsługi zapotrzebowań i wskaźniki odrzuceń” oraz KPI, takie jak „Wskaźnik odrzuceń zapotrzebowań” i „Wskaźnik wycofań zapotrzebowań”. Analiza zmian statusu pomaga wykryć nieefektywne etapy i miejsca, w których proces się zatrzymuje. Dlaczego to ważne Określa wynik obsługi zapotrzebowania, co pozwala analizować wskaźniki powodzenia, przyczyny odrzuceń i zakończenie procesu. Skąd pobrać Status realizacji znajduje się w tabeli EBAN, w polu STATU. Status zatwierdzenia znajduje się w polu EBAN-FRGZU. Przykłady N (nieedytowane)B (utworzono zamówienie zakupu)A (utworzono zapytanie ofertowe)K (zamknięte)
	Typ dokumentu RequisitionDocumentType	Klasyfikacja określająca rodzaj i właściwości zapotrzebowania zakupowego.
Opis Typ dokumentu w SAP określa różne właściwości zapotrzebowania zakupowego, w tym zakres numeracji, wybór pól i przebieg procesu zakupowego. Przykłady to „Standardowe zapotrzebowanie”, „Przesunięcie zapasów” i „Zapotrzebowanie na usługi”. Ten atrybut pozwala analizować dane według kategorii, ponieważ różne typy dokumentów często mają odrębne przebiegi procesu i wymagania dotyczące zatwierdzania. Analitycy mogą porównywać wyniki obsługi poszczególnych typów zapotrzebowań, sprawdzać zgodność i wskazywać możliwości standaryzacji lub dostosowania procesu. Dlaczego to ważne Pozwala podzielić zapotrzebowania na kategorie procesów, co ułatwia dokładniejszą i trafniejszą analizę. Skąd pobrać Dane znajdują się w tabeli EBAN, w polu BSART. Przykłady NBUBRV
	Czy wymaga ponownej pracy IsRework	Wartość logiczna wskazująca, czy zapotrzebowanie wymagało ponownej pracy, na przykład zmiany po przesłaniu.
Opis Ten atrybut pochodny oznacza czynności lub sprawy, które wymagały ponownej pracy. Na przykład czynność „Zmieniono zapotrzebowanie” wykonana po „Przesłaniu do zatwierdzenia” jest traktowana jako ponowna praca. Może ją również oznaczać odrzucenie, po którym proces wraca do wcześniejszego etapu. Ten wskaźnik jest potrzebny w dashboardzie „Analiza zmian i ponownej pracy przy zapotrzebowaniach”. Ułatwia filtrowanie i mierzenie ponownej pracy, ocenę jej wpływu na całkowity czas procesu oraz ustalenie przyczyn nieefektywności. Częsta ponowna praca może wskazywać na problemy z jakością danych lub niejasne wymagania. Dlaczego to ważne Pomaga mierzyć częstotliwość i wpływ ponownej pracy, ułatwiając wykrywanie i analizę nieefektywności oraz pętli w procesie. Skąd pobrać Atrybut wyznacza się na podstawie dziennika zdarzeń, wyszukując określone sekwencje czynności, na przykład „Zmieniono zapotrzebowanie” po czynności zatwierdzania. Przykłady truefalse
	Grupa materiałowa MaterialGroup	Grupa lub kategoria, do której należy zamawiany materiał albo usługa.
Opis Grupa materiałowa służy do łączenia materiałów i usług o podobnych właściwościach. Umożliwia analizę zakupów według kategorii. Analiza według grup materiałowych wspiera strategiczne zarządzanie zakupami i analizę wydatków. W process mining można sprawdzić, czy zapotrzebowania dotyczące określonych kategorii, takich jak „Sprzęt IT” lub „Usługi profesjonalne”, przebiegają inną ścieżką albo wymagają dłuższego zatwierdzania. Takie informacje przydają się w raporcie jakości danych zapotrzebowań i pomagają zrozumieć różnice w procesie zależne od rodzaju zakupu. Dlaczego to ważne Umożliwia analizę wydatków i procesu według kategorii zakupowej, wspiera strategiczne zarządzanie zakupami i pomaga wykrywać wąskie gardła charakterystyczne dla danej kategorii. Skąd pobrać Dane znajdują się w tabeli EBAN, w polu MATKL. Przykłady 00101L001IT-SFTWR
	Grupa zakupowa PurchasingGroup	Grupa kupujących odpowiedzialna za zakup zamawianych pozycji.
Opis Grupa zakupowa to jednostka organizacyjna odpowiedzialna za określone działania zakupowe. Obejmuje kupujących, którzy zajmą się zapotrzebowaniem po jego zatwierdzeniu. Ten atrybut pozwala analizować obciążenie pracą i wyniki poszczególnych zespołów zakupowych. Pomaga sprawdzić, czy niektóre grupy opóźniają przekształcanie zapotrzebowań w zamówienia zakupu albo czy sprawniej obsługują określone typy zapotrzebowań. Umożliwia analizę zasobów i wyników pracy w obszarze zakupów. Dlaczego to ważne Wskazuje odpowiedzialność za zakupy, umożliwiając analizę obciążenia pracą i porównanie wyników zespołów zakupowych. Skąd pobrać Dane znajdują się w tabeli EBAN, w polu EKGRP. Przykłady 001002P01
	Identyfikator dostawcy VendorId	Unikalny identyfikator sugerowanego lub przypisanego dostawcy.
Opis Ten atrybut zawiera identyfikator preferowanego lub wskazanego w umowie dostawcy zamawianej pozycji. Dane mogą być wstępnie uzupełnione lub wskazane przez zgłaszającego. Analiza zapotrzebowań według dostawcy pozwala ocenić, jak wcześniejszy wybór dostawcy wpływa na proces zakupowy. Można na przykład sprawdzić, czy zapotrzebowania ze wskazanym dostawcą są zatwierdzane szybciej albo czy określeni dostawcy wiążą się z większą liczbą odrzuceń. Atrybut pokazuje, jak dostawcy są angażowani na wczesnym etapie procesu. Dlaczego to ważne Pozwala analizować relacje z preferowanymi dostawcami oraz ich wpływ na czas i wyniki obsługi zapotrzebowań. Skąd pobrać Dane znajdują się w tabeli EBAN, w polu LIFNR (dostawca przypisany na stałe). Przykłady 100030025V9876
	Identyfikator zamówienia zakupu PurchaseOrderId	Identyfikator zamówienia zakupu utworzonego na podstawie zapotrzebowania.
Opis Ten atrybut łączy zapotrzebowanie zakupowe z utworzonym na jego podstawie zamówieniem zakupu. Jedno zapotrzebowanie może czasem prowadzić do utworzenia kilku zamówień. To powiązanie jest niezbędne do analizy przekazania sprawy z procesu obsługi zapotrzebowania do procesu zakupowego. Pozwala obliczyć KPI „Czas od zapotrzebowania do utworzenia zamówienia zakupu” i zasila dashboard „Opóźnienie między zatwierdzeniem zapotrzebowania a utworzeniem zamówienia zakupu”. Analiza tego powiązania pomaga ocenić sprawność całego cyklu od zakupu do płatności. Dlaczego to ważne Łączy proces obsługi zapotrzebowania z dalszym etapem zakupów, umożliwiając analizę opóźnień przy przekazywaniu sprawy. Skąd pobrać Numer zamówienia zakupu po jego utworzeniu jest zapisywany w tabeli EBAN, w polu EBELN. Przykłady 450001712345000171244500017125
	Imię i nazwisko zgłaszającego RequesterName	Imię i nazwisko osoby, która zgłosiła zapotrzebowanie na towary lub usługi.
Opis Ten atrybut wskazuje osobę, która zainicjowała zapotrzebowanie zakupowe, czyli zgłosiła potrzebę zakupu danych pozycji. Śledzenie zgłaszających pozwala analizować wzorce składania zapotrzebowań przez poszczególne osoby i grupy. Dashboard „Liczba utworzonych zapotrzebowań według zgłaszającego” pomaga wskazać osoby często korzystające z procesu, użytkowników wymagających dodatkowego szkolenia oraz działy o dużej aktywności zakupowej. Pokazuje, kto inicjuje proces. Dlaczego to ważne Wskazuje osobę inicjującą proces, co pozwala analizować wzorce tworzenia zapotrzebowań i lepiej kierować szkolenia do użytkowników. Skąd pobrać Dane znajdują się w tabeli EBAN, w polu AFNAM. Przykłady Alice WilliamsBob JohnsonCharlie Brown
	Priorytet Priority	Poziom pilności przypisany do zapotrzebowania zakupowego.
Opis Ten atrybut określa priorytet zapotrzebowania, na przykład „Pilne”, „Wysoki” lub „Normalny”. Informuje osoby zatwierdzające i kupujących, że wniosek wymaga szybszej obsługi. Atrybut ten jest potrzebny w dashboardzie „Wyniki obsługi pilnych zapotrzebowań” i KPI „Skuteczność oznaczenia pilności”. Analiza pozwala sprawdzić, czy zapotrzebowania oznaczone jako pilne są obsługiwane szybciej niż standardowe. Dzięki temu można ocenić skuteczność nadawania priorytetów i sprawdzić, czy pilne potrzeby biznesowe są realizowane na czas. Dlaczego to ważne Pozwala sprawdzić, czy pilne zapotrzebowania są obsługiwane szybciej, i ocenić skuteczność nadawania priorytetów. Skąd pobrać To pole nie występuje standardowo w tabeli EBAN. Często jest dodawane jako pole niestandardowe lub określane na podstawie numeru śledzenia zapotrzebowania (EBAN-BEDNR) albo konkretnego typu dokumentu. Przykłady 123
	Przyczyna odrzucenia RejectionReason	Powód podany przy odrzuceniu zapotrzebowania lub etapu zatwierdzania.
Opis Ten atrybut zapisuje uzasadnienie odrzucenia zapotrzebowania zakupowego. Osoba zatwierdzająca zwykle wpisuje je jako tekst lub wybiera kod z predefiniowanej listy podczas odrzucania. Analiza przyczyn odrzuceń pomaga usprawniać proces. Pokazuje, dlaczego zapotrzebowania nie są realizowane, na przykład z powodu naruszenia zasad, błędnych danych lub braku budżetu. Dane te są potrzebne w dashboardzie „Wyniki obsługi zapotrzebowań i wskaźniki odrzuceń” oraz pomagają ustalić źródła nieefektywności procesu. Dlaczego to ważne Pokazuje, dlaczego zapotrzebowania są odrzucane, co ułatwia ukierunkowanie usprawnień procesu i szkoleń użytkowników. Skąd pobrać Dane te są zwykle przechowywane w dziennikach workflow lub w długim tekście powiązanym ze zdarzeniem odrzucenia. Tabela EBAN nie zawiera standardowego pola na tę informację. Przykłady Nieprawidłowe centrum kosztówPrzekroczony budżetZduplikowane zapotrzebowanieNiezgodność z zasadami
	Zakład Plant	Lokalizacja firmy lub zakład, dla którego zamówiono towary albo usługi.
Opis Zakład to jednostka organizacyjna firmy odpowiadająca lokalizacji fizycznej, takiej jak fabryka, magazyn lub biuro. W zapotrzebowaniu wskazuje się zakład, do którego mają trafić zamawiane pozycje. Analiza według zakładu pozwala porównywać przebieg procesu w różnych lokalizacjach. Może ujawnić różnice w wynikach, które wynikają z lokalnych procedur, liczby pracowników lub potrzeb biznesowych. Zakład jest często wykorzystywany jako wymiar w dashboardach dotyczących wyników regionalnych. Dlaczego to ważne Zapewnia kontekst geograficzny i lokalizacyjny, pomagając wykrywać różnice w przebiegu procesu i wynikach poszczególnych regionów. Skąd pobrać Dane znajdują się w tabeli EBAN, w polu WERKS. Przykłady 10002100DE01

Wymagane Zalecane Opcjonalne

Działania w procesie zapotrzebowania od zakupu do płatności

Poniżej przedstawiono najważniejsze kroki i etapy procesu, które warto zapisać w dzienniku zdarzeń, aby prawidłowo odkrywać i analizować workflow obsługi zapotrzebowań.

6 Zalecane 7 Opcjonalne

	Działanie	Opis
	Odrzucono zapotrzebowanie	To końcowe działanie oznacza definitywne odrzucenie zapotrzebowania zakupowego, które nie może być dalej realizowane. Wnioskuje się o nim, gdy osoba akceptująca ustawi w tabeli EBAN końcowy wskaźnik odrzucenia.
Dlaczego to ważne To ważny punkt końcowy procesu, niezbędny do obliczenia KPI odsetka odrzuconych zapotrzebowań. Analiza takich przypadków pomaga ustalić przyczyny niepowodzeń zakupowych i strat. Skąd pobrać Wnioskuje się o nim na podstawie znacznika czasu wpisu w dzienniku zmian CDPOS dla tabeli EBAN i pola FRGZU, gdy pole przyjmuje wartość oznaczającą ostateczne odrzucenie. Rejestrowanie Wnioskuje się o nim, gdy końcowy wskaźnik zwalniania w tabeli EBAN osiąga status „odrzucone”. Typ zdarzenia inferred
	Przekazano do akceptacji	To działanie oznacza, że zapotrzebowanie trafiło do formalnego workflow akceptacji. Zazwyczaj wnioskuje się o nim na podstawie zmiany statusu zapotrzebowania na wymagający pierwszego zwolnienia lub akceptacji zgodnie ze skonfigurowaną strategią zwalniania.
Dlaczego to ważne To początek czasu cyklu akceptacji, ważnego KPI służącego do pomiaru sprawności procesu. Ustalenie tego momentu pozwala oddzielić opóźnienia między utworzeniem zapotrzebowania a rozpoczęciem formalnej akceptacji. Skąd pobrać Wnioskuje się o nim na podstawie pierwszej zmiany statusu związanej ze strategią zwalniania w tabeli EBAN, na przykład zmiany pola FRGZU ze stanu początkowego na oczekujący, lub pierwszego wpisu w dzienniku workflow powiązanym z zapotrzebowaniem. Rejestrowanie Wnioskuje się o nim na podstawie pierwszego wpisu w dzienniku zmian wskazującego na aktywację strategii zwalniania. Typ zdarzenia inferred
	Utworzono zamówienie zakupu	To działanie oznacza pomyślne przekształcenie zatwierdzonego zapotrzebowania zakupowego w dokument zamówienia zakupu. Zdarzenie jest przypisywane do zapotrzebowania po znalezieniu odpowiadającej mu pozycji zamówienia zakupu.
Dlaczego to ważne To główny pomyślny wynik procesu: kończy obsługę zapotrzebowania i rozpoczyna etap zakupów. Czas między zdarzeniami „Zatwierdzono zapotrzebowanie” i „Utworzono zamówienie zakupu” jest ważnym KPI efektywności przekazania. Skąd pobrać Wnioskuje się o nim, znajdując w tabeli EKPO (pozycje zamówień zakupu) rekord, w którym pola BANFN i BNFPO odpowiadają numerowi i pozycji zapotrzebowania z tabeli EBAN. Znacznik czasu pochodzi z daty utworzenia zamówienia zakupu (EKKO.AEDAT). Rejestrowanie Wnioskuje się o nim, łącząc tabele EBAN i EKPO oraz korzystając z daty utworzenia zamówienia zakupu z tabeli EKKO. Typ zdarzenia inferred
	Utworzono zapotrzebowanie	To działanie oznacza utworzenie i zapisanie przez użytkownika nowego zapotrzebowania zakupowego. Zdarzenie jest rejestrowane, gdy w tabeli EBAN powstaje nowy rekord, wraz z datą i godziną utworzenia.
Dlaczego to ważne Jako początek procesu działanie to pozwala obliczyć całkowity czas obsługi zapotrzebowania i analizować tempo tworzenia nowych zgłoszeń. Pomaga też ustalić, kto i kiedy tworzy zapotrzebowania. Skąd pobrać Zdarzenie jest odczytywane z tabeli EBAN na podstawie pól daty utworzenia (ERDAT) i godziny utworzenia (UZEIT) dla danego identyfikatora zapotrzebowania zakupowego (BANFN). Rejestrowanie Znacznik czasu z pól ERDAT i UZEIT tabeli EBAN, zapisany przy pierwszym zapisie rekordu. Typ zdarzenia explicit
	Wycofano zapotrzebowanie	To końcowe działanie oznacza anulowanie pozycji zapotrzebowania przez autora lub uprawnionego użytkownika poprzez ustawienie wskaźnika usunięcia. Jest ono jawnie rejestrowane i wskazuje, że potrzeba biznesowa przestała być aktualna lub zapotrzebowanie utworzono przez pomyłkę.
Dlaczego to ważne To ważny punkt końcowy oznaczający niepowodzenie procesu, niezbędny do obliczenia odsetka wycofanych zapotrzebowań. Wysoki odsetek może wskazywać, że długi czas akceptacji skłania użytkowników do rezygnacji albo że występują problemy z planowaniem popytu. Skąd pobrać Działanie jest rejestrowane, gdy dla pozycji zapotrzebowania w tabeli EBAN zostaje ustawione pole „Wskaźnik usunięcia” (LOEKZ). Zmiana jest zapisywana w tabelach CDHDR i CDPOS. Rejestrowanie Wpis w dzienniku zmian utworzony po ustawieniu wskaźnika usunięcia (EBAN-LOEKZ) na „L”. Typ zdarzenia explicit
	Zatwierdzono zapotrzebowanie	To zdarzenie oznacza, że zapotrzebowanie zakupowe przeszło wszystkie wymagane etapy akceptacji. Wnioskuje się o nim, gdy zastosowano końcowy kod zwalniania, a ogólny wskaźnik zwalniania (FRGZU) w tabeli EBAN przyjmuje status zatwierdzenia.
Dlaczego to ważne To ważny moment, który kończy cykl akceptacji i rozpoczyna etap zakupów. Pozwala obliczyć KPI całkowitego czasu akceptacji i zmierzyć opóźnienie między przekazaniem zapotrzebowania a utworzeniem zamówienia zakupu. Skąd pobrać Wnioskuje się o nim na podstawie znacznika czasu wpisu w dzienniku zmian CDPOS dla tabeli EBAN i pola FRGZU, gdy pole przyjmuje wartość oznaczającą ostateczną akceptację. Rejestrowanie Wnioskuje się o nim, gdy końcowy wskaźnik zwalniania w tabeli EBAN osiąga status „zatwierdzone”. Typ zdarzenia inferred
	Odrzucono etap	Uprawniony użytkownik formalnie odrzucił etap strategii zwalniania, zwykle odsyłając zapotrzebowanie do autora w celu korekty. Działanie jest zapisywane jako zmiana statusu zwalniania zapotrzebowania.
Dlaczego to ważne Odrzucenia są częstą przyczyną poprawek i opóźnień. Analiza ich liczby i przyczyn pomaga wykryć nieporozumienia dotyczące zasad, problemy z jakością danych lub nieefektywne etapy akceptacji. Skąd pobrać Dane pochodzą z dzienników zmian (CDHDR/CDPOS) dotyczących pól statusu zwalniania w tabeli EBAN. Odrzucenie w transakcji ME54N lub podobnej powoduje odpowiednią zmianę statusu. Rejestrowanie Wpis w dzienniku zmian utworzony po odrzuceniu zapotrzebowania przez osobę akceptującą. Typ zdarzenia explicit
	Rozpoczęto etap akceptacji	Oznacza, że zapotrzebowanie oczekuje na działanie konkretnej osoby akceptującej lub grupy akceptującej wskazanej w strategii zwalniania. Zdarzenie jest wywnioskowane ze statusu zapotrzebowania, który wskazuje oczekiwanie na określony kod zwalniania.
Dlaczego to ważne To działanie umożliwia szczegółową analizę poszczególnych etapów ścieżki akceptacji. Pomaga ustalić, które osoby lub etapy powodują największe opóźnienia. Skąd pobrać Wnioskuje się o nim, śledząc kolejność zmian pól statusu zwalniania w tabeli EBAN. Każda zmiana na nowy status oczekujący oznacza rozpoczęcie kolejnego etapu akceptacji. Rejestrowanie Wnioskuje się o nim na podstawie zmian statusu wskazujących, że nowy kod zwalniania jest aktywny i oczekuje na akceptację. Typ zdarzenia inferred
	Skorygowano zapotrzebowanie	Oznacza każdą zmianę zapotrzebowania zakupowego po jego utworzeniu, na przykład zmianę ilości, ceny lub materiału. Zmiany są zapisywane w tabelach dziennika zmian SAP, co zapewnia szczegółową historię modyfikacji.
Dlaczego to ważne Śledzenie korekt pomaga wykrywać pętle poprawek i problemy z jakością danych. Częste korekty mogą wskazywać na niejasne wymagania początkowe lub braki w szkoleniu użytkowników, a w konsekwencji prowadzić do opóźnień. Skąd pobrać Dane pochodzą z tabel dziennika zmian CDHDR (nagłówek) i CDPOS (pozycja), w których klasa obiektu to EINKBELEG, a identyfikator obiektu odpowiada numerowi zapotrzebowania zakupowego. Można analizować zmiany konkretnych pól. Rejestrowanie Zdarzenie zapisane w tabelach zmian CDHDR i CDPOS dla dokumentu zapotrzebowania zakupowego. Typ zdarzenia explicit
	Zaakceptowano etap	Oznacza formalną akceptację pojedynczego etapu strategii zwalniania przez uprawnionego użytkownika. Działanie jest zapisywane jako zmiana statusu zwalniania zapotrzebowania i przybliża je do ostatecznej akceptacji.
Dlaczego to ważne Śledzenie poszczególnych akceptacji pozwala mierzyć czas trwania każdego etapu i analizować pracę różnych osób akceptujących. Jest też niezbędne do oceny zgodności z workflow. Skąd pobrać Dane pochodzą z dzienników zmian (CDHDR/CDPOS) dotyczących pól statusu zwalniania w tabeli EBAN. Działanie osoby akceptującej w transakcji ME54N lub podobnym kodzie transakcji powoduje zapis zmiany. Rejestrowanie Wpis w dzienniku zmian utworzony po wykonaniu transakcji zwalniania przez osobę akceptującą. Typ zdarzenia explicit
	Zablokowano zapotrzebowanie	Oznacza formalne zablokowanie pozycji zapotrzebowania zakupowego, które uniemożliwia przekształcenie jej w zamówienie zakupu. Blokadę ustawia się za pomocą odpowiedniego wskaźnika na pozycji zapotrzebowania.
Dlaczego to ważne Blokada może wskazywać na problem lub tymczasowe wstrzymanie zakupów. Śledzenie takich zdarzeń pomaga wykryć wąskie gardła, w których zatwierdzone zapotrzebowania nie są od razu realizowane. Skąd pobrać Dane pochodzą ze zmiany pola „Wskaźnik blokady” (EBAKZ) w tabeli EBAN. Zmiana jest zapisywana w tabelach CDHDR i CDPOS. Rejestrowanie Zdarzenie zapisane w tabelach zmian po ustawieniu pola EBAN-EBAKZ. Typ zdarzenia explicit
	Zamknięto zapotrzebowanie	Oznacza ostateczne zamknięcie pozycji zapotrzebowania, po którym nie oczekuje się dalszej obsługi. Wnioskuje się o nim, gdy pozycja została w pełni przekształcona w zamówienie zakupu i zrealizowana albo ręcznie oznaczona jako zamknięta.
Dlaczego to ważne To jednoznaczny punkt końcowy dla zapotrzebowań, które zostały zrealizowane, ale niekoniecznie usunięte. Pozwala poprawnie obliczyć czas obsługi zakończonych powodzeniem zgłoszeń. Skąd pobrać Wnioskuje się o nim na podstawie wskaźnika „Zamknięte” (EBAKZ o wartości „S” lub innej skonfigurowanej wartości) w tabeli EBAN. System często ustawia ten status automatycznie po pełnym przekształceniu zapotrzebowania w zamówienie zakupu i przyjęciu towarów. Rejestrowanie Wnioskuje się o nim na podstawie zmiany pola EBAN-EBAKZ na wartość oznaczającą zamknięcie. Typ zdarzenia inferred
	Zresetowano akceptację	Oznacza zresetowanie całego workflow akceptacji zapotrzebowania, często z powodu istotnej korekty. Wnioskuje się o nim, gdy aktywny wcześniej status zwalniania zostaje wyczyszczony, co wymusza ponowne rozpoczęcie procesu akceptacji.
Dlaczego to ważne Reset akceptacji oznacza istotne dodatkowe prace i znacznie wydłuża cykl. Wykrycie takich przypadków ujawnia nieefektywności procesu i wpływ korekt zapotrzebowań na dalszy przebieg workflow. Skąd pobrać Wnioskuje się o nim na podstawie dzienników zmian (CDHDR/CDPOS) tabeli EBAN, gdy pola statusu zwalniania, takie jak FRGZU, zmieniają się ze stanu oczekującego lub zatwierdzonego na początkowy albo pusty. Rejestrowanie Wnioskuje się o nim na podstawie dzienników zmian wskazujących na wyczyszczenie pól strategii zwalniania. Typ zdarzenia inferred

Zalecane Opcjonalne

Instrukcje ekstrakcji danych

Jak pobrać dane z SAP ECC

Kroki

Uzyskaj dostęp do bazy danych: Przed rozpoczęciem upewnij się, że masz dostęp do odczytu bazowej bazy danych SAP ECC. Potrzebne będą odpowiednie dane logowania (nazwa użytkownika, hasło, host i port). Taki dostęp nie jest standardowy i wymaga zgody zespołów SAP Basis oraz bezpieczeństwa.
Znajdź schemat SAP: Połącz się z bazą danych za pomocą standardowego klienta SQL, takiego jak DBeaver, Toad lub SQL Developer. Ustal, w którym schemacie SAP znajdują się tabele. Jego nazwa to często SAPSR3 lub SAPR3.
Przygotuj zapytanie SQL: Użyj pełnego zapytania SQL podanego w tym dokumencie. Zapytanie łączy tabele danych podstawowych i dzienników zmian, aby pobrać wymagane działania i atrybuty.
Ustaw parametry zapytania: Znajdź w zapytaniu wartości zastępcze i zastąp je danymi odpowiednimi dla systemu i wymagań biznesowych. Najważniejsze z nich to '{source_system_name}', '{start_date}', '{end_date}', '{company_codes}' i '{document_types}'.
Dostosuj składnię do bazy danych: Zapytanie korzysta ze standardowej składni SQL. Niektóre funkcje, na przykład TO_TIMESTAMP do tworzenia znaczników czasu lub funkcje przetwarzania tekstu, mogą jednak wymagać drobnych zmian zależnie od używanej bazy, takiej jak Oracle, SQL Server, DB2 lub HANA.
Uruchom ekstrakcję: Uruchom dostosowane zapytanie w kliencie SQL. W przypadku dużych zbiorów danych najlepiej zrobić to poza godzinami szczytu, aby nie obciążać systemu.
Sprawdź wstępne wyniki: Po zakończeniu zapytania sprawdź, czy wynik zawiera oczekiwane kolumny (PurchaseRequisitionId, ActivityName, EventTime itd.) oraz wiersze dotyczące różnych działań.
Wyeksportuj dane do CSV: Wyeksportuj cały zestaw wyników z klienta SQL do pliku CSV. Ustaw kodowanie UTF-8, aby uniknąć problemów ze znakami specjalnymi.
Przygotuj plik do przesłania: Sprawdź, czy nagłówki kolumn w pliku CSV dokładnie odpowiadają aliasom zdefiniowanym w zapytaniu SQL. Plik powinien zawierać uporządkowane dane tabelaryczne z dziennika zdarzeń.
Prześlij dane do ProcessMind: Prześlij gotowy plik CSV do projektu ProcessMind, aby rozpocząć analizę i wizualizację.

Konfiguracja

Połączenie z bazą danych: Wymagane jest bezpośrednie połączenie z bazą danych SAP ECC. Potrzebne będą nazwa hosta, port, nazwa bazy danych i odpowiednie dane logowania.
Schemat SAP: Należy znać nazwę schematu zawierającego tabele SAP, na przykład SAPSR3. Zapytanie trzeba uruchomić w kontekście tego schematu.
Zakres dat: Aby kontrolować wydajność i ilość danych, należy ustawić konkretny zakres dat. Na początek zalecamy okres od 3 do 6 miesięcy. Wartości '{start_date}' i '{end_date}' należy podać w formacie YYYYMMDD.
Filtry organizacyjne: Aby zawęzić analizę, filtruj dane według kodu spółki (BUKRS) i typu dokumentu zapotrzebowania (BSART). Zastąp wartości '{company_codes}' i '{document_types}' listami rozdzielonymi przecinkami, na przykład '1000','2000'.
Wymagania wstępne: Uzyskanie bezpośrednich danych logowania do bazy wymaga zgody zespołów SAP Basis i bezpieczeństwa. Nie jest to standardowe zadanie użytkownika końcowego.
Wydajność: Zapytanie łączy tabele dzienników zmian (CDHDR, CDPOS), które mogą zawierać bardzo dużo danych. Bez odpowiednich filtrów może działać wolno i zużywać znaczne zasoby systemowe. Zawsze stosuj ograniczony zakres dat i dodatkowe filtry.

Przykładowe zapytanie sql

WITH REQUISITION_BASE AS (
    SELECT 
        EBAN.MANDT,
        EBAN.BANFN,
        EBAN.BNFPO,
        EBAN.BSART AS RequisitionDocumentType,
        EBAN.ERNAM,
        EBAN.ERDAT,
        EBAN.ERZET,
        EBAN.FRGZU AS CurrentRequisitionStatus,
        EBAKN.KOSTL AS Department,
        EBAKN.GSWRT
    FROM EBAN
    LEFT JOIN EBAKN ON EBAN.MANDT = EBAKN.MANDT AND EBAN.BANFN = EBAKN.BANFN AND EBAN.BNFPO = EBAKN.BNFPO
    WHERE EBAN.ERDAT BETWEEN '{start_date}' AND '{end_date}'
      AND EBAN.BUKRS IN ('{company_codes}')
      AND EBAN.BSART IN ('{document_types}')
),
REQUISITION_AGG AS (
    SELECT 
        MANDT, BANFN, RequisitionDocumentType, ERNAM, ERDAT, ERZET, CurrentRequisitionStatus, Department,
        SUM(GSWRT) AS TotalRequisitionValue
    FROM REQUISITION_BASE
    GROUP BY MANDT, BANFN, RequisitionDocumentType, ERNAM, ERDAT, ERZET, CurrentRequisitionStatus, Department
)
-- 1. Requisition Created
SELECT
    R.BANFN AS PurchaseRequisitionId,
    'Requisition Created' AS ActivityName,
    TO_TIMESTAMP(R.ERDAT || R.ERZET, 'YYYYMMDDHH24MISS') AS EventTime,
    '{source_system_name}' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    R.ERNAM AS User,
    R.Department AS Department,
    R.CurrentRequisitionStatus AS RequisitionStatus,
    R.RequisitionDocumentType AS RequisitionDocumentType,
    R.TotalRequisitionValue AS TotalRequisitionValue
FROM REQUISITION_AGG R

UNION ALL

-- 2. Requisition Amended, Approval Steps, Status Changes from Change Logs
SELECT 
    SUBSTRING(C.OBJECTID, 4, 10) AS PurchaseRequisitionId,
    CASE 
        WHEN C.FNAME = 'FRGZU' AND C.VALUE_NEW > C.VALUE_OLD THEN 'Approval Step Approved'
        WHEN C.FNAME = 'FRGZU' AND C.VALUE_NEW < C.VALUE_OLD THEN 'Approval Step Rejected'
        WHEN C.FNAME = 'FRGZU' AND C.VALUE_NEW = '{final_approval_status_code}' THEN 'Requisition Approved'
        WHEN C.FNAME = 'FRGZU' AND C.VALUE_NEW = '{final_rejection_status_code}' THEN 'Requisition Rejected'
        WHEN C.FNAME = 'FRGSX' AND C.VALUE_OLD IS NOT NULL AND C.VALUE_NEW IS NULL THEN 'Approval Reset'
        WHEN C.FNAME = 'FRGZU' AND C.CHNGIND = 'U' AND C.TCODE LIKE 'ME54%' THEN 'Approval Submitted' 
        WHEN C.FNAME = 'LOEKZ' AND C.VALUE_NEW IN ('L', 'X') THEN 'Requisition Withdrawn'
        WHEN C.FNAME = 'EBAKZ' AND C.VALUE_NEW = 'X' THEN 'Requisition Blocked'
        WHEN C.FNAME = 'STATU' AND C.VALUE_NEW = 'B' THEN 'Purchase Order Created'
        WHEN C.FNAME = 'EREKZ' AND C.VALUE_NEW = 'X' THEN 'Requisition Closed'
        ELSE 'Requisition Amended'
    END AS ActivityName,
    TO_TIMESTAMP(C.UDATE || C.UTIME, 'YYYYMMDDHH24MISS') AS EventTime,
    '{source_system_name}' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    C.USERNAME AS User,
    R.Department AS Department,
    C.VALUE_NEW AS RequisitionStatus,
    R.RequisitionDocumentType AS RequisitionDocumentType,
    R.TotalRequisitionValue AS TotalRequisitionValue
FROM CDHDR C
JOIN CDPOS P ON C.MANDANT = P.MANDANT AND C.OBJECTCLAS = P.OBJECTCLAS AND C.OBJECTID = P.OBJECTID AND C.CHANGENR = P.CHANGENR
JOIN REQUISITION_AGG R ON SUBSTRING(C.OBJECTID, 4, 10) = R.BANFN
WHERE C.OBJECTCLAS = 'BANF'
  AND C.UDATE || C.UTIME <> R.ERDAT || R.ERZET -- Exclude changes made at the exact time of creation
  AND NOT (C.TCODE IN ('ME51', 'ME51N') AND C.UDATE = R.ERDAT) -- Exclude initial creation events from being amendments

UNION ALL

-- 3. Approval Step Started (Inferred)
SELECT 
    SUBSTRING(C.OBJECTID, 4, 10) AS PurchaseRequisitionId,
    'Approval Step Started' AS ActivityName,
    TO_TIMESTAMP(C.UDATE || C.UTIME, 'YYYYMMDDHH24MISS') AS EventTime,
    '{source_system_name}' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    C.USERNAME AS User,
    R.Department AS Department,
    P.VALUE_OLD AS RequisitionStatus,
    R.RequisitionDocumentType AS RequisitionDocumentType,
    R.TotalRequisitionValue AS TotalRequisitionValue
FROM CDHDR C
JOIN CDPOS P ON C.MANDANT = P.MANDANT AND C.OBJECTCLAS = P.OBJECTCLAS AND C.OBJECTID = P.OBJECTID AND C.CHANGENR = P.CHANGENR
JOIN REQUISITION_AGG R ON SUBSTRING(C.OBJECTID, 4, 10) = R.BANFN
WHERE C.OBJECTCLAS = 'BANF' AND P.FNAME = 'FRGZU' AND P.CHNGIND = 'U'
  AND P.VALUE_OLD IS NOT NULL AND P.VALUE_NEW IS NOT NULL AND P.VALUE_NEW > P.VALUE_OLD; -- This logic infers that a step starts just before it is approved

Kroki

Przygotuj środowisko Python: Zainstaluj Python w wersji 3.6 lub nowszej. Utwórz folder projektu i skonfiguruj środowisko wirtualne do zarządzania zależnościami. Zainstaluj potrzebne biblioteki za pomocą pip: pip install pyrfc pandas numpy
Zainstaluj SAP RFC SDK: Pobierz SAP NetWeaver RFC SDK z SAP Support Portal. Rozpakuj pliki i umieść biblioteki, na przykład sapnwrfc.dll w systemie Windows lub libsapnwrfc.so w systemie Linux, w katalogu dostępnym w ścieżce systemowej lub dla skryptu Python.
Skonfiguruj połączenie z SAP: Otwórz udostępniony skrypt Python. Znajdź sekcję parametrów połączenia z SAP i zastąp wartości zastępcze (ashost, sysnr, client, user, passwd) danymi logowania do systemu SAP. Upewnij się, że użytkownik ma wymagane uprawnienia do wywołań RFC i dostępu do tabel.
Ustaw parametry ekstrakcji: W skrypcie ustaw zmienne date_from i date_to, aby określić zakres dat ekstrakcji. Na początek warto wybrać krótszy okres, na przykład jeden miesiąc, i przetestować proces.
Uruchom skrypt Python: Uruchom skrypt w terminalu poleceniem python your_script_name.py. Skrypt połączy się z SAP przez RFC, wywoła funkcję RFC_READ_TABLE dla każdej wymaganej tabeli (EBAN, EKKO, EKPO, CDHDR, CDPOS) i pobierze dane.
Pobierz dane: Skrypt pobiera surowe dane dotyczące zapotrzebowań, zamówień zakupu i dokumentów zmian. Stosuje filtry, takie jak zakres dat i klasy obiektów, aby ograniczyć ilość przesyłanych danych.
Przekształć dane lokalnie: Po pobraniu danych skrypt używa biblioteki pandas do wykonania wszystkich przekształceń lokalnie. Przetwarza surowe dane z tabel, aby utworzyć osobne wpisy dziennika zdarzeń dla każdego z 13 wymaganych działań, takich jak „Utworzono zapotrzebowanie”, „Zaakceptowano na etapie” i „Utworzono zamówienie zakupu”.
Utwórz dziennik zdarzeń: Skrypt łączy zdarzenia z poszczególnych tabel w jedną ramkę danych DataFrame. Oblicza znaczniki czasu zdarzeń, przypisuje nazwy użytkowników i porządkuje dane według wymaganego formatu identyfikatora case, działania i znacznika czasu.
Przypisz atrybuty: Ważne atrybuty, takie jak PurchaseRequisitionId, ActivityName, EventTime, User i TotalRequisitionValue, są przypisywane do odpowiednich kolumn w końcowej ramce DataFrame.
Wyeksportuj dane do CSV: Skrypt zapisuje końcowy dziennik zdarzeń w pliku CSV event_log_pr.csv w tym samym katalogu. Plik jest przygotowany do bezpośredniego przesłania do ProcessMind.
Sprawdź i prześlij dane: Otwórz wygenerowany plik CSV i sprawdź kompletność oraz poprawność danych. Po weryfikacji można przesłać plik do projektu ProcessMind.

Konfiguracja

Połączenie z SAP: Skrypt wymaga danych do bezpośredniego połączenia RFC z systemem SAP ECC, w tym serwera aplikacji, numeru systemu, klienta, nazwy użytkownika i hasła. Użytkownik musi mieć uprawnienia do wywołań RFC oraz dostęp do odczytu tabel EBAN, EKPO, EKKO, CDHDR i CDPOS.
Zakres dat: Ekstrakcja korzysta z parametrów daty początkowej i końcowej ustawionych w skrypcie. Przy pierwszym uruchomieniu, aby ograniczyć obciążenie, zaleca się pobranie danych z okresu od 3 do 6 miesięcy.
Filtry tabel: W miarę możliwości filtry są stosowane w wywołaniach RFC. Na przykład zapotrzebowania są filtrowane według daty utworzenia (EBAN-ERDAT), a dokumenty zmian według daty (CDHDR-UDATE) i klasy obiektu (CDHDR-OBJECTCLAS = 'BANF').
Biblioteki Python: Skrypt korzysta z pyrfc do łączenia z SAP i z pandas do przetwarzania danych. Upewnij się, że biblioteki są zainstalowane w środowisku Python.
Wydajność: Ekstrakcja dużych zbiorów danych za pomocą RFC_READ_TABLE może trwać długo, ponieważ dane są pobierane kolejno, tabela po tabeli. Aby ograniczyć obciążenie systemu, warto uruchamiać ekstrakcję poza godzinami szczytu.
Typy dokumentów: Domyślnie skrypt pobiera wszystkie typy dokumentów zapotrzebowania. Aby zawęzić zakres, można po ekstrakcji dodać filtr w ramce DataFrame pandas, korzystając z kolumny BSART z tabeli EBAN.

Przykładowe zapytanie python

import pandas as pd
from pyrfc import Connection
import datetime

class=class="hl-string">"hl-comment"># --- 1. Configuration Settings ---
class=class="hl-string">"hl-comment"># Replace with your SAP system connection details
SAP_CONNECTION_PARAMS = {
    class="hl-string">"ashost": class="hl-string">"your_sap_host",      class=class="hl-string">"hl-comment"># Application server host
    class="hl-string">"sysnr": class="hl-string">"00",                 class=class="hl-string">"hl-comment"># System number
    class="hl-string">"client": class="hl-string">"100",               class=class="hl-string">"hl-comment"># Client
    class="hl-string">"user": class="hl-string">"your_rfc_user",       class=class="hl-string">"hl-comment"># RFC user
    class="hl-string">"passwd": class="hl-string">"your_password"      class=class="hl-string">"hl-comment"># Password
}

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYYMMDD format)
date_from = class="hl-string">'20230101'
date_to = class="hl-string">'20231231'

source_system = class="hl-string">"SAP ECC"
last_data_update = datetime.datetime.now().isoformat()

class=class="hl-string">"hl-comment"># --- 2. Helper function for RFC_READ_TABLE ---
def rfc_read_table(conn, table_name, fields, options):
    class="hl-string">"""Fetches data from an SAP table using RFC_READ_TABLE."""
    try:
        result = conn.call(class="hl-string">'RFC_READ_TABLE',
                           QUERY_TABLE=table_name,
                           DELIMITER=class="hl-string">',',
                           FIELDS=fields,
                           OPTIONS=options)
        
        data = result[class="hl-string">'DATA']
        if not data:
            return pd.DataFrame(columns=[field[class="hl-string">'FIELDNAME'] for field in fields])

        records = [row[class="hl-string">'WA'].strip().split(class="hl-string">',') for row in data]
        df = pd.DataFrame(records, columns=[field[class="hl-string">'FIELDNAME'] for field in fields])
        class=class="hl-string">"hl-comment"># Trim whitespace from all cells
        df = df.apply(lambda x: x.str.strip() if x.dtype == class="hl-string">"object" else x)
        return df
    except Exception as e:
        print(fclass="hl-string">"Error reading table {table_name}: {e}")
        return pd.DataFrame(columns=[field[class="hl-string">'FIELDNAME'] for field in fields])

class=class="hl-string">"hl-comment"># --- 3. Main Extraction Logic ---
def main():
    print(class="hl-string">"Starting SAP data extraction...")
    try:
        conn = Connection(**SAP_CONNECTION_PARAMS)
    except Exception as e:
        print(fclass="hl-string">"Failed to connect to SAP: {e}")
        return

    class=class="hl-string">"hl-comment"># --- EBAN (Purchase Requisitions) ---
    print(class="hl-string">"Extracting EBAN...")
    eban_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'BANFN'}, {class="hl-string">'FIELDNAME': class="hl-string">'BNFPO'}, {class="hl-string">'FIELDNAME': class="hl-string">'BSART'}, {class="hl-string">'FIELDNAME': class="hl-string">'ERNAM'}, {class="hl-string">'FIELDNAME': class="hl-string">'ERDAT'}, {class="hl-string">'FIELDNAME': class="hl-string">'ERFZEIT'}, {class="hl-string">'FIELDNAME': class="hl-string">'PREIS'}, {class="hl-string">'FIELDNAME': class="hl-string">'MENGE'}, {class="hl-string">'FIELDNAME': class="hl-string">'KOSTL'}, {class="hl-string">'FIELDNAME': class="hl-string">'FRGZU'}, {class="hl-string">'FIELDNAME': class="hl-string">'FRGSX'}]
    eban_options = [fclass="hl-string">"ERDAT >= '{date_from}' AND ERDAT <= '{date_to}'"]
    df_eban = rfc_read_table(conn, class="hl-string">'EBAN', eban_fields, eban_options)
    if df_eban.empty:
        print(class="hl-string">"No requisitions found in EBAN for the given date range. Exiting.")
        conn.close()
        return

    df_eban[class="hl-string">'PREIS'] = pd.to_numeric(df_eban[class="hl-string">'PREIS'], errors=class="hl-string">'coerce').fillna(0)
    df_eban[class="hl-string">'MENGE'] = pd.to_numeric(df_eban[class="hl-string">'MENGE'], errors=class="hl-string">'coerce').fillna(0)
    df_eban[class="hl-string">'TotalRequisitionValue'] = df_eban[class="hl-string">'PREIS'] * df_eban[class="hl-string">'MENGE']
    df_eban_grouped = df_eban.groupby(class="hl-string">'BANFN').agg(
        TotalRequisitionValue=(class="hl-string">'TotalRequisitionValue', class="hl-string">'sum'),
        RequisitionDocumentType=(class="hl-string">'BSART', class="hl-string">'first'),
        Department=(class="hl-string">'KOSTL', class="hl-string">'first')
    ).reset_index()
    df_eban = df_eban.merge(df_eban_grouped, on=class="hl-string">'BANFN', suffixes=(class="hl-string">'', class="hl-string">'_agg'))

    class=class="hl-string">"hl-comment"># --- EKPO/EKKO (Purchase Orders) ---
    print(class="hl-string">"Extracting EKPO and EKKO...")
    banfn_list = class="hl-string">"'" + class="hl-string">"', '".join(df_eban[class="hl-string">'BANFN'].unique()) + class="hl-string">"'"
    ekpo_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'BANFN'}, {class="hl-string">'FIELDNAME': class="hl-string">'BNFPO'}, {class="hl-string">'FIELDNAME': class="hl-string">'EBELN'}]
    ekpo_options = [fclass="hl-string">"BANFN IN ({banfn_list})"]
    df_ekpo = rfc_read_table(conn, class="hl-string">'EKPO', ekpo_fields, ekpo_options)

    ekko_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'EBELN'}, {class="hl-string">'FIELDNAME': class="hl-string">'AEDAT'}]
    if not df_ekpo.empty:
        ebeln_list = class="hl-string">"'" + class="hl-string">"', '".join(df_ekpo[class="hl-string">'EBELN'].unique()) + class="hl-string">"'"
        ekko_options = [fclass="hl-string">"EBELN IN ({ebeln_list})"]
        df_ekko = rfc_read_table(conn, class="hl-string">'EKKO', ekko_fields, ekko_options)
        df_po = pd.merge(df_ekpo, df_ekko, on=class="hl-string">'EBELN')
    else:
        df_po = pd.DataFrame(columns=[class="hl-string">'BANFN', class="hl-string">'BNFPO', class="hl-string">'EBELN', class="hl-string">'AEDAT'])

    class=class="hl-string">"hl-comment"># --- CDHDR/CDPOS (Change Documents) ---
    print(class="hl-string">"Extracting CDHDR and CDPOS...")
    cdhdr_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'OBJECTID'}, {class="hl-string">'FIELDNAME': class="hl-string">'CHANGENR'}, {class="hl-string">'FIELDNAME': class="hl-string">'USERNAME'}, {class="hl-string">'FIELDNAME': class="hl-string">'UDATE'}, {class="hl-string">'FIELDNAME': class="hl-string">'UTIME'}]
    cdhdr_options = [fclass="hl-string">"OBJECTCLAS = 'BANF' AND UDATE >= '{date_from}' AND UDATE <= '{date_to}'"]
    df_cdhdr = rfc_read_table(conn, class="hl-string">'CDHDR', cdhdr_fields, cdhdr_options)
    
    df_cdpos = pd.DataFrame()
    if not df_cdhdr.empty:
        class=class="hl-string">"hl-comment"># Process changenr in chunks to avoid overly long SQL queries
        changenr_chunks = [df_cdhdr[class="hl-string">'CHANGENR'][i:i + 100] for i in range(0, df_cdhdr.shape[0], 100)]
        cdpos_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'CHANGENR'}, {class="hl-string">'FIELDNAME': class="hl-string">'TABNAME'}, {class="hl-string">'FIELDNAME': class="hl-string">'FNAME'}, {class="hl-string">'FIELDNAME': class="hl-string">'VALUE_NEW'}, {class="hl-string">'FIELDNAME': class="hl-string">'VALUE_OLD'}]
        cdpos_frames = []
        for chunk in changenr_chunks:
            changenr_list = class="hl-string">"'" + class="hl-string">"', '".join(chunk) + class="hl-string">"'"
            cdpos_options = [fclass="hl-string">"OBJECTCLAS = 'BANF' AND CHANGENR IN ({changenr_list}) AND TABNAME = 'EBAN'"]
            cdpos_frames.append(rfc_read_table(conn, class="hl-string">'CDPOS', cdpos_fields, cdpos_options))
        if cdpos_frames:
            df_cdpos = pd.concat(cdpos_frames, ignore_index=True)

    conn.close()
    print(class="hl-string">"Extraction from SAP complete. Starting transformation...")

    class=class="hl-string">"hl-comment"># --- 4. Event Log Generation ---
    events = []

    class=class="hl-string">"hl-comment"># Activity: Requisition Created
    df_created = df_eban[[class="hl-string">'BANFN', class="hl-string">'ERNAM', class="hl-string">'ERDAT', class="hl-string">'ERFZEIT', class="hl-string">'RequisitionDocumentType', class="hl-string">'TotalRequisitionValue', class="hl-string">'Department']].drop_duplicates(subset=[class="hl-string">'BANFN'])
    for _, row in df_created.iterrows():
        events.append({
            class="hl-string">'PurchaseRequisitionId': row[class="hl-string">'BANFN'],
            class="hl-string">'ActivityName': class="hl-string">'Requisition Created',
            class="hl-string">'EventTime': fclass="hl-string">"{row['ERDAT']} {row['ERFZEIT']}",
            class="hl-string">'User': row[class="hl-string">'ERNAM'],
            class="hl-string">'RequisitionDocumentType': row[class="hl-string">'RequisitionDocumentType'],
            class="hl-string">'TotalRequisitionValue': row[class="hl-string">'TotalRequisitionValue'],
            class="hl-string">'Department': row[class="hl-string">'Department'],
            class="hl-string">'RequisitionStatus': class="hl-string">'Created'
        })

    class=class="hl-string">"hl-comment"># Merge change documents
    df_changes = pd.DataFrame()
    if not df_cdhdr.empty and not df_cdpos.empty:
        df_changes = pd.merge(df_cdhdr, df_cdpos, on=class="hl-string">'CHANGENR')
        df_changes[class="hl-string">'PurchaseRequisitionId'] = df_changes[class="hl-string">'OBJECTID'].str[:10]
        df_changes[class="hl-string">'EventTime'] = pd.to_datetime(df_changes[class="hl-string">'UDATE'] + class="hl-string">' ' + df_changes[class="hl-string">'UTIME'], format=class="hl-string">'%Y%m%d %H%M%S')

    if not df_changes.empty:
        class=class="hl-string">"hl-comment"># Activities from Change Logs
        for _, row in df_changes.iterrows():
            activity = None
            status = None

            class=class="hl-string">"hl-comment"># Approval-related activities
            if row[class="hl-string">'FNAME'] in [class="hl-string">'FRGZU', class="hl-string">'FRGSX']:
                if row[class="hl-string">'VALUE_OLD'].strip() == class="hl-string">'' and row[class="hl-string">'VALUE_NEW'].strip() != class="hl-string">'':
                    activity = class="hl-string">'Approval Submitted'
                    status = class="hl-string">'In Approval'
                elif row[class="hl-string">'VALUE_OLD'] != class="hl-string">'' and row[class="hl-string">'VALUE_NEW'] == class="hl-string">'':
                    activity = class="hl-string">'Approval Reset'
                    status = class="hl-string">'In Progress'
                else:
                    class=class="hl-string">"hl-comment"># Logic to differentiate approve/reject might need config specifics
                    activity = class="hl-string">'Approval Step Approved' if row[class="hl-string">'VALUE_NEW'] > row[class="hl-string">'VALUE_OLD'] else class="hl-string">'Approval Step Rejected'
                    status = class="hl-string">'In Approval'
            class=class="hl-string">"hl-comment"># Final Approval/Rejection
            elif row[class="hl-string">'FNAME'] == class="hl-string">'FRGZU':
                 class=class="hl-string">"hl-comment"># This logic assumes specific final approval/rejection codes. Adjust if needed.
                 if row[class="hl-string">'VALUE_NEW'] in [class="hl-string">'X', class="hl-string">'Y', class="hl-string">'Z']: class=class="hl-string">"hl-comment"># Placeholder for final approval states
                     activity = class="hl-string">'Requisition Approved'
                     status = class="hl-string">'Approved'
                 elif row[class="hl-string">'VALUE_NEW'] in [class="hl-string">'R', class="hl-string">'S']: class=class="hl-string">"hl-comment"># Placeholder for final rejection states
                     activity = class="hl-string">'Requisition Rejected'
                     status = class="hl-string">'Rejected'
            class=class="hl-string">"hl-comment"># Other Amendments
            elif row[class="hl-string">'FNAME'] not in [class="hl-string">'FRGZU', class="hl-string">'FRGSX', class="hl-string">'LOEKZ', class="hl-string">'EBAKZ']:
                activity = class="hl-string">'Requisition Amended'
                status = class="hl-string">'Amended'
            class=class="hl-string">"hl-comment"># Blocked
            elif row[class="hl-string">'FNAME'] == class="hl-string">'EBAKZ' and row[class="hl-string">'VALUE_NEW'] == class="hl-string">'B':
                activity = class="hl-string">'Requisition Blocked'
                status = class="hl-string">'Blocked'
            class=class="hl-string">"hl-comment"># Withdrawn
            elif row[class="hl-string">'FNAME'] == class="hl-string">'LOEKZ' and row[class="hl-string">'VALUE_NEW'] == class="hl-string">'L':
                activity = class="hl-string">'Requisition Withdrawn'
                status = class="hl-string">'Withdrawn'
            class=class="hl-string">"hl-comment"># Closed
            elif row[class="hl-string">'FNAME'] == class="hl-string">'EBAKZ' and row[class="hl-string">'VALUE_NEW'] == class="hl-string">'L':
                activity = class="hl-string">'Requisition Closed'
                status = class="hl-string">'Closed'

            if activity:
                events.append({
                    class="hl-string">'PurchaseRequisitionId': row[class="hl-string">'PurchaseRequisitionId'],
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': row[class="hl-string">'EventTime'].strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
                    class="hl-string">'User': row[class="hl-string">'USERNAME'],
                    class="hl-string">'RequisitionStatus': status
                })

    class=class="hl-string">"hl-comment"># Activity: Purchase Order Created
    if not df_po.empty:
        df_po_first = df_po.sort_values(class="hl-string">'AEDAT').drop_duplicates(class="hl-string">'BANFN', keep=class="hl-string">'first')
        for _, row in df_po_first.iterrows():
            events.append({
                class="hl-string">'PurchaseRequisitionId': row[class="hl-string">'BANFN'],
                class="hl-string">'ActivityName': class="hl-string">'Purchase Order Created',
                class="hl-string">'EventTime': fclass="hl-string">"{row['AEDAT']} 00:00:00", class=class="hl-string">"hl-comment"># EKKO only has date
                class="hl-string">'User': None, class=class="hl-string">"hl-comment"># User info not directly in EKKO/EKPO for this event
                class="hl-string">'RequisitionStatus': class="hl-string">'PO Created'
            })
            
    class=class="hl-string">"hl-comment"># Dummy activities for Approval Step Started (inferred before approval)
    class=class="hl-string">"hl-comment"># This is a simplified inference. Real logic can be much more complex.
    approval_events = [e for e in events if e[class="hl-string">'ActivityName'] == class="hl-string">'Approval Step Approved']
    for event in approval_events:
        event_time = pd.to_datetime(event[class="hl-string">'EventTime'])
        class=class="hl-string">"hl-comment"># Infer class="hl-string">'started' event one minute before class="hl-string">'approved' for demonstration
        start_time = event_time - datetime.timedelta(minutes=1)
        events.append({
            class="hl-string">'PurchaseRequisitionId': event[class="hl-string">'PurchaseRequisitionId'],
            class="hl-string">'ActivityName': class="hl-string">'Approval Step Started',
            class="hl-string">'EventTime': start_time.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
            class="hl-string">'User': None, class=class="hl-string">"hl-comment"># Approver user is not known until they approve
            class="hl-string">'RequisitionStatus': class="hl-string">'In Approval'
        })

    class=class="hl-string">"hl-comment"># --- 5. Final Formatting ---
    if not events:
        print(class="hl-string">"No events generated. Exiting.")
        return

    df_event_log = pd.DataFrame(events)
    df_event_log = df_event_log.merge(df_eban_grouped, left_on=class="hl-string">'PurchaseRequisitionId', right_on=class="hl-string">'BANFN', how=class="hl-string">'left')
    df_event_log[class="hl-string">'EventTime'] = pd.to_datetime(df_event_log[class="hl-string">'EventTime'])
    df_event_log = df_event_log.sort_values(by=[class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventTime'])

    class=class="hl-string">"hl-comment"># Fill forward attributes within each case
    df_event_log[class="hl-string">'RequisitionDocumentType'] = df_event_log.groupby(class="hl-string">'PurchaseRequisitionId')[class="hl-string">'RequisitionDocumentType_agg'].transform(lambda x: x.ffill().bfill())
    df_event_log[class="hl-string">'TotalRequisitionValue'] = df_event_log.groupby(class="hl-string">'PurchaseRequisitionId')[class="hl-string">'TotalRequisitionValue_agg'].transform(lambda x: x.ffill().bfill())
    df_event_log[class="hl-string">'Department'] = df_event_log.groupby(class="hl-string">'PurchaseRequisitionId')[class="hl-string">'Department_agg'].transform(lambda x: x.ffill().bfill())

    class=class="hl-string">"hl-comment"># Add standard columns
    df_event_log[class="hl-string">'SourceSystem'] = source_system
    df_event_log[class="hl-string">'LastDataUpdate'] = last_data_update

    class=class="hl-string">"hl-comment"># Select and rename final columns
    final_columns = {
        class="hl-string">'PurchaseRequisitionId': class="hl-string">'PurchaseRequisitionId',
        class="hl-string">'ActivityName': class="hl-string">'ActivityName',
        class="hl-string">'EventTime': class="hl-string">'EventTime',
        class="hl-string">'SourceSystem': class="hl-string">'SourceSystem',
        class="hl-string">'LastDataUpdate': class="hl-string">'LastDataUpdate',
        class="hl-string">'User': class="hl-string">'User',
        class="hl-string">'Department': class="hl-string">'Department',
        class="hl-string">'RequisitionStatus': class="hl-string">'RequisitionStatus',
        class="hl-string">'RequisitionDocumentType': class="hl-string">'RequisitionDocumentType',
        class="hl-string">'TotalRequisitionValue': class="hl-string">'TotalRequisitionValue'
    }
    df_event_log = df_event_log[final_columns.keys()].rename(columns=final_columns)
    
    class=class="hl-string">"hl-comment"># Save to CSV
    df_event_log.to_csv(class="hl-string">'event_log_pr.csv', index=False)
    print(class="hl-string">"Event log successfully created: event_log_pr.csv")

if __name__ == class="hl-string">'__main__':
    main()

Gotowi do rozpoczęcia?

Skorzystaj z tego szablonu, aby odpowiednio przygotować dane do process mining i uzyskać wgląd w proces zapotrzebowania od zakupu do płatności. Zacznij optymalizować proces już dziś.

Wróć do przewodnika ulepszania procesów

Pobierz szablon

Usprawnij proces zapotrzebowania P2P. Rozpocznij okres próbny

Wskaż i usuń przyczyny wąskich gardeł w P2P, skracając czas cyklu o 30% lub więcej.

Rozpocznij okres próbny

Bez karty kredytowej. Bezpłatny dostęp przez 14 dni.

Szablon danych procesu zapotrzebowania od zakupu do płatności

Szablon danych procesu zapotrzebowania od zakupu do płatności

Atrybuty procesu zapotrzebowania od zakupu do płatności

Działania w procesie zapotrzebowania od zakupu do płatności

Instrukcje ekstrakcji danych

Bezpośrednie zapytanie SQL do bazowej bazy danych SAP ECC

Kroki

Konfiguracja

Przykładowe zapytanie sql

Skrypt Python wykorzystujący SAP RFC do ekstrakcji danych z tabel

Kroki

Konfiguracja

Przykładowe zapytanie python

Gotowi do rozpoczęcia?

Usprawnij proces zapotrzebowania P2P. Rozpocznij okres próbny