Płatności

Cykliczne

Widok płatności cyklicznych porządkuje stałe zobowiązania, które nie powinny być co miesiąc przepisywane ręcznie. Operator pracuje na definicjach, a system w odpowiednim dniu tworzy zwykłe płatności wychodzące, widoczne później w obiegu płatności nadchodzących.

Widok definicji płatności

Strona Płatności cykliczne jest listą reguł, a nie listą przelewów. Każdy wiersz opisuje szablon: typ płatności, numer dokumentu, odbiorcę, kwotę, termin następnego wykonania, interwał, warunek zakończenia i aktywność definicji.

To rozróżnienie jest ważne operacyjnie. Użytkownik nie zastanawia się, czy stała płatność została już ręcznie przepisana. Widzi, kiedy definicja wykona się następnym razem, czy nadal jest aktywna i ile razy została już użyta. Pozycje nieaktywne są przygaszone, a termin przypadający dzisiaj lub wcześniej jest wyróżniony, żeby łatwo zauważyć zaległy harmonogram.

Co widać w tabeli

  • Typ wynika z typów płatności dostępnych dla cyklicznych zobowiązań.

  • Dokument przechowuje tytuł lub numer zobowiązania, który trafi później do wygenerowanej płatności.

  • Odbiorca jest powiązany ze słownikiem kontrahentów, ale definicja zapisuje komplet danych potrzebnych do płatności.

  • Kwota pokazuje wartość brutto, która będzie użyta przy kolejnym wykonaniu.

  • Następna mówi, kiedy scheduler powinien utworzyć kolejną płatność wychodzącą.

  • Interwał opisuje rytm: minuty testowe, dni, tygodnie albo miesiące.

  • Zakończenie pokazuje, czy definicja działa bezterminowo, kończy się po liczbie wykonań albo po dacie.

Akcje wiersza

Menu trzech kropek trzyma operacje przy konkretnej definicji. Akcja Edytuj jest dostępna tylko wtedy, gdy definicja nie została jeszcze wykonana. Po pierwszym wykonaniu dane finansowe i odbiorca mają już historię, więc system zamiast swobodnej edycji pozwala użyć akcji Powtórz dla zakończonej definicji. Powtórzenie tworzy nową regułę na podstawie poprzedniej, ale z nowym harmonogramem.

Akcja Usuń usuwa definicję, ale nie usuwa płatności, które już zostały przez nią utworzone. To oddziela konfigurację przyszłości od dokumentów historycznych.

Historia wykonań pod wierszem

Kliknięcie wiersza rozwija historię wykonań danej definicji. Operator widzi numer wykonania, datę wykonania, kwotę, dokument, referencję wygenerowanej płatności i następny zaplanowany termin.

Dzięki temu strona pełni dwie funkcje naraz: pokazuje aktualny harmonogram i daje ślad po tym, co automat faktycznie utworzył. Referencja płatności pozwala przejść myślowo od definicji do konkretnej pozycji w obiegu płatności wychodzących, bez mieszania obu pojęć w jednej tabeli.

Dlaczego to ma znaczenie

W stałych zobowiązaniach najczęstszy problem nie polega na samym wpisaniu przelewu, tylko na utrzymaniu kontroli: czy płatność została utworzona, czy harmonogram przesunął się dalej i czy reguła nie działa po terminie końcowym. Historia wykonania odpowiada na te pytania bez zaglądania do logów technicznych.

Scheduler tworzący płatności

Za automatyczne wykonywanie definicji odpowiada zadanie RecurringPaymentExecution. Job pobiera aktywne definicje, których data następnej płatności jest dzisiaj lub wcześniej. Dla każdej definicji tworzy płatność wychodzącą, zapisuje log wykonania i przesuwa harmonogram.

Wykonanie pojedynczej definicji jest objęte transakcją. Utworzenie płatności, zapis historii wykonania i aktualizacja następnej daty muszą zapisać się razem. To zabezpiecza system przed sytuacją, w której powstałaby płatność, ale harmonogram nie zostałby przesunięty i przy następnym uruchomieniu utworzyłby duplikat.

Status startowy wygenerowanej płatności zależy od konfiguracji bankowej i ryzyk biznesowych. Gdy Pekao Connect nie jest aktywny, płatność trafia do stanu gotowego do eksportu. Gdy Pekao Connect działa, płatność może wejść do kolejki bankowej, a jeśli dla odbiorcy istnieją nierozliczone korekty, zostaje wstrzymana do decyzji, żeby nie wysłać przelewu przed rozliczeniem korekty.

Po udanym zapisie job może wysłać powiadomienie e-mail albo SMS według konfiguracji w administracji. Jeżeli płatność trafiła do kolejki bankowej, używany jest ten sam mechanizm wysyłki co w pozostałych płatnościach, więc ścieżka cykliczna nie tworzy osobnego, równoległego procesu bankowego.

Wykonanie płatności cyklicznej

%%{init: {"themeVariables": {"fontSize": "12px"}}}%%
flowchart TD
  A[Aktywna definicja] --> B{Data następnej płatności}
  B -- przyszłość --> C[Pomiń do kolejnego uruchomienia]
  B -- dziś lub wcześniej --> D[Utwórz płatność wychodzącą]
  D --> E[Zapisz historię wykonania]
  E --> F[Wylicz kolejny termin]
  F --> G{Warunek zakończenia}
  G -- osiągnięty --> H[Dezaktywuj definicję]
  G -- nieosiągnięty --> I[Zostaw aktywną]
  H --> J[Commit transakcji]
  I --> J
  J --> K{Status płatności}
  K --> L[Gotowa do eksportu]
  K --> M[W kolejce do banku]
  K --> N[Wstrzymana przez korekty]

Praktyczne pytania

Czy definicja cykliczna jest przelewem?

Nie. Definicja jest regułą. Dopiero scheduler tworzy z niej realną płatność wychodzącą.

Czy wygenerowana płatność omija zatwierdzanie i statusy?

Nie. Płatność trafia do tego samego procesu co inne płatności wychodzące. Jej status startowy wynika z konfiguracji Pekao Connect i kontroli korekt.

Co oznacza nieaktywna definicja?

Harmonogram został zakończony albo definicja została wyłączona przez osiągnięcie limitu. Historyczne płatności pozostają w obiegu i w raportach.