Szablon danych dla procesu fakturowania od zamówienia do płatności
Szablon danych dla procesu fakturowania od zamówienia do płatności
- Zalecane atrybuty do szczegółowej analizy
- Najważniejsze etapy i punkty kontrolne procesu do śledzenia
- Praktyczne wskazówki dotyczące ekstrakcji danych z SAP ECC
Atrybuty procesu fakturowania od zamówienia do płatności
| Nazwa | Opis | ||
|---|---|---|---|
| Czas rozpoczęcia EventTime | Znacznik czasu wskazujący, kiedy wystąpiło dane działanie lub zdarzenie. | ||
| Opis Czas zdarzenia określa dokładną datę i godzinę każdego działania w cyklu życia faktury. Ten znacznik czasu jest podstawą analiz czasowych w process mining, w tym obliczania czasu cyklu, wykrywania wąskich gardeł i monitorowania wyników procesu względem uzgodnionych poziomów usług. Atrybut ten zwykle powstaje przez połączenie pola daty, takiego jak data księgowania (BUDAT), z polem czasu (UZEIT) z tabel SAP rejestrujących zmiany lub utworzenie dokumentu. Dokładne znaczniki czasu są niezbędne do zbudowania wiarygodnego dziennika zdarzeń i zapewnienia rzetelności analiz wyników. Dlaczego to ważne Ten atrybut stanowi podstawę analizy wyników procesu. Umożliwia obliczanie czasu cyklu, czasu trwania i przerw między kolejnymi krokami. Skąd pobrać Wyznaczany na podstawie różnych pól daty i czasu z wielu tabel, takich jak BKPF (BUDAT, CPUTM), VBRK (ERDAT, ERZET) oraz tabele dziennika zmian, na przykład CDHDR (UDATE, UTIME). Przykłady 2023-04-15T10:30:00Z2023-04-16T11:00:00Z2023-05-20T09:00:00Z | |||
| Działanie ActivityName | Nazwa zdarzenia biznesowego lub kroku, który wystąpił w cyklu życia faktury. | ||
| Opis Ten atrybut opisuje konkretne działanie lub zmianę statusu w procesie rozliczania, na przykład „Wygenerowano fakturę”, „Zaksięgowano fakturę” lub „Otrzymano płatność od klienta”. Działania te są wyznaczane na podstawie różnych zdarzeń systemowych, zmian statusu dokumentów lub kodów transakcji użytych przez użytkowników. Sekwencja działań tworzy przebieg procesu i stanowi podstawę analizy process mining. Analiza pozwala ustalić, jakie kroki są wykonywane, w jakiej kolejności i jak często. Dzięki temu można porównać rzeczywisty przebieg procesu z jego założonym modelem. Dlaczego to ważne Określa kroki na mapie procesu i umożliwia wizualizację oraz analizę przebiegu procesu, odstępstw i wąskich gardeł. Skąd pobrać To atrybut pojęciowy wyznaczany na podstawie wielu źródeł, takich jak kody transakcji (CDHDR-TCODE), zmiany statusu dokumentów (VBUK-FKSTK) i księgowania dokumentów finansowych. Przykłady Wystawiono fakturęZaksięgowano fakturęWysłano przypomnienie o płatnościRozliczono fakturę | |||
| Numer faktury InvoiceNumber | Unikalny identyfikator dokumentu rozliczeniowego, używany jako główny identyfikator sprawy w procesie fakturowania. | ||
| Opis Numer faktury, w SAP nazywany numerem dokumentu rozliczeniowego, jednoznacznie identyfikuje każdą fakturę. W process mining pełni funkcję CaseId i łączy powiązane działania, takie jak utworzenie, księgowanie, wysłanie, płatność i rozliczenie, w jedną instancję procesu. Analiza procesu według numeru faktury pokazuje pełny przebieg każdej transakcji rozliczeniowej, od jej rozpoczęcia do ostatecznego rozliczenia. Dzięki temu można obliczyć wskaźniki, takie jak Days Sales Outstanding (DSO) i całkowity czas obsługi faktury, a następnie wykorzystać je do oceny i usprawnienia procesu. Dlaczego to ważne To podstawowy identyfikator, który pozwala śledzić cały przebieg obsługi faktury oraz analizować czas cyklu, wąskie gardła i różnice w poszczególnych transakcjach rozliczeniowych. Skąd pobrać Tabela SAP ECC: VBRK, pole: VBELN Przykłady 90001234900012359000123690001237 | |||
| Kod spółki CompanyCode | Identyfikator jednostki prawnej, która wystawiła fakturę. | ||
| Opis Kod spółki oznacza w SAP niezależną jednostkę prawną i księgową. Wszystkie transakcje finansowe, w tym faktury, są księgowane w ramach określonego kodu spółki. To podstawowy element struktury organizacyjnej. W process mining kod spółki służy do analizy i porównywania wyników procesu rozliczeń w różnych jednostkach prawnych firmy. Pozwala wskazać dobre praktyki, które można zastosować w innych jednostkach, a także dopasować analizę do struktury organizacyjnej firmy. Dlaczego to ważne Umożliwia filtrowanie i porównywanie procesów w różnych jednostkach prawnych. Jest to podstawa analiz finansowych i porównań między jednostkami. Skąd pobrać Tabela SAP ECC: VBRK, pole: BUKRS Przykłady 10002000US01DE01 | |||
| Łączna kwota faktury TotalInvoiceAmount | Łączna wartość netto dokumentu rozliczeniowego. | ||
| Opis Ten atrybut określa łączną kwotę netto faktury, bez podatków. Kwota faktury to istotna dana finansowa związana z procesem rozliczeń. Można jej używać do różnych analiz, na przykład podzielić faktury na wysokokwotowe i niskokwotowe, aby sprawdzić, czy ich przebieg się różni. Pomaga też ustalać priorytety działań windykacyjnych i analizować, dlaczego zatwierdzenie lub opłacenie faktur o wysokiej wartości trwa dłużej. Dzięki temu analiza procesu uwzględnia kontekst finansowy. Dlaczego to ważne Dostarcza kontekstu finansowego i pozwala analizować proces według wartości faktury, na przykład sprawdzić, czy faktury o wysokiej wartości mają inny przebieg lub dłużej czekają na rozliczenie. Skąd pobrać Tabela SAP ECC: VBRK, pole: NETWR Przykłady 1500.7525000.00500.0012345.67 | |||
| Nazwa użytkownika UserName | Identyfikator użytkownika, który wykonał działanie lub utworzył dokument. | ||
| Opis Ten atrybut zawiera identyfikator użytkownika SAP odpowiedzialnego za dane zdarzenie, na przykład utworzenie faktury lub zaksięgowanie płatności. Pozwala analizować udział pracowników w procesie. Dzięki tym danym można sprawdzać różnice w wynikach pracy użytkowników i zespołów, określać potrzeby szkoleniowe oraz wykrywać potencjalne problemy ze zgodnością. Atrybut pomaga też odróżnić działania ręczne od kroków wykonywanych automatycznie przez użytkowników systemowych lub zadania wsadowe. To ważne przy obliczaniu poziomu automatyzacji. Dlaczego to ważne Umożliwia analizę wyników pracy użytkowników i rozkładu obciążenia, a także odróżnienie działań ręcznych od automatycznych. Wspiera to inicjatywy związane z automatyzacją i poprawą efektywności. Skąd pobrać Tabela SAP ECC: VBRK, pole: ERNAM (utworzył) lub BKPF, pole: USNAM (nazwa użytkownika) lub CDHDR, pole: USERNAME (użytkownik). Przykłady JSMITHBW_BATCHLROSSIMKUMAR | |||
| Numer klienta CustomerNumber | Unikalny numer klienta, na którego wystawiono fakturę. | ||
| Opis Numer klienta łączy fakturę z konkretnym klientem lub partnerem biznesowym. Atrybut ten pozwala analizować proces rozliczeń według cech klientów. Analitycy mogą porównywać Days Sales Outstanding (DSO) dla różnych klientów, ustalać, którzy z nich często płacą po terminie, oraz sprawdzać, czy przestrzegają uzgodnionych warunków płatności. Wiedza o tych wzorcach pomaga zarządzać relacjami z klientami i dostosowywać działania windykacyjne do poszczególnych grup. Dlaczego to ważne Umożliwia analizę z perspektywy klienta, w tym badanie zachowań płatniczych, ocenę DSO dla poszczególnych klientów i dostosowanie działań windykacyjnych. Skąd pobrać Tabela SAP ECC: VBRK, pole: KUNRG (płatnik) lub KUNAG (odbiorca towaru). Przykłady 100023200541CUST-A487910345 | |||
| Rodzaj dokumentu rozliczeniowego BillingDocumentType | Kod określający rodzaj dokumentu rozliczeniowego, na przykład fakturę, notę uznaniową lub notę obciążeniową. | ||
| Opis Rodzaj dokumentu rozliczeniowego klasyfikuje transakcje według ich celu biznesowego. Na przykład „F2” oznacza standardową fakturę dla klienta, a „G2” notę uznaniową. Klasyfikacja jest skonfigurowana w SAP i określa sposób przetwarzania poszczególnych dokumentów rozliczeniowych. W process mining atrybut ten służy do filtrowania i porównywania różnych scenariuszy rozliczeń. Można osobno analizować proces obsługi standardowych faktur i not uznaniowych, aby poznać ich przebieg, czas cyklu i problemy. Ułatwia to lepsze ukierunkowanie działań usprawniających. Dlaczego to ważne Umożliwia podział i analizę różnych procesów rozliczeniowych, na przykład obsługi standardowych faktur i not uznaniowych, które często przebiegają zupełnie inaczej. Skąd pobrać Tabela SAP ECC: VBRK, pole: FKART Przykłady F2G2L2IV | |||
| Data dokumentu DocumentDate | Data na dokumencie źródłowym, podana przez dostawcę lub osobę, która go utworzyła. | ||
| Opis Data dokumentu to dzień wystawienia dokumentu źródłowego. W procesie rozliczeń jest to zwykle data utworzenia faktury i często stanowi podstawę do wyznaczenia terminu płatności. Data ta ma znaczenie przy raportowaniu finansowym i obliczaniu wskaźników, takich jak Days Sales Outstanding (DSO). Z perspektywy klienta wyznacza początek okresu oczekiwania na płatność. Analiza różnic między datą dokumentu a datą księgowania może ujawnić opóźnienia w wewnętrznej obsłudze dokumentów rozliczeniowych. Dlaczego to ważne Stanowi punkt odniesienia przy obliczaniu wieku faktury i DSO oraz analizie finansowej i warunków płatności. Skąd pobrać Tabela SAP ECC: VBRK, pole: FKDAT (data rozliczenia) Przykłady 2023-04-152023-04-162023-05-20 | |||
| Data księgowania PostingDate | Data zaksięgowania dokumentu w księgach rachunkowych. | ||
| Opis Data księgowania określa okres obrachunkowy, w którym transakcja jest ujmowana w księdze głównej. Ma zasadnicze znaczenie dla księgowości i sprawozdawczości finansowej. Opóźnienie między utworzeniem dokumentu a jego zaksięgowaniem może wskazywać na problemy z wewnętrzną obsługą dokumentów rozliczeniowych. W analizie process mining data księgowania oznacza ważny etap cyklu życia faktury. Czas między wygenerowaniem a zaksięgowaniem faktury może służyć jako wskaźnik efektywności działu rozliczeń. Dlaczego to ważne Oznacza ważny etap finansowy i ma zasadnicze znaczenie dla księgowości. Czas między utworzeniem a zaksięgowaniem faktury mierzy efektywność jej wewnętrznej obsługi. Skąd pobrać Tabela SAP ECC: BKPF, pole: BUDAT Przykłady 2023-04-152023-04-172023-05-21 | |||
| Data rozliczenia ClearingDate | Data otrzymania płatności i rozliczenia faktury w należnościach. | ||
| Opis Data rozliczenia to dzień, w którym pozycja otwarta, na przykład faktura, zostaje oznaczona w systemie finansowym jako opłacona lub rozliczona. Oznacza moment, w którym środki uznaje się za otrzymane i uzgodnione. To jedna z najważniejszych dat w cyklu Order to Cash. Wyznacza koniec okresu używanego do obliczenia Days Sales Outstanding (DSO) i całkowitego czasu od wystawienia faktury do otrzymania płatności. Analiza tej daty pomaga ocenić skuteczność procesu windykacji. Dlaczego to ważne Oznacza końcowy etap cyklu życia faktury. Wyznacza datę końcową przy obliczaniu DSO i całkowitego czasu cyklu, a także odzwierciedla skuteczność odzyskiwania należności. Skąd pobrać Tabela SAP ECC: BSAD, pole: AUGDT Przykłady 2023-05-142023-06-012023-06-25 | |||
| Kod transakcji TransactionCode | Kod transakcji SAP użyty do wykonania działania. | ||
| Opis Kod transakcji, czyli T-Code, to unikalny identyfikator funkcji lub programu w SAP, na przykład „VF01” służący do utworzenia dokumentu rozliczeniowego. Rejestrowanie T-Code dla każdego zdarzenia pokazuje techniczny, systemowy przebieg procesu. Te informacje pomagają ustalić przyczyny problemów. Jeśli często występują błędy, analitycy mogą sprawdzić, czy używany jest niestandardowy kod transakcji. Kod ułatwia też określenie nazwy działania i ustalenie, z jakich funkcji systemu korzystano w procesie. Dlaczego to ważne Dostarcza technicznego kontekstu wykonania działania, ułatwia analizę przyczyn odstępstw od procesu i pomaga wykrywać niestandardowe działania użytkowników. Skąd pobrać Tabela SAP ECC: CDHDR, pole: TCODE Przykłady VF01VF02FB01F-28 | |||
| Numer dokumentu sprzedaży SalesDocumentNumber | Identyfikator pierwotnego zamówienia sprzedaży, na podstawie którego wystawiono fakturę. | ||
| Opis Ten atrybut bezpośrednio łączy fakturę z zamówieniem sprzedaży, które zapoczątkowało transakcję. Taka możliwość śledzenia jest niezbędna do pełnej analizy procesu Order to Cash. Połączenie procesu rozliczeń z poprzedzającym go procesem obsługi zamówienia pozwala analizować całkowity czas od złożenia zamówienia przez klienta do otrzymania płatności. Ułatwia ustalenie, czy opóźnienia w rozliczeniach wynikają z problemów w sprzedaży, realizacji zamówienia czy samym dziale rozliczeń. Dzięki temu można spojrzeć na proces z szerszej perspektywy. Dlaczego to ważne Łączy proces rozliczeń z zamówieniem sprzedaży, umożliwia pełną analizę Order to Cash i pomaga wykrywać opóźnienia między działami. Skąd pobrać Tabela SAP ECC: VBRP, pole: VGBEL Przykłady 100000451000004610000047 | |||
| Organizacja sprzedaży SalesOrganization | Jednostka organizacyjna odpowiedzialna za sprzedaż produktów lub usług. | ||
| Opis Organizacja sprzedaży to jednostka w SAP odpowiedzialna za dystrybucję towarów i usług oraz ustalanie warunków sprzedaży. Stanowi element struktury sprzedaży i dystrybucji. W process mining atrybut ten pozwala analizować proces rozliczeń z perspektywy struktury sprzedaży. Umożliwia porównanie wyników różnych organizacji sprzedaży i wskazanie regionów lub linii biznesowych, w których rozliczenia przebiegają sprawniej. Pomaga też upowszechniać sprawdzone praktyki. Dlaczego to ważne Umożliwia porównywanie wyników różnych działów sprzedaży lub regionów, co pomaga wskazywać dobre praktyki i obszary wymagające usprawnienia. Skąd pobrać Tabela SAP ECC: VBRK, pole: VKORG Przykłady 1000NA01EU01AP01 | |||
| Ostatnia aktualizacja danych LastDataUpdate | Znacznik czasu ostatniego odświeżenia danych lub ich ekstrakcji z systemu źródłowego. | ||
| Opis Ten atrybut wskazuje, kiedy dane zostały ostatnio zaktualizowane z systemu źródłowego. Dostarcza kontekstu potrzebnego do oceny aktualności analizowanych danych. W dashboardach i raportach znacznik czasu informuje odbiorców, na ile aktualne są dane, i pozwala określić, czy uwzględniają najnowsze transakcje. Zwykle jest generowany po zakończeniu ekstrakcji danych. Dlaczego to ważne Informuje o aktualności danych, co ma znaczenie przy podejmowaniu decyzji operacyjnych na podstawie analizy. Skąd pobrać Generowany i zapisywany podczas procesu ekstrakcji, transformacji i ładowania danych (ETL). Przykłady 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Ponowne wykonanie IsRework | Flaga wskazująca, czy działanie jest etapem ponownej obsługi lub korekty. | ||
| Opis Ten obliczany atrybut wskazuje działania oznaczające ponowną obsługę, takie jak „Skorygowano fakturę” lub odwrócenie księgowania dokumentu. Zwykle ma postać wartości logicznej i jest wyznaczany na podstawie nazwy działania lub kodów transakcji związanych z korektami i anulowaniem, takich jak „VF11” służący do anulowania dokumentu rozliczeniowego. W process mining flaga ta pozwala określić skalę ponownej obsługi w procesie rozliczeń. Bezpośrednio wspiera wskaźniki KPI, takie jak wskaźnik korekt faktur, i pomaga wizualizować pętle poprawek na mapie procesu. Ujawnia nieefektywność i problemy z jakością, które zwiększają koszty operacyjne i opóźniają płatności. Dlaczego to ważne Pomaga określić skalę nieefektywności i problemów z jakością, pokazując nakład pracy potrzebny na poprawianie błędów. Wspiera też wskaźniki KPI dotyczące ponownej obsługi. Skąd pobrać Wyznaczany na podstawie nazwy działania lub kodu transakcji. Na przykład: IF ActivityName = 'Invoice Corrected' OR TransactionCode = 'VF11' THEN true ELSE false. Przykłady truefalse | |||
| System źródłowy SourceSystem | Wskazuje system, z którego wyodrębniono dane. | ||
| Opis Ten atrybut określa system, w którym pierwotnie zapisano dane. W firmach korzystających z wielu instancji ERP lub zintegrowanych systemów pozwala rozróżnić dane pochodzące z różnych źródeł. W process mining jest niezbędny do walidacji danych i porównywania procesów między systemami lub jednostkami organizacyjnymi. Zwykle przypisuje się go jako stałą wartość podczas ekstrakcji danych, aby oznaczyć zbiór danych. Dlaczego to ważne Informuje o pochodzeniu danych. Ma to znaczenie w środowiskach z wieloma systemami, ponieważ pomaga zachować integralność danych i prowadzić analizy dla poszczególnych systemów. Skąd pobrać Zwykle jest to stała wartość dodawana podczas procesu ekstrakcji, transformacji i ładowania danych (ETL), która wskazuje konkretną instancję SAP ECC, na przykład „ECC_PROD_NA”. Przykłady SAP_ECC_PRODECC_EU_100SAP_US_FIN | |||
| Termin płatności faktury InvoiceDueDate | Data, do której klient powinien dokonać płatności. | ||
| Opis Termin płatności faktury to data, do której należy uregulować należność zgodnie z warunkami płatności. Ma zasadnicze znaczenie dla zarządzania należnościami i rozpoczynania działań windykacyjnych. Atrybut ten służy do obliczania wskaźnika KPI terminowych płatności przez porównanie terminu z faktyczną datą płatności. Analiza faktur według terminu płatności pomaga prognozować przepływy pieniężne i ustalać priorytety działań dotyczących płatności zbliżających się do terminu lub już przeterminowanych. Termin jest zwykle wyznaczany na podstawie daty bazowej i warunków płatności. Dlaczego to ważne Stanowi punkt odniesienia przy ocenie terminowości płatności i jest niezbędny do zarządzania należnościami oraz prognozowania przepływów pieniężnych. Skąd pobrać Obliczany na podstawie daty bazowej (BSEG-ZFBDT) i warunków płatności (BSEG-ZTERM). Nie zawsze jest zapisany w osobnym polu. Przykłady 2023-05-152023-05-302023-06-20 | |||
| Waluta Currency | Kod waluty, w której podano kwoty na fakturze. | ||
| Opis Ten atrybut wskazuje walutę transakcji, na przykład USD, EUR lub JPY. Pozwala prawidłowo interpretować kwoty, takie jak łączna kwota faktury. Podczas analizy danych z międzynarodowej firmy pole waluty jest niezbędne do poprawnej interpretacji i przeliczania kwot. Umożliwia spójne raportowanie i zapobiega sumowaniu kwot bez właściwego przeliczenia walut, które prowadziłoby do błędnych wniosków finansowych. Dlaczego to ważne Zapewnia kontekst dla wszystkich kwot i pozwala rzetelnie analizować dane finansowe, zwłaszcza w środowisku wielowalutowym. Skąd pobrać Tabela SAP ECC: VBRK, pole: WAERK Przykłady USDEURGBPJPY | |||
| Warunki płatności PaymentTerms | Uzgodnione zasady sprzedaży, w tym harmonogram płatności. | ||
| Opis Warunki płatności określają termin uregulowania należności, na przykład „30 dni netto” lub „60 dni netto”. Są uzgadniane z klientem i wpływają na przepływy pieniężne. Analiza procesu według warunków płatności może wykazać, czy niektóre z nich wiążą się z dłuższym cyklem płatności lub częstszymi opóźnieniami. Te informacje mogą pomóc w negocjowaniu korzystniejszych warunków z klientami i planowaniu finansowym. Warunki płatności są też jednym z danych wykorzystywanych do obliczenia terminu płatności faktury. Dlaczego to ważne Pomaga analizować zachowania płatnicze klientów i wpływ uzgodnionych warunków na przepływy pieniężne, dostarczając informacji przydatnych przy optymalizacji umów handlowych. Skąd pobrać Tabela SAP ECC: VBRK, pole: ZTERM Przykłady Z030Z060Z001 | |||
| Wykonywane automatycznie IsAutomated | Flaga wskazująca, czy działanie wykonał użytkownik systemowy lub czy zostało zautomatyzowane. | ||
| Opis Ten obliczany atrybut ma postać wartości logicznej i odróżnia działania ręczne od automatycznych. Zwykle jest wyznaczany przez porównanie atrybutu „Nazwa użytkownika” z listą znanych identyfikatorów użytkowników systemowych lub wsadowych, takich jak „BATCHUSER” lub „SAPSYSTEM”. Flaga ta pozwala mierzyć poziom automatyzacji procesu rozliczeń, do którego wiele firm dąży, aby zwiększyć efektywność i ograniczyć koszty. Na jej podstawie bezpośrednio oblicza się wskaźnik KPI automatyzacji rozliczeń, który pomaga śledzić postępy inicjatyw automatyzacyjnych. Dlaczego to ważne Bezpośrednio wspiera obliczanie wskaźnika automatyzacji rozliczeń, pomaga mierzyć efektywność procesu i oceniać wpływ projektów automatyzacyjnych. Skąd pobrać Wyznaczany na podstawie atrybutu „Nazwa użytkownika”. Logika może wyglądać następująco: IF UserName IN ('BATCH', 'SYSTEM', 'RFCUSER') THEN true ELSE false. Przykłady truefalse | |||
Czynności w procesie fakturowania od zamówienia do płatności
| Działanie | Opis | ||
|---|---|---|---|
| Otrzymano płatność od klienta | Otrzymano płatność od klienta i zaksięgowano ją w systemie jako wpływ gotówki lub wpłatę bankową. Powstaje osobny dokument płatności, który nie został jeszcze przypisany do konkretnej faktury. | ||
| Dlaczego to ważne To ważny etap cyklu konwersji gotówki. Czas od wysłania faktury do otrzymania płatności stanowi główną składową Days Sales Outstanding (DSO). Skąd pobrać Płatność jest rejestrowana jako nowy dokument w tabelach BKPF i BSEG, zwykle z typem dokumentu oznaczającym płatność od klienta, na przykład „DZ”. Zdarzenie oznacza data księgowania (BUDAT). Rejestrowanie Na podstawie daty księgowania dokumentu płatności od klienta w tabeli BKPF. Typ zdarzenia explicit | |||
| Rozliczono fakturę | Końcowy status opłaconej faktury. Oznacza, że otwarta pozycja została zamknięta po otrzymaniu płatności lub noty uznaniowej. Faktura jest w pełni rozliczona. | ||
| Dlaczego to ważne Zdarzenie oznacza pomyślne zakończenie cyklu Order to Cash dla faktury. Jest głównym zdarzeniem końcowym używanym do pomiaru średniego czasu realizacji całego cyklu faktury. Skąd pobrać Zdarzenie występuje po uzupełnieniu pól dokumentu rozliczenia (AUGBL) i daty rozliczenia (AUGDT) dla pozycji faktury w tabeli BSEG. Rejestrowanie Zdarzenie występuje w dniu rozliczenia (AUGDT) zapisanym w tabeli BSEG dla pozycji faktury. Typ zdarzenia explicit | |||
| Wysłano fakturę do klienta | Oznacza wysłanie faktury do klienta za pośrednictwem określonego kanału, takiego jak druk, e-mail lub EDI. Zdarzenie jest zwykle rejestrowane w dziennikach systemu zarządzania wydrukami i komunikatami. | ||
| Dlaczego to ważne To ważny etap, od którego zaczyna biec termin płatności klienta. Opóźnienie na tym etapie bezpośrednio wpływa na przewidywany termin otrzymania płatności i efektywność odzyskiwania należności. Skąd pobrać Zdarzenie można wywnioskować z daty i godziny przetworzenia zapisanych w tabeli statusów komunikatów (NAST) dla typu komunikatu odpowiadającego fakturze. Rejestrowanie Zdarzenie można wywnioskować z wpisu w tabeli NAST ze statusem przetwarzania „1” (przetworzono pomyślnie). Typ zdarzenia inferred | |||
| Wystawiono fakturę | Oznacza utworzenie dokumentu rozliczeniowego w systemie. Zdarzenie jest rejestrowane po dodaniu nowego wpisu do tabeli nagłówków dokumentów księgowych (BKPF) z typem dokumentu właściwym dla faktur. | ||
| Dlaczego to ważne To początek całego procesu fakturowania. Analiza czasu od tego zdarzenia pozwala mierzyć czas wystawiania faktury i stanowi podstawę do obliczania Days Sales Outstanding (DSO). Skąd pobrać Zdarzenie jest rejestrowane w tabeli BKPF. Oznaczają je data utworzenia (CPUDT) i godzina (CPUTM) dla danego numeru dokumentu (BELNR). Typ dokumentu (BLART) wskazuje, że jest to faktura. Rejestrowanie Na podstawie znacznika czasu utworzenia (CPUDT) dokumentu faktury w tabeli BKPF. Typ zdarzenia explicit | |||
| Zaksięgowano fakturę | Faktura została formalnie ujęta w księdze pomocniczej należności i księdze głównej. Zdarzenie nadaje jej moc prawną i odzwierciedla zadłużenie klienta. | ||
| Dlaczego to ważne To ważny etap, który oficjalnie rozpoczyna bieg terminu płatności. Czas między wystawieniem a zaksięgowaniem faktury może ujawnić opóźnienia w obsłudze wewnętrznej wpływające na przepływy pieniężne. Skąd pobrać Zdarzenie jest rejestrowane w tabeli BKPF. Oznacza je data księgowania (BUDAT) dla numeru dokumentu (BELNR). W przypadku dokumentu zapisanego wstępnie jest to moment jego przekształcenia w dokument zaksięgowany. Rejestrowanie Na podstawie daty księgowania (BUDAT) dokumentu faktury w tabeli BKPF. Typ zdarzenia explicit | |||
| Nadszedł termin płatności faktury | Zdarzenie wyliczane, które oznacza dzień, w którym zgodnie z warunkami płatności należy uregulować fakturę. Nie jest to czynność wykonywana przez użytkownika ani system, lecz ważny moment w czasie. | ||
| Dlaczego to ważne Zdarzenie jest niezbędne do analizy zachowań płatniczych i zgodności z warunkami. Stanowi punkt odniesienia przy ustalaniu, czy płatność była terminowa, oraz obliczaniu KPI terminowości płatności. Skąd pobrać Zdarzenie wylicza się, porównując bieżącą datę z terminem płatności netto. Termin znajduje się w polu BSEG-ZFBDT lub jest obliczany na podstawie daty bazowej i warunków płatności. Rejestrowanie Porównaj datę systemową z terminem płatności netto w pozycji faktury (BSEG). Typ zdarzenia calculated | |||
| Odpisano fakturę | Alternatywny status końcowy, w którym fakturę uznaje się za nieściągalną, a należną kwotę rozlicza na koncie należności nieściągalnych. Faktura zostaje zamknięta bez płatności od klienta. | ||
| Dlaczego to ważne Zdarzenie oznacza niekorzystny wynik procesu i utratę przychodów. Śledzenie takich przypadków pomaga analizować przyczyny powstawania należności nieściągalnych i usprawniać zasady zarządzania ryzykiem kredytowym. Skąd pobrać Ustalane na podstawie analizy transakcji rozliczenia faktury. Jeśli dokument rozliczeniowy jest księgowany na określonym koncie księgi głównej dla należności nieściągalnych, fakturę uznaje się za odpisaną. Rejestrowanie Ustalane, gdy transakcja rozliczenia obejmuje księgowanie na wyznaczonym koncie księgi głównej dla należności nieściągalnych. Typ zdarzenia inferred | |||
| Przypisano płatność do faktury | Otrzymana płatność od klienta została dopasowana do konkretnej otwartej faktury i przypisana do niej, co oznacza pozycję jako rozliczaną. Ten etap uzgadniania łączy płatność z należnością. | ||
| Dlaczego to ważne Ta czynność jest niezbędna do pomiaru czasu rozliczania płatności. Opóźnienia w przypisywaniu wpłat mogą zniekształcać obraz należności i ukrywać dostępne środki. Skąd pobrać Zdarzenie można wywnioskować z transakcji rozliczenia, na przykład F-32, która uzupełnia pola rozliczenia w pozycji faktury. Znacznikiem czasu zdarzenia jest data rozliczenia. Rejestrowanie Zdarzenie można wywnioskować na podstawie uzupełnienia daty rozliczenia (AUGDT) w tabeli pozycji faktury (BSEG). Typ zdarzenia inferred | |||
| Skorygowano fakturę | Oznacza poprawkę po wykryciu błędu w pierwotnej fakturze i jej późniejszym odwróceniu. Zdarzenie wykrywa się na podstawie dokumentów korygujących powiązanych z pierwotną fakturą. | ||
| Dlaczego to ważne Zdarzenie wskazuje nieefektywność procesu i problemy z jakością. Częste korekty sygnalizują problemy z danymi sprzedażowymi lub fakturowaniem na wcześniejszych etapach. Informacje te wspierają dashboard dotyczący poprawek i błędów na fakturach. Skąd pobrać Zdarzenie można wykryć, znajdując dokument korygujący, w którym pole BKPF-STBLG wskazuje dokument pierwotny. Zdarzeniem jest utworzenie dokumentu korygującego. Rejestrowanie Zdarzenie jest rejestrowane po utworzeniu dokumentu korygującego, na przykład za pomocą FB08. Typ zdarzenia explicit | |||
| Utworzono sprawę sporną | Do faktury zarejestrowano formalny spór, zwykle w związku z reklamacją klienta. Informacja jest zapisywana w systemie SAP Dispute Management. | ||
| Dlaczego to ważne Zdarzenie wskazuje faktury zagrożone opóźnieniem płatności i ujawnia problemy leżące u podstaw niezadowolenia klienta. Oznacza początek ważnego procesu obsługi wyjątków. Skąd pobrać Zdarzenie jest rejestrowane po utworzeniu sprawy w tabeli spraw spornych (UDM_CASE) powiązanej z dokumentem księgowym faktury. Rejestrowanie Zdarzenie jest rejestrowane, gdy użytkownik tworzy sprawę sporną za pomocą transakcji UDM_DISPUTE. Typ zdarzenia explicit | |||
| Wysłano przypomnienie o płatności | System wygenerował i wysłał do klienta wezwanie do zapłaty lub przypomnienie dotyczące przeterminowanej faktury. Zdarzenie jest rejestrowane w historii monitów. | ||
| Dlaczego to ważne Zdarzenie pomaga ocenić skuteczność strategii odzyskiwania należności. Analiza czasu od wysłania przypomnienia do otrzymania płatności jest ważna przy obliczaniu KPI skuteczności przypomnień o płatności. Skąd pobrać Zdarzenie jest rejestrowane w tabelach danych dotyczących monitów, w szczególności MHNK (nagłówki danych monitów) i MHND (pozycje danych monitów), generowanych podczas przebiegu monitów (transakcja F150). Rejestrowanie Zdarzenie jest rejestrowane po wykonaniu przebiegu monitów (F150) dla przeterminowanej pozycji. Typ zdarzenia explicit | |||
| Zaakceptowano fakturę | Oznacza formalną akceptację faktury, która umożliwia jej zaksięgowanie lub wysłanie do klienta. Zdarzenie jest często wnioskowane na podstawie przekształcenia dokumentu zapisanego wstępnie w dokument zaksięgowany. | ||
| Dlaczego to ważne Zdarzenie pozwala śledzić wewnętrzny workflow akceptacji, w którym często występują wąskie gardła. Analiza tej czynności wspiera dashboard analizy obiegu akceptacji faktur i pomaga wskazać osoby, które opóźniają akceptację. Skąd pobrać Zdarzenie można wywnioskować ze zmiany statusu dokumentu z wstępnego (w VBKPF) na zaksięgowany (w BKPF). Jeśli używany jest system workflow, może ono być też zapisane bezpośrednio w jego dziennikach. Rejestrowanie Porównaj datę utworzenia dokumentu wstępnego (VBKPF) z datą zaksięgowania dokumentu końcowego (BKPF). Typ zdarzenia inferred | |||
| Zapisano fakturę wstępnie | Dokument faktury został zapisany wstępnie, ale nie zaksięgowano go jeszcze w księdze głównej. Ten sposób zapisu stosuje się często, gdy brakuje informacji lub dokument wymaga sprawdzenia przed ostatecznym zaksięgowaniem. | ||
| Dlaczego to ważne Zdarzenie pozwala śledzić etapy przed zaksięgowaniem i wykrywać opóźnienia. Długi czas w statusie wstępnym może wskazywać na problemy z jakością danych lub wąskie gardła w procesie wstępnej akceptacji. Skąd pobrać Dokumenty zapisane wstępnie są przechowywane w tabeli VBKPF. Czynność oznacza utworzenie w niej dokumentu, który zostaje później zaksięgowany. Rejestrowanie Zdarzenie jest rejestrowane po zapisaniu dokumentu wstępnego za pomocą transakcji, takiej jak FV70. Typ zdarzenia explicit | |||
Instrukcje ekstrakcji danych
Kroki
- Otwórz edytor ABAP: Zaloguj się do systemu SAP ECC. Otwórz edytor ABAP za pomocą kodu transakcji
SE38. - Utwórz program: W polu Program wpisz nazwę nowego programu, na przykład
Z_PM_O2C_INVOICE_EXTRACT, i kliknij przycisk Create. Podaj opisowy tytuł i ustaw typ programu na „Executable Program”. - Zdefiniuj ekran wyboru: W kodzie źródłowym programu zdefiniuj parametry ekranu wyboru. Umożliwią one filtrowanie danych do ekstrakcji. Najważniejsze parametry to zakres dat utworzenia dokumentu (
S_ERDAT), kod firmy (S_BUKRS) i rodzaj dokumentu fakturowania (S_VBTYP). - Zdefiniuj struktury danych: Zadeklaruj strukturę tabeli wewnętrznej, która będzie przechowywać końcowe dane dziennika zdarzeń. Powinna zawierać pola
InvoiceNumber,ActivityName,EventTimeoraz zalecane atrybuty, takie jakUserName,BillingDocumentType,CustomerNumber,CompanyCodeiTotalInvoiceAmount. - Zaimplementuj logikę wyboru danych: Napisz podstawową logikę ABAP do wyboru danych. Najpierw wybierz główne dokumenty fakturowania z tabel
VBRKiBKPFna podstawie parametrów ekranu wyboru. Zapisz je w tymczasowej tabeli wewnętrznej. - Wyodrębnij czynności: Przejdź przez początkową listę dokumentów fakturowania. Dla każdego dokumentu wykonaj kolejne odczyty z różnych tabel, aby zidentyfikować 13 wymaganych czynności. Na przykład sprawdź tabelę
NASTpod kątem zdarzeń „Faktura wysłana do klienta”, tabelęBSEGw poszukiwaniu informacji o rozliczeniu („Faktura rozliczona”, „Płatność przypisana”), a tabelęMHNKw poszukiwaniu danych o monitach („Wysłano przypomnienie o płatności”). - Zbuduj tabelę dziennika zdarzeń: Dla każdej znalezionej czynności dodaj rekord do końcowej tabeli wewnętrznej dziennika zdarzeń. Upewnij się, że pola
InvoiceNumber,ActivityName,EventTimei pozostałe atrybuty są prawidłowo odwzorowane z tabel źródłowych. - Zapisz plik na serwerze aplikacyjnym: Po zakończeniu pętli i wypełnieniu końcowej tabeli dziennika zdarzeń użyj instrukcji
OPEN DATASET,LOOP AT... TRANSFERiCLOSE DATASET, aby zapisać jej zawartość w pliku tekstowym na serwerze aplikacyjnym SAP. Podaj dostępną ścieżkę pliku logicznego. - Pobierz plik: Użyj kodu transakcji
AL11, aby przejść do katalogów serwera aplikacyjnego i znaleźć wygenerowany plik. Uzgodnij z zespołem SAP Basis pobranie pliku na komputer lokalny lub do współdzielonej lokalizacji sieciowej. - Końcowe formatowanie: Otwórz pobrany plik i sprawdź, czy jest to plik CSV z wierszem nagłówkowym. Zapisz go w kodowaniu UTF-8, aby można go było przesłać do ProcessMind.
Konfiguracja
- Wymagania wstępne: Uprawnienia do tworzenia i uruchamiania programów ABAP (transakcja SE38). Uprawnienia do odczytu tabel FI i SD, w tym
VBRK,VBRP,BKPF,BSEG,NAST,MHNKiUDM_CASE_ATTR00(na potrzeby zarządzania sporami). - Wybór zakresu dat: Program powinien wymagać podania zakresu dat, zwykle na podstawie daty utworzenia dokumentu (
ERDATw VBRK/BKPF). Przy pierwszej ekstrakcji zaleca się zakres 3–6 miesięcy, aby zachować rozsądną wielkość zbioru danych. - Najważniejsze filtry: Zawsze filtruj dane według kodu firmy (
BUKRS), aby ograniczyć zakres ekstrakcji. Zaleca się również filtrowanie według rodzaju dokumentu fakturowania (VBTYPz VBRK) lub rodzaju dokumentu księgowego (BLARTz BKPF). Pozwoli to uwzględnić tylko potrzebne rodzaje faktur, na przykład „RV” dla standardowych faktur księgowych, i wykluczyć noty uznaniowe oraz inne dokumenty. - Wydajność: W przypadku dużych zbiorów danych obejmujących więcej niż kilka miesięcy program należy uruchamiać jako zadanie w tle, aby uniknąć przekroczenia limitu czasu sesji. Kod ABAP powinien korzystać z odczytów indeksowanych tabel i unikać zagnieżdżonych pętli, w których wykonywane są zapytania do bazy danych. Zaleca się najpierw wczytać dane do tabel wewnętrznych, a następnie je przetwarzać.
- Konfiguracja pliku wyjściowego: Kod ABAP musi określać ścieżkę pliku wyjściowego na serwerze aplikacyjnym oraz separator CSV, zwykle przecinek lub średnik. Ścieżka powinna wskazywać globalnie skonfigurowany i dostępny katalog.
Przykładowe zapytanie abap
REPORT Z_PM_O2C_INVOICE_EXTRACT.
*&---------------------------------------------------------------------*
*& Tables
*&---------------------------------------------------------------------*
TABLES: VBRK, BKPF.
*&---------------------------------------------------------------------*
*& Type Definitions for Event Log Output
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
invoicenumber TYPE vbrk-vbeln,
activityname TYPE string,
eventtime TYPE timestamp,
username TYPE xubname,
billingdocumenttype TYPE vbrk-vbtyp,
customernumber TYPE vbrk-kunnr,
companycode TYPE vbrk-bukrs,
totalinvoiceamount TYPE vbrk-netwr,
END OF ty_event_log.
*&---------------------------------------------------------------------*
*& Data Declarations
*&---------------------------------------------------------------------*
DATA: gt_event_log TYPE TABLE OF ty_event_log,
gs_event_log TYPE ty_event_log.
DATA: BEGIN OF gs_invoice,
vbeln TYPE vbrk-vbeln, " SD Doc (Invoice)
awkey TYPE bkpf-awkey, " Accounting Doc Reference Key
bukrs TYPE vbrk-bukrs, " Company Code
kunnr TYPE vbrk-kunnr, " Customer
vbtyp TYPE vbrk-vbtyp, " SD Doc Type
netwr TYPE vbrk-netwr, " Net Value
waerk TYPE vbrk-waerk, " Currency
fkdat TYPE vbrk-fkdat, " Billing Date
erdat TYPE vbrk-erdat, " Creation Date
erzet TYPE vbrk-erzet, " Creation Time
ernam TYPE vbrk-ernam, " Creator
belnr TYPE bkpf-belnr, " Acct Doc
gjahr TYPE bkpf-gjahr, " Fiscal Year
cpudt TYPE bkpf-cpudt, " Acct Doc Entry Date
cputm TYPE bkpf-cputm, " Acct Doc Entry Time
usnam TYPE bkpf-usnam, " Acct Doc User
stblg TYPE bkpf-stblg, " Reversal Doc
END OF gs_invoice.
DATA: gt_invoices LIKE TABLE OF gs_invoice.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_erdat FOR vbrk-erdat OBLIGATORY,
s_bukrs FOR vbrk-bukrs OBLIGATORY,
s_vbtyp FOR vbrk-vbtyp.
PARAMETERS: p_path TYPE string DEFAULT '/usr/sap/trans/tmp/invoice_extract.csv' OBLIGATORY.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
" 1. Select base set of invoices
SELECT vbrk~vbeln, vbrk~bukrs, vbrk~kunnr, vbrk~vbtyp, vbrk~netwr, vbrk~waerk,
vbrk~fkdat, vbrk~erdat, vbrk~erzet, vbrk~ernam,
bkpf~belnr, bkpf~gjahr, bkpf~cpudt, bkpf~cputm, bkpf~usnam, bkpf~stblg, bkpf~awkey
INTO CORRESPONDING FIELDS OF TABLE gt_invoices
FROM vbrk
INNER JOIN bkpf ON bkpf~awkey = vbrk~vbeln AND bkpf~awtyp = 'VBRK'
WHERE vbrk~erdat IN s_erdat
AND vbrk~bukrs IN s_bukrs
AND vbrk~vbtyp IN s_vbtyp.
IF gt_invoices IS INITIAL.
MESSAGE 'No invoices found for the selected criteria.' TYPE 'I'.
RETURN.
ENDIF.
LOOP AT gt_invoices INTO gs_invoice.
CLEAR gs_event_log.
gs_event_log-invoicenumber = gs_invoice-vbeln.
gs_event_log-billingdocumenttype = gs_invoice-vbtyp.
gs_event_log-customernumber = gs_invoice-kunnr.
gs_event_log-companycode = gs_invoice-bukrs.
gs_event_log-totalinvoiceamount = gs_invoice-netwr.
" Activity: Invoice Generated (using accounting doc creation)
gs_event_log-activityname = 'Invoice Generated'.
gs_event_log-username = gs_invoice-usnam.
CONCATENATE gs_invoice-cpudt gs_invoice-cputm INTO DATA(lv_ts_gen).
CONVERT DATE gs_invoice-cpudt TIME gs_invoice-cputm INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Posted (same as generated for non-parked docs)
gs_event_log-activityname = 'Invoice Posted'.
gs_event_log-username = gs_invoice-usnam.
CONVERT DATE gs_invoice-cpudt TIME gs_invoice-cputm INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Approved (inferred by posting)
gs_event_log-activityname = 'Invoice Approved'.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Sent To Customer
SELECT SINGLE addat, aduhr FROM nast
INTO (DATA(lv_nast_date), DATA(lv_nast_time))
WHERE kappl = 'V3' AND objky = gs_invoice-vbeln AND vszst > '0'.
IF sy-subrc = 0.
gs_event_log-activityname = 'Invoice Sent To Customer'.
gs_event_log-username = sy-uname.
CONVERT DATE lv_nast_date TIME lv_nast_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Invoice Corrected / Reversed
IF gs_invoice-stblg IS NOT INITIAL.
SELECT SINGLE cpudt, cputm, usnam FROM bkpf
INTO (DATA(lv_rev_date), DATA(lv_rev_time), DATA(lv_rev_user))
WHERE belnr = gs_invoice-stblg AND gjahr = gs_invoice-gjahr.
IF sy-subrc = 0.
gs_event_log-activityname = 'Invoice Corrected'.
gs_event_log-username = lv_rev_user.
CONVERT DATE lv_rev_date TIME lv_rev_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
" Activity: Payment Applied, Cleared, Due Date, Written Off (from BSEG)
SELECT SINGLE augdt, augbl, zfBDT, hkont FROM bseg
INTO (DATA(lv_augdt), DATA(lv_augbl), DATA(lv_zfbdt), DATA(lv_hkont))
WHERE bukrs = gs_invoice-bukrs
AND belnr = gs_invoice-belnr
AND gjahr = gs_invoice-gjahr
AND koart = 'D'. " Customer line
IF sy-subrc = 0.
" Due Date Reached (Calculated event)
IF lv_zfbdt IS NOT INITIAL.
gs_event_log-activityname = 'Invoice Due Date Reached'.
gs_event_log-username = 'System'.
CONVERT DATE lv_zfbdt INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Cleared, Applied, Write-Off
IF lv_augdt IS NOT INITIAL.
SELECT SINGLE usnam, cpudt, cputm, blart FROM bkpf
INTO (DATA(lv_clear_user), DATA(lv_clear_date), DATA(lv_clear_time), DATA(lv_clear_type))
WHERE belnr = lv_augbl AND bukrs = gs_invoice-bukrs.
IF sy-subrc = 0.
gs_event_log-username = lv_clear_user.
CONVERT DATE lv_clear_date TIME lv_clear_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
IF lv_clear_type = 'DZ'. " Standard Customer Payment
gs_event_log-activityname = 'Customer Payment Received'. APPEND gs_event_log TO gt_event_log.
gs_event_log-activityname = 'Payment Applied To Invoice'. APPEND gs_event_log TO gt_event_log.
gs_event_log-activityname = 'Invoice Cleared'. APPEND gs_event_log TO gt_event_log.
ELSE. " Assuming other clearing doc types could be write-offs
gs_event_log-activityname = 'Invoice Written Off'.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
ENDIF.
ENDIF.
" Activity: Payment Reminder Issued (Dunning)
SELECT COUNT(*) FROM mhnk WHERE kunnr = gs_invoice-kunnr AND bukrs = gs_invoice-bukrs AND lafdn > gs_invoice-cpudt.
IF sy-subrc = 0 AND sy-dbcnt > 0.
SELECT SINGLE lafdn FROM mhnk
INTO DATA(lv_dunning_date)
WHERE kunnr = gs_invoice-kunnr AND bukrs = gs_invoice-bukrs AND lafdn > gs_invoice-cpudt.
gs_event_log-activityname = 'Payment Reminder Issued'.
gs_event_log-username = 'System'.
CONVERT DATE lv_dunning_date INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Invoice Parked (Example from VBKPF, may require system specific logic)
SELECT SINGLE cpudt, cputm, usnam FROM vbkpf
INTO (DATA(lv_park_date), DATA(lv_park_time), DATA(lv_park_user))
WHERE awkey = gs_invoice-vbeln AND awsys = 'LOG' AND bstat = 'V'.
IF sy-subrc = 0.
gs_event_log-activityname = 'Invoice Parked'.
gs_event_log-username = lv_park_user.
CONVERT DATE lv_park_date TIME lv_park_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Dispute Case Created (Requires Dispute Management module)
SELECT SINGLE create_date, create_time, create_user FROM udm_case_attr00
INTO (DATA(lv_disp_date), DATA(lv_disp_time), DATA(lv_disp_user))
WHERE [Your logic to link invoice to dispute case, e.g., via a custom field or object link].
IF sy-subrc = 0.
gs_event_log-activityname = 'Dispute Case Created'.
gs_event_log-username = lv_disp_user.
CONVERT DATE lv_disp_date TIME lv_disp_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
*&---------------------------------------------------------------------*
*& Write data to file
*&---------------------------------------------------------------------*
OPEN DATASET p_path FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
ENDIF.
" Header
DATA(lv_header) = 'InvoiceNumber,ActivityName,EventTime,UserName,BillingDocumentType,CustomerNumber,CompanyCode,TotalInvoiceAmount'.
TRANSFER lv_header TO p_path.
LOOP AT gt_event_log INTO gs_event_log.
DATA(lv_line) = |
{ gs_event_log-invoicenumber }|
,{ gs_event_log-activityname }|
,{ gs_event_log-eventtime }|
,{ gs_event_log-username }|
,{ gs_event_log-billingdocumenttype }|
,{ gs_event_log-customernumber }|
,{ gs_event_log-companycode }|
,{ gs_event_log-totalinvoiceamount }|.
TRANSFER lv_line TO p_path.
ENDLOOP.
CLOSE DATASET p_path.
WRITE: 'Extraction complete. File created at:', p_path. Kroki
- Wymagania wstępne i dostęp: Upewnij się, że konto bazy danych ma uprawnienia tylko do odczytu wymaganych tabel SAP ECC, w tym VBRK, BKPF, BSAD, NAST, CDHDR, CDPOS, SCASE i innych wskazanych w zapytaniu. Takie uprawnienia zwykle otrzymują wyłącznie administratorzy systemu lub wyznaczone zespoły analityczne.
- Połącz się z bazą danych: Użyj standardowego klienta SQL, takiego jak DBeaver, Oracle SQL Developer lub Microsoft SQL Server Management Studio, aby połączyć się z bazą danych SAP ECC.
- Przygotuj zapytanie SQL: Skopiuj pełne zapytanie SQL z sekcji „query” do edytora klienta SQL.
- Uzupełnij symbole zastępcze: W zapytaniu znajduje się kilka symboli zastępczych, które należy zastąpić wartościami właściwymi dla danego środowiska. Są to:
'YYYYMMDD': Zastąp wszystkie wystąpienia datą początkową i końcową analizowanego okresu. Należy ograniczyć zakres danych do wielkości, którą można sprawnie przetworzyć.'XXXX': Wpisz kod lub kody firm, które mają zostać poddane analizie.[Your Invoice Output Type]: Podaj kod typu komunikatu wyjściowego używanego do wysyłania faktur klientom, na przykład „RD00”.[Your Bad Debt G/L Account]: Wpisz numer konta księgi głównej używanego do odpisywania nieściągalnych faktur.[Your Dispute Case Invoice Attribute]: Podaj nazwę atrybutu, w którym konfiguracja zarządzania sporami przechowuje numer faktury, na przykład „INVOICE_ID”.
- Sprawdź funkcje obsługi znaczników czasu: Zapytanie korzysta z ogólnej składni
CAST(CONCAT(date_field, time_field) AS TIMESTAMP). Może być konieczne dostosowanie jej do używanego systemu bazodanowego, na przykład zastosowanieTO_TIMESTAMPw Oracle lubDATETIMEFROMPARTSw SQL Server. - Uruchom zapytanie: Wykonaj zmodyfikowane zapytanie. Czas przetwarzania może być długi, zależnie od wielkości tabel SAP i wybranego zakresu dat.
- Sprawdź wyniki: Po zakończeniu zapytania sprawdź, czy wynik zawiera oczekiwane kolumny: InvoiceNumber, ActivityName, EventTime i zalecane atrybuty. Zwróć uwagę na błędy i pusty wynik.
- Eksportuj do CSV: Wyeksportuj cały zestaw wyników z klienta SQL do pliku CSV. Zapisz plik w kodowaniu UTF-8, aby uniknąć problemów ze znakami specjalnymi.
- Przygotuj plik do przesłania: Przed przesłaniem danych do narzędzia process mining sprawdź, czy nagłówki kolumn CSV dokładnie odpowiadają wymaganym nazwom atrybutów, na przykład
InvoiceNumber,ActivityName,EventTime,UserName.
Konfiguracja
- Połączenie z bazą danych: Wymagane jest bezpośrednie połączenie SQL tylko do odczytu z bazą danych SAP ECC. Ta metoda całkowicie pomija warstwę aplikacyjną SAP.
- Uprawnienia: Konto bazy danych musi mieć uprawnienia
SELECTdo wszystkich tabel używanych w zapytaniu, obejmujących moduły FI, SD i potencjalnie FSCM. - Zakres dat: Aby zapewnić odpowiednią wydajność i ograniczyć ilość danych, zapytanie musi uwzględniać konkretny zakres dat. Na początek zaleca się okres od 3 do 6 miesięcy. Symbole zastępcze daty
'YYYYMMDD'należy ustawić w kilku miejscach zapytania. - Filtr kodu firmy: Zapytanie należy filtrować według kodu firmy (
BUKRS). Standardową praktyką jest analiza jednego lub kilku kodów firmy naraz. - Konfiguracja typów dokumentów: Sposób identyfikacji zdarzeń, takich jak korekty faktur, odpisy lub wysłane dokumenty, zależy od standardowej konfiguracji SAP. Jeśli organizacja używa niestandardowych typów dokumentów (
BLART), typów komunikatów wyjściowych (KSCHL) lub kont księgi głównej, może być konieczne dostosowanie zapytania. - Wydajność: Wykonanie tego zapytania w działającym systemie produkcyjnym SAP może zużywać znaczne zasoby i wpływać na wydajność operacyjną. Duże ekstrakcje najlepiej uruchamiać poza godzinami szczytu lub na dedykowanej replice raportowej bazy danych.
Przykładowe zapytanie sql
WITH InvoiceBase AS (
SELECT
VBRK.VBELN AS InvoiceNumber,
VBRK.FKART AS BillingDocumentType,
VBRK.KUNRG AS CustomerNumber,
VBRK.BUKRS AS CompanyCode,
VBRK.NETWR AS TotalInvoiceAmount,
VBRK.ERNAM AS CreatorName,
VBRK.ERDAT AS CreationDate,
VBRK.ERZET AS CreationTime
FROM VBRK
WHERE VBRK.ERDAT BETWEEN '20230101' AND '20231231' -- Filter by Invoice Creation Date
AND VBRK.BUKRS IN ('1000') -- Filter by Company Code
AND VBRK.FKART NOT IN ('S1', 'S2') -- Exclude cancelled invoices
)
-- 1. Invoice Generated
SELECT
ib.InvoiceNumber,
'Invoice Generated' AS ActivityName,
CAST(CONCAT(ib.CreationDate, ib.CreationTime) AS TIMESTAMP) AS EventTime,
ib.CreatorName AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM InvoiceBase ib
UNION ALL
-- 2. Invoice Parked
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Parked' AS ActivityName,
CAST(CONCAT(b.CPUDT, b.CPUTM) AS TIMESTAMP) AS EventTime,
b.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
b.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BKPF b
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE b.AWTYP = 'VBRK' AND b.BSTAT = 'V' AND b.CPUDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 3. Invoice Posted
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Posted' AS ActivityName,
CAST(CONCAT(b.CPUDT, b.CPUTM) AS TIMESTAMP) AS EventTime,
b.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
b.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BKPF b
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE b.AWTYP = 'VBRK' AND b.BSTAT = '' AND b.CPUDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 4. Invoice Approved (from Parked to Posted)
SELECT
SUBSTRING(h.OBJECTID, 4, 10) AS InvoiceNumber,
'Invoice Approved' as ActivityName,
CAST(CONCAT(h.UDATE, h.UTIME) AS TIMESTAMP) AS EventTime,
h.USERNAME AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM CDHDR h
JOIN CDPOS p ON h.MANDANT = p.MANDANT AND h.OBJECTCLAS = p.OBJECTCLAS AND h.OBJECTID = p.OBJECTID AND h.CHANGENR = p.CHANGENR
JOIN InvoiceBase ib ON SUBSTRING(h.OBJECTID, 4, 10) = ib.InvoiceNumber
WHERE h.OBJECTCLAS = 'BELEGV'
AND p.TABNAME = 'BKPF'
AND p.FNAME = 'BSTAT'
AND p.VALUE_OLD = 'V'
AND p.VALUE_NEW = ' '
AND h.UDATE BETWEEN '20230101' AND '20231231'
UNION ALL
-- 5. Invoice Sent To Customer
SELECT
n.OBJKY AS InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
CAST(CONCAT(n.DATVR, n.UHRVR) AS TIMESTAMP) AS EventTime,
n.VSTAT AS UserName, -- User who processed is not directly available, using processing status as a proxy
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM NAST n
JOIN InvoiceBase ib ON n.OBJKY = ib.InvoiceNumber
WHERE n.KSCHL = '[Your Invoice Output Type]' -- E.g., 'RD00'
AND n.VSTAT = '1' -- Processed successfully
AND n.DATVR BETWEEN '20230101' AND '20231231'
UNION ALL
-- 6. Invoice Corrected (Reversed)
SELECT
SUBSTRING(orig_doc.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Corrected' AS ActivityName,
CAST(CONCAT(rev_doc.CPUDT, rev_doc.CPUTM) AS TIMESTAMP) AS EventTime,
rev_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
rev_doc.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BKPF orig_doc
JOIN BKPF rev_doc ON orig_doc.STBLG = rev_doc.BELNR AND orig_doc.BUKRS = rev_doc.BUKRS AND orig_doc.GJAHR = rev_doc.STJAH
JOIN InvoiceBase ib ON SUBSTRING(orig_doc.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE orig_doc.AWTYP = 'VBRK' AND orig_doc.STBLG IS NOT NULL AND rev_doc.CPUDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 7. Invoice Due Date Reached
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Due Date Reached' AS ActivityName,
CAST(CONCAT(bs.ZFBDT, '000000') AS TIMESTAMP) AS EventTime,
'System' AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
b.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSEG bs
JOIN BKPF b ON bs.MANDT = b.MANDT AND bs.BUKRS = b.BUKRS AND bs.BELNR = b.BELNR AND bs.GJAHR = b.GJAHR
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE b.AWTYP = 'VBRK' AND bs.KOART = 'D' AND bs.ZFBDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 8. Payment Reminder Issued
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(CONCAT(h.LAUFD, '000000') AS TIMESTAMP) AS EventTime,
h.LAUFI AS UserName, -- Dunning Run ID
ib.BillingDocumentType,
ib.CustomerNumber,
d.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM MHND d
JOIN MHNK h ON d.MANDT = h.MANDT AND d.LAUFD = h.LAUFD AND d.LAUFI = h.LAUFI
JOIN BKPF b ON d.MANDT = b.MANDT AND d.BUKRS = b.BUKRS AND d.BELNR = b.BELNR AND d.GJAHR = b.GJAHR
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE h.LAUFD BETWEEN '20230101' AND '20231231'
UNION ALL
-- 9. Dispute Case Created
SELECT
attr.ATTR_VALUE AS InvoiceNumber,
'Dispute Case Created' AS ActivityName,
sc.CREATE_TIME AS EventTime,
sc.CREATED_BY AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM SCMG_T_CASE_ATTR attr
JOIN SCASE sc ON attr.CASE_GUID = sc.CASE_GUID
JOIN InvoiceBase ib ON attr.ATTR_VALUE = ib.InvoiceNumber
WHERE attr.ATTR_NAME = '[Your Dispute Case Invoice Attribute]' -- e.g., 'INVOICE_ID'
AND CAST(sc.CREATE_TIME AS DATE) BETWEEN '20230101' AND '20231231'
UNION ALL
-- 10, 11, 12. Clearing Events (Payment, Clearing, Write-Off)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
BillingDocumentType,
CustomerNumber,
CompanyCode,
TotalInvoiceAmount
FROM (
SELECT
bsad.XBLNR AS InvoiceNumber,
CASE
WHEN clearing_item.HKONT = '[Your Bad Debt G/L Account]' THEN 'Invoice Written Off'
ELSE 'Customer Payment Received'
END AS ActivityName,
CAST(CONCAT(clearing_doc.CPUDT, clearing_doc.CPUTM) AS TIMESTAMP) AS EventTime,
clearing_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
bsad.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSAD bsad
JOIN InvoiceBase ib ON bsad.XBLNR = ib.InvoiceNumber
JOIN BKPF clearing_doc ON bsad.MANDT = clearing_doc.MANDT AND bsad.BUKRS = clearing_doc.BUKRS AND bsad.AUGBL = clearing_doc.BELNR AND bsad.AUGGJ = clearing_doc.GJAHR
LEFT JOIN BSEG clearing_item ON clearing_doc.MANDT = clearing_item.MANDT AND clearing_doc.BUKRS = clearing_item.BUKRS AND clearing_doc.BELNR = clearing_item.BELNR AND clearing_doc.GJAHR = clearing_item.GJAHR AND clearing_item.HKONT = '[Your Bad Debt G/L Account]' -- e.g. '148000'
WHERE bsad.AUGDT BETWEEN '20230101' AND '20231231' AND bsad.UMSKZ = ''
UNION ALL
SELECT
bsad.XBLNR AS InvoiceNumber,
'Payment Applied To Invoice' AS ActivityName,
CAST(CONCAT(bsad.AUGDT, '000000') AS TIMESTAMP) AS EventTime,
clearing_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
bsad.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSAD bsad
JOIN InvoiceBase ib ON bsad.XBLNR = ib.InvoiceNumber
JOIN BKPF clearing_doc ON bsad.MANDT = clearing_doc.MANDT AND bsad.BUKRS = clearing_doc.BUKRS AND bsad.AUGBL = clearing_doc.BELNR AND bsad.AUGGJ = clearing_doc.GJAHR
WHERE bsad.AUGDT BETWEEN '20230101' AND '20231231' AND bsad.UMSKZ = ''
UNION ALL
SELECT
bsad.XBLNR AS InvoiceNumber,
'Invoice Cleared' AS ActivityName,
CAST(CONCAT(bsad.AUGDT, '235959') AS TIMESTAMP) AS EventTime, -- Add time to separate from 'Payment Applied'
clearing_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
bsad.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSAD bsad
JOIN InvoiceBase ib ON bsad.XBLNR = ib.InvoiceNumber
JOIN BKPF clearing_doc ON bsad.MANDT = clearing_doc.MANDT AND bsad.BUKRS = clearing_doc.BUKRS AND bsad.AUGBL = clearing_doc.BELNR AND bsad.AUGGJ = clearing_doc.GJAHR
WHERE bsad.AUGDT BETWEEN '20230101' AND '20231231' AND bsad.UMSKZ = ''
) AS ClearingEvents Kroki
- Wymagania wstępne: Upewnij się, że masz licencję na narzędzie ETL z certyfikowanym konektorem SAP, na przykład Informatica PowerCenter z SAP Connector lub Talend z SAP Connector. Sprawdź, czy masz dane logowania użytkownika SAP z uprawnieniami do odczytu wymaganych tabel finansowych, sprzedażowych i systemowych: BKPF, BSEG, VBRK, NAST, MHNK, UDM_CASE_ATTR00, CDHDR, CDPOS.
- Nawiąż połączenie z SAP: W narzędziu ETL utwórz nowe połączenie z systemem SAP ECC. Skonfiguruj serwer aplikacyjny, numer systemu, klienta, użytkownika i hasło. Przetestuj połączenie.
- Zdefiniuj źródła danych: Dla każdej wyodrębnianej czynności określ odpowiednie tabele SAP jako źródła danych w zadaniu ETL. Na przykład dodaj VBRK dla wystawiania faktur, BKPF dla zdarzeń księgowania i NAST dla komunikacji z klientem.
- Przygotuj logikę ekstrakcji dla każdej czynności: Utwórz osobny przepływ danych lub transformację dla każdej z 13 wymaganych czynności. W każdym przepływie zastosuj filtry wybierające odpowiednie rekordy. Można na przykład filtrować według kodu firmy (BUKRS), rodzaju dokumentu (BLART) i określonego zakresu dat, na przykład daty utworzenia ERDAT.
- Odwzoruj pola i przekształć dane: W każdym przepływie danych odwzoruj pola z tabel źródłowych na strukturę dziennika zdarzeń: InvoiceNumber, ActivityName, EventTime, UserName i inne zalecane atrybuty. Ustaw wartość „ActivityName” osobno dla każdego przepływu i odpowiednio sformatuj daty oraz znaczniki czasu.
- Obsłuż złożone czynności: W przypadku zdarzeń wyliczanych, takich jak „Nadszedł termin płatności faktury”, użyj bazowej daty płatności (ZFBDT) i warunków płatności do obliczenia terminu albo pobierz bezpośrednio termin płatności netto (NETDT) z BSEG. Przy zdarzeniach wyznaczanych na podstawie dzienników zmian, takich jak „Zatwierdzono fakturę”, może być konieczne połączenie tabel BKPF i CDHDR/CDPOS według numeru i daty dokumentu.
- Połącz dane o czynnościach: Użyj transformacji „Union” lub „Merge” w narzędziu ETL, aby połączyć wyniki wszystkich 13 przepływów danych w jeden zbiór. Przed połączeniem upewnij się, że nazwy kolumn i typy danych są spójne.
- Skonfiguruj miejsce docelowe: Określ miejsce zapisu końcowego dziennika zdarzeń. Może to być plik CSV, tabela bazy danych lub bezpośrednie połączenie z obszarem przejściowym.
- Ustaw harmonogram ekstrakcji: Skonfiguruj parametry zakresu dat. Przy pierwszym wczytaniu można pobrać dane z 6–12 miesięcy. Przy kolejnych przyrostowych wczytaniach ustaw ekstrakcję danych od daty ostatniego uruchomienia.
- Uruchom zadanie i wyeksportuj dane: Uruchom zadanie ETL. Po jego zakończeniu sprawdź, czy plik wynikowy ma wymagany format. Końcowy plik CSV powinien zawierać jeden wiersz dla każdego zdarzenia i być gotowy do przesłania do ProcessMind.
Konfiguracja
- Połączenie z SAP: Wymagane jest połączenie z serwerem aplikacyjnym docelowego systemu SAP ECC. Użytkownik SAP musi mieć dostęp RFC i uprawnienia do tabel takich jak VBRK, BKPF, BSEG, NAST oraz innych wskazanych w zapytaniu.
- Licencja na narzędzie ETL: Wymagana jest ważna licencja na komercyjne narzędzie ETL i jego konektor SAP.
- Zakres dat: Zaleca się ekstrakcję danych z okresu od 3 do 6 miesięcy. Pozwoli to uzyskać reprezentatywną próbkę bez nadmiernego obciążania systemu. Użyj konfigurowalnych parametrów daty początkowej i końcowej.
- Najważniejsze filtry: Zawsze filtruj dane według kodu firmy (BUKRS), aby ograniczyć zakres ekstrakcji. Należy również filtrować według odpowiednich rodzajów dokumentów fakturowania (VBRK-FKART) i dokumentów księgowych (BKPF-BLART), aby uwzględnić standardowe faktury, a wykluczyć inne dokumenty, takie jak noty uznaniowe lub dokumenty wewnętrzne.
- Wydajność: Ekstrakcja danych z dużych tabel, takich jak BSEG, może trwać długo. Stosuj selektywne filtry, pomijaj niepotrzebne pola i planuj ekstrakcję poza godzinami szczytu, aby ograniczyć wpływ na wydajność systemu SAP.
Przykładowe zapytanie config
// ETL Data Extraction Logic for SAP Order-to-Cash Invoicing
// This represents the configuration logic within a graphical ETL tool.
// == Global Parameters ==
// $StartDate: '[Start Date]' (e.g., '2023-01-01')
// $EndDate: '[End Date]' (e.g., '2023-06-30')
// $CompanyCodes: '[Company Code(s)]' (e.g., '1000', '2000')
// $BillingDocTypes: '[Billing Document Type(s)]' (e.g., 'F1', 'F2')
// == Source 1: Invoice Generated ==
// Tables: VBRK
DATA_SOURCE generated_invoices FROM VBRK WHERE
ERDAT >= $StartDate AND ERDAT <= $EndDate
AND BUKRS IN ($CompanyCodes)
AND FKART IN ($BillingDocTypes)
MAP {
InvoiceNumber: VBELN,
ActivityName: 'Invoice Generated',
EventTime: ERDAT + ERZET, // Combine date and time
UserName: ERNAM,
BillingDocumentType: FKART,
CustomerNumber: KUNAG,
CompanyCode: BUKRS,
TotalInvoiceAmount: NETWR
}
// == Source 2: Invoice Posted ==
// Tables: BKPF joined with VBRK
DATA_SOURCE posted_invoices FROM BKPF as A
INNER JOIN VBRK as B ON (A.AWKEY = B.VBELN AND A.AWTYP = 'VBRK')
WHERE A.BUDAT >= $StartDate AND A.BUDAT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.BSTAT = ' '
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Posted',
EventTime: A.BUDAT + A.CPUTM, // Posting date and entry time
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 3: Invoice Parked ==
// Tables: BKPF joined with VBRK
DATA_SOURCE parked_invoices FROM BKPF as A
INNER JOIN VBRK as B ON (A.AWKEY = B.VBELN AND A.AWTYP = 'VBRK')
WHERE A.CPUDT >= $StartDate AND A.CPUDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.BSTAT = 'V'
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Parked',
EventTime: A.CPUDT + A.CPUTM,
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 4: Invoice Approved (Transition from Parked to Posted) ==
// Tables: BKPF joined with VBRK
DATA_SOURCE approved_invoices FROM BKPF as A
INNER JOIN VBRK as B ON (A.AWKEY = B.VBELN AND A.AWTYP = 'VBRK')
WHERE A.BUDAT >= $StartDate AND A.BUDAT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.BSTAT = ' '
AND EXISTS (SELECT 1 FROM VBELEGV C WHERE C.BELNR = A.BELNR) // Check if it was ever parked
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Approved',
EventTime: A.BUDAT + A.CPUTM, // Use posting date as approval date
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 5: Invoice Sent To Customer ==
// Tables: NAST joined with VBRK
DATA_SOURCE sent_invoices FROM NAST as A
INNER JOIN VBRK as B ON (A.OBJKY = B.VBELN)
WHERE A.ERDAT >= $StartDate AND A.ERDAT <= $EndDate
AND B.BUKRS IN ($CompanyCodes)
AND A.VSTAT = '1' // Successfully processed
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Sent To Customer',
EventTime: A.ERDAT + A.ERUHR,
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: B.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 6: Invoice Corrected (Reversed) ==
// Tables: VBRK (for the reversal document)
DATA_SOURCE corrected_invoices FROM VBRK as A
WHERE A.ERDAT >= $StartDate AND A.ERDAT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.SFAKN <> '' // SFAKN is the original cancelled invoice
MAP {
InvoiceNumber: A.SFAKN, // Case ID is the original invoice
ActivityName: 'Invoice Corrected',
EventTime: A.ERDAT + A.ERZET,
UserName: A.ERNAM,
BillingDocumentType: A.FKART,
CustomerNumber: A.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: NULL // Amount belongs to the reversal doc, not original
}
// == Source 7: Invoice Due Date Reached ==
// Tables: BSEG joined with VBRK
DATA_SOURCE due_invoices FROM BSEG as A
INNER JOIN BKPF as H ON (A.BUKRS = H.BUKRS AND A.BELNR = H.BELNR AND A.GJAHR = H.GJAHR)
INNER JOIN VBRK as B ON (H.AWKEY = B.VBELN AND H.AWTYP = 'VBRK')
WHERE A.NETDT >= $StartDate AND A.NETDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.KOART = 'D' // Customer line item
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Due Date Reached',
EventTime: A.NETDT, // Net due date
UserName: 'System',
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 8: Payment Reminder Issued ==
// Tables: MHNK, MHND, VBRK
DATA_SOURCE reminders FROM MHNK as A
INNER JOIN MHND as D ON (A.LAUFD = D.LAUFD AND A.LAUFI = D.LAUFI)
INNER JOIN VBRK as B ON (SUBSTRING(D.XBLNR, 1, 10) = B.VBELN) // XBLNR may need parsing
WHERE A.LAUFD >= $StartDate AND A.LAUFD <= $EndDate
AND D.BUKRS IN ($CompanyCodes)
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Payment Reminder Issued',
EventTime: A.LAUFD, // Dunning date
UserName: A.IDAPS,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: D.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 9: Dispute Case Created ==
// Tables: UDM_CASE_ATTR00
DATA_SOURCE disputes FROM UDM_CASE_ATTR00 as A
WHERE A.CREATE_TIMESTAMP >= $StartDate // Timestamp format may vary
AND A.FIN_COMP_CODE IN ($CompanyCodes)
AND A.PROCESS = 'FIN_FSCM_DIS'
MAP {
InvoiceNumber: A.BILL_DOC_ID,
ActivityName: 'Dispute Case Created',
EventTime: A.CREATE_TIMESTAMP,
UserName: A.CREATE_USER,
BillingDocumentType: NULL,
CustomerNumber: A.BP_NUMBER,
CompanyCode: A.FIN_COMP_CODE,
TotalInvoiceAmount: A.DISPUTED_AMOUNT
}
// == Source 10: Customer Payment Received ==
// Tables: BKPF
DATA_SOURCE payments FROM BKPF
WHERE BUDAT >= $StartDate AND BUDAT <= $EndDate
AND BUKRS IN ($CompanyCodes)
AND BLART = 'DZ' // Example for Customer Payment
MAP {
InvoiceNumber: NULL, // Invoice not yet known
ActivityName: 'Customer Payment Received',
EventTime: BUDAT + CPUTM,
UserName: USNAM,
BillingDocumentType: NULL,
CustomerNumber: NULL, // Requires join to BSEG to get customer
CompanyCode: BUKRS,
TotalInvoiceAmount: NULL
}
// == Source 11 & 12: Payment Applied To Invoice & Invoice Cleared ==
// Tables: BSEG joined with VBRK
DATA_SOURCE cleared_items FROM BSEG as A
INNER JOIN BKPF as H ON (A.BUKRS = H.BUKRS AND A.BELNR = H.BELNR AND A.GJAHR = H.GJAHR)
INNER JOIN VBRK as B ON (H.AWKEY = B.VBELN AND H.AWTYP = 'VBRK')
WHERE A.AUGDT >= $StartDate AND A.AUGDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.AUGBL <> ''
// Generate two records from this source
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Payment Applied To Invoice',
EventTime: A.AUGDT, // Clearing Date
UserName: H.USNAM, // User from header of original invoice doc
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
UNION WITH {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Cleared',
EventTime: A.AUGDT, // Clearing Date
UserName: H.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 13: Invoice Written Off ==
// Tables: BSEG (for the invoice line) and BKPF (for clearing doc type)
DATA_SOURCE written_off FROM BSEG as A
INNER JOIN BKPF as H ON (A.BUKRS = H.BUKRS AND A.BELNR = H.BELNR AND A.GJAHR = H.GJAHR)
INNER JOIN VBRK as B ON (H.AWKEY = B.VBELN AND H.AWTYP = 'VBRK')
INNER JOIN BKPF as C ON (A.AUGBL = C.BELNR AND A.BUKRS = C.BUKRS AND A.AUGGJ = C.GJAHR)
WHERE A.AUGDT >= $StartDate AND A.AUGDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND C.BLART = '[Your Write-Off Document Type]' // e.g., 'AB'
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Written Off',
EventTime: A.AUGDT,
UserName: C.USNAM, // User who posted the write-off
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Final Union of all sources ==
OUTPUT generated_invoices
UNION ALL posted_invoices
UNION ALL parked_invoices
UNION ALL approved_invoices
UNION ALL sent_invoices
UNION ALL corrected_invoices
UNION ALL due_invoices
UNION ALL reminders
UNION ALL disputes
UNION ALL payments
UNION ALL cleared_items
UNION ALL written_off Gotowi do rozpoczęcia?
Skorzystaj z tego szablonu, aby usprawnić przygotowanie danych i lepiej poznać proces wystawiania faktur. Rozpocznij analizę, która pomoże przyspieszyć wpływ należności.
Przyspiesz przepływ środków: usprawnij fakturowanie już dziś!
Ogranicz nieefektywności, skróć czas realizacji procesu o 30% i popraw przepływy pieniężne.
Nie trzeba podawać danych karty płatniczej. Pierwsze usprawnienia można rozpocząć w kilka minut.