I. Opis przedmiotu zamówienia

Transkrypt

1 I. Opis przedmiotu zamówienia Oprogramowanie do obsługi Funduszu Ochrony Gruntów Rolnych Wymagania minimalne Zakres dostawy Zamówienie obejmuje dostawę oprogramowania do obsługi Funduszu Ochrony Gruntów Rolnych oraz wdrożenie go w siedzibie Urzędu Marszałkowskiego Województwa Mazowieckiego w Warszawie dostawę bezterminowych licencji stanowiskowych dostarczanie zmian w oprogramowaniu w stosunku do zmian prawnych przez okres licencjonowania trwania umowy dostawę systemu wraz z instalacją i wdrożeniem obejmującym jednodniowe szkolenie; przez wdrożenie rozumie się osiągnięcie fazy eksploatacji oprogramowania w podstawowym zakresie przez potencjalnych użytkowników systemu do obsługi FOGR, usługę serwisową przez okres 1 roku Wymagania prawne Oprogramowanie powinno być zgodne z odpowiednimi zapisami aktów prawnych: Ustawy z dnia 3 lutego 1995 r. o ochronie gruntów rolnych i leśnych (Dz. U. Nr 121/2004 r., poz. 1266); Rozporządzenia Ministra Rolnictwa i Gospodarki Żywnościowej z dnia 27 października 1998 r. w sprawie regulaminu funkcjonowania Funduszu Ochrony Gruntów Rolnych; Ustawy o rachunkowości; Rozporządzenia Ministra Finansów z dnia 25 marca 2003 r. w sprawie szczegółowej klasyfikacji dochodów i wydatków oraz przychodów i rozchodów (Dz. U. Nr 68, poz. 634); Rozporządzenia Ministra Finansów z dnia 1 sierpnia 2003 r. zmieniające rozporządzenie w sprawie szczegółowej klasyfikacji dochodów i wydatków oraz przychodów i rozchodów (Dz. U. Nr 137, poz. 1307); Wymagania funkcjonalne 1. System powinien zawierać następujące dane w postaci katalogów stopy procentowe do automatycznego naliczania karnych odsetek od nieterminowych wpłat; ceny żyta do automatycznego wyliczania kwot opłat rocznych oraz do zawiadomień o wysokości opłaty rocznej wysyłanych do płatników; odbiorcy środków z FOGR do generowania przelewów do wnioskodawców dofinansowania oraz Centralnego Funduszu Ochrony Gruntów Rolnych; wystawcy decyzji do charakteryzowania wprowadzanych decyzji; oraz do zestawień o ilościach i kwotach decyzji od poszczególnych wystawców; podział administracyjny, zawierający aktualny podział administracyjny Polski, wykorzystywany do uzyskania informacji o wpłatach i zaległościach płatników w rozbiciu na gminy i 1

2 powiaty, z których nastąpiło wyłączenie gruntów z produkcji oraz do porównywania wysokości wpłat z danej gminy z wysokością udzielonego dofinansowania kody PKD, aktualny katalog Polskiej Klasyfikacji Działalności, który służy do uzyskania informacji o zaległościach płatników w rozbiciu na rodzaje działalności wg PKD; paragrafy wydatkowe do uzyskania informacji o kwocie dofinansowania z Terenowego Funduszu Ochrony Gruntów Rolnych w rozbiciu na paragrafy wydatkowe; dni wolnych od pracy niezbędne do poprawnego liczenia odsetek i ustalania terminu płatności zobowiązań poprzez definiowanie dni dodatkowo wolnych od pracy; Katalogi powinny być aktualizowane przez autorów oprogramowania w ramach umowy licencyjnej lub możliwe do edycji przez użytkowników. 2. System powinien obsługiwać rachunek Terenowego Funduszu Ochrony Gruntów Rolnych w oparciu o zasady księgowości, plan kont oraz schematy dekretowania poszczególnych operacji księgowych; powinien umożliwiać księgowanie m.in. należności jednorazowych, opłat rocznych, wpłat, odprowadzeń do Centralnego Funduszu Ochrony Gruntów Rolnych, dofinansowań z Terenowego Funduszu Ochrony Gruntów Rolnych, lokat bankowych, likwidacji lokat bankowych, zwrotów kwot, wydatków, zwrotów wydatków, odsetek bankowych od rachunku, odsetek bankowych od lokat; wykonywać automatycznie podział i odprowadzenie środków na Centralny Fundusz Ochrony Gruntów Rolnych oraz dofinansowania z Terenowego Funduszu Ochrony Gruntów Rolnych; automatycznie wprowadzać bilanse otwarcia i zamknięcia; umożliwiać prowadzenie kilku rachunków bankowych, umożliwiać wydruk przelewów; wykazywać się elastycznością planu kont i możliwością definiowania kont wirtualnych; 3. System powinien umożliwiać prowadzenie kartotek płatników; w szczególności umożliwiać wprowadzanie dokumentów należności za wszelkie możliwe rodzaje opłat z rozróżnieniem na: czasowe wyłączenie gruntów z produkcji, trwałe wyłączenie gruntów z produkcji; niezgodne z ustawą wyłączenie gruntów z produkcji; niewykonanie obowiązku zdjęcia i wykorzystania próchniczej warstwy gleby; niezakończenie rekultywacji gruntów zdewastowanych i zdegradowanych. umożliwiać wprowadzanie dokumentów wpłat: 2

3 do należności, od płatnika do wyjaśnienia, wpłat do wyjaśnienia, wpłat do kosztów upomnień, od płatnika do zwrotu; umożliwiać wprowadzanie i modyfikację danych o płatniku (nazwa, adres, NIP, REGON, numer rachunku bankowego, data upadłości, itd.); automatycznie naliczać odsetki karne od nieterminowej wpłaty; umożliwiać tworzenie wydruków dokumentów w oparciu o szablony: potwierdzenie sald; postanowienie o zaliczeniu wpłaty; postanowienie o zaliczeniu nadpłaty; umożliwiać wprowadzanie dokumentów dotyczących restrukturyzacji należności, umorzeń, przesunięć środków ; 4. System powinien umożliwiać tworzenie zestawień księgowych wymaganych ustawą o rachunkowości takich jak: dziennik; obroty na kontach syntetycznych i analitycznych oraz obroty na wybranym koncie; zestawienia obrotów i sald kont syntetycznych i analitycznych; obroty / stany kont; 5. System powinien umożliwiać tworzenie raportów z bazy danych wg wybranych kryteriów: podział środków na Centralny Fundusz Ochrony Gruntów Rolnych, koszty funduszu; wpłaty; rozliczenie płatników; odsetki bankowe; należności w restrukturyzacji; 6. System powinien umożliwiać tworzenie raportów z danymi wymaganymi do następujących sprawozdań: RRW-12; Rb-33; Kwartalne Rozliczenie Terenowego Funduszu Gruntów Rolnych; Rb-N; Rb-Z; 7. System powinien umożliwiać wydruk dokumentu zawiadomienia o wysokości opłaty rocznej (z opcją seryjnego wydruku); 8. System powinien gwarantować niezaprzeczalność i integralność danych poprzez nadawanie zakresu uprawnień dostępu do programu: dodawanie, usuwanie użytkowników programu; przypisywanie uprawnień poszczególnym użytkownikom (administrator, użytkownik standardowy, gość) ; 9. Pożądane jest, aby system posiadał dodatkowe funkcje, takie jak: 3

4 zabezpieczenia przed wprowadzeniem nieprawidłowych danych; narzędzia serwisowe sprawdzające i weryfikujące poprawność baz; kalkulator odsetek; próbne naliczenie CFOGR; łączenie płatników; automatyczna numeracja dokumentów. 10. System powinien realizować proces windykacji należności poprzez: automatyczne wyszukiwanie dokumentów kwalifikujących się do wystawienia: upomnienia, noty odsetkowej, tytułów wykonawczych; wydruk dokumentów: upomnienia (z opcją seryjnego wydruku), ewidencji wysłanych upomnień, noty odsetkowej (z opcją seryjnego wydruku), tytułów wykonawczych (z opcją seryjnego wydruku), reklamacji na pocztę, zawiadomienia do izby skarbowej, zaświadczenia o niezaleganiu z opłatami; 11. System powinien umożliwiać umożliwia tworzenie elektronicznych przelewów z programu i wysyłanie ich do systemu Multi-Cash w jednym z poniższych standardów: elixir-o; minibank; home-banking; DTPLI; termit; goniec; inny wskazany przez urząd format zgodny z formatem banku, w którym urząd posiada swój rachunek. 12. System powinien automatycznie księgować wyciąg bankowy na podstawie pliku otrzymywanego z banku obsługującego urząd marszałkowski zawierającego minimum: nr rachunku bankowego, którego dotyczy operacja, nazwę i dane płatnika, w tym numer rachunku bankowego, kwotę operacji, datę dokonania wpłaty, datę zaksięgowania w systemie bankowym, opis dokonanego przelewu przez płatnika (czego dotyczy wpłata); 13. Ponadto system powinien umożliwiać: automatyczne wyszukanie płatnika wnoszącego opłatę oraz należności, do której jest ona wnoszona; automatycznie uzupełniać bazę o dane płatnika na podstawie danych zawartych na wyciągu bankowym; umożliwiać raportowanie danych o niepoprawnych oraz powielonych numerach rachunków bankowych płatników w bazie danych. 4

5 II. W zakresie przepisów dotyczących bezpieczeństwa przechowywania danych system musi realizować obowiązki: 1) zarządzania prawami i dostępem użytkowników do Systemu, 2) rejestracja zdarzeń w bazie (logowanie, modyfikacja danych, itp.), 3) zarządzania logami (określanie szczegółowości rejestracji), 4) określania uprawnień dla poszczególnych grup użytkowników, a w szczególności: a. zapewnia zabezpieczenie zgromadzonych danych, b. zapewnia dostęp do Systemu tylko dla użytkowników z poprawnym, ważnym i niezablokowanym kontem, c. wymusza stosowanie formatu i długości haseł wymaganych ustawą o ochronie danych osobowych, między innymi: i. kontroluje czy hasła składają się, z co najmniej określonej przez administratora (np. ośmiu) znaków, ii. kontroluje czy hasła zawierają znaki, z co najmniej trzech, spośród czterech następujących kategorii, wielkie litery angielskie (od A do Z), małe litery angielskie (od a do z), cyfry systemu dziesiętnego (od 0 do 9), znaki niealfabetyczne (na przykład!, $, #, %), d. wymusza zmianę haseł dla użytkownika Systemu po określonym czasie, e. zapewnia unikalność i brak możliwości ponownego użycia tego samego hasła, nie wcześniej niż po określonej przez administratora ilości zmian (pamięta co najmniej sześć haseł, skojarzonych z kontem użytkownika, zanim będzie można ponownie użyć stosowanego wcześniej hasła), f. umożliwia tworzenie profili użytkowników i automatyzuje nadawanie uprawnień dla poszczególnych typów użytkowników (np. dyrektor, administrator, koordynator, księgowa, inspektor, stażysta), g. umożliwia nadawanie praw zdefiniowanym grupom użytkowników do określonych funkcjonalności Systemu, spośród listy zdefiniowanych uprawnień (np. prawo do zaksięgowania wpłat, prawo do dokonania przesunięcia środków, prawo do zmiany danych jednostki organizacyjnej, prawo do wystawienia upomnienia, prawo do połączenia płatników, dodawania nowych obiektów, itd.), h. umożliwia nadawanie praw zdefiniowanym grup użytkowników do określonych jednostek organizacyjnych wg zdefiniowanych wzorców tj. praw dostępu do jednostki z wybranej gminy / powiatu, i. wspomaga zarządzanie bazą danych Systemu m.in. poprzez: i. umożliwienie blokowania płatników m.in. poprzez oznaczenie, że prace na płatniku zostały zakończone w danym roku, 5

6 3. System umożliwia ponadto: ii. zapamiętanie, który użytkownik i kiedy oznaczył danego płatnika i zdecydował, że prace na nim są zakończone - zamknięcie płatnika. 1) wykonanie raportu ilości wykonanych przez danego użytkownika, w określonym przedziale czasowym czynności w Systemie (np.: weryfikacji), 2) rejestrowanie historii aktywności użytkowników poprzez: a. zapisanie w bazie danych informacji o tym który użytkownik i kiedy (data i godzina) logował/wylogował się, b. tworzenie zestawień o czasie pracy, godzinie zalogowania i wylogowania poszczególnych użytkowników, c. tworzenie i modyfikowanie zestawień o dokonanych zmianach wg zadanych kryteriów z możliwością ich eksportu np. do Excela. 4. System ma możliwość eksportu danych w formacie XML o strukturze pliku, której szczegółowa specyfikacja pozwala na przeniesienie danych z lub do innych systemów. 5. System zapewnia bezpieczeństwo przetwarzania danych wpływających na rozliczenia finansowe zgromadzone w bazie poprzez rejestrowanie historii operacji wykonanych w Systemie: 1) zapisanie wszystkich zmian w bazie danych, 2) rejestrowanie nazwy konta użytkownika który dokonał zmiany, 3) data i godzina operacji, 4) rejestracja zakresu zmiany (dana sprzed dokonania zmiany i po zmianie), historia 5) transakcji, 5. System jest transakcyjny. III. Wymogi techniczne dotyczące systemu. Założenia techniczne oparte są o infrastrukturę IT Urzędu Marszałkowskiego i System powinien być zbudowany jako dwu lub wielowarstwowa, rozproszona aplikacja w architekturze klient-serwer. a.) Architektura dwuwarstwowa Klient Serwer: Oferowany system powinien być w konfiguracji jako systemem zamknięty, tzn. aplikacje pracują w wewnętrznej sieci Urzędu i żadne informacje nie są udostępniane na zewnątrz. Wszystkie pliki aplikacji oraz pliki bazy danych przechowywane są na stacji lub jednym serwerze pracującym pod kontrolą systemu operacyjnego (SO) MS Windows Serwer Wszystkie istotne algorytmy systemu umieścić po stronie aplikacji lub serwera. - Interfejs użytkownika systemu powinien pracować w środowisku MS Windows xp, vista,7 i wykorzystywać zdefiniowane dla niego standardy. 6

7 - Bazą danych, posadowioną na dedykowanym serwerze, będzie administrował relacyjny system zarządzania bazą danych MS Serwer SQL. b.) Architekturze klient-serwer oparta o technologię webową. Architekturze klient-serwer oparta o technologię webową gdzie wyodrębnienie się następujące warstwy: Warstwa danych Serwer bazy danych, składnica plików Warstwa aplikacji serwer aplikacyjny, Web Services Warstwa prezentacji danych cienki klient. Serwer bazy danych. W przypadku gdy Wykonawca chce wykorzystać system relacyjnych baz danych inny niż MS-SQL, zobowiązany jest dostarczyć odpowiednią licencję dedykowaną do systemu, cena licencji powinna zostać wliczona w koszt wykonania systemu. System zarządzania bazą danych nie powinien być oparty o licencję oprogramowania otwartego. Warstwa prezentacji danych powinna być oparta o przeglądarkę internetową zrealizowana w języku HTML, DHTML, XML, JavaScript generowana przez warstwę aplikacji. Aplikacja powinna prawidłowo pracować na przeglądarce internetowej Microsoft Internet Explorer w wersji 7 i 8. 7