Израда и имплементација модула за проширење функционалности код продаје путем интернета и за лојалити програм у програмском пакету "Тицкет Логиц Про"

3 Opis i specifikacija predmeta.docx ОПИС И СПЕЦИФИКАЦИЈА ПРЕДМЕТА, УСЛОВИ ИСПОРУКЕ ИЛИ ИЗВРШЕЊА Израда и имплементација модула за проширење функционалности код продаје путем интернета и за лојалити програм у програмском пакету "Ticket Logic Pro" ЈН-у 15/26 1. Предмет набавке Предмет набавке је развој, имплементација, интеграција и пуштање у рад нових функционалности постојећег тицкетинг система, са циљем унапређења продаје карата, управљања попустима и ваучерима, корисничких функционалности, мониторинга пролазака, извештавања и аутоматизације слања извештаја. Спецификација обухвата следеће функционалне целине: Loyalty програм и интеграција са системом ДигиталнаКартица Онлине продаја Управљање ваучерима и попустима Профил корисника Мониторинг и извештавање за контролоре Realtime мониторинг пролазака и врста карата Подршка за доње сензоре Аутоматско слање извештаја путем e-mailа Напредно филтрирање и типизирање извештаја Посебан приказ хотелских карата на билетарници Проширење извештаја пролазака кроз капије подацима о кориснику карте 2. Loyalty програм и интеграција са ДигиталнаКартица 2.1. Опис функционалности Систем треба да подржи интеграцију са екстерним системом ДигиталнаКартица, који представља засебну weб и мобилну апликацију са административним и корисничким делом. ДигиталнаКартица омогућава дефинисање различитих правила лојалности, попуста и ваучера, као што су: ● остваривање бесплатне вожње након одређеног броја вожњи; ● остваривање ваучера након достизања одређеног износа потрошње; ● други модели награђивања дефинисани у систему ДигиталнаКартица. Корисник ДигиталнаКартица апликације поседује кориснички идентификатор у облику QR кода. Тицкетинг систем треба да омогући очитавање тог QR кода и комуникацију са ДигиталнаКартица системом ради провере корисника, доступних погодности и података релевантних за обрачун продаје. Интеграција треба да се реализује путем АПИ интерфејса ДигиталнаКартица система. 2.2. Интеграција корисничког профила Тицкетинг систем мора омогућити скенирање QR кода корисника ДигиталнаКартица апликације приликом продаје карте. Након очитавања QR кода систем треба да: ● идентификује корисника; ● путем АПИ-ја провери податке доступне у ДигиталнаКартица систему; ● утврди да ли корисник има право на одређени попуст или погодност; ● повеже куповину са одговарајућим корисничким профилом; ● проследи податке о куповини ДигиталнаКартица систему када је то предвиђено АПИ спецификацијом. Подаци о куповини треба да буду доступни за потребе статистике и праћења активности корисника у ДигиталнаКартица систему. 2.3. Попусти и ваучери Тицкетинг систем мора омогућити очитавање QR кода ваучера. Ваучер треба да садржи идентификациони податак на основу којег тицкетинг систем може путем АПИ-ја ДигиталнаКартица система проверити његову валидност и утврдити износ или другу погодност коју ваучер обезбеђује. Процес треба да обухвати: генерисање/слање ваучера из ДигиталнаКартица система; очитавање QR кода у тицкетинг систему; валидацију ваучера путем ДигиталнаКартица АПИ-ја; преузимање информација о износу или погодности; обрачун погодности приликом продаје; евидентирање искоришћеног ваучера; прослеђивање релевантних података у систем за фискализацију; евидентирање података о попусту/ваучеру у подацима о куповини. 2.4. Евиденција попуста и ваучера у продаји Подаци о оствареном попусту или искоришћеном ваучеру морају бити саставни део података о продаји. Систем треба да евидентира најмање: ● врсту попуста или ваучера; ● износ попуста/ваучера; ● податке потребне за идентификацију погодности; ● оригинални износ продаје; ● коначни износ продаје након примене погодности. Подаци треба да буду доступни за потребе извештавања и статистике. 2.5. Извештавање У постојеће извештаје о продаји потребно је укључити информације о попустима и ваучерима. Извештаји треба да омогуће: ● приказ података о попусту/ваучеру; ● филтрирање по релевантним критеријумима; ● извоз података; ● преглед података у билетарници и административном делу система. 3. Онлине продаја 3.1. Интеграција са Cloud Middlewarе системом Онлине продаја мора бити интегрисана са Cloud Middlewarе системом. Потребно је омогућити одговарајућу комуникацију са сервером за фискализацију у складу са актуелном архитектуром система. Решење мора подржати коришћење одговарајућег тест сертификата за потребе тестирања интеграције са системом DigiAccLogic. 3.2. Обрада података онлине куповине Потребно је проверити и обезбедити исправност података који се шаљу приликом онлине куповине, укључујући податке добијене скенирањем/уносом одговарајућих података. Систем мора омогућити тестирање комплетног процеса онлине куповине, укључујући: ● креирање куповине; ● комуникацију са Цлоуд Middlewarе системом; ● комуникацију са системом за фискализацију; ● обраду одговора; ● успешан завршетак куповине. 3.3. Е-маил потврда куповине Након успешне онлине куповине систем треба да пошаље кориснику одговарајућу потврду путем e-maila. Потврда треба да обухвати податке о куповини и фискалном рачуну, у складу са постојећим процесом система. Потребно је обезбедити да промена начина комуникације са сервером за фискализацију не утиче на постојећи процес слања е-маил потврда. 4. Ваучери и попусти 4.1. Управљање попустима у административном делу Административни део система мора омогућити управљање попустима. За сваки попуст потребно је омогућити унос и приказ најмање следећих података: ● назив попуста; ● датум креирања; ● почетак важења; ● крај важења; ● статус активан/неактиван; ● опис; ● фиксни износ попуста; ● проценат попуста. За један попуст може бити дефинисан или фиксни новчани износ или проценат. Није дозвољено истовремено дефинисање оба начина обрачуна. 4.2. Активирање и деактивирање попуста Систем мора омогућити деактивирање постојећег попуста. Попуст се не сме физички брисати из система, због потребе очувања историјских података о већ реализованим куповинама. Операција „брисање“ треба да представља деактивирање попуста, без трајног уклањања података из базе. 4.3. Претрага и филтрирање попуста Административни део треба да омогући филтрирање попуста најмање према: ● датуму креирања од–до; ● периоду важења од–до; ● статусу активан/неактиван; ● другим релевантним критеријумима. 4.4. Примена попуста на билетарници Билетар мора имати могућност избора попуста из листе тренутно активних и важећих попуста. Примери попуста могу бити: ● MasterCard; ● Виса; ● Wallet; ● други попусти дефинисани у административном делу система. Након избора попуста систем аутоматски обрачунава одговарајући попуст и формира коначну цену карте. Подаци о попусту морају бити прослеђени систему Терон ради одговарајуће фискализације. 4.5. Аутоматско препознавање попуста на основу платне картице Систем треба да подржи аутоматско препознавање права на попуст на основу коришћене платне картице приликом онлине куповине. За попуст треба омогућити дефинисање да ли се примењује на онлине продају. Уколико је дефинисан попуст за одређену врсту картице, систем треба да: 1. препозна картицу на основу података доступних током процеса плаћања; 2. путем одговарајућег АПИ-ја утврди тип картице; 3. утврди да ли постоји одговарајући попуст; 4. обрачуна попуст; 5. изврши плаћање; 6. проследи одговарајуће податке систему за фискализацију. Интеграција треба да подржи одговарајући АПИ система PaySpot. 4.6. Извештавање о попустима Сви релевантни извештаји о продаји треба да садрже информације о примењеним попустима. За онлине продају потребно је омогућити посебно разликовање продаја реализованих путем онлине канала и продаја код којих је примењен попуст. Подаци треба да буду доступни кроз: ● колоне у извештајима; ● филтере; ● експорт података. 5. Профил корисника 5.1. Основни подаци корисника Онлине апликација мора омогућити кориснику креирање и одржавање корисничког профила. Профил треба да омогући чување података потребних за реализацију будућих куповина, најмање: ● име; ● презиме; ● адреса; ● број телефона; ● подаци потребни за плаћање, у складу са могућностима paymenт провидера. Подаци о банковној картици треба да се обрађују и чувају у складу са могућностима и правилима система PaySpot. 5.2. Историја куповина Корисник мора имати могућност прегледа историје својих претходних куповина. Историја треба да садржи податке о претходно реализованим куповинама и омогући преглед одговарајућих улазница/карата. Потребно је омогућити опцију понављања куповине на основу претходно реализоване куповине, када је то могуће. 5.3. Измена података и лозинке Корисник мора имати могућност: ● измене личних података; ● промене лозинке; ● коришћења функционалности за заборављену лозинку. 5.4. Интеграција са ДигиталнаКартица системом Онлине портал треба да омогући приказ података о погодностима које је корисник остварио путем ДигиталнаКартица система, укључујући, када АПИ омогућава: ● ваучере; ● бодове; ● остварене погодности; ● друге релевантне податке корисничког програма лојалности. Доступност и обим ових података зависи од АПИ могућности ДигиталнаКартица система. 6. Мониторинг и извештаји за контролора 6.1. Улога контролора Систем мора подржати посебну корисничку улогу „Контролор“. Контролору треба омогућити приступ релевантним извештајима и подацима потребним за праћење броја гостију и вожњи. Контролор не сме имати приступ финансијским подацима који нису неопходни за обављање његове функције. 6.2. Извештај броја гостију и вожњи Контролору треба омогућити преглед броја гостију и вожњи без приказа података о приходима. У оквиру извештаја потребно је онемогућити приказ колона које садрже податке о приходима. 6.3. Преглед по станицама Контролору треба омогућити преглед броја гостију и вожњи за одређену станицу, односно групу читача. 7. Realtime мониторинг пролазака и врста карата 7.1. Опис функционалности Потребно је омогућити контролору праћење пролазака кроз рампе у реалном времену. Контролор не мора бити физички присутан непосредно уз рампу/терминал, већ треба да путем посебног екрана може да прати догађаје који се дешавају на читачима. За сваки пролаз потребно је приказати: ● информацију о томе да ли је пролаз дозвољен; ● информацију о томе да ли је карта важећа; ● разлог одбијања када карта није важећа; ● врсту карте; ● релевантне податке о карти. 7.2. Организација приказа На посебној страници за мониторинг потребно је омогућити избор групе читача. Након избора групе треба приказати све читаче/рампе које припадају изабраној групи. За сваки читач потребно је приказати последњи релевантни догађај проласка. 7.3. Визуелни приказ статуса Статус проласка треба јасно визуелно означити. Најмање је потребно подржати: ● зелено – дозвољен/важећи пролаз; ● црвено – недозвољен пролаз/неважећа карта; ● жуто – карта са попустом или друго посебно стање које захтева пажњу. Поред статуса потребно је приказати релевантне податке о карти, укључујући врсту карте и податке који се могу добити путем постојећег АПИ-ја за проверу карте. 7.4. Реалтиме освежавање Мониторинг мора бити ажуриран у реалном времену након очитавања карте на читачу. Систем треба да омогући комуникацију између догађаја проласка и мониторинг интерфејса тако да се нови догађај аутоматски прикаже без потребе за ручним освежавањем странице. 8. Подршка за доње сензоре Систем треба проширити подршком за доње сензоре на локацијама на којима се користе. Функционалност треба да омогући евидентирање и обраду догађаја које генеришу доњи сензори и њихово повезивање са постојећим процесом контроле проласка. Детаљна спецификација комуникације са доњим сензорима и начин интеграције треба да буде дефинисана у оквиру техничке спецификације уређаја и постојеће инфраструктуре. 9. Аутоматско слање извештаја путем e-mailа 9.1. Управљање аутоматским слањем У административном делу система потребно је додати функционалност за конфигурацију аутоматског слања извештаја путем e-maila. Потребно је омогућити креирање конфигурације аутоматског слања која садржи најмање: ● назив конфигурације; ● листу прималаца у пољу То; ● листу прималаца у пољу CC; ● типизирани извештај који се шаље; ● период понављања; ● време слања када је релевантно. 9.2. Периодично слање Систем треба да подржи најмање следеће периоде: ● дневно; ● недељно; ● месечно. За дневно слање потребно је омогућити дефинисање тачног времена слања. Примери коришћења: ● слање извештаја сваког дана у 16:00; ● слање извештаја на крају сваке недеље; ● слање извештаја на крају сваког месеца. 9.3. Динамички период извештаја Приликом аутоматског генерисања извештаја потребно је аутоматски дефинисати период података на основу правила слања. За дневни извештај треба користити податке за одговарајући дан. За недељни извештај треба користити податке за одговарајућу недељу. За месечни извештај треба користити податке за одговарајући месец. Остали критеријуми дефинисани за типизирани извештај треба да се примењују приликом аутоматског генерисања извештаја. 10. Типизирање извештаја и вишеструки избор критеријума 10.1. Вишеструки избор вредности Постојеће извештаје потребно је проширити тако да омогућавају избор више вредности истог критеријума. Примери: ● избор више врста карата; ● избор више билетара; ● избор више станица; ● избор више других вредности за које тренутно постоји избор само једне вредности. Код одговарајућих падајућих листа потребно је омогућити вишеструки избор, на пример коришћењем checkbox елемената. 10.2. Чување критеријума Вишеструко изабрани критеријуми морају бити подржани и код типизираних извештаја. Приликом чувања типизираног извештаја потребно је сачувати све изабране вредности критеријума како би се исте примењивале приликом поновног покретања или аутоматског слања извештаја. 11. Посебан таб за хотелске карте на билетарници 11.1. Обележавање хотелских карата У административном делу система, код актуелног ценовника, потребно је омогућити означавање карте као хотелске. За карту треба омогућити најмање следеће категорије/ознаке: ● омиљена; ● web; ● хотелска. 11.2. Приказ хотелских карата На билетарници је потребно додати посебан таб „Хотелске карте“. Таб треба да омогућава билетару брз и једноставан преглед и избор карата које су означене као хотелске. Хотелске карте треба да се понашају на исти начин као постојеће категорије карата које имају посебан приказ на билетарници. 12. Проширење извештаја пролазака кроз капије 12.1. Подаци о кориснику карте Извештај пролазака кроз капије потребно је проширити информацијама о кориснику карте, када такви подаци постоје у систему. Извештај треба да садржи: ● име корисника; ● презиме корисника; ● податке о проласку; ● податке о капији/читачу; ● податке о карти. Име и презиме треба приказати за оне категорије карата за које постоји могућност повезивања РФИД/картичног идентификатора са корисником, укључујући, где је применљиво: ● месечне карте; ● ВИП карте; ● карте физичких лица; ● друге категорије код којих постоје подаци о власнику карте. 12.2. Повезивање података Потребно је обезбедити повезивање евиденције проласка кроз капију са подацима о власнику одговарајуће РФИД картице. Уколико се подаци о кориснику налазе у другој табели или систему, потребно је обезбедити одговарајуће повезивање података приликом генерисања извештаја. 13. Интеграције Имплементација захтева обухвата, где је применљиво, интеграцију са постојећим и екстерним системима, укључујући: ● ДигиталнаКартица; ● Терон; ● PaySpot; ● Cloud Middleware; ● DigiAccLogic; ● постојећи систем за контролу пролазака; ● постојећи систем евиденције догађаја; ● постојеће сервисе за слање е-маил порука. За све интеграције понуђач је дужан да обезбеди одговарајућу комуникацију, обраду грешака и евидентирање резултата комуникације у складу са постојећом архитектуром система и доступном АПИ документацијом. 14. Извештавање и експорт података Све функционалности које уводе нове податке релевантне за продају, попусте, ваучере, онлине продају или кориснике морају бити адекватно укључене у постојеће извештаје система. Где је применљиво, потребно је омогућити: ● приказ нових података у табелама; ● филтрирање; ● сортирање; ● комбиновање више критеријума; ● експорт података; ● коришћење података у типизираним извештајима; ● коришћење података у аутоматском слању извештаја. 15. Општи захтеви за имплементацију Понуђено решење мора бити имплементирано тако да нове функционалности буду интегрисане са постојећим функционалностима система и да не нарушавају постојеће процесе продаје, фискализације, контроле пролазака и извештавања. Понуђач треба да обезбеди: ● имплементацију свих наведених функционалних захтева; ● интеграцију са наведеним екстерним системима; ● тестирање имплементираних функционалности; ● интеграционо тестирање; ● тестирање постојећих функционалности које су обухваћене променама; ● отклањање уочених грешака; ● припрему система за продукционо пуштање. За функционалности које зависе од АПИ-ја екстерних система, имплементација мора бити усклађена са доступном АПИ документацијом и техничким могућностима екстерног система. 4 Kriterijumi za dodelu ugovora.docx КРИТЕРИЈУМИ ЗА ДОДЕЛУ УГОВОРА, ЈН-у 15/26 За утврђивање најповољније понуде користиће се следећи критеријуми: 1. Цена2. Рок испоруке и извршења ЦЕНА 80 бодова РОК ИСПОРУКЕ И ИЗВРШЕЊА 20 бодова I ЦЕНА Највећи могући број бодова код овог критеријума је 80.Понуђач који понуди најнижу укупну понуђену цену добија 80 бодова (B1 = 80). Понуде осталих понуђача се рачунају према следећој формули: B1 = 80 x C min / Cp Где је: B1 – број бодоваC min – најнижа понуђена ценаCp – понуђена цена конкретног понуђача II РОК ИСПОРУКЕ И ИЗВРШЕЊА Највећи могући број бодова код овог критеријума је 20.Понуђач који понуди најкраћи рок испоруке и извршења добија 20 бодова (B2 = 20). Понуде осталих понуђача се рачунају према следећој формули: B2 = 20 x I min / Ip Где је: B2 – број бодоваI min – најкраћи рок испоруке и извршењаIp – рок испоруке и извршења конкретног понуђача УКУПАН БРОЈ БОДОВА ЗА СВАКОГ ПОНУЂАЧА: B = B1 + B2 Напомена: Уколико две или више понуда имају исти број бодова, најповољнија биће изабрана понуда оног понуђача који понуди нижу цену за извршење услуга. *Напомена: Рангирање се врши у опадајућем низу, тако да је на првом месту ранг листе понуда са највећим бројем бодова, а на последњем понуда са најмањим бројем бодова **Напомена: Приликом израчунавања броја бодова заокруживање се врши на две децимале 5 Obrazac strukture ponuđene cene.docx ОБРАЗАЦ СТРУКТУРЕ ЦЕНЕ Израда и имплементација модула за проширење функционалности код продаје путем интернета и за лојалити програм у програмском пакету „Ticket Logic Pro“ ЈН-у 15/26 Р.бр. Предмет јавне набавке Цена укупно без пдв-а Цена укупно са пдв-ом 1 Израда и имплементација модула за проширење функционалности код продаје путем интернета и за лојалити програм у програмском пакету „Ticket Logic Pro“, у свему према спецификацији предмета набавке 2. Рок испоруке и извршења: _____ дана од дана закључења Уговора. Упутство: У табели попунити вредност без и са пдв-а, Попунити колико је највише дана потребно за испоруку и извршење услуга. Напомена: плаћање ће се вршити из делова, у року од 45 дана од дана достављања фактуре. МЕСТО И ДАТУМ М.П. ПОТПИС ОВЛАШЋЕНОГ ЛИЦА _________________ ____________________________ 6 Model ugovora.docx РЕПУБЛИКА СРБИЈА ЈП „ГОЛД ГОНДОЛА ЗЛАТИБОР“ Број набавке: ЈН-у 15/26 Број уговора: Датум: МОДЕЛ УГОВОРА - Израда и имплементација модула за проширење функционалности код продаје путем интернета и за лојалити програм у програмском пакету "Ticket Logic Pro"- ЗАКЉУЧЕН ИЗМЕЂУ: 1. ЈП „Голд гондола Златибор“, Улица спортова бб, 31315 Златибор, матични број 21162035, ПИБ 109326994, број рачуна: 200-3577420101898-62, које заступа директорка Бојана Божанић (у даљем тексту: Наручилац) и 2. ____________, улица __________, пошт.број и место _____________, матични број: __________, ПИБ: _________, број рачуна: __________, кога заступа __________(у даљем тексту: Извршилац) (у даљем тексту: Уговорне стране) Уводне одредбе * Наручилац је, на основу одлуке о покретању поступка јавне набавке број 02-191/26 од дана 08.10.2026. године спровео отворени поступак јавне набавке број ЈН-у 15/26 за набавку услуга – Израда и имплементација модула за проширење функционалности код продаје путем интернета и за лојалити програм у програмском пакету "Ticket Logic Pro", за потребе ЈП „Голд гондола Златибор“; * Извршилац је дана _________. године доставио понуду број ________, заведену код Наручиоца под бројем __________ дана __________. године, која се налази у прилогу овог уговора и његов је саставни део; * Понуда Извршиоца у потпуности одговара захтевима Наручиоца из конкурсне документације; * Наручилац је, на основу члана 146. Закона донео Одлуку о додели уговора за набавку услуга израде и имплементације модула за проширење функционалности код продаје путем интернета и за лојалити програм у програмском пакету "Ticket Logic Pro", и као најповољнију изабрао понуду _______________________________. Члан 1. Предмет набавке је развој, имплементација, интеграција и пуштање у рад нових функционалности постојећег тицкетинг система, са циљем унапређења продаје карата, управљања попустима и ваучерима, корисничких функционалности, мониторинга пролазака, извештавања и аутоматизације слања извештаја. Спецификација обухвата следеће функционалне целине: Loyalty програм и интеграција са системом ДигиталнаКартица Онлине продаја Управљање ваучерима и попустима Профил корисника Мониторинг и извештавање за контролоре Realtime мониторинг пролазака и врста карата Подршка за доње сензоре Аутоматско слање извештаја путем e-mailа Напредно филтрирање и типизирање извештаја Посебан приказ хотелских карата на билетарници Проширење извештаја пролазака кроз капије подацима о кориснику карте, детаљно описане у спецификацији предмета набавке Наручиоца. Члан 2. Укупна вредност уговора за извршење услуга из члана 1. овог Уговора износи _________ без ПДВ-а, односно ________ са ПДВ-ом. Члан 3. Рок за испоруку и извршење услуга из члана 1. и спецификације предмета набавке износи _____ дана од дана закључења Уговора. Члан 4. Износ из члана 2. Уговора износ биће плаћен из делова, најкасније у року од 45 дана од дана достављања фактура. Члан 5. Овај Уговор ступа на снагу даном закључења и важи до извршења свих уговорних обавеза. Члан 6. Овај уговор се може изменити или допунити само у писаној форми - закључивањем анекса уговора уз поштовање Закона о јавним набавкама. Члан 7. Право на раскид Уговора задржавају обе уговорне стране у случају да једна од уговорних страна не испуњава своје уговорене обавезе, с тим што су обавезне да о својој намери у писаној форми обавесте другу уговорну страну најмање у року од 30 (тридесет) дана унапред. Члан 8. Уговорне стране ће уложити максималне напоре да споразумно, у духу добрих пословних односа и узајамног поверења реше све евентуалне спорове који се појаве у вези са овим Уговором или његовом интерпретацијом. У случају да се спор између уговорних страна у вези са овим Уговором не може споразумно решити, исти ће се поверити на решавање стварно надлежном суду у Ужицу. Члан 9. За све што није овим уговором предвиђено, примењиваће се Закон о јавним набавкама, Закон о облигационим односима, као и други прописи који регулишу ову врсту посла. Члан 10. Уговорне стране сагласно констатују да ће међусобну комуникацију обављати путем телефона, лично и путем електронске поште и то: -За Наручиоца је контакт за комуникацију са Извршиоцем Иван Радивојевић, е-маил: ivan.radivojevic@goldgondola.rs, моб: 064/87-021-81, -За Извршиоца је особа за контакт за комуникацију са Наручиоцем ___________________, е-маил: _______________, моб: ________________. Члан 11. Овај уговор сачињен је у 4 (четири) истоветна примерка, по 2 примерка за сваку уговорну страну. За ИЗВРШИОЦА За НАРУЧИОЦА ______________________ ________________________ Директорка Бојана Божанић НАПОМЕНЕ: Понуђач није дужан да уз понуду достави потписан модел уговора, подношењем понуде сматра се да је пристао на услове из модела уговора.