Szablon danych dla procesu od zapisu do raportu, zapisy księgowe
Szablon danych dla procesu od zapisu do raportu, zapisy księgowe
- Zalecane atrybuty do szczegółowej analizy
- Ważne czynności związane z zapisami księgowymi do śledzenia
- Praktyczne wskazówki dotyczące ekstrakcji danych z SAP ECC
Atrybuty procesu od zapisu do raportu, zapisy księgowe
| Nazwa | Opis | ||
|---|---|---|---|
| Czas zdarzenia EventTime | Znacznik czasu wskazujący, kiedy wystąpiło konkretne działanie lub zdarzenie w procesie księgowania zapisu. | ||
| Opis Czas zdarzenia określa dokładną datę i godzinę każdego działania w procesie księgowania zapisów. Dane te są niezbędne do obliczania wskaźników opartych na czasie, takich jak czas realizacji, czas przetwarzania i opóźnienia między etapami. Źródło znacznika czasu zależy od działania. Może nim być data i godzina utworzenia dokumentu (CPUDT/CPUTM) lub znacznik czasu zmiany z dziennika (CDHDR-UDATE/UTIME). W analizie czas zdarzenia służy do uporządkowania zdarzeń chronologicznie i stanowi podstawę mapy procesu. Jest niezbędny do obliczania wszystkich KPI związanych z czasem, takich jak średni czas realizacji zapisu księgowego, średni czas akceptacji oraz czas od akceptacji do zaksięgowania. Dlaczego to ważne Ten znacznik czasu stanowi podstawę analizy czasu i umożliwia obliczanie czasu realizacji, długości poszczególnych etapów oraz wąskich gardeł. Skąd pobrać Źródło zależy od działania. Najczęściej są to znaczniki czasu utworzenia (CPUDT, CPUTM) z BKPF lub znaczniki czasu zmiany (UDATE, UTIME) z CDHDR. Przykłady 2023-10-26T09:00:00Z2023-10-26T14:30:15Z2023-10-27T11:05:00Z | |||
| Identyfikator zapisu księgowego JournalEntryId | Unikalny identyfikator dokumentu księgowego, złożony z kodu jednostki gospodarczej, numeru dokumentu i roku obrotowego. | ||
| Opis Journal Entry ID to główny identyfikator case, który służy do śledzenia cyklu życia zapisu księgowego. Jest to klucz złożony, zwykle utworzony przez połączenie kodu jednostki gospodarczej (BUKRS), numeru dokumentu (BELNR) i roku obrotowego (GJAHR). Zapewnia unikalność w całym systemie SAP. W analizie procesu ten identyfikator łączy wszystkie powiązane działania, takie jak utworzenie, wstępne wprowadzenie, przekazanie, akceptacja, odrzucenie i zaksięgowanie. Śledząc go, można odtworzyć cały przebieg każdego zapisu księgowego, zmierzyć czas realizacji oraz wykryć odstępstwa od procesu lub wąskie gardła dotyczące konkretnych zapisów. Dlaczego to ważne To niezbędny identyfikator do śledzenia zapisu księgowego od utworzenia do zaksięgowania. Umożliwia analizę całego procesu i porównywanie jego wariantów. Skąd pobrać To atrybut pochodny, zwykle utworzony przez połączenie pól z tabeli BKPF: kodu jednostki gospodarczej (BUKRS), numeru dokumentu (BELNR) i roku obrotowego (GJAHR). Przykłady 1000-1000000123-20232000-1900000456-20231000-1800000789-2024 | |||
| Nazwa działania ActivityName | Nazwa działania biznesowego lub zdarzenia, które wystąpiło na danym etapie procesu księgowania zapisów. | ||
| Opis Nazwa działania opisuje konkretny etap cyklu życia zapisu księgowego, na przykład „Utworzono zapis księgowy”, „Zaakceptowano zapis księgowy” lub „Zaksięgowano zapis księgowy”. Atrybut ten jest zwykle określany na podstawie wielu źródeł w SAP, w tym kodów transakcji (TCODE), dzienników zmian dokumentów (tabele CDHDR i CDPOS) oraz pól statusu dokumentu. Analiza działań stanowi podstawę process mining. Umożliwia wizualizację map procesów, obliczanie czasu między etapami i wykrywanie pętli poprawek, na przykład „Odrzucono zapis księgowy”, po którym następuje „Poprawiono zapis księgowy”. Dane te są niezbędne do tworzenia dashboardów dotyczących czasu realizacji, odsetka poprawek i wariantów procesu. Dlaczego to ważne Określa etapy na mapie procesu, dzięki czemu można wizualizować, analizować i optymalizować workflow księgowania zapisów. Skąd pobrać Dane pochodzą z różnych źródeł, w tym kodów transakcji w BKPF (TCODE), statusu dokumentu, dzienników workflow w tabelach takich jak SWW_WI2OBJ oraz dokumentów zmian w CDHDR i CDPOS. Przykłady Utworzono zapis księgowyZaakceptowano zapis księgowyOdrzucono zapis księgowyZaksięgowano zapis księgowy | |||
| Ostatnia aktualizacja danych LastDataUpdate | Znacznik czasu wskazujący, kiedy dane zostały ostatnio wyodrębnione z systemu źródłowego lub odświeżone. | ||
| Opis Ten atrybut zapisuje datę i godzinę ostatniego pobrania danych z SAP ECC. Jest to pole metadanych, które pozwala ocenić aktualność analizowanych danych. W każdym dashboardzie lub analizie process mining informacja o czasie ostatniej aktualizacji pomaga użytkownikom ocenić wiarygodność danych i podejmować świadome decyzje. Odpowiada na pytanie: „Jak aktualne są te informacje?”. Dlaczego to ważne Informuje użytkowników o aktualności danych, dzięki czemu wiedzą, jakiego okresu dotyczy analiza, i mogą ocenić wiarygodność wyników. Skąd pobrać To pole metadanych generowane i zapisywane przez narzędzie do ekstrakcji danych lub proces ETL podczas odświeżania danych. Przykłady 2024-05-20T04:00:00Z2024-05-21T04:00:00Z2024-05-22T04:00:00Z | |||
| System źródłowy SourceSystem | System, z którego wyodrębniono dane o procesie. | ||
| Opis Ten atrybut wskazuje źródło danych, którym w tym przypadku jest konkretna instancja SAP ECC. Zwykle jest to stała wartość dodawana podczas ekstrakcji danych. Atrybut jest prosty, ale ważny w środowiskach z wieloma systemami ERP lub źródłami danych. Pozwala zachować przejrzystość pochodzenia danych oraz filtrować i segmentować analizę według systemu źródłowego. Dlaczego to ważne Zapewnia przejrzystość pochodzenia danych i pomaga śledzić ich jakość, szczególnie w środowiskach z wieloma systemami źródłowymi. Skąd pobrać Zwykle jest to stała wartość dodawana podczas transformacji danych, która wskazuje konkretną instancję SAP ECC (np. 'ECC_PROD_100'). Przykłady SAP ECC EHP8ECC_FIN_PRODSAP_ERP_60 | |||
| Czy wykonano storno IsReversed | Wartość logiczna wskazująca, czy zapis księgowy został storniowany. | ||
| Opis Ta flaga wskazuje zapisy księgowe, które zostały później storniowane innym dokumentem księgowym. W SAP dokument storniowany jest powiązany z dokumentem storna, co zapewnia przejrzystą ścieżkę audytową. Ten atrybut jest niezbędny do korzystania z dashboardu „Analiza storna zapisów księgowych” i KPI „Odsetek storna zapisów księgowych”. Pozwala wyodrębnić storniowane zapisy i zbadać przyczyny, takie jak błędy przy wprowadzaniu danych lub nieprawidłowe ujęcie księgowe. Dzięki temu można ograniczyć liczbę storna. Dlaczego to ważne Bezpośrednio wspiera analizę storna. Wskazuje zapisy, które zostały później wycofane, co pomaga ustalić przyczyny błędów i poprawić jakość danych. Skąd pobrać Wartość pochodzi z pola numeru dokumentu storna (STBLG) w tabeli BKPF. Jeśli pole STBLG nie jest puste, flaga ma wartość true. Przykłady truefalse | |||
| Data księgowania PostingDate | Data ujęcia transakcji w księdze głównej, która wpływa na okres finansowy. | ||
| Opis Data księgowania określa okres obrotowy, w którym ujmuje się zapis księgowy. Z punktu widzenia finansów i zgodności jest to ważne pole daty, które musi odpowiadać harmonogramowi zamknięcia okresu księgowego i wymogom regulacyjnym. W process mining data ta służy do monitorowania zgodności. Dashboard „Monitorowanie zgodności z wymogami” i KPI „Poziom zgodności z wymogami” wykorzystują ten atrybut, aby sprawdzić, czy zapisy są księgowane we właściwym okresie. Można go również użyć do analizy zmian liczby zapisów księgowych w czasie. Dlaczego to ważne Ważna przy sprawozdawczości finansowej i analizie zgodności, pozwala sprawdzić, czy zapisy są księgowane we właściwym okresie. Skąd pobrać Znajduje się w tabeli nagłówków dokumentów BKPF, w polu BUDAT. Przykłady 2023-10-312023-11-302024-01-15 | |||
| Jednostka gospodarcza CompanyCode | Jednostka organizacyjna reprezentująca niezależny podmiot prawny, dla którego sporządza się sprawozdania finansowe. | ||
| Opis Jednostka gospodarcza to podstawowa jednostka organizacyjna w SAP Financials. Reprezentuje niezależną prawnie spółkę i jest ważnym polem w nagłówku dokumentu księgowego. Atrybut ten pozwala segmentować analizę procesu według podmiotu prawnego. Ułatwia porównywanie przebiegu procesu, poziomu zgodności i wyników KPI w różnych częściach firmy. Można na przykład sprawdzić, czy opóźnienia w akceptacji lub częste storna dotyczą konkretnych jednostek gospodarczych. Dlaczego to ważne Umożliwia filtrowanie i porównywanie przebiegu procesu w różnych podmiotach prawnych lub jednostkach biznesowych organizacji. Skąd pobrać Znajduje się w tabeli nagłówków dokumentów BKPF, w polu BUKRS. Przykłady 10002000US01DE01 | |||
| Kod transakcji TransactionCode | Kod transakcji SAP użyty do utworzenia lub przetworzenia zapisu księgowego. | ||
| Opis Kod transakcji (T-Code) to unikalny identyfikator określonej funkcji lub programu w SAP. W przypadku zapisów księgowych wskazuje sposób ich utworzenia, na przykład ręcznie (FB01, F-02), przez wstępne wprowadzenie (FV50) lub za pomocą interfejsu automatycznego. Atrybut ten jest przydatny w dashboardzie „Optymalizacja działań ręcznych”. Analiza kodu T pozwala odróżnić działania ręczne od automatycznych, ustalić, które procesy ręczne zajmują najwięcej czasu, i wskazać możliwości automatyzacji, aby ograniczyć pracę ręczną i zwiększyć sprawność. Dlaczego to ważne Pomaga odróżnić procesy ręczne od automatycznych oraz wskazać możliwości automatyzacji i standaryzacji procesu. Skąd pobrać Znajduje się w tabeli nagłówków dokumentów BKPF, w polu TCODE. Przykłady FB01F-02FV50FBD1 | |||
| Rodzaj dokumentu DocumentType | Klasyfikacja dokumentów księgowych, która określa sposób ich przetwarzania i przechowywania. | ||
| Opis Rodzaj dokumentu pozwala odróżnić typy transakcji biznesowych, takie jak zapis w księdze głównej (SA), faktura dostawcy (KR) czy księgowanie środka trwałego (AA). Jest określany podczas konfiguracji systemu i przypisywany do każdego zapisu księgowego. To ważny atrybut analizy, ponieważ umożliwia segmentowanie procesu według rodzaju transakcji. Dashboard „Liczba przetworzonych zapisów księgowych według rodzaju” i KPI „Średni czas realizacji według rodzaju zapisu księgowego” bezpośrednio korzystają z tego pola. Atrybut pomaga wykryć, czy określone rodzaje zapisów częściej powodują opóźnienia, poprawki lub storna. Dlaczego to ważne Umożliwia segmentowanie analizy według rodzaju transakcji i pomaga ustalić, czy problemy dotyczą konkretnych rodzajów zapisów księgowych. Skąd pobrać Znajduje się w tabeli nagłówków dokumentów BKPF, w polu BLART. Przykłady SAKRREAA | |||
| Użytkownik User | Identyfikator użytkownika SAP, który utworzył lub zmienił zapis księgowy. | ||
| Opis Ten atrybut wskazuje nazwę użytkownika SAP odpowiedzialnego za dane działanie, takie jak utworzenie, wstępne wprowadzenie lub zaksięgowanie dokumentu. Dane pochodzą bezpośrednio z nagłówka dokumentu lub tabel dziennika zmian. Analiza atrybutu „Użytkownik” pomaga ocenić pracę zespołów i poszczególnych osób. Dashboard produktywności użytkowników pokazuje liczbę działań i czas przetwarzania dla każdego użytkownika. Atrybut ułatwia też ustalenie, kto uczestniczy w pętlach poprawek, stornach lub przypadkach niezgodności, co pozwala lepiej ukierunkować szkolenia i usprawnienia procesu. Dlaczego to ważne Wskazuje użytkownika odpowiedzialnego za każde działanie, co umożliwia analizę jego pracy, rozkładu obciążenia i powtarzających się poprawek. Skąd pobrać Zwykle dane pochodzą z tabeli BKPF (pole USNAM dla autora) lub CDHDR (pole USERNAME dla osoby wprowadzającej zmianę). Przykłady ABROWNCJONESDSMITH | |||
| Czas zatwierdzania ApprovalTime | Czas od przekazania zapisu księgowego do zatwierdzenia do jego zatwierdzenia lub odrzucenia. | ||
| Opis Ta miara określa czas trwania podprocesu zatwierdzania, który często znacząco wpływa na całkowity czas realizacji. Oblicza się ją jako różnicę między zdarzeniem „Przekazano zapis księgowy do zatwierdzenia” a odpowiadającym mu zdarzeniem „Zatwierdzono zapis księgowy” lub „Odrzucono zapis księgowy”. Czas zatwierdzania jest główną miarą dashboardu „Sprawność zatwierdzania zapisów księgowych” i KPI „Średni czas zatwierdzania zapisów księgowych”. Analiza tego czasu pomaga wykryć wąskie gardła w workflow zatwierdzania, ocenić pracę osób zatwierdzających i uzasadnić zmiany w procesie, na przykład korektę progów zatwierdzania. Dlaczego to ważne Określa czas trwania etapu zatwierdzania i pomaga wskazać oraz ograniczyć opóźnienia w workflow weryfikacji i zatwierdzania. Skąd pobrać Obliczany przez odjęcie znacznika czasu zdarzenia „Przekazano zapis księgowy do zatwierdzenia” od znacznika czasu zdarzenia „Zatwierdzono zapis księgowy” lub „Odrzucono zapis księgowy”. Przykłady P1DT2HPT4H15MP3D | |||
| Czy dokument jest wstępnie wprowadzony IsParked | Flaga logiczna wskazująca, czy zapis księgowy został zapisany jako dokument wstępnie wprowadzony przed zaksięgowaniem. | ||
| Opis Wstępne wprowadzenie dokumentu pozwala zapisać niekompletny zapis księgowy bez wpływu na salda finansowe. Następnie inny użytkownik może go uzupełnić lub sprawdzić przed zaksięgowaniem. Ta flaga wskazuje zapisy, które przeszły etap wstępnego wprowadzenia. Analiza tego atrybutu pomaga ustalić, jak wykorzystywana jest funkcja wstępnego wprowadzania. Może ujawnić, że służy ona jako nieformalny etap weryfikacji, który powoduje opóźnienia. Ułatwia też analizę czasu realizacji całego procesu i rozróżnienie zapisów księgowanych bezpośrednio od tych, które najpierw wstępnie wprowadzono. Dlaczego to ważne Wskazuje zapisy obsługiwane z użyciem funkcji wstępnego wprowadzania. Może ona powodować opóźnienia lub sygnalizować nieformalny etap weryfikacji. Skąd pobrać Wartość pochodzi z pola statusu dokumentu (BSTAT) w tabeli BKPF. Wartość „V” oznacza dokument wstępnie wprowadzony. Przykłady truefalse | |||
| Czy wymagał poprawek IsRework | Flaga logiczna wskazująca, czy zapis księgowy wymagał poprawek, na przykład po odrzuceniu i skorygowaniu. | ||
| Opis Ta flaga wskazuje przypadki odbiegające od standardowego przebiegu, w których konieczne były działania naprawcze. Zwykle przyjmuje wartość true, gdy dla danego zapisu księgowego wystąpiła sekwencja zdarzeń, na przykład „Odrzucono zapis księgowy”, a następnie „Skorygowano zapis księgowy”. Ten atrybut jest niezbędny do obliczenia KPI „Odsetek zapisów księgowych wymagających poprawek” i analizy dashboardu „Odsetek poprawek i odrzuceń”. Pozwala określić skalę nieefektywności procesu i stanowi podstawę do badania przyczyn poprawek, takich jak niejasne wymagania lub niewystarczająca dokumentacja. Dlaczego to ważne Wskazuje zapisy wymagające korekty, co pozwala określić skalę poprawek i zbadać ich przyczyny, aby zwiększyć odsetek poprawnych zapisów za pierwszym razem. Skąd pobrać Atrybut obliczany na podstawie sekwencji zdarzeń dla danego przypadku. Pętla poprawek jest wykrywana, gdy wystąpi zdarzenie odrzucenia lub korekty. Przykłady truefalse | |||
| Klucz waluty CurrencyKey | Kod waluty, w której zapisano kwoty w dokumencie księgowym. | ||
| Opis Ten atrybut określa walutę dokumentu księgowego, na przykład USD, EUR lub JPY. Pozwala właściwie interpretować powiązane z dokumentem kwoty. Nie zawsze jest głównym wymiarem analizy, ale ma zasadnicze znaczenie dla prawidłowej interpretacji wartości pieniężnych. W organizacjach międzynarodowych można też podzielić dane według waluty i sprawdzić, czy proces przebiega inaczej dla zapisów w walutach obcych i lokalnych. Dlaczego to ważne Zapewnia kontekst niezbędny do prawidłowej analizy i interpretacji wszystkich wartości pieniężnych. Skąd pobrać Pole WAERS w tabeli nagłówków dokumentów BKPF. Przykłady USDEURGBPJPY | |||
| Łączna kwota dokumentu TotalDocumentAmount | Łączna wartość zapisu księgowego w walucie dokumentu. | ||
| Opis Ten atrybut określa łączną wartość finansową zapisu księgowego. Zwykle oblicza się ją przez zsumowanie wartości bezwzględnych wszystkich pozycji debetowych lub kredytowych powiązanych z dokumentem. Analiza procesu według wartości finansowej może ujawnić istotne zależności. Na przykład zapisy o wysokiej wartości mogą podlegać innej, bardziej rygorystycznej ścieżce akceptacji. Atrybut ten pozwala filtrować lub segmentować analizę, aby sprawdzić, czy kwota zapisu wiąże się z czasem realizacji, odsetkiem odrzuceń lub opóźnieniami w akceptacji. Dlaczego to ważne Umożliwia analizę wpływu finansowego, na przykład sprawdzenie, czy czas przetwarzania lub odsetek odrzuceń zależy od wartości zapisów księgowych. Skąd pobrać To pole obliczane na podstawie sumy wartości pola kwoty (WRBTR lub DMBTR) ze wszystkich pozycji w tabeli BSEG dla danego zapisu księgowego. Przykłady 1500.0025000.75125.50 | |||
| Miejsce powstawania kosztów CostCenter | Jednostka organizacyjna w obszarze rachunku kosztów, która odpowiada miejscu ponoszenia kosztów. | ||
| Opis Miejsce powstawania kosztów to podstawowy element danych podstawowych modułu Controlling (CO). Często jest przypisywane do pozycji dokumentu księgowego i służy do ewidencji kosztów konkretnego działu, funkcji lub lokalizacji. Uwzględnienie tego atrybutu pozwala dokładniej analizować proces obsługi dokumentów księgowych. Można sprawdzić, czy określone działy częściej wykonują poprawki, mają dłuższy czas realizacji lub wprowadzają więcej zapisów ręcznie. Ułatwia to ocenę sprawności procesu w poszczególnych działach. Dlaczego to ważne Umożliwia analizę wyników procesu według działu lub obszaru funkcjonalnego i pomaga wskazać lokalne źródła nieefektywności. Skąd pobrać Pole KOSTL w tabeli pozycji dokumentu BSEG. Przykłady 4100CC_FINANCE_US10010101 | |||
| Przyczyna storna ReversalReason | Kod określający przyczynę storna zapisu księgowego. | ||
| Opis Podczas stornowania dokumentu SAP pozwala podać kod przyczyny. Kod ten opisuje, dlaczego storno było konieczne, na przykład z powodu nieprawidłowej daty księgowania lub błędu przy wprowadzaniu danych. Ten atrybut jest jednym z głównych źródeł danych dla dashboardu „Analiza storna zapisów księgowych”. Analiza najczęstszych przyczyn storna pozwala wykryć powtarzające się problemy w procesach lub braki w szkoleniach. Na tej podstawie można podjąć ukierunkowane działania, aby zapobiegać kolejnym błędom i ograniczyć liczbę storna. Dlaczego to ważne Pokazuje bezpośrednio, dlaczego dochodzi do storna, co ułatwia analizę przyczyn i ograniczenie liczby przyszłych błędów. Skąd pobrać Pole STGRD w tabeli nagłówków dokumentów BKPF. Przykłady 010205 | |||
Czynności w procesie od zapisu do raportu, zapisy księgowe
| Działanie | Opis | ||
|---|---|---|---|
| Przekazano zapis księgowy do akceptacji | To działanie oznacza, że autor zakończył pracę nad wstępnie wprowadzonym zapisem księgowym i przekazał go do weryfikacji oraz akceptacji. Zdarzenie jest zwykle rejestrowane przy uruchomieniu zadania SAP Business Workflow powiązanego z dokumentem. | ||
| Dlaczego to ważne To moment przekazania zapisu od autora do osoby akceptującej i początek pomiaru KPI czasu akceptacji. Jest to ważny punkt pomiaru sprawności workflow akceptacji. Skąd pobrać Zdarzenie można wywnioskować z czasu rozpoczęcia instancji workflow powiązanej z obiektem dokumentu finansowego. Wymaga to analizy tabel dziennika workflow, takich jak SWW_WI2OBJ, aby znaleźć workflow uruchomione dla określonej jednostki gospodarczej, numeru dokumentu i roku obrotowego. Rejestrowanie Wskaż zdarzenie rozpoczęcia workflow dla wstępnie wprowadzonego dokumentu. Typ zdarzenia inferred | |||
| Przetworzono storno zapisu księgowego | To działanie oznacza storno wcześniej zaksięgowanego zapisu księgowego. Storno jest nowym dokumentem księgowym, który odwraca skutki pierwotnego zapisu. | ||
| Dlaczego to ważne To ważne zdarzenie przy pomiarze jakości danych i dokładności procesu. Wysoki odsetek storna wskazuje na problemy systemowe na etapie wprowadzania lub akceptacji danych. Każde storno oznacza dodatkową pracę. Skąd pobrać Zdarzenie można zidentyfikować w nagłówku pierwotnego dokumentu (tabela BKPF). Po wykonaniu storna SAP uzupełnia numer dokumentu storna (BKPF-STBLG) i przyczynę storna (BKPF-STGRD). Znacznikiem czasu zdarzenia jest data księgowania nowego dokumentu storna. Rejestrowanie Wskaż moment wypełnienia BKPF-STBLG w pierwotnym dokumencie. Znacznikiem czasu jest data księgowania dokumentu storna. Typ zdarzenia explicit | |||
| Zaakceptowano zapis księgowy | To działanie oznacza końcową akceptację zapisu księgowego w workflow, po której można go zaksięgować. Zdarzenie jest rejestrowane w dzienniku workflow po zakończeniu ostatniego kroku „zwolnij” lub „zaakceptuj”. | ||
| Dlaczego to ważne To ważny punkt kończący proces akceptacji. Czas do tego etapu jest istotnym KPI sprawności akceptacji, a czas od tego zdarzenia do zaksięgowania pokazuje opóźnienie po akceptacji. Skąd pobrać Zdarzenie można wywnioskować ze znacznika czasu zakończenia ostatniego kroku akceptacji w dzienniku SAP Business Workflow. Jest to ostatnie działanie akceptacyjne przed zaksięgowaniem dokumentu lub przygotowaniem go do zaksięgowania. Rejestrowanie Wskaż zakończenie ostatniego kroku „zwolnij” lub „zaakceptuj” w dziennikach workflow. Typ zdarzenia inferred | |||
| Zaksięgowano zapis księgowy | To główne działanie, podczas którego zapis księgowy zostaje oficjalnie ujęty w księdze głównej i wpływa na sprawozdania finansowe. Zdarzenie jest rejestrowane, gdy status dokumentu zmienia się na „zaksięgowany” i zostaje przypisana data księgowania. | ||
| Dlaczego to ważne To najważniejszy punkt procesu, oznaczający pomyślne przetworzenie zapisu księgowego. Czas całego procesu często mierzy się do tego momentu. Zdarzenie jest też istotne przy analizie zamknięcia finansowego. Skąd pobrać Zdarzenie można zidentyfikować, gdy dokument w tabeli BKPF ma przypisaną datę księgowania (BKPF-BUDAT). W przypadku wstępnie wprowadzonych dokumentów odpowiada to chwili, gdy status BKPF-BSTAT zmienia się z 'V' na pusty. Znacznikiem czasu księgowania jest data wprowadzenia BKPF-CPUDT. Rejestrowanie Wskaż zmianę BKPF-BSTAT z 'V' na pusty, a w przypadku księgowania bezpośredniego wskaż zdarzenie utworzenia. Typ zdarzenia explicit | |||
| Zapis księgowy wstępnie wprowadzony | To działanie oznacza utworzenie zapisu księgowego w stanie wstępnym, zanim zostanie on oficjalnie zaksięgowany w księdze głównej. W SAP zdarzenie jest rejestrowane, gdy użytkownik zapisuje dokument za pomocą transakcji wstępnego wprowadzania, a status dokumentu zmienia się na „wstępnie wprowadzony”. | ||
| Dlaczego to ważne To ważne zdarzenie początkowe w procesach obejmujących weryfikację i akceptację. Analiza czasu między wstępnym wprowadzeniem a zaksięgowaniem pomaga wykryć opóźnienia przed księgowaniem i na etapie akceptacji. Skąd pobrać Zdarzenie można zidentyfikować w tabeli nagłówków dokumentów BKPF. Dokument uznaje się za wstępnie wprowadzony, gdy utworzono go ze statusem BKPF-BSTAT = 'V'. Znacznik czasu zdarzenia to data i godzina utworzenia: BKPF-CPUDT i BKPF-CPUTM. Rejestrowanie Wskaż utworzenie dokumentu w BKPF, gdy BKPF-BSTAT ma wartość 'V'. Typ zdarzenia explicit | |||
| Dołączono dokumentację | To działanie oznacza dołączenie przez użytkownika dokumentów potwierdzających, takich jak faktury lub arkusze kalkulacyjne, do zapisu księgowego. Zdarzenie nie jest rejestrowane jako standardowe zdarzenie księgowe. Zwykle można je wywnioskować na podstawie utworzenia załączników powiązanych z obiektem dokumentu księgowego. | ||
| Dlaczego to ważne Śledzenie tego działania pomaga sprawdzić, czy przestrzegane są zasady wymagające dokumentacji. Opóźnienie w dołączeniu dokumentów może wydłużać cykl akceptacji. Skąd pobrać Wiarygodne zarejestrowanie tego zdarzenia wraz ze znacznikiem czasu jest trudne. Można je potencjalnie wywnioskować z analizy tabel załączników Generic Object Services (GOS), takich jak SOOD, i powiązania czasu utworzenia załącznika z kluczem obiektu zapisu księgowego. Rejestrowanie Wywnioskuj zdarzenie na podstawie czasu utworzenia powiązanych obiektów w tabelach GOS (np. SOOD). Typ zdarzenia inferred | |||
| Odrzucono zapis księgowy | To działanie oznacza ostateczne odrzucenie zapisu księgowego, który nie zostanie już zaksięgowany. Zwykle jest to końcowy status w workflow akceptacji, po którym wstępnie wprowadzony dokument zostaje usunięty. | ||
| Dlaczego to ważne Śledzenie odrzuceń jest ważne dla zarządzania jakością. Analiza przyczyn i częstotliwości odrzuceń pomaga zwiększyć odsetek zapisów księgowych poprawnych za pierwszym razem. Skąd pobrać Wynik ten można odczytać z dziennika SAP Business Workflow. Oznacza końcową decyzję użytkownika „odrzuć”, która kończy proces. Wstępnie wprowadzony dokument może zostać później usunięty. Rejestrowanie Wskaż końcowy status „odrzucono” w dzienniku workflow dla dokumentu. Typ zdarzenia inferred | |||
| Poprawiono zapis księgowy | To działanie oznacza, że autor zmodyfikował wstępnie wprowadzony zapis księgowy po otrzymaniu prośby o zmiany. Można je wywnioskować, wykrywając zmiany w dokumencie po zdarzeniu „Zażądano zmian”. | ||
| Dlaczego to ważne Śledzenie poprawek pozwala oszacować nakład pracy związany z ponownym przetwarzaniem. Czas między prośbą o zmianę a poprawieniem zapisu pokazuje, jak długo trwa rozwiązanie problemów ze zgłoszonymi zapisami. Skąd pobrać Zdarzenie można wywnioskować z analizy dzienników zmian dokumentu (tabele CDHDR i CDPOS) dla wstępnie wprowadzonego dokumentu. Zmiana zarejestrowana po zdarzeniu odrzucenia w workflow oznacza, że wprowadzono poprawkę. Znacznik czasu pochodzi z tabeli CDHDR. Rejestrowanie Wskaż wpis w dzienniku zmian CDHDR/CDPOS po zdarzeniu odrzucenia. Typ zdarzenia inferred | |||
| Rozliczono pozycję zapisu księgowego | To działanie oznacza rozliczenie pozycji konta księgi głównej prowadzonego w systemie otwartych pozycji, na przykład konta rozliczeniowego banku. Następuje, gdy pozycja zostaje dopasowana do innej i zamknięta. | ||
| Dlaczego to ważne W procesach takich jak uzgadnianie wyciągów bankowych czas rozliczenia pozycji jest ważnym KPI. To działanie pomaga analizować sprawność uzgadniania i procedur zamknięcia miesiąca. Skąd pobrać Zdarzenie można odczytać z tabeli pozycji BSEG. Po rozliczeniu pozycji wypełniane są pola daty rozliczenia (BSEG-AUGDT) i dokumentu rozliczeniowego (BSEG-AUGBL). Znacznikiem czasu zdarzenia jest data rozliczenia. Rejestrowanie Wskaż moment wypełnienia daty rozliczenia (BSEG-AUGDT) dla pozycji. Typ zdarzenia explicit | |||
| Usunięto wstępnie wprowadzony zapis księgowy | Oznacza usunięcie wstępnie wprowadzonego zapisu księgowego, który nie został zaksięgowany. Może do tego dojść po odrzuceniu zapisu lub gdy utworzono go przez pomyłkę. | ||
| Dlaczego to ważne To działanie oznacza niepowodzenie procesu. Analiza przyczyn usuwania wstępnie wprowadzonych dokumentów może ujawnić problemy, takie jak duplikaty lub nieporozumienia dotyczące procesu. Skąd pobrać Zdarzenie jest rejestrowane, gdy zmienia się status wstępnie wprowadzonego dokumentu w tabeli BKPF. Pole statusu BKPF-BSTAT przyjmuje wartość 'Z' (wstępnie wprowadzony dokument usunięty). Znacznik czasu zmiany można znaleźć w dziennikach zmian dokumentu (CDHDR). Rejestrowanie Wskaż moment, w którym BKPF-BSTAT przyjmuje wartość 'Z'. Typ zdarzenia explicit | |||
| Utworzono zapis księgowy | Oznacza utworzenie zapisu księgowego zaksięgowanego bezpośrednio, bez wcześniejszego wstępnego wprowadzenia. Zdarzenie jest rejestrowane, gdy dokument zostaje utworzony w SAP za pomocą transakcji bezpośredniego księgowania. | ||
| Dlaczego to ważne To alternatywny punkt początkowy prostszych procesów księgowania zapisów, które nie wymagają workflow akceptacji. Pozwala odróżnić proste księgowania bezpośrednie od bardziej złożonych zapisów wstępnie wprowadzonych. Skąd pobrać Zdarzenie odpowiada utworzeniu dokumentu w tabeli BKPF, gdy status BKPF-BSTAT jest pusty (dokument zaksięgowany). Znacznikiem czasu zdarzenia jest data utworzenia BKPF-CPUDT. W przypadku tych dokumentów zdarzenia „Utworzono” i „Zaksięgowano” występują jednocześnie. Rejestrowanie Wskaż utworzenie dokumentu w BKPF, gdy BKPF-BSTAT jest puste. Typ zdarzenia explicit | |||
| Zażądano zmian w zapisie księgowym | Oznacza etap workflow, na którym osoba akceptująca sprawdziła zapis księgowy i odesłała go autorowi do poprawy. Zdarzenie można odczytać z dzienników workflow, które wskazują decyzję użytkownika „odrzuć” lub „odeślij”. | ||
| Dlaczego to ważne To działanie pomaga wykrywać pętle poprawek, które są częstym źródłem nieefektywności i odstępstw od procesu. Częste występowanie tego zdarzenia może wskazywać na niską jakość zapisów lub niejasne wymagania. Skąd pobrać Zdarzenie można wywnioskować ze znacznika czasu konkretnego kroku decyzyjnego użytkownika w dzienniku SAP Business Workflow, odpowiadającego działaniu „odrzuć” lub „odeślij do poprawy”. Rejestrowanie Wskaż znacznik czasu decyzji „odrzucono” lub „do poprawy” w dziennikach workflow. Typ zdarzenia inferred | |||
| Zidentyfikowano księgowanie między jednostkami | To wyliczane działanie oznacza zapis księgowy dotyczący więcej niż jednej jednostki gospodarczej. Można je zidentyfikować na podstawie pozycji pojedynczego dokumentu finansowego. | ||
| Dlaczego to ważne Transakcje między jednostkami mogą wymagać bardziej złożonego przetwarzania i akceptacji. Ich identyfikacja pozwala osobno analizować czas realizacji i przebieg procesu, aby znaleźć charakterystyczne dla nich wąskie gardła. Skąd pobrać Wartość oblicza się na podstawie tabeli pozycji BSEG dla danego numeru dokumentu (BELNR). Jeśli pozycje obejmują więcej niż jedną różną jednostkę gospodarczą (BSEG-BUKRS), jest to księgowanie między jednostkami. Rejestrowanie Sprawdź, czy dla jednego BKPF-BELNR występuje więcej niż jedna unikalna wartość BSEG-BUKRS. Typ zdarzenia calculated | |||
| Zidentyfikowano ręczne wprowadzenie | To działanie określa, czy zapis księgowy utworzono za pomocą ręcznej transakcji online, czy przez interfejs automatyczny lub proces wsadowy. Nie jest to działanie użytkownika, lecz wyliczany atrybut zapisu, określany na podstawie danych systemowych. | ||
| Dlaczego to ważne Rozróżnienie zapisów ręcznych i automatycznych jest ważne przy planowaniu usprawnień procesu. Procesy ręczne często obejmuje się działaniami na rzecz standaryzacji i automatyzacji. Skąd pobrać Wartość oblicza się na podstawie pól tabeli nagłówków dokumentów BKPF. Kody transakcji (BKPF-TCODE), takie jak 'FB01', 'FB50' lub 'FV50', wskazują na ręczne wprowadzenie. Inne kody T lub określone nazwy wprowadzania wsadowego (BKPF-AWKEY) mogą wskazywać na automatyzację. Rejestrowanie Określ na podstawie BKPF-TCODE lub innych wskaźników systemu źródłowego w nagłówku dokumentu. Typ zdarzenia calculated | |||
Przewodniki po ekstrakcji danych
Kroki
- Utwórz program ABAP: W systemie SAP przejdź do transakcji SE38 (ABAP Editor). Wpisz nazwę nowego programu, na przykład Z_PM_JE_EXTRACTION, i kliknij przycisk Create. Podaj odpowiedni tytuł i ustaw typ programu na „Executable Program”.
- Zdefiniuj ekran wyboru: W kodzie źródłowym programu zdefiniuj ekran wyboru. Umożliwi on użytkownikom określenie parametrów, takich jak zakres dat utworzenia dokumentu, kody spółek i typy dokumentów, aby ograniczyć ilość danych do ekstrakcji.
- Zadeklaruj struktury danych: Zdefiniuj strukturę tabeli wewnętrznej, która będzie przechowywać końcowe dane dziennika zdarzeń. Musi ona zawierać wszystkie wymagane pola: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate oraz zalecane atrybuty, takie jak User, CompanyCode i PostingDate.
- Zaimplementuj logikę wyboru danych: Napisz podstawowe zapytania ABAP SQL, aby wyodrębnić dane dla każdej z 14 wymaganych czynności. W tym celu pobierz dane z tabel głównych, takich jak BKPF (nagłówek) i BSEG (pozycja), tabel dziennika zmian CDHDR i CDPOS, tabel workflow, takich jak SWWLOGHIST, oraz tabel rozliczeń, takich jak BSAS i BSAK.
- Wyodrębnij dokumenty wstępnie wprowadzone i zaksięgowane: W przypadku zdarzeń „Wstępnie wprowadzono zapis księgowy” wybierz z BKPF dokumenty, których status (BSTAT) ma wartość „V”. W przypadku zdarzeń „Utworzono zapis księgowy” i „Zaksięgowano zapis księgowy” wybierz z BKPF dokumenty z pustym statusem, co oznacza zwykły, zaksięgowany dokument.
- Wyodrębnij zdarzenia zmian i usunięć: Odpytaj tabele dokumentów zmian CDHDR i CDPOS dla klasy obiektu „BELEG”. Zastosuj filtr na kluczu dokumentu, aby znaleźć zmiany odpowiadające czynnościom „Skorygowano zapis księgowy” lub „Usunięto wstępnie wprowadzony zapis księgowy”.
- Wyodrębnij zdarzenia workflow: Aby zarejestrować czynności takie jak „Przekazano zapis księgowy”, „Zatwierdzono”, „Odrzucono” i „Zażądano zmian”, odpytaj tabele workflow. Użyj tabeli SWW_WI2OBJ, aby powiązać dokument księgowy z instancją workflow, a następnie odczytaj z SWWLOGHIST decyzje użytkowników lub zmiany statusu.
- Zidentyfikuj zdarzenia obliczane: W przypadku czynności „Zidentyfikowano ręczny zapis” sprawdź kod transakcji (BKPF-TCODE) względem listy znanych kodów transakcji używanych do ręcznego wprowadzania. Aby zidentyfikować księgowania między spółkami, przeanalizuj pozycje BSEG danego dokumentu i sprawdź, czy dotyczą wielu kodów spółek.
- Połącz i przekształć dane: Po wybraniu danych dla każdej czynności przekształć je do końcowej struktury dziennika zdarzeń. Połącz kod spółki, numer dokumentu i rok obrotowy, aby utworzyć JournalEntryId. Połącz daty i godziny SAP w jeden znacznik czasu EventTime. Dodaj wyniki każdego zapytania do końcowej tabeli wewnętrznej.
- Zaimplementuj eksport pliku: Użyj instrukcji ABAP do obsługi plików, takich jak OPEN DATASET, LOOP AT, TRANSFER i CLOSE DATASET, aby zapisać połączoną tabelę wewnętrzną jako plik CSV lub plik tekstowy w katalogu serwera aplikacji SAP (dostępnym przez transakcję AL11).
- Zaplanuj zadanie w tle: Przejdź do transakcji SM36 (Define Background Job). Utwórz zadanie, dodaj krok uruchamiający program ABAP i ustaw harmonogram, na przykład codziennie w nocy lub co tydzień poza godzinami szczytu, aby zautomatyzować ekstrakcję.
- Pobierz i przygotuj plik: Użyj transakcji CG3Y lub poproś administratora systemu o pobranie wygenerowanego pliku z serwera aplikacji na komputer lokalny. Sprawdź, czy kodowanie i format pliku są odpowiednie do wczytania do narzędzia process mining.
Konfiguracja
- Zakres dat: Określenie zakresu dat ma zasadnicze znaczenie dla wydajności. Jako głównego filtra użyj daty utworzenia dokumentu (BKPF-CPUDT). Do wstępnej analizy zaleca się okres od 3 do 6 miesięcy. Na potrzeby testów wybierz kilka dni, o których wiadomo, że zawierają dane.
- Filtr kodu spółki: Zawsze filtruj dane według kodu spółki (BKPF-BUKRS). Jednoczesna ekstrakcja danych dla wszystkich kodów spółek może znacznie obciążyć zasoby. Zacznij od jednego lub kilku istotnych kodów spółek.
- Filtr typu dokumentu: Użyj filtra typu dokumentu (BKPF-BLART), aby ograniczyć zakres do wybranych typów zapisów księgowych, na przykład „SA” dla dokumentów księgi głównej, jeśli analiza nie musi obejmować wszystkich typów dokumentów.
- Identyfikatory zadań workflow: Logika ekstrakcji zdarzeń workflow zależy od identyfikatorów zadań używanych w systemie do zatwierdzania, odrzucania i przekazywania dokumentów. Należy skonfigurować je w kodzie źródłowym programu zgodnie z definicjami workflow w Państwa firmie.
- Wydajność: Program łączy kilka dużych tabel, zwłaszcza CDPOS i tabele historii workflow. Uruchomienie go w godzinach największego obciążenia może obniżyć wydajność systemu. Należy zaplanować zadanie w tle poza godzinami szczytu. Jeśli problemy z wydajnością się powtarzają, warto rozważyć utworzenie dodatkowych indeksów bazy danych.
- Wymagania wstępne: Ta metoda wymaga użytkownika z uprawnieniami do tworzenia programów ABAP (SE38) oraz uprawnieniami do tworzenia i zarządzania zadaniami w tle (SM36). Użytkownik lub zadanie musi też mieć dostęp do odczytu wszystkich odpowiednich tabel finansowych, workflow i systemowych (BKPF, BSEG, CDHDR, CDPOS, SWWLOGHIST itd.).
Przykładowe zapytanie abap
REPORT Z_PM_JE_EXTRACTION.
*&---------------------------------------------------------------------*
*& Data Structures for Final Event Log
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
journalentryid TYPE string,
activityname TYPE string,
eventtime TYPE timestamp,
sourcesystem TYPE string,
lastdataupdate TYPE timestamp,
username TYPE uname,
companycode TYPE bukrs,
documenttype TYPE blart,
postingdate TYPE budat,
transactioncode TYPE tcode,
isreversed TYPE abap_bool,
END OF ty_event_log.
DATA: lt_final_log TYPE STANDARD TABLE OF ty_event_log.
DATA: ls_event TYPE ty_event_log.
*&---------------------------------------------------------------------*
*& Selection Screen Parameters
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_blart FOR bkpf-blart,
s_cpudt FOR bkpf-cpudt OBLIGATORY.
PARAMETERS: p_sysid TYPE sy-sysid DEFAULT sy-sysid.
*&---------------------------------------------------------------------*
*& Main Logic
*&---------------------------------------------------------------------*
START-OF-SELECTION.
DATA(lv_last_update) = cl_abap_context_info=>get_system_timestamp( ).
" 1. Journal Entry Parked
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
'Journal Entry Parked' AS activityname,
a~cpudt, a~cputm,
a~usnam AS username,
a~bukrs AS companycode,
a~blart AS documenttype,
a~bldat AS postingdate,
a~tcode AS transactioncode
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~bstat = 'V' " Parked Document
INTO TABLE @DATA(lt_parked).
IF sy-subrc = 0.
LOOP AT lt_parked ASSIGNING FIELD-SYMBOL(<fs_parked>).
ls_event-journalentryid = <fs_parked>-journalentryid.
ls_event-activityname = <fs_parked>-activityname.
CONVERT DATE <fs_parked>-cpudt TIME <fs_parked>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_parked>-username.
ls_event-companycode = <fs_parked>-companycode.
ls_event-documenttype = <fs_parked>-documenttype.
ls_event-postingdate = <fs_parked>-postingdate.
ls_event-transactioncode = <fs_parked>-transactioncode.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 2. Journal Entry Created (directly posted, not parked first)
" 9. Journal Entry Posted
" These two events happen at the same time for a direct posting.
SELECT CONCAT( bukrs, belnr, gjahr ) AS journalentryid,
cpudt, cputm, usnam, bukrs, blart, budat, tcode, stblg
FROM bkpf
WHERE bukrs IN s_bukrs
AND blart IN s_blart
AND cpudt IN s_cpudt
AND bstat = '' " Normal, posted document
INTO TABLE @DATA(lt_posted).
IF sy-subrc = 0.
LOOP AT lt_posted ASSIGNING FIELD-SYMBOL(<fs_posted>).
" Activity: Journal Entry Created
ls_event-journalentryid = <fs_posted>-journalentryid.
ls_event-activityname = 'Journal Entry Created'.
CONVERT DATE <fs_posted>-cpudt TIME <fs_posted>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_posted>-usnam.
ls_event-companycode = <fs_posted>-bukrs.
ls_event-documenttype = <fs_posted>-blart.
ls_event-postingdate = <fs_posted>-budat.
ls_event-transactioncode = <fs_posted>-tcode.
ls_event-isreversed = COND #( WHEN <fs_posted>-stblg IS NOT INITIAL THEN abap_true ELSE abap_false ).
APPEND ls_event TO lt_final_log.
" Activity: Journal Entry Posted
ls_event-activityname = 'Journal Entry Posted'.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 3. Documentation Attached (via GOS)
SELECT a~instid_a, c~cr_timestamp
FROM srgbtbrel AS a
INNER JOIN sood AS b ON a~instid_b = b~objid
INNER JOIN socf AS c ON b~filid = c~filid
WHERE a~typeid_a = 'BKPF'
AND a~bukrs IN s_bukrs
INTO TABLE @DATA(lt_attachments).
IF sy-subrc = 0.
LOOP AT lt_attachments ASSIGNING FIELD-SYMBOL(<fs_attach>).
ls_event-journalentryid = |{ <fs_attach>-instid_a(4) }{ <fs_attach>-instid_a+4(10) }{ <fs_attach>-instid_a+14(4) }|.
ls_event-activityname = 'Documentation Attached'.
ls_event-eventtime = <fs_attach>-cr_timestamp.
" Other attributes may need to be looked up from BKPF if needed.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 4, 5, 6, 7, 8: Workflow events (Submitted, Changes Requested, Corrected, Approved, Rejected)
" This is a simplified example. Real logic depends on specific workflow templates.
SELECT a~instid, b~wi_cd, b~wi_ct, b~wi_aagent, b~wi_text
FROM sww_wi2obj AS a
INNER JOIN swwloghist AS b ON a~wi_id = b~wi_id
WHERE a~typeid = 'BKPF'
AND a~catid = 'BO'
AND a~bukrs IN s_bukrs
AND b~wi_cd BETWEEN s_cpudt-low AND s_cpudt-high
INTO TABLE @DATA(lt_workflow).
IF sy-subrc = 0.
LOOP AT lt_workflow ASSIGNING FIELD-SYMBOL(<fs_wf>).
ls_event-journalentryid = |{ <fs_wf>-instid(4) }{ <fs_wf>-instid+4(10) }{ <fs_wf>-instid+14(4) }|.
ls_event-activityname = CASE <fs_wf>-wi_text. " Simplified logic based on work item text
WHEN '[Placeholder for Submit Text]' THEN 'Journal Entry Submitted'
WHEN '[Placeholder for Approve Text]' THEN 'Journal Entry Approved'
WHEN '[Placeholder for Reject Text]' THEN 'Journal Entry Rejected'
WHEN '[Placeholder for Rework Text]' THEN 'Journal Entry Changes Requested'
ELSE ''
ENDCASE.
IF ls_event-activityname IS NOT INITIAL.
CONVERT DATE <fs_wf>-wi_cd TIME <fs_wf>-wi_ct INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_wf>-wi_aagent.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
ENDIF.
" 10. Manual Entry Identified & 11. Cross-Company Posting Identified
SELECT bukrs, belnr, gjahr, tcode FROM bkpf
WHERE bukrs IN s_bukrs AND blart IN s_blart AND cpudt IN s_cpudt
INTO TABLE @DATA(lt_calc_base).
LOOP AT lt_calc_base ASSIGNING FIELD-SYMBOL(<fs_calc>).
ls_event-journalentryid = |{ <fs_calc>-bukrs }{ <fs_calc>-belnr }{ <fs_calc>-gjahr }|.
" Check for manual entry T-Codes
IF <fs_calc>-tcode = 'FB01' OR <fs_calc>-tcode = 'F-02' OR <fs_calc>-tcode = 'FB50'.
ls_event-activityname = 'Manual Entry Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
" Check for cross-company posting
SELECT SINGLE bukrs FROM bseg WHERE belnr = <fs_calc>-belnr AND gjahr = <fs_calc>-gjahr AND bukrs <> <fs_calc>-bukrs INTO @DATA(lv_cross_bukrs).
IF sy-subrc = 0.
ls_event-activityname = 'Cross-Company Posting Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 12. Journal Entry Line Item Cleared
SELECT a~bukrs, a~belnr, a~gjahr, a~augdt, a~augbl
FROM bsas AS a " G/L Cleared Items
WHERE a~bukrs IN s_bukrs
AND a~budat IN s_cpudt
INTO TABLE @DATA(lt_cleared_gl).
IF sy-subrc = 0.
LOOP AT lt_cleared_gl ASSIGNING FIELD-SYMBOL(<fs_clr>).
ls_event-journalentryid = |{ <fs_clr>-bukrs }{ <fs_clr>-belnr }{ <fs_clr>-gjahr }|.
ls_event-activityname = 'Journal Entry Line Item Cleared'.
CONVERT DATE <fs_clr>-augdt INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
" User is often not directly available for clearing events
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 13. Parked Journal Entry Deleted & 6. Journal Entry Corrected
SELECT objectid, changenr, username, udate, utime FROM cdhdr
WHERE objectclas = 'BELEG'
AND udate IN s_cpudt
INTO TABLE @DATA(lt_cdhdr).
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
SELECT SINGLE tcode FROM cdpos WHERE changenr = <fs_cdhdr>-changenr AND fname = 'BSTAT' AND value_new = 'Z' INTO @DATA(lv_deleted_tcode).
ls_event-journalentryid = |{ <fs_cdhdr>-objectid(4) }{ <fs_cdhdr>-objectid+4(10) }{ <fs_cdhdr>-objectid+14(4) }|.
CONVERT DATE <fs_cdhdr>-udate TIME <fs_cdhdr>-utime INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_cdhdr>-username.
IF sy-subrc = 0.
ls_event-activityname = 'Parked Journal Entry Deleted'.
APPEND ls_event TO lt_final_log.
ELSE.
ls_event-activityname = 'Journal Entry Corrected'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 14. Journal Entry Reversal Processed
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
a~cpudt, a~cputm, a~usnam
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~stblg IS NOT NULL " Document is a reversal
INTO TABLE @DATA(lt_reversals).
IF sy-subrc = 0.
LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
ls_event-journalentryid = <fs_rev>-journalentryid.
ls_event-activityname = 'Journal Entry Reversal Processed'.
CONVERT DATE <fs_rev>-cpudt TIME <fs_rev>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_rev>-usnam.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" Final step: Output to file
DATA(lv_filename) = |/tmp/je_extraction_{ sy-datum }_{ sy-uzeit }.csv|.
OPEN DATASET lv_filename FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc = 0.
" Write header
DATA(lv_header) = 'JournalEntryId,ActivityName,EventTime,SourceSystem,LastDataUpdate,User,CompanyCode,DocumentType,PostingDate,TransactionCode,IsReversed'.
TRANSFER lv_header TO lv_filename.
LOOP AT lt_final_log INTO ls_event.
DATA(lv_line) = |"{ ls_event-journalentryid }","|
|{ ls_event-activityname }","|
|{ ls_event-eventtime }","|
|{ ls_event-sourcesystem }","|
|{ ls_event-lastdataupdate }","|
|{ ls_event-username }","|
|{ ls_event-companycode }","|
|{ ls_event-documenttype }","|
|{ ls_event-postingdate }","|
|{ ls_event-transactioncode }","|
|{ ls_event-isreversed }"|.
TRANSFER lv_line TO lv_filename.
ENDLOOP.
CLOSE DATASET lv_filename.
ENDIF. Kroki
- Nawiąż połączenie z bazą danych: Uzyskaj dane logowania z uprawnieniami tylko do odczytu do bazy SAP ECC. Połącz się z bazą za pomocą standardowego klienta SQL, takiego jak DBeaver, SAP HANA Studio lub SQL Server Management Studio.
- Przygotuj zapytanie SQL: Skopiuj pełne zapytanie SQL z sekcji „query” tego dokumentu do klienta SQL.
- Ustaw parametry ekstrakcji: Przed uruchomieniem skonfiguruj symbole zastępcze w zapytaniu. Zastąp „[START_DATE]” i „[END_DATE]” wybranym zakresem dat w formacie „YYYYMMDD”. Zastąp „[COMPANY_CODE_1]”, „[COMPANY_CODE_2]” kodami spółek SAP, które mają zostać uwzględnione w analizie.
- Określ system źródłowy: W głównej instrukcji
SELECTzastąp symbol zastępczy „[Your SAP System ID]” rzeczywistym identyfikatorem systemu SAP (SID), aby prawidłowo wskazać źródło danych. - Uruchom zapytanie: Wykonaj skonfigurowane zapytanie SQL w bazie SAP. Czas wykonania zależy od zakresu dat i wielkości tabel w bazie.
- Sprawdź wstępne wyniki: Po zakończeniu zapytania przejrzyj pobrane wiersze i upewnij się, że dane są wypełnione zgodnie z oczekiwaniami. Sprawdź, czy występują różne czynności oraz czy ważne pola, takie jak
JournalEntryIdiEventTime, nie są puste. - Obsłuż znaczniki czasu: Zapytanie łączy pola daty i godziny w ciąg znaków
YYYYMMDDHHMMSS. Upewnij się, że dalsze przetwarzanie lub system docelowy potrafi odczytać ten format. Jeśli baza danych na to pozwala, można zmienić funkcję SQLCONCAT, aby uzyskać format ISO 8601, na przykładYYYY-MM-DDTHH:MI:SS. - Wyeksportuj dane: Wyeksportuj pełny zestaw wyników z klienta SQL do pliku CSV. Użyj kodowania UTF-8, aby uniknąć problemów ze znakami specjalnymi.
- Przygotuj dane do wczytania: Przed wczytaniem do narzędzia process mining sprawdź, czy nagłówki kolumn odpowiadają wymaganemu schematowi danych. Pola
JournalEntryId,ActivityNameiEventTimesą niezbędne. Dodaj kolumnęLastDataUpdatei wpisz w niej znacznik czasu wykonania ekstrakcji. - Przeprowadź końcową weryfikację: Wykonaj czynności opisane w sekcji „validationSteps”, aby przed rozpoczęciem analizy sprawdzić kompletność i poprawność wyodrębnionych danych.
Konfiguracja
- Uprawnienia do bazy danych: Użytkownik bazy danych musi mieć dostęp do odczytu następujących tabel SAP: BKPF, BSEG, CDHDR, CDPOS, T001 i V_USERNAME. W przypadku czynności związanych z workflow potrzebny jest również dostęp do SWW_WI2OBJ i SWWLOGHIST. Taki poziom dostępu jest zazwyczaj przyznawany tylko wyspecjalizowanym zespołom technicznym.
- Filtrowanie według zakresu dat: Aby zapewnić wydajność zapytania, należy filtrować dane według określonego zakresu dat. W zapytaniu zastosowano symbole zastępcze daty początkowej i końcowej, które są używane do filtrowania według daty utworzenia dokumentu (
BKPF.CPUDT). Do wstępnej analizy zaleca się zakres od 3 do 6 miesięcy. - Filtrowanie według jednostki: Aby ograniczyć ilość danych i skupić analizę na wybranym zakresie, zawsze filtruj według kodu spółki (
BKPF.BUKRS). Można też użyć filtra typu dokumentu (BKPF.BLART), aby uwzględnić tylko odpowiednie typy zapisów księgowych, na przykład „SA” dla dokumentów księgi głównej, i wykluczyć dokumenty operacyjne, takie jak faktury lub płatności, jeśli nie są objęte zakresem analizy. - Wydajność: Bezpośrednie zapytania do głównych tabel, takich jak BSEG i CDPOS, mogą znacznie obciążać zasoby. Zaleca się uruchamianie ekstrakcji poza godzinami szczytu, aby nie wpływać na wydajność systemu podczas pracy użytkowników. Nie należy pobierać danych za okres dłuższy niż rok w jednym uruchomieniu.
- Identyfikatory zadań workflow: Zapytanie zawiera symbole zastępcze, takie jak „[WF_TASK_ID_SUBMIT]” i „[WF_TASK_ID_APPROVE]”. Należy zastąpić je identyfikatorami zadań używanymi w konfiguracji workflow zapisów księgowych w danym systemie. Można je ustalić z pomocą specjalisty SAP Workflow lub analizując techniczną definicję workflow w transakcji PFTC.
Przykładowe zapytanie sql
WITH DOC_HEADERS AS (
SELECT
BUKRS,
BELNR,
GJAHR,
BLART,
BLDAT,
BUDAT,
CPUDT,
CPUTM,
USNAM,
TCODE,
BSTAT,
STBLG,
XRECH
FROM BKPF
WHERE CPUDT BETWEEN '[START_DATE]' AND '[END_DATE]'
AND BUKRS IN ('[COMPANY_CODE_1]', '[COMPANY_CODE_2]')
)
-- Event 1: Journal Entry Created (Directly Posted)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = '' OR H.BSTAT = 'U'
UNION ALL
-- Event 2: Journal Entry Parked
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = 'V'
UNION ALL
-- Event 3: Journal Entry Posted (from Parked state)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT <> 'V'
AND P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW <> 'V'
UNION ALL
-- Event 4: Parked Journal Entry Deleted
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Parked Journal Entry Deleted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND C.TCODE = 'FBV0'
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW = 'Z'
UNION ALL
-- Event 5: Journal Entry Reversal Processed
SELECT
CONCAT(H.BUKRS, H.STBLG, H.GJAHR) AS "JournalEntryId", -- Linking to the original document
'Journal Entry Reversal Processed' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
TRUE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.STBLG IS NOT NULL AND H.STBLG <> ''
UNION ALL
-- Event 6: Journal Entry Line Item Cleared
SELECT
CONCAT(B.BUKRS, B.BELNR, B.GJAHR) AS "JournalEntryId",
'Journal Entry Line Item Cleared' AS "ActivityName",
TO_TIMESTAMP(B.AUGDT, 'YYYYMMDD') AS "EventTime", -- Clearing date used as event time
U.NAME_TEXT AS "User",
B.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode", -- Clearing transaction is in the clearing document header, complex to retrieve here
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM BSEG B
JOIN DOC_HEADERS H ON B.BUKRS = H.BUKRS AND B.BELNR = H.BELNR AND B.GJAHR = H.GJAHR
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE B.AUGBL IS NOT NULL AND B.AUGBL <> '' AND B.AUGDT <> '00000000'
UNION ALL
-- Event 7: Journal Entry Corrected (changes to a parked document)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT = 'V' AND C.TCODE IN ('FBV2', 'FBV4') -- FBV2 is change parked doc, FBV4 is change parked doc header
UNION ALL
-- Event 8: Documentation Attached (inferred from GOS attachment creation, requires configuration)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(CONCAT(REL.RECDATE, '000000'), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SRGBTBREL REL ON REL.INSTID_A = CONCAT('BUS2081', H.BUKRS, H.BELNR, H.GJAHR) -- BUS2081 is object type for BKPF
LEFT JOIN V_USERNAME U ON REL.RECUNAM = U.BNAME
WHERE REL.TYPEID_A = 'BUS2081' AND REL.RELTYPE = 'ATTA'
UNION ALL
-- Events 9-13 from Workflow (Submitted, Changes Requested, Approved, Rejected) requires specific workflow config
-- This is a generic template. The WI_RH_TASK must be adapted to your system.
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
CASE
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_SUBMIT]' THEN 'Journal Entry Submitted'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_APPROVE]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Approved'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_REJECT]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Rejected'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_CHANGES_REQ]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Changes Requested'
ELSE NULL
END AS "ActivityName",
TO_TIMESTAMP(CONCAT(LOG.EVT_DATE, LOG.EVT_TIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SWW_WI2OBJ WIOBJ ON WIOBJ.INSTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND WIOBJ.TYPEID = 'BKPF'
JOIN SWWLOGHIST LOG ON WIOBJ.WI_ID = LOG.WI_ID
LEFT JOIN V_USERNAME U ON LOG.EXEC_USER = U.BNAME
WHERE LOG.WI_RH_TASK IN ('[WF_TASK_ID_SUBMIT]', '[WF_TASK_ID_APPROVE]', '[WF_TASK_ID_REJECT]', '[WF_TASK_ID_CHANGES_REQ]')
UNION ALL
-- Event 14: Manual Entry Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Manual Entry Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.TCODE IN ('FB01', 'F-02', 'FB50', 'F-04', 'F-22', 'F-43', 'FB60', 'FB70', 'FV50', 'FV60', 'FV70')
UNION ALL
-- Event 15: Cross-Company Posting Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Cross-Company Posting Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.XRECH = 'X' Kroki
- Konfiguracja połączenia z SAP: W zewnętrznym narzędziu ETL skonfiguruj nowe połączenie źródłowe z systemem SAP ECC. Zwykle potrzebne są dane serwera aplikacji, klient, numer systemu oraz dedykowane konto SAP z wymaganymi uprawnieniami RFC.
- Definiowanie źródeł danych: W projekcie ekstrakcji dodaj wymagane tabele SAP jako źródła danych. Główne tabele to BKPF (nagłówek dokumentu księgowego), BSEG (pozycje dokumentu księgowego), VBSEGK (nagłówek zaparkowanego dokumentu), CDHDR (nagłówek zmiany), CDPOS (pozycje zmiany), SWW_WI2OBJ (powiązania workflow z obiektami), SWWLOGHIST (dziennik workflow) oraz SRGBTBREL (powiązania załączników GOS).
- Ekstrakcja zdarzeń podstawowych (utworzenie i zaparkowanie): Utwórz pierwszy przepływ danych, aby pobrać zdarzenia początkowe. Dla zdarzenia „Zaparkowano zapis księgowy” użyj tabeli VBSEGK. Dla zdarzenia „Utworzono zapis księgowy” użyj BKPF, filtrując dokumenty tak, aby wykluczyć storna i dokumenty pierwotnie zaparkowane. Można to zrobić za pomocą antyzłączenia z VBSEGK.
- Ekstrakcja zdarzeń workflow: Utwórz przepływ danych, który łączy BKPF z SWW_WI2OBJ za pomocą klucza obiektu (kod spółki + numer dokumentu + rok obrotowy), aby znaleźć identyfikator instancji workflow. Połącz wynik z SWWLOGHIST, aby pobrać zdarzenia takie jak „Przesłano”, „Zatwierdzono”, „Odrzucono” i „Zażądano zmian”, na podstawie wyników zadań workflow i decyzji użytkowników zapisanych w dzienniku.
- Ekstrakcja zdarzeń zmian i usunięć: Użyj tabel CDHDR i CDPOS, aby zidentyfikować zmiany. W przypadku zdarzenia „Skorygowano zapis księgowy” filtruj zmiany wprowadzone w zaparkowanych dokumentach (klasa obiektu „FIPP”). Aby wykryć zdarzenie „Usunięto zaparkowany zapis księgowy”, szukaj znaczników usunięcia w dziennikach zmian zaparkowanych dokumentów.
- Ekstrakcja zdarzeń dotyczących załączników: Aby zarejestrować zdarzenie „Dołączono dokumentację”, połącz BKPF z SRGBTBREL, gdzie typ obiektu to „BKPF”, a typ powiązania to „[typ powiązania załącznika]”. Data utworzenia powiązania określa czas zdarzenia.
- Ekstrakcja zdarzeń rozliczenia i storna: W przypadku zdarzenia „Rozliczono pozycję zapisu księgowego” odpytaj tabelę BSEG i wybierz wiersze z wypełnionym polem dokumentu rozliczającego (AUGBL). Czasem zdarzenia jest data księgowania dokumentu rozliczającego (AUGDT). Aby zarejestrować zdarzenie „Przetworzono storno zapisu księgowego”, odpytaj BKPF i wybierz dokumenty będące stornami, czyli mające wartość w polu dokumentu storna (STBLG).
- Wyznaczanie zdarzeń obliczanych: Utwórz osobne bloki logiki dla zdarzeń obliczanych. Dla zdarzenia „Zidentyfikowano zapis ręczny” filtruj BKPF według listy kodów transakcji ręcznych (np. FB01, FB50, F-02). Dla zdarzenia „Zidentyfikowano księgowanie między spółkami” pogrupuj tabelę BSEG według identyfikatora dokumentu i wybierz dokumenty z więcej niż jednym różnym kodem spółki.
- Połączenie wszystkich przepływów zdarzeń: Użyj transformacji UNION w narzędziu ETL, aby połączyć wyniki poszczególnych przepływów zdarzeń (utworzenie, zaparkowanie, zatwierdzenie itd.) w jednej tabeli dziennika zdarzeń. Nazwy kolumn i typy danych muszą być spójne we wszystkich przepływach.
- Mapowanie do schematu docelowego: Zmapuj połączone dane do wymaganej struktury dziennika zdarzeń, tworząc atrybuty
JournalEntryId,ActivityName,EventTime,Useroraz pozostałe wymagane i zalecane atrybuty. Dodaj kolumny statyczne, takie jakSourceSystem, a jako wartośćLastDataUpdatewykorzystaj czas wykonania zadania ETL. - Konfiguracja ładowania przyrostowego: Przy kolejnych ekstrakcjach skonfiguruj strategię ładowania przyrostowego. Użyj daty utworzenia lub zmiany (np. BKPF.CPUDT, CDHDR.UDATE) jako znacznika, aby pobierać tylko nowe lub zaktualizowane rekordy od ostatniego uruchomienia.
- Eksport do ProcessMind: Zaplanuj zadanie ekstrakcji i skonfiguruj końcowy etap tak, aby zapisywał dziennik zdarzeń w pliku CSV lub Parquet w lokalizacji dostępnej dla ProcessMind, skąd można go przesłać.
Konfiguracja
- Wymagania wstępne: Licencjonowane zewnętrzne narzędzie ETL (np. Theobald Xtract Universal, Informatica, Talend) z dedykowanym konektorem SAP. Konto SAP z dostępem RFC i uprawnieniami do odczytu tabel finansowych (np. S_TABU_DIS dla grup tabel F_00, F_WF), danych workflow i dzienników zmian.
- Parametry połączenia: Potrzebny będzie adres IP lub nazwa hosta serwera aplikacji SAP, numer systemu i identyfikator klienta. Nazwę użytkownika SAP i hasło należy przechowywać w bezpieczny sposób.
- Najważniejsze filtry: Zawsze stosuj filtry dla kodu spółki (BKPF.BUKRS) i roku obrotowego (BKPF.GJAHR) już w źródle, aby ograniczyć ilość danych. Zaleca się również filtrowanie według daty utworzenia dokumentu (BKPF.CPUDT), aby określić okres ekstrakcji, na przykład ostatnie 6 miesięcy.
- Wybór zakresu dat: Przy pierwszym ładowaniu wybierz reprezentatywny okres, na przykład od 3 do 6 miesięcy. Przy kolejnych ładowaniach przyrostowych użyj znacznika opartego na polu czasu, takim jak
CPUDT, aby pobierać tylko nowe rekordy. - Wydajność: Złączenia tabel BSEG, CDPOS i tabel workflow mogą działać bardzo wolno. Jeśli to możliwe, skonfiguruj narzędzie ETL tak, aby przekazywało filtry do źródła SAP. Jeśli narzędzie na to pozwala, pobieraj dane w mniejszych partiach, szczególnie przy ładowaniu dużej ilości danych historycznych.
- Dostosowanie workflow: Sposób identyfikowania działań workflow, takich jak „Zatwierdzono” lub „Odrzucono”, zależy w dużej mierze od używanych szablonów workflow. W systemie trzeba ustalić właściwe identyfikatory zadań workflow i klucze decyzji użytkowników, które zostaną użyte w filtrach.
Przykładowe zapytanie sql
/*
This is a logical representation of the extraction configuration in a third-party ETL tool.
It is not executable SQL but defines the sources, joins, and transformations for each activity.
Placeholders like [Your SAP Source], [Date Filter], and [Company Code Filter] must be configured in the tool.
*/
-- Extraction block for 'Journal Entry Parked'
SELECT
CONCAT(v.BUKRS, v.VBELN, v.GJAHR) AS JournalEntryId,
'Journal Entry Parked' AS ActivityName,
CAST(CONCAT(v.CPUDT, v.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
v.USNAM AS User,
v.BUKRS AS CompanyCode,
v.BLART AS DocumentType,
v.BUDAT AS PostingDate,
v.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].VBSEGK v
WHERE [Date Filter on v.CPUDT] AND [Company Code Filter on v.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Created'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Created' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
LEFT JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE h.BSTAT = '' AND v.VBELN IS NULL AND h.STBLG IS NULL
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Posted' (from parked)
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Posted' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Or a more precise posting time from change logs if available
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Submitted', 'Approved', 'Rejected', 'Changes Requested'
SELECT
CONCAT(SUBSTRING(o.INSTID, 3, 4), SUBSTRING(o.INSTID, 7, 10), SUBSTRING(o.INSTID, 17, 4)) AS JournalEntryId,
CASE
WHEN wl.WI_TEXT LIKE '%Submit%' THEN 'Journal Entry Submitted'
WHEN wl.WI_TEXT LIKE '%Approve%' THEN 'Journal Entry Approved'
WHEN wl.WI_TEXT LIKE '%Reject%' THEN 'Journal Entry Rejected'
WHEN wl.WI_TEXT LIKE '%Request Changes%' THEN 'Journal Entry Changes Requested'
END AS ActivityName,
CAST(CONCAT(wl.WI_CD, wl.WI_CT) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
wl.EXEC_USER AS User,
SUBSTRING(o.INSTID, 3, 4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SWW_WI2OBJ o
JOIN [Your SAP Source].SWWLOGHIST wl ON o.WI_ID = wl.WI_ID
WHERE o.TYPEID = 'BKPF' AND o.CATID = 'BO'
AND wl.WI_TEXT IN ('[Your Submit Task Name]', '[Your Approve Task Name]', '[Your Reject Task Name]', '[Your Changes Request Task Name]')
AND [Date Filter on wl.WI_CD]
UNION ALL
-- Extraction block for 'Journal Entry Corrected'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Journal Entry Corrected' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'U'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Parked Journal Entry Deleted'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Parked Journal Entry Deleted' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'D'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Documentation Attached'
SELECT
CONCAT(SUBSTRING(r.INSTID_A, 3, 4), SUBSTRING(r.INSTID_A, 7, 10), SUBSTRING(r.INSTID_A, 17, 4)) AS JournalEntryId,
'Documentation Attached' AS ActivityName,
-- Note: A precise timestamp is often unavailable. Using document creation time as a proxy.
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SRGBTBREL r
JOIN [Your SAP Source].BKPF h ON h.BUKRS = SUBSTRING(r.INSTID_A, 3, 4) AND h.BELNR = SUBSTRING(r.INSTID_A, 7, 10) AND h.GJAHR = SUBSTRING(r.INSTID_A, 17, 4)
WHERE r.TYPEID_A = 'BKPF' AND r.RELTYPE = '[Configure based on your system]'
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Reversal Processed'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Reversal Processed' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.STBLG IS NOT NULL AND h.STBLG <> ''
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Is Reversed' flag on original document
SELECT
CONCAT(h_orig.BUKRS, h_orig.BELNR, h_orig.GJAHR) AS JournalEntryId,
'Is Reversed' AS ActivityName, -- This is an attribute update, modeled as an event
CAST(CONCAT(h_rev.CPUDT, h_rev.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h_rev.USNAM AS User,
h_orig.BUKRS AS CompanyCode,
h_orig.BLART AS DocumentType,
h_orig.BUDAT AS PostingDate,
h_orig.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h_rev
JOIN [Your SAP Source].BKPF h_orig ON h_rev.STBLG = h_orig.BELNR AND h_rev.BUKRS = h_orig.BUKRS AND h_rev.GJAHR_S = h_orig.GJAHR
WHERE h_rev.STBLG IS NOT NULL AND h_rev.STBLG <> ''
AND [Date Filter on h_rev.CPUDT] AND [Company Code Filter on h_rev.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Line Item Cleared'
SELECT
CONCAT(i.BUKRS, i.BELNR, i.GJAHR) AS JournalEntryId,
'Journal Entry Line Item Cleared' AS ActivityName,
CAST(i.AUGDT AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
NULL AS User, -- User who performed clearing is on the clearing document header
i.BUKRS AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BSEG i
WHERE i.AUGBL IS NOT NULL AND i.AUGBL <> ''
AND [Date Filter on i.AUGDT] AND [Company Code Filter on i.BUKRS]
UNION ALL
-- Extraction block for 'Manual Entry Identified'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Manual Entry Identified' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.TCODE IN ('FB01', 'F-02', 'FB50', 'FV50', '[Add other manual T-Codes]')
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Cross-Company Posting Identified'
SELECT
JournalEntryId,
'Cross-Company Posting Identified' AS ActivityName,
EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
User,
CompanyCode,
DocumentType,
PostingDate,
TransactionCode,
IsReversed
FROM (
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed,
(SELECT COUNT(DISTINCT i.BUKRS) FROM [Your SAP Source].BSEG i WHERE i.BELNR = h.BELNR AND i.BUKRS = h.BUKRS AND i.GJAHR = h.GJAHR) as CompanyCodeCount
FROM [Your SAP Source].BKPF h
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
) AS CrossCompanyCheck
WHERE CompanyCodeCount > 1 Gotowi do rozpoczęcia?
Skorzystaj z tego szablonu danych, aby rozpocząć process mining dla procesu od zapisu do raportu, zapisy księgowe. Uzyskaj dokładniejszy obraz sytuacji i zwiększ sprawność operacji finansowych.
Usprawnij proces od zapisu do raportu, zapisy księgowe
Skróć czas cyklu obsługi zapisów księgowych o 30% i zadbaj o bezbłędne raportowanie.
Nie trzeba podawać danych karty kredytowej. Usprawnienia można rozpocząć już dziś.