UMOWA /2013/ /
UMOWA /2013/ /
zawarta w dniu. 2013 r. w Warszawie, w wyniku przeprowadzenia postępowania
ofertowego, pomiędzy:
Narodowym Funduszem Ochrony Środowiska i Gospodarki Wodnej,
z siedzibą w Warszawie, , przy xx. Xxxxxxxxxxxxxxxx 0x, 00-000 Xxxxxxxxx, NIP: 000-00-00-000, REGON: 142137128, reprezentowanym przez:
1. ..............................................- ....................................
2. ..............................................- ....................................
zwanym dalej „Zamawiającym”, a
....................................... z siedzibą w .........................., ul. ....................., 00-000 ,
wpisaną/ym do Krajowego Rejestru Sądowego prowadzonego przez Sąd ......................
w.........................., .............Wydział Gospodarczy Krajowego Rejestru Sądowego, pod numerem
KRS........................., NIP ............................, REGON ..............................., zwaną/ym dalej
„Wykonawcą”,
reprezentowaną/ym przez
1. ..............................................- ....................................
2. ..............................................- ....................................
na podstawie , stanowiącego Załącznik nr 9 do niniejszej Umowy
zwanymi dalej łącznie „Stronami", zawierają Umowę o następującej treści:
§1
Definicje
Ilekroć w Umowie jest mowa o:
1. Błędzie - oznacza to:
a) W odniesieniu do Oprogramowania - wadę, której skutkiem jest funkcjonowanie Oprogramowania w sposób niezgodny ze specyfikacją usług i dokumentacją techniczną Oprogramowania, o których mowa w Załącznikach nr 1 i 3. Do Błędów zalicza się także nieprawidłowe działanie systemu, którego częścią jest Oprogramowanie, wynikające z wadliwej współpracy Oprogramowania z bazą danych, systemem operacyjnym lub sprzętem komputerowym,
b) W odniesieniu do Produktów - wadę, której skutkiem jest nieprawidłowa zawartość
Produktu wymagająca jego Naprawy według wskazówek Zamawiającego.
2. Błędzie Krytycznym - oznacza to poważny Błąd uniemożliwiający dokonanie odbioru lub eksploatacji odebranego Produktu:
a) W odniesieniu do Oprogramowania - szczególny przypadek Błędu -nieprawidłowość w funkcjonowaniu Oprogramowania lub systemu, którego częścią jest Oprogramowanie, uniemożliwiająca realizację kluczowej funkcjonalności przez Oprogramowanie. Błędem Krytycznym jest również nieprawidłowe działanie Oprogramowania lub systemu objawiające się między innymi poprzez:
I. Uzyskiwanie z Oprogramowania informacji niespójnych, niezgodnych z prawidłowymi danymi wejściowymi lub nie wynikających z prawidłowych danych wejściowych (uwzględniając uprawnienia użytkownika).
II. Wyznaczanie przez algorytmy obliczeniowe Oprogramowania nieprawidłowych wartości – w przypadku, gdy dane wejściowe i parametry obliczeń są prawidłowe,
III. Uniemożliwienie pracy w wyniku obciążenia Oprogramowania przez maksymalną, przewidzianą w umowie liczbę użytkowników,
IV. Zawieszanie się bazy danych podczas pracy Oprogramowania, następujące w wyniku
pracy z Oprogramowaniem,
V. Powtarzające zawieszanie się lub resetowanie komputerów spowodowane pracą
Oprogramowania,
VI. Utratę lub niedostępność wprowadzonych do Oprogramowania danych lub przez
Oprogramowanie wyznaczonych.
b) W odniesieniu do Produktów - szczególny przypadek Błędu - nieprawidłowa zawartość Produktu Umowy dotykająca fundamentalnych i zasadniczych kwestii, wymagająca jego Naprawy, według wskazówek Zamawiającego.
3. Dniu roboczym - oznacza to dzień od poniedziałku do piątku, poza dniami ustawowo wolnymi od pracy. Dzień roboczy u Zamawiającego rozpoczyna się o 7.30 i kończy o15.30.
4. Dokumentacji - wszelka dokumentacja dostarczana przez Wykonawcę w ramach realizacji
Umowy.
5. Roboczogodzinie - oznacza to godzinę zegarową roboczego świadczenia Usług przez Wykonawcę.
6. Godzinie roboczej - oznacza to godzinę zegarową wchodzącą w skład Dnia Roboczego.
7. Karcie Zgłoszenia Gwarancyjnego - oznacza to dokument, którego wzór określony jest w
§7 Załącznika nr 4, podpisany przez upoważnionego przedstawiciela Zamawiającego
i przekazany upoważnionemu przedstawicielowi Wykonawcy przy dokonywaniu Zgłoszenia Gwarancyjnego, zawierającej komplet posiadanych informacji dotyczących Błędu lub Błędu Krytycznego.
8. Licencji - oznacza licencję niewyłączną na korzystanie z Oprogramowania na terytorium Rzeczypospolitej Polskiej w zakresie i na zasadach opisanych w Załączniku nr 2.
9. Sublicencji – oznacza prawo do przenoszenia praw z Licencji na osoby trzecie udzielone
Zamawiającemu przez Wykonawcę w ramach Licencji.
10. Naprawie - oznacza to usunięcie Błędu lub Błędu Krytycznego lub dostarczenie Zamawiającemu Produktów lub Oprogramowania albo jego elementów wolnych od Błędów i Błędów Krytycznych. W odniesieniu do Oprogramowania, Wykonawca zapewnia, że po dokonaniu naprawy, Oprogramowanie funkcjonuje zgodnie z:
a) wymaganiami określonymi w Załączniku nr 1,
b) wynikami Usług opisanych w Załączniku nr 3,
c) dokumentacją Oprogramowania.
11. Umowie - oznacza to niniejszą umowę.
12. Usłudze - oznacza to usługi świadczone przez Wykonawcę na podstawie Umowy i zgodnie z zasadami określonymi w Umowie.
13. Oprogramowaniu - oznacza to oprogramowanie dostarczone i/lub będące wynikiem
realizacji Umowy.
14. Powiadomieniu, przekazaniu, wezwaniu, dostarczeniu określonego dokumentu lub jego pisemnej formy - oznacza to wymóg przesłania skanu dokumentu na adres email koordynatora Umowy w ciągu trzech dni roboczych - chyba, że postanowienia Umowy stanowią inaczej.
15. Produktach - oznacza to wszelkie działania, utwory, kody źródłowe Oprogramowania, dokumenty i opracowania wykonane lub dostarczone w wyniku realizacji Usług świadczonych w ramach Umowy.
16. Protokole Przekazania - oznacza to dokument przedstawiony Zamawiającemu przez Wykonawcę po zakończeniu realizacji zlecenia będący podstawą do przeprowadzenia Procedury Odbioru.
17. Protokole Odbioru - oznacza to dokument podpisany przez Zamawiającego, potwierdzający odbiór Produktów zgłoszonych wcześniej do realizacji na formularzu zlecenia i przekazanych przez Wykonawcę Protokołem Przekazania.
18. Sile wyższej - oznacza to zdarzenie zewnętrzne, niemożliwe do przewidzenia i zapobieżenia, na którego zaistnienie i przebieg nie ma wpływu żadna ze stron Umowy, a które jednocześnie ma wpływ na realizację przedmiotu zamówienia.
19. Systemie - oznacza to środowisko programowe i techniczne systemu bazy danych, systemów operacyjnych, którego dotyczą Usługi świadczone w ramach Umowy.
20. Zgłoszeniu Gwarancyjnym - oznacza to przekazanie upoważnionemu przedstawicielowi Wykonawcy informacji o Błędzie lub Błędzie Krytycznym poprzez przekazanie mu Karty Zgłoszenia Gwarancyjnego i poprzez wykonanie innych przewidzianych Załącznikiem nr 4 czynności.
§2
Przedmiot Umowy
1. Na mocy Umowy Wykonawca zobowiązuje się wykonać przedmiot umowy opisany
w Załączniku nr 1 w tym:
a) dostarczy Zamawiającemu Oprogramowanie, które zostało wyszczególnione w Załączniku nr 2, spełniające wymagania określone w Załączniku nr 1. Wykonawca przeniesie na Zamawiającego majątkowe prawa autorskie do Oprogramowania, którego jest autorem, na wszystkich polach eksploatacji znanych w dniu zawierania Umowy, bez żadnych ograniczeń czasowych lub terytorialnych, w zakresie i na zasadach opisanych w Załączniku nr 2. Wykonawca zapewni udzielenie Zamawiającemu Licencji na korzystanie z Oprogramowania przez osoby trzecie, przez właścicieli majątkowych praw autorskich tego Oprogramowania, w zakresie i na zasadach opisanych w Załączniku nr 2,
b) wykona Usługi w zakresie i na zasadach opisanych w Załączniku nr 3,
c) udzieli gwarancji w zakresie i na zasadach opisanych w Załączniku nr 4.
2. Przedmiot Umowy, o którym mowa w ust. 1 lit. a) i b), będzie realizowany etapami, zgodnie
z harmonogramem zawartym w Załączniku nr 5.
3. Przedmiot Umowy będzie realizowany zgodnie z metodyką zarządzania projektami Prince2.
4. Dzień zawarcia Umowy oznacza dzień podpisania Umowy wskazany na stronie pierwszej
Umowy.
§3
Odpowiedzialność Stron
1. Wykonawca oświadcza, że zapoznał się z wymaganiami dotyczącymi Oprogramowania
zawartymi w Załączniku nr 1.
2. Wykonawca oświadcza, że Oprogramowanie, o którym mowa w §2 ust. 1 lit. a) zostanie wdrożone w ramach Usług, o których mowa w §2 ust. 1 lit. b), w taki sposób, aby Oprogramowanie działało zgodnie z:
a) wymaganiami określonymi w Załączniku nr 1,
b) wynikami Usług opisanych w Załączniku nr 3,
c) dokumentacją Oprogramowania.
3. Wykonawca zobowiązuje się do wykonania prac składających się na przedmiot Umowy z zachowaniem najwyższej profesjonalnej staranności, wymaganej od podmiotu profesjonalnie wykonującego usługi w obszarze Technologii Informatycznych.
4. Zamawiający udzieli Wykonawcy informacji oraz udostępni dokumentację znajdującą się w posiadaniu Zamawiającego, w zakresie, w jakim Zamawiający uzna to za konieczne do prawidłowej realizacji Umowy.
5. Zamawiający oświadcza, że jest świadom, że realizacja przedmiotu Umowy wymaga jego współpracy z Wykonawcą i zobowiązuje się do udostępniania Wykonawcy wszelkich wyjaśnień niezbędnych do realizacji przedmiotu Umowy. Jeżeli Strony nie zdefiniowały danego działania niezbędnego dla prawidłowej realizacji Umowy, jako obowiązku Zamawiającego, Stroną zobowiązaną do wykonania takiego działania jest Wykonawca.
6. Wykonawca zobowiązuje się do bieżącego konsultowania z Zamawiającym zagadnień dotyczących realizowanego przedmiotu Umowy.
7. Wykonawca zobowiązany jest do ścisłej współpracy z Zamawiającym i niezwłocznego informowania Zamawiającego o wszelkich okolicznościach mogących mieć wpływ na prawidłowość lub terminowość realizacji Umowy.
8. Wykonawca zobowiązuje się do realizacji przedmiotu Umowy w sposób minimalizujący uciążliwość prac dla Zamawiającego.
9. Wykonawca oświadcza, że:
a) posiada wiedzę, doświadczenie i narzędzia informatyczne niezbędne do prawidłowego
wykonania Umowy,
b) przedmiot Umowy zostanie zrealizowany przez profesjonalny zespół specjalistów,
c) dostarczone przez niego Oprogramowanie będzie zgodne z Umową i będzie realizowało wszystkie funkcjonalności opisane w Dokumentacji przy zachowaniu określonej w Dokumentacji wydajności.
10. Zamawiający uprawniony jest do skorzystania w trakcie wykonywania przedmiotu Umowy z usług strony trzeciej (Audytora) celem kontroli jakości i sposobu prowadzenia całości lub poszczególnych prac objętych Umową.
11. Wykonawca zobowiązany jest do udzielenia Audytorowi, posiadającemu pisemne upoważnienie udzielone przez Zamawiającego wszelkich informacji, danych i wyjaśnień w żądanym zakresie oraz udostępnienia i zaprezentowania rezultatów prowadzonych prac, jak również zapewnienia możliwości ich kontroli.
12. Zamawiający ponosi koszty wszelkich przeprowadzanych przez niego lub na jego zlecenie audytów oraz wszelkich innych kontroli realizacji prac objętych Umową.
13. Osobami upoważnionymi do podpisywania dokumentów związanych z realizacją Umowy, są:
a) w imieniu Xxxxxxxxxxxxx:
• Pan/i......................................................
• Pan/i......................................................
b) W imieniu Wykonawcy
• Pan/i......................................................
• Pan/i......................................................
Każda ze Stron może zmienić osobę upoważnioną do podpisywania dokumentów związanych z realizacją Umowy, poprzez pisemne powiadomienie drugiej Strony
14. Koordynatorem Umowy jest ze strony:
a) Zamawiającego:
• Pan/i ..........................................
• Adres e-mail: @xxxxxxx.xxx.xx
Telefon stacjonarny: x0000 0000 ........... telefon gsm: +48 ............................
b) Wykonawcy:
• Pan/i...................................
• Adres e-mail: ………………………………
• Telefon stacjonarny: +48..................., telefon gsm: +48 ..........................
Każda ze Stron może zmienić koordynatora, poprzez pisemne powiadomienie drugiej Strony.
§4
Wynagrodzenie
1. Wynagrodzenie z tytułu wykonania przedmiotu Umowy określonego w §2 ust. 1, wynosi
.............. zł brutto (słownie:.................................................złotych brutto), w tym podatek
VAT 23%.
2. Kwoty wymienione w niniejszym paragrafie zawierają wszystkie koszty, jakie powstaną w związku z realizacją przedmiotu Umowy, w tym podatki i inne opłaty przewidziane prawem.
3. Kwota wskazana w ust. 1 oraz w ust. 2, obejmuje także wynagrodzenie za:
a) wykonanie elementów autorskich, w tym Oprogramowanie i Produkty,
b) przekazanie kodów źródłowych do Oprogramowania,
c) przeniesienie majątkowych praw autorskich oraz prawa zezwalania na wykonywanie zależnego prawa autorskiego do elementów autorskich, na wszystkich polach eksploatacji objętych Umową, w szczególności w zakresie i na zasadach określonych w Załączniku nr 2,
d) udzielenie Licencji na Oprogramowanie nabyte od osób trzecich,
e) udzielenie gwarancji w zakresie i na zasadach opisanych w Załączniku nr 4.
4. Ceny określone w Umowie zostaną zapłacone w złotych polskich na podstawie prawidłowo
wystawionych faktur VAT, otrzymanych i zaakceptowanych przez Zamawiającego.
§5
Płatności
1. Strony ustalają, że płatność za wykonanie przedmiotu Umowy nastąpi po zrealizowaniu wszystkich prac objętych Umową.
2. Strony ustalają, że Wykonawca wystawi fakturę po wykonaniu prac objętych Umową oraz po podpisaniu przez Xxxxxxxxxxxxx Protokołu Odbioru Końcowego z wynikiem pozytywnym zgodnie z procedurą odbioru, o której mowa w §6.
3. Strony ustalają, że Zamawiający zapłaci wynagrodzenie za wykonane prace w ciągu 30 dni od otrzymania i zaakceptowania przez Zamawiającego prawidłowo wystawionych faktur.
4. Zapłata zostanie dokonana w formie przelewu, na rachunek bankowy Wykonawcy wskazany
na fakturze.
5. Za zwłokę w zapłacie wynagrodzenia Zamawiający zapłaci na żądanie Wykonawcy odsetki
ustawowe za każdy dzień zwłoki.
6. Termin płatności uważa się za dotrzymany, jeżeli nie później niż w ostatnim dniu terminu
płatności zostanie uznany rachunek Wykonawcy.
§6
Warunki przekazania i odbioru
1. Przekazanie Oprogramowania i Produktów będzie następowało etapami zgodnie
z harmonogramem stanowiącym Załącznik nr 5.
2. Dokumenty, o których mowa w niniejszym paragrafie, muszą być przedkładane w formie pisemnej. Strony dopuszczają składanie dokumentów za pośrednictwem poczty elektronicznej lub faksu. W przypadku, gdy jedna ze Stron prześle dokument za pośrednictwem poczty elektronicznej lub faksu, druga Strona zobowiązana jest do potwierdzenia otrzymania dokumentu, najpóźniej w następnym dniu roboczym, od otrzymania dokumentu. W przypadku, gdy jedna ze Stron prześle dokument pocztą elektroniczną lub faksem, zobowiązana jest również do przesłania oryginału dokumentu w formie pisemnej w postaci papierowej.
3. Wykonawca będzie dokonywał dostawy Oprogramowania i Produktów oraz protokołów w sposób określony w załącznikach opisujących Oprogramowanie i poszczególne Produkty, na:
• adres xx. Xxxxxxxxxxxxxx 0x, 00-000 Xxxxxxxx, z dopiskiem Departament Rozwoju
Systemów Informatycznych - Projekt „MODUŁ DOM”,
• adres poczty elektronicznej @xxxxxxx.xxx.xx,
• numer faksu: 22 45 90 .....
Zamawiający będzie dostarczał protokoły na:
• adres: ul. ....... ............., 00-000 ,
• adres poczty elektronicznej: .............@ ,
• numer faksu:+48.....................................
Ewentualne zmiany w zakresie ww. danych stanowią dopuszczalną zmianę umowy.
4. Procedurze odbioru opisanej poniżej podlegają wszystkie etapy prac wyszczególnione w harmonogramie stanowiącym Załącznik nr 5 oraz wszystkie Produkty i Usługi wymienione w Załączniku nr 3.
5. Wykonawca każdorazowo po zakończeniu prac objętych odbiorem, przekaże Zamawiającemu Oprogramowanie lub Produkty wraz z Protokołem Przekazania, który stanowi zawiadomienie o zakończeniu prac objętych odbiorem. Otrzymanie Protokołu Przekazania przez Zamawiającego jest równoznaczne ze zgłoszeniem przez Wykonawcę gotowości do odbioru Oprogramowania lub Produktów. Wzór Protokołu Przekazania stanowi Załącznik nr 6.
6. Każdorazowo przed przekazaniem przez Wykonawcę do odbioru Oprogramowania i/lub Produktów Zamawiającemu, Wykonawca zaprezentuje Zamawiającemu bezbłędne i prawidłowe działanie Oprogramowania będącego przedmiotem odbioru.
7. Wykonawca zobowiązuje się do przekazania do odbioru Oprogramowania i Produktów pozbawionych Błędów i Błędów Krytycznych.
8. Za datę wykonania części Umowy będącej przedmiotem odbioru uznaje się datę podpisania odpowiedniego Protokołu Odbioru lub Protokołu Odbioru Końcowego z wynikiem pozytywnym. Wzór Protokołu Odbioru stanowi Załącznik nr 7.
9. Zamawiający jest zobowiązany do przeprowadzenia odbioru, poprzez przetestowanie lub zweryfikowanie Oprogramowania i/lub Produktów oraz podpisanie Protokołu Odbioru, w terminie 20 dni roboczych od dnia otrzymania Protokołu Przekazania. Strony w Protokole Przekazania mogą ustalić inny termin przeprowadzenia odbioru Oprogramowania lub Produktów. Protokół Odbioru dla swej skuteczności musi zostać podpisany przez Zamawiającego.
10. W przypadku wydłużenia terminu odbioru, o którym mowa w ust. 9, z przyczyn leżących po stronie Zamawiającego, terminy realizacji pozostałych zadań określonych w Załączniku nr 5 ulegną stosownemu przesunięciu o okres wydłużenia.
11. W przypadku podpisania Protokołu Odbioru z wynikiem negatywnym Strony uznają Oprogramowanie lub Produkt za nieodebrany, a Protokół Przekazania staje się bezskuteczny. W takim przypadku Wykonawca w terminie 5 dni roboczych od dnia otrzymania Protokołu Odbioru przez Wykonawcę usunie Błędy i Błędy Krytyczne wyspecyfikowane w Protokole Odbioru i ponownie zgłosi Oprogramowanie lub Produkty do odbioru stosownie do postanowień niniejszego paragrafu. Za datę wykonania części Umowy będącej przedmiotem odbioru, z uwzględnieniem wszystkich uwag i zastrzeżeń umieszczonych w Protokole Odbioru z wynikiem negatywnym, uznaje się datę podpisania odpowiedniego Protokołu Odbioru z wynikiem pozytywnym.
12. Kompletność i prawidłowość wykonania prac określonych niniejszą Umową stwierdza Protokół Odbioru Końcowego. Warunkiem podpisania Protokołu Odbioru Końcowego jest odebranie przez Zamawiającego Oprogramowania i wszystkich Produktów, o których mowa
w ust. 4 potwierdzone Protokołami Odbioru z wynikiem pozytywnym. Protokół Odbioru Końcowego dla swej skuteczności musi być podpisany przez przedstawicieli obu Stron. Wzór Protokołu Odbioru Końcowego stanowi Załącznik nr 8.
13. Protokół Odbioru, zostanie przekazany Wykonawcy najpóźniej w ciągu 1 Dnia roboczego po jego podpisaniu przez Xxxxxxxxxxxxx oraz przesłany listem poleconym w terminie do 5 Dni roboczych na adres siedziby Wykonawcy.
14. Protokół Odbioru z wynikiem pozytywnym sporządzony i podpisany na zasadach określonych w ustępach poprzedzających stanowi dowód prawidłowego i kompletnego wykonania etapu prac.
§7
Kary umowne, odstąpienie od Umowy
1. Strony zastrzegają karę umowną za niewykonanie bądź nienależyte wykonanie przedmiotu Umowy w przypadku niedostarczenia Oprogramowania lub Produktów lub niewykonania Usługi w terminie określonym w §2 ust. 2 i §6 ust. 11 Umowy. Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 0,3% wartości brutto kwoty określonej w §4 ust. 1 za każdy dzień opóźnienia. Wysokość kar umownych z tego tytułu, nie przekroczy wartości brutto kwoty określonej w §4 ust 1.
2. Zamawiający ma prawo odstąpić od Umowy w przypadku, gdy:
a) Wykonawca, z przyczyn leżących po jego stronie, nie przystąpi do realizacji Umowy
w terminie 2 tygodni od daty podpisania Umowy.
b) Wykonawca realizuje przedmiot Umowy niezgodnie z jej postanowieniami lub nie wywiąże się z obowiązków określonych w Umowie, z zastrzeżeniem, iż Zamawiający uprzednio wezwie Wykonawcę do zaniechania dalszych naruszeń i przywrócenia stanu zgodnego z Umową określając dodatkowy termin nie krótszy niż 14 dni. Po bezskutecznym upływie określonego terminu, Zamawiający może odstąpić od Umowy niezwłocznie powiadamiając Wykonawcę o fakcie odstąpienia od Umowy na piśmie.
c) Zamawiający podpisał, co najmniej 3 Protokoły Odbioru z wynikiem negatywnym lub Wykonawca odmówił usunięcia błędów wykazanych w Protokole Odbioru.
d) Zamawiający podpisał łącznie, co najmniej 6 Protokołów Odbioru z wynikiem
negatywnym.
e) Opóźnienie w realizacji Usługi, bądź dostawie Oprogramowania lub Produktu
przekroczyło 60 dni kalendarzowych.
f) Wykonawca został postawiony w stan likwidacji, złożono wniosek o ogłoszenie jego upadłości, lub został wydany nakaz zajęcia majątku Wykonawcy.
g) Zaistniała istotna zmiana okoliczności powodująca, że wykonanie Umowy nie leży w interesie publicznym, czego nie można było przewidzieć w chwili zawarcia Umowy.
3. Każda ze Stron uprawniona jest do dochodzenia roszczeń odszkodowawczych na zasadach
ogólnych Kodeksu cywilnego.
4. W przypadku odstąpienia od Umowy przez którąkolwiek ze Stron, Wykonawca zachowuje prawo do wynagrodzenia z tytułu wykonanych zleceń, które zostały odebrane Protokołami Odbioru z wynikiem pozytywnym. Zamawiający nabywa majątkowe prawa autorskie do Oprogramowania i Produktów, na zasadach i w granicach określonych w Załączniku nr 2.
5. W przypadku odstąpienia od Umowy przez którąkolwiek ze Stron, z przyczyn leżących po stronie Wykonawcy, Zamawiający nie będzie zobowiązany zwrócić Wykonawcy kosztów, jakie Wykonawca poniósł w związku z realizacją Umowy, z zastrzeżeniem ust. 4.
6. W przypadku, gdy Zamawiający lub Wykonawca zamierza odstąpić od Umowy, zobowiązany jest do przesłania Wykonawcy oświadczenia o odstąpieniu od Umowy, listem poleconym za zwrotnym poświadczeniem odbioru.
7. W przypadku odstąpienia od Umowy przez którąkolwiek ze Stron, z przyczyn leżących po stronie Wykonawcy, Zamawiający jest uprawniony do żądania zapłaty kary umownej w wysokości 20% kwoty brutto określonej w §4 ust. 1.
8. Wykonawca ponosi odpowiedzialność za szkody wyrządzone Zamawiającemu w wyniku
zaniedbania lub celowego działania.
9. W przypadku naruszenia zasad poufności, o których mowa w §8, przez Wykonawcę podczas wykonania zobowiązań wynikających z Umowy, Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 10% kwoty brutto, określonej w §4 ust. 1, za każdy przypadek stwierdzonego naruszenia zasad. Wartość kary umownej z tego tytułu nie przekroczy wartości brutto kwoty określonej w §4 ust 1.
10. Kary umowne określone w ust.1, ust 7, ust. 9 niniejszego paragrafu oraz określone w § 4 ust. 1 Załącznika nr 4 mogą być naliczane niezależnie od siebie i kumulować się.
11. Zamawiający może, za zgodą Wykonawcy potrącić należne mu kary umowne
z wynagrodzenia Wykonawcy.
12. W przypadku, gdy wysokość poniesionej szkody przewyższa wysokość zastrzeżonych kar umownych, Strony mogą dochodzić odszkodowania na zasadach ogólnych.
13. Postanowienia dotyczące kar umownych obowiązują pomimo wygaśnięcia, rozwiązania lub odstąpienia od Umowy.
§8
Poufność
1. Wykonawca zobowiązuje się do nie ujawniania osobom trzecim jakichkolwiek danych i informacji dotyczących Zamawiającego, jakie uzyskał w związku z realizacją przedmiotu Umowy, chyba, że Wykonawca otrzyma od Zamawiającego pisemną zgodę na ich ujawnienie.
2. Zamawiający zobowiązuje się do nie ujawniania osobom trzecim jakichkolwiek danych i informacji dotyczących Wykonawcy, jakie uzyskał w związku z realizacją Umowy, chyba, że Zamawiający, otrzyma od Wykonawcy pisemną zgodę na ich ujawnienie.
3. Obowiązek nie ujawniania danych i informacji dotyczących drugiej Strony Umowy uzyskanych w związku z wykonywaniem przedmiotu Umowy wiąże Strony również po wygaśnięciu, jak i po rozwiązaniu Umowy.
4. Ograniczenia określone w ust. 1 i ust. 2 nie dotyczą informacji uzyskanych przez Xxxxxx od osób trzecich zgodnie z prawem oraz nienaruszających zobowiązań tych osób do nie ujawniania takich informacji oraz informacji, które są publicznie znane.
5. Strony zobowiązują się do przestrzegania przepisów o ochronie danych osobowych.
§9
Zabezpieczenie danych osobowych
1. W przypadku, gdy Wykonawca będzie przetwarzać dane osobowe, Zamawiający upoważnia Wykonawcę do ich przetwarzania wyłącznie w zakresie i celu przewidzianym Umową, tj. w zakresie wszelkich danych osobowych, które zamieszczone są lub będą w Systemie.
2. Wykonawca zobowiązuje się zachować w tajemnicy wszelkie informacje poufne, nie wykorzystać ich w celu innym niż wynikającym z Umowy oraz przestrzegać zasad wskazanych w niniejszej Umowie oraz przepisów ustawy z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (t.j. Xx. X. x 0000 x. Xx 000, poz. 926 z późn. zm.).
3. Wykonawca nie może wprowadzać, zmieniać, kopiować ani przekazywać przetwarzanych przez Wykonawcę danych osobowych udostępnionych przez Zamawiającego.
4. Do przetwarzania danych osobowych dopuszczone mogą być jedynie osoby wskazane przez wykonawcę oraz imiennie upoważnione przez Zamawiającego.
5. W terminie 7 dni od dnia zawarcia Umowy, Wykonawca przedstawi Zamawiającemu listę osób, które będą dopuszczone do przetwarzania danych osobowych. Zamawiający udzieli tym osobom pisemnego upoważnienia, o którym mowa w ust. 4.
6. Upoważnieni przez Zamawiającego specjaliści Wykonawcy będą mogli przetwarzać dane osobowe tylko i wyłącznie przy użyciu indywidualnie przypisanych kont użytkownika nadanych im przez Zamawiającego. Udostępnianie indywidualnie przypisanych kont użytkownika osobom innym niż upoważnione przez Zamawiającego będzie traktowane jako naruszenie warunków Umowy.
§10
Postanowienia końcowe Umowy
1. Załączniki wymienione w treści Umowy stanowią jej integralną część.
2. Strony zobowiązują się do natychmiastowego informowania o zmianie formy organizacyjno- prawnej, zgłoszeniu wniosku o ogłoszenie upadłości lub podjęciu postępowania układowego (ugodowego) oraz o innych istotnych zmianach sytuacji prawnej i danych rejestrowych.
3. Strony nie ponoszą odpowiedzialności z tytułu niewykonania lub nienależytego wykonania przedmiotu Umowy, które zostało spowodowane wystąpieniem Siły wyższej.
4. Strony zobowiązują się do wzajemnego, niezwłocznego powiadamiania się o zaistnieniu zdarzeń Siły wyższej.
5. Wszelkie zmiany Umowy wymagają formy pisemnej pod rygorem nieważności. Do zmian Umowy stosuje się art. 144 ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (t.j. Xx. X. x 0000 x. Xx 000, poz. 759 z późn. zm.). Każda zmiana, o której mowa w §3 ust. 13 i ust. 14, §6 ust. 3 i ust. 9 oraz w §3 ust. 3 Załącznika nr 2 traktowana jest, jako dopuszczalna zmiana Umowy.
6. Tytuły poszczególnych paragrafów mają wyłącznie charakter informacyjny i nie mogą stanowić podstawy do wykładni niniejszej Umowy.
7. Każda ze Stron oświadcza, że posiada zdolność prawną i pełną zdolność do czynności prawnych , a także jest prawidłowo umocowana do zawarcia Umowy.
8. Do spraw nie uregulowanych Umową mają zastosowanie przepisy Kodeksu cywilnego
i Ustawy Prawo Zamówień Publicznych.
9. Xxxxxx postanowiły, że wszelkie ewentualne spory wynikłe na tle Umowy rozwiązywane będą
w drodze porozumienia Stron. W przypadku braku możliwości rozwiązania sporu w drodze
porozumienia, spory wynikające ze stosowania Umowy poddane zostaną pod rozstrzygnięcie sądu właściwego dla siedziby Zamawiającego.
10. Umowę sporządzono w dwóch jednobrzmiących egzemplarzach, po jednym dla każdej ze
Stron.
ZA WYKONAWCĘ ZA ZAMAWIAJĄCEGO
Zestawienie załączników:
Załącznik 1 - Wymagania dotyczące Oprogramowania
Załącznik 2 - Licencje i prawa autorskie
Załącznik 4 - Warunki gwarancji Załącznik 5 - Harmonogram Załącznik 6 - Protokół przekazania Załącznik 7 - Protokół odbioru
Załącznik 8 - Protokół odbioru końcowego
Załącznik 9 - dokument potwierdzający umocowanie przedstawiciela Wykonawcy do działania
w jego imieniu i na jego rzecz (pełnomocnictwo, odpis z KRS, inne).
„MODUŁ DOM”
Zawartość Strona
6.3.1. REJESTR UMÓW O WSPÓŁPRACY Z BANKAMI 11
6.3.2. ZAMYKANIE UMOWY O WSPÓŁPRACY Z BANKIEM 14
6.3.3. REJESTR INFORMACJI O PRZEPROWADZONEJ KONTROLI TRWAŁOŚCI 14
6.4.1. PRZEGLĄDANIE INFORMACJI O BENEFICJENCIE 17
6.4.2. KOREKTA DANYCH BENEFICJENTA 18
6.5. REJESTR UMÓW KREDYTOWYCH 18
6.5.2. REJESTRACJA WPŁAT ZWIĄZANYCH ZE ZWROTEM DOTACJI 22
6.6.1. ZGŁOSZENIE PROBLEMU Z PIT-em BENEFICJENTA 28
6.6.2. RAPORTOWANIE PROBLEMÓW Z PIT-ami 29
6.7. REJESTR WYSTĄPIEŃ BANKÓW O ŚRODKI 29
6.7.1. WPROWADZANIE WYSTĄPIENIA 31
6.7.2. PRZEGLĄDANIE WYSTĄPIEŃ 35
6.7.3. WERYFIKACJA WYSTĄPIENIA ORAZ UMÓW PRZEPROWADZANA PRZEZ
6.7.6. REJESTRACJA WYPŁACONYCH DOTACJI 40
6.7.7. WYDRUK NEGATYWNIE ZWERYFIKOWANEGO WYSTĄPIENIA 42
6.7.8. WPROWADZENIE DANYCH O WYSYŁCE ODRZUCONEGO WYSTĄPIENIA 42
6.8. REJESTR SPRAWOZDAŃ BANKU 42
6.8.1. WPROWADZANIE SPRAWOZDANIA 44
6.8.2. PRZEGLĄDANIE SPRAWOZDAŃ 46
6.8.3. WERYFIKACJA SPRAWOZDANIA BANKU PRZEZ PRACOWNIKÓW FUNDUSZU 46
6.9. REJESTR ARKUSZY EWALUACYJNYCH 47
8.1. PARAMETRY DODATKOWE MODUŁU DEFINIOWANE PRZEZ ADMINISTRATORA 48
8.2. FUNKCJE DOSTĘPNE DLA ADMINISTRATORA 49
8.3. SŁOWNIKI, Z KTÓRYCH KORZYSTA MODUŁ 49
11. WARUNKI TECHNICZNE ZAMAWIAJĄCEGO 62
1. Przedmiotem zamówienia jest wykonanie oprogramowania „MODUŁ DOM”, które będzie częścią systemu LSI, funkcjonującego w Narodowym Funduszu Ochrony Środowiska i Gospodarki Wodnej. Wymagana jest zgodność modułu z systemem LSI w następującym zakresie:
a) „MODUŁ DOM” będzie korzystać z zainstalowanych w LSI Słowników. Lista słowników będzie udostępniona na etapie tworzenia projektu technicznego.
b) Pomiędzy „MODUŁEM DOM” oraz systemem LSI, a także „MODUŁEM KOLEKTOR” zostanie zachowana spójność wyglądu ekranów.
c) Interfejs użytkownika oraz logika obsługi systemu będą podobne.
d) „MODUŁ DOM” i LSI będą wykorzystywały tę samą bazę danych MS SQL Serwer 2005.
e) „MODUŁ DOM” zostanie zintegrowany z oprogramowaniem MODUŁ KOLEKTOR na zasadach
opisanych w rozdziale 11 „Warunkii Techniczne Zamawiającego”
2. „MODUŁ DOM” zostanie napisany w Delphi 2007.
3. Wykorzystanie komponentów/narzędzi firm trzecich przy budowie „MODUŁU DOM” wymaga uzgodnienia z Zamawiającym.
4. W zakres zamówienia wchodzi realizacja opisanej poniżej specyfikacji, a ponadto:
1. Analiza załączonej specyfikacji i uzgodniony ze Zleceniodawcą projekt jej realizacji
2. Licencja na użytkowanie zamówionego oprogramowania
3. Prawa majątkowe dostarczonego oprogramowania
4. Instalacja oprogramowania u zamawiającego
5. Przekazanie dokumentacji użytkownika
6. Konsultacje i asysta wdrożeniowa w wymiarze co najmniej 12 godzin
7. Przekazanie dokumentacji technicznej dla programistów
8. Szkolenie programistów w wymiarze co najmniej 6 godzin
9. Gwarancja na okres 12 miesięcy
10. Gotowość do świadczenia usług modyfikacji systemu w zakresie nieprzekraczającym 40 godzin roboczych
1. WSTĘP
„MODUŁ DOM” ma zapewnić wsparcie dla obsługi udzielania przez NFOŚiGW dotacji na częściową spłatę kapitału kredytów oferowanych przez Banki z przeznaczeniem na określone cele proekologiczne, na podstawie zawartych umów o współpracy.
Za pomocą tej aplikacji obsługiwane będzie dofinansowanie udzielane osobom fizycznym na budowę
domów lub zakup mieszkań energooszczędnych.
2. SŁOWNIK
1. Bank - bank podpisujący Umowę kredytową z Beneficjentom, na podstawie Umowy z bankiem,
2. Beneficjent - osoba fizyczna zawierająca z Bankiem Umowę kredytu z dotacją na budowę domów energooszczędnych,
3. Dotacja - dokonywana jednorazowo przez Fundusz częściowa splata kapitału kredytu opisanego Umową kredytu z dotacją, po wypłaceniu Dotacji osobom fizycznym wystawiany jest PIT-8C,
4. Efekt przedsięwzięcia - rozumiany jako efekt ekologiczny, który zostanie uzyskany po osiągnięciu efektu rzeczowego polegającego na wykonaniu budynku/lokalu mieszkalnego w nowym budynku mieszkalnym, spełniającego warunki określone w Programie Priorytetowym. Miernikiem osiągnięcia efektu ekologicznego jest wskaźnik EUco. Osiągnięcie Efektu rzeczowego wymaga potwierdzonego protokołu końcowego odbioru i potwierdzenia Banku,
5. Ewaluacja - ocena wartości wdrażania „programu dopłat do kredytów na budowę domów energooszczędnych” z zastosowaniem określonych kryteriów oceny, podejmowana w celu określenia efektywności wdrażania oraz oszacowania w odniesieniu do celów.
6. Limit dla wypłat - określona w Umowie z Bankiem maksymalna suma Dotacji Wypłaconych w danym okresie; określa się również limit wypłat w danym roku dla umów zawartych w latach poprzednich,
7. Fundusz - NFOŚiGW,
8. Okres trwałości - okres (36 miesięcy), po osiągnięciu Efektu rzeczowego, w trakcie którego przedsięwzięcie może zostać skontrolowane, a w przypadku wyniku negatywnego Dotacja może zostać cofnięta (Bank zwraca Funduszowi dotację wraz z odsetkami jak od zaległości podatkowej).
9. Sprawozdanie - raport przekazywany przez Bank cztery razy w roku, podsumowujący udzielone
Kredyty i wypłacone Dotacje; sprawozdanie może zawierać wniosek o zmianę Xxxxxxx,
00. Umowa - umowa kredytowa zawarta przez Beneficjenta z Bankiem,
11. Umowa z Bankiem - zawarta przez Bank umowa o współpracy z Funduszem; zawiera x.xx. określenie Limitów,
12. Wystąpienie - wystąpienie Banku o wypłatę Dotacji dla osiągniętych Efektów rzeczowych określonych w załączonych Umowach.
13. Moduł, System, MODUŁ DOM – przedmiot zamówienia.
3. ZAŁOŻENIA
2. Uwzględniane są koszty kwalifikowane, na które zaciągnięty jest kredyt. Informacje przekazywane do
aplikacji zawierają również kwalifikowane koszty przedsięwzięcia ogółem.
3. Bank przeprowadza kontrolę nie mniej niż 25% przedsięwziąć ujętych w wystąpieniu o środki, liczonych narastająco w skali roku. Fundusz nie przyznaje dotacji, jeżeli po zweryfikowaniu, wystąpienie zawiera mniej niż 25% skontrolowanych przedsięwzięć, liczonych jw.
4. Wszystkie kwoty wyrażone są w PLN z dwoma miejscami po przecinku,
5. Dane będą przekazywane przez Banki w formie elektronicznej, w plikach XML o ustalonym formacie. Format xml oraz xsd zostanie udostępniony Wykonawcy.
6. Beneficjent może wziąć udział (otrzymać dotację) w programie tylko jeden raz.
7. Na przedsięwzięcie (budowa lub zakup) może być udzielona tylko i wyłącznie jedna dotacja.
8. Wdrożenie oprogramowania nie spowoduje ujemnych skutków dla funkcjonującego programu
„Kolektory”
9. Będzie możliwe ogólne (wspólne) raportowanie dla obydwu programów i dla każdego odrębnie.
4. PODMODUŁY
„MODUŁ DOM” będzie zawierał następujące części:
2. moduł administracyjny obsługujący użytkowników i ich uprawnienia oraz słowniki i logi systemu, Proces (por. rozdział 5.) będzie wspierany przez następujące narzędzia niebędące częścią „MODUŁU DOM”:
1. eksporter – zewnętrzny, użytkowany przez banki interfejs do tworzenia plików XML,(tzw.
„DomyBank”),
2. e-PUAP - aplikacja służąca do przekazywania plików XML z banków do Funduszu,
3. aplikacje w SAP do tworzenia i wysyłania do Urzędu Skarbowego formularza PIT-8C,
4. moduł analityczno/raportowy (w ramach modułu raportowego LSI).
5. PROCES
Wykorzystanie „MODUŁU DOM” w obsłudze procesu polegać będzie na przekazywaniu przez Fundusz dotacji dla zrealizowanych przedsięwzięć proekologicznych. Proces z punktu widzenia Funduszu składa się z następujących grup czynności:
1. Złożenie przez bank wniosku o współpracę z Funduszem. Kolejne etapy to przyznanie limitów,
zawieranie umów z bankami, ich obsługa i ocena (na podstawie przekazanych przez banki wniosków i sprawozdań), stosowne decyzje i w końcu zakończenie umów z Bankami. „MODUŁ DOM” ewidencjonuje Umowy, zmiany w nich oraz sprawozdania składane przez Banki. W
„MODULE DOM” ewidencjonowane są również Banki oraz Umowy z Bankami.
2. Obsługa wiążących banki limitów (wniosków banków o ich zmianę) na zawierane umowy i udzielane dopłaty w poszczególnych okresach. W Module są rejestrowane kolejne obowiązujące wartości limitów.
3. Prowadzenie przez bank akcji kredytowej - beneficjenci składają wnioski o kredyt. Wnioski są kontrolowane i oceniane oraz podejmowane są decyzje o przyznaniu kredytu z dotacją wyłącznie na koszty kwalifikowane.
4. Przetwarzanie wystąpień Banku o wypłatę dotacji na zrealizowane przedsięwzięcia, w tym wyplata dotacji. Bank prowadzi akcje kredytową w oparciu o umowę z Funduszem, nie częściej niż co miesiąc (nie dotyczy wystąpień aktualizacyjnych i korygujących) oraz nie później niż po upływie
2 m-cy od dnia złożenia przez kredytobiorcę w banku potwierdzenia zrealizowania przedsięwzięcia, może przesłać wystąpienie do Funduszu o dotacje, a cztery razy w roku przesyła do Funduszu sprawozdanie. Kolejne etapy przekazania tych dokumentów są następujące:
1) Po stronie banku
a) Przygotowanie i podpisanie dokumentu {wystąpienie lub sprawozdanie) przez Bank.
b) Utworzenie wersji elektronicznej dokumentu (pliki XML) - podmoduł „DomyBank".
c) Przesłanie elektronicznej wersji dokumentu do Funduszu z wykorzystaniem platformy e-PUAP.
2) Po stronie Funduszu
a) Odebranie dokumentu i wczytanie go do „MODUŁU DOM”.
b) Czteroetapowa walidacja dokumentu wystąpienia i dwuetapowa sprawozdania w
„MODULE DOM”:
1. Walidacja przez system, wystąpienie i sprawozdanie
2. Walidacja formalno – merytoryczna, WKR wystąpienie i sprawozdanie
3. Walidacja formalno – rachunkowa (tylko wystąpienie),
4. Walidacja, w tym:
▪ przez Zarząd Funduszu – wystąpienie, korekta po wypłacie obciążająca Fundusz,
▪ przez Dyrektora Xxxxx – korekta po wypłacie nieobciążająca Funduszu,
c) Przygotowanie, wyplata i rejestracja dotacji przekazywanej do banku na podstawie
decyzji Zarządu dla wystąpienia.
5. Przetwarzanie wyników kontroli trwałości przedsięwzięć realizowanych przez Fundusz, w tym obsługa zwrotów udzielonych dotacji w przypadkach negatywnego wyniku kontroli. W Funduszu na podstawie raportu podejmowana jest decyzja o ewentualnym zwrocie dotacji oraz o należnych
odsetkach. W „MODULE DOM” rejestrowany jest wynik kontroli. W systemie zapisywana jest informacja zbiorcza (liczba przeprowadzonych kontroli trwałości), a dla przypadku zwrotów kwota odsetek i wpłaty zwrotu do banku dla umów, dla których została podjęta decyzja o zwrocie dotacji.
6. Wystawianie formularza PIT-8C dla beneficjentów - osób fizycznych, w związku z udzielonymi przez Fundusz dotacjami. „MODUŁ DOM” odpowiada za przygotowanie danych do formularza lub do jego korekty. Następnie formularz jest:
a) Drukowany przez SAP,
b) Papierowa wersja formularza wysyłana jest do beneficjenta - Departament DKU w Funduszu,
c) Elektroniczna wersja jest wysyłana na stronę www Ministerstwa Finansów – aplikacja do
wysyłki PIT-8C.
d) Elektroniczna kopia dokumentu jest archiwizowana - aplikacja do wysyłki PIT-8C.
7. Raportowanie wyników – podmoduł raportowy (szczegółowo opisany w części 7 - raporty).
8. Ewaluacja programu – beneficjenci w trakcie kontroli są proszeni o wypełnienie arkusza ewaluacyjnego zał. Nr 8 do Umowy o współpracy z bankami). W module przewidziane jest wprowadzenie danych z tych arkuszy, tworzenie zestawienia (na monitorze) i raportu za określony czas.
6. CZĘŚCI MODUŁU
Moduł składa się z następujących rejestrów:
1. Rejestr banków,
2. Rejestr beneficjentów,
3. Rejestr Umów kredytowych,
4. Rejestr wystąpień banku o środki,
5. Rejestr okresowych sprawozdań banków,
6. Rejestr arkuszy ewaluacyjnych,
7. Rejestr PIT,
8. Rejestr – Problem z PIT
9. Rejestr uchwał, także akceptacje Dyrektora Biura.
Menu główne modułu składa się z następujących pozycji:
1. Banki,
2. Beneficjenci,
3. Raportowanie,
4. Administracja,
5. Pomoc.
1. Każda funkcja systemu (przeglądanie, edycja, przetwarzanie) wymaga nadania uprawnień:
a) tworzenie nowych zapisów
b) modyfikacja „swoich” zapisów
c) kasowanie „swoich” zapisów
d) modyfikacja „obcych” zapisów
e) kasowanie „obcych” zapisów
f) drukowanie „swoich” i/lub „obcych” danych
2. Czynności nieodwracalne (zatwierdzanie umów, odrzucanie dokumentów bankowych) wymagają
dodatkowego, świadomego potwierdzenia przez tego samego użytkownika.
3. Pola o ograniczonej liczbie możliwych wartości lub określonego formatu powinny być walidowane według zawartości słowników.
4. Walidacja poprawności nie powinna uwzględniać wielkości liter oraz nadmiarowych spacji (spacje
„z przodu” i „z tyłu” tekstu powinny być usunięte a spacje „w środku” zredukowane do jednego znaku spacji (zamiast spójnego ciągu spacji).
5. W trakcie zapisywania przesyłanych danych do bazy systemu „MODUŁ DOM”, powinny być
usuwane nadmiarowe (podwójne, na początku i na końcu pola) spacje.
6. System zawiera rozwiązania ergonomiczne - w przypadku operacji czasochłonnych (weryfikacja umów) mała liczba przycisków konieczna jest dla osiągnięcia celu; klawisz Enter w polu wyboru inicjuje wyszukiwanie itp. Szczegółowe propozycje powinny być przedstawione w projekcie technicznym.
7. System powinien zostać wyposażony w przejrzystą pomoc on-line dla użytkownika.
System będzie umożliwiał przeglądanie następujących zarejestrowanych danych:
1. Banki,
2. Beneficjenci,
3. Umowy o współpracy z Bankami,
4. Wystąpienia Banków o środki,
5. PIT,
6. Umowy,
7. Sprawozdania Banków,
8. Kontrole przeprowadzone przez banki,
9. Kontrole trwałości przeprowadzone przez NFOŚiGW,
10. Ewaluacja programu.
Każdy z widoków będzie wyświetlał podstawowe dane o pozycji (np. banki – Tel. fax. E-mail, adres, Nr KRS, NIP, REGON), w określonym porządku i filtrowaniu (np. na liście sprawozdań banków będą wyświetlane tylko sprawozdania o statusie „poprawne" oraz „weryfikacja systemu - poprawne"), szczegóły
do określenia w projekcie technicznym. W każdym z widoków, poprzez zadanie określonych warunków, będzie możliwość zdjęcia wstępnego filtrowania lub określenia innego filtrowania wyświetlanych pozycji. Dla każdej pozycji będzie istniała możliwość wyświetlenia ekranu zawierającego pełne dane tej pozycji oraz przejście do innego widoku zawierającego powiązane z nią elementy (np. wszystkie wystąpienia banku dla wybranej umowy o współpracy, albo wszystkie umowy kredytowe dla danego wystąpienia itp.). Dla każdej z pozycji będzie można przejść do edycji (przetwarzania) wyświetlanej pozycji. Powinna istnieć możliwość wydrukowania wyświetlanych ekranów lub skopiowania do schowka w formacie tabelarycznym.
Sposób logowania się do systemu jest taki sam jak do systemu LSI. Szczegóły powinny być ujęte w projekcie technicznym. System sam rozpoznaje uprawnienia użytkownika. Przed przejściem do menu głównego system wyświetla na ekranie wstępnym (a później w górnym pasku ekranu):
1. Nazwisko i imię osoby, która wchodzi do systemu
2. Rolę przypisaną tej osobie
Pole rekordów banków:
1. Nazwa skrócona, Pola rekordu banków:
1. Numer systemowy banku,
2. Nazwa banku,
3. Adres siedziby (ulica, nr domu, nr lokalu, miejscowość, kod pocztowy, poczta, województwo,
powiat, gmina),
4. Numer KRS,
5. NIP,
6. REGON,
7. Dane kontaktowe (telefon, faks. e-mail),
8. Xxxxx /osoby zatwierdzająca (imię i nazwisko, stanowisko, nr telefonu, nr faksu, e-mail).
W bazie danych należy umieścić rekordy dla wszystkich tych banków, które mają aktualną umowę z Funduszem oraz utworzyć możliwość dodawania kolejnych banków. Powinna istnieć możliwość zarządzania rejestrem banków przez użytkownika, np.:
1. Stworzenie nowego banku i umowy o współpracy,
2. Zaznaczanie zamknięcia umowy,
3. Konsolidacja banków (przeniesienie następstw prawnych),
Funkcjonalność:
Przeglądanie informacji, wybór z listy banku, a następnie:
a) Wyświetlanie kompleksowej informacji na temat banku:
- Stan umowy z bankiem (czynna, zamknięta),
- Wartości limitów środków do wypłaty w danym roku, w tym z tytułu umów z lat poprzednich i
stopień ich wykorzystania,
- Daty ostatnich sprawozdań i wniosków banków o zmianę limitów, historia wszystkich zmian
powinna być pamiętana i wyświetlana na oddzielnym ekranie,
- Dane na temat zmian w wartościach limitów, powinna być pamiętana i możliwa do wyświetlenia historia zmian danych oraz kto dokonywał zmian.
- Możliwość wyświetlenia wybranych sprawozdań lub wystąpień,
b) Edycja danych banku: Możliwa jest zmiana wartości każdego z pól,
c) Obsługa umów kredytowych.
d) Obsługa wystąpień banku o środki.
e) Obsługa sprawozdań banków.
f) Obsługa umów o współpracy z bankiem, w tym:
- Wprowadzenie nowej umowy o współpracy,
- Przeglądanie i zmiany we wprowadzonych umowach o współpracy,
Na ekranie statystyk banków należy przez odpowiednie wartości rozumieć:
a. Łączna liczba umów - liczba umów w ostatniej wersji poprawnych wystąpień bez uwzględnienia wystąpień rodzaju „Korekta po wypłacie"
b. Liczba umów poprawnych - liczba (a) - (c)
c. Liczba umów pozostałych - umowy z (a) opisane w pkt od (d) do (j) [(c) = suma od (d) do (j)],
Dodatkowo potrzebne są również wielkości
d. Liczba umów niepoprawnych - status niepoprawne (formalnie lub nie)
e. Liczba korekt niefinansowych - status skorygowane, ale tylko dla umów bez korekt finansowych lub
obejmujących też korekty finansowe o saldzie zero (niezależnie od roku korekty)
f. Liczba korekt na plus - status skorygowane, korekty finansowe na plus (niezależnie od roku - znak
określa się saldem wszystkich korekt finansowych danej umowy)
g. Liczba korekt na minus - status skorygowane, korekty finansowe na minus (niezależnie od roku -
znak określa się saldem wszystkich korekt finansowych danej umowy)
h. Liczba umów do zwrotu - status do zwrotu
i. Liczba umów zwróconych - status zwrócone (bez względu na status zwrotu)
j. Liczba umów z problemem - liczba wszystkich umów, do których istnieje „problem z PIT-em" o
statusie „zgłoszono problem w DKU" lub „wyjaśniany z bankiem"
k. Liczba umów wypłaconych - umowy z (a) o statusie „wypłacone”, „do zwrotu”, „skorygowane” lub
„zwrócone”, ale tylko w innym roku niż rok wypłaty (umów zwróconych w roku wypłaty nie
uwzględnia się).
Pozostałe istniejące statystyki:
a) Powierzchnia, opłaty, oprocentowanie - dane z uwzględnieniem korekt
b) Kwota dotacji i koszt przedsięwzięcia - dane oryginalne, uzupełnione o korekty na plus wypłacone w
raportowanym roku.
c) Jednostkowy koszt przedsięwzięcia:
- średni - (łączny koszt przedsięwzięcia)/(łączne metry kwadratowe)
- maksymalny i minimalny - (koszt przedsięwzięcia)/(metry kwadratowe) dla najdroższej i najtańszej (w przeliczeniu na metry) umowy; przy czym koszt przedsięwzięcia oryginalny, skorygowany co najwyżej przez korekty na plus, a metry kwadratowe z uwzględnieniem korekt.
6.3.1. REJESTR UMÓW O WSPÓŁPRACY Z BANKAMI
Pola rekordu „Umowa z Bankiem":
1. Numer systemowy umowy z Bankiem,
2. Numer systemowy Banku,
3. Numer umowy (określony poza systemem),
4. Data zawarcia umowy z Bankiem,
5. Numer aneksu (jeżeli zmiana w umowie związana jest z aneksem),
6. Data aneksu (jeżeli zmiana w umowie związana jest z aneksem),
7. Okres obowiązywania umowy (daty od - do),
8. Adres Banku do korespondencji (ulica, nr domu. nr lokalu, miejscowość, kod pocztowy, poczta). Numer rachunku Banku dla wypłat dotacji,
9. Osoba/osoby zatwierdzająca – uprawniony reprezentant banku składający podpis pod przesyłanymi
dokumentami,
10. Program priorytetowy,
11. Status umowy z Bankiem,
12. Uwagi,
13. Liczba dni, którą ma Fundusz na przelanie środków po złożeniu poprawnego wystąpienia przez bank,
14. Data i godzina wprowadzenia do systemu,
15. Identyfikator pracownika dokonującego zmiany.
W tablicy „zmiana statusów" pamiętane są zmiany statusów rekordów danych. Tablica ma następujące pola:
1. Rodzaj rekordu (umowa z bankiem, beneficjent, umowa kredytowa, wystąpienie, sprawozdanie),
2. Numer systemowy zmienianego rekordu,
3. Poprzedni status,
4. Nowy status,
5. Data wprowadzenia nowego statusu,
6. Kto wprowadził nowy status.
Pola rekordu „limity":
1. Numer systemowy banku,
2. Numer systemowy umowy,
3. Pierwszy rok okresu sprawozdawczego (np, 2013),
4. Data, od której obowiązują limity zawarte w rekordzie,
5. Numer decyzji o zmianie limitu,
6. Data decyzji o zmianie limitu,
7. Limit środków do wypłaty w pierwszym roku okresu dla umów zawartych w pierwszym roku okresu,
8. Limit środków do wypłaty w drugim roku okresu dla umów zawartych w pierwszym roku okresu,
9. Limit środków do wypłaty w drugim roku okresu dla umów zawartych w drugim roku okresu,
10. Limit środków do wypłaty w trzecim roku okresu dla umów zawartych w pierwszym roku okresu,
11. Limit środków do wypłaty w trzecim roku okresu dla umów zawartych w drugim roku okresu,
12. Limit środków do wypłaty w trzecim roku okresu dla umów zawartych w trzecim roku okresu,
13. Limit środków do wypłaty w czwartym roku okresu dla umów zawartych w pierwszym roku okresu,
14. Limit środków do wypłaty w czwartym roku okresu dla umów zawartych w drugim roku okresu,
15. Limit środków do wypłaty w czwartym roku okresu dla umów zawartych w trzecim roku okresu,
16. Limit środków do wypłaty w piątym roku okresu dla umów zawartych w drugim roku okresu,
17. Limit środków do wypłaty w piątym roku okresu dla umów zawartych w trzecim roku okresu,
18. Limit środków do wypłaty w szóstym i siódmym roku okresu dla umów zawartych w trzecim roku
okresu,
19. Data i godzina wprowadzenia nowego limitu do systemu,
20. Identyfikator pracownika dokonującego zmiany.
W bazie danych należy umieścić po dwa rekordy limitów dla wszystkich tych banków, które mają aktualną umowę z Funduszem oraz umożliwić tworzenie dodatkowych rekordów dla nowych banków. Jeden z rekordów powinien dotyczyć roku 2013, a drugi roku 2016. Każdy z limitów powinien być równy 999.999.999 zł, z datą obowiązywania od 22.03.2013 r.
Funkcjonalność (po wybraniu banku z listy banków):
1. Wprowadzenie nowej umowy o współpracy z bankiem. Aby system zapamiętał umowę (ze statusem
„nowa") konieczne jest wypełnienie wszystkich pól obowiązkowych.
2. Przeglądanie informacji o umowach z bankami, a po wybraniu umowy z listy umów można:
a) Edytować wybraną umowę o współpracę (dotyczy umów o statusie ,nowa" lub „realizowana").
Możliwa jest zmiana wartości każdego z pól, w tym limitów na umowy i wypłaty na wybrany okres.
b) Edytować pole „konto bankowe", na które Fundusz przelewa dotacje w odpowiedzi na wystąpienie banku (odrębnych uprawnień wymaga wprowadzenie konta bankowego oraz zmiana wartości konta); nie jest możliwe zapamiętanie wartości pola „Konto bankowe” o ile nie są wypełnione informacje adresowe, które są niezbędne do wystawienia przelewu,
c) Zatwierdzać umowę o statusie „nowa” – umowa po zatwierdzeniu ma status „realizowana”,
d) Zmienić wartość obowiązujących limitów,
e) Zamknąć umowę z bankiem.
Uwagi:
1. Umowa o współpracy z bankiem może mieć następujące statusy:
a) „Nowa” – status otrzymywany po wprowadzeniu umowy; edycja danych „nowej” umowy nie powoduje zmiany jej statusu,
b) „Realizowana” – otrzymywana po poprawnym wprowadzeniu wszystkich danych i zatwierdzeniu umowy o statusie „nowa” lub dla utworzonej kolejnej wersji umowy po zmianie danych w umowie o statusie „realizowana”; tylko jedna umowa o współpracy z danym bankiem może mieć status
„realizowana”,
c) „Nieaktualna” – otrzymywana po zmianie danych umowy o statusie „realizowana”,
d) „Zamknięta” – po upływie terminu jej obowiązywania.
2. Podczas przeglądania umów wyświetlane są podstawowe statystyki dotyczące realizacji umowy:
a) Limity i stopień ich wykorzystania (korzystając z tablicy limity oraz z rzeczywistego wykorzystania –
zrealizowane wypłaty),
b) Procent kontrolowanych przedsięwzięć przez banki, oczekiwane jest minimum 25%, liczone w skali roku kalendarzowego dla składanych wystąpień (korzystając z tablicy umowy kredytowe – nie są brane pod uwagę umowy o statusie „niepoprawna”, „nieaktualna” lub „usunięta”,
c) Procent przedsięwzięć w skali roku oraz całego okresu (w tym negatywne), których trwałość została
skontrolowana (korzystając z tablicy „kontrola trwałości”),
d) Podstawowe statystyki wystąpień obejmujące dane (w statystykach uwzględnia się skorygowane dane zawarte w wystąpieniach rodzaju „Korekta po wypłacie” – statystyka za dany okres może być różna w zależności od momentu jej sporządzenia);
• Liczby umów poprawnych,
• Liczba błędów według rodzajów,
• Liczba umów niepoprawnych,
• Procent skontrolowanych umów,
• Koszt przedsięwzięć (łączny, średni, max i min),
• Kwota dotacji (łączna, dom: NF40 i NF 15, średnia, mieszkanie: NF40 i NF15, średnia),
• Oprocentowanie kredytów (średnia, max i min),
• Opłaty (średnia, max i min).
3. O ile użytkownik nie wprowadzi innego filtrowania to wyświetlane są tylko umowy o statusie „nowa” i
„realizowana”.
4. Z jednym rekordem umowy może być związanych wiele rekordów z limitami. Wiążące są dane wpisane na podstawie najpóźniejszej decyzji dotyczącej zmiany limitu, o ile zdarzenie nastąpiło po „dacie od której obowiązują limity”.
5. Limity związane z umową to „limit środków do wypłaty w danym roku oraz limit środków do wypłaty z tytułu umów zawartych w roku poprzednim”. Limity dotyczą każdego z lat w okresie 2013-2018. W przypadku roku 2013 (oraz roku 2016 w perspektywie 2016-18) limit dla umów z poprzedniego roku równy jest zero, a w przypadku roku 2019 (oraz roku 2016 dla perspektywy 2013-15) limit środków do wypłaty i limit dla umów z poprzedniego roku to ta sama liczba. Wprowadzenie lub zmiana limitu musi obejmować też wprowadzenie do systemu „daty decyzji o limicie” oraz numeru decyzji o limicie. System wylicza łączny limit wypłat na lata 2013-2019 (umowy kredytowe podpisane w latach 2013-2015) Lub na lata 2016-2022 (umowy podpisane w latach 2016-2018). Nie jest możliwe wprowadzenie limitów, które są niższe od sumy wypłaconych już środków i wnioskowanych (nowe wystąpienia przekazane do Funduszu, dla których nie zostały wypłacone środki).
6. Logowane jest „zatwierdzanie umowy” oraz wszystkie zmiany w umowie o współpracę o statusie
„realizowana”, w tym zmiany limitu.
6.3.2. ZAMYKANIE UMOWY O WSPÓŁPRACY Z BANKIEM
„Uwagi”). Obsługa wystąpień, w tym wypłata dotacji jest możliwa tylko, gdy umowa o współpracy z bankiem ma status „realizowana”, a wystąpienie dotyczy okresu ważności tej umowy.
6.3.3. REJESTR INFORMACJI O PRZEPROWADZONEJ KONTROLI TRWAŁOŚCI
Fundusz przeprowadza kontrole trwałości i sporządza z nich raporty. Rejestr dokumentuje liczbę przeprowadzonych kontroli trwałości, jak również liczbę tych przedsięwzięć, które zostały zweryfikowane negatywnie. Kontrola trwałości może być przeprowadzona nie później niż w 36 miesiącu od daty zakończenia realizacji przedsięwzięcia.
Pola rekordu „zbiorcze sprawozdania":
1. Numer systemowy banku,
2. Numer umowy, której dotyczy przedsięwzięcie,
3. Data wystąpienia, w którym zatwierdzono środki do wypłaty,
4. Źródło informacji o kontrolowanym przedsięwzięciu, (Informacja po kontroli przeprowadzonej przez Fundusz, Inne źródło),
5. Data przeprowadzenia kontroli trwałości,
6. Informacja o wyniku kontroli, wybór z listy:
a) Pozytywny,
b) Negatywny – zwrot dotacji z winy beneficjenta,
c) Negatywny – zwrot dotacji z winy banku,
d) Negatywny – odstąpienie od zwrotu dotacji
7. Uwagi,
8. Data wpisu do systemu,
9. Identyfikator pracownika, który wpisał informacje o kontroli,
10. Liczba skontrolowanych przedsięwzięć,
11. Liczba przedsięwzięć skontrolowanych negatywnie.
Po wybraniu z listy stosownej umowy (o statusie „wypłacona”, dla beneficjenta o statusie „poprawny”),
pracownik WRK ma możliwość realizacji następujących funkcji:
1. Rejestracja informacji o wyniku kontroli trwałości przedsięwzięcia,
2. Usuniecie informacji o wyniku kontroli trwałości przedsięwzięcia.
Ad. 1. W przypadku zarejestrowania wyniku kontroli „negatywna – zwrot dotacji” bez względu na winę, status odpowiedniej umowy kredytu zostanie automatycznie zmieniony na „do zwrotu”. Negatywna kontrola trwałości, z „odstąpieniem od zwrotu dotacji” nie zmienia statusu umowy (pozostaje status „Wypłacona”). System rejestruje kto i kiedy zarejestrował dane o wynikach kontroli.
W przypadku decyzji o zwrocie dotacji pracownik DKU rejestruje dane o oczekiwanej kwocie należnych odsetek od zwracanej dotacji. System wylicza kwotę odsetek (dotacja jest traktowana jak zaległość podatkowa). System zapisuje kto i kiedy rejestrował oczekiwaną kwotę odsetek (np. w tablicy zmiana statusów). Możliwe jest korygowanie danych o trwałości przedsięwzięcia. W systemie pamiętane są tylko ostatnio wprowadzone wartości, a w tablicy „zmiana statusów” informacja o modyfikacji danych o trwałości przedsięwzięcia dla danej umowy.
Ad 2. Upoważniony użytkownik może usunąć informację o wynikach kontroli. Wówczas rekordy z tablic
„trwałość przedsięwzięcia" oraz „zwroty dotacji" są odłączane od danej umowy kredytowej, jednak nie kasowane. Konieczne jest potwierdzenie świadomości konsekwencji wykonywanej akcji.
Funkcjonalność:
1. Przeglądanie listy dotychczas skontrolowanych przedsięwzięć, w tym:
a) Listy umów skontrolowanych z możliwością filtrowania umów z negatywnym wynikiem
kontroli,
b) Lista umów, dla których okres trwałości (36 miesięcy) mija w danym roku (filtrowanie),
2. Po wyborze konkretnej umowy wyświetlenie kompletu informacji o kontrolowanym przedsięwzięciu.
Pola rekordu „zbiorcze sprawozdania":
1. Numer systemowy beneficjenta,
2. Nazwisko Beneficjenta,
3. Imię Beneficjenta,
4. Obywatelstwo,
5. Adres zamieszkania:
a) województwo,
b) powiat,
c) gmina,
d) ulica,
e) nr domu,
f) nr lokalu,
g) miejscowość,
h) kod pocztowy,
i) poczta,
6. Data urodzenia,
7. PESEL - pełna kontrola,
8. NIP - pełna kontrola,
9. Dane urzędu skarbowego (nazwa i adres),
10. Status umowy z beneficjentem – możliwa zmiana statusu:
a) dla umów „wypłaconych” na „do zwrotu”,
b) dla umów „niepoprawna” na nieaktualna”.
11. Szczegóły korygowanej umowy – dotyczy tylko „korekty po wypłacie”. Szczegóły korekt dotyczące korekt umów zawartych w „Korektach po wypłacie" powinny obejmować zmiany wszystkich pól umowy.
Zmiana statusu beneficjenta pamiętana jest w tablicy „zmiana statusów".
Identyfikacja (oprócz unikalnego pola - numer systemowy beneficjenta):
1. PESEL,
2. NIP,
Funkcjonalność:
Przeglądanie informacji o beneficjencie, a następnie:
a) Edycja (korekta) danych osobowych beneficjenta któremu dotacja została wypłacona lub ma
status „Poprawne do wypłaty”,
b) Zgłoszenie problemu z PIT-em beneficjenta,
c) Raportowanie zgłoszonych problemów z PIT-ami, możliwość wydruku problemów wg statusu,
banku.
Uwagi:
1. Beneficjent jest osobą fizyczną i może wziąć udział w programie tyko jeden raz.
2. Wprowadzenie nowego lub korekta danych wprowadzonego do systemu beneficjenta następuje w
wyniku wczytania wystąpienia banku o środki (por.6.7.1.).
3. Beneficjent może mieć następujące statusy:
a) „Poprawny" - nadawany w przypadku wprowadzania wystąpienia z banku bez względu na status tego wystąpienia oraz status umowy, o ile tylko rekord beneficjenta przejdzie przez weryfikację techniczną (np. poprawny format PESEL, NIP); umowa, w której beneficjent nie przejdzie tej weryfikacji jest odrzucana.
b) „Nieaktualny" - nadawany istniejącemu w systemie rekordowi w przypadku wczytania nowych danych (identyfikacja po PESEL, NIP); nowo wczytany rekord ma status „poprawny". Wyjątkiem jest sytuacja opisana w rozdz.6.7.1.
4. Dla beneficjentów o statusie „poprawny" pola PESEL jest unikalne.
5. Dla beneficjentów o statusie „poprawny" pole NIP jest unikalne pod warunkiem, że jest niepuste.
6.4.1. PRZEGLĄDANIE INFORMACJI O BENEFICJENCIE
Funkcjonalność:
1. Listowanie beneficjentów,
a) Nazwisko i imię beneficjenta,
b) PESEL,
c) NIP,
d) Adres,
e) Status
f) Adres korespondencyjny.
Dane są wstępnie posortowane alfabetycznie według nazwiska i imienia, możliwe sortowanie według pozostałych cech. O ile użytkownik nie wybierze innego filtrowania wyświetlani są tylko beneficjenci o statusie „poprawny".
Po wybraniu przez użytkownika beneficjenta wyświetlana jest pełna informacja na jego temat. Z danym
beneficjentem w „MODULE DOM” może być związana tylko jedna umowa kredytowa. W określonych
6.4.2. KOREKTA DANYCH BENEFICJENTA
W przypadku konieczności poprawy danych beneficjenta po przekazaniu wystąpienia do decyzji Zarządu, system nie daje możliwości przysłania przez bank zwykłej aktualizacji wystąpienia zawierającego skorygowane dane umowy. Jedyną możliwością poprawienia niezauważonych wcześniej błędów jest wczytanie wystąpienia korygującego (rodzaj ,Korekta po wypłacie").
Po wybraniu przez użytkownika beneficjenta, który jest osobą fizyczną i któremu dotacja została już wypłacona lub wypłata dotacji została zatwierdzona przez Zarząd możliwa jest edycja tych jego danych, które są na formularzu PIT-8C.
System zapewnia spójność wpisywanych danych, w szczególności data urodzenia beneficjenta jest wyprowadzana na podstawie wartości pola PESEL, W przypadku, gdy dla tego beneficjanta PIT (lub PIT-y) został już wystawiony, edycja danych beneficjenta powoduje, że korekta PIT-u (PIT-ów) jest automatycznie wystawiana i przesyłana do systemu SAP do wydrukowania. System daje możliwość zmiany danych beneficjenta po wystawieniu dokumentu PIT z modułu połączonej z powtórnym wystawieniem dokumentu PIT z tym samym numerem kancelaryjnym, a nie PTT-u korygującego. Ta funkcjonalność, dostępna dla uprawnionych użytkowników, jest konieczna na wypadek, gdy błąd w danych beneficjenta został dostrzeżony już po przesłaniu danych do systemu SAP, ale jeszcze przed wysłaniem dokumentu PIT do Urzędu Skarbowego lub do beneficjenta. W sytuacji, gdy poprzednia wersja dokumentu PIT nie została wysłana poprawiony dokument PIT nie jest formalną korektą. W przypadku, gdy edycja danych łączy się z wystawieniem korekty PIT-8C konieczne jest też wypełnienie dodatkowego pola „uzasadnienie". Pole to ma 132 znaki. Zawartość tego pola jest następnie przesyłana wraz z danymi o PIT-8C do systemu SAP, System daje możliwość skorygowania i wysłania do wydrukowania w SAP wszystkich dotychczas wystawionych PIT-ów beneficjenta. Użytkownik ma możliwość wyboru z listy tych dokumenty, które mają zostać skorygowane. Np. gdy beneficjent zmienił adres w roku 2016, to nie ma powodu korygowania PIT-u wystawionego w roku 2014. W trakcie wyboru dokumentów do drukowania użytkownik ma możliwość dopasowania uzasadnienia do każdego dokumentu korekty. Wybór użytkownika należy opisać (np. „Liczba PIT-ów korygujących: 2") i dać użytkownikowi do zatwierdzenia. Możliwe jest niewybranie żadnego dokumentu. Brak zatwierdzenia wysyłki (choćby pustej) jest równoznaczny z rezygnacją ze zmiany danych beneficjenta. Dodatkową funkcją systemu jest powtórne wysłanie dokumentu PIT do SAP-a bez poprawiania danych. Jednak wówczas również wysyłany jest dokument PIT korekta i również konieczne jest podanie uzasadnienie korekty.
Pola rekordu „Umowa kredytowa":
1. Numer systemowy umowy kredytowej,
2. Identyfikator systemowy umowy korygującej umowę,
3. Czy należy wystawić PIT korygujący,
4. Numer systemowy banku,
5. Miesiąc wystąpienia,
6. Rok wystąpienia,
7. Numer wystąpienia, w którym umowa została wprowadzona do systemu (numer ostatniej aktualizacji),
8. Imię
9. Nazwisko
10. Data urodzenia,
11. PESEL Beneficjenta,
12. NIP Beneficjenta,
13. Adres zamieszkania:
a) Ulica,
b) Nr domu,
c) Nr lokalu,
d) Miejscowość,
e) Kod pocztowy,
14. Identyfikator Urzędu Skarbowego,
15. Nazwa Urzędu Skarbowego,
16. Adres realizacji przedsięwzięcia:
a) Ulica,
b) Nr domu,
c) Nr lokalu,
d) Miejscowość,
e) Kod pocztowy,
17. Numer umowy kredytu,
18. Data zawarcia umowy z beneficjentem,
19. Okres kredytowania,
20. Oprocentowanie kredytu (WIBOR, marża Banku, łączne opłaty),
21. Nazwa dewelopera (jeśli dotyczy),
22. Powierzchnia całkowita budynku/mieszkania,
23. Powierzchnia ogrzewana budynku/mieszkania,
24. Nazwisko i imię weryfikatora budynku,
25. Numer weryfikatora budynku,
26. Wskaźnik zapotrzebowania na energię,
27. Wskaźnik energii pierwotnej,
28. Rodzaj zastępowanego nośnika energii,
29. Data osiągnięcia efektu przedsięwzięcia (rzeczowego),
30. Data kontroli przedsięwzięcia przez Bank (o ile została przeprowadzona),
31. Kwalifikowany koszt przedsięwzięcia,
32. Wykorzystana kwota kredytu na koszty kwalifikowane,
33. Kwota dotacji,
34. Data dokonania wypłaty,
35. Uzasadnienie odrzucenia umowy przez Fundusz,
Pola rekordu „trwałość przedsięwzięcia":
1. Numer systemowy umowy kredytowej
2. Numer systemowy wystąpienia zatwierdzającego wypłatę środków,
3. Data przeprowadzenia kontroli trwałości przedsięwzięcia,
4. Wynik (pozytywna, negatywna - zwrot dotacji z winy Beneficjenta, negatywna - zwrot dotacji z winy Banku, negatywna - odstąpienie od zwrotu),
5. Uwagi,
6. Data wpisania wyników kontroli,
7. Kto wpisał wyniki kontroli,
8. Kwota oczekiwanych odsetek od zwracanej dotacji,
9. Data ostatniego naliczenia odsetek,
10. Kto naliczył odsetki.
Pola rekordu „zwroty dotacji"
1. Numer systemowy umowy kredytowej,
2. Data wpłaty,
3. Kwota,
4. Rodzaj należności (kapitał, odsetki),
5. Data wprowadzenia wpłaty,
6. Kto wprowadził wpłatę.
Zmiana statusu umowy pamiętana jest w tablicy „zmiana statusów”. Identyfikacja umowy - numer systemowy umowy kredytowej oraz:
1. Numer systemowy banku,
2. Miesiąc wystąpienia,
3. Rok wystąpienia,
4. Numer umowy kredytowej,
5. Numer wystąpienia, w którym umowa została wprowadzona do systemu (numer ostatniej
aktualizacji).
Funkcjonalność jest dostępna z głównego ekranu rejestru banków (po wybraniu banku z listy banków):
1. Przeglądanie informacji o umowach, a następnie:
a) Przeglądanie szczegółów dotyczących umowy,
b) Rejestracja informacji o wyniku kontroli trwałości przedsięwzięcia,
c) Rejestracja wpłat związanych ze zwrotem dotacji,
2. Wystawienie PIT-8C (dla osoby fizycznej w wybranej umowie). Uwagi:
1. Wprowadzenie nowej umowy lub korekta umowy wczytanej następuje wyłącznie w wyniku wczytania wystąpienia banku o środki (por. 6.7.1). W szczególnym przypadku możliwa jest korekta danych beneficjenta (por. 6.4.2).
2. Umowa może mieć następujący status:
a) „weryfikacja systemu - poprawna" - umowa po weryfikacji przez system,
b) „weryfikacja formalno-merytoryczna - poprawna" - umowa po weryfikacji przez pracownika WRK,
c) "weryfikacja formalno-rachunkowa poprawna" umowa po zakończonej pozytywnie
weryfikacji przez pracowników DKU,
d) „w trakcie akceptacji” – umowa w trakcie procesu decyzyjnego,
e) „poprawna do wypłaty" - umowa po zaakceptowaniu przez Zarząd Funduszu / DB,
f) „wypłacona" - po dokonaniu wypłaty,
g) „skorygowana” – umowa, która została skorygowana przez inną umowę w wystąpieniu
„Korekta po wypłacie”,
h) „do zwrotu" - dla umowy o statusie „wypłacona", w wyniku negatywnej kontroli trwałości przedsięwzięcia i decyzji o zwrocie dotacji,
i) „zwrócona" - dla umowy o statusie „do zwrotu", po rejestracji zwrotu wypłaconej dotacji,
j) „niepoprawna" - umowa po automatycznej lub ręcznej weryfikacji zakończonej negatywnie, zmiana statusu powinna być możliwa,
k) „nieaktualna" - nadawany jest, gdy wpisywana jest aktualizacja wystąpienia (por. 6.7.1), oraz umowa z aktualizacji ma zmiany w stosunku do tej z oryginalnego (poprzedniego, poprzednich) wystąpienia,
l) „usunięta" - dla umów, które były w oryginalnym wystąpieniu, ale nie pojawiły się w
aktualizacji.
3. Umowa, która jest związana z beneficjentem o statusie innym niż „poprawny" może zmienić
swój status tylko na „niepoprawna". Zmiana statusu z „niepoprawna” na „nieaktualna” może być
dokonana przez użytkownika w trzech miejscach - po wyborze umowy w wystąpieniu, w rejestrze
beneficjentów lub w rejestrze umów kredytowych.
4. Umowy skorygowane uwzględniane są bez zmian w zestawieniach zbiorczych za korygowany okres, ale dla korygowanej umowy (na ekranie możliwy podgląd pełnej informacji) dostępna jest pełna informacja uwzględniająca również dane zawarte w umowach korygujących.
Funkcjonalność:
1. Listowanie umów wprowadzonych do systemu,
2. Wyświetlenie szczegółowych informacji o wybranej umowie.
Na liście wyświetlane są następujące informacje o umowach:
1. Nazwa banku,
2. Miesiąc i rok wystąpienia, w którym umowie została przesłana do Funduszu,
3. Status umowy,
4. Numer umowy,
5. Dane beneficjenta - imię i nazwisko oraz jego status.
Dane na liście umów są posortowane według odwrotnej kolejności wczytywania umów do bazy. O ile użytkownik nie wprowadzi innego filtrowania to wyświetlane są tylko umowy o poprawnym statusie (bez niepoprawnych i usuniętych).
Po wybraniu przez użytkownika umowy wyświetlana jest pełna informacja na jej temat. Po wybraniu umowy można wprowadzić informację o wynikach kontroli, lub wprowadzić zwrot(y) dotacji. Pełna informacja na temat umowy zawiera między innymi dane na temat wystawionych dla danej umowy dokumentów PIT-8C. Na liście wyświetlany jest rodzaj przychodu. Po wyborze stosownego rekordu wyświetlana jest pełna informacja, która została przesłana do SAP w celu wystawienia dokumentu PIT-8C. Nie ma potrzeby drukowania dokumentów PIT z poziomu modułu. Dla umów „skorygowanych” system daje możliwość wyświetlenia pełnej informacji o umowie korygującej bieżącą umowę, a dla umów korygujących (są to wyłącznie umowy zawarte w wystąpieniach „Korekta po wypłacie”) informacje o umowie, która została skorygowana.
6.5.2. REJESTRACJA WPŁAT ZWIĄZANYCH ZE ZWROTEM DOTACJI
Po wybraniu stosownej umowy (o statusie „do zwrotu", dla beneficjenta o statusie „poprawny") z listy umów
użytkownik ma możliwość:
1. Obliczenia wysokości odsetek, które są należne w przypadku zwrotu dotacji na podany dzień
zwrotu dotacji.
2. Wpisania wysokości Odsetek, które są oczekiwane w przypadku zwrotu dotacji.
3. Rejestracja zwrotu.
Ad 1. System na podstawie podanej w części Administracja (por. rozdział 8); tabeli oprocentowania oraz
podanej przez użytkownika przewidywanej daty zwrotu oblicza należne odsetki. Na ekranie pozostaje
widoczna poprzednio wpisana/obliczona wartość odsetek.
Ad 2. Użytkownik zapamiętuje obliczoną lub wpisaną ręcznie wartość odsetek. Ad 3. Rejestracji podlegają następujące dane o zwrocie:
1. Data wpłaty,
2. Kwota,
3. Rodzaj należności:
a) Kapitał,
b) Odsetki.
Gdy spłacona kwota należności równa jest oczekiwanej (kapitał = dotacji, a odsetki = oczekiwanej kwocie odsetek) system zaproponuje zmianę statusu umowy kredytowej na „zwrócona”. Nie jest możliwa zmiana statusu umowy na „zwrócona” zanim nie zostanie zarejestrowana kwota należnych odsetek. System rejestruje kto i kiedy wprowadził kolejne wpłaty oraz kto podjął decyzję o zmianie statusu umowy kredytowej na „zwrócona”. Po zmianie statusu umowy kredytowej na „zwrócona” nie ma już możliwości wprowadzania poprawek (np. podania innej kwoty należnych odsetek).
Oczekiwane czynności pracownika to:
1. Obliczenie oczekiwanych odsetek dla wybranego przez użytkownika dnia (jeżeli wpłacono kapitał, to należy wybrać datę zwrotu kapitału).
2. Rejestracja oczekiwanej kwoty odsetek
3. Po przyjściu zwrotu – rejestracja zwrotu, a następnie powtórne obliczenie (ostateczne) oczekiwanej kwoty należnych odsetek.
4. Po rejestracji wpłaconych co najmniej we właściwej wysokości – zmiana statusu umowy kredytowej na „zwrócona”.
W przypadku zwrotu dotacji z winy beneficjenta, po całkowitym zwrocie dotacji, jeżeli dotyczy to beneficjenta, któremu został już wystawiony PIT-8C w związku z umową, automatycznie wystawiany jest PIT-8C korekta. Użytkownik musi wpisać uzasadnienie wystawienia korekty. Pole może mieć predefiniowaną wartość, np. „Korekta ze względu na cofnięcie dotacji przez NFOŚiGW, Dotacja została całkowicie zwrócona”. Gdy jest to korekta na plus, to dla roku, w którym wypłacono kwotę dopłaty powinien zostać wystawiony zwykły PIT na kwotę dopłaty (owej korekty na plus). Jeśli jest to korekta na minus, to dokument PIT nie jest tworzony. System poprawnie działa, gdy korekta na minus dotyczy zwrotu dokonanego w roku wypłaty. Wówczas system wystawia PIT korygujący, który uwzględnia dokonany zwrot. W trakcie zwrotu całkowitego użytkownik jest zobowiązany opisać, czy zwrot następuje z winy beneficjenta, czy banku.
Każde nowe zdarzenie finansowe dla tego samego beneficjenta (mogą być przypadki korzystania z dwóch programów dofinansowania – kolektory i domy energooszczędne) powinno się łączyć z wystawieniem PIT-u obejmującego łącznie zdarzenia poprzednie i bieżące. W przypadku zdarzeń opisanych powyżej NFOŚiGW w zasadzie powinien na samym początku następnego roku wystawić jeden PIT. W praktyce PIT-y drukowane i wysyłane są wcześniej i wtedy może być konieczne wystawienie korekty ostatniego wysłanego
PIT-u. W przypadku pojawienia się kolejnego zdarzenia finansowego w danym roku dla tego samego beneficjenta - bez względu na rodzaj wystąpienia (Korekta po wypłacie, wystąpienie Podstawowe, Aktualizacja czy Korekta) - tworzony powinien być PIT na kwotę równą nieujemnemu saldu wszystkich dotychczasowych zdarzeń z bieżącego roku (lub na zero):
1. Dla przypadku, gdy poprzednio wystawiony PIT był utworzony w innym okresie miesięcznym niż bieżące wystąpienie, to w zależności od tego, czy PIT został już wydrukowany, system proponuje użytkownikowi utworzenie PIT-u w celu nadpisania niewydrukowanego jeszcze PIT-u lub wystawienie nowego PIT-u korygującego.
2. Dla przypadku, gdy jest kilka zdarzeń w ramach tego samego wystąpienia lub grupy wystąpień weryfikowanych w tym samym okresie i dane beneficjenta są takie same, system wystawia dokument PIT tylko dla ostatniej z weryfikowanych umów. Jeśli już wcześniej w bieżącym roku dla tego beneficjenta został wystawiony PIT, system proponuje nadpisanie poprzednio wystawionego PIT-u. Użytkownik może jednak wystawić PIT korygujący.
3. Dla przypadku, gdy dane beneficjenta różnią się (np. inny adres zamieszkania lub inne dane), to ostatnio podany adres traktuje się jako aktualny. Pojawienie się dwóch lub więcej umów dla tego samego beneficjenta (dotyczy tylko programu dofinansowania domów energooszczędnych) z różnymi danymi w ramach tego samego wystąpienia lub grupy w tym samym okresie weryfikowanych wystąpień jest nowym błędem formalnym, który wymaga przesłania poprawnych danych przez bank (lub banki).
W przypadku, gdy pierwszym ruchem w danym roku jest zwrot, to PIT nie jest wystawiany aż do momentu, gdy saldo ruchów beneficjenta w danym roku będzie dodatnie. Wówczas wystawiany jest PIT na dodatnią kwotę tego salda.
W przypadku, gdy PIT nadpisywany jest już korektą, PIT nadpisujący musi być również korektą obejmującą wszystkie pozycje korygowane w obu PIT-ach. W nowym PIT może być mniej zapisów w polu „Powód korekty" (gdy nowe zdarzenie „unieważnia" poprzednie - korekta powrotna), a w skrajnym przypadku system wyświetla komunikat o konieczności anulowania niewysłanego uprzednio PIT-u. Również w przypadku zwrotu całkowitego, gdy PIT dotyczący kwoty wypłaty nie został jeszcze wydrukowany system wyświetla komunikat o konieczności anulowania niewysłanego PIT-u.
Należy uwzględnić w systemie możliwość - gdy system proponuje nadpisanie PIT-u, użytkownik może utworzyć nowy dokument PIT. Jeśli korygowany PIT nie został jeszcze wydrukowany to system proponuje nadpisanie, na co użytkownik może się nie zgodzić, a gdy korygowany PIT został już wydrukowany automatycznie wybierana jest opcja „Nowy numer kancelaryjny". Wybór opcji „nadpisanie" powoduje wyświetlenie na ekranie informacji koniecznej do zatwierdzenia przez użytkownika o treści „PIT dla (nazwisko) o numerze kancelaryjnym (numer) należy niezwłocznie zablokować do wydruku w SAP".
W przypadku wystawienia PIT-u dotyczącego kilku umów, w nowym, dodatkowym, wyświetlanym na ekranie polu informacyjnym powinny pojawić się następujące teksty:
1. Dla PIT-u, który został nadpisany informacja, że „PIT został nadpisany PIT-em (numer kancelaryjny)".
2. Dla PIT-u nadpisującego informacja, których umów dotyczy ten PIT zbiorczy.
Jeżeli PIT nie został dotąd wystawiony dla tej umowy, oznaczać to może poważny błąd obsługi systemu. W takim przypadku korekta PIT-u nie może zostać wystawiona, a użytkownik jest powiadamiany stosownym komunikatem.
Na liście można zobaczyć wszystkie dane o PIT. System umożliwia wystawienie dokumentów PIT-8C w
następujących miejscach:
1. Rejestrowanie wypłaty połączone z tworzeniem dokumentów PIT-8C
2. Korekta danych beneficjenta wykonywana ręcznie przez użytkownika (nie zalecane)
3. Korekta danych beneficjenta wykonywana na podstawie wystąpienia korygującego dane („Korekta po wypłacie”)
4. PIT korygujący po zwrocie dotacji wypłaconej beneficjentowi
Odrębne przepisy dotyczą wystawienia PIT-u dla beneficjenta niebędącego obywatelem polskim.
Pola rekordu PIT8C:
1. Numer systemowy umowy kredytowej,
2. Nazwisko Beneficjenta,
3. Imię Beneficjenta,
4. Adres zamieszkania:
a) kraj,
b) województwo,
c) powiat,
d) gmina,
e) ulica.
f) nr domu,
g) nr lokalu,
h) miejscowość,
i) kod pocztowy,
j) poczta,
5. PESEL,
6. NIP,
7. Data urodzenia,
8. Dane urzędu skarbowego (nazwa i adres),
9. Rok, którego dotyczy informacja,
10. Czy to złożenie informacji, czy jej korekta,
11. Rodzaj przychodu - opis tekstowy,
12. Kwota przychodu,
13. Numer kancelaryjny (do systemu LOTUS),
14. Dala i godzina utworzenia PIT w „MODULE DOM” (wszystkie PIT-y utworzone w ramach jednej paczki mają ten sam czas utworzenia -jest to stempel czasowy akcji),
15. Kto utworzył PIT,
16. Data i godzina przekazania rekordu poza „MODUŁ DOM” (do systemu SAP),
17. Kto przekazał dane
18. data i godzina wydruku PIT-u (w tablicy PIT-ów), wyświetlane w:
a) Rejestrze PIT-ów,
b) zakładce danych o PIT wyświetlanych z umowy kredytowej,
c) w rejestrze umów.
Po wybraniu z listy umów, zawartych precz osobę fizyczną (beneficjent o statusie „poprawny"), umowy o statusie „wypłacona", pracownik DK ma możliwość wystawienia formularza podatkowego PIT-8C za dany rok. O ile użytkownik nie określi innego filtrowania na ekranie pojawią się jedynie te umowy (o statusie
„wypłacona"), dla których nie został jeszcze wystawiony PIT-8C.
Funkcjonalność:
1. Przegląd informacji o umowie, a w szczególności informacji o wystawionym dokumencie PIT-8C,
2. Wystawienie PIT-8C dla wszystkich wybranych umów, którym jeszcze nie wystawiono PIT-u, a umowa ma status „wypłacona",
3. Wystawienie PIT-8C dla wybranej umowy,
4. Informacja na temat umowy związanej z PIT, a po jej wyświetleniu ewentualnie umów korygujących lub korygowanych oraz ew. szczegółów korekty,
5. Powtórne wystawienie PIT-8C - w przypadku, gdy z powodu błędu systemu lub błędu
transmisji wystawiony P1T-8C nie dotarł do systemu SAP.
6. Przekazanie wystawionych PIT-ów z „MODUŁU DOM” do systemu SAP,
PIT wystawiany jest dla osoby fizycznej – beneficjenta, na rzecz którego została przekazana dotacja. Dla każdej umowy, dla której wystawiono P1T-8C rejestrowana będzie informacja o datach oraz czasie wystawienia formularza.
W przypadku błędów wydruku, zniszczenia lub zgubienia wydrukowanego formularza, będzie możliwe powtórne wystawienie PIT-u również z systemu SAP. Tam też będą rejestrowane momenty wydrukowania formularza i ewentualnych powtórek.
Wystawienie PIT-8C z punktu widzenia „MODUŁU DOM” będzie polegać na zapisaniu w tablicy PIT-8C rekordu danych, w formacie gotowym do wczytania przez system SAP. W tablicy w dodatkowych polach zapisana jest informacja kto i kiedy zapisał dane do wydrukowania PIT-8C.
Przekazanie danych do systemu SAP będzie związane z następującymi czynnościami:
1. Zapisanie w tablicy momentu przekazania wybranych (domyślnie wszystkich dotychczas
nieprzekazanych) rekordów,
2. Wygenerowanie i zapisanie numeru kancelaryjnego (kolejny numer wysyłanego PIT-u w danym roku kalendarzowym); należy przyjąć format NF/PIT/nn/yy, gdzie nn to numer PIT-u, a yy to numer roku kalendarzowego (np, NF.PIT/1/14),
3. Wygenerowanie tablicy (pliku CSV) w określonym folderze odczytywalnym przez system SAP,
4. Odczytanie pliku przez system SAP w celu utworzenia wydruku,
5. Odczytanie pliku i zarejestrowanie wybranych danych (w systemie kancelaryjnym nie są zapisywane nazwy ulic ani numer ulicy i lokalu) przez system kancelaryjny (Lotus); powinno to nastąpić w dniu wysyłki wydrukowanych PIT-ów do beneficjantów; system kancelaryjny umożliwi podanie daty wysyłki,
6. Wygenerowanie dwóch plików CSV pocztowej listy nadawczej oraz importu do systemu kancelaryjnego. Ze względu na to, że wydruk listy nadawczej oraz wydruk PIT-ów będą wykonywane z różnych systemów, w różnym czasie i ewentualność zgubienia wydrukowanej listy, konieczne jest uwzględnienie możliwości powtórzenia drukowania listy nadawczej dla wysyłki przygotowanej o wybranej godzinie i dniu.
W dalszej kolejności system SAP wczytuje przygotowany plik CSV z danymi do PIT, drukuje formularze PIT wraz z etykietą adresową, przygotowuje dane do wysyłki elektronicznej do Urzędów Skarbowych oraz zapamiętuje te informacje w przygotowanej do tego celu strukturze. Na podstawie tych informacji będzie możliwe wspomniane powyżej powtórne wydrukowanie PIT-u i/albo powtórna wysyłka do Urzędu Skarbowego. Daty przesyłania wersji elektronicznej na stronę Ministerstwa Finansów oraz otrzymania dokumentu UPO są rejestrowane.
Wydrukowane przez system SAP PIT-y dla beneficjentów będą pakowane do kopert, a następnie wysyłane listem poleconym. W tym celu konieczne będzie wczytanie utworzonej listy podawczej do arkusza xls. a następnie wydrukowanie. Po wysłaniu listów poleconych kolejny plik CSV będzie wczytywany do systemu kancelaryjnego, w celu zarejestrowania wysyłki. Konieczne jest automatyczne wczytywanie przygotowanego przez SAP pliku zawierającego dla poszczególnych numerów kancelaryjnych; datę i godzinę wydruku. Należy określić format stosownego pliku .csv, np.: nr. kancelaryjny; Pesel; data i godzina wydruku oraz zdefiniować parametr na folder, w którym mają się znajdować pliki tworzone przez SAP.
„MODUŁ DOM” umożliwi wystawienie korekty (por. 6.4.2.) do przesłanego do Urzędu Skarbowego
formularza. Projektując interfejs do systemu SAP należy uwzględnić pole „Uzasadnienie".
6.6.1. ZGŁOSZENIE PROBLEMU Z PIT-em BENEFICJENTA
W przypadku, gdy wystąpił problem z dokumentem PIT należy go zarejestrować a następnie obsłużyć. Zasadniczo mają miejsce dwa rodzaje problemów:
1. Zwrot PIT z powodu niedoręczenia przesyłki,
2. Zgłoszony błąd PIT-u.
Każdy z tych błędów należy wyjaśnić z bankiem, W pierwszym przypadku należy uzyskać z banku właściwy adres, na który należy wysłać PIT, a w drugim właściwe dane. W pierwszym przypadku bank powinien przesłać nowy adres zamieszkania (przez wystąpienie „Korekta po wypłacie”). Dopuszcza się jednak podanie przez bank adresu korespondencyjnego, na który należy wysłać zwrócony PIT do beneficjenta. Nie ma wówczas PIT-u korygującego, ale w trakcie drukowania kartki adresowej dla problemu jest generowany nowy numer kancelaryjny. W drugim przypadku konieczne jest wystąpienie z banku
„Korekta po wypłacie”, w którym zostaną podane właściwe dane i na podstawie którego zostanie
wystawiony PIT korygujący.
Pola rekordu „Problem z PIT-em"
1. Numer systemowy problemu,
2. Numer systemowy beneficjenta,
3. Rodzaj problemu (wybór z listy: Adres, NIP, PESEL, Nazwisko, Imię Data urodzenia, Urząd
Skarbowy, kwota, niedoręczenie),
4. Uzupełniający rodzaj problemu (gdy problemów jest kilka np. PESEL, data urodzenia i nazwisko) – pole tekstowe,
5. Jeśli zgłaszający podał - jakie powinny być właściwe dane,
6. Status sprawy (wybór z listy: Zgłoszona w DKU, Wyjaśniana z bankiem przez WRK, Otrzymano
wyjaśnienie z banku),
7. Adres korespondencyjny w przypadku, gdy PIT ma zostać wysłany na inny adres,
8. Xxxxx, która utworzyła problem z PIT-em.
Należy wprowadzić rodzaj obiektu w tablicy statusów (Zmiana Statusów) do zapamiętywania zmian statusu w tej tablicy. Dodatkowo wpisanie rekordu przez osobę zgłaszającą problem w DKU powinno skutkować wysłaniem maiła do WRK informującego o wprowadzeniu danych.
Status „Otrzymano wyjaśnienie z banku" jest równoznaczny z zamknięciem tego problemu. Dalsza jego obsługa to albo przetwarzanie otrzymanego z banku dokumentu „Korekta po wypłacie", albo: inna reakcja na informacje z banku (np. wysłanie PIT-u na adres korespondencyjny).
Dostęp do informacji o problemie jest możliwy zarówno z listy beneficjentów poprzez wywołanie funkcji
„Zgłoszenie problemu" (pojawia się, wówczas możliwość wpisania problemu, gdy nie ma jeszcze żadnego problemu dla danego beneficjenta, lub lista problemów danego beneficjenta) lub z następnej funkcji umożliwiającej wyświetlenie wszystkich zapisanych w systemie problemów. Funkcja „Zgłaszanie problemu” działa tylko dla tych beneficjentów, którym wystawiono już dokument PIT-8C. System rejestruje
osobę zgłaszającą problem z PIT-em oraz generuje mail z informacja o utworzeniu nowego problemu z PIT-em.
Po wybraniu problemu użytkownik może zmienić status problemu lub inne zapisane w rekordzie informacje. Może też utworzyć nowy problem dotyczący beneficjenta.
6.6.2. RAPORTOWANIE PROBLEMÓW Z PIT-ami
Funkcja umożliwia wylistowanie wszystkich zarejestrowanych problemów bez wybrania beneficjenta. Użytkownik może wybrać status rodzaju problemów, które chce oglądać po wybraniu szukanego problemu i może przejść do jego edycji. Na ekranie edycji dostępna jest również funkcja utworzenia nowego problemu. Nowy problem tworzony jest dla beneficjenta, którego wcześniej wybrany problem został wskazany. Funkcja wydruku raportów.
6.7. REJESTR WYSTĄPIEŃ BANKÓW O ŚRODKI
Pola rekordu „wystąpienie":
1. Numer systemowy wystąpienia,
2. Numer systemowy banku,
3. Miesiąc wystąpienia,
4. Rok wystąpienia,
5. Numer kolejny wystąpienia (dla danego Banku, w danym roku),
6. Numer umowy o współpracy,
7. Data wystąpienia,
8. Rodzaj wystąpienia,
9. Wystąpienie sporządził,
10. Łączna kwota dotacji, o jaką występuje Bank,
11. Data wpłynięcia wystąpienia do Funduszu (wpisywana ręcznie),
12. Data wczytania do systemu (informacja nadmiarowa),
13. Status wystąpienia,
14. Uzasadnienie odrzucenia wystąpienia (niezależnie od rodzaju wystąpienia) przez pracownika
Funduszu,
15. Data przekazania informacji o odrzuceniu wystąpienia do banku,
16. Kto przekazał informację o odrzuceniu wystąpienia,
17. Komu w banku została przekazana informacja o odrzuceniu wystąpienia,
18. Kwota wypłaty,
19. Data dokonania wypłaty,
20. Kto dokonał wypłaty,
21. Data rejestracji wypłaty,
22. Kto zarejestrował wypłatę.
Zmiana statusu wystąpienia pamiętana jest w tablicy „zmiana statusów".
Identyfikacja:
1. Numer systemowy banku.
2. Miesiąc wystąpienia,
3. Rok wystawienia,
4. Numer wystąpienia w danym miesiącu.
Funkcjonalność (po wybraniu banku z listy banków):
1. Wprowadzenie wystąpienia,
2. Przeglądanie wystąpień, a następnie dla wybranego wystąpienia:
a) Trzystopniowa weryfikacja (ocena) wybranego wystąpienia,
b) Wyplata dotacji dla zweryfikowanego wystąpienia,
c) Wydruk negatywnie zweryfikowanego wystąpienia w celu przesiania do banku (Raport
dotyczący braków lub nieprawidłowości – Bank rok, miesiąc,)
d) Wprowadzanie danych o wysyłce odrzuconego wystąpienia.
3. Unieważnienie korekty wystąpienia – możliwość ta powinna dotyczyć wystąpień dowolnego rodzaju
dot. korekt.
Uwagi:
1. Wprowadzanie wystąpień, ich walidacja, obsługa decyzji Zarządu oraz wypłat jest możliwa tylko wówczas, gdy Fundusz jest związany z bankiem ważną umową. Przeglądanie, obsługa trwałości przedsięwzięcia oraz zwrotów dopłat jest możliwa bez względu na to, czy umowa z bankiem jest ważna, czy nie.
2. Na ekranie ze szczegółami wystąpienia system będzie prezentował aktualną informację statystyczną o związanych z nim umowach kredytowych: liczba umów ogółem, liczba umów poprawnych, suma kwot do wypłaty z umów poprawnych,
3. System będzie nadawał kolejne numery wersjom wystąpienia otrzymanym od banku w danym miesiącu. Numerowane powinny być również próby wczytania wystąpienia, po których wystąpienie nie zostało zapamiętane w systemie.
4. Beneficjent związany z umową identyfikowany jest poprzez NIP (zapisany w umowie) i swój status
-„poprawny".
5. Wystąpienie może mieć następujące statusy:
a) „weryfikacja systemu - poprawna - otrzymywany po wczytaniu i poprawnym automatycznym
zweryfikowaniu wystąpienia,
b) „weryfikacja formalno-merytoryczna - poprawna" otrzymany po zakończonej pozytywnie weryfikacji przez pracowników WFB,
c) "weryfikacja formalno-rachunkowa - poprawna" - otrzymany po zakończonej pozytywnie
weryfikacji przez pracowników DK,
d) „poprawne do wypłaty" - otrzymany po zaakceptowaniu wystąpienia do wypłaty przez Zarząd Funduszu; wystąpienie „poprawne do wypłaty" musi zawierać przynajmniej jedną umowę kredytową o statusie „poprawna do wypłaty",
e) „wypłacone" - otrzymywany po dokonaniu i zarejestrowaniu wypłaty,
f) „niepoprawne" - otrzymywany po weryfikacji negatywnej, automatycznej lub dokonanej przez
użytkownika,
g) „nieaktualne" otrzymywane po wczytaniu aktualizacji wystąpienia (nie jest możliwe aktualizowanie wystawień o statusie „wypłacone" lub „nieaktualne").
6.7.1. WPROWADZANIE WYSTĄPIENIA
Wprowadzenie wystąpienia składa się z następujących etapów:
1. Wczytanie wystąpienia odbywa się automatycznie,
2. Określenie rodzaju wystąpienia.
3. Weryfikacja warunków wyprowadzenia danego rodzaju wystąpienia,
4. Odrzucenie całego wystąpienia lub wprowadzenie wystąpienia i umów z nim związanych (wyjątki
por. Aktualizacja wystąpienia).
5. Automatyczna weryfikacja wystąpienia i zawartych w nim umów połączona z nadaniem stosownego statusu wystąpieniu oraz związanymi z nim umowom i beneficjentom.
6. Obsługa „Korekty po wypłacie”.
Ad 1. Wystąpienia wczytywane są automatycznie przy wykorzystaniu systemu komunikacji z e-PUAP (przekazywanie danych przy pomocy Web service'ów) lub przy pomocy importu plików xml. Dla wystąpień, których wczytanie do „MODUŁU DOM" było możliwe, ewentualne błędy wczytania (np. zatwierdzenie przez osobę nieuprawnioną) zapisywane są w polu wystąpienia „Uzasadnienie odrzucenia". W przypadku, gdy wczytanie nie było możliwe wówczas plik, który nie został wczytany umieszczany jest w folderze błędów wczytywania (definiowany przez parametr).
Do określonych w parametrach użytkowników przekazywany jest mail z informacją o wynikach wczytania wystąpienia. Mail zawiera co najmniej następujące informacje (pierwsza w każdym przypadku, a pozostałe, gdy wczytanie dokumentu było możliwe):
a) Stwierdzone wszystkie błędy wczytywania - te, które uniemożliwiły wczytanie dokumentu oraz
ewentualnie stwierdzone błędy samego wystąpienia (niezwiązane z umowami),
b) Czy jest to jest wystąpienie,
c) Bank,
d) Xxxxxx wczytanego dokumentu,
e) Okres, którego dokument dotyczy,
System utworzy log z wczytywania wystąpienia, zawierający podstawowe informacje oraz listę wykrytych błędów i niepoprawności. Identyfikacja ewentualnych błędów wpisana zostaje w pola „Uzasadnienie odrzucenia..." - stosownie do błędu - rekordu umowy kredytowej lub wystąpienia. W przypadku gdy wczytanie wystąpienia jest niemożliwe (np. błąd danych) system generuje mail z przeznaczeniem do wysłania do banku zawierający informację o przyczynach nieudanego wczytania wystąpienia. Mail wysyłany jest do użytkownika lub do grupy użytkowników WRK. W przypadku braku podpisu pod wystąpieniem powinny być wypisane cechy podpisu złożonego pod dokumentem (w mailu oraz w polu wystąpienia „uzasadnienie odrzucenia").
Ad 2-4. System rozpoznaje, rodzaj wczytywanego wystąpienia:
Podstawowe - pierwsze wystąpienie danego banku dotyczące danego miesiąca. Ten rodzaj jest dopuszczalny, gdy me ma jeszcze żadnego wystąpienia z danego banku dotyczącego danego miesiąca, albo wszystkie takie dotychczas wczytane wystąpienia mają status „niepoprawne". Do systemu są wprowadzane następujące dane:
1. Dane o wystąpieniu,
2. Dane o wszystkich umowach zawartych w tym wystąpieniu,
3. Dane o beneficjencie (wzięte z rekordu umowa):
a) Jeżeli w systemie nie ma jeszcze danych o beneficjencie dla wczytywanej umowy (identyfikacja po numerze PESEL / NIP), to wprowadzane są dane tego beneficjenta. W projekcie technicznym należy przewidzieć sytuacje, w których mogą zaistnieć wystąpienia z różnych banków z takim samym nr PESEL.
b) Jeżeli są dane o beneficjencie i te dane:
- Są identyczne - system nie wprowadza nowych danych, (komunikat: beneficjent jest już w
bazie)
- Różnią się od wprowadzanych, to zostaje to odnotowane w logach systemu. Jeżeli „staremu"
beneficjentowi:
∗ Wypłacono już dotację to „nowy" beneficjent zostaje zapamiętany ze statusem
„nieaktualny", a umowa ze statusem „niepoprawna",
∗ Nie wypłacono dotacji (przypadek aktualizacji wystąpienia, korekty) to „stary" beneficjent otrzymuje status „nieaktualny", a „nowy" status „poprawny"; status umowy zostanie nadany po jej pełnej weryfikacji przez system.
Aktualizacja - kolejne wystąpienie banku w danym miesiącu. Ten rodzaj jest dopuszczalny, gdy w systemie jest już wystąpienie z danego banku, dotyczące danego miesiąca o statusie „weryfikacja", (dowolny rodzaj) lub „niepoprawne" . Wystąpienie zarejestrowane wcześniej w systemie zmieni swój status na „nieaktualne", a umowy w nim zawarte:
1. Te, które nie różnią się od uprzednio wprowadzonych w wersji zapamiętanej będą miały zmieniany
tylko numer wystąpienia na numer aktualizacji; nowa wersja umowy nie jest wprowadzana do
systemu,
2. Te, których dane zostały zmodyfikowane (umowa jest w wystąpieniu aktualizacyjnym i aktualizowanym) → status „starej" zmienia się na „nieaktualna", a „nowa" jest wprowadzana; następnie przeprowadzana jest jej automatyczna weryfikacja,
3. Te, które były w wystąpieniu aktualizowanym, ale nie ma ich w wystąpieniu aktualizacyjnym mają zmieniany status na „usunięte".
Sposób obsługi beneficjentów jest identyczny jak w przypadku wczytywania wystąpienia podstawowego. W przypadku, gdy w systemie nie ma jeszcze żadnego wystąpienia z danego banku dotyczącego danego miesiąca to system powinien założyć, że uprzednio podjęto nieudaną próbę wczytania wystąpienia podstawowego, a następnie zarejestrować wczytywaną aktualizację oraz związane z nią umowy. Stosowny komunikat powinien być umieszczony zarówno w logach systemu jak i na ekranie.
Korekta - kolejne wystąpienie banku dotyczące danego miesiąca. Ten rodzaj jest dopuszczalny, gdy w systemie jest już wystąpienie lub wystąpienia o statusie „wypłacone" lub „poprawne do wypłaty” z danego banku i dotyczące danego miesiąca. Poza tymi wystąpieniami mogą być jeszcze jedynie wystąpienia o statusie „niepoprawne" lub „nieaktualne" lub inne wystąpienia rodzaju „Korekta” lub „Korekta po wypłacie”.
Korekta po wypłacie – kolejne wystąpienie banku dotyczące danego miesiąca. Ten rodzaj jest dopuszczalny, gdy w systemie jest już wystąpienie lub wystąpienia o statusie „wypłacone” z danego banku i dotyczące danego miesiąca. Umowy zawarte w „Korekcie po wypłacie” musiały występować w zarejestrowanym w systemie wystąpieniu o statusie „wypłacone” i mieć ten sam status co wystąpienie. Ani zarejestrowane uprzednio wystąpienia ani umowy, nie zmieniają swojego statusu w zapamiętanej w systemie korygowanej umowie po zarejestrowaniu wypłaty, dla nowo wczytanej umowy (choćby w kwocie zero) zapisywany jest link do nowo wczytanej umowy. Umowy zawarte w „Korekcie po wypłacie” po wczytaniu są weryfikowane podobnie jak umowy z innych rodzajów wystąpień. Jeżeli choćby jedna z umów z
„Korekty po wypłacie” nie miała zapamiętanego w systemie odpowiednika o właściwym statusie to cała
„Korekta po wypłacie” i wszystkie zawarte w niej umowy są odrzucane. Sposób obsługi beneficjentów jest
identyczny jak w przypadku wczytywania Aktualizacji.
W przypadku, gdy nie są spełnione warunki poprawnego wczytania wystąpienia (np. wczytywana jest korekta do nieistniejącego wystąpienia) to wszystkie zawarte w wystąpieniu umowy są odrzucane, stosowna informacja jest wyświetlana na ekranie, a wystąpienie zapisywane jest w systemie ze statusem niepoprawne i z podaniem uzasadnienia odrzucenia.
Ad 5. Automatycznej weryfikacji przez system podlega wczytywane wystąpienie oraz jego pozycje. W wyniku weryfikacji określany jest status wystąpienia oraz każdej z zawartych w nim umów, na
„weryfikacja systemu – wystąpienie „poprawne" albo „niepoprawne". Weryfikacja systemowa składa się z następujących etapów:
1. Weryfikacja poprawności formatu i kompletności danych (w tym weryfikacja właściwego wypełnienia pól ograniczonego wyboru) - całość wystąpienia i jego poszczególne pola mają być zgodne z definicją XML Scheme.
2. Nazwa banku i umowa - umowa z bankiem musi być zarejestrowana w systemie, musi mieć status
„realizowana", a jej ważność obejmować miesiąc, którego dotyczy wystąpienie.
3. Weryfikacja rodzaju wystąpienia (opisana powyżej).
4. Dla beneficjentów opisanych w pozycjach wystąpienia (w umowach):
a) Wypełnione są pola identyfikujące osobę fizyczną Nr PESEL, - pełna kontrola numeru,
b) Nr NIP (jeżeli niepusty) – pełna kontrola numeru,
c) Ulica powinna być wpisana bez przedrostka "ul." lub "u." lub "ulica" (np. "ul. Dumki" ma być wpisana jako "Dumki"). Słowa "Aleja", "Aleje" lub "Plac" powinny być wpisane w pełnym brzmieniu. Nie wolno stosować kropki ani wersji skróconych tych słów. Odstępstwa (np. nadmiarowe spacje), o ile to możliwe, powinny być automatycznie poprawione przez system podczas wprowadzania umowy. Dotyczy to zarówno ulicy jak i numeru domu i lokalu.
d) Numer domu i lokalu ma być zapisany bez spacji. Zakres powinien być oddzielony znakiem"/". Inne znaki niż cyfry, litery i znak „/" nie są dopuszczalne.
e) Kod pocztowy musi być zapisany w bazie teleadresowej LSI, a nazwa miejscowości w umowie musi być taka sama jak odpowiadająca kodowi pocztowemu nazwa z bazy teleadresowej. System uzupełnia wszystkie wpisywane adresy o województwo, powiat, gminę i pocztę - wzięte z bazy teleadresowej.
f) Beneficjent musi mieć status: „poprawny".
g) System powinien dopuszczać wprowadzanie danych dużymi lub małymi literami.
5. Dla pozycji wystąpienia (umowy):
a) Numer umowy nie może się powtarzać w ramach wystąpienia.
b) Numer umowy nie może się powtarzać w ramach wszystkich zarejestrowanych umów z danym Bankiem. W oczywisty sposób nie dotyczy to umów z wystąpienia o rodzaju Korekta i Aktualizacja.
c) Adres realizacji przedsięwzięcia nie może się powtarzać w ramach wystąpienia oraz wszystkich zarejestrowanych umów. W oczywisty sposób nie dotyczy to umów z wystąpienia o rodzaju Korekta i Aktualizacja.
d) Wykorzystana kwota kredytu na koszty kwalifikowane powinna być równa lub mniejsza od kosztów kwalifikowanych ogółem.
e) Kwota kredytu wykorzystanego na koszty kwalifikowane musi być większa od dotacji.
6. Dla każdego wprowadzanego wystąpienia sprawdzane jest czy:
a) Łącznie z wczytywanym wystąpieniem spełniony został warunek kontroli co najmniej 25% (parametr modułu) przedsięwzięć, liczony narastająco za dany rok kalendarzowy (nie dotyczy wystąpień rodzaju Korekta) - sprawdzenie pola „data kontroli realizacji",
b) Suma kwot dotacji równa jest wartości pola „wysokość dotacji",
c) W wyniku złożonego wystąpienia nie został przekroczony przyznany bankowi limit środków do wypłaty na dany rok,
W wyniku weryfikacji systemu:
1. Wprowadzane wystąpienie otrzymuje status „weryfikacja systemu - poprawna" albo
„niepoprawna", konieczny mail o automatycznie wykonanej operacji przez system z informacją
o statusie i przyczynie,
2. Umowy z tego wystąpienia uzyskują status „weryfikacja systemu - poprawna" albo
„niepoprawna". W przypadku aktualizacji wystąpienia, gdy nie ma zmian w danej umowie to
status umowy zapisanej w systemie nie jest zmieniany.
Ad 6. Automatycznej weryfikacji przez system podlega wczytywane wystąpienie typu „Korekta po wypłacie" oraz jego pozycje i w jej wyniku określany jest status wystąpienia oraz umów. Weryfikacja systemowa przebiega analogicznie jak dla wystąpień innych typów.
Każda z umów uzyskująca status „weryfikacja formalno - merytoryczna poprawna" jest następnie dalej przetwarzana w celu określenia różnić pomiędzy umową oryginalną oraz umową poprawioną. Różnice określają typ korekty i mogą dotyczyć następujących kwestii:
1. Korekta danych adresowych beneficjanta lub innych jego danych niefinansowych, które znajdują się na dokumencie PIT-8C lub korekta w dół kwoty wypłaconej (w tym całkowity zwrot). Określane są informacje, które są korygowane i stosowna informacja jest zapamiętywana (np.
„Korekta NIP” lub „Korekta adresu"). Ten tekst będzie użyty przy propozycji uzasadnienia korekty. Korekta jest typu „PIT-DB”.
2. Korekta innych niefinansowych danych, które nie pojawią się na dokumencie PIT-8C (np. powierzchnia ogrzewana budynku lub adres przedsięwzięcia) dotyczącym umowy. Określane są informacje, które są korygowane i stosowna informacja jest zapamiętywana. Korekta jest typu
„DB” – Dyrektor Biura.
3. Jeżeli wśród korygowanych danych jest też korekta w górę kwoty, która została wypłacona to korekta jest typu „Zarząd” (zmiana w górę wypłaconej kwoty) lub „PIT-Zarząd” (zmiana w górę kwoty oraz zmiana innych danych z dokumentu PIT). W tym drugim przypadku zapamiętywana jest informacja o rodzaju dokonanych zmian.
Po w weryfikacji formalno-merytorycznej wystąpienie jest weryfikowane rachunkowo a następnie użytkownik uruchamia dla niego funkcję „Obieg dokumentów”.
Funkcjonalność (po wybraniu wystąpienia z listy wystąpień):
1. Listowanie wprowadzonych do systemu wystąpień,
2. Wybór wybranego z listy wystąpienia i wyświetlenie szczegółowych informacji związanych z
wystąpieniem.
Na liście wyświetlane są następujące informacje o wystąpieniu:
1. Nazwa banku,
2. Miesiąc i rok, którego dotyczy wystąpienie,
3. Data wystąpienia,
4. Status wystąpienia,
5. Numer kolejny wystąpienia danego banku, dotyczącego danego miesiąca,
6. Data kontroli formalno-merytorycznej / formalno-rachunkowej,
7. Kto dokonał kontroli formalno-merytorycznej / formalno-rachunkowej.
Dane są posortowane według miesiąca (zaczynając od ostatniego) oraz nazwy banku. O ile użytkownik nie wprowadzi innego filtrowania, to wyświetlane są tylko wystąpienia o statusach:
1. „Weryfikacja systemu poprawna".
2. „Weryfikacja formalno-merytoryczna poprawna",
3. „Weryfikacja formalno-rachunkowa poprawna",
4. „Poprawne do wypłaty".
W dokumentacji dla użytkownika powinny być opisane kryteria poprawności dla każdej z tych weryfikacji.
Po wybraniu przez użytkownika wystąpienia wyświetlana jest pełna informacja na temat samego wystąpienia oraz lista umów związanych z tym wystąpieniem (których pole „numer wystąpienia" równe jest numerowi wybranego wystąpienia). Istnieje możliwość wylistowania wszystkich umów związanych z danym bankiem, miesiącem i rokiem wystąpienia, bez względu na ich status. Dla umów istnieje możliwość przeglądania szczegółowych informacji związanych z umową.
Po wybraniu wystąpienia można je zweryfikować, wprowadzić informację o wypłacie dotacji lub wydrukować wystąpienie w celu przekazania wyników weryfikacji do banku (por. podrozdziały poniżej).
6.7.3. WERYFIKACJA WYSTĄPIENIA ORAZ UMÓW PRZEPROWADZANA PRZEZ
PRACOWNIKÓW FUNDUSZU
Funkcjonalność:
Dla zweryfikowanych merytorycznie umów danego wystąpienia weryfikację formalno-rachunkową można rozpocząć zanim zakończy się weryfikacja formalno-merytoryczna wszystkich umów. W trakcie weryfikacji formalno-rachunkowej umowy dla wystąpienia o statusie „Korekta po wypłacie” użytkownik może zaznaczyć, że dla danej umowy nie należy wystawiać PIT-u korygującego, a PIT zwykły z tym samym numerem kancelaryjnym co uprzednio wystawiony PIT. Ta funkcjonalność jest ważna na wypadek, gdy błąd w PIT zostanie zauważony już po przesłaniu dokumentu do SAP, ale jeszcze przed wysłaniem dokumentu do beneficjenta lub Urzędu Skarbowego (na bramkę Ministerstwa Finansów).
1. Weryfikacja umów z wybranego Banku oraz miesiąca, którego dotyczy wystąpienie,
2. Weryfikacja wystąpienia.
Uwagi:
1. Możliwa jest zarówno weryfikacja umów wystąpienia pojedynczo lub zbiorczo. Typowy sposób pracy pracownika merytorycznego, który powinien być obsłużony przez system to:
a) Tymczasowe zaznaczenie wszystkich widocznych na ekranie umów wybranego wystąpienia jako zweryfikowanych (system nie daje możliwości ustawienia znacznika dla umów, które nie są widoczne na ekranie),
b) Zdjęcie znacznika dla umów „podejrzanych",
c) Pozytywne zweryfikowanie wszystkich pozostałych,
d) Bardziej szczegółowa analiza „podejrzanych”, a w jej wyniku weryfikacja umów lub określenie
ich statusu jako „niepoprawna".
2. Typowy sposób pracy pracownika wpisującego decyzję Zarządu to:
a) Wpisanie statusu „niepoprawna" dla umów negatywnie zweryfikowanych przez Zarząd,
b) Wpisanie statusu „poprawna do wypłaty" dla wszystkich pozostałych umów.
3. Po weryfikacji wszystkich umów wystąpienia, o ile jest zachowana zasada, że co najmniej 25% dotychczas zweryfikowanych umów zostało skontrolowanych przez bank (licząc w skali roku kalendarzowego dla składanych wystąpień), to automatycznie odpowiednio zmienia się status wystąpienia:
a) Jeżeli żadna umowa w wystąpieniu nie ma statusu „weryfikacja systemu – „poprawna", a przynajmniej jedna ma status „weryfikacja formalno-merytoryczna poprawna" to wystąpieniu nadawany jest status „weryfikacja formalno-merytoryczna - poprawna".
b) Jeżeli żadna umowa nie ma statusu „weryfikacja formalno-merytoryczna - poprawna", a przynajmniej jedna ma status „weryfikacja formalno-rachunkowa - poprawna", to wystąpieniu nadawany jest status „weryfikacja formalno-rachunkowa - poprawna".
c) Jeżeli żadna umowa nic ma statusu „weryfikacja formalno-rachunkowa - poprawna", a
przynajmniej jedna ma status „poprawna do wypłaty", to wystąpieniu nadawany jest status
„poprawne do wypłaty".
d) Jeżeli po weryfikacji zweryfikowanych umów zostało mniej 25% to system nadaje wystąpieniu
status „niepoprawne" i jednocześnie podaje uzasadnienie w stosownym polu rekordu wystąpienie.
4. Jeżeli wystąpienie lub umowa zostały zweryfikowane negatywnie to użytkownik powinien w polu
„uzasadnienie" podać powód negatywnej weryfikacji.
W celu dokonania weryfikacji umów użytkownik wybiera z listy właściwe wystąpienie, o statusie
„weryfikacja systemu - poprawna", „weryfikacja formalno-merytoryczna poprawna", „weryfikacja formalno-rachunkowa poprawna" lub „poprawna do wypłaty". Do weryfikacji wybierana jest lista umów o odpowiednim statusie:
1. Weryfikacja umów przez WRK jest możliwa tylko dla tych o statusie „weryfikacja systemu -
poprawna". Należy zmienić status umowy na jeden z dwóch: „weryfikacja formalno-merytoryczna -
poprawna" lub „niepoprawna".
2. Weryfikacja umów przez DKU jest możliwa tylko dla tych o statusie „weryfikacja formalno- merytoryczna - poprawna". Należy zmienić status umowy na jeden z dwóch: „weryfikacja formalno- rachunkowa - poprawna" lub „niepoprawna".
3. Wpisywanie wyników weryfikacji umów przez Zarząd Funduszu jest możliwe tylko dla tych o statusie
„weryfikacja formalno-rachunkowa - poprawna" lub „poprawna do wypłaty". Należy zmienić status umowy na jeden z dwóch: „poprawna do wypłaty" lub „niepoprawna".
Dla zweryfikowanych merytorycznie umów danego wystąpienia weryfikacje, formalno-rachunkowa można rozpocząć zanim zakończy się weryfikacja formalno-merytoryczna wszystkich umów. Status „poprawna do wypłaty" można nadawać umowom, których wystąpienie ma status „weryfikacja formalno-rachunkowa - poprawna".
W celu dokonania weryfikacji wystąpienia użytkownik wybiera z listy właściwe wystąpienie, o statusie
„weryfikacja systemu - poprawna", „weryfikacja formalno -merytoryczna poprawna" lub „poprawne do wypłaty". Wystąpienie poprawne będzie zmieniać swój status automatycznie w miarę weryfikacji i zmiany statusów umów z nim związanych. Wystąpieniu niepoprawnemu należy zmienić status na „niepoprawne". Jeżeli użytkownik uzna wystąpienie za niepoprawne, to zmienia on status wystąpienia podając uzasadnienie decyzji.
System automatycznie rejestruje informację o pracowniku dokonującym weryfikacji oraz dacie jej dokonania. Zarejestrowana informacja o wyniku weryfikacji nie będzie mogła być już zmieniona. Umowa kredytowa lub cale wystąpienie posiadające status „niepoprawne" nie będzie mogło być weryfikowane na kolejnych etapach.
1. Powtórzony adres przedsięwzięcia (albo inne dane np. PESEL, NIP, nr umowy, kolejna umowa beneficjenta) – system bez wychodzenia z weryfikacji wystąpienia umożliwia wyświetlenie umowy (umów), które mają ten sam adres przedsięwzięcia lub (PESEL, NIP, nr umowy, lub tego samego beneficjenta),
2. Automatyczne opisy – dla powtórzeń, informacja co zostało powtórzone, dla Xxxxxx Skarbowego informacja jaki Urząd jest właściwy dla adresu, a jaki został wybrany,
3. Gdy wystąpienie nie jest kompletne – brak wartości pola – system wskazuje puste pola,
Każdy błąd ma swój numer (lista błędów zawiera kod błędu, rodzaj błąd/ostrzeżenie oraz komunikat). System prowadzi rejestr błędów.
Pola tablicy „Błędy wystąpień” :
1. Numer systemowy wystąpienia,
2. Numer błędu,
3. Identyfikator obszaru zmian,
4. Data usunięcia
Zapamiętywane są jedynie błędy skorygowane przez bank. W przypadku pojawienia się nowych, poprawionych danych dotyczących umowy w tablicy wpisywane są dane dotyczące tej poprawy. W tym celu porównywane są aktualnie przeprowadzone wyniki weryfikacji i starej wersji umowy z weryfikacją nowej wersji. Do tablicy trafiają obszary zmian oraz numer usuniętego błędu. Lista obszarów zmian podana jest poniżej:
1. Dane identyfikacyjne beneficjenta (imię, nazwisko, data ur., XXXXX, XXX),
2. Dane adresowe beneficjenta,
3. Dane adresowe przedsięwzięcia,
4. Dane niefinansowe dotyczące umowy,
5. Dane finansowe umowy
Wystąpienia wybrane w trakcie realizacji tej funkcji otrzymują status „Uchwala dla Zarządu".
W przypadku wystąpienia ”Korekta po wypłacie" obsługa wystąpienia zależy od rodzaju korekty zgłaszanej przez bank. Wystąpienie dzielone jest na odrębne wystąpienia dla różnych typów umów (PIT-DB, DB, pozostałe (Zarząd oraz PIT-Zarząd). Wystąpienia wynikowe zawierać będą umowy tylko jednego (lub dwóch – zarząd i PIT-Zarząd) typu, a różnić się będą od oryginalnego kolejną numeracją i nazwą pliku uzupełnioną o literę „V” wraz z numerem umowy.
Jeżeli wśród zmian, które są w umowie znajduje się korekta w górę kwoty, którą wypłacono beneficjentowi, wówczas wystąpienie to jest dołączane do zbioru wystąpień, które są załącznikami do tworzonej uchwały Zarządowej i wymagają zatwierdzenia przez Zarząd (korekta typu „Zarząd" lub „PIT-Zarząd”).
Jeżeli umowa zawarta w wystąpieniu „Korekta po wypłacie" nie koryguje w górę wypłaconej dotacji to
wystąpienie wymaga zatwierdzenia przez Dyrektora Xxxxx.
Dokumenty przekazywane do systemu Lotus są tam podpisywane według stosownego dla rodzaju dokumentu obiegu dokumentów. Po zakończeniu obsługi dokumentu użytkownik w systemie Lotus rejestruje jego status. Status ten jest automatycznie przekazywany do „MODUŁU DOM”, w którym podejmowane są stosowne akcje:
1. W przypadku zatwierdzenia uchwały przez Zarząd (Dyrektora Biura), wystąpienia związane z tą
uchwalą Zarządu (lub z tą decyzją Dyrektora Biura) oraz zawarte w nich umowy otrzymują status
„Poprawne do wypłaty". Wyjątkiem są umowy-korekty typu „DB", które otrzymują status
„Wypłacone". W przypadku, gdy decyzja związana jest z wypłatą środków, system generuje przelew w formacie xml (ustalonym dla przelewów zwykłych BGK) dla każdego z wystąpień, z którym związana jest wypłata i zapisuje go w folderze określonym przez parametr systemu. Przelew generowany jest tylko dla tych banków, dla których jest wpisane do systemu konto bankowe. Generowany jest również automatycznie rejestrowany w SAP dokument księgowy.
2. W przypadku odrzucenia uchwały lub odesłania jej do poprawy, wystąpienia związane z uchwałą Zarządu (decyzją DB) otrzymują znów status „Weryfikacja formalno-rachunkowa poprawne".
Po zarejestrowaniu w „MODULE DOM" statusu dokumentu przekazanego przez system „Lotus" moduł wysyła mail do DKU informujący o zdarzeniu. Mail jest wezwaniem do realizacji przelewów przygotowanych przez system. W mailu zawarta jest informacja o najpóźniejszej możliwej dacie, kiedy może zostać zrealizowana wypłata dla danego banku. Data ta obliczana jest na podstawie daty ostatniej aktualizacji wystąpienia danego banku oraz zapisanej w parametrze systemu liczby dni, którą ma Fundusz na całkowitą obsługę wystąpienia. Data, o której jest mowa w mailu to data wpływu środków na rachunek banku, a w praktyce jest to data o dzień roboczy późniejsza niż data najpóźniejszej możliwej, zgodnej z umową realizacji przelewu przez Fundusz. System nie obsługuje przypadku decyzji „zatwierdzone z poprawkami”. W przypadku „Korekt po wypłacie” typu „DB” dodatkowym działaniem realizowanym przez system jest:
1. Dala umowy korygowanej ustawienie statusu „skorygowana” oraz zapisanie numeru
identyfikacyjnego umowy korygującej (dla pozostałych typów robi się to po „rejestracji wypłaty”),
2. Opisane powyżej ustawienie statusu wystąpienia oraz zawartych w nim umów na „Wypłacone”.
6.7.6. REJESTRACJA WYPŁACONYCH DOTACJI
Informację o wypłacie będzie można zarejestrować tylko dla:
1. wystąpienia banku o statusie „poprawne - do wypłaty"
2. wystąpienia, która zawiera minimum 25% umów skontrolowanych przez Bank, liczonych
narastająco w skali roku kalendarzowego dla kolejnych wystąpień,
3. banku, z którym ważność umowy pokrywa cały okres, którego dotyczy wystąpienie
4. beneficjentów, którzy mają status „poprawny".
System umożliwia realizację wypłat częściowych (dla wybranych umów z wystąpienia). System umożliwia wygodny wybór umów do zapłacenia (podanie kwoty maksymalnej i automatycznie wybranie pierwszych umów z wystąpienia, tak by nie przekroczyć kwoty maksymalnej, zaznaczanie i odznaczanie umów do wypłaty, stała kontrola kwoty do zapłaty). Po zarejestrowaniu wypłaty częściowej wystąpienie nie zmienia statusu (status „Poprawne do wypłaty” pozostaje aż do zapłacenia (ostatniej z umów), a status (na
„wypłacone”) zmieniają jedynie zapłacone umowy.
W celu rejestracji dokonanej wypłaty użytkownik wybiera z listy właściwe wystąpienie, dla tych wystąpień wybranego Banku, które mają status „poprawne do wypłaty". Na ekranie przed rejestracją wypłaty pokazywana jest lista umów związanych z tym wystąpieniem oraz podsumowania, w szczególności łączna kwota „do wypłaty". Zarejestrowanie wypłaty (wpisanie daty dokonania wypłaty) powoduje zmianę statusu wystąpienia na „wypłacone". Przed zatwierdzeniem zmiany statusu (zapisaniem daty) system zażąda od użytkownika dodatkowego potwierdzenia.
System automatycznie wpisze informację o wypłacie dla każdej z zapłaconych umów kredytowych o statusie
„poprawna - do wypłaty" wymienionych w danym wystąpieniu oraz zmieni ich status na „wypłacona". Od tego momentu zmiana jakichkolwiek danych dla wystąpienia nie będzie możliwa. Dla wymienionych w wystąpieniu umów o statusie „wypłacona” będzie możliwość ich skorygowania wystąpieniem „Korekta po wypłacie” lub wpisanie danych o kontroli trwałości przedsięwzięcia, a w przypadku negatywnego wyniku kontroli również możliwość dopisania informacji o zwrocie dotacji. Dla beneficjentów będzie możliwe edytowanie danych, w celu poprawienia ew. błędów w formularzach PIT-8C.
Dodatkowe funkcje realizowane w trakcie rejestrowania wypłaty (lub decyzji Dyrektora Biura wymagających wystawienia PIT-u korygującego):
1. Przygotowanie dokumentów PIT w przypadku rejestracji wypłaty wystąpienia rodzajów
„Podstawowe”, „Aktualizacja”, „Korekta”, „Korekta po wypłacie” dla przypadku typu „Zarząd”,
2. Stworzenie PIT-u korygującego dla „Korekt po wypłacie” typu „PIT-Zarząd” oraz „PIT-DB”,
3. Dla umów rodzaju „Korekta po wypłacie”, korygowana przez nie umowa otrzymuje status
„skorygowano” oraz zapamiętywany jest link do umowy korygującej,
4. W przypadku przekazania środków do banku (oba poprzednie punkty) – przygotowanie informacji
dla banku, które umowy zostały zapłacone,
5. W przypadku rejestracji zwrotu lub częściowego zwrotu (Korekta po wypłacie typu „PIT-DB” anulująca lub zmniejszająca wypłaconą dotację) rejestracja wypłaty dotyczy w istocie zwrotu przez bank środków w wysokości różnicy pomiędzy poprzednią i aktualną wartością umowy. System nie zawiera obsługi odsetek należnych w związku ze zwrotem przez bank nienależnie pobranych środków. System wystawia również PIT korygujący, uzupełniony modyfikowalną przez użytkownika informacją np. „Korekta kwoty dotacji” lub „Dotacja podatnikowi nie została przyznana”. Zwrot ma wpływ na limit tylko w przypadku zwrotów związanych z brakiem trwałości przedsięwzięcia. W przypadku „Korekt po wypłacie” typu „PIT-DB” związanych tylko z danymi niefinansowymi (np. NIP) rejestruje się wypłatę w kwocie zero zł. W przypadku, gdy dla umowy nie ma konieczności tworzenia PIT korygującego (przypadek, gdy XXX został wysłany do SAP, ale nie został jeszcze wysłany dalej) wówczas przygotowany jest PIT zwykły ze starym numerem kancelaryjnym. Eksport danych do SAP tworzony jest w celu nadpisania zapamiętanych tam danych.
W trakcie tworzenia dokumentów PIT obliczany jest kolejny numer kancelaryjny (zależny od roku, w którym drukowany jest PIT). Każdy z dokumentów ma „stempel czasowy”, kiedy został utworzony dany
6.7.7. WYDRUK NEGATYWNIE ZWERYFIKOWANEGO WYSTĄPIENIA
W przypadku, gdy wystąpienie lub któraś z umów wystąpienia została negatywnie zweryfikowana (przez system lub na dowolnym etapie weryfikacji przeprowadzanej przez pracowników Funduszu) to wypełniane jest pole „uzasadnienie odrzucenia". Pole to wypełnianie jest dla wystąpienia lub umów albo automatycznie (dla umów odrzuconych przez moduł Kolektor), albo ręcznie (dla umów- odrzuconych przez pracowników Funduszu lub jego Zarząd).
Wystąpienie z negatywnymi weryfikacjami można wydrukować. Wydruk powinien zostać niezwłocznie mailem lub faksem przekazany do właściwego banku, a dane o wysyłce zarejestrować w systemie (por. rozdział następny). Bank po poprawieniu danych przesyła Aktualizację wystąpienia (możliwe tylko przed decyzją o wypłacie dotacji) lub jego Korektę (gdy decyzja o wypłacie dotacji została już dla danego wystąpienia podjęta).
6.7.8. WPROWADZENIE DANYCH O WYSYŁCE ODRZUCONEGO WYSTĄPIENIA
Dla wybranego wystąpienia o statusie „niepoprawne" lub zawierającego umowy o statusie „niepoprawne" do
systemu należy wpisać następujące dane:
1. Data przekazania informacji o odrzuceniu wystąpienia do banku,
2. Kto przekazał informację o odrzuceniu wystąpienia,
3. Komu w banku została przekazana informacja o odrzuceniu wystąpienia.
Rejestr sprawozdań banku utworzony na podstawie danych przekazywanych przez banki do NFOŚiGW zawartych w załączniku nr 6 do Umowy o współpracy.
Pola rekordu „sprawozdanie" str. 1:
1. Numer systemowy sprawozdania,
2. Numer systemowy banku,
3. Numer kolejny sprawozdania (dla danego Banku, w danym roku),
4. Numer umowy o współpracy,
5. Okres, którego dotyczy sprawozdanie,
6. Rodzaj sprawozdania - podstawowe lub aktualizacja,
7. Rok, którego dotyczy sprawozdanie,
8. Data utworzenia sprawozdania,
9. Klo utworzył sprawozdanie,
10. Kto zatwierdził sprawozdanie,
11. Dane o złożonych wnioskach narastająco za dany rok:
12. Standard wykonania domu lub lokalu,
13. Liczba złożonych wniosków,
14. Kwota dotacji na częściową spłatę kapitału kredytu dla złożonych wniosków,
15. Dane o zawartych przez Bank umowach kredytu narastająco za dany rok:
16. Standard wykonania domu lub lokalu,
17. Liczba zawartych umów kredytu,
18. Kwota kredytów na koszty kwalifikowane,
19. Kwota dotacji na częściową spłatę kapitału kredytu ogółem,
w tym: kwota dotacji do wypłaty w danym roku,
20. Data wpłynięcia sprawozdania do Funduszu (wpisywana ręcznie),
21. Uzasadnienie odrzucenia sprawozdania (nadania statusu „niepoprawne")
22. Data wczytania do systemu,
23. Status sprawozdania.
Zmiana statusu sprawozdania pamiętana jest w tablicy „zmiana statusów".
Pola rekordu „dane o przewidywanym wykorzystaniu środków":
1. Numer systemowy wystąpienia,
2. Numer roku, którego dotyczy informacja (pierwszy, drugi, trzeci lub czwarty),
3. Przyznany limit środków do wypłaty,
4. Wykorzystany limit środków do wypłaty,
5. Zmiana limitu (zwiększenie, zmniejszenie),
6. Razem wysokość limitu środków do wypłaty po zmianie,
7. Środki planowane do wypłaty w danym roku z uwzględnieniem umów zawartych w latach
poprzednich.
8. Dla poszczególnych wierszy podsumowania w kolumnie „razem”. Pola rekordu „sprawozdanie" str. 2:
1. Liczba porządkowa,
2. Nazwisko i imię beneficjenta,
3. Województwo (dotyczy realizowanego przedsięwzięcia),
4. Nr umowy kredytu z dotacją,
5. Data podpisania umowy,
6. Rodzaj przedsięwzięcia: d-budowa domu, zd – zakup domu, zm – zakup mieszkania (lokalu),
7. Planowany wskaźnik zapotrzebowania na energię (EUco)2,
8. Planowana data zakończenia przedsięwzięcia,
9. Autor projektu budowlanego (Nazwisko i imię projektanta lub nazwa biura projektowego),
10. Nazwisko i imię weryfikatora,
11. Numer weryfikatora z listy weryfikatorów (unikalny numer nadawany przy wpisie na listę)
Identyfikacja:
1. Numer systemowy banku,
2. Rok sprawozdania,
3. Numer sprawozdania w danym roku.
Funkcjonalność (po wybraniu banku z listy banków):
1. Wprowadzenie sprawozdania,
2. Przeglądanie sprawozdań, a następnie:
a) Weryfikacja (ocena) sprawozdania.
Uwagi:
1. Sprawozdanie może mieć następujące statusy:
a) „Weryfikacja systemu - poprawna" - otrzymywany po wczytaniu i poprawnym automatycznym zweryfikowaniu sprawozdania,
b) „Poprawne" otrzymany po weryfikacji przez pracownika ZFZ,
c) „Niepoprawne" - otrzymywany po negatywnej weryfikacji wykonanej automatycznie lub przez
użytkownika,
d) „Nieaktualne" - otrzymywane po wczytaniu aktualizacji sprawozdania.
6.8.1. WPROWADZANIE SPRAWOZDANIA
Wprowadzenie sprawozdania składa się z następujących etapów:
1. Wczytanie sprawozdania odbywa się automatycznie,
2. Weryfikacja warunków wprowadzenia sprawozdania, w tym rodzaju sprawozdania,
3. Odrzucenie lub wprowadzenie sprawozdania.
Ad 1-3. Po wskazaniu pliku zawierającego sprawozdanie, system wczyta zawarte w nim dane. O ile jest to możliwe (poprawna struktura pliku, kompletne dane w polach obowiązkowych, bank znany w systemie) sprawozdanie jest wprowadzane do systemu. Sprawozdania wczytywane są automatycznie przy wykorzystaniu systemu komunikacji z e-PUAP (przekazywanie danych przy pomocy Web service'ów). Dla sprawozdań, których wczytanie do „MODUŁU DOM" było możliwe, ewentualne błędy wczytania (np. zatwierdzenie przez osobę nieuprawnioną) zapisywane są w polu wystąpienia „Uzasadnienie
odrzucenia". W przypadku, gdy wczytanie nie było możliwe wówczas plik, który nie został wczytany umieszczany jest w folderze błędów wczytywania (definiowany przez parametr).
Do określonych w parametrach użytkowników przekazywany jest mail z informacją o wynikach wczytania sprawozdania. Mail zawiera co najmniej następujące informacje (pierwsza w każdym przypadku, a pozostałe, gdy wczytanie dokumentu było możliwe):
1. Stwierdzone wszystkie błędy wczytywania - te, które uniemożliwiły wczytanie dokumentu oraz
ewentualnie stwierdzone błędy samego sprawozdania (niezwiązane z umowami),
2. Czy jest to sprawozdanie,
3. Bank,
4. Rodzaj wczytanego dokumentu,
5. Okres, którego dokument dotyczy,
System rozpoznaje, rodzaj wczytywanego sprawozdania:
a) Podstawowe - pierwsze sprawozdanie danego banku dotyczące danego okresu. Ten rodzaj jest dopuszczalny, gdy nie ma wprowadzonego jeszcze żadnego sprawozdania z danego banku dotyczącego danego okresu.
b) Aktualizacja - kolejne sprawozdanie banku dotyczące danego okresu. Ten rodzaj jest dopuszczalny, gdy do systemu wprowadzono już jedno lub więcej sprawozdanie z danego banku dotyczące danego okresu. Zarejestrowane uprzednio sprawozdanie o statusie „poprawne" lub
„niepoprawne" zmieni status na „nieaktualne;". W przypadku, gdy w systemie nie ma jeszcze żadnego sprawozdania z danego banku i okresu to system powinien założyć, że uprzednio podjęto nieudaną próbę wczytania sprawozdania podstawowego i zarejestrować wczytywaną aktualizację. Stosowny komunikat powinien być umieszczony zarówno w logach systemu jak i na ekranie.
Ad 4. Po wprowadzeniu sprawozdań system przejdzie do weryfikacji następujących elementów:
1. Weryfikacja poprawności formatu i kompletności danych (w tym weryfikacja właściwego wypełnienia pól ograniczonego wyboru) - całość wystąpienia i jego poszczególne pola powinny być zgodne z definicją XML Scheme.
2. Nazwa Banku i umowa - umowa z bankiem musi być zarejestrowana w systemie, musi mieć status
„realizowana", a jej ważność obejmować okres, którego dotyczy sprawozdanie,
3. Czy liczba kredytów i inne dane zawarte w sprawozdaniu nie są mniejsze od liczb i kwot podanych w poprawnych sprawozdaniach dotyczących tego samego roku?
4. Czy podana przez użytkownika data wpływu jest zgodna z innymi datami sprawozdania – data sprawozdania jest po okresie, którego sprawozdanie dotyczy, a data wpływu nie jest wcześniejsza od daty sprawozdania?
5. Czy kwota dotacji ogółem jest mniejsza od kwoty kosztów kwalifikowanych objętych kredytem z dotacją?
6. Czy kwota dotacji do wypłaty w danym roku nie jest większa niż kwota dotacji ogółem?
7. Czy nie zostały przekroczone przyznane bankowi limity środków do wypłaty w poszczególnych
latach (dla umów zawartych w latach poprzednich i w roku bieżącym)?
Wyniki poszczególnych weryfikacji dokonanych przez system powinny zostać zapisane w systemie i być widoczne przy przeglądaniu sprawozdania. Sprawozdaniu nadany zostanie również odpowiedni status:
„weryfikacja systemu - poprawna" lub „niepoprawna". System utworzy ponadto log z wczytywania sprawozdania zawierający podstawowe informacje (wystąpienie zdarzenia, powodzenie, niepowodzenie, itp.) oraz listę wykrytych błędów i niepoprawności. W przypadku braku podpisu pod sprawozdaniem powinny być wypisane cechy podpisu złożonego pod dokumentem (w mailu oraz w polu sprawozdania
„uzasadnienie odrzucenia").
6.8.2. PRZEGLĄDANIE SPRAWOZDAŃ
Funkcjonalność (po wybraniu banku z listy banków):
1. Listowanie wprowadzonych do systemu sprawozdań,
2. Wybór wybranego z listy sprawozdania i wyświetlenie szczegółowych informacji z nim związanych. Na liście wyświetlane są następujące informacje o sprawozdaniu;
1. Nazwa banku.
2. Zmiana limitu do wypłaty w roku sprawozdawczym,
3. Zmiana limitu do wypłaty w roku sprawozdawczym z tytułu umów z lat poprzednich,
4. % wykorzystania limitu środków do wypłaty ogółem w roku sprawozdawczym,
5. Okres, którego dotyczy sprawozdanie,
6. Data sprawozdania,
7. Status sprawozdania.
Dane są posortowane według roku (zaczynając od ostatniego), nazwy banku oraz okresu. O ile użytkownik
nie wprowadzi innego filtrowania to wyświetlane są tylko sprawozdania o statusie „poprawne".
Po wybraniu przez użytkownika sprawozdania wyświetlana jest pełna informacja na jego temat. Po wybraniu
z listy sprawozdania można je zweryfikować.
6.8.3. WERYFIKACJA SPRAWOZDANIA BANKU PRZEZ PRACOWNIKÓW FUNDUSZU
Funkcjonalność:
1. Weryfikacja sprawozdania,
2. Przeniesienie limitów dla wybranego sprawozdania.
Ad. 1. W celu dokonania weryfikacji sprawozdania użytkownik wybiera je z listy. W pierwszym kroku system dokonuje powtórnej weryfikacji sprawozdania (po ew. ręcznej zmianie limitów), na tej podstawie sprawozdanie ocenia użytkownik. Następnie po dokonaniu oceny przez użytkownika, zmienia status sprawozdania na - „poprawne" lub „niepoprawne". Po określeniu statusu jako „niepoprawne" konieczne jest
podanie uzasadnienia. Ponadto system automatycznie zarejestruje informację o pracowniku dokonującym
weryfikacji oraz dacie jej dokonania.
Ad. 2. Dla wybranego: sprawozdania możliwe jest przeniesienie limitów zapisanych w sprawozdaniu do systemowej tablicy limitów. Akcja wymaga specjalnych uprawnień i potwierdzenia użytkownika, że jest świadomy wykonywanej czynności. Użytkownik jest proszony o podanie:
1. daty, od której obowiązują limity (proponowana, jest data pierwszego dnia z okresu
sprawozdawczego, którego dotyczy sprawozdanie),
2. numeru decyzji o zmianie limitu (proponowany jest numer sprawozdania),
3. daty decyzji o zmianie limitu (proponowana jest data sprawozdania).
Użytkownik zmienia lub akceptuje przedstawione propozycje i zatwierdza ustawienie limitów zgodnie z danymi na sprawozdaniu.
Upoważniony użytkownik będzie mógł nadać sprawozdaniu status „poprawne" nawet wówczas, gdy zapisane w nim limity będą inne niż zapamiętane w systemie.
6.9. REJESTR ARKUSZY EWALUACYJNYCH
Pola rekordu „Arkusze ewaluacyjne":
1. Numer systemowy banku
2. Data wpisania arkusza do systemu
3. Identyfikator pracownika, który wpisał arkusz
4. Numer arkusza
5. Rodzaj przedsięwzięcia (wybór z listy)
6. Wybór standardu energetycznego (wybór z listy)
7. Powierzchnia w m2
8. Województwo (wybór z listy)
9. Rok otrzymania dopłaty (wybór z listy)
10. Okres sprawozdawczy (pełny rok kalendarzowy – wybór z listy)
11. Zużycie energii w kWh/rok lub GJ/rok (wybór z listy w zależności od jednostki)
12. Zużycie paliwa:
a) Źródło energii wraz z rodzajem paliwa
- jeżeli „kocioł” to – (do wyboru z listy: węgiel, gaz, olej, drewno oraz zużycie paliwa w jednostkach przyporządkowanych do rodzaju paliwa),
- jeżeli „pompa ciepła” to – energia elektryczna wraz ze zużyciem w kWh
- jeżeli „inne” to – rodzaj paliwa oraz zużycie paliwa w jednostkach do wyboru z listy (m3, tony, kWh)
b) Koszt paliwa łączny lub jednostkowy w zł
13. Odpowiedź na pytanie 4, jeżeli tak - pole powierzchnia w m2
14. Odpowiedź na pytanie 5, do wyboru z listy c.o. albo c.o + c.w.u. oraz liczba osób zamieszkujących
15. Ocena założonych celów: odpowiedzi na pytania 1-4 (wybór z listy).
Na liście uwidocznione są wszystkie dane uchwały, w tym, czy jest to Uchwała Zarządu, czy Decyzja DB.
Funkcjonalność:
1. Odrzucenie uchwały - działanie analogiczne do odrzucenia uchwały w Lotusie
2. Przyjęcie uchwały - działanie analogiczne do przyjęcia uchwały w Lotusie (użytkownik musi znać numer uchwały i datę jej podjęcia)
3. Lista załączników (analogiczny ekran jak „Wystąpienia banków o środki do uchwały Zarządu")
7. RAPORTY
Z poziomu systemu możliwe będzie utworzenie następujących raportów:
1. Raport dotyczący braków lub nieprawidłowości (format html),
2. Wykaz przekazanych dotacji (format html),
3. Wystąpienie o środki – załącznik do uchwały Zarządu (format html).
Z poziomu narzędzia raportowego Business Objects możliwe będzie utworzenie następujących raportów:
1. Raport z Wystąpień banków o dotacje
2. Raporty ze sprawozdań z realizacji postanowień umowy o współpracy
a) Złożone wnioski o dotacje i zawarte umowy kredytu,
b) Informacja o przewidywanym wykorzystaniu limitu środków na dotacje.
3. Raport z arkuszy ewaluacyjnych,
4. Raport z efektu ekologicznego,
5. Raport - realizacja warunków umowy o współpracy przez banki,
6. Raport z błędów w wystąpieniach banków,
W „MODULE DOM” istnieje podsystem raportowy umożliwiający użytkownikowi wybranie z bazy danych interesujących kolumn i zakresów be z konieczności dodatkowego programowania. Projekt systemu raportowego w projekcie technicznym.
Raportowanie powinno być wywołaniem przeglądarki internetowej z adresem podanym na liście parametrów.
8. ADMINISTRACJA
8.1. PARAMETRY DODATKOWE MODUŁU DEFINIOWANE PRZEZ ADMINISTRATORA
Parametry systemu:
1. Parametry dotacji: NF 15, NF 40 – budowa domu, zakup domu, zakup mieszkania,
2. Kwalifikowany koszt wyższy od dotacji,
4. Foldery komunikacyjne
5. Nadawanie uprawnień
8.2. FUNKCJE DOSTĘPNE DLA ADMINISTRATORA
Odpowiednio przeszkolony administrator ma możliwość wykonania następujących funkcji:
1. Dopisanie brakującego kodu pocztowego na liście kodów pocztowych,
2. Powtórna walidacja całego wystąpienia – np. po dopisaniu kodu pocztowego, zmianie parametrów
systemu lub uzupełnienia bazy danych przez administratora z poziomu SQL Server,
3. Zmiana adresów mailowych wykorzystywanych przez moduł oraz treści maili,
4. Zmiana parametrów systemu, w tym zapisanych folderów standardowo używanych przez moduł
(np. do komunikacji z SAP-em),
5. Rejestracja informacji niezbędnych do wyliczenia odsetek jak od zalęgłości podatkowych (wspólna
z LSI),
6. Wpisanie danych koniecznych do obliczenia odsetek (jak od zalęgłości podatkowych) – oprocentowanie oraz zakres dat.
8.3. SŁOWNIKI, Z KTÓRYCH KORZYSTA MODUŁ
Słowniki są konieczne do właściwej walidacji dokumentów, które przychodzą w formie elektronicznej z
banków:
1. Województwa,
2. Powiaty (w ramach województwa),
3. Gminy (w ramach powiatów),
4. Poczty (w ramach gmin),
5. Nośniki energii (zastępowane przez kolektor),
6. Miesiące,
7. Okresy sprawozdawcze (do 15 kwietnia, 15 lipca, 15 października i 31stycznia),
8. Rodzaje wystąpienia (Podstawowe, Aktualizacja, Korekta, Korekta po wypłacie),
9. WYDRUKI
W ramach „MODUŁU DOM” opisywanego w tym dokumencie przewiduje się możliwość drukowania dla
widocznych ekranów, możliwość wyeksportowania do plików edycyjnych lub generowanie plików csv.
1. Dla ekranów typu „lista”: „wydruk do xls” z nagłówkiem.
2. Dla ekranów typu formularz:
a) dwa wiersze: nagłówek i dane – kolejność wg pól na ekranie
b) dwie kolumny: opis pola, wartość pola – kolejność wg pól na ekranie Wybór opcji i szczegóły do ustalenia w projekcie technicznym.
3. Zawsze dostępny printscreen.
10. SCHEMATY
Opis techniczny procesów przedstawiają załączone schematy:
STANOWISKA PRAC, ROLE – PRZEKAZANIE WYSTĄPIENIA O ŚRODKI
WYSTĄPIENIE
KANCELARIA NFOŚiGW
BANK
BENEFICJENT
ZARZĄD NFOŚiGW
7. Podjęcie / niepodjęcie
uchwały
6. Przekazanie
DO projektu uchwały
Zarządowi.
8. Przygotowanie informacji o
podjętej uchwale.
DYREKTOR BIURA NFOŚiGW
5. Akceptacja projektu uchwały
WRK
1. Weryfikacja formalno -
merytoryczna
3. Utworzenie projektu uchwały
oraz wykazu beneficjentów
9. Przygotowanie informacji o zatwierdzeniu
wypłaty
DKU
2. Weryfikacja formalno - rachunkowa
4. Akceptacja projektu uchwały
9a. Wypłata środków na podstawie uchwały
ZRP
10. Wystawienie PIT
5. Akceptacja projektu uchwały
Główny Księgowy
5. Akceptacja projektu uchwały
1. Weryfikacja formalno-merytoryczna w WRK oraz przekazanie do DKU. W przypadku stwierdzenia błędów merytorycznych oraz ew. rachunkowych (inf. przekazana przez DKU) wysyłana jest do banku informacja zwrotna oraz oczekiwana jest aktualizacja wystąpienia.
2. Weryfikacja formalno-rachunkowa w DKU. W przypadku stwierdzenia błędów DKU informuje WRK o błędach. Dalsze czynności jw.
3. W przypadku stwierdzenia poprawności wystąpienia WRK przygotowuje projekt uchwały wraz z
wykazem beneficjentów i przekazuje go do DKU.
4. DKU weryfikuje wykaz oraz akceptuje projekt uchwały,
5. Dyrektor Biura, ZRP oraz Główny Księgowy akceptują projekt uchwały z wykazem. Dokument
zostaje przekazany przez WRK do DO.
6. DO przekazuje projekt uchwały Zarządowi NFOŚiGW.
7. Zarząd podejmuje uchwałę o wypłacie środków dla banku.
8. DO przekazuje do WRK informację o podjętej uchwale.
9. XXX przygotowuje informację dla banku o podjęciu uchwały i wypłacie środków.
9. a) DKU przekazuje środki na podstawie przyjętej uchwały.
10. DKU wystawia PIT Skróty:
WRK – Grupa użytkowników ds. współpracy z bankami - (obecnie) Wydział Rozwoju i Nadzoru Kapitałowego
DKU – Departament Księgowości i Rozliczeń
DO – Departament Organizacyjny ZRP – Zespół Radców Prawnych Słownik:
Wystąpienie – wystąpienie o środki na dotacje składane do Funduszu przez bank.
Uchwała - podejmowana przez Zarząd NFOŚiGW w celu zatwierdzenia środków do wypłaty, każdorazowo dla złożonego wystąpienia.
KOREKTA PO WYPŁACIE – OBCIĄŻAJĄCA NFOŚiGW
KOREKTA PO WYPŁACIE
KANCELARIA NFOŚiGW
BANK
BENEFICJENT
ZARZĄD NFOŚiGW
7. Podjęcie / niepodjęcie
uchwały
6. Przekazanie
DO projektu uchwały
Zarządowi.
8. Przygotowanie informacji o
podjętej uchwale.
DYREKTOR BIURA NFOŚiGW
5. Akceptacja projektu uchwały
WRK
1. Weryfikacja formalno -
merytoryczna
3. Utworzenie projektu uchwały
oraz wykazu beneficjentów
9. Przygotowanie informacji o zatwierdzeniu
wypłaty
DKU
2. Weryfikacja formalno - rachunkowa
4. Akceptacja projektu uchwały
9a. Wypłata środków na podstawie uchwały
10. Wystawienie PIT
ZRP
5. Akceptacja projektu uchwały
Główny Księgowy
5. Akceptacja projektu uchwały
KOREKTA PO WYPŁACIE – OBCIĄŻAJĄCA NFOŚiGW OPIS
Bank przekazuje do NFOŚiGW korektę po wypłacie poprzez portal e-PUAP. Wszelkie czynności związane z obsługą korekty po wypłacie wykonywane są przez komórki Funduszu, zgodnie z ich kompetencjami. W NFOŚiGW następuje wczytanie korekty po wypłacie do programu oraz kolejno:
1. Weryfikacja formalno-merytoryczna w WRK oraz przekazanie do DKU. W przypadku stwierdzenia błędów merytorycznych oraz ew. rachunkowych (inf. przekazana przez DKU) wysyłana jest do banku informacja zwrotna oraz oczekiwana jest poprawa korekty.
2. Weryfikacja formalno-rachunkowa w DKU. W przypadku stwierdzenia błędów DKU informuje WRK o błędach. Dalsze czynności jw.
3. W przypadku stwierdzenia poprawności korekty po wypłacie WRK przygotowuje projekt uchwały
wraz z wykazem beneficjentów i przekazuje go do DKU.
4. DKU weryfikuje wykaz oraz akceptuje projekt uchwały.
5. Dyrektor Biura, ZRP oraz Główny Księgowy akceptują projekt uchwały z wykazem. Dokument
zostaje przekazany przez WRK do DO.
6. DO przekazuje projekt uchwały Zarządowi NFOŚiGW
7. Zarząd podejmuje uchwałę o wypłacie środków dla banku.
8. DO przekazuje do WRK informację o podjętej uchwale.
9. XXX przygotowuje informacje dla banku o podjęciu uchwały i wypłacie środków.
9. a) DKU przekazuje środki na podstawie przyjętej uchwały.
10. Jeżeli występuje konieczność (PIT został wystawiony wcześniej), DKU wystawia PIT korygujący.
Skróty:
WRK – Wydział Rozwoju i Nadzoru Kapitałowego DKU – Departament Księgowości i Rozliczeń DO – Departament Organizacyjny
ZRP – Zespół Radców Prawnych Słownik:
Wystąpienie – wystąpienie o środki na dotacje składane do Funduszu przez bank.
Uchwała - podejmowana przez Zarząd NFOŚiGW w celu zatwierdzenia środków do wypłaty, każdorazowo dla złożonego wystąpienia.
Korekta po wypłacie obciążająca NFOŚiGW - przesłane przez bank kolejne wystąpienie korygujące złożone poprzednio, które zostało zatwierdzone do wypłaty. Korekta obciążająca NFOŚiGW występuje w przypadku zwiększenia kwoty środków przypadającej do wypłaty.
KOREKTA PO WYPŁACIE – NIEOBCIĄŻAJĄCA NFOŚiGW
KOREKTA PO WYPŁACIE
KANCELARIA NFOŚiGW
BANK
BENEFICJENT
ZARZĄD NFOŚiGW
DO 6. Archiwizacja
decyzji/akceptacji
DYREKTOR BIURA NFOŚiGW
5. Decyzja
/akceptacja korekty
WRK
1. Weryfikacja formalno -
merytoryczna
3. Utworzenie projektu korekty
DKU
2. Weryfikacja formalno - rachunkowa
4. Akceptacja projektu korekty
7. Zaksięgowanie korekty, dot. korekt
rachunkowych– wystawienie PIT
ZRP
Główny Księgowy
5. Akceptacja projektu korekty
KOREKTA PO WYPŁACIE – NIEOBCIĄŻAJĄCA NFOŚiGW OPIS
Bank przekazuje do NFOŚiGW korektę po wypłacie poprzez portal e-PUAP. Wszelkie czynności związane z obsługą korekty po wypłacie wykonywane są przez komórki Funduszu, zgodnie z ich kompetencjami. W NFOŚiGW następuje wczytanie korekty po wypłacie do programu oraz kolejno:
1. Weryfikacja formalno-merytoryczna w WRK oraz przekazanie do DKU. W przypadku stwierdzenia błędów merytorycznych oraz ew. rachunkowych (inf. przekazana przez DKU) wysyłana jest do banku informacja zwrotna oraz oczekiwana jest poprawa korekty.
2. Weryfikacja formalno-rachunkowa w DKU. W przypadku stwierdzenia błędów DKU informuje WRK o błędach. Dalsze czynności jw.
3. W przypadku stwierdzenia poprawności korekty po wypłacie WRK przygotowuje projekt akceptacji
w spr. korekty wraz z wykazem beneficjentów i przekazuje go do DKU.
4. DKU weryfikuje wykaz oraz akceptuje projekt korekty,
5. Księgowy akceptuje projekt korekty z wykazem. Dokument zostaje przekazany przez WRK do
Dyrektora Biura. Dyrektor Xxxxx zatwierdza korektę po wypłacie.
6. DO archiwizuje decyzję DB.
7. DKU księguje korektę w przypadku „korekty rachunkowej” oraz jeśli występuje konieczność, wystawia PIT korygujący.
Skróty:
WRK – Wydział Rozwoju i Nadzoru Kapitałowego DKU – Departament Księgowości i Rozliczeń DO – Departament Organizacyjny
ZRP – Zespół Radców Prawnych Słownik:
Wystąpienie – wystąpienie o środki na dotacje składane do Funduszu przez bank.
Uchwała - podejmowana przez Zarząd NFOŚiGW w celu zatwierdzenia środków do wypłaty, każdorazowo dla złożonego wystąpienia.
Korekta po wypłacie nieobciążająca NFOŚiGW - przesłane przez bank kolejne wystąpienie korygujące złożone poprzednio, które zostało zatwierdzone do wypłaty. Korekta nieobciążająca NFOŚiGW występuje w przypadku zmniejszenia kwoty środków przypadającej do wypłaty lub nie mająca wpływu na kwotę (korekta pozostałych danych).
SPRAWOZDANIA SKŁADANE DO NFOŚiGW
KANCELARIA
NFOŚiGW
DC
prawozdawczość
1. Weryfikacja formalno -
merytoryczna
2.S
SPRAWOZDANIA SKŁADANE DO NFOŚiGW OPIS
WRK
BANK
SPRAWOZDANIE
Bank przekazuje do NFOŚiGW sprawozdanie poprzez portal e-PUAP. Wszelkie czynności związane z obsługą sprawozdania wykonywane są przez komórki Funduszu, zgodnie z ich kompetencjami. W NFOŚiGW następuje wczytanie sprawozdania do programu oraz kolejno:
1. Weryfikacja formalno-merytoryczna w WRK. W przypadku stwierdzenia błędów merytorycznych oraz ew. rachunkowych wysyłana jest do banku informacja zwrotna oraz oczekiwana jest poprawa sprawozdania.
2. W przypadku stwierdzenia poprawności sprawozdania WRK archiwizuje dane w programie. Na podstawie tworzonych przez program raportów DC wykorzystuje dane do tworzonych przez siebie sprawozdań.
Skróty:
WRK – Wydział Rozwoju i Nadzoru Kapitałowego
DC – Departament Planowania i Sprawozdawczości
WYPŁATA ŚRODKÓW– WYSTAWIENIE PIT
KANCELARIA NFOŚiGW
BANK
BENEFICJENT
ZARZĄD NFOŚiGW
3. Zatwierdzenie wypłaty
1. Przygotowanie
DO informacji o podjętej uchwale.
DYREKTOR BIURA NFOŚiGW
WRK
5. Przygotowanie informacji o
zatwierdzeniu wypłaty
DKU
2. Zaksięgowanie wypłaty na podstawie uchwały i przygotowanie
przelewu
4. Wypłata środków, informacja do WRK
4. a) Wystawienie PIT
ZRP
Główny Księgowy
3. Zatwierdzenie wypłaty
WYPŁATA ŚRODKÓW– WYSTAWIENIE PIT OPIS
Wszelkie czynności związane z obsługą wypłaty środków oraz wystawianiem PIT wykonywane są przez komórki Funduszu, zgodnie z ich kompetencjami. Po podjęciu uchwały przez Zarząd dotyczącej wystąpienia o środki lub korekty po wypłacie obciążającej NFOŚiGW realizowane są kolejne czynności:
1. DO przygotowuje informację o podjętej uchwale Zarządu i przekazuje ją do DKU.
2. DKU księguje wypłatę oraz przygotowuje przelew.
3. Główny Księgowy wraz z upoważnioną osobą zatwierdzają wypłatę środków.
4. DKU realizuje wypłatę na podstawie zatwierdzonego przelewu,
4. a) DKU wystawia PIT lub w przypadku korekty, jeżeli zachodzi taka potrzeba (PIT został wcześniej wystawiony) PIT korygujący.
Skróty:
WRK – Wydział Rozwoju i Nadzoru Kapitałowego DKU – Departament Księgowości i Rozliczeń DO – Departament Organizacyjny
ZRP – Zespół Radców Prawnych Słownik:
Uchwała - podejmowana przez Zarząd NFOŚiGW w celu zatwierdzenia środków do wypłaty, każdorazowo dla złożonego wystąpienia.
KANCELARIA
NFOŚiGW
BANK
BENEFICJENT
US
3. Odbiór PIT / zgłoszenie
uwag do PIT / odbiór skorygowanego PIT
DO
1. Przygotowanie
informacji o podjętej uchwale.
DYREKTOR
BIURA NFOŚiGW
4. Akceptacja korekty
PIT
WRK
5. Przekazanie do banku uwag do PIT / odbiór skorygowanych
danych / przygotowanie korekty PIT / tworzenie problemu z PIT w przypadku otrzymanego samodzielnego zgłoszenia z banku / zamknięcie problemu z PIT /
DKU
2. Wystawienie PIT / utworzenie
problemu z PIT / przekazanie skorygowanego PIT
PROBLEM Z PIT OPIS
Wszelkie czynności związane z tworzeniem problemu z PIT oraz obsługą PIT wykonywane są przez komórki Funduszu, zgodnie z ich kompetencjami. Po podjęciu uchwały przez Zarząd dotyczącej wystąpienia o środki lub korekty po wypłacie obciążającej NFOŚiGW, jak też nieobciążającej NFOŚiGW, jednak mającej wpływ na PIT, realizowane są kolejne czynności:
1. DO przygotowuje informację o podjętej uchwale Zarządu i przekazuje ją do DKU.
2. DKU wypłaca środki, przygotowuje PIT do Urzędu Skarbowego oraz Beneficjenta. W przypadku zgłoszonych uwag przez Urząd Skarbowy, tworzy „problem z PIT”, który następnie wyjaśniany jest przez WRK. Po wyjaśnieniu problemu i akceptacji korekty przez Dyrektora Xxxxx, wystawia PIT korygujący.
3. Urząd Skarbowy odbiera przesłane PIT, zgłasza ewentualne związane z nimi uwagi oraz odbiera
ponownie skorygowane PIT.
4. WRK poinformowany o problemie z PIT wyjaśnia zgłoszone uwagi w korespondencji z bankiem oraz przygotowuje korektę PIT do akceptacji Dyrektora Biura. W przypadkach samodzielnego przekazania przez bank korekty danych, mających wpływ na PIT, niezależnie od wystąpienia bądź nie, uwag zgłoszonych przez Urząd Skarbowy, WRK tworzy „problem z pit” a następnie przygotowuje korektę do akceptacji przez Dyrektora Xxxxx. Po zaakceptowaniu zmian zamyka problem z PIT.
5. Dyrektor Biura akceptuje korektę PIT.
Skróty:
WRK – Wydział Rozwoju i Nadzoru Kapitałowego DKU – Departament Księgowości i Rozliczeń DO – Departament Organizacyjny
ZRP – Zespół Radców Prawnych Słownik:
Uchwała - podejmowana przez Zarząd NFOŚiGW w celu zatwierdzenia środków do wypłaty, każdorazowo dla złożonego wystąpienia.
Problem z PIT – utworzenie statusu dla PIT w sytuacji, w której występuje konieczność wyjaśnienia błędów zgłaszanych przez Urząd Skarbowy, bank lub beneficjenta. Po skorygowaniu błędów (akceptacja Dyrektora Biura) następuje zamknięcie „problemu z PIT” oraz wystawienie skorygowanego PIT.
11. WARUNKI TECHNICZNE ZAMAWIAJĄCEGO
Ze względu na zapewnienie jednolitości oprogramowania z użytkowanym u Zamawiającego środowiskiem, moduł DOM powinien być wykonany z uwzględnieniem następujących ograniczeń wynikających z warunków technicznych środowiska Zamawiającego.
1. Moduł DOM będzie częścią systemu LSI (LSI - Lokalny System Informatyczny), który funkcjonuje
w Funduszu. Wymagana jest zgodność modułu z systemem LSI w następującym zakresie:
a. Moduł DOM będzie korzystać ze znajdujących się w systemie LSI słowników (województwa, powiaty, gminy, etc.). W/w słowniki znajdują się w tabelach bazy danych środowiska Microsoft SQL Server 2005. Struktura słowników uwzględnia przyporządkowanie (na podstawie kluczy obcych) jednostek podrzędnych do jednostek nadrzędnych.
b. Moduł DOM będzie wykorzystywał identyczny mechanizm autoryzacji użytkowników jak system LSI (użytkownicy autoryzowani poprzez Active Directory z podstawieniem bazodanowej roli aplikacyjnej – procedura systemowa MS SQL Server SetupRole()).
c. Moduł DOM będzie wykorzystywał identyczny mechanizm ról jak system LSI i będzie korzystać ze słowników osób, departamentów, ról systemu LSI, które znajdują się w tabelach bazy danych środowiska MS SQL Server 2005.
d. Pomiędzy modułem DOM oraz systemem LSI zostanie zachowana spójność wyglądu ekranów Interfejs użytkownika oraz logika obsługi systemu będą podobne.
e. Moduł DOM i system LSI będą wykorzystywały ten sam silnik bazy danych - MS SQL Server 2005.
f. Moduł zostanie napisany w CodeGear Delphi w wersji 2007 lub nowszej, z zachowaniem standardów wersji 2007 i umożliwieniem rekompilacji w wersji 2007.
g. Wykorzystanie komponentów/narzędzi firm trzecich przy budowie modułu DOM wymaga uzgodnienia z Zamawiającym.
2. Moduł DOM będzie zintegrowany z systemem Moduł Kolektor. Integracja polega na:
a. utworzeniu nowej bazy danych „Banki” w środowisku bazodanowym MS SQL Server 2005.
b. przeniesieniu struktury i zawartości części bazy danych systemu LSI (znajdującej się w wydzielonym schemacie „klk”) należącej do użytkowanego przez Zamawiającego modułu Kolektor, z bazy LSI do bazy „Banki” (pkt.2.a)
c. uruchomienie modułu Kolektor połączonego z nowo utworzoną bazą danych „Banki” środowiska MS SQL Server (pkt.2.b). Zostanie przy tym zachowana zasada, użytkownik nie odczuje zmiany środowiska bazodanowego.
d. Wykonaniu i implementacji Przedmiotu Zamówienia (tj. modułu DOM) z wykorzystaniem słowników bazy danych LSI (pkt.1.a i 1.c) oraz bazy danych „Banki” (pkt.2.a i b) jako jedynego repozytorium danych. Zamawiający udostępni niezbędną dokumentację oraz kody źródłowe, umożliwiające wykonanie integracji.
3. Obecna i docelowa architektura rozwiązania jest podana na poniższych schematach:
a. Obecna architektura
§1
1. Wykonawca w ramach wynagrodzenia określonego w §4 ust. 1 Umowy, przenosi na Zamawiającego całość autorskich praw majątkowych do wyszczególnionego w tabelce poniżej Oprogramowania, kodów źródłowych tego Oprogramowania oraz do Oprogramowania i Produktów wytworzonych w ramach Umowy, o których mowa w Załączniku 1 i 3 (Usługi), stanowiących utwór w rozumieniu ustawy z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych. Oprogramowanie o którym mowa w tabelce poniżej, kody źródłowe tego Oprogramowania oraz Oprogramowanie i Produkty, o których mowa w Załączniku 1 i 3 zwane są również "Utworami".
2. Autorskie prawa majątkowe, które Wykonawca przenosi na Zamawiającego obejmują prawo do: rozporządzania Utworami, korzystania z Utworów, wynagrodzenia za korzystanie z Utworów, przenoszenia praw nabytych do Utworów na podstawie umowy, dokonywania zmian w Utworach, wyłącznego zezwalania na wykonywanie zależnych praw autorskich do Utworów, na warunkach opisanych w §2.
L.p. | Nazwa Oprogramowania wytworzonego w ramach Umowy obejmującego wszystkie funkcjonalności określone w Załączniku 1. | Producent Oprogramowania | Liczba użytkowników |
1. | „Moduł Dom" | bez limitu |
§2
1. Wykonawca oświadcza, że jest uprawniony do dysponowania majątkowymi prawami autorskimi do Utworów, o których mowa w § 1.
2. Przeniesienie autorskich praw majątkowych, o których mowa w §1, uprawnia do nieograniczonego w czasie korzystania z Utworów i rozporządzania nimi w kraju i za granicą, dokonywania zmian w Utworach, a także rozporządzania i korzystania z opracowań, na następujących polach eksploatacji:
a) używania i korzystania z Utworów oraz ich pojedynczych elementów przez Zamawiającego oraz inne podmioty upoważnione przez Zamawiającego,
b) używania i korzystania z Utworów oraz ich pojedynczych elementów przez Wojewódzkie Fundusze Ochrony Środowiska i Gospodarki Wodnej i Centrum Koordynacji Projektów Środowiskowych,
c) publicznego wykonywania, wystawiania, wyświetlania oraz odtwarzania Utworów,
d) rozpowszechniania Utworów, w tym w szczególności publicznego udostępniania w taki
sposób, aby każdy mógł mieć do nich dostęp w miejscu i w czasie przez siebie wybranym,
e) użyczania lub najmu, Utworów lub ich kopii,
f) obrotu oryginałem albo egzemplarzami, na których Utwory utrwalono, w tym wprowadzanie
do obrotu, użyczania lub najmu oryginału albo egzemplarzy,
g) swobodnego wytwarzania dowolną techniką egzemplarzy Utworów,
h) tworzenia nowych wersji i adaptacji Utworów (tłumaczenia, przystosowania, skróty, cięcia, zmiany układu lub jakiekolwiek inne zmiany),
i) tworzenia opracowań i przeróbek całości oraz pojedynczych fragmentów Utworów oraz rozporządzania i korzystania z takich opracowań na wszystkich polach eksploatacji określonych w niniejszym załączniku do Umowy, w tym x.xx. prawo do korekty,
j) przekształcenie formatu pierwotnego Utworów na dowolny inny format,
k) łączenia fragmentów Utworów z innymi utworami,
l) określenia nazw Utworów, pod którymi będą one wykorzystywane lub rozpowszechniane, w tym nazw handlowych, włączając w to prawo do zarejestrowania na swoją rzecz znaków towarowych, którymi oznaczone będą Utwory,
m) używania, zmiany, przekazywania i przechowywania niezależnie od formatu, systemu lub standardu,
n) trwałego lub czasowego utrwalania lub zwielokrotniania Utworów w całości lub w części, jakimikolwiek środkami i w jakiejkolwiek formie, niezależnie od formatu, systemu lub standardu, w tym wprowadzania do pamięci komputera i serwerów sieci komputerowych oraz trwałego lub czasowego utrwalania lub zwielokrotniania takich zapisów, włączając w to sporządzanie ich kopii oraz dowolnego korzystania i rozporządzania tymi kopiami,
o) wykorzystywania Utworów do celów marketingowych lub promocji, w tym dla celów edukacyjnych lub szkoleniowych,
p) modyfikacji kodów źródłowych Oprogramowania lub tłumaczenia ich formy (dekompilacja),
q) zwielokrotniania kodów źródłowych Oprogramowania, włączając w to prawo do trwałego lub czasowego zwielokrotniania w całości lub w części jakimikolwiek środkami i w jakiejkolwiek formie, a także opracowania (tłumaczenia, przystosowania lub jakichkolwiek innych zmian) bez ograniczania warunków dopuszczalności tych czynności, w szczególności, ale nie wyłącznie, w celu wykorzystania dla celów współdziałania z programami komputerowymi.
3. Przeniesienie majątkowych praw autorskich do każdego z Utworów nastąpi z chwilą podpisania przez
Zamawiającego Protokołu Odbioru z wynikiem pozytywnym, dotyczącego tego Utworu.
4. Wykonawca zobowiązuje się, że twórcy Utworów nie będą wykonywali osobistych praw autorskich.
5. Jeżeli w ramach realizacji powyższej umowy powstanie wynalazek lub wzór przemysłowy to
Wykonawca przeniesie na Zamawiającego prawo do tego wynalazku lub wzoru przemysłowego.
6. Wykonawca przekaże Zamawiającemu kody źródłowe Oprogramowania, o których mowa w §1 na nośniku CD lub DVD, w postaci nieskompilowanej wraz ze skryptami instalacyjnymi oraz odpowiednim opisem zgodnie ze standardami powszechnie uznawanymi i stosowanymi, w takim formacie, aby Zamawiający mógł z nich korzystać i je modyfikować.
7. Środowisko niezbędne do modyfikacji Oprogramowania zostanie wyspecyfikowane, a specyfikacja umieszczona na nośniku z kodami źródłowymi. Jeżeli do modyfikowania kodów źródłowych potrzebne są specyficzne narzędzia opracowane przez Wykonawcę, zostaną one przekazane Zamawiającemu wraz z kodami źródłowymi.
8. Kody źródłowe będą aktualizowane i dostarczane Zamawiającemu po dokonaniu przez Wykonawcę zmian w Oprogramowaniu w związku ze świadczeniem usług gwarancyjnych, serwisowych lub usług rozwoju Oprogramowania. Zmiany będą przekazywane nie rzadziej niż raz na sześć miesięcy, pod warunkiem realizacji zmian w Oprogramowaniu w danym okresie.
9. Wykonawca, w ramach wynagrodzenia, o którym mowa w §4 ust 1 Umowy przenosi na Zamawiającego własność nośników, o których mowa w niniejszym paragrafie.
§3
1. Wykonawca dostarczy Zamawiającemu wyszczególnione poniżej Oprogramowanie, które jest niezbędne do prawidłowego funkcjonowania przedmiotu Umowy, a do którego Wykonawcy nie przysługują autorskie prawa majątkowe oraz udziela Zamawiającemu w ramach wynagrodzenia określonego w §4 ust. 1 Umowy dalszej licencji na korzystanie z tego Oprogramowania w zakresie uzyskanej przez siebie licencji, zwanej dalej „sublicencją" na to Oprogramowanie, na warunkach opisanych w §4.
2. W okresie 24 miesięcy od zawarcia umowy Wykonawca zapewni prawo do aktualizacji
Oprogramowania do najnowszej opublikowanej wersji oraz wsparcie techniczne dla Oprogramowania.
L.p. | Nazwa Oprogramowania | Producent Oprogramowania | Liczba użytkowników |
1 | |||
2 |
3. W przypadku, gdy do realizacji umowy Wykonawca wykorzysta dodatkowo inne oprogramowanie niż wymienione powyżej oprogramowanie to zostanie dopisane do powyższej listy i w ramach wynagrodzenia określonego w §4 ust. 1 Umowy Wykonawca udzieli Zamawiającemu dalszej licencji na korzystanie z tego Oprogramowania w zakresie uzyskanej przez siebie licencji, zwanej dalej
„sublicencją" na to Oprogramowanie, na warunkach opisanych w §4.
§4
1. Sublicencją, o której mowa w §3 zostanie udzielona na następujących polach eksploatacji:
a) używania i korzystania z Oprogramowania przez Zamawiającego oraz inne podmioty upoważnione przez Zamawiającego,
b) publicznego wykonywania, wystawiania, wyświetlania oraz odtwarzania Oprogramowania,
c) trwałego lub czasowego utrwalania lub zwielokrotniania Oprogramowania w całości lub w części, jakimikolwiek środkami i w jakiejkolwiek formie, niezależnie od formatu, systemu lub standardu, w tym wprowadzania do pamięci komputera i serwerów sieci komputerowych oraz trwałego lub czasowego utrwalania lub zwielokrotniania takich zapisów, włączając w to sporządzanie ich kopii oraz dowolnego korzystania i rozporządzania tymi kopiami,
d) wykorzystywania Oprogramowania do celów edukacyjnych lub szkoleniowych,
2. Udzielenie sublicencji na Oprogramowanie nastąpi z chwilą podpisania przez Zamawiającego Protokołu Odbioru dotyczącego tego Oprogramowania.
3. Sublicencją na Oprogramowanie, o której mowa w § 1 zostanie udzielona na czas nieoznaczony, o
nieograniczonym terytorialnie zasięgu.
4. Wykonawca zobowiązuje się do niewypowiadania licencji na Oprogramowanie.
5. W przypadku wypowiedzenia sublicencji na Oprogramowanie, Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 150% ceny zakupu tego Oprogramowania.
§5
1. Wykonawca zobowiązuje się do pełnego zaspokojenia wszelkich roszczeń, których będą dochodziły strony trzecie w stosunku do licencji i majątkowych praw autorskich przeniesionych na Zamawiającego na podstawie niniejszej umowy.
2. Przeniesienie autorskich praw majątkowych, o których mowa w niniejszym Załączniku, nie dotyczy programów komputerowych, elementów, podprogramów oraz silników udostępnionych publicznie jako Open Source wykorzystanych do wykonania przedmiotu umowy. Wykonawca oświadcza, iż w momencie podpisania końcowego protokołu odbioru ww. programy komputerowe, elementy, podprogramy oraz silniki będą publicznie dostępne bez ograniczeń na korzystanie z nich przez Zamawiającego oraz nie jest wymagane uzyskanie w tym zakresie jakichkolwiek zgód lub opłat na rzecz jakichkolwiek osób trzecich.
§1
1. Wykonawca przeprowadzi szczegółową analizę wymagań.
2. Wykonawca opracuje Projekt Techniczny Oprogramowania. Projekt będzie zawierał między innymi niżej wymienione diagramy, zgodne ze standardem modelowania systemów informatycznych UML:
a) diagram przypadków użycia,
b) diagram czynności,
c) diagram komponentów (wdrożeniowy),
d) schemat bazy danych.
3. Wykonawca opracuje, co najmniej, następujące dokumenty projektowe:
a) Plan Projektu
b) Plan Jakości Projektu
c) Raporty Końcowe Etapu
d) Raporty Okresowe
e) Plany testów i scenariusze testowe
f) Protokoły z testów wewnętrznych
4. Wykonawca przekaże Zamawiającemu wyniki prac, o których mowa w ust. 1, 2, 3 i 4 w formie pisemnej. Jeden egzemplarz każdego z Produktów zostanie przekazany w postaci papierowej, a drugi egzemplarz zostanie przekazany na płycie CD lub DVD, w formacie umożliwiającym edycję, uzgodnionym z Zamawiającym.
5. Wykonawca zaimplementuje prototyp Oprogramowania. Jako prototyp Oprogramowania rozumie się wstępną wersję Oprogramowania obejmującą ekrany przygotowane w narzędziu/narzędziach przewidzianych do budowy docelowego Oprogramowania posiadające ograniczone funkcjonalności umożliwiające podczas prezentacji zapoznanie się ze sposobem pracy użytkownika oraz prześledzeniem sposobu realizacji poszczególnych funkcji oraz przebiegu całego procesu. Wykonawca zaprezentuje Zamawiającemu sposób działania Oprogramowania z wykorzystaniem prototypu. Zamawiający przekaże Wykonawcy, w formie pisemnej, uwagi do prototypu dotyczące działania Oprogramowania na podstawie zaprezentowanego prototypu.
6. Wykonawca zaimplementuje (opracuje i wdroży) Oprogramowanie zgodnie z:
a) wymaganiami określonymi w Załączniku 1,
b) wynikami Usług opisanych w Załączniku 3,
c) dokumentacją Oprogramowania,
d) uwagami do prototypu Oprogramowania.
e) Wykonawca zainstaluje i uruchomi Oprogramowanie w środowisku komputerowym Zamawiającego, znajdującym się w siedzibie Zamawiającego. Oprogramowanie będzie zawierało wyniki prac, o których mowa w niniejszym paragrafie.
f) Wykonawca zobowiązuje się do zapewnienia wsparcia na etapie uruchomienia każdego z etapów Oprogramowania, w wymiarze 1 osobodnia, mającego na celu sprawne rozwiązywanie problemów, jakie mogą wystąpić na tym etapie.
g) Wykonawca, na żądanie Zamawiającego, wykona optymalizację wydajności Oprogramowania.
§2
1. Wykonawca przeprowadzi następujące szkolenia:
a) dla administratorów systemu po stronie Zamawiającego — w wymiarze min. 6 godziny zegarowych,
b) z budowy wewnętrznej systemu (z uwzględnieniem wszystkich użytych komponentów) - w wymiarze min. 4 godziny zegarowe. Zakres szkolenia powinien być dobrany w taki sposób, aby w wyniku szkolenia przekazana została wiedza niezbędna do samodzielnego utrzymania i rozwoju systemu przez zespół programistów Funduszu.
2. Szkolenia zostaną przeprowadzone w języku polskim, w sali szkoleniowej przygotowanej przez
Zamawiającego w jego siedzibie.
3. Szkolenia, o których mowa w ust. 1 będą prowadzone w oparciu o Oprogramowanie zaimplementowane u Zamawiającego.
4. Programy szkoleń zostaną opracowane w taki sposób, aby zapewnić przekazanie wiedzy i umiejętności niezbędnych do samodzielnej realizacji odpowiednich zadań.
5. Wymiary poszczególnych szkoleń określone w ust. 1 są minimalne. W przypadku, gdy do przekazania wiedzy i umiejętności niezbędnych do samodzielnej realizacji odpowiednich zadań wymagany jest większy wymiar szkoleń niż określono w ust. 1, wymiar ten ulegnie odpowiedniemu powiększeniu, bez zwiększenia wynagrodzenia Wykonawcy.
6. Wykonawca przygotuje i przedstawi Zamawiającemu do zatwierdzenia materiały szkoleniowe przeznaczone dla poszczególnych szkoleń.
§3
1. Wykonawca opracuje opisaną poniżej dokumentację w języku polskim i przekaże ją Zamawiającemu w formie pisemnej. Jeden egzemplarz zostanie przekazany w postaci papierowej oraz jeden egzemplarz zostanie przekazany w postaci elektronicznej na płycie CD lub DVD, w formacie umożliwiającym edycję, który zostanie uzgodniony z Zamawiającym.
2. Dokumentacja użytkownika:
a) Zakres tematyczny będzie obejmował obsługę funkcjonalności związanych z bieżącym użytkowaniem Oprogramowania.
b) Dokumentacja zostanie opracowana w taki sposób, aby była ona zrozumiała dla użytkowników nieposiadających biegłości w obsłudze komputera.
c) Dokumentacja będzie zawierała, co najmniej:
I. dokładny opis ekranów, pól i akceptowalnych wartości dla poszczególnych pól,
II. dokładny opis możliwych do wykonania funkcji,
III. dokładny opis tworzenia zapytań pozwalających wyszukać żądane dane,
IV. listę komunikatów i komunikatów o błędach z opisami, w przypadku wyświetlania przez Oprogramowanie komunikatów nie posiadających pełnych opisów,
3. Dokumentacja administratora:
a) Zakres tematyczny będzie obejmował obsługę funkcjonalności związanych z administrowaniem Oprogramowaniem.
b) Podręcznik będzie zawierał, co najmniej:
I. opis mechanizmów wykorzystywanych do administrowania Oprogramowaniem,
II. opis instalacji Oprogramowania na serwerze i na stacji roboczej,
III. opis wszystkich ról i uprawnień użytkowników,
IV. opis definiowania nowego użytkownika i nadawania mu uprawnień oraz zmiany w
uprawnieniach użytkownika,
V. opis rozmieszczenia plików Oprogramowania w systemie operacyjnym wraz z plikami bazy danych i wszystkimi plikami konfiguracyjnymi, plikami logów i rejestrów,
VI. opis konfiguracji stacji roboczej w tym opis parametrów przeglądarki internetowej, rejestrów
i innych zmiennych środowiskowych stacji roboczej,
VII. dokładny opis sposobu konfigurowania Oprogramowania, definiowania słowników
i parametrów oraz opis ekranów, pól i akceptowalnych wartości dla poszczególnych pól,
VIII. dokładny opis mechanizmów integracji z innymi systemami,
IX. procedurę wykonywania kopii bezpieczeństwa Oprogramowania oraz bazy danych Oprogramowania, a także procedurę przywracania Oprogramowania oraz bazy danych Oprogramowania z kopii,
X. listę komunikatów i komunikatów o błędach z opisami, w przypadku wyświetlania przez Oprogramowanie komunikatów nie posiadających pełnych opisów.
4. Dokumentacja projektanta:
c) Zakres tematyczny będzie obejmował obsługę funkcjonalności Oprogramowania związanych
z projektowaniem i implementowaniem Oprogramowania.
d) Podręcznik będzie zawierał, co najmniej:
I. opis budowy logicznej Oprogramowania,
II. pełny opis znaczenia parametrów, identyfikatorów, flag i innych danych numerycznych i znakowych mających wpływ na sterowanie procesami w Oprogramowaniu.
5. Dokumentacja techniczna Oprogramowania. W przypadku, gdy w ramach niniejszej umowy Wykonawca przekazuje Zamawiającemu majątkowe prawa autorskie do kodów źródłowych Oprogramowania, Wykonawca opracuje i przekaże Zamawiającemu dokumentację techniczną Oprogramowania. Dokumentacja ta będzie zawierała, co najmniej:
a) pełny opis struktur danych z opisem źródła danych, czyli wszystkich tabel, pól tabel, indeksów,
więzów integralności, triggerów, procedur, funkcji oraz innych obiektów bazodanowych,
b) opis wszystkich procedur, funkcji, modułów, obiektów i bibliotek kodu źródłowego oprogramowania. Opis powinien zawierać informację, które ekrany i raporty korzystają z procedury, funkcji, modułu, obiektu lub biblioteki oraz jakie są parametry wejściowe ich wywołania,
c) projekty graficzne formatek ekranowych – ze wskazaniem źródła danych,
d) projekty raportów z opisami parametrów wywołania i opisem źródła danych.
§5
Wykonawca przekaże Zamawiającemu pozostałe Produkty, w formie pisemnej. Jeden egzemplarz zostanie przekazany w postaci papierowej oraz jeden egzemplarz zostanie przekazany w postaci elektronicznej na płycie CD lub DVD w formacie umożliwiającym edycję uzgodnionym z Zamawiającym.
Warunki Gwarancji oraz Zasady Świadczenia Serwisu
Gwarancyjnego
§1
1. Wykonawca gwarantuje Zamawiającemu poprawność działania Oprogramowania, wdrożonego do eksploatacji u Zamawiającego, obejmującą realizację przez Oprogramowanie funkcji przewidzianych w niniejszej Umowie w sposób zgodny z:
a) wymaganiami określonymi w Załączniku 1,
b) wynikami Usług opisanych w Załączniku 3,
c) dokumentacją Oprogramowania,
2. Okres gwarancji Oprogramowania dostarczanego w poszczególnych etapach rozpoczyna się w dniu podpisania Protokołu Odbioru dla danego etapu z wynikiem pozytywnym lub pozytywnym warunkowym. Okres gwarancji dla Oprogramowania kończy się po 12 miesiącach od daty podpisania Protokołu Odbioru Końcowego.
3. Wykonawca zobowiązany jest, w ramach gwarancji do usuwania Błędów oraz Błędów Krytycznych
Oprogramowania w celu zapewnienia zgodności jego funkcjonowania z:
a) wymaganiami określonymi w Załączniku 1,
b) wynikami Usług opisanych w Załączniku 3,
c) dokumentacją Oprogramowania.
§2
1. Świadczenie usług gwarancyjnych odbywać się będzie na podstawie Zgłoszeń Gwarancyjnych
dokonywanych w oparciu o procedurę określoną poniżej.
2. Zgłoszenia Gwarancyjne przyjmowane będą przez upoważnionego przedstawiciela Wykonawcy w Dni Xxxxxxx.
3. Karta Zgłoszenia Gwarancyjnego przekazana zostanie upoważnionemu przedstawicielowi Wykonawcy
za pośrednictwem: e-mail'a na adres: ................. lub za pośrednictwem faksu na numer: ...................
4. Wykonawca prześle Zamawiającemu potwierdzenie otrzymania zgłoszenia gwarancyjnego nie później niż w ciągu 4 godzin roboczych, od momentu otrzymania zgłoszenia.
5. W przypadku wystąpienia Błędu lub Błędu Krytycznego w komponentach Oprogramowania opracowanych przez Wykonawcę, Wykonawca podejmie następujące działania:
a) rozpocznie usuwanie Błędu Krytycznego w terminie nie dłuższym niż 1 dzień roboczy, od
momentu przekazania zgłoszenia,
b) usunie Błąd Krytyczny w terminie nie dłuższym niż 2 dni robocze od momentu przekazania
zgłoszenia,
c) rozpocznie usuwanie Błędu w terminie nie dłuższym niż 2 dni robocze od momentu przekazania zgłoszenia,
d) usunie Błąd w terminie nie dłuższym niż 4 dni roboczych od momentu przekazania zgłoszenia.
6. W przypadku wystąpienia Błędu lub Błędu Krytycznego w komponentach Oprogramowania, o których mowa w §3 ust. 2 Załącznika 2, Wykonawca podejmie następujące działania:
a) rozpocznie usuwanie Błędu Krytycznego w terminie nie dłuższym niż 1 dzień roboczy, od
momentu przekazania zgłoszenia.
b) usunie Błąd Krytyczny w terminie nie dłuższym niż 4 dni robocze od momentu przekazania
zgłoszenia.
c) rozpocznie usuwanie Błędu w terminie nie dłuższym niż 2 dni robocze od momentu przekazania
zgłoszenia.
d) usunie Błąd w terminie nie dłuższym niż 10 dni roboczych od momentu przekazania zgłoszenia.
7. Xxxx terminów rozpoczyna się w chwili przekazania zgłoszenia.
8. Naprawa Błędu lub Błędu Krytycznego obejmuje również aktualizację dokumentacji Oprogramowania,
o której mowa w §4 Załącznika 3.
9. Przekazanie i odbiór prac realizowanych w ramach serwisu gwarancyjnego będzie następował zgodnie z zasadami opisanymi w §6 Umowy, z tą różnicą, że zamiast Protokołu Przekazania Wykonawca będzie przedstawiał Protokół Naprawy Gwarancyjnej, który został określony w §8 niniejszego Załącznika.
§3
1. W przypadku, gdy Zamawiający będzie chciał wykonać zmiany w Oprogramowaniu, prześle Wykonawcy specyfikację tych zmian w celu ich zatwierdzenia.
2. Wykonawca zweryfikuje proponowane zmiany i dokona ich akceptacji lub wskaże powód uniemożliwiający zaakceptowanie proponowanych zmian.
3. Wykonawca udzieli odpowiedzi Zamawiającemu, w terminie 10 dni roboczych od daty otrzymania specyfikacji zmian.
4. Zmiany zaakceptowane przez Wykonawcę nie powodują utraty gwarancji, o której mowa w §2 ust. 1 c) Umowy.
5. W przypadku wprowadzenia zmian w Oprogramowaniu, które nie zostały zaakceptowane przez
Wykonawcę, wszelkie błędy, które wynikły z powodu wprowadzenia zmian, nie są objęte gwarancją.
§4
1. W przypadku niedotrzymania terminów, o których mowa w zasadach świadczenia gwarancji, Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 0,1%, a jeśli dotyczy to Błędu Krytycznego - w wysokości 0,3 % ceny brutto określonej w § 4 ust. 1 Umowy, za każdy dzień opóźnienia.
2. W przypadku, gdy wysokość poniesionej szkody przewyższa wysokość zastrzeżonej kary umownej, Zamawiający może dochodzić odszkodowania na zasadach ogólnych.
§5
W przypadku opóźnienia przy usuwaniu Błędu lub Błędu Krytycznego okres gwarancji w odniesieniu do Oprogramowania ulega przedłużeniu o okres opóźnienia.
§6
Niezależnie od roszczeń wynikających z gwarancji Zamawiający, może realizować uprawnienia
wynikające z rękojmi.
§7
Karta Zgłoszenia Gwarancyjnego
Zgłaszający: | Nr zgłoszenia: | Data zgłoszenia: |
Rodzaj Błędu: | - Błąd | - Błąd Krytyczny |
Opis Błędu: | ||
Powtarzalność Błędu: | - tak | - nie |
Kroki umożliwiające powtórzenie błędu: | ||
Dodatkowe informacje: | ||
Załączone zrzuty ekranowe: 1. 2. 3. | ||
Imię Xxx | , nazwisko i podpis ze strony awiającego | |
§8
Protokół Naprawy Gwarancyjnej
Nr Zgłoszenia Gwarancyjnego: | Data naprawy: | |
Przyczyny Błędu: | ||
Wykonane prace naprawcze: | ||
Imię, nazwisko i podpis ze strony Wykonawcy: | Xxxx, nazwisko i podpis ze strony Zamawiającego: |
Załącznik 5 do umowy nr /2013/ /
Numer etapu | Zakres etapu | Czas realizacji (w miesiącach) | Rozpoczęcie realizacji | Strony realizujące | Czas na odbiór (dni robocze)* |
1. | |||||
2. |
* Czas na odbiór określony jest w dniach roboczych liczonych od daty przekazania Protokołu Przekazania danego etapu.
Za datę wykonania części Umowy będącej przedmiotem odbioru uznaje się datę podpisania odpowiedniego Protokołu Odbioru z wynikiem pozytywnym lub
pozytywnym warunkowym.
UWAGA:
Zakresy poszczególnych etapów obejmują również zadania i czynności niezbędne do pełnego, produkcyjnego wdrożenia zrealizowanych w tych etapach
modułów, czyli np. instalację, konfigurację, szkolenia, wdrożenie, wsparcie na etapie uruchomienia, itd.
spisany w dniu w Warszawie
Protokół dotyczy przekazania Produktów opracowanych w ramach Umowy nr.................... zawartej dnia w Warszawie pomiędzy:
NFOŚiGW - Zamawiającym,
a
........................................................ - Wykonawcą.
1. Przedmiotem przekazania są następujące Produkty:
L.p. | Nazwa Produktu | Nr etapu | Oznaczenie Produktu |
1. | |||
2. | |||
3. |
2. Wykonawca oświadcza, że przeprowadził testy lub weryfikację przekazywanych Produktów.
3. Wykonawca oświadcza, że Produkty wymienione w ust. 1 są wolne od Błędów.
4. Termin odbioru Produktów przez Xxxxxxxxxxxxx zostaje określony na dzień (∗) .......................
ze strony Wykonawcy | ze strony Zamawiającego |
(∗) należy wpisać założoną datę
Protokół Odbioru nr
spisany dnia w Warszawie
Protokół dotyczy odbioru Produktów opracowanych w ramach Umowy zawartej w dniu w
Warszawie pomiędzy: NFOŚiGW - Zamawiającym, a ..- Wykonawcą.
1. Protokół dotyczy Produktów przekazanych Protokołem Przekazania nr........................
2. Przedmiotem odbioru są następujące Produkty:
L.p. | Nazwa Produktu | Nr etapu | Oznaczenie Produktu |
1. | |||
2. | |||
3. |
3. Odbiór produktów wymienionych w ust. 1 zakończył się wynikiem (∗)
□ – pozytywnym | □ - negatywnym |
4. Warunki/Błędy:
ze strony Wykonawcy | ze strony Zamawiającego |
Protokół Odbioru Końcowego
spisany dnia w Warszawie
Protokół dotyczy odbioru Produktów opracowanych w ramach Umowy zawartej w dniu w
Warszawie pomiędzy: NFOŚiGW - Zamawiającym, a ..- Wykonawcą.
1. Protokół dotyczy Produktów przekazanych Protokołem Przekazania nr.....................
2. Przedmiotem odbioru są następujące Produkty:
L.p. | Nazwa Produktu | Nr etapu | Oznaczenie Produktu |
1. | |||
2. | |||
3. |
3. Odbiór produktów wymienionych w ust. 1 zakończył się wynikiem (∗)
□ - pozytywnym | □ - negatywnym |
4. Warunki/Błędy:
ze strony Wykonawcy | ze strony Zamawiającego |