Mechanizm Podzielonej Płatność w kontekście systemu SAP

Z dniem 1 lipca 2018 roku w Polsce została wprowadzona nowa regulacja prawna zwana Mechanizmem Podzielonej Płatności w skrócie MPP (ang. Split Payment – SP). Ponieważ te nazwy już istnieją w naszej rzeczywistości gospodarczej, będziemy ich obu używać. Sam mechanizm MPP polega na tym, że płatność dokonywana za towar lub usługę jest dzielona pomiędzy dwa rachunki bankowe dostawcy. Wartość netto jest płacona przez nabywcę na pierwszy rachunek bankowy dostawcy, a kwota podatku VAT trafia na drugi, na dedykowane konto VAT. Samo konto VAT jest tworzone nieodpłatnie przez bank, w którym kontrahent posiada swój rachunek rozliczeniowy.

W założeniach mechanizm jest dobrowolny, jednak jest to dobrowolność pozorna, wynikająca z faktu, że stroną decydująca jest tutaj kupujący towar lub usługę (nabywca). Dostawca nie może nie przyjąć płatności z wykorzystaniem mechanizmu Split Payment. Minister Finansów nie wyklucza jednak możliwości regulacji na poziomie umów cywilnoprawnych pomiędzy kontrahentami. W praktyce oznacza to, że dostawca może w umowie z nabywcą zaznaczyć, że nie godzi się na płatność w formie Split Payment i taka adnotacja jest zgodna z polskim prawem.

Głównym celem MPP jest ograniczenie wyłudzeń podatkowych. Realizacja tego założenia jest możliwa dzięki temu, że kontrahent posiada bardzo ograniczony dostęp do dedykowanego konta (lub kont) VAT. W sytuacji, gdy właściciel rachunku VAT chciałby przelać część środków pieniężnych z rachunku VAT na swoje konto rozliczeniowe wymagane jest złożenie wniosku do naczelnika urzędu skarbowego. Na rozpatrzenie wniosku urzędnik ma aż 60 dni i istnieją okoliczności, w których może odrzucić prośbę. Od takiej decyzji można się oczywiście odwołać. W praktyce, dla wielu firm może to oznaczać potencjalne problemy z płynnością finansową z racji ograniczonych możliwości dyspozycji środkami pieniężnymi na rachunku VAT.

Warto zaznaczyć, że ciężar faktycznego podziału płatności na kwotę netto, która trafia na rachunek dostawcy i kwotę VAT, która trafia na dedykowany rachunek VAT leży po stronie banku. W tym miejscu pojawia się jednak kwestia odpowiedniego przygotowania nośnika płatności, który zostanie przekazany do banku, z którego płacimy. Ten obowiązek spoczywa już po stronie użytkowników systemu SAP. Dodatkowo warto zauważyć, że Split Payment w pewien sposób utrudnia proces płatności z racji tego, że nie obsługuje płatności zbiorczych, oznacza to, że 1 faktura SP = 1 przelew bankowy, a więc tym samym 500 faktur SP = 500 przelewów bankowych.

W związku z powyższymi założeniami jednym z pierwszych kroków związanych z dostosowaniem systemu SAP do mechanizmu MPP powinna być analiza sposobu generowania nośnika płatności. Niektóre firmy używają starszego nośnika, opartego na specjalnie dedykowanym programie do płatności. Wadą tego programu jest niewspieranie go przez SAP AG od 2005 roku. Nowsze podejście opiera się wykorzystaniu mechanizmu Payment Medium Workbench (w skrócie: PMW). PMW wykorzystuje z kolei Data Medium Exchange Engine (w skrócie: DMEE), czyli narzędzie pozwalające na łatwe tworzenie i zarządzanie formatami nośników płatności.

Sposób generowania płatności jest o tyle istotny, że determinuje opcje, jakie możemy wykorzystać przy dostosowaniu systemu SAP. Klienci wykorzystujący starszą metodę generowania nośnika płatności, z racji braku wsparcia ze strony SAP AG zmuszeni są dostosować swój system indywidualnie z pomocą wykwalikowanych firm z obszaru consultingu IT. Zakres pracy w takim przypadku zakłada m.in. dobudowanie do standardowego programu generującego nośnik płatności dodatkowej funkcjonalności (include), która pozwoli na wygenerowanie nośnika płatności zawierającego wszystkie potrzebne informacje. Komunikat przelewu musi zawierać w sobie informację o:

  • kwocie sprzedaży brutto (lub jej części),
  • kwocie podatku VAT (lub jej części),
  • numerze faktury, której dotyczy płatność podzielona,
  • numerze NIP dostawcy.

W przypadku klientów wykorzystujących PMW możliwe jest wykorzystanie oficjalnego rozwiązania do obsługi Split Payment. Jego implementacja odbywa się za pomocą specjalnych not (patrz: nota SAP 2607042), które zawierają w sobie potrzebne instrukcje. SAP aktywnie wspiera swoje rozwiązania i często po ich udostępnieniu publikuje również różnego rodzaju modyfikacje, udogodnienia i poprawki. Podobnie jest w przypadku mechanizmu Split Payment, warto więc być na bieżąco. Bardzo dobre centrum informacji stanowi nota 2654294, która w formie FAQ (Frequently Asked Questions = zbiór najczęściej zadawanych pytań wraz z odpowiedziami) jasno i czytelnie wyjaśnia najistotniejsze kwestie związane z implementacją rozwiązania. Dodatkowo warto pamiętać o tym, że przy implementacji not SAP-owych bardzo istotna jest kolejność wgrywania oraz kolejności czynności wykonywanych w ramach konkretnych not. Tak więc aby uniknąć niepotrzebnych trudności przed podjęciem jakichkolwiek prac warto dokładnie przeanalizować oficjalny FAQ.

Oficjalne SAP-owe rozwiązanie zostało przygotowane z myślą o najpopularniejszym w Polsce formacie ELIXIR. Nie wszystkie polskie banki z niego korzystają. W związku z tym, jeżeli nasz bank wykorzystuje format inny niż ELIXIR np.: MTMS to wtedy implementacja not nie przyniesie oczekiwanego rezultatu. W takiej sytuacji konieczne będzie indywidualne dostosowanie systemu.

Tak więc nowa funkcjonalność musi zapewnić wszystkie powyższe informacje i wbudować je w nośnik płatności zgodnie z jego specyfikacją. Sam proces dostosowania wymaga analizy konfiguracji banków klienta i weryfikacji standardów, z jakich te banki korzystają.

Poza obsługą płatności wychodzących pozostaje jeszcze kilka innych istotnych obszarów. Jednym z nich jest kwestia wyciągów bankowych, do których należy dobudować obsługę operacji związanych z mechanizmem podzielonej płatności. Kolejną kwestią jest możliwość kontroli, którzy kontrahenci mają być włączeni, a którzy wyłączeni z mechanizmu MPP. Jest to o tyle istotne, że na mocy umowy możemy być zobowiązani do niepłacenia danemu kontrahentowi mechanizmem podzielonej płatności. Opcja wyłączenia takiego kontrahenta ze SP znacznie ogranicza ryzyko pomyłki. Finalnie pozostaje jeszcze kwestia raportowania, dzięki któremu firma będzie w stanie szybko i wygodnie przenalizować komu i ile płaci z wykorzystaniem MPP. Najczęściej na potrzeby tego wymagania tworzony jest dedykowany Z-towy (kliencki) raport prezentujący wszystkie wymagane informacje.

Resumując, stopień trudności dostosowania systemu SAP pod obsługę mechanizm podzielonej płatności w dużej mierze zależy od specyfiki konkretnego klienta. Jakiekolwiek prace powinny więc zostać poprzedzoną rzetelną analizą biznesową ze szczególnym uwzględnieniem bankowości. Nierzadko taki proces będzie wymagał wsparcia wykwalifikowanych konsultantów.

Komentarz o “Mechanizm Podzielonej Płatność w kontekście systemu SAP

  1. Cześć,
    Dobrze napisana kwintesencja zagadnienia. W ramach realizacji zadania utworzyliśmy szczegółową KB (opisującą przypadki podstawowe i szczególne), instrukcję operacyjną dla użytkownika oraz wytyczne biznesowe. Utworzone rozwiązanie powinno umożliwiać pełną kontrolę płacenia kwot VAT (od rejestracji zobowiązania, przez żądania płatności aż do rozliczenia) oraz raportowanie kwoty VAT możliwej do zapłacenia MPP, zapłaconej MPP i spodziewanej płatności MPP.
    Pozdrawiam Rafał Kisiel

Zostaw komentarz

This site uses Akismet to reduce spam. Learn how your comment data is processed.