Szablon danych do analizy procesu obsługi faktur w procesie zakupów do płatności
Szablon danych do analizy procesu obsługi faktur w procesie zakupów do płatności
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia
- Wskazówki dotyczące pobierania danych z SAP ECC
Atrybuty procesu obsługi faktur w procesie zakupów do płatności
| Nazwa | Opis | ||
|---|---|---|---|
| Czas zdarzenia EventTime | Dokładny znacznik czasu, obejmujący datę i godzinę wystąpienia czynności. | ||
| Opis Czas zdarzenia wskazuje dokładny moment wykonania czynności biznesowej i jej zarejestrowania w systemie źródłowym. Ten znacznik czasu porządkuje wszystkie czynności dotyczące każdej faktury w spójną sekwencję. W analizie czas zdarzenia jest niezbędny do obliczania wskaźników opartych na czasie, takich jak czas cyklu, czas oczekiwania i czas obsługi między czynnościami. Zasila dashboardy, takie jak „Całkowity czas obsługi faktury” i „Czas usuwania blokady płatności”, dostarczając danych potrzebnych do pomiaru czasu między dowolnymi etapami procesu. Dokładne znaczniki czasu pomagają wykrywać opóźnienia i wąskie gardła. Dlaczego to ważne Ten znacznik czasu jest niezbędny do prawidłowego uporządkowania zdarzeń i obliczania wskaźników, takich jak czas cyklu i czas trwania wąskich gardeł. Skąd pobrać Zazwyczaj wyznacza się go, łącząc datę zmiany (UDATE) i godzinę zmiany (UTIME) z tabeli nagłówków dokumentów zmian CDHDR. W przypadku niektórych zdarzeń utworzenia można użyć daty i godziny utworzenia z tabel takich jak RBKP (ERNAM, ERZET). Przykłady 2023-03-15T10:30:00Z2023-03-16T14:05:21Z2023-03-28T09:00:00Z | |||
| Czynność Activity | Nazwa konkretnego kroku lub zdarzenia biznesowego w cyklu obsługi faktury. | ||
| Opis Atrybut czynności oznacza odrębny etap lub działanie w workflow obsługi faktury. Czynności są wyznaczane na podstawie różnych zdarzeń systemowych, takich jak utworzenie dokumentu, zmiana statusu, akceptacja lub działania użytkowników zapisane w dziennikach zmian SAP. Analiza czynności stanowi podstawę process mining. Pozwala wizualizować mapy procesów, wykrywać wąskie gardła, na przykład długie oczekiwanie po przekazaniu faktury do akceptacji, pętle poprawek, takie jak wielokrotne ustawianie i usuwanie blokady płatności, oraz odstępstwa od zasad zgodności. Kolejność i częstotliwość czynności pokazują rzeczywisty przebieg procesu. Dlaczego to ważne Określa kroki na mapie procesu, umożliwiając wizualizację przebiegu, wykrywanie wąskich gardeł i identyfikację poprawek. Skąd pobrać Atrybut ten jest zwykle wyznaczany na podstawie wielu źródeł, w tym kodów transakcji (SY-TCODE), pól statusu w tabelach takich jak RBKP (np. RBSTAT) oraz zdarzeń zmian z tabel CDHDR i CDPOS. Przykłady Wstępne wprowadzenie fakturyPrzekazanie faktury do akceptacjiAkceptacja fakturyZaksięgowanie fakturyRozliczenie faktury | |||
| Numer faktury InvoiceNumber | Unikalny identyfikator dokumentu faktury od dostawcy. | ||
| Opis Numer faktury jest unikalnym identyfikatorem sprawy w procesie obsługi faktury. Każdy numer odpowiada jednej fakturze otrzymanej od dostawcy i pozwala śledzić wszystkie powiązane czynności, od rejestracji danych po końcową płatność, jako jeden przebieg procesu. W analizie process mining ten atrybut jest podstawą odtworzenia pełnego cyklu życia każdej faktury. Pozwala połączyć w chronologiczną sekwencję różne zdarzenia zarejestrowane w SAP, takie jak wstępne wprowadzenie, księgowanie, blokada i rozliczenie. Dzięki temu widać, jak obsługiwano każdą fakturę, ile to trwało i gdzie proces odbiegał od standardowego przebiegu. Dlaczego to ważne To główny identyfikator łączący wszystkie zdarzenia dotyczące jednej faktury. Stanowi podstawę analizy procesu i badania jego wariantów. Skąd pobrać Zazwyczaj jest to numer dokumentu z tabeli SAP RBKP, pole BELNR, często połączony z kodem spółki (BUKRS) i rokiem obrotowym (GJAHR), aby zapewnić pełną unikalność. Przykłady 510004567851000456795100045680 | |||
| Data księgowania PostingDate | Data oficjalnego zaksięgowania faktury w księgach finansowych. | ||
| Opis Data księgowania wyznacza okres obrachunkowy, w którym koszt faktury jest ujmowany w księdze głównej. Zazwyczaj ustala ją pracownik działu zobowiązań podczas obsługi faktury. W analizie procesów aktywność „Zaksięgowanie faktury”, oznaczona tą datą, stanowi ważny punkt procesu. Czas od otrzymania faktury do jej zaksięgowania jest istotną częścią całkowitego czasu obsługi. Data ta ma również podstawowe znaczenie dla raportowania finansowego i analizy przepustowości, na przykład przy śledzeniu liczby faktur zaksięgowanych w tygodniu lub miesiącu. Dlaczego to ważne Wyznacza ważny etap procesu, określa okres finansowy transakcji i służy do obliczania czasu realizacji. Skąd pobrać To pole „Posting Date” (BUDAT) z tabeli nagłówka dokumentu faktury RBKP. Przykłady 2023-03-202023-04-052023-04-11 | |||
| Data rozliczenia ClearingDate | Data dokonania płatności i rozliczenia faktury w księgach zobowiązań. | ||
| Opis Data rozliczenia oznacza ostatni etap cyklu życia faktury, czyli płatność. Jest to dzień, w którym otwarta pozycja faktury zostaje rozliczona dokumentem płatności w systemie. Data ta wskazuje faktyczny moment realizacji płatności. Atrybut ten wyznacza koniec okresu mierzonego przez wiele istotnych KPI, w tym „Średni czas obsługi faktury” i „Odsetek płatności terminowych”. Porównuje się go z terminem płatności, aby ocenić terminowość. W analizie rabatów za wcześniejszą płatność zestawia się go z okresem rabatowym, aby sprawdzić, czy płatność nastąpiła na czas i pozwoliła uzyskać rabat. Dlaczego to ważne Oznacza zakończenie procesu i stanowi podstawę do obliczania całkowitego czasu realizacji, terminowości płatności oraz wykorzystania rabatów za wcześniejszą płatność. Skąd pobrać Dla rozliczonych pozycji jest to pole „Clearing Date” (AUGDT) z tabeli rozliczonych pozycji dostawców BSAK. Przykłady 2023-04-152023-05-022023-05-20 | |||
| Kwota faktury InvoiceAmount | Łączna kwota brutto faktury w walucie oryginalnego dokumentu. | ||
| Opis Kwota faktury oznacza łączną wartość faktury przesłanej przez dostawcę. Jest to ważny wskaźnik finansowy dla każdej sprawy dotyczącej faktury. W process mining atrybut ten jest niezbędny do analizy wartości. Pozwala filtrować i dzielić proces według kwoty faktury, która często wiąże się ze złożonością procesu i wymaganiami dotyczącymi akceptacji. Na przykład faktury o wysokiej wartości mogą podlegać innej, bardziej rygorystycznej ścieżce akceptacji. Atrybut ten służy też do analizy zgodności, na przykład do sprawdzania, czy faktury o wysokiej wartości nie pomijają wymaganych etapów akceptacji. Dlaczego to ważne Umożliwia analizę według wartości, pomaga ustalać priorytety dla faktur o wysokiej kwocie i sprawdzać, jak kwota faktury wpływa na przebieg procesu i zgodność. Skąd pobrać Jest to pole „Kwota brutto faktury” (RMWWR) z tabeli nagłówków dokumentów faktur RBKP. Przykłady 1500.7512500.00850.20 | |||
| Nazwa użytkownika UserName | Identyfikator użytkownika SAP, który wykonał daną czynność. | ||
| Opis Atrybut nazwy użytkownika wskazuje konkretną osobę odpowiedzialną za wykonanie danej czynności w procesie. Zwykle jest to nazwa użytkownika SAP zapisana przy transakcji lub zdarzeniu zmiany. Atrybut ten jest ważny przy analizie wyników pracy poszczególnych osób i zespołów. Pomaga odpowiedzieć na pytania: „Kto najszybciej akceptuje faktury?” lub „Którzy użytkownicy najczęściej powodują poprawki?”. Dashboardy wykorzystują go do analizy rozkładu obciążenia, wykrywania potrzeb szkoleniowych i porównywania wyników pracy. Dlaczego to ważne Umożliwia analizę wyników pracy i obciążenia poszczególnych osób lub zespołów oraz pomaga wskazać osoby osiągające najlepsze wyniki, potrzeby szkoleniowe i nierównomierne wykorzystanie zasobów. Skąd pobrać Jest to pole „Zmienione przez” (USERNAME) z tabeli nagłówków dokumentów zmian CDHDR. W przypadku zdarzeń utworzenia może to być pole „Wprowadził” (ERNAM) w tabelach takich jak RBKP. Przykłady JSMITHBWILSONCHEN | |||
| Numer dostawcy VendorNumber | Unikalny identyfikator dostawcy, który przesłał fakturę. | ||
| Opis Numer dostawcy to klucz danych podstawowych identyfikujący dostawcę. Łączy transakcję faktury z konkretnym partnerem biznesowym, co pozwala analizować proces z uwzględnieniem cech dostawcy. Analiza procesu według numeru dostawcy może ujawnić istotne informacje o relacjach z dostawcami i ich wynikach. Można na przykład ustalić, którzy dostawcy regularnie przesyłają faktury powodujące blokady płatności lub rozbieżności, a których faktury są obsługiwane najsprawniej. Informacje te przydają się w zarządzaniu dostawcami i planowaniu zakupów. Dlaczego to ważne Umożliwia analizę dla poszczególnych dostawców i pomaga wykrywać wzorce, problemy lub usprawnienia związane z konkretnymi dostawcami. Skąd pobrać Jest to pole „Strona fakturująca” (LIFNR) z tabeli nagłówków dokumentów faktur RBKP. Przykłady 100345100876200112 | |||
| Numer zamówienia zakupu PurchaseOrderNumber | Identyfikator zamówienia zakupu (PO), z którym uzgadniana jest faktura. | ||
| Opis Numer zamówienia zakupu łączy fakturę z pierwotnym dokumentem zakupu. Jest niezbędny do uzgadniania trzech dokumentów (zamówienia zakupu, przyjęcia towaru i faktury) oraz analizy sprawności obsługi faktur powiązanych z zamówieniem. Ten atrybut jest ważny dla dashboardów, takich jak „Odsetek rozbieżności przy uzgadnianiu faktur z zamówieniami zakupu”. Pozwala podzielić proces na faktury powiązane z zamówieniem i faktury bez zamówienia, które często przebiegają inaczej i mają różny stopień złożoności. Analiza problemów dotyczących konkretnych zamówień może pomóc wykryć wcześniejsze nieprawidłowości w procesie zakupowym. Dlaczego to ważne Łączy fakturę z procesem zakupowym, umożliwiając analizę faktur powiązanych z zamówieniem i bez zamówienia oraz wykrywanie rozbieżności przy uzgadnianiu. Skąd pobrać Zazwyczaj znajduje się na poziomie pozycji. Pole „Numer zamówienia zakupu” (EBELN) jest w tabeli pozycji faktury RSEG. Może być konieczne zagregowanie go na poziomie nagłówka. Przykłady 450001756345000175644500017565 | |||
| Przyczyna blokady płatności PaymentBlockReason | Kod określający, dlaczego faktura została zablokowana do płatności. | ||
| Opis Blokadę płatności stosuje się, gdy na fakturze wykryto rozbieżność lub potrzebne jest dodatkowe wyjaśnienie. Kod przyczyny wskazuje powód blokady, na przykład różnicę w ilości lub cenie albo blokadę ręczną. Atrybut ten jest niezbędny w dashboardzie dotyczącym czasu usuwania blokad płatności. Analiza częstotliwości i czasu trwania blokad według przyczyny pomaga ustalić źródła opóźnień. Jeśli na przykład najczęstszą przyczyną długich blokad są rozbieżności cenowe, może to wskazywać na problem z danymi podstawowymi lub procesem zamówień zakupu, który wymaga rozwiązania. Dlaczego to ważne Wyjaśnia przyczyny opóźnień w obsłudze faktur, ułatwia analizę źródeł blokad płatności i pomaga ustalać priorytety działań usprawniających proces. Skąd pobrać Przyczynę blokady płatności można znaleźć na poziomie pozycji w tabeli RSEG (pole SPGRS) lub w tabeli dokumentów księgowych BSEG (pole ZLSPR). Przykłady RIM | |||
| Termin płatności PaymentDueDate | Data, do której zgodnie z warunkami płatności należy uregulować fakturę dostawcy. | ||
| Opis Termin płatności oblicza się na podstawie daty bazowej faktury i uzgodnionych warunków płatności. To ostateczny termin uregulowania należności, który pozwala uniknąć opóźnienia, ewentualnych kar i pogorszenia relacji z dostawcą. Atrybut ten ma istotne znaczenie dla KPI dotyczących wyników i zgodności, takich jak „Odsetek płatności terminowych” czy „Utracone rabaty za wcześniejszą płatność”. Porównanie faktycznej daty płatności (daty rozliczenia) z terminem płatności pozwala automatycznie ustalić, czy płatność nastąpiła w terminie, przed terminem czy po terminie. To również podstawa dashboardu dotyczącego przestrzegania warunków płatności. Dlaczego to ważne Stanowi punkt odniesienia przy ocenie terminowości płatności i wskazywaniu możliwości uzyskania rabatów za wcześniejszą płatność. Skąd pobrać Ta data jest często obliczana. Data bazowa płatności (ZFBDT) znajduje się w tabeli BSEG. Sposób wyznaczania terminu zależy również od warunków płatności (BSEG-ZTERM). Przykłady 2023-04-192023-05-052023-05-11 | |||
| Czas zakończenia EndTime | Znacznik czasu wskazujący, kiedy czynność została zakończona. W przypadku zdarzeń chwilowych jest taki sam jak czas rozpoczęcia. | ||
| Opis Atrybut czasu zakończenia wskazuje, kiedy dana czynność dobiegła końca. Wiele zdarzeń w SAP jest rejestrowanych jako pojedynczy moment, dlatego czas zakończenia jest w ich przypadku taki sam jak czas rozpoczęcia. W przypadku czynności o mierzalnym czasie trwania, takich jak aktywnie realizowany etap akceptacji, może oznaczać zakończenie pracy. Osobny czas zakończenia pozwala w analizie procesu zmierzyć czas realizacji czynności niezależnie od poprzedzającego ją czasu oczekiwania. Dzięki temu można odróżnić czas wykonania czynności od czasu, przez jaki sprawa czeka na jej rozpoczęcie, i lepiej ocenić wykorzystanie zasobów. Dlaczego to ważne Pozwala obliczyć czas realizacji czynności, odróżnić go od czasu oczekiwania między czynnościami i dokładniej analizować wąskie gardła. Skąd pobrać Często jest taki sam jak czas rozpoczęcia i wyznacza się go na podstawie CDHDR-UDATE oraz CDHDR-UTIME. W niektórych przypadkach można go odczytać z dzienników workflow, które jawnie rejestrują rozpoczęcie i zakończenie zadania. Przykłady 2023-03-15T10:35:10Z2023-03-16T14:10:00Z2023-03-28T09:02:45Z | |||
| Czy po terminie IsOverdue | Obliczana flaga wskazująca, czy faktura została opłacona po terminie płatności. | ||
| Opis Jest to atrybut logiczny obliczany przez porównanie daty rozliczenia (faktycznej daty płatności) z terminem płatności. Jeśli data rozliczenia przypada po terminie, flaga ma wartość prawda, w przeciwnym razie fałsz. W prosty sposób pokazuje to terminowość płatności każdej faktury. Atrybut ten ułatwia analizę i wizualizację danych na dashboardach. Pozwala łatwo filtrować i agregować dane w celu obliczenia KPI „Odsetek płatności terminowych”. Można szybko porównać przebieg obsługi faktur opłaconych po terminie z przebiegiem obsługi faktur opłaconych na czas, aby wykryć wzorce prowadzące do opóźnień. Dlaczego to ważne Ułatwia analizę terminowości płatności i porównywanie obsługi faktur opłaconych na czas z obsługą faktur opłaconych z opóźnieniem. Skąd pobrać Tego atrybutu nie ma w SAP. Jest obliczany podczas transformacji danych według wzoru: ClearingDate > PaymentDueDate. Przykłady truefalse | |||
| Czy utracono rabat za wcześniejszą płatność IsCashDiscountLost | Obliczana flaga wskazująca, czy nie wykorzystano dostępnego rabatu za wcześniejszą płatność. | ||
| Opis Jest to atrybut logiczny obliczany na podstawie warunków płatności i faktycznej daty płatności. Przyjmuje wartość prawda, jeśli warunki płatności przewidywały rabat za wcześniejszą płatność, a data rozliczenia przypadała po zakończeniu okresu rabatowego. Bezpośrednio wskazuje to straty finansowe wynikające z nieefektywności procesu. Atrybut ten stanowi podstawę dashboardu dotyczącego utraconych rabatów za wcześniejszą płatność. Ułatwia określenie finansowych skutków opóźnień w obsłudze. Po odfiltrowaniu przypadków z wartością prawda analitycy mogą sprawdzić, które warianty procesu i wąskie gardła najczęściej prowadzą do utraty rabatów. Wyniki pomagają uzasadnić potrzebę usprawnienia procesu. Dlaczego to ważne Bezpośrednio określa straty finansowe wynikające z opóźnień w procesie i pomaga uzasadnić usprawnienie workflow obsługi faktur. Skąd pobrać Tego atrybutu nie ma w SAP. Jest obliczany podczas transformacji danych na podstawie interpretacji pola „PaymentTerms” i porównania pola „ClearingDate” z terminem uzyskania rabatu. Przykłady truefalse | |||
| Kod spółki CompanyCode | Identyfikator jednostki prawnej lub spółki, w której obsługiwana jest faktura. | ||
| Opis Kod spółki to podstawowa jednostka organizacyjna w SAP Financials, reprezentująca niezależną jednostkę prawną. Wszystkie transakcje finansowe, w tym faktury, są księgowane w ramach określonego kodu spółki. Atrybut ten pozwala analizować proces osobno dla każdej jednostki prawnej. Ułatwia porównywanie wyników procesu, zgodności i sprawności między spółkami należącymi do jednej grupy. Filtrowanie dashboardów według kodu spółki pozwala wyświetlić KPI dotyczące obsługi faktur dla wybranej spółki. Dlaczego to ważne Umożliwia porównywanie procesów i wyników między różnymi jednostkami prawnymi w organizacji. Skąd pobrać To pole „Company Code” (BUKRS) z tabeli nagłówka dokumentu faktury RBKP. Przykłady 10002000US01 | |||
| Konto księgi głównej GeneralLedgerAccount | Numer konta księgi głównej, na które księgowany jest koszt faktury. | ||
| Opis Konto księgi głównej (G/L) to konto w planie kont, na którym rejestruje się finansowe skutki faktury. Dane te są istotne dla raportowania finansowego i zarządzania kosztami. W process mining analiza kont księgi głównej pozwala uwzględnić finansowy wymiar przebiegu procesu. Dashboard dotyczący wykorzystania kont księgi głównej może ujawnić wzorce wydatków, wskazać potencjalne błędy w dekretacji faktur i pomóc sprawdzić, czy koszty są przypisywane do właściwych działów lub projektów. Łączy to przebieg procesu z jego skutkami finansowymi. Dlaczego to ważne Dodaje finansowy wymiar do analizy procesu, umożliwiając ocenę alokacji kosztów, wzorców wydatków i potencjalnych błędów w dekretacji faktur. Skąd pobrać Dane te znajdują się na poziomie pozycji. Pole „G/L Account Number” (HKONT) jest w tabeli pozycji faktury RSEG w przypadku faktur z zamówieniem zakupu lub w tabeli BSEG w przypadku bezpośrednich faktur FI. Przykłady 630000655100741000 | |||
| Ostatnia aktualizacja danych LastDataUpdate | Znacznik czasu wskazujący, kiedy dane procesu zostały ostatnio odświeżone z systemu źródłowego. | ||
| Opis Atrybut ten zapisuje datę i godzinę ostatniego pobrania lub aktualizacji danych. Dotyczy całego zbioru danych, a nie poszczególnych zdarzeń, i jasno wskazuje, jak aktualne są dane. To ważny atrybut metadanych dla użytkowników dashboardów i analityków. Pomaga ustalić, jaki okres obejmuje analiza, i upewnić się, że decyzje są podejmowane na podstawie aktualnych informacji. Zwykle jest wyraźnie widoczny na dashboardach, aby użytkownicy wiedzieli, kiedy dane zostały odświeżone. Dlaczego to ważne Informuje użytkowników o aktualności danych, dzięki czemu analiza i decyzje opierają się na bieżących informacjach. Skąd pobrać Wartość tę generuje i dodaje do zbioru danych narzędzie do pobierania danych lub ETL podczas ich odświeżania. Przykłady 2024-05-20T08:00:00Z2024-05-21T08:00:00Z2024-05-22T08:00:00Z | |||
| Przyczyna odrzucenia RejectionReason | Kod lub tekst wyjaśniający, dlaczego faktura została odrzucona w workflow zatwierdzania. | ||
| Opis Osoba zatwierdzająca, która odrzuca fakturę, powinna podać przyczynę. Może to być standardowy kod lub komentarz tekstowy wskazujący problem, na przykład „Nieprawidłowy numer zamówienia zakupu”, „Zduplikowana faktura” albo „Nieprawidłowa kwota”. Dane te są niezbędne w dashboardzie dotyczącym przyczyn i trendów odrzuceń faktur. Analiza częstotliwości poszczególnych przyczyn pozwala wykryć powtarzające się problemy i podjąć działania naprawcze. Jeśli faktury często są odrzucane z powodu nieprawidłowego numeru zamówienia zakupu, może to wskazywać na potrzebę lepszej komunikacji z dostawcami lub przeszkolenia osób wprowadzających dane. Taka analiza pomaga ograniczyć ponowną pracę w procesie. Dlaczego to ważne Wskazuje źródła odrzuceń, dzięki czemu można precyzyjnie usprawniać proces, ograniczać ponowną pracę i zwiększać odsetek spraw załatwionych poprawnie za pierwszym razem. Skąd pobrać Informacje te często nie są przechowywane w jednym standardowym polu. Mogą znajdować się w logach kontenera workflow, polach długiego tekstu powiązanych z dokumentem lub w polach specyficznych dla niestandardowego rozwiązania workflow. Przykłady DUPLICATE_INVWRONG_AMTNO_PO_MATCH | |||
| System źródłowy SourceSystem | Wskazuje system źródłowy, z którego pobrano dane. | ||
| Opis Atrybut systemu źródłowego wskazuje pochodzenie danych o zdarzeniach, na przykład nazwę konkretnej instancji SAP ECC. Jest szczególnie ważny w środowiskach z wieloma systemami ERP lub danymi pochodzącymi z różnych źródeł. W analizie atrybut ten pomaga porównywać procesy i wyniki w różnych systemach, regionach lub jednostkach biznesowych działających na osobnych instancjach. Ułatwia śledzenie pochodzenia danych oraz filtrowanie i analizę dla poszczególnych systemów. Dlaczego to ważne Zapewnia niezbędny kontekst w środowiskach z wieloma systemami, umożliwiając rozdzielanie danych i analizę wyników dla poszczególnych systemów. Skąd pobrać Zazwyczaj jest to stała wartość dodawana podczas pobierania danych, która oznacza identyfikator systemu SAP (TADIR-SRCSYSTEM) lub ręcznie przypisany identyfikator konkretnej instancji SAP. Przykłady SAPECC_PROD_EUECC_US_FINSAP_ERP_6_EHP8 | |||
| Typ dokumentu DocumentType | Kod klasyfikujący dokument księgowy, na przykład jako fakturę dostawcy lub notę kredytową. | ||
| Opis Typ dokumentu służy do klasyfikowania różnych rodzajów transakcji biznesowych w SAP. W obsłudze faktur często stosuje się typ „RE” dla standardowych faktur i „KG” dla not kredytowych od dostawców. Typ dokumentu określa między innymi używany zakres numeracji. W analizie atrybut ten pozwala filtrować proces według rodzaju transakcji. Obsługa noty kredytowej może znacznie różnić się od obsługi standardowej faktury. Rozdzielenie tych przebiegów według typu dokumentu daje dokładniejszy i bardziej miarodajny obraz procesu. Dlaczego to ważne Pozwala rozdzielić i analizować różne transakcje biznesowe, na przykład faktury i noty kredytowe, które są obsługiwane w odmienny sposób. Skąd pobrać To pole „Document Type” (BLART) z tabeli nagłówka dokumentu faktury RBKP. Przykłady REKRKG | |||
| Waluta Currency | Kod waluty, w której podano kwotę faktury. | ||
| Opis Atrybut Waluta określa walutę, w której podano kwotę faktury, na przykład USD, EUR lub JPY. Dzięki temu atrybutowi kwotę faktury można prawidłowo interpretować i agregować. Ma to szczególne znaczenie w organizacjach działających na wielu rynkach i rozliczających się w różnych walutach. Analizę można filtrować według waluty, aby porównywać sprawność obsługi i problemy w poszczególnych obszarach walutowych. Aby rzetelnie agregować dane finansowe, może być konieczne przeliczenie kwot na jedną walutę raportową. Dlaczego to ważne Zapewnia niezbędny kontekst dla kwot finansowych, ułatwia ich prawidłową interpretację oraz filtrowanie i analizę według waluty. Skąd pobrać To pole „Currency Key” (WAERS) z tabeli nagłówka dokumentu faktury RBKP. Przykłady USDEURGBP | |||
| Warunki płatności PaymentTerms | Kod określający uzgodnione z dostawcą warunki płatności, takie jak okresy rabatowe i terminy płatności. | ||
| Opis Warunki płatności określają, kiedy należy uregulować fakturę i czy za wcześniejszą płatność przysługuje rabat. Przykładem jest „30 dni netto” albo „2% w ciągu 10 dni, 30 dni netto”, co oznacza 2% rabatu przy płatności w ciągu 10 dni, a w przeciwnym razie pełną kwotę do zapłaty w ciągu 30 dni. Atrybut ten stanowi podstawę dashboardu dotyczącego utraconych rabatów za wcześniejszą płatność oraz KPI „Wskaźnik wykorzystania rabatów za wcześniejszą płatność”. Analiza łączy warunki płatności z datą księgowania i datą płatności, aby ustalić, czy rabat przysługiwał i czy został wykorzystany. Atrybut ten ma również istotne znaczenie dla dashboardu dotyczącego przestrzegania warunków płatności. Dlaczego to ważne Jest niezbędny do analizy wykorzystania rabatów za wcześniejszą płatność i oceny finansowych skutków opóźnień w procesie. Skąd pobrać To pole „Terms of Payment Key” (ZTERM) z tabeli nagłówka dokumentu faktury RBKP. Przykłady Z0010001NT30 | |||
Działania w procesie obsługi faktur w procesie zakupów do płatności
| Działanie | Opis | ||
|---|---|---|---|
| Odwrócenie księgowania faktury | Oznacza anulowanie zaksięgowanego dokumentu faktury. Tworzony jest dokument korygujący, który odwraca skutki finansowe pierwotnej faktury. | ||
| Dlaczego to ważne To zdarzenie wskazuje istotny wyjątek i ścieżkę poprawek. Analiza częstotliwości i przyczyn odwróceń księgowania może ujawnić problemy systemowe w kontroli i księgowaniu faktur. Skąd pobrać Jest to jawne zdarzenie zapisane w tabeli nagłówków dokumentów BKPF. Nagłówek odwróconego dokumentu zawiera numer dokumentu korygującego (STBLG) i rok obrotowy (STJAH). Rejestrowanie Należy znaleźć dokumenty, w których pole BKPF-STBLG jest wypełnione. Znacznikiem czasu zdarzenia jest data księgowania dokumentu korygującego. Typ zdarzenia explicit | |||
| Rozliczenie faktury | To zdarzenie oznacza ostatni etap prawidłowo zakończonego cyklu życia faktury. Otwarte zobowiązanie zostaje rozliczone dokumentem płatności, co potwierdza wykonanie płatności. | ||
| Dlaczego to ważne Jako główne zdarzenie końcowe jest niezbędne do obliczenia całkowitego czasu obsługi faktury od początku do końca. Potwierdza zakończenie procesu i służy do pomiaru terminowości płatności. Skąd pobrać Jest to jawne zdarzenie zapisane w tabeli pozycji faktury BSEG. Data rozliczenia znajduje się w polu AUGDT, a numer dokumentu rozliczeniowego w polu AUGBL. Rejestrowanie Należy użyć daty rozliczenia (BSEG-AUGDT) z pozycji dokumentu faktury. Typ zdarzenia explicit | |||
| Ustawienie blokady płatności | Zdarzenie występuje, gdy na pozycji faktury zostaje ustawiona blokada uniemożliwiająca płatność. Blokady mogą być ustawiane automatycznie z powodu rozbieżności przy uzgadnianiu trzech dokumentów lub ręcznie z różnych przyczyn. | ||
| Dlaczego to ważne To zdarzenie jest niezbędne do pomiaru czasu usuwania blokady płatności i ustalenia przyczyn opóźnień. Wskazuje problemy z ceną, ilością lub wymaganymi akceptacjami. Skąd pobrać Jest to jawne zdarzenie, które można śledzić w dziennikach dokumentów zmian (tabele CDHDR i CDPOS) dla tabeli BSEG, pola ZLSPR (klucz blokady płatności). Rejestrowanie Znacznik czasu z dokumentów zmian (CDHDR), gdy wartość BSEG-ZLSPR zmienia się z pustej na niepustą. Typ zdarzenia explicit | |||
| Zaksięgowanie faktury | To ważne zdarzenie finansowe, podczas którego faktura zostaje oficjalnie zapisana w księdze głównej i powstaje zobowiązanie. Dokument przechodzi ze stanu tymczasowego, czyli wstępnie wprowadzonego, do trwałego zapisu księgowego. | ||
| Dlaczego to ważne Zaksięgowanie to ważny etap, który potwierdza prawidłowość faktury. Jest warunkiem płatności i istotnym wskaźnikiem przepustowości procesu. Skąd pobrać Jest to jawne zdarzenie zapisane w tabeli nagłówków dokumentów BKPF. Znacznikiem czasu jest data księgowania BKPF-BUDAT. Dokument nie będzie już miał statusu „wstępnie wprowadzony”. Rejestrowanie W przypadku dokumentów, które nie są wstępnie wprowadzone (BKPF-BSTAT jest puste lub ma wartość ' '), należy użyć daty księgowania (BKPF-BUDAT). Typ zdarzenia explicit | |||
| Zarejestrowanie faktury | Oznacza utworzenie dokumentu faktury w SAP, jako dokumentu wstępnie wprowadzonego lub zaksięgowanego. Zwykle jest to pierwsze zarejestrowane w systemie zdarzenie w cyklu życia faktury i początek procesu. | ||
| Dlaczego to ważne To główny punkt początkowy pomiaru czasu obsługi faktury od początku do końca. Analiza czasu od tego momentu pomaga wykryć opóźnienia na etapie wprowadzania danych i tworzenia dokumentu. Skąd pobrać Znacznik czasu utworzenia jest zapisany w tabeli SAP BKPF, w polach CPUDT (data wprowadzenia dokumentu księgowego) i CPUTM (godzina wprowadzenia). Rejestrowanie Należy użyć znacznika czasu utworzenia dokumentu z nagłówka tabeli BKPF (CPUDT). Typ zdarzenia explicit | |||
| Akceptacja faktury | Oznacza formalną akceptację faktury przez upoważnioną osobę, która pozwala przejść do księgowania i płatności. Często jest to ostatni etap workflow. | ||
| Dlaczego to ważne Ten etap kończy pomiar czasu cyklu akceptacji. Odblokowuje dalszą obsługę faktury, umożliwia terminową płatność i pomaga analizować rozkład obciążenia między osobami akceptującymi. Skąd pobrać Zdarzenie to zwykle można odczytać z tabel SAP Business Workflow, identyfikując zakończenie zadania akceptacji. Można je też wywnioskować ze zdjęcia blokady płatności związanej z akceptacją. Rejestrowanie Znacznik czasu zakończenia etapu akceptacji w dziennikach workflow lub usunięcia określonej blokady płatności. Typ zdarzenia inferred | |||
| Odrzucenie faktury | Oznacza odrzucenie faktury podczas procesu akceptacji. Zwykle wymaga to poprawienia i ponownego przesłania dokumentu, co tworzy pętlę poprawek. | ||
| Dlaczego to ważne Śledzenie odrzuceń pomaga wykryć częste przyczyny problemów, takie jak nieprawidłowe dane lub naruszenie zasad. Pozwala zmierzyć skalę poprawek i wskazać obszary wymagające usprawnienia procesu lub lepszego przygotowania dostawców. Skąd pobrać Zdarzenie to zwykle występuje w dziennikach SAP Business Workflow jako etap odrzucenia. Można je też wywnioskować z określonych zmian statusu lub notatek dodanych do dokumentu faktury. Rejestrowanie Znacznik czasu etapu odrzucenia w dziennikach workflow lub zmiany statusu dokumentu wskazującej na odrzucenie. Typ zdarzenia inferred | |||
| Przekazanie faktury do akceptacji | Oznacza moment przekazania faktury do formalnego workflow akceptacji. Sposób rejestrowania tego zdarzenia zależy w dużej mierze od konkretnej konfiguracji SAP Workflow lub systemu zewnętrznego. | ||
| Dlaczego to ważne To zdarzenie rozpoczyna pomiar KPI czasu cyklu akceptacji faktury. Jest niezbędne do wykrywania opóźnień w ścieżce akceptacji i analizy pracy osób akceptujących. Skąd pobrać Zdarzenie to zwykle można odczytać z tabel SAP Business Workflow (np. SWW_WI2OBJ, SWWLOG), identyfikując rozpoczęcie konkretnego zadania akceptacji. W prostszych przypadkach można je wywnioskować ze zmiany statusu w polu niestandardowym. Rejestrowanie Wymaga analizy dzienników SAP Workflow lub niestandardowych pól statusu powiązanych z dokumentem faktury. Typ zdarzenia inferred | |||
| Przekroczenie terminu płatności faktury | Zdarzenie obliczane, które występuje, gdy bieżąca data przekracza termin płatności netto faktury, a faktura nie została jeszcze opłacona. Termin płatności wynika z warunków płatności i daty bazowej. | ||
| Dlaczego to ważne To zdarzenie jest niezbędne do monitorowania KPI terminowości płatności. Z wyprzedzeniem wskazuje faktury zagrożone opóźnieniem, które może zaszkodzić relacjom z dostawcami i wiązać się z karami. Skąd pobrać Zdarzenie oblicza się, porównując bieżącą datę z terminem płatności netto. Termin wynika z daty bazowej (BSEG-ZFBDT) i warunków płatności (BSEG-ZTERM). Rejestrowanie Zdarzenie jest wyzwalane, gdy Typ zdarzenia calculated | |||
| Usunięcie blokady płatności | Oznacza usunięcie blokady płatności z pozycji faktury, co pozwala uwzględnić ją w przebiegu płatności. Potwierdza, że wcześniej wykryty problem został rozwiązany. | ||
| Dlaczego to ważne To zdarzenie kończy pomiar czasu trwania blokady. Analiza czasu od jej ustawienia do usunięcia pokazuje, jak sprawnie rozwiązywane są problemy. Skąd pobrać Zdarzenie to można śledzić w dziennikach dokumentów zmian (tabele CDHDR i CDPOS) dla tabeli BSEG, pola ZLSPR (klucz blokady płatności), gdy blokada zostaje usunięta. Rejestrowanie Znacznik czasu z dokumentów zmian (CDHDR), gdy wartość BSEG-ZLSPR zmienia się z niepustej na pustą. Typ zdarzenia explicit | |||
| Wstępne wprowadzenie faktury | Oznacza, że faktura została wprowadzona do SAP, ale nie została jeszcze zaksięgowana w księdze głównej. Jest to stan tymczasowy, który pozwala sprawdzić dokument, poprawić go lub uzyskać akceptację przed zaksięgowaniem. | ||
| Dlaczego to ważne Śledzenie, kiedy faktury są wstępnie wprowadzane i jak długo pozostają w tym stanie, pomaga wykryć wąskie gardła w kontroli i akceptacji przed zaksięgowaniem. Pozwala oddzielić czas wprowadzania danych od czasu obsługi finansowej. Skąd pobrać Zdarzenie można wywnioskować ze statusu dokumentu w tabeli BKPF, w polu BSTAT. Wartość 'V' (dokument wstępnie wprowadzony) lub 'W' (dokument wstępnie wprowadzony z możliwością zmiany po akceptacji) oznacza taki stan. Rejestrowanie Należy znaleźć dokumenty, w których pole statusu BKPF-BSTAT ma wartość 'V'. Znacznikiem czasu zdarzenia jest data utworzenia BKPF-CPUDT. Typ zdarzenia inferred | |||
Instrukcje pobierania danych
Kroki
- Utwórz program ABAP: Użyj transakcji
SE38lubSE80, aby utworzyć nowy program wykonywalny, na przykładZ_PM_INVOICE_EXTRACT. Nadaj mu odpowiedni tytuł i ustaw typ „Program wykonywalny”. - Zdefiniuj ekran wyboru: W programie utwórz ekran wyboru, który umożliwi filtrowanie danych. Uwzględnij co najmniej kod spółki (
BUKRS), rok obrotowy (GJAHR), zakres dat księgowania (BUDAT) oraz ścieżkę pliku wyjściowego na serwerze aplikacyjnym. - Zadeklaruj struktury danych: Zdefiniuj strukturę tabeli wewnętrznej, w której będzie przechowywany dziennik zdarzeń. Musi ona zawierać wszystkie wymagane i zalecane atrybuty:
InvoiceNumber,Activity,EventTime,UserName,VendorNumber,PurchaseOrderNumber,InvoiceAmount,PostingDate,PaymentDueDate,PaymentBlockReasoniClearingDate. - Zaimplementuj logikę wyboru danych: Napisz główną logikę ABAP do pobierania danych o fakturach. Dane należy pobrać w kilku zapytaniach, a następnie połączyć w końcowym dzienniku zdarzeń.
- Najpierw pobierz dane nagłówków i pozycji z głównych tabel faktur
BKPF,BSEG,RBKPiRSEG, stosując kryteria z ekranu wyboru. - Dla każdej faktury utwórz zdarzenia podstawowe, takie jak „Zarejestrowano dane faktury” (na podstawie znacznika czasu utworzenia) i „Zaksięgowano fakturę” (na podstawie znacznika czasu księgowania).
- Odpytaj tabele dokumentów zmian
CDHDRiCDPOS, aby znaleźć zmiany dotyczące blokad płatności (poleZLSPRw tabeliBSEG). Dla każdej odpowiedniej zmiany utwórz zdarzenia „Ustawiono blokadę płatności” i „Usunięto blokadę płatności”. - Wykryj zdarzenia „Rozliczono fakturę”, sprawdzając dokument rozliczeniowy (
AUGBL) i datę rozliczenia (AUGDT) w tabeliBSEG. - Wykryj zdarzenia „Odwrócono fakturę”, sprawdzając dokument storna (
STBLG) w nagłówkuBKPF. - Dodaj własną logikę do rejestrowania zdarzeń workflow („Wysłano fakturę do akceptacji”, „Zaakceptowano”, „Odrzucono”). Ten fragment zależy od konfiguracji danego klienta. Kod trzeba dostosować do tabel lub pól statusu używanych w workflow.
- Najpierw pobierz dane nagłówków i pozycji z głównych tabel faktur
- Utwórz zdarzenia wyliczane: W logice programu oblicz zdarzenie
Invoice Becomes Overdue. W tym celu porównaj termin płatności faktury (PaymentDueDate) z bieżącą datą dla wszystkich nieopłaconych faktur. Jeśli termin już minął, utwórz zdarzenie z polemEventTimeustawionym na termin płatności. - Wypełnij tabelę dziennika zdarzeń: Pobierając dane o każdej fakturze z różnych źródeł, sformatuj je i dodaj nowe wiersze do końcowej tabeli wewnętrznej dziennika zdarzeń, po jednym wierszu na działanie.
- Wyeksportuj dane do pliku: Użyj instrukcji
OPEN DATASET,TRANSFERiCLOSE DATASET, aby zapisać zawartość końcowej tabeli wewnętrznej w pliku tekstowym w ścieżce na serwerze aplikacyjnym SAP wskazanej na ekranie wyboru. Zastosuj stały separator, na przykład średnik lub tabulator, aby utworzyć plik CSV. - Zaplanuj pobieranie danych: Aby regularnie pobierać dane, utwórz wariant programu z wybranymi kryteriami i zaplanuj jego uruchamianie w tle jako zadanie za pomocą transakcji
SM36. - Pobierz plik wyjściowy: Otwórz katalog serwera aplikacyjnego SAP za pomocą transakcji
AL11i znajdź wygenerowany plik. Użyj transakcjiCG3Y, aby pobrać go na komputer. - Przygotuj plik do przesłania: Przed przesłaniem pliku do narzędzia process mining otwórz go i sprawdź nagłówki, spójność formatu danych, zwłaszcza znaczników czasu, oraz separator. Zapisz plik w kodowaniu UTF-8.
Konfiguracja
- Kryteria wyboru: Raport ABAP powinien zawierać rozbudowany ekran wyboru. Najważniejsze filtry to:
Company Code (BUKRS): ogranicza pobieranie danych do wybranych podmiotów prawnych.Posting Date (BUDAT): określa zakres czasu. Zaleca się pobieranie danych w mniejszych partiach, na przykład za okres od 3 do 6 miesięcy.Document Type (BLART): pozwala uwzględnić tylko odpowiednie typy dokumentów faktur, na przykład „RE” dla faktur logistycznych i „KR” dla faktur od dostawców.
- Ścieżka pliku wyjściowego: Wymagany parametr określający pełną ścieżkę i nazwę pliku, który zostanie utworzony na serwerze aplikacyjnym SAP. Użytkownik uruchamiający raport musi mieć uprawnienia do zapisu w tym katalogu.
- Wydajność: W przypadku dużych zbiorów danych raport należy uruchamiać jako zadanie w tle poza godzinami szczytu, aby nie obciążać systemu. Logika powinna pobierać z tabel tylko wymagane pola i, jeśli to możliwe, korzystać ze standardowych indeksów bazy danych SAP.
- Wymagania wstępne i uprawnienia: Użytkownik lub konto serwisowe uruchamiające pobieranie danych potrzebuje:
- uprawnień do uruchamiania raportów ABAP (w ramach
S_PROGRAM); - dostępu do odczytu tabel finansowych i logistycznych, w tym
BKPF,BSEG,RBKP,RSEG,CDHDRiCDPOS; - uprawnień do zapisu plików we wskazanym katalogu serwera aplikacyjnego (
S_DATASET); - dostępu do transakcji
SE38,SM36,AL11iCG3Yna potrzeby programowania, planowania zadań i pobierania plików.
- uprawnień do uruchamiania raportów ABAP (w ramach
Przykładowe zapytanie abap
REPORT Z_PM_INVOICE_EXTRACT.
*&---------------------------------------------------------------------*
*& Tables for Selection Screen
*&---------------------------------------------------------------------*
TABLES: BKPF, RBKP.
*&---------------------------------------------------------------------*
*& Data Declarations
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
InvoiceNumber TYPE belnr_v,
Activity TYPE string,
EventTime TYPE timestamp,
UserName TYPE uname,
VendorNumber TYPE lifnr,
PurchaseOrderNumber TYPE ebeln,
InvoiceAmount TYPE wrbtr,
PostingDate TYPE budat,
PaymentDueDate TYPE faedt,
PaymentBlockReason TYPE rstgr,
ClearingDate TYPE augdt,
END OF ty_event_log.
DATA: gt_event_log TYPE TABLE OF ty_event_log,
gs_event_log TYPE ty_event_log.
DATA: lt_bkpf TYPE TABLE OF bkpf,
ls_bkpf TYPE bkpf,
lt_bseg TYPE TABLE OF bseg,
ls_bseg TYPE bseg.
DATA: lt_rbkp TYPE TABLE OF rbkp,
ls_rbkp TYPE rbkp.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_gjahr FOR bkpf-gjahr OBLIGATORY,
s_budat FOR bkpf-budat.
PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/usr/sap/tmp/invoice_events.csv'.
*&---------------------------------------------------------------------*
*& Start of Program Logic
*&---------------------------------------------------------------------*
START-OF-SELECTION.
" Select FI Invoices (e.g., Doc Type KR)
SELECT * FROM bkpf INTO TABLE lt_bkpf
WHERE bukrs IN s_bukrs
AND gjahr IN s_gjahr
AND budat IN s_budat
AND blart = 'KR'.
" Select MM Invoices
SELECT * FROM rbkp INTO TABLE lt_rbkp
WHERE bukrs IN s_bukrs
AND gjahr IN s_gjahr
AND budat IN s_budat.
* --- Process FI Invoices ---
LOOP AT lt_bkpf INTO ls_bkpf.
CLEAR gs_event_log.
gs_event_log-InvoiceNumber = ls_bkpf-belnr.
gs_event_log-PostingDate = ls_bkpf-budat.
SELECT SINGLE * FROM bseg INTO ls_bseg
WHERE bukrs = ls_bkpf-bukrs
AND belnr = ls_bkpf-belnr
AND gjahr = ls_bkpf-gjahr
AND koart = 'K'. " Vendor Line Item
IF sy-subrc = 0.
gs_event_log-VendorNumber = ls_bseg-lifnr.
gs_event_log-InvoiceAmount = ls_bseg-wrbtr.
gs_event_log-ClearingDate = ls_bseg-augdt.
" Calculate Due Date
CALL FUNCTION 'DETERMINE_DUE_DATE'
EXPORTING
i_bseg = ls_bseg
IMPORTING
e_faedt = gs_event_log-PaymentDueDate.
ENDIF.
" Activity: Invoice Data Captured
gs_event_log-Activity = 'Invoice Data Captured'.
CONVERT DATE ls_bkpf-cpudt TIME ls_bkpf-cputm INTO TIME STAMP gs_event_log-EventTime TIME ZONE sy-zonlo.
gs_event_log-UserName = ls_bkpf-usnam.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Parked (if BSTAT = 'V')
IF ls_bkpf-bstat = 'V'.
gs_event_log-Activity = 'Invoice Parked'.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Invoice Posted
gs_event_log-Activity = 'Invoice Posted'.
CONVERT DATE ls_bkpf-budat TIME ls_bkpf-cputm INTO TIME STAMP gs_event_log-EventTime TIME ZONE sy-zonlo.
gs_event_log-UserName = ls_bkpf-usnam.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Cleared
IF ls_bseg-augbl IS NOT INITIAL.
gs_event_log-Activity = 'Invoice Cleared'.
CONVERT DATE ls_bseg-augdt INTO TIME STAMP gs_event_log-EventTime TIME ZONE sy-zonlo.
gs_event_log-UserName = ls_bseg-usnam_cl.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Invoice Becomes Overdue
IF gs_event_log-PaymentDueDate IS NOT INITIAL AND gs_event_log-PaymentDueDate < sy-datum AND ls_bseg-augbl IS INITIAL.
gs_event_log-Activity = 'Invoice Becomes Overdue'.
CONVERT DATE gs_event_log-PaymentDueDate INTO TIME STAMP gs_event_log-EventTime TIME ZONE sy-zonlo.
gs_event_log-UserName = 'SYSTEM'.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Invoice Reversed
IF ls_bkpf-stblg IS NOT INITIAL.
DATA: ls_rev_bkpf TYPE bkpf.
SELECT SINGLE budat, usnam FROM bkpf INTO ls_rev_bkpf
WHERE belnr = ls_bkpf-stblg AND bukrs = ls_bkpf-bukrs AND gjahr = ls_bkpf-gjahr.
IF sy-subrc = 0.
gs_event_log-Activity = 'Invoice Reversed'.
CONVERT DATE ls_rev_bkpf-budat INTO TIME STAMP gs_event_log-EventTime TIME ZONE sy-zonlo.
gs_event_log-UserName = ls_rev_bkpf-usnam.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
ENDLOOP.
* --- NOTE: The logic for MM invoices (from lt_rbkp) would be similar, joining RBKP with RSEG.
* --- NOTE: The logic for Payment Blocks and Workflow events requires reading change documents (CDHDR/CDPOS)
* --- or custom workflow tables. Below is a conceptual example for payment blocks.
* --- Conceptual Example for 'Payment Block Set' / 'Released' using Change Docs
* DATA: lt_cdhdr TYPE TABLE OF cdhdr, ls_cdhdr TYPE cdhdr,
* lt_cdpos TYPE TABLE OF cdpos, ls_cdpos TYPE cdpos.
* SELECT * FROM cdhdr INTO TABLE lt_cdhdr
* WHERE objectclas = 'BELEG' AND objectid IN (SELECT belnr FROM bkpf WHERE ...).
* LOOP AT lt_cdhdr.
* SELECT * FROM cdpos INTO TABLE lt_cdpos
* WHERE changenr = ls_cdhdr-changenr AND tabname = 'BSEG' AND fname = 'ZLSPR'.
* LOOP AT lt_cdpos.
* "... logic to create 'Payment Block Set' (if VALUE_NEW is not blank)
* "... or 'Payment Block Released' (if VALUE_NEW is blank) events.
* ENDLOOP.
* ENDLOOP.
* --- Conceptual Example for Workflow events ('Sent For Approval', 'Approved', 'Rejected')
* --- This part MUST be customized based on your specific workflow implementation (e.g., OpenText VIM, SAP WF).
* --- You would query the relevant workflow tables or status change tables here.
*&---------------------------------------------------------------------*
*& Write to File
*&---------------------------------------------------------------------*
END-OF-SELECTION.
DATA: lv_string TYPE string,
lv_header TYPE string.
" Create Header
lv_header = 'InvoiceNumber;Activity;EventTime;UserName;VendorNumber;PurchaseOrderNumber;InvoiceAmount;PostingDate;PaymentDueDate;PaymentBlockReason;ClearingDate'.
OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc = 0.
TRANSFER lv_header TO p_fpath.
LOOP AT gt_event_log INTO gs_event_log.
CONCATENATE gs_event_log-InvoiceNumber
gs_event_log-Activity
gs_event_log-EventTime
gs_event_log-UserName
gs_event_log-VendorNumber
gs_event_log-PurchaseOrderNumber
gs_event_log-InvoiceAmount
gs_event_log-PostingDate
gs_event_log-PaymentDueDate
gs_event_log-PaymentBlockReason
gs_event_log-ClearingDate
INTO lv_string SEPARATED BY ';'.
TRANSFER lv_string TO p_fpath.
ENDLOOP.
CLOSE DATASET p_fpath.
ELSE.
MESSAGE 'Error opening file.' TYPE 'E'.
ENDIF. Gotowi do rozpoczęcia?
Korzystając z tego szablonu, mogą Państwo odkryć przydatne informacje i usprawnić proces obsługi faktur w procesie zakupów do płatności. Warto rozpocząć pobieranie danych już dziś i wykorzystać je do usprawnienia operacji.
Usprawnij obsługę faktur w procesie zakupów do płatności
Wykryj nieefektywne działania i skróć cykl obsługi faktur o 30%.
Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.