Znaczna część funkcjonalności obszaru FI systemu SAP to rozliczenia dotyczące kontrahentów, rozliczenia wewnątrzkorporacyjne, z pracownikami czy urzędami. Uprawniona osoba z działu finansowo-księgowego ma możliwość wygenerowania płatności bezpośrednio w systemie SAP poprzez pliki w narzuconym przez bank formacie, zaczytując je w systemie bankowym. Na tej podstawie dokonywane są przelewy bankowe.
W Polsce ogólnie przyjętym standardem dla przelewów krajowych jest Elixir-O, zaś do przelewów walutowych MT100. Jeśli jednak system bankowy klienta wymaga innego formatu danych, to program generujący plik w SAP jest odpowiednio dostosowywany.
Plik z płatnościami (nazywany Komputerowym Nośnikiem Danych – KND) to w istocie plik tekstowy (płaski) zawierający istotne dla przelewu dane o obciążanym rachunku, beneficjencie, kwocie, walucie, dacie przelewu itp. Następnym krokiem zamykającym proces płatności jest zaczytanie do systemu SAP wyciągu bankowego i rozliczenie wpływów i wypływów.
Tak w znacznym uproszczeniu w tradycyjnym modelu realizowane są płatności z SAP, zarówno w samodzielnych firmach, jak i w spółkach należących do grup kapitałowych. Tak też do niedawna obsługiwano ten proces w firmie Sitech, należącej do koncernu Volkswagen.
To dość wygodne rozwiązanie, w znacznym stopniu automatyzujące obsługę płatności, pozwalające na szybką i sprawną komunikację pomiędzy systemem SAP a dowolnym systemem bankowym.
Jednak grupy kapitałowe takie właśnie jak Volkswagen mają o wiele większe wymagania związane z podniesieniem efektywności zarządzania środkami pieniężnymi zarówno w zakresie rozliczeń z kontrahentami, jak i obrotu wewnętrznego. Decydując się na wspomaganie procesów biznesowych w systemie SAP, firma chce jak w największym stopniu wykorzystać jego możliwości. Jednym z umożliwiających to rozwiązań jest funkcjonalność banku wewnętrznego.
In-House Cash (IHC) dostępny w systemie SAP to jeden z komponentów FSCM (Financial Supply Chain Management). Umożliwia on utworzenie własnego, wewnętrznego banku, w ramach którego dokonywane są międzynarodowe płatności zobowiązań wszystkich spółek należących do grupy do podmiotów trzecich, jak również wzajemne rozliczenia pomiędzy spółkami grupy.
Wirtualny bank dla korporacji
W Grupie Volkswagen prace nad projektem uruchomienia centralnego banku wirtualnego trwają już od 2005 r. Początkowo bank działał dla kilku spółek. Sukcesywnie do wspólnej platformy dołączane są kolejne, takie jak Audi, Seat, Skoda. W 2011 r. dołączają kolejne spółki z Włoch, Polski, Słowacji i Wielkiej Brytanii.
Nie jest to jednak jedna centrala koncernowa, lecz kilka centr regionalnych obsługi (np. spółki polskie obsługiwane są przez GTP-2 w VW Group Services z siedzibą w Belgii). Opisywane rozwiązanie swoje główne zastosowanie znajduje w module zarządzania gotówką (Cash Management), zarządzania transakcjami (Transaction Management) i banku wewnętrznego (In-House Management).
Celem projektu jest zwiększenie efektywności zarządzania środkami finansowymi podmiotów z grupy poprzez optymalne wykorzystanie nadwyżek środków pieniężnych, zintegrowanie zarządzania procesami płatniczymi oraz automatyzację rozliczeń wewnątrzkoncernowych, rozliczeń będących skutkiem transakcji na rynku pieniężnym, jak i rozliczeń z pracownikami.
Grupa Volkswagen zdecydowała się wprowadzić centralny system do zarządzania płatnościami stopniowo we wszystkich swoich spółkach zależnych. W Spółce Sitech, która dołączyła do GTP-2 pod koniec 2011 r., z całego procesu wykluczone są płatności podatkowe i ZUS, jako że wymogiem polskiego ustawodawcy jest dokonanie zapłaty podatku bezpośrednio przez podatnika – zapłata dokonana przez inny podmiot w imieniu podatnika nie powoduje wygaśnięcia zobowiązania podatkowego tego podatnika.
B. Dominik, Specjalista ds. Finansowych, Sitech
Założenia koncepcyjne
Centralizacja płatności dokonywana jest w wirtualnym banku własnym koncernu – systemie GTP (Global Treasury Platform) opartym na rozwiązaniu SAP IHC.
Założenie podstawowe obejmuje automatyczne bilansowanie/pooling sald bankowych kont operacyjnych spółek na rachunek VGS na koniec każdego dnia roboczego, zgodnie z umowami zawartymi z bankami. Salda są zapisywane na dobro lub obciążają konto IHC (In-House Cash).
Komunikacja między lokalnymi systemami, VGS i bankiem zewnętrznym oparta jest na standardowym protokole RFC. Wymiana informacji takich jak płatności, wyciągi bankowe i dokumenty TR pomiędzy systemami odbywa się przy użyciu IDOC-ów (Intermediate documents, standardowy format SAP) poprzez połączenie ALE.
Koncepcja rozwiązania przygotowana została przez zespół roboczy Sitech, natomiast firma BCC (aktualnie All for One Poland) realizowała wsparcie techniczne, wprowadzenie zmian konfiguracyjnych i programistycznych w systemie, wsparcie w fazie testów oraz w trakcie i po starcie produktywnym.
IDOC i typy płatności
Komunikacja pomiędzy lokalnym systemem SAP a systemem VGS przebiega przy użyciu IDOC-ów. Wykorzystane zostały trzy typy standardowych IDOC-ów:
- PAYEXT – zlecenia płatności,
- FINSTA – wyciągi bankowe,
- FIDCC2 – dane transakcji finansowych (księgowania FI/TM).
Przejście z plików tekstowych na IDOC-i wiąże się z podpięciem innego (standardowego) programu do generowania nośnika KND, a sama struktura IDOC-a musiała być odpowiednio zasilana danymi i przekazana do VGS. Wiązało się to z uruchomieniem kilku standardowych rozszerzeń.
Wskutek zmiany organizacji wyróżnione zostały cztery typy płatności:
- płatność wewnętrzna (w Global Treasury Platform): płatność na rzecz spółek przyłączonych do GTP,
- płatność koncernowa: płatność na rzecz spółek należących do koncernu VW (spółki spoza GTP),
- płatność krajowa:zlecenia w złotówkach i w walucie wysyłane do banku w kraju,
- płatność zagraniczna: zlecenia wysyłane do banków za granicą.
Trzeba tu jednak zaznaczyć, że podział na płatności krajowe i zagraniczne nie jest tak jednoznaczny, jak w sytuacji poprzednio obowiązującej. Rozpatrywać tu również należy punkt widzenia VGS. Tak więc płatność w EUR dla spółki niemieckiej należy uważać za płatność krajową, tyle że dokonaną w Niemczech, ponieważ VGS dysponuje swoim kontem bankowym w tym kraju. Jest to informacja istotna, ponieważ od tego podziału zależy czas realizacji przelewu, a także jego koszt.
W zależności od rodzaju płatności różne dane bankowe musiały trafić do IDOC-a, wskutek czego należało poprawić część danych podstawowych kontrahentów w zakresie numerów rachunków. Tylko poprawne dane skutkują faktycznym dokonaniem płatności.
Wygenerowanie nośnika płatności powoduje jego automatyczne przesunięcie na maszynę VGS. Użytkownik nie musi się logować do systemu bankowego i wciągać pliku – o ile wygenerowane dane (zwłaszcza dane bankowe) są prawidłowe, jego praca w obrębie płatności na tym się kończy.
Wskutek braku podwójnej akceptacji płatności w systemie, co zazwyczaj ma miejsce w systemach bankowych, w celu podniesienia bezpieczeństwa przygotowane zostało rozwiązanie zetowe do zatwierdzeń płatności.
Procedury i bezpieczeństwo
Dodatkowo została uruchomiona inna funkcjonalność SAP – płatności Free Form dla HR, w której można podać dowolną kwotę, ponieważ nie wynika ona z zaksięgowanych dokumentów (żądanie zaliczki) i księgowana jest na kontach KG, co z kolei pozwala dokonać płatności osobowych bez widocznej po stronie FI informacji, do kogo został wygenerowany przelew. Generowane tą drogą IDOC-i również przekazywane są do VGS. Ten rodzaj płatności wykorzystywany jest głównie do realizacji wypłat dla pracowników, które nie mogą zostać wygenerowane automatycznie.
Generowanie płatności przez spółki grupy wiąże się z zachowaniem pewnego rodzaju procedury. Po pierwsze przebiegi płatności powinny być przygotowane na tyle wcześnie, aby do godz. 13 wszystkie IDOC-i z płatnościami były już na systemie VGS (liczy się godzina wpływu IDOC-ów na platformę!). Po tej godzinie następuje bowiem fizyczna realizacja przelewów przez VGS i dalej przez bank zewnętrzny.
Po drugie, jako że system VGS znajduje się w belgijskiej spółce koncernu, procedura musi uwzględniać święta i dni wolne w tym kraju, które mogłyby opóźnić dokonanie płatności. W przypadku wystąpienia zagrożenia terminowości realizacji przelewów dana spółka uzgadnia z VGS sposób postępowania (dostępność personelu w dniach wolnych od pracy).
Innym elementem podnoszenia bezpieczeństwa przesyłu danych w IDOC-ach było zbudowanie szyfrowanego kanału VPN do komunikacji pomiędzy systemem SAP Sitechu i systemem VGS korporacji.
Elektroniczne wyciągi
Kolejna funkcjonalność objęta projektem GTP to elektroniczne wyciągi bankowe. Wyciągi z lokalnych kont bankowych są przesyłane automatycznie do VGS, a w kolejnym kroku przekazywane z VGS automatycznie bez zmian do lokalnych systemów SAP za pomocą IDOC-ów FINSTA. Wyciągi są zaczytywane automatycznie, ale księgowanie pozostaje po stronie lokalnych użytkowników.
Obok wyciągów zewnętrznych spółki grupy otrzymują wyciągi wewnętrzne dla konta głównego IHC na bazie pojedynczych pozycji w formie FINSTA IDOC. Dla subkont dotyczących płatności personalnych nie wpływają wyciągi szczegółowe (dane chronione), te księgowania widoczne są w jednej kwocie jako koncentracja środków z subkonta P (płatności personalne) na konto główne A. Przygotowana została największa możliwa automatyzacja wyciągów bankowych, tak więc ingerencja pracownika Sitech jest tylko konieczna tam, gdzie brak jest bezpośredniego przyporządkowania do pozycji, np. przy wpływie gotówki, przy zwrotach. Także wyciągi FIDCC2 księgowane są automatycznie i nie wymagają interwencji.
Obsługa płatności po nowemu
Obecnie wszystkie płatności dla dostawców oraz pomiędzy spółkami grupy odbywają się poprzez bank własny, co pozwoliło zlikwidować rachunki do obsługi dostawców w innych bankach. Jedyne płatności, które Sitech wykonuje bezpośrednio poprzez system bankowy, to przelewy podatkowe oraz do ZUS, gdzie prawo wymaga, by bezpośrednim płatnikiem był podatnik.
Z punktu widzenia użytkownika końcowego w zasadzie nic się nie zmienia w zakresie kroków wykonanych w systemie SAP. Należy kolejno przygotować parametry, propozycję płatności i na końcu samą płatność z wygenerowaniem nośnika. Propozycja płatności musi być zatwierdzona przez osobę (osoby) trzecią. Ponieważ standardowo taki akcept dokonywany jest już po stronie systemu bankowego, we wdrożonym rozwiązaniu należy wykonać dodatkowe kroki, zapewniające tę samą funkcjonalność po stronie systemu SAP.
Generując nośnik, użytkownik musi pamiętać, że automatycznie jest on wysyłany do systemu VGS, a jego wycofanie jest nieco skomplikowane (konieczne zlecenie podpisane przez osoby upoważnione, zgłoszone w VGS). Lista płatności z SAP jest przesyłana do VGS średnio dwa razy w tygodniu – jako część korporacji VGS także korzysta z systemu SAP, lista płatności nie musi być więc przekazywana w formie pliku płaskiego, ale za pomocą IDOC. Dopiero zbiorczo, z wszystkich przelewów tworzone są paczki z płatnościami dla banku obsługującego koncern (Citi Bank).
Płatności realizowane są zgodnie z ustalonym w pliku terminem płatności i realizacja zlecenia powoduje wyksięgowanie środków w dzień realizacji. Salda na rachunkach są codziennie poolowane na konto główne VGS (również z rachunków zewnętrznych). Na koniec każdego miesiąca spółka otrzymuje zestawienie środków, które nie zostały ulokowane na lokatach terminowych, wraz z należnymi odsetkami liczonymi jak dla formy overnight.
Z kolei płatności wewnątrzkorporacyjne to faktycznie przeksięgowania pomiędzy kontami Księgi Głównej. W ten sposób dokonywany jest przepływ wirtualnej gotówki.
Walutą transakcyjną jest PLN. Wszystkie wpływy walutowe są przeliczane po kursie Europejskiego Banku Centralnego z chwilą poolowania. Część płatności Sitech wykonuje w złotówkach. Jeśli płatność jest dokonywana w walucie obcej, następuje przeliczenie po kursie dnia ECB. A zatem przeliczenia walutowe dokonywane jednego dnia nie powodują powstania różnic kursowych.
Joanna Bachorska, Kierownik rachunkowości, Sitech
Zarabiamy dzięki efektowi skali
W miarę rozwoju grupy kapitałowej Volkswagen zmagał się z brakiem przejrzystości w strukturze rachunków w grupie, nieefektywnym alokowaniem środków, niekontrolowanym wykorzystaniem kredytów przez spółki zależne oraz zawyżaniem poziomu kosztów finansowych. Aby temu zapobiec, stworzone zostało rozwiązanie systemowe GTP (Global Treasury Platform) na bazie systemu SAP. Jego zadaniem była centralizacja funkcji treasury oraz optymalizacja procesów w poszczególnych spółkach. Dzięki wykorzystaniu cash poolingu Volkswagen ma możliwość bilansowania nadwyżek i niedoborów gotówkowych w ramach grupy oraz uzyskania kompletnej informacji o stanach gotówki, wartości wykorzystania kredytów i ich dostępności.
Prace nad wdrożeniem rozwiązania GTP w Sitech rozpoczęły się ponad rok przed produktywnym startem. Z uwagi na kompleksowość tego zagadnienia, niezbędne okazało się zaangażowanie w proces wdrożenia nie tylko pracowników treasury, ale i zespołu księgowego, podatkowego, pracowników działu personalnego, doradców podatkowych, informatyków, firmy wdrożeniowej – w naszym przypadku BCC (aktualnie All for One Poland) – tworząc zespół, wyznaczając zadania i dzieląc odpowiedzialność.
Ponieważ w polskim prawodawstwie nadal nie ma jednoznacznej definicji cash poolingu, najwięcej czasu pochłonęła klasyfikacja rozwiązania i poszczególnych operacji finansowych pod względem prawa podatkowego i bilansowego, łącznie z uzyskaniem indywidualnej interpretacji organu podatkowego. Implementacja rozwiązania cash poolingu wiązała się oczywiście z modyfikacjami systemu ERP. Konieczna była również zmiana schematów księgowania operacji bankowych w księdze głównej.
Jednak pozytywne efekty zastosowania cash poolingu można zaobserwować już w kilka dni po uruchomieniu funkcjonalności. Na zlecenie spółki bank jest wykonawcą operacji transferu sald gotówkowych, przez co proces ten jest automatyczny i nie wymaga zaangażowania i działań po naszej stronie. Większość operacji związanych z obrotem płatniczym księgowana jest teraz automatyczne, łącznie z zaczytywaniem wyciągów i księgowaniami na konta księgi głównej.
Dzięki ograniczeniu liczby kont bankowych ich struktura stała się przejrzysta, a przejęcie przez VGS funkcji banku ograniczyło konieczność współpracy z kilkoma bankami zewnętrznymi. Wykorzystując efekt skali, jaką daje Volkswagen, spółka może uzyskiwać obecnie większe korzyści finansowe, np. z lokowania wolnych środków pieniężnych. Dodatkowym atutem wdrożenia tego rozwiązania była możliwość zoptymalizowania wewnętrznych procesów księgowych, finansowych i organizacyjnych.
Joanna Bachorska, Kierownik rachunkowości, Sitech Sp. z o.o.
Także przelewy płacowe
Oprócz rozliczeń z kontrahentami za pośrednictwem GTP realizowane są wszystkie przelewy płacowe: wynagrodzenia, umowy-zlecenia, zajęcia komornicze.
W ramach projektu konieczne było dostosowanie form płatności w SAP do wymagań GTP. Dokonano także w konfiguracji zmiany konta, z którego realizowane są wypłaty wynagrodzeń, zajęć sądowych i komorniczych.
Dodatkowo wprowadzono także możliwość definiowania daty realizacji przelewu (do 5 dni). Dzięki temu rozliczenie listy płac w systemie i wydanie dyspozycji przelewu nie musi być ściśle powiązane z datą wypłat pracowniczych.
Oprócz zmiany banku obsługującego przelewy pracownicze, w ramach projektu wprowadzono także nową procedurę zatwierdzania przelewów. Zgodnie z wymaganiami bezpieczeństwa i najlepszymi praktykami (m.in. ustawą SOX) przyjęto zasadę kilkustopniowej kontroli. Przede wszystkim osoba przygotowująca listę płac i polecenie przelewu nie ma obecnie uprawnień do jego zatwierdzenia w systemie. Konieczne jest zaangażowanie innego uprawnionego uczestnika procesu. Taka co najmniej dwustopniowa kontrola zwiększa bezpieczeństwo i jest zgodna z polityką koncernu VW.
Prace projektowe nie charakteryzowały się dużą pracochłonnością dla osób odpowiedzialnych za płace w Sitechu mimo dużej liczby pracowników – ok. 1600 osób. Już po uruchomieniu nowego rozwiązania bankowego praca działu płac wygląda podobnie jak dotychczas. Rozliczenie listy płac jest realizowane bez zmian. Dopiero przygotowując paczkę z przelewami, pracownik zamiast pliku tekstowego generuje IDOC oraz wprowadza datę przelewu (nie wcześniej niż następnego dnia, nie później niż za 5 dni) – czego nie robiono poprzednio.
Zgodnie z przyjętą procedurą, następuje zatwierdzenie przelewu przez uprawnionego pracownika.
Nowością jest możliwość „podglądania” zatwierdzonych przelewów w systemie bankowym VGS – co stanowi dodatkową kontrolę poprawności naliczeń. W systemie bankowym VGS w przypadku płatności personalnych (nie dotyczy FI) istnieje możliwość usunięcia płatności. Jest to funkcja dostępna tylko dla upoważnionych pracowników HR.
Podsumowanie
Mówiąc o wdrożeniu platformy GTP, należy z pewnością uwzględnić poniższe zagadnienia:
- Zgromadzenie środków finansowych wielu spółek powoduje to, że VGS posiada potężną kartę przetargową w pertraktacjach z bankami. Wymierne skutki tego widoczne są na miesięcznych zestawieniach odsetek uzyskanych z lokat typu overnight i lokat długoterminowych.
- Ponieważ VGS posiada konta w wielu bankach europejskich, przelewy zagraniczne traktowane są najczęściej jako krajowe, a to z kolei zmniejsza koszty obsługi.
- Program do obsługi IHC posiada kilka funkcji planowania. Można tu wprowadzić planowane na poszczególne dni obroty, można również uwzględniać na bieżąco istniejące w systemie informacje dotyczące wychodzących i powracających lokat.
- Wymuszone przez GTP planowanie jest korzystne przede wszystkim dla Sitech Sp. z o.o., ponieważ sama spółka posiada w tym momencie bardzo dobre narzędzie kontroli i planowania środków finansowych.
- Sposób księgowania płatności personalnych (dla pracowników FI widoczna jest tylko jedna kwota poolowania z danego dnia) wymusza regularne uzgadnianie zobowiązań z tego tytułu.
- Przejęcie funkcji banku przez VGS powoduje centralizację kontaktów bankowych.
- Platforma GTP uprościła płatności pomiędzy spółkami GTP-2, jak i pozostałymi spółkami koncernowymi.
- Wdrożenie platformy – jak to wyraźnie widać powyżej – przynosi wymierne korzyści nie tylko koncernowi, są to również korzyści, i to nie małe, dla spółki Sitech.