I. Szczegółowy opis przedmiotu zamówienia zadanie Uruchomienie e-usług finansowych

Transkrypt

1 Załącznik nr do specyfikacji istotnych warunków zamówienia na wykonanie zadań w ramach projektu pn. "CYFROWA BLACHOWNIA zwiększenie dostępu obywateli i przedsiębiorców Gminy BLACHOWNIA do cyfrowych usług Publicznych", realizowanego w ramach Regionalnego Programu Operacyjnego Województwa Śląskiego na lata (Europejski Fundusz Rozwoju Regionalnego) dla osi priorytetowej: II. Cyfrowe śląskie dla działania: 2.1. Wsparcie rozwoju cyfrowych usług publicznych. SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA W ZAKRESIE OPROGRAMOWANIA: SYSTEM FINANSOWO-KSIĘGOWY, PORTAL INFORMACYJNO-PŁATNICZY ORAZ KONFIGURACJA E-USŁUG NA PLATFORMIE EPUAP Strona 1 z 41

2 Spis treści Spis treści... 2 I. Szczegółowy opis przedmiotu zamówienia zadanie Uruchomienie e-usług finansowych 3 a. Zakup licencji zintegrowanego systemu dziedzinowego ) Architektura systemu i wymagania niefunkcjonalne ) Wymagania licencyjne ) Wymagania funkcjonalne dla systemu zintegrowanego... 5 b. Wdrożenie zintegrowanego systemu dziedzinowego i asysta techniczna c. Zakup licencji portalu informacyjno-płatniczego ) Architektura systemu i wymagania niefunkcjonalne ) Wymagania funkcjonalne portalu informacyjno-płatniczego d. Wdrożenie portalu informacyjno-płatniczego i asysta techniczna e. Integracja systemów informatycznych f. Opracowanie i wdrożenie e-usług na platformie epuap i SEKAP II. Szczegółowy opis przedmiotu zamówienia zadanie Wdrożenie e-usług publicznych dla urzędu a. Audyt obecnie istniejących procedur i dokumentów dotyczących elektronizowanych e- usług b. Przygotowanie ustandaryzowanych projektów dokumentów niezbędnych przy świadczeniu e-usług c. Przygotowanie formularzy e-usług d. Konfiguracja ESP na epuap w zakresie świadczonych e-usług e. Stworzenie projektów aktualizacji wewnętrznych procedur i regulaminów f. Audyt i aktualizacja polityki bezpieczeństwa i dokumentacji ochrony danych osobowych g. Audyt i aktualizacja instrukcji zarządzania systemem informatycznym Strona 2 z 41

3 I. Szczegółowy opis przedmiotu zamówienia zadanie Uruchomienie e-usług finansowych a. Zakup licencji zintegrowanego systemu dziedzinowego 1) Architektura systemu i wymagania niefunkcjonalne 1. System musi być zbudowany w architekturze klient-serwer lub architekturze trójwarstwowej, w oparciu o bazę danych SQL typu Open Source, posiadającą wsparcie techniczne producenta. Zamawiający dopuszcza rozwiązanie oparte na komercyjnym systemie bazodanowym, ale w takim przypadku Wykonawca musi doliczyć koszt zakupu licencji bazy komercyjnej oraz dostępów do serwerów na nieograniczoną ilość użytkowników. 2. System musi działać w środowisku zintegrowanych baz danych posiadającym następujące cechy: a. relacyjność i transakcyjność, b. komunikacja z aplikacjami w standardzie SQL. 3. System musi posiadać budowę modułową i stanowić kompletny, kompleksowy zintegrowany system zarządzania. Wymagane jest wzajemne współdziałanie aplikacji programowych poprzez powiązania logiczne i korzystanie ze wspólnych danych przechowywanych w serwerze bazy danych. 4. Dostarczone moduły dziedzinowe muszą pracować na jednym silniku bazy danych. System musi być zintegrowany pod względem przepływu informacji - informacja raz wprowadzona do systemu jest wykorzystywana w pozostałych modułach dziedzinowych. 5. System musi zapewniać pracę w środowisku klastrowym serwerów aplikacji bazodanowych. 6. System musi pracować na sieciowych systemach operacyjnych funkcjonujących na sprzęcie stosowanym w projekcie, tj.: MS Windows Serwer oraz Linux. 7. System musi działać poprawnie na komputerach (stanowiskach roboczych) z systemami operacyjnymi funkcjonującymi na sprzęcie stosowanym w projekcie, tj.: MS Windows XP/VISTA/ 7 / 8 / 10 bądź równoważnymi. 8. System musi działać w dowolnej sieci komputerowej w standardzie TCP/IP. 9. System musi zapewniać spójność i integrację, informacje raz wprowadzone w którymkolwiek z modułów muszą trafiać wszędzie tam, gdzie są wymagane oraz możliwy jest elektroniczny transfer danych. 10. System musi zapewniać elastyczność i daleko posuniętą parametryzację - dostępną dla użytkownika lub administratora. 11. System musi umożliwiać definiowanie dowolnej ilości użytkowników. 12. System musi być w całości polskojęzyczny. 13. System musi posiadać graficzny interfejs użytkownika gwarantujący wygodne wprowadzanie danych, bieżącą kontrolę poprawności wprowadzanych danych, przejrzystość prezentowania danych na ekranie oraz wygodny sposób wyszukiwania danych po dowolnych kryteriach. 14. System musi posiadać jednolitą obsługę operatorską, uławiającą korzystanie z różnych części systemu. 15. System musi posiadać mechanizmy umożliwiające identyfikację operatora i ustalenie daty wprowadzenia i modyfikacji danych. 16. System musi posiadać mechanizm backupu danych. 17. System musi zapewniać bieżącą kontrolę poprawności wprowadzanych danych wraz z mechanizmem pomocy kontekstowej. 18. System musi zapewniać weryfikację poprawności wprowadzanych danych: PESEL, NIP, kont bankowych. 19. System musi posiadać wspólne dla wszystkich modułów słowniki i wspólną bazę kontrahentów. Strona 3 z 41

4 20. System musi umożliwiać prowadzenie rejestrów branżowych (osób, kontrahentów, działek, nieruchomości), wspólnych dla wszystkich części, bez dublowania danych. 21. System musi posiadać wbudowane mechanizmy zapewniające jednoznaczną identyfikację informacji oraz gwarantujące spójność danych. 22. System musi posiadać wbudowane mechanizmy budowy i projektowania raportów łącznie z projektowaniem wydruków, w szczególności musi mieć: a. możliwość definiowania układu strony, marginesów, b. możliwość definiowania dowolnej ilości pól, c. możliwość tworzenia dowolnej ilości obiektów, pól, d. możliwość wstawiania grafiki, e. możliwość zmiany rozmiarów obiektów, f. możliwość zmiany pozycji obiektów i dopasowania do punktów łączenia siatki, g. możliwość ustawienia tekstów w dowolnej pozycji, h. możliwość tworzenia zapytań w SQL, i. możliwość tworzenia zapytań do bazy danych oraz z zewnętrznych źródeł, j. możliwość przypisania raportu do drukarki w systemie, k. możliwość tworzenia raportów wielopoziomowych. 23. System musi zapewniać możliwość eksportu do formatów: pdf, xlsx, csv, rtf, XML. 24. System musi posiadać możliwość dwukierunkowej wymiany informacji w standardzie XML, a dla systemów podatkowych w standardzie zgodnym z IPE-PN. 25. System musi posiadać narzędzia administracyjne pozwalające na zarządzanie użytkownikami i ich uprawnieniami. 26. Mechanizmy przyznawania uprawnień w systemie muszą umożliwiać: a. pracę w oparciu o strukturę organizacyjną Zamawiającego, wraz z podziałem na jednostki, wydziały i referaty, b. zakładanie nowych użytkowników systemu i modyfikację istniejących, c. nadawanie identyfikatora systemowego, d. rejestrację daty założenia, e. ustawianie i zmiany hasła, f. możliwość automatycznego logowania według Loginu z systemu operacyjnego, g. wymuszanie zmiany hasła przy pierwszym zalogowaniu do bazy danych, h. blokowanie i odblokowywanie konta użytkownika, i. przydzielanie podsystemów - nadawanie i odbieranie uprawnień do podsystemów, j. definiowanie grup użytkowników, k. możliwość generowania zestawień typu: ewidencja użytkowników systemu, lista użytkowników wybranego podsystemu, lista aktywnych użytkowników. 27. System musi umożliwiać administratorowi ustalenie polityki dostępu do systemu, w szczególności w zakresie definicji haseł użytkowników oraz musi: a. umożliwiać definiowanie i modyfikację czasu ważności hasła, b. umożliwiać wskazanie minimalnej długości hasła i liczby znaków specjalnych, c. umożliwiać wymuszanie stosowania małych i dużych liter w haśle, d. umożliwiać wskazanie minimalnego terminu wymuszenia zmiany hasła, e. umożliwiać zdefiniowanie blokady użytkownika po określonej liczbie prób błędnego logowania, f. umożliwiać zdefiniowanie przechowywania określonej liczby poprzednich haseł, g. umożliwiać blokowanie wcześniej używanego hasła, h. umożliwiać blokowanie hasła identycznego z loginem, i. umożliwiać wymuszanie, aby hasło nie składało się z samych liter. Strona 4 z 41

5 28. System musi umożliwiać pracę w ramach bezpiecznego połączenia SSL gwarantując zachowanie poufności, integralności i bezpieczeństwa przesyłanych danych. 29. System musi być rozwiązaniem skalowalnym, rozumianym przez: a. możliwość dołączenia dodatkowych stanowisk zwiększenia liczby użytkowników, b. możliwość rozbudowy warstwy aplikacyjnej (zwiększenia zasobów komputerów), c. możliwość rozbudowy infrastruktury serwerowej. 2) Wymagania licencyjne 1. Wykonawca musi dostarczyć licencje na następujące produkty: a. licencje na czas nieokreślony na oprogramowanie systemu zintegrowanego dla Gminy Blachownia, dla nieograniczonej liczby użytkowników, b. licencje na czas nieokreślony na każde dostarczone oprogramowanie, które potrzebne jest do prawidłowego funkcjonowania systemu zintegrowanego, c. licencje na oprogramowanie systemowe niezbędne do prawidłowej pracy systemu zintegrowanego, w tym licencje na oprogramowanie bazodanowe w przypadku zastosowania bazy komercyjnej. 2. Dostarczone licencje muszą charakteryzować się poniższymi cechami: a. wszystkie licencje udzielone na oprogramowanie systemu zintegrowanego muszą obejmować nieograniczoną liczbę stanowisk do wykorzystania przez Gminę Blachownia, b. Licencje na oprogramowanie systemu nie mogą posiadać ograniczeń związanych z uruchamianiem w środowisku zwirtualizowanym, c. Licencje oprogramowania baz danych oraz serwera aplikacji nie mogą mieć ograniczeń związanych z liczbą użytkowników bądź ograniczeń związanych z wykorzystywaną infrastrukturą sprzętową. 3) Wymagania funkcjonalne dla systemu zintegrowanego A. Wymagania dla obszaru budżetowo-sprawozdawczego 1. System musi umożliwiać tworzenie budżetu zarówno w układzie klasycznym, jak i zadaniowym. 2. System musi umożliwiać wprowadzanie planu na rok budżetowy do pełnego klucza budżetowego, przy wymaganych elementach klucza budżetowego: a. dysponent środków budżetowych, b. klasyfikacja budżetowa wraz z możliwością wprowadzenia pozycji paragrafu, c. źródła finansowania, 3. System musi zapewniać użytkownikom, w zależności od nadanych uprawnień, możliwość korzystania ze słowników budżetowych: a. słownik klasyfikacji budżetowej z informacjami o działach, rozdziałach, paragrafach i pozycjach paragrafów definiowanych przez użytkowników, b. słownik klasyfikacji strukturalnej zawierający klasyfikację strukturalną, 4. System musi pozwalać na wprowadzenie do każdego zadania parametrów. a. nazwa, b. cel realizacji (wraz z określeniem priorytetu), c. jednostka nadzorująca zadanie, d. jednostka realizująca zadanie, e. dziedzina, f. kategoria, g. opis dodatkowy. Strona 5 z 41

6 5. System musi zapewniać możliwość wprowadzenia przez użytkowników merytorycznych kwot planu budżetu oraz zmian budżetowych tylko w ramach otwartych zmian. 6. System musi zapewniać dwupoziomowe zatwierdzanie projektu budżetu. 7. System musi umożliwiać, wybranym użytkownikom, anulowanie zatwierdzenia projektu całości budżetu oraz anulowania zatwierdzenia wybranej zmiany w ramach wybranego dysponenta środków budżetowych. 8. System musi posiadać możliwość podłączenia wariantów planów jednostek organizacyjnych w ramach tylko ukończonych bądź wszystkich utworzonych projektów jednostek. 9. System musi umożliwiać wprowadzanie uzasadnień opisowych do wprowadzanych zmian budżetowych. 10. System musi umożliwiać udostępnienie on-line planu jednostkom organizacyjnym. 11. System musi zawierać funkcjonalność umożliwiającą udostępnienie elementów wprowadzania projektu budżetu oraz zmian budżetowych przez jednostki organizacyjne. 12. System musi umożliwiać agregowanie sprawozdań jednostkowych i sporządzania sprawozdań zbiorczych. 13. System musi umożliwiać kontrolę planu jednostki w zakresie zgodności z uchwalonym planem. 14. System musi umożliwiać generowanie planów, zmian i sprawozdań budżetowych do plików XML(możliwość eksportu do obecnie istniejącego w Gminie systemu BESTI@). 15. System musi umożliwiać przegląd, w dowolnym momencie, aktualnego stanu budżetu dla wybranego dysponenta środków budżetowych bądź dla wszystkich jednostek dla pełnego klucza budżetowego. 16. System musi umożliwiać utworzenie symulacji budżetu na podstawie zatwierdzonego plan budżetu z poprzedniego roku, 17. System musi umożliwiać tworzenia symulacji przy wybraniu parametrów związanych z kluczem budżetowym. 18. System musi umożliwiać raportowanie w zakresie planu oraz wykonania na podstawie sprawozdań budżetowych do arkusza kalkulacyjnego (w formacie xlsx), przy czym wymagana jest: a. możliwość definiowania dynamicznych zestawień przez użytkowników modułu w oparciu o zarejestrowane dane, b. możliwość generowania raportów w dowolnym momencie czasu, które wcześniej zostaną zdefiniowane przez użytkowników, zarówno z zarejestrowanych danych aktualnych, jak i historycznych, c. możliwość blokady definicji raportu dla użytkowników. 19. System musi być zintegrowany z modułem księgowym w zakresie dekretacji planu budżetu i zmian. 20. System musi umożliwiać budowanie wzorców dekretacji planu budżetu, zmian i sprawozdań budżetowych w oparciu o konta księgowe. 21. System musi być zintegrowany z rejestrem umów i umożliwiać sprawdzenie na danym poziomie planowania budżetu bieżącego stanu zaangażowania w oparciu o wybrany klucz budżetowy. 22. System musi umożliwiać rejestrację sprawozdań budżetowych Rb wymaganych przepisami prawa oraz możliwość wydruku na wzorach ustawowych. 23. System musi umożliwiać rejestrację sprawozdań Rb-27S i Rb-28S z pełną szczegółowością klasyfikacji budżetowej, zadania budżetowego, źródła finansowania. 24. System musi posiadać obsługę sprawozdań wymaganych przepisami prawa, w zakresie: a. dwupoziomowe zatwierdzanie, b. tworzenie korekt sprawozdań, c. tworzenie sprawozdań łącznych, d. tworzenie sprawozdań zbiorczych w zakresie wybranej jednostki organizacyjnej, e. wydruk sprawozdań na wydrukach zgodnych z przepisami prawa, f. wydruk sprawozdań do arkusza kalkulacyjnego, Strona 6 z 41

7 g. eksport do programu obecnie istniejącego w Gminie Besti@, h. podłączenie załączników do wybranego sprawozdania, i. generowanie sprawozdań Rb27S, Rb28S, RbN, RbZ, Rb-50, Rb-27ZZ, Rb-28NW, Rb-ST, Rb-NZ, Rb-UZ, Rb-UN z ksiąg rachunkowych i eksport do sprawozdawczości budżetowej. 25. System musi posiadać integrację z obecnie istniejącym w Gminie programem Besti@ w zakresie importu sprawozdań w postaci plików xml. 26. System musi zapewniać możliwość przeglądu oraz porównania planu budżetu oraz wykonania w dowolnym momencie. 27. System musi umożliwiać tworzenie sprawozdań łącznych na dowolnym poziomie wybranym przez użytkownika. 28. System musi być zintegrowany z modułem księgowym w zakresie dekretacji sprawozdań Rb27S i Rb28S. 29. System musi umożliwiać budowanie wzorców dekretacji planu budżetu, zmian i sprawozdań budżetowych w oparciu o konta księgowe. 30. System musi posiadać obsługę sprawozdań finansowych (rachunek zysków i strat, bilans jednostki budżetowej oraz zestawienie zmian w funduszu jednostki), w tym możliwość automatycznego ich generowania. 31. System musi posiadać możliwość wprowadzania uzasadnień do wykonania planu w pełnej szczegółowości do klucza budżetowego. 32. System musi umożliwiać czynności w zakresie deklaracji VAT, w szczególności: a. generowanie zbiorczej deklaracji VAT dla całej Gminy (centralizacja VAT), b. import faktur sprzedażowych i zakupowych z jednostek podległych w formacie JPK, z podziałem na jednostki i wydziały. c. obsługę korekt deklaracji zbiorczej, d. tworzenie zbiorczej korekty deklaracji VAT-7, e. wprowadzenie powodu złożenia korekty, których lista będzie dołączana do deklaracji zbiorczej, f. archiwizowanie deklaracji w formacie PDF. 33. System musi umożliwiać tworzenie wariantów prognozy finansowej. 34. System musi posiadać funkcjonalność w zakresie badania płynności finansowej w perspektywie roku budżetowego. B. Wymagania dla obszaru finansowo-księgowego 1. System musi umożliwiać rejestrację faktur zakupu w zakresie danych opisowych, pozycji faktury wraz z wyborem z listy stawki podatku VAT. 2. System musi umożliwiać ukończenie faktury, anulowanie faktury, dekretację faktury według automatów dekretujących zdefiniowanych przez użytkownika. 3. System musi umożliwiać rejestrowanie realizacji do wybranej umowy na podstawie utworzonej faktury zakupu wraz z przypisaniem szczegółowości klucza budżetowego. 4. System musi posiadać możliwość wygenerowania korekty faktury oraz podpięcie jej do kwot realizacji do wybranej umowy. 5. System musi umożliwiać utworzenie noty korygującej dla wybranego dokumentu. 6. System musi posiadać ewidencję faktur zakupów. 7. System musi posiadać możliwość rejestracji dowolnych dokumentów zobowiązań będących podstawą wydatków. 8. System musi umożliwiać wprowadzanie listy dokumentów zobowiązań wg określonych kryteriów: a. rodzaj dokumentu, Strona 7 z 41

8 b. typ operacji księgowej, c. jednostka organizacyjna, d. data wystawienia, e. data otrzymania, f. data terminu płatności, g. stały opis dokumentu. 9. System musi umożliwiać generowanie korekt dokumentów zobowiązań. 10. System musi umożliwiać powiązanie dowolnego zobowiązania do wybranej umowy. 11. System musi posiadać możliwość generowania paczki przelewów oraz pliku elektronicznego do systemu bankowego. 12. System musi posiadać możliwość dekretacji dokumentu zobowiązań według zdefiniowanych automatów księgowych utworzonych przez użytkownika. 13. System musi umożliwiać dekretację pojedynczych dokumentów zobowiązań bądź dekretację zbiorczą wybranych dokumentów przez użytkownika. 14. System musi umożliwiać wygenerowanie raportów: a. zestawienie dokumentów na kontrahenta, b. zestawienie z ewidencji dokumentów, c. sumaryczne zestawienie na rodzaj dokumentu oraz typu operacji księgowej, d. zestawienie kontrahentów. 15. System musi umożliwiać wyszukiwanie dowolnych dokumentów po wybranych parametrach z dokumentów (numer, data wystawienia, data zapłaty, rodzaj dokumentu, typ operacji księgowej, jednostka organizacyjna). 16. System musi zapewniać możliwość wprowadzenia jednolitego planu kont z podziałem na jednostki organizacyjne Gminy. 17. System musi zapewniać możliwość grupowania kont. 18. System musi zapewniać możliwość definiowania różnych typów dekretów. 19. System musi pozwalać na rozbudowę analityki według potrzeb za pomocą wykorzystania zdefiniowanych słowników pomocniczych: a. klasyfikacji budżetowej dział, rozdział, paragraf oraz opcjonalnie pozycja paragrafu, b. listy zadań budżetowych, c. listy jednostek organizacyjnych, d. listy źródeł finansowania, e. listy kontrahentów, f. słownika zadań inwestycyjnych, g. słownika klasyfikacji wydatków strukturalnych, 20. System musi zapewniać możliwość definiowania wielu poziomów kont księgowych. 21. System musi umożliwiać zmianę nazwy kont bez zmiany numeru. 22. System musi umożliwiać zdefiniowanie rodzajów dokumentów/należności, które pozwalają charakteryzować poszczególne operacje wykonywane w systemie i agregować je w jednorodne grupy. 23. System musi zapewniać możliwość zdefiniowania słownika typów operacji księgowej. 24. System musi zapewniać możliwość tworzenia automatów dekretujących i wzorców księgowań dla zdefiniowanych operacji księgowych. 25. System powinien posiadać kontrole sprawdzające: a. uzupełnienia wymagalnych elementów dekretu, b. czy kwoty dekretu są różne od zera, c. czy księgowanie odbywa się na najniższym poziomie analityki, d. czy data dowodu odpowiada okresowi, który nie został zamknięty ani zablokowany. Strona 8 z 41

9 26. System powinien pozwalać na nadawanie numerów dla dowodów w ewidencji księgowej zgodnie ze zdefiniowanym numeratorem. 27. System powinien zapewniać przyporządkowanie kolejnych numerów dla dowodów w sposób chronologiczny. 28. System musi umożliwić wykonywanie operacji dla dowodów zaksięgowanych: a. generowanie dowodów storna, b. przeglądanie stornowanych dowodów, c. przeglądanie dowodów storna, d. wydruk księgowania, e. przegląd dokumentów źródłowych, f. kopiowanie dowodu. 29. System musi mieć funkcjonalność służącą do otwierania nowego roku bilansowego z: a. automatycznego definiowania okresów sprawozdawczych, b. kopiowania dostępów do okresów z poprzedniego roku bilansowego. 30. System powinien umożliwiać wyodrębnienie dowolnej ilości okresów dla przeksięgowań technicznych wykonywanych pod koniec roku w zależności od potrzeb użytkownika. 31. System powinien umożliwiać wprowadzanie dowodów księgowych do dowolnej ilości otwartych okresów jednocześnie. 32. System powinien umożliwiać blokowanie oraz zamykanie okresów uniemożliwiające wprowadzanie dowodów księgowych. 33. System powinien umożliwiać przeglądanie i drukowanie dowodów księgowych, w szczególności: a. wyszukanie dowodów wprowadzonych w ramach danego okresu sprawozdawczego, b. wyszukanie wszystkich dowodów wprowadzonych przez danego użytkownika, c. wyszukanie dowodów księgowych według: daty operacji, daty dowodu, nazwy, numeru, symbolu rejestru, rodzaju dowodu, symbolu operacji księgowej, d. wyszukanie dekretów wg kwot, dat, kont, klucza dekretu uzupełniającego. 34. System musi zapewniać możliwość generowania sprawozdań budżetowych Rb-28S, Rb-27S, Rb-27, Rb- 28, Rb-23, Rb-27ZZ, Rb-30S, Rb-31, Rb-32, Rb-33, Rb-34, Rb-50D, Rb-50W, Rb-N, Rb-Z, Rb-UN, Rb-UZ, Rb-WS, Rb-ZN, Rb-28NWS oraz zestawień. 35. System musi zapewniać możliwość automatycznego tworzenia sprawozdań finansowych (bilans, rachunek zysków i strat, zestawienie zmian w funduszu). 36. System powinien dawać możliwość wygenerowania potwierdzenia sald z kontrahentami, w szczególności: a. stworzenia zbioru kont biorących udział w wyliczaniu salda rozliczeń z kontrahentem, b. generowania potwierdzenia salda na wskazany dzień dla jednego lub wielu kontrahentów z funkcją pozwalająca na przeglądanie, drukowanie, nanoszenie uwag, modyfikowanie opisu, c. prowadzenia ewidencji wygenerowanych potwierdzeń sald, d. możliwości zdefiniowania odpowiednich filtrów pozwalających na wyszukanie kontrahentów zgodnie z warunkami zawartymi w filtrze. 37. System musi zapewniać możliwość archiwizacji ksiąg rachunkowych. 38. System musi umożliwiać generowanie raportów i zestawień, w szczególności: a. wydruk kart kontowych kont analitycznych, b. wydruk Dziennika, c. wydruk zestawień dowodów księgowych, d. wydruk obrotów i sald, e. wydruk obrotów i sald dla dekretów uzupełniających, f. wydruk raportów obrotów i sald wygenerowanego na podstawie zaksięgowanych dowodów prezentujący skutki dekretacji. Strona 9 z 41

10 39. System musi umożliwiać definiowanie dowolnej ilości rejestrów sprzedaży i nabycia. 40. System musi umożliwiać przydzielanie i modyfikowanie dostępów do rejestrów sprzedaży. 41. System musi pozwalać na oznaczanie rodzaju dokumentu: a. symbolem b. pełną nazwą dokumentu c. zdefiniowaniem numeracji (miesięczna, roczna, kwartalna, własna) d. rejestrem VAT do którego należy e. domyślnego szablonu wydruku faktury f. domyślnego typu płatności (ilość dni czy termin) 42. System musi umożliwiać definiowanie oddzielnych numeratorów dla poszczególnych rejestrów sprzedaży. 43. System musi umożliwiać obsługę centralizacji VAT w zakresie fakturowania z możliwością wskazania na fakturze jednostki organizacyjnej. 44. System musi umożliwiać umieszczanie faktur VAT w rejestrach zgodnie z datą wystawienia; system powinien zapewniać nadanie kolejnych numerów faktur narastająco zgodnie z datą wystawienia. 45. System musi umożliwiać wprowadzenia daty VAT na fakturze określającej moment powstania obowiązku podatkowego. 46. System musi umożliwiać wygenerowanie wydruku rejestru pozwalającego na zestawienie wystawionych faktur umieszczonych w różnych rejestrach według daty wystawienia oraz według daty powstania obowiązku podatkowego w danym miesiącu. 47. System musi umożliwiać wygenerowanie zbiorczego zestawienia dla rejestrów VAT: a. podsumowanie wartości netto, VAT i brutto dla poszczególnych rejestrów, b. łączne podsumowanie wartości netto, VAT i brutto dla rejestrów danego okresu, c. wyszczególnienie sumarycznego ujęcia pozycji sprzedaży podlegającej opodatkowaniu w rozbiciu na poszczególne stawki podatku VAT oraz sprzedaży zwolnionej z podatku VAT dla faktur ujętych we wszystkich rejestrach danego okresu, d. wyszczególnienie sumarycznego zestawienia pozycji faktur według przyporządkowanej jednostki księgowej oraz rodzaju dowodu. 48. System musi umożliwiać wygenerowanie wydruku danych rejestrów z możliwością ograniczenia: a. rodzaju dokumentu, b. symbolu rejestru, c. miesiąca, w ramach którego utworzony był rejestr, d. wybranej grupy rejestrów, e. daty VAT, f. daty wystawienia w okresie. 49. System musi umożliwiać wprowadzanie zarówno faktur jedno- jak i wielopozycyjnych. 50. System musi umożliwiać wprowadzanie faktur sprzedaży zarówno w kwotach netto jak i brutto. 51. System musi umożliwiać wprowadzenie danych ewidencyjnych i opisowych zawartych na fakturze: a. kontrahenta zarejestrowanego w ewidencji kontrahentów, b. nazwy, ceny jednostkowej, stawki VAT, jednostki miary, c. podsumowania pozycji faktury, d. terminu płatności dla faktury wpływającego na wysokość odsetek od zaległości, e. terminu zapłaty drukowanego na fakturze, f. rodzaju należności. 52. System musi umożliwiać wprowadzanie faktur korygujących ze szczególnym uwzględnieniem zapewnienia powiązania pomiędzy dokumentem pierwotnym a korektą oraz ewidencjonowanie wprowadzonych korekt. Strona 10 z 41

11 53. System powinien zapewniać możliwość kopiowania faktur na podstawie faktury już wprowadzonej raz do modułu. 54. System powinien umożliwiać hurtowe drukowanie partii utworzonych faktur. 55. System powinien umożliwiać prowadzanie ewidencji faktur wewnętrznych. 56. System musi pozwalać na przegląd wystawionych faktur oraz ich wyszukiwanie po zadeklarowanym parametrze (m.in. numerze faktury, kodzie kontrahenta, dacie wystawienia, sprzedaży, VAT). 57. System musi umożliwiać: a. generowanie wielu duplikatów faktur, b. wprowadzanie daty wystawienia dla każdego z duplikatów przed jego zatwierdzeniem, c. wygenerowanie duplikatu faktury z danymi, jakie zawierała faktura pierwotna, d. wygenerowanie i odłożenie kopii wygenerowanych faktur w formacie PDF. 58. System musi umożliwiać: a. automatyczne pobieranie danych zarejestrowanych w ewidencji modułu dziedzinowego do generowanych faktur dla zaznaczonych grup należności, b. hurtowe generowanie faktur dla usług o charakterze ciągłym, których ewidencje prowadzone są w modułach dziedzinowych, c. generowanie faktur zaliczkowych na podstawie przekazanych informacji o zarejestrowaniu wpłat dla wybranej grupy należności. 59. System powinien pozwolić na tworzenie ewidencji zamówień z uwzględnieniem możliwości tworzenia faktur zaliczkowych oraz generowania faktur końcowych. 60. System musi generować Jednolity Plik Kontrolny zgodny z wymaganiami prawa. 61. W systemie musi istnieć możliwość prowadzenia rejestru umów. 62. Prowadzenie rejestru umów musi opierać się na podziale umów: a. będące w przygotowaniu - umowy, które można edytować, b. umowy aktualne, c. umowy archiwalne. 63. W systemie musi istnieć możliwość prowadzenia słowników do umów, które będą daną umowę charakteryzowały: a. słownik rodzajów umów, b. słownik kategorii, c. słownik typów umów. 64. System musi istnieć możliwość dwupoziomowego zatwierdzania/ blokowania umów. 65. System musi mieć możliwość prowadzenia rejestru aneksów do wybranych umów, które będą powiązane z umową główną za pomocą jej numeru. 66. System musi mieć możliwość wprowadzania harmonogramu finansowego do każdej umowy, wraz z możliwością zmiany w momencie podpisania aneksu oraz powiązania danej pozycji harmonogramu z wybranym aneksem. 67. System musi mieć możliwość wprowadzania i aktualizacji harmonogramu umowy ze szczegółowością do klasyfikacji budżetowej, zadania budżetowego, źródła finansowania, obiektu budżetowego oraz dysponenta środków budżetowych, wraz z określeniem rodzaju kosztu. 68. System musi mieć możliwość weryfikacji zarejestrowanych harmonogramów z danymi już zaksięgowanymi dotyczącymi zaksięgowanego planu budżetu, zaksięgowanego wykonania, pozostałej kwoty do wykorzystania, zaksięgowanego zaangażowania oraz kosztów. 69. System musi umożliwiać śledzenie na bieżąco zaangażowanych środków ze wszystkich umów na danym kluczu budżetowym oraz weryfikację z danymi realizacji umów. 70. System musi umożliwiać szybkie zweryfikowanie z jakimi fakturami (dokumentami) powiązana jest dana umowa, w tym również z fakturami (dokumentami) korygującymi lub dokumentami wewnętrznymi. Strona 11 z 41

12 71. System musi umożliwiać rejestrowanie informacji o umowach podpisanych w wyniku prowadzonego postępowania o zamówienie publiczne. Wymagane informacje: a. numer postępowania, b. data rozpoczęcia postępowania, c. data zakończenia postępowania. 72. System musi umożliwiać rejestrację i ewidencję składników majątku trwałego, w szczególności: a. nazwy środka, b. opisu środka, c. daty przychodu, d. wartości środka, e. umorzenia, f. jednostki organizacyjnej, g. rodzaju GUS, h. rodzaju WNP, i. roku produkcji, j. numeru fabrycznego, k. KST, l. stawki amortyzacji. 73. System musi umożliwiać przyporządkowanie oraz zmianę osoby odpowiedzialnej za składnik majątku z określeniem w jakim okresie dana osoba jest przypisana jako osoba odpowiedzialna. 74. System musi umożliwiać przyporządkowanie oraz zmianę adresu składnika majątku z określeniem w jakim okresie dany adres jest przypisany do składnika majątku. 75. System musi umożliwiać budowanie przez użytkownika słowników cech wraz z możliwością przypisywania cech wybranym składnikom majątku. 76. System musi umożliwiać wykonanie operacji hurtowego przychodu składników majątku o takiej samej charakterystyce. 77. System musi umożliwiać generowanie dokumentów przychodu, likwidacji, sprzedaży, zmiany miejsca użytkowania, odpowiedzialności, zmian wartości. 78. System musi umożliwiać ewidencję zmian: a. zwiększenia wartości, b. zmniejszenia wartości, c. zmiany stawki amortyzacji, d. przeceny, e. korekty umorzeń, f. zatrzymanie naliczania umorzeń. 79. System musi umożliwiać ewidencję przemieszczeń składników majątku. 80. System musi umożliwiać hurtowe wykonywanie operacji na składnikach majątku, w szczególności: a. przemieszczenia, b. rozchody, c. przyporządkowanie lub zmiana adresu, d. przyporządkowanie lub zmiana osoby odpowiedzialnej, e. przyporządkowanie lub zmiana osoby użytkującej, f. nadanie cechy. 81. System musi umożliwiać naliczanie umorzeń i amortyzacji na wybrany okres (miesiąc, rok). 82. System musi umożliwiać pełną obsługę inwentaryzacji z wykorzystaniem czytników kodów kreskowych. 83. System musi umożliwiać przeglądanie i wydruk ilościowo-wartościowych zestawień majątku w zakresie: Strona 12 z 41

13 a. zestawienie stanu majątku, b. zestawienie obrotów za wskazany okres, c. zestawienie przychodów za wskazany okres, d. zestawienie rozchodów za wskazany okres, e. zestawienie majątku według adresów, f. zestawienie majątku według osób użytkujących, g. zestawienie majątku według osób odpowiedzialnych, h. zestawienie majątku według jednostek organizacyjnych. 84. System musi umożliwiać równoległe prowadzenie wielu ewidencji i wielu ksiąg inwentarzowych. 85. System musi umożliwiać prowadzenie odrębnych ewidencji majątku trwałego dla jednostek podległych które ewidencjonowane są przez jednostkę główną, ewidencje jednostek muszą być rozdzielone poprzez ich wybór na etapie logowania 86. System musi umożliwiać prowadzenie słowników związanych z ewidencją środków: a. rodzaje środków nazwa rodzaju (np. środki trwałe, pozostałe środki trwałe, wartości niematerialne i prawne), b. rodzaje GUS wraz z przyporządkowaniem stawki, c. rodzaje PKD na potrzeby sprawozdania SG-01, d. rodzaje WNiP wraz z przyporządkowaniem stawki. 87. System musi umożliwiać prowadzenie słowników związanych z ewidencją księgową środków w zakresie: a. rodzaje przychodów, b. rodzaje rozchodów, c. rodzaje operacji, d. konta księgowe, e. wzorce dekretacji. C. Wymagania dla obszaru obsługi dochodów podatkowych i opłat Podatek od nieruchomości, rolny i leśny dla osób fizycznych: 1. System powinien zapewniać możliwość założenia kartoteki podmiotowo-przedmiotowej z uwzględnieniem dołączenia podatników ze słownika klientów lub opcjonalnie uzupełnienia słownika brakującymi danymi z uwzględnieniem daty rejestracji i wyrejestrowania klienta z kartoteki, określenia formy władania, charakteru podatnika. 2. System musi umożliwiać rejestrację danych karty składnika podatkowego: a. położenie nieruchomości, gruntu rolnego, lasu, b. numery ewidencji geodezyjnej, c. numery ksiąg wieczystych, d. okres opodatkowania, e. podstawy opodatkowania. 3. System musi umożliwiać rejestrację decyzji o odroczeniu terminów płatności, rozłożeniu zaległości na raty, ulg i zwolnień. 4. System musi umożliwiać rejestrację ewidencji opisowej nieruchomości podatkowej: a. położenie nieruchomości, b. dane ksiąg wieczystych, c. numer zbioru dokumentów, d. dane geodezyjne, e. udział. Strona 13 z 41

14 5. System musi umożliwiać przeniesienie składników z kartoteki podatnika zbywającego na podatnika, który nabył składnik podatkowy. 6. System musi umożliwiać wyszukiwanie oraz przegląd danych po informacjach osobowo-adresowych podatników, współwłaścicieli oraz danych położenia składników podatkowych, numerach ksiąg wieczystych i numerach geodezyjnych. 7. System musi umożliwiać ewidencję złożonych informacji podatkowych z uwzględnieniem rodzaju informacji, składającego oraz daty złożenia. 8. System musi automatycznie na podstawie przedmiotów opodatkowania ustalać stawkę podatku rolnego (niższa dla rolnika, wyższa dla pozostałych). 9. System musi umożliwiać wyliczenie kwoty należnego podatku oraz wydruk raportu decyzji podatkowych oraz nakazów płatniczych w bieżącym roku podatkowym lub za lata wstecz. 10. System musi umożliwiać generowanie numerów indywidualnych kont bankowych oraz generowanie korespondencji do podatników dotyczącej indywidualnych numerów rachunków. 11. System musi umożliwiać rejestrację zmian w karcie składnika podatkowego wraz z obliczaniem przypisu lub odpisu oraz wydruk decyzji o zmianie podatku w bieżącym roku podatkowym oraz za lata wstecz. 12. System musi umożliwiać seryjny wydruk decyzji wymiarowych oraz zwrotnych potwierdzeń odbioru na podstawie zdefiniowanych algorytmów. 13. System musi umożliwiać wgląd w bieżący stan konta podatnika w zakresie dokonanych przypisów i odpisów oraz wpłat. 14. System musi umożliwiać dokonywania symulacji związanych ze zmianami stawek. 15. System musi generować zrzut danych do GUS w formacie XML 16. System musi generować zaświadczenia o posiadaniu i dochodowości. 17. System musi generować sprawozdania Rb-27S i RBN na podstawie zapisów księgowych. 18. System musi umożliwiać obsługę płatności masowych. Podatek od nieruchomości, rolny i leśny od osób prawnych: 1. System musi zapewniać możliwość założenia kartoteki podmiotowo-przedmiotowej z uwzględnieniem dołączenia podatników ze słownika klientów lub opcjonalnie uzupełnienia słownika brakującymi danymi z uwzględnieniem daty rejestracji i wyrejestrowania klienta z kartoteki, określenia formy władania, charakteru podatnika. 2. System musi umożliwiać rejestracje ewidencji opisowej nieruchomości podatkowej: a. położenie nieruchomości, b. dane ksiąg wieczystych, c. numery zbioru dokumentów, d. dane geodezyjne, e. udział, f. powierzchnie nieruchomości. 3. System musi umożliwiać wyszukiwanie oraz przegląd danych po informacjach osobowo-adresowych podatników, współwłaścicieli oraz danych położenia nieruchomości, gruntu rolnego oraz lasu, numerach ksiąg wieczystych i numerach geodezyjnych. 4. System musi umożliwiać rejestrację, ewidencję i rozliczanie deklaracji podatkowych za rok bieżący i lata wstecz: a. numer deklaracji nadany przez system, b. daty obowiązywania deklaracji, c. daty złożenia deklaracji, d. dane dotyczące podstaw opodatkowania, Strona 14 z 41

15 e. ulgi i zwolnienia z możliwością wprowadzenia wielu zwolnień dla poszczególnych podstaw opodatkowania. 5. System musi zapewniać możliwość podpowiadania podstaw opodatkowania z poprzedniej zatwierdzonej deklaracji oraz przepisania podstaw do rejestrowanej deklaracji. 6. System musi umożliwiać wyliczanie aktualnego podatku na podstawie danych z deklaracji przed jej zatwierdzeniem. 7. System musi umożliwiać rejestrację korekty deklaracji podatkowej. 8. System musi umożliwiać rejestrację korekty deklaracji od początku roku z rożnymi podstawami opodatkowania w poszczególnych miesiącach. 9. System musi umożliwiać podglądu podczas zatwierdzanie deklaracji rat przed zmianą i po zmianie. 10. System musi umożliwiać korygowanie rat podatku podczas zatwierdzania deklaracji (zmiana wysokości poszczególnych rat). 11. System musi umożliwiać uchylenie decyzji określającej wysokość zobowiązania podatkowego. 12. System musi umożliwiać ewidencję deklaracji podatkowych złożonych przez współwłaścicieli z uwzględnieniem rodzaju deklaracji, składającego oraz daty złożenia z możliwością dopisania podatnika do osób zobowiązanych. 13. System musi umożliwiać naliczenie na podstawie deklaracji kwoty należnego w bieżącym roku podatkowym lub za lata wstecz. 14. System musi umożliwiać wgląd w bieżący stan konta podatnika w zakresie dokonanych przypisów i odpisów oraz wpłat. 15. System musi umożliwiać kompleksową obsługę w zakresie generowania, zatwierdzania, ewidencjonowania oraz drukowania pism: a. rejestrowanie pism, b. oznaczanie daty wysłania i odbioru, c. elastyczne definiowanie szablonów pism, d. generowanie ewidencji pism. 16. System musi umożliwiać dokonywania symulacji związanych ze zmianami stawek. 17. System musi generować sprawozdania Rb-27S i RBN na podstawie zapisów księgowych. 18. System musi umożliwiać obsługę płatności masowych. Podatek od środków transportu osób fizycznych i prawnych: 1. System musi zapewniać możliwość założenia kartoteki podmiotowo-przedmiotowej. 2. System musi umożliwiać rejestrację danych pojazdu: a. daty nabycia lub rejestracji z oznaczeniem typu daty, b. daty sprzedaży lub wyrejestrowania z oznaczeniem typu daty, c. rodzaj środka transportu, d. numer rejestracyjny, e. marka, f. model, g. rok produkcji, h. parametry określane na podstawie rodzaju pojazdu (ilość miejsc, DMC), i. wartość parametru, j. liczba osi, k. rodzaj zawieszenia, l. dodatkowy słownik charakterystyki pojazdu (np. katalizator, certyfikat euro). 3. System musi umożliwiać ewidencję zmian numeru rejestracyjnego pojazdu. 4. System musi umożliwiać rejestrację dat czasowego wycofania pojazdów z ruchu. Strona 15 z 41

16 5. System musi umożliwiać wyszukiwanie i przegląd danych po informacjach osobowo-adresowych podatników, współwłaścicieli oraz danych pojazdu. 6. System musi umożliwiać rejestrację, ewidencję i rozliczanie deklaracji podatkowych za rok bieżący i lata wstecz.: a. Numeru deklaracji nadanego przez system, b. Dat obowiązywania deklaracji, c. Daty złożenia deklaracji, d. Danych dotyczących podstaw opodatkowania, e. Ulg i zwolnień. 7. System musi umożliwiać pełną rejestrację druku deklaracji DT-1 i załączników DT-1/A wraz z możliwością weryfikacji kwot podatku wpisanych przez podatnika z kwotami wynikającymi z uchwały. 8. System musi umożliwiać wyliczenia należnego podatku na podstawie danych pojazdów wskazanych w deklaracji. 9. System musi umożliwiać rejestrację korekty deklaracji o podatkowej. 10. System musi umożliwiać ustalenie w drodze decyzji wysokości wymiaru podatku za rok bieżący i lata wstecz poprzez wskazanie pojazdów zawartych w decyzji. 11. System musi umożliwiać ewidencję deklaracji podatkowych złożonych przez współwłaścicieli z uwzględnieniem rodzaju informacji, składającego oraz daty złożenia. 12. System musi umożliwiać naliczenie na podstawie deklaracji kwoty należnego w bieżącym roku podatkowym lub za lata wstecz. 13. System musi umożliwiać wgląd w bieżący stan konta podatnika w zakresie dokonanych przypisów i odpisów oraz wpłat. 14. System musi umożliwiać kompleksową obsługę w zakresie generowania, zatwierdzania, ewidencjonowania oraz drukowania różnorodnych pism (dokumentów): a. rejestrowanie pism, b. zatwierdzanie pism, c. oznaczanie daty wysłania i odbioru, d. elastyczne definiowanie szablonów pism, e. generowanie ewidencji pism. 15. System musi zapewniać możliwość zbiorczego generowania pism. 16. System musi generować sprawozdania Rb-27S i RBN na podstawie zapisów księgowych. 17. System musi umożliwiać obsługę płatności masowych. Obsługa opłat od posiadania psa: 1. System musi umożliwiać rejestrację podatnika. 2. System musi umożliwiać rejestrację danych psa. 3. System musi umożliwiać rejestrację stawek. 4. System musi umożliwiać ewidencję ulg i zwolnień z opłaty. 5. System musi umożliwiać naliczanie opłaty i korekt ze zmian w ciągu roku. 6. System musi umożliwiać przegląd przypisów wg daty rejestracji. 7. umożliwiać przegląd odpisów wg daty rejestracji. 8. System musi umożliwiać wgląd w bieżący stan kartoteki finansowej podatnika w zakresie dokonanych przypisów i odpisów, wpłat. Obsługa dochodów innych: 1. System musi pozwalać na rozróżnienie wprowadzonych należności podatkowych i niepodatkowych. Strona 16 z 41

17 2. System musi zapewniać możliwość generowania dokumentów korygujących przypisy należności ze szczególnym uwzględnieniem zaewidencjonowania powiązania pomiędzy dokumentem korygowanym a korektą. 3. System musi zapewniać nadawanie indywidualnego numeru dla każdego ewidencjonowanego dokumentu należności zgodnie ze zdefiniowanym numeratorem. 4. System musi gwarantować wyświetlanie historii dokumentu uwzględniającej informacje dotyczące daty, loginu użytkownika oraz rodzaju operacji wykonanej na dokumencie. 5. System musi umożliwiać definiowanie paczek dokumentów pozwalających na uporządkowanie i agregację przypisów należności. 6. System musi zapewniać możliwość przyporządkowania do dokumentu osób solidarnie zobowiązanych. 7. System musi zapewniać możliwość operacji dla osób solidarnie zobowiązanych m.in. wystawienie upomnień oraz tytułów wykonawczych. 8. System musi zapewniać możliwość przeglądania salda kontrahenta-współwłaściciela w kontekście wszystkich należności kontrahenta, zarówno tych, które zostały bezpośrednio przypisane, jak i tych, za które kontrahent odpowiada jako osoba solidarnie odpowiedzialna. 9. System musi zapewniać obsługę upomnień i wezwań do zapłaty, w szczególności: a. możliwości wprowadzania upomnień pojedynczo lub hurtowo za pomocą generatora, b. możliwości nadawania upomnieniom określonych statusów w zależności od wykonywanej w ramach upomnienia operacji (rejestrowane, nadane, doręczone, zwrócone, anulowane), c. możliwości wprowadzenia daty wystawienia, daty doręczenia oraz notatki własnej dla pojedynczego upomnienia lub wielu zaznaczonych upomnień, d. możliwości prowadzenia ewidencji wystawionych upomnień, e. możliwości obsługi seryjnej upomnień, f. możliwości wyszukiwania upomnień po zadanym parametrze, g. możliwości wydruku upomnienia wraz z potwierdzeniem odbioru lub danymi adresatów, h. możliwości przypisania kosztów upomnienia z poziomu ewidencji upomnień dla jednego lub wielu upomnień, i. możliwości wygenerowania pisma związanego z upomnieniem na bazie funkcjonalności dotyczącej obsługi pism w systemie, j. możliwości wydruku ewidencji upomnień, k. elastyczności w sposobie numerowania, przyporządkowanych szat graficznych wydruków dla upomnień wystawionych dla należności danego rodzaju oraz konfigurowania treści upomnienia z poziomu aplikacji. 10. System musi zapewniać obsługę tytułów wykonawczych, w szczególności: a. możliwości wystawiania tytułów pojedynczo oraz z wykorzystaniem generatora, b. możliwości wystawiania tytułów wielo- i jednopozycyjnych, c. możliwości prowadzenia ewidencji wystawionych tytułów wykonawczych, d. możliwości przeglądania szczegółów tytułu wykonawczego z poziomu ewidencji, e. możliwości wyszukiwania tytułów wykonawczych po zadanym parametrze, f. możliwości drukowania tytułów wielo- i jednopozycyjnych, g. możliwości wydruku ewidencji tytułów wykonawczych, h. możliwości wygenerowania pisma w ramach tytułu wykonawczego z pełną obsługą pism, i. możliwości przeprowadzenia aktualizacji tytułów wykonawczych wynikającej ze zmiany wysokości zaległości spowodowanej zarachowaniem zapłaty na zaległy termin lub wydaniem decyzji, j. możliwości prowadzenia ewidencji uaktualnień, k. elastyczności w sposobie numerowania tytułów wystawionych dla należności danego rodzaju, Strona 17 z 41

18 l. możliwości dowolnego definiowania słownika podstaw prawnych oraz treści tytułu wykonawczego. 11. System musi zapewniać możliwość generowania dokumentów umorzeń, przedawnień oraz dokumentu rozłożenia na raty. 12. System musi zapewniać możliwość wygenerowania dokumentów PK szczególnie w zakresie: zarachowania zapłaty, zmiany danych na dokumencie, zmiany terminu płatności. 13. System musi umożliwiać prowadzenie kartoteki kontrahenta, podatnika oraz współwłaściciela wraz z prezentacją: a. wygenerowanych dla kontrahenta/podatnika/współwłaściciela rat w ramach danego roku lub lat przeszłych z możliwością dynamicznego filtrowania wyświetlanych pozycji oraz prezentacją informacji dodatkowych przyporządkowanych do danej raty, b. zarejestrowanych wpłat i wypłat kontrahenta/podatnika/współwłaściciela, c. wystawionych upomnień, tytułów, spraw, decyzji ratalnych, pism itp., d. listy rat płatności pogrupowanych wg daty w ramach danego rodzaju należności (podatku) oraz roku, e. zapisów na wybranych kontach księgowych w ramach kontrahenta/podatnika, f. historii zapisów na koncie. 14. System musi zapewniać prawidłowe naliczanie odsetek od zaległości wraz z opcjami: a. możliwości wstrzymania naliczania odsetek w danym okresie, b. przywrócenia naliczania odsetek od wskazanego dnia, c. zawieszenie naliczania odsetek w wielu przedziałach czasowych. 15. System musi umożliwiać wystawianie not odsetkowych dla należności zapłaconych po terminie pojedynczo lub hurtowo na podstawie wskazanych parametrów ograniczających: a. przedział dat wystawienia, rodzaj dokumentu, b. przedział dat terminu płatności, c. suma zaległości, d. uwzględnienie terminów objętych tytułem wykonawczym lub upomnieniem, e. przedział dat zapłaty, f. innych zadeklarowanych w filtrze. 16. System musi przy generacji hurtowej not mieć możliwość: a. wygenerowania symulacji wystawienia not odsetkowych, b. wielokrotnego powtarzania symulacji przed zatwierdzeniem not, c. przeglądania dokumentów not z możliwością zmiany daty wysłania/ otrzymania oraz numeru noty, d. wydruku dokumentów noty. 17. System musi posiadać możliwość wygenerowania raportów i zestawień, w szczególności: a. zestawienie z ewidencji zapłat, b. zestawienie przypisów i odpisów, c. zestawienie sald kontrahentów, d. zestawienie zaległości, e. zestawienie nadpłat. 18. System musi umożliwiać dekretację pojedynczych dokumentów należności bądź wyselekcjonowanych grup należności przy użyciu definiowanych przez użytkowników wzorców dekretacji. 19. System musi obsługiwać przesunięcia terminów płatności wynikające z dni ustawowo wolnych. 20. System musi ewidencjonować hipoteki i zastawy skarbowe. 21. System musi umożliwiać generowanie faktur na podstawie zapisów na koncie. 22. System musi umożliwiać zablokowanie danego dokumentu przed egzekucją. 23. System musi generować sprawozdania Rb-27S i RBN na podstawie zapisów księgowych. Strona 18 z 41

19 24. System musi umożliwiać wysyłanie SMS-ów o zbliżającym się terminie płatności bądź o zaległościach na koncie. Obsługa kasy: 1. System musi umożliwiać obsługę wielu kas. 2. System musi umożliwiać rejestrację wpłat dla poszczególnych tytułów płatności w oddzielnych rejestrach kasowych. 3. System powinien umożliwiać podgląd wszystkich zobowiązań klienta z informacją, w jakim podsystemie są ewidencjonowane i jaka jest wysokość odsetek, kosztów upomnienia, opłaty prolongacyjnej oraz rodzaju egzekucji. 4. System musi umożliwiać prowadzenie wszelkich rozliczeń kasowych z równoczesną ich automatyczną dekretacją. 5. System musi umożliwiać wprowadzanie dokumentów zapłat gotówkowych i bezgotówkowych. 6. System musi umożliwiać sporządzanie raportów kasowych z bieżącą kontrolą salda kasowego. 7. System musi umożliwiać wystawianie dowolnych dokumentów kasowych typu KP, KW i innych. 8. System powinien umożliwiać wyliczanie wysokości przychodu i rozchodu przed zamknięciem raportu kasowego. 9. System musi umożliwiać automatyczne wyliczanie stanu końcowego kasy. 10. System musi umożliwiać zamknięcie raportu kasowego z blokadą możliwości zmian. 11. System musi umożliwiać wydruk raportu kasowego w układzie szczegółowym, lub w układzie sum na poszczególnych tytułach wpłat. 12. System musi umożliwiać współpracę z czytnikami kodów kreskowych. 13. System musi umożliwiać współpracę z drukarką fiskalną. 14. System musi umożliwiać automatyczne wygenerowanie dokumentu przekazania pieniędzy do banku. Obsługa płatności masowych: 1. System musi umożliwiać gromadzenie i zarządzanie danymi o wyciągu bankowym oraz poszczególnych operacjach zarejestrowanych pod wyciągiem na podstawie dostarczanego przez bank elektronicznego pliku z zapisem operacji na koncie lub kontach bankowych. 2. System musi zapewniać import wyciągów bankowych w formie elektronicznej o wymaganym formacie w ramach systemu indywidualnych rachunków bankowych kontrahentów. 3. System musi zapewniać rozkodowanie pliku wyciągu bankowego ze szczególnym uwzględnieniem wydzielenia z poszczególnych operacji bankowych kwoty oraz tytułu wpłaty. 4. System musi zapewniać możliwość wyszukiwania danych z operacji zawartych w wyciągach bankowych. 5. System musi zapewniać możliwość automatycznej identyfikacji wpłacającego na podstawie kodowanej informacji zawartej w numerze rachunku bankowego (wirtualne konta) oraz identyfikacja tytułu. 6. System musi zapewniać weryfikację poprawności rozliczenia wyciągu w odniesieniu do ilość pozycji, kwoty. 7. System powinien zapewniać możliwość wykonania symulacji rozdysponowania środków wynikających z wpłaty: a. symulacje zapłat odsetek od zaległości b. symulacje zapłat kosztów upomnienia c. wyświetlanie oznaczenia należności dowolnym znacznikiem określającym cechy szczególne należności. 8. System musi umożliwiać kodowanie i dekodowanie informacji o kontrahencie/podatniku urzędu oraz tytułu należności w ramach systemu indywidualnych rachunków bankowych. Strona 19 z 41