Załącznik nr 1 do Opisu Przedmiotu Zamówienia System

Załącznik nr 1 do Opisu Przedmiotu Zamówienia
System Centrum Obsługi Karty
Wymagania dotyczące systemu Centrum Obsługi Karty
1. Wstęp
1.1. W zakresie przedmiotu zamówienia jest wdrożenie systemu do obsługi e-karty:
1.1.1. system Centrum Obsługi Karty (zwany dalej w załączniku ‘COK’ lub ‘system’) - 1 sztuka.
1.2. Przedmiot zamówienia obejmuje także:
1.2.1. dostawę i uruchomienie w siedzibie całego systemu COK, w tym dostawa licencji
i oprogramowania będącego przedmiotem zamówienia,
1.2.2. sporządzenie dokumentacji wdrożeniowej i powdrożeniowej obejmującej wszystkie
etapy procesu instalacji, konfiguracji i wdrożenia wszystkich elementów zamówienia,
1.2.3. zapewnienie możliwości korzystania przez Zamawiającego z pomocy technicznej
producenta urządzeń, licencji oraz oprogramowania,
1.2.4. uzyskanie i stosowanie przez Zamawiającego poprawek do oprogramowania,
1.2.5. przeszkolenie - instruktaż wskazanych przez Zamawiającego osób w zakresie instalacji,
konfiguracji i obsługi systemu COK niezbędny do prawidłowego rozpoczęcia ich
użytkowania przez Użytkownika
2. Wymagania ogólne
2.1. System musi posiadać budowę modułową i umożliwiać rozbudowę infrastruktury w zakresie
możliwości obsługi dodatkowego wyposażenia, a także uruchomienie dodatkowych punktów
do wydawania i ładowania kart elektronicznych, w tym automatów.
2.2. Wykonawca dostarczy oprogramowanie do sprzedaży i personalizacji e-kart wraz z modułem
analiz.
2.3. System musi współpracować z dostarczanymi w ramach niniejszego przedmiotu zamówienia
urządzeniami, w tym autokomputerami, kasownikami, automatami biletowymi, czytnikami
kontrolerskimi.
2.4. System musi być skalowalny.
2.4.1. System musi być przystosowany zarówno do przyrostu liczby użytkowników jak i do
ciągłego przyrostu liczby i rozmiaru przechowywanych w Systemie danych.
2.4.2. Musi być także otwarty na rozbudowę oraz modyfikacje mogące wystąpić
w przyszłości.
2.5. System musi realizować funkcjonalność pracy wielostanowiskowej z wykorzystaniem
jednolitego i spójnego środowiska aplikacyjnego.
2.5.1. System musi obsługiwać i zapewnić Zamawiającemu dowolną liczbę stanowisk Punktu
Obsługi Klienta niezależnie od liczby opisanych w ramach niniejszego przedmiotu
zamówienia.
2.6. Wszystkie transakcje muszą być rejestrowane w sposób umożliwiający ich odtworzenie
w dowolnym momencie.
2.7. System musi być w całości spolonizowany, a więc posiadać polskie znaki i instrukcję obsługi
po polsku a także polski interfejs i komunikaty.
2.8. System musi działać w środowisku zintegrowanych baz danych posiadającym następujące
cechy: relacyjność i transakcyjność, komunikacja z aplikacjami w standardzie SQL.
2.9. System powinien być zbudowany w architekturze trójwarstwowej, złożonej z:
2.9.1. programu klienckiego,
SIWZ – OPZ – System Biletu Elektronicznego
Strona 1 z 9
2.9.2. serwera aplikacji (kod zarządzający aplikacją, wykonujący funkcje z zakresu logiki
biznesowej, pośredniczący między żądaniami programu klienckiego a funkcjami
udostępnianymi przez motor bazy danych),
2.9.3. motoru bazy danych, zarządzającego SQL-ową bazą danych.
2.10. Dane już raz wprowadzone w jednej aplikacji nie powinny wymagać ponownego
wprowadzania w innych aplikacjach i systemach z nim współpracujących.
2.11. System ma być „przyjazny” dla użytkownika, wymagana jest ergonomiczność i intuicyjność
obsługi oraz możliwość uruchomienia kilku instancji oprogramowania (oznacza to możliwość
uruchomienia kilku okien systemu w celu równoległego uruchomienia kilku zadań, np.:
uruchomienie raportu i jednocześnie generowanie faktury sprzedaży).
2.12. System musi zostać zintegrowany z istniejącą infrastrukturą teleinformatyczną
Zamawiającego.
2.13. System musi zostać zintegrowany z istniejącym u Zamawiającego systemem księgowym
MACROLOGIC „Finanse i Księgowość” w zakresie wymiany danych księgowych
i rozliczeniowych. Koszt integracji ponosi Wykonawca.
2.13.1. Zakres integracji:
2.13.1.1. Zakres eksportowanych danych: co najmniej identyfikator klienta, dane klienta,
dane finansowe niezbędne do prawidłowego zaksięgowania transakcji.
2.13.1.2. Oprogramowanie MACROLOGIC posiada interfejs wymiany danych REST Web
Services.
2.14. Klasa zabezpieczenia systemu:
2.14.1. Wykonawca przed przystąpieniem do prac przedstawi sposób zabezpieczenia
systemu przed nielegalnym doładowywaniem kart, ich kopiowaniem oraz wszelkimi
innymi nielegalnymi próbami ich użycia.
2.14.1.1. Karta obca oraz karta niewprowadzona do systemu, nie może zostać
zidentyfikowana w systemie.
2.14.1.2. Próba użycia takiej karty powinna być w systemie odnotowana.
2.14.2. System musi realizować separację użytkowników i danych.
2.14.3. System musi realizować bezpieczeństwo obsługi, eliminując możliwość utraty danych.
2.14.4. Poziom bezpieczeństwa musi pozwalać użytkownikowi na ochronę danych
związanych z realizowanymi przez system funkcjami, uniemożliwiając innym
użytkownikom ich odczyt, modyfikowanie lub usuwanie.
2.14.5. Zabezpieczenia systemu powinny uwzględniać m.in. zastosowanie szyfrowanych
kanałów transmisji (VPN), a także szyfrowanie poufnych informacji w bazie danych.
2.14.5.1. Przez szyfrowanie rozumie się tu takie ich przekształcenie podczas zapisu do
bazy danych, które uniemożliwi odczyt przez osoby nie posiadające
odpowiedniego klucza.
2.14.5.2. Zakłada się, że szyfrowanie dokonane jest z użyciem algorytmu co najmniej
3DES lub AES.
2.14.5.3. Zakres chronionych danych wynika z Ustawy o ochronie danych osobowych
oraz Ustawy o ochronie informacji niejawnych (pełne zabezpieczenie systemu,
baz danych zgodnie z ustawą o ochronie danych osobowych).
2.14.6. System musi wymuszać poziom ochrony poprzez wprowadzenie procedur logowania,
mechanizmów audytów i izolacji zasobów.
2.14.7. System musi realizować procedury ustalania zasad haseł (np. minimalna długość
hasła, wymagane znaki - hasło musi się składać z liter i cyfr, okres ważności hasła) dla
użytkowników oraz grup użytkowników przez administratora lub osobę upoważnioną.
2.14.8. System musi rejestrować historię haseł (zakodowanych) i przy próbie podania przez
użytkownika starego hasła (wcześniej używanego) musi zabraniać jego ponownego
SIWZ – OPZ – System Biletu Elektronicznego
Strona 2 z 9
użycia oraz gwarantować automatyczne wygaszenie hasła z chwilą upływu jego
ważności. Czas ważności danego hasła będzie określany przez Administratora.
2.14.9. System musi zapewnić autoryzowany dostęp do poszczególnych modułów wyłącznie
według zdefiniowanych uprawnień (administrator, operator, użytkownik). Każda próba
nieautoryzowanej ingerencji w system musi być rejestrowana z podaniem daty,
godziny, miejsca oraz rodzajem ingerencji.
2.14.10. Wszelkie dokonane w systemie zmiany muszą być rejestrowane, z podaniem daty
i godziny dokonania oraz identyfikatora odpowiedzialnego użytkownika.
2.14.11. System musi zapewniać weryfikację źródła danych na poziomie transmisji i formatu
oraz zapewnić bezpieczeństwo danych przesyłanych do serwera poprzez ich
kodowanie. Rozkodowanie winno odbywać się już po przesłaniu danych, bezpośrednio
na serwerze.
2.14.12. System wykona automatyczną kopię zapasową systemu oraz archiwizację danych
(co najmniej raz na 24 godz. na dedykowanym urządzeniu zewnętrznym, z tym że
szczegóły procesu kopii bezpieczeństwa muszą być uzgodnione z Zamawiającym).
3. Wymagania szczegółowe
3.1. Dostarczony w ramach realizacji niniejszego zamówienia system COK winien zapewnić
realizację taryf Zamawiającego w zakresie obsługi biletów okresowych, o zdefiniowanych
kryteriach ważności czasowej w trybie rejestrowania karty przy wchodzeniu i przy
wychodzeniu z pojazdu oraz umożliwić rozszerzenie funkcji użytkowych w ramach COK.
3.2. COK musi posiadać funkcjonalność pozwalającą Zamawiającemu na swobodne kreowanie
taryf oraz dowolne definiowanie parametrów, od których uzależniona będzie wysokość
pobieranych od pasażerów opłat za przejazd środkami komunikacji miejskiej w trybie
dwukrotnego rejestrowania karty przy wchodzeniu i przy wychodzeniu z autobusu (tzw.
„check in - check out” - rejestracja wejścia i wyjścia).
3.3. System COK musi realizować promocje taryfy w określonych dniach, godzinach lub trasach
oraz w zależności od ustalonej kwoty doładowania karty. COK musi pozwalać na określenie,
czy promocja ma obowiązywać na wszystkich liniach czy też na wybranych.
3.4. W systemie COK mają występować trzy rodzaje funkcjonalności biletów:
3.4.1. bilet okresowy z dowolną lub określoną liczbą przejazdów lub/i horyzontem czasowym,
3.4.2. bilet bezpłatny
3.4.3. elektroniczna portmonetka e-portmonetka.
3.5. System COK zapewni co najmniej poniższe sposoby obsługi i rejestracji biletów w zależności
od konfiguracji systemu:
3.5.1. bez rejestracji przejazdów,
3.5.2. opcjonalnie aktywacja biletu okresowego w kasowniku,
3.5.3. opcjonalnie rejestracja przy wejściu do pojazdu (check-in),
3.5.4. opcjonalnie rejestracja przy wejściu i wyjściu z pojazdu (check-in - check-out),
3.6. Szczegółowe kroki i schematy procedur związanych ze sposobem realizacji przez klienta
operacji związanych z zakupami i kasowaniem biletów oraz obsługą e-portmonetki zostaną
opracowane przez Wykonawcę i uzgodnione z Zamawiającym na etapie wdrożenia.
3.7. System powinien być zaprojektowany w taki sposób, aby nie było możliwe korzystanie
z usług systemu przy wykorzystaniu kart:
3.7.1. niezarejestrowanych w systemie,
3.7.2. nieaktywnych,
3.7.3. po okresie ważności,
3.7.4. zastrzeżonych i zablokowanych.
3.8. System powinien zapewnić zarządzanie magazynem e-kart. Zarządzanie magazynem e-kart
powinno dzielić się na:
SIWZ – OPZ – System Biletu Elektronicznego
Strona 3 z 9
3.8.1. import kart do głównej bazy danych – wpisywanie wszystkich fizycznych kart do
systemu bazy danych,
3.8.2. przypisywanie kart do lokalizacji – przypisywanie poszczególnych kart do lokalizacji
(Punktów Obsługi Klienta), do których zostały one wysłane (np. w celu odbioru karty
spersonalizowanej),
3.8.3. sprawdzanie stanu kart w lokalizacjach – weryfikacja stanu kart przypisanych do danej
lokalizacji.
3.9. Wykonawca dokona wstępnego zaprogramowania dostarczonych kart.
3.9.1. Wstępne zaprogramowanie karty ma polegać na określeniu przeznaczenia
poszczególnych aplikacji / sektorów karty z przypisaniem ich konkretnym aplikacjom.
3.9.2. Wynik operacji sprzedaży / zakupu ma być zapisywany we właściwych, przeznaczonych
do tego celu, aplikacjach / sektorach karty.
3.9.3. Wstępne zaprogramowanie ma umożliwić zarejestrowanie kart jako dopuszczonych do
obiegu i aktywowanie w momencie sprzedaży.
3.10. COK musi realizować funkcjonalność promocji (tzw. ulgi przesiadkowej) w przypadku, gdy
pasażer w ciągu określonego czasu od wyjścia z pojazdu podejmie podróż inną linią
komunikacji miejskiej.
3.11. System musi zapewnić sprzedaż, czyli zapis na e-kartę, zdefiniowanych przez
Zamawiającego na etapie wdrożenia rodzajów biletów z uwzględnieniem ulg.
3.12. System musi obsługiwać funkcjonalność definiowania przez Zamawiającego dowolnego
zakresu terytorialnego ważności biletu elektronicznego , np. na całą sieć, na wybrane linie,
na grupę linii, na pojedynczą linie, itp.
3.13. Wykonawca skonfiguruje system w taki sposób, aby na karcie imiennej nie można było
zapisać biletu okresowego na okaziciela, a na karcie na okaziciela nie można było zapisać
biletu imiennego.
3.14. System musi realizować funkcjonalność obsługi zwracanych przez klientów e-kart. Klient
będzie mógł w dowolnym czasie zwrócić e-kartę.
3.15. System musi realizować sprzedaż, czyli zapis na e-karcie, i pobieranie opłat za przejazd z ekart funkcjonujących w systemie na zasadzie „elektronicznej portmonetki”, z możliwością
dowolnego definiowania wysokości pobieranych opłat w zależności od ilości biletów, liczby
przejechanych przystanków.
3.16. System musi realizować sprawdzenia stanu konta na karcie za pomocą przeglądarki
internetowej dla każdego posiadacza karty.
3.17. System musi realizować funkcjonalność doładowania „portmonetki elektronicznej” i zakupu
biletu okresowego za pośrednictwem internetu poprzez portal WWW pasażera.
3.18. Przekaz danych (w tym białych i czarnych list) do urządzeń będących w zakresie niniejszego
przedmiotu zamówienia musi być realizowany bezprzewodowo za pośrednictwem GPRS w
czasie rzeczywistym na terenie całego miasta oraz dodatkowo poprzez sieć WiFi na terenie
zajezdni Zamawiającego.
3.18.1. System powinien zapewnić podgląd do których urządzeń (m.in. autobusy, automaty
stacjonarne, kasowniki, itp.) zostały wgrane niezbędne do funkcjonowania całego
systemu dane, w tym czarne i białe listy.
3.19. System musi posiadać możliwość rozbudowy o dodatkowe aplikacje oparte o kartę
bezstykową, np. pobieranie opłat za parkowanie, bilet wstępu do kina.
3.19.1. System musi zapewnić rozszerzenie systemu o dodatkowe podmioty miejskie
w warstwie organizacyjnej oraz sprzętowej poprzez dodanie do kart innych usług.
3.20. Szczegółowe funkcjonalności ogólne systemu COK:
3.20.1. funkcja stosowania biletów o różnych ulgach oraz biletów bezpłatnych,
3.20.2. funkcja stosowania e-kart imiennych oraz na okaziciela,
SIWZ – OPZ – System Biletu Elektronicznego
Strona 4 z 9
3.20.3. funkcja tworzenia modyfikowalnej listy zablokowanych kart,
3.20.4. funkcja odtworzenia historii karty i wystawiania duplikatu,
3.20.5. funkcja predefiniowania taryf domyślnych dla różnych typów kart (normalne, ulgowe,
bezpłatne),
3.20.6. funkcja realizacji dokupywanych biletów – również w innej taryfie, niż domyślna,
3.20.7. funkcja definiowania kart personalizowanych elektronicznie i kart na okaziciela,
3.20.8. funkcja stosowania bonusów cenowych (krótkie przejazdy, przesiadki, jednorazowe
doładowywania karty dużym nominałem),
3.20.9. funkcja definiowania innych cen dla wybranych pór dnia wprowadzenie dolnego
i górnego limitu doładowania,
3.20.10. funkcja kreowania raportów finansowych i statystycznych zdefiniowanych
w systemie (z podziałem na urządzenia, grupy urządzeń, taryfy, grupy taryf,
sprzedawców, okresy czasowe, ilości i rodzaje wydawanych kart),
3.20.11. prowadzenie bazy o kontrolach biletowych,
3.20.12. przegląd danych z czytników kontrolerskich (data i czas kontroli, numer karty, numer
pojazdu, numer kontrolera, typ i ważność biletu, itp.),
3.20.13. gromadzenie i przetwarzanie danych COK przesyłanych z urządzeń sterujących pracą
urządzeń pokładowych autobusowych, punktów sprzedaży i czytników kontrolerskich,
3.20.14. sygnalizacja nieprawidłowości działania systemów pokładowych, w tym
kasowników,
3.20.15. transmisja i rejestracja danych z komputerów pokładowych (rejestracja e-kart),
3.20.16. współpraca z serwerem komunikacyjnym odpowiedzialnym za transmisję danych
do/z systemu biletowego pojazdu,
3.20.17. umożliwienie importu i eksportu danych z/do innych programów (Wykonawca
powinien określić, jakie dane są niezbędne do prawidłowego importowania
i eksportowania oraz wskazać interfejs wymiany tych danych),
3.20.18. funkcja wprowadzania danych musi być udostępniona tylko autoryzowanym
użytkownikom,
3.20.19. praca wielostanowiskowa równoczesna - wprowadzanie danych musi być możliwe
przez kilku użytkowników jednocześnie,
3.20.20. funkcja rejestrowania czasu pracy wszystkich pracowników Zamawiającego
użytkujących COK,
3.20.21. zakres działania użytkownika jest określany przez Administratora, który przydziela
odpowiednie prawa dostępu, w tym nadawanie i obsługa uprawnień pracowników COK
i POK, kontrolerów, kierowców i administratorów systemu,
3.21. Funkcjonalności COK związane z obsługą e-kart:
3.21.1. inicjalizacja kart w systemie przy użyciu kluczy do kodowania, których właścicielem
jest Zamawiający,
3.21.2. obsługa procesu personalizacji e-karty;
3.21.2.1. W pamięci karty oraz w bazie danych systemu zapisane są co najmniej
następujące dane klienta:
3.21.2.1.1. w systemie: imię i nazwisko, dane adresowe, terminowe lub
bezterminowe uprawnienia do zniżek, numer klienta,
3.21.2.1.2. na e-karcie: imię i nazwisko, terminowe lub bezterminowe uprawnienia
do zniżek, numer klienta.
3.21.3. współpraca z urządzeniami kontroli biletowej,
3.21.4. wydawanie e-kart,
3.21.5. funkcja zdefiniowania i przypisania bądź nie kaucji za wydanie określonej e-karty,
SIWZ – OPZ – System Biletu Elektronicznego
Strona 5 z 9
3.21.6. funkcja zdefiniowania pobierania opłaty przy wydaniu e-karty z podziałem na rodzaje
e-kart (imiennej i na okaziciela),
3.21.7. doładowywanie e-kart oraz przedłużanie okresu ważności biletów okresowych
(funkcjonalność sprzedaży i fakturowania),
3.21.8. obsługa e-portmonetki, w tym doładowań internetowych e-kart,
3.21.8.1. system musi mieć funkcjonalność sprzedaży i pobierania opłat za przejazdy z eportmonetki z możliwością dowolnego definiowania wysokości pobieranych opłat,
np. poprzez pobieranie opłat w zależności od ilości przejechanych przystanków,
3.21.9. funkcja konieczności załadowania na miejscu w POK biletu okresowego lub punktów
w elektronicznej portmonetce przy wydawaniu e-karty lub jej duplikatu,
3.21.9.1. wysokość doładowania e-portmonetki musi być parametrem konfigurowalnym
w systemie;
3.21.10. rejestrację na e-karcie imiennej uprawnień do przejazdów ulgowych lub bezpłatnych
z uwzględnieniem terminu obowiązywania ulgi lub bezterminowo;
3.21.11. podczas ładowania karty biletem ulgowym system umożliwi zapisanie biletu na
karcie pod warunkiem, iż w terminie rozpoczęcia ważności biletu Pasażer będzie
posiadał zapisane na karcie ważne uprawnienie do ulgi,
3.21.12. warunkiem zawarcia umowy przewozu przez pasażera jest przytknięcie karty do
kasownika przy wejściu do autobusu i automatyczna rejestracja przejazdu na karcie
potwierdzona sygnałem dźwiękowym i komunikatem tekstowym na kasowniku;
3.21.13. kasownik automatycznie wykrywa na karcie bilet okresowy i potwierdza jego
rejestrację podczas przejazdu,
3.21.14. przejazd z biletem, na którym podczas kontroli nie zostanie stwierdzona rejestracja
biletu w kasowniku autobusu będzie traktowany jak przejazd bez ważnego biletu –
podczas kontroli biletowej na czytniku kontrolerskim pojawi się informacja : brak
rejestracji biletu,
3.21.15. pasażer będzie miał obowiązek rejestrowania karty przy wejściu i oraz powinien
zarejestrować kartę przy wyjściu,
3.21.16. obsługa zgłoszenia utraconych e-kart,
3.21.17. zastrzeganie w systemie kart utraconych,
3.21.17.1. przez zastrzeżenie karty rozumie się zablokowanie obsługi takiej karty przez
system COK i przeniesienie jej do bazy kart zablokowanych (czarna lista),
3.21.17.2. informacja o zablokowaniu/zastrzeżeniu karty powinna być niezwłocznie
udostępniania wszystkim urządzeniom i podsystemom współpracującym
z systemem biletu elektronicznego,
3.21.17.3. zastrzeżenie wiąże się z utratą jej ważności w trybie do 24 godzin. Wykonawca
zagwarantuje, że informacja o zablokowaniu karty będzie rozpropagowana w
systemie SBE (do autobusów za pośrednictwem GPRS i dodatkowo WiFi) w czasie
jak najkrótszym, jednak nie dłuższym niż 24 godziny od zgłoszenia zastrzeżenia
karty w systemie COK.
3.21.17.4. System COK musi wykazywać do których autokomputerów zostały wgrane
czarne listy.
3.21.17.5. Karta znajdująca się na liście kart zablokowanych po rozpropagowaniu przez
system staje się kartą nieaktywną.
3.21.17.6. Którykolwiek z czytników systemu, w tym czytników kontrolerskich, do
którego zostanie zbliżona karta z czarnej listy ma dokonać jej blokady.
3.21.18. anulowanie transakcji zakupu z zachowaniem danych w systemie o tej transakcji
w celach kontrolnych,
3.21.19. zwroty kart - po zwróceniu karty przez klienta:
SIWZ – OPZ – System Biletu Elektronicznego
Strona 6 z 9
3.21.19.1. zostanie zwrócony ekwiwalent pieniężny niewykorzystanych punktów na
bilety jednorazowe oraz niewykorzystane pieniądze na elektronicznej
portmonetce, zwrot takich środków nastąpi gotówką lub przekazem pocztowym
na koszt Klienta,
3.21.19.2. nie zostaje zwrócona kwota wpłacona na bilety okresowe,
3.21.20. wymiana danych o e-kartach w ramach systemu SBE, w tym z urządzeniami
kontrolerów biletów, automatami i kasownikami,
3.21.21. analiza i raportowanie dotyczące e-kart,
3.21.22. ewidencja danych systemu biletowego: obsługa rodzajów ładowania kart pełniących
role e-biletów, obsługa rodzajów ulg, okresów ważności biletów okresowych,
3.21.23. system musi zapewnić personalizację graficzną e-kart zgodnie z wymaganiami
Zamawiającego.
3.22. Funkcjonalności COK związane z e-portmonetką
3.22.1. e-portmonetka jest to wydzielona aplikacja na e-karcie,
3.22.2. płatność na zasadzie zakupienia „z góry” określonej liczby punktów na przejazdy (np.
poprzez portal WWW obsługi klienta),
3.22.3. płatność za przejazd będzie realizowana w następujący sposób: pasażer wsiadając do
autobusu, na kasowniku musi wybrać zakup zdefiniowanego biletu, a następnie
przytknąć kartę do kasownika; na podobnej zasadzie możliwy będzie zakup wielu
biletów z różnymi ulgami;
3.22.4. przy braku punktów na karcie do opłacenia przejazdu do przystanku końcowego,
kasownik pobierze opłatę za przejazd w aktualnej strefie taryfowej, a na kasowniku
pojawi się sygnał dźwiękowy i stosowny komunikat tekstowy,
3.22.5. rozliczenie przejazdu nastąpi po przytknięciu karty do kasownika przy wysiadaniu
i potwierdzeniu operacji skasowania biletu. W efekcie nastąpi zwrot na kartę punktów
wynikających z różnicy w cenie pomiędzy biletem do przystanku końcowego,
a faktycznie wykorzystanym przejazdem;
3.22.6. Zamawiający przewiduje zastosowanie niższej taryfy za krótkie przejazdy i przesiadki
oraz zmianę taryfy przy przekroczeniu przystanku granicznego stref taryfowych.
3.22.7. System musi zapewnić określanie limitów kwotowych na załadowanie e-portmonetki
poprzez parametr definiowalny dla danej karty lub dla całego systemu COK,
3.22.8. system musi zarejestrować na karcie wszystkie zdarzenia skasowania biletów
w ramach danego kursu,
3.22.9. system musi zapewnić funkcję pobierania maksymalnej ilości punktów dla całej trasy,
a następnie od tej ilości punktów przy wysiadaniu odejmowana jest faktyczna wartość
wynikająca z cennika za przejechaną trasę,
3.22.10. system musi zapewnić pobieranie mniejszej ilości punktów od nominalnej przy
przejazdach na krótkich odcinkach (np. 2 przystanki),
3.22.11. system musi zapewnić realizację ulgi przesiadkowej polegającej na tym, że przejazd
kolejnymi pojazdami, gdy pomiędzy opuszczeniem pojazdu, a wejściem do następnego,
następuje przed upływem określonego przedziału czasu, oznacza pobranie z karty
zmniejszonej liczby punktów za kolejny przejazd - parametry tej usługi ustala
administrator systemu,
3.23. Podsystem raportowy:
3.23.1. Zaoferowane w niniejszym postępowaniu oprogramowanie COK musi realizować
funkcjonalność tworzenia i dostępu do raportów.
3.23.2. Raporty są wykonywane na bieżąco na żądanie użytkownika i mogą być przez niego
zapisywane w systemie, w formacie umożliwiającym późniejszą modyfikację, a także
eksportowanie do formatów, co najmniej Microsoft Office (w tym: .xlsx, .docx), PDF.
SIWZ – OPZ – System Biletu Elektronicznego
Strona 7 z 9
3.23.3. Raporty są od razu zapisywane do plików bądź przesyłane do innych modułów do
wykorzystania lub przesłania do odbiorców itp.
3.23.4. Raporty mogą być wykonywane wg harmonogramu (ustawianego w dyspozytorze
zadań). Sposób ich wykorzystania musi być również programowalny.
3.23.5. System raportowy musi realizować funkcjonalność pozwalającą zaawansowanemu
użytkownikowi na dodatkową możliwość posłużenia się zapytaniem SQL do tworzenia
szablonów i analiz raportów.
3.23.6. Moduł raportowy musi posiadać mechanizmy wzbogacające sposób prezentacji
wyników analiz:
3.23.6.1. prezentacja danych wstępnie zagregowanych na różnych poziomach
szczegółowości, niosących w sobie informacje decyzyjne,
3.23.6.2. przestawne tabele prezentujące przekrój przez wielowymiarową strukturę
danych, powiązane z nimi dwu i trójwymiarowe wykresy,
3.23.6.3. dobieranie sposobu prezentacji danych w trakcie tworzenia analizy oraz
możliwość późniejszego ustawienia zmian sposobu prezentacji przez użytkownika
(w tym ustawienie domyślnego sposobu prezentacji dla określonej analizy),
3.23.6.4. analizy porównawcze.
3.23.7. Zamawiający musi uzyskać w systemie raportowym możliwość tworzenia i modyfikacji
szablonów raportów.
3.23.7.1. Szablon ma zawierać zestaw danych, które mają być prezentowane oraz sposób
prezentacji, natomiast wybrane dane (np. czas, zakres linii, pojazdów lub
przystanków) są uzupełniane/wybierane kiedy z szablonu tworzony jest konkretny
raport.
3.23.7.2. W module ma znajdować się ogólny zestaw szablonów uzupełniany
i modyfikowany przez administratora modułu, ponadto każdy użytkownik może
tworzyć własne szablony i dzielić je z innymi.
3.23.7.3. Raporty można zapisać i porównywać.
3.23.7.4. Raporty muszą powiązywać dane o sprzedaży z danymi o kliencie.
3.23.7.5. Zestawienia te mają mieć charakter statystyczny. Pozwoli to na gromadzenie
informacji o zapotrzebowaniu na określony rodzaj produktu lub usługi
i budowanie charakterystyk tego zapotrzebowania. Profile zachowań „klientów”
służą Zamawiającemu do badania zapotrzebowania na określony typ e-biletów na
danej trasie poszczególnych grup klientów.
3.23.7.6. Do realizacji wymienionych funkcjonalności konieczne jest osobne umożliwienie
użytkownikowi zdefiniowania i zapisania grupy „klientów” (przez podanie
wartości parametrów dotyczących zakupywanych usług, prawa do ulgi), do
późniejszego wykorzystania w szablonach i raportach. System wykorzystując
opisane wyżej narzędzia musi również wspomagać tworzenie raportów sprzedaży
biletów z podziałem na rodzaj e-biletu, miejsce sprzedaży oraz czas zakupu.
W momencie wdrożenia systemu winny być dostępne szablony do tworzenia
następujących raportów prezentujących: a) ranking punktów sprzedaży, typu ekarty wg ilości lub wartości sprzedanych kart oraz czasu (np. godziny
największej/najmniejszej
sprzedaży),
b)
średnią
sprzedaż
na
godzinę/dzień/miesiąc z podziałem na typ e -karty, miejsce/punkt sprzedaży,
c) procentowy udział poszczególnych typów e-kart w ogólnej sprzedaży
godzinę/dzień w miesiącu o minimalnej/maksymalnej sprzedaży z podziałem na
miejsca/punkty.
3.23.8. Wykonawca w ramach przedmiotu zamówienia zobowiązany jest przygotować
w systemie SBE następujące raporty:
SIWZ – OPZ – System Biletu Elektronicznego
Strona 8 z 9
3.23.8.1. rozliczenie dla indywidualnego posiadacza karty zawierające co najmniej takie
dane jak data, godzina, kwota i opis transakcji, saldo początkowe i końcowe,
3.23.8.1.1. system musi generować miesięczne zestawienie przeprowadzonych
operacji w zadanym czasie.
3.23.8.2. statystyczne z przeprowadzonych transakcji,
3.23.8.3. sprzedanych i używanych kart,
3.23.8.4. kart zastrzeżonych,
3.23.8.5. listy białych i czarnych kart,
3.23.8.6. kart do wydania czekających na odbiór przez klientów,
3.23.8.7. ilości sprzedanych usług (w oparciu o rodzaje biletów zdefiniowanych
w systemie, w tym z podziałem na bilety jednorazowe i okresowe),
3.23.8.8. dane z kontroli biletów,
3.23.8.9. użytkownicy systemu,
3.23.8.10. o transakcjach, biletach i pasażerach na konkretnym przystanku, linii,
w autobusie i kursie w rozbiciu godzinowym, dziennym (w tym pora dnia),
tygodniowym, miesięcznym, rocznym,
3.23.8.11. z danych off-line o dokładnej ilości pasażerów wsiadających i wysiadających
(w przypadku biletów check in – check out) dla poszczególnych przystanków
w podziale na rodzaje biletów,
3.23.8.12. o przeciążeniach w autobusach na poszczególnych liniach,
3.23.8.13. o ilości pasażerów przewiezionych w oparciu o rodzaje biletów zdefiniowanych
w systemie, w tym normalne, ulgowe, bezpłatne,
3.23.8.14. o błędach w systemie, z podaniem informacji o miejscu i rodzaju błędu.
3.23.9. Powyższe raporty mają być generowane z możliwością grupowania, sortowania
i podziału na:
3.23.9.1. dzienne, tygodniowe, miesięczne zestawienie sprzedaży z podziałem na
poszczególnych sprzedawców,
3.23.9.2. według obowiązujących ulg,
3.23.9.3. według rodzaju i ilości wystawionych kart,
3.23.9.4. ilości kart użytkowanych,
3.23.9.5. ilości kart zablokowanych,
3.23.9.6. zestawienie wg numeru karty (wszystkie transakcje na karcie).
3.23.10. Zawartość i ostateczny format raportów Wykonawca ustali z Zamawiającym na
etapie realizacji.
3.23.11. Dostarczony system raportowy musi realizować tworzenie przez Zamawiającego
nowych raportów (tzw. funkcja generatora raportów).
3.23.11.1. Zamawiający musi mieć pełną obsługę generatora raportów według własnego
uznania i zapotrzebowania bez konieczności udziału osób/firm trzecich.
3.23.12. Wygenerowane w systemie raportowym raporty system COK będzie prezentować za
pomocą jednorodnego interfejsu graficznego.
ZAMAWIAJĄCY
WYKONAWCA
SIWZ – OPZ – System Biletu Elektronicznego
Strona 9 z 9