Szablon danych dla procesu od zamówienia do płatności: obsługa zamówień sprzedaży
Szablon danych dla procesu od zamówienia do płatności: obsługa zamówień sprzedaży
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia
- Wskazówki dotyczące ekstrakcji danych z SAP ECC
Atrybuty procesu obsługi zamówień sprzedaży
| Nazwa | Opis | ||
|---|---|---|---|
| Zlecenie sprzedaży SalesOrder | Unikalny identyfikator dokumentu zlecenia sprzedaży, który służy jako główny identyfikator sprawy do śledzenia całego procesu od zamówienia do płatności. | ||
| Opis Zlecenie sprzedaży to centralny dokument procesu sprzedaży, który odzwierciedla zamówienie klienta na towary lub usługi. Zawiera wszystkie informacje potrzebne do obsługi zamówienia od początku do końca. W process mining ten atrybut służy jako identyfikator sprawy (Case ID). Każdy unikalny numer zlecenia sprzedaży odpowiada jednej instancji procesu od początku do końca. Analiza według zlecenia sprzedaży pozwala śledzić cały cykl jego realizacji, mierzyć czas trwania i wykrywać różnice w obsłudze poszczególnych zamówień klientów. Dlaczego to ważne To podstawowy klucz łączący wszystkie powiązane działania i zdarzenia, dzięki czemu można przeanalizować cały przebieg realizacji każdego zamówienia klienta. Skąd pobrać Pole VBELN w tabeli danych nagłówka dokumentu sprzedaży (VBAK). Przykłady 900001234590000123469000012347 | |||
| Czas rozpoczęcia StartTime | Znacznik czasu wskazujący, kiedy rozpoczęła się czynność lub wystąpiło zdarzenie. | ||
| Opis Czas rozpoczęcia, nazywany również znacznikiem czasu zdarzenia, określa dokładną datę i godzinę wystąpienia danej czynności. Może na przykład wskazywać, kiedy utworzono zlecenie sprzedaży, wydano towary lub zaksięgowano fakturę. Ten znacznik czasu jest podstawą wszystkich analiz czasowych w process mining. Służy do obliczania czasu między czynnościami, mierzenia całkowitego czasu trwania sprawy oraz wykrywania opóźnień i wąskich gardeł. Dokładne znaczniki czasu są niezbędne w dashboardach do analizy wyników, na przykład przy monitorowaniu terminowości dostaw i czasu realizacji zleceń. Dlaczego to ważne Ten atrybut jest niezbędny do obliczania miar wyników, takich jak czas trwania i czas cyklu, które pomagają wykrywać wąskie gardła. Skąd pobrać To atrybut złożony, zwykle wyznaczany przez połączenie pola daty (np. ERDAT) i pola godziny (np. ERZET) z różnych tabel SAP, takich jak VBAK (zlecenie sprzedaży), LIKP (dostawa) i VBRK (faktura). Przykłady 2023-04-15T09:00:12Z2023-04-16T14:30:00Z2023-04-20T11:22:45Z | |||
| Czynność Activity | Nazwa konkretnego kroku biznesowego lub zdarzenia, które wystąpiło w procesie obsługi zlecenia sprzedaży. | ||
| Opis Ten atrybut opisuje pojedynczy krok procesu od zamówienia do płatności, na przykład „Utworzono zlecenie sprzedaży”, „Utworzono dostawę” lub „Otrzymano płatność”. Czynności te służą do odtworzenia przebiegu procesu dla każdego zlecenia sprzedaży. Analiza kolejności i czasu trwania tych czynności stanowi podstawę process mining. Pozwala zobrazować mapę procesu, wykrywać wąskie gardła i warianty procesu oraz sprawdzać zgodność ze standardowym modelem. Czynności są zwykle wyznaczane na podstawie zdarzeń utworzenia dokumentów, zmian statusu lub kodów transakcji zapisanych w systemie. Dlaczego to ważne Czynności tworzą podstawę mapy procesu i pozwalają zobrazować oraz analizować jego przebieg, odstępstwa i wąskie gardła. Skąd pobrać To atrybut pochodny, zwykle tworzony podczas ekstrakcji danych przez przypisanie czytelnych nazw czynności do kodów transakcji SAP (T-Code), zmian statusu dokumentów (np. w tabelach VBUK, VBUP) lub dzienników zmian (tabele CDHDR, CDPOS). Przykłady Utworzono zamówienie sprzedażyUtworzono dostawęWydano towaryUtworzenie fakturyOtrzymanie płatności | |||
| Ostatnia aktualizacja danych LastDataUpdate | Znacznik czasu wskazujący, kiedy dane tego rekordu zostały ostatnio odświeżone z systemu źródłowego. | ||
| Opis Ten atrybut zapisuje datę i godzinę ostatniej ekstrakcji lub aktualizacji danych dla danego zdarzenia albo sprawy. Informuje, jak aktualne są analizowane dane. W dashboardach i raportach pozwala użytkownikom ocenić aktualność wniosków. Pomaga sprawdzić, czy analiza odzwierciedla bieżący stan operacji, czy opiera się na starszych danych, i odpowiednio ustawić oczekiwania dotyczące ich aktualności. Dlaczego to ważne Informuje użytkowników o aktualności danych, co ma znaczenie przy podejmowaniu terminowych i świadomych decyzji na podstawie analizy process mining. Skąd pobrać To atrybut metadanych uzupełniany przez narzędzie lub proces ekstrakcji danych podczas ich wczytywania. Nie jest przechowywany w źródłowych tabelach SAP. Przykłady 2024-06-10T05:00:00Z2024-06-11T05:00:00Z2024-06-12T05:00:00Z | |||
| System źródłowy SourceSystem | Określa system źródłowy, z którego pobrano dane. | ||
| Opis Ten atrybut wskazuje system źródłowy, na przykład nazwę konkretnej instancji SAP ECC lub numer klienta. Dostarcza kontekstu dla danych, szczególnie w środowiskach z wieloma systemami produkcyjnymi lub danymi ze starszych systemów. W analizie służy do filtrowania lub grupowania danych według źródła. Przydaje się zwłaszcza przy porównywaniu procesów w różnych systemach oraz podczas migracji, gdy trzeba sprawdzić integralność i spójność danych. Dlaczego to ważne Dostarcza niezbędnego kontekstu, szczególnie w środowiskach z wieloma systemami. Ułatwia porównywanie procesów i pozwala prześledzić pochodzenie danych. Skąd pobrać Wartość jest zwykle dodawana podczas ekstrakcji danych i często jest stała. Może oznaczać identyfikator systemu SAP (SAPSID) lub klienta (MANDT). Przykłady ECC_PROD_800SAP_ERP_EU1ECC_QAS_300 | |||
| Blokada dostawy DeliveryBlock | Kod wskazujący, czy zlecenie sprzedaży jest zablokowane do dostawy, co uniemożliwia utworzenie dokumentu dostawy. | ||
| Opis Blokada dostawy to status ustawiany na zleceniu sprzedaży, na poziomie nagłówka lub pozycji, który tymczasowo wstrzymuje proces przed etapem dostawy. Blokadę może ustawić użytkownik albo system, na przykład z powodu przekroczenia limitu kredytowego lub niekompletnych danych. Ten atrybut jest niezbędny w dashboardzie do analizy blokad i poprawek w zleceniach sprzedaży. Analiza częstotliwości, czasu trwania i przyczyn blokad dostaw pomaga wykrywać główne wąskie gardła w realizacji zleceń. Ograniczenie liczby blokad poprawia terminowość dostaw i skraca całkowity czas realizacji. Dlaczego to ważne Bezpośrednio wskazuje wąskie gardła w realizacji zleceń. Analiza przyczyn i częstotliwości blokad jest niezbędna do usprawnienia przepływu pracy. Skąd pobrać Pole LIFSK w tabeli danych nagłówka dokumentu sprzedaży (VBAK). Przykłady 0102Z1 | |||
| Numer klienta CustomerNumber | Unikalny identyfikator klienta, który złożył zlecenie sprzedaży. | ||
| Opis Ten atrybut oznacza odbiorcę faktury (Sold-to Party), czyli główne konto klienta powiązane ze zleceniem sprzedaży. Łączy transakcję z konkretnym klientem w danych podstawowych. Analiza według numeru klienta pozwala podzielić proces na segmenty i sprawdzić zachowania oraz wyniki dla poszczególnych klientów. Ułatwia ustalenie, którzy klienci mają najdłuższy czas realizacji, najwięcej poprawek lub najczęściej zmieniają zlecenia. To przydatne przy doskonaleniu zarządzania relacjami z klientami i poziomu obsługi. Dlaczego to ważne Umożliwia analizę z perspektywy klienta, pomaga wykrywać problemy procesowe dotyczące konkretnych klientów i mierzyć wyniki obsługi każdego z nich. Skąd pobrać Pole KUNNR w tabeli danych nagłówka dokumentu sprzedaży (VBAK). Przykłady 100234100567200112 | |||
| Numer materiału MaterialNumber | Unikalny identyfikator sprzedawanego produktu lub usługi. | ||
| Opis Numer materiału identyfikuje konkretną pozycję w wierszu zlecenia sprzedaży. Ponieważ jedno zlecenie może obejmować wiele materiałów, atrybut ten jest zwykle analizowany na poziomie pozycji. Analiza procesu według numeru materiału pomaga wykrywać problemy dotyczące konkretnych produktów. Może pokazać, czy wybrane produkty wiążą się z dłuższym czasem realizacji, częstszymi blokadami dostaw lub większą liczbą rozbieżności na fakturach. To przydatne przy zarządzaniu łańcuchem dostaw i produktami oraz usprawnianiu procesu dla różnych grup produktów. Dlaczego to ważne Umożliwia analizę procesu według produktów i wskazuje, które z nich wiążą się z nieefektywnością, taką jak opóźnienia, blokady lub poprawki. Skąd pobrać Pole MATNR w tabeli danych pozycji dokumentu sprzedaży (VBAP). Przykłady FG-1001-ARAW-205BSERV-INSTALL | |||
| Organizacja sprzedaży SalesOrganization | Jednostka organizacyjna odpowiedzialna za sprzedaż produktów lub usług. | ||
| Opis Organizacja sprzedaży to jednostka organizacyjna w SAP, która odzwierciedla strukturę firmy dostosowaną do potrzeb sprzedaży. Odpowiada za uzgadnianie warunków sprzedaży oraz dystrybucję towarów i usług. W process mining ten atrybut stanowi ważny wymiar analizy. Pozwala porównywać wyniki procesów, ich efektywność i zgodność w różnych jednostkach sprzedaży, regionach lub działach. Dzięki temu można wskazać dobre praktyki w jednostkach osiągających lepsze wyniki oraz obszary wymagające poprawy. Dlaczego to ważne Umożliwia porównywanie efektywności procesów i zgodności między jednostkami biznesowymi lub regionami. Skąd pobrać Pole VKORG w tabeli danych nagłówka dokumentu sprzedaży (VBAK). Przykłady 100025003100 | |||
| Przyczyna odrzucenia RejectionReason | Kod wskazujący przyczynę odrzucenia lub anulowania pozycji zlecenia sprzedaży. | ||
| Opis Przyczyna odrzucenia wyjaśnia, dlaczego zlecenie sprzedaży lub jego konkretna pozycja nie zostały zrealizowane. Powodem może być anulowanie przez klienta, brak produktu lub inna przyczyna biznesowa. Ten atrybut jest niezbędny w dashboardzie do analizy trendów anulowania zleceń sprzedaży. Analiza najczęstszych przyczyn odrzucenia pomaga ustalić źródła utraconej sprzedaży. Na tej podstawie można usprawnić zarządzanie zapasami, strategię cenową lub komunikację z klientami, aby ograniczyć liczbę anulowanych zleceń. Dlaczego to ważne Wyjaśnia przyczyny anulowania zleceń i umożliwia analizę źródłowych problemów, ograniczenie utraconej sprzedaży oraz poprawę dokładności prognoz. Skąd pobrać Pole ABGRU w tabeli danych pozycji dokumentu sprzedaży (VBAP). Przykłady 0215Z5 | |||
| Użytkownik User | Identyfikator użytkownika, który utworzył lub ostatnio zmienił dokument albo wykonał daną czynność. | ||
| Opis Ten atrybut wskazuje identyfikator użytkownika SAP odpowiedzialnego za dane zdarzenie w procesie. Może na przykład wskazywać pracownika działu sprzedaży, który utworzył zlecenie, lub pracownika magazynu, który zaksięgował wydanie towarów. Analiza według użytkownika pomaga ocenić rozkład obciążenia pracą, określić potrzeby szkoleniowe i wykryć różnice w sposobie wykonywania tych samych zadań. Jest przydatna w dashboardach dotyczących wyników pracy, zgodności i ręcznych interwencji. Dlaczego to ważne Pokazuje wyniki pracy i obciążenie zasobów, pomaga wykrywać odstępstwa w procesie związane z konkretnymi użytkownikami oraz wspiera analizę zgodności i automatyzacji. Skąd pobrać Występuje w wielu tabelach nagłówkowych SAP jako pole „Utworzył” (ERNAM) lub „Zmienił” (AENAM), na przykład w tabelach VBAK, LIKP i VBRK. Przykłady CBURKEJSMITHRWILLIAMS | |||
| Wartość netto NetAmount | Łączna wartość zlecenia sprzedaży bez podatków i rabatów, na poziomie nagłówka dokumentu. | ||
| Opis Wartość netto określa wartość pieniężną zlecenia sprzedaży. Jest to miara finansowa przypisana do każdej instancji procesu. Atrybut ten jest przydatny w process mining opartym na wartości. Pozwala ustalać priorytety działań usprawniających, koncentrując się na zleceniach o wysokiej wartości. Analitycy mogą powiązać problemy procesowe, takie jak opóźnienia lub poprawki, z ich skutkami finansowymi i lepiej uzasadnić potrzebę zmian. Można na przykład sprawdzić, czy zlecenia o wysokiej wartości są realizowane sprawniej niż zlecenia o niższej wartości. Dlaczego to ważne Umożliwia analizę według wartości i pomaga skupić działania usprawniające na zleceniach o największym wpływie finansowym na firmę. Skąd pobrać Pole NETWR w tabeli danych nagłówka dokumentu sprzedaży (VBAK). Przykłady 1500.0012550.75850.50 | |||
| Czy dostarczono na czas IsOnTimeDelivery | Wartość logiczna wskazująca, czy towary wysłano w potwierdzonym terminie lub wcześniej. | ||
| Opis Ten obliczany atrybut porównuje faktyczną datę wydania towarów z atrybutem „ConfirmedDeliveryDate” dla zlecenia sprzedaży. Jeśli towary wydano w potwierdzonym terminie lub wcześniej, wartość jest ustawiana na true, w przeciwnym razie na false. Atrybut ten ułatwia tworzenie dashboardu do analizy terminowości dostaw i obliczanie wskaźnika dostaw na czas. Pozwala łatwo agregować i wizualizować wyniki bez konieczności każdorazowego porównywania dat w analizie lub na wykresie. Zapewnia czytelny, szybki obraz terminowości dostaw. Dlaczego to ważne Zapewnia prostą i czytelną miarę terminowości dostaw, ułatwiając obliczenie ogólnego wskaźnika dostaw na czas. Skąd pobrać To atrybut obliczany. Logika porównuje znacznik czasu czynności „Wydano towary” z wartością atrybutu „ConfirmedDeliveryDate”. Przykłady truefalse | |||
| Czy wymagało poprawek IsRework | Wartość logiczna wskazująca, czy po utworzeniu zlecenia sprzedaży wprowadzono w nim istotne zmiany lub wykonano dodatkowe prace. | ||
| Opis Ten obliczany atrybut wskazuje instancje procesu, w których wystąpiły poprawki, na przykład jedna lub więcej czynności „Zmieniono zlecenie sprzedaży”. Szczegółowe kryteria, takie jak zmiana ceny, ilości lub daty dostawy, ustala się podczas konfiguracji projektu. Atrybut ten jest przydatny w dashboardzie do analizy poprawek i częstotliwości zmian w zleceniach sprzedaży oraz we wskaźniku poprawek. Ułatwia filtrowanie i porównywanie zleceń zrealizowanych bez dodatkowych zmian z tymi, które wymagały ręcznej interwencji. Pozwala ocenić wpływ poprawek na czas realizacji i koszty. Dlaczego to ważne Pozwala bezpośrednio mierzyć częstotliwość poprawek, analizować ich przyczyny oraz oceniać wpływ na efektywność procesu i czas realizacji. Skąd pobrać To atrybut obliczany na podstawie dziennika zdarzeń. Logika sprawdza, czy wystąpiły czynności „Zmieniono zlecenie sprzedaży” lub określone zdarzenia zmian z tabel CDHDR/CDPOS. Przykłady truefalse | |||
| Potwierdzona data dostawy ConfirmedDeliveryDate | Data dostawy towarów lub usług potwierdzona klientowi. | ||
| Opis To uzgodniona z klientem data dostawy, ustalona na podstawie dostępności materiałów i harmonogramu. Stanowi punkt odniesienia przy ocenie terminowości dostaw. Atrybut ten stanowi podstawę dashboardu do analizy terminowości dostaw oraz wskaźnika dostaw na czas. Porównanie potwierdzonej daty dostawy z faktyczną datą wydania towarów pozwala ustalić, czy zlecenie zrealizowano w terminie, przed terminem czy z opóźnieniem. Jest to podstawowa miara niezawodności łańcucha dostaw i zadowolenia klientów. Dlaczego to ważne To punkt odniesienia przy ocenie terminowości dostaw, ważnego KPI z punktu widzenia zadowolenia klientów i efektywności łańcucha dostaw. Skąd pobrać Pole EDATU w tabeli harmonogramu pozycji dokumentu sprzedaży (VBEP). Przykłady 2023-05-102023-06-202023-07-01 | |||
| Status kontroli zdolności kredytowej CreditCheckStatus | Wskazuje status kontroli zdolności kredytowej dokumentu sprzedaży. | ||
| Opis Ten atrybut pokazuje wynik automatycznej lub ręcznej kontroli zdolności kredytowej zlecenia sprzedaży. Typowe statusy to „Zatwierdzono”, „Odrzucono” i „Zablokowano”. Atrybut ten jest przydatny w dashboardzie do analizy czasu kontroli zdolności kredytowej. Opóźnienia lub blokady na tym etapie mogą znacząco wydłużyć cały czas realizacji zlecenia. Analiza statusu pomaga ocenić sprawność procesu zarządzania kredytem i jego wpływ na tempo sprzedaży. Dlaczego to ważne Bezpośrednio wpływa na szybkość obsługi zleceń. Analiza statusu pomaga wykrywać wąskie gardła w zarządzaniu kredytem, które opóźniają realizację zleceń. Skąd pobrać Występuje w tabeli statusów nagłówka dokumentu sprzedaży (VBUK) lub bezpośrednio w tabeli VBAK jako pole statusu kredytowego (np. CMGST). Przykłady ABD | |||
| Warunki wysyłki ShippingConditions | Określają ogólny sposób dostarczenia towarów do klienta. | ||
| Opis Warunki wysyłki określają sposób dostarczenia zlecenia, na przykład standardowy, ekspresowy lub odbiór osobisty. Są uzgadniane z klientem i wpływają na planowanie logistyki. Atrybut ten służy do analizy efektywności i kosztów metod wysyłki. Podział procesu według warunków wysyłki pozwala sprawdzić, czy niektóre metody częściej wiążą się z opóźnieniami lub dłuższym czasem realizacji. Dane te pomagają usprawnić logistykę i lepiej informować klientów o terminach dostaw. Dlaczego to ważne Umożliwia analizę wyników logistyki i pomaga ustalić, czy wybrane metody wysyłki wiążą się z opóźnieniami lub większą efektywnością. Skąd pobrać Pole VSBED w tabeli danych nagłówka dokumentu sprzedaży (VBAK). Przykłady 011020 | |||
Działania w procesie obsługi zamówień sprzedaży
| Działanie | Opis | ||
|---|---|---|---|
| Otrzymanie płatności | Zdarzenie oznacza otrzymanie płatności od klienta i przypisanie jej do faktury, co rozlicza otwartą pozycję należności. Jest to zdarzenie księgowe, wnioskowane na podstawie rozliczenia dokumentu finansowego. | ||
| Dlaczego to ważne To ostatni etap uzyskania środków ze sprzedaży. Wyznacza koniec okresu mierzonego jako czas od wystawienia faktury do otrzymania płatności oraz całkowity czas realizacji zlecenia sprzedaży. Skąd pobrać Zdarzenie jest wnioskowane na podstawie informacji o rozliczeniu w tabeli BSEG dla pozycji klienta. Jeśli pola BSEG-AUGBL (dokument rozliczeniowy) i BSEG-AUGDT (data rozliczenia) są wypełnione, oznacza to otrzymanie płatności. Rejestrowanie Zdarzenie jest wnioskowane na podstawie wypełnienia pola daty rozliczenia (AUGDT) w tabeli BSEG dla pozycji należności. Typ zdarzenia inferred | |||
| Potwierdzono zamówienie | Ta czynność oznacza, że zamówienie sprzedaży przeszło wszystkie wstępne kontrole i zostało zatwierdzone do realizacji. Zwykle wnioskuje się o tym, gdy zamówienie nie jest już zablokowane, a jego pozycje harmonogramu mają potwierdzone ilości. | ||
| Dlaczego to ważne To ważny etap, który oddziela wprowadzenie zamówienia od jego realizacji. Stanowi punkt początkowy pomiaru czasu realizacji i terminowości dostaw. Skąd pobrać Zdarzenie można ustalić, gdy pozycje harmonogramu w tabeli VBEP mają potwierdzoną ilość (BMENG > 0), a zamówienie nie jest zablokowane do dostawy, na przykład pole VBUK-LIFSK jest puste. Rejestrowanie Zdarzenie jest ustalane na podstawie potwierdzenia pozycji harmonogramu (VBEP-BMENG > 0) i usunięcia blokad na poziomie nagłówka. Typ zdarzenia inferred | |||
| Utworzenie faktury | Oznacza utworzenie faktury dla klienta lub dokumentu rozliczeniowego. To jawne zdarzenie, które tworzy nowy dokument w systemie i rozpoczyna etap płatności procesu. | ||
| Dlaczego to ważne To ważny punkt procesu, od którego liczy się czas od wystawienia faktury do otrzymania płatności. Opóźnienia w fakturowaniu bezpośrednio wpływają na przepływy pieniężne. Skąd pobrać Zdarzenie jest rejestrowane w tabeli VBRK (dane nagłówka dokumentu rozliczeniowego) na podstawie daty utworzenia dokumentu (ERDAT). Powiązanie ze zleceniem sprzedaży lub dostawą znajduje się w tabeli VBFA. Rejestrowanie Zdarzenie jest określane na podstawie znacznika czasu utworzenia (ERDAT) w tabeli VBRK. Typ zdarzenia explicit | |||
| Utworzono zamówienie sprzedaży | Oznacza utworzenie nowego dokumentu zamówienia sprzedaży. To jawne zdarzenie jest rejestrowane, gdy użytkownik zapisuje nowe zamówienie, zwykle za pomocą transakcji VA01 w SAP. | ||
| Dlaczego to ważne To główne zdarzenie rozpoczynające proces Order to Cash. Analiza czasu jego wystąpienia ma zasadnicze znaczenie dla pomiaru całkowitego czasu cyklu i liczby przyjmowanych zamówień. Skąd pobrać Zdarzenie jest rejestrowane w tabeli VBAK (dane nagłówka dokumentu sprzedaży) na podstawie daty utworzenia (ERDAT) i godziny (ERZET). Kod transakcji jest zapisany w polu VBAK-TCODE. Rejestrowanie Zdarzenie oparte na znaczniku czasu utworzenia (ERDAT, ERZET) w tabeli VBAK. Typ zdarzenia explicit | |||
| Wydano towary | To ważne zdarzenie oznacza przeniesienie własności towarów i ich oficjalne opuszczenie magazynu. Jest to jawne księgowanie finansowe, które tworzy dokument materiałowy i aktualizuje stan zapasów. | ||
| Dlaczego to ważne To zdarzenie oznacza wysyłkę i jest ważnym etapem pomiaru terminowości dostaw oraz czasu realizacji. Uruchamia aktualizacje finansowe i stanowi punkt, po którym nie można już cofnąć fizycznej realizacji zamówienia. Skąd pobrać Utworzenie dokumentu materiałowego (MKPF/MSEG) z typem ruchu wydania towarów, na przykład 601, powiązanego z dokumentem dostawy. Rejestrowanie Utworzenie dokumentu materiałowego (MKPF/MSEG) z typem ruchu wydania towarów, powiązanego z dostawą. Typ zdarzenia explicit | |||
| Zamknięcie pozycji zlecenia | To zdarzenie oznacza ostateczne zamknięcie pozycji zlecenia sprzedaży. Wskazuje, że pozycja została w pełni dostarczona i zafakturowana, a jej realizację uznano za zakończoną. Zdarzenie jest wnioskowane na podstawie ogólnego statusu pozycji. | ||
| Dlaczego to ważne To pomyślne zakończenie procesu. Analiza momentu zamknięcia pozycji pozwala określić czas realizacji całego procesu i wykryć zlecenia, które niepotrzebnie pozostają otwarte. Skąd pobrać Zdarzenie jest wnioskowane na podstawie ogólnego statusu pozycji w tabeli VBUP (status pozycji dokumentu sprzedaży). Gdy pole VBUP-GBSTA ma wartość „C” (przetworzono w całości), pozycja jest zamknięta. Rejestrowanie Zdarzenie jest wnioskowane na podstawie zmiany statusu pozycji (VBUP-GBSTA) na „C” (przetworzono w całości). Typ zdarzenia inferred | |||
| Anulowanie faktury | Oznacza odwrócenie wcześniej utworzonego dokumentu rozliczeniowego. To jawna transakcja, która tworzy nowy dokument anulujący, kompensujący dokument pierwotny. | ||
| Dlaczego to ważne Śledzenie anulowanych faktur pomaga wykrywać problemy z cenami, rozbieżności w dostawach i błędy danych. Wspiera to analizę wskaźnika rozbieżności na fakturach. Skąd pobrać Jawne zdarzenie rejestrowane przy utworzeniu dokumentu anulującego rozliczenie (VBRK-VBTYP = 'N' lub 'O'). Numer pierwotnej faktury znajduje się w polu VBRK-SFAKN. Rejestrowanie Utworzenie dokumentu anulującego w tabeli VBRK z odwołaniem do pierwotnej faktury. Typ zdarzenia explicit | |||
| Anulowanie zlecenia | Oznacza anulowanie zlecenia sprzedaży przed jego realizacją. Zwykle jest rejestrowane przez przypisanie przyczyny odrzucenia do wszystkich odpowiednich pozycji zlecenia. | ||
| Dlaczego to ważne To niepomyślne zakończenie procesu, które bezpośrednio wspiera analizę wskaźnika anulowania zleceń. Informacje o tym, kiedy i dlaczego zlecenia są anulowane, pomagają wykrywać problemy w procesie sprzedaży. Skąd pobrać Zdarzenie jest wnioskowane na podstawie wypełnienia pola VBAP-ABGRU (przyczyna odrzucenia) dla wszystkich aktywnych pozycji zlecenia sprzedaży. Datę zmiany można znaleźć w tabelach CDHDR/CDPOS. Rejestrowanie Zdarzenie jest wnioskowane na podstawie wypełnienia pola „Przyczyna odrzucenia” (VBAP-ABGRU) dla wszystkich pozycji. Typ zdarzenia inferred | |||
| Potwierdzono odbiór dostawy | To zdarzenie oznacza potwierdzenie, że klient otrzymał towary. Jest rejestrowane w systemie po zapisaniu potwierdzenia dostawy, często wraz ze zmianą statusu dokumentu dostawy. | ||
| Dlaczego to ważne Zdarzenie zawiera faktyczną datę dostawy, niezbędną do dokładnego obliczenia wskaźnika dostaw na czas w odniesieniu do obiecanej daty. Skąd pobrać Zdarzenie jest wnioskowane na podstawie statusu potwierdzenia dostawy (VBUK-PODAT) ustawionego na „C” (potwierdzono). Data potwierdzenia jest zapisywana w polu VLPOD-PODAT. Nie zawsze jest to wdrożone. Rejestrowanie Zdarzenie jest wnioskowane na podstawie zmiany statusu POD dostawy (VBUK-PODAT) lub wpisu w tabeli VLPOD. Typ zdarzenia inferred | |||
| Przeprowadzono weryfikację zdolności kredytowej | Oznacza zakończenie automatycznej lub ręcznej weryfikacji zdolności kredytowej klienta dla zamówienia sprzedaży. Zwykle wnioskuje się o tym na podstawie zmiany ogólnego statusu kredytowego dokumentu. | ||
| Dlaczego to ważne Weryfikacja zdolności kredytowej często stanowi wąskie gardło. Pomiar czasu jej trwania jest niezbędny do analizy czasu weryfikacji zdolności kredytowej i przyspieszenia obsługi zamówień. Skąd pobrać Zdarzenie jest ustalane na podstawie pól statusu kredytowego w tabeli VBUK (status nagłówka dokumentu sprzedaży). Zmiana VBUK-CMGST z zablokowanego na zwolniony oznacza wykonanie tej czynności. Rejestrowanie Zdarzenie jest ustalane na podstawie zmiany ogólnego pola statusu kredytowego (VBUK-CMGST). Typ zdarzenia inferred | |||
| Ustawiono blokadę dostawy | Oznacza nałożenie blokady dostawy na zamówienie sprzedaży, która uniemożliwia utworzenie dokumentu dostawy. Zdarzenie można odczytać bezpośrednio z dzienników zmian lub ustalić na podstawie tabel statusów. | ||
| Dlaczego to ważne Ta czynność bezpośrednio wiąże się z KPI „Odsetek zablokowanych zamówień sprzedaży”. Ustalenie przyczyn i częstotliwości blokad pomaga wykryć źródła opóźnień w realizacji. Skąd pobrać Informacje można znaleźć w dziennikach zmian (CDHDR/CDPOS) dla pola VBAK-LIFSK. Można też ustalić zdarzenie na podstawie momentu wypełnienia pola VBAK-LIFSK. Rejestrowanie Zdarzenie na podstawie dokumentów zmian pola VBAK-LIFSK lub VBAP-LIFSP. Typ zdarzenia explicit | |||
| Utworzono dostawę | To zdarzenie oznacza utworzenie dokumentu dostawy wychodzącej, który zleca magazynowi rozpoczęcie kompletowania i wysyłki. Jest to jawne zdarzenie rejestrowane w przepływie dokumentów. | ||
| Dlaczego to ważne To pierwszy etap fizycznej realizacji zamówienia. Czas między potwierdzeniem zamówienia a utworzeniem dostawy pokazuje, jak szybko rozpoczyna się proces logistyczny. Skąd pobrać Utworzenie rekordu w tabeli LIKP (dane nagłówka dokumentu dostawy SD). Powiązanie z zamówieniem sprzedaży jest przechowywane w tabeli przepływu dokumentów VBFA. Rejestrowanie Zdarzenie oparte na znaczniku czasu utworzenia w tabeli LIKP, powiązane za pośrednictwem tabeli VBFA. Typ zdarzenia explicit | |||
| Zakończono kompletowanie | Oznacza fizyczne pobranie z magazynu wszystkich pozycji dostawy. Jeśli używany jest Warehouse Management (WM), zdarzenie można ustalić na podstawie statusu zlecenia transportowego. | ||
| Dlaczego to ważne Analiza czasu kompletowania pomaga usprawnić operacje magazynowe. Opóźnienia na tym etapie bezpośrednio wpływają na czas wysyłki i cały cykl realizacji zamówienia. Skąd pobrać Zdarzenie jest ustalane na podstawie zmiany statusu kompletowania pozycji dostawy w polu LIPS-KOSTA na „C” (skompletowano w całości). Jeśli aktywny jest WM, można je ustalić na podstawie potwierdzenia zlecenia transportowego (tabele LTAK/LTAP). Rejestrowanie Zdarzenie jest ustalane na podstawie zmiany statusu kompletowania (LIPS-KOSTA) lub potwierdzenia zlecenia transportowego WM. Typ zdarzenia inferred | |||
| Zmieniono zamówienie sprzedaży | Oznacza zmianę istniejącego zamówienia sprzedaży po jego utworzeniu. Zmiany są rejestrowane w dedykowanych tabelach dziennika zmian (CDHDR, CDPOS), gdy modyfikowane są na przykład ilość, cena lub daty. | ||
| Dlaczego to ważne Śledzenie zmian pomaga wykrywać poprawki, niestabilność procesu i problemy z jakością danych. Częste zmiany mogą wskazywać na błędy podczas wprowadzania zamówienia, które prowadzą do opóźnień. Skąd pobrać Dane pochodzą z tabel dokumentów zmian CDHDR (nagłówek) i CDPOS (pozycja) dla OBJECTCLAS = 'VERKBELEG'. Można ustalić znacznik czasu i zmienione pole. Rejestrowanie Zdarzenie na podstawie tabel dokumentów zmian (CDHDR, CDPOS) dotyczących dokumentów sprzedaży. Typ zdarzenia explicit | |||
Instrukcje ekstrakcji danych
Kroki
- Opracuj program: W transakcji SE38 lub SE80 utwórz nowy wykonywalny program ABAP. Będzie on zawierał całą logikę ekstrakcji.
- Zdefiniuj ekran wyboru: Dodaj ekran wyboru umożliwiający filtrowanie danych. Uwzględnij parametry daty utworzenia dokumentu sprzedaży (VBAK-ERDAT), organizacji sprzedaży (VBAK-VKORG) i typu dokumentu sprzedaży (VBAK-AUART). Dzięki temu ekstrakcję będzie można ponownie wykorzystać i łatwo kontrolować.
- Zadeklaruj dane: Zdefiniuj tabele wewnętrzne i struktury do przechowywania danych z różnych tabel SAP, na przykład VBAK, VBAP, VBFA, CDHDR, CDPOS, VBRK i BSAD. Zdefiniuj też strukturę wynikową dziennika zdarzeń, zgodną z wymaganymi atrybutami.
- Wybierz zamówienia sprzedaży: Napisz początkową instrukcję SELECT, która pobierze nagłówki zamówień sprzedaży (VBAK) i ich pozycje (VBAP) na podstawie danych z ekranu wyboru. Powstanie w ten sposób podstawowy zbiór spraw do analizy.
- Wyodrębnij zdarzenie „Utworzenie zamówienia”: Przejdź przez wybrane rekordy VBAK. Dla każdego wypełnij strukturę dziennika zdarzeń działaniem „Utworzono zamówienie sprzedaży”, używając VBAK-ERDAT i VBAK-ERZET jako StartTime.
- Wyodrębnij zdarzenia z dziennika zmian: Wybierz z CDHDR i CDPOS rekordy, w których OBJECTCLAS ma wartość „VERKBELEG” i które dotyczą wybranych zamówień sprzedaży. Przejdź przez wyniki, aby znaleźć zmiany konkretnych pól. Na przykład zmiana VBAK-LIFSK oznacza „Ustawiono blokadę dostawy”, a zmiana VBUK-CMGST oznacza „Przeprowadzono kontrolę kredytową”. Inne istotne zmiany można zapisać jako „Zmieniono zamówienie sprzedaży”.
- Wyodrębnij dane o przepływie dokumentów: Dla wybranych zamówień sprzedaży odpytaj tabelę przepływu dokumentów (VBFA). Łączy ona zamówienia z kolejnymi dokumentami, takimi jak dostawy, ruchy towarów i faktury. Wybierz wszystkie powiązane dokumenty do dalszego przetwarzania.
- Wyodrębnij zdarzenia dostawy i realizacji: Użyj numerów dokumentów dostawy z VBFA, aby odpytując LIKP i LIPS, znaleźć zdarzenia „Utworzono dostawę”. Odpytaj MKPF i MSEG o dokumenty wydania towaru (rodzaj ruchu „601”), aby zarejestrować zdarzenie „Wydano towary”. Jeśli aktywne jest Warehouse Management, odpytaj LTAK i LTAP, aby ustalić czas potwierdzenia ostatniej pozycji zlecenia przesunięcia i określić moment „Zakończono kompletację”. Sprawdź status nagłówka dostawy VBUK-PODAT, aby zarejestrować „Potwierdzono dostawę”.
- Wyodrębnij zdarzenia fakturowania i płatności: Użyj numerów dokumentów rozliczeniowych z VBFA i odpytaj VBRK oraz VBRP, aby zarejestrować zdarzenia „Utworzono fakturę” i „Anulowano fakturę” (gdy VBRK-FKSTO = „X”). Aby znaleźć zdarzenie „Otrzymano płatność”, połącz fakturę z VBRK z dokumentem księgowym w BKPF, a następnie znajdź dokument rozliczeniowy i datę rozliczenia w BSAD.
- Wyodrębnij zdarzenia na podstawie statusów: Użyj tabel statusów VBUP (status pozycji) i VBUK (status nagłówka), aby określić zdarzenia biznesowe. Na przykład pozycję uznaje się za „Zamkniętą pozycję zamówienia”, gdy VBUP-GBSTA ma wartość „C”. Zamówienie uznaje się za „Anulowane”, gdy dla wszystkich właściwych pozycji ustawiono „Przyczynę odrzucenia” (VBAP-ABGRU).
- Połącz i sformatuj dane: Połącz wszystkie zarejestrowane zdarzenia w jednej końcowej tabeli wewnętrznej. Upewnij się, że dla każdego rekordu zdarzenia prawidłowo wypełniono wszystkie atrybuty, takie jak SalesOrder, Activity, StartTime i User. Dodaj znaczniki czasu SourceSystem i LastDataUpdate.
- Utwórz plik wynikowy: Użyj modułu funkcyjnego GUI_DOWNLOAD lub metody cl_gui_frontend_services=>gui_download, aby wyeksportować końcową tabelę wewnętrzną do pliku CSV na komputerze użytkownika. Zapisz plik w kodowaniu UTF-8.
Konfiguracja
- Wymagania wstępne: Uprawnienia programisty ABAP, na przykład dostęp do transakcji SE38, oraz uprawnienia do odczytu wszystkich wymaganych tabel SAP, w tym VBAK, VBAP, CDHDR, CDPOS, VBFA, LIKP, LIPS, VBRK, VBRP, MKPF, MSEG i BSAD.
- Parametry wyboru: Program musi zawierać ekran wyboru z parametrami filtrowania. Najważniejsze z nich to:
- Zakres dat: Obowiązkowy zakres dat utworzenia zamówień sprzedaży (VBAK-ERDAT). Warto zacząć od ostatnich 3–6 miesięcy, aby utrzymać zbiór danych w rozsądnych granicach.
- Organizacja sprzedaży: Filtr VBAK-VKORG pozwala ograniczyć analizę do wybranych jednostek biznesowych.
- Typ dokumentu sprzedaży: Filtr VBAK-AUART pozwala uwzględnić tylko właściwe typy zamówień, na przykład standardowe, i wykluczyć pozostałe, takie jak oferty i zwroty.
- Wydajność: Ekstrakcja dużych ilości danych z tabel dziennika zmian (CDHDR, CDPOS) i przepływu dokumentów (VBFA) może działać bardzo wolno. W klauzulach WHERE warto używać pól indeksowanych. Przy bardzo dużych ekstrakcjach należy zaplanować uruchomienie programu w tle poza godzinami szczytu za pomocą transakcji SM36.
- Aktywacja dziennika zmian: Ta metoda korzysta z funkcji dokumentów zmian SAP. Należy sprawdzić, czy rejestrowanie zmian jest włączone dla ważnych elementów danych, takich jak LIFSK, CMGST i ABGRU. Można to zweryfikować w transakcji SCDO dla obiektu VERKBELEG.
Przykładowe zapytanie abap
REPORT Z_O2C_PM_EXTRACTOR.
*&---------------------------------------------------------------------*
*& Data Declarations
*&---------------------------------------------------------------------*
TABLES: vbak.
TYPES: BEGIN OF ty_event_log,
salesorder TYPE vbeln_va,
activity TYPE string,
starttime TYPE string,
sourcesystem TYPE logsys,
lastdataupdate TYPE string,
user TYPE ernam,
customernumber TYPE kunnr,
salesorganization TYPE vkorg,
netamount TYPE netwr,
materialnumber TYPE matnr,
deliveryblock TYPE lifsk,
rejectionreason TYPE abgru,
salesordercycletime TYPE string, " Placeholder for calculation
END OF ty_event_log.
DATA: gt_event_log TYPE TABLE OF ty_event_log.
DATA: gs_event_log TYPE ty_event_log.
DATA: gv_sysid TYPE logsys.
DATA: gv_last_update TYPE string.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_erdat FOR vbak-erdat OBLIGATORY,
s_vkorg FOR vbak-vkorg,
s_auart FOR vbak-auart.
PARAMETERS: p_file TYPE rlgrap-filename OBLIGATORY DEFAULT 'C:\temp\o2c_event_log.csv'.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
CALL FUNCTION 'OWN_LOGICAL_SYSTEM_GET'
IMPORTING
own_logical_system = gv_sysid.
CONCATENATE sy-datum sy-uzeit INTO gv_last_update.
PERFORM get_base_data.
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*& Form get_base_data
*&---------------------------------------------------------------------*
FORM get_base_data.
TYPES: BEGIN OF ty_order_item,
vbeln TYPE vbeln_va,
posnr TYPE posnr_va,
erdat TYPE erdat,
erzet TYPE erzet,
ernam TYPE ernam,
kunnr TYPE kunnr,
vkorg TYPE vkorg,
netwr TYPE netwr_ak,
matnr TYPE matnr,
lifsk TYPE lifsk,
abgru TYPE abgru,
END OF ty_order_item.
DATA: lt_order_items TYPE TABLE OF ty_order_item.
SELECT h~vbeln i~posnr h~erdat h~erzet h~ernam h~kunnr h~vkorg h~netwr i~matnr h~lifsk i~abgru
INTO TABLE lt_order_items
FROM vbak AS h
INNER JOIN vbap AS i ON h~vbeln = i~vbeln
WHERE h~erdat IN s_erdat
AND h~vkorg IN s_vkorg
AND h~auart IN s_auart.
CHECK sy-subrc = 0.
DATA(lt_vbeln_range) = VALUE rsdsselopt_t(
FOR <fs_item> IN lt_order_items WHERE ( vbeln = <fs_item>-vbeln )
( sign = 'I' option = 'EQ' low = <fs_item>-vbeln ) ).
SORT lt_vbeln_range BY low.
DELETE ADJACENT DUPLICATES FROM lt_vbeln_range COMPARING low.
PERFORM extract_order_created USING lt_order_items.
PERFORM extract_changes USING lt_vbeln_range lt_order_items.
PERFORM extract_doc_flow_events USING lt_vbeln_range lt_order_items.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_order_created
*&---------------------------------------------------------------------*
FORM extract_order_created USING it_order_items TYPE ANY TABLE.
FIELD-SYMBOLS: <fs_item> TYPE any.
DATA: lt_unique_orders TYPE HASHED TABLE OF vbeln_va WITH UNIQUE KEY table_line.
lt_unique_orders = VALUE #( FOR <order> IN it_order_items ( CONV vbeln_va( <order>-vbeln ) ) ).
LOOP AT it_order_items ASSIGNING <fs_item> WHERE table_line IN lt_unique_orders.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_item>-vbeln.
gs_event_log-activity = 'Sales Order Created'.
CONCATENATE <fs_item>-erdat <fs_item>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_item>-ernam.
gs_event_log-customernumber = <fs_item>-kunnr.
gs_event_log-salesorganization = <fs_item>-vkorg.
gs_event_log-netamount = <fs_item>-netwr.
APPEND gs_event_log TO gt_event_log.
DELETE lt_unique_orders WHERE table_line = <fs_item>-vbeln.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_changes
*&---------------------------------------------------------------------*
FORM extract_changes USING it_vbeln_range TYPE rsdsselopt_t it_order_items TYPE ANY TABLE.
DATA: lt_cdhdr TYPE TABLE OF cdhdr,
lt_cdpos TYPE TABLE OF cdpos.
SELECT * INTO TABLE lt_cdhdr FROM cdhdr
WHERE objectclas = 'VERKBELEG'
AND objectid IN it_vbeln_range
AND tcode = 'VA02'.
IF sy-subrc = 0.
SELECT * INTO TABLE lt_cdpos FROM cdpos
FOR ALL ENTRIES IN lt_cdhdr
WHERE objectclas = lt_cdhdr-objectclas
AND objectid = lt_cdhdr-objectid
AND changenr = lt_cdhdr-changenr.
ENDIF.
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
DATA(lv_order_info) = REF #( it_order_items[ vbeln = <fs_cdhdr>-objectid ] ).
IF lv_order_info IS NOT BOUND. CONTINUE. ENDIF.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_cdhdr>-objectid.
gs_event_log-user = <fs_cdhdr>-username.
CONCATENATE <fs_cdhdr>-udate <fs_cdhdr>-utime INTO gs_event_log-starttime.
gs_event_log-customernumber = lv_order_info->kunnr.
gs_event_log-salesorganization = lv_order_info->vkorg.
gs_event_log-netamount = lv_order_info->netwr.
" Generic Change Event
gs_event_log-activity = 'Sales Order Changed'.
APPEND gs_event_log TO gt_event_log.
LOOP AT lt_cdpos ASSIGNING FIELD-SYMBOL(<fs_cdpos>)
WHERE objectclas = <fs_cdhdr>-objectclas
AND objectid = <fs_cdhdr>-objectid
AND changenr = <fs_cdhdr>-changenr.
CASE <fs_cdpos>-fname.
WHEN 'LIFSK'. " Delivery Block
gs_event_log-activity = 'Delivery Block Set'.
gs_event_log-deliveryblock = <fs_cdpos>-value_new.
APPEND gs_event_log TO gt_event_log.
WHEN 'CMGST'. " Credit Status
IF <fs_cdpos>-value_new = 'B'. " B = Credit Check OK
gs_event_log-activity = 'Credit Check Performed'.
APPEND gs_event_log TO gt_event_log.
ENDIF.
WHEN 'ABGRU'. " Rejection Reason
IF <fs_cdpos>-value_new IS NOT INITIAL.
gs_event_log-activity = 'Order Cancelled'.
gs_event_log-rejectionreason = <fs_cdpos>-value_new.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDCASE.
ENDLOOP.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_doc_flow_events
*&---------------------------------------------------------------------*
FORM extract_doc_flow_events USING it_vbeln_range TYPE rsdsselopt_t it_order_items TYPE ANY TABLE.
DATA: lt_vbfa TYPE TABLE OF vbfa,
lt_vbrk TYPE TABLE OF vbrk,
lt_likp TYPE TABLE OF likp,
lt_mseg TYPE TABLE OF mseg,
lt_bsad TYPE TABLE OF bsad,
lt_vbup TYPE TABLE OF vbup.
SELECT * INTO TABLE lt_vbfa FROM vbfa
WHERE vbelv IN it_vbeln_range
AND ( vbtyp_n = 'J' " Delivery
OR vbtyp_n = 'M' " Invoice
OR vbtyp_n = 'N' " Invoice Cancellation
OR vbtyp_n = 'R' ). " Goods Movement
IF lt_vbfa IS INITIAL. RETURN. ENDIF.
SELECT vbeln, erdat, erzet, ernam, fksto, belnr FROM vbrk INTO TABLE lt_vbrk
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbeln
AND ( lt_vbfa-vbtyp_n = 'M' OR lt_vbfa-vbtyp_n = 'N' ).
SELECT vbeln, erdat, erzet, ernam, podat FROM likp INTO TABLE lt_likp
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbeln AND lt_vbfa-vbtyp_n = 'J'.
SELECT mblnr, mjahr, zeile, bwart, budat, cpuzt, usnam FROM mseg INTO TABLE lt_mseg
FOR ALL ENTRIES IN lt_vbfa
WHERE mblnr = lt_vbfa-vbeln AND mjahr = lt_vbfa-mjahr AND zeile = lt_vbfa-posnn AND lt_vbfa-vbtyp_n = 'R' AND bwart = '601'.
SELECT augdt, belnr, gjahr, kunnr FROM bsad INTO TABLE lt_bsad
FOR ALL ENTRIES IN lt_vbrk
WHERE belnr = lt_vbrk-belnr AND gjahr = SUBSTRING( val = lt_vbrk-erdat len = 4 ).
SELECT vbeln, posnr, gbsta FROM vbup INTO TABLE lt_vbup
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbelv AND posnr = lt_vbfa-posnv.
LOOP AT lt_vbfa ASSIGNING FIELD-SYMBOL(<fs_vbfa>).
DATA(lv_order_info) = REF #( it_order_items[ vbeln = <fs_vbfa>-vbelv ] ).
IF lv_order_info IS NOT BOUND. CONTINUE. ENDIF.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_vbfa>-vbelv.
gs_event_log-customernumber = lv_order_info->kunnr.
gs_event_log-salesorganization = lv_order_info->vkorg.
gs_event_log-netamount = lv_order_info->netwr.
gs_event_log-materialnumber = lv_order_info->matnr.
CASE <fs_vbfa>-vbtyp_n.
WHEN 'J'. " Delivery
READ TABLE lt_likp ASSIGNING FIELD-SYMBOL(<fs_likp>) WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0.
gs_event_log-activity = 'Delivery Created'.
CONCATENATE <fs_likp>-erdat <fs_likp>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_likp>-ernam.
APPEND gs_event_log TO gt_event_log.
" Picking Completed - simplified logic, check status
gs_event_log-activity = 'Picking Completed'. APPEND gs_event_log TO gt_event_log.
" POD Confirmed
IF <fs_likp>-podat IS NOT INITIAL.
gs_event_log-activity = 'Proof Of Delivery Confirmed'.
gs_event_log-starttime = <fs_likp>-podat.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
WHEN 'R'. " Goods Issue
READ TABLE lt_mseg ASSIGNING FIELD-SYMBOL(<fs_mseg>) WITH KEY mblnr = <fs_vbfa>-vbeln mjahr = <fs_vbfa>-mjahr zeile = <fs_vbfa>-posnn.
IF sy-subrc = 0.
gs_event_log-activity = 'Goods Issued'.
CONCATENATE <fs_mseg>-budat <fs_mseg>-cpuzt INTO gs_event_log-starttime.
gs_event_log-user = <fs_mseg>-usnam.
APPEND gs_event_log TO gt_event_log.
ENDIF.
WHEN 'M'. " Invoice
READ TABLE lt_vbrk ASSIGNING FIELD-SYMBOL(<fs_vbrk>) WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0.
gs_event_log-activity = 'Invoice Created'.
CONCATENATE <fs_vbrk>-erdat <fs_vbrk>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_vbrk>-ernam.
APPEND gs_event_log TO gt_event_log.
" Payment Received
READ TABLE lt_bsad ASSIGNING FIELD-SYMBOL(<fs_bsad>) WITH KEY belnr = <fs_vbrk>-belnr.
IF sy-subrc = 0 AND <fs_bsad>-augdt IS NOT INITIAL.
gs_event_log-activity = 'Payment Received'.
gs_event_log-starttime = <fs_bsad>-augdt.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
WHEN 'N'. " Invoice Cancellation
READ TABLE lt_vbrk ASSIGNING <fs_vbrk> WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0 AND <fs_vbrk>-fksto = 'X'.
gs_event_log-activity = 'Invoice Cancelled'.
CONCATENATE <fs_vbrk>-erdat <fs_vbrk>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_vbrk>-ernam.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDCASE.
ENDLOOP.
" Infer other events from status
LOOP AT lt_vbup ASSIGNING FIELD-SYMBOL(<fs_vbup>).
IF <fs_vbup>-gbsta = 'C'.
DATA(lv_order_info_stat) = REF #( it_order_items[ vbeln = <fs_vbup>-vbeln ] ).
IF lv_order_info_stat IS NOT BOUND. CONTINUE. ENDIF.
gs_event_log-salesorder = <fs_vbup>-vbeln.
gs_event_log-activity = 'Order Item Closed'.
" Timestamp for closed is harder, using current time as placeholder
CONCATENATE sy-datum sy-uzeit INTO gs_event_log-starttime.
gs_event_log-user = sy-uname.
gs_event_log-customernumber = lv_order_info_stat->kunnr.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
" Order Confirmed (Simplified - assumes if not blocked it's confirmed)
LOOP AT it_order_items ASSIGNING FIELD-SYMBOL(<fs_item>).
IF <fs_item>-lifsk IS INITIAL.
gs_event_log-salesorder = <fs_item>-vbeln.
gs_event_log-activity = 'Order Confirmed'.
CONCATENATE <fs_item>-erdat <fs_item>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_item>-ernam.
gs_event_log-customernumber = <fs_item>-kunnr.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form write_output_file
*&---------------------------------------------------------------------*
FORM write_output_file.
DATA: lt_final_output TYPE TABLE OF ty_event_log.
" Add common fields
LOOP AT gt_event_log ASSIGNING FIELD-SYMBOL(<fs_event>).
<fs_event>-sourcesystem = gv_sysid.
<fs_event>-lastdataupdate = gv_last_update.
ENDLOOP.
SORT gt_event_log BY salesorder starttime.
DELETE ADJACENT DUPLICATES FROM gt_event_log COMPARING ALL FIELDS.
lt_final_output = gt_event_log.
DATA: lt_fieldnames TYPE TABLE OF string.
APPEND 'SalesOrder' TO lt_fieldnames.
APPEND 'Activity' TO lt_fieldnames.
APPEND 'StartTime' TO lt_fieldnames.
APPEND 'SourceSystem' TO lt_fieldnames.
APPEND 'LastDataUpdate' TO lt_fieldnames.
APPEND 'User' TO lt_fieldnames.
APPEND 'CustomerNumber' TO lt_fieldnames.
APPEND 'SalesOrganization' TO lt_fieldnames.
APPEND 'NetAmount' TO lt_fieldnames.
APPEND 'MaterialNumber' TO lt_fieldnames.
APPEND 'DeliveryBlock' TO lt_fieldnames.
APPEND 'RejectionReason' TO lt_fieldnames.
APPEND 'SalesOrderCycleTime' TO lt_fieldnames.
DATA(lv_header) = REDUCE string(
INIT s = ''
FOR field IN lt_fieldnames
NEXT s = s && COND #( WHEN s = '' THEN field ELSE |,{ field }| ) ).
DATA: lt_file_content TYPE TABLE OF string.
APPEND lv_header TO lt_file_content.
LOOP AT lt_final_output INTO DATA(ls_output).
DATA(lv_line) = |"{ ls_output-salesorder }","{ ls_output-activity }","{ ls_output-starttime }","{ ls_output-sourcesystem }","{ ls_output-lastdataupdate }","{ ls_output-user }","{ ls_output-customernumber }","{ ls_output-salesorganization }",{ ls_output-netamount },"{ ls_output-materialnumber }","{ ls_output-deliveryblock }","{ ls_output-rejectionreason }","{ ls_output-salesordercycletime }"|.
APPEND lv_line TO lt_file_content.
ENDLOOP.
cl_gui_frontend_services=>gui_download(
EXPORTING
filename = p_file
filetype = 'ASC'
CHANGING
data_tab = lt_file_content ).
ENDFORM. Kroki
- Wymagania wstępne: Upewnij się, że mają Państwo bezpośredni dostęp do odczytu bazy danych SAP ECC. Do połączenia i wykonywania zapytań potrzebne będzie narzędzie klienckie, takie jak DBeaver, SQL Server Management Studio lub Oracle SQL Developer.
- Pobierz skrypt SQL: Skopiuj pełne zapytanie SQL z sekcji „Zapytanie” tego dokumentu.
- Połącz się z bazą danych: Otwórz narzędzie klienckie i połącz się z instancją bazy danych SAP ECC. Potrzebne będą adres serwera, port, nazwa bazy danych i odpowiednie dane logowania.
- Skonfiguruj zapytanie: Wklej skrypt SQL do nowego okna edytora zapytań. Znajdź sekcję konfiguracji w głównym wyrażeniu Common Table Expression (CTE) o nazwie SalesOrders. Zastąp wartości zastępcze daty początkowej („{StartDate}”), daty końcowej („{EndDate}”), organizacji sprzedaży („{SalesOrgs}”) i typów dokumentów („{DocTypes}”) właściwymi wartościami dla analizy.
- Uruchom zapytanie: Wykonaj skonfigurowany skrypt SQL. W zależności od zakresu dat i wielkości bazy SAP wykonanie może potrwać kilka minut.
- Sprawdź wyniki: Po zakończeniu zapytania wyświetli się zestaw wyników. Sprawdź, czy zawiera oczekiwane kolumny, takie jak SalesOrder, Activity i StartTime, oraz czy zwrócono wiersze dla różnych działań.
- Wyeksportuj dane: Użyj funkcji eksportu w narzędziu klienckim, aby zapisać wyniki jako plik CSV. Nadaj mu opisową nazwę, na przykład SAP_O2C_Event_Log.csv.
- Przygotuj dane dla ProcessMind: Otwórz plik CSV w edytorze arkuszy kalkulacyjnych. Sprawdź, czy nagłówki kolumn dokładnie odpowiadają wymaganym atrybutom, na przykład SalesOrder, Activity i StartTime. Upewnij się, że format daty i godziny w polach StartTime i LastDataUpdate jest spójny i obsługiwany przez ProcessMind, na przykład YYYY-MM-DD HH:MI:SS.
- Prześlij dane do ProcessMind: Prześlij przygotowany plik CSV do projektu ProcessMind, aby rozpocząć analizę.
Konfiguracja
- Zakres dat: Zapytanie używa wartości zastępczych („{StartDate}” i „{EndDate}”) do filtrowania zamówień według daty utworzenia (VBAK.ERDAT). Zwykle analizuje się dane z okresu od 3 do 6 miesięcy, aby uzyskać reprezentatywną próbę bez nadmiernego obciążania bazy.
- Filtr organizacji sprzedaży: Użyj wartości zastępczej „{SalesOrgs}”, aby ograniczyć ekstrakcję do wybranych organizacji sprzedaży, na przykład „1000” lub „2000”. Pozwala to skupić analizę i poprawić wydajność zapytania.
- Filtr typu dokumentu: Użyj wartości zastępczej „{DocTypes}”, aby wybrać określone typy zamówień sprzedaży, na przykład „OR” dla zamówienia standardowego. Dzięki temu można wykluczyć z głównego przebiegu procesu nieistotne dokumenty, takie jak dostawy bezpłatne lub zwroty.
- Identyfikator systemu źródłowego: Wartość zastępcza „{SourceSystemName}” służy do oznaczenia każdego rekordu nazwą systemu źródłowego. Należy zastąpić ją odpowiednią nazwą instancji SAP ECC, na przykład SAP_ECC_PRD.
- Zgodność z bazą danych: Funkcja łącząca pola daty i godziny, [Your DB-specific timestamp function], jest wartością zastępczą. Należy zastąpić ją funkcją właściwą dla danej bazy, na przykład TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UZEIT), 'YYYYMMDDHH24MISS') w SAP HANA lub CAST(CDHDR.UDATE AS DATETIME) + CAST(CDHDR.UZEIT AS DATETIME) w SQL Server.
- Wymagania wstępne: Ta metoda wymaga bezpośrednich danych logowania do bazy z uprawnieniami tylko do odczytu. Użytkownik bazy musi mieć dostęp do wszystkich tabel użytych w zapytaniu, w tym VBAK, VBAP, VBFA, CDHDR, CDPOS, LIKP, VBRK i BSAD.
Przykładowe zapytanie sql
WITH SalesOrders AS (
SELECT VBELN
FROM VBAK
WHERE ERDAT BETWEEN '{StartDate}' AND '{EndDate}' -- Filter by creation date
AND VKORG IN ('{SalesOrgs}') -- Filter by Sales Organization(s)
AND AUART IN ('{DocTypes}') -- Filter by Sales Document Type(s)
)
-- 1. Sales Order Created
SELECT
vbak.VBELN AS "SalesOrder",
'Sales Order Created' AS "Activity",
[Your DB-specific timestamp function](vbak.ERDAT, vbak.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbak.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBAK vbak
JOIN SalesOrders so ON vbak.VBELN = so.VBELN
UNION ALL
-- 2. Sales Order Changed
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Sales Order Changed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG' AND cdhdr.TCODE IN ('VA02')
UNION ALL
-- 3. Credit Check Performed (Release)
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Credit Check Performed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'CMGST'
AND cdpos.VALUE_NEW = 'B' -- Credit status 'Released'
UNION ALL
-- 4. Order Confirmed (Overall status not blocked)
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Order Confirmed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'GBSTK'
AND cdpos.VALUE_OLD <> 'A' AND cdpos.VALUE_NEW = 'A' -- Status changes to 'Not yet processed'
UNION ALL
-- 5. Delivery Block Set
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Delivery Block Set' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
cdpos.VALUE_NEW AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBAK'
AND cdpos.FNAME = 'LIFSK'
AND cdpos.VALUE_NEW IS NOT NULL AND cdpos.VALUE_NEW <> ''
UNION ALL
-- 6. Delivery Created
SELECT
vbfa.VBELV AS "SalesOrder",
'Delivery Created' AS "Activity",
[Your DB-specific timestamp function](likp.ERDAT, likp.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
likp.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN LIKP likp ON vbfa.VBELN = likp.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J'
UNION ALL
-- 7. Picking Completed
SELECT
vbfa.VBELV AS "SalesOrder",
'Picking Completed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN CDHDR cdhdr ON vbfa.VBELN = cdhdr.OBJECTID
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J'
AND cdhdr.OBJECTCLASS = 'LIEFERUNG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'PKSTK'
AND cdpos.VALUE_NEW = 'C'
UNION ALL
-- 8. Goods Issued
SELECT
vbfa_gi.VBELV AS "SalesOrder",
'Goods Issued' AS "Activity",
[Your DB-specific timestamp function](mkpf.BUDAT, mkpf.CPUTM) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
mkpf.USNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa_gi
JOIN SalesOrders so ON vbfa_gi.VBELV = so.VBELN
JOIN MKPF mkpf ON vbfa_gi.VBELN = mkpf.XBLNR -- XBLNR is Reference Document Number
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa_gi.VBTYP_V = 'J' AND vbfa_gi.VBTYP_N = 'R'
UNION ALL
-- 9. Proof Of Delivery Confirmed
SELECT
vbfa.VBELV AS "SalesOrder",
'Proof Of Delivery Confirmed' AS "Activity",
[Your DB-specific timestamp function](likp.PODAT, '000000') AS "StartTime", -- PODAT is only a date
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
likp.AENAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN LIKP likp ON vbfa.VBELN = likp.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J' AND likp.PODAT IS NOT NULL AND likp.PODAT <> '00000000'
UNION ALL
-- 10. Invoice Created
SELECT
vbfa.VBELV AS "SalesOrder",
'Invoice Created' AS "Activity",
[Your DB-specific timestamp function](vbrk.ERDAT, vbrk.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbrk.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'M'
UNION ALL
-- 11. Invoice Cancelled
SELECT
vbfa.VBELV AS "SalesOrder",
'Invoice Cancelled' AS "Activity",
[Your DB-specific timestamp function](vbrk.ERDAT, vbrk.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbrk.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'M' AND vbfa.VBTYP_N = 'N'
UNION ALL
-- 12. Payment Received
SELECT
vbfa.VBELV AS "SalesOrder",
'Payment Received' AS "Activity",
[Your DB-specific timestamp function](bsad.AUGDT, '000000') AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
NULL AS "User", -- Clearing user not readily available here
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN BSAD bsad ON vbrk.VBELN = bsad.VBLNR
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'M'
AND bsad.AUGDT IS NOT NULL AND bsad.AUGDT <> '00000000'
UNION ALL
-- 13. Order Item Closed
SELECT DISTINCT
cdhdr.OBJECTID AS "SalesOrder",
'Order Item Closed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
vbap.MATNR AS "MaterialNumber",
NULL AS "DeliveryBlock",
vbap.ABGRU AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAP vbap ON cdhdr.OBJECTID = vbap.VBELN AND SUBSTRING(cdpos.TABKEY, 4, 6) = vbap.POSNR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUP'
AND cdpos.FNAME = 'GBSTA'
AND cdpos.VALUE_NEW = 'C' -- Item is completely processed
UNION ALL
-- 14. Order Cancelled
SELECT DISTINCT
cdhdr.OBJECTID AS "SalesOrder",
'Order Cancelled' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
vbap.MATNR AS "MaterialNumber",
NULL AS "DeliveryBlock",
cdpos.VALUE_NEW AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAP vbap ON cdhdr.OBJECTID = vbap.VBELN AND SUBSTRING(cdpos.TABKEY, 4, 6) = vbap.POSNR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBAP'
AND cdpos.FNAME = 'ABGRU'
AND cdpos.VALUE_NEW IS NOT NULL AND cdpos.VALUE_NEW <> ''; Gotowi do rozpoczęcia?
Skorzystaj z tego szablonu danych, aby lepiej zrozumieć proces obsługi zamówień sprzedaży. Zacznij usprawniać proces i przyspieszać przepływ środków.
Usprawnij obsługę zamówień sprzedaży już dziś
Usuń wąskie gardła, skróć czas cyklu o 30% i szybciej popraw przepływ środków.
Nie trzeba podawać danych karty. Konfiguracja zajmuje kilka minut.