Szablon danych dla procesu Record to Report, księgowanie
Szablon danych dla procesu Record to Report, księgowanie
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia
- Praktyczne wskazówki dotyczące ekstrakcji danych
Atrybuty procesu Record to Report, księgowanie
| Nazwa | Opis | ||
|---|---|---|---|
| Czas zdarzenia EventTime | Znacznik czasu wskazujący, kiedy miało miejsce określone działanie dotyczące zapisu księgowego. | ||
| Opis Czas zdarzenia to dokładna data i godzina wykonania działania biznesowego i zapisania go w systemie. Każde działanie w danym case ma własny znacznik czasu, co tworzy chronologiczną sekwencję zdarzeń. Ten atrybut ma zasadnicze znaczenie dla analizy procesu w ujęciu czasowym. Służy do obliczania czasu cyklu, czasu między działaniami i czasu oczekiwania, a także do analizy rozkładu pracy w czasie. Dokładne znaczniki czasu są niezbędne do zbudowania wiarygodnego modelu procesu i obliczania wskaźników efektywności, takich jak czas cyklu akceptacji. Dlaczego to ważne Określa chronologiczną kolejność zdarzeń, niezbędną do obliczania wszystkich miar czasu i analizy przebiegu procesu. Skąd pobrać Pochodzi z dzienników zmian dokumentu (CDHDR-UDATE, CDHDR-UTIME), dzienników workflow lub znaczników czasu utworzenia i wprowadzenia w tabelach takich jak BKPF (CPUDT, CPUTM). Przykłady 2023-10-26T10:05:00Z2023-11-15T14:30:15Z2024-01-20T09:00:45Z | |||
| Działanie ActivityName | Nazwa działania biznesowego, które miało miejsce na określonym etapie procesu obsługi zapisu księgowego. | ||
| Opis Działanie oznacza konkretny etap lub zdarzenie w cyklu życia zapisu księgowego, na przykład „Utworzono zapis księgowy”, „Zapis księgowy przesłany do weryfikacji” lub „Zaksięgowano zapis księgowy”. Działania te zazwyczaj ustala się na podstawie dzienników zmian, aktualizacji statusu lub kodów transakcji zapisanych w systemie. Analiza działań pozwala zwizualizować przebieg procesu, wskazać typowe ścieżki i wykryć odstępstwa od standardowej procedury. Jest też podstawą do obliczania takich miar jak częstotliwość działań, czas oczekiwania między etapami i poziom zgodności. Dlaczego to ważne Określa etapy procesu, umożliwiając tworzenie map procesów i analizę wzorców workflow. Skąd pobrać Ustalane na podstawie różnych źródeł, w tym pól statusu w tabelach nagłówkowych i pozycji (np. BKPF-BSTAT), dzienników zmian dokumentu (CDHDR/CDPOS) oraz dzienników workflow. Przykłady Utworzono zapis księgowyZapis księgowy wstrzymanyZapis księgowy przesłany do weryfikacjiZapis księgowy zaakceptowanyZaksięgowano zapis księgowy | |||
| Identyfikator zapisu księgowego JournalEntryId | Unikatowy identyfikator zapisu księgowego, który służy jako główny identyfikator case w procesie. | ||
| Opis Identyfikator zapisu księgowego to unikatowy numer nadawany każdemu dokumentowi księgowemu podczas jego tworzenia w SAP S/4HANA. Umożliwia śledzenie całego cyklu życia zapisu, od utworzenia lub zaparkowania, przez workflow akceptacji, aż po zaksięgowanie, ewentualne storno lub rozliczenie. W analizie process mining ten identyfikator służy do łączenia wszystkich powiązanych działań w jeden case. Grupując zdarzenia według wspólnego identyfikatora zapisu księgowego, analitycy mogą odtworzyć przebieg procesu od początku do końca, zmierzyć czas cyklu i wykryć różnice lub wąskie gardła w poszczególnych transakcjach finansowych. To podstawowy atrybut potrzebny do zbudowania pełnego obrazu procesu. Dlaczego to ważne Ten identyfikator łączy wszystkie powiązane etapy procesu, umożliwiając analizę pełnego przebiegu każdego zapisu księgowego. Skąd pobrać To klucz złożony, zwykle utworzony przez połączenie kodu jednostki gospodarczej (BKPF-BUKRS), numeru dokumentu (BKPF-BELNR) i roku obrotowego (BKPF-GJAHR). Przykłady 1000-1000000001-20231710-1900000055-20242000-2100003412-2023 | |||
| Data księgowania PostingDate | Data zaksięgowania dekretu w księdze głównej, która wpływa na okres sprawozdawczy. | ||
| Opis Data księgowania określa rok obrotowy, w którym transakcja zostanie ujęta w sprawozdaniach finansowych. Jest istotna z punktu widzenia księgowości i może różnić się od daty utworzenia dokumentu lub wprowadzenia go do systemu. W process mining data księgowania służy do analizy kohort w czasie, na przykład porównywania procesów zamknięcia miesiąca lub badania trendów w różnych okresach sprawozdawczych. Pozwala też mierzyć opóźnienie między utworzeniem dekretu a jego zaksięgowaniem. Dlaczego to ważne Pozwala analizować wyniki procesu w określonych okresach księgowych, na przykład przy zamknięciu miesiąca lub roku. Skąd pobrać Tabela BKPF w SAP S/4HANA, pole BUDAT (data księgowania dokumentu). Przykłady 2023-10-312023-11-012024-02-29 | |||
| Kod spółki CompanyCode | Unikalny identyfikator spółki lub jednostki prawnej, dla której księgowany jest dekret. | ||
| Opis Kod spółki to podstawowa jednostka organizacyjna w SAP Financials. Reprezentuje niezależną jednostkę prawną, dla której sporządza się sprawozdania finansowe. Każdy dekret jest przypisany do konkretnego kodu spółki. Atrybut ten pozwala dzielić i porównywać wyniki procesu w różnych częściach organizacji. Analitycy mogą filtrować widok procesu według jednostki prawnej, porównywać odsetek odrzuceń między kodami spółek lub wykrywać różnice w przebiegu procesu w poszczególnych regionach. Dlaczego to ważne Umożliwia filtrowanie i porównywanie procesu dekretowania w różnych jednostkach prawnych lub jednostkach biznesowych organizacji. Skąd pobrać Tabela BKPF w SAP S/4HANA, pole BUKRS (kod spółki). Przykłady 10001710US01 | |||
| Kwota w walucie lokalnej AmountInLocalCurrency | Łączna wartość dekretu wyrażona w walucie lokalnej kodu spółki. | ||
| Opis Ten atrybut określa wartość finansową dekretu. Zazwyczaj jest to suma wartości bezwzględnych wszystkich pozycji debetowych lub kredytowych dokumentu, przeliczona na walutę lokalną kodu spółki. Analiza według kwoty pozwala podzielić proces ze względu na jego wpływ finansowy. Na przykład dekrety o wysokiej wartości mogą wymagać bardziej rygorystycznego zatwierdzania niż te o niskiej wartości. Ułatwia to ustalanie priorytetów przy ulepszaniu procesów i skupienie się na transakcjach wiążących się z największym ryzykiem finansowym. Dlaczego to ważne Podaje wartość finansową dekretu, co pozwala sprawdzić, jak przebieg procesu zależy od kwoty transakcji. Skąd pobrać Obliczana przez zsumowanie kwot z tabeli pozycji BSEG (pole DMBTR) dla danego dekretu (BELNR) i przeliczenie wyniku na wartość dodatnią. Przykłady 1500.75125000.0050.20 | |||
| Rodzaj dekretu JournalEntryType | Klasyfikuje dekret według celu biznesowego, na przykład księgowania środka trwałego, faktury dostawcy lub zapisu w księdze głównej. | ||
| Opis Rodzaj dekretu, określany w terminologii SAP jako typ dokumentu, to oznaczenie klasyfikujące dokumenty księgowe. Określa między innymi zakres numeracji dokumentu i dozwolone typy kont. Analiza procesu według rodzaju dekretu pomaga zrozumieć różnice w jego przebiegu zależnie od kontekstu. Na przykład zatwierdzanie prostego rozliczenia międzyokresowego (typ SA) może być znacznie prostsze niż zatwierdzanie złożonego nabycia środka trwałego (typ AA). Ten wymiar jest podstawą dashboardu „Zgodność według rodzaju dekretu”. Dlaczego to ważne Klasyfikuje dekrety według kontekstu biznesowego, umożliwiając analizę różnic w przebiegu i wynikach procesu dla różnych rodzajów transakcji finansowych. Skąd pobrać Tabela BKPF w SAP S/4HANA, pole BLART (typ dokumentu). Przykłady SAKRAA | |||
| Użytkownik, który utworzył CreatedByUser | Identyfikator użytkownika, który utworzył dekret. | ||
| Opis Ten atrybut przechowuje unikalny identyfikator użytkownika, który rozpoczął proces dekretowania, tworząc dokument źródłowy. Może to być księgowy, użytkownik biznesowy lub identyfikator systemu używany przy automatycznym wprowadzaniu zapisów. Analiza procesu według osoby tworzącej dokument pomaga wykrywać wzorce związane z konkretnymi użytkownikami lub zespołami. Może wskazać potrzeby szkoleniowe, jeśli niektóre osoby częściej spotykają się z odrzuceniem dokumentów, albo pomóc rozpoznać osoby osiągające dobre wyniki. Atrybut jest niezbędny w dashboardzie „Aktywność i wydajność użytkowników”. Dlaczego to ważne Przypisuje działania w procesie konkretnym użytkownikom, umożliwiając analizę wyników, równoważenie obciążenia pracą i identyfikację potrzeb szkoleniowych. Skąd pobrać Tabela BKPF w SAP S/4HANA, pole USNAM (nazwa użytkownika). Przykłady ABROWNCJONESBATCH_USER | |||
| Czas zakończenia EndTime | Znacznik czasu wskazujący, kiedy zakończyło się działanie. | ||
| Opis Czas zakończenia wskazuje, kiedy działanie dobiegło końca. W wielu dziennikach zdarzeń czas rozpoczęcia i zakończenia działania jest taki sam, co oznacza zdarzenie chwilowe. W przypadku działań o mierzalnym czasie trwania, takich jak aktywne sprawdzanie dokumentu przez użytkownika, ten atrybut pozwala zapisać ich długość. Osobny czas zakończenia umożliwia dokładniejsze obliczanie czasu realizacji działania i czasu oczekiwania. Pozwala odróżnić czas aktywnej pracy nad zadaniem od czasu, gdy zadanie czekało w kolejce. Dlaczego to ważne Umożliwia dokładne obliczenie czasu realizacji działania i oddzielenie aktywnej pracy od oczekiwania. Skąd pobrać W przypadku zdarzeń atomowych zwykle jest taki sam jak StartTime. Dla działań trwających w czasie może pochodzić z dzienników workflow lub być obliczany na podstawie kolejnych zdarzeń. Przykłady 2023-10-26T10:05:00Z2023-11-15T14:45:20Z2024-01-20T09:10:30Z | |||
| Czas zatwierdzania ApprovalCycleTime | Czas od przesłania dekretu do zatwierdzenia lub odrzucenia. | ||
| Opis Ta obliczana miara dotyczy czasu trwania etapu zatwierdzania. Mierzy czas między działaniem „Przesłano dekret do sprawdzenia” a kolejnym działaniem „Zatwierdzono dekret” lub „Odrzucono dekret”. KPI ten pomaga wykrywać wąskie gardła w workflow zatwierdzania. Długi czas akceptacji może znacznie opóźnić cały proces. Analiza tej miary według osoby zatwierdzającej, kodu spółki lub rodzaju dekretu może wskazać obszary wymagające poprawy. Dlaczego to ważne Pokazuje czas trwania etapu zatwierdzania, pomagając wskazać i usunąć wąskie gardła w workflow sprawdzania i akceptacji. Skąd pobrać Obliczany jako różnica czasu między zdarzeniem „Przesłano dekret do sprawdzenia” a zdarzeniem „Zatwierdzono dekret” lub „Odrzucono dekret”. Przykłady 1 dzień 2 godziny4 godziny 25 minut5 dni 0 godzin | |||
| Czy wymagał poprawy IsRework | Wartość logiczna wskazująca, czy dekret wymagał dodatkowej pracy, na przykład poprawienia po odrzuceniu. | ||
| Opis Ten obliczany atrybut oznacza dekrety, których przebieg odbiegał od standardowej ścieżki procesu. Zazwyczaj przyjmuje wartość true, jeśli w danym case wystąpiło działanie takie jak „Odrzucono dekret” lub „Poprawiono dekret”. Atrybut ułatwia analizę efektywności procesu. Pozwala szybko obliczyć KPI odsetka poprawek i bezpośrednio porównać czas realizacji oraz koszty spraw wymagających poprawek i tych, które ich nie wymagały. Ustalenie przyczyn poprawek jest jednym z głównych celów wielu inicjatyw związanych z ulepszaniem procesów. Dlaczego to ważne Oznacza sprawy wymagające poprawy lub dodatkowych obiegów, ułatwiając pomiar nieefektywności procesu i analizę ich przyczyn. Skąd pobrać To atrybut obliczany na podstawie sekwencji działań w danym case. Przyjmuje wartość „true”, jeśli wystąpiło działanie takie jak „Odrzucono dekret”. Przykłady truefalse | |||
| Czy zaksięgowano ręcznie IsManualPosting | Wartość logiczna wskazująca, czy użytkownik zaksięgował dekret ręcznie. | ||
| Opis Ten atrybut identyfikuje dekrety zaksięgowane ręcznie przez użytkownika, a nie automatycznie przez zadanie systemowe lub interfejs. Zazwyczaj jest wyznaczany na podstawie kodu transakcji użytego do zaksięgowania dokumentu. Atrybut służy do obliczania KPI odsetka ręcznych księgowań i pozwala śledzić postępy w automatyzacji procesu Record to Report. Filtrowanie ręcznie zaksięgowanych dekretów pomaga wskazać sytuacje, które nadal wymagają udziału człowieka, i ocenić ich potencjał do automatyzacji. Dlaczego to ważne Rozróżnia księgowania wykonane przez użytkowników i przez system, co pozwala mierzyć poziom automatyzacji i wskazywać możliwości jej zwiększenia. Skąd pobrać To atrybut obliczany na podstawie TransactionCode. Wartość „true” jest ustawiana dla kodów transakcji z wcześniej zdefiniowanej listy kodów ręcznych, na przykład „FB01” lub „F-02”. Przykłady truefalse | |||
| Data ostatniej aktualizacji danych LastDataUpdate | Znacznik czasu wskazujący, kiedy dane tego rekordu zostały ostatnio odświeżone z systemu źródłowego. | ||
| Opis Ten atrybut zapisuje datę i godzinę ostatniej ekstrakcji lub aktualizacji danych z systemu źródłowego. Informuje, jak aktualne są analizowane dane. Znajomość czasu ostatniej aktualizacji pomaga ocenić aktualność analizy procesu. Ułatwia też prawidłową interpretację dashboardów i KPI, ponieważ pokazuje, czy dane są niemal bieżące, czy pochodzą z wcześniejszego okresu. Dlaczego to ważne Informuje o aktualności danych, dzięki czemu wiadomo, jak bieżąca jest analiza procesu. Skąd pobrać To atrybut metadanych, zwykle generowany i zapisywany w każdym rekordzie podczas procesu wczytywania danych. Przykłady 2024-03-10T02:00:00Z2024-03-11T02:00:00Z2024-03-12T02:00:00Z | |||
| Kod transakcji TransactionCode | Kod transakcji SAP użyty do utworzenia lub zmiany dekretu. | ||
| Opis Kod transakcji (T-Code) to skrót identyfikujący konkretną funkcję lub program w SAP. W przypadku dekretów różne kody T-Code mogą wskazywać sposób ich utworzenia, na przykład FB01 oznacza ręczne księgowanie w księdze głównej, FV50 zapis wstępny, a kod automatyczny może oznaczać zapis wygenerowany przez system. Atrybut ten dobrze wskazuje, czy działanie wykonał ręcznie użytkownik, czy system. Jest potrzebny do obliczania KPI odsetka ręcznych księgowań i identyfikowania możliwości automatyzacji. Dlaczego to ważne Wskazuje, czy dekret przetworzono ręcznie, czy automatycznie. Pomaga analizować automatyzację i różnice w przebiegu procesu. Skąd pobrać Tabela BKPF w SAP S/4HANA, pole TCODE (kod transakcji). Przykłady FB01FV50F-02 | |||
| Przyczyna storna ReversalReason | Kod wskazujący przyczynę storna zaksięgowanego dekretu. | ||
| Opis Jeśli zaksięgowany dekret jest nieprawidłowy, nie można go usunąć. Należy go odwrócić za pomocą nowego dokumentu. Kod przyczyny storna wyjaśnia, dlaczego wykonano tę operację, na przykład z powodu nieprawidłowej daty księgowania lub kwoty. Analiza przyczyn storna pomaga wykrywać źródła błędów w procesie Record to Report. Częste występowanie konkretnej przyczyny może wskazywać na problemy systemowe, takie jak niewystarczające szkolenia lub nieskuteczne kontrole. Ich rozwiązanie pomaga poprawić jakość za pierwszym razem. Dlaczego to ważne Pomaga ustalić źródła błędów prowadzących do storna i wskazuje, jak ograniczyć poprawki oraz poprawić jakość procesu. Skąd pobrać Tabela BKPF w SAP S/4HANA, pole STGRD (przyczyna storna). Przykłady 010205 | |||
| Rok obrotowy FiscalYear | Rok obrotowy, do którego należy dekret. | ||
| Opis Rok obrotowy jest częścią unikalnego klucza dekretu, obok kodu spółki i numeru dokumentu. Określa rok finansowy, którego dotyczy dokument. W analizie rok obrotowy służy do badania długoterminowych trendów i zapewnienia unikalności identyfikatora case. Porównanie miar procesu z różnych lat obrotowych może ujawnić zmiany wyników w czasie. Dlaczego to ważne Jest niezbędny do jednoznacznej identyfikacji dokumentów i umożliwia porównywanie wyników procesu rok do roku. Skąd pobrać Tabela BKPF w SAP S/4HANA, pole GJAHR (rok obrotowy). Przykłady 202320242022 | |||
| Status dokumentu DocumentStatus | Bieżący status przetwarzania dekretu, na przykład wstępnie zapisany, zaksięgowany lub rozliczony. | ||
| Opis Status dokumentu określa etap dekretu w jego cyklu życia. Na przykład dokument zapisany wstępnie został zapisany, ale nie zaksięgowano go jeszcze w księdze głównej. Dokument zaksięgowany jest już zatwierdzony. Analiza statusu pomaga zrozumieć przebieg pracy i wykrywać wąskie gardła. Duża liczba dokumentów długo pozostających w stanie wstępnego zapisu lub oczekiwania na zatwierdzenie może wskazywać na nieefektywności w procesie. Status jest też ważnym źródłem informacji przy wyznaczaniu działań w procesie. Dlaczego to ważne Pokazuje etap dekretu w jego cyklu życia i pomaga wykrywać kolejki oraz wąskie gardła. Skąd pobrać Tabela BKPF w SAP S/4HANA, pole BSTAT (status dokumentu). Przykłady VAB | |||
| System źródłowy SourceSystem | Wskazuje system źródłowy, z którego wyodrębniono dane o zapisach księgowych. | ||
| Opis Ten atrybut wskazuje system źródłowy, z którego pochodzą dane dotyczące dekretu. W firmach korzystających z kilku instancji ERP lub łączących starsze i nowoczesne systemy pozwala rozróżnić źródła danych. Podczas analizy można porównywać wyniki procesu w różnych systemach lub filtrować dane według konkretnego źródła. Atrybut ten wspiera zarządzanie danymi i pomaga właściwie interpretować ich kontekst. Dlaczego to ważne Informuje o pochodzeniu danych. Ma to znaczenie przy analizie i porównywaniu procesów w środowisku obejmującym wiele systemów. Skąd pobrać Zazwyczaj jest to stała wartość dodawana podczas ekstrakcji danych, która identyfikuje konkretną instancję SAP S/4HANA, na przykład SID lub nazwę systemu logicznego. Przykłady S4H_PROD_100ECC_FIN_200S4C_US_EAST | |||
| Użytkownik zatwierdzający ApproverUser | Identyfikator użytkownika, który zatwierdził lub odrzucił dekret. | ||
| Opis Ten atrybut identyfikuje użytkownika odpowiedzialnego za sprawdzenie i podjęcie decyzji w sprawie przesłanego dekretu. W workflow z wielopoziomowym zatwierdzaniem jeden dekret może mieć kilku zatwierdzających. Informacja ta jest niezbędna do szczegółowej analizy procesu zatwierdzania. Pozwala mierzyć obciążenie poszczególnych osób, obliczać czas zatwierdzania i wykrywać wąskie gardła w ścieżce akceptacji. Wspiera dashboard „Aktywność i wydajność użytkowników”. Dlaczego to ważne Wskazuje osobę odpowiedzialną za zatwierdzenie, umożliwiając analizę obciążenia pracą, wyników i wąskich gardeł w procesie akceptacji. Skąd pobrać Dane pochodzą z dzienników workflow, na przykład SWW_WI2OBJ lub SWWLOG, albo z tabel dokumentów zmian (CDHDR/CDPOS). Użytkownika ustala się na podstawie informacji o wykonaniu kroku zatwierdzania. Przykłady DMILLERFWHITEKCHEN | |||
Działania w procesie Record to Report, księgowanie
| Działanie | Opis | ||
|---|---|---|---|
| Przetworzono storno zapisu księgowego | Wcześniej zaksięgowany zapis księgowy zostaje odwrócony przez utworzenie nowego dokumentu z przeciwnymi zapisami. Tę jawną i podlegającą audytowi transakcję wykonuje się w celu skorygowania błędów w zaksięgowanych dokumentach. | ||
| Dlaczego to ważne Storno wskazuje, że w zaksięgowanym dokumencie wystąpił błąd. Wysoki odsetek storna może świadczyć o problemach z procesem akceptacji lub jakością wprowadzanych danych. Śledzenie tych przypadków pomaga poprawić dokładność za pierwszym razem. Skąd pobrać Storno jest jawnym zdarzeniem. Nagłówek nowego dokumentu storna (BKPF) zawiera odwołanie do dokumentu pierwotnego w polu numeru dokumentu storna (STBLG). Czasem zdarzenia jest data księgowania nowego dokumentu. Rejestrowanie Wskaż dokumenty, w których pole BKPF-STBLG jest wypełnione. Znacznikiem czasu zdarzenia jest data księgowania dokumentu storna. Typ zdarzenia explicit | |||
| Rozliczono zapis księgowy | Otwarta pozycja zapisu księgowego zostaje skompensowana innym księgowaniem, na przykład płatność rozlicza fakturę. To działanie oznacza uzgodnienie konkretnych pozycji i ich zamknięcie. | ||
| Dlaczego to ważne To działanie oznacza końcowy etap uzgadniania wielu zapisów księgowych, zwłaszcza dotyczących kont przejściowych lub zarządzanych na podstawie otwartych pozycji. Pomiar czasu od zaksięgowania do rozliczenia pozwala ocenić sprawność uzgadniania. Skąd pobrać Zdarzenie to można wywnioskować z tabeli pozycji (BSEG lub widoku ACDOCA). Po rozliczeniu pozycji wypełniane są dla niej pola daty rozliczenia (AUGDT) i dokumentu rozliczającego (AUGBL). Rejestrowanie Jako znacznik czasu zdarzenia użyj daty rozliczenia pozycji (BSEG-AUGDT). Typ zdarzenia inferred | |||
| Utworzono zapis księgowy | To działanie oznacza utworzenie dokumentu zapisu księgowego w systemie. Rekord trafia do tabeli nagłówkowej (BKPF), ale nie został jeszcze zaksięgowany w księdze głównej. Jest to początek cyklu życia zapisu księgowego. | ||
| Dlaczego to ważne To główne zdarzenie rozpoczynające proces. Analiza czasu od tego zdarzenia do zaksięgowania ma zasadnicze znaczenie dla pomiaru całkowitego czasu cyklu i wykrywania opóźnień na etapie wprowadzania danych. Skąd pobrać To zdarzenie można bezpośrednio odczytać z tabeli SAP BKPF, korzystając z pól daty utworzenia (CPUDT) i godziny utworzenia (CPUTM) dla danego numeru dokumentu (BELNR). Rejestrowanie Jako znacznik czasu zdarzenia należy wykorzystać BKPF-CPUDT i BKPF-CPUTM. Typ zdarzenia explicit | |||
| Zaksięgowano zapis księgowy | Zapis księgowy zostaje oficjalnie ujęty w księdze głównej i wpływa na sprawozdania finansowe firmy. Od tego momentu dokument staje się trwałym zapisem finansowym. | ||
| Dlaczego to ważne To główny etap potwierdzający pomyślne zakończenie procesu i zamykający podstawowy cykl obsługi. Przepustowość zaksięgowanych zapisów oraz czas potrzebny na dotarcie do tego etapu to podstawowe miary w process mining. Skąd pobrać To jawne zdarzenie oznaczone datą księgowania (BUDAT) w tabeli BKPF. W zaksięgowanym dokumencie pole statusu dokumentu (BSTAT) jest puste, co odróżnia go od dokumentów wstrzymanych („V”) lub zaparkowanych („D”). Rejestrowanie Jako znacznik czasu zdarzenia wykorzystaj datę księgowania (BKPF-BUDAT) i datę wprowadzenia (BKPF-CPUDT). Puste pole BKPF-BSTAT oznacza, że dokument został zaksięgowany. Typ zdarzenia explicit | |||
| Zapis księgowy przesłany do weryfikacji | Osoba tworząca zapis księgowy formalnie przesyła dokument do workflow weryfikacji i akceptacji. To działanie oznacza przekazanie dokumentu z etapu wprowadzania danych do formalnego procesu kontrolnego i rozpoczyna cykl akceptacji. | ||
| Dlaczego to ważne To początek pomiaru czasu cyklu akceptacji. Pomiar od tego momentu do ostatecznej akceptacji lub odrzucenia pozwala wskazać wąskie gardła na etapach weryfikacji i akceptacji. Skąd pobrać Zdarzenie to często można odczytać z dzienników workflow (tabele SWW_WIHEAD, SWWLOG) powiązanych z obiektem biznesowym. Można je również wywnioskować ze zmiany statusu w niestandardowym polu nagłówka dokumentu (BKPF). Rejestrowanie Znacznik czasu utworzenia elementu workflow lub zmiany wartości pola statusu na „Przesłano” albo „W trakcie weryfikacji”. Typ zdarzenia inferred | |||
| Zapis księgowy zaakceptowany | Upoważniony kierownik ostatecznie akceptuje zapis księgowy, potwierdzając jego prawidłowość i poprawność. Jest to ostatni etap kontroli przed zaksięgowaniem dokumentu w księdze głównej. | ||
| Dlaczego to ważne To ważny etap kończący cykl akceptacji. Czas potrzebny na jego osiągnięcie stanowi znaczną część całkowitego czasu procesu i jest istotnym wskaźnikiem sprawności osób akceptujących. Skąd pobrać Zdarzenie to można wywnioskować z dziennika workflow, który pokazuje końcowy etap akceptacji, lub ze zmiany statusu dokumentu. Identyfikator użytkownika akceptującego i znacznik czasu można uzyskać z danych workflow lub dzienników zmian. Rejestrowanie Ustal znacznik czasu końcowego etapu akceptacji w dziennikach workflow lub zmianę statusu na „Zaakceptowano” w dokumentach zmian. Typ zdarzenia inferred | |||
| Dołączono dokumentację potwierdzającą | Użytkownik dołącza do zapisu księgowego jeden lub więcej dokumentów potwierdzających, na przykład faktury lub arkusze kalkulacyjne. Zazwyczaj służą one jako dowód i źródło informacji o transakcji finansowej podczas weryfikacji i audytu. | ||
| Dlaczego to ważne Dołączenie dokumentacji przed weryfikacją ma zasadnicze znaczenie dla zgodności i sprawnej akceptacji. Analiza tego działania pozwala ocenić przestrzeganie zasad dokumentowania i jego wpływ na czas akceptacji. Skąd pobrać Zdarzenie to zazwyczaj ustala się na podstawie znacznika czasu utworzenia załączników powiązanych przez Generic Object Services (GOS). Tabela SRGBTBREL łączy obiekt biznesowy, na przykład dokument BKPF, z załącznikiem. Rejestrowanie Sprawdź tabele załączników GOS, na przykład SRGBTBREL, pod kątem powiązań z obiektem BKPF i użyj znacznika czasu utworzenia załącznika. Typ zdarzenia inferred | |||
| Poprawiono zapis księgowy | Po odrzuceniu zapisu księgowego lub odesłaniu go do poprawy użytkownik wprowadza zmiany. Działanie to odzwierciedla nakład pracy potrzebny do usunięcia problemów wykrytych podczas weryfikacji przed ponownym przesłaniem dokumentu. | ||
| Dlaczego to ważne To działanie pozwala zmierzyć liczbę pętli poprawek. Analiza ich częstotliwości i czasu trwania pomaga wskazać źródła nieefektywności oraz możliwości szkolenia i doprecyzowania procesu. Skąd pobrać Można je wywnioskować, śledząc datę ostatniej zmiany (AEDAT) w tabeli BKPF dla dokumentu, który wcześniej miał status „Odrzucono”. Dokumenty zmian zawierają dokładniejsze informacje o wprowadzonych modyfikacjach. Rejestrowanie W przypadku zmian wprowadzonych po odrzuceniu użyj znacznika czasu z nagłówków dokumentów zmian (CDHDR-UDATE). Typ zdarzenia inferred | |||
| Wykryto ręczne księgowanie | Zapis księgowy zaksięgowano za pomocą ręcznego kodu transakcji, a nie przez automatyczny interfejs lub zadanie wsadowe. Nie jest to zdarzenie określające moment w czasie, lecz klasyfikacja działania księgowania. | ||
| Dlaczego to ważne Wykrywanie ręcznych księgowań ma duże znaczenie dla inicjatyw automatyzacyjnych. Duży udział ręcznych księgowań może wskazywać na możliwości usprawnienia procesu przez integrację podsystemów lub użycie automatycznych programów księgujących. Skąd pobrać Klasyfikację przeprowadza się na podstawie pola kodu transakcji (TCODE) w tabeli nagłówkowej dokumentu (BKPF). Do oznaczenia zapisu wykorzystuje się listę znanych ręcznych kodów transakcji (np. FB01, F-02, FB50). Rejestrowanie Sklasyfikuj zdarzenie na podstawie BKPF-TCODE i zdefiniowanej listy ręcznych kodów transakcji obowiązującej w chwili księgowania. Typ zdarzenia calculated | |||
| Zapis księgowy odrzucony | Osoba weryfikująca lub akceptująca odrzuca zapis księgowy, uniemożliwiając jego zaksięgowanie. Dokument jest zazwyczaj odsyłany do osoby, która go utworzyła, w celu poprawienia, co rozpoczyna pętlę ponownej pracy. | ||
| Dlaczego to ważne Śledzenie odrzuceń pomaga ocenić jakość procesu i wykryć powtarzające się błędy. Wysoki odsetek odrzuceń może wskazywać na problemy z poprawnością danych, znajomością zasad lub dokumentacją potwierdzającą. Skąd pobrać Zdarzenie to można wywnioskować ze zmiany statusu w dzienniku workflow lub niestandardowym polu statusu dokumentu zapisu księgowego. Znacznik czasu można uzyskać z dzienników zmian dokumentu (CDHDR/CDPOS) dla odpowiedniego pola statusu. Rejestrowanie Wykryj zmianę pola statusu na „Odrzucono” na podstawie dokumentów zmian (CDHDR/CDPOS) lub dzienników workflow. Typ zdarzenia inferred | |||
| Zapis księgowy wstrzymany | Użytkownik zapisuje niekompletny zapis księgowy bez jego księgowania, aby można go było później uzupełnić lub sprawdzić. Ta jawna czynność tworzy rekord nagłówka dokumentu ze statusem „wstrzymany”, który pozostaje niezaksięgowany. | ||
| Dlaczego to ważne Wstrzymanie zapisu to częsty etap przed jego przesłaniem. Pomiar czasu, przez jaki zapis pozostaje wstrzymany, pomaga wykryć opóźnienia w uzupełnianiu i przygotowaniu danych przed rozpoczęciem formalnej weryfikacji i akceptacji. Skąd pobrać W tabeli BKPF wstrzymany dokument można rozpoznać po wartości „V” w polu statusu dokumentu (BSTAT). Znacznikiem czasu zdarzenia jest data utworzenia (CPUDT). Rejestrowanie Wybierz dokumenty, dla których BKPF-BSTAT = 'V' w chwili utworzenia. Typ zdarzenia explicit | |||
| Zmieniono zapis księgowy po zaksięgowaniu | Po zaksięgowaniu zapisu w księdze głównej użytkownik zmienia wybrane pola dokumentu. Większość danych finansowych nie podlega zmianom po zaksięgowaniu, ale można modyfikować niektóre pola, na przykład tekst lub przypisania. | ||
| Dlaczego to ważne To działanie jest istotnym sygnałem dla kontroli zgodności. Zmiany wprowadzone po zaksięgowaniu mogą wskazywać na próbę modyfikacji zapisów, dlatego należy je uważnie monitorować, aby zapobiegać nadużyciom i chronić integralność danych. Skąd pobrać Zdarzenie można wiarygodnie wywnioskować z tabel dokumentów zmian (CDHDR i CDPOS). Wpis w CDHDR dotyczący numeru dokumentu, z datą zmiany późniejszą niż data księgowania, wskazuje na zmianę po zaksięgowaniu. Rejestrowanie Znajdź rekordy w CDHDR, w których znacznik czasu zmiany (UDATE/UTIME) jest późniejszy niż data księgowania dokumentu (BKPF-BUDAT). Typ zdarzenia inferred | |||
Instrukcje ekstrakcji danych
Kroki
- Wymagania wstępne i dostęp: Należy zapewnić użytkownika z uprawnieniami do odpytywania bazowej bazy danych SAP S/4HANA lub uruchamiania raportów ABAP. Wymagany jest dostęp do odczytu widoków CDS I_JournalEntry i I_JournalEntryItem oraz tabel CDHDR, CDPOS, SRGBREL, SOOD, SWW_WI2OBJ i SWWLOGHIST. Dostęp można uzyskać za pomocą klienta bazodanowego, takiego jak SAP HANA Studio lub DBeaver, albo narzędzi SAP ABAP Development Tools (ADT) dla Eclipse.
- Ustalenie konfiguracji systemu: Przed uruchomieniem zapytania należy ustalić kody zadań używane w workflow akceptacji księgowań. Administrator workflow SAP może wskazać identyfikatory zadań (np. TS12345678) odpowiadające wysłaniu, odrzuceniu i akceptacji. Te wartości należy wstawić w odpowiednie miejsca zapytania.
- Przygotowanie zapytania SQL: Skopiuj pełne zapytanie SQL z sekcji
querydo wybranego klienta SQL lub narzędzia programistycznego. - Ustawienie parametrów zapytania: Znajdź w zapytaniu symbole zastępcze i zastąp je właściwymi wartościami. Dotyczy to parametrów
[YourCompanyCode],[StartDate]i[EndDate]. Należy też zastąpić symbole zastępcze identyfikatorów zadań workflow ([Workflow Submitted Task ID],[Workflow Rejected Task ID],[Workflow Approved Task ID]) wartościami ustalonymi w poprzednim kroku. - Uruchomienie zapytania ekstrakcyjnego: Uruchom zmodyfikowane zapytanie SQL w bazie SAP S/4HANA. Czas wykonania może być długi, zależnie od zakresu dat i ilości danych. Zaleca się uruchamianie zapytania poza godzinami szczytu.
- Weryfikacja wyników: Po zakończeniu zapytania sprawdź kilka pierwszych wierszy i upewnij się, że kolumny, takie jak JournalEntryId, ActivityName i EventTime, zawierają oczekiwane wartości. Zestaw wyników powinien zawierać jeden wiersz dla każdego odrębnego zdarzenia biznesowego w cyklu życia księgowania.
- Eksport danych do CSV: Wyeksportuj cały zestaw wyników z narzędzia SQL do jednego pliku CSV. Ustaw kodowanie UTF-8, aby uniknąć problemów ze znakami specjalnymi.
- Przygotowanie do przesłania: Przed przesłaniem pliku do narzędzia process mining sprawdź, czy zawiera wymagane nagłówki. Dane mają już strukturę dziennika zdarzeń, więc nie powinny wymagać dalszych przekształceń ani przestawiania.
Konfiguracja
- Widoki Core Data Services (CDS): Ekstrakcja korzysta głównie z widoku
I_JournalEntryzawierającego dane nagłówka oraz zI_JournalEntryItemz danymi pozycji i kwot. Widoki te zapewniają uproszczony, bogaty semantycznie dostęp do uniwersalnego dziennika (ACDOCA). - Tabele pomocnicze: Aby odtworzyć pełny przebieg procesu, zapytanie łączy również kilka standardowych tabel SAP:
CDHDRiCDPOSdo śledzenia zmian w dokumentach.SRGBRELiSOODdo ustalenia, kiedy załączniki są łączone za pośrednictwem Generic Object Services (GOS).SWW_WI2OBJiSWWLOGHISTdo pobierania najważniejszych zdarzeń z workflow akceptacji.
- Filtrowanie według zakresu dat: Aby zachować wydajność, należy ograniczyć dane do określonego zakresu dat. W klauzuli
WHEREnależy użyć polaI_JournalEntry.CreationDateTime. Na początek zaleca się zakres od 3 do 6 miesięcy. - Filtrowanie według jednostki organizacyjnej: Zawsze należy filtrować według
CompanyCode, aby ograniczyć ekstrakcję do właściwych podmiotów prawnych. Pobieranie danych dla wszystkich kodów spółek naraz z dużego systemu może znacznie wydłużyć wykonanie zapytania. - Identyfikatory zadań workflow: Zapytanie zawiera symbole zastępcze identyfikatorów zadań workflow (np.
[Workflow Approved Task ID]). Są one unikatowe dla każdej instalacji SAP i należy je prawidłowo skonfigurować, aby pobrać działania workflow. Bez nich nie zostaną uwzględnione zdarzenia wysłania, akceptacji ani odrzucenia. - Wymagania wstępne: Użytkownik uruchamiający zapytanie potrzebuje szerokich uprawnień do odczytu tabel finansowych, systemowych i workflow. Nie są to uprawnienia standardowe, należy je nadać osobno.
Przykładowe zapytanie sql
WITH JournalEntryAmountCTE AS (
SELECT
CompanyCode,
AccountingDocument,
FiscalYear,
SUM(AmountInCompanyCodeCurrency) AS AmountInLocalCurrency
FROM I_JournalEntryItem
GROUP BY CompanyCode, AccountingDocument, FiscalYear
),
JournalEntryBaseCTE AS (
SELECT
JE.CompanyCode,
JE.AccountingDocument,
JE.FiscalYear,
JE.CreatedByUser,
JE.CreationDateTime,
JE.PostingDateTime,
JE.PostingDate,
JE.AccountingDocumentType,
JE.DocumentIsParked,
JE.ReversedJournalEntry,
JE.TransactionCode,
JEA.AmountInLocalCurrency
FROM I_JournalEntry AS JE
LEFT JOIN JournalEntryAmountCTE AS JEA
ON JE.CompanyCode = JEA.CompanyCode
AND JE.AccountingDocument = JEA.AccountingDocument
AND JE.FiscalYear = JEA.FiscalYear
WHERE JE.CompanyCode IN ('[YourCompanyCode]')
AND JE.CreationDateTime BETWEEN '[StartDate]' AND '[EndDate]'
)
-- 1. Journal Entry Created
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
UNION ALL
-- 2. Journal Entry Parked
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 3. Supporting Documentation Attached
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Supporting Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(SOOD.CREDAT || ' ' || SOOD.CRETIM, 'YYYYMMDD HH24MISS') AS "EventTime",
SOOD.OWNER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SRGBREL ON SRGBREL.INSTID_A = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND SRGBREL.TYPEID_A = 'BKPF'
AND SRGBREL.CATID_A = 'BO'
JOIN SOOD ON SOOD.OBJTP = SRGBREL.TYPEID_B
AND SOOD.OBJYR = SRGBREL.INSTID_B(3)
AND SOOD.OBJNO = SRGBREL.INSTID_B(5)
UNION ALL
-- 4. Journal Submitted For Review
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Submitted For Review' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Submitted Task ID]'
UNION ALL
-- 5. Journal Entry Rejected
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Rejected' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Rejected Task ID]'
UNION ALL
-- 6. Journal Entry Corrected (changed while parked)
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 7. Journal Entry Approved
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Approved' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Approved Task ID]'
UNION ALL
-- 8. Manual Posting Identified
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Manual Posting Identified' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL AND BJE.TransactionCode IN ('FB01', 'F-02', 'FB50', 'FV50', 'FBB1', 'FBV1')
UNION ALL
-- 9. Journal Entry Posted
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL
UNION ALL
-- 10. Journal Entry Changed After Posting
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Changed After Posting' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.PostingDateTime IS NOT NULL AND TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') > BJE.PostingDateTime
UNION ALL
-- 11. Journal Entry Cleared
SELECT
JEI.AccountingDocument AS "JournalEntryId",
'Journal Entry Cleared' AS "ActivityName",
MIN(JEI.ClearingDateTime) AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser", -- Note: Clearing user is not directly available here
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM I_JournalEntryItem AS JEI
JOIN JournalEntryBaseCTE AS BJE ON JEI.AccountingDocument = BJE.AccountingDocument
AND JEI.CompanyCode = BJE.CompanyCode
AND JEI.FiscalYear = BJE.FiscalYear
WHERE JEI.ClearingDateTime IS NOT NULL
GROUP BY JEI.AccountingDocument, BJE.CreatedByUser, BJE.CompanyCode, BJE.AccountingDocumentType, BJE.PostingDate, BJE.AmountInLocalCurrency
UNION ALL
-- 12. Journal Entry Reversal Processed
SELECT
OriginalDoc.AccountingDocument AS "JournalEntryId",
'Journal Entry Reversal Processed' AS "ActivityName",
ReversalDoc.PostingDateTime AS "EventTime",
ReversalDoc.CreatedByUser AS "CreatedByUser",
OriginalDoc.CompanyCode AS "CompanyCode",
OriginalDoc.AccountingDocumentType AS "JournalEntryType",
OriginalDoc.PostingDate AS "PostingDate",
OriginalDoc.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS ReversalDoc
JOIN JournalEntryBaseCTE AS OriginalDoc
ON ReversalDoc.ReversedJournalEntry = OriginalDoc.AccountingDocument
AND ReversalDoc.CompanyCode = OriginalDoc.CompanyCode
AND ReversalDoc.ReversalFiscalYear = OriginalDoc.FiscalYear
WHERE ReversalDoc.ReversedJournalEntry IS NOT NULL; Kroki
- Potwierdź, że bezpośredni dostęp SQL do bazy SAP HANA jest zatwierdzony, a użytkownik wykonujący ekstrakcję ma uprawnienia do odczytu tabel BKPF i ACDOCA oraz wszystkich skonfigurowanych źródeł workflow, załączników, historii zmian, rozliczeń lub storna wymaganych w danym systemie. Bezpośredni dostęp do bazy danych odbywa się zwykle za pomocą SAP HANA Database Explorer, SAP HANA Studio lub zatwierdzonego klienta SQL. Nie uruchamiaj zapytań ekstrakcyjnych w transakcji aplikacji SAP, chyba że system wyraźnie obsługuje taki dostęp.
- Sprawdź fizyczny schemat tabel BKPF i ACDOCA, w tym pola klienta, kodu spółki, roku obrachunkowego, numeru dokumentu, rodzaju dokumentu, daty księgowania, daty utworzenia, godziny utworzenia, użytkownika, kwoty w walucie lokalnej oraz ewentualne pola storna lub rozliczenia. Wdrożenia SAP S/4HANA mogą różnić się schematem i dostępnością pól, dlatego zastąp symbole w nawiasach kwadratowych w zapytaniu polami zweryfikowanymi w danym systemie.
- Ustal wiarygodne źródła zdarzeń workflow i załączników. BKPF i ACDOCA zawierają dane dokumentów księgowych i pozycji, ale same nie pokazują wiarygodnie wszystkich zdarzeń: wstępnego zapisu, wysłania, odrzucenia, korekty, akceptacji ani dodania załącznika. Zastąp symbole źródeł workflow i załączników zatwierdzonymi widokami lub tabelami używanymi w danym wdrożeniu. Jeśli źródło jest niedostępne, nie twórz zdarzeń na podstawie przypuszczeń. Skonfiguruj odpowiednie źródło albo wyklucz działanie po uzyskaniu udokumentowanej zgody.
- Ustaw parametry ekstrakcji: wymagany zakres dat, kody spółek, rodzaje dokumentów i klienta. Do wstępnej weryfikacji zaleca się zakres od trzech do sześciu miesięcy. Zgodnie z uzgodnionym zakresem procesu użyj zakresu znaczników czasu dla zdarzeń operacyjnych, a zakresu daty księgowania dla zdarzeń księgowych.
- Uruchom pełne zapytanie SQL w zatwierdzonym kliencie SQL dla HANA. Zapytanie tworzy jeden wiersz zdarzenia dla każdej jawnie pobieranej czynności. Do zdarzeń księgowych wykorzystuje BKPF i ACDOCA, a do zdarzeń workflow, załączników, zmian, rozliczeń i storna skonfigurowane widoki źródłowe. Nie wywnioskuje działań wyłącznie na podstawie istnienia dokumentu.
- Sprawdź schemat wyników. JournalEntryId to identyfikator case, ActivityName to nazwa działania, a EventTime to znacznik czasu zdarzenia. Zalecane atrybuty biznesowe są zwracane, jeśli są dostępne. Upewnij się, że EventTime ma typ znacznika czasu, a pola JournalEntryId i ActivityName są wypełnione w każdym wierszu.
- Uzgodnij populację dokumentów księgowych, porównując odrębne wartości JournalEntryId z oczekiwaną populacją BKPF dla wybranego klienta, kodów spółek, lat obrachunkowych i zakresu dat. Populacje workflow i załączników uzgadniaj osobno, ponieważ zasady przechowywania i znaczniki czasu mogą się różnić od danych księgowych.
- Sprawdź kolejność zdarzeń i obsługę duplikatów. Wiele pozycji w ACDOCA nie powinno powodować powielania zdarzeń księgowych, chyba że projekt procesu celowo wymaga zdarzeń na poziomie pozycji. Zastosuj logikę agregacji z zapytania, aby uzyskać jedno zdarzenie księgowe na zapis i typ zdarzenia, zachowując dostępne identyfikatory zdarzeń ze skonfigurowanych źródeł.
- Wyeksportuj wyniki do pliku CSV w kodowaniu UTF-8 lub innym formacie tabelarycznym obsługiwanym przez ProcessMind. Zachowaj dokładne nazwy kolumn: JournalEntryId, ActivityName i EventTime. Posortuj plik według JournalEntryId i EventTime, a pozostałe atrybuty zachowaj jako kolumny. Prześlij plik do ProcessMind i ustaw JournalEntryId jako identyfikator case, ActivityName jako działanie, a EventTime jako znacznik czasu zdarzenia.
Konfiguracja
- Zakres dat: Zacznij od trzech do sześciu miesięcy. Do testów wydajności użyj krótszego okresu i rozszerz go dopiero po sprawdzeniu liczby wierszy oraz pokrycia zdarzeń.
- Zakres klienta i spółek: Ustaw [Client parameter] i ogranicz CompanyCode do wymaganych podmiotów prawnych. W systemie wieloklientowym nie pomijaj warunku dotyczącego klienta.
- Zakres księgowy: Skonfiguruj [Document type filter] oraz, w razie potrzeby, filtry roku obrachunkowego i daty księgowania. Uwzględniaj dokumenty zaksięgowane i niezaksięgowane tylko wtedy, gdy wybrane źródło wiarygodnie je reprezentuje.
- Zakres workflow: Skonfiguruj [Workflow event source] i mapowanie typów zdarzeń na wysłanie, odrzucenie, korektę i akceptację. Sprawdź, czy znaczniki czasu oznaczają utworzenie, wykonanie czy zakończenie działania workflow.
- Zakres załączników: Skonfiguruj [Attachment event source] oraz pole relacji łączące załącznik z zapisem księgowym. Sprawdź, czy źródło rejestruje dodanie, zastąpienie czy usunięcie załącznika.
- Zakres zmian: Skonfiguruj [Change history source], aby uwzględnić zmiany po zaksięgowaniu. Sprawdź, czy źródło wskazuje zapis księgowy i podaje wiarygodny znacznik czasu zmiany.
- Zakres rozliczeń: Skonfiguruj [Clearing source] oraz relację między rozliczanym dokumentem księgowym a dokumentem rozliczającym. Ustal, czy zdarzenie ma być przypisane do pierwotnego zapisu, dokumentu rozliczającego czy obu.
- Zakres storna: Skonfiguruj [Reversal source] i relację między dokumentem pierwotnym a dokumentem storna. Jeśli ta relacja jest dostępna, zapytanie przypisuje zdarzenie storna do pierwotnego JournalEntryId.
- Klasyfikacja księgowania ręcznego: Skonfiguruj [Manual posting source] lub zweryfikowane pole wskazujące źródło księgowania. Manual Posting Identified to zdarzenie klasyfikacyjne. Należy konsekwentnie używać znacznika czasu księgowania lub innego zatwierdzonego znacznika czasu.
- Kwota w walucie: ACDOCA zawiera dane na poziomie pozycji. Zapytanie agreguje kwoty w walucie lokalnej według zapisu księgowego. Sprawdź konwencję znaków oraz to, czy uwzględniać wiersze statystyczne, dotyczące konkretnej księgi lub księgi rozszerzonej.
- Wydajność: Pobieraj tylko wymagane kolumny, stosuj filtry na wczesnym etapie, unikaj nieograniczonego skanowania ACDOCA i uruchamiaj zapytanie w zatwierdzonym oknie raportowym. Jeśli system to obsługuje, ogranicz skanowanie partycji warunkami dotyczącymi klienta, roku obrachunkowego, kodu spółki i daty księgowania.
- Obsługa duplikatów: Korzystaj z identyfikatorów zdarzeń ze źródeł, jeśli są dostępne. Jeśli źródło może zawierać powtarzające się rekordy techniczne, zastosuj udokumentowaną regułę usuwania duplikatów, nie łącząc odrębnych działań workflow.
- Wymagania wstępne: Wymagane uprawnienia do bazy danych, zatwierdzone połączenie z SAP HANA, dostęp do skonfigurowanych źródeł workflow i załączników, odpowiednia konfiguracja SAP Financial Accounting i workflow oraz format eksportu obsługiwany przez ProcessMind.
Przykładowe zapytanie sql
WITH
accounting_base AS (
SELECT
b.[Client field] AS ClientId,
b.[Company code field] AS CompanyCode,
b.[Fiscal year field] AS FiscalYear,
b.[Document number field] AS AccountingDocumentNumber,
b.[Document type field] AS JournalEntryType,
b.[Created by field] AS CreatedByUser,
b.[Document date field] AS DocumentDate,
b.[Posting date field] AS PostingDate,
b.[Creation date field] AS CreationDate,
b.[Creation time field] AS CreationTime,
b.[Reversal document field] AS ReversalDocumentNumber,
b.[Reversed document field] AS ReversedDocumentNumber,
b.[Reversal fiscal year field] AS ReversalFiscalYear,
SUM(a.[Local currency amount field]) AS AmountInLocalCurrency,
MAX(a.[Local currency field]) AS LocalCurrency
FROM [Your schema].[BKPF] b
INNER JOIN [Your schema].[ACDOCA] a
ON a.[Client field] = b.[Client field]
AND a.[Company code field] = b.[Company code field]
AND a.[Fiscal year field] = b.[Fiscal year field]
AND a.[Document number field] = b.[Document number field]
WHERE b.[Client field] = '[Client parameter]'
AND b.[Company code field] IN ([Company code filter])
AND b.[Posting date field] BETWEEN '[Start date parameter]' AND '[End date parameter]'
AND b.[Document type field] IN ([Document type filter])
GROUP BY
b.[Client field],
b.[Company code field],
b.[Fiscal year field],
b.[Document number field],
b.[Document type field],
b.[Created by field],
b.[Document date field],
b.[Posting date field],
b.[Creation date field],
b.[Creation time field],
b.[Reversal document field],
b.[Reversed document field],
b.[Reversal fiscal year field]
),
base_cases AS (
SELECT
ClientId,
CompanyCode,
FiscalYear,
AccountingDocumentNumber,
CAST(CompanyCode || '/' || FiscalYear || '/' || AccountingDocumentNumber AS NVARCHAR(100)) AS JournalEntryId,
JournalEntryType,
CreatedByUser,
PostingDate,
AmountInLocalCurrency,
LocalCurrency,
CreationDate,
CreationTime,
ReversalDocumentNumber,
ReversedDocumentNumber,
ReversalFiscalYear
FROM accounting_base
),
created_events AS (
SELECT
JournalEntryId,
'Journal Entry Created' AS ActivityName,
CAST(CreationDate || ' ' || CreationTime AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
),
parked_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Parked' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Parked event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
attachment_events AS (
SELECT
CAST(x.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Supporting Documentation Attached' AS ActivityName,
CAST(x.[Event timestamp field] AS TIMESTAMP) AS EventTime,
x.[User field] AS CreatedByUser,
x.[Company code field] AS CompanyCode,
x.[Journal entry type field] AS JournalEntryType,
x.[Posting date field] AS PostingDate,
x.[Amount in local currency field] AS AmountInLocalCurrency,
x.[Local currency field] AS LocalCurrency
FROM [Your schema].[Attachment event source] x
WHERE x.[Client field] = '[Client parameter]'
AND x.[Event type field] = '[Attachment created event type]'
AND CAST(x.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
submitted_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Submitted For Review' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Submitted event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
rejected_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Rejected' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Rejected event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
corrected_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Corrected' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Corrected event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
approved_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Approved' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Approved event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
manual_events AS (
SELECT
JournalEntryId,
'Manual Posting Identified' AS ActivityName,
CAST(PostingDate AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
WHERE [Manual posting condition verified for this system]
),
posted_events AS (
SELECT
JournalEntryId,
'Journal Entry Posted' AS ActivityName,
CAST(PostingDate AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
WHERE [Posted document condition verified for this system]
),
changed_events AS (
SELECT
CAST(c.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Changed After Posting' AS ActivityName,
CAST(c.[Change timestamp field] AS TIMESTAMP) AS EventTime,
c.[User field] AS CreatedByUser,
c.[Company code field] AS CompanyCode,
c.[Journal entry type field] AS JournalEntryType,
c.[Posting date field] AS PostingDate,
c.[Amount in local currency field] AS AmountInLocalCurrency,
c.[Local currency field] AS LocalCurrency
FROM [Your schema].[Change history source] c
WHERE c.[Client field] = '[Client parameter]'
AND c.[Post posting change indicator field] = '[Post posting change value]'
AND CAST(c.[Change timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
cleared_events AS (
SELECT
CAST(cl.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Cleared' AS ActivityName,
CAST(cl.[Clearing timestamp field] AS TIMESTAMP) AS EventTime,
cl.[User field] AS CreatedByUser,
cl.[Company code field] AS CompanyCode,
cl.[Journal entry type field] AS JournalEntryType,
cl.[Posting date field] AS PostingDate,
cl.[Amount in local currency field] AS AmountInLocalCurrency,
cl.[Local currency field] AS LocalCurrency
FROM [Your schema].[Clearing source] cl
WHERE cl.[Client field] = '[Client parameter]'
AND CAST(cl.[Clearing timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
reversal_events AS (
SELECT
CAST(r.[Original journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Reversal Processed' AS ActivityName,
CAST(r.[Reversal timestamp field] AS TIMESTAMP) AS EventTime,
r.[User field] AS CreatedByUser,
r.[Company code field] AS CompanyCode,
r.[Journal entry type field] AS JournalEntryType,
r.[Posting date field] AS PostingDate,
r.[Amount in local currency field] AS AmountInLocalCurrency,
r.[Local currency field] AS LocalCurrency
FROM [Your schema].[Reversal source] r
WHERE r.[Client field] = '[Client parameter]'
AND CAST(r.[Reversal timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
)
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM created_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM parked_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM attachment_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM submitted_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM rejected_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM corrected_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM approved_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM manual_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM posted_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM changed_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM cleared_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM reversal_events
ORDER BY JournalEntryId, EventTime, ActivityName; Kroki
- Utwórz program ABAP: Otwórz edytor ABAP za pomocą kodu transakcji
SE38. Wpisz nazwę nowego programu, na przykładZ_PM_JE_EXTRACT, i kliknij „Utwórz”. Podaj odpowiedni tytuł, ustaw typ „Program wykonywalny” i zapisz program jako obiekt lokalny lub w pakiecie. - Zdefiniuj ekran wyboru: W programie zdefiniuj parametry i opcje wyboru, które pozwolą filtrować dane. Uwzględnij zakres dat utworzenia zapisu księgowego (
P_CPUDT_FR,P_CPUDT_TO), opcję wyboru kodu spółki (SO_BUKRS) oraz ścieżkę pliku wyjściowego na serwerze aplikacji (P_FPATH). - Zadeklaruj struktury danych: Zdefiniuj strukturę tabeli wewnętrznej zgodną z wymaganym formatem dziennika zdarzeń. Będzie ona przechowywać końcowe wyniki. Zadeklaruj również tabele wewnętrzne i obszary robocze dla tabel SAP, z których będą pobierane dane, takich jak BKPF, ACDOCA, CDHDR, CDPOS i różne tabele workflow.
- Zaimplementuj logikę wyboru danych: Napisz główną logikę ABAP, która pobierze dane dla każdego z 12 wymaganych działań. Dla zachowania porządku utwórz osobne podprogramy (FORM) dla każdego działania. Można na przykład utworzyć FORM dla
get_created_events,get_parked_events,get_workflow_eventsitd. - Pobierz zdarzenia „Utworzono” i „Zaksięgowano”: Odczytaj tabelę BKPF zgodnie z kryteriami z ekranu wyboru. Wpis w BKPF oznacza utworzenie dokumentu. Dokument ze statusem
BSTAT = ' 'uznaje się za zaksięgowany. Jako czas zdarzenia wykorzystaj znacznik czasu utworzenia (CPUDT,CPUTM). - Pobierz zdarzenia „Wstępnie zapisano”: Odczytaj tabelę VBKPF, w której przechowywane są nagłówki dokumentów wstępnie zapisanych. Znacznik czasu utworzenia w tej tabeli odpowiada zdarzeniu wstępnego zapisu.
- Pobierz zdarzenia workflow (wysłanie, akceptacja, odrzucenie): Odpytaj tabele workflow, takie jak SWW_WI2OBJ (aby powiązać obiekt zapisu księgowego z instancją workflow) oraz SWWLOGHIST lub SWWIHEAD (aby pobrać szczegóły i czas poszczególnych kroków). Należy ustalić identyfikatory zadań workflow używane w danym systemie do wysłania, akceptacji i odrzucenia.
- Pobierz zdarzenia „Zmieniono” i „Skorygowano”: Odpytaj tabele dokumentów zmian CDHDR (nagłówek) i CDPOS (pozycja) dla
OBJECTCLAS = 'BELEG'. W przypadku zdarzenia „Zmieniono po zaksięgowaniu” uwzględnij zmiany, których znacznik czasu przypada po dacie księgowania dokumentu. W przypadku „Skorygowano” uwzględnij zmiany dotyczące dokumentów wstępnie zapisanych lub odrzuconych. - Pobierz zdarzenia „Unieważniono” i „Rozliczono”: Wyszukaj dokumenty storna, w których pole
STBLG(numer dokumentu storna) w BKPF jest wypełnione. Czas zdarzenia storna to czas utworzenia dokumentu korygującego. Zdarzenia rozliczenia ustal na podstawie najpóźniejszej daty rozliczenia (AUGDT) w tabeli ACDOCA dla pozycji danego zapisu księgowego. - Połącz i posortuj dane: Po pobraniu danych dla każdego działania dodaj wyniki do głównej tabeli wewnętrznej. Po zakończeniu wszystkich operacji posortuj ją według
JournalEntryIdiEventTime, aby zachować kolejność chronologiczną w każdym przypadku. - Utwórz plik wyjściowy: Użyj instrukcji
OPEN DATASET,LOOP AT... TRANSFERiCLOSE DATASET, aby zapisać zawartość posortowanej tabeli wewnętrznej w podanej ścieżce na serwerze aplikacji SAP. Plik powinien mieć format CSV i zawierać wiersz nagłówkowy. - Zaplanuj uruchamianie: Aby regularnie pobierać dane, użyj kodu transakcji
SM36i utwórz zadanie w tle uruchamiające programZ_PM_JE_EXTRACTwedług ustalonego harmonogramu, na przykład co tydzień lub co miesiąc. Dzięki temu eksport danych będzie wykonywany automatycznie.
Konfiguracja
- Zakres dat: Ekran wyboru powinien wymagać podania zakresu daty utworzenia zapisu księgowego (
CPUDT). Zaleca się pobieranie danych w łatwych do obsłużenia partiach, na przykład po 3–6 miesięcy, aby zachować dobrą wydajność. - Kod spółki (
BUKRS): To ważny filtr, który ogranicza ekstrakcję do podmiotów prawnych objętych analizą process mining. Nie zaleca się pobierania danych dla wszystkich kodów spółek naraz. - Rodzaj dokumentu (
BLART): Można dodać ten opcjonalny filtr, aby uwzględnić wybrane rodzaje zapisów księgowych, na przykład „SA” dla księgowania na koncie księgi głównej lub „KR” dla faktur dostawców. Ograniczy to ilość danych i zwiększy przydatność zestawu. - Ścieżka pliku: Program wymaga logicznej ścieżki do pliku na serwerze aplikacji SAP. Sprawdź, czy ścieżka jest prawidłowa i czy użytkownik systemowy SAP ma uprawnienia do zapisu w tym katalogu. Do zarządzania katalogami serwera i ich przeglądania służy transakcja
AL11. - Identyfikatory zadań workflow: Logikę pobierania zdarzeń workflow (wysłanie, akceptacja, odrzucenie) należy skonfigurować z użyciem identyfikatorów zadań właściwych dla workflow akceptacji księgowań w danej organizacji. Często są to identyfikatory niestandardowe, które powinien ustalić konsultant lub programista workflow.
- Wymagania wstępne: Użytkownik lub konto systemowe uruchamiające program musi mieć uprawnienia programistyczne do tworzenia i uruchamiania programów ABAP (
S_DEVELOP) oraz szeroki dostęp do odczytu tabel finansowych (BKPF, ACDOCA), tabel dziennika zmian (CDHDR, CDPOS) i tabel workflow (SWW*).
Przykładowe zapytanie abap
REPORT Z_PM_JE_EXTRACT.
*&---------------------------------------------------------------------*
*&-- Data Structures for Event Log --*
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
journalentryid TYPE string,
activityname TYPE string,
eventtime TYPE string,
createdbyuser TYPE uname,
companycode TYPE bukrs,
journalentrytype TYPE blart,
postingdate TYPE budat,
amountinlocalcurrency TYPE wrbtr,
END OF ty_event_log.
*&---------------------------------------------------------------------*
*&-- Selection Screen Definition --*
*&---------------------------------------------------------------------*
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE TEXT-001.
PARAMETERS: p_erdat_fr TYPE dats OBLIGATORY DEFAULT sy-datum-30,
p_erdat_to TYPE dats OBLIGATORY DEFAULT sy-datum.
SELECT-OPTIONS: so_bukrs FOR bkpf-bukrs OBLIGATORY.
PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/usr/sap/trans/tmp/je_event_log.csv'.
SELECTION-SCREEN END OF BLOCK b1.
*&---------------------------------------------------------------------*
*&-- Internal Tables --*
*&---------------------------------------------------------------------*
DATA: gt_event_log TYPE TABLE OF ty_event_log.
*&---------------------------------------------------------------------*
*&-- Main Processing Block --*
*&---------------------------------------------------------------------*
START-OF-SELECTION.
PERFORM get_created_posted_events.
PERFORM get_parked_events.
PERFORM get_attachment_events.
PERFORM get_workflow_events.
PERFORM get_change_events.
PERFORM get_cleared_events.
PERFORM get_reversal_events.
SORT gt_event_log BY journalentryid eventtime.
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*&-- Subroutines for Extracting Individual Activities --*
*&---------------------------------------------------------------------*
FORM get_created_posted_events.
DATA: lt_bkpf TYPE TABLE OF bkpf,
ls_event_log TYPE ty_event_log,
lv_timestamp TYPE string.
SELECT * FROM bkpf INTO TABLE lt_bkpf
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.
LOOP AT lt_bkpf ASSIGNING FIELD-SYMBOL(<fs_bkpf>).
CLEAR ls_event_log.
CONCATENATE <fs_bkpf>-bukrs <fs_bkpf>-belnr <fs_bkpf>-gjahr INTO ls_event_log-journalentryid.
ls_event_log-companycode = <fs_bkpf>-bukrs.
ls_event_log-journalentrytype = <fs_bkpf>-blart.
ls_event_log-postingdate = <fs_bkpf>-budat.
ls_event_log-createdbyuser = <fs_bkpf>-usnam.
" Timestamp format YYYY-MM-DDTHH:MI:SS
CONCATENATE <fs_bkpf>-cpudt(4) '-' <fs_bkpf>-cpudt+4(2) '-' <fs_bkpf>-cpudt+6(2) 'T' <fs_bkpf>-cputm(2) ':' <fs_bkpf>-cputm+2(2) ':' <fs_bkpf>-cputm+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
" Activity: Journal Entry Created
ls_event_log-activityname = 'Journal Entry Created'.
SELECT SUM( hsl ) INTO ls_event_log-amountinlocalcurrency FROM acdoca WHERE belnr = <fs_bkpf>-belnr AND gjahr = <fs_bkpf>-gjahr AND bukrs = <fs_bkpf>-bukrs.
APPEND ls_event_log TO gt_event_log.
" Activity: Journal Entry Posted (if not parked)
IF <fs_bkpf>-bstat = ' '.
ls_event_log-activityname = 'Journal Entry Posted'.
APPEND ls_event_log TO gt_event_log.
" Activity: Manual Posting Identified (based on T-Code)
CASE <fs_bkpf>-tcode.
WHEN 'FB01' OR 'F-02' OR 'FB50' OR 'F-22' OR 'F-43'.
ls_event_log-activityname = 'Manual Posting Identified'.
APPEND ls_event_log TO gt_event_log.
ENDCASE.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_parked_events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM vbkpf
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.
CLEAR ls_event_log.
CONCATENATE vbkpf-bukrs vbkpf-belnr vbkpf-gjahr INTO ls_event_log-journalentryid.
CONCATENATE vbkpf-cpudt(4) '-' vbkpf-cpudt+4(2) '-' vbkpf-cpudt+6(2) 'T' vbkpf-cputm(2) ':' vbkpf-cputm+2(2) ':' vbkpf-cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Journal Entry Parked'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = vbkpf-usnam.
ls_event_log-companycode = vbkpf-bukrs.
ls_event_log-journalentrytype = vbkpf-blart.
ls_event_log-postingdate = vbkpf-budat.
APPEND ls_event_log TO gt_event_log.
ENDSELECT.
ENDFORM.
FORM get_attachment_events.
DATA: lt_bdocs TYPE TABLE OF srgbtbrel, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM srgbtbrel INTO TABLE lt_bdocs
WHERE typeid_a = 'BUS2081' " Object type for Accounting Document
AND catid_a = 'BO'.
LOOP AT lt_bdocs ASSIGNING FIELD-SYMBOL(<fs_bdocs>).
CHECK <fs_bdocs>-instid_a(4) IN so_bukrs.
DATA(lv_bukrs) = <fs_bdocs>-instid_a(4).
DATA(lv_belnr) = <fs_bdocs>-instid_a+4(10).
DATA(lv_gjahr) = <fs_bdocs>-instid_a+14(4).
SELECT SINGLE cpudt, cputm, usnam, blart, budat FROM bkpf
INTO (DATA(lv_cpudt), DATA(lv_cputm), DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
IF sy-subrc = 0 AND lv_cpudt BETWEEN p_erdat_fr AND p_erdat_to.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
" Note: Using document creation time as a proxy for attachment time.
CONCATENATE lv_cpudt(4) '-' lv_cpudt+4(2) '-' lv_cpudt+6(2) 'T' lv_cputm(2) ':' lv_cputm+2(2) ':' lv_cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Supporting Documentation Attached'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = lv_bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_workflow_events.
" This is a simplified example. Real workflow logic can be complex.
" You must identify your specific Task IDs for these events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
DATA: BEGIN OF ls_wi, wi_id TYPE sww_wiid, cr_date TYPE sww_cd, cr_time TYPE sww_ct, task TYPE sww_task, instid TYPE swo_typeid, END OF ls_wi.
SELECT h~wi_id h~cr_date h~cr_time h~wi_rh_task o~instid
FROM swwwihead AS h
JOIN sww_wi2obj AS o ON h~wi_id = o~wi_id
INTO @ls_wi
WHERE o~typeid = 'BUS2081' AND o~catid = 'BO'
AND h~cr_date BETWEEN @p_erdat_fr AND @p_erdat_to.
DATA(lv_bukrs) = ls_wi-instid(4).
DATA(lv_belnr) = ls_wi-instid+4(10).
DATA(lv_gjahr) = ls_wi-instid+14(4).
IF lv_bukrs IN so_bukrs.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
CONCATENATE ls_wi-cr_date(4) '-' ls_wi-cr_date+4(2) '-' ls_wi-cr_date+6(2) 'T' ls_wi-cr_time(2) ':' ls_wi-cr_time+2(2) ':' ls_wi-cr_time+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-companycode = lv_bukrs.
CASE ls_wi-task.
WHEN '[Your Submit Task ID]'. " e.g., TS20000139
ls_event_log-activityname = 'Journal Submitted For Review'.
APPEND ls_event_log TO gt_event_log.
WHEN '[Your Approve Task ID]'. " e.g., TS20000142
ls_event_log-activityname = 'Journal Entry Approved'.
APPEND ls_event_log TO gt_event_log.
WHEN '[Your Reject Task ID]'. " e.g., TS20000141
ls_event_log-activityname = 'Journal Entry Rejected'.
APPEND ls_event_log TO gt_event_log.
ENDCASE.
ENDIF.
ENDSELECT.
ENDFORM.
FORM get_change_events.
DATA: lt_cdhdr TYPE TABLE OF cdhdr, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM cdhdr INTO TABLE lt_cdhdr
WHERE objectclas = 'BELEG'
AND udate BETWEEN p_erdat_fr AND p_erdat_to.
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
DATA(lv_bukrs) = <fs_cdhdr>-objectid(4).
DATA(lv_belnr) = <fs_cdhdr>-objectid+4(10).
DATA(lv_gjahr) = <fs_cdhdr>-objectid+14(4).
IF lv_bukrs IN so_bukrs.
SELECT SINGLE bstat, budat, blart FROM bkpf
INTO (DATA(lv_bstat), DATA(lv_budat), DATA(lv_blart))
WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
CONCATENATE <fs_cdhdr>-udate(4) '-' <fs_cdhdr>-udate+4(2) '-' <fs_cdhdr>-udate+6(2) 'T' <fs_cdhdr>-utime(2) ':' <fs_cdhdr>-utime+2(2) ':' <fs_cdhdr>-utime+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = <fs_cdhdr>-username.
ls_event_log-companycode = lv_bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
IF lv_bstat = ' ' AND <fs_cdhdr>-udate > lv_budat.
ls_event_log-activityname = 'Journal Entry Changed After Posting'.
APPEND ls_event_log TO gt_event_log.
ELSEIF lv_bstat <> ' '.
ls_event_log-activityname = 'Journal Entry Corrected'.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDIF.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_cleared_events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
DATA: BEGIN OF ls_clear, belnr TYPE belnr_d, gjahr TYPE gjahr, bukrs TYPE bukrs, augdt TYPE augdt, END OF ls_clear, lt_clear LIKE TABLE OF ls_clear.
SELECT belnr, gjahr, bukrs, MAX( augdt ) AS augdt FROM acdoca
INTO TABLE @lt_clear
WHERE bukrs IN @so_bukrs
AND augdt NE '00000000'
AND augdt BETWEEN @p_erdat_fr AND @p_erdat_to
GROUP BY belnr, gjahr, bukrs.
LOOP AT lt_clear INTO ls_clear.
SELECT SINGLE usnam, blart, budat FROM bkpf
INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = ls_clear-bukrs AND belnr = ls_clear-belnr AND gjahr = ls_clear-gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE ls_clear-bukrs ls_clear-belnr ls_clear-gjahr INTO ls_event_log-journalentryid.
CONCATENATE ls_clear-augdt(4) '-' ls_clear-augdt+4(2) '-' ls_clear-augdt+6(2) 'T12:00:00' INTO lv_timestamp. " Clearing date has no time, use midday
ls_event_log-activityname = 'Journal Entry Cleared'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = ls_clear-bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_reversal_events.
DATA: lt_reversals TYPE TABLE OF bkpf, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM bkpf INTO TABLE lt_reversals
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to
AND stblg IS NOT NULL.
LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
SELECT SINGLE usnam, blart, budat FROM bkpf
INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = <fs_rev>-bukrs AND belnr = <fs_rev>-stblg AND gjahr = <fs_rev>-gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE <fs_rev>-bukrs <fs_rev>-stblg <fs_rev>-gjahr INTO ls_event_log-journalentryid.
CONCATENATE <fs_rev>-cpudt(4) '-' <fs_rev>-cpudt+4(2) '-' <fs_rev>-cpudt+6(2) 'T' <fs_rev>-cputm(2) ':' <fs_rev>-cputm+2(2) ':' <fs_rev>-cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Journal Entry Reversal Processed'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = <fs_rev>-bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM write_output_file.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_event_log> TYPE ty_event_log.
OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc NE 0.
MESSAGE 'Error opening file.' TYPE 'E'.
RETURN.
ENDIF.
" Write Header
lv_line = 'JournalEntryId,ActivityName,EventTime,CreatedByUser,CompanyCode,JournalEntryType,PostingDate,AmountInLocalCurrency'.
TRANSFER lv_line TO p_fpath.
LOOP AT gt_event_log ASSIGNING <fs_event_log>.
CONCATENATE <fs_event_log>-journalentryid <fs_event_log>-activityname <fs_event_log>-eventtime <fs_event_log>-createdbyuser <fs_event_log>-companycode <fs_event_log>-journalentrytype <fs_event_log>-postingdate <fs_event_log>-amountinlocalcurrency
INTO lv_line SEPARATED BY ','.
TRANSFER lv_line TO p_fpath.
ENDLOOP.
CLOSE DATASET p_fpath.
WRITE: / 'File successfully written to', p_fpath.
ENDFORM. Gotowi do rozpoczęcia?
Skorzystaj z tego szablonu, aby przygotować dane i lepiej poznać przebieg procesu Record to Report, księgowanie. Zacznij usprawniać proces na podstawie danych.
Usprawnij księgowanie w procesie Record to Report i skróć czas realizacji
Usprawnij proces i skróć cykl księgowania w Record to Report o 30%.
Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.