Spis treści
Realizowanie płatności z systemów ERP firmy SAP może być obarczone różnymi niedogodnościami. W poniższym poradniku postaramy się zidentyfikować te najbardziej popularne i jednocześnie wskazać pomysły, dzięki którym wymienione problemy można wyeliminować. Przyjrzyjmy się zatem następującym elementom procesów przelewów wychodzących w SAP:
Płatności w SAP - kilka słów o złożoności procesu
Ustawa o przeciwdziałaniu nadmiernym opóźnieniom w transakcjach handlowych (tzw. Ustawa o Zatorach płatniczych), poza nowymi obowiązkami sprawozdawczymi, nakłada na dużych przedsiębiorców przede wszystkim obowiązek bieżącego monitorowania zobowiązań przeterminowanych (zarówno niezapłaconych jak i zapłaconych, ale po terminie). Ich łączna wartość w okresie trzech następujących po sobie miesięcy nie może przekraczać 5 mln zł w latach 2020-2021 oraz 2 mln w latach kolejnych. Jeśli próg ten jest w naszej firmie przekraczany możemy liczyć się z dotkliwymi karami ze strony UOKiK, w przypadku gdy Prezes urzędu zdecyduje się na wszczęcie postępowania w sprawie nadmiernego opóźniania. Duzi przedsiębiorcy to zazwyczaj duże instalacje systemów klasy ERP odpowiedzialnych m.in. za ewidencję księgową, procesy płatnicze, czy raportowania operacyjnego rozrachunków. Najbardziej powszechnym systemem tej klasy jest SAP ECC lub S/4HANA, w którym funkcje księgowe realizowane są w module SAP FI (Rachunkowości finansowej).
Tylko, czy aby na pewno sam fakt korzystania z wiodącego systemu finansowego załatwia sprawę?
Aby uniknąć potencjalnych kłopotów, możesz z jednej strony monitorować próg nadmiernego opóźnienia oraz być gotowym na ewentualną kontrolę UOKiK, a z drugiej po prostu płacić w terminie. Działania te wydawałyby się proste, ale jak wynika z naszych doświadczeń, takimi zazwyczaj nie są w dużych podmiotach korzystających z SAP. Na potrzeby tego artykułu wyłączmy poza nawias ewentualną trudną sytuację płynnościową podmiotu, która w sposób szczególny wpływa na opóźnienia w płatnościach. Podobnie nie dotykamy w artykule problemów z nieefektywnym systemem obiegu faktur zakupowych, który w skrajnych przypadkach może skutkować zwalnianiem do płatności dokumentów po terminie ich wymagalności.
Zatem skupiając się na technicznej stronie przebiegu procesu płatniczego, użytkownicy SAP FI regulując zobowiązania handlowe spółki lub grupy (np. w ramach funkcjonującego centrum usług wspólnych) korzystają z programu automatycznych płatności, tzw. transakcji F110. Aplikacja ta analizuje otwarte rozrachunki oraz – przy właściwej parametryzacji – umożliwia automatyczne generowanie plików z listą przelewów do zaimportowania do systemu bankowości elektronicznej. Pytanie zatem: Gdzie leży problem, skoro program płatności działa automatycznie? Konstrukcja standardowego rozwiązania SAP narzuca pewne ograniczenia, z którymi użytkownicy są zmuszeni mierzyć się
w dużej części podczas codziennego użytkowania. Najczęściej napotykając trudności z poniższymi aspektami procesu przelewów wychodzących:
Obserwuj nas na LinkedIn
Obserwuj nas
Mechanizmy płatności w SAP
Tworzenie propozycji
Proces płatności rozpoczyna się od utworzenia propozycji płatniczej, której użytkownik nadaje własne ID, datę przebiegu i uzupełnia pola kolejnych zakładek, z których część może wypełnić kopiując dane z historycznych propozycji. Czynność jest rutynowa i podatna na pomyłki. Dowolność wskazywania identyfikacji propozycji utrudnia utrzymanie porządku w przebiegach płatniczych i ich późniejsze raportowanie w sytuacji, gdy przelewy realizuje kilka osób. Pomysłem na rozwiązanie problemu byłoby zdefiniowanie typowych scenariuszy płatniczych (np. przelewy krajowe, zagraniczne, wysokokwotowe, centrala, oddziały, kontrahenci wewnętrzni, kluczowi, pozostali etc.), które wybierane byłyby
z listy w momencie tworzenia propozycji przez uprawnione osoby. Podejście takie znakomicie uporządkowałoby proces.
Wyświetlanie propozycji
Brak możliwości zbiorczego wyświetlenia danych bieżących i historycznych propozycji (przebiegów) z informacją o łącznej wartości zleconych przelewów wg walut, banków, czy form jakie zawiera płatność. Aby poznać te wartości należy „wklikiwać się” w każdą propozycję z osobna, znając jej podstawowe parametry jak ID czy datę wykonania. Podobnie rzecz się ma z wygenerowaniem preliminarza płatności czy listy dokumentów zapłaconych. Rozwiązaniem problemu byłby raport umożliwiający podsumowanie płatności per rachunek bankowy dla określonego zakresu przebiegów.
Zmiany propozycji
Kolejny element procesu wymagający uciążliwego wyklikiwania. Użytkownicy najczęściej odczuwają potrzebę zmian:
- Konta banku własnego domyślnie przypisanego do propozycji – głównie na potrzeby regulowania bieżącej płynności wg dostępności środków. F110 nie udostępnia funkcji masowej zmiany przypisania banku do wskazanych przelewów.
- Formy płatności określonej dla przelewu – najczęściej obsługa Split Payment (mechanizm podzielonej płatności) realizowana jest za pomocą dedykowanej formy płatności. Jest zatem niejednokrotnie potrzeba jej zmiany w określonych przypadkach w sposób zbiorczy. Podobnie jak w przypadku banku własnego, w standardzie mamy jedynie możliwość zmiany formy pojedynczo przelew po przelewie.
- Blokady (wyłączenia) faktur z propozycji – nierzadko zachodzi potrzeba wykluczenia określonych pozycji lub całych przelewów
z propozycji, np. ze względu na błędny rachunek kontrahenta. Ponownie takie działanie polega na pojedynczym blokowaniu określonych pozycji na fakturze. - Dodatkowe instrukcje płatnicze – rzadziej spotykane, np. sposoby podziału kosztów pomiędzy stronami przelewu.
Obsługa wyjątków
Wyjątki, czyli pozycje, które z jakichś względów nie zostały poprawnie zaklasyfikowane do płatności nabierają szczególnego znaczenia
w kontekście monitorowania nadmiernego opóźnienia w płatnościach za transakcję handlową (towar lub usługę). Nie możemy pomijać ich bez uprzedniej analizy, bo wśród nich mogą znajdować się faktury wymagalne do zapłaty. Analiza takich przypadków jest zazwyczaj uciążliwa, wymaga „doklikiwania” do szczegółów danej pozycji i weryfikowania danych na fakturze. Znacznym ułatwieniem byłaby prosta lista pozycji z objaśnieniem przyczyny wyjątku oraz możliwość zbiorczego odblokowania i przypisania pozycji do istniejących przelewów lub utworzenia nowych płatności.
Mechanizmy akceptacji
Najczęściej proces obsługi przelewów jest tak zorganizowany, że płatności akceptowane są bezpośrednio w systemie bankowości elektronicznej przez dwie osoby, nierzadko z różnych komórek merytorycznych. Skutkuje to utrzymywaniem nadmiarowej ilości użytkowników i certyfikatów w bankowości elektronicznej. Proces mógłby zostać uproszczony poprzez przeniesienie jednego z etapów autoryzacji bankowej na poziom akceptacji propozycji bezpośrednio w SAP F110, gdyby taka funkcja była dostępna.
Blokowanie kontrahentów w propozycjach
Może mieć ono miejsce, w sytuacji, gdy spółka ma strukturę wielooddziałową rozproszoną geograficznie i reprezentowaną w SAP za pośrednictwem działów gospodarczych lub filii. Jeśli każdy oddział odpowiedzialny jest za „swoje” rachunki bieżące i zobowiązania, pracownicy poszczególnych filii regulując rozrachunki z różnego tytułu do tych samych dostawców będą się blokować. Wynika to z konstrukcji F110, gdzie
w otwartej propozycji płatniczej blokowany jest cały kontrahent, niezależnie od tego, że może być stroną transakcji w stosunku do różnych filii/DG w ramach danej jednostki gospodarczej. Rozwiązaniem byłoby w tym przypadku zakładanie blokady propozycji na poziomie pojedynczego dokumentu księgowego, a nie całego kontrahenta.
Formy płatności
W zależności od parametryzacji formatów płatniczych, spotykamy się często u Klientów z definiowaniem formy płatności dla każdego banku z osobna. Takie podejście skutkuje niepotrzebnym namnażaniem form płatności i trudnościami w późniejszym ich utrzymaniu, przypisaniu na fakturze i obsłudze podzielonej płatności. Rekomendujemy utrzymywanie form płatności w odniesieniu do sposobów realizacji płatności, np. przelew krajowy/SP, przelew walutowy/zagraniczny, przelew podatkowy (np. vat), polecenie zapłaty, karta płatnicza, gotówka, weksel etc. – dopiero formaty plików dzielimy na banki.
Generowanie i wysyłka pliku płatniczego do banku
Najczęściej w oprogramowaniu SAP mamy do czynienia z generowaniem plików tzw. płaskich (tekstowych), zapisywanych lokalnie lub na wskazanej lokalizacji sieciowej i następnie importowanie ich ręcznie do systemu bankowości elektronicznej. Oprócz systemowego braku kontroli nad ścieżkami w jakich zapisywane są pliki, mamy również dostęp do ich edycji. F110 umożliwia także wielokrotne generowanie plików dla tego samego przebiegu, co potencjalnie powodować może duplikacje nośników. Ponadto program nie weryfikuje czy suma przelewów w pliku zgadza się z sumą przelewów w przebiegu. W efekcie niekiedy w przypadku błędów w tworzonym pliku możemy doświadczyć rozbieżności pomiędzy danymi F110, a fizycznym plikiem płatniczym. Gdyby SAP kontrolował za nas te aspekty mielibyśmy większe poczucie bezpieczeństwa procesu, a gdyby ponadto umożliwiał bezpośrednią wysyłkę bezpiecznym kanałem podpisanych już plików do banku – w zasadzie użytkownicy nie musieliby się logować do bankowości elektronicznej. Zautoryzowane paczki przelewów trafiałyby od razu do realizacji przy najbliższej sesji wychodzącej.
Biała Lista KAS i mechanizm podzielonej płatności (Split Payment)
To już rozwiązania klienckie integrowane w określony sposób z SAP F110. Ze względu na ograniczenia rozszerzeń standardowego programu płatności, nierzadko informacje dotyczące podatników spoza białej listy bądź kwoty VAT w split payment są trudno dostępne dla użytkowników (np. poprzez log szczegółowy przebiegu płatności; kwota VAT widoczna tylko z poziomu podglądu pliku płatniczego). Informacje te można zaprezentować w zdecydowanie bardziej użytecznej formie, wykazując je wraz z pojedynczymi przelewami lub statystykami propozycji.
Czym skutkują wymienione problemy?
Wymienione bolączki często w dużych podmiotach skutkują ograniczeniem płatności do jednej sesji przelewowej w ciągu dnia o określonym cut-off time. W związku z tym trafiać mogą się faktury wymagalne dziś, a płacone w kolejnych sesjach, co ma natychmiastowy negatywny wpływ na wartość współczynnika świadczeń niespełnionych w terminie. Co może być rozwiązaniem?
Mając na względzie wszystkie opisane problemy opracowaliśmy autorskie rozwiązanie SAP Fintiera Payment Cockpit rozszerzające w efektywny sposób mechanizmy standardowego programu płatności. Dzięki uporządkowaniu, zautomatyzowaniu i przyspieszeniu procesu, obsługa płatności może odbywać się w kilku sesjach w ciągu dnia, dając komórkom merytorycznym elastyczne narzędzie do regulowania zobowiązań w terminie płatności. Szczegółowe porównanie funkcji kokpitu z możliwościami F110 opisujemy w artykule Standardowy program F110 a kokpit Fintiera. Z kolei rozwiązanie Fintiera Zatory Płatnicze spełnia wymagania Ustawy o Zatorach płatniczych, dopełniając nie tylko obowiązków sprawozdawczych dla dużych podmiotów, ale również umożliwiając raportowanie biznesowe własnych praktyk płatniczych. Dzięki niemu dowiemy się m.in. o bieżącej wartości świadczeń niespełnionych w terminie, czy o fakturach pozostających na ścieżce akceptacyjnej, których termin płatności za chwilę upłynie. Omówienie funkcjonalności tego narzędzia na tle standardowego raportu dostarczanego przez SAP dostępne jest na naszym blogu w materiale Fintiera Zatory Płatnicze vs standard SAP.
Autor: Bartosz Kozioł
