Szablon danych dla procesu od zakupu do płatności, zamówienia zakupu
Szablon danych dla procesu od zakupu do płatności, zamówienia zakupu
- Zalecane atrybuty do szczegółowej analizy
- Działania do śledzenia w procesie
- Instrukcja ekstrakcji danych krok po kroku
Atrybuty procesu od zakupu do płatności, zamówienia zakupu
| Nazwa | Opis | ||
|---|---|---|---|
| Czas zdarzenia EventTime | Timestamp wskazujący, kiedy wystąpiła czynność. | ||
| Opis Ten atrybut zapisuje dokładną datę i godzinę każdej czynności w procesie. Jest podstawą wszystkich analiz czasowych w process mining. Czas zdarzenia służy do chronologicznego uporządkowania czynności i odtworzenia przebiegu procesu. Na jego podstawie oblicza się też wszystkie miary czasu, takie jak czas realizacji między czynnościami, czas oczekiwania i czas przetwarzania. Są one niezbędne do analizy wyników i wykrywania wąskich gardeł. Dlaczego to ważne Ten timestamp pozwala prawidłowo uporządkować zdarzenia i obliczyć wszystkie miary wyników, w tym czas realizacji, czas dostawy i czas oczekiwania. Skąd pobrać Pola timestamp powiązane z konkretnymi czynnościami, takie jak data utworzenia (EKKO-AEDAT dla zmian) lub data księgowania (MKPF-BUDAT dla przyjęć towarów). Często wymagają połączenia danych z kilku tabel. Przykłady 2023-04-15T10:00:00Z2023-04-15T14:30:00Z2023-05-01T09:15:00Z | |||
| Czynność ActivityName | Nazwa zdarzenia biznesowego lub etapu, który wystąpił w procesie zamówienia zakupu. | ||
| Opis Ten atrybut opisuje konkretne działanie lub zmianę statusu w cyklu życia zamówienia zakupu, na przykład „Utworzenie zamówienia zakupu”, „Akceptacja zamówienia zakupu” lub „Zaksięgowanie przyjęcia towaru”. Kolejność tych czynności tworzy przebieg procesu. Analiza kolejności i częstotliwości czynności stanowi podstawę process mining. Pomaga odkryć rzeczywisty przebieg procesu, porównać go z zaprojektowanym modelem, wykrywać wąskie gardła, na przykład długie oczekiwanie po „Otrzymaniu faktury”, oraz mierzyć dodatkową pracę, na przykład powtarzające się czynności „Zmiana zamówienia zakupu”. Dlaczego to ważne Określa etapy procesu, umożliwiając wizualizację i analizę przebiegu od początku do końca, wariantów oraz wąskich gardeł. Skąd pobrać Zwykle jest wyznaczany na podstawie kombinacji tabel i pól, takich jak pola statusu w EKKO/EKPO lub dzienniki dokumentów zmian w CDHDR/CDPOS, aby odzwierciedlić ważne etapy biznesowe. Przykłady Utworzenie zamówienia zakupuAkceptacja zamówienia zakupuZaksięgowanie przyjęcia towaruOtrzymanie faktury | |||
| Zamówienie zakupu PurchaseOrderNumber | Unikalny identyfikator zamówienia zakupu (PO), pełniący funkcję głównego identyfikatora case do śledzenia cyklu zakupowego. | ||
| Opis Numer Purchase Order to główny identyfikator łączący wszystkie powiązane czynności, od utworzenia zamówienia po przyjęcie towaru i zamknięcie. W analizie process mining pełni funkcję identyfikatora case. Grupowanie zdarzeń według tego numeru pozwala odtworzyć przebieg każdego PO. Jest to niezbędne do obliczania czasu realizacji, analizowania wariantów procesu oraz wykrywania wąskich gardeł i odchyleń dotyczących konkretnego zamówienia. Dlaczego to ważne To niezbędny identyfikator, który łączy wszystkie zdarzenia zakupowe w jeden proces od początku do końca i umożliwia szczegółową analizę cyklu życia każdego zamówienia zakupu. Skąd pobrać Atrybut znajduje się w tabeli EKKO systemu SAP S/4HANA, w polu EBELN. Przykłady 450001712345000171244500017125 | |||
| Data ostatniej aktualizacji danych LastDataUpdate | Timestamp ostatniego odświeżenia danych lub ich pobrania z systemu źródłowego. | ||
| Opis Ten atrybut informuje, jak aktualne są analizowane dane. Pokazuje datę i godzinę ostatniego pobrania danych z SAP S/4HANA. Informacja o czasie ostatniej aktualizacji jest niezbędna do oceny aktualności analizy. Pozwala prawidłowo interpretować wyniki i ustalić, czy dotyczą danych bieżących, czy migawki z określonego momentu. Ma to wpływ na trafność działań podejmowanych na podstawie analizy. Dlaczego to ważne Informuje o aktualności danych, dzięki czemu można ocenić kontekst i przydatność wniosków z analizy. Skąd pobrać To timestamp metadanych dodawany podczas ekstrakcji, transformacji i ładowania danych (ETL). Przykłady 2024-05-21T02:00:00Z2024-05-20T02:00:00Z2024-05-19T02:00:00Z | |||
| System źródłowy SourceSystem | Wskazuje system źródłowy, z którego pobrano dane. | ||
| Opis Ten atrybut określa system, z którego pochodzą dane o zdarzeniach, na przykład „SAP S/4HANA Production” lub „SAP ECC”. W środowiskach korzystających z wielu systemów pole to ma zasadnicze znaczenie dla śledzenia pochodzenia danych, rozwiązywania problemów i prawidłowej interpretacji danych z różnych źródeł. Pomaga zrozumieć ich kontekst i filtrować analizę według konkretnego środowiska systemowego. Dlaczego to ważne Dostarcza informacji o pochodzeniu danych, niezbędnych do zarządzania nimi, ich weryfikacji i analizy w środowiskach wielosystemowych. Skąd pobrać Zwykle jest to stała wartość dodawana podczas ekstrakcji, transformacji i ładowania danych (ETL), która oznacza źródło zbioru danych. Przykłady S4H_PROD_100ECC_EU_200S4H_US_300 | |||
| Identyfikator dostawcy VendorId | Unikalny identyfikator dostawcy towarów lub usług. | ||
| Opis Identyfikator dostawcy to ważna dana podstawowa, która łączy zamówienie zakupu z konkretnym dostawcą. Jest wykorzystywany w całym procesie zakupowym do komunikacji, dostaw i płatności. W process mining ten atrybut pozwala analizować wyniki według dostawcy. Jest niezbędny w dashboardach takich jak „Czas realizacji dostawcy” i „Wskaźnik zwrotów towarów według dostawcy”. Pomaga wskazać rzetelnych dostawców oraz tych, którzy mogą powodować opóźnienia lub problemy z jakością. Dlaczego to ważne Umożliwia analizę wyników poszczególnych dostawców, wskazanie tych osiągających lepsze i gorsze wyniki oraz usprawnienie łańcucha dostaw. Skąd pobrać Atrybut znajduje się w tabeli EKKO systemu SAP S/4HANA, w polu LIFNR. Przykłady 100023100045100088 | |||
| Łączna wartość netto TotalNetAmount | Łączna wartość zamówienia zakupu bez podatków i kosztów transportu. | ||
| Opis Ten atrybut określa wartość netto zamówienia zakupu. Jest to ważna kwota finansowa, która pokazuje skalę transakcji zakupowej. Kwota ta ma znaczenie w analizie finansowej, na przykład przy podziale PO według wartości, aby sprawdzić, czy zamówienia o wysokiej i niskiej wartości przebiegają inaczej. Można jej też użyć do ustalenia priorytetów analizy i skupić się na zamówieniach o wysokiej wartości, które mogą wiązać się z większym ryzykiem finansowym lub mieć większy wpływ na działalność. Dlaczego to ważne Umożliwia analizę finansową, podział zamówień zakupu według wartości i nadanie priorytetu usprawnieniom w obszarach o największych wydatkach. Skąd pobrać Atrybut znajduje się w tabeli EKKO systemu SAP S/4HANA, w polu NETWR. Przykłady 1500.0025000.50125.75 | |||
| Typ dokumentu PO DocumentType | Klasyfikacja rozróżniająca typy zamówień zakupu, takie jak standardowe PO, PO na usługi lub zamówienia transportu zapasów. | ||
| Opis Typ dokumentu to ważny element konfiguracji SAP, który określa przebieg procesu, zakres numeracji i pola zamówienia zakupu. Pozwala dostosować proces zakupowy do różnych sytuacji. Analiza procesu według typu dokumentu pomaga zrozumieć różnice w jego przebiegu. Proces dla standardowego zamówienia towarów może znacznie różnić się od procesu dla usług lub transferu zapasów. Ten atrybut pozwala filtrować i porównywać poszczególne przebiegi, aby znaleźć konkretne możliwości usprawnień. Dlaczego to ważne Klasyfikuje zamówienia zakupu, umożliwia porównywanie procesów zakupowych i pomaga wyjaśnić różnice w przebiegu oraz czasie realizacji. Skąd pobrać Atrybut znajduje się w tabeli EKKO systemu SAP S/4HANA, w polu BSART. Przykłady NBFOUB | |||
| Użytkownik UserName | Identyfikator użytkownika, który wykonał daną czynność. | ||
| Opis Ten atrybut zapisuje identyfikator użytkownika SAP odpowiedzialnego za utworzenie, zmianę lub akceptację dokumentu. Pozwala ustalić, kto wykonał daną czynność w systemie. Analiza według użytkownika pomaga określić potrzeby szkoleniowe, rozkład obciążenia pracą i wyniki poszczególnych osób. Można na przykład sprawdzić, czy konkretni użytkownicy regularnie uczestniczą w długich procesach akceptacji lub częstych zmianach po akceptacji. Wnioski te pomagają zarządzać zasobami i usprawniać proces. Dlaczego to ważne Pozwala ustalić odpowiedzialność i analizować wyniki na poziomie osoby lub zespołu, a także wykrywać potrzeby szkoleniowe i ograniczenia zasobów. Skąd pobrać Informacje te znajdują się w polach takich jak ERNAM (utworzył) w EKKO lub w polu użytkownika w tabelach dokumentów zmian (CDHDR-USERNAME). Przykłady CB9980000012JSMITHRROE | |||
| Żądany termin dostawy RequestedDeliveryDate | Data, w której firma oczekuje dostawy towarów lub usług od dostawcy. | ||
| Opis Ten atrybut określa docelowy termin dostawy uzgodniony w zamówieniu zakupu. Stanowi punkt odniesienia przy ocenie terminowości dostawcy. W process mining datę tę porównuje się z datą rzeczywistego przyjęcia towaru (timestampem zdarzenia „Zaksięgowanie przyjęcia towaru”), aby obliczyć KPI „Wskaźnik terminowych dostaw dostawcy”. Analiza odchyleń pomaga ocenić rzetelność dostawcy i zarządzać ryzykiem w łańcuchu dostaw. Dlaczego to ważne Stanowi punkt odniesienia przy pomiarze terminowości dostaw dostawcy, czyli ważnego KPI w zarządzaniu łańcuchem dostaw i planowaniu operacyjnym. Skąd pobrać Dane znajdują się w tabeli harmonogramu EKET, w polu EINDT. Przykłady 2023-06-012023-06-152023-07-01 | |||
| Zap zapotrzebowanie zakupu PurchaseRequisitionNumber | Identyfikator zapotrzebowania zakupowego (PR), na podstawie którego utworzono zamówienie zakupu. | ||
| Opis Ten atrybut łączy zamówienie zakupu z zapotrzebowaniem, od którego rozpoczął się proces. Nie każde PO ma powiązane PR, ponieważ zamówienia mogą być tworzone bezpośrednio. To powiązanie jest niezbędne do analizy całego procesu zakupowego od pierwotnego zgłoszenia. Umożliwia obliczanie KPI, takich jak „Czas akceptacji zapotrzebowania zakupowego”, i pomaga wykrywać zakupy poza zatwierdzonymi kanałami, czyli PO utworzone bez wcześniejszego, zaakceptowanego zapotrzebowania. Dlaczego to ważne Łączy PO z pierwotnym zapotrzebowaniem, umożliwiając analizę procesu od początku do końca oraz wykrywanie zakupów poza zatwierdzonymi kanałami. Skąd pobrać Atrybut znajduje się w tabeli EKPO systemu SAP S/4HANA (poziom pozycji PO), w polu BANFN. Przykłady 1001005110010052 | |||
| Czy wystąpiła poprawka IsRework | Obliczana flaga wskazująca, czy zamówienie zakupu wymagało poprawek, na przykład zmiany po zatwierdzeniu lub zwrotu towaru. | ||
| Opis Ten atrybut logiczny jest obliczany na podstawie sekwencji działań dla każdego zamówienia zakupu. Przyjmuje wartość „true”, jeśli po zdarzeniu „Zatwierdzono zamówienie zakupu” wystąpi zdarzenie „Zmieniono zamówienie zakupu” lub jeśli wystąpi zdarzenie „Zwrócono towar”. Flaga ułatwia obliczanie KPI „Wskaźnik przetwarzania bezpośredniego”. Pozwala szybko filtrować i wizualizować zamówienia zakupu wymagające ręcznej interwencji lub korekty, a także określić częstotliwość i koszt poprawek. Dlaczego to ważne Pomaga określić skalę nieefektywności procesu, wskazując przypadki wymagające poprawek. Jest to istotne przy obliczaniu wskaźnika przetwarzania bezpośredniego i ustalaniu przyczyn odstępstw. Skąd pobrać Pole obliczane na podstawie sekwencji działań. Logika sprawdza, czy po zatwierdzeniu wystąpiło zdarzenie „Zmieniono zamówienie zakupu” lub czy wystąpiło zdarzenie „Zwrócono towar”. Przykłady truefalse | |||
| Grupa zakupowa PurchasingGroup | Grupa nabywców odpowiedzialna za określone działania zakupowe. | ||
| Opis Grupa zakupowa to nabywca lub zespół nabywców odpowiedzialny za określone działania zakupowe, materiały lub dostawców. To główny punkt kontaktu dla dostawców. Ten atrybut pozwala analizować obciążenie pracą i wyniki bardziej szczegółowo niż organizacja zakupowa. Można go wykorzystać do wykrywania przeciążonych zespołów, pomiaru efektywności poszczególnych grup nabywców oraz ustalenia, które z nich częściej odstępują od procesu, na przykład dokonując zakupów poza ustalonymi zasadami. Dlaczego to ważne Pozwala szczegółowo analizować wyniki grup nabywców, w tym obciążenie pracą, efektywność i przestrzeganie procesu na poziomie zespołu. Skąd pobrać Ten atrybut znajduje się w tabeli SAP S/4HANA EKKO, w polu EKGRP. Przykłady 001002N00 | |||
| Kategoria pozycji ItemCategory | Klasyfikuje pozycję zamówienia zakupu, na przykład jako standardową, konsygnacyjną, podwykonawczą lub usługową. | ||
| Opis Kategoria pozycji określa sposób obsługi zakupu konkretnego materiału lub usługi. Wpływa na kolejne etapy, takie jak przyjęcie towaru i weryfikacja faktury. Ten atrybut jest przydatny przy analizie wariantów procesu zależnie od przedmiotu zakupu. Na przykład obsługa pozycji usługowej, która wymaga arkusza wprowadzania usług, znacznie różni się od obsługi standardowej pozycji magazynowej. Analiza według kategorii pozycji pomaga wyjaśnić te różnice i zaplanować odpowiednie usprawnienia. Dlaczego to ważne Wyjaśnia różnice między wariantami procesu, rozróżniając typy zakupów, takie jak towary, usługi czy podwykonawstwo. Skąd pobrać Ten atrybut znajduje się w tabeli SAP S/4HANA EKPO, w polu PSTYP. Przykłady 093 | |||
| Kod spółki CompanyCode | Identyfikator jednostki prawnej lub spółki, dla której utworzono zamówienie zakupu. | ||
| Opis Kod spółki oznacza niezależną jednostkę księgową w organizacji. Wszystkie transakcje finansowe związane z zamówieniem zakupu są księgowane na konkretny kod spółki. To podstawowy atrybut organizacyjny, który pozwala filtrować i porównywać procesy zakupowe w różnych jednostkach prawnych. Analiza według kodu spółki może ujawnić niespójności w realizacji procesu, różnice w efektywności lub poziomie zgodności w poszczególnych częściach organizacji. Dlaczego to ważne Pozwala analizować procesy osobno dla poszczególnych jednostek prawnych i porównywać ich wyniki oraz zgodność w różnych częściach firmy. Skąd pobrać Ten atrybut znajduje się w tabeli SAP S/4HANA EKKO, w polu BUKRS. Przykłady 101017102000 | |||
| Numer materiału MaterialNumber | Identyfikator konkretnego materiału lub towaru kupowanego w ramach procesu. | ||
| Opis Numer materiału to unikalny kod przypisany do każdej kartoteki materiałowej w SAP. Jest używany we wszystkich transakcjach dotyczących danego materiału, w tym zakupach, zarządzaniu zapasami i sprzedaży. Analiza według numeru lub grupy materiałowej pozwala oceniać zakupy w podziale na kategorie. Może pomóc ustalić, czy procesy zakupowe dotyczące określonych materiałów są mniej efektywne, trwają dłużej lub częściej prowadzą do zwrotów. Takie informacje wspierają zarządzanie kategoriami zakupowymi. Dlaczego to ważne Umożliwia analizę zakupów według kategorii i pomaga wykrywać problemy z procesem lub wynikami dostawców w odniesieniu do konkretnych produktów i materiałów. Skąd pobrać Ten atrybut znajduje się w tabeli SAP S/4HANA EKPO, w polu MATNR. Przykłady RM100-100FG210USŁUGI-KONSULTINGOWE | |||
| Organizacja zakupowa PurchasingOrganization | Jednostka organizacyjna odpowiedzialna za zakup materiałów i usług oraz negocjacje z dostawcami. | ||
| Opis Organizacja zakupowa to ważna jednostka organizacyjna w obszarze zakupów. Może działać na poziomie całej grupy kapitałowej, spółki lub zakładu i odpowiada za wszystkie działania zakupowe. Analiza procesu według organizacji zakupowej pomaga ocenić efektywność i wyniki różnych zespołów zakupowych lub regionów. Może ujawnić różnice w negocjacjach z dostawcami, zgodności z procesem lub opóźnieniach w zatwierdzaniu między jednostkami organizacyjnymi. Dlaczego to ważne Umożliwia porównanie wyników różnych działów zakupów lub regionów, co pomaga wskazać dobre praktyki i obszary wymagające usprawnień. Skąd pobrać Ten atrybut znajduje się w tabeli SAP S/4HANA EKKO, w polu EKORG. Przykłady 10101710US01 | |||
| Terminowość dostaw dostawcy SupplierOnTimeDelivery | Obliczana flaga wskazująca, czy przyjęcie towaru zaksięgowano w dniu wymaganej dostawy lub wcześniej. | ||
| Opis Ten atrybut logiczny jest wyliczany przez porównanie znacznika czasu działania „Zaksięgowano przyjęcie towaru” z „Wymaganą datą dostawy”. Jeśli przyjęcie towaru nastąpiło w wymaganym terminie lub wcześniej, flaga przyjmuje wartość „true”. Atrybut ten bezpośrednio zasila KPI „Wskaźnik terminowych dostaw dostawcy”. Ułatwia analizę, pozwalając filtrować dostawy terminowe i opóźnione. Jest przydatny w dashboardach wyników dostawców i przy ocenie dostawców. Dlaczego to ważne Bezpośrednio mierzy rzetelność dostawcy, stanowi podstawę KPI terminowości dostaw i wspiera zarządzanie wynikami dostawców. Skąd pobrać Obliczany przez porównanie znacznika czasu działania „Zaksięgowano przyjęcie towaru” z atrybutem „RequestedDeliveryDate”. Przykłady truefalse | |||
| Zakład Plant | Zakład lub lokalizacja, do której dostarczane są towary albo w której świadczone są usługi. | ||
| Opis W SAP zakład to fizyczna lokalizacja, w której produkuje się lub przechowuje towary albo świadczy usługi. Jest ważnym elementem logistyki i planowania. Podział analizy procesu według zakładu może ujawnić różnice regionalne lub lokalne w przebiegu zakupów. Można na przykład sprawdzić, czy w niektórych zakładach dostawy trwają dłużej albo częściej dochodzi do zwrotów towarów. Może to wskazywać na lokalne problemy logistyczne lub z kontrolą jakości. Dlaczego to ważne Umożliwia analizę według lokalizacji i pokazuje różnice w przebiegu procesu między zakładami, placówkami operacyjnymi i magazynami. Skąd pobrać Ten atrybut znajduje się w tabeli SAP S/4HANA EKPO, w polu WERKS. Przykłady 10101710DE01 | |||
| Zakup poza ustalonymi zasadami IsMaverickSpend | Obliczana flaga wskazująca, czy zamówienie zakupu utworzono bez wcześniejszego zatwierdzonego zapotrzebowania zakupowego. | ||
| Opis Ta flaga logiczna jest wyliczana podczas przetwarzania danych. Przyjmuje wartość „true”, jeśli zamówienie zakupu nie ma powiązanego zapotrzebowania zakupowego lub jego utworzenie ominęło standardowy workflow zatwierdzania. Atrybut ten bezpośrednio zasila dashboard „Identyfikacja zakupów poza ustalonymi zasadami” i powiązane KPI. Pomaga określić skalę zakupów niezgodnych z zasadami, dzięki czemu można wskazać konkretne działy lub grupy użytkowników i wzmocnić stosowanie polityki zakupowej oraz mechanizmów kontrolnych. Dlaczego to ważne Bezpośrednio wskazuje zakupy niezgodne z zasadami, pomaga określić skalę odstępstw od procesu oraz egzekwować kontrolę finansową i politykę zakupową. Skąd pobrać Pole obliczane na podstawie braku wartości w polu „PurchaseRequisitionNumber” dla określonych typów dokumentów lub analizy sekwencji zdarzeń. Przykłady truefalse | |||
Działania w procesie od zakupu do płatności, zamówienia zakupu
| Działanie | Opis | ||
|---|---|---|---|
| Akceptacja zamówienia zakupu | Oznacza, że zamówienie zakupu uzyskało wszystkie wymagane akceptacje wewnętrzne i może zostać wysłane do dostawcy. Zdarzenie jest określane na podstawie zmiany statusu w strategii zwalniania zamówienia zakupu. | ||
| Dlaczego to ważne To ważny etap przy mierzeniu sprawności akceptacji i dodatkowej pracy po zatwierdzeniu. Analiza czasu między utworzeniem a akceptacją PO pozwala wykryć opóźnienia w procesie wewnętrznym. Skąd pobrać Zdarzenie jest określane na podstawie wskaźnika zwolnienia (FRGKE) w tabeli EKKO. Timestamp ustala się na podstawie historii zmian (CDHDR/CDPOS), sprawdzając, kiedy pole przyjęło status „zwolnione”. Rejestrowanie Zdarzenie jest określane na podstawie dzienników zmian pola wskaźnika zwolnienia (FRGKE) w tabeli EKKO. Typ zdarzenia inferred | |||
| Akceptacja zapotrzebowania zakupowego | Oznacza formalną akceptację zapotrzebowania zakupowego przez kierownika lub wyznaczoną osobę zatwierdzającą. Zwykle wnioskuje się o niej na podstawie zmiany statusu dokumentu, która oznacza, że można przekształcić go w zamówienie zakupu. | ||
| Dlaczego to ważne To ważny etap przy mierzeniu czasu akceptacji i wykrywaniu wąskich gardeł. Opóźnienia bezpośrednio wpływają na to, jak szybko można utworzyć zamówienie zakupu i wysłać je do dostawcy. Skąd pobrać Zdarzenie jest określane na podstawie pól statusu zwolnienia w tabeli EBAN, na przykład FRGZU (wskaźnik zwolnienia). Timestamp pochodzi z dokumentów zmian (CDHDR/CDPOS), które zapisują moment ustawienia końcowego statusu zwolnienia. Rejestrowanie Zdarzenie jest określane na podstawie dzienników zmian (CDHDR/CDPOS) pól statusu zwolnienia w tabeli EBAN. Typ zdarzenia inferred | |||
| Otrzymanie faktury | Oznacza wprowadzenie faktury dostawcy do systemu SAP i powiązanie jej z odpowiednim zamówieniem zakupu. Jest to jawne księgowanie finansowe, które tworzy dokument księgowy. | ||
| Dlaczego to ważne To ważny etap łączący proces zakupowy z procesem obsługi zobowiązań. Pozwala analizować czas między przyjęciem towaru a przetworzeniem faktury. Skąd pobrać Dokument księgowy jest tworzony w tabeli BKPF (nagłówek), a jego pozycje znajdują się w tabeli BSEG lub w uniwersalnym dzienniku ACDOCA. Dokument jest powiązany z PO w tabeli RSEG. Rejestrowanie Data wprowadzenia dokumentu (CPUDT) z tabeli nagłówka dokumentu księgowego BKPF. Typ zdarzenia explicit | |||
| Utworzenie zamówienia zakupu | Oznacza utworzenie oficjalnego dokumentu zamówienia zakupu, z odwołaniem do zapotrzebowania zakupowego lub bez niego. Zdarzenie jest rejestrowane w chwili pierwszego zapisania dokumentu PO w systemie. | ||
| Dlaczego to ważne To zdarzenie może być alternatywnym początkiem procesu, szczególnie przy analizie zakupów poza zatwierdzonymi kanałami. Jest podstawą do mierzenia całkowitego czasu obsługi PO. Skąd pobrać Dane są zapisane w tabeli nagłówka zamówienia zakupu EKKO. Data utworzenia (AEDAT) i godzina dokumentu są przechowywane bezpośrednio w tej tabeli. Rejestrowanie Timestamp utworzenia (AEDAT) dokumentu zamówienia zakupu w tabeli EKKO. Typ zdarzenia explicit | |||
| Utworzenie zapotrzebowania zakupowego | To zdarzenie oznacza formalne zgłoszenie zapotrzebowania na towary lub usługi i rozpoczyna proces zakupowy. Jest rejestrowane w chwili zapisania przez użytkownika nowego dokumentu zapotrzebowania zakupowego, na przykład w transakcji ME51N. | ||
| Dlaczego to ważne To częsty punkt początkowy cyklu życia zamówienia zakupu. Analiza czasu od tego zdarzenia do utworzenia PO pomaga wykryć opóźnienia w pozyskiwaniu ofert i obsłudze wewnętrznej. Skąd pobrać Dane są zapisane w tabeli EBAN (Purchase Requisition). Timestamp utworzenia można znaleźć w tabelach historii zmian CDHDR i CDPOS dla obiektu EBAN. Rejestrowanie Zdarzenie rejestrowane podczas tworzenia dokumentu w tabeli EBAN. Typ zdarzenia explicit | |||
| Zaksięgowanie przyjęcia towaru | Oznacza fizyczne przyjęcie towarów od dostawcy i odpowiadający mu zapis w systemie. Jest to jawna transakcja aktualizująca historię zamówienia zakupu. | ||
| Dlaczego to ważne To ważny etap, który kończy czas realizacji po stronie dostawcy i rozpoczyna wewnętrzną weryfikację faktury. Jest niezbędny do śledzenia terminowości dostaw. Skąd pobrać Dane są zapisane jako dokument materiałowy w tabelach MKPF (nagłówek) i MSEG (pozycja), a w tabeli historii zamówienia zakupu EKBE są powiązane z określonym typem ruchu, na przykład 101. Rejestrowanie Data księgowania (BUDAT) z nagłówka dokumentu materiałowego (MKPF), powiązana przez EKBE. Typ zdarzenia explicit | |||
| Zamknięcie zamówienia zakupu | To zdarzenie oznacza, że pozycja zamówienia zakupu jest uznawana za zamkniętą z punktu widzenia logistyki. Wnioskuje się o nim, gdy ustawione są wskaźniki „Dostawa zakończona” i „Faktura końcowa”. | ||
| Dlaczego to ważne To końcowy punkt analizy cyklu życia zamówienia zakupu. Pomiar czasu do tego zdarzenia pokazuje całkowity czas realizacji operacji zakupowych. Skąd pobrać Zdarzenie jest określane na podstawie flag statusu w tabeli pozycji zamówienia zakupu EKPO. Występuje, gdy wskaźniki „Dostawa zakończona” (ELIKZ) i „Faktura końcowa” (EREKZ) są ustawione na true. Rejestrowanie Zdarzenie jest określane na podstawie dzienników zmian, gdy pola ELIKZ i EREKZ w EKPO są oznaczone jako zakończone. Typ zdarzenia inferred | |||
| Opłacenie faktury | Oznacza końcowe rozliczenie faktury dostawcy w ramach przebiegu płatności lub płatności ręcznej. Jest to jawna transakcja finansowa, która tworzy dokument rozliczeniowy. | ||
| Dlaczego to ważne Choć technicznie należy do procesu płatności, uwzględnienie tego zdarzenia zapewnia pełny obraz cyklu zakupowego od zamówienia do płatności. Jest ono ważne przy analizie warunków i terminowości płatności. Skąd pobrać Płatność jest rejestrowana jako dokument rozliczeniowy w BKPF/ACDOCA. Data rozliczenia (AUGDT) pozycji faktury w tabeli BSEG lub ACDOCA wskazuje zdarzenie płatności. Rejestrowanie Data rozliczenia (AUGDT) dokumentu faktury, dostępna w BSEG lub ACDOCA. Typ zdarzenia explicit | |||
| Usunięcie zamówienia zakupu | Oznacza anulowanie lub logiczne usunięcie pozycji zamówienia zakupu albo całego dokumentu. Zdarzenie jest rejestrowane, gdy użytkownik ustawi flagę usunięcia dokumentu. | ||
| Dlaczego to ważne To alternatywny punkt końcowy procesu, oznaczający niepowodzenie lub anulowanie. Analiza przyczyn usuwania PO może ujawnić problemy z planowaniem popytu lub określaniem wymagań. Skąd pobrać Dane pochodzą z flagi wskaźnika usunięcia (LOEKZ) w tabeli nagłówka zamówienia zakupu (EKKO) lub pozycji (EKPO). Timestamp ustala się na podstawie dokumentów zmian (CDHDR/CDPOS). Rejestrowanie Timestamp z dokumentów zmian (CDHDR/CDPOS) z chwili ustawienia flagi usunięcia (LOEKZ). Typ zdarzenia explicit | |||
| Wprowadzenie potwierdzenia wykonania usługi | To zdarzenie oznacza potwierdzenie wykonania usługi określonej w zamówieniu zakupu. Jest jawnie rejestrowane podczas tworzenia arkusza wprowadzania usług. | ||
| Dlaczego to ważne W przypadku zakupów usług jest to odpowiednik przyjęcia towaru. Zdarzenie pomaga śledzić terminy realizacji usług i terminowo opłacać dostawców. Skąd pobrać Zdarzenie jest rejestrowane podczas tworzenia arkusza wprowadzania usług. Dane są przechowywane w tabelach ESSR (nagłówek) i ESLL (pozycje). Timestampem jest data utworzenia. Rejestrowanie Data utworzenia dokumentu arkusza wprowadzania usług w tabeli ESSR. Typ zdarzenia explicit | |||
| Wysłanie zamówienia zakupu do dostawcy | Oznacza moment przekazania zamówienia zakupu dostawcy, na przykład przez EDI, e-mail lub wydruk. Zdarzenie często można odczytać z dzienników zarządzania komunikatami wyjściowymi systemu. | ||
| Dlaczego to ważne To faktyczny początek czasu realizacji po stronie dostawcy. Zdarzenie jest niezbędne do rzetelnego pomiaru wyników dostawcy od chwili otrzymania zamówienia. Skąd pobrać Dane pochodzą z tabeli sterowania komunikatami wyjściowymi NAST, w której zapisywane są komunikaty wysłane dla dokumentu zakupowego. Można wykorzystać datę i godzinę odpowiedniego typu komunikatu, na przykład EDI lub e-mail. Rejestrowanie Timestamp pierwszego pomyślnie wysłanego komunikatu dotyczącego PO w tabeli NAST. Typ zdarzenia inferred | |||
| Zmiana zamówienia zakupu | To zdarzenie oznacza zmianę zamówienia zakupu po jego utworzeniu, na przykład zmianę ilości, ceny lub terminu dostawy. Jest jawnie rejestrowane w dziennikach zmian systemu. | ||
| Dlaczego to ważne Śledzenie zmian, szczególnie po akceptacji, pomaga wykrywać nieefektywności, dodatkową pracę i potencjalne problemy ze zgodnością. Częste zmiany mogą wskazywać na niedokładne specyfikacje początkowe. Skąd pobrać Dane są zapisane w tabelach dokumentów zmian CDHDR (nagłówek) i CDPOS (pozycja) dla obiektów zamówień zakupu (EINKBELEG). Każda zmiana tworzy szczegółowy wpis w dzienniku. Rejestrowanie Zdarzenie rejestrowane przy zmianie ważnych pól w tabelach EKKO lub EKPO, zapisanej w CDHDR/CDPOS. Typ zdarzenia explicit | |||
| Zwrot towarów | Oznacza zwrot wcześniej przyjętych towarów do dostawcy, zwykle z powodu problemów z jakością, uszkodzeń lub błędnej dostawy. Zdarzenie jest jawnie rejestrowane jako ruch zwrotny towarów. | ||
| Dlaczego to ważne To zdarzenie wskazuje na dodatkową pracę i możliwe problemy z jakością dostawcy lub poprawnością zamówienia. Częste zwroty konkretnego materiału lub do konkretnego dostawcy sygnalizują problem. Skąd pobrać Dane są zapisywane jako dokument materiałowy z określonym typem ruchu zwrotnego, na przykład 122. Zdarzenie jest rejestrowane w MKPF/MSEG i powiązane z PO w tabeli historii EKBE. Rejestrowanie Data księgowania z dokumentu materiałowego z typem ruchu zwrotnego w EKBE. Typ zdarzenia explicit | |||
Instrukcje ekstrakcji danych
Kroki
- Wymagania wstępne i dostęp: Należy mieć użytkownika z odpowiednimi uprawnieniami do odpytywania widoków Core Data Services (CDS) w systemie SAP S/4HANA. Dostęp można uzyskać przez SAP HANA Studio, ABAP Development Tools (ADT) dla Eclipse lub zewnętrzne narzędzie do pobierania danych obsługujące połączenia SQL z bazą SAP HANA.
- Ustalanie parametrów połączenia z systemem: Należy uzyskać wymagane parametry połączenia z systemem SAP S/4HANA, w tym host, numer instancji i dane uwierzytelniające.
- Łączenie z bazą danych: Za pomocą wybranego klienta SQL należy połączyć się z bazą SAP S/4HANA, w której znajdują się widoki CDS.
- Przygotowanie zapytania SQL: Należy skopiować całe zapytanie SQL z sekcji zapytań w tym dokumencie do edytora SQL. Zapytanie pobiera wszystkie wymagane działania i atrybuty.
- Ustawianie parametrów filtrowania: W zapytaniu należy znaleźć wartości zastępcze. Wartości _start_date i _end_date trzeba zastąpić zakresem dat do analizy, na przykład '20230101' i '20231231'. Filtr poh.CompanyCode należy zmienić tak, aby uwzględniał kody spółek objęte analizą.
- Uruchomienie zapytania: Zmodyfikowane zapytanie SQL należy uruchomić w bazie S/4HANA. W zależności od ilości danych i wybranego zakresu dat wykonanie może potrwać.
- Wstępna kontrola wyników: Po zakończeniu zapytania warto szybko sprawdzić wyniki w kliencie SQL. Należy upewnić się, że są widoczne różne działania, znaczniki czasu zostały poprawnie wypełnione, a identyfikator sprawy (PurchaseOrderNumber) jest spójny.
- Eksport danych: Cały zestaw wyników należy wyeksportować z narzędzia SQL do pliku CSV (Comma Separated Values). Plik powinien być zapisany w kodowaniu UTF-8, aby uniknąć problemów z wyświetlaniem znaków.
- Przygotowanie do przesłania: Przed przesłaniem pliku do ProcessMind należy go otworzyć i sprawdzić, czy nagłówki kolumn dokładnie odpowiadają atrybutom określonym w wymaganiach dotyczących danych (PurchaseOrderNumber, ActivityName, EventTime itd.). Jeśli narzędzie eksportujące zmieniło nazwy kolumn, należy je poprawić.
- Przesłanie do ProcessMind: Gotowy plik CSV należy przesłać do projektu ProcessMind. Podczas importu trzeba przypisać kolumny z pliku do odpowiednich pól identyfikatora sprawy, działania i znacznika czasu.
Konfiguracja
- Używane widoki CDS: Logika pobierania danych korzysta ze standardowych widoków CDS o bogatej semantyce. Główne widoki to:
- I_PurchaseOrderItemAPI01: podstawowe dane pozycji zamówienia.
- I_PurchaseRequisitionItemAPI01: szczegóły zapotrzebowania zakupowego.
- I_MaterialDocumentItem: ruchy materiałowe, takie jak przyjęcia i zwroty.
- I_ServiceEntrySheetAPI01: zdarzenia potwierdzenia wykonania usług.
- I_SupplierInvoiceAPI01: informacje o fakturach dostawców.
- I_OperationalAcctgDocItem: powiązanie faktur z dokumentami finansowymi na potrzeby śledzenia płatności.
- I_ChangeDocument: zmiany w zamówieniu.
- Filtrowanie według zakresu dat: Aby kontrolować wydajność i ilość danych, należy zastosować filtr zakresu dat. W zapytaniu użyto wartości zastępczych _start_date i _end_date dla daty utworzenia zamówienia (PurchaseOrderDate). Na początek zaleca się zakres od 3 do 6 miesięcy.
- Filtrowanie według struktury organizacyjnej: Zapytanie należy zawsze filtrować według CompanyCode, aby ograniczyć pobieranie danych do właściwych jednostek biznesowych. W głównym wyrażeniu tabelowym PO_base można dodać filtry PurchaseOrderType lub PurchasingOrganization, aby zawęzić zakres.
- Wymagania wstępne: Użytkownik uruchamiający zapytanie musi mieć uprawnienia SELECT do wszystkich wymienionych wyżej widoków CDS. Dostęp do tych widoków jest zwykle przyznawany w ramach określonych ról biznesowych lub analitycznych w S/4HANA. Bez odpowiednich uprawnień zapytanie zakończy się błędem.
Przykładowe zapytanie sql
WITH PO_base AS (
SELECT
poh.PurchaseOrder AS PurchaseOrderNumber,
poi.PurchaseOrderItem AS PurchaseOrderItem,
poh.CompanyCode,
poh.PurchaseOrderType AS DocumentType,
poh.Supplier AS VendorId,
poh.PurchaseOrderDate,
poi.PurchaseRequisition AS PurchaseRequisitionNumber,
poi.NetPriceAmount * poi.OrderQuantity AS TotalNetAmount, -- Note: This is item-level net amount
poh.CreationDate AS POCreationDate,
poh.CreationTime AS POCreationTime,
poh.LastChangeDateTime AS POLastChangeDateTime,
poi.IsDeleted,
poi.DeliveryIsCompleted,
poi.FinalInvoiceIsExpected,
poi.GoodsReceiptIsExpected,
poi.LastGoodsReceiptDate,
poi.LastInvoiceReceiptDate
FROM I_PurchaseOrderAPI01 poh
JOIN I_PurchaseOrderItemAPI01 poi
ON poh.PurchaseOrder = poi.PurchaseOrder
WHERE
poh.PurchaseOrderDate BETWEEN '_start_date' AND '_end_date' -- Placeholder: e.g., '20230101' and '20230630'
AND poh.CompanyCode IN ('[YourCompanyCode]') -- Placeholder: e.g., '1010'
)
-- 1. Purchase Requisition Created
SELECT
po.PurchaseOrderNumber,
'Purchase Requisition Created' AS ActivityName,
CAST(CONCAT(pr.CreationDate, 'T', pr.CreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem, -- Placeholder
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
pr.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate, -- Available in PR, add if needed
po.DocumentType
FROM I_PurchaseRequisitionItemAPI01 pr
JOIN PO_base po
ON pr.PurchaseRequisition = po.PurchaseRequisitionNumber AND pr.PurchaseRequisitionItem = po.PurchaseOrderItem
UNION ALL
-- 2. Purchase Requisition Approved
SELECT
po.PurchaseOrderNumber,
'Purchase Requisition Approved' AS ActivityName,
CAST(CONCAT(pr.PurReqnReleaseDate, 'T', '000000') AS TIMESTAMP) AS EventTime, -- Time is not available in this view
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName, -- Approver info requires complex joins
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_PurchaseRequisitionItemAPI01 pr
JOIN PO_base po
ON pr.PurchaseRequisition = po.PurchaseRequisitionNumber AND pr.PurchaseRequisitionItem = po.PurchaseOrderItem
WHERE
pr.PurReqnReleaseDate IS NOT NULL
UNION ALL
-- 3. Purchase Order Created
SELECT
po.PurchaseOrderNumber,
'Purchase Order Created' AS ActivityName,
CAST(CONCAT(po.POCreationDate, 'T', po.POCreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
poh.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
poi.RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
JOIN I_PurchaseOrderAPI01 poh ON po.PurchaseOrderNumber = poh.PurchaseOrder
JOIN I_PurchaseOrderItemAPI01 poi ON po.PurchaseOrderNumber = poi.PurchaseOrder AND po.PurchaseOrderItem = poi.PurchaseOrderItem
UNION ALL
-- 4. Purchase Order Approved
SELECT DISTINCT
po.PurchaseOrderNumber,
'Purchase Order Approved' AS ActivityName,
CAST(poh.ReleaseDate AS TIMESTAMP) AS EventTime, -- Assuming ReleaseDate reflects final approval
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName, -- Approver info requires complex joins
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
poi.RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
JOIN I_PurchaseOrderAPI01 poh ON po.PurchaseOrderNumber = poh.PurchaseOrder
JOIN I_PurchaseOrderItemAPI01 poi ON po.PurchaseOrderNumber = poi.PurchaseOrder AND po.PurchaseOrderItem = poi.PurchaseOrderItem
WHERE poh.ReleaseDate IS NOT NULL
UNION ALL
-- 5. Purchase Order Sent to Vendor
SELECT DISTINCT
po.PurchaseOrderNumber,
'Purchase Order Sent to Vendor' AS ActivityName,
CAST(poh.ReleaseDate AS TIMESTAMP) AS EventTime, -- Using ReleaseDate as a proxy for sending time
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
poi.RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
JOIN I_PurchaseOrderAPI01 poh ON po.PurchaseOrderNumber = poh.PurchaseOrder
JOIN I_PurchaseOrderItemAPI01 poi ON po.PurchaseOrderNumber = poi.PurchaseOrder AND po.PurchaseOrderItem = poi.PurchaseOrderItem
WHERE poh.ReleaseDate IS NOT NULL
UNION ALL
-- 6. Purchase Order Changed
SELECT DISTINCT
ch.OBJECTID AS PurchaseOrderNumber,
'Purchase Order Changed' AS ActivityName,
CAST(CONCAT(ch.ChangeDocumentDate, 'T', ch.ChangeDocumentTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
ch.UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_ChangeDocument ch
JOIN PO_base po ON ch.OBJECTID = po.PurchaseOrderNumber
WHERE
ch.ObjectClassName = 'EINKBELEG' -- Object Class for Purchase Documents
AND CAST(CONCAT(ch.ChangeDocumentDate, 'T', ch.ChangeDocumentTime) AS TIMESTAMP) > CAST(CONCAT(po.POCreationDate, 'T', po.POCreationTime) AS TIMESTAMP)
UNION ALL
-- 7. Goods Receipt Posted
SELECT
po.PurchaseOrderNumber,
'Goods Receipt Posted' AS ActivityName,
CAST(CONCAT(md.PostingDate, 'T', md.CreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
md.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_MaterialDocumentItem md
JOIN PO_base po
ON md.PurchaseOrder = po.PurchaseOrderNumber AND md.PurchaseOrderItem = po.PurchaseOrderItem
WHERE
md.GoodsMovementType = '101'
UNION ALL
-- 8. Services Confirmation Entered
SELECT
po.PurchaseOrderNumber,
'Services Confirmation Entered' AS ActivityName,
CAST(se.PostingDate AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
se.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_ServiceEntrySheetAPI01 se
JOIN PO_base po
ON se.PurchaseOrder = po.PurchaseOrderNumber AND se.PurchaseOrderItem = po.PurchaseOrderItem
UNION ALL
-- 9. Goods Returned
SELECT
po.PurchaseOrderNumber,
'Goods Returned' AS ActivityName,
CAST(CONCAT(md.PostingDate, 'T', md.CreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
md.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_MaterialDocumentItem md
JOIN PO_base po
ON md.PurchaseOrder = po.PurchaseOrderNumber AND md.PurchaseOrderItem = po.PurchaseOrderItem
WHERE
md.GoodsMovementType = '122'
UNION ALL
-- 10. Invoice Received
SELECT
po.PurchaseOrderNumber,
'Invoice Received' AS ActivityName,
CAST(inv.PostingDate AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
inv.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_SupplierInvoiceAPI01 inv
JOIN PO_base po
ON inv.PurchaseOrderReference = po.PurchaseOrderNumber
WHERE
inv.DebitCreditCode = 'H' -- 'H' for Credit (Supplier Invoice)
UNION ALL
-- 11. Invoice Paid
SELECT
po.PurchaseOrderNumber,
'Invoice Paid' AS ActivityName,
CAST(doc.ClearingDate AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
doc.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_SupplierInvoiceAPI01 inv
JOIN I_OperationalAcctgDocItem doc
ON inv.AccountingDocument = doc.AccountingDocument
JOIN PO_base po
ON inv.PurchaseOrderReference = po.PurchaseOrderNumber
WHERE
doc.IsCleared = 'X' AND doc.ClearingDate IS NOT NULL
UNION ALL
-- 12. Purchase Order Completed
SELECT
po.PurchaseOrderNumber,
'Purchase Order Completed' AS ActivityName,
CAST(GREATEST(po.LastGoodsReceiptDate, po.LastInvoiceReceiptDate) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
'SYSTEM' AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
WHERE
po.DeliveryIsCompleted = 'X'
AND (po.FinalInvoiceIsExpected = 'X' OR po.GoodsReceiptIsExpected = '') -- Logic for completion
AND GREATEST(po.LastGoodsReceiptDate, po.LastInvoiceReceiptDate) IS NOT NULL
UNION ALL
-- 13. Purchase Order Deleted
SELECT
po.PurchaseOrderNumber,
'Purchase Order Deleted' AS ActivityName,
CAST(po.POLastChangeDateTime AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName, -- User who set the flag is in change docs
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
WHERE
po.IsDeleted = 'X' Kroki
- Należy potwierdzić dostęp SQL do schematu SAP HANA zawierającego tabele EKKO i EKPO oraz uzyskać wymagane uprawnienia do odczytu. Wartości zastępcze schematu i połączenia należy zastąpić ustawieniami skonfigurowanymi w danym systemie.
- Zakres pobierania danych należy określić za pomocą [Start timestamp] i [End timestamp]. Przy pierwszym pobraniu zaleca się zakres od trzech do sześciu miesięcy. Filtry kodu spółki i typu dokumentu należy stosować tylko wtedy, gdy są wymagane zakresem raportowania.
- Należy zidentyfikować zamówienia w tabelach EKKO i EKPO oraz zachować numer zamówienia, dostawcę, typ dokumentu, kod spółki, datę i godzinę utworzenia oraz atrybuty pozycji. Wartości netto z EKPO należy zsumować, aby obliczyć TotalNetAmount dla każdego zamówienia.
- Z tabeli EBAN należy pobrać zdarzenia utworzenia i zatwierdzenia zapotrzebowania zakupowego. Do powiązania zapotrzebowań z zamówieniami należy użyć numeru zapotrzebowania i odwołania do pozycji dostępnego w EKPO. Wskaźniki zatwierdzenia i znaczniki czasu zapotrzebowań zależą od konfiguracji wersji systemu. Wyrażenia określające status zatwierdzenia i znacznik czasu należy skonfigurować zgodnie z aktywną strategią zwalniania SAP w sekcji [Configure based on your system].
- Należy pobrać zdarzenia utworzenia, zatwierdzenia, zmiany, usunięcia i zakończenia zamówienia. Do ustalenia utworzenia służą data i godzina utworzenia z EKKO. Zatwierdzenie, zmiana i usunięcie wymagają źródeł historii zwolnień lub zmian. Jeśli odpowiednia historia nie jest dostępna w wybranym schemacie, źródła należy skonfigurować za pomocą [Your table name] i [Your column name].
- Należy pobrać zdarzenia komunikacji z dostawcą, przyjęcia towaru, potwierdzenia wykonania usługi, zwrotu towaru, otrzymania faktury i płatności za fakturę z odpowiednich źródeł dotyczących komunikatów, dokumentów materiałowych, potwierdzeń usług, faktur, księgowań i rozliczeń. Zapytanie zawiera osobne wartości zastępcze dla obiektów zależnych od systemu, ponieważ samych tabel EKKO i EKPO nie wystarczy do ich ustalenia.
- Wszystkie zdarzenia ze źródeł należy ujednolicić do tej samej struktury dziennika zdarzeń. Każdy wiersz musi zawierać PurchaseOrderNumber, ActivityName, EventTime, SourceSystem, LastDataUpdate, VendorId, UserName, TotalNetAmount, PurchaseRequisitionNumber, RequestedDeliveryDate i DocumentType. Jeśli źródło zawiera kilka prawidłowych zdarzeń tego samego rodzaju, należy zachować każde z nich.
- Należy sprawdzić znaczniki czasu i usuwać wyłącznie dokładne duplikaty wierszy ze źródeł. Nie należy dopisywać działań, dla których nie ma rekordu źródłowego. ProcessMind odczytuje dziennik zdarzeń bez zmian, dlatego każde działanie widoczne na wizualizacji procesu musi mieć osobny wiersz.
- Wyniki należy wyeksportować jako plik rozdzielany separatorami lub zestaw wyników z bazy danych, z jednym wierszem nagłówków i stałymi nazwami kolumn. Należy użyć formatu znacznika czasu obsługiwanego przez konfigurację przesyłania ProcessMind, zachować PurchaseOrderNumber jako tekst i przesłać cały dziennik zdarzeń przez skonfigurowane połączenie danych ProcessMind.
Konfiguracja
- Obiekty źródłowe: EKKO i EKPO to potwierdzone źródła danych nagłówków i pozycji zamówień. Pozostałe obiekty dotyczące zapotrzebowań, statusu zwolnień, historii zmian, komunikatów, ruchów materiałowych, potwierdzeń usług, faktur, płatności i rozliczeń należy skonfigurować zgodnie z wersją SAP S/4HANA i aktywnym modelem danych.
- Identyfikator sprawy: Jako identyfikatora sprawy należy użyć PurchaseOrderNumber. Zdarzenia dotyczące pozycji należy przypisać do numeru zamówienia, a odwołania do pozycji zachować w dodatkowej kolumnie właściwej dla źródła, jeśli są potrzebne.
- Zakres dat: Na początek należy wybrać okres od trzech do sześciu miesięcy. Przy pobieraniu danych historycznych warto przetwarzać krótsze okresy i uzgadniać nakładające się granice, aby uniknąć pominięć.
- Filtry: Filtry Company Code, Document Type, VendorId, organizacji zakupowej, grupy zakupowej i daty zdarzenia należy skonfigurować zgodnie z wymaganym zakresem. Filtry kodu spółki i typu dokumentu muszą korzystać z wartości obowiązujących w systemie docelowym.
- Znaczenie zdarzeń: Utworzenie i usunięcie można określić bezpośrednio, jeśli dostępne są odpowiednie pola dokumentu lub dzienniki. Zatwierdzenie i zakończenie to zdarzenia oparte na statusie, które wymagają skonfigurowanych znaczników czasu. Nie należy tworzyć wierszy wyłącznie na podstawie bieżącego statusu, jeśli nie ma wiarygodnego znacznika czasu zdarzenia.
- Wydajność: Należy wcześnie filtrować dane według dat zdarzeń i zakresu organizacyjnego, w miarę możliwości agregować EKPO przed połączeniem ze źródłami zdarzeń oraz pobierać duże zbiory historyczne w przedziałach czasowych. Trzeba zadbać o odpowiednie statystyki bazy danych i unikać nieograniczonych połączeń tabel pozycji, księgowań i historii zmian.
- Znacznik czasu odświeżenia: Dla każdego wiersza w danym przebiegu pobierania LastDataUpdate należy ustawić na czas uruchomienia ekstrakcji.
- Wymagania wstępne: Potrzebne są połączenie z SAP HANA, uprawnienia do odczytu wszystkich skonfigurowanych obiektów źródłowych, dostęp do danych dotyczących zakupów, gospodarki magazynowej, zakupów usług, weryfikacji faktur i zobowiązań oraz połączenie ProcessMind umożliwiające import wybranego pliku lub zestawu wyników.
- Konfiguracja zależna od systemu: Każdą wartość zastępczą w nawiasach kwadratowych należy zastąpić zatwierdzoną tabelą, widokiem, kolumną lub wyrażeniem z docelowego systemu SAP S/4HANA. Nie wolno umieszczać danych uwierzytelniających w zapytaniu ani konfiguracji pobierania.
Przykładowe zapytanie sql
WITH
params AS (
SELECT
CAST('[Start timestamp]' AS TIMESTAMP) AS start_ts,
CAST('[End timestamp]' AS TIMESTAMP) AS end_ts,
CAST(CURRENT_TIMESTAMP AS TIMESTAMP) AS last_data_update,
CAST('[Source system]' AS NVARCHAR(100)) AS source_system
FROM DUMMY
),
po_base AS (
SELECT
h.MANDT,
h.EBELN AS PurchaseOrderNumber,
h.LIFNR AS VendorId,
h.BSART AS DocumentType,
h.BUKRS AS CompanyCode,
CAST(h.AEDAT AS DATE) AS POChangedDate,
CAST(h.AEDAT AS TIMESTAMP) AS POChangedTimestamp,
CAST(h.ERNAM AS NVARCHAR(100)) AS POCreatedBy,
CAST(h.BEDAT AS DATE) AS PODate,
CAST(h.EBELN AS NVARCHAR(20)) AS PurchaseOrderKey,
CAST(SUM(COALESCE(i.NETWR, 0)) AS DECIMAL(23, 2)) AS TotalNetAmount,
CAST(MIN(i.BEDNR) AS NVARCHAR(20)) AS PurchaseRequisitionNumber,
CAST(MIN(i.EINDT) AS DATE) AS RequestedDeliveryDate
FROM EKKO h
INNER JOIN EKPO i
ON i.MANDT = h.MANDT
AND i.EBELN = h.EBELN
WHERE h.AEDAT >= (SELECT start_ts FROM params)
AND h.AEDAT < (SELECT end_ts FROM params)
AND h.BUKRS IN ([Company Code filter])
AND h.BSART IN ([Document Type filter])
GROUP BY
h.MANDT,
h.EBELN,
h.LIFNR,
h.BSART,
h.BUKRS,
h.AEDAT,
h.ERNAM,
h.BEDAT
),
po_items AS (
SELECT
i.MANDT,
i.EBELN AS PurchaseOrderNumber,
i.EBELP,
i.BANFN AS PurchaseRequisitionNumber,
i.BEDNR,
i.EINDT AS RequestedDeliveryDate
FROM EKPO i
),
events AS (
SELECT
p.PurchaseOrderNumber,
'Purchase Requisition Created' AS ActivityName,
CAST(r.[Purchase requisition creation timestamp] AS TIMESTAMP) AS EventTime,
s.source_system AS SourceSystem,
s.last_data_update AS LastDataUpdate,
p.VendorId,
CAST(r.[Purchase requisition created by] AS NVARCHAR(100)) AS UserName,
p.TotalNetAmount,
CAST(r.[Purchase requisition number] AS NVARCHAR(20)) AS PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your requisition source table or view] r
ON r.[Client] = p.MANDT
AND r.[Purchase requisition number] = p.PurchaseRequisitionNumber
CROSS JOIN params s
WHERE r.[Purchase requisition creation timestamp] >= s.start_ts
AND r.[Purchase requisition creation timestamp] < s.end_ts
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Requisition Approved' AS ActivityName,
CAST(r.[Purchase requisition approval timestamp] AS TIMESTAMP) AS EventTime,
s.source_system,
s.last_data_update,
p.VendorId,
CAST(r.[Purchase requisition approver] AS NVARCHAR(100)),
p.TotalNetAmount,
CAST(r.[Purchase requisition number] AS NVARCHAR(20)),
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your requisition approval history table or view] r
ON r.[Client] = p.MANDT
AND r.[Purchase requisition number] = p.PurchaseRequisitionNumber
CROSS JOIN params s
WHERE r.[Purchase requisition approval timestamp] >= s.start_ts
AND r.[Purchase requisition approval timestamp] < s.end_ts
AND r.[Approval status] = '[Approved status value]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Created',
CAST(p.PODate AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
p.POCreatedBy,
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
CROSS JOIN params s
WHERE p.PODate >= CAST(s.start_ts AS DATE)
AND p.PODate < CAST(s.end_ts AS DATE)
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Approved',
CAST(a.[Purchase order approval timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(a.[Approver] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your purchase order release history table or view] a
ON a.[Client] = p.MANDT
AND a.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE a.[Purchase order approval timestamp] >= s.start_ts
AND a.[Purchase order approval timestamp] < s.end_ts
AND a.[Release status] = '[Approved release status value]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Sent to Vendor',
CAST(o.[Output timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(o.[Output user] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your purchase order output source table or view] o
ON o.[Client] = p.MANDT
AND o.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE o.[Output timestamp] >= s.start_ts
AND o.[Output timestamp] < s.end_ts
AND o.[Output status] = '[Successfully processed output status]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Changed',
CAST(c.[Change timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(c.[Changed by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your purchase order change history table or view] c
ON c.[Client] = p.MANDT
AND c.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE c.[Change timestamp] >= s.start_ts
AND c.[Change timestamp] < s.end_ts
AND c.[Change indicator] = '[Changed indicator value]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Goods Receipt Posted',
CAST(g.[Goods movement timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(g.[Posted by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your goods movement source table or view] g
ON g.[Client] = p.MANDT
AND g.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE g.[Goods movement timestamp] >= s.start_ts
AND g.[Goods movement timestamp] < s.end_ts
AND g.[Movement type] IN ([Goods receipt movement types])
AND g.[Reversal indicator] IS NULL
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Services Confirmation Entered',
CAST(v.[Service entry timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(v.[Entered by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your service entry sheet source table or view] v
ON v.[Client] = p.MANDT
AND v.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE v.[Service entry timestamp] >= s.start_ts
AND v.[Service entry timestamp] < s.end_ts
AND v.[Service entry status] = '[Accepted service entry status]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Goods Returned',
CAST(g.[Goods movement timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(g.[Posted by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your goods movement source table or view] g
ON g.[Client] = p.MANDT
AND g.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE g.[Goods movement timestamp] >= s.start_ts
AND g.[Goods movement timestamp] < s.end_ts
AND g.[Movement type] IN ([Goods return movement types])
AND g.[Reversal indicator] IS NULL
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Invoice Received',
CAST(i.[Invoice posting timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(i.[Posted by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your supplier invoice source table or view] i
ON i.[Client] = p.MANDT
AND i.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE i.[Invoice posting timestamp] >= s.start_ts
AND i.[Invoice posting timestamp] < s.end_ts
AND i.[Invoice status] = '[Posted invoice status]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Invoice Paid',
CAST(i.[Clearing timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(i.[Cleared by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your supplier invoice clearing source table or view] i
ON i.[Client] = p.MANDT
AND i.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE i.[Clearing timestamp] >= s.start_ts
AND i.[Clearing timestamp] < s.end_ts
AND i.[Clearing status] = '[Cleared status value]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Completed',
CAST(x.[Completion timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(x.[Completion user] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your purchase order item status source table or view] x
ON x.[Client] = p.MANDT
AND x.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE x.[Completion timestamp] >= s.start_ts
AND x.[Completion timestamp] < s.end_ts
AND x.[Delivery completed indicator] = '[Set indicator value]'
AND x.[Final invoice indicator] = '[Set indicator value]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Deleted',
CAST(d.[Deletion timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(d.[Deleted by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your purchase order deletion history table or view] d
ON d.[Client] = p.MANDT
AND d.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE d.[Deletion timestamp] >= s.start_ts
AND d.[Deletion timestamp] < s.end_ts
AND d.[Deletion indicator] = '[Set deletion indicator value]'
)
SELECT
PurchaseOrderNumber,
ActivityName,
EventTime,
SourceSystem,
LastDataUpdate,
VendorId,
UserName,
TotalNetAmount,
PurchaseRequisitionNumber,
RequestedDeliveryDate,
DocumentType
FROM events
WHERE PurchaseOrderNumber IS NOT NULL
AND ActivityName IS NOT NULL
AND EventTime IS NOT NULL
ORDER BY PurchaseOrderNumber, EventTime, ActivityName; Kroki
- Specyfikacja i projekt: Należy określić docelową strukturę pliku dziennika zdarzeń, uwzględniając wszystkie wymagane i zalecane atrybuty. Trzeba opisać konkretne tabele SAP, na przykład EKKO, EKPO, EKBE, CDHDR i CDPOS, które posłużą jako źródła danych dla każdego z 13 wymaganych działań.
- Utworzenie programu: W SAP GUI należy przejść do edytora ABAP za pomocą kodu transakcji SE38 lub SE80. Następnie utworzyć nowy program wykonywalny, na przykład Z_PM_PO_EXTRACT.
- Definicja ekranu wyboru: Należy zaprogramować ekran wyboru raportu, który pozwoli użytkownikom filtrować pobierane dane. Powinien zawierać parametry zakresu dat utworzenia zamówienia (P_AEDAT), kodu spółki (P_BUKRS) i typu dokumentu zakupowego (P_BSART).
- Deklaracje danych: Należy zdefiniować tabele wewnętrzne i struktury danych potrzebne programowi. Wśród nich powinna znaleźć się tabela wewnętrzna dziennika zdarzeń o strukturze zgodnej ze specyfikacją.
- Implementacja logiki wyboru danych: Należy napisać główną logikę ABAP pobierającą dane dla każdego z 13 działań. Wymaga to serii instrukcji SELECT dla odpowiednich tabel SAP, połączonych w razie potrzeby. W przypadku zdarzeń związanych ze zmianami należy odczytać tabele dziennika zmian CDHDR i CDPOS.
- Przekształcenie i mapowanie danych: Dla każdego pobranego rekordu należy przypisać pola tabel SAP do odpowiednich kolumn końcowej tabeli wewnętrznej dziennika zdarzeń. ActivityName należy ustawić zgodnie z przetwarzanym zdarzeniem, na przykład 'Purchase Order Created'. Pola daty i godziny trzeba przekształcić do spójnego formatu znacznika czasu dla EventTime.
- Scalenie danych o zdarzeniach: Po przetworzeniu wszystkich 13 typów działań należy zebrać dane w jednej, ujednoliconej tabeli wewnętrznej. Będzie ona zawierać kompletny dziennik zdarzeń dla wybranych zamówień.
- Zapis do pliku: Należy dodać funkcję zapisu końcowej tabeli wewnętrznej do pliku. Zalecane jest użycie metody cl_gui_frontend_services=>gui_download, która pozwala zapisać plik CSV na komputerze użytkownika, lub instrukcji OPEN DATASET, aby zapisać go na serwerze aplikacji SAP i przetwarzać w tle.
- Utworzenie kodu transakcji (opcjonalnie): Aby ułatwić użytkownikom biznesowym dostęp do programu, można użyć kodu transakcji SE93 do utworzenia własnego kodu transakcji, na przykład ZPM_PO_EXTRACT, który uruchamia program ABAP.
- Zaplanowanie zadania w tle: W przypadku dużej ilości danych lub automatycznego pobierania można użyć kodu transakcji SM36, aby zaplanować uruchomienie programu jako zadania w tle. Plik wynikowy zostanie zapisany w ścieżce serwera aplikacji określonej w logice programu.
Konfiguracja
- Kryteria wyboru: Program powinien udostępniać parametry pozwalające skutecznie filtrować dane. Najważniejsze filtry to:
- Zakres dat: Obowiązkowy zakres dat utworzenia zamówienia (EKKO-AEDAT). Aby kontrolować ilość danych i wydajność raportu, zaleca się rozpocząć od okresu 3–6 miesięcy.
- Kod spółki (BUKRS): Niezbędny w organizacjach obejmujących wiele podmiotów prawnych, pozwala zawęzić zakres pobierania danych.
- Typ dokumentu zakupowego (BSART): Umożliwia filtrowanie według określonych typów zamówień, takich jak zamówienie standardowe, umowa ramowa lub zamówienie przesunięcia zapasów, i zawężenie analizy.
- Odczyt dziennika zmian: Pobieranie działań takich jak 'Purchase Order Approved' lub 'Purchase Order Changed' wymaga odczytu tabel dziennika zmian SAP (CDHDR, CDPOS), co może obciążać zasoby. Logikę ABAP należy zoptymalizować tak, aby wybierała tylko potrzebne klasy obiektów (EINKBELEG, BANF) oraz kombinacje tabel i pól.
- Uprawnienia: Użytkownik lub konto techniczne uruchamiające raport musi mieć szerokie uprawnienia do odczytu tabel z wielu modułów SAP, w tym Materials Management (MM), Financial Accounting (FI) i tabel systemowych. Dotyczy to między innymi tabel EKKO, EKPO, EBAN, EKBE, BKPF, BSAK, RBKP, NAST, CDHDR i CDPOS.
- Uruchamianie w tle: Jeśli pobieranie obejmuje dane z okresu dłuższego niż kilka miesięcy lub odbywa się w systemie o dużej liczbie transakcji, program należy uruchamiać w tle, aby uniknąć przekroczenia limitu czasu procesu dialogowego.
Przykładowe zapytanie abap
REPORT z_pm_po_extract.
" ====================================================================
" SELECTION SCREEN
" ====================================================================
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE TEXT-001.
SELECT-OPTIONS: s_aedat FOR sy-datum OBLIGATORY.
SELECT-OPTIONS: s_bukrs FOR ekko-bukrs.
SELECT-OPTIONS: s_bsart FOR ekko-bsart.
PARAMETERS: p_sysid TYPE string DEFAULT '[Your SAP System ID]'.
SELECTION-SCREEN END OF BLOCK b1.
" ====================================================================
" DATA DECLARATIONS
" ====================================================================
TYPES: BEGIN OF ty_event_log,
purchaseordernumber TYPE ebeln,
activityname TYPE string,
eventtime TYPE timestamp,
sourcesystem TYPE string,
lastdataupdate TYPE timestamp,
vendorid TYPE lifnr,
username TYPE ernam,
totalnetamount TYPE netwr,
purchaserequisitionnumber TYPE banfn,
requesteddeliverydate TYPE eedat,
documenttype TYPE bsart,
END OF ty_event_log.
DATA: lt_event_log TYPE TABLE OF ty_event_log,
ls_event_log TYPE ty_event_log.
DATA: lt_ekko TYPE TABLE OF ekko,
lt_ekpo TYPE TABLE OF ekpo.
" ====================================================================
" START OF SELECTION
" ====================================================================
START-OF-SELECTION.
" Get current timestamp for LastDataUpdate
GET TIME STAMP FIELD ls_event_log-lastdataupdate.
ls_event_log-sourcesystem = p_sysid.
" --- Initial Data Selection: Purchase Orders in Scope ---
SELECT * FROM ekko INTO TABLE lt_ekko
WHERE aedat IN s_aedat
AND bukrs IN s_bukrs
AND bsart IN s_bsart.
IF lt_ekko IS INITIAL.
MESSAGE 'No Purchase Orders found for the given criteria.' TYPE 'S' DISPLAY LIKE 'E'.
RETURN.
ENDIF.
SELECT * FROM ekpo INTO TABLE lt_ekpo
FOR ALL ENTRIES IN lt_ekko
WHERE ebeln = lt_ekko-ebeln.
" --- 1. Purchase Requisition Created ---
SELECT ban.banfn, ban.erdat, ban.erzet, ban.ernam,
ekpo.ebeln, ekpo.netwr, ekpo.eindt, ekpo.bsart, ekpo.lifnr, ekko.bukrs
FROM eban AS ban
INNER JOIN ekpo AS ekpo ON ban.banfn = ekpo.banfn AND ban.bnfpo = ekpo.bnfpo
INNER JOIN ekko AS ekko ON ekpo.ebeln = ekko.ebeln
WHERE ekko.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_pr_created).
LOOP AT lt_pr_created INTO DATA(ls_pr_created).
ls_event_log-purchaseordernumber = ls_pr_created-ebeln.
ls_event_log-activityname = 'Purchase Requisition Created'.
CONVERT DATE ls_pr_created-erdat TIME ls_pr_created-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-vendorid = ls_pr_created-lifnr.
ls_event_log-username = ls_pr_created-ernam.
ls_event_log-totalnetamount = ls_pr_created-netwr.
ls_event_log-purchaserequisitionnumber = ls_pr_created-banfn.
ls_event_log-requesteddeliverydate = ls_pr_created-eindt.
ls_event_log-documenttype = ls_pr_created-bsart.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 2. Purchase Requisition Approved (via Change Docs on Release Indicator) ---
SELECT h.objectid, h.udate, h.utime, h.username
FROM cdhdr AS h
INNER JOIN cdpos AS p ON h.objectclas = p.objectclas AND h.objectid = p.objectid AND h.changenr = p.changenr
INNER JOIN ekpo AS ekpo ON h.objectid = ekpo.banfn
INNER JOIN ekko AS ekko ON ekpo.ebeln = ekko.ebeln
WHERE h.objectclas = 'BANF'
AND p.tabname = 'EBAN'
AND p.fname = 'FRGZU'
AND p.value_new = 'X' "Configure based on your system release indicator for 'Approved'
AND ekko.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_pr_approved).
LOOP AT lt_pr_approved INTO DATA(ls_pr_approved).
SELECT SINGLE ebeln FROM ekpo INTO ls_event_log-purchaseordernumber WHERE banfn = ls_pr_approved-objectid.
ls_event_log-activityname = 'Purchase Requisition Approved'.
CONVERT DATE ls_pr_approved-udate TIME ls_pr_approved-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_pr_approved-username.
" Other attributes can be populated with another SELECT if needed.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 3. Purchase Order Created ---
LOOP AT lt_ekko INTO DATA(ls_ekko_created).
ls_event_log-purchaseordernumber = ls_ekko_created-ebeln.
ls_event_log-activityname = 'Purchase Order Created'.
CONVERT DATE ls_ekko_created-aedat TIME ls_ekko_created-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-vendorid = ls_ekko_created-lifnr.
ls_event_log-username = ls_ekko_created-ernam.
ls_event_log-totalnetamount = ls_ekko_created-rlwrt.
ls_event_log-purchaserequisitionnumber = ''. "Can be enriched later if needed
ls_event_log-requesteddeliverydate = ''. "Can be enriched from EKPO
ls_event_log-documenttype = ls_ekko_created-bsart.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 4. Purchase Order Approved (via Change Docs on Release Indicator) ---
SELECT h.objectid, h.udate, h.utime, h.username
FROM cdhdr AS h
INNER JOIN cdpos AS p ON h.objectclas = p.objectclas AND h.objectid = p.objectid AND h.changenr = p.changenr
WHERE h.objectclas = 'EINKBELEG'
AND p.tabname = 'EKKO'
AND p.fname = 'FRGKE'
AND p.value_new = 'R' "R for Released
AND h.objectid IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_po_approved).
LOOP AT lt_po_approved INTO DATA(ls_po_approved).
ls_event_log-purchaseordernumber = ls_po_approved-objectid.
ls_event_log-activityname = 'Purchase Order Approved'.
CONVERT DATE ls_po_approved-udate TIME ls_po_approved-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_po_approved-username.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 5. Purchase Order Sent to Vendor ---
SELECT n.objky, n.vstat, n.datvr, n.uhrvr, e.ernam
FROM nast AS n
INNER JOIN ekko AS e ON n.objky = e.ebeln
WHERE n.kappl = 'EF' "Application for Purchasing
AND n.kschl = '[Your PO Output Type]' "e.g. NEU
AND n.vstat = '1' "Successfully processed
AND n.objky IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_po_sent).
LOOP AT lt_po_sent INTO DATA(ls_po_sent).
ls_event_log-purchaseordernumber = ls_po_sent-objky.
ls_event_log-activityname = 'Purchase Order Sent to Vendor'.
CONVERT DATE ls_po_sent-datvr TIME ls_po_sent-uhrvr INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_po_sent-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 6. Purchase Order Changed ---
SELECT objectid, udate, utime, username FROM cdhdr
WHERE objectclas = 'EINKBELEG'
AND tcode IN ('ME22', 'ME22N')
AND objectid IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_po_changed).
LOOP AT lt_po_changed INTO DATA(ls_po_changed).
ls_event_log-purchaseordernumber = ls_po_changed-objectid.
ls_event_log-activityname = 'Purchase Order Changed'.
CONVERT DATE ls_po_changed-udate TIME ls_po_changed-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_po_changed-username.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 7. Goods Receipt Posted & 9. Goods Returned ---
SELECT e.ebeln, m.budat, m.cpudt, m.cputm, m.usnam, b.shkzg, b.bwart
FROM mkpf AS m
INNER JOIN mseg AS s ON m.mblnr = s.mblnr AND m.mjahr = s.mjahr
INNER JOIN t156 AS t ON s.bwart = t.bwart
INNER JOIN ekbe AS e ON s.ebeln = e.ebeln AND s.ebelp = e.ebelp AND s.mblnr = e.belnr AND s.mjahr = e.gjahr
WHERE e.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
AND e.bwart IN ('101', '102', '122', '123') "GR, GR Reversal, Return
INTO TABLE @DATA(lt_goods_mvmt).
LOOP AT lt_goods_mvmt INTO DATA(ls_goods_mvmt).
ls_event_log-purchaseordernumber = ls_goods_mvmt-ebeln.
IF ls_goods_mvmt-bwart = '101'.
ls_event_log-activityname = 'Goods Receipt Posted'.
ELSE.
ls_event_log-activityname = 'Goods Returned'.
ENDIF.
CONVERT DATE ls_goods_mvmt-cpudt TIME ls_goods_mvmt-cputm INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_goods_mvmt-usnam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 8. Services Confirmation Entered ---
SELECT h.erdat, h.erzeit, h.ernam, l.ebeln
FROM essr AS h
INNER JOIN esll AS l ON h.lblni = l.lblni
WHERE l.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_services).
LOOP AT lt_services INTO DATA(ls_services).
ls_event_log-purchaseordernumber = ls_services-ebeln.
ls_event_log-activityname = 'Services Confirmation Entered'.
CONVERT DATE ls_services-erdat TIME ls_services-erzeit INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_services-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 10. Invoice Received ---
SELECT r.ebeln, r.cpudt, r.cputm, r.usnam
FROM rbkp AS r
WHERE r.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_invoice_rcvd).
LOOP AT lt_invoice_rcvd INTO DATA(ls_invoice_rcvd).
ls_event_log-purchaseordernumber = ls_invoice_rcvd-ebeln.
ls_event_log-activityname = 'Invoice Received'.
CONVERT DATE ls_invoice_rcvd-cpudt TIME ls_invoice_rcvd-cputm INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_invoice_rcvd-usnam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 11. Invoice Paid ---
SELECT b.ebeln, s.augdt, s.augbl, b.usnam
FROM rbkp AS b
INNER JOIN bseg AS e ON b.belnr = e.belnr AND b.gjahr = e.gjahr
INNER JOIN bsak AS s ON e.bukrs = s.bukrs AND e.belnr = s.belnr AND e.gjahr = s.gjahr AND e.buzei = s.buzei
WHERE b.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
AND s.augdt IS NOT NULL
INTO TABLE @DATA(lt_invoice_paid).
LOOP AT lt_invoice_paid INTO DATA(ls_invoice_paid).
ls_event_log-purchaseordernumber = ls_invoice_paid-ebeln.
ls_event_log-activityname = 'Invoice Paid'.
CONVERT DATE ls_invoice_paid-augdt INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_invoice_paid-usnam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 12. Purchase Order Completed & 13. Purchase Order Deleted (via Change Docs) ---
SELECT h.objectid, h.udate, h.utime, h.username, p.fname
FROM cdhdr AS h
INNER JOIN cdpos AS p ON h.changenr = p.changenr
INNER JOIN ekpo AS ekpo ON h.objectid = |{ ekpo.ebeln }{ ekpo.ebelp }|
WHERE h.objectclas = 'EINKBELEG'
AND p.tabname = 'EKPO'
AND p.fname IN ('ELIKZ', 'EREKZ', 'LOEKZ')
AND p.value_new = 'X'
AND ekpo.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_po_status_change).
LOOP AT lt_po_status_change INTO DATA(ls_po_status_change).
ls_event_log-purchaseordernumber = substring( val = ls_po_status_change-objectid, off = 0, len = 10 ).
CASE ls_po_status_change-fname.
WHEN 'LOEKZ'.
ls_event_log-activityname = 'Purchase Order Deleted'.
WHEN 'ELIKZ' OR 'EREKZ'.
"This logic may need refinement to check if both are now set.
ls_event_log-activityname = 'Purchase Order Completed'.
ENDCASE.
CONVERT DATE ls_po_status_change-udate TIME ls_po_status_change-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_po_status_change-username.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- Final Output to CSV ---
CALL METHOD cl_gui_frontend_services=>gui_download
EXPORTING
filename = 'C:\temp\po_event_log.csv'
filetype = 'ASC'
CHANGING
data_tab = lt_event_log. Gotowi, by zacząć?
Ten szablon to dobry punkt wyjścia do analizy procesu za pomocą process mining. Wykorzystajcie dane z SAP S/4HANA, aby znaleźć możliwości usprawnień i już dziś poprawić proces od zakupu do płatności.
Usprawnijcie obsługę zamówień w P2P i skróćcie czas realizacji
Ograniczcie nieefektywne działania i skróćcie cykl obsługi zamówienia w P2P o 30%.
Nie trzeba podawać danych karty płatniczej. Konfiguracja zajmuje kilka minut.