Szablon danych dla procesu Record to Report, księgowanie

SAP S/4HANA
Szablon danych dla procesu Record to Report, księgowanie

Szablon danych dla procesu Record to Report, księgowanie

Ten szablon pomaga zebrać dane potrzebne do analizy procesu Record to Report, księgowanie. Zawiera listę zalecanych atrybutów i działań do śledzenia oraz praktyczne wskazówki dotyczące pobierania informacji z systemu źródłowego. Dzięki niemu można przygotować dane do analizy process mining.
  • Zalecane atrybuty do zebrania
  • Najważniejsze działania do śledzenia
  • Praktyczne wskazówki dotyczące ekstrakcji danych
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty procesu Record to Report, księgowanie

Poniżej przedstawiono zalecane pola danych do uwzględnienia w dzienniku zdarzeń na potrzeby analizy procesu Record to Report, księgowanie.
3 Wymagane 5 Zalecane 11 Opcjonalne
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
Wymagane Zalecane Opcjonalne

Działania w procesie Record to Report, księgowanie

Poniżej przedstawiono najważniejsze kroki i punkty kontrolne, które warto uwzględnić w dzienniku zdarzeń, aby prawidłowo odkryć i usprawnić proces.
6 Zalecane 6 Opcjonalne
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
Zalecane Opcjonalne

Instrukcje ekstrakcji danych

Jak pobrać dane z SAP S/4HANA

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%.

Rozpocznij okres próbny

Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.