Wymagania dotyczące systemu Centrum Obsługi Karty

Transkrypt

1 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: system Centrum Obsługi Karty (zwany dalej w załączniku COK lub system ) - 1 sztuka Przedmiot zamówienia obejmuje także: dostawę i uruchomienie w siedzibie całego systemu COK, w tym dostawa licencji i oprogramowania będącego przedmiotem zamówienia, sporządzenie dokumentacji wdrożeniowej i powdrożeniowej obejmującej wszystkie etapy procesu instalacji, konfiguracji i wdrożenia wszystkich elementów zamówienia, zapewnienie możliwości korzystania przez Zamawiającego z pomocy technicznej producenta urządzeń, licencji oraz oprogramowania, uzyskanie i stosowanie przez Zamawiającego poprawek do oprogramowania, 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 Wykonawca dostarczy oprogramowanie do sprzedaży i personalizacji e-kart wraz z modułem analiz System musi współpracować z dostarczanymi w ramach niniejszego przedmiotu zamówienia urządzeniami, w tym autokomputerami, kasownikami, automatami biletowymi, czytnikami kontrolerskimi System musi być skalowalny 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 Musi być także otwarty na rozbudowę oraz modyfikacje mogące wystąpić w przyszłości System musi realizować funkcjonalność pracy wielostanowiskowej z wykorzystaniem jednolitego i spójnego środowiska aplikacyjnego 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 Wszystkie transakcje muszą być rejestrowane w sposób umożliwiający ich odtworzenie w dowolnym momencie 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 System musi działać w środowisku zintegrowanych baz danych posiadającym następujące cechy: relacyjność i transakcyjność, komunikacja z aplikacjami w standardzie SQL System powinien być zbudowany w architekturze trójwarstwowej, złożonej z: programu klienckiego, Strona 1 z 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), motoru bazy danych, zarządzającego SQL-ową bazą danych Dane już raz wprowadzone w jednej aplikacji nie powinny wymagać ponownego wprowadzania w innych aplikacjach i systemach z nim współpracujących 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) System musi zostać zintegrowany z istniejącą infrastrukturą teleinformatyczną Zamawiającego 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 Zakres integracji: Zakres eksportowanych danych: co najmniej identyfikator klienta, dane klienta, dane finansowe niezbędne do prawidłowego zaksięgowania transakcji Oprogramowanie MACROLOGIC posiada interfejs wymiany danych REST Web Services Klasa zabezpieczenia systemu: 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 Karta obca oraz karta niewprowadzona do systemu, nie może zostać zidentyfikowana w systemie Próba użycia takiej karty powinna być w systemie odnotowana System musi realizować separację użytkowników i danych System musi realizować bezpieczeństwo obsługi, eliminując możliwość utraty danych 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 Zabezpieczenia systemu powinny uwzględniać m.in. zastosowanie szyfrowanych kanałów transmisji (VPN), a także szyfrowanie poufnych informacji w bazie danych 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 Zakłada się, że szyfrowanie dokonane jest z użyciem algorytmu co najmniej 3DES lub AES 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) System musi wymuszać poziom ochrony poprzez wprowadzenie procedur logowania, mechanizmów audytów i izolacji zasobów 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ą 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 Strona 2 z 9

3 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 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 Wszelkie dokonane w systemie zmiany muszą być rejestrowane, z podaniem daty i godziny dokonania oraz identyfikatora odpowiedzialnego użytkownika 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 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 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) 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 W systemie COK mają występować trzy rodzaje funkcjonalności biletów: bilet okresowy z dowolną lub określoną liczbą przejazdów lub/i horyzontem czasowym, bilet bezpłatny elektroniczna portmonetka e-portmonetka System COK zapewni co najmniej poniższe sposoby obsługi i rejestracji biletów w zależności od konfiguracji systemu: bez rejestracji przejazdów, opcjonalnie aktywacja biletu okresowego w kasowniku, opcjonalnie rejestracja przy wejściu do pojazdu (check-in), 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 System powinien być zaprojektowany w taki sposób, aby nie było możliwe korzystanie z usług systemu przy wykorzystaniu kart: niezarejestrowanych w systemie, nieaktywnych, po okresie ważności, zastrzeżonych i zablokowanych System powinien zapewnić zarządzanie magazynem e-kart. Zarządzanie magazynem e-kart powinno dzielić się na: Strona 3 z 9

4 import kart do głównej bazy danych wpisywanie wszystkich fizycznych kart do systemu bazy danych, 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), sprawdzanie stanu kart w lokalizacjach weryfikacja stanu kart przypisanych do danej lokalizacji Wykonawca dokona wstępnego zaprogramowania dostarczonych kart Wstępne zaprogramowanie karty ma polegać na określeniu przeznaczenia poszczególnych aplikacji / sektorów karty z przypisaniem ich konkretnym aplikacjom Wynik operacji sprzedaży / zakupu ma być zapisywany we właściwych, przeznaczonych do tego celu, aplikacjach / sektorach karty Wstępne zaprogramowanie ma umożliwić zarejestrowanie kart jako dopuszczonych do obiegu i aktywowanie w momencie sprzedaży 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 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 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 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 System musi realizować funkcjonalność obsługi zwracanych przez klientów e-kart. Klient będzie mógł w dowolnym czasie zwrócić e-kartę System musi realizować sprzedaż, czyli zapis na e-karcie, i pobieranie opłat za przejazd z e- kart 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 System musi realizować sprawdzenia stanu konta na karcie za pomocą przeglądarki internetowej dla każdego posiadacza karty System musi realizować funkcjonalność doładowania portmonetki elektronicznej i zakupu biletu okresowego za pośrednictwem internetu poprzez portal WWW pasażera 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 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 System musi posiadać możliwość rozbudowy o dodatkowe aplikacje oparte o kartę bezstykową, np. pobieranie opłat za parkowanie, bilet wstępu do kina System musi zapewnić rozszerzenie systemu o dodatkowe podmioty miejskie w warstwie organizacyjnej oraz sprzętowej poprzez dodanie do kart innych usług Szczegółowe funkcjonalności ogólne systemu COK: funkcja stosowania biletów o różnych ulgach oraz biletów bezpłatnych, funkcja stosowania e-kart imiennych oraz na okaziciela, Strona 4 z 9

5 funkcja tworzenia modyfikowalnej listy zablokowanych kart, funkcja odtworzenia historii karty i wystawiania duplikatu, funkcja predefiniowania taryf domyślnych dla różnych typów kart (normalne, ulgowe, bezpłatne), funkcja realizacji dokupywanych biletów również w innej taryfie, niż domyślna, funkcja definiowania kart personalizowanych elektronicznie i kart na okaziciela, funkcja stosowania bonusów cenowych (krótkie przejazdy, przesiadki, jednorazowe doładowywania karty dużym nominałem), funkcja definiowania innych cen dla wybranych pór dnia wprowadzenie dolnego i górnego limitu doładowania, 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), prowadzenie bazy o kontrolach biletowych, przegląd danych z czytników kontrolerskich (data i czas kontroli, numer karty, numer pojazdu, numer kontrolera, typ i ważność biletu, itp.), 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, sygnalizacja nieprawidłowości działania systemów pokładowych, w tym kasowników, transmisja i rejestracja danych z komputerów pokładowych (rejestracja e-kart), współpraca z serwerem komunikacyjnym odpowiedzialnym za transmisję danych do/z systemu biletowego pojazdu, 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), funkcja wprowadzania danych musi być udostępniona tylko autoryzowanym użytkownikom, praca wielostanowiskowa równoczesna - wprowadzanie danych musi być możliwe przez kilku użytkowników jednocześnie, funkcja rejestrowania czasu pracy wszystkich pracowników Zamawiającego użytkujących COK, 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, Funkcjonalności COK związane z obsługą e-kart: inicjalizacja kart w systemie przy użyciu kluczy do kodowania, których właścicielem jest Zamawiający, obsługa procesu personalizacji e-karty; W pamięci karty oraz w bazie danych systemu zapisane są co najmniej następujące dane klienta: w systemie: imię i nazwisko, dane adresowe, terminowe lub bezterminowe uprawnienia do zniżek, numer klienta, na e-karcie: imię i nazwisko, terminowe lub bezterminowe uprawnienia do zniżek, numer klienta współpraca z urządzeniami kontroli biletowej, wydawanie e-kart, funkcja zdefiniowania i przypisania bądź nie kaucji za wydanie określonej e-karty, Strona 5 z 9

6 funkcja zdefiniowania pobierania opłaty przy wydaniu e-karty z podziałem na rodzaje e-kart (imiennej i na okaziciela), doładowywanie e-kart oraz przedłużanie okresu ważności biletów okresowych (funkcjonalność sprzedaży i fakturowania), obsługa e-portmonetki, w tym doładowań internetowych e-kart, system musi mieć funkcjonalność sprzedaży i pobierania opłat za przejazdy z e- portmonetki 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, funkcja konieczności załadowania na miejscu w POK biletu okresowego lub punktów w elektronicznej portmonetce przy wydawaniu e-karty lub jej duplikatu, wysokość doładowania e-portmonetki musi być parametrem konfigurowalnym w systemie; rejestrację na e-karcie imiennej uprawnień do przejazdów ulgowych lub bezpłatnych z uwzględnieniem terminu obowiązywania ulgi lub bezterminowo; 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, 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; kasownik automatycznie wykrywa na karcie bilet okresowy i potwierdza jego rejestrację podczas przejazdu, 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, pasażer będzie miał obowiązek rejestrowania karty przy wejściu i oraz powinien zarejestrować kartę przy wyjściu, obsługa zgłoszenia utraconych e-kart, zastrzeganie w systemie kart utraconych, przez zastrzeżenie karty rozumie się zablokowanie obsługi takiej karty przez system COK i przeniesienie jej do bazy kart zablokowanych (czarna lista), informacja o zablokowaniu/zastrzeżeniu karty powinna być niezwłocznie udostępniania wszystkim urządzeniom i podsystemom współpracującym z systemem biletu elektronicznego, 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 System COK musi wykazywać do których autokomputerów zostały wgrane czarne listy Karta znajdująca się na liście kart zablokowanych po rozpropagowaniu przez system staje się kartą nieaktywną 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 anulowanie transakcji zakupu z zachowaniem danych w systemie o tej transakcji w celach kontrolnych, zwroty kart - po zwróceniu karty przez klienta: Strona 6 z 9

7 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, nie zostaje zwrócona kwota wpłacona na bilety okresowe, wymiana danych o e-kartach w ramach systemu SBE, w tym z urządzeniami kontrolerów biletów, automatami i kasownikami, analiza i raportowanie dotyczące e-kart, 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, system musi zapewnić personalizację graficzną e-kart zgodnie z wymaganiami Zamawiającego Funkcjonalności COK związane z e-portmonetką e-portmonetka jest to wydzielona aplikacja na e-karcie, płatność na zasadzie zakupienia z góry określonej liczby punktów na przejazdy (np. poprzez portal WWW obsługi klienta), 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; 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, 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; Zamawiający przewiduje zastosowanie niższej taryfy za krótkie przejazdy i przesiadki oraz zmianę taryfy przy przekroczeniu przystanku granicznego stref taryfowych 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, system musi zarejestrować na karcie wszystkie zdarzenia skasowania biletów w ramach danego kursu, 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ę, system musi zapewnić pobieranie mniejszej ilości punktów od nominalnej przy przejazdach na krótkich odcinkach (np. 2 przystanki), 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, Podsystem raportowy: Zaoferowane w niniejszym postępowaniu oprogramowanie COK musi realizować funkcjonalność tworzenia i dostępu do raportów 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. Strona 7 z 9

8 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 Raporty mogą być wykonywane wg harmonogramu (ustawianego w dyspozytorze zadań). Sposób ich wykorzystania musi być również programowalny 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 Moduł raportowy musi posiadać mechanizmy wzbogacające sposób prezentacji wyników analiz: prezentacja danych wstępnie zagregowanych na różnych poziomach szczegółowości, niosących w sobie informacje decyzyjne, przestawne tabele prezentujące przekrój przez wielowymiarową strukturę danych, powiązane z nimi dwu i trójwymiarowe wykresy, 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), analizy porównawcze Zamawiający musi uzyskać w systemie raportowym możliwość tworzenia i modyfikacji szablonów raportów 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 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 Raporty można zapisać i porównywać Raporty muszą powiązywać dane o sprzedaży z danymi o kliencie 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 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 e- karty 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 Wykonawca w ramach przedmiotu zamówienia zobowiązany jest przygotować w systemie SBE następujące raporty: Strona 8 z 9

9 rozliczenie dla indywidualnego posiadacza karty zawierające co najmniej takie dane jak data, godzina, kwota i opis transakcji, saldo początkowe i końcowe, system musi generować miesięczne zestawienie przeprowadzonych operacji w zadanym czasie statystyczne z przeprowadzonych transakcji, sprzedanych i używanych kart, kart zastrzeżonych, listy białych i czarnych kart, kart do wydania czekających na odbiór przez klientów, ilości sprzedanych usług (w oparciu o rodzaje biletów zdefiniowanych w systemie, w tym z podziałem na bilety jednorazowe i okresowe), dane z kontroli biletów, użytkownicy systemu, 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, 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, o przeciążeniach w autobusach na poszczególnych liniach, o ilości pasażerów przewiezionych w oparciu o rodzaje biletów zdefiniowanych w systemie, w tym normalne, ulgowe, bezpłatne, o błędach w systemie, z podaniem informacji o miejscu i rodzaju błędu Powyższe raporty mają być generowane z możliwością grupowania, sortowania i podziału na: dzienne, tygodniowe, miesięczne zestawienie sprzedaży z podziałem na poszczególnych sprzedawców, według obowiązujących ulg, według rodzaju i ilości wystawionych kart, ilości kart użytkowanych, ilości kart zablokowanych, zestawienie wg numeru karty (wszystkie transakcje na karcie) Zawartość i ostateczny format raportów Wykonawca ustali z Zamawiającym na etapie realizacji Dostarczony system raportowy musi realizować tworzenie przez Zamawiającego nowych raportów (tzw. funkcja generatora raportów) 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 Wygenerowane w systemie raportowym raporty system COK będzie prezentować za pomocą jednorodnego interfejsu graficznego. ZAMAWIAJĄCY WYKONAWCA Strona 9 z 9