Płatności

Nowa płatność cykliczna

Formularz płatności cyklicznej zamienia powtarzalne zobowiązanie w kontrolowaną regułę. Operator wskazuje odbiorcę, rachunek, kwotę i harmonogram, a system dopiero w dniu wykonania tworzy zwykłą płatność wychodzącą.

Płatności cykliczne Schedulery

Formularz jako definicja przyszłej płatności

Dodanie płatności cyklicznej nie tworzy od razu przelewu. Formularz zapisuje wzorzec, z którego scheduler będzie później generował płatności. To pozwala utrzymać automatyzację bez rezygnowania z kontroli nad odbiorcą, rachunkiem, kwotą i statusem płatności.

Użytkownik zaczyna od typu płatności. Lista typów pochodzi z administracji i zawiera tylko te pozycje, które są dopuszczone do użycia w płatnościach cyklicznych. Dzięki temu operator nie wybiera przypadkowej kategorii, która nie powinna być powtarzana automatycznie.

Dane dokumentu i odbiorcy

Formularz wymaga numeru dokumentu, daty dokumentu, odbiorcy, kompletnego adresu oraz rachunku bankowego. Odbiorca jest wybierany przez wspólny komponent kontrahenta, więc można go wyszukać, dodać albo poprawić bez opuszczania procesu. Po wyborze kontrahenta system uzupełnia nazwę, NIP i adres.

Rachunek jest walidowany jako NRB. Pole rachunku korzysta z tych samych podpowiedzi co płatności wychodzące: można wykorzystać numery znane z wcześniejszych płatności, definicji cyklicznych i faktur zakupowych. To zmniejsza ryzyko ręcznego wpisania błędnego numeru.

Kwoty i MPP

Zakres pól zależy od wybranego typu płatności. Dla prostych zobowiązań operator wpisuje kwotę do zapłaty i powtarza ją w drugim polu. Dla typów wymagających pełnych kwot wpisuje netto i VAT, a brutto jest wyliczane. Dostępna jest też waluta oraz znacznik MPP, który ma sens tylko przy kompletnych danych podatkowych.

Powtórzenie kwoty nie jest dekoracją formularza. To świadomy mechanizm ograniczający przypadkową pomyłkę przy płatnościach, które mogą być później wykonywane automatycznie przez wiele miesięcy.

Harmonogram i potwierdzenie

Sekcja harmonogramu określa, kiedy reguła ma zacząć działać i jak długo ma być aktywna. Operator wpisuje datę pierwszej płatności, interwał i jednostkę czasu. Jednostkami są dni, tygodnie, miesiące oraz wariant minutowy używany do testowania automatyzacji.

Warunek zakończenia może być bezterminowy, liczbowy albo oparty o datę. Przy zakończeniu po liczbie wykonań system wymaga limitu. Przy zakończeniu po dacie wymaga daty końcowej. Formularz pokazuje błędy przy polach i pozwala kliknąć komunikat, żeby wrócić dokładnie do miejsca wymagającego poprawy.

Przed zapisem pojawia się dialog potwierdzenia. Zawiera odbiorcę, NIP, rachunek, dokument, kwotę, termin pierwszej płatności, interwał i warunek zakończenia. Dopiero po tym kroku reguła zostaje zapisana.

Edycja i powtarzanie

Ten sam formularz obsługuje dodawanie, edycję i powtórzenie zakończonej definicji. Edycja jest przeznaczona dla definicji przed pierwszym wykonaniem. Gdy definicja ma już historię, bezpieczniejszym wzorcem jest powtórzenie: stare dane dokumentu, odbiorcy i kwoty są zablokowane, a użytkownik ustawia nowy harmonogram.

Co robi scheduler po zapisaniu reguły

Zapisana reguła czeka na zadanie RecurringPaymentExecution. Job działa w tle i sprawdza definicje, których data następnej płatności jest dzisiaj lub minęła. Dla każdej należnej definicji tworzy płatność wychodzącą ze źródłem cyklicznym, buduje XML płatności, zapisuje historię wykonania i przesuwa datę następnego uruchomienia.

Proces jest celowo rozdzielony na definicję i wykonanie. Formularz odpowiada za poprawne dane wejściowe, a scheduler za moment wykonania. Dzięki temu automatyzacja nie zależy od tego, czy operator akurat otworzył stronę.

Wygenerowana płatność nie trafia do osobnego świata. Pojawia się w normalnym obiegu płatności wychodzących. Gdy Pekao Connect jest wyłączony, płatność startuje jako gotowa do eksportu. Gdy Pekao Connect jest aktywny, może wejść do kolejki bankowej i zostać wysłana tym samym mechanizmem co inne przelewy. Jeżeli dla odbiorcy są nierozliczone korekty, płatność zostaje wstrzymana, żeby użytkownik najpierw zdecydował o rozliczeniu.

Po wykonaniu definicja zwiększa licznik wykonań. Jeżeli osiągnięto limit albo datę końca, staje się nieaktywna. W przeciwnym razie dostaje kolejną datę zgodnie z interwałem.

Od formularza do płatności

%%{init: {"themeVariables": {"fontSize": "12px"}}}%%
flowchart TD
  A[Nowa płatność cykliczna] --> B[Typ płatności]
  B --> C[Dokument i odbiorca]
  C --> D[Rachunek i kwoty]
  D --> E[Harmonogram]
  E --> F{Walidacja formularza}
  F -- błędy --> G[Komunikaty przy polach]
  G --> C
  F -- poprawne --> H[Dialog potwierdzenia]
  H --> I[Zapis definicji]
  I --> J[Scheduler RecurringPaymentExecution]
  J --> K[Utworzenie płatności wychodzącej]
  K --> L[Historia wykonania]
  L --> M[Przesunięcie harmonogramu]

Bezpieczeństwo procesu

Czy po zapisaniu formularza przelew jest od razu wysyłany?

Nie. Formularz zapisuje definicję. Płatność powstaje dopiero przy wykonaniu schedulera, a jej dalszy status zależy od konfiguracji obiegu i Pekao Connect.

Dlaczego trzeba powtórzyć kwotę przy prostych płatnościach?

To zabezpieczenie przed literówką w kwocie, która może później tworzyć kolejne płatności automatycznie.

Co się dzieje z zakończoną definicją?

Definicja staje się nieaktywna. Można ją wykorzystać jako podstawę nowej reguły, ale wcześniejsze wykonania i utworzone płatności pozostają jako historia.