Izrada i implementacija modula za proširenje funkcionalnosti kod prodaje putem interneta i za lojaliti program u programskom paketu "Ticket Logic Pro"

3 Opis i specifikacija predmeta.docx OPIS I SPECIFIKACIJA PREDMETA, USLOVI ISPORUKE ILI IZVRŠENJA Izrada i implementacija modula za proširenje funkcionalnosti kod prodaje putem interneta i za lojaliti program u programskom paketu "Ticket Logic Pro" JN-u 15/26 1. Predmet nabavke Predmet nabavke je razvoj, implementacija, integracija i puštanje u rad novih funkcionalnosti postojećeg ticketing sistema, sa ciljem unapređenja prodaje karata, upravljanja popustima i vaučerima, korisničkih funkcionalnosti, monitoringa prolazaka, izveštavanja i automatizacije slanja izveštaja. Specifikacija obuhvata sledeće funkcionalne celine: Loyalty program i integracija sa sistemom DigitalnaKartica Online prodaja Upravljanje vaučerima i popustima Profil korisnika Monitoring i izveštavanje za kontrolore Realtime monitoring prolazaka i vrsta karata Podrška za donje senzore Automatsko slanje izveštaja putem e-maila Napredno filtriranje i tipiziranje izveštaja Poseban prikaz hotelskih karata na biletarnici Proširenje izveštaja prolazaka kroz kapije podacima o korisniku karte 2. Loyalty program i integracija sa DigitalnaKartica 2.1. Opis funkcionalnosti Sistem treba da podrži integraciju sa eksternim sistemom DigitalnaKartica, koji predstavlja zasebnu web i mobilnu aplikaciju sa administrativnim i korisničkim delom. DigitalnaKartica omogućava definisanje različitih pravila lojalnosti, popusta i vaučera, kao što su: ● ostvarivanje besplatne vožnje nakon određenog broja vožnji; ● ostvarivanje vaučera nakon dostizanja određenog iznosa potrošnje; ● drugi modeli nagrađivanja definisani u sistemu DigitalnaKartica. Korisnik DigitalnaKartica aplikacije poseduje korisnički identifikator u obliku QR koda. Ticketing sistem treba da omogući očitavanje tog QR koda i komunikaciju sa DigitalnaKartica sistemom radi provere korisnika, dostupnih pogodnosti i podataka relevantnih za obračun prodaje. Integracija treba da se realizuje putem API interfejsa DigitalnaKartica sistema. 2.2. Integracija korisničkog profila Ticketing sistem mora omogućiti skeniranje QR koda korisnika DigitalnaKartica aplikacije prilikom prodaje karte. Nakon očitavanja QR koda sistem treba da: ● identifikuje korisnika; ● putem API-ja proveri podatke dostupne u DigitalnaKartica sistemu; ● utvrdi da li korisnik ima pravo na određeni popust ili pogodnost; ● poveže kupovinu sa odgovarajućim korisničkim profilom; ● prosledi podatke o kupovini DigitalnaKartica sistemu kada je to predviđeno API specifikacijom. Podaci o kupovini treba da budu dostupni za potrebe statistike i praćenja aktivnosti korisnika u DigitalnaKartica sistemu. 2.3. Popusti i vaučeri Ticketing sistem mora omogućiti očitavanje QR koda vaučera. Vaučer treba da sadrži identifikacioni podatak na osnovu kojeg ticketing sistem može putem API-ja DigitalnaKartica sistema proveriti njegovu validnost i utvrditi iznos ili drugu pogodnost koju vaučer obezbeđuje. Proces treba da obuhvati: generisanje/slanje vaučera iz DigitalnaKartica sistema; očitavanje QR koda u ticketing sistemu; validaciju vaučera putem DigitalnaKartica API-ja; preuzimanje informacija o iznosu ili pogodnosti; obračun pogodnosti prilikom prodaje; evidentiranje iskorišćenog vaučera; prosleđivanje relevantnih podataka u sistem za fiskalizaciju; evidentiranje podataka o popustu/vaučeru u podacima o kupovini. 2.4. Evidencija popusta i vaučera u prodaji Podaci o ostvarenom popustu ili iskorišćenom vaučeru moraju biti sastavni deo podataka o prodaji. Sistem treba da evidentira najmanje: ● vrstu popusta ili vaučera; ● iznos popusta/vaučera; ● podatke potrebne za identifikaciju pogodnosti; ● originalni iznos prodaje; ● konačni iznos prodaje nakon primene pogodnosti. Podaci treba da budu dostupni za potrebe izveštavanja i statistike. 2.5. Izveštavanje U postojeće izveštaje o prodaji potrebno je uključiti informacije o popustima i vaučerima. Izveštaji treba da omoguće: ● prikaz podataka o popustu/vaučeru; ● filtriranje po relevantnim kriterijumima; ● izvoz podataka; ● pregled podataka u biletarnici i administrativnom delu sistema. 3. Online prodaja 3.1. Integracija sa Cloud Middleware sistemom Online prodaja mora biti integrisana sa Cloud Middleware sistemom. Potrebno je omogućiti odgovarajuću komunikaciju sa serverom za fiskalizaciju u skladu sa aktuelnom arhitekturom sistema. Rešenje mora podržati korišćenje odgovarajućeg test sertifikata za potrebe testiranja integracije sa sistemom DigiAccLogic. 3.2. Obrada podataka online kupovine Potrebno je proveriti i obezbediti ispravnost podataka koji se šalju prilikom online kupovine, uključujući podatke dobijene skeniranjem/unosom odgovarajućih podataka. Sistem mora omogućiti testiranje kompletnog procesa online kupovine, uključujući: ● kreiranje kupovine; ● komunikaciju sa Cloud Middleware sistemom; ● komunikaciju sa sistemom za fiskalizaciju; ● obradu odgovora; ● uspešan završetak kupovine. 3.3. E-mail potvrda kupovine Nakon uspešne online kupovine sistem treba da pošalje korisniku odgovarajuću potvrdu putem e-maila. Potvrda treba da obuhvati podatke o kupovini i fiskalnom računu, u skladu sa postojećim procesom sistema. Potrebno je obezbediti da promena načina komunikacije sa serverom za fiskalizaciju ne utiče na postojeći proces slanja e-mail potvrda. 4. Vaučeri i popusti 4.1. Upravljanje popustima u administrativnom delu Administrativni deo sistema mora omogućiti upravljanje popustima. Za svaki popust potrebno je omogućiti unos i prikaz najmanje sledećih podataka: ● naziv popusta; ● datum kreiranja; ● početak važenja; ● kraj važenja; ● status aktivan/neaktivan; ● opis; ● fiksni iznos popusta; ● procenat popusta. Za jedan popust može biti definisan ili fiksni novčani iznos ili procenat. Nije dozvoljeno istovremeno definisanje oba načina obračuna. 4.2. Aktiviranje i deaktiviranje popusta Sistem mora omogućiti deaktiviranje postojećeg popusta. Popust se ne sme fizički brisati iz sistema, zbog potrebe očuvanja istorijskih podataka o već realizovanim kupovinama. Operacija „brisanje“ treba da predstavlja deaktiviranje popusta, bez trajnog uklanjanja podataka iz baze. 4.3. Pretraga i filtriranje popusta Administrativni deo treba da omogući filtriranje popusta najmanje prema: ● datumu kreiranja od–do; ● periodu važenja od–do; ● statusu aktivan/neaktivan; ● drugim relevantnim kriterijumima. 4.4. Primena popusta na biletarnici Biletar mora imati mogućnost izbora popusta iz liste trenutno aktivnih i važećih popusta. Primeri popusta mogu biti: ● MasterCard; ● Visa; ● Wallet; ● drugi popusti definisani u administrativnom delu sistema. Nakon izbora popusta sistem automatski obračunava odgovarajući popust i formira konačnu cenu karte. Podaci o popustu moraju biti prosleđeni sistemu Teron radi odgovarajuće fiskalizacije. 4.5. Automatsko prepoznavanje popusta na osnovu platne kartice Sistem treba da podrži automatsko prepoznavanje prava na popust na osnovu korišćene platne kartice prilikom online kupovine. Za popust treba omogućiti definisanje da li se primenjuje na online prodaju. Ukoliko je definisan popust za određenu vrstu kartice, sistem treba da: 1. prepozna karticu na osnovu podataka dostupnih tokom procesa plaćanja; 2. putem odgovarajućeg API-ja utvrdi tip kartice; 3. utvrdi da li postoji odgovarajući popust; 4. obračuna popust; 5. izvrši plaćanje; 6. prosledi odgovarajuće podatke sistemu za fiskalizaciju. Integracija treba da podrži odgovarajući API sistema PaySpot. 4.6. Izveštavanje o popustima Svi relevantni izveštaji o prodaji treba da sadrže informacije o primenjenim popustima. Za online prodaju potrebno je omogućiti posebno razlikovanje prodaja realizovanih putem online kanala i prodaja kod kojih je primenjen popust. Podaci treba da budu dostupni kroz: ● kolone u izveštajima; ● filtere; ● eksport podataka. 5. Profil korisnika 5.1. Osnovni podaci korisnika Online aplikacija mora omogućiti korisniku kreiranje i održavanje korisničkog profila. Profil treba da omogući čuvanje podataka potrebnih za realizaciju budućih kupovina, najmanje: ● ime; ● prezime; ● adresa; ● broj telefona; ● podaci potrebni za plaćanje, u skladu sa mogućnostima payment providera. Podaci o bankovnoj kartici treba da se obrađuju i čuvaju u skladu sa mogućnostima i pravilima sistema PaySpot. 5.2. Istorija kupovina Korisnik mora imati mogućnost pregleda istorije svojih prethodnih kupovina. Istorija treba da sadrži podatke o prethodno realizovanim kupovinama i omogući pregled odgovarajućih ulaznica/karata. Potrebno je omogućiti opciju ponavljanja kupovine na osnovu prethodno realizovane kupovine, kada je to moguće. 5.3. Izmena podataka i lozinke Korisnik mora imati mogućnost: ● izmene ličnih podataka; ● promene lozinke; ● korišćenja funkcionalnosti za zaboravljenu lozinku. 5.4. Integracija sa DigitalnaKartica sistemom Online portal treba da omogući prikaz podataka o pogodnostima koje je korisnik ostvario putem DigitalnaKartica sistema, uključujući, kada API omogućava: ● vaučere; ● bodove; ● ostvarene pogodnosti; ● druge relevantne podatke korisničkog programa lojalnosti. Dostupnost i obim ovih podataka zavisi od API mogućnosti DigitalnaKartica sistema. 6. Monitoring i izveštaji za kontrolora 6.1. Uloga kontrolora Sistem mora podržati posebnu korisničku ulogu „Kontrolor“. Kontroloru treba omogućiti pristup relevantnim izveštajima i podacima potrebnim za praćenje broja gostiju i vožnji. Kontrolor ne sme imati pristup finansijskim podacima koji nisu neophodni za obavljanje njegove funkcije. 6.2. Izveštaj broja gostiju i vožnji Kontroloru treba omogućiti pregled broja gostiju i vožnji bez prikaza podataka o prihodima. U okviru izveštaja potrebno je onemogućiti prikaz kolona koje sadrže podatke o prihodima. 6.3. Pregled po stanicama Kontroloru treba omogućiti pregled broja gostiju i vožnji za određenu stanicu, odnosno grupu čitača. 7. Realtime monitoring prolazaka i vrsta karata 7.1. Opis funkcionalnosti Potrebno je omogućiti kontroloru praćenje prolazaka kroz rampe u realnom vremenu. Kontrolor ne mora biti fizički prisutan neposredno uz rampu/terminal, već treba da putem posebnog ekrana može da prati događaje koji se dešavaju na čitačima. Za svaki prolaz potrebno je prikazati: ● informaciju o tome da li je prolaz dozvoljen; ● informaciju o tome da li je karta važeća; ● razlog odbijanja kada karta nije važeća; ● vrstu karte; ● relevantne podatke o karti. 7.2. Organizacija prikaza Na posebnoj stranici za monitoring potrebno je omogućiti izbor grupe čitača. Nakon izbora grupe treba prikazati sve čitače/rampe koje pripadaju izabranoj grupi. Za svaki čitač potrebno je prikazati poslednji relevantni događaj prolaska. 7.3. Vizuelni prikaz statusa Status prolaska treba jasno vizuelno označiti. Najmanje je potrebno podržati: ● zeleno – dozvoljen/važeći prolaz; ● crveno – nedozvoljen prolaz/nevažeća karta; ● žuto – karta sa popustom ili drugo posebno stanje koje zahteva pažnju. Pored statusa potrebno je prikazati relevantne podatke o karti, uključujući vrstu karte i podatke koji se mogu dobiti putem postojećeg API-ja za proveru karte. 7.4. Realtime osvežavanje Monitoring mora biti ažuriran u realnom vremenu nakon očitavanja karte na čitaču. Sistem treba da omogući komunikaciju između događaja prolaska i monitoring interfejsa tako da se novi događaj automatski prikaže bez potrebe za ručnim osvežavanjem stranice. 8. Podrška za donje senzore Sistem treba proširiti podrškom za donje senzore na lokacijama na kojima se koriste. Funkcionalnost treba da omogući evidentiranje i obradu događaja koje generišu donji senzori i njihovo povezivanje sa postojećim procesom kontrole prolaska. Detaljna specifikacija komunikacije sa donjim senzorima i način integracije treba da bude definisana u okviru tehničke specifikacije uređaja i postojeće infrastrukture. 9. Automatsko slanje izveštaja putem e-maila 9.1. Upravljanje automatskim slanjem U administrativnom delu sistema potrebno je dodati funkcionalnost za konfiguraciju automatskog slanja izveštaja putem e-maila. Potrebno je omogućiti kreiranje konfiguracije automatskog slanja koja sadrži najmanje: ● naziv konfiguracije; ● listu primalaca u polju To; ● listu primalaca u polju CC; ● tipizirani izveštaj koji se šalje; ● period ponavljanja; ● vreme slanja kada je relevantno. 9.2. Periodično slanje Sistem treba da podrži najmanje sledeće periode: ● dnevno; ● nedeljno; ● mesečno. Za dnevno slanje potrebno je omogućiti definisanje tačnog vremena slanja. Primeri korišćenja: ● slanje izveštaja svakog dana u 16:00; ● slanje izveštaja na kraju svake nedelje; ● slanje izveštaja na kraju svakog meseca. 9.3. Dinamički period izveštaja Prilikom automatskog generisanja izveštaja potrebno je automatski definisati period podataka na osnovu pravila slanja. Za dnevni izveštaj treba koristiti podatke za odgovarajući dan. Za nedeljni izveštaj treba koristiti podatke za odgovarajuću nedelju. Za mesečni izveštaj treba koristiti podatke za odgovarajući mesec. Ostali kriterijumi definisani za tipizirani izveštaj treba da se primenjuju prilikom automatskog generisanja izveštaja. 10. Tipiziranje izveštaja i višestruki izbor kriterijuma 10.1. Višestruki izbor vrednosti Postojeće izveštaje potrebno je proširiti tako da omogućavaju izbor više vrednosti istog kriterijuma. Primeri: ● izbor više vrsta karata; ● izbor više biletara; ● izbor više stanica; ● izbor više drugih vrednosti za koje trenutno postoji izbor samo jedne vrednosti. Kod odgovarajućih padajućih lista potrebno je omogućiti višestruki izbor, na primer korišćenjem checkbox elemenata. 10.2. Čuvanje kriterijuma Višestruko izabrani kriterijumi moraju biti podržani i kod tipiziranih izveštaja. Prilikom čuvanja tipiziranog izveštaja potrebno je sačuvati sve izabrane vrednosti kriterijuma kako bi se iste primenjivale prilikom ponovnog pokretanja ili automatskog slanja izveštaja. 11. Poseban tab za hotelske karte na biletarnici 11.1. Obeležavanje hotelskih karata U administrativnom delu sistema, kod aktuelnog cenovnika, potrebno je omogućiti označavanje karte kao hotelske. Za kartu treba omogućiti najmanje sledeće kategorije/oznake: ● omiljena; ● web; ● hotelska. 11.2. Prikaz hotelskih karata Na biletarnici je potrebno dodati poseban tab „Hotelske karte“. Tab treba da omogućava biletaru brz i jednostavan pregled i izbor karata koje su označene kao hotelske. Hotelske karte treba da se ponašaju na isti način kao postojeće kategorije karata koje imaju poseban prikaz na biletarnici. 12. Proširenje izveštaja prolazaka kroz kapije 12.1. Podaci o korisniku karte Izveštaj prolazaka kroz kapije potrebno je proširiti informacijama o korisniku karte, kada takvi podaci postoje u sistemu. Izveštaj treba da sadrži: ● ime korisnika; ● prezime korisnika; ● podatke o prolasku; ● podatke o kapiji/čitaču; ● podatke o karti. Ime i prezime treba prikazati za one kategorije karata za koje postoji mogućnost povezivanja RFID/kartičnog identifikatora sa korisnikom, uključujući, gde je primenljivo: ● mesečne karte; ● VIP karte; ● karte fizičkih lica; ● druge kategorije kod kojih postoje podaci o vlasniku karte. 12.2. Povezivanje podataka Potrebno je obezbediti povezivanje evidencije prolaska kroz kapiju sa podacima o vlasniku odgovarajuće RFID kartice. Ukoliko se podaci o korisniku nalaze u drugoj tabeli ili sistemu, potrebno je obezbediti odgovarajuće povezivanje podataka prilikom generisanja izveštaja. 13. Integracije Implementacija zahteva obuhvata, gde je primenljivo, integraciju sa postojećim i eksternim sistemima, uključujući: ● DigitalnaKartica; ● Teron; ● PaySpot; ● Cloud Middleware; ● DigiAccLogic; ● postojeći sistem za kontrolu prolazaka; ● postojeći sistem evidencije događaja; ● postojeće servise za slanje e-mail poruka. Za sve integracije ponuđač je dužan da obezbedi odgovarajuću komunikaciju, obradu grešaka i evidentiranje rezultata komunikacije u skladu sa postojećom arhitekturom sistema i dostupnom API dokumentacijom. 14. Izveštavanje i eksport podataka Sve funkcionalnosti koje uvode nove podatke relevantne za prodaju, popuste, vaučere, online prodaju ili korisnike moraju biti adekvatno uključene u postojeće izveštaje sistema. Gde je primenljivo, potrebno je omogućiti: ● prikaz novih podataka u tabelama; ● filtriranje; ● sortiranje; ● kombinovanje više kriterijuma; ● eksport podataka; ● korišćenje podataka u tipiziranim izveštajima; ● korišćenje podataka u automatskom slanju izveštaja. 15. Opšti zahtevi za implementaciju Ponuđeno rešenje mora biti implementirano tako da nove funkcionalnosti budu integrisane sa postojećim funkcionalnostima sistema i da ne narušavaju postojeće procese prodaje, fiskalizacije, kontrole prolazaka i izveštavanja. Ponuđač treba da obezbedi: ● implementaciju svih navedenih funkcionalnih zahteva; ● integraciju sa navedenim eksternim sistemima; ● testiranje implementiranih funkcionalnosti; ● integraciono testiranje; ● testiranje postojećih funkcionalnosti koje su obuhvaćene promenama; ● otklanjanje uočenih grešaka; ● pripremu sistema za produkciono puštanje. Za funkcionalnosti koje zavise od API-ja eksternih sistema, implementacija mora biti usklađena sa dostupnom API dokumentacijom i tehničkim mogućnostima eksternog sistema. 4 Kriterijumi za dodelu ugovora.docx KRITERIJUMI ZA DODELU UGOVORA, JN-u 15/26 Za utvrđivanje najpovoljnije ponude koristiće se sledeći kriterijumi: 1. Cena2. Rok isporuke i izvršenja CENA 80 bodova ROK ISPORUKE I IZVRŠENJA 20 bodova I CENA Najveći mogući broj bodova kod ovog kriterijuma je 80.Ponuđač koji ponudi najnižu ukupnu ponuđenu cenu dobija 80 bodova (B1 = 80). Ponude ostalih ponuđača se računaju prema sledećoj formuli: B1 = 80 x C min / Cp Gde je: B1 – broj bodovaC min – najniža ponuđena cenaCp – ponuđena cena konkretnog ponuđača II ROK ISPORUKE I IZVRŠENJA Najveći mogući broj bodova kod ovog kriterijuma je 20.Ponuđač koji ponudi najkraći rok isporuke i izvršenja dobija 20 bodova (B2 = 20). Ponude ostalih ponuđača se računaju prema sledećoj formuli: B2 = 20 x I min / Ip Gde je: B2 – broj bodovaI min – najkraći rok isporuke i izvršenjaIp – rok isporuke i izvršenja konkretnog ponuđača UKUPAN BROJ BODOVA ZA SVAKOG PONUĐAČA: B = B1 + B2 Napomena: Ukoliko dve ili više ponuda imaju isti broj bodova, najpovoljnija biće izabrana ponuda onog ponuđača koji ponudi nižu cenu za izvršenje usluga. *Napomena: Rangiranje se vrši u opadajućem nizu, tako da je na prvom mestu rang liste ponuda sa najvećim brojem bodova, a na poslednjem ponuda sa najmanjim brojem bodova **Napomena: Prilikom izračunavanja broja bodova zaokruživanje se vrši na dve decimale 5 Obrazac strukture ponuđene cene.docx OBRAZAC STRUKTURE CENE Izrada i implementacija modula za proširenje funkcionalnosti kod prodaje putem interneta i za lojaliti program u programskom paketu „Ticket Logic Pro“ JN-u 15/26 R.br. Predmet javne nabavke Cena ukupno bez pdv-a Cena ukupno sa pdv-om 1 Izrada i implementacija modula za proširenje funkcionalnosti kod prodaje putem interneta i za lojaliti program u programskom paketu „Ticket Logic Pro“, u svemu prema specifikaciji predmeta nabavke 2. Rok isporuke i izvršenja: _____ dana od dana zaključenja Ugovora. Uputstvo: U tabeli popuniti vrednost bez i sa pdv-a, Popuniti koliko je najviše dana potrebno za isporuku i izvršenje usluga. Napomena: plaćanje će se vršiti iz delova, u roku od 45 dana od dana dostavljanja fakture. MESTO I DATUM M.P. POTPIS OVLAŠĆENOG LICA _________________ ____________________________ 6 Model ugovora.docx REPUBLIKA SRBIJA JP „GOLD GONDOLA ZLATIBOR“ Broj nabavke: JN-u 15/26 Broj ugovora: Datum: MODEL UGOVORA - Izrada i implementacija modula za proširenje funkcionalnosti kod prodaje putem interneta i za lojaliti program u programskom paketu "Ticket Logic Pro"- ZAKLJUČEN IZMEĐU: 1. JP „Gold gondola Zlatibor“, Ulica sportova bb, 31315 Zlatibor, matični broj 21162035, PIB 109326994, broj računa: 200-3577420101898-62, koje zastupa direktorka Bojana Božanić (u daljem tekstu: Naručilac) i 2. ____________, ulica __________, pošt.broj i mesto _____________, matični broj: __________, PIB: _________, broj računa: __________, koga zastupa __________(u daljem tekstu: Izvršilac) (u daljem tekstu: Ugovorne strane) Uvodne odredbe * Naručilac je, na osnovu odluke o pokretanju postupka javne nabavke broj 02-191/26 od dana 08.10.2026. godine sproveo otvoreni postupak javne nabavke broj JN-u 15/26 za nabavku usluga – Izrada i implementacija modula za proširenje funkcionalnosti kod prodaje putem interneta i za lojaliti program u programskom paketu "Ticket Logic Pro", za potrebe JP „Gold gondola Zlatibor“; * Izvršilac je dana _________. godine dostavio ponudu broj ________, zavedenu kod Naručioca pod brojem __________ dana __________. godine, koja se nalazi u prilogu ovog ugovora i njegov je sastavni deo; * Ponuda Izvršioca u potpunosti odgovara zahtevima Naručioca iz konkursne dokumentacije; * Naručilac je, na osnovu člana 146. Zakona doneo Odluku o dodeli ugovora za nabavku usluga izrade i implementacije modula za proširenje funkcionalnosti kod prodaje putem interneta i za lojaliti program u programskom paketu "Ticket Logic Pro", i kao najpovoljniju izabrao ponudu _______________________________. Član 1. Predmet nabavke je razvoj, implementacija, integracija i puštanje u rad novih funkcionalnosti postojećeg ticketing sistema, sa ciljem unapređenja prodaje karata, upravljanja popustima i vaučerima, korisničkih funkcionalnosti, monitoringa prolazaka, izveštavanja i automatizacije slanja izveštaja. Specifikacija obuhvata sledeće funkcionalne celine: Loyalty program i integracija sa sistemom DigitalnaKartica Online prodaja Upravljanje vaučerima i popustima Profil korisnika Monitoring i izveštavanje za kontrolore Realtime monitoring prolazaka i vrsta karata Podrška za donje senzore Automatsko slanje izveštaja putem e-maila Napredno filtriranje i tipiziranje izveštaja Poseban prikaz hotelskih karata na biletarnici Proširenje izveštaja prolazaka kroz kapije podacima o korisniku karte, detaljno opisane u specifikaciji predmeta nabavke Naručioca. Član 2. Ukupna vrednost ugovora za izvršenje usluga iz člana 1. ovog Ugovora iznosi _________ bez PDV-a, odnosno ________ sa PDV-om. Član 3. Rok za isporuku i izvršenje usluga iz člana 1. i specifikacije predmeta nabavke iznosi _____ dana od dana zaključenja Ugovora. Član 4. Iznos iz člana 2. Ugovora iznos biće plaćen iz delova, najkasnije u roku od 45 dana od dana dostavljanja faktura. Član 5. Ovaj Ugovor stupa na snagu danom zaključenja i važi do izvršenja svih ugovornih obaveza. Član 6. Ovaj ugovor se može izmeniti ili dopuniti samo u pisanoj formi - zaključivanjem aneksa ugovora uz poštovanje Zakona o javnim nabavkama. Član 7. Pravo na raskid Ugovora zadržavaju obe ugovorne strane u slučaju da jedna od ugovornih strana ne ispunjava svoje ugovorene obaveze, s tim što su obavezne da o svojoj nameri u pisanoj formi obaveste drugu ugovornu stranu najmanje u roku od 30 (trideset) dana unapred. Član 8. Ugovorne strane će uložiti maksimalne napore da sporazumno, u duhu dobrih poslovnih odnosa i uzajamnog poverenja reše sve eventualne sporove koji se pojave u vezi sa ovim Ugovorom ili njegovom interpretacijom. U slučaju da se spor između ugovornih strana u vezi sa ovim Ugovorom ne može sporazumno rešiti, isti će se poveriti na rešavanje stvarno nadležnom sudu u Užicu. Član 9. Za sve što nije ovim ugovorom predviđeno, primenjivaće se Zakon o javnim nabavkama, Zakon o obligacionim odnosima, kao i drugi propisi koji regulišu ovu vrstu posla. Član 10. Ugovorne strane saglasno konstatuju da će međusobnu komunikaciju obavljati putem telefona, lično i putem elektronske pošte i to: -Za Naručioca je kontakt za komunikaciju sa Izvršiocem Ivan Radivojević, e-mail: ivan.radivojevic@goldgondola.rs, mob: 064/87-021-81, -Za Izvršioca je osoba za kontakt za komunikaciju sa Naručiocem ___________________, e-mail: _______________, mob: ________________. Član 11. Ovaj ugovor sačinjen je u 4 (četiri) istovetna primerka, po 2 primerka za svaku ugovornu stranu. Za IZVRŠIOCA Za NARUČIOCA ______________________ ________________________ Direktorka Bojana Božanić NAPOMENE: Ponuđač nije dužan da uz ponudu dostavi potpisan model ugovora, podnošenjem ponude smatra se da je pristao na uslove iz modela ugovora.