Szablon danych do analizy obsługi płatności zobowiązań
Szablon danych do analizy obsługi płatności zobowiązań
- Podstawowe atrybuty do analizy dostawców i płatności
- Najważniejsze etapy procesu płatności
- Specjalna logika ekstrakcji danych z systemów SAP S/4HANA
Atrybuty procesu obsługi płatności zobowiązań
| Nazwa | Opis | ||
|---|---|---|---|
| Czas zdarzenia EventTime | Dokładny znacznik czasu wystąpienia czynności. | ||
| Opis Czas zdarzenia wskazuje dokładną datę i godzinę zapisania czynności w bazie danych SAP. Pozwala ustalić kolejność zdarzeń w ramach sprawy. Zwykle jest wyznaczany przez połączenie pól daty i czasu CPU z dzienników systemowych lub nagłówków dokumentów. W analizie atrybut ten jest niezbędny do obliczania czasu cyklu, czasu trwania i przepustowości. Pozwala mierzyć odstępy między krokami, na przykład czas od otrzymania faktury do jej końcowego zatwierdzenia. To ważne przy wykrywaniu wąskich gardeł i ocenie KPI, takich jak średni czas zatwierdzania faktury. Dlaczego to ważne Określa chronologiczną kolejność zdarzeń i stanowi podstawę wszystkich obliczeń wydajności opartych na czasie. Skąd pobrać Tabela SAP BKPF, pola CPUDT (data wprowadzenia) i CPUTM (godzina wprowadzenia), lub pola UDATE i UTIME w CDHDR Przykłady 2023-10-12T08:30:00.000Z2023-10-12T14:15:22.000Z2023-10-15T09:00:00.000Z | |||
| Czynność Activity | Konkretne zadanie lub zmiana statusu zdarzenia zarejestrowana dla faktury. | ||
| Opis Ten atrybut opisuje poszczególne kroki procesu w cyklu życia faktury. Obejmuje zdarzenia takie jak utworzenie i zaksięgowanie faktury, jej zablokowanie i zatwierdzenie oraz rozliczenie płatności. Nazwy czynności pochodzą z kodów transakcji, wpisów w dzienniku zmian lub aktualizacji statusu workflow w systemie źródłowym. W analizie pole to służy do mapowania wariantów przebiegu procesu. Umożliwia silnikowi process mining wizualizację kolejności kroków, wykrywanie pętli ponownej pracy i wskazywanie miejsc, w których proces odbiega od standardowego przebiegu. Jest podstawowym elementem dziennika zdarzeń. Dlaczego to ważne Wyznacza węzły na mapie procesu, dzięki czemu można zobaczyć przebieg workflow i wąskie gardła. Skąd pobrać Na podstawie kodów transakcji (TCODE) lub nagłówka dokumentu zmian (CDHDR) i jego pozycji (CDPOS) Przykłady Faktura zaksięgowanaNałożono blokadę płatnościWykonanie przebiegu płatnościRozliczenie faktury | |||
| Numer faktury InvoiceNumber | Unikalny identyfikator przetwarzanej faktury dostawcy. | ||
| Opis Numer faktury jest głównym identyfikatorem służącym do śledzenia cyklu życia zobowiązania w systemie SAP S/4HANA. Chodzi o numer dokumentu księgowego nadawany podczas księgowania faktury w księdze głównej. W standardowej terminologii SAP jest to numer dokumentu (BELNR), rozpatrywany w ramach określonej jednostki gospodarczej i roku obrotowego. W analizie procesów ten atrybut pełni funkcję Case ID. Łączy wszystkie powiązane zdarzenia: od otrzymania i wstępnego zapisania faktury, przez blokady i zmiany, aż po końcowe rozliczenie płatności. Grupowanie zdarzeń według tego identyfikatora pozwala odtworzyć pełną historię obsługi każdego zobowiązania. Dlaczego to ważne Pełni funkcję jednoznacznego Case ID i pozwala odtworzyć przebieg procesu płatności od początku do końca. Skąd pobrać Tabela SAP BKPF (nagłówek dokumentu księgowego), pole BELNR, lub tabela ACDOCA, pole BELNR Przykłady 1900000523510000289119000006015100003002 | |||
| Ostatnia aktualizacja danych LastDataUpdate | Znacznik czasu wskazujący, kiedy rekord został ostatnio pobrany lub odświeżony. | ||
| Opis Ostatnia aktualizacja danych wskazuje moment pomyślnego załadowania danych do platformy process mining. Nie jest to czas wystąpienia zdarzenia biznesowego, lecz informacja o aktualności samego zbioru danych. Ma to znaczenie dla wiarygodności analiz w dashboardach. Atrybut ten pomaga ocenić, jak aktualne są wyświetlane informacje. Jest szczególnie przydatny przy monitorowaniu dashboardów z danymi zbliżonymi do czasu rzeczywistego, takich jak analiza blokad płatności. Dzięki temu decyzje można podejmować na podstawie najnowszego stanu systemu SAP S/4HANA. Dlaczego to ważne Informuje o aktualności danych, co ma znaczenie przy korzystaniu z dashboardów operacyjnych. Skąd pobrać Wartość generowana przez proces ETL lub ekstrakcji danych Przykłady 2023-10-27T23:59:59.000Z2023-11-01T06:00:00.000Z | |||
| System źródłowy SourceSystem | Identyfikator instancji SAP S/4HANA, z której pochodzą dane. | ||
| Opis Ten atrybut wskazuje instalację ERP lub klienta, z którego pobrano dane o procesie. W środowiskach z wieloma instancjami SAP lub równolegle działającymi systemami starszego typu pozwala zachować informacje o pochodzeniu danych i porównywać wyniki między systemami. W analizie pole to służy jako filtr ogólnego poziomu. Pomaga rozdzielić dane przy porównywaniu wyników między instalacjami regionalnymi lub sprawdzaniu ich spójności podczas migracji systemu. Ułatwia też uwzględnienie wpływu konfiguracji systemu na różnice w przebiegu procesu. Dlaczego to ważne Rozróżnia źródła danych w środowiskach wielosystemowych i pozwala prawidłowo dzielić dane na segmenty. Skąd pobrać Identyfikator systemu (SY-SYSID) z konfiguracji instalacji SAP Przykłady SAP_PROD_01S4H_NA_100ERP_EU_200 | |||
| Bez obsługi ręcznej IsTouchless | Flaga logiczna informująca, czy faktura została przetworzona bez ręcznej interwencji. | ||
| Opis Atrybut jest obliczany na podstawie strumienia zdarzeń dla danego przypadku. Jeśli obejmuje on wyłącznie działania zautomatyzowane, na przykład wykonane przez użytkownika „system” lub określone transakcje w tle (TCODE), i nie zawiera ręcznych zmian ani blokad, przypadek otrzymuje oznaczenie „bez obsługi ręcznej”. W analizie jest to podstawowa miara KPI udziału faktur przetwarzanych bez obsługi ręcznej. Pozwala śledzić wyniki inicjatyw automatyzacyjnych i sprawdzać, które typy przypadków, na przykład według dostawcy lub regionu, przechodzą przez system bez udziału człowieka. Dlaczego to ważne To podstawowa miara automatyzacji i efektywności procesu. Skąd pobrać Obliczane na podstawie kolejności działań i typów użytkowników Przykłady truefalse | |||
| Czy płatność jest opóźniona IsLatePayment | Flaga logiczna informująca, czy płatność została zrealizowana po terminie płatności netto. | ||
| Opis Ten atrybut obliczany przyjmuje wartość true, jeśli data rozliczenia przypada po terminie płatności netto. Służy jako binarny wskaźnik efektywności procesu. W analizie flaga pozwala zliczyć przypadki niezgodne z wymaganiami na potrzeby KPI dotyczącego częstotliwości naliczania kar za opóźnione płatności. Ułatwia tworzenie dashboardów: wystarczy zliczyć wartości „True”, bez wykonywania złożonych obliczeń dat w warstwie wizualizacji. Dlaczego to ważne Ułatwia obliczanie KPI dotyczących terminowości. Skąd pobrać Obliczane: data rozliczenia > termin płatności netto Przykłady truefalse | |||
| Data rozliczenia ClearingDate | Data rozliczenia faktury płatnością. | ||
| Opis Data rozliczenia wskazuje, kiedy otwarta pozycja w księdze zobowiązań została rozliczona, zwykle w ramach przebiegu płatności lub przez ręczne zaksięgowanie płatności. Oznacza to koniec zobowiązania. W analizie atrybut ten służy do obliczania całkowitego czasu cyklu procesu. Jest znacznikiem czasu czynności „Rozliczenie płatności” i jest porównywany z terminem płatności netto, aby ocenić terminowość płatności. Zasila bezpośrednio dashboard efektywności rozliczania płatności. Dlaczego to ważne Oznacza zakończenie procesu płatności i pozwala ocenić jej terminowość. Skąd pobrać Tabela SAP BSEG, pole AUGDT Przykłady 2023-11-012023-11-15 | |||
| Jednostka gospodarcza CompanyCode | Jednostka organizacyjna, dla której sporządza się bilans i rachunek zysków i strat. | ||
| Opis Jednostka gospodarcza to niezależny podmiot księgowy w przedsiębiorstwie. Jest podstawową jednostką organizacyjną w rachunkowości zewnętrznej i służy do porządkowania danych finansowych. Każda faktura jest przypisana do jednej jednostki gospodarczej. W analizie atrybut ten pozwala dzielić KPI według podmiotu prawnego lub regionu. Dashboardy wykorzystują go do porównywania efektywności zespołów obsługujących zobowiązania w różnych spółkach zależnych. Można na przykład sprawdzić, czy w danym oddziale ręczne blokady płatności występują częściej niż w całej firmie. Dlaczego to ważne Pozwala analizować proces według podmiotu prawnego i porównywać wyniki wewnątrz organizacji. Skąd pobrać Tabela SAP BKPF, pole BUKRS Przykłady US01DE1010002000 | |||
| Kwota faktury InvoiceAmount | Łączna kwota brutto faktury w walucie dokumentu. | ||
| Opis Atrybut ten określa wartość finansową faktury zapisaną w dokumencie źródłowym. Jest to zobowiązanie, które należy uregulować wobec dostawcy. W SAP S/4HANA kwota jest zwykle przechowywana w polu kwoty w walucie dokumentu. W analizie kwota faktury pomaga ustalać priorytety pracy. Dashboardy, takie jak rozkład ręcznych punktów obsługi, wykorzystują to pole, aby pokazać, czy czasochłonne czynności ręczne dotyczą faktur o niskiej wartości. Dzięki temu można skupić działania usprawniające na transakcjach o wysokiej wartości, przy których błędy procesu wiążą się z większym ryzykiem finansowym. Dlaczego to ważne Określa wartość finansową sprawy i pomaga ustalać priorytety przy analizie nieefektywności dotyczących transakcji o wysokiej wartości. Skąd pobrać Tabela SAP BKPF lub BSEG, pole WRBTR Przykłady 1500.00250.5010000.00 | |||
| Nazwa użytkownika UserName | Identyfikator użytkownika, który wykonał daną czynność. | ||
| Opis Nazwa użytkownika to identyfikator logowania osoby lub konta systemowego odpowiedzialnego za wykonanie kroku procesu. Może to być użytkownik ręcznie wprowadzający dane albo identyfikator zadania w tle, na przykład „BATCH_USER”, które wykonuje zadania automatycznie. W analizie atrybut ten pozwala obliczyć wskaźnik automatyzacji czynności. Rozróżnienie użytkowników i kont systemowych umożliwia ocenę poziomu automatyzacji procesu. Pole jest też wykorzystywane w dashboardzie rozkładu ręcznych punktów obsługi do analizy obciążenia zespołów. Dlaczego to ważne Pozwala odróżnić pracę ręczną od automatycznej i obliczyć poziom automatyzacji. Skąd pobrać Tabela SAP BKPF, pole USNAM, lub tabela CDHDR, pole USERNAME Przykłady BSMITHWF-BATCHRJONES | |||
| Numer dostawcy VendorNumber | Unikalny identyfikator dostawcy powiązanego z fakturą. | ||
| Opis Numer dostawcy wskazuje konkretne konto wierzyciela w księdze pomocniczej SAP. Łączy fakturę z danymi podstawowymi, które obejmują warunki płatności, dane bankowe i kontaktowe. W S/4HANA często jest powiązany z koncepcją partnera biznesowego, ale w wielu tabelach nadal występuje pod starszą nazwą pola LIFNR. W analizie atrybut ten jest podstawą dashboardu zgodności warunków płatności dostawców. Pozwala zestawiać wyniki procesu według dostawcy i wskazywać tych, którzy regularnie powodują blokady, rozbieżności cenowe lub opóźnienia. Dane te wspierają decyzje dotyczące zakupów strategicznych i zarządzania relacjami z dostawcami. Dlaczego to ważne Pozwala porównywać wyniki według dostawcy i wskazywać przyczyny opóźnień. Skąd pobrać Tabela SAP BKPF, pole LIFNR, lub tabela ACDOCA, pole LIFNR Przykłady 100050VEND-US-99200400 | |||
| Przyczyna blokady płatności PaymentBlockReason | Kod określający przyczynę zablokowania faktury do płatności. | ||
| Opis Atrybut ten zawiera kod przyczyny blokady faktury, która uniemożliwia uwzględnienie jej w automatycznym przebiegu płatności. Przykładowe wartości to „A” dla blokady płatności, „R” dla weryfikacji faktury lub blokady ustawione ręcznie przez użytkowników. W analizie pole to jest głównym źródłem danych dla dashboardu analizy ręcznych blokad płatności. Zestawienie częstotliwości poszczególnych przyczyn pozwala wykrywać problemy systemowe, takie jak częste rozbieżności cenowe lub brak potwierdzenia przyjęcia towaru, które opóźniają płatności. Dlaczego to ważne Wskazuje konkretną przyczynę przestojów w procesie i ułatwia analizę ich źródeł. Skąd pobrać Tabela SAP BSEG, pole ZLSPR Przykłady ABR* | |||
| Termin płatności netto NetDueDate | Obliczona data, do której należy zapłacić fakturę, aby uniknąć kar. | ||
| Opis Termin płatności netto to ostateczny termin zapłaty. Oblicza się go, dodając maksymalną liczbę dni przewidzianą na płatność do daty bazowej. Czasem jest zapisany bezpośrednio, ale często oblicza się go w widokach analitycznych. W analizie jest podstawowym punktem odniesienia dla narzędzia do monitorowania opóźnionych płatności i kar. Porównanie rzeczywistej daty rozliczenia z terminem płatności netto pozwala obliczyć liczbę dni opóźnienia. Miara ta pomaga ocenić efektywność zespołu obsługującego zobowiązania i ryzyko pogorszenia relacji z dostawcami. Dlaczego to ważne To docelowy termin procesu. Jego przekroczenie może wpłynąć na ocenę wiarygodności kredytowej i generować koszty. Skąd pobrać Obliczenie: data bazowa + maksymalna liczba dni na płatność (ZBD1T/ZBD2T/ZBD3T) Przykłady 2023-11-302023-12-01 | |||
| Typ dokumentu DocumentType | Określa rodzaj dokumentu księgowego, na przykład fakturę dostawcy, płatność lub notę kredytową. | ||
| Opis Typ dokumentu to dwuznakowy kod w SAP, który określa rodzaj transakcji księgowej. Do często używanych typów należą KR dla faktur dostawców, KZ dla płatności na rzecz dostawców i RE dla faktur za przyjęte towary. Typ dokumentu określa zakres numeracji i status pól dokumentu. W analizie atrybut ten służy do filtrowania zakresu procesu. Analityk może na przykład wykluczyć noty kredytowe, aby skupić się wyłącznie na efektywności płatności wychodzących. Pole pomaga też określić udział poszczególnych typów transakcji i zasila dashboard złożoności wariantów procesu. Dlaczego to ważne Określa kategorię sprawy, na przykład fakturę lub notę kredytową, i pozwala filtrować analizę. Skąd pobrać Tabela SAP BKPF, pole BLART Przykłady KRREKZKG | |||
| Warunki płatności PaymentTerms | Kod określający uzgodnione warunki płatności i skonta. | ||
| Opis Warunki płatności określają termin zapłaty faktury oraz ewentualne skonto za wcześniejszą płatność. Kod, na przykład „Z001”, odpowiada regułom takim jak „30 dni netto” lub „2% w ciągu 10 dni, 30 dni netto”. Jest kopiowany z danych podstawowych dostawcy do faktury, ale można go zmienić ręcznie. W analizie atrybut ten jest podstawą dashboardów optymalizacji skonta za wcześniejszą płatność i zgodności warunków płatności dostawców. Pozwala obliczyć bazowy termin płatności i sprawdzić, czy płatność zrealizowano w optymalnym okresie, aby uzyskać oszczędności. Dlaczego to ważne Określa oczekiwany termin płatności i zachęty finansowe, co ma znaczenie przy analizie skonta. Skąd pobrać Tabela SAP BSEG, pole ZTERM Przykłady Z001NT300001 | |||
| Data bazowa BaselineDate | Data, od której obowiązują warunki płatności i obliczane są terminy płatności. | ||
| Opis Data bazowa jest punktem wyjścia do obliczenia terminu płatności netto i okresów skonta. Zależnie od konfiguracji i danych podstawowych dostawcy jest to zwykle data faktury lub data księgowania. W analizie data ta jest niezbędna do określenia, czy płatność jest opóźniona. Błędy w dacie bazowej mogą prowadzić do przedwczesnych płatności, wpływających na przepływy pieniężne, lub opóźnień, które wiążą się z karami. Sprawdzenie poprawności tej daty jest częścią analizy zgodności warunków płatności dostawców. Dlaczego to ważne Stanowi punkt odniesienia przy obliczaniu wszystkich terminów płatności. Skąd pobrać Tabela SAP BSEG, pole ZFBDT Przykłady 2023-10-012023-10-15 | |||
| Dokument zakupowy PurchasingDocument | Numer zamówienia zakupu powiązanego z fakturą. | ||
| Opis Atrybut ten łączy fakturę z wcześniejszym etapem procesu zakupowego. Zawiera numer zamówienia zakupu (PO), z którym porównywana jest faktura. Nie każda faktura, na przykład za wydatki różne, ma przypisany numer PO. W analizie pole to jest niezbędne do badania zgodności trójstronnej. Pozwala oddzielić faktury powiązane z zamówieniem od tych bez takiego powiązania, które zwykle podlegają innym workflow zatwierdzania. Umożliwia też analizę procesu od początku do końca przez połączenie danych z obszaru zobowiązań z danymi zakupowymi. Dlaczego to ważne Łączy obszar zobowiązań z zakupami, umożliwiając analizę zgodności trójstronnej i rozszerzenie zakresu procesu. Skąd pobrać Tabela SAP BSEG, pole EBELN Przykłady 45000012344500009876 | |||
| Kwota utraconego rabatu DiscountLostAmount | Wartość pieniężna dostępnych rabatów za wcześniejszą płatność, z których nie skorzystano. | ||
| Opis Ten atrybut obliczany pokazuje wartość rabatów, które można było uzyskać, ale przepadły. Jest wyznaczany przez sprawdzenie, czy płatność nastąpiła po terminie uprawniającym do rabatu. Jeśli tak, obliczana jest wartość utraconego rabatu jako procent kwoty faktury. W analizie jest to ważna miara finansowa dla optymalizacji rabatów za wcześniejszą płatność. Pokazuje koszt nieefektywności w konkretnych kwotach, co pomaga uzasadnić biznesowo ulepszanie procesów. Dlaczego to ważne Pokazuje bezpośrednie straty finansowe wynikające z opóźnień w procesie. Skąd pobrać Obliczane: jeśli data rozliczenia > termin rabatu, to kwota faktury * rabat % Przykłady 30.000.00150.00 | |||
| Liczba dni skonta 1 CashDiscountDays1 | Liczba dni od daty bazowej, w których można uzyskać pierwsze skonto. | ||
| Opis Atrybut ten określa okres obowiązywania najkorzystniejszych warunków płatności, na przykład „10” w warunku „2% w ciągu 10 dni, 30 dni netto”. Wartość pochodzi z warunków zapisanych w pozycji faktury. W analizie pomaga ustalić docelową datę dla narzędzia do optymalizacji skonta za wcześniejszą płatność. Jeśli faktura zostanie rozliczona w tym okresie, skonto zostanie uzyskane. Pole pozwala ocenić koszt utraconych korzyści wynikający z długiego czasu obsługi. Dlaczego to ważne Określa okres, w którym można uzyskać oszczędności. Skąd pobrać Tabela SAP BSEG, pole ZBD1T Przykłady 10140 | |||
| Procent skonta 1 CashDiscountPercentage1 | Wysokość skonta dostępnego przy płatności w pierwszym okresie skonta. | ||
| Opis Atrybut ten określa wysokość korzyści finansowej oferowanej przez dostawcę za wcześniejszą płatność, na przykład „2” w warunku „2% w ciągu 10 dni”. W analizie służy do obliczania potencjalnej kwoty skonta. Pomnożenie tego procentu przez kwotę faktury pozwala pokazać w dashboardach łączną wartość oszczędności utraconych z powodu nieefektywności procesu. Dane te pomagają uzasadnić biznesowo automatyzację. Dlaczego to ważne Określa potencjalną wysokość oszczędności i jest niezbędny do obliczania ROI. Skąd pobrać Tabela SAP BSEG, pole ZBD1P Przykłady 2.03.00.0 | |||
| Rok obrotowy FiscalYear | Rok obrotowy, do którego należy faktura. | ||
| Opis Rok obrotowy to okres wykorzystywany w sprawozdawczości finansowej. Wraz z jednostką gospodarczą i numerem dokumentu tworzy złożony klucz główny dokumentu finansowego w SAP. W analizie jest niezbędny do jednoznacznego identyfikowania spraw, a także umożliwia porównania rok do roku. Dzięki niemu numer faktury używany jako Case ID pozostaje unikalny nawet w wieloletniej historii danych. Dlaczego to ważne Wymóg techniczny umożliwiający jednoznaczną identyfikację spraw w SAP FI. Skąd pobrać Tabela SAP BKPF, pole GJAHR Przykłady 20232024 | |||
| Waluta Currency | Kod waluty przypisany do kwoty faktury. | ||
| Opis Atrybut waluty określa, w jakiej walucie podano kwotę faktury, na przykład USD, EUR lub GBP. Umożliwia prawidłową interpretację wartości finansowych i jest niezbędny przy agregowaniu danych z jednostek gospodarczych działających w różnych krajach. W analizie pole to zapewnia poprawność obliczeń finansowych KPI. Często służy do przeliczania wartości na walutę raportową w dashboardach globalnych. Bez tego atrybutu zbiorcze miary, takie jak łączne wydatki czy średnia wartość faktury, nie miałyby sensu w środowisku wielowalutowym. Dlaczego to ważne Określa walutę kwot i umożliwia prawidłowe raportowanie globalne. Skąd pobrać Tabela SAP BKPF, pole WAERS Przykłady USDEURGBPJPY | |||
Działania w procesie obsługi płatności zobowiązań
| Działanie | Opis | ||
|---|---|---|---|
| Faktura zaksięgowana | Oznacza oficjalne ujęcie zobowiązania w księdze głównej. Zdarzenie można ustalić na podstawie znacznika czasu utworzenia w tabeli BKPF lub daty wprowadzenia w tabeli ACDOCA. | ||
| Dlaczego to ważne To podstawowy punkt początkowy osi czasu finansowej, który wyznacza bazę do obliczania terminów płatności i analizy przeterminowanych należności. Skąd pobrać Tabela BKPF, pola CPUDT (data wprowadzenia) i CPUTM (godzina wprowadzenia). Rejestrowanie Rejestrowane po utworzeniu rekordu w BKPF Typ zdarzenia explicit | |||
| Nałożono blokadę płatności | Oznacza ustawienie blokady płatności na pozycji faktury, która uniemożliwia uwzględnienie jej w sesji płatności. Zdarzenie można wykryć, monitorując zmiany pola ZLSPR w tabeli BSEG na podstawie dokumentów zmian. | ||
| Dlaczego to ważne Blokady są główną przyczyną opóźnionych płatności i zakłóceń procesu. Wpływają bezpośrednio na dashboard analizy ręcznych blokad płatności. Skąd pobrać Tabele CDPOS i CDHDR (dokumenty zmian), z wyszukiwaniem aktualizacji pola BSEG-ZLSPR. Rejestrowanie Rejestrowane po zmianie wartości ZLSPR w rekordach CDPOS Typ zdarzenia explicit | |||
| Rozliczenie płatności | Oznacza końcowe rozliczenie otwartej pozycji na koncie dostawcy z płatnością. Dane pochodzą z pola AUGDT (Clearing Date) w tabeli BSEG. | ||
| Dlaczego to ważne Końcowy stan procesu, który oznacza jego zakończenie i uzgodnienie ksiąg. Wysoki odsetek ręcznych rozliczeń wskazuje na nieefektywne uzgadnianie. Skąd pobrać Tabela BSEG, pole AUGDT (Clearing Date). Rejestrowanie Zarejestrowano po uzupełnieniu pola AUGDT Typ zdarzenia explicit | |||
| Usunięto blokadę płatności | Oznacza zdjęcie wcześniej nałożonej blokady płatności, co umożliwia realizację płatności za fakturę. Zdarzenie można wykryć, gdy pole ZLSPR w tabeli BSEG zmienia wartość na null lub puste. | ||
| Dlaczego to ważne W systemach bez jawnych dzienników workflow często służy jako przybliżony wskaźnik akceptacji faktury i oznacza koniec okresu, w którym proces był zablokowany. Skąd pobrać Tabele CDPOS i CDHDR, z wyszukiwaniem zmian pola BSEG-ZLSPR na wartość pustą. Rejestrowanie Rejestrowane po odnotowaniu usunięcia wartości ZLSPR w rekordach CDPOS Typ zdarzenia explicit | |||
| Utworzenie dokumentu płatności | Utworzenie dokumentu księgowego, który uznaje konto bankowe i obciąża konto dostawcy. Dokument znajduje się w tabeli BKPF i ma typ dokumentu płatności, np. ZP lub KZ. | ||
| Dlaczego to ważne Finansowa realizacja płatności, wykorzystywana do obliczania wskaźnika Days Payable Outstanding (DPO). Skąd pobrać Tabela BKPF, filtrowana według typu dokumentu (BLART) właściwego dla płatności. Rejestrowanie Zarejestrowano podczas tworzenia dokumentu płatności w BKPF Typ zdarzenia explicit | |||
| Wykonanie przebiegu płatności | Oznacza wykonanie przebiegu płatności, podczas którego generowane są dyspozycje przelewów. Zdarzenie jest rejestrowane na podstawie zmiany statusu w tabeli REGUH lub REGUP. | ||
| Dlaczego to ważne Operacyjne zobowiązanie do zapłaty, istotne przy analizie efektywności grupowania płatności. Skąd pobrać Tabela REGUH, zwykle w powiązaniu z datą i identyfikatorem przebiegu. Rejestrowanie Zarejestrowano podczas aktualizacji statusu przebiegu płatności Typ zdarzenia explicit | |||
| Faktura wstępnie wprowadzona | Oznacza, że fakturę wprowadzono do SAP, ale nie zaksięgowano jej jeszcze w księdze głównej. Ten status służy często do wstępnego wprowadzania danych. Można go odczytać bezpośrednio z tabeli VBKPF lub wykryć w tabeli BKPF na podstawie kodu statusu dokumentu wskazującego, że dokument nie został jeszcze zaksięgowany. | ||
| Dlaczego to ważne Wstępne wprowadzenie faktury oznacza początek etapu wprowadzania danych i pozwala zmierzyć czas od otrzymania faktury do powstania zobowiązania finansowego. Skąd pobrać Tabela VBKPF z danymi nagłówkowymi wstępnie wprowadzonych dokumentów lub tabela BKPF z określonym statusem dokumentu (BSTAT = V). Rejestrowanie Rejestrowane po utworzeniu wpisu w VBKPF Typ zdarzenia explicit | |||
| Odwrócenie faktury | Oznacza, że dokument faktury został odwrócony lub anulowany. Zdarzenie można rozpoznać po uzupełnieniu pola STBLG (Reversal Document) w tabeli BKPF. | ||
| Dlaczego to ważne Oznacza ponowne wykonanie pracy i niepowodzenie procesu, wskazując straty oraz możliwe powielanie czynności. Skąd pobrać Tabela BKPF, pole STBLG nie jest puste. Rejestrowanie Zarejestrowano po uzupełnieniu pola STBLG Typ zdarzenia explicit | |||
| Termin płatności faktury | Obliczony timestamp wskazujący moment upływu terminu płatności netto faktury. Wyznacza się go, dodając liczbę dni wynikającą z warunków płatności do daty bazowej zapisanej w tabeli BSEG. | ||
| Dlaczego to ważne Punkt odniesienia dla wskaźnika terminowości płatności i monitorowania kar za opóźnienia. Skąd pobrać Obliczenie: BSEG-ZFBDT (data bazowa) + BSEG-ZBD1T/ZBD2T/ZBD3T (liczba dni). Rejestrowanie Ustal na podstawie porównania bieżącej daty z terminem płatności netto Typ zdarzenia calculated | |||
| Utracono rabat za wcześniejszą płatność | Obliczone zdarzenie oznaczające dzień, w którym upłynął termin skorzystania z rabatu za wcześniejszą płatność. Ustala się je przez porównanie terminu rabatu z bieżącą datą lub datą płatności. | ||
| Dlaczego to ważne Niezbędne do wizualizacji utraconych korzyści finansowych w narzędziu do optymalizacji rabatów za wcześniejszą płatność. Skąd pobrać Obliczenie: BSEG-ZFBDT + BSEG-ZBD1T (liczba dni rabatu 1). Rejestrowanie Ustal na podstawie porównania daty z terminem rabatu Typ zdarzenia calculated | |||
| Utworzono propozycję płatności | Oznacza uwzględnienie faktury w sesji tworzenia propozycji płatności (F110), czyli pierwszym etapie automatycznego programu płatności. Zdarzenie można odczytać z tabeli REGUH, w której przechowywane są dane rozliczeniowe. | ||
| Dlaczego to ważne Oznacza, że fakturę wybrano do płatności i przeszła kontrole poprawności w programie płatności. Skąd pobrać Znacznik czasu utworzenia wpisu w tabeli REGUH (klucze LAUFD i LAUFI). Rejestrowanie Zarejestrowano podczas tworzenia wpisu REGUH Typ zdarzenia explicit | |||
| Wykryto rozbieżność cenową | Zdarzenie wywnioskowane, które wskazuje rozbieżność między ceną na fakturze a ceną w zamówieniu zakupu. Można je ustalić na podstawie automatycznego zastosowania określonego klucza blokady płatności, zwykle „R” dla weryfikacji faktury, podczas księgowania. | ||
| Dlaczego to ważne Pomaga ustalić przyczyny ręcznych poprawek i wspiera analizę poziomu uzgadniania trójstronnego. Skąd pobrać Wnioskowane na podstawie wartości „R” w polu BSEG-ZLSPR (lub konfiguracji blokad cenowych właściwej dla systemu) w chwili księgowania. Rejestrowanie Porównaj wartość ZLSPR z „R” Typ zdarzenia inferred | |||
| Wykryto rozbieżność ilościową | Zdarzenie wywnioskowane, które wskazuje rozbieżność między ilością na fakturze a ilością przyjętych towarów. Można je ustalić na podstawie zastosowania do pozycji określonego klucza blokady płatności, zwykle „M” dla rozbieżności ilościowej. | ||
| Dlaczego to ważne Niezbędne do analizy skuteczności uzgadniania i jakości danych w łańcuchu dostaw. Skąd pobrać Wnioskowane na podstawie wartości „M” w polu BSEG-ZLSPR (lub konfiguracji blokad ilościowych właściwej dla systemu). Rejestrowanie Porównaj wartość ZLSPR z „M” Typ zdarzenia inferred | |||
| Zmieniono warunki płatności | Rejestruje zmianę warunków płatności otwartej faktury, która wpływa na termin płatności lub możliwość uzyskania rabatu. Zmianę śledzi się na podstawie dzienników zmian pola ZTERM w tabeli BSEG. | ||
| Dlaczego to ważne Częste zmiany mogą wskazywać na błędy w danych podstawowych lub ręczne nadpisywanie wartości, które wpływają na prognozowanie przepływów pieniężnych i zgodność z warunkami płatności dostawców. Skąd pobrać Tabele CDPOS i CDHDR, z wyszukiwaniem aktualizacji pola BSEG-ZTERM. Rejestrowanie Rejestrowane po zmianie wartości ZTERM w rekordach CDPOS Typ zdarzenia explicit | |||
Instrukcje ekstrakcji danych
Kroki
Wybierz wymagane widoki CDS: Sprawdź, czy standardowe widoki CDS w SAP S/4HANA są dostępne. Potrzebne są przede wszystkim: I_JournalEntry (nagłówek), I_OperationalAcctgDocItem (pozycje, odpowiednik BSEG), I_SupplierInvoice (logistyka), I_PaymentProposalItem (F110) oraz I_ChangeDocument (dzienniki).
Skonfiguruj uprawnienia użytkownika: Upewnij się, że użytkownik bazy danych lub techniczny użytkownik usługi ma uprawnienia SELECT do widoków DDL SQL powiązanych z encjami CDS. Zwykle konfiguruje się je w SAP HANA Studio lub ABAP Eclipse Development Tools (ADT).
Przygotuj środowisko SQL: Otwórz interfejs SQL, na przykład SAP HANA Studio, DBeaver połączony z HANA lub konektor process mining obsługujący SQL. Ta metoda zakłada bezpośredni dostęp SQL do warstwy HANA, w której widoki CDS są udostępnione jako widoki.
Określ zakres: Wybierz kod spółki (CompanyCode) i zakres lat obrotowych, aby ograniczyć ilość danych. Ma to szczególne znaczenie dla wydajności zapytań do widoku pozycji dokumentów księgowych.
Zdefiniuj logikę działań: Skopiuj poniższe zapytanie SQL. Wykorzystuje ono UNION ALL do połączenia 14 odrębnych bloków logiki w jeden event log. Każdy blok odpowiada konkretnemu działaniu, na przykład zaksięgowaniu faktury lub rozliczeniu płatności.
Uwzględnij dokumenty zmian: Zapytanie zawiera sekcje dotyczące zmian warunków płatności i modyfikacji blokad. Korzystają one z widoku I_ChangeDocument. Jeśli widok nie jest aktywny w używanej wersji S/4, może być konieczne udostępnienie tabel źródłowych (CDHDR/CDPOS) za pomocą niestandardowego widoku CDS.
Sprawdź zdarzenia obliczane: Przejrzyj logikę zdarzeń „Termin płatności faktury” i „Utrata rabatu za wcześniejszą płatność”. Są one wyznaczane przez dodanie odpowiedniej liczby dni do daty bazowej z widoku pozycji operacyjnych.
Uruchom ekstrakcję: Wykonaj zapytanie. W przypadku dużych zbiorów danych zaleca się podział ekstrakcji według roku obrotowego lub kodu spółki, aby uniknąć przepełnienia pamięci.
Sprawdź format daty: Upewnij się, że kolumna EventTime ma format YYYY-MM-DD HH:MM:SS. Znaczniki czasu zwracane przez SAP HANA SQL mogą wymagać konwersji zależnie od aplikacji docelowej.
Wyeksportuj dane: Zapisz wynik jako plik CSV lub Parquet. Nagłówki muszą odpowiadać kolumnom zdefiniowanym w końcowej instrukcji SELECT.
Przygotuj dane do przesłania: Jeśli narzędzie process mining wymaga określonego formatu CSV, na przykład konkretnego formatu daty, zastosuj konwersje w skrypcie przetwarzającym dane lub w SQL za pomocą funkcji TO_VARCHAR.
Przeprowadź końcową walidację: Załaduj próbkę do ProcessMind i sprawdź, czy Case ID (numer faktury) prawidłowo grupuje wszystkie działania, od zaksięgowania po rozliczenie.
Konfiguracja
- Filtr kodu spółki: Ogranicz zapytanie do wybranych jednostek organizacyjnych (CompanyCode = '1000'), aby zachować właściwy zakres danych i wydajność.
- Zakres dat: Zastosuj filtr PostingDate lub CreationDate, na przykład za ostatnie 12 miesięcy, aby kontrolować ilość danych.
- Typ konta: Ustaw w I_OperationalAcctgDocItem filtr FinancialAccountType = 'K' (dostawca), aby wykluczyć pozycje kont księgi głównej i klientów.
- Aktywacja widoków CDS: Upewnij się, że widoki I_JournalEntry, I_OperationalAcctgDocItem i I_PaymentProposalItem są aktywne i udostępnione do dostępu SQL.
- Wydajność dziennika zmian: Odczyt danych z I_ChangeDocument może obciążać system. Ogranicz podzapytania do klasy obiektów 'BELEG' i konkretnych nazw pól, takich jak ZLSPR i ZTERM.
Przykładowe zapytanie sql
/* SAP S/4HANA CDS View Extraction for Accounts Payable */
/* Combined Event Log Query */
/* 1. Invoice Parked */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Parked' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
JE.CreatedByUser AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
CASE WHEN JE.CreationDateTime > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) THEN 'True' ELSE 'False' END AS IsLatePayment,
'False' AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K' -- Vendor
AND JE.AccountingDocumentCategory = 'V' -- Parked Document
UNION ALL
/* 2. Invoice Posted */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Posted' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
JE.CreatedByUser AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
'False' AS IsLatePayment,
CASE WHEN JE.CreatedByUser = 'BATCH_USER' THEN 'True' ELSE 'False' END AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JE.AccountingDocumentCategory <> 'V' -- Exclude Parked
UNION ALL
/* 3. Price Variance Detected (Inferred at Posting) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Price Variance Detected' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.PaymentBlockingReason = 'R' -- Standard SAP Price Variance Block Key
UNION ALL
/* 4. Quantity Variance Detected (Inferred at Posting) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Quantity Variance Detected' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.PaymentBlockingReason = 'M' -- Standard SAP Quantity Variance Block Key
UNION ALL
/* 5. Payment Block Applied (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Block Applied' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
CD.NewValue AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZLSPR'
AND CD.OldValue IS NULL AND CD.NewValue IS NOT NULL
UNION ALL
/* 6. Payment Block Removed (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Block Removed' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZLSPR'
AND CD.OldValue IS NOT NULL AND (CD.NewValue IS NULL OR CD.NewValue = '')
UNION ALL
/* 7. Payment Terms Changed (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Terms Changed' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
CD.NewValue AS PaymentTerms,
NULL AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZTERM'
UNION ALL
/* 8. Invoice Due (Calculated) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Due' AS Activity,
TO_TIMESTAMP(ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays))) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) < CURRENT_DATE
UNION ALL
/* 9. Cash Discount Lost (Calculated) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Cash Discount Lost' AS Activity,
TO_TIMESTAMP(ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.CashDiscount1Days))) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.CashDiscount1Days > 0
AND (JEItem.ClearingDate IS NULL OR JEItem.ClearingDate > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.CashDiscount1Days)))
UNION ALL
/* 10. Payment Proposal Created */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Proposal Created' AS Activity,
PPI.ProposalRunDate AS EventTime, -- Often just a date, cast to timestamp if needed
JE.CompanyCode,
PPI.Supplier AS VendorNumber,
PPI.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PPI.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_PaymentProposalItem AS PPI
JOIN I_JournalEntry AS JE
ON PPI.CompanyCode = JE.CompanyCode
AND PPI.AccountingDocument = JE.AccountingDocument
AND PPI.FiscalYear = JE.FiscalYear
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JEItem.FinancialAccountType = 'K'
UNION ALL
/* 11. Payment Run Executed */
/* Derived from existence in payment tables with a run ID */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Run Executed' AS Activity,
PPI.PaymentRunDate AS EventTime,
JE.CompanyCode,
PPI.Supplier AS VendorNumber,
PPI.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PPI.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_PaymentProposalItem AS PPI
JOIN I_JournalEntry AS JE
ON PPI.CompanyCode = JE.CompanyCode
AND PPI.AccountingDocument = JE.AccountingDocument
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
WHERE PPI.PaymentRunID IS NOT NULL
UNION ALL
/* 12. Payment Document Created */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Document Created' AS Activity,
PayJE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
PayJE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PayJE.CreatedByUser AS UserName,
PayJE.PostingDate AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
JOIN I_JournalEntry AS PayJE
ON JEItem.ClearingJournalEntry = PayJE.AccountingDocument
AND JEItem.ClearingJournalEntryFiscalYear = PayJE.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.ClearingJournalEntry IS NOT NULL
UNION ALL
/* 13. Payment Cleared */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Cleared' AS Activity,
TO_TIMESTAMP(JEItem.ClearingDate) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
JEItem.ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
CASE WHEN JEItem.ClearingDate > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) THEN 'True' ELSE 'False' END AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.ClearingDate IS NOT NULL
UNION ALL
/* 14. Invoice Reversed */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Reversed' AS Activity,
RevJE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
RevJE.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
JOIN I_JournalEntry AS RevJE
ON JE.ReverseDocument = RevJE.AccountingDocument
AND JE.ReverseDocumentFiscalYear = RevJE.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JE.ReverseDocument IS NOT NULL Kroki
- Sprawdź, czy dostępne jest bezpośrednie połączenie SQL ze schematem SAP HANA zawierającym ACDOCA, BKPF, BSEG, VBKPF, REGUH, REGUP oraz odpowiednie tabele dokumentów zmian. Zastąp [Your SAP HANA schema] i dane połączenia wartościami zatwierdzonymi dla danego systemu.
- Ustal zakres faktur i okres raportowania. Ustaw [Start date] i [End date] w formacie YYYYMMDD, a [Company code filter] skonfiguruj jako prawidłowy warunek SQL, na przykład BUKRS IN ('1000','2000').
- Sprawdź wersję SAP i lokalną konfigurację dokumentów wstępnie wprowadzonych, pól statusu programu płatności, typów dokumentów płatności oraz przechowywania dokumentów zmian. Zapytanie korzysta z udokumentowanych obiektów źródłowych i zachowawczego mapowania pól, ale przed użyciem produkcyjnym należy zweryfikować lokalne rozszerzenia i różnice między wersjami.
- Wykonaj zapytanie w SAP HANA za pomocą zatwierdzonego klienta SQL lub usługi ekstrakcji. Zapytanie tworzy jeden wiersz zdarzenia dla każdego jawnie pobieranego działania. ProcessMind nie wywnioskuje działań, których nie ma w wyniku.
- Przejrzyj dane źródłowe i dostosuj oznaczone warunki konfiguracji dotyczące statusu dokumentów wstępnie wprowadzonych, typów dokumentów płatności, statusu propozycji i przebiegu płatności oraz klas obiektów dokumentów zmian. Nie rozszerzaj tych warunków bez sprawdzenia, czy nie pojawią się zduplikowane lub niezwiązane dokumenty księgowe.
- Zweryfikuj połączenia tabel według InvoiceNumber, CompanyCode, roku obrotowego, numeru dokumentu księgowego, numeru dostawcy i pozycji, jeśli ma to zastosowanie. Sprawdź, czy numery dokumentów faktur są spójnie reprezentowane w BKPF, BSEG, ACDOCA, REGUH i REGUP w systemie docelowym.
- Uzgodnij zdarzenia obliczane. Zdarzenie „Termin płatności faktury” jest generowane w obliczonym terminie płatności netto, a „Utrata rabatu za wcześniejszą płatność” w najwcześniejszym właściwym terminie rabatu, jeśli płatność nie nastąpiła wcześniej. Są to wiersze pochodne, dlatego należy je wyraźnie odróżnić od zdarzeń pochodzących z rekordów źródłowych.
- Wyeksportuj wynik jako płaski plik CSV w kodowaniu UTF-8 lub inny tabelaryczny format obsługiwany przez ProcessMind. Zachowaj dokładne nazwy kolumn: InvoiceNumber, Activity, EventTime, SourceSystem i LastDataUpdate. Każde zdarzenie powinno zajmować osobny wiersz. Nie agreguj działań według faktury.
- Prześlij event log do ProcessMind i przypisz InvoiceNumber jako identyfikator przypadku, Activity jako nazwę działania, a EventTime jako znacznik czasu zdarzenia. Pozostałe kolumny przypisz jako atrybuty zdarzenia lub przypadku zgodnie z konfiguracją importu ProcessMind.
Konfiguracja
- Zakres dat: Przy pierwszej ekstrakcji wybierz kroczący okres od 3 do 6 miesięcy. Stosuj spójne warunki dotyczące daty księgowania, daty zmiany i daty programu płatności. Rozszerz zakres podczas weryfikacji długich terminów płatności.
- Schemat: Zastąp [Your SAP HANA schema] nazwą schematu, do którego należą obiekty SAP. Sprawdź, czy wybrany schemat udostępnia obiekty zależne od klienta, czy też wymagają one jawnego warunku klienta.
- Filtrowanie według spółki: Skonfiguruj [Company code filter], aby ograniczyć BUKRS do wymaganych kodów spółek. Zastosuj ten sam zakres do BKPF, BSEG, ACDOCA, REGUH, REGUP i źródeł dokumentów zmian, jeśli dostępne są w nich odpowiednie pola.
- Filtrowanie dokumentów: Sprawdź warunek dotyczący typu dokumentu faktury i warunek dotyczący typu dokumentu płatności. Zapytanie zawiera typowe przykłady, ale typy dokumentów można konfigurować i należy je dostosować do systemu docelowego.
- Faktury wstępnie wprowadzone: Sprawdź, jak status dokumentu wstępnie wprowadzonego jest reprezentowany w VBKPF lub BKPF. Zapytanie wykorzystuje konfigurowalny warunek statusu, ponieważ jego kodowanie może się różnić w zależności od wersji i wdrożenia.
- Zmiany płatności: Sprawdź klasę obiektu dokumentu zmian, nazwę tabeli, nazwy pól i sposób reprezentacji wartości dla BSEG-ZLSPR i BSEG-ZTERM. Sposób przechowywania dokumentów zmian i nazewnictwo pól należy zweryfikować w systemie docelowym.
- Program płatności: Sprawdź pola REGUH i REGUP używane do określania statusu propozycji i wykonania, daty przebiegu, identyfikatora przebiegu oraz powiązania z dokumentem księgowym. Lokalna konfiguracja programu płatności może wpływać na dostępne wartości statusu.
- Wydajność: Ogranicz zakres dat i kody spółek, wybieraj tylko potrzebne kolumny i stosuj filtry dla źródeł przed łączeniem tabel. Przy dużych zbiorach danych przygotuj przefiltrowane podzbiory źródłowe lub użyj zatwierdzonego widoku kalkulacyjnego HANA albo schematu ekstrakcji.
- Uprawnienia: Wymagany jest dostęp do odczytu odpowiednich obiektów schematu SAP HANA oraz widoków udostępniających dane księgowe, dane programu płatności i dokumenty zmian. Uzgodnij dostęp z zespołami ds. bezpieczeństwa SAP i zarządzania danymi.
- Wymagania funkcjonalne: Odpowiednie funkcje księgowości finansowej, obsługi zobowiązań, programu płatności i dokumentów zmian muszą być aktywne i zawierać dane. Jeśli dana tabela źródłowa nie jest używana we wdrożeniu, skonfiguruj zatwierdzony zamiennik zgodny z projektem systemu.
- Obsługa znaczników czasu: BKPF i BSEG zwykle przechowują daty i godziny w osobnych polach. Zapytanie łączy je w znacznik czasu. Sprawdź strefę czasową systemu źródłowego i przed przesłaniem danych do ProcessMind zastosuj wymaganą konwersję.
- Ochrona danych: Ogranicz zakres danych dostawców i księgowych do zatwierdzonego minimum oraz stosuj zasady organizacji dotyczące przechowywania, maskowania i dostępu.
Przykładowe zapytanie sql
WITH
params AS (
SELECT
TO_DATE('[Start date]', 'YYYYMMDD') AS start_date,
TO_DATE('[End date]', 'YYYYMMDD') AS end_date,
'[Source system identifier]' AS source_system
FROM DUMMY
),
base_bkpf AS (
SELECT
b.MANDT,
b.BUKRS,
b.BELNR,
b.GJAHR,
b.BLART,
b.BLDAT,
b.BUDAT,
b.CPUDT,
b.CPUTM,
b.USNAM,
b.STBLG,
b.STJAH,
b.XBLNR,
b.WAERS,
b.BKTXT,
p.source_system,
p.start_date,
p.end_date
FROM [Your SAP HANA schema].BKPF b
CROSS JOIN params p
WHERE b.BUDAT BETWEEN TO_VARCHAR(p.start_date, 'YYYYMMDD') AND TO_VARCHAR(p.end_date, 'YYYYMMDD')
AND [Company code filter]
),
invoice_bseg AS (
SELECT
k.MANDT,
k.BUKRS,
k.BELNR,
k.GJAHR,
k.BLART,
k.BLDAT,
k.BUDAT,
k.CPUDT,
k.CPUTM,
k.USNAM,
k.STBLG,
k.STJAH,
k.XBLNR,
k.WAERS,
k.BKTXT,
k.source_system,
s.BUZEI,
s.LIFNR,
s.WRBTR,
s.DMBTR,
s.ZTERM,
s.ZLSPR,
s.ZFBDT,
s.ZBD1T,
s.ZBD2T,
s.ZBD3T,
s.AUGDT,
s.AUGBL,
s.SHKZG,
s.SGTXT,
s.XREF1,
s.XREF2,
s.XREF3
FROM base_bkpf k
INNER JOIN [Your SAP HANA schema].BSEG s
ON s.MANDT = k.MANDT
AND s.BUKRS = k.BUKRS
AND s.BELNR = k.BELNR
AND s.GJAHR = k.GJAHR
WHERE s.LIFNR IS NOT NULL
AND s.LIFNR <> ''
),
acdoca_invoice AS (
SELECT
a.RCLNT AS MANDT,
a.RBUKRS AS BUKRS,
a.BELNR,
a.GJAHR,
a.BUZEI,
a.RACCT,
a.HSL,
a.WSL,
a.RWCUR,
a.BUDAT,
a.BLDAT,
a.AUGDT,
a.AUGBL
FROM [Your SAP HANA schema].ACDOCA a
WHERE a.BUDAT BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
AND [ACDOCA company code filter]
),
invoice_cases AS (
SELECT DISTINCT
i.MANDT,
i.BUKRS,
i.BELNR,
i.GJAHR,
i.BUZEI,
i.LIFNR,
i.WRBTR,
i.ZTERM,
i.ZLSPR,
i.ZFBDT,
i.ZBD1T,
i.ZBD2T,
i.ZBD3T,
i.AUGDT,
i.AUGBL,
i.BLART,
i.BLDAT,
i.BUDAT,
i.CPUDT,
i.CPUTM,
i.USNAM,
i.STBLG,
i.STJAH,
i.XBLNR,
i.WAERS,
i.source_system,
COALESCE(NULLIF(i.XBLNR, ''), i.BELNR) AS InvoiceNumber,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD3T, '')), 0)) AS NetDueDate,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD1T, '')), 0)) AS DiscountDueDate1,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD2T, '')), 0)) AS DiscountDueDate2
FROM invoice_bseg i
LEFT JOIN acdoca_invoice a
ON a.MANDT = i.MANDT
AND a.BUKRS = i.BUKRS
AND a.BELNR = i.BELNR
AND a.GJAHR = i.GJAHR
AND a.BUZEI = i.BUZEI
),
change_events AS (
SELECT
c.MANDT,
c.OBJECTID,
c.TABKEY,
c.FNAME,
c.VALUE_OLD,
c.VALUE_NEW,
c.UDATE,
c.UTIME,
c.USERNAME
FROM [Your SAP HANA schema].[Your change document item table name] c
WHERE c.TABNAME = 'BSEG'
AND c.FNAME IN ('ZLSPR', 'ZTERM')
AND c.UDATE BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
AND [Change document object class filter]
),
reguh_events AS (
SELECT
r.MANDT,
r.LAUFD,
r.LAUFI,
r.XVORL,
r.ZBUKR,
r.LIFNR,
r.VBLNR,
r.AUSFD,
r.AUSDT,
r.LAUFD AS RunDate,
r.ZALDT,
r.RZAWE,
r.XEINZ,
r.XPGRO,
r.XAVIS,
r.XVORL AS ProposalIndicator
FROM [Your SAP HANA schema].REGUH r
WHERE r.LAUFD BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
),
regup_events AS (
SELECT
u.MANDT,
u.LAUFD,
u.LAUFI,
u.ZBUKR,
u.LIFNR,
u.VBLNR,
u.BUKRS,
u.BELNR,
u.GJAHR,
u.BUZEI,
u.XVORL,
u.AUGBL,
u.AUGDT
FROM [Your SAP HANA schema].REGUP u
WHERE u.LAUFD BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Parked' AS Activity,
TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
i.source_system AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate,
i.LIFNR AS VendorNumber,
i.BUKRS AS CompanyCode,
i.WRBTR AS InvoiceAmount,
i.BLART AS DocumentType,
i.ZTERM AS PaymentTerms,
i.ZLSPR AS PaymentBlockReason,
i.USNAM AS UserName,
i.AUGDT AS ClearingDate,
i.NetDueDate,
CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END AS IsLatePayment,
FALSE AS IsTouchless
FROM invoice_cases i
INNER JOIN [Your SAP HANA schema].VBKPF v
ON v.MANDT = i.MANDT
AND v.BUKRS = i.BUKRS
AND v.BELNR = i.BELNR
AND v.GJAHR = i.GJAHR
WHERE [VBKPF parked status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Posted', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i
UNION ALL
SELECT i.InvoiceNumber, 'Payment Block Applied', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, c.VALUE_NEW, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZLSPR' AND COALESCE(c.VALUE_OLD, '') = '' AND COALESCE(c.VALUE_NEW, '') <> ''
UNION ALL
SELECT i.InvoiceNumber, 'Price Variance Detected', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.ZLSPR = 'R'
UNION ALL
SELECT i.InvoiceNumber, 'Quantity Variance Detected', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.ZLSPR = 'M'
UNION ALL
SELECT i.InvoiceNumber, 'Payment Terms Changed', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, c.VALUE_NEW, i.ZLSPR, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZTERM'
UNION ALL
SELECT i.InvoiceNumber, 'Payment Block Removed', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, c.VALUE_OLD, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZLSPR' AND COALESCE(c.VALUE_OLD, '') <> '' AND COALESCE(c.VALUE_NEW, '') = ''
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Due', TO_TIMESTAMP(TO_VARCHAR(i.NetDueDate, 'YYYYMMDD') || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.NetDueDate IS NOT NULL
UNION ALL
SELECT i.InvoiceNumber, 'Cash Discount Lost', TO_TIMESTAMP(TO_VARCHAR(CASE WHEN i.DiscountDueDate1 <= i.DiscountDueDate2 THEN i.DiscountDueDate1 ELSE i.DiscountDueDate2 END, 'YYYYMMDD') || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.AUGDT IS NULL OR i.AUGDT > CASE WHEN i.DiscountDueDate1 <= i.DiscountDueDate2 THEN i.DiscountDueDate1 ELSE i.DiscountDueDate2 END
UNION ALL
SELECT i.InvoiceNumber, 'Payment Proposal Created', TO_TIMESTAMP(r.RunDate || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN regup_events u ON u.BUKRS = i.BUKRS AND u.BELNR = i.BELNR AND u.GJAHR = i.GJAHR AND u.BUZEI = i.BUZEI INNER JOIN reguh_events r ON r.MANDT = u.MANDT AND r.LAUFD = u.LAUFD AND r.LAUFI = u.LAUFI AND r.LIFNR = u.LIFNR WHERE [Payment proposal status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Payment Run Executed', TO_TIMESTAMP(r.RunDate || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN regup_events u ON u.BUKRS = i.BUKRS AND u.BELNR = i.BELNR AND u.GJAHR = i.GJAHR AND u.BUZEI = i.BUZEI INNER JOIN reguh_events r ON r.MANDT = u.MANDT AND r.LAUFD = u.LAUFD AND r.LAUFI = u.LAUFI AND r.LIFNR = u.LIFNR WHERE [Payment run executed status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Payment Document Created', TO_TIMESTAMP(p.CPUDT || LPAD(COALESCE(p.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, p.BLART, i.ZTERM, i.ZLSPR, p.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN [Your SAP HANA schema].BKPF p ON p.MANDT = i.MANDT AND p.BUKRS = i.BUKRS AND p.BELNR = i.AUGBL AND p.GJAHR = i.GJAHR WHERE p.BLART IN ('ZP', 'KZ')
UNION ALL
SELECT i.InvoiceNumber, 'Payment Cleared', TO_TIMESTAMP(i.AUGDT || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.AUGDT IS NOT NULL
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Reversed', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.STBLG IS NOT NULL AND i.STBLG <> ''
)
SELECT
InvoiceNumber,
Activity,
EventTime,
SourceSystem,
LastDataUpdate,
VendorNumber,
CompanyCode,
InvoiceAmount,
DocumentType,
PaymentTerms,
PaymentBlockReason,
UserName,
ClearingDate,
NetDueDate,
IsLatePayment,
IsTouchless
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, Activity; Gotowi do rozpoczęcia?
Zamień dane finansowe w praktyczne informacje i już dziś zacznij usprawniać cykle płatności. Nasz zespół pomoże Państwu na każdym etapie pracy z process mining.
Usprawnij obsługę płatności zobowiązań w SAP S/4HANA
Usuń wąskie gardła i skróć czas realizacji procesu o 30%.
Karta kredytowa nie jest wymagana. Konfiguracja zajmuje 5 minut.