OPIS WSTĘPNYCH OCZEKIWAŃ I WYMAGAŃ FUNKCJONALNYCH SYSTEMU

OPIS WSTĘPNYCH OCZEKIWAŃ I WYMAGAŃ FUNKCJONALNYCH SYSTEMU

Dostawa i wdrożenie systemu sprzedaży i rezerwacji biletów, usług i produktów dla Zamku Królewskiego na Wawelu i jego Oddziałów

I. PRZEDMIOT ZAMÓWIENIA

Przedmiotem zamówienia jest Wdrożenie systemu wspomagającego działalność Zamku Królewskiego na Wawelu w obszarze obsługi całego ruchu turystycznego, w szczególności: dostawa i wdrożenie systemu do rezerwacji, sprzedaży i walidacji biletów wstępu, sprzedaży i rezerwacji różnego rodzaju towarów, różnego rodzaju usług np. edukacyjnych, przewodnickich oraz wspierającego przepływ informacji na temat dostępnych tras zwiedzania i biletów dla turystów, wraz z wyposażeniem i montażem urządzeń do sprzedaży, rezerwacji i kontroli biletów.

W ramach wykonania zamówienia Wykonawca będzie zobowiązany do:

1. Dostawy (uzupełnienia posiadanego przez Zamawiającego sprzętu) i montażu urządzeń do sprzedaży i kontroli biletów – szczegółowa lista sprzętu zostanie uzupełniona na etapie ostatecznego OPZ;

2. Dostawy (uzupełnienia posiadanego przez Zamawiającego sprzętu) i montażu urządzeń do udostępniania informacji (np. ekrany) – szczegółowa lista sprzętu zostanie uzupełniona na etapie ostatecznego OPZ

3. Instalacji, wdrożenia, skonfigurowania oprogramowania

4. Importu dostarczonej przez Zamawiającego bazy kontrahentów

5. Przeprowadzenia pełnych testów oprogramowania w środowisku testowym orazasysty w siedzibie Zamawiającego podczas uruchomienia produkcyjnego systemu – wymiar godzin uzupełniony będzie na etapie ostatecznego OPZ

6. Zapewnienia licencji na całość dostarczonego oprogramowania – liczba użytkowników zostanie uzupełniona na etapie ostatecznego OPZ

7. Zapewnienia efektywnych szkoleń dla całego personelu, korzystającego z dostarczonego oprogramowania u Zamawiającego (zarówno pracowników odpowiadających za obsługę informatyczną jak i końcowych użytkowników, obsługujących procesy kasowe, rezerwacyjne, edukacyjne, informacyjne, walidacyjne) – liczba dni szkoleniowych zostanie uzupełniona na etapie ostatecznego OPZ

8. Zapewnienia wsparcia informatycznego i serwisu gwarancyjnego i pogwarancyjnego

II. SYSTEM MUSI WSPIERAĆ REALIZACJĘ STRATEGICZNYCH CELÓW PROJEKTU

Zapewnienie płynności obsługi ruchu turystycznego, przy rocznym poziomie około 2 mln sprzedanych

/ wydanych biletów.

Zapewnienie większej dostępności dla Zwiedzających - obsługi na najwyższym poziomie większej liczby turystów przy zachowaniu istniejącego stanu osobowego zespołu.

Możliwość redefiniowania strategii ruchu turystycznego opartej na analizie danych na temat ruchu turystycznego, pozyskanych dzięki poprawnemu, rozbudowanemu raportowaniu przez system.

Poprawa jakości i komfortu pracy Działu Obsługi Ruchu Turystycznego, Edukacyjnego oraz recepcji Zamku odpowiedzialnych za wstęp zwiedzających na poszczególne wystawy.

Integracja w jednym systemie całej wielokanałowej sprzedaży (kasy, rezerwacja, sprzedaż w recepcjach i informacji, sprzedaż w mobilnych punktach sprzedaży, sprzedaż w automatach).

III. ZAKRES PROJEKTU:

Projekt obejmuje wdrożenie systemu wspomagającego działalność Zamku Królewskiego na Wawelu w obszarze obsługi całego ruchu turystycznego, w tym wsparcia następujących procesów:

 rezerwacja i wielokanałowa, zintegrowana sprzedaż biletów wstępu na ekspozycje muzealne, na wydarzenia edukacyjne towarzyszące wystawom, koncerty, lekcje i inne jednostkowe bądź powtarzalne zajęcia muzealne oraz wszelkie inne wydarzenia organizowane przez ZK na Wawelu

 bieżąca oraz na najbliższe dni sprzedaż biletów wstępu w kasach, w punktach sprzedaży mobilnej, w dziale rezerwacji, w recepcjach, w punkcie informacji, w systemie sprzedaży on- line, w automatach biletowych(Zamawiający posiada automaty Mera Systemy)

 bieżąca sprzedaż towarów (wydawnictw, pamiątek) oraz usług np. audioguides w kasach, w punktach sprzedaży mobilnej, w dziale rezerwacji, w recepcjach, w punkcie informacji i w systemie sprzedaży on-line

 planowanie, ewidencja i zarządzanie sprzedażą biletów wstępu, usług i towarów prowadzoną w każdym z wymienionych wyżej kanałów i punktów sprzedaży (planowanie sprzedaży w każdym z kanałów i punktów sprzedaży), w tym zarządzanie magazynem (stockiem)

 zarządzanie promocjami cenowymi, bazującymi na różnych mechanizmach (upsellingu, zniżkach procentowych itd.), budowanie dedykowanych ofert dla wielu grup turystów (np. VIP, Business)

 walidacja biletów, zleceń przewodnickich/edukacyjnych i ewidencja wejść osób zwiedzających na ekspozycje, lekcje muzealne oraz na wszelkie inne wydarzenia organizowane przez Zamek, we wszystkich lokalizacjach (też w Zamku w Pieskowej Skale i Dworze w Stryszowie tj. oddziałach Zamku Królewskiego na Wawelu)

 rezerwacja i sprzedaż usług przewodnickich oraz zarządzanie współpracą z przewodnikami, prowadzenie rozliczeń finansowych i sprawozdawczości, komunikacja z przewodnikami

 zarządzanie planem wydarzeń edukacyjnych, współpracą z edukatorami zewnętrznymi, prowadzenie rozliczeń finansowych i sprawozdawczości, komunikacja z edukatorami

 zarządzanie informacją - zarządzanie treścią na ekranach, możliwość ciągłej aktualizacji informacji na ekranach, wyświetlanie na bieżąco informacji o dostępnych biletach i najbliższej godzinie wejścia na poszczególne wydarzenia/trasy

 zarządzanie informacją wewnętrzną w recepcjach Zamku (wejściach na wystawy) - przygotowanie do przyjęcia poszczególnych grup turystów przez Zamek – dostęp do informacji o rezerwacjach i sprzedaży biletów na dany dzień

 eksport danych sprzedażowych do systemu finansowo-księgowego Zamku (Comarch Egeria) generowanie raportów i możliwość ich wielopłaszczyznowej analizy

 badanie ruchu turystycznego - poprzez ankietowanie, komunikację e-mail – np. badanie satysfakcji

 działania lojalizujące - obsługa karty lojalnościowej, zniżkowej, możliwość zbierania danych i komunikacji z turystą - np. życzenia urodzinowe z ofertą zniżkową

 uruchomienie systemu sprzedaży i rezerwacji biletów on-line zintegrowanego z podstawowymi funkcjonalnościami systemu

 zapewnienie ochrony danych osobowych w systemie

 potencjalne funkcjonalności rozwojowe:

- sprzedaż u dystrybutorów

- baza wiedzy/ materiały edukacyjne dla przewodników / edukatorów

IV. WYMAGANIA TECHNICZNE SYSTEMU

1. Wymagania ogólne

1.1. Dostarczone rozwiązanie musi pracować w architekturze zapewniającej maksymalne bezpieczeństwo danych i optymalizację wykonywania procesów biznesowych przy wielu równocześnie pracujących stacjach roboczych. Warunek taki spełnia np. architektura 3-warstwowa, gdzie na stacjach klienckich instaluje się warstwę prezentacji a aplikacja obsługująca logikę procesów biznesowych znajduje się na serwerze.

1.2. Dostarczone rozwiązanie musi umożliwiać zainstalowanie aplikacji klienckiej na dowolnym stanowisku komputerowym znajdującym się w sieci komputerowej Zamawiającego. Dopuszczalne jest wykorzystanie przeglądarek internetowych do uruchomienia warstwy prezentacji klienta systemu.

1.3. Uruchomienie i utrzymanie systemu musi opierać się o procedury wykorzystujące środowisko testowe oraz produkcyjne.

1.4. System musi być otwarty na integrację z innymi systemami poprzez interface API.

1.5. System musi posiadać interface importu i eksportu danych z plików (określony format plików).

2. Baza danych

2.1. Baza danych Systemu musi być bazą relacyjną i transakcyjną, wykorzystującą język SQL do operacji na danych i tworzenia zaawansowanych funkcji obsługi i przetwarzania danych systemowych, zapewniając wszystkim użytkownikom ciągły dostęp do aktualnych danych.

2.2. System musi zapewniać możliwość generowania zapytań SQL do bazy danych z wykorzystaniem narzędzi wspomagających jak np. edytor zapytań SQL.

3. Współpraca z obecną infrastrukturą informatycznąZamawiającego.

3.1. Wykonawca musi zagwarantować poprawne działanie w pełnej funkcjonalności w obecnym środowisku Zamawiającego.

3.2. Wykonawca musi zapewnić niezakłócone, poprawne działanie Systemu w istniejącej sieci informatycznej Zamawiającego, pracującej w oparciu o technologie Fast Ethernet oraz Gigabit Ethernet z zestawem protokołów TCP/IP w wersji 4 oraz zapewniać poprawność działania w razie decyzji Zamawiającego o przejściu do wersji 6 protokołów TCP/IP.

3.3. Oprogramowanie na stacjach roboczych musi działać pod kontrolą systemu Windows 10 z zainstalowanym oprogramowaniem antywirusowym oraz firewallem firmy ESET.

3.4. System musi współpracować z dostępnymi na rynku drukarkami fiskalnymi w tym z drukarkami PosnetThermal użytkowanymi przez Zamawiającego.

3.5. System musi obsługiwać drukarki z własną kartą sieciową podłączone do sieci wewnętrznej, do serwerów wydruku oraz drukarki lokalne udostępnione przez inne komputery.

4. Bezpieczeństwo.

4.1. Musi istnieć możliwość jednoznacznej identyfikacji użytkowników poprzez unikalny login i hasło.

4.2. Musi istnieć możliwość skonfigurowania ustawień długości hasła, rodzajów znaków, dużych, małych liter, znaków numerycznych, specjalnych i częstotliwości jego zmiany.

4.3. Hasła muszą być przechowywane w postaci niejawnej.

4.4. System musi posiadać możliwość kontroli dostępu i zapisywania w logach systemowych wszystkich wykonywanych w nim operacji powodujących zmianę w bazie danych, pozwalając w sposób jednoznaczny zidentyfikować użytkownika dokonującego modyfikacji danych w systemie z podaniem czasu (rok, miesiąc, dzień, godzina, minuta, sekunda).

4.5. Dostęp do danych musi być realizowany zgodnie z przepisami o ochronie danych osobowych.

5. Parametry wydajnościowe systemu.

5.1. Konfiguracja oferowanego Systemu musi pozwalać na równoczesną pracę wszystkich użytkowników Systemu z zachowaniem dostępu do wszystkich funkcji Systemu i z możliwością korzystania przez wielu użytkowników równocześnie z poszczególnych elementów Systemu (np. modyfikowanie poszczególnych rekordów przez dwie osoby – dany element jest blokowany, inny element musi być dostępny).

5.2. Równoległa praca wszystkich użytkowników nie może powodować zauważalnych opóźnień przetwarzania danych.

5.3. Realizacja głównych transakcji systemowych oraz prostych zapytań do bazy danych musi odbywać się w czasie rzeczywistym.

6. Administrowanie.

6.1. System musi udostępniać mechanizm zarządzania uprawnieniami poprzez nadawanie wielopoziomowych praw dostępu dla użytkowników (administrator z pełnym dostępem, zapis danych, odczyt danych) na poziomie poszczególnych modułów, funkcjonalności oraz poszczególnych pól systemu.

6.2. System musi umożliwiać konfigurację uprawnień użytkowników do danych i funkcjonalności systemu w tym prawa do odczytu, zapisu, zmiany i usuwania danych w powiązaniu z mechanizmami Active Directory i środowiskiem domenowym Zamawiającego.

6.3. Wykonawca musi skonfigurować dostarczony System do współpracy z istniejącym rozwiązaniem Active Directory w organizacji Zamawiającego. Po zalogowaniu użytkownika do

komputera z wykorzystaniem rozwiązania Active Directory nie będzie wymagane ponowne wprowadzanie danych logowania w celu uzyskania dostępu do Systemu.

6.4. System musi umożliwiać utworzenie co najmniej 4 kont użytkowników z uprawnieniami administratora technicznego.

6.5. System musi umożliwiać definiowanie profili użytkowników określających prawa dostępu do funkcjonalności i danych oraz przypisywanie użytkowników do profili.

V. WYMAGANIA FUNKCJONALNE SYSTEMU

Zamawiający planuje wdrożenie podstawowych funkcjonalności przed szczytem sezonu turystycznego w 2021 r., w związku z tym dopuszcza realizację zamówienia w kilku etapach, zakres i termin wdrożenia poszczególnych etapów zostanie uzupełniony na etapie OPZ.

System wdrożony przez Wykonawcę, w dniu jego przekazania do odbioru przez Xxxxxxxxxxxxx, musi posiadać następujące funkcjonalności (zgodnie z określonymi etapami i ich zakresem):

1. MODUŁ ADMINISTRACJA - Wymagane funkcjonalności systemu wspierające proces administrowania

Moduł Administracja musi umożliwiać konfigurację całości systemu, zarządzanie treścią i funkcjonalne zarządzanie samym systemem przez definiowanie dostępów i ustawień w ramach różnych funkcjonalności. Musi umożliwiać tworzenie i zarządzanie harmonogramem wszystkich tworzonych wydarzeń organizowanych przez muzeum w dowolnych terminach (datach i godzinach). Musi w funkcjonalny sposób umożliwiać definiowanie cen, limitów wstępu (dziennych, godzinowych i innych), częstotliwości, języka oprowadzania. Musi umożliwiać zarządzanie kartotekami kontrahentów, pracowników i współpracowników. Musi umożliwiać bieżące zarządzanie sprzedażą, rezerwacjami. Musi być możliwy do zainstalowania na dowolnej liczbie stanowisk.

Funkcja administratora powinna być rozdzielona na Administratora IT / technicznego zarządzającego uprawnieniami poszczególnych użytkowników i urządzeń oraz administratora merytorycznego zarządzającego treściami.

W szczególności system musi umożliwiać:

a) zarządzanie uprawnieniami i konfiguracją systemu

- pełne zarządzanie i administrowanie funkcjonalnościami w poszczególnych modułach systemu np. sprzedażowym, rezerwacyjnym itd.

- system musi umożliwiać nadanie konkretnemu użytkownikowi / stanowisku minimum uprawnień do wykonywania danego rodzaju pracy na danym stanowisku:

 możliwość nadawania szczegółowych uprawnień poszczególnym użytkownikom modułu kasa, koniecznym jest np. uprawnienie do funkcjonalności zwracania biletów z dni minionych

 możliwość definiowania, czy dany punkt sprzedaży sprzedaje bilety tylko na dzień bieżący czy na przyszłość również, z możliwością definiowania ilości dni „na przód”

 możliwość definiowania użytkownika, który może przyjąć zwrot biletów wykorzystanych

 możliwość wskazania użytkownika mającego uprawnienie do zarządzania (treścią, harmonogramem) na ekranach informacyjnych

 możliwość definiowania przykładowych uprawnień i grup uprawnień, takich jak:

o tworzenie, modyfikowanie, usuwanie, dezaktywowanie, aktywowanie użytkowników

o przypisywanie, modyfikowanie uprawnień użytkowników

o tworzenie, modyfikowanie, usuwanie, dezaktywowanie, aktywowanie stanowisk

o tworzenie, modyfikowanie, usuwanie, dezaktywowanie, aktywowanie pozycji słownikowych związanych z użytkownikami i stanowiskami np. rodzaje stanowisk

o tworzenie, modyfikowanie, usuwanie szablonów biletów

o tworzenie, modyfikowanie, usuwanie, dezaktywowanie, aktywowanie pozycji słownikowych związanych z wydarzeniami, rezerwacją, sprzedażą, przewodnikami, edukatorami np. klasyfikatory, formy płatności

o tworzenie, modyfikowanie, usuwanie, dezaktywowanie, aktywowanie wydarzeń (wystaw, tras, lekcji, zajęć muzealnych, edukacyjnych i innych)

o tworzenie, modyfikowanie, usuwanie, dezaktywowanie, aktywowanie towarów, usług, cenników, rabatów, kart klienckich, kart lojalnościowych, karnetów

o uprawnienie do podglądu cenników (bez edycji)

o tworzenie harmonogramów wydarzeń (wystaw, tras, lekcji, zajęć muzealnych, edukacyjnych i innych)

o modyfikowanie harmonogramów wydarzeń (wystaw, tras, lekcji, zajęć muzealnych, edukacyjnych i innych), w tym dodawania pojedynczych godzin wejść na wystawy spoza wygenerowanego harmonogramu, zamykania i otwierania pojedynczych godzin i przedziałów czasowych

o tworzenie, modyfikowanie, usuwanie, dezaktywowanie, aktywowanie przewodników i edukatorów

o rozliczanie osobno przewodników i edukatorów

o ręczna realizacja zleceń, odznaczanie zrealizowania zleceń

o sprzedaż biletów (bez rezerwacji)

o sprzedaż rezerwacji zwiedzania

o sprzedaż rezerwacji zajęć muzealnych, edukacyjnych i innych

o sprzedaż towarów

o edycja statusów rezerwacji

o tworzenie, modyfikowanie, usuwanie, dezaktywowanie, aktywowanie kontrahentów

o tworzenie, modyfikowanie, usuwanie szablonów potwierdzeń rezerwacji

o tworzenie, modyfikowanie wzorców i sposobów numeracji faktur

o tworzenie, modyfikowanie wzorców i sposobów numeracji zleceń przewodnickich

o tworzenie raportów

o ustawianie, modyfikowanie parametrów systemowych

o możliwość sterowania tablicami informacyjnymi

o przypisywanie dostępności towarów i usług w poszczególnych punktach i kanałach sprzedaży

o ewidencja sprzedaży prowadzonej poza systemem

o Dział Edukacji – tworzenie i modyfikowanie tylko lekcji i zajęć muzealnych; podgląd i edycja tylko rezerwacji lekcji i zajęć muzealnych

- definicje produktów i usług

- ukrywanie danych nieaktualnych z możliwością ich wykorzystania w celach raportowych (z możliwością aktywowania) np. klasyfikatory, (chodzi o wszelkie dane definiowane, a w danym okresie czasu nie używane) – parametr aktywności

- możliwość zdefiniowania z jakich adresów e-mail wysyłana jest komunikacja do zwiedzającego, przewodników / edukatorów i innych podmiotów

- definiowanie stanowisk poprzez możliwość przypisania do danego stanowiska elementów obowiązkowych: (nazwa, skrót, rodzaj (np. sprzedażowe, rezerwacyjne itd. według słownika rodzajów stanowisk pracy) oraz elementów zależnych od funkcji danego stanowiska: (przypisywanie drukarek, przyporządkowanie magazynów, dostępnych form płatności, przypisanie obsługiwanych wystaw, dostępnych towarów do sprzedaży np. jedna wystawa, dwie wystawy, wszystkie wystawy, rezerwacje lekcji, wydarzeń, zwiedzania, wydawnictwa, gadżety), w przypadku recepcji dodatkowo obsługiwane wystawy – z możliwością modyfikacji

- definiowanie rodzajów stanowisk i prowadzenie ich słownika (np. w przypadku stanowisk sprzedażowych możliwość definiowania różnych funkcjonalności dla poszczególnych stanowisk sprzedażowych (różne rodzaje kas) np. kasa biletowa, kasa z możliwością zwrotu, kasa przy informacji, BR, recepcja, automat, mobilny punkt sprzedaży, online) - w każdej z kas możliwość zdefiniowana innego zakresu

- definiowanie wzorców i sposobów numeracji zleceń przewodnickich(w skali roku)

- definiowanie wzorców i sposobów numeracji zleceń edukacyjnych (w skali roku)

- definiowanie wzorców i sposobów numeracji dokumentów sprzedażowych (odrębnie dla poszczególnych rodzajów dokumentów, punktów sprzedaży, roku)

- definicja słowników powodów pomyłek i zwrotów sprzedaży

- definicja słowników powodów anulowania faktur

zarządzanie użytkownikami

- tworzenie kont użytkowników systemu - nieograniczonej ilości kont Pracowników Zamawiającego

- możliwość zmiany hasła przez użytkownika

- nadawanie użytkownikom uprawnień do modułów i do poszczególnych funkcjonalności

- szczególny typ użytkowników stanowią przewodnicy /edukatorzy którzy mają dostęp tylko do dedykowanej dla nich części systemu -portalu przewodnickiego - użytkownicy zewnętrzni

zarządzanie definicją klasyfikatorów usług i zwiedzających

- definiowanie klasyfikatorów zwiedzających, produktów i funkcjonalności / moduły, w których mają się pokazywać

- Zamawiający zidentyfikował na własne potrzeby następujące klasyfikatory (system musi mieć możliwość dodania kolejnych):

 dla usług

o rodzaj usługi / grupa wydarzeń - zwiedzanie, zajęcia edukacyjne, wydarzenia

o typ usługi / wydarzenia – wstęp na wystawę, lekcje, warsztaty, koncert itd. przypisane do rodzaju usługi / grupy wydarzeń

o lokalizacja - Zamek Królewski na Wawelu, Zamek w Pieskowej Skale, Dwór w Stryszowie tj. wszystkie oddziały Zamku Królewskiego na Wawelu

o obiekt / trasa / wystawa np. Apartamenty Królewskie, ogród w Pieskowej Skale przypisane do lokalizacji, możliwe produkty dotyczące kilku wystaw i w związku z tym kilku lokalizacji

o rodzaj obiektu / trasy / wystawy – stała, czasowa, sezonowa

o nazwa / temat produktu / wydarzenia – np. Komnaty Królewskie z przewodnikiem, Skarbiec i Zbrojownia indywidualnie, produkty łączone np. ogrody we wszystkich lokalizacjach

o nazwa projektu specjalnego – np. kultura dostępna

 dla zwiedzających

o uprawnienie do ulgi np. uczeń, student,senior, posiadacz KDR itd. słownik podpowiada się w zależności od rodzaju wybranego biletu

o uprawnienie do biletów bezpłatnych np. muzealnik, dziecko do lat 7, dziennikarz itd. słownik podpowiada się w zależności od rodzaju wybranego biletu

o narodowość - słownik krajów z autouzupełnianiem, możliwy tylko obcokrajowiec bez wskazania krajów, dodatkowo dla Polski kod pocztowy, ustawienie kolejności podpowiadania

o charakter grupy – np. biuro podróży, przedszkole, klasa podstawowa I-III, biznesmeni itp.

- system musi umożliwiać wskazanie które z klasyfikatorów są obowiązkowe, a które dobrowolne do wypełniania przy transakcjach rezerwacji (przenoszone automatycznie na dokumenty sprzedaży) i sprzedaży

- wszystkie ww. klasyfikatory muszą mieć charakter słownikowy zdefiniowany przez administratora systemu

- system musi umożliwiać raportowanie liczby sprzedanych i wydanych biletów / wykorzystanych biletów wg. jednego lub wielu wybranych klasyfikatorów

-słownik kategorii kontrahentów

zarządzanie parametrami rezerwacji

- definiowanie czasu na odebranie rezerwacji

- definiowanie czasu na dokonanie płatności

- definiowanie czasu na bezkosztową anulację rezerwacji

- definiowanie szablonów potwierdzeń rezerwacji w języku polskim i angielskim z automatycznie wypełnianymi polami danymi z systemu (takimi jak daty, godziny, języki oprowadzania, nazwy wystaw, tematy lekcji, wydarzeń, numery rezerwacji, nazwy kontrahentów, czas na odebranie rezerwacji, termin bezkosztowej anulacji, forma płatności itd.)

- definiowanie różnych szablonów wiadomości potwierdzających realizację zamówienia w języku polskim i angielskim, w zależności od kanału sprzedaży (np. sprzedaż biletów online) i sposobu płatności

zarządzanie komunikacją wewnętrzną

- wyświetlanie komunikatów dla zalogowanych pracowników

- preferowany byłby w systemie komunikator, umożliwiający przesyłanie różnych komunikatów tekstowych, obrazków do użytkowników systemu, z możliwością definiowania odbiorców np. do danej grupy stanowisk

zarządzanie komunikacją zewnętrzną

- preferowane: pola tekstowe z możliwością definiowania komunikatów tekstowych wyświetlanych na stronie do sprzedaży w automatach, w online (np. o zamkniętych wystawach, nieczynnym zamku itd.) niezależnie od danych o ofercie automatycznie aktualizowanych z systemu

b) zarządzanie wydarzeniami

Definiowanie następujących rodzajów wydarzeń: wystaw, tras (złożonych z więcej niż jednej wystawy), lekcji i innych wydarzeń muzealnych/edukacyjnych

Dla każdego z wymienionych wydarzeń osobno do wydarzenia konfigurowane jest:

 nazwa w systemie polska i angielska,

 nazwa widoczna na bilecie polska i angielska,

 skrót nazwy wydarzenia (do wyświetlania w kasach i rezerwacjach),

 określanie kolejności wyświetlania wystaw w kasach i rezerwacjach,

 maksymalna wielkość grupy – do wykorzystania jako podpowiedź w rezerwacjach,

 klasyfikator usług / produktów,

 określanie ważności biletu (czas wejścia przed i po godzinie rozpoczęcia zwiedzania, liczony w godzinach i dniach i minutach),

 czas zwiedzania wystawy/trwania wydarzenia – do wykorzystania przy sprawdzeniu kolizji przy rezerwacji i sprzedaży biletów,

 cennik zdefiniowany poniżej,

 znacznikwyznaczenia rodzaju prowadzącego (powiązanie z kartoteką kontrahenta) który jest zdefiniowany, jeśli na danej wystawie w cenie zwiedzania / zajęć jest uwzględniony przewodnik lub edukator– wykorzystywany dla zlecania usług przewodnikom, edukatorom

 pozostałe wymagania dla prowadzącego (słownikowe, przypisane do kartoteki kontrahenta) dotyczące przewodnika/edukatora np. kategoria dzieci, VIP itd.,

 definiowanie skrótu klawiszowego do wyboru danej wystawy w kasach

 pole z informacjami o ograniczeniach dostępu dla osób z niepełnosprawnościami

 możliwość dodania piktogramu (grafiki danego wydarzenia)

- definiowanie harmonogramów udostępniania wystaw oddzielnie dla każdej wystawy (rodzaju wydarzenia) i oddzielnie dla każdego dnia tygodnia; określanie godzin otwarcia i ostatniego wejścia, rodzaju limitowania wejść /godzinowe – rytmiczna i nierytmiczna sekwencyjność wejść z określaną liczbą zwiedzających mogących rozpocząć zwiedzanie o konkretnej godzinie lub w określonym przedziale czasu, dzienne, bez limitu/; definiowanie dopuszczalnych przekroczeń

limitów, możliwość wydzielania pul dla poszczególnych kanałów sprzedaży np. online, automat); możliwość definiowania harmonogramów na podstawie istniejących

- elastyczne zarządzanie pulą biletów na potrzeby organizacji różnych wydarzeń, szybka zamiana istniejącego wydarzenia w harmonogramie na inne wydarzenie w ramach istniejących limitów dostępnych biletów

- automatyczne przenoszenie dostępnej puli biletów na inne wydarzenie po zaistnieniu określonego warunku np. upływu terminu rezerwacji puli na lekcje muzealne i przeniesienie ich na zwiedzanie indywidualne

- możliwość wprowadzania doraźnych zmian w obowiązujących harmonogramach wystaw np.:

 dodawania pojedynczych godzin wejść na wystawy spoza wygenerowanego harmonogramu,

 zamykania i ponownego otwierania pojedynczych godzin lub przedziałów czasowych wejść na wystawy (zarówno przedziału czasowego liczonego w dniach, jak i określonego przedziału czasowego liczonego w minutach, godzinach w okresie liczonym w dniach),możliwość szybkiego otwarcia i zamknięcia wszystkich wygenerowanych harmonogramów w zadanym okresie

- możliwość zdefiniowania wydarzenia odbywającego się w kilku obiektach (trasach), z kilkoma strefami walidacji (rezerwacja, sprzedaż, przewodnicy, edukatorzy), np. lekcja muzealna mająca miejsce na trzech wystawach i w sali szkoleniowej, bilet na wiele wystaw

- możliwość tworzenia produktów „specjalnych” np. karnetów - typu: 5 warsztatów + 1 gratis składających się z kilku wydarzeń o różnych terminach, obowiązkowe wykupienie całego pakietu wydarzeń, wykupienie biletu pomniejsza limit dostępnych miejsc na wszystkich wydarzeniach

c) zarządzanie cennikami i sposobami płatności

- definiowanie cenników sprzedaży dla poszczególnych wydarzeń wg zdefiniowanych rodzajów biletów (normalny, ulgowy, bezpłatny)

- definiowanie cenników sprzedaży poszczególnych usługi towarównp. usługi przewodnickie, zajęcia edukacyjne

- definiowanie cennika zakupu usług, wykorzystywane do dalszych rozliczeń:

 usługprzewodnickich – stawka uzależniona od języka oprowadzania, wydarzenia lub sprzedawanego produktu (np. oprowadzanie na 1/2/3/4 wystawach)

 edukatorskich – stawka uzależniona od języka oprowadzania, wydarzenia

- możliwość definiowania okresu obowiązywania cenników – data od

 definiowanie rabatów ze wskazaniem okresu obowiązywania, ilości wystaw, dla kart lojalnościowych

 definiowanie waluty – obecnie tylko PLN

- definiowanie sposobów płatności (nazwa polska i angielska)

- możliwość definiowania kart klienckich, karnetów, kart lojalnościowych

d) zarządzanie towarami i usługami:

- definiowanie towarów i usług (nazwa na fakturę polska i angielska oraz nazwa na paragon, stawka VAT, jednostka miary, symbol PKWiU, ID księgowe, indeks towaru)

- definiowanie dostępności towarów i usług w poszczególnych punktach i kanałach sprzedaży

- definiowanie, które rabaty dostępne są dla których towarów i usług

e) zarządzanie kontrahentami

- odrębna od systemu finansowo-księgowego baza kontrahentów

- struktura pól NIP bez myślnika, kontrola liczby znaków

- blokada ponownego założenia kontrahenta z tym samym nr NIP, dopuszczalna sytuacja jednego nabywcy, ale kilku odbiorców / oddziałów / adresów do korespondencji

- ściąganie danych kontrahenta z GUS na podstawnie NIP

- blokada ponownego założenia kontrahenta bez NIP o tej samej nazwie i adresie

- możliwość dopisywania kontrahentów do kartoteki kontrahentów i modyfikowania kontrahentów również z poziomu rezerwacji

- system musi mieć możliwość w kartotece odrębnego definiowania odbiorców usług i dostawców usług, w szczególnych przypadkach ten sam podmiot może być odbiorcą i dostawcą

- kartoteka kontrahenta musi zawierać następujące pola:

 nazwa kontrahenta

 kod kontrahenta nadawany automatycznie przez system

 adres siedziby

 adres korespondencyjny

 adres e-mail

 nr telefonu

 NIP, w tym kontrahentów zagranicznych

 PESEL dla osób fizycznych

 nr. rachunku bankowego

 domyślna formę płatności, z możliwością zmiany na dokumentach

 domyślny termin płatności, z możliwością zmiany na dokumentach

 specyfika kontrahenta np. jednorazowy, powtarzany, VIP (słownik)

 rodzaj umowy np. umowa, umowa zlecenia, w umowa o dzieło (słownik), umowa o pracę (brak rozliczeń za wykonaną usługę)

 okres obowiązywania umowy

 znacznik firma / osoba fizyczna

 aktualny nr umowy i czas jej obowiązywania – archiwalne zostają zachowane

 znacznik aktywny / nieaktywny

 kategoria

 uwagi

- system musi mieć możliwość rozbudowania kartoteki kontrahenta o kolejne klasyfikatory

- system musi mieć możliwość stworzenia bazy przewodników i edukatorów, powiązanej z bazą kontrahentów

- kartoteka przewodnika / edukatora musi zawierać następujące pola:

 imię i nazwisko przewodnika / edukatora

 nr telefonu i adres e-mail

 rodzaj prowadzącego : przewodnik, edukator – wykorzystywane przy rezerwacji oprowadzania lub lekcji, oraz w portalu przewodnickim i do rozliczeń, znacznik wielokrotnego wyboru

 nr upoważnienia z możliwością wskazania daty ważności – pole tekstowe z archiwizacją

 min. ilość grup do realizacji w danym roku

 języki oprowadzania – wykorzystywane przy rezerwacji oprowadzania lub lekcji, oraz w portalu przewodnickim i do rozliczeń, znacznik wielokrotnego wyboru

 certyfikaty uprawniające do świadczenia usług np. dzieci, VIP, osoby z niepełnosprawnościamiitp., z określeniem daty ważności certyfikatu – wykorzystywane przy rezerwacji oprowadzania lub lekcji, oraz w portalu przewodnickim i do rozliczeń, znacznik wielokrotnego wyboru

 rodzaj zajęć do prowadzenia - wykorzystywane przy rezerwacji oprowadzania lub lekcji, oraz w portalu przewodnickim i do rozliczeń, znacznik wielokrotnego wyboru

 informacja o odbytych szkoleniach – pola tekstowe

 nazwa kontrahenta na którego powinny być wystawiane rozliczenia opłat za zrealizowane usługi

 zakładanie konta do portalu dla przewodników /edukatorów /login, hasło/

 uwagi

 znacznik aktywny / nieaktywny

- każde z pól w kartotece kontrahenta / przewodnika / edukatora powinno być możliwe do wykorzystania w raportowaniu

- system musi umożliwiać korygowanie danych kontrahenta / przewodnika / edukatora,

- system musi umożliwiać usuwanie danych kontrahenta / przewodnika / edukatora(niepowiązanych ze zleceniami, fakturami)

- system musi umożliwiać dopisanie do jednej firmy więcej niż 1 przewodnika /edukatora,

- możliwość dezaktywowania i aktywowania firmy prowadzonej przez przewodnika/edukatora lub dezaktywowanej starej a wprowadzenie nowej do danego przewodnika z możliwością podglądu obu informacji niezależnie (obu firm aktywnej i nieaktywnej)

zarządzanie definiowaniem usług przewodnickich

- definiowanie języków, w jakich są świadczone usługi przewodnickie (nazwa polska i angielska)

- definiowanie min. terminów uzupełniania danych o publikacji zleceń w portalu przewodnickim przed terminem zwiedzania

- definiowanie terminów przekazywanie zleceń na „giełdę” zleceń niezależnie od znacznika na rezerwację

- definiowanie terminu akceptacji lub odrzucenia zlecenia otrzymanego na portalu przewodnickim

f) zarządzanie wydrukiem biletów

- numerowanie biletów w skali roku

- odrębna numeracja dla biletów, karnetów, kart lojalnościowych itd.

- drukowanie na biletach kodów, które oprócz wpuszczania na wystawy, mogą wpuszczać do toalety (bramki ze skanerami) i na zdefiniowane wydarzenia, mogą upoważniać do pobrania mini przewodnika na telefon, mogą otwierać i zamykać szafki na bagaż, itp.

- pożądane: możliwość zmiany samodzielnieprzez Zamawiającego układu biletu z możliwością dodawania np. pól tekstowych czypiktogramów

- możliwość zastosowania wielu wzorców biletów - „personalizowania” biletów (układ biletu, zawarte informacje w zależności od rodzaju drukarki) – inne bilety na zwiedzanie, inne na lekcje (np. z nazwiskiem prowadzącego), inne na różne wydarzenia, inne dla dziennikarzy

- możliwość definiowania wydruku biletu na „prezent”

- możliwość drukowania na biletach godzin otwarcia wystawy i ostatniego wejścia przy wystawach nielimitowanych godzinowo

2. MODUŁ KASA - wymagane funkcjonalności systemu wspierające proces sprzedaży

Moduł umożliwiający wykonanie wszelkich operacji związanych z procesem sprzedaży biletów, usług i towarów klientowi.

Musi działać w pełni kompatybilnie z posiadaną przez Zamawiającego i uzupełnioną przez Dostawcę infrastrukturą zbudowaną z: terminali kasowych, drukarek fiskalnych, drukarek biletów, drukarek faktur, monitorów dla kasjera, monitorów wyświetlających informacje dla klienta,terminali do przyjmowania płatności kartami płatniczymi.

a) funkcjonalności dotyczące łatwości obsługi

- zapewnienie logicznej i łatwej ścieżki transakcji (od wyboru godziny wstępu do płatności) przy kilkunastu równoległych wystawach

- logiczny, klarowny i funkcjonalny interfejs przy sprzedaży biletów na konkretne godziny – wiele wystaw równoległych (kilka / kilkanaście różnych rodzajów biletów na kilkanaście różnych wystaw -bilety sprzedawane na konkretne godziny, wejścia co kilka minut, lub dzienne)

- zapewnienie funkcjonalności web usability - wyrazista czcionka, łatwość nawigacji itd.

- możliwość wyboru obsługi w formie dotykowego ekranu lub za pomocą myszki przez poszczególne stanowiska kasowe,

- system powinien wyświetlać kasjerowi odświeżane na bieżąco informacje:

 aktualną ilość dostępnych biletów w podziale na poszczególne produkty do sprzedaży – biorąc pod uwagę wiele działających stanowisk sprzedaży jednocześnie, godziny, o których rozpoczyna się zwiedzanie na poszczególnych trasach - w przypadku tras z godzinowym limitowaniem wejść, czyli takich gdy wstęp na trasę jest możliwy o godzinach z góry określonych w harmonogramie, a liczba zwiedzających mogących rozpocząć zwiedzanie o każdej wymienionej w harmonogramie godzinie jest ograniczona

 godziny otwarcia wystawy (pierwsze i ostanie wejście) w przypadku wystaw nie limitowanych godzinowo- system przestaje pokazywać kasjerowi wydarzenia na które skończyły się już bilety

- system sortuje kasjerowi widoczność poszczególnych wydarzeń wg. godziny wejścia

- przy wyborze więcej niż jednej trasy system powinien wspomagać (automat) kasjera w doborze kolejności zwiedzania ekspozycji (tak by na bieżąco sprzedawać równomiernie bilety na poszczególne godziny i wydarzenia, by nie przepadały nie wykorzystane bilety) oraz w doborze godzin rozpoczęcia poszczególnych wystaw. Kasjer musi mieć możliwość równoczesnego ręcznego dobierania godzin oraz korygowania podpowiedzianych przez system godzin i kolejności zwiedzania, analogicznie w przypadku więcej niż jednego wydarzenia

- przy wyborze kilku tras nie powinno być przerw w zwiedzaniu, czas przeznaczony na zwiedzanie każdej trasy nie powinien być mniejszy niż czas trwania zdefiniowany w systemie, ale kasjer może na życzenie klienta wybrać trasy zachodzące na siebie czasem trwania

- system musi umożliwiać kasjerowi tworzenie indywidualnych tras zwiedzania dla indywidualnego turysty, zbudowanych z różnych wystaw, w kolejności ułożonej według preferencji turysty

- system musi kontrolować, czy nie przekroczono limitów wejść na poszczególne wydarzenia i godziny wejścia. W takim przypadku system powinien wygenerować ostrzeżenie, co pozwala kasjerowi na ponowny wybór właściwej godziny wejścia

-system musi umożliwić rejestrację zmiany kasjerów poprzez raportowanie:

 jako raport kasowy, rozumiany tak, że system musi posiadać funkcjonalność pozwalającą kasjerowi, w dowolnym momencie trwania zmiany, wyświetlić na swym ekranie informacje podsumowujące operacje wykonane przez niego na danym stanowisku od początku bieżącej zmiany. Musi istnieć możliwość wydrukowania tych informacji.

 jako raport dzienny z systemu, rozumiany tak, że Kasjer musi mieć możliwość wygenerowania na drukarce fiskalnej raportu fiskalnego dobowego oraz raportu dziennego z systemu, z tym, że uwzględniającego wszystkie transakcje sprzedaży i inne operacje wykonane na danym stanowisku w ciągu całego dnia przez wszystkich kasjerów. Musi być zapewniona możliwość ponownego wydrukowania raportu dziennego stanowiska, tworzonego w oparciu o zapisy w bazie danych, również za dni poprzednie.

 jako raport okresowy (miesięczny, roczny) z systemu, rozumiany tak, że Kasjer musi mieć możliwość wygenerowania na drukarce fiskalnej raportu fiskalnegooraz raportu z systemu uwzględniającego wszystkie transakcje sprzedaży i inne operacje wykonane na

xxxxx stanowisku w ciągu wybranego okresu przez wszystkich kasjerów. Musi być zapewniona możliwość ponownego wydrukowania raportu okresowego stanowiska tworzonego w oparciu o zapisy w bazie danych.

-powyższe raporty powinny obejmować następujące informacje ilość i wartość transakcji z podziałem na formy płatności i rodzaje dokumentów sprzedaży; musi być wskazana kwota do wpłaty do kasy głównej (podsumowanie gotówki)

- system musi automatyczne łączyć się z terminalem kart płatniczych by kasjer nie musiał wpisywać kwoty ręcznie

- system musi posiadać funkcję wskazania reszty do wydania po wprowadzeniu kwoty, jaką otrzymuje od Klienta

b) inne funkcjonalności dotyczące kas

- system powinien umożliwiać sprzedaż (bądź wystawienie w przypadku biletów bezpłatnych) różnych rodzajów biletów (usług) i towarów

- możliwość wydawania biletów niefiskalnych z datą sprzedaży wstecz (cele raportowe)

- musi pojawiać się komunikat dla kasjera jeśli będzie chciał sfinalizować sprzedaż biletu na godzinę późniejszą niż 10 min przez rozpoczęciem wydarzenia, ze wskazaniem dla którego wydarzenia dany komunikat powinien się pojawić

- w przypadku tras z usługą przewodnicką w cenie biletu (w harmonogramie niektóre wydarzenia zdefiniowane są jako z przewodnikiem w cenie, bilet jest droższy niż standardowy) musi istnieć dodatkowo możliwość filtrowania godzin wejścia z uwzględnieniem języka, w jakim jest prowadzona usługa przewodnicka. Mechanizm filtrujący musi wybrać te godziny wejścia, na które jest dostępna wystarczająca ilość biletów w danym języku

- system musi obsługiwać rabaty - procentowe, kwotowe

- stanowisko kasowe musi sprzedawać i honorować karty stałego klienta, vouchery, karty lojalnościowe itd.

- w przypadku, gdy kupujący nabywa więcej niż jeden zestaw wystaw (tras) w ramach jednej transakcji system musi umożliwić wygenerowanie oddzielnych biletów dla każdego z zestawów – kilku zwiedzających każdy idzie inną kombinacją wystaw

- kasjer drukuje bilety i paragon fiskalny jednocześnie, po zaakceptowaniu wcześniej podsumowania transakcji sprzedaży (koszyka) i wybraniu formy płatności

- system powinien umożliwiać w funkcjonalny sposób przeprowadzenie następujących operacji zmiany przed zarejestrowaniem transakcji na drukarce fiskalnej i wydrukiem biletów:

 zmianę rodzaju biletów

 możliwość modyfikacji koszyka

 zmniejszenie ilości osób

 zwiększenie ilości osób

 korekty kolejności tras

 korektę godzin wejścia na trasy

- system ma mieć możliwość wygenerowania biletów w innej konfiguracji (podział / łączenia) niż początkowa po zafiskalizowaniu paragonu, wtedy stare numery biletów są deaktywowane, a nowe bilety otrzymują nowe numery, system aktualizuje numery biletów przypisane do danej transakcji sprzedaży

- system musi umożliwić wydrukowanie kolejnego egzemplarza tego samego biletu. Nowy egzemplarz biletu musi być oznaczony takim samym numerem jak egzemplarz wydrukowany wcześniej. Musi istnieć możliwość wielokrotnego powtórzenia ponownego drukowania tego samego biletu

- system podpowiada z automatu druk na pojedynczym blankiecie, ale musi dać możliwość wydrukowania biletów na oddzielnym blankiecie dla każdej osoby, bez potwierdzania indywidualnie każdego blankietu

- system musi zapewniać obsługę zwracanych biletów. Muszą one niezwłocznie wracać do puli biletów dostępnych.

- system automatycznie przy zwrocie produktów do kasy narzuca formę płatności z dokumentu pierwotnego. System musi generować protokół zwrotu określony w stosownych przepisach wydanych przez Ministra Finansów.

- na wybranych stanowiskach kasowych są przyjmowane zwroty biletów wystawionych w dowolnej kasie biletowej

- system umożliwia generowanie raportu pomyłek i zwrotów sprzedaży z informacją o powodzie zwrotu (słownik)

- musi istnieć możliwość sprzedaży biletów na wydarzenia już rozpoczęte z uwzględnieniem czasu ważności biletu definiowanego w konfiguracji wydarzenia

- możliwość częściowej płatności kartą, częściowo gotówką

- system musi umożliwić wyświetlenie informacji jakie bilety (na jakie wystawy i w jakich godzinach) zwiedzający kupuje, kwotę do zapłaty, widoczne na dodatkowym ekranie przy kasie

- możliwość drukowania biletów i faktur na drukarkach zainstalowanych przy innych stanowiskach

- możliwość drukowania na biletach kolejności zwiedzania

- możliwość wybrania biletów w formie standardowej lub prezentowej (klient kupuje bilet dla kogoś)

c) funkcjonalności dotyczące dokumentów sprzedażowych

- obsługa proces sprzedaży zgodnie z obowiązującymi przepisami prawa

- możliwość drukowania na dokumentach sprzedaży form płatności

- obsługa form płatności: gotówka, karta płatnicza, przelew, na fakturze powinna się znaleźć informacja zapłacono i do zapłaty – zapłacono jeśli gotówka /karta płatnicza lub zaznaczono

opłacenie faktury na rezerwacji, do której faktura jest wystawiana, do zapłaty, jeśli przelew i rezerwacja maj status nieopłacona

- rodzaje wystawianych dokumentów sprzedaży:

 paragony i korekty paragonów

 paragony z NIP i korekty paragonów z NIP,

 faktury do paragonów i korekty faktur do paragonów,

 faktury VAT z NIP i korekty do faktur VAT z NIP

 faktury VAT bez NIP (osoby fizyczne) i korekty do faktur VAT bez NIP

 faktury proformy z możliwością przekształcenia w fakturę VAT, na fakturze końcowej kwota do zapłaty 0 lub odpowiednia kwota różnicy między kwotą już zapłaconą, a kwotą do zapłaty

- możliwość drukowania numeru NIP na paragonach

- możliwość wystawienia faktury do paragonu tylko do części paragonu – wskazane w funkcjonalnościach kasy

- możliwość zdefiniowania numeracji dokumentów odrębnie dla poszczególnych rodzajów dokumentów i punktów sprzedaży

- zachowanie ciągłości numeracji dokumentów w ramach roku, m-ca, rodzaju

- możliwość powiązania paragonu fiskalnego z dokumentem sprzedaży w systemie - na paragonie fiskalnym nr transakcji z systemu, w systemie nr paragonu fiskalnego

- kontrola niezafiskalizowanych paragonów i możliwość ręcznego zafiskalizowania dokumentu, który nie został zafiskalizowany automatycznie

- możliwość wystawiania zbiorczych dokumentów sprzedaży dla zaznaczonych rezerwacji,(rezerwacje do zaznaczenia wyszukiwane / filtrowane poprzez kryteria np. daty, zakres dat, statusy rezerwacji czy nazwa kontrahenta) - możliwość wystawiania jednej faktury do wielu transakcji sprzedaży (rezerwacje biur)

- możliwość wystawiania kliku dokumentów sprzedaży do jednej rezerwacji, również na różnych nabywców

- możliwość wystawienia faktury do paragonu na stanowisku innym niż paragon był wystawiony poprzez nadanie uprawnień konkretnym użytkownikom

- obowiązkowe wskazanie przyczyny zwrotu dokumentu sprzedaży (ze słownika) wraz z wydrukowaniem protokołu zwrotu/pomyłki

- dopuszczalne rodzaje korekt dokumentów sprzedaży po zatwierdzeniu transakcji:

 błędna forma płatności – zachowanie systemu: możliwość korekty formy płatności jedynie w dniu sprzedaży

 błąd w danych kontrahenta na fakturze - zachowanie systemu: możliwość poprawy danych kontrahenta jedynie w dniu sprzedaży przez osoby z odpowiednim uprawnieniem

 błędna liczba biletów – zachowanie systemu: korekta dokumentu sprzedaży

 błędny rodzaj biletów np. normalny zamiast ulgowego – zachowanie systemu: korekta dokumentu sprzedaży

- powiązanie paragonu z terminalem kart płatniczych – brak możliwości wskazania formy płatności kartą bez wysyłki do terminala płatniczego

- brak możliwości usuwania faktur z systemu

- możliwość anulowania faktur w systemie ze wskazaniem powodu anulowania

- na dokumentach sprzedaży te same towary/usługi (ten sam produkt) muszą być agregowane

- możliwość ręcznego ustawienia daty sprzedaży na zbiorczych dokumentach sprzedaży

- musi być możliwość wielokrotnego korygowania tej samej transakcji sprzedaży, wystawiania kolejnych faktur korygujących

- przy wystawianiu faktur do paragonu system musi podpowiadać datę sprzedaży (data wystawienia paragonu)

- możliwość wystawiania duplikatów faktur

- możliwość wystawiania not korygujących do faktur sprzedażowych

- możliwość wskazywania na fakturze innego nabywcy niż tego, dla którego jest utworzona rezerwacja, możliwość wskazywania na fakturze odbiorcy

- możliwość edytowania rezerwacji, za której część został wystawiony dokument sprzedaży i możliwość zmiany elementów rezerwacji, za które nie został wystawiony dokument sprzedaży

- możliwość drukowania na fakturach okresu za jaki została wystawiona

- możliwość utworzenia zestawienia rezerwacji do wystawionego dokumentu sprzedaży, wydrukowania go i wysłania pocztą elektroniczną jako załącznik

- możliwość wystawiania dokumentów sprzedaży z anulowanych rezerwacji oznaczonych do obciążenia (możliwość wyboru składników obciążenia) – powiązanie kary za anulację z konkretną rezerwacją

- możliwość wystawiania dokumentów sprzedaży niepowiązanych z rezerwacją

- możliwość wystawiania faktur do paragonu wystawionego na dowolnym stanowisku systemu oraz poza systemem, również do sprzedaży w automacie

- możliwość wystawiania kilku faktur do jednego paragonu

- możliwość wystawiania faktur, w tym faktur proforma, w języku angielskim

- podgląd wysłanych faktur proforma z możliwością filtrowania po terminie zwiedzania, wystawienia proformy, terminie płatności, statusie płatności

- możliwość wyszukiwania, filtrowania i sumowania listy i kwoty dokumentów sprzedaży wg rodzaju dokumentu sprzedaży, formy płatności, stanowiska sprzedaży, kasjera, zakresu dat, kontrahenta, nr dokumentu korygowanego produktu

- możliwość wyszukiwania po numerze biletu dokumentu sprzedaży / rezerwacji na którym ten bilet był sprzedany

- możliwość wystawiania korekt dokumentów sprzedaży z poziomu rejestru dokumentu sprzedaży

- brak możliwości wystawienia biletów o tym samym numerze przy jednoczesnej transakcji na różnych stanowiskach sprzedaży

- na liście dokumentów sprzedaży przy dokumentach skorygowanych musi być informacja, że zostały skorygowane; przy korektach musi być numer dokumentu korygowanego; w szczegółach dokumentów musi być informacja czego korekta dotyczy

- możliwość przechodzenia w systemie pomiędzy rezerwacją, a dokumentem sprzedaży i odwrotnie bez wycofywania się do listy dokumentów

- korekty dokumentów sprzedaży muszą być wystawiane do konkretnej usługi / biletu który podlega zwrotowi

- możliwość tworzenia zestawienia sprzedaży za wybrany okres ze wszystkich stanowisk sprzedaży rezerwacji lub z wybranych stanowisk sprzedaży rezerwacji; na zestawieniu towary i usługi powinny być pogrupowane według stawek VAT i być podzielone na usługi przewodnickie, opłaty za prowadzenie zajęć, bilety na wystawy, bilety na lekcje muzealne, bilety na inne wydarzenia;

3. MODUŁ REZERWACJA - wymagane funkcjonalności systemu wspierające proces rezerwacji zwiedzania, lekcji muzealnych i innych wydarzeń oraz usług przewodnickich

Moduł umożliwiający wykonanie wszelkich operacji związanych z procesem rezerwacji biletów i usług klientowi indywidualnemu i grupowemu.

a) funkcjonalności dotyczące tworzenia, modyfikowania i anulowania rezerwacji

- możliwość tworzenia jednej rezerwacji zwiedzania na więcej niż jedną wystawę, czy wydarzenie dla tego samego kontrahenta - w pierwszej kolejności system podpowiada już zdefiniowane terminy

- możliwość tworzenia i modyfikowania rezerwacji (na dzień bieżący lub inny dzień) zwiedzania wystaw z usługą przewodnicką na jedną lub więcej wystaw, system musi brać pod uwagę istniejący harmonogram

- możliwość tworzenia i modyfikowania rezerwacji biletów wstępu na lekcje muzealne, zajęcia edukacyjne lub inne wydarzenia, z usługą edukacyjną lub bez, system musi brać pod uwagę istniejący harmonogram

- możliwość dokonania modyfikacji w istniejącej rezerwacji, polegającej na np.: zmianie liczby osób i podgrup, rodzajów biletów, wystaw i godzin wejść, języków oprowadzania, przydzielonych przewodników / edukatorów, daty zwiedzania, statusów rezerwacji

- możliwość tworzenia jednej rezerwacji zwiedzania z podziałem uczestników na podgrupy (max. ilość osób w grupie określona w konfiguracji wydarzenia)zwiedzające wystawy o tych samych lub różnych godzinach (ilość osób w podgrupie może być różna na różnych wystawach w zależności od ustalonego limitu na danej wystawie, kolejność zwiedzania wystaw przez każdą podgrupę może być inna)

- preferowane systemowe wspomaganie podziału danej grupy, dokonującej rezerwacji na podgrupy, gdy rezerwacja przekracza maksymalną wielkość grupy lub gdy nie ma wystarczającej

liczby biletów (różne wystawy mają określoną różną wielkość grupy, więc liczba podgrup na poszczególne wystawy w jednej rezerwacji może być różna)

- informacje, które musi zawierać okno rezerwacji zwiedzania:

 numer rezerwacji,

 status rezerwacji,

 data zwiedzania,

 wykaz zarezerwowanych wydarzeń wraz z godzinami,

 dane identyfikujące kontrahenta,

 liczba osób z podziałem na rodzaje biletów na poszczególne wydarzenia,

 forma płatności,

 numer imprezy zamawiającego,

 numer wewnętrzny nadawany przez użytkownika,

 rodzaj prowadzącego: edukator / przewodnik

 informacja czy jest zamawiana usługa przewodnicka na życzenie,w jakim języku, na które wydarzenie(wybierany ze słownika),

 znacznik braku wysyłki zlecenia przewodnickiego na „giełdę” do portalu przewodnickiego,

 certyfikaty uprawniające do świadczenia usług (kartoteka przewodnika / edukatora) – wykorzystywane na portalu przewodnickim,

 informacja o wybranych przewodnikach / edukatorach – wpisany ręcznie lub automatycznie z giełdy po jej uruchomieniu (akceptacja przez pierwszego spełniającego wymagania),

 data i godzina utworzenia rezerwacji,

 dodatkowe klasyfikatory zwiedzających,

 osoba tworząca rezerwację,

 uwagi (cztery różne pola do wpisywania uwag – rezerwacja, recepcja, przewodnik/ edukator, dział edukacji – pola dostępne w innych miejscach systemu np. w portalu przewodnickim czy w panelu recepcji,

 koszty poszczególnych usług z rezerwacji,

 łączna kwota rezerwacji,

 link do płatności on-line,

 pola dodatkowe w przypadku lekcji edukacyjnych i wydarzeń muzealnych: temat, godziny wejść do różnych obiektów jeśli w ramach jednego wydarzenie następuje wejście na kilka wystaw lub na jedną wystawę ale w późniejszej godzinie niż godzina rozpoczęcia wydarzenia.

- system ma podpowiadać osobie tworzącej rezerwację wolne terminy wg zadanych kryteriów, minimum: zakres dat, nazwa wydarzenia, liczba dostępnych miejsc, typ wydarzenia, języku,(ew. inne klasyfikatory)

- możliwość utworzenia rezerwacji poprzez formularz rezerwacji lub z harmonogramu z możliwością utworzenia rezerwacji

- musi istnieć możliwość zapisania rezerwacji, przy wypełnieniu tylko wskazanych pól obowiązkowych, którymi są: data, kontrahent

- system powinien ostrzegać przed kolizjami – niezgodnościami z zadanymi uprzednio limitami uczestników na daną godzinę, wielkości grupy w rezerwacjach

- możliwość pobierania danych kontrahentów do rezerwacji z kartoteki kontrahentów

- system (automatyzm) wspiera pracownika rezerwacji w ustalaniu dla danego klienta harmonogramu (daty i godziny) zwiedzania wystaw, terminów rezerwacji lekcji i wydarzeń (z możliwością modyfikacji) oraz pomimo posiadanego „kreatora terminów”, podpowiadającego kolejne godziny wejść na wystawy przy zachowaniu zadanego czasu zwiedzania i zadanej częstotliwości, umożliwia pracownikowi możliwość samodzielnego ustalania godzin. System przestrzega zdefiniowane zasady przepływu zwiedzających (np. zdefiniowana liczebność grup, limitów), gdy użytkownik je narusza system ostrzega, ale pozwala zapisać rezerwacje „z naruszeniami” po potwierdzeniu woli użytkownika; – automat opisany przy funkcjonalności kasy

- system powinien wspomagać pracownika w wyszukiwaniu najbliższych wolnych terminów zwiedzania, czy zajęć dla grupy o określonych parametrach: np.„pokaż mi wolne miejsca dla 30 osób”- możliwość wyszukiwania wolnych miejsc poprzez podświetlenie ich w innym kolorze po zadaniu kryteriów (x.xx. zakres dat, liczba osób, język/i, wystawa/y – z ekranu nie znikają godziny, które nie mają dyżurów, i godziny, które nie spełniają kryteriów)

- możliwość tworzenia cyklicznych rezerwacji na podstawie utworzonej wcześniej rezerwacji (system kopiuje rezerwację w zadanym okresie w wybranych dniach tygodnia – gdy z powodu zdefiniowanych zasad przepływu zwiedzających utworzenie rezerwacji będzie naruszało te zasady system tworzy rezerwacje z informacją o kolizji i jej przyczynie; system nie tworzy rezerwacji w przypadku braku harmonogramu lub zamknięcia wystawy)

- możliwość anulowania rezerwacji (pozostają wszystkie dane dotyczące rezerwacji, zwalniane bilety trafiają do puli biletów dostępnych, przypisani przewodnicy/edukatorzy stają się dyspozycyjni) i obciążania kontrahenta zdefiniowanymi kosztami rezerwacji (opłata anulacyjna przy odwołaniu rezerwacji) (pozostaje możliwość zmiany składników obciążenia i nie obciążania kontrahenta; możliwość utworzenia i wysłania/wydrukowania faktury proforma lub linku do płatności on-line z anulowanej rezerwacji z możliwością zmiany składników obciążenia

- przy anulowaniu rezerwacji - system umożliwia wpisanie przyczyny anulacji rezerwacji

- możliwość modyfikowania rezerwacji w trakcie rozpoczęcia procesu sprzedaży, modyfikowania rezerwacji po wydrukowaniu biletów i ponownego wydruku biletów (by wydruk biletu nie blokował możliwości modyfikowania rezerwacji), modyfikowania rezerwacji po anulowaniu faktury

- możliwość utworzenia jednej rezerwacji z różnymi językami usług przewodnickich dla poszczególnych podgrup

- system udostępnia na ekranie szczegółowy wykaz ilości biletów dostępnych na poszczególne wystawy wraz z językami oprowadzania – wiele wystaw i wiele godzin wejść powinno mieścić się na jednym ekranie; możliwość uzyskania takiego wykazu dla dowolnego dnia oraz możliwość jego filtrowana w celu wyszukania wolnych miejsc spełniających wymagania tworzonej rezerwacji

- automatyczna wysyłka maila do klienta i do edukatora/przewodnika, po zmianie statusu rezerwacji z potwierdzonej na anulowaną

- musi istnieć możliwość przyjmowania rezerwacji grupowych przez wypełnienie formularza on- line przesyłającego dane do systemu

- rezerwacja złożona on-line i przesłana do systemu musi zostać zatwierdzonaprzez pracownika zamawiającego zanim otrzyma status przyjęta

- rezerwacja zatwierdzona (przyjęta on-line) może być wycofana tylko po kontakcie z pracownikiem Zamawiającego

- formularz rezerwacji on-line obejmuje wybrane pola z formularza rezerwacji oraz pola dodatkowe tekstowe

- możliwość generowania i wysyłania pocztą elektroniczną linku do płatności za daną rezerwację lub grupę rezerwacji wraz z potwierdzeniem rezerwacji; możliwość ponownego wysłania linku; możliwość anulowania linku; możliwość zmodyfikowania rezerwacji i wysłania kolejnego linku

- system musi mieć możliwość ustawienia dwóch rodzajów kategorii statusów (stanów) rezerwacji

 główne (G) - przyjęta, potwierdzona, odebrana, anulowana, wykorzystana (zwalidowana- przynajmniej jeden bilet z danej rezerwacji został zwalidowany)

 dodatkowe (D) – np. wysłano potwierdzenie, niewykupiona

- możliwość zmiany statusów ręcznie i w określonych przypadkach z wykorzystaniem automatu, po wykonaniu określonej czynności w systemie

- przykłady automatów zidentyfikowanych przez Zamawiającego:

 zmiana z G -Przyjęta na G- Potwierdzona po wysłaniu potwierdzenia lub linku do zapłaty,

 zmiana z D- wyślij potwierdzenie na D - wysłano potwierdzeniepo wysłaniu potwierdzenia

 zmiana z G-Przyjęta na G- Anulowana po anulowaniu rezerwacji,

 zmiana z G-Przyjęta na G -Wykorzystana po wystawieniu dokumentów wstępu lub dokumentów sprzedaży,

 zmiana zG-Potwierdzona na G- Anulowana po anulowaniu rezerwacji,

 zmiana z G-Potwierdzona na G-Wykorzystana po wystawieniu dokumentów wstępu lub dokumentów sprzedaży,

- możliwość zapisania rezerwacji bez statusu dodatkowego,

-komunikaty systemowe (lub uprawnienia) dla użytkownika przy zmianie niektórych statusów np. zmiana statusu rezerwacji z wykorzystanej na przyjętą albo konflikt wykupiona i anulowana

- możliwość oznaczania rezerwacji, dla których należy wysłać fakturę proforma i ich wyszukania – statusy dodatkowe

- rozwojowo: każda rezerwacja ze wskazaniem oprowadzania automatycznie powoduje dodanie ceny usługi przewodnickiej, odpowiednio wg. zdefiniowanego cennika. Musi istnieć możliwość ręcznej korekty tej kwoty (np. przewodnik za zero złotych)

- rozwojowo: możliwość oznaczania poszczególnych rezerwacji biletów na zwiedzanie, lekcje i wydarzenia, tematów wydarzeń, tematów lekcji jako bezpłatne (nie są naliczane opłaty pomimo ich wybrania)

b) przeglądanie i filtrowanie rezerwacji

- system musi posiadać możliwość filtrowania listy rezerwacji po różnych polach rezerwacji pod kątem nieuzupełnienia tych pól

- system musi posiadać możliwość wyszukiwania, sortowania i filtrowania listy rezerwacji wg jednej lub kilku zmiennych (z formularza rezerwacji) np. po zakresie dat, statusach rezerwacji, nazwie kontrahenta (wpisanym ręcznie, po kodzie kontrahenta lub wybranym z kartoteki kontrahentów), po językach oprowadzania, po numerze imprezy, po numerze zamówienia, po numerze rezerwacji, po dacie utworzenia rezerwacji, postatusie dodatkowym (informacji opłacona/częściowo opłacona/ nieopłacona)

- system musi posiadać możliwość wyszukiwania, sortowania i filtrowania listy rezerwacji wg. informacji pochodzących z kartoteki kontrahentanp. rodzaj umowy którego nie ma w formularzu rezerwacji lub z konfiguracji wydarzenia np. lokalizacja wydarzenia, nazwa wydarzenia

- powinna istnieć możliwość sumowania liczby rezerwacji wg. powyższych kryteriów wyszukiwania, sortowania, filtrowania

- na liście rezerwacji muszą być widoczne przynajmniej: numer rezerwacji, data zwiedzania, godzina rozpoczęcia zwiedzania, nazwa kontrahenta, miejscowość kontrahenta, numer imprezy, uwagi, statusy rezerwacji, informacja na co jest rezerwacja (dobrze by był podgląd na wszystkie wystawy, informacja czy rezerwacja jest opłacona czy nie, czy wysłano fakturę proforma

- system musi pokazywać który dokument sprzedaży, zlecenia przewodnickiego / dla edukatora, nr biletu został wystawiony do danej rezerwacji, powiązany z daną rezerwacją (możliwość wyszukania)

- możliwość złożonego wyszukiwania kontrahentów (w rezerwacji czy na liście kontrahentów) np. po wpisaniu fragmentów nazwyczy miejscowości; system powinien wyszukiwać kontrahentów niezależnie czy są np. zapisane dwie spacje pomiędzy słowami czy jedna

- możliwość sortowania, filtrowania kontrahentów, wyszukiwania danych odwołując się do różnych zdefiniowanych pól w kartotece kontrahenta

- możliwość filtrowania rezerwacji według informacji o braku wystawienia dokumentów sprzedaży

c) zarządzanie przypisywaniem przewodników i edukatorów

- system powinien umożliwiać podgląd stanu zleceń przewodnickich/edukatorów w module rezerwacji i w portalu przewodnickim - możliwość podglądu i filtrowania zleceń przewodników/edukatorów (po językach, przewodnikach, przypisanych, nieprzypisanych zleceniach, zleceniach z usługą przewodnicką w cenie biletu, po dostępności wybranego przewodnika – z uwzględnieniem przypisanych zleceń i zajęć - niektórzy przewodnicy mogą być również edukatorami) według określonych przez użytkownika kryteriów

- możliwość wydrukowania zlecenia dla przewodnika/edukatora (z numerem zlecenia)

- musi być w systemie podgląd dostępnościprzewodników/edukatorów deklarujących dostępność w terminie danej rezerwacji (lub w zadanym okresie czasowym) dostępny również z poziomu

tworzonej rezerwacji (pokazujący zlecenia z przypisanymi i nieprzypisanymi przewodnikami/edukatorami, z możliwością filtrowania po językach)

- musi być możliwość odrębnego sprawdzania powyższych parametrów wg. rodzaju prowadzącego (pole z kartoteki edukator/przewodnik)

- możliwość przypisywania pojedynczych zleceń lub grupy zleceń jednemu przewodnikowi i edukatorowi korzystając z kartoteki przewodników / edukatorów z uwzględnieniem dyspozycyjności oraz języków w jakich dany przewodnik / edukator świadczy usługi

- możliwość przypisania przewodnika / edukatora pomimo braku dyspozycyjności lub zachodzenia zleceń na siebie (system ostrzega i pokazuje godziny zajętości)

- system musi mieć możliwość przypisania przewodnika nie spełniającego kryteriów dla danej grupy (certyfikat przewodnika czy edukatora na kartotece), pomimo sygnalizowanego przez system w tej sytuacji błędu

- system musi umożliwiać umieszczanie zleceń dla przewodników/edukatorów na platformie dla przewodników i edukatorów (przewodnik/edukator potwierdza przyjęcie zleceń, ma możliwość odrzucenia w zdefiniowanym terminie; preferowana jest możliwość wydrukowania tych informacji oraz wysłania ich pocztą elektroniczną; możliwość generowania zestawienia zleceń dla wybranego przewodnika w wybranym zakresie dat

- musi istnieć możliwość przypisania przewodnika / edukatora do rezerwacji bez jego akceptacji w portalu dla przewodników / edukatorów, ale system sygnalizuje błąd

- rozwojowo: System musi uwzględniać możliwość prowadzenia „giełdy zleceń przewodników/edukatorów”- by kryteria przypisywania przewodnika/edukatora do każdego zlecenia były transparentne, należy je zautomatyzować. Zlecenie wprowadzone na „giełdę” – np. przez znacznik przy rezerwacji trafia do przewodników/edukatorów, którzy w terminie zadanym w zleceniu są dostępni (na podstawie wcześniej zdefiniowanej dostępności) i spełniają kryteria rezerwacji (certyfikat na kartotece przewodnika / edukatora). Zlecenie otrzymuje osoba, która je jako pierwsza potwierdzi – potwierdzenie automatycznie powoduje wpisanie danego edukatora / przewodnika do rezerwacji. Równocześnie w systemie musi istnieć możliwość ręcznego przypisania przewodnika do danej rezerwacji (przy ręcznym przypisywaniu musi odnotowywać się fakt zlecenia danego przewodnika w portalu dla przewodników/edukatorów)

-możliwość przypisania, anulowania i modyfikowania zleceń z automatycznym powiadomieniem mailowym i w portalu przewodnickim przewodnika/edukatora

- system musi umożliwiać wygenerowanie raportu zmian w przydzielonych zleceniach i jego wysłanie (podgląd) do przewodnika/edukatora (w powiązaniu z portalem przewodnickim)

- system musi umożliwiać użytkownikowi anulowanie przypisanego do zlecenia przewodnika/edukatora i na jego miejsce przypisanie drugiego(również po wystawieniu dokumentu sprzedaży do rezerwacji)

- możliwość tworzenia rezerwacji na świadczenie usługi przewodnickiej bez sprzedaży biletów

- musi istnieć możliwość walidacji w recepcjach wystaw wykonania zlecenia przez przewodnika/edukatora

- możliwość potwierdzania w systemie i cofania potwierdzenia wykonania zlecenia przez przewodnika/edukatora

- możliwość przypisania więcej niż jednego prowadzącego do lekcji muzealnej

- system musi umożliwiać tworzenie i korygowanie harmonogramów dostępności przez pracownika Zamawiającego z odpowiednimi uprawnieniami oraz przez przewodnika/edukatora (w powiązaniu z portalem dla przewodników / edukatorów)

- system musi umożliwiać wygenerowanie w/w podglądu/wydruku zleceń bez przypisanego przewodnika/edukatora i wysłanie do akceptacji wybranej osoby

- powinna być możliwość zaznaczenia okresu niedyspozycyjności przewodników/ edukatorów, z zaznaczeniem przyczyny w uwagach

- musi pojawiać się data wysłania zlecenia przewodnikowi/ edukatorowi

d) funkcjonalności związane z rozliczaniem przewodników/edukatorów

- po zakończeniu miesiąca kalendarzowego lub innego cyklu rozliczeń (przypisanego do kartoteki kontrahenta) system przygotowuje i automatycznie wysyła mailem (na adres wskazany w kartotece) do kontrahentów rozliczenie wykonanych usług celem wystawienia na ich podstawie faktury / rachunku

- rozliczenia są numerowane wg następującego schematu: nr kolejny rozliczenia danego przewodnika lub edukatora / numer kontrahenta z bazy / rok świadczenia usług / symbol rozliczenia

- rozliczenie obejmuje wszystkie wykonane przez danego przewodnika / edukatora usługi (potwierdzone w recepcji lub ręcznie przez operatora / administratora) wycenione wg cennika danej usługi zdefiniowanego w systemie np. płatna usługa przewodnicka (klasyfikator usług przewodnickich), zajęcia edukacyjne itp.

- rozliczenie zawiera szczegółową listę usług ze wskazaniem: daty, godziny, wystawy, stawki za daną usługę, nazwę grupy, rodzaj zajęć, nazwę zajęć, oraz na osobnej stronie dane zagregowane wg. rodzaju zajęć i wystawy ze wskazaniem kwoty

- wysłane rozliczenia zapisywane są do rejestru rozliczeń wraz z informacją o dacie ich wysłania

- w rejestrze musi istnieć możliwość wskazania otrzymania rachunku / faktury od przewodnika / edukatora wraz z datą jej otrzymania oraz nr dokumentu, system musi umożliwiać wpisanie kilku faktur do jednego rozliczenia, w tym faktur korygujących - system przy rozliczeniu danego przewodnika / edukatora w rejestrze rozliczeń podpowiada z kartoteki kontrahenta czy dany kontrahent jest płatnikiem VAT

- rejestr wszystkich wystawionych przez przewodnika / edukatora faktur / rachunków jest dostępny z poziomu kartoteki kontrahenta, system umożliwia wyszukiwanie wystawionych faktur

/ rachunków wg daty, nr faktury, nr rozliczenia, wartości faktury / rachunku

- system umożliwia sumowanie wszystkich faktur/rachunków wystawionych przez konkretnego kontrahenta, w zadanym okresie, roku - wartość: brutto, netto, VAT itp., czyli zaangażowanie

- tworzenie zestawienia rozliczonych usług na podstawie faktur wystawionych przez przewodników/ edukatorów – rejestr wszystkich dokumentów zakupu

- po wpisaniu do systemu faktur odpowiadających co do kwoty wartości całego rozliczenia, rozliczenie otrzymuje automatycznie status rozliczony, z możliwością ręcznego wycofania i ponownego zaznaczenia parametru rozliczenia

- status umożliwia szybkie wskazanie / przefiltrowanie wszystkich, rozliczeń do których nie wpłynęły jeszcze faktury / rachunki

- z chwilą uruchomienia w pełni portalu przewodnickiego rozliczenie oprócz wysyłki mailem jest umieszczane w portalu na koncie danego przewodnika / edukatora

- możliwość wyszukania zlecenia po numerze np. który przewodnik był przypisany do takiego zlecenia

e) obsługa rezerwacji

- możliwość wysyłania potwierdzeń rezerwacji (w języku polskim lub angielskim) drogą elektroniczną do kontrahenta i ich wydrukowania (jedno potwierdzenie może zawierać jedną rezerwację lub grupę rezerwacji); możliwość ponownego wysyłania potwierdzeń rezerwacji

- możliwość tworzenia faktur proforma z rezerwacji i ich wysyłania pocztą elektroniczną oraz drukowania; możliwość ponownego wysyłania faktur proforma; możliwość zmodyfikowania rezerwacji i wysłania faktury proforma ze zmienionymi danymi

- możliwość dołączania do zbiorczych dokumentów sprzedaży obciążeń z anulowanych rezerwacji (po anulowanej rezerwacji opłata anulacyjna)

- funkcja kasy dla rezerwacji - możliwość sprzedaży towarów, rezerwacji zwiedzania, lekcji i innych wydarzeń (drukowania biletów, zleceń przewodnickich, zleceń edukatorów, paragonów, faktur, korygowania i zwracania towarów i usług – możliwość drukowania dokumentów w dniu zwiedzania, przed zwiedzaniem i po zwiedzaniu; możliwość drukowania części dokumentów i drukowania pozostałych w terminie późniejszym)

- możliwość sprzedania dodatkowych biletów na wydarzenie po wystawieniu dokumentu sprzedaży

- możliwość edytowania i zmiany liczby osób biorących udział w wydarzeniu w przypadku pobierania opłaty za zajęcia od grupy, a nie od uczestnika

- alert systemu, gdy mija termin opłacenia rezerwacji, na tej podstawie użytkownik decyduje co zrobić z rezerwacją, (pozostawić, anulować)

- alert systemu, gdy mija termin odbioru rezerwacji,na tej podstawie użytkownik decyduje co zrobić z rezerwacją, (pozostawić, anulować)

f) inne

- system powinien informować użytkowników w przypadku zmiany grafiku, limitów - powinien wspierać obsługę zmiany przyjętych uprzednio rezerwacji, przyszłościowo: system powinien podpowiadać użytkownikowi najlepszy sposób rozwiązania tego konfliktu

- system musi być intuicyjny i szybki w obsłudze, zwłaszcza w procesie rezerwacji i sprzedaży, liczba zakładek i kolejnych okien powinna być jak najmniejsza

- system musi działać sprawnie i efektywnie przy wielu stanowiskach pracujących jednocześnie (zwłaszcza rezerwacja i sprzedaż) i dużym obciążeniu danymi, w połączeniu z rezerwacją i sprzedażą online

- „zawieszenie” się systemu na jednym stanowisku nie może blokować rezerwacji i sprzedaży na innych stanowiskach

Wymagania pożądane:

- na ekranie z wykazem wystaw i dostępnością biletów są pokazane przekroczenia limitów

- niewykupione rezerwacje są wizualnie wyróżniane (np. inny kolor czcionki lub pojawia się przy nich symbol)

- możliwość automatycznego przesyłania wiadomości na zdefiniowany adres email informacji o anulowaniu rezerwacji lekcji/ zajęć muzealnych podczas procesu anulowania rezerwacji

g) raporty i zestawienia dostępne z modułu rezerwacji

- w celu analizy frekwencji - musi istnieć w systemie możliwość tworzenia zestawienia sprzedanych i wydanych biletów (normalne, ulgowe, bezpłatne, promocyjne /rabaty/, dla rodzajów zwiedzających; ilość i wartość) za okres z wyborem miejsca sprzedaży: wszystkie, dział rezerwacji, kasy, recepcje, automaty itd. (checkbox’y- wielokrotny wybór) i poszczególnych wystaw, lekcji muzealnych i innych wydarzeń (checkbox’y)

- możliwość tworzenia zestawień rezerwacji (wykaz, ilość i wartość) za okres wg statusów, przewodników, edukatorów, języków oprowadzania, kontrahenta, daty przyjęcia rezerwacji, rezerwacje w okresach zamkniętych; z podziałem na rezerwacje (wg. rodzaju usługi- grupy wydarzeń)

- możliwość tworzenia zestawienia pokazującego liczbę biletów promocyjnych normalnych, liczbę biletów promocyjnych ulgowych, wartość biletów przed promocją i po promocji

- możliwość tworzenia zestawień pokazujących liczbę i wartość biletów wg wszystkich klasyfikatorów razem i wg wydarzeń(checkbox’y); z podziałem narezerwacje (wg rodzaju usługi- grupy wydarzeń)

- możliwość tworzenia zestawienia pokazującego liczbę i wartość biletów sprzedanych np. młodzieży, obcokrajowcom (klasyfikator zwiedzających) (z podziałem na miejsce sprzedaży kasy, dział rezerwacji itd.)

- możliwość tworzenia zestawienia pokazującego liczbę biletów wg języka oprowadzania (z podziałem na zlecenia „na życzenie” i oprowadzanie z usługą przewodnicką w cenie biletu)

- możliwość tworzenia raportów frekwencyjnych: liczba osób razem, w tym razem w grupach zorganizowanych - w tym młodzież szkolna oraz liczba bezpłatnych; liczba osób razem, w tym w grupach zorganizowanych polskojęzycznych i obcojęzycznych oraz na wystawach stałych i czasowych; liczba osób razem, w tym młodzież szkolna z polski i z innych krajów; liczba osób razem w tym młodzież i obcokrajowcy (kombinacja różnych klasyfikatorów usług i zwiedzających)

- możliwość tworzenia zestawień przeprowadzonych wydarzeń muzealnych po grupie i typie wydarzenia, po temacie wydarzenia, za okres (ilość wydarzeń, uczestników i wartość)

- system musi umożliwiać wygenerowanie podglądu/ wydruku zrealizowanych zleceń dla wybranego przewodnika / edukatora lub grupy za zadany przedział czasowy wg rodzaju zleceń

(przewodnik, edukator) i rodzaju/kategorii zlecenia (zlecenie z usługą w cenie biletu, zlecenie na życzenie itp.)

4. PLATFORMA / PORTAL DLA PRZEWODNIKÓW / EDUKATORÓW - Wymagane funkcjonalności systemu wspierające koordynowanie współpracy z przewodnikami i edukatorami

Wymagania systemu modułu przewodnickiego:

- możliwość zaznaczania dostępności lub absencji (z zaznaczeniem przyczyny w uwagach) przez przewodnika/edukatora na jeden dzień lub na okresy czasu

- możliwość modyfikowania uprzednio zdefiniowanej dostępności przez przewodnika/edukatora, gdy nie ma w tym terminie przypisanego zlecenia

- możliwość zmiany danych do logowania przez przewodnika/edukatora – konto użytkownika tworzone z poziomu administratora

- zaakceptowane lub przypisane zlecenia są uwzględniane w grafiku dostępności danego edukatora/przewodnika (blokują terminy)

- możliwość wyświetlania „kalendarza” danego przewodnika/edukatora (dyspozycyjność i zlecenia)

- możliwość wygenerowania przez przewodnika/edukatora podglądu lub wydruku zleceń dla siebie za zadany przedział czasowy ze statusem realizacji, zarówno tych przez niego zaakceptowanych jak i tych „narzuconych” przez instytucję

- widoczność (tylko odczyt) kartoteki edukatora/przewodnika tylko dla danego przewodnika/edukatora

- możliwość sprawdzenia przez przewodnika/edukatora czy w systemie odnotowano wystawienie faktury (przewodnik/edukator jest powiązany z kartoteką kontrahentów)

- możliwość przesyłania (preferowane: automatycznie) przewodnikowi/edukatorowi informacji dotyczącej zleceń do których został przydzielony przewodnik/edukator

- rozwojowo (powtórzenie z modułu rezerwacja): System musi uwzględniać możliwość prowadzenia „giełdy zleceń przewodników/edukatorów”- Zlecenie wprowadzone na „giełdę” – np. przez znacznik przy rezerwacji trafia do przewodników/edukatorów, którzy w terminie zadanym w zleceniu są dostępni (na podstawie wcześniej zdefiniowanej dostępności) i spełniają kryteria rezerwacji (kategoria na kartotece). Zlecenie otrzymuje osoba, która je jako pierwsza potwierdzi– potwierdzenie automatycznie powoduje wpisanie danego edukatora / przewodnika do rezerwacji. Równocześnie w systemie musi istnieć możliwość ręcznego przypisania przewodnika do danej rezerwacji przez użytkownika – pracownika Zamawiającego (przy ręcznym przypisywaniu musi odnotowywać się fakt zlecenia danego przewodnika w portalu dla przewodników/edukatorów. Giełda musi zakładać przypisanie więcej niż jednego prowadzącego do danych zajęć, jeśli tak zdefiniowano ilość prowadzących dane wydarzenie

- możliwość korespondencji z przewodnikiem w portalu

- w portalu musi istnieć specjalne konto „tylko do odczytu” dla użytkownika- pracownika Zamawiającego do danych z wszystkich lub wybranych kont edukatorów/przewodników w portalu

- możliwość wyszukania dla użytkownika- pracownika Zamawiającego wszystkich edukatorów/ przewodników poprzez konkretny język oprowadzania i posiadane certyfikaty (kartoteka przewodnika/edukatora)

- możliwość powiadamiania edukatorów/ przewodników o zmianach w przydzielonych grupach do oprowadzania

- możliwość przyjęcia lub odrzucenia zlecenia przez przewodnika / edukatora w zdefiniowanym terminie. W przypadku odrzucenia konieczność podania przyczyny (słownik + pole na uwagi)

- możliwość zaakceptowania przez przewodnika/edukatora kilku zleceń jednocześnie

- możliwość odrzucenia zaakceptowanego wcześniej zlecenia tylko w ustalonym terminie przed planowaną datą realizacji usługi i z automatycznym powiadomieniem pracownika Zamawiającego (modułu rezerwacja), zmianę prowadzącego przy takiej rezerwacji musi potwierdzić pracownik Zamawiającego. Po zdefiniowanym terminie anulacji zmiana prowadzącego możliwa jest tylko przez pracownika Zamawiającego

- prowadzenie bazy danych informujących o odrzuconych zleceniach i o przyczynie odrzucenia (słownik + pole na uwagi)

- generowanie podsumowania - informacji jak jest realizowane założone minimum ilości grup w danym roku oprowadzania (parametr w kartotece kontrahenta) np. w formie „przypominajki” dostarczanej przewodnikowi/edukatorowi i operatorowi, pracownikowi zarządzającemu modułem (po zalogowaniu przewodnik/edukator musi widzieć liczbę odbytych oprowadzań

/zajęć edukacyjnych)

- preferowane- generowanie podsumowania - informacji jak jest realizowane założone minimum szkoleń i jakie szkolenia odbył przewodnik/edukator w danym roku oprowadzania (parametr w kartotece kontrahenta) np. w formie „przypominajki” dostarczanej przewodnikowi/edukatorowi i operatorowi, pracownikowi zarządzającemu modułem (po zalogowaniu przewodnik/edukator musi widzieć liczbę odbytych szkoleń); wymaga to dodania listy szkoleń dla przewodników/edukatorów

- powiadomienie pracownika Zamawiającego w przypadku przypisania się do danego oprowadzania dwóch przewodników/ edukatorów z wyjątkiem sytuacji, gdy więcej niż jeden jest zaplanowany

5. MODUŁ EDUKACJA - wymagane funkcjonalności systemu wspierające zarządzenie i koordynowanie lekcji muzealnych i innych wydarzeń edukacyjnych

System musi umożliwiać wyodrębnionej grupie pracowników Zamawiającego dostęp do poniższych funkcjonalności:

- (powtórzenie z modułu administracja – nadanie uprawnień pracownikom działu edukacji do części modułu administracja) system musi umożliwiać tworzenie pracownikom działu

edukacyjnego nowych wydarzeń edukacyjnych w systemie: definiowanie tematów oraz parametrów wydarzeń

- w przypadku wydarzeń i lekcji możliwość nie określania maksymalnej liczby osób biorących udział w wydarzeniu/lekcji

- (powtórzenie z modułu administracja – nadanie uprawnień pracownikom działu edukacji do części modułu administracja) prowadzenie rejestru edukatorów/przewodników – osób prowadzących zajęcia (imię, nazwisko, firma powiązana z bazą kontrahentów, numer telefonu, adres email, zakładanie konta dla edukatora do portalu dla przewodników i edukatorów /login, hasło/, numer i czas obowiązywania umowy, wybór – umowa o pracę/umowacywilnoprawna, uwagi), „informacje o certyfikatach” (język, grupa docelowa - kategoria wiekowa, certyfikat gold, rodzaj zajęć (specyfika), osoba która prowadzi zajęcia dla osób z niepełnosprawnościami (słownik)

- możliwość rozliczania edukatorów zatrudnionych na umowę cywilnoprawną (ewidencjonowanie faktur wystawionych przez edukatorów, wykaz przeprowadzonych zajęć (wszelkiego rodzaju, też oprowadzania) wraz z kwotą, datą i godziną lekcji/wydarzenia z możliwością filtrowania i wyszukiwania)

- możliwość generowania bieżącego podglądu rezerwacji wydarzeń edukacyjnych

6. INFORMACJA - wymagane funkcjonalności systemu wspierające dział informacji

- system musi umożliwiać wsparcie działu Informacji w procesach zarządzania informacją dla Zwiedzającego, zarządzania treściami tablic (różnymi na różnych ekranach)

- musi istnieć możliwość logowania się wielu użytkowników z właściwymi sobie, różnymi uprawnieniami (możliwość logowania na stanowisko Informacja Turystyczna, wg zdefiniowanych funkcjonalności i uprawnień, z możliwością ustawiania odrębnych uprawnień w ramach tego stanowiska dla różnych pracowników)

- musi istnieć podgląd dla Informacji ilości dostępnych biletów (wyświetlanie się limitów w dniu bieżącym i na inne dni) i ilości osób na konkretne godziny i całodniowej, także na oferowane języki oprowadzania na konkretne godziny

- automatyczne odświeżanie się limitów (widok dla pracownika)

- musi być też wgląd do harmonogramu wydarzeń z dostępną ilością biletów na dzień bieżący i na inne dni

- system musi umożliwiać zarządzanie treścią wyświetlaną na ekranach dostępnych dla Turystów:

 automatyczne odświeżanie się limitów (ekrany w kasach, totemy, małe ekrany przed kasami

 działanie tych urządzeń w sposób niezależny, ale możliwość również synchronizowania ich działania i wprowadzanych zmian

 dowolne definiowanie i tworzenie harmonogramów wyświetlanych slajdów

 możliwość dodawania i usuwania wystaw z widoku, zmiana kolejności, piktogramy, nazwy, limity, ceny

 możliwość dodawania komunikatów przez użytkownika, do wydarzenia i ogólnych

 możliwość wyświetlania obrazów np. mapa wzgórza, wyczerniania ekranów,

- System musi też na tym stanowisku umożliwiać druk dodatkowych kodów

7. MODUŁ RECEPCJA / PANEL ZARZĄDCZY - wymagane funkcjonalności systemu wspierające proces przyjmowania turystów w recepcjach poszczególnych ekspozycji, proces walidacji biletów i informacji o przebiegu ruchu turystycznego

- dostarczanie aktualnych (aktualizowanych na bieżąco) danych o ruchu turystycznym, opisanych poniżej

- system powinien wspomagać obsługę poszczególnych recepcji Zamku (różne wystawy), przyjmujących turystów na wystawy i walidujących bilety tzn. recepcja danej wystawy ma mieć dostęp do informacji o:

 liczbie dostępnych i sprzedanych biletów na danej wystawie

 lista aktualnych rezerwacji wg rodzaju i nazwy wydarzeń wraz ze wskazaniem liczby osób w każdej z nich i przydzielonych przewodnikach czy edukatorach, ze wskazaniem statusu rezerwacji, kontrahenta i uwag z rezerwacji

 z podziałem na godziny wejść

- system musi zapewnić stabilną i wydajną pracę recepcji nawet przy zakłóceniach dostępu do Internetu

- system musi zapewnić możliwość obsługiwania więcej niż jednej wystawy w jednej recepcji tzn. widok planowanych wejść dla dwóch lub więcej wystaw jednocześnie

- system musi umożliwiać w recepcjach proces sprzedaży biletów i innych produktów (rodzaje biletów i produktów definiowane dla poszczególnych punktów sprzedaży tj. poszczególnych recepcji wystaw, osobne magazyny towarów)

- system musi umożliwiać w recepcjach wystaw podgląd wszystkich wystaw (też innych niż obsługiwane, wtedy bez możliwości modyfikacji (jakie są rezerwacje, ilość dostępnych i sprzedanych biletów, godziny wejścia i rodzaje grup podgląd rezerwacji, wydarzeń, zajęć muzealnych itp.). Wydarzenia z walidowanymi biletami powinny „znikać” z pulpitu (z opcją podglądu).

- system musi umożliwiać dodawanie notatek przy różnych grupach

- system musi umożliwiać potwierdzanie wykonania usługi przewodnickiej (preferowane automatyczne), bądź przeprowadzenia lekcji przez przewodnika czy edukatora, informacja ta jest wykorzystywana następnie do rozliczenia finansowego usług świadczonych przez te podmioty

- system musi mieć możliwość zbierania danych o wykorzystanych biletach (raportowanie)

- system musi umożliwiać prostą, intuicyjną i niezawodną walidację w poszczególnych recepcjach różnych wystaw, wszelkich biletów zakupionych lub wydanych zwiedzającym (w przypadku wydarzeń darmowych) we wszystkich kanałach, w tym zleceń dla przewodników/ edukatorów

 czytelne i wyraźne informacje na czytniku

 jeden czytnik – według zdefiniowanej jednej strefy walidacji

 Automatyczna walidacja wg zdefiniowanego czasu ważności biletu, możliwość ręcznej akceptacji biletu spoza zdefiniowanego zakresu ważności przez operatorapo sygnalizowaniu błędu

 możliwość odczytania biletu w każdej wersji (screen, e-mail, forma papierowa)

 możliwość pracy w trybie off-line

 informacja na urządzeniu walidującym o bilecie czy ważny / zwrócony / wykorzystany, na jaką godzinę i na jaką jest wystawę, ze wskazaniem liczby osób

- musi istnieć możliwość zwalidowania każdego biletu indywidualnie lub jednocześnie całej grupy jeśli drukowany był bilet grupowy

Panel informacji o przebiegu ruchu turystycznego

- dostęp on-line do aktualnych, wybranych informacji (możliwość tworzenia różnych widoków dla różnych użytkowników) o przebiegu ruchu turystycznego bez konieczności logowania do aplikacji czy generowania wielu raportów, chyba że aplikacja przewiduje dostęp do danych dla wybranych użytkowników

- możliwość przeglądania na ekranie (z możliwością filtrowania) liczby biletów zarezerwowanych (wszystkich), liczby biletów zarezerwowanych na poczet wydarzeń edukacyjnych, liczby biletów sprzedanych przez kasy, liczby sprzedanych biletów normalnych, ulgowych, bezpłatnych, (z podziałem na kasy, dział rezerwacji, recepcje, online, automaty), liczby dostępnych biletów na poszczególne wydarzenia

- możliwość przeglądania (z możliwością filtrowania) na ekranie transakcji sprzedaży z wszystkich miejsc sprzedaży (pokazującymi szczegóły transakcji takie jak data i godzina sprzedaży, osoba wystawiająca, wydarzenia, godziny wejść, liczby i rodzaje biletów, język oprowadzania, towary, rabaty)

- podgląd zalogowanych użytkowników systemu

8. MODUŁ SPRZEDAŻY ON-LINE

Intencją Zamawiającego jest doprowadzenie w ostatnim etapie wdrożenia do funkcjonowania systemu sprzedaży biletów on-line jako jednego z kanałów sprzedaży zintegrowanego z pozostałymi funkcjonalnościami systemu w szczególności z: konfiguracją wydarzeń do sprzedaży, cennikami, limitami na poszczególnych wydarzeniach, kartotek kontrahentów, kontrolą biletów na recepcjach, raportowaniem, przygotowaniem danych do systemu finansowo-księgowego.

System będzie obejmował sprzedaż dla klientów indywidualnych i rezerwacje grupowe on-line.

Zamawiający na chwilę obecną posiada odrębny system sprzedaży biletów on-line, niezależny od systemu obsługującego pozostałe kanały i procesy sprzedaży. Zamawiający bierze pod uwagę zarówno zintegrowanie istniejącego sklepu on-line z systemem, jak też wykorzystanie istniejącego modułu on-line w systemie, albo stworzenie nowego, dedykowanego modułu on-line w systemie.

Moduł sprzedaży biletów on-line musi spełniać x.xx. poniższe wymagania:

- możliwość samodzielnego definiowania które z wydarzeń / terminów będzie udostępnione do sprzedaży on-line

- możliwość zakończenia sprzedaży on-line biletów na dane wydarzenie / termin niezależnie od ilości sprzedanych dotychczas biletów

- możliwość zbiorczego „wyłączania” i „włączania” wydarzeń/terminów z publikacji do sprzedaży on- line niezależnie od ilości sprzedanych biletów

- możliwość dodania opisu wydarzeń wraz z grafiką przez użytkownika systemu, możliwość ich modyfikacji

- możliwość definiowania odrębnego cennika sprzedaży biletów on-line, możliwa sytuacja, że to samo wydarzenie sprzedawane on-line będzie miało inną cenę przy sprzedaży w kasie

- możliwość ustawienia maksymalnej liczby biletów do zakupu w jednej transakcji, na jednym wydarzeniu i tej samej godzinie

- możliwość wskazania/przeznaczenia z całkowitej dostępnej w systemie puli biletów na dane wydarzenie/termin liczby biletów udostępnionych do sprzedaży on-line, możliwa sytuacja gdy tylko część biletów z puli jest przekazywana do sprzedaży on-line

- możliwość ustawienia przez Zamawiającego, indywidulnie dla każdego wydarzenia/terminu datyrozpoczęcia i zakończenia sprzedaży biletów przed datą zwiedzania

- możliwość sprzedaży miejsc numerowanych na wybrane wydarzenia

- zbieranie wybranych danych o kupującym w zależności od faktu założenia konta w systemie: e-mail, nr telefonu, zgoda na przesyłanie materiałów promocyjnych, … (kartoteka kontrahenta)

- możliwość przesyłania materiałów promocyjnych z systemu do kupujących, którzy wyrazili na to zgodę w procesie zakupu, pojedynczo i zbiorczo do wielu kupujących

- przygotowanie automatycznego mechanizmu anonimizacjidanych kontrahenta po spełnieniu określonych wymagań tj. daty ostatniej transakcji i rodzaju wystawionego dokumentu sprzedaży

- możliwość wyrejestrowania kupującego tj. przekazanie formularzem przez niego prośby o usunięcie danych osobowych z bazy i wycofania zgody na przesyłanie materiałów promocyjnych

- możliwość samodzielnego definiowania przez Zamawiającego wzorów komunikacji z kupującym w procesie zakupu on-line, zmiennej w zależności od wydarzeń

- możliwość definiowania treści komunikacji e-mail dla grupy adresów uczestników, w zależności od zakupionego przez nich wydarzenia (przy ręcznej i zdefiniowanej, automatycznej wysyłce)

- przekierowanie na stronę zakupu biletów będzie odbywać się przez strony internetowe Zamawiającego tj. Zamku Królewskiego na Wawelu, Zamku w Pieskowej Skale i Dworu w Stryszowie

- projekt wizualny strony internetowej musi zostać uzgodniony z Zamawiającym

- możliwość umieszczania samodzielnie na stronie sprzedaży on-line krótkich komunikatów tekstowych dla kupującego np. informacji o czasowym zwieszeniu sprzedaży biletów on-line

- dwujęzyczna wersja interfejsu kupującego - wersja polska i angielska – zarówno treści jak i komunikaty systemowe jako odrębne wersje, możliwość wyboru przez kupującego wersji językowej interfejsu

- możliwość udostępnienia wybranych wydarzeń / terminów tylko w jednej wersji językowej

- możliwość wstawienia linków do innych podstron np. zasad zwiedzania obowiązujących u Zamawiającego, regulaminu sprzedaży itp.; linki muszą być możliwe do dodania zarówno na etapie rozpoczynania transakcji zakupu jak i przy wyborze biletu na konkretne wydarzenie

- dopasowanie języka sklepu do języka przeglądarki

- spełnienie norm WCAG.2.0

- aplikacja zaprojektowana w technice responsywnej RWD

- aplikacja musi działać na urządzeniach mobilnych wykorzystujących systemy: IOS, Android, Windows i Linux

- możliwość zobligowania kupującego do zaznaczenia opcji zapoznania się z regulaminami (sprzedaży, zwiedzania, informacją o zasadach przetwarzania danych osobowych, itp.)

- możliwość zaznaczenia przez kupującego prośby o wystawienie faktury z przejściem do kroku z wypełnieniem danych oraz automatyczne wystawienie i wysyłka faktury na podany adres e-mail

- dla każdej transakcji sprawdzenie czy dany kontrahent istnieje i jeśli nie istnieje założenie nowej kartoteki kontrahenta

- obsługa różnych rodzajów biletów (normalnych, ulgowych, bezpłatnych), w tym biletów rodzinnych

- możliwość wydawania biletów dla wydarzeń bezpłatnych

- możliwość zastosowania dodatkowych słowników z informacjami do wyboru przy zakupie biletu przez kupującego (klasyfikatory zwiedzających zdefiniowane w systemie np. tytuł ulgi, również drukowany na bilecie)

- wymagana kolejność przechodzenia przez system przez kupującego – wybór: daty /lokalizacji / grupy wydarzeń / wydarzenia / godziny

- kalendarz do wyboru dnia zwiedzania z „wyszarzeniem/dezaktywacją” terminów na które brak biletów w sprzedaży, preferowane: pokazanie pierwszego wolnego terminu na dane wydarzenie

- informacja dla kupującego o liczbie dostępnych biletów na dane wydarzenie i termin

- informacja dla kupującego o zakończeniu sprzedaży na dane wydarzenie/termin lub wyczerpaniu się puli biletów do sprzedaży

- określony czas na sfinalizowanie transakcji i płatność – po tym czasie bilety wracają do dostępnej puli

- możliwość wyboru wielu różnych wydarzeń przez kupującego w ramach jednej transakcji

- informacja/podpowiedź kolejnych wydarzeń i terminów dostępnych do zakupu po wyborze danego terminu, jak również podpowiadanie powiązanych wydawnictw i innych towarów

- „koszyk”, czyli ilość i wartość wybranych biletów, widoczny i dostępny z każdego poziomu procesu zakupu

- komunikat o kolizji biletów przy kupnie w jednej transakcji biletów na kilka wydarzeń, które zachodzą na siebie czasowo (na podstawie godziny wstępu i średniego czasu zwiedzania zdefiniowanych w konfiguracji wydarzenia), nie blokuje sprzedaży

- pełne podsumowanie transakcji dla kupującego (dla każdego wydarzenia osobno wskazana godzina, cena i czas zwiedzania plus podsumowanie kwoty do zapłaty i łącznego czasu zwiedzania)

- integracja z pośrednikiem płatności w zakresie płatności za zakupione bilety i zwrotu środków za zwrócone bilety

- aktualna informacja w systemie na temat opłaconych zamówień (status)

- możliwość zrealizowania płatności za zamówienie poprzez posiadany voucher

- możliwość zastosowania innego rodzaju wydruku biletów niż w kasie dla tego samego wydarzenia

- wydruk biletów pojedynczo lub zbiorczo - do wyboru przez kupującego, autopodpowiadanie zbiorczego

- możliwość ponownego pobrania / przesłania biletu dla kupującego i rejestracja w systemie daty i godziny ponownej wysyłki

- możliwość zakupu biletu jako prezentu

- możliwość przedstawienia biletu do walidacji na ekranie urządzeń mobilnych z systemem Android, IOS lub Windows

- obsługa pojedynczych zwrotów przez Xxxxxxxxxxxxx, który rozpoczyna procedurę zwrotu lub na podstawie formularza zwrotów wypełnionego przez kupującego:

 kupujący zgłasza przez system chęć zwrotu biletu (w narzuconym terminie, jeśli jest po terminie,system wysyła klientowi odpowiedni komunikat )

 Zamawiający po otrzymaniu zgłoszenia zwrotu potwierdza go lub odrzuca ręcznie

 po akceptacji zwrotu przez Zamawiającego, system generuje informację zwrotną do kupującego – mail i sms (jeżeli został podany)

 system automatycznie zleca zwrot pieniędzy przez pośrednika płatności

 system automatycznie wystawia korektę dokumentu sprzedaży

 system powiększa pulę dostępnych biletów na dany termin w puli biletów on-line

- obsługa wielu zwrotów (masowe zwroty) inicjowana przez Zamawiającego (np. w przypadku awarii)

– kolejność kroków:

 filtrowanie wielu transakcji sprzedaży biletów on-line po datach/wydarzeniach/godzinach

 zaznaczenie wszystkich wyników filtrowania z możliwością odznaczenia pojedynczych transakcji

 wysyłka e-mail i sms (jeżeli został podany) do wszystkich kupujących

 system automatycznie zleca zwroty pieniędzy przez pośrednika płatności

 system automatycznie wystawia korekty dokumentów sprzedaży

 system powiększa pulę dostępnych biletów na dany termin, (termin będzie wyłączony przez Zamawiającego ze sprzedaży, więc nie będzie możliwości zakupienia kolejnych biletów)

- preferowane: wsparcie kupującego przez Oferenta w procesie zakupu biletu

- możliwość filtrowania zamówień / kontrahentów, którzy zakupili bilety on-line na konkretne wydarzenie/termin

- możliwość sprawdzenia przez Xxxxxxxxxxxxx poprawności procesu wysyłki biletu do kupującego wraz z informacją o dacie i godzinie jego wysyłki

- niesprzedane (zwrócone) bilety w systemie on-line, po zakończeniu daty udostępniania, powiększają pulę wszystkich dostępnych biletów na dane wydarzenie/termin w pozostałych kanałach sprzedaży (automat)

9. GOSPODARKA MAGAZYNOWA I EKSPORT DANYCH DO SYTEMU FINANSOWO- KSIĘGOWEGO - wymagane funkcjonalności systemu wspierające proces rozliczeń księgowych

- możliwość prowadzenia gospodarki magazynowej w stopniu umożliwiającym minimum ewidencję stanów magazynowych i określenie wartości rozchodowanych produktów

- odrębne lub wspólne (w zależności od zdefiniowania) magazyny dla każdego z kilku punktów sprzedaży (recepcje poszczególnych wystaw, informacja, kasa itd.)

- odrębna od systemu finansowo-księgowego baza towarów i usług – zakres przechowywanych danych:

 indeks produktu,

 nazwa produktu

 cena sprzedaży produktu

 cena zakupu produktu – wykorzystywana do rozliczenia wartości sprzedanych produktów metodą FIFO, raport wbudowany w system

 kod księgowy, wykorzystywany następnie do sporządzenia pliku do importu danych do systemu finansowo-księgowego, indywidualny kod dla każdego produktu / usługi

- nowe indeksy towarowe zakładane na poziomie bazy centralnej nie przez poszczególne punkty sprzedaży

- jedyne możliwe wydania z magazynu: wydanie do sprzedaży i zwrot na magazyn główny

- przyjęcie towarów na magazyn wraz z ich ceną zakupu, która następnie będzie wykorzystywana do rozliczeń rozchodów

- raportowanie stanów magazynowych z informacją o: nazwie i indeksie poszczególnych produktów, ilości, wartości w cenie zakupu

- raportowanie rozchodów produktów w podziale na rodzaje rozchodów (sprzedaż, zwrot sprzedaży, zwrot na magazyn) z informacją o : ilości, wartości w cenie zakupu, nazwie i indeksie poszczególnych produktów oraz nr dokumentu sprzedaży powiązanym z konkretnym rozchodem – celem przekazania do rozliczeń księgowych

- centralny cennik sprzedaży produktów – brak możliwości sprzedania produktu z inną ceną niż w cenniku z uwzględnieniem dopuszczalnych zniżek / rabatów

- brak możliwości sprzedaży produktów poniżej stanu magazynowego 0

- automatyczne generowanie przez system raz dziennie (np. w nocy), pliku do importu danych sprzedażowych do systemu finansowo-księgowego, dokładny zakres danych i format pliku do określenia na etapie wdrożenia, minimalny zakres danych:

 wszystkie faktury, faktury do paragonu i ich korekty uwzględniane 1:1

 zakres min.:

- nagłówek dokumentu: rodzaj dokumentu, data wystawienia, data sprzedaży, data płatności, forma płatności, nr dokumentu, nr dokumentu korygowanego, nr paragonu (jeśli faktura do paragonu), nr kontrahenta, nazwa kontrahenta, adres kontrahenta, NIP kontrahenta

- pozycje dokumentu: kod księgowy, nazwa produktu/ usługi, indeks produktu /usługi, ilość, waluta, stawka VAT, wartość netto, wartość brutto, wartość VAT, przyczyna korekty?

 paragony i korekty do paragonów w formie dziennych agregatów

- plik importu będzie automatycznie przesyłany na wskazany adres e-mail lub umieszczany w wyznaczonym miejscu na serwerze Zamawiającego

- dane o ruchu magazynowym ewidencjonowane będą w systemie finansowo-księgowym z wykorzystaniem danych z wygenerowanych raportów

10. RAPORTY - Wymagane funkcjonalności systemu wspierające proces raportowania

- każdy raport musi być dostępny do eksportu w formacie XLS

- każdy raport musi mieć możliwość wydruku w czytelnym formularzu PDF z zaznaczeniem daty, godziny wydruku, użytkownika oraz wersji definicji formularza raportu

- możliwość definiowania własnych raportów na podstawie danych dostępnych w systemie, w tym stosowanych klasyfikatorów

- możliwość nadania uprawnień do tworzenia nowych raportów i modyfikacji istniejących raportów

- zdefiniowane wbudowane raporty z opcją filtrowania i grupowania danych – część z raportów opisano już w niniejszym dokumencie:

 raport kasowy dzienny w podziale na formy płatności i rodzaje dokumentów do rozliczenia kasy sprzedaży z kasą główną instytucji – opisany w części kasowej dokumentu

 raport kasowy – podgląd kasy w ciągu dnia – opisany w części kasowej dokumentu

 raport zwrotów sprzedaży z informacją o powodzie zwrotu – opisany w części kasowej dokumentu

 raport sprzedaży z możliwością wybrania zakresu dat, grupy usług / towarów, punktu sprzedaży, rodzaju dokumentu, kanału sprzedaży, konkretnego produktu, wydarzenia z wykorzystaniem różnych klasyfikatorów usług i zwiedzających – opisany w części rezerwacyjnej

 lista wystawionych dokumentów sprzedaży z możliwością wybrania zakresu dat, kanału sprzedaży, stanowiska sprzedaży, rodzajów dokumentów ze wskazaniem daty, nr dokumentu, nr dokumentu korygowanego, wartości netto / brutto / VAT, stawka VAT, nazwy kontrahenta, formy płatności – opisany w części rezerwacyjnej

 frekwencja, rozumiana jako ilość sprzedanych i wydanych bezpłatnych biletów w podziale na różne klasyfikatory z uwzględnieniem łączenia wystaw w trasy w ramach jednego biletu

opisane w części administracyjnej niniejszego dokumentu -funkcjonalność opisana w części rezerwacyjnej

 raporty sprzedaży wg kontrahentów i wg produktów / usług i wartość netto

 raport ilości zużytych blankietów biletów wg stanowisk sprzedaży

 raport sprzedanych biletów wg rodzajów biletów

 raport wykorzystanych biletów (walidacja w recepcji wystaw) wg dat, rodzajów, stref walidacji (możliwy jeden produkt kilka wystaw)

 raportowanie zrealizowanych zleceń na poszczególnych przewodników / edukatorów w zadanym okresie wraz z ich wartością – rodzaj usługi / trasa / temat / język / termin / wartość rozliczenia / cena sprzedaży – opisany w części dotyczącej rozliczeń przewodników

 raport zrealizowanych lekcji muzealnych w zadanym okresie z podziałem na tematy, klasyfikatory zwiedzających i prowadzących ze wskazaniem liczby uczestników – wykorzystanie klasyfikatorów usług i zwiedzających – funkcjonalność opisana w części rezerwacyjnej

 raport zrealizowanych wydarzeń muzealnych w zadanym okresie z podziałem na rodzaje, tematy, ze wskazaniem liczby uczestników – wykorzystanie klasyfikatorów usług i zwiedzających – funkcjonalność opisana w części rezerwacyjnej

 raport stanów magazynowych – ilość, wartość produktów w wybranych (jeden / kilka / wszystkich) magazynach

 raport rozchodów z magazynów wg stanowiska, produktu z wartością rozchodu celem przekazania do rozliczeń księgowych

 raport rezerwacji wg daty wydarzenia w podziale na statusy, ilość uczestników, język, kontrahenta, wydarzenie / trasę, przewodnika/edukatora? – opisany w części dotyczącej funkcjonalności rezerwacji

 raport wykorzystanych terminów – sprzedane / wykorzystane / dostępne

 raport anulowanych rezerwacji w podziale na kontrahentów

- zamawiający zastrzega sobie możliwość zlecenia 10 dodatkowych raportów wbudowanych w system poza tymi wspomnianymi w całym niniejszym dokumencie do przygotowania w oparciu o dane znajdujące się już bazie

- każdy z wyników filtrowania danych w systemie powinien mieć możliwość eksportu do XLS

11. Wymagane funkcjonalności systemu dotyczące wszystkich modułów

- możliwość dodawania, modyfikowania, usuwania, dezaktywowania, aktywowania danych

- możliwość sortowania, filtrowania, wyszukiwania danych według wybranych kryteriów (również wybranych równocześnie) i w celu ich wyszukiwania i przeprowadzenia różnych operacji