Szablon danych do analizy obsługi faktur zakupu

SAP S/4HANA
Szablon danych do analizy obsługi faktur zakupu

Szablon danych do analizy obsługi faktur zakupu

Ten szablon zawiera wskazówki dotyczące gromadzenia danych potrzebnych do analizy obsługi faktur zakupu. Wymienia atrybuty i czynności niezbędne do utworzenia dziennika zdarzeń. Zawiera również praktyczne informacje o pobieraniu danych z systemów źródłowych, które ułatwią rozpoczęcie analizy process mining.
  • Zalecane atrybuty do szczegółowej analizy
  • Najważniejsze czynności procesu do śledzenia
  • Instrukcja pobierania danych krok po kroku
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty procesu obsługi faktur zakupu

To najważniejsze pola danych, które należy uwzględnić w dzienniku zdarzeń, aby dokładnie przeanalizować proces obsługi faktur zakupu.
5 Wymagane 6 Zalecane 9 Opcjonalne
Nazwa Opis
Czas zdarzenia
EventTime
Dokładna data i godzina wystąpienia czynności.
Opis

Czas zdarzenia to znacznik czasu przypisany do każdej czynności, który określa chronologiczną kolejność zdarzeń dotyczących faktury. Dane te są niezbędne do zrozumienia przebiegu procesu i przeprowadzania analiz czasowych.

W analizie czas zdarzenia służy do prawidłowego uporządkowania czynności, obliczania czasu między etapami, wykrywania czasu oczekiwania i oceny wyników procesu w różnych okresach, np. miesiąc do miesiąca. Stanowi podstawę wszystkich KPI opartych na czasie trwania.

Dlaczego to ważne

Ten znacznik czasu jest niezbędny do chronologicznego uporządkowania zdarzeń i obliczania mierników czasowych, takich jak czas cyklu i czas trwania. To podstawa process mining.

Skąd pobrać

Dane pochodzą z różnych pól daty i godziny w tabelach SAP, takich jak data utworzenia (BKPF-CPUDT), data księgowania (BKPF-BUDAT), data rozliczenia (BSAK-AUGDT) lub znaczniki czasu w dzienniku zmian (CDHDR-UDATE/UTIME).

Przykłady
2023-10-01T09:00:00Z2023-10-05T14:30:15Z2023-10-15T11:21:05Z
Czynność
ActivityName
Nazwa konkretnego zdarzenia biznesowego lub etapu, który wystąpił podczas obsługi faktury.
Opis

Czynność oznacza odrębny etap lub działanie w procesie obsługi zobowiązań, takie jak „Otrzymano fakturę”, „Zaksięgowano fakturę” lub „Zrealizowano płatność”. Czynności tworzą mapę procesu.

Analiza czynności jest podstawą process mining. Pozwala zobrazować przebieg procesu, wykryć typowe ścieżki i odstępstwa od standardowego przebiegu oraz zmierzyć częstotliwość i czas trwania poszczególnych etapów. Kolejność czynności dla danej faktury pokazuje jej przebieg przez proces.

Dlaczego to ważne

Czynności określają etapy procesu. Umożliwiają zobrazowanie i analizę jego przebiegu, wykrywanie wąskich gardeł oraz pętli poprawek.

Skąd pobrać

Dane pochodzą z różnych źródeł, w tym ze zmian statusu dokumentu (np. BKPF-BSTAT), dokumentów zmian (tabele CDHDR/CDPOS) lub dzienników workflow. Zwykle wymagają niestandardowej logiki ekstrakcji.

Przykłady
Otrzymano fakturęZaakceptowano fakturęZrealizowano płatnośćZablokowano płatność faktury
Faktura
Invoice
Unikalny identyfikator dokumentu faktury, który pełni funkcję głównego identyfikatora case w procesie obsługi zobowiązań.
Opis

Faktura jest centralnym obiektem łączącym wszystkie powiązane działania, od jej otrzymania po płatność. W SAP S/4HANA jej identyfikator jest zwykle kluczem złożonym z kodu jednostki gospodarczej (BUKRS), unikalnego numeru dokumentu (BELNR) i roku obrotowego (GJAHR).

Analiza według faktury pokazuje cały cykl jej obsługi. Umożliwia obliczanie podstawowych mierników, takich jak łączny czas obsługi, wykrywanie wąskich gardeł dla poszczególnych faktur i sprawdzanie, jakimi ścieżkami przechodzą one przez proces.

Dlaczego to ważne

Unikalny identyfikator pozwala prześledzić pełny cykl obsługi każdej faktury i analizować wyniki procesu dla poszczególnych przypadków.

Skąd pobrać

Klucz złożony z pól BUKRS, BELNR i GJAHR, pochodzących z tabel BKPF (nagłówek dokumentu księgowego) lub RBKP (nagłówek dokumentu: otrzymanie faktury).

Przykłady
1000-1900000001-20231710-1900000002-20232000-5100000003-2024
Ostatnia aktualizacja danych
LastDataUpdate
Znacznik czasu wskazujący, kiedy dane tego rekordu zostały ostatnio odświeżone z systemu źródłowego.
Opis

Ten atrybut zawiera datę i godzinę ostatniej ekstrakcji lub aktualizacji danych z SAP S/4HANA. To pole metadanych informuje, jak aktualne są analizowane dane.

Dzięki tej informacji użytkownicy wiedzą, na jak aktualnych danych opiera się analiza procesu. Pozwala ona uwzględnić opóźnienia w dostępności danych, zaplanować ich odświeżanie i dbać o ich spójność.

Dlaczego to ważne

Informuje o aktualności danych, dzięki czemu użytkownicy wiedzą, jak aktualna jest analiza procesu.

Skąd pobrać

Wartość jest generowana i zapisywana w każdym rekordzie podczas ekstrakcji danych z systemu źródłowego.

Przykłady
2024-05-20T04:00:00Z2024-05-21T04:00:00Z
System źródłowy
SourceSystem
System, z którego wyodrębniono dane.
Opis

Ten atrybut wskazuje źródło danych o procesie. W tym widoku jego wartością będzie zwykle „SAP S/4HANA”.

W środowiskach z wieloma systemami ERP lub systemami zintegrowanymi pole to ma istotne znaczenie dla śledzenia pochodzenia danych i ich rozdzielania. Pomaga analizować właściwy zbiór danych oraz diagnozować problemy z ich jakością przez wskazanie systemu źródłowego.

Dlaczego to ważne

Wskazuje źródło danych, co ma znaczenie dla zarządzania danymi, rozwiązywania problemów i pracy w środowiskach z wieloma systemami.

Skąd pobrać

Zwykle jest to stała wartość dodawana podczas ekstrakcji danych w celu oznaczenia ich źródła.

Przykłady
SAP S/4HANASAP ECC 6.0S4H_PROD_100
Kod jednostki gospodarczej
CompanyCode
Jednostka organizacyjna, w której obsługiwana jest faktura.
Opis

Kod jednostki gospodarczej oznacza najmniejszą jednostkę organizacyjną, dla której można sporządzić kompletny, samodzielny zestaw kont na potrzeby sprawozdawczości zewnętrznej. W procesie obsługi zobowiązań reprezentuje podmiot prawny, który jest winien pieniądze dostawcy.

Analiza według kodu jednostki gospodarczej pozwala porównywać wyniki procesu w różnych podmiotach prawnych organizacji. Pomaga ustalić, które części firmy stosują standardowy proces, a w których proces jest sprawniejszy, trwa dłużej lub wymaga więcej poprawek.

Dlaczego to ważne

Umożliwia porównanie wyników procesu w różnych podmiotach prawnych oraz wykrycie problemów i dobrych praktyk charakterystycznych dla regionu lub jednostki biznesowej.

Skąd pobrać

Dane znajdują się w tabelach nagłówków dokumentów, przede wszystkim w polu BKPF-BUKRS dla faktur FI i RBKP-BUKRS dla faktur MM.

Przykłady
10001710US01DE01
Kwota faktury
InvoiceAmount
Łączna kwota brutto faktury w walucie dokumentu źródłowego.
Opis

To łączna wartość faktury przesłanej przez dostawcę. Obejmuje koszt towarów lub usług, podatki i inne opłaty przed odliczeniem potrąceń lub rabatów.

Kwota faktury to ważny atrybut finansowy, wykorzystywany w wielu analizach. Pomaga ustalać priorytety dla faktur o wysokiej wartości, oceniać finansowe skutki opóźnień w procesie, np. opłat za zwłokę przy wysokich kwotach, oraz dzielić proces na segmenty, np. sprawdzać, czy faktury o wysokiej wartości przechodzą inną ścieżkę akceptacji. Jest też niezbędna do wykrywania potencjalnych podwójnych płatności.

Dlaczego to ważne

Nadaje procesowi kontekst finansowy. Umożliwia analizę według wartości, ustalanie priorytetów dla faktur o wysokiej wartości i określanie skutków finansowych.

Skąd pobrać

Dane znajdują się w tabelach takich jak RBKP-RMWWR (kwota brutto faktury) dla faktur MM lub są obliczane na podstawie pozycji w BSEG (pole WRBTR) dla faktur FI.

Przykłady
1500.00250.7512345.50
Nazwa dostawcy
VendorName
Nazwa dostawcy, który przesłał fakturę.
Opis

Ten atrybut zawiera oficjalną nazwę dostawcy. Jest powiązany z numerem dostawcy zapisanym w dokumencie faktury.

Analiza dostawców pomaga zarządzać relacjami z nimi i wykrywać problemy w procesie dotyczące konkretnych dostawców. Pozwala odpowiedzieć na pytania, takie jak „Którzy dostawcy najczęściej przesyłają faktury z niezgodnościami?” lub „Czy strategicznym dostawcom regularnie płacimy w terminie?”. Pole to, wraz z numerem i kwotą faktury, pomaga też wykrywać potencjalne podwójne płatności.

Dlaczego to ważne

Umożliwia analizę wyników procesu według dostawcy, wykrywanie problemów i skuteczniejsze zarządzanie relacjami ze strategicznymi dostawcami.

Skąd pobrać

Dane pobiera się z tabeli danych podstawowych dostawców LFA1 (pole NAME1), łącząc je z numerem dostawcy (LIFNR) z tabeli BKPF lub RBKP.

Przykłady
Office Supplies Inc.Global Consulting GroupMachine Parts GmbH
Nazwa użytkownika
UserName
Identyfikator użytkownika, który wykonał czynność.
Opis

Ten atrybut zapisuje identyfikator użytkownika SAP odpowiedzialnego za wykonanie określonej czynności, takiej jak księgowanie, akceptacja lub rozliczenie faktury. Łączy etapy procesu z konkretnymi użytkownikami.

Analiza według nazwy użytkownika pomaga ocenić rozkład obciążenia pracą, wskazać osoby osiągające najlepsze wyniki i wykryć potrzebę dodatkowego szkolenia. Jest też przydatna przy analizie wąskich gardeł w dashboardach akceptacji, ponieważ pozwala ustalić, które osoby akceptujące powodują opóźnienia.

Dlaczego to ważne

Przypisuje czynności konkretnym osobom, umożliwiając analizę ich wyników i obciążenia pracą oraz zgodności z zasadami rozdziału obowiązków.

Skąd pobrać

Dane znajdują się zwykle w tabelach nagłówków, takich jak BKPF-USNAM (wprowadził), lub w tabelach dokumentów zmian, takich jak CDHDR-USERNAME (zmienił).

Przykłady
ABROWNJSMITHAP_AUTOMATION
Numer zamówienia zakupu
PurchaseOrderNumber
Unikalny identyfikator zamówienia zakupu powiązanego z fakturą, jeśli dotyczy.
Opis

Ten atrybut łączy fakturę z wcześniej zatwierdzonym zamówieniem zakupu (PO). Obecność numeru PO stanowi podstawę uzgadniania trójstronnego: zamówienia zakupu, faktury i przyjęcia towaru.

Atrybut ten jest ważny przy analizie zgodności i sprawności procesu. Służy do obliczania KPI „Odsetek faktur bez zamówienia zakupu”, który mierzy przestrzeganie zasad zakupowych. Jest też podstawą dashboardu „Skuteczność uzgadniania trójstronnego”, który pozwala analizować uzgadnianie faktur powiązanych z zamówieniem zakupu.

Dlaczego to ważne

Pomaga analizować sprawność uzgadniania trójstronnego i zgodność z zasadami zakupowymi przez wskazanie faktur przetwarzanych bez zamówienia zakupu.

Skąd pobrać

Dane znajdują się w tabelach pozycji faktur, takich jak RSEG-EBELN dla faktur MM lub BSEG-EBELN dla faktur FI.

Przykłady
45000012344500005678
Termin płatności faktury
InvoiceDueDate
Termin, do którego należy zapłacić dostawcy za fakturę.
Opis

Termin płatności faktury to data, do której należy zapłacić dostawcy, aby uniknąć opłat za opóźnienie i utrzymać dobre relacje. Wyznacza się go na podstawie daty bazowej faktury i uzgodnionych z dostawcą warunków płatności.

Ta data jest niezbędna w dashboardzie „Zgodność płatności i wiek zobowiązań” oraz przy obliczaniu KPI „Odsetek płatności zrealizowanych w terminie”. Porównanie terminu z datą faktycznej płatności pokazuje, czy płatności są realizowane przed terminem, w terminie czy po terminie, co ma bezpośrednie skutki finansowe i wpływa na relacje z dostawcami.

Dlaczego to ważne

To podstawowa wartość przy analizie płatności w terminie. Pozwala mierzyć terminowość płatności i oceniać jej wpływ na relacje z dostawcami oraz opłaty za opóźnienia.

Skąd pobrać

Ta data jest często obliczana. Termin płatności netto znajduje się w polu BSEG-NETDT. Można go też wyznaczyć na podstawie daty bazowej płatności (BSEG-ZFBDT) i warunków płatności (BSEG-ZTERM).

Przykłady
2023-10-312023-11-152024-01-10
Czy płatność była opóźniona
IsLatePayment
Wartość logiczna wskazująca, czy fakturę opłacono po terminie.
Opis

Ten obliczany atrybut przyjmuje wartość prawda lub fałsz i wskazuje, czy fakturę opłacono po wyznaczonym terminie. Jest wyliczany przez porównanie „Daty rozliczenia” z „Terminem płatności faktury”.

Ułatwia analizę w dashboardzie „Zgodność z terminami płatności i zaległości” oraz obliczanie KPI „Odsetek płatności w terminie”. Pozwala łatwo filtrować i agregować dane, aby policzyć opóźnione płatności, obliczyć odsetek płatności zrealizowanych w terminie oraz wskazać dostawców lub kody spółek, w przypadku których opóźnienia występują najczęściej.

Dlaczego to ważne

Bezpośrednio mierzy zgodność z warunkami płatności, ułatwia obliczanie KPI dotyczącego płatności w terminie i pomaga wskazać obszary, w których płatności są realizowane z opóźnieniem.

Skąd pobrać

Atrybut obliczany. Reguła: IF ClearingDate > InvoiceDueDate THEN true ELSE false.

Przykłady
truefalse
Data rozliczenia
ClearingDate
Data dokonania płatności i rozliczenia faktury w ramach pozycji otwartych.
Opis

Data rozliczenia oznacza finansowe uregulowanie faktury. Jest to data wystąpienia czynności „Płatność rozliczona”, która w większości przypadków kończy obsługę faktury.

Na tej podstawie ustala się faktyczną datę płatności i porównuje ją z terminem płatności faktury. Data ta jest więc niezbędna do obliczenia KPI „Odsetek płatności w terminie” oraz do analiz wyników procesu płatności. Wyznacza również koniec cyklu obsługi faktury, od początku do końca.

Dlaczego to ważne

Oznacza ostateczne rozliczenie faktury. Wyznacza koniec cyklu obsługi i stanowi podstawę analizy płatności dokonanych w terminie.

Skąd pobrać

Dane znajdują się w tabelach rozliczonych pozycji, na przykład BSAK-AUGDT dla dostawców.

Przykłady
2023-10-282023-11-142024-01-09
Numer faktury dostawcy
VendorInvoiceNumber
Numer faktury podany przez dostawcę na dokumencie.
Opis

To numer referencyjny z systemu księgowego dostawcy, widoczny na papierowej lub elektronicznej fakturze. Jest wprowadzany ręcznie lub odczytywany za pomocą OCR podczas przyjmowania faktury.

Pole to ma duże znaczenie w codziennej obsłudze i analizie, zwłaszcza w dashboardzie „Potencjalne podwójne płatności za faktury”. Duplikaty można wykrywać, wyszukując dokumenty wewnętrzne o tej samej nazwie dostawcy, numerze faktury dostawcy i kwocie faktury. Jest to podstawowy zewnętrzny numer referencyjny faktury.

Dlaczego to ważne

Pole to pomaga wykrywać potencjalne podwójne płatności i stanowi podstawowy zewnętrzny numer referencyjny używany w komunikacji z dostawcami.

Skąd pobrać

Dane są przechowywane w polu „Referencja” w nagłówku dokumentu, zwykle BKPF-XBLNR.

Przykłady
INV-2023-9876733401120231015-001
Przyczyna blokady
BlockingReason
Powód zablokowania faktury do płatności, wskazujący na niezgodność.
Opis

Jeśli faktura nie przejdzie kontroli w ramach dopasowania trójstronnego lub innego etapu weryfikacji, zostaje zablokowana do płatności. Przyczyna blokady określa rodzaj problemu, na przykład niezgodność ilości, różnicę w cenie lub brak potwierdzenia przyjęcia towaru.

Ten atrybut ma zasadnicze znaczenie dla dashboardu „Analiza ponownej obsługi niezgodności na fakturach”. Analiza częstotliwości poszczególnych przyczyn blokady pomaga ustalić źródła nieefektywności procesu. Jeśli na przykład często występuje „Różnica w cenie”, może to wskazywać na problemy z danymi podstawowymi w systemie zakupowym.

Dlaczego to ważne

Pozwala bezpośrednio ustalić przyczyny niezgodności na fakturach i ponownej obsługi, co ułatwia ukierunkowane usprawnianie procesu.

Skąd pobrać

Dane są przechowywane w tabelach pozycji faktury, takich jak RSEG, w polach zaczynających się od SPGR* (np. SPGRP, SPGRQ, SPGRT). Można je również znaleźć w RBKP_BLOCKED.

Przykłady
Niezgodność cenyNiezgodność ilościBrak potwierdzenia przyjęcia towaru
Typ dokumentu faktury
InvoiceDocumentType
Klasyfikacja dokumentu faktury, która określa sposób jego przetwarzania w SAP.
Opis

Typ dokumentu to element konfiguracji SAP, który klasyfikuje dokumenty księgowe. Na przykład „KR” jest zwykle używany dla faktur dostawców, „RE” dla faktur MM, a „KG” dla not uznaniowych dostawców. Typ określa między innymi zakres numeracji i wymagane pola.

Filtrowanie według typu dokumentu pozwala porównywać przebieg procesu dla różnych rodzajów faktur. Na przykład proces akceptacji noty uznaniowej może różnić się od procesu dla standardowej faktury. Jest to przydatne w dashboardzie „Warianty ścieżek akceptacji faktur”.

Dlaczego to ważne

Umożliwia podział procesu według sposobu obsługi różnych typów faktur i ujawnia różnice w ścieżkach przetwarzania oraz czasie cyklu.

Skąd pobrać

Bezpośrednio z tabeli nagłówków dokumentów, z pola BKPF-BLART.

Przykłady
KRREKG
Waluta faktury
InvoiceCurrency
Kod waluty, w której podano kwotę faktury (np. USD, EUR).
Opis

Ten atrybut określa walutę, w której wyrażono kwotę faktury. Jest niezbędnym kontekstem dla wszystkich wartości finansowych.

W organizacji działającej w wielu krajach analiza faktur bez uwzględnienia waluty może prowadzić do błędnych wniosków. To pole pozwala prawidłowo przetwarzać dane finansowe: przeliczyć wszystkie kwoty na jedną walutę raportową albo podzielić analizę według walut, aby porównać wyniki finansowe w poszczególnych regionach.

Dlaczego to ważne

Uzupełnia kwotę faktury o informację o walucie, co umożliwia rzetelną analizę i raportowanie finansowe, zwłaszcza w organizacjach działających w wielu krajach.

Skąd pobrać

Dane znajdują się w tabelach nagłówków dokumentów, przede wszystkim BKPF-WAERS lub RBKP-WAERS.

Przykłady
USDEURGBPJPY
Warunki płatności
PaymentTerms
Warunki uzgodnione z dostawcą dotyczące płatności za fakturę, często obejmujące możliwość uzyskania rabatu.
Opis

Warunki płatności określają terminy płatności i zasady przyznawania rabatów za wcześniejszą zapłatę. Na przykład warunek „Z001” może oznaczać: „Płatność w ciągu 30 dni, rabat 2% przy zapłacie w ciągu 10 dni”.

Ten atrybut stanowi podstawę dashboardu „Wykorzystanie rabatów za wcześniejszą płatność”. Analiza warunków płatności pozwala wskazać wszystkie faktury uprawniające do rabatu. Porównanie ich z faktycznie uzyskanymi rabatami pokazuje utracone oszczędności i pozwala ocenić sprawność procesu płatności.

Dlaczego to ważne

Atrybut ten jest niezbędny do analizy możliwości uzyskania rabatu za wcześniejszą płatność, oceny wyników finansowych procesu płatności i wykrywania utraconych oszczędności.

Skąd pobrać

Dane znajdują się w pozycjach dostawcy w tabeli BSEG-ZTERM lub w nagłówku faktury w RBKP-ZTERM.

Przykłady
Z0010001NT30
Wykonano automatycznie
IsAutomated
Flaga wskazująca, czy czynność wykonał automatycznie system, a nie użytkownik.
Opis

Ten atrybut logiczny rozróżnia czynności wykonane przez ludzi od tych realizowanych przez zadania systemowe, workflow lub boty. Na przykład automatyczny przebieg płatności lub księgowanie faktury wygenerowane przez system zostaną oznaczone jako automatyczne.

Analiza tego atrybutu pomaga ocenić poziom automatyzacji procesu obsługi zobowiązań. Można go użyć do pomiaru efektów wdrożonych rozwiązań, porównania sprawności etapów automatycznych i ręcznych oraz wskazania kolejnych możliwości automatyzacji.

Dlaczego to ważne

Pomaga mierzyć poziom automatyzacji procesu, oceniać jej skuteczność i wskazywać możliwości dalszych usprawnień.

Skąd pobrać

Wartość ustala się na podstawie nazwy użytkownika, np. identyfikatorów kont systemowych takich jak 'SAP_SYSTEM' lub 'BATCHUSER', albo kodów transakcji powiązanych z zadaniami automatycznymi.

Przykłady
truefalse
Zastosowano rabat
DiscountTaken
Wartość logiczna wskazująca, czy udało się uzyskać rabat za wcześniejszą płatność.
Opis

Ten atrybut wskazuje, czy przy płatności za fakturę faktycznie zastosowano rabat. Pomaga ocenić efektywność finansową procesu obsługi zobowiązań.

Stanowi podstawę KPI „Wykorzystanie rabatów za wcześniejszą płatność”. Wystarczy wybrać faktury uprawniające do rabatu na podstawie warunków płatności i sprawdzić ten atrybut, aby dokładnie obliczyć uzyskane oszczędności oraz liczbę niewykorzystanych możliwości. Dzięki temu można liczbowo ocenić wyniki obsługi zobowiązań.

Dlaczego to ważne

Bezpośrednio mierzy skuteczność uzyskiwania dostępnych rabatów za wcześniejszą płatność, które wpływają na wynik finansowy firmy.

Skąd pobrać

Atrybut jest wyliczany przez sprawdzenie, czy kwota rabatu w polu BSEG-SKNTO na dokumencie płatności jest większa od zera.

Przykłady
truefalse
Wymagane Zalecane Opcjonalne

Czynności w procesie obsługi faktur zakupu

To najważniejsze kroki i etapy procesu, które należy uwzględnić w dzienniku zdarzeń, aby prawidłowo odkryć i usprawnić proces.
7 Zalecane 8 Opcjonalne
Działanie Opis
Anulowano fakturę
Dokument faktury został storno, co skutecznie wyzerowało jego wpływ finansowy. Jest to alternatywny stan końcowy procesu, często wynikający z błędnego wpisu lub sporu z dostawcą.
Dlaczego to ważne

Śledzenie anulowań pomaga ustalić przyczyny niepowodzeń procesu, takie jak zduplikowane zgłoszenia lub nieprawidłowe dane faktury. Może też wskazać problemy na wcześniejszych etapach.

Skąd pobrać

Zdarzenie jest jawnie rejestrowane po utworzeniu dokumentu storna. W nagłówku pierwotnego dokumentu (BKPF) zostają wypełnione numer dokumentu storna (STBLG) i przyczyna storna.

Rejestrowanie

Ustal datę księgowania dokumentu storna powiązanego z pierwotnym dokumentem w nagłówku (BKPF-STBLG).

Typ zdarzenia explicit
Otrzymano fakturę
To zdarzenie oznacza utworzenie dokumentu faktury w SAP, ręcznie lub za pośrednictwem zautomatyzowanego interfejsu, takiego jak OCR/VIM. Zwykle rejestruje się je na podstawie daty i godziny utworzenia nagłówka dokumentu księgowego.
Dlaczego to ważne

Jako początkowy etap procesu zdarzenie to jest niezbędne do obliczenia pełnego czasu obsługi faktury i pomiaru przepustowości całego procesu zobowiązań.

Skąd pobrać

Zdarzenie odczytuje się z tabeli nagłówków dokumentów księgowych (BKPF), korzystając z daty utworzenia dokumentu (CPUDT) i godziny (CPUTM).

Rejestrowanie

Użyj znacznika czasu utworzenia dokumentu faktury (BKPF-CPUDT, BKPF-CPUTM).

Typ zdarzenia explicit
Rozliczono płatność
To zdarzenie oznacza ostateczne zamknięcie faktury. Płatność i faktura zostają wzajemnie rozliczone w księdze pomocniczej. Oznacza to zakończenie procesu.
Dlaczego to ważne

Jako końcowy etap procesu zdarzenie to jest niezbędne do dokładnego obliczenia pełnego czasu obsługi faktury. Potwierdza uregulowanie zobowiązania.

Skąd pobrać

Jest to jawne zdarzenie. Występuje, gdy pole daty rozliczenia (AUGDT) zostaje wypełnione w pozycji dostawcy dokumentu faktury (tabela BSEG).

Rejestrowanie

Użyj daty rozliczenia (BSEG-AUGDT) z pozycji faktury.

Typ zdarzenia explicit
Zaakceptowano fakturę
Faktura uzyskała wszystkie wymagane akceptacje w systemie workflow. Często jest to ostatni etap przed zaksięgowaniem faktury lub zdjęciem blokady płatności.
Dlaczego to ważne

Ten ważny etap oznacza koniec cyklu akceptacji. Czas od przekazania faktury do akceptacji do jej zatwierdzenia jest istotnym miernikiem sprawności procesu.

Skąd pobrać

Zdarzenie odczytuje się z dzienników SAP Business Workflow jako zakończenie lub końcowy etap zwolnienia. Można je też ustalić na podstawie zdjęcia blokady płatności po przekazaniu faktury do akceptacji.

Rejestrowanie

Wyodrębnij zdarzenia zakończenia workflow z dzienników SAP workflow lub zidentyfikuj końcowe zdarzenie „release”.

Typ zdarzenia explicit
Zablokowano płatność faktury
System automatycznie lub ręcznie zablokował fakturę, uniemożliwiając jej opłacenie. Przyczyną są zwykle rozbieżności w cenie lub ilości albo brak wymaganych akceptacji.
Dlaczego to ważne

To ważny sygnał problemów i konieczności poprawek. Analiza przyczyn i czasu trwania blokad pomaga ustalić źródła opóźnień płatności i nieefektywności procesu.

Skąd pobrać

Jest to jawny status zapisany w polu klucza blokady płatności (ZLSPR) w pozycji dostawcy dokumentu księgowego (tabela BSEG).

Rejestrowanie

Zdarzenie jest rejestrowane w dokumentach zmian, gdy pole BSEG-ZLSPR zawiera przyczynę blokady.

Typ zdarzenia explicit
Zaksięgowano fakturę
Faktura została formalnie ujęta w księdze głównej, co oznacza powstanie zobowiązania finansowego. Dokument wstępnie wprowadzony staje się zaksięgowany albo faktura jest księgowana bezpośrednio.
Dlaczego to ważne

To ważny etap finansowy. Potwierdza zobowiązanie firmy do zapłaty i często jest warunkiem zaplanowania płatności.

Skąd pobrać

Zdarzenie identyfikuje się na podstawie daty księgowania (BUDAT) w nagłówku dokumentu (BKPF). W zaksięgowanym dokumencie pole statusu (BKPF-BSTAT) jest puste.

Rejestrowanie

W przypadku dokumentów, które nie są wstępnie wprowadzone (BKPF-BSTAT jest puste), użyj daty księgowania (BKPF-BUDAT).

Typ zdarzenia explicit
Zrealizowano płatność
Faktura została opłacona. Zdarzenie rejestruje się po zakończeniu przebiegu płatności oraz utworzeniu i zaksięgowaniu dokumentu płatności.
Dlaczego to ważne

To zdarzenie jest ważne przy analizie przepływów pieniężnych i pomiarze KPI „Odsetek płatności zrealizowanych w terminie”. W tym celu datę płatności porównuje się z terminem płatności faktury.

Skąd pobrać

Zdarzenie odczytuje się z daty księgowania dokumentu płatności, który rozlicza fakturę. Numer dokumentu płatności jest powiązany z fakturą w polu dokumentu rozliczającego (AUGBL) pozycji faktury (BSEG).

Rejestrowanie

Ustal datę księgowania (BUDAT) dokumentu płatności rozliczającego pozycję faktury.

Typ zdarzenia explicit
Minął termin płatności faktury
To obliczane zdarzenie oznacza, że minął termin płatności netto faktury, a płatność nie została rozliczona. Wskazuje na opóźnienie lub zaległość w płatności.
Dlaczego to ważne

To zdarzenie jest niezbędne w dashboardzie „Zgodność płatności i wiek zobowiązań”. Pomaga wcześniej wykrywać i obsługiwać przeterminowane faktury oraz analizować przyczyny opóźnień w płatnościach.

Skąd pobrać

SAP nie rejestruje tego jako jawnego zdarzenia. Oblicza się je, porównując bieżącą datę systemową z terminem płatności netto, wyznaczonym na podstawie BSEG-ZFBDT lub daty bazowej i warunków płatności.

Rejestrowanie

Zdarzenie obliczane, gdy znacznik czasu zdarzenia jest późniejszy niż termin płatności netto faktury.

Typ zdarzenia calculated
Odrzucono fakturę
Osoba akceptująca odrzuciła fakturę w workflow akceptacji. Zwykle powoduje to zwrot faktury do osoby obsługującej ją w celu poprawienia lub uzupełnienia danych.
Dlaczego to ważne

Śledzenie odrzuceń ujawnia pętle poprawek w procesie akceptacji i może wskazywać na problemy ze zgodnością z zasadami lub nieprawidłowe kodowanie faktur.

Skąd pobrać

Zdarzenie jest rejestrowane jako określony wynik w dziennikach SAP Business Workflow powiązanych z fakturą.

Rejestrowanie

Wyodrębnij zdarzenia statusu „rejected” z dzienników SAP workflow.

Typ zdarzenia explicit
Przekazano fakturę do akceptacji
Faktura została przekazana do workflow akceptacji zgodnie z wymaganymi regułami biznesowymi. Oznacza to początek podprocesu akceptacji.
Dlaczego to ważne

To zdarzenie wyznacza początek pomiaru KPI „Średni czas akceptacji faktury” i analizy wąskich gardeł w procesie akceptacji.

Skąd pobrać

Zdarzenie można odczytać z dzienników SAP Business Workflow (tabele SWW*), które rejestrują rozpoczęcie instancji workflow powiązanej z obiektem faktury, np. BUS2081.

Rejestrowanie

Wyodrębnij zdarzenia rozpoczęcia workflow z dzienników SAP workflow, np. z tabeli SWW_WIHEAD, i powiąż je z dokumentem faktury.

Typ zdarzenia explicit
Rozwiązano niezgodność
To zdarzenie oznacza, że zbadano i rozwiązano wcześniej wykryty problem, który prawdopodobnie spowodował blokadę płatności. Rejestruje się je po usunięciu blokady płatności faktury.
Dlaczego to ważne

Śledzenie tej pętli poprawek jest niezbędne w dashboardzie „Analiza poprawek niezgodności na fakturach”. Pozwala określić czas i nakład pracy poświęcone na usuwanie błędów.

Skąd pobrać

Zdarzenie ustala się na podstawie dokumentów zmian wskazujących na usunięcie blokady płatności. Głównym źródłem jest dziennik zmian pola BSEG-ZLSPR.

Rejestrowanie

Wyszukaj dokumenty zmian dla tabeli BSEG, w których wartość pola ZLSPR została zmieniona z niepustej na pustą.

Typ zdarzenia inferred
Utworzono propozycję płatności
Faktura została uwzględniona w propozycji płatności w ramach przebiegu płatności, np. F110. Jest przeznaczona do opłacenia po ostatecznym wykonaniu przebiegu.
Dlaczego to ważne

To zdarzenie pokazuje przejście od otwartego zobowiązania do pozycji przygotowywanej do płatności. Pomaga analizować sprawność operacji płatniczych.

Skąd pobrać

Zdarzenie jest jawnie rejestrowane w tabelach danych przebiegu płatności, w szczególności REGUP (pozycje przetworzone przez program płatności) i REGUH (nagłówek).

Rejestrowanie

Ustal, kiedy faktura pojawia się w tabeli REGUP dla przebiegu płatności wskazanego w REGUH.

Typ zdarzenia explicit
Uzgodniono z przyjęciem towaru
To zdarzenie oznacza pomyślne uzgodnienie ilości i wartości na fakturze z odpowiednim dokumentem przyjęcia towaru. Jest to końcowy etap weryfikacji w uzgadnianiu trójstronnym.
Dlaczego to ważne

Śledzenie tego zdarzenia pomaga wykryć nieefektywności w uzgadnianiu trójstronnym i rozbieżności między przyjętym towarem a pozycjami na fakturze od dostawcy.

Skąd pobrać

Zdarzenie ustala się na podstawie odwołania do dokumentu materiałowego (przyjęcia towaru) w pozycji faktury. Odwołanie jest często powiązane z historią pozycji zamówienia zakupu.

Rejestrowanie

Zdarzenie ustala się na podstawie odwołania do dokumentu przyjęcia towaru w pozycji faktury, np. w tabeli RSEG dla faktur MIRO.

Typ zdarzenia inferred
Uzgodniono z zamówieniem zakupu
To zdarzenie oznacza pomyślne uzgodnienie faktury z odpowiednim zamówieniem zakupu. Jest to ważny etap uzgadniania trójstronnego faktur związanych z zakupami.
Dlaczego to ważne

Analiza tego zdarzenia pozwala ocenić sprawność uzgadniania i stanowi podstawę KPI „Skuteczność uzgadniania trójstronnego” oraz „Odsetek faktur bez zamówienia zakupu”.

Skąd pobrać

Zdarzenie ustala się, gdy pozycja faktury w tabeli BSEG lub ACDOCA zawiera prawidłowy numer zamówienia zakupu (EBELN) i numer pozycji (EBELP).

Rejestrowanie

Zdarzenie ustala się na podstawie obecności odwołania do zamówienia zakupu (BSEG-EBELN) w dokumencie faktury w chwili jego utworzenia.

Typ zdarzenia inferred
Wstępnie wprowadzono fakturę
Faktura została wprowadzona do systemu, ale nie zaksięgowano jej jeszcze w księdze głównej. Ten etap często pozwala zapisać niekompletny dokument i wrócić do jego przetwarzania lub akceptacji później.
Dlaczego to ważne

Śledzenie wstępnie wprowadzonych faktur pomaga wykryć opóźnienia przed rozpoczęciem formalnego księgowania oraz problemy z kompletnością danych lub wstępną weryfikacją.

Skąd pobrać

Status ustala się na podstawie pola statusu dokumentu w nagłówku dokumentu księgowego (BKPF-BSTAT = 'V' oznacza dokument wstępnie wprowadzony). Zdarzenie występuje w chwili ustawienia tego statusu.

Rejestrowanie

Wyszukaj dokumenty zmian dla tabeli BKPF, w których pole BSTAT przyjmuje wartość 'V' (Vor-erfasst/Pre-entered).

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje pobierania danych

Jak pobrać dane z SAP S/4HANA

Gotowi do rozpoczęcia?

Skorzystajcie z tego szablonu, aby rozpocząć inicjatywę process mining i zwiększyć efektywność operacji związanych z zobowiązaniami. Już dziś usprawnijcie proces i ograniczcie zbędne kroki.

Ograniczcie opłaty za opóźnienia. Usprawnijcie obsługę faktur już dziś

Obniżcie koszty obsługi o 60% i łatwiej eliminujcie podwójne płatności.

Rozpocznijcie okres próbny

Karta kredytowa nie jest wymagana. Rozpoczęcie zajmuje kilka minut.