Nazwa zamówienia: zamówienie obejmuje sprzedaż 3 nieograniczonych licencji do specjalistycznych systemów informatycznych:
- systemu głównego (sprzedażowego),
- systemu integrującego operatorów logistycznych i płatniczych z systemem głównym oraz
- systemu klienta (widgety wymagane do zainstalowania na stronach internetowych klientów w wersji www i mobilnej),
umożliwiających świadczenie przez Zamawiającego usług logistyczno-płatniczych.
Definicje:
- widget - aplikacja typu client-side osadzana w sklepie merchanta, która uruchamiana jest w formie lightboxa,
- transakcja - proces finalizowania kupna produktów w sklepie internetowym, czyli. wybór formy płatności, dostawy i wykonanie płatności,
- zamknięta transakcja - transakcja, która została opłacana przez klienta za pomocą widgetu,
- przesyłka - forma dostawy zamówionych przez klienta produktów, którą wybrał w trakcie realizowania transakcji przy użyciu widgetu,
- klient - osoba kupująca produkty w sklepie internetowym, finalizująca kupno przy użyciu Widgetu,
- merchant - inaczej e-sklep, w którym implementowany jest Widget,
- integracja - definiowana za pomocą unikalnego klucza (można to określić jako App ID), który jednoznacznie identyfikuje merchanta oraz przypisaną do niego stronę internetową, np. Merchant A może mieć 2 strony internetowe, dla integracji z każdą z nich przypisany jest odrębny App ID.
Systemy powinny składać się z poniższych modułów funkcjonalnych:
- System główny o następującej budowie
- Moduł administracyjny składający się z następujących modułów/platform:
- Modułu Rejestracyjnego (modułu umożliwiającego rejestracje i onboarding nowych sprzedawców),
- Modułu Compliance/KYC (modułu generującego faktury za usługi logistyczne i usługi płatnicze),
- Modułu Billing brokerski (modułu który odpowiada za sprzedaż paczek z wcześniej zakupionej puli produktów),
- Modułów PrePaid i PostPaid,
- Modułu Push GCM/APNS/Chrome (modułu odpowiadającego za wysyłanie komunikatów dla merchatna),
- Modułu Agregacji Danych (modułu odpowiadającego za przetwarzanie i analizę danych dot. preferencji zakupowych) oraz
- Platform testowych (staging i deweloperska)
- Moduł administracyjny składający się z następujących modułów/platform:
2. System sprzedawcy składający się z następujących modułów/platform:
- Moduł Merchant (sklepy internetowe - sprzedaż B2C) składający się z następujących podmodułów:
- Modułu Raportowyego (modułu zwracającego statystyki użytkowania systemu),
- Modułu CMS (modułu pozwalającego na graficzne dostosowanie widgeta pod kątem wizualnym, zgodnym z marchandem),
- Modułu Online Dispute (modułu automatyzującego procesy rozliczeń akcji promocyjnych (np. kody rabatowe) i ułatwiającego kontakt klienta z merchantem,
- Platformy testowej oraz
- Modułów adaptacyjnych i lokalizacyjnych (API i dostosowanie front-endu do wymogów rynku brytyjskiego).
Moduł Merchant (sprzedawcy indywidualni - sprzedaż C2C) składający się z następujących podmodułów:
i. Modułu Aktywacyjnego (modułu odpowiedzialnego za weryfikację osoby prywatnej oraz pobieranie ewentualnych dokumentów),
ii. Modułu billingowego/PrePaid (modułu rozliczającego transakcje w oparciu o przedpłaty),
iii. Modułu rozliczeniowego (modułu rozliczającego przesyłki za pobraniem),
iv. Modułu raportowego (modułu zwracającego statystyki użytkowania systemu) oraz
v. Modułu lokalizacyjnego (dostosowanie front-endu do wymogów rynku brytyjskiego),
B. System integrujący operatorów logistycznych i płatniczych z systemem głównym, w skład którego wchodzą następujące moduły:
- Moduł Logistyki składający się z następujących podmodułów:
- Modułu Proxy,
- Modułu integrującego operatorów logistycznych z systemem głównym,
- Modułu odpowiedzialnego za generowanie raportów i rozliczeń za usługi logistyczne oraz
- Modułu administracyjnego związanego z świadczeniem na rynku brytyjskim.
- Moduł Płatności składający się z następujących podmodułów:
- Modułu Uniwersalnego Routera (odpowiedzialny za przekierowanie konsumenta do preferowanej bramki płatniczej),
- Modułu Scoringu Fraudowego (modułu do liczenia score konsumenta pod kątem ograniczenia ryzyka fraudowego),
- Modułu Obsługi Chargeback (modułu do automatycznej obsługi chargebacków ze strony operatora kart),
- Modułów integrujących operatorów płatniczych z systemem głównym,
- Modułów odpowiedzialnych za generowanie raportów i rozliczeń za usługi płatnicze oraz
- Modułu administracyjnego związanego ze świadczeniem na rynku brytyjskim.
C. System klienta (widgety do wgrania na stronach sklepów internetowych w wersji www i mobile www) składający się z następujących modułów/platform:
- Moduł Klient (obsługa www) składający się z następujących podmodułów:
- Modułu Rejestracyjnego i Logowania,
- Modułu Tokenizacji (mechanizmu umożliwiającego bezpieczne przechowywanie kart kredytowych klienta),
- Modułu Push (mechanizmu zwrotnych komunikatów w oparciu o sieci PUSH),
- Modułu Raportującego (mechanizmu raportującego transakcje i poczynania klienta),
- Modułu Online Dispute (modułu automatyzującego procesy rozliczeń akcji promocyjnych (np. kody rabatowe) i ułatwiającego kontakt klienta z merchantem oraz
- Modułu lokalizacyjnego (dostosowanie front-endu do wymogów rynku brytyjskiego).
- Moduł Klient (obsługa mobilna) składający się z następujących podmodułów:
- Modułu Rejestracyjnego i Logowania,
- Modułu Tokenizacji (mechanizmu umożliwiającego bezpieczne przechowywanie kart kredytowych klienta),
- Modułu Push (mechanizmu zwrotnych komunikatów w oparciu o sieci PUSH),
- Modułu Raportującego (mechanizmu raportującego transakcje i poczynania klienta),
- Modułu Online Dispute (modułu automatyzującego procesy rozliczeń akcji promocyjnych (np. kody rabatowe) i ułatwiającego kontakt klienta z merchantem,
- Modułu SDK dla Merchanta (odpowiednika widgetu do implementowania w aplikacjach mobilnych),
- Modułu CMS (modułu pozwalającego na graficzne dostosowanie widgeta pod kątem wizualnym zgodnym z merchantem),
- Modułu lokalizacyjnego (dostosowanie front-endu do wymogów rynku brytyjskiego).
Sposób integracji ze sklepem:
- integracja powinna obsługiwać dwa tryby - testowy oraz produkcyjny,
- tryb produkcyjny domyślnie powinien być wyłączony. Powinna istnieć możliwość aktywacji trybu produkcyjnego,
- tryb testowy powinien być włączany domyślnie,
- tryb testowy/produkcyjny powinny implikować, które z systemów będą używane (np. testowa strona do płatności czy produkcyjna),
- użytkownik (w tym przypadku programista) powinien mieć możliwość uruchomienia widgetu w trybie testowym (np. gdy będzie chciał móc przeprowadzić testy przed wdrożeniem nowej funkcjonalności),
- jeśli tryb produkcyjny jest wyłączony integracja powinna zostać automatycznie przełączona na tryb testowy.
Widget
Widget powinien być aplikacją Client-Side, napisaną w języku JavaScript, w taki sposób by nie generowało to konfliktów z innymi bibliotekami JavaScript, które mogą być osadzone w sklepie merchanta. Widget, na danej stronie internetowej, musi odpowiadać tylko i wyłącznie jednej integracji.
Kluczowe funkcjonalności dostępne z poziomu widgetu:
- możliwość prostego osadzenia widgeta na wybranej stronie internetowej (a'la Facebook Like Button),
- interfejs API widgetu (po stronie Client-Side) powinien umożliwiać manipulację widgetem, np. poprzez odbieranie callbacków zdarzeń zachodzących w widgecie lub na programistyczne manipulowanie widgetem,
- możliwość zarejestrowania nowego konta z poziomu widgetu bezpośrednio przez klienta,
- możliwość zalogowania się z poziomu widgetu przez klienta,
- możliwość zmiany domyślnie wybranych sposobów płatności i dostawy przez klienta,
- możliwość dodania nowego sposobu dostawy przez klienta,
- możliwość dodania nowego sposobu płatności przez klienta,
- możliwość przeprowadzenia płatności przez klienta z poziomu widgetu, np. kartą płatniczą,
- możliwość przeprowadzenia płatności przez klienta z użyciem e-przelewu,
- komunikacja pomiędzy widgetem a API powinna odbywać się w sposób szyfrowany uniemożliwiający sfałszowanie danych wysyłanych z i do widgetu.
System transakcyjny
System transakcyjny stanowiący część systemu głównego będzie odpowiedzialny za przetwarzanie informacji i danych, które spływają z poziomu Widgetu, m.in. przygotowywanie nowych transakcji, przetwarzanie ich, generowanie płatności, przyjmowanie informacji zwrotnych o płatnościach od operatorów płatności, itp. Komunikacja widgetu z systemem transakcyjnym odbywa się za pomocą API w standardzie REST.
Dane przekazywane z Widgetu do systemu transakcyjnego powinny być weryfikowane pod kątem poprawności, tak by nie dopuścić do manipulowania nimi, np. zmiana wartości produktów, za które ma zapłacić klient, itp.
Kluczowe funkcjonalności:
- możliwość przygotowania nowej transakcji na zapytanie przesłane do API,
- interfejs odbierający informacje o płatnościach od operatorów płatności,
- aktualizacja informacji o transakcji, dla której odebrano informacji o płatności,
- interfejs asynchroniczny - przetwarzanie odebranych zapytań poprzez kolejki zapytań.
Moduł klient
Moduł klient jest to szeroko pojęty interfejs, który umożliwia klientowi zarządzanie jego kontem. System będzie dostępny z poziomu strony www oraz aplikacji mobilnej.
Kluczowe funkcjonalności:
- możliwość zarejestrowania się,
- możliwość zalogowania się,
- możliwość wylogowania się,
- możliwość zmiany hasła,
- możliwość zmiany danych konta,
- możliwość zmiany adresu e-mail,
- możliwość przejrzenia listy transakcji dokonanych przy użyciu Widgetu,
- możliwość połączenia konta z kontami Facebook oraz Google.
Moduł klient powinien wspierać lokalizację, tak by możliwe było wprowadzenie obsługi nowych języków, formatów danych, walut i dat.
Moduł Merchant
Moduł Merchant to szeroko pojęty system oraz interfejs użytkownika przeznaczony dla klientów, którzy prowadzą własny sklep internetowy i zintegrowani są z usługą NeoClick. Powinien on mieć postać strony www, do której dostęp ograniczony jest na podstawie loginu i hasła.
Kluczowe funkcjonalności:
możliwość zarejestrowania nowego konta - nowy, jeszcze niezidentyfikowany merchant zainteresowany usługą zakłada nowe konto:
- nowe konto powinno automatycznie mieć dostęp do trybu testowego,
- przy rejestracji nowego konta powinny być zbierane informacje o stronie www, którą merchant chce zintegrować,
- przy rejestracji powinno zostać utworzone nowe konto użytkownika, które automatycznie staje się kontem z pełnymi uprawnieniami administracyjnymi,
- możliwość zalogowania się - użytkownik z odpowiednimi uprawnieniami powinien mieć możliwość nadawania uprawnień innych użytkownikom do dostępu do konta merchanta,
- możliwość wylogowania się,
- możliwość zmiany hasła do konta - użytkownik z odpowiednimi uprawnieniami powinno mieć możliwość resetowania hasła dla określonego użytkownika w ramach konta merchanta,
- możliwość zmiany danych merchanta - zmiana określonych danych merchanta powinna mieć wpływ na konieczność ponownej weryfikacji konta i/lub integracji z stroną www,
- możliwość zmiany adresu e-mail,
zarządzanie integracjami (widgety - strony www):
- dostęp do listy stron www dla których istnieją integracje lub są w trakcie ich weryfikacji,
- szczegóły dotyczące wybranej integracji,
- możliwość utworzenia nowej integracji - nowa integracja powinna mieć automatycznie dostępny tryb testowy,
- możliwość zarządzania webhookami w ramach integracji.
Moduł administracyjny
Moduł administracyjny (inaczej konsola administracyjna) będzie dostarcza szereg informacji/funkcjonalności związanych z zarządzaniem całą platformą.
Kluczowe funkcjonalności:
- możliwość zarządzania merchantami:
- dostęp do listy merchantów
- możliwość zmiany parametrów konta merchanta,
- możliwość dodawania nowego merchanta,
- dostęp do listy integracji określonego merchanta,
- możliwość zmiany parametrów integracji określonego merchanta,
- możliwość zarządzania kontem billingowym merchanta,
- możliwość weryfikacji konta merchanta ( jego aktywacji/deaktywacji),
- możliwość zarządzania parametrami i ustawieniami, którymi merchant będzie mógł zarządzać z poziomie własnego konta,
możliwość zarządzania klientami:
- dostęp do listy klientów,
- możliwość zmiany parametrów konta klienta,
- dostęp do listy transakcji klienta,
- dostęp do podglądu szczegółów związanych z transakcjami klienta,
- możliwość zarządzania parametrami i ustawieniami, którymi klient może zarządzać z poziomu własnego konta,
możliwość zarządzania transakcjami:
- dostęp do listy transakcji,
- dostęp do szczegółów transakcji,
- możliwość zmiany parametrów transakcji,
- możliwość generowania linka do przeprowadzenia płatności,
- możliwość anulowania transakcji,
możliwość wystawiania faktur dla merchantów za zrealizowane usługi,
możliwość generowania raportów,
możliwość zarządzania użytkownikami, którzy uzyskują dostęp do części administracyjnej systemu:
- każdy z użytkowników powinien mieć określony zakres uprawnień, które definiują do jakiś części systemu i w jakim zakresie ma dostęp oraz jakie czynności administracyjne może wykonać,
- uprawnienia powinny być grupowane w role,
- dwuetapowa weryfikacja.
Szczegółowe informacje na temat dokładnych parametrów technicznych i funkcjonalnych poszczególnych systemów informatycznych objętych niniejszym zapytaniem ofertowym są zawarte:
w specyfikacji technicznej i funkcjonalnej, prezentującej budowę trzech systemów IT o rozbudowanych funkcjonalnościach oraz
w raporcie prac badawczo-rozwojowych przeprowadzonych w poniższym zakresie:
- opracowanie koncepcji świadczenia usługi informatycznej w zakresie zdalnej obsługi procesów sklepów internetowych obejmujących usługi płatności oraz dostawy nabytych towarów, w której proces zapłaty i zakupu usługi dostawy byłby maksymalnie zautomatyzowany, ograniczony niemal do jednego „kliknięcia”,
- opracowanie, na bazie przeprowadzonych badań i testów, kompletnej, optymalnej struktury systemu, a w szczególności optymalnych metod integracji z przedsiębiorstwami świadczącymi usługi rozliczania płatności w Internecie oraz dostawy przesyłek,
- opracowanie ww. specyfikacji technicznej i funkcjonalne systemu informatycznego umożlwiającego świadczenie ww usługi.
Oba ww dokumenty są w posiadaniu Zamawiającego, stanowią know-how przedsiębiorstwa i zostaną udostępnione jedynie Oferentom którzy podpiszą zobowiązanie do zachowania w tajemnicy uzyskanych informacji i niewykorzystywania ich w sposób, na który nie wyraził zgody Zamawiający. Zainteresowane podmioty po przesłaniu na adres e-mailowy marcin.karny@evl.pl prośby, otrzymają wzór umowy o zachowaniu poufności, po podpisaniu której otrzymają ww dokumenty.
Informujemy, iż w związku z poniesieniem przez Zamawiającego znaczących nakładów na opracowanie przedmiotowego know-how oraz założeń nowych systemów informatycznych, w tym specyfikacji technicznej i funkcjonalnej, Zamawiający zastrzega w umowie o zachowaniu poufności kary za każdorazowe naruszenie poufności w wysokości 1 000 000,00 PLN (1 miliona złotych), za każde takie naruszenie.
1. O realizację zamówienia może ubiegać się podmiot, który znajduje się w sytuacji ekonomicznej i finansowej zapewniającej wykonanie zamówienia.
2. O realizację zamówienia może ubiegać się wyłącznie podmiot posiadający doświadczenie w budowie rozbudowanych systemów informatycznych oraz aplikacji mobilnych tworzonych w technologii RWD (ang. Responsive Web Design), w tym tworzeniu aplikacji kompatybilnych z najpopularniejszymi systemami mobilnymi IOS i Adroid - doświadczenie w budowie min. 2 systemów informatycznych o wartości powyżej 1 mln zł (każdy z osobna) oraz w budowie min. 2 aplikacji mobilnych o wartości min. 500 tys. zł (każda z osobna). Przy ocenie dopuszczalności oferty będzie brane pod uwagę doświadczenie wskazane w przekazanej ofercie.
Podmiot składając ofertę w odpowiedzi na niniejsze zapytanie deklaruje również, iż lider zespołu projektowego posiadać będzie min. 5-letnie doświadczenie w programowaniu systemów informatycznych i aplikacji mobilnych. Oferent dowodzi spełnienia przedmiotowego kryterium zamieszczając odpowiednie informacje w ofercie i oświadcza, iż na prośbę Zamawiającego jest w stanie dostarczyć niezbędne dokumenty potwierdzające posiadane doświadczenie wyszczególnione w ofercie.
3. Z ubiegania się o udzielenie zamówienia wykluczeni zostaną oferenci powiązani z Zamawiającym osobowo lub kapitałowo, w związku z czym Oferent zobowiązany jest do dostarczenia wraz z ofertą oświadczenia stanowiącego załącznik nr 2 do niniejszego zapytania ofertowego.
Przez powiązania kapitałowe lub osobowe rozumie się wzajemne powiązania między Zamawiającym lub osobami upoważnionymi do zaciągania zobowiązań w imieniu Zamawiającego lub osobami wykonującymi w imieniu Zamawiającego czynności związane z przygotowaniem i przeprowadzeniem procedury wyboru wykonawcy a wykonawcą, polegające w szczególności na:
uczestniczeniu w spółce jako wspólnik spółki cywilnej lub spółki osobowej,
posiadaniu co najmniej 10 % udziałów lub akcji,
pełnieniu funkcji członka organu nadzorczego lub zarządzającego, prokurenta, pełnomocnika,
pozostawaniu w związku małżeńskim, w stosunku pokrewieństwa lub powinowactwa w linii prostej, pokrewieństwa drugiego stopnia lub powinowactwa drugiego stopnia w linii bocznej lub w stosunku przysposobienia, opieki lub kurateli.
- Otwarcie ofert nastąpi w siedzibie Zamawiającego (ul. Lubostroń 1, 30-383 Kraków) dnia 17 sierpnia 2016 roku o godz. 8:00.
- Oferta powinna być sporządzona w języku polskim
- Oferta powinna:
- zawierać datę sporządzenia
- zawierać adres Oferenta, nr NIP Oferenta
- zawierać imię i nazwisko oraz dane kontaktowe, telefon i adres e-mail, osoby wyznaczonej do kontaktów z Zamawiającym,
- być opatrzona podpisem osoby upoważnionej lub umocowanej do reprezentowania oferenta.
5. Oferta powinna zostać dostarczona w formie pisemnej (w zamkniętej kopercie): za pośrednictwem poczty, kuriera lub złożona osobiście na adres: ul. Lubostroń 1, 30-383 Kraków.
6. Za termin złożenia oferty uznaje się termin wpływu oferty do siedziby Zamawiającego podany powyżej.
7. Oferty złożone po terminie nie będą podlegały ocenie.
8. Oferent może przed terminem kończącym możliwość składania ofert zmienić, uzupełnić lub wycofać swoją ofertę.
9. Zamawiający dopuszcza możliwość porozumiewania się z Oferentami za pośrednictwem e-maila, faksu bądź telefonicznie – dane zostały umieszczone w nagłówku niniejszego zapytania.
10. Koszty związane z przygotowaniem oferty ponosi Oferent.
11. W toku badania i oceny ofert Zamawiający może żądać od Oferentów wyjaśnień dotyczących treści złożonych ofert.
12. W toku oceny ofert Zamawiający może podjąć negocjacje cenowe ze wszystkimi Oferentami na równych warunkach. Przebieg negocjacji będzie potwierdzony pismem w formie raportu z negocjacji.
13. W uzasadnionych przypadkach Zamawiający może przed upływem terminu składania ofert zmodyfikować treść zapytania ofertowego wyznaczając nowy termin składania ofert nie krótszy niż 40 dni. Wszelkie modyfikacje, uzupełnienia i ustalenia oraz zmiany, w tym zmiany terminów stają się integralną częścią zapytania ofertowego i będą wiążące przy składaniu ofert. Wszelkie prawa i zobowiązania Zamawiającego oraz Wykonawcy odnośnie wcześniej ustalonych terminów będą podlegały nowemu terminowi. W takim przypadku każdy z oferentów będzie miał prawo do nowelizacji już złożonej oferty i zostanie o tym fakcie poinformowany. Nie dotyczy to nieistotnych korekt w treści zapytania ofertowego.
Zamawiający dokona oceny ważnych ofert na podstawie poniższych kryteriów i ich wag:
Kryterium wyboru nr 1: Łączna cena netto za nieograniczone licencje do 3 systemów informatycznych
Sposób przyznawania punktów: Cena najtańszej spośród złożonych i prawidłowych pod względem formalnym oraz spełniających kryteria wejścia ofert zostanie podzielona przez cenę każdej oferty i pomnożona przez 100 punktów.
Waga: 60%
Kryterium wyboru nr 2: Długość gwarancji na pełną sprawność systemów informatycznych
Sposób przyznawania punktów: Ofercie proponującej najdłuższą gwarancję na pełną sprawność oferowanych systemów informatycznych przyznanych zostanie 100 pkt, kolejnej ofercie 20 pkt mniej, itd. aż do momentu gdy kolejnej i pozostałym ofertom przyznane zostanie 0 pkt. W przypadku braku informacji w przedmiotowym zakresie punkty nie zostaną przyznane.
Waga: 15%
Kryterium wyboru nr 3: Miesięczna ryczałtowa cena netto za usługi serwisowe świadczone w okresie 2 lat po zakończeniu okresu gwarancji
Sposób przyznawania punktów:
Ofercie o najkorzystniejszej miesięcznej cenie netto za usługi serwisowe świadczone po zakończeniu okresu gwarancji zostanie przyznanych 100 pkt, kolejnej ofercie 20 pkt więcej, itp. aż do momentu gdy kolejnej i pozostałym ofertom przyznane zostanie 0 pkt. W przypadku braku informacji w przedmiotowym zakresie punkty nie zostaną przyznane.
Waga: 10%
Kryterium wyboru nr 4: Termin płatności za odebrane systemy
Sposób przyznawania punktów:
Dostawcy proponującemu najdłuższy termin płatności za faktury obejmujące odbiór danego systemu lub jego części zostanie przyznanych 100 pkt, kolejnej ofercie 20 pkt więcej, itp. aż do momentu gdy kolejnej i pozostałym ofertom przyznane zostanie 0 pkt. W przypadku braku informacji w przedmiotowym zakresie punkty nie zostaną przyznane.
Waga: 15%
Oferty, spełniające wszystkie wymogi przedstawione w niniejszym zapytaniu ofertowym, zostaną uszeregowane od najmniej korzystnej do najbardziej korzystnej w ramach poszczególnych kryteriów wskazanych w pkt. IX. Następnie ofertom zostaną przyznane punkty zgodnie z metodologią przyznawania punktów opisaną również w pkt IX. Następnie, w zależności od danego kryterium, liczba zdobytych punktów zostanie przemnożona przez jego odpowiednią wagę procentową. W postępowaniu ofertowym zwycięży oferent, który zdobędzie najwyższą liczbę punktów zsumowanych w ramach wszystkich kryteriów. W razie równej liczby punktów zwycięży oferta o najniższej cenie.
W celu uniknięcia konfliktu interesów, zamówienie nie może być udzielone podmiotom powiązanym osobowo lub kapitałowo z zamawiającym. Przez powiązania kapitałowe lub osobowe rozumie się wzajemne powiązania między zamawiającym lub osobami upoważnionymi do zaciągania zobowiązań w imieniu zamawiającego lub osobami wykonującymi w imieniu zamawiającego czynności związane z przygotowaniem i przeprowadzeniem procedury wyboru wykonawcy a wykonawcą, polegające w szczególności na:
- uczestniczeniu w spółce jako wspólnik spółki cywilnej lub spółki osobowej,
- posiadaniu co najmniej 10% udziałów lub akcji,
- pełnieniu funkcji członka organu nadzorczego lub zarządzającego, prokurenta, pełnomocnika,
- pozostawaniu w związku małżeńskim, w stosunku pokrewieństwa lub powinowactwa w linii prostej, pokrewieństwa drugiego stopnia lub powinowactwa drugiego stopnia w linii bocznej lub w stosunku przysposobienia, opieki lub kurateli.
Zamawiający przewiduje możliwość dokonania zmian postanowień zawartej umowy w stosunku do treści oferty, na podstawie której dokonano wyboru Wykonawca, w następującym zakresie:
- Rozwiązania umowy, bez regresu odszkodowawczego ze strony Wykonawcy, jeżeli z Zamawiającym nie zostanie podpisana umowa o dofinansowanie z Urzędem Marszałkowskim Województwa Podkarpackiego (Zamawiający w dniu 31.03 br. złożył wniosek o dofinansowanie na przedmiotowy projekt i aktualnie czeka na rozstrzygnięcie konkursu) lub w przypadku gdy ww umowa o dofinansowanie zostanie podpisana i z jakichś przyczyn zostanie ona rozwiązana.
- Zmiany harmonogramu realizacji umowy wynikającej z postanowień umowy Zamawiającego z Urzędem Marszałkowskim Województwa Podkarpackiego, jeżeli umowa ta zostanie zmieniona po udzieleniu zamówienia.
- Zmiana istotnych postanowień umowy w stosunku do treści oferty jest dopuszczalna w sytuacji, gdy jest ona korzystna dla Zamawiającego i nie była możliwa do przewidzenia na etapie podpisywania umowy, a ponadto jej dokonanie wskazane jest w szczególności, gdy:
- nastąpi zmiana powszechnie obowiązujących przepisów prawa w zakresie mającym wpływ na realizację przedmiotu umowy;
- wynikną rozbieżności lub niejasności w umowie, których nie można usunąć w inny sposób, a zmiana będzie umożliwiać usunięcie rozbieżności i doprecyzowanie Umowy w celu jednoznacznej interpretacji jej postanowień przez Strony.