Szablon danych Order-to-Cash: rozliczenia i fakturowanie
Szablon danych Order-to-Cash: rozliczenia i fakturowanie
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia
- Wskazówki dotyczące ekstrakcji danych z SAP S/4HANA
Atrybuty procesu Order-to-Cash: rozliczenia i fakturowanie
| Nazwa | Opis | ||
|---|---|---|---|
| Numer faktury InvoiceNumber | Unikalny identyfikator dokumentu rozliczeniowego, który pełni funkcję głównego identyfikatora case w procesie fakturowania. | ||
| Opis Numer faktury, nazywany w SAP numerem dokumentu rozliczeniowego, jednoznacznie identyfikuje każdą transakcję fakturowania. Jest głównym identyfikatorem łączącym wszystkie powiązane działania, od utworzenia i zaksięgowania faktury po otrzymanie płatności i jej uzgodnienie. W process mining ten atrybut służy do łączenia zdarzeń w case. Wszystkie zdarzenia z tym samym numerem faktury są grupowane w jedną instancję procesu. Dzięki temu można przeanalizować cały cykl życia każdej faktury, mierzyć czas cyklu, wykrywać odstępstwa i śledzić przebieg procesu dla poszczególnych faktur. Dlaczego to ważne To podstawowy identyfikator, który łączy wszystkie powiązane działania dotyczące faktury w jeden case i umożliwia analizę procesu od początku do końca. Skąd pobrać Tabela SAP: VBRK, pole: VBELN Przykłady 900012349000567890009012 | |||
| Czas zdarzenia EventTime | Dokładny znacznik czasu wskazujący, kiedy wystąpiło działanie lub zdarzenie. | ||
| Opis Czas zdarzenia określa datę i godzinę każdego działania, tworząc chronologiczny zapis procesu. Ten znacznik czasu jest niezbędny do obliczania czasu trwania, czasu cyklu i czasu oczekiwania między poszczególnymi etapami fakturowania. W analizie czas zdarzenia służy do uporządkowania działań, obliczania KPI, takich jak okres spływu należności (DSO) i czas cyklu wystawienia faktury, oraz wykrywania wąskich gardeł związanych z czasem. Pozwala obserwować zmiany efektywności procesu i mierzyć czas trwania poszczególnych etapów cyklu fakturowania. Dlaczego to ważne Określa chronologiczną kolejność zdarzeń, niezbędną do obliczania wszystkich miar czasu, takich jak czas cyklu i czas trwania. Skąd pobrać Dane są pobierane z różnych pól daty i godziny, zależnie od działania. Mogą to być data i godzina utworzenia (VBRK-ERDAT, VBRK-ERZET), znaczniki czasu zmian (CDHDR-UDATE, CDHDR-UTIME) lub data księgowania (BKPF-BUDAT). Przykłady 2023-04-15T10:30:00Z2023-04-20T14:00:00Z2023-05-10T09:15:00Z | |||
| Nazwa działania ActivityName | Nazwa działania biznesowego lub zdarzenia w procesie fakturowania, na przykład „Faktura wystawiona” lub „Otrzymano płatność”. | ||
| Opis Nazwa działania opisuje konkretny krok lub etap cyklu życia faktury. Działania są wyznaczane na podstawie różnych danych z SAP, takich jak kody transakcji, zmiany statusu dokumentu lub wpisy w dziennikach. Na tej podstawie powstaje sekwencja przebiegu procesu. Analiza kolejności i częstotliwości działań stanowi podstawę process mining. Pozwala zwizualizować mapę procesu, wykryć częste i rzadkie warianty, wskazać wąskie gardła między etapami oraz zmierzyć częstotliwość działań, które nie tworzą wartości, takich jak poprawki lub anulowania. Dlaczego to ważne Ten atrybut określa kroki procesu. Umożliwia wizualizację map procesów oraz analizę przebiegu, wariantów i wąskich gardeł. Skąd pobrać Dane pochodzą z różnych źródeł, między innymi z kodów transakcji (SY-TCODE), statusów dokumentów zmian (tabele CDHDR/CDPOS) i dzienników workflow (na przykład SWW_WI2OBJ). Przykłady Faktura wystawionaFaktura zaksięgowana w rachunkowościOtrzymano płatność od klientaFaktura anulowana | |||
| Czas zakończenia EndTime | Dokładny znacznik czasu wskazujący, kiedy zakończono działanie lub zdarzenie. | ||
| Opis Czas zakończenia oznacza moment ukończenia działania. W process mining często przyjmuje się, że jest to czas rozpoczęcia kolejnego działania w danym case. Można go też pobrać bezpośrednio z systemu, jeśli rejestruje on zarówno rozpoczęcie, jak i zakończenie zdarzeń. Ten atrybut jest niezbędny do obliczania czasu przetwarzania poszczególnych działań. Różnica między czasem zakończenia a czasem rozpoczęcia pokazuje, ile trwał każdy etap. To ważne przy analizie wąskich gardeł, na przykład opóźnień na etapie zatwierdzania faktury. Dlaczego to ważne Pozwala dokładnie obliczyć czas trwania każdego działania, co jest podstawą analizy wąskich gardeł. Skąd pobrać Jest to atrybut wyliczany na potrzeby process mining. Zwykle przyjmuje się czas rozpoczęcia kolejnego zdarzenia w sekwencji danego case. W niektórych przypadkach czas zakończenia jest rejestrowany w osobnych tabelach. Przykłady 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| Data faktury InvoiceDate | Oficjalna data wystawienia faktury dla klienta. | ||
| Opis Data faktury, nazywana w SAP datą rozliczenia, stanowi punkt wyjścia dla wielu obliczeń finansowych. Na jej podstawie określa się warunki płatności, termin płatności i wiek należności. To ważny atrybut na poziomie case, wykorzystywany w analizie finansowej. Stanowi punkt odniesienia przy obliczaniu KPI okresu spływu należności (DSO) i tworzeniu raportów o wieku nieopłaconych faktur. Raporty te pomagają zarządzać przepływami pieniężnymi i ściąganiem należności. Dlaczego to ważne To podstawowa data wykorzystywana w obliczeniach finansowych. Stanowi punkt wyjścia do obliczania DSO, terminów płatności i wieku faktur. Skąd pobrać Tabela SAP: VBRK, pole: FKDAT Przykłady 2023-03-202023-04-012023-05-18 | |||
| Kwota faktury InvoiceAmount | Łączna wartość netto faktury. | ||
| Opis Ten atrybut określa łączną wartość pieniężną fakturowanych towarów lub usług bez podatków. Jest podstawową daną finansową dla każdego case dotyczącego faktury. Kwota faktury służy do wielu rodzajów analiz. Pozwala podzielić proces według wartości, na przykład sprawdzić, czy faktury o wysokiej wartości są przetwarzane inaczej lub częściej się opóźniają. Jest też podstawą raportowania finansowego i obliczania łącznej wartości nieuregulowanych należności. Dlaczego to ważne Określa wartość finansową każdej faktury, umożliwiając analizę według kwoty, ustalanie priorytetów w ściąganiu należności i ocenę skutków finansowych. Skąd pobrać Tabela SAP: VBRK, pole: NETWR Przykłady 1500.0025000.50125.75 | |||
| Nazwa klienta CustomerName | Nazwa klienta, dla którego wystawiono fakturę. | ||
| Opis Ten atrybut określa nazwę prawną fakturowanego klienta. Dane pochodzą z centralnych danych podstawowych klientów w SAP. Analiza procesu według klienta pozwala wykrywać wzorce dotyczące poszczególnych kont. Można na przykład sprawdzić, którzy klienci regularnie płacą po terminie, najczęściej zgłaszają spory lub wymagają najbardziej czasochłonnego fakturowania. Ułatwia to dostosowanie obsługi klienta i strategii ściągania należności. Dlaczego to ważne Umożliwia analizę z perspektywy klienta, pomagając wykrywać wzorce płatności, częstotliwość sporów i nieefektywne działania dotyczące poszczególnych kont. Skąd pobrać Dane są pobierane z tabeli danych podstawowych klientów KNA1 (pole: NAME1) i łączone za pomocą identyfikatora płatnika w nagłówku faktury (VBRK-KUNRG). Przykłady Elektrownia SpringfieldSklep Kwik-E-MartCyberdyne Systems | |||
| Nazwa użytkownika UserName | Identyfikator użytkownika, który wykonał dane działanie. | ||
| Opis Ten atrybut zapisuje identyfikator użytkownika SAP odpowiedzialnego za dane zdarzenie, na przykład utworzenie faktury, zaksięgowanie dokumentu lub rozliczenie płatności. Łączy etapy procesu z osobami lub zespołami, które je wykonują. Analiza według nazwy użytkownika pomaga wskazać osoby osiągające dobre wyniki, potrzeby szkoleniowe i nierównomierny podział pracy. Jest też ważna przy analizie zgodności: pokazuje, kto wykonał istotne działania, i pozwala sprawdzić, jak różni użytkownicy realizują ten sam proces. Dlaczego to ważne Łączy działania w procesie z konkretnymi użytkownikami, umożliwiając analizę obciążenia pracą, efektywności i zgodności na poziomie osoby lub zespołu. Skąd pobrać W przypadku zdarzeń związanych z utworzeniem dokumentu dane znajdują się w polu VBRK-ERNAM. Informacje o późniejszych zmianach można znaleźć w tabelach historii zmian, takich jak CDHDR-USERNAME, lub w dziennikach workflow. Przykłady CBURNSHSIMPSONLLEONARD | |||
| Region Region | Region geograficzny klienta. | ||
| Opis Atrybut regionu wskazuje obszar geograficzny, na przykład stan lub prowincję, powiązany z adresem klienta. Dane te są zwykle częścią rekordu klienta w danych podstawowych. Atrybut ten jest wykorzystywany w dashboardzie wyników fakturowania według regionu. Pozwala porównywać kluczowe miary, takie jak czas cyklu, odsetek błędów i DSO, między regionami. Takie porównanie może ujawnić regionalne różnice w przebiegu procesu, zgodności lub efektywności, co ułatwia wprowadzanie ukierunkowanych usprawnień i ujednolicanie dobrych praktyk. Dlaczego to ważne Umożliwia porównanie wyników fakturowania w różnych regionach, pomaga wykrywać różnice i ujednolicać procesy. Skąd pobrać Dane są pobierane z tabeli danych podstawowych klientów KNA1 (pole: REGIO) i łączone za pomocą identyfikatora płatnika w nagłówku faktury (VBRK-KUNRG). Przykłady KaliforniaNowy JorkTeksasBuenos Aires | |||
| Termin płatności PaymentDueDate | Data, do której klient powinien zapłacić fakturę. | ||
| Opis Termin płatności jest obliczany na podstawie daty faktury i uzgodnionych warunków płatności. Określa datę, do której należy otrzymać płatność, aby faktura nie stała się przeterminowana. Ten atrybut pomaga monitorować skuteczność ściągania należności i prognozować przepływy pieniężne. Służy do obliczania KPI terminowości płatności oraz grupowania faktur w raportach o wieku należności. Analiza różnicy między terminem płatności a datą faktycznej zapłaty pozwala ocenić skuteczność różnych warunków płatności. Dlaczego to ważne Wyznacza termin zapłaty przez klienta, dlatego jest niezbędny do obliczania terminowości płatności i zarządzania należnościami. Skąd pobrać Ta data nie jest przechowywana bezpośrednio. Oblicza się ją na podstawie daty faktury (VBRK-FKDAT) i klucza warunków płatności (VBRK-ZTERM), korzystając ze standardowych funkcji SAP do wyznaczania dat. Przykłady 2023-04-192023-05-012023-06-17 | |||
| Czy płatność nastąpiła w terminie IsPaidOnTime | Wartość logiczna wskazująca, czy fakturę opłacono najpóźniej w terminie płatności. | ||
| Opis Ten atrybut jest wyliczany przez porównanie rzeczywistej daty płatności z ustalonym terminem płatności. Przyjmuje wartość „true”, jeśli płatność nastąpiła w terminie, i „false”, jeśli była spóźniona. Ułatwia obliczanie i prezentowanie wskaźnika KPI płatności w terminie. Pozwala łatwo filtrować i dzielić faktury na opłacone po terminie oraz w terminie. Dzięki temu można wykryć zależności między opóźnieniami a konkretnymi klientami, regionami lub warunkami płatności. Dlaczego to ważne Ułatwia pomiar wyników, oznaczając każdą fakturę jako opłaconą w terminie lub po terminie. Bezpośrednio wspiera wskaźnik KPI płatności w terminie. Skąd pobrać To pole jest wyliczane. Logika porównuje znacznik czasu działania „Otrzymano płatność od klienta” z wartością atrybutu „PaymentDueDate”. Przykłady truefalse | |||
| Data ostatniej aktualizacji danych LastDataUpdate | Znacznik czasu wskazujący, kiedy dane dotyczące tego zdarzenia zostały ostatnio pobrane lub odświeżone. | ||
| Opis Ten atrybut zapisuje datę i godzinę ostatniego pobrania danych z systemu źródłowego. Jest to pole metadanych, które pozwala ocenić aktualność analizowanych danych. Informacja ta służy do sprawdzania aktualności analizy i planowania odświeżania danych. Dzięki niej osoby korzystające z dashboardów i analiz process mining wiedzą, na ile dane są aktualne, gdy podejmują decyzje dotyczące procesu. Dlaczego to ważne Informuje o aktualności danych, co pomaga ocenić wiarygodność analizy i jej przydatność do oceny bieżącego stanu operacji. Skąd pobrać Ten znacznik czasu jest generowany i przypisywany do każdego rekordu podczas procesu ekstrakcji, transformacji i ładowania danych (ETL). Przykłady 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
| Kod spółki CompanyCode | Jednostka organizacyjna, w której księgowana jest transakcja finansowa. | ||
| Opis Kod spółki to podstawowa jednostka organizacyjna w SAP Financials. Oznacza prawnie niezależną spółkę, dla której sporządza się sprawozdania finansowe. Każdy dokument rozliczeniowy jest przypisany do określonego kodu spółki. Analiza według kodu spółki jest niezbędna w organizacjach obejmujących wiele spółek. Pozwala porównywać wyniki procesu, wskaźniki finansowe, takie jak DSO, oraz zgodność w poszczególnych podmiotach prawnych. Zapewnia też nadrzędny filtr organizacyjny dla wszystkich dashboardów procesu. Dlaczego to ważne Pozwala analizować procesy według podmiotów prawnych, porównywać ich wyniki i konsolidować dane finansowe w całej organizacji. Skąd pobrać Tabela SAP: VBRK, pole: BUKRS Przykłady 10002000US01 | |||
| Numer zamówienia sprzedaży SalesOrderNumber | Identyfikator pierwotnego zamówienia sprzedaży, na podstawie którego wystawiono fakturę. | ||
| Opis Numer zamówienia sprzedaży łączy dokument rozliczeniowy z wcześniejszymi działaniami sprzedażowymi. Jedno zamówienie może prowadzić do wystawienia jednej lub kilku faktur, a to powiązanie pozwala odtworzyć pełny przepływ dokumentów. Ten atrybut jest niezbędny do rzetelnej analizy procesu Order-to-Cash od początku do końca. Pozwala rozszerzyć analizę o wcześniejsze etapy i powiązać problemy z fakturowaniem z ich możliwymi przyczynami podczas tworzenia lub realizacji zamówienia. Można na przykład obliczyć całkowity czas wystawienia faktury, liczony od realizacji zamówienia. Dlaczego to ważne Łączy fakturę z pierwotnym zamówieniem sprzedaży, dzięki czemu można analizować cały proces Order-to-Cash, a nie tylko fakturowanie. Skąd pobrać Tabela SAP: VBRP (dane pozycji dokumentu rozliczeniowego), pole: AUBEL Przykłady 100001231000045610000789 | |||
| Przyczyna noty uznaniowej CreditMemoReason | Kod przyczyny wskazujący, dlaczego wystawiono notę uznaniową. | ||
| Opis Gdy faktura zawiera błąd i trzeba ją skorygować na korzyść klienta, do dokumentu noty uznaniowej zwykle przypisuje się przyczynę. Pozwala to uporządkować źródła błędów w fakturowaniu. Ten atrybut bezpośrednio wspiera wskaźnik KPI błędów fakturowania. Zestawienie i analiza przyczyn wystawiania not uznaniowych pozwalają ustalić najczęstsze rodzaje błędów, takie jak pomyłki w cenach czy zwroty produktów. Wyniki analizy pomagają usprawnić proces i ograniczyć konieczność korekt finansowych oraz ponownej pracy. Dlaczego to ważne Klasyfikuje przyczyny korekt na korzyść klienta, pomagając wskazać najczęstsze źródła błędów w fakturowaniu i poprawić jakość procesu. Skąd pobrać Tabela SAP: VBRK, pole: AUGRU (przyczyna zamówienia). Pole jest używane w zleceniach wystawienia not uznaniowych lub obciążeniowych, które następnie są rozliczane. Przykłady 001 - Różnica w cenie002 - Niska jakość005 - Zwrot od klienta | |||
| Przyczyna sporu CustomerDisputeReason | Powód, dla którego klient kwestionuje fakturę. | ||
| Opis Gdy klient kwestionuje fakturę, zwykle rejestruje się przyczynę sporu. Może nią być błąd w cenie, nieprawidłowa ilość lub uszkodzony towar. Informacje te mogą być przechowywane w module SAP Dispute Management lub w notatkach tekstowych. Analiza przyczyn sporów jest podstawą wskaźnika KPI błędów fakturowania i powiązanej z nim analizy błędów. Pomaga ustalić źródła nieprawidłowości na fakturach, a następnie rozwiązać problemy w procesach na wcześniejszych etapach, poprawić jakość faktur i zwiększyć zadowolenie klientów. Dlaczego to ważne Wyjaśnia, dlaczego klienci kwestionują faktury, i wskazuje bezpośrednio przyczyny błędów w fakturowaniu oraz niezadowolenia klientów. Skąd pobrać Jeśli używany jest SAP Dispute Management, informacje te można znaleźć w tabelach takich jak UDM_DISPUTE. W przeciwnym razie można je ustalić na podstawie kodów przyczyn w powiązanych dokumentach lub pól tekstowych. Przykłady Nieprawidłowa cenaNiezgodna ilośćOtrzymano uszkodzony towar | |||
| Rodzaj dokumentu rozliczeniowego BillingDocumentType | Kod określający rodzaj dokumentu rozliczeniowego, na przykład fakturę, notę uznaniową lub anulowanie. | ||
| Opis Rodzaj dokumentu rozliczeniowego to pole klasyfikujące transakcje w procesie fakturowania. Określa sposób przetwarzania dokumentu, w tym zakres numeracji i zasady księgowania. Ten atrybut pozwala filtrować proces i analizować wybrane rodzaje transakcji. Można na przykład utworzyć osobny widok procesu dla not uznaniowych, aby poznać przyczyny i przebieg korekt finansowych. Można też analizować standardowe faktury oddzielnie od anulowań, by uzyskać czytelniejszy obraz głównego procesu fakturowania. Dlaczego to ważne Klasyfikuje transakcje i pozwala skupić analizę na wybranych przepływach dokumentów, takich jak standardowe faktury, noty uznaniowe czy anulowania. Skąd pobrać Tabela SAP: VBRK, pole: FKART Przykłady F2G2S1L2 | |||
| Status płatności PaymentStatus | Bieżący status płatności za fakturę, na przykład otwarta, opłacona lub przeterminowana. | ||
| Opis Status płatności pokazuje, na jakim etapie obsługi należności znajduje się faktura. W SAP nie jest to pojedyncze pole. Status ustala się na podstawie informacji o rozliczeniu powiązanego dokumentu księgowego. Ten atrybut jest niezbędny na dashboardzie wieku nieopłaconych faktur. Pozwala podzielić wszystkie otwarte faktury według statusu i wieku, dzięki czemu zespół windykacji może skutecznie ustalać priorytety. Śledzenie zmian statusu pozwala również monitorować sam proces windykacji. Dlaczego to ważne Pokazuje status windykacji dla każdej faktury, co pomaga zarządzać należnościami i ustalać priorytety działań windykacyjnych. Skąd pobrać Ustalany na podstawie statusu rozliczenia dokumentu księgowego (VBRK-BELNR) w tabelach finansowych, takich jak BSID (pozycje otwarte) i BSAD (pozycje rozliczone). Przykłady OtwartaOpłaconaPrzeterminowanaCzęściowo opłacona | |||
| System źródłowy SourceSystem | Wskazuje konkretny system źródłowy, z którego pobrano dane. | ||
| Opis Ten atrybut określa pochodzenie danych. Jest szczególnie przydatny w środowiskach z wieloma instancjami SAP lub innymi zintegrowanymi systemami. Zwykle zawiera identyfikator systemu i numer klienta. W analizie pozwala porównywać procesy i ich efektywność w różnych systemach lub jednostkach organizacyjnych. Ułatwia śledzenie pochodzenia danych i zapewnia kontekst, zwłaszcza gdy łączy się dane z wielu źródeł, aby uzyskać pełny obraz procesu. Dlaczego to ważne Informuje o pochodzeniu danych, co ułatwia ich interpretację w środowisku wielosystemowym i wspiera zarządzanie danymi. Skąd pobrać Zwykle jest to stała wartość określana podczas ekstrakcji danych, często złożona z identyfikatora systemu (SY-SYSID) i klienta (SY-MANDT). Przykłady S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| Waluta Currency | Kod waluty, w której podano kwotę faktury. | ||
| Opis Ten atrybut określa walutę, w której podano kwoty na fakturach, na przykład USD, EUR lub JPY. Zapewnia niezbędny kontekst dla wszystkich wartości pieniężnych. W organizacji działającej na wielu rynkach waluta jest niezbędna do prawidłowej analizy i raportowania finansowego. Umożliwia przeliczenie kwot na wspólną walutę raportową i porównanie wyników fakturowania w regionach, w których obowiązują różne waluty lokalne. Dlaczego to ważne Zapewnia kontekst niezbędny do prawidłowej analizy i raportowania wartości pieniężnych, zwłaszcza w operacjach prowadzonych w wielu krajach. Skąd pobrać Tabela SAP: VBRK, pole: WAERK Przykłady USDEURGBP | |||
| Warunki płatności PaymentTerms | Kod określający warunki płatności, na przykład termin, w którym należy uregulować należność. | ||
| Opis Warunki płatności to ustalone z klientem zasady określające termin zapłaty za fakturę. Przykładem jest „Net 30”, czyli płatność w ciągu 30 dni, albo „2/10 Net 30”, czyli 2% rabatu przy płatności w ciągu 10 dni, a w przeciwnym razie termin płatności wynosi 30 dni. Analiza warunków płatności pozwala ocenić ich skuteczność. Zestawiając poszczególne warunki z rzeczywistym czasem oczekiwania na płatność, można ustalić, które z nich najlepiej zachęcają klientów do terminowego regulowania należności. Na tej podstawie można dostosować warunki i poprawić przepływy pieniężne. Dlaczego to ważne Określa uzgodniony harmonogram płatności i pozwala ocenić, które warunki najskuteczniej zapewniają terminowe płatności klientów. Skąd pobrać Tabela SAP: VBRK, pole: ZTERM Przykłady Z030Z060ZB60 | |||
Działania w procesie Order-to-Cash: rozliczenia i fakturowanie
| Działanie | Opis | ||
|---|---|---|---|
| Faktura wystawiona | To zdarzenie oznacza utworzenie dokumentu rozliczeniowego w systemie. Jest rejestrowane, gdy użytkownik wykona transakcję, taką jak VF01, albo gdy fakturę utworzy zadanie działające w tle. W efekcie w tabeli nagłówka dokumentu rozliczeniowego pojawia się nowy wpis. | ||
| Dlaczego to ważne To główne zdarzenie rozpoczynające proces fakturowania. Analiza czasu od realizacji zamówienia do tego zdarzenia pozwala mierzyć czas cyklu wystawienia faktury i wykrywać opóźnienia na początkowym etapie procesu. Skąd pobrać Zdarzenie jest rejestrowane w tabeli SAP S/4HANA VBRK (dokument rozliczeniowy: dane nagłówka) podczas tworzenia dokumentu. Znacznik czasu tworzą data utworzenia (VBRK-ERDAT) i godzina utworzenia (VBRK-ERZET). Rejestrowanie Zdarzenie jest rejestrowane na podstawie znacznika czasu utworzenia dokumentu rozliczeniowego w tabeli VBRK. Typ zdarzenia explicit | |||
| Faktura zaksięgowana w rachunkowości | To zdarzenie oznacza pomyślne zaksięgowanie dokumentu rozliczeniowego w module rachunkowości finansowej. Jest to ważny etap, w którym faktura staje się oficjalną należnością i powoduje powstanie zapisów w księdze głównej. | ||
| Dlaczego to ważne To zdarzenie potwierdza, że faktura jest dokumentem finansowym. Czas między jej wystawieniem a zaksięgowaniem jest ważnym KPI, który pokazuje sprawność przetwarzania wewnątrz firmy. Skąd pobrać Zdarzenie jest rejestrowane po utworzeniu powiązanego dokumentu księgowego. Dokument rozliczeniowy (VBRK-VBELN) jest łączony z dokumentem księgowym (BKPF-BELNR) za pomocą pola VBRK-BELNR, a datę księgowania określa pole BKPF-BUDAT. Rejestrowanie Zdarzenie jest rejestrowane na podstawie daty księgowania (BUDAT) dokumentu księgowego w tabeli BKPF powiązanego z dokumentem rozliczeniowym. Typ zdarzenia explicit | |||
| Faktura zamknięta | To zdarzenie oznacza końcowy etap procesu dla opłaconej faktury. Funkcjonalnie odpowiada zdarzeniu „Płatność przypisana do faktury i uzgodniona” i wskazuje, że proces dotyczący tej faktury został zakończony. | ||
| Dlaczego to ważne To główne zdarzenie kończące prawidłowy przebieg procesu. Pomiar całkowitego czasu cyklu do tego momentu daje pełny obraz procesu fakturowania od początku do końca. Skąd pobrać Zdarzenie jest wnioskowane na podstawie statusu pozycji klienta w dokumencie księgowym. Pozycja jest zamknięta, czyli rozliczona, gdy uzupełniono pola daty rozliczenia (BSEG-AUGDT) i dokumentu rozliczeniowego (BSEG-AUGBL). Rejestrowanie Zdarzenie jest wnioskowane na podstawie uzupełnienia daty rozliczenia (AUGDT) w tabeli BSEG/ACDOCA dla pozycji faktury. Typ zdarzenia inferred | |||
| Otrzymano płatność od klienta | To zdarzenie oznacza zaksięgowanie wpłaty od klienta w systemie finansowym. Na tym etapie płatność może nie być jeszcze przypisana do konkretnej faktury, ale jej otrzymanie zostało już odnotowane. | ||
| Dlaczego to ważne To ważny etap przy obliczaniu okresu spływu należności (DSO). Oznacza, że środki wpłynęły, nawet jeśli ich uzgodnienie jeszcze się nie zakończyło. Skąd pobrać Zdarzenie jest rejestrowane na podstawie daty księgowania (BKPF-BUDAT) dokumentu płatności klienta, zwykle dokumentu typu „DZ” w tabeli BKPF. Rejestrowanie Zdarzenie jest oparte na utworzeniu dokumentu płatności w tabelach BKPF/BSEG. Typ zdarzenia explicit | |||
| Płatność przypisana do faktury i uzgodniona | To zdarzenie oznacza moment, w którym wpłata od klienta zostaje dopasowana do otwartej pozycji faktury i rozlicza ją w księdze pomocniczej należności. Z finansowego punktu widzenia zamyka transakcję. | ||
| Dlaczego to ważne Zdarzenie pozwala mierzyć sprawność przypisywania wpłat do faktur. Opóźnienia mogą zniekształcać obraz sald klientów i powodować niepotrzebną pracę zespołów zajmujących się ściąganiem należności. Skąd pobrać Zdarzenie jest rejestrowane na podstawie daty rozliczenia (BSEG-AUGDT) w pozycji dokumentu księgowego pierwotnej faktury. Data ta jest uzupełniana po rozliczeniu pozycji dokumentem rozliczeniowym. Rejestrowanie Zdarzenie jest rejestrowane na podstawie pola daty rozliczenia (AUGDT) w tabeli BSEG/ACDOCA dla pozycji faktury. Typ zdarzenia explicit | |||
| Faktura anulowana | Zdarzenie występuje, gdy wcześniej wystawiona faktura zostaje anulowana, zwykle przez utworzenie dokumentu anulującego. W ten sposób odwracane są pierwotna faktura i jej skutki księgowe. | ||
| Dlaczego to ważne Zdarzenie wskazuje na poprawki, korekty lub błędy w fakturowaniu. Częste anulowanie faktur może świadczyć o poważnych problemach na wcześniejszych etapach, takich jak wprowadzanie zamówień sprzedaży lub konfiguracja fakturowania. Skąd pobrać Zdarzenie jest rejestrowane po utworzeniu dokumentu anulującego fakturę, na przykład dokumentu typu „S1”. Nowy dokument w tabeli VBRK zawiera numer pierwotnej faktury w polu VBRK-SFAKN. Rejestrowanie Zdarzenie jest rejestrowane na podstawie daty utworzenia dokumentu anulującego w tabeli VBRK, który wskazuje pierwotną fakturę. Typ zdarzenia explicit | |||
| Faktura wysłana do klienta | To zdarzenie oznacza wysłanie faktury do klienta, na przykład w formie wydruku, e-maila lub komunikatu EDI. Sposób rejestrowania zależy od konfiguracji zarządzania wydrukami w SAP. | ||
| Dlaczego to ważne Z perspektywy klienta od tego momentu zaczyna biec termin płatności. Opóźnienie w wysłaniu faktury bezpośrednio wpływa na okres spływu należności (DSO) i przepływy pieniężne. Skąd pobrać Zdarzenie może być jawnie rejestrowane w tabelach kontroli wydruków, takich jak NAST w starszych rozwiązaniach lub jej odpowiednik w S/4HANA. Jeśli nie jest rejestrowane, często przyjmuje się, że następuje w chwili „Faktura zaksięgowana w rachunkowości”. Rejestrowanie Sprawdź dzienniki przetwarzania w tabelach zarządzania wydrukami i znajdź znacznik czasu powiązany z typem wydruku faktury. Typ zdarzenia explicit | |||
| Faktura zablokowana do księgowania | To zdarzenie występuje, gdy faktura zostaje utworzona, ale system automatycznie blokuje jej zaksięgowanie w rachunkowości finansowej, na przykład z powodu kontroli kredytowej lub niespójnych danych. Zdarzenie jest wnioskowane na podstawie pola statusu księgowania w dokumencie rozliczeniowym. | ||
| Dlaczego to ważne Zdarzenie wskazuje wąskie gardła, w których faktury są wystawiane, ale nie trafiają od razu do działu finansowego, co opóźnia cały cykl ściągania należności. Może też sygnalizować problemy z jakością danych lub zarządzaniem kredytowym. Skąd pobrać Zdarzenie jest wnioskowane na podstawie pola statusu księgowania w tabeli nagłówka dokumentu rozliczeniowego (VBRK-RFBSK). Status taki jak „A” (dokument rozliczeniowy zablokowany przed przekazaniem do FI) oznacza blokadę. Rejestrowanie Zdarzenie jest wnioskowane przez sprawdzenie wartości pola statusu księgowania (VBRK-RFBSK) bezpośrednio po wystawieniu faktury. Typ zdarzenia inferred | |||
| Nadszedł termin płatności | Zdarzenie obliczane, które wskazuje datę, do której zgodnie z uzgodnionymi warunkami klient powinien zapłacić fakturę. Nie jest to zdarzenie transakcyjne, lecz wartość wyliczana na podstawie danych faktury. | ||
| Dlaczego to ważne To punkt odniesienia przy pomiarze terminowości płatności i analizie zachowań płatniczych klientów. Pozwala odróżnić płatności terminowe od przeterminowanych. Skąd pobrać Wartość jest obliczana na podstawie bazowej daty płatności (BSEG-ZFBDT) i warunków płatności zapisanych w pozycji klienta dokumentu księgowego. Rejestrowanie Wartość jest wyliczana przez dodanie liczby dni wynikającej z warunków płatności do bazowej daty płatności zapisanej w pozycji dokumentu księgowego (BSEG). Typ zdarzenia calculated | |||
| Otwarto spór z klientem | To zdarzenie występuje, gdy klient zgłasza zastrzeżenia do faktury, a następnie są one formalnie rejestrowane w systemie. Wymaga to korzystania z modułu SAP Dispute Management. | ||
| Dlaczego to ważne Zdarzenie wskazuje problemy z poprawnością fakturowania, jakością produktów lub realizacją usług, które opóźniają płatności. Analiza przyczyn sporów pomaga usunąć źródła problemów i poprawić zadowolenie klientów. Skąd pobrać Zdarzenie jest rejestrowane po utworzeniu sprawy sporu w tabelach Dispute Management, na przykład UDM_CASE, i powiązaniu jej z pozycją dokumentu księgowego. Rejestrowanie Zdarzenie jest rejestrowane na podstawie znacznika czasu utworzenia sprawy sporu powiązanej z fakturą. Typ zdarzenia explicit | |||
| Utworzono notę kredytową | To zdarzenie oznacza utworzenie noty kredytowej dla klienta, na przykład w celu skorygowania zawyżonej kwoty lub przyznania zwrotu za oddane towary. Nota jest często powiązana z pierwotną fakturą. | ||
| Dlaczego to ważne Zdarzenie wskazuje korekty finansowe wprowadzane po wystawieniu faktury. Analiza not kredytowych może ujawnić błędy cenowe, problemy z produktami lub inne przyczyny utraty przychodów. Skąd pobrać Nota jest tworzona jako nowy dokument rozliczeniowy w tabeli VBRK, z określonym typem dokumentu dla not kredytowych, na przykład „G2”. Często wskazuje pierwotne zamówienie sprzedaży lub fakturę. Rejestrowanie Zdarzenie jest rejestrowane po utworzeniu dokumentu rozliczeniowego w tabeli VBRK z typem dokumentu noty kredytowej. Typ zdarzenia explicit | |||
| Wykryto poprawkę w fakturowaniu | Zdarzenie obliczane, które wykrywa pętlę poprawek: faktura zostaje anulowana, a następnie dla tego samego zamówienia sprzedaży wystawiana jest nowa. Nie jest to pojedyncza transakcja, lecz wzorzec zdarzeń. | ||
| Dlaczego to ważne Zdarzenie bezpośrednio wspiera KPI dotyczący odsetka poprawek w fakturowaniu, ponieważ pozwala policzyć przypadki wymagające korekty. Pomaga wskazać nieefektywne działania i ocenić koszt niskiej jakości procesu fakturowania. Skąd pobrać Wzorzec jest obliczany przez wykrycie zdarzenia „Faktura anulowana”, po którym następuje nowe zdarzenie „Faktura wystawiona”. Oba zdarzenia muszą odnosić się do tego samego dokumentu źródłowego, na przykład numeru zamówienia sprzedaży. Rejestrowanie Wartość jest wyliczana przez wykrycie sekwencji „Faktura anulowana” i „Faktura wystawiona” dla tego samego zamówienia sprzedaży. Typ zdarzenia calculated | |||
| Wysłano przypomnienie o płatności | To zdarzenie oznacza wysłanie klientowi przypomnienia o płatności lub wezwania do zapłaty za przeterminowaną fakturę. Jest rejestrowane podczas automatycznej procedury monitowania. | ||
| Dlaczego to ważne Zdarzenie pozwala ocenić skuteczność procesu monitowania. Można sprawdzić, czy przypomnienia przyspieszają płatności i które poziomy monitów przynoszą najlepsze efekty. Skąd pobrać Zdarzenie jest rejestrowane w tabelach historii monitów (MAHNV, MHND) podczas uruchomienia procedury monitowania (transakcja F150) dla nieuregulowanej pozycji faktury. Rejestrowanie Zdarzenie jest rejestrowane na podstawie daty uruchomienia procedury monitowania zapisanej w tabelach historii monitów. Typ zdarzenia explicit | |||
Instrukcje ekstrakcji danych
Kroki
- Wymagania wstępne: Upewnij się, że mają Państwo konto użytkownika w SAP S/4HANA z uprawnieniami do odpytywania widoków Core Data Services (CDS). Potrzebny jest dostęp do odczytu takich widoków jak I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase i I_DunningHistory.
- Dostęp do narzędzia ekstrakcji danych: Zaloguj się do systemu SAP S/4HANA. Zapytania SQL do widoków CDS można wykonywać za pomocą różnych narzędzi, takich jak SAP HANA Studio, DBeaver połączony przez klienta SAP HANA lub dodatek SAP Analysis for Microsoft Excel. W tej instrukcji zakładamy użycie standardowego klienta SQL.
- Ustalenie parametrów systemu: Przed uruchomieniem zapytania określ kody spółek i zakres dat potrzebny do analizy. Na początek warto ograniczyć zakres, na przykład do danych z ostatnich 3–6 miesięcy, aby czas wykonania zapytania był możliwy do opanowania.
- Przygotowanie zapytania SQL: Skopiuj całe zapytanie SQL z sekcji „query” tego dokumentu do wybranego klienta SQL.
- Uzupełnienie wartości zastępczych: Zmień wartości zastępcze w zapytaniu. Zastąp
'YYYY-MM-DD'wybranymi datami początkową i końcową. Zastąp'XXXX'kodem lub kodami spółek. W zależności od konfiguracji systemu może być też konieczna zmiana wartości zastępczej dla typów dokumentów not kredytowych, na przykład'G2'. - Uruchomienie zapytania: Uruchom zmodyfikowane zapytanie SQL na bazie danych SAP S/4HANA. Czas wykonania zależy od ilości danych w wybranym zakresie dat.
- Sprawdzenie wyników: Po zakończeniu zapytania sprawdź wyniki. Powinna powstać płaska tabela, w której każdy wiersz odpowiada jednej czynności w procesie rozliczania i fakturowania. To dziennik zdarzeń.
- Przekształcenie danych, jeśli jest potrzebne: Zapytanie powinno utworzyć dziennik zdarzeń w odpowiednim formacie. Sprawdź jednak format znaczników czasu i upewnij się, że jest zgodny z używanym narzędziem process mining. Zapytanie korzysta z
ABAP_SYSTEM_UTCL_TO_TIMESTAMP, aby przekształcić wartości na standardowe znaczniki czasu UTC, obsługiwane przez większość narzędzi. - Eksport dziennika zdarzeń: Wyeksportuj cały zestaw wyników z klienta SQL do pliku CSV. Zapisz plik w kodowaniu UTF-8, aby uniknąć problemów ze znakami.
- Przesłanie danych do ProcessMind: Prześlij wygenerowany plik CSV na platformę ProcessMind i przyporządkuj jego kolumny, takie jak InvoiceNumber, ActivityName i EventTime, do odpowiednich pól w narzędziu.
Konfiguracja
- Zakres dat: Ustaw daty początkową i końcową w klauzuli
WHEREpoczątkowego wyrażenia Common Table Expression (CTE). Do wstępnej analizy zaleca się zakres 3–6 miesięcy, aby zachować równowagę między ilością danych a wydajnością. Filtr dotyczy polaBillingDocumentDate. - Kod spółki: Ogranicz ekstrakcję do odpowiednich podmiotów prawnych, filtrując według jednej lub kilku wartości
CompanyCode. Ten filtr pozwala kontrolować zakres danych. - Typy dokumentów: Zapytanie rozpoznaje noty kredytowe na podstawie pola
BillingDocumentType. Uzupełnij wartość zastępczą, na przykład('G2', 'CR'), typami dokumentów używanymi w organizacji dla not kredytowych. - Wymagania wstępne: Dostęp do źródłowych widoków CDS jest niezbędny. Wymaga to odpowiednich ról i uprawnień przyznanych przez zespół ds. bezpieczeństwa SAP. Ponadto czynności takie jak „Otwarto spór z klientem” czy „Wysłano przypomnienie o płatności” będą dostępne tylko wtedy, gdy w systemie są używane odpowiednie moduły SAP Dispute Management i SAP Financials Dunning.
- Wydajność: Zapytanie korzysta z wielu złączeń i operatorów UNION. W przypadku bardzo dużych zbiorów danych, na przykład obejmujących kilka lat, warto uruchomić je poza godzinami szczytu lub zastosować bardziej restrykcyjne filtry, aby ograniczyć początkowy zakres pobierania danych.
Przykładowe zapytanie sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime; Kroki
- Potwierdź dostęp do odczytu schematu SAP HANA zawierającego tabele rozliczeniowe i powiązane tabele finansowe. Uzyskaj od właściciela systemu nazwę schematu, dane połączenia, dozwolony zakres dat, zakres kodów spółek, typy dokumentów rozliczeniowych oraz ewentualne filtry klientów lub regionów. Zastąp wyłącznie wartości zastępcze dotyczące połączenia i filtrów.
- Potwierdź źródła danych SAP S/4HANA i mapowanie ich pól w systemie docelowym. Zapytanie korzysta z VBRK i VBRP do pobierania danych rozliczeniowych. Wymaga też skonfigurowanych źródeł danych księgowych, zarządzania wynikami, zarządzania sporami, monitowania, płatności przychodzących, rozliczeń i powiązań między dokumentami. Zastąp ujęte w nawiasy kwadratowe wartości zastępcze źródeł i pól dopiero po sprawdzeniu ich w słowniku danych systemu.
- Ustaw okres ekstrakcji, stosując włączający znacznik czasu początku i wyłączający znacznik czasu końca. Na pierwsze uruchomienie zaleca się okres od trzech do sześciu miesięcy. Ogranicz ekstrakcję według kodu spółki i, jeśli to właściwe, typu rozliczenia, aby kontrolować ilość danych i nie łączyć niezwiązanych procesów rozliczeniowych.
- Uruchom zapytanie przy użyciu użytkownika bazy HANA z uprawnieniami tylko do odczytu. Zapytanie tworzy jeden wiersz zdarzenia dla każdej jawnie pobieranej czynności. Nie polega na wnioskowaniu o zdarzeniach przez ProcessMind. Czynności wyliczane, w tym „Nadszedł termin płatności” i „Wykryto ponowne przetwarzanie rozliczenia”, są generowane przez logikę SQL i zwracane jako wiersze.
- Sprawdź schemat wyników. Dziennik zdarzeń musi zawierać pola InvoiceNumber, ActivityName, EventTime, UserName, InvoiceDate, PaymentDueDate, InvoiceAmount, CustomerName, Region i EndTime. Upewnij się, że w każdym wierszu pola InvoiceNumber, ActivityName i EventTime są wypełnione.
- Sprawdź znaczenie zdarzeń i powiązania między nimi. Porównaj wiersze Invoice Generated z danymi o utworzeniu nagłówka dokumentu rozliczeniowego, Invoice Posted To Accounting ze statusem księgowania, Invoice Sent To Customer z rekordami wyników, zdarzenia płatności z dokumentami księgowymi, a zdarzenia rozliczenia z rozliczonymi pozycjami faktur. Przed użyciem produkcyjnym sprawdź wszystkie sekcje zależne od wartości zastępczych.
- Przygotuj wyniki dla ProcessMind. Zachowaj jeden wiersz na zdarzenie, używaj spójnego typu danych znacznika czasu i jednej strefy czasowej, a pole InvoiceNumber przechowuj jako tekst, aby zachować zera wiodące. Wartości ActivityName muszą dokładnie odpowiadać wymaganym nazwom czynności. Posortuj dane według InvoiceNumber i EventTime, a jeśli kilka zdarzeń ma ten sam znacznik czasu, zastosuj deterministyczne sortowanie dodatkowe.
- Wyeksportuj wyniki do pliku CSV w kodowaniu UTF-8 lub innym obsługiwanym formacie tabelarycznym ProcessMind. Przypisz InvoiceNumber do identyfikatora case, ActivityName do kolumny czynności, a EventTime do znacznika czasu zdarzenia. Jeśli są dostępne, uwzględnij zalecane atrybuty. Następnie prześlij plik za pomocą skonfigurowanego procesu importu ProcessMind i sprawdź końcową liczbę wierszy oraz zdarzeń poszczególnych typów.
Konfiguracja
- Zakres dat: Na początek wybierz okres od trzech do sześciu miesięcy. Użyj włączającego znacznika czasu początku i wyłączającego znacznika czasu końca, aby uniknąć powielania zdarzeń przy kolejnych ekstrakcjach.
- Identyfikator case: Użyj pola InvoiceNumber z nagłówka dokumentu rozliczeniowego. Zachowaj je jako ciąg znaków, ponieważ numery dokumentów SAP mogą zaczynać się od zer.
- Wymagane czynności: Ekstrakcja musi zwracać jawne wiersze dla następujących czynności: Invoice Generated, Invoice Posting Blocked, Invoice Posted To Accounting, Invoice Sent To Customer, Payment Due Date Reached, Customer Dispute Opened, Payment Reminder Issued, Customer Payment Received, Cash Applied/Reconciled, Invoice Closed, Invoice Cancelled, Credit Memo Created i Billing Rework Identified.
- Filtry: Filtruj według Company Code, typu dokumentu rozliczeniowego, organizacji sprzedaży, klienta, regionu i dat dopiero po potwierdzeniu odpowiednich pól oraz zakresu biznesowego w systemie docelowym. Nie zakładaj, że wszystkie typy dokumentów rozliczeniowych podlegają takim samym zasadom księgowania i obsługi wyników.
- Konfiguracja źródeł: Główne źródła danych rozliczeniowych to VBRK i VBRP. Źródła danych księgowych, wyników, sporów, monitowania, płatności, rozliczeń i przepływu dokumentów należy skonfigurować zgodnie z wdrożoną wersją SAP S/4HANA i włączonymi modułami. Zastąp odwołania do źródeł ujęte w nawiasy kwadratowe obiektami i polami, które zostały zweryfikowane.
- Zdarzenia wyliczane: Payment Due Date Reached jest wyliczane na podstawie warunków płatności i danych o terminie płatności. Billing Rework Identified wynika z wzorców anulowania i późniejszego wygenerowania faktury. Są to wiersze zdarzeń tworzone przez SQL, a nie natywne rekordy transakcyjne.
- Wydajność: Dodaj filtry dat, kodu spółki, typu rozliczenia i numeru dokumentu do zapytań dla każdego źródła. Pobieraj tylko potrzebne kolumny, unikaj nieograniczonych złączeń z dużymi tabelami księgowymi, przetwarzaj dane w partiach miesięcznych lub tygodniowych i korzystaj z planów wykonania bazy danych, aby wykryć kosztowne złączenia.
- Ekstrakcja przyrostowa: Użyj stabilnego punktu kontrolnego opartego na znacznikach czasu utworzenia lub księgowania w źródle. Ponownie przetwarzaj krótki nakładający się okres, aby uwzględnić późno dodane rekordy wyników, płatności, sporów i rozliczeń. Następnie usuń duplikaty na podstawie InvoiceNumber, ActivityName i EventTime oraz odpowiedniego klucza dokumentu źródłowego.
- Uprawnienia: Użytkownik ekstrakcji musi mieć uprawnienia do odczytu wybranych obiektów i pól w schemacie HANA. Potwierdź, że bezpośredni dostęp do bazy danych jest dozwolony przez politykę bezpieczeństwa organizacji oraz że spełniono wymagania dotyczące przetwarzania danych osobowych i danych klientów.
- Wymagania funkcjonalne: Dane dotyczące zarządzania wynikami, integracji księgowej, zarządzania sporami, monitowania, płatności przychodzących i rozliczeń są dostępne tylko wtedy, gdy odpowiednie funkcje skonfigurowano i są używane w systemie. Brak modułów lub rekordów źródłowych oznacza brak danych o tych czynnościach, a nie zdarzenia wywnioskowane.
- Strefa czasowa: Ujednolić znaczniki czasu zgodnie ze strefą czasową wymaganą przez ProcessMind. Udokumentuj, czy znaczniki czasu w źródle są zapisane w UTC, czasie lokalnym systemu czy innej skonfigurowanej strefie czasowej.
Przykładowe zapytanie sql
WITH
billing_headers AS (
SELECT
h.VBELN AS InvoiceNumber,
h.FKDAT AS InvoiceDate,
h.NETWR AS InvoiceAmount,
h.KUNAG AS CustomerNumber,
h.ERDAT AS BillingCreatedDate,
h.ERZET AS BillingCreatedTime,
h.ERNAM AS BillingCreatedBy,
h.BUKRS AS CompanyCode,
h.FKART AS BillingType,
h.FKSTO AS CancellationIndicator,
h.RFBSK AS AccountingPostingStatus,
h.ZTERM AS PaymentTerms,
h.ZFBDT AS BaselineDate,
h.NETDT AS PaymentDueDate,
h.VBELV AS PrecedingDocument
FROM [Your HANA schema].VBRK h
WHERE h.ERDAT >= '[Start date, YYYY-MM-DD]'
AND h.ERDAT < '[End date, YYYY-MM-DD]'
AND h.BUKRS IN ([Company code filter])
AND h.FKART IN ([Billing document type filter])
),
customer_data AS (
SELECT
c.KUNNR AS CustomerNumber,
c.NAME1 AS CustomerName,
c.REGION AS Region
FROM [Your customer master source] c
),
invoice_base AS (
SELECT
b.InvoiceNumber,
b.InvoiceDate,
b.InvoiceAmount,
b.CustomerNumber,
c.CustomerName,
c.Region,
b.BillingCreatedDate,
b.BillingCreatedTime,
b.BillingCreatedBy,
b.CompanyCode,
b.BillingType,
b.CancellationIndicator,
b.AccountingPostingStatus,
b.PaymentTerms,
b.BaselineDate,
b.PaymentDueDate,
b.PrecedingDocument
FROM billing_headers b
LEFT JOIN customer_data c
ON c.CustomerNumber = b.CustomerNumber
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Generated' AS ActivityName,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EventTime,
i.BillingCreatedBy AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EndTime
FROM invoice_base i
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posting blocked status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
a.StatusTimestamp AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
a.StatusTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posted status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
o.SentTimestamp AS EventTime,
o.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
o.SentTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your output management source] o
ON o.InvoiceNumber = i.InvoiceNumber
AND o.OutputStatus = '[Successfully sent status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM invoice_base i
WHERE i.PaymentDueDate IS NOT NULL
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
d.OpenedTimestamp AS EventTime,
d.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
d.OpenedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dispute management source] d
ON d.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
r.IssuedTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.IssuedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dunning or payment reminder source] r
ON r.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Payment Received' AS ActivityName,
p.ReceivedTimestamp AS EventTime,
p.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
p.ReceivedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your incoming payment source] p
ON p.CustomerNumber = i.CustomerNumber
AND p.CompanyCode = i.CompanyCode
AND p.ReceivedTimestamp >= TO_TIMESTAMP(TO_VARCHAR(i.InvoiceDate))
UNION ALL
SELECT
i.InvoiceNumber,
'Cash Applied/Reconciled' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Closed' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
x.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
LEFT JOIN [Your billing cancellation or document flow source] x
ON x.InvoiceNumber = i.InvoiceNumber
WHERE i.CancellationIndicator = '[Cancellation indicator value]'
OR x.InvoiceNumber IS NOT NULL
UNION ALL
SELECT
cm.ReferenceInvoiceNumber AS InvoiceNumber,
'Credit Memo Created' AS ActivityName,
cm.CreatedTimestamp AS EventTime,
cm.UserName,
i.InvoiceDate,
i.PaymentDueDate,
cm.Amount AS InvoiceAmount,
i.CustomerName,
i.Region,
cm.CreatedTimestamp AS EndTime
FROM [Your credit memo source] cm
INNER JOIN invoice_base i
ON i.InvoiceNumber = cm.ReferenceInvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
r.ReworkTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.ReworkTimestamp AS EndTime
FROM invoice_base i
INNER JOIN (
SELECT
old_invoice.InvoiceNumber,
new_invoice.InvoiceNumber AS ReplacementInvoiceNumber,
new_invoice.BillingCreatedDate AS ReworkTimestamp,
new_invoice.BillingCreatedBy AS UserName
FROM invoice_base old_invoice
INNER JOIN invoice_base new_invoice
ON new_invoice.PrecedingDocument = old_invoice.InvoiceNumber
AND new_invoice.BillingCreatedDate > old_invoice.BillingCreatedDate
WHERE old_invoice.CancellationIndicator = '[Cancellation indicator value]'
) r
ON r.InvoiceNumber = i.InvoiceNumber
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
InvoiceDate,
PaymentDueDate,
InvoiceAmount,
CustomerName,
Region,
EndTime
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName; Gotowi, aby zacząć?
Skorzystaj z tego szablonu, aby przyspieszyć przygotowanie danych i rozpocząć optymalizację procesu Order to Cash: rozliczanie i fakturowanie. Już dziś przekształć dane z SAP S/4HANA w praktyczne informacje.
Przyspiesz rozliczanie zamówień i skróć przepływ gotówki o 30%
Już dziś ogranicz nieefektywne działania i skróć cykl fakturowania o 30%.
Nie trzeba podawać danych karty płatniczej. Rozpoczęcie zajmuje kilka minut.