B. TECHNISCHE VOORSCHRIFTEN

Stadsbestuur Sint-Niklaas Dienst logistiek Industriepark Noord 4 9100 Sint-Niklaas Tel. 03 778 35 51 [email protected] BESTEK 2015-40/LOG/hard- en software parkeerbeheer/JG-AL-CQ-VW ONDERHANDELINGSPROCEDURE MET VOORAFGAANDE BEKENDMAKING VOOR HET LEVEREN , PLAATSEN EN IN DIENST STELLEN VAN HARD- EN SOFTWARE VOOR HET PARKEERBEHEER EN DE GEMEENTELIJKE ADMINISTRATIEVE SANCTIES VOOR REKENING VAN HET STADSBESTUUR VAN SINT-NIKLAAS

B.

TECHNISCHE VOORSCHRIFTEN

Voorwerp van de opdracht Leveren, plaatsen en in dienst stellen van hard- en software voor het parkeerbeheer en de gemeentelijke administratieve sancties. De opdracht bestaat uit drie percelen: PERCEEL 1: Leveren, plaatsen en in dienst stellen van nieuwe hard- en software, front- en backend voor het parkeerbeheer, omvattende: - Handterminals/PDA’s voor het toezicht op de geparkeerde voertuigen (voorzien voor eventuele uitbreidingen in de toekomst; controles op openbaar domein, sluikstorten, leegstand edm) - Front-end software voor het toezicht op geparkeerde voertuigen - Backoffice software voor de afhandeling en de opvolging van de retributies - Backoffice software voor het beheer van de bewonerskaarten (on-street) en andere abonnementen - Onderhoudscontract na garantieperiode - Opleiding PERCEEL 2: Leveren, plaatsen en in dienst stellen van hardware, front-end software en koppeling met backoffice: - voor het beheer van gemeentelijke administratieve sancties (GAS) via een koppeling met de CIPAL-applicatie Ariadne (CSV-bestand en bijlagen) - inclusief installatie & opleiding front-office en koppeling - inclusief onderhoudscontract na garantieperiode PERCEEL 3: Ontwerpen, leveren, plaatsen en in dienst stellen van een systeem voor het digitaal uitreiken van bewonerskaarten en andere abonnementen (on-street): - inclusief link tussen deze oplossing en backend software parkeerbeheer - inclusief installatie & opleiding front-office en koppeling - inclusief onderhoudscontract na garantieperiode De bedoeling van dit bestek is dat de te leveren onderdelen van de opdracht zowel de huidige gewenste functionaliteiten afdekken, alsook klaar zijn om naadloos de huidige vernieuwende trends rond parkeren te integreren. De aangeboden oplossing dient dus voldoende performant te zijn om alle onderdelen qua volume te doen toenemen in de toekomst en is ook in staat om nieuwe toepassingen probleemloos te integreren (mobiel betalen, apps, edm……).

9100 Sint-Niklaas

2015-41/LOG/hard- en software parkeerbeheer/JG-AL-CQ-VW Deel B bestek

Pagina 1 van 49

PERCEEL 1 1. Op weg naar een geïntegreerd en duurzaam parkeerbeleid in Sint-Niklaas. In Sint-Niklaas zijn er 7 zones bewonersparkeren, 1884 bovengrondse betalende parkeerplaatsen en 1757 bovengrondse parkeerplaatsen schijf verplicht ingevoerd. Dit betekent dat er op dit ogenblik 3641 bovengrondse parkeerplaatsen een parkeerregime kennen tussen 9 uur ’s morgens en 18 uur ’s avonds van maandag tot en met zaterdag. De stad beschikt over 127 parkeerautomaten, hiervan zijn er op dit ogenblik 120 in dienst. De 7 parkeerautomaten uit de Stationsstraat zijn sinds begin dit jaar weggenomen door het invoeren van het voetgangersgebied in deze straat. Van de 127 parkeerautomaten zijn er 112 geautomatiseerd. Enkel de parkeerautomaten in de Spoorweglaan, de Knaptandstraat en de Truweelstraat zijn nog niet geautomatiseerd. Aan de automaten kan enkel betaald worden met muntstukken. De gemeenteraad heeft in zitting van 19-12-2013 de belasting op parkeren gewijzigd. Vanaf 0101-2014 zijn het parkeertarief 2 (betalend parkeren) en het forfaitair tarief (blauwe zone parkeren), de zogenaamde ‘parkeerboetes’, opgetrokken van 15,00 EUR naar 25,00 EUR. Een overzicht van het mobiliteitsbeleid in de Stad Sint-Niklaas kan de inschrijver terugvinden via deze link: http://www.sint-niklaas.be/sites/default/files/ontwerp_mobiliteitsplan.pdf Een overzicht van de huidige en toekomstige reglementering van blauwe zone, betalend parkeren en producten voor parkeren wordt onderstaand opgelijst en wordt toegelicht via de stedelijke reglementen in bijlagen 3 tem 5. De inschrijver gaat na of zijn voorstel alle randvoorwaarden en modaliteiten en dergelijke meer van deze reglementen kan verwerken en licht duidelijk toe in zijn voorstel hoe dit praktisch zal gerealiseerd worden: -

Reglement betalend parkeren Reglement blauwe zone Huidig belastings- en toekomstige retributiereglement Reglement 1e en 2e bewonerskaart Week- maand- en kwartaalabonnementen Werkdag maand – en kwartaalabonnementen Halve werkdag abonnement per maand Abonnement marktkramers Abonnement bouwwerken Abonnement maand – en kwartaal on street voor personeel Dagtickets

9100 Sint-Niklaas


Pagina 2 van 49

2. Algemeen De aangeboden oplossingen voor front en backoffice software worden bij voorkeur gehost in een Cloud-omgeving voorzien van een beveiligde toegang. Om een eenvoudige integratie met andere, externe of interne systemen mogelijk te maken, bevestigt de leverancier expliciet in zijn offerte dat de gegevens op een eenvoudige wijze en met behulp van APIs (Application Programming Interface) en data-exports/imports in de gekende formaten ontsloten kunnen worden. Hiervoor beschikt de software over: a. b. c.

een standaard oplossing (ja/nee?): omschrijf incl. screen shots maatwerk (ja/nee?): omschrijf niet mogelijk: omschrijf

Alle software die aangeboden zal worden dient dus op deze omgeving te kunnen werken. De Inschrijver voorziet in zijn antwoord een schematisch overzicht van de architectuur om dit toe te lichten. Het systeem dient minimaal 95 % te werken, 7 dagen op 7. Hiervoor wordt een SLA afgesproken met de Stad Sint-Niklaas. De inschrijver geeft aan welk “Service Level Agreement” wordt aangeboden ter ondersteuning van de aangeboden oplossing. De inschrijver voegt het bijhorende Service Level Agreement bij de offerte. Indien er meerdere SLA mogelijkheden zijn, worden deze opgelijst met vermelding van prijsaspect. De toegepaste politiek betreffende change– en release management moet worden verduidelijkt. Wordt er bv. gewerkt met een test- en productieomgeving? Aanpak van uitvoeren updates/upgrades. De helpdesk/servicedesk moet ondersteuning geven in de Nederlandse taal. Belangrijke te verduidelijken aspecten binnen de SLA zijn:  Gegarandeerde beschikbaarheid (%)  Service window  Maintenance window  Beschikbaarheid van service desk  Minimale gegarandeerde bandbreedte internet link (download en upload)  Uitvoeringstermijnen “Changes” De inschrijver geeft een beschrijving van de gegarandeerde technische infrastructuur en bijhorende back-up oplossing alsook de monitoring-aspecten die leiden tot de aangeboden SLA. De software moet compatibel zijn met de standaardconfiguratie van de eindgebruikers. Deze staat beschreven in het document in bijlage 7. De inschrijver bevestigt dat de software compatibel is met de gevirtualiseerde omgeving van Sint-Niklaas waarbij elke medewerker werkt met een Thin Client. De inschrijver omschrijft in zijn antwoord alle technische kenmerken en vereisten van de software en de hardware.

9100 Sint-Niklaas


Pagina 3 van 49

De toepassing moet via het web toegankelijk zijn.

a. Overname toekomstige gegevens: Indien de mobiliteitswinkel in de toekomst beslist om met een ander software pakket te werken, moeten alle gegevens op een duidelijke manier kunnen geëxporteerd worden. Dit wil zeggen dat de database structuur van de aangeboden software en bijhorende gegevens moet kunnen overgenomen worden door een andere leverancier.

b. Taal De taal van de software is Nederlands. Handleidingen, documentatie en informatie worden ter beschikking gesteld in het Nederlands. Helpfuncties in de programmatuur zijn in het Nederlands ter beschikking. Gebruikers gebonden foutmeldingen en controleboodschappen verschijnen steeds in het Nederlands.

c. Intellectuele eigendom van de verworven data Alle verworven data blijft eigendom van de opdrachtgever. De opdrachtnemer mag geenszins gebruik maken van deze data alsook de verspreiding ervan zonder voorafgaande schriftelijke toestemming van de opdrachtgever.

d. Look & Feel De ‘schermen’ van de software zijn overzichtelijk, gebruiksvriendelijk, duidelijk, eenvoudig en binnen de volledige software op dezelfde manier opgezet. De inschrijver geeft een overzicht van de belangrijkste schermen in de offerte. De ‘schermen’ van de software kunnen naar eigen wensen aangepast worden. De inschrijver beschrijft de mogelijkheden voor wat betreft de aanpasbaarheid van de ‘look & feel’ ( integreren huisstijl, kleurgebruik, lettergrootte,...). De huisstijl van Sint-Niklaas wordt omschreven in bijlage 2. De inschrijver geeft ook aan welke andere elementen van de software ( functies, schermen, teksten, tabellen, ...) configureerbaar zijn.

e. Gebruiksvriendelijkheid Invoer van specifieke velden zoals datum, dient door de gehele software op de zelfde manier plaats te vinden. Functietoetsen ( bv. opslaan, afdrukken, annuleren, ed.) zijn eenvoudig te interpreteren. Op elke plaats in het pakket zijn deze op dezelfde wijze gebruikt en gedefinieerd. Deze sluiten zoveel mogelijk aan bij de standaard ‘Windows’ functietoetsen De software biedt de mogelijkheid om een configureerbare ‘helptekst’ te voorzien bij de belangrijkste functies. Dit is toelichting die verschijnt zodra je met je muis op een tekst, icoon of menu gaat staan (mouse over).

9100 Sint-Niklaas


Pagina 4 van 49

Bij iedere foutmelding die gemeld wordt aan de gebruiker moet de context waarin de fout is opgetreden duidelijk zijn. Er moet vermeld worden welke actie niet kon worden uitgevoerd, en hoe het probleem kan worden opgelost.

3. Gewenste situatie na implementatie nieuwe software parkeerbeheer. Onderstaand zijn de minimale vereisten weergegeven van de gewenste werking en communicatie over en weer tussen de verschillende onderdelen. Deze samenvatting geeft een overzicht. Alle details over de specifieke onderdelen worden verder uitgebreid omschreven in het bestek. a.

De handterminals van de parkeerwachters communiceren realtime met de backoffice software. De opgemaakte retributies, de opgemaakte vaststellingen van GAS-inbreuken en de uitgevoerde controles worden meteen doorgestuurd naar de backoffice software retributies, samen met de bijhorende foto’s.

b.

Tijdens de controles van kentekens op straat moeten meerdere databases en/of webservices geraadpleegd kunnen worden om te kunnen nagaan of het voertuig met betreffend kenteken beschikt over een E-ticket en/of een geldige gemeentelijke parkeerkaart: i. De leverancier van de E-applicatie ligt nog niet vast doch de opdrachtgevende overheid verwacht dat de voorgestelde software kan communiceren met de meest “courante” leveranciers van E-ticketing zoals, zonder limitatief te zijn, YellowBrick, Mobile – for, PARK-Mobile, MobiGo, edm ii. Database van de backoffice software parkeerkaarten en abonnementen, eveneens onderdeel van deze opdracht: Kunnen opzoeken of het kenteken beschikt over een geldige parkeerkaart voor de locatie van de controle.

c.

Alle kentekens waarvoor een retributie werd opgemaakt moeten geïdentificeerd en gepersonaliseerd kunnen worden via een link met DIV.

d.

De gegevens van DIV moeten automatisch geïmporteerd worden in de backoffice software, en bij iedere retributie worden de persoonsgegevens automatisch ingevuld. De inschrijver licht in zijn offerte duidelijk toe hoe wordt omgegaan met bedrijfsvoertuigen (opvraging via KBO) en leasingvoertuigen.

e.

De kennisgeving van de uitgeschreven retributie wordt (al dan niet) automatisch via post overgemaakt aan de automobilist.

f.

Indien de automobilist het verschuldigde bedrag via overschrijving betaalt moet een CODA bestand van de bankier van de Stad Sint-Niklaas automatisch geïmporteerd kunnen worden in de backoffice software. Alle betalingen die gebeurd zijn met de correcte gestructureerde mededeling worden automatisch afgeboekt. Andere betalingen behoeven aandacht van een gebruiker.

g.

Indien de automobilist het verschuldigde bedrag van een retributie (of van een parkeerkaart of abonnement) aan het loket in cash, met bancontact of online

9100 Sint-Niklaas


Pagina 5 van 49

betaalt, kan een betalingsbewijs uitgeprint worden en de retributie wordt automatisch afgeboekt. De betalingsflows cash, bancontact en online worden weergegeven in bijlagen 6a tem 6b. Gedeeltelijke betalingen zijn eveneens mogelijk. Indien de automobilist een afbetalingsplan wenst, dient enerzijds de financieel beheerder voorafgaand zijn akkoord moeten kunnen geven; anderzijds dient de retributie uit de manuele flow gehaald te worden. Het spreekt voor zich dat er een overzicht gegeven kan worden van alle afbetalingsplannen. Deze actie moet mogelijk zijn in alle fasen van de invordering. De fysieke kassa is ook gekoppeld aan de backoffice software. h.

De automobilist vraagt inlichtingen aan de mobiliteitswinkel, of telefoneert naar de mobiliteitswinkel betreffende een retributie of parkeerkaart. Deze informatie is op te zoeken aan de hand van meerdere zoekcriteria. Alle contactmomenten met klanten kunnen worden genoteerd en bijgehouden. Deze gegevens moeten eenvoudig te ontsluiten zijn uit de database voor hergebruik in andere applicaties of rapporteringen. De inschrijver licht hier de mogelijkheden toe.

i.

Van alle vaststellingen die niet betaald zijn wordt na een te bepalen aantal dagen een eerste betalingsvraag opgemaakt en verstuurd. Deze betalingsvraag wordt automatisch voorbereid door de backoffice software volgens een bepaalde lay-out.

j.

Van eerste betalingsaanvragen die niet betaald zijn wordt na een te bepalen aantal dagen een tweede betalingsvraag opgemaakt en verstuurd. Deze betalingsvraag wordt automatisch voorbereid door de backoffice software volgens een bepaalde lay-out.

k.

Van tweede betalingsaanvragen die niet betaald zijn wordt na een te bepalen aantal dagen een aangetekende aanmaning opgemaakt en verstuurd. Deze aanmaning wordt automatisch voorbereid door de backoffice software volgens een bepaalde lay-out. Niet afgehaalde terugkomende aanmaningen moeten registreerbaar zijn en apart kunnen worden opgevolgd.

l.

Wanneer het verschuldigde bedrag 1 maand na de aangetekende ingebrekestelling nog steeds niet wordt betaald en niet ernstig is betwist, wordt het volledige dossier klaargemaakt voor invordering via dwangbevel.

m. Hiertoe wordt een maandelijks lijst gegenereerd van alle dossiers in dit geval voor goedkeuring tot invordering via het College van burgemeester en schepenen en de Financieel Beheerder. Deze goedkeuringen zorgen onmiddellijk voor een invorderbare titel via een dwangbevel. n.

Deze dossiers dienen na akkoord van de Financieel Beheerder automatisch digitaal overgemaakt te worden aan de deurwaarder met alle nodige

9100 Sint-Niklaas


Pagina 6 van 49

bewijsstukken en goedkeuringen. Het dwangbevel dient eveneens op papier afgeleverd te worden aan de deurwaarder. o.

Wanneer de deurwaarder na enige tijd het geld van een bepaald dossier doorstort naar de mobiliteitswinkel, kan de betreffende retributie afgehandeld worden.

p.

Wanneer het verschuldigde bedrag van de retributiebon na 1 maand na de aangetekende ingebrekestelling nog steeds niet wordt betaald en ernstig is betwist, wordt het volledige dossier klaargemaakt akkoord van het College van Burgemeester en Schepenen voor invordering via advocaat.

q.

Deze dossiers dienen na akkoord van het College automatisch digitaal overgemaakt te worden aan de advocaat met alle nodige bewijsstukken en goedkeuringen.

r.

De volledige procedure van niet – ernstig betwiste en ernstig betwiste retributiebonnen dient gevolgd te kunnen worden via de backoffice software.

s.

De klanten-automobilisten kunnen een parkeerkaart raadplegen, aanmaken en verlengen. De wijzigingen zijn meteen actief.

t.

Wanneer de parkeerwachter tijdens de controleronde een defect opmerkt aan één van de ticketautomaten, kan hij hiervan een melding maken. Het defect wordt rechtstreeks doorgestuurd naar de beheersoftware van de parkeerautomaten. Omgekeerd krijgt de parkeerwachter ook een melding wanneer hij controleert in de zone van een parkeerautomaat die als ‘defect’ staat geregistreerd in de beheersoftware.

u.

De automobilist betaalt het verschuldigde bedrag ( van een retributie of een parkeerkaart /abonnement) via de web shop op de website van de oplossing van de inschrijver gepersonaliseerd voor Sint-Niklaas (zie perceel 3). De klant betaalt dit bedrag online met een verplichte mededeling. Zie betalingsflow in bijlage 6.

v.

Tweerichtingskoppeling tussen de website en de backoffice software retributies. (zie perceel 3) i. Informatie over openstaande retributies ter beschikking stellen aan de ingelogde klant ( identificatie via rijksregisternummer) ii. Informatie betreffende de uitgevoerd handelingen wegschrijven naar de backofficesoftware.

w. Tweerichtingskoppeling tussen de website en de backoffice software parkeerkaarten. (zie perceel 3) i. Informatie over parkeerkaarten ter beschikking stellen aan de ingelogde klant ( identificatie via rijksregisternummer) ii. Informatie betreffende de uitgevoerd handelingen wegschrijven naar de backofficesoftware.

9100 Sint-Niklaas


Pagina 7 van 49

4.

Detail verwachtingen Front-end software voor de controle op geparkeerde voertuigen a. Algemeen:

De software dient voor het toezicht op geparkeerde voertuigen, hoofdzakelijk ten behoeve van het uitschrijven van retributies, maar ook ten behoeve van het uitschrijven van een gemeentelijke administratieve sanctie. Op termijn moet een uitbreiding mogelijk zijn zodat de software kan dienen voor een controle op het openbaar domein, bijv. sluikstorten, leegstand, edm. Wanneer een parkeerwachter in een straat toezicht aan het uitoefenen is op de geparkeerde voertuigen, en hij stelt een GAS-inbreuk vast, dan kan de parkeerwachter hiervoor een vaststelling opmaken, zonder dat hij de software voor het toezicht op de parkeerde voertuigen moet verlaten. Het controleren van geparkeerde voertuigen en het opmaken van een vaststelling voor een GASinbreuk zijn dus zo veel mogelijk met elkaar verweven. Op ieder mogelijk scherm van de software moet het virtuele toetsenbord kunnen geactiveerd worden door de parkeerwachter. Op ieder mogelijk scherm van de software is de klok zichtbaar. De klok wordt weergegeven in uren (24-uurs), minuten en seconden. Wanneer al op voorhand vaststaat dat in het actieve tekstveld numerieke waarden moeten ingevuld worden, wordt automatische het numerieke ( fysiek of virtueel) toetsenbord geactiveerd. De handterminal is voorzien van een instelbare systeembeheerder die verhindert dat er ongewenste applicaties kunnen geopend worden ( MSN, Browser, spelletjes, ed.). De systeembeheerder is een door de mobiliteitswinkel-beheerder goedgekeurde gebruiker in de backoffice software. De gebruiker kan handmatig de lichtintensiteit van het beeldscherm (back light) instellen en het beeldscherm is duidelijk leesbaar in openlucht. (zie verder) De lijst met alle mogelijke gebruikers (parkeerwachters) wordt vastgelegd in de backoffice software, samen met het rechtenprofiel door een mobiliteitswinkel-beheerder.

b. Inloggen: Na invoer van een bepaalde gebruikersnaam/paswoord combinatie worden de bijhorende rechten van de gebruiker (parkeerwachter) geactiveerd. Eenmaal ingelogd, wordt het hoofdmenu getoond. Vanuit het hoofdmenu zijn alle hoofdfuncties beschikbaar: Opstarten van een controle van een geparkeerd voertuig Doorgeven van een melding Bekijken dag planning Uitloggen

9100 Sint-Niklaas


Pagina 8 van 49

Bekijken van de al opgemaakte retributies ( retributies die opgemaakt zijn tijdens de sessie. Een sessie start telkens een gebruiker inlogt, en eindigt telkens een gebruiker uitlogt) Bekijken van de al opgemaakte vaststellingen voor GAS-inbreuken. Contacten (telefoon)

c. Ingave locatie: Controle voertuigen gebeurt door de parkeerwachter bij de start van de controle door in te geven waar het voertuig zich bevindt. Hiertoe worden de eerste letters van een straatnaam ingegeven en kan de parkeerwachter de straat selecteren door deze aan te klikken in een drop down list. (Zowel scannen van de nummerplaat als locatie-bepaling zijn opties die de inschrijver kan voorstellen?) Eenmaal de straat is geselecteerd, geeft de software alle mogelijke ‘modaliteiten’ in de straat weer, dit kan zowel een zone voor betalend parkeren als een blauwe zone zijn. Meerdere type zones kunnen voorkomen binnen één straat. In de toekomst moet het mogelijk zijn nieuwe types te creëren. Er kan worden teruggekeerd naar het hoofdmenu door op de knop ‘Terug’ te drukken. Deze knop is altijd actief. Wanneer de parkeerwachter een straat en zone selecteert waarin een automaat buiten dienst staat (koppeling met beheersoftware voor parkeerautomaten), krijgt hij hiervan een pop-up melding. Deze pop-up verschijnt enkel wanneer de straatnaam voor de eerste keer wordt ingegeven, en niet bij iedere controle binnen diezelfde straat.

d. Controle betaling Na het ingeven van de locatie van een geparkeerd voertuig kan de parkeerwachter controleren of het voertuig al dan niet heeft betaald en/of een vergunning heeft. Indien geen mindervalidenkaart voorligt, worden de online databases bevraagd via een web service. Zowel de interne als de externe databases worden op deze manier bevraagd: Eerst wordt gecontroleerd als er voor het kenteken die voor- of namiddag al een retributie werd opgemaakt. Er moet gecontroleerd worden op het kenteken, het type retributie ( betalend parkeren, blauwe zone) en de locatie. Indien voor het kenteken eenzelfde type retributie gevonden wordt, krijgt de parkeerwachter hiervan een melding en kan worden gestart met een nieuwe controle. Na bovenstaande controle worden de databases gelijktijdig bevraagd: - database backoffice software parkeerbeheer: houders van een gemeentelijke parkeerkaart voor bewoners. dag-, week- of maandkaarten - database van E-ticketing Het resultaat van de bevraging verschijnt op het volgende scherm.

9100 Sint-Niklaas


Pagina 9 van 49

Een lijst met gemelde en/of geseinde voertuigen kan in de backoffice-software worden aangemaakt. Deze lijst bestaat uit kentekens met daarnaast een vrij in te vullen commentaar.

e. Opmaak retributie Voor de opmaak van een retributie dient een scherm voorzien voor de ingave van de voertuiggegevens. Dit scherm bevat onder meer volgende velden: - ‘TYPE’: ‘personenauto’ is standaard, anders keuze uit een lijst van types alfabetisch gerangschikt. (combo box) - ‘MERK’: keuze uit een lijst van merken alfabetisch gerangschikt. (combo box) - ‘KLEUR’: keuze uit een lijst van kleuren alfabetisch gerangschikt. (combo box) De verschillende mogelijkheden voor de velden ‘type’, ‘merk’ en ‘kleur’ zijn instelbaar in de backoffice software door een beheerder, doch al standaard voorzien. Iedere retributie dient gestaafd te worden met foto’s en eventuele commentaar van de parkeerwachter. De parkeerwachter krijgt een overzicht van standaard boodschappen die kunnen worden ingesteld in de backoffice software. (overtredingstypes).

f.

Foto’s nemen

Een scherm voor het nemen van foto’s dient voorzien te zijn. Het minimum aantal, dat een parkeerwachter bij een vaststelling moet nemen is instelbaar in de backoffice software. Mogelijkheid om de flits-modus te wijzigen (aan, uit, automatisch). Mogelijkheid om het verlichtingsniveau bij te stellen (-3 tot +3) ‘OK’: Foto wordt genomen. ‘Terug’: wordt pas actief wanneer het minimum aantal foto’s is genomen; leidt terug naar het scherm voor de ingave van commentaar. Telkens een foto genomen wordt, verschijnt deze in het overzicht onderaan. Zo krijgt de parkeerwachter een mooi overzicht van de al genomen foto’s. De parkeerwachter heeft de mogelijkheid om foto’s te wissen. Iedere genomen foto is voorzien van datum (dd/mm/jj) en uur (uu:mm) waarop deze werd genomen. Tevens is deze voorzien van de referentie van de vaststelling (XXX/XXXX/XXXXX).

g. Overzicht van de retributie Er dient eveneens een scherm voorzien te worden met een overzicht van de belangrijkste ingevulde gegevens. Wanneer nog iets van de gegevens van de retributie moet gewijzigd worden, kan er op dit moment nog steeds teruggegaan worden om te wijzigen. Wanneer de parkeerwachter op een knop’ bevestigen’ drukt, worden alle gegevens, inclusief de foto’s doorgestuurd naar de backoffice software.

9100 Sint-Niklaas


Pagina 10 van 49

Wanneer het om welke reden dan ook niet meteen mogelijk is om de data te versturen, worden deze tijdelijk in wacht gezet. In wacht betekent hier dat ze worden opgeslagen in het interne geheugen van de handterminal. Iedere X minuten probeert de software de communicatie met de backoffice software te herstellen. Van zodra er terug communicatie is, worden de retributiebonnen in wacht doorgestuurd. Dit alles gebeurt zonder bijkomende handeling van de parkeerwachter. Eenmaal de parkeerwachter op de knop ‘versturen’ heeft gedrukt, wordt de retributie opgeslagen in het overzicht van de al opgemaakte retributiebonnen Deze kan enkel nog geraadpleegd worden, deze is niet meer te wijzigen. De parkeerwachter kan onmogelijk een bevestigde retributiebon annuleren.

h. Overzicht al opgemaakte retributiebonnen Het raadplegen van de al opgemaakte retributiebonnen gedurende de ‘sessie’ is steeds mogelijk vanuit het hoofdmenu.

i.

Verzoek tot annulatie:

De parkeerwachter kan d.m.v. vrije tekst ingave het verzoek verduidelijken. Er kunnen ook foto’s genomen worden om de reden waarom verzocht wordt te annuleren te verduidelijken.

j.

Extra informatie:

De parkeerwachter kan d.m.v. vrije tekst ingave extra informatie aan de retributie toevoegen. De informatie wordt in de backoffice software meteen aan de desbetreffende retributie gelinkt.

k. Doorgeven van een melding De parkeerwachter moet vanuit het hoofdmenu een melding kunnen doorgeven naar de backoffice. Deze melding kan vrij worden ingevuld of werd standaard bepaald voor de meest voorkomende meldingen. Deze kunnen in de backoffice software worden aangemaakt door een beheerder (combo box). Naargelang het gekozen type melding worden verschillende velden weergegevens op het scherm. Eén van de mogelijke types is ‘defect automaat’. Hierbij moet het nummer van de automaat kunnen worden ingegeven.

l.

Telefoneren / tekstberichten

De telefoonfunctionaliteit komt over de actieve applicatie heen. Wanneer de telefoonfunctionaliteit wordt afgesloten, kom je terug in de actieve applicatie en worden alle al ingevoerde gegevens behouden.

m. Registratie van alle gecontroleerde voertuigen. Alle door de parkeerwachter uitgevoerde controles (ook voor de voertuigen die reglementair geparkeerd waren) worden realtime naar de backoffice verstuurd, en opgeslagen.

9100 Sint-Niklaas


Pagina 11 van 49

5. Backoffice software Onder backoffice software wordt verstaan: - Backoffice software voor het beheer en de afhandeling van de retributiebonnen - Backoffice software voor het beheer van de bewoners-(parkeer)kaarten Bij voorkeur zijn beide systemen toegankelijk vanuit één gebruikersinterface en is het systeembeheer voor beiden gemeenschappelijk. Indien beide systemen niet toegankelijk zijn via één gebruikersinterface, maar elk een eigen gebruikersinterface hebben, is het noodzakelijk dat de achterliggende databases van beide systemen met elkaar kunnen communiceren. Dit voornamelijk om bepaalde configuraties/instellingen niet dubbel te moeten uitvoeren (vb. aanmaak van nieuwe straten en zones) De inschrijver geeft uitgebreid weer in zijn offerte hoe de aangeboden backoffice software is opgebouwd, hoe de interne gegevens kunnen ontsloten worden met behulp van APIs, webservices, edm, hoe met andere programma’s gekoppeld kan worden en hoe gegevens kunnen geëxporteerd of geïmporteerd worden. De opdrachtgever wenst bij voorkeur een SaaS/Cloud-oplossing. Deze moet voldoen aan de normen en voorwaarden van toepassing voor gemeenten en aan de regels gesteld door de Privacy-commissie. De leverancier zal bij de implementatie van de oplossing verzekeren dat al deze voorwaarden vervuld zijn.

6. Backoffice software voor de afhandeling en opvolging van de retributiebonnen Alle door de parkeerwachters opgemaakte retributiebonnen worden centraal opgeslagen. De backoffice software dient hoofdzakelijk voor de administratieve opvolging en afhandeling van de door de parkeerwachters opgemaakte retributiebonnen. Alle handterminals kunnen beheerd worden via de backoffice software. Er bestaat een bi-directionele vorm van realtime datacommunicatie tussen de backoffice en de handterminals. De inschrijver staat in voor de levering en de installatie van de backoffice software. Hoofdfuncties: -

Financiële afhandeling van de retributiebonnen

-

Beheer van de verschillende types retributiebonnen

-

Beheer van parkeermodaliteiten (straten, zones,...) optioneel via een koppeling met een centrale databank van straten, zones zoals bijv. GIS

9100 Sint-Niklaas


Pagina 12 van 49

-

Beheer van contactmomenten met klanten

-

Rapportering

In onderstaande punten worden de eisen naar de werking van de backoffice software voor de administratieve opvolging en afhandeling van de retributiebonnen uitgebreid omschreven.

a. Opstarten en aanmelden Na het dubbelklikken op het logo van de software moet de gebruiker zich inloggen a.d.h.v. een gebruikersnaam en paswoord. De gebruikersnaam samen met het bijhorende paswoord werkt als een toegangscode tot de software. Na invoer van een bepaalde gebruikersnaam/paswoord combinatie worden de bijhorende rechten van de gebruiker geactiveerd.

b. Configuratie Alle onderdelen onder systeembeheer kunnen enkel gewijzigd worden door een mobiliteitswinkel-beheerder en niet door een standaard gebruiker. Onder configuratie wordt verstaan de instellingsmogelijkheden van de software om deze te configureren naar de in Sint-Niklaas van toepassing zijnde modaliteiten m.b.t. straatparkeren. Ook het beheer van de gebruikers van de software voor de opvolging en afhandeling van de retributiebonnen valt onder systeembeheer. De volledige configuratie van de software m.b.t. het opvolgen en afhandelen van de retributiebonnen volgens de modaliteiten, zoals in dit bestek beschreven, is inbegrepen in de prijsopgave voor de levering en indienststelling. Indien in de toekomst de modaliteiten wijzigen ( nieuwe uren van toezicht, tariefwijzigingen, bijkomende zones...), dan moet de mobiliteitswinkel-beheerder in staat zijn om zelf uren, tarieven, zones, ... te creëren of te wijzigen en te configureren. De inschrijver geeft aan hoe dit in zijn werk gaat, en wat de totale configuratiemogelijkheden van de software inhouden.

c. Beheer gebruikers De lijst met alle mogelijke gebruikers van de backoffice software wordt beheerd door een mobiliteitswinkel-beheerder. Per gebruiker kan worden ingesteld welke rechten en rollen deze gebruiker heeft.

d. Beheer parkeerwachters Het definiëren van een parkeerwachter kan gebeuren aan de hand van verschillende criteria en levert een rechtenprofiel ( vb. mag al dan niet GAS-vaststellingen doen, of bij uitbreiding andere functionaliteiten) Nieuwe parkeerwachters kunnen door een mobiliteitswinkel-beheerder aangemaakt worden. Al gedefinieerde parkeerwachters kunnen op niet-actief geplaatst worden, wanneer deze vb. uit dienst treden.

9100 Sint-Niklaas


Pagina 13 van 49

e. Beheer straten Alle straten die liggen in een betalende zone of een blauwe zone zijn gedefinieerd in de software. Het definiëren van een straat kan gebeuren aan de hand van verschillende criteria zoals straatnaam, aantal parkeerplaatsen , eventuele speciale modaliteiten ( vb. mindervalidenplaatsen) edm De mobiliteitswinkel-beheerder kan een nieuwe straat definiëren, of een al gedefinieerde straat op ‘niet-actief’ plaatsen. Bij voorkeur is hiervoor een (in)directe koppeling met het GIS systeem of het CRAB-systeem van AGIV voorzien, dat een centrale databank heeft van straten

f.

Beheer voertuigtypes

De voertuigtypes waaruit de parkeerwachters kunnen selecteren bij de opmaak van een retributie, worden beheerd in de backoffice software. Het definiëren van een voertuigtype gebeurt op basis van een naam (vb. ’personenwagen’). De mobiliteitswinkel beheerder kan een nieuw voertuigtype definiëren, of een al gedefinieerd voertuigtype op ‘niet-actief’ plaatsen.

g. Beheer automerken De automerken waaruit de parkeerwachters kunnen selecteren bij de opmaak van een retributie, worden beheerd in de backoffice software. Het definiëren van een automerk gebeurt op basis van een naam (vb. ’Opel’). De lijst met automerken wordt alfabetisch gerangschikt. De mobiliteitswinkel beheerder kan een nieuw automerk definiëren, of een al gedefinieerd automerk op ‘niet-actief’ plaatsen.

h. Beheer autokleuren De autokleuren waaruit de parkeerwachters kunnen selecteren bij de opmaak van een retributie, worden beheerd in de backoffice software. Het definiëren van een autokleur gebeurt op basis van een naam (vb. ’Zilvergrijs’).De lijst met autokleuren wordt alfabetisch gerangschikt. De mobiliteitswinkel beheerder kan een nieuw autokleur definiëren, of een al gedefinieerde autokleur op ‘niet-actief’ plaatsen.

i.

Beheer nationaliteiten

De nationaliteiten waaruit de parkeerwachters kunnen selecteren bij de opmaak van een retributie, worden beheerd in de backoffice software. Het definiëren van een nationaliteit kan gebeurt op basis van een naam (vb. ’België’), de internationale afkorting van de nationaliteit (vb. ’B’) en combinaties letter –cijfers van de kentekens (meerdere per nationaliteit) De lijst met nationaliteiten wordt gerangschikt op basis van hun frequentie.

9100 Sint-Niklaas


Pagina 14 van 49

De mobiliteitswinkel beheerder kan een nieuw nationaliteit definiëren, of een al gedefinieerde nationaliteit op ‘niet-actief’ plaatsen.

j.

Beheer type retributiebonnen

Het definiëren van een type retributie bestaat uit verschillende onderdelen: -

Volgnummer van het type retributie Naam van de retributie: (=ID) Retributie ‘betalend parkeren’ Retributie ‘blauwe zone’ Bedrag van de retributie Dagen waarop een retributie kan worden opgemaakt Uren waarbinnen een retributie kan worden opgemaakt

Nieuwe types kunnen worden aangemaakt en gedefinieerd door een mobiliteitswinkel-beheerder. Al gedefinieerde types kunnen worden gewijzigd door een mobiliteitswinkel-beheerder. Een al bestaand type kan op ‘actief’ of op ‘niet-actief’ worden geplaatst.

k. Beheer modaliteiten-zones Het definiëren van een zone bestaat uit verschillende onderdelen: -

Volgnummer van de zone Naam van de zone (=ID) Omschrijving van de zone Type van de retributie: Betalend parkeren Blauwe zone Straten: zone kan eveneens een stuk van een straat zijn tussen verschillende huisnummers

Voor de huidige zones verwijzen we naar de diverse bijlagen. Nieuwe zones kunnen worden aangemaakt en gedefinieerd door een mobiliteitswinkelbeheerder. Al gedefinieerde zones kunnen worden gewijzigd door een mobiliteitswinkel-beheerder. Een al bestaande zone kan op ‘actief’ of op ‘niet-actief’ worden geplaatst.

l.

Beheer standaard toelichting bij retributiebonnen voor parkeerwachters

Het definiëren van een standaard toelichting kan bestaan uit verschillende onderdelen zoals volgnummer, Prioriteit, type van de toelichting, naam van de toelichting en tekst van de toelichting. Nieuwe toelichtingen kunnen worden aangemaakt en gedefinieerd door een mobiliteitswinkel-beheerder. Al gedefinieerde toelichtingen kunnen worden gewijzigd door een mobiliteitswinkelbeheerder. Een al bestaande toelichting kan op ‘actief’ of op ‘niet-actief’ worden geplaatst.

9100 Sint-Niklaas


Pagina 15 van 49

m. Beheer informatie van de parkeerwachters Het definiëren van een melding kan bestaan uit verschillende onderdelen: volgnummer van de informatie (=ID), type van de informatie en invulvelden van de informatie.

n. Beheer tijdslijnen administratieve afhandeling De tijdslijnen voor aanmaningen e.d. zijn programmeerbaar. Deze termijnen zijn instelbaar door de mobiliteitswinkel-beheerder.

o. Individuele opvolging van een retributie Iedere retributie wordt in de backoffice in een afzonderlijk dossier opgevolgd. Hiertoe heeft iedere retributie een uniek referentienummer, dat automatisch wordt aangemaakt. Alle vaststellingsgegevens, genomen foto’s, eventuele GPS coördinaten, personalia, contactmomenten en informatie betreffende de financiële afhandeling worden aan deze digitale steekkaart gekoppeld. Volgende gegevens zijn minimaal raadpleegbaar per retributie, in diverse tabbladen en logisch gerangschikt : i.

Overzicht van de belangrijkste gegevens van de retributie: - Referentienummer van de retributie: XXX/XXXX/XXXXX - Datum: DD-MM-JJJJ - Tijd: uu:mm - Artikel (betalend parkeren, blauwe zone, ..) - Openstaand bedrag - Zone - Status - Parkeerwachter : Volledige naam - Modaliteiten (vb. ma t/m za – van 9u-19u) - Bedrag van de retributie: (vb. 25,00€) - Voertuiggegevens: Kenteken/ Type/ Merk/ Kleur/ Nationaliteit - Toelichting: (vb. gebarsten voorruit)

ii.

Genomen foto’s

Overzicht van de foto’s die de parkeerwachter heeft genomen. Er is een overzicht met kleine thumbnails. iii.

Verzoek tot annuleren

Indien de parkeerwachter een verzoek tot annulatie heeft doorgestuurd na het opmaken van de retributie, dan zijn de toelichting en bijgaande foto’s op dit tabblad zichtbaar.

iv.

Eigenaar

Gegevens worden automatisch geïmporteerd uit de DIV-file en bevatten naam , voornaam, straat nummer, bus ,postcode ,plaats, land, nationaliteit en taal Telefoonnummer kan handmatig aangevuld worden (meerdere telefoonnummers zijn mogelijk)

9100 Sint-Niklaas


Pagina 16 van 49

Ook E-mailadres kan handmatig aangevuld worden. Het spreekt voor zich dat hier de nodige beveiligingsmaatregelen aanwezig zijn. De software logt elke poging tot opzoeken van de gegevens. De inschrijver omschrijft deze beveiliging verder in detail. v.

Betalingen

Dit tabblad geeft: - een overzicht van de samenstelling van het bedrag van de retributie. - een overzicht van de uittreksels/cashbetalingen die aan deze retributie gekoppeld werden. - een overzicht van het te betalen bedrag, het reeds betaalde bedrag en het openstaande saldo. vi.

Historiek

Per retributie wordt een historiek van alle acties bijgehouden Contactmomenten (tabblad) Per retributie wordt een historiek van de contactmomenten met de klant bijgehouden. Deze worden weergegeven in een chronologisch overzicht op dit tabblad. vii.

Notities

Mogelijkheid tot het opslaan van algemene informatie betreffende een retributie.

p. Financiële afhandeling van een retributie i.

Directe betalingen aan de balie (cash / krediet- of debet kaart)

Wanneer een klant een betaling doet aan het loket voor een retributie, dan wordt deze betaling meteen geregistreerd in de digitale steekkaart van de betreffende retributie. De gebruiker kan een ‘nieuwe betaling’ aanmaken onder tabblad ‘betalingen’ in de digitale steekkaart van de retributie. De datum staat automatisch ingevuld, de gebruiker vult het bedrag, het type betaling (cash/ krediet-of debet kaart) en een eventuele opmerking in. Een ontvangstbewijs kan worden afgedrukt. Indien het betaalde bedrag identiek is aan het openstaande saldo, dan wordt de retributie automatisch op ‘afgehandeld’ gezet. Indien het betaalde bedrag lager is dan het openstaande saldo, dan wordt het saldo automatisch aangepast. Gedeeltelijke betalingen zijn steeds mogelijk. Iedere in de software geregistreerde cash betaling wordt ook geregistreerd in het kasregister van de fysieke kassa. De fysieke kassa is gekoppeld aan de backoffice software van de leverancier, die op haar beurt is gekoppeld aan het boekhoudpakket van de Stad Sint-Niklaas.

9100 Sint-Niklaas


Pagina 17 van 49

ii.

Bankbetalingen: overschrijvingen

Om de registratie van de betalingen via overschrijving te kunnen uitvoeren, moeten CODAbestanden kunnen ingelezen worden. De CODA-bestanden worden door een gebruiker dagelijks in een bepaalde map op de server geplaatst. Automatisch worden de CODA-bestanden geïmporteerd en verwerkt door de backoffice software. Na het inlezen worden ze meteen automatisch verwijderd. Per betaling zijn meerdere mogelijkheden: De betaling gebeurde volgens de correcte gestructureerde mededeling en voor het juiste bedrag. De betaling kan worden toegewezen: de betaling wordt geregistreerd onder ‘betalingen’ in de digitale steekkaart van de betreffende retributie. Eenmaal het volledige bedrag toegewezen werd aan een dossier, wordt deze automatisch op betaald en afgehandeld gezet zodat deze niet verder bij de openstaande dossiers behoort. De betaling gebeurde volgens de correcte gestructureerde mededeling maar niet voor het juiste bedrag. De betaling kan niet automatisch worden toegewezen en komt terecht bij de betalingen die aandacht behoeven. De betaling werd uitgevoerd zonder gestructureerde mededeling. De betaling kan niet automatisch worden toegewezen en komt terecht bij de betalingen die aandacht behoeven. iii.

Betalingen die aandacht behoeven

Er kan in de backoffice software een dagelijks overzicht gegeven worden van alle betalingen die aandacht behoeven. Deze kunnen worden opgedeeld in verschillende groepen, en worden bij voorkeur ook per groep weergegeven: Referentienummer niet gevonden: Via de wizard kan worden gezocht naar openstaande dossiers op naam, adres, enz. van de rekeninghouder. Indien een retributie wordt gevonden die voldoet aan de zoekcriteria, kan de betaling worden toegewezen. Afhankelijk of het bedrag correct is, wordt het dossier al dan niet als afgehandeld gezet. Indien op basis van de gegevens van de overschrijving geen retributie wordt gevonden waarvoor de betaling bestemd zou kunnen zijn, wordt automatisch een email voorbereid, volgens een vaste te bepalen lay-out, met de vraag om het referentienummer. Indien geen emailadres beschikbaar, wordt automatisch een brief voorbereid. Dubbele betaling: Via de wizard kan worden gezocht naar andere openstaande dossiers op naam, adres, enz. van de rekeninghouder. Indien een nog openstaande retributie wordt gevonden op naam, adres, ... van de rekeninghouder, dan kan de betaling aan deze andere retributie worden toegewezen.

9100 Sint-Niklaas


Pagina 18 van 49

Indien op basis van de gegevens van de overschrijving geen andere openstaande retributie wordt gevonden waarvoor de betaling bestemd zou kunnen zijn, zal het bedrag teruggestort worden (worden toegevoegd aan een CODA bestand)

Verkeerd bedrag: - Bedrag is te hoog: Via de wizard kan worden gezocht naar andere openstaande dossiers op naam, adres, enz. van de rekeninghouder. Indien een nog openstaande retributie wordt gevonden op naam, adres, ... van de rekeninghouder, dan kan de ‘rest’ van het bedrag van de betaling aan deze andere retributie worden toegewezen. Het saldo wordt automatisch aangepast. Indien op basis van de gegevens van de overschrijving geen andere openstaande retributie wordt gevonden waarvoor de betaling bestemd zou kunnen zijn, kan de ‘rest’ van het bedrag teruggestort worden (worden toegevoegd aan een CODA bestand). Dit gebeurt enkel wanneer het restbedrag hoger is dan 1€. - Bedrag is te laag: Het bedrag van de betaling wordt toegewezen aan de retributie. Het saldo wordt automatisch aangepast. Dossier reeds bij deurwaarder: Er wordt door de mobiliteitswinkel contact opgenomen met de deurwaarder met de vraag om te annuleren indien nog mogelijk. Geannuleerde retributie: Via de wizard kan worden gezocht naar andere openstaande dossiers op naam, adres, enz. van de rekeninghouder. Indien een nog openstaande retributie wordt gevonden op naam, adres, ... van de rekeninghouder, dan kan de betaling aan deze andere retributie worden toegewezen. Indien op basis van de gegevens van de overschrijving geen andere openstaande retributie wordt gevonden waarvoor de betaling bestemd zou kunnen zijn, kan het bedrag teruggestort worden (worden toegevoegd aan een CODA bestand)

q. Overzicht van alle retributiebonnen Een overzicht van alle retributiebonnen is raadpleegbaar voor de gebruiker. Binnen dit overzicht kan gefilterd worden op verschillende veld-items.

r.

Status van een retributie

Afhankelijk van de fase waarin een dossier van een retributie zich bevindt, kan een status worden toegekend. Mogelijke fasen waarin een retributiebon zich bevindt zijn ondermeer: Betaald: De retributie werd volledig betaald. Geannuleerd: De retributie werd geannuleerd. De reden tot annulatie zal zijn toegevoegd aan de contactmomenten, samen met een eventueel ingescand bewijsstuk (ticket, mindervalidenkaart, doktersattest) of een verklarende email. DIV gegevens nodig: Deze status wordt automatisch toegekend aan iedere retributie wanneer deze wordt ingevoegd in de backoffice.

9100 Sint-Niklaas


Pagina 19 van 49

KBO – Leasing gegevens nodig: Deze status wordt automatisch toegekend aan iedere retributie van een bedrijfs- of leasing wagen. Betwist: Deze status wordt toegekend aan iedere retributie wanneer deze manueel in wacht wordt geplaatst. Dit gebeurt bijvoorbeeld wanneer er voor een retributie een betwisting werd ingediend. Ernstig betwist: Deze status wordt toegekend aan iedere retributie wanneer deze manueel in wacht wordt geplaatst. Dit gebeurt bijvoorbeeld wanneer er voor een retributie een betwisting werd ingediend Vaststelling en aanvraag tot betaling verstuurd: Deze status wordt automatisch toegekend aan iedere retributie wanneer de vaststelling en de aanvraag tot betaling verstuurd werd. Eerste betalingsvordering verstuurd: Deze status wordt automatisch toegekend aan iedere retributie wanneer de eerste betalingsvordering verstuurd werd. Tweede betalingsvordering verstuurd: Deze status wordt automatisch toegekend aan iedere retributie wanneer de eerste betalingsvordering verstuurd werd. Naar College: Deze status wordt toegekend aan iedere retributie die wordt voorgelegd op het College van Burgemeester en Schepenen. Naar deurwaarder: Deze status wordt automatisch toegekend aan iedere retributie wanneer het dossier werd overgemaakt aan de deurwaarder. De gemaakte kosten door de deurwaarder dienen opgevolgd te kunnen worden. Naar advocaat: Deze status wordt automatisch toegekend aan iedere retributie wanneer het dossier werd overgemaakt aan de advocaat. De inschrijver geeft aan of er andere statuten mogelijk zijn en in zijn ogen noodzakelijk zijn voor de efficiënte opvolging van de retributiebondossiers.

s. Historiek van een retributie Per retributie wordt een historiek van alle acties bijgehouden. In chronologische volgorde worden onderstaande stappen per retributie bijgehouden: Retributie uitgeschreven Personalia opgevraagd Personalia ontvangen Vaststelling en betalingsaanvraag verstuurd Betalingsvordering 1 verstuurd

9100 Sint-Niklaas


Pagina 20 van 49

Betalingsvordering 2 verstuurd Aanmaning verstuurd Aanmaning vervallen Dossier overgemaakt aan deurwaarder I.v.m. met de betalingen: Retributie deels betaald Retributie volledig betaald Andere: Retributie geannuleerd Retributie in wacht geplaatst Annulatie van de retributie ongedaan gemaakt Hierbij wordt steeds de datum en de gebruiker mee opgeslagen.

t.

Contactmomenten betreffende een retributie

Per retributie wordt een historiek van de contactmomenten met de klant bijgehouden. Deze worden weergegeven in een chronologisch overzicht. Contactmomenten kunnen automatisch/manueel aangemaakt worden: i.

Manueel aangemaakte contactmomenten:

Door een gebruiker kan in de fiche van de retributie een nieuw contactmoment aangemaakt worden. Afhankelijk van het gekozen type zijn er verschillende mogelijkheden. Telkens kan worden aangeduid of het om een inkomend of uitgaand contact gaat. Telkens wordt de datum, het uur en gebruiker die het contactmoment aanmaakt, opgeslagen bij het contactmoment.

Verschillende types: Telefoongesprek : Inhoud van het telefoongesprek kan worden genoteerd. E-mail : E-mail kan worden gelinkt aan het contactmoment (.pdf). Brief: Inkomende brief/fax kan worden gelinkt aan een contactmoment (.pdf). Uitgaande brief kan door middel van verschillende keuzemogelijkheden aan de hand van een sjabloon worden samengesteld. ii.

Automatisch aangemaakte contactmomenten:

E-mail/ brief die automatisch wordt voorbereid voor de betalingsaanvraag voor de verlenging van een termijn van een tweede parkeerkaart voor bewoners. Wanneer voor een aangemaakt contactmoment nog een actie van een gebruiker vereist is (bv. een klant moet worden teruggebeld), kan het contactmoment als ‘onafgerond’ worden opgeslagen. Deze is dan zichtbaar in de lijst van de onafgeronde contactmomenten en/of takenoverzicht.

9100 Sint-Niklaas


Pagina 21 van 49

u. Takenoverzicht Het takenoverzicht is onafhankelijk van de ingelogde gebruiker. Het takenoverzicht geeft een overzicht van alle ‘onderdelen’ waarvoor nog een actie van een gebruiker noodzakelijk is: Onafgeronde contactmomenten: Eenmaal de correcte actie is ondernomen, moet het contactmoment manueel als ‘afgerond’ worden opgeslagen. Het afgeronde contactmoment verdwijnt uit het takenoverzicht. Betalingen die aandacht behoeven: Eenmaal voor een betaling een actie is gebeurd ( toewijzen, terugstorten, ...) verdwijnt die uit het takenoverzicht. Voorbereide brieven: Eenmaal een brief werd afgeprint, verdwijnt deze uit het overzicht. Deze wordt wel opgeslagen onder de contactmomenten van de betreffende retributie, en kan te allen tijde terug worden opgeroepen als pdf-bestand. Voorbereide e-mails: Eenmaal de e-mail werd verstuurd, verdwijnt deze uit het overzicht. Deze wordt wel opgeslagen onder de contactmomenten van de betreffende retributie/parkeerkaart.

v.

Registratie van alle door de parkeerwachters uitgevoerde controles

De parkeerwachters van de mobiliteitswinkel voeren tijdens hun dagtaak meerdere types opdrachten uit: Controles op geparkeerde voertuigen in een betalende zone of een blauwe zone (Controles op zones met een parkeerduurbeperking) Vaststellingen van GAS-inbreuken In een aparte module binnen de backoffice software kunnen deze controles worden gefilterd op de opgeslagen gegevens om zodoende rapportering over de totale opdracht mogelijk te maken. Ook het aantal uren dat een parkeerwachter per dag is ingelogd, worden bijgehouden in de backoffice software voor rapportage-doeleinden.

w.

Rapportagemogelijkheden

Standaard rapportages: Een aantal standaard rapportages zullen worden gedefinieerd door de opdrachtgever. Hiermee wordt bedoeld dat deze bij de levering reeds geconfigureerd zullen zijn in de backoffice software. Het resultaat van een in de software geconfigureerde rapportage is een tabel. Deze tabel kan geëxporteerd worden naar CSV (comma separated values). De verkregen informatie kan ook vanuit de software afgedrukt worden als een opgemaakte tabel met daarbij een grafiek van de verkregen waarden. Op ieder afgedrukt rapport wordt de titel van de rapportage vermeld, en de datum van opmaak.

9100 Sint-Niklaas


Pagina 22 van 49

Iedere standaard rapportage kan op een geregeld tijdstip ( dagelijks, wekelijks, maandelijks – instelbaar) automatisch door de backoffice software worden gecreëerd en weggeschreven in een daartoe bestemde map op de server. Een mobiliteitswinkel-beheerder kan ook zelf een eenvoudige rapportage opstellen. De inschrijver geeft aan op welke manier dit gebeurt. Vanuit het overzicht van de retributiebonnen / controles / GAS-vaststellingen kan a.d.h.v. een aantal gekozen selectiecriteria ook een bepaalde selectie van retributiebonnen / controles / GASvaststellingen verkregen worden. Deze selectie kan geëxporteerd worden. Aantal retributiebonnen /artikel/tijdsinterval Aantal retributiebonnen / zone, tijdsinterval Gemiddeld aantal retributiebonnen /zone/parkeerwachter/ controle Aantal retributiebonnen cumulatief Gemiddeld aantal retributiebonnen per uur per parkeerwachter Evolutie retributiebonnen Inningstermijnen retributiebonnen Retributiebonnen – algemeen (jaar)overzicht. Per tijdsinterval rapporten (datum van-tot). Telkens dit rapport gegenereerd wordt, kan het tijdsinterval gekozen worden. Aantal gecontroleerde voertuigen in verhouding tot het aantal opgemaakte retributiebonnen per zone per dag Aantal gecontroleerde voertuigen in verhouding tot het aantal opgemaakte retributiebonnen per straat per dag Aantal gecontroleerde voertuigen in verhouding tot het aantal opgemaakte retributiebonnen per zone per maand Ook i.v.m. GAS-vaststellingen dienen standaard-rapportages mogelijk te zijn. Aantal vaststellingen / maand, parkeerwachter Aantal vaststellingen / dag, parkeerwachter

Export van gegevens: De gegevens in de back-office applicatie kunnen steeds geëxporteerd worden als lijst (CSV of XML-formaat) om deze als input voor andere applicaties te kunnen gebruiken zonder dat een manuele aanpassing aan het gegenereerde rapport nodig is.

9100 Sint-Niklaas


Pagina 23 van 49

7. Backoffice software voor het beheer van de bewoners- en/of parkeerkaarten De software dient voor het beheer van de bewonerskaarten (on-street). De software dient eveneens voor alle parkeerkaarten, die vandaag en eventueel in de toekomst in de Stad Sint-Nklaas zullen worden voorzien. De opdrachtgever gaat er van uit dat de beschrijving van de verwachtingen omtrent de bewonerskaarten eveneens van toepassing is op alle andere parkeerkaarten, die werden gedetailleerd in bijlagen 4 en 5. Indien dit niet zo zou blijken te zijn, dient de inschrijver de opdrachtgever hierop attent te maken en in te lichten hoe zijn voorgestelde software hieraan remedieert. Hoofdfuncties: Nieuwe aanvragen voor parkeerkaarten behandelen Wijzigingen op bestaande parkeerkaarten behandelen Verlengingen op bestaande parkeerkaarten behandelen Nieuwe parkeerkaarten creëren Parkeerkaarten beëindigen Financiële afhandeling van parkeerkaarten Beheer van de verschillende types parkeerkaarten Beheer van straten en zones Contactmomenten beheren Rapportages maken... In onderstaande punten worden de eisen naar de werking van de backoffice software voor het beheer van de bewonerskaarten uitgebreid omschreven. Alle processen beschreven in dit hoofdstuk zijn gebaseerd op rechtstreeks contact van de mobiliteitswinkel-klant met de mobiliteitswinkel-klantendienst, d.w.z. aan het loket.

a. Opstarten en aanmelden Na het dubbelklikken op het logo van de software moet de gebruiker zich inloggen a.d.h.v. een gebruikersnaam en paswoord. De gebruikersnaam samen met het bijhorende paswoord werkt als een toegangscode tot de software. Na invoer van een bepaalde gebruikersnaam/paswoord combinatie worden de bijhorende rechten van de gebruiker geactiveerd.

9100 Sint-Niklaas


Pagina 24 van 49

b. Configuratie Alle onderdelen onder configuratie kunnen enkel gewijzigd worden door een mobiliteitswinkelbeheerder en niet door een standaard gebruiker. Onder configuratie wordt verstaan de instellingsmogelijkheden van de software om deze te configureren naar de in Sint-Niklaas van toepassing zijnde werkwijzen/ procedures om alle types parkeerkaarten (bewonerskaarten en eventueel toekomstige parkeerkaarten) uit te reiken, te verlengen, te wijzigen, en te beëindigen. Ook het beheer van de gebruikers van de software voor het beheer van bewonerskaarten valt onder configuratie. De configuratie van de software m.b.t. het beheer (uitreiken, verlengen, wijzigen en beëindigen) van alle in dit bestek beschreven types is inbegrepen in de prijsopgave voor de levering en indienststelling. Indien in de toekomst een nieuw type parkeerkaart of abonnement van kracht wordt, of er wordt een nieuwe zone bepaald, dan moet de mobiliteitswinkel-beheerder in staat zijn om zelf een nieuw type / zone / .. te creëren en te configureren. De inschrijver geeft aan hoe dit in zijn werk gaat, en wat de totale configuratiemogelijkheden van de software inhouden.

c. Beheer gebruikers De lijst met alle mogelijke gebruikers wordt beheerd door een mobiliteitswinkel-beheerder. Per gebruiker kan worden ingesteld welke rechten en rollen deze gebruiker heeft.

d. Beheer straten Alle straten die liggen in een betalende zone of een blauwe zone zijn gedefinieerd in de software. De mobiliteitswinkel-beheerder kan steeds een nieuwe straat definiëren, of een reeds gedefinieerde straat op ‘niet-actief’ plaatsen. Koppeling met GIS en/of CRAB is gewenst.

e. Beheer hoofdcategorieën bewonerskaarten/ parkeerkaarten Volgende hoofdcategorieën worden bij opstart gedefinieerd: Bewonerskaarten Gemeentelijke on street parkeerkaarten voor bewoners Gemeentelijke on street parkeerkaarten voor personeel Parkeerkaart voor inname openbaar domein De mobiliteitswinkel-beheerder kan steeds een nieuwe hoofdcategorie definiëren, of een reeds gedefinieerde hoofdcategorie op ‘niet actief’ plaatsen.

9100 Sint-Niklaas


Pagina 25 van 49

f.

Beheer subcategorie bewonerskaarten/ parkeerkaarten

Het definiëren van een subcategorie parkeerkaart bestaat uit verschillende onderdelen: ` - Volgnummer - Hoofdcategorie - Naam - Omschrijving van het type parkeerkaart - Periodes - Tijdseenheid (dag, maand, jaar) - Aantal tijdseenheden - Max. aantal opeenvolgende periodes - Max. aantal kentekens - Wijze van prijsbepaling - Per aantal periodes - Per aantal periodes en per zone - Prijs: gedefinieerd d.m.v. een begindatum (en een einddatum). Prijswijzigingen kunnen ingevoerd worden door aan de huidige prijs een einddatum toe te kennen, de nieuwe prijs kan geconfigureerd worden d.m.v. een nieuwe begindatum. De prijshistoriek wordt bijgehouden. De mobiliteitswinkel-beheerder kan een nieuwe subcategorie definiëren, of een reeds gedefinieerde subcategorie op ‘niet actief’ plaatsen.

g. Beheer zones voor parkeerkaarten Het definiëren van een zone bestaat uit verschillende onderdelen: - Volgnummer van de zone - Naam van de zone - Omschrijving van de zone - Type van de zone Verschillende types worden bij opstart gedefinieerd: -

Bewonerszone in een betalende zone Bewonerszone in een blauwe zone Het maximale aantal , dat kunnen worden uitgereikt per zone.

Informatie in verband met de huidige zones ‘bewonerszones’ (Naam, parkeerstraten, rechthebbende straten) is opgenomen in bijlage 4 en 5.

h. Beheer types aanvrager Het definiëren van een type aanvrager bestaat uit verschillende onderdelen: - Volgnummer van het type aanvrager - Naam van het type aanvrager - Omschrijving van het type aanvrager

9100 Sint-Niklaas


Pagina 26 van 49

i.

Uitreiken van nieuwe parkeerkaarten

Onder dit punt wordt de gewenste werkwijze/procedure omschreven voor het aanmaken van alle huidige types parkeerkaarten: Gemeentelijke parkeerkaart voor bewoners (straatparkeren) Gemeentelijke parkeerkaarten voor bouwwerken (straatparkeren) Wanneer de ‘procedure’ wordt gestart om een nieuwe parkeerkaart of abonnement te maken, wordt automatisch een uniek referentienummer gecreëerd (XXX/XXXX/XXXXX).

j.

Ingeven persoonsgegevens i. Mogelijkheid 1: invullen rijksregisternummer en de naam en voornaam van de aanvrager.

Vervolgens wordt het bevolkingsregister bevraagd, en wordt de rest van de persoonsgegevens automatisch ingevuld. Hiervoor beschikt Sint-Niklaas over een centrale databank die bevraagd kan worden. Het is absoluut noodzakelijk dat deze gegevens overgenomen en gesyncroniseerd worden met deze databank. De applicatie voorziet ook in een export en webservice om de gegevens te kunnen ontsluiten naar andere applicaties. Sint-Niklaas zal beschikken over een Persoonlijke Internet Pagina die alle gegevens van alle applicaties zal verzamelen en ter beschikking stellen van de burger (sleutel: rijksregisternummer). De inschrijver beschrijft in zijn antwoord hoe dit technisch zal gerealiseerd worden. Volgende gegevens worden opgevraagd (ter illustratie – niet limitatief – in detail te bekijken bij uitwerking): - Rijksregisternummer - Naam en voornaam - Adres - Postcode - Gemeente - Land - Taal - Nationaliteit - Geboortedatum en –plaats Volgende gegevens kunnen bijkomend worden ingevuld: - Rijbewijsnummer - Bankrekeningnummer - E-mailadres - Telefoonnummer

ii. Mogelijkheid 2: invullen van alle persoonsgegevens zonder controle in het bevolkingsregister. Ook de keuze van het type aanvrager wordt gedefinieerd: ‘bewoner met kenteken op eigen naam’ of ‘bewoner met kenteken niet op eigen naam’.

9100 Sint-Niklaas


Pagina 27 van 49

De aanvraag wordt geweigerd wanneer de aanvrager niet in een rechthebbend gebied gedomicilieerd is. De aanvraag wordt eveneens geweigerd wanneer de aanvrager niet over een rijbewijs beschikt.

k. Bepaling van de zone: Aan de hand van het adres van de aanvrager wordt de zone bepaald waarin de parkeerkaart geldig zal zijn.

l.

Ingeven kenteken

Afhankelijk van het opgegeven type aanvrager moet een ‘attest voor hoofdgebruik van de wagen’ kunnen worden gescand door de gebruiker. Dit attest wordt automatisch digitaal gekoppeld aan de fiche van de parkeerkaart. Wanneer de aanvrager het ‘attest voor hoofdgebruik van de wagen’ nog niet ingevuld mee heeft gebracht naar het loket, kan toch verdergegaan worden met de aanvraag. De aanvrager krijgt in dit geval nog 10 dagen de tijd om het ingevulde en ondertekende attest te bezorgen. Indien dit niet op tijd wordt bezorgd, wordt de parkeerkaart automatisch geannuleerd. Indien het binnen de 10 dagen wordt bezorgd, kan dit nog achteraf aan de parkeerkaart worden toegevoegd.

m. Controle van het aantal actieve parkeerkaarten voor bewoners op het adres Het maximaal aantal parkeerkaarten voor bewoners en bewonersabonnementen per adres is 2. Wanneer na de controle blijkt dat er nog geen actieve parkeerkaarten voor bewoners of bewonersabonnementen op dit adres zijn, dan wordt verdergegaan voor de creatie van een eerste parkeerkaart. Wanneer na de controle blijkt dat er reeds één actieve parkeerkaart voor bewoners of bewonersabonnement op dit adres is, dan wordt verdergegaan voor de creatie van een tweede parkeerkaart. De gegevens van de reeds actieve parkeerkaart op het adres worden getoond. Wanneer na de controle blijkt dat er reeds twee actieve parkeerkaarten voor bewoners of bewonersabonnementen op dit adres zijn, dan wordt de aanvraag geweigerd. De gegevens van de 2 reeds actieve parkeerkaarten op het adres worden getoond.

n. De aanvrager betaalt meteen het verschuldigde bedrag (automatisch bepaald aan de hand van de gekozen periode) cash of met een betaalkaart. Een bevestigingsbrief met daarbij een plan van de zone waarin de uitgereikte parkeerkaart geldig is, kan worden uitgeprint nadat de aanvraag beëindigd is. Indien een e-mail adres beschikbaar, wordt automatisch een e-mail voorbereid met de digitale bevestigingsbrief en het plan van de parkeerstraten.

9100 Sint-Niklaas


Pagina 28 van 49

o. Parkeerkaarten wijzigen Een parkeerkaart kan gewijzigd worden vanuit het overzicht door de bepaalde parkeerkaart te selecteren en op de knop ‘wijzigen’ te drukken.

p. Parkeerkaarten verlengen De controle op de geldigheidsdatum voor de parkeerkaarten gebeurt iedere dag bij het openen van het softwarepakket door de eerste gebruiker. Een parkeerkaart kan gewijzigd worden vanuit het overzicht door de bepaalde parkeerkaart te selecteren en op de knop ‘wijzigen’ te drukken.

q. Parkeerkaarten beëindigen Parkeerkaarten kunnen manueel worden beëindigd, op specifieke vraag van de houder. Parkeerkaarten worden in sommige gevallen ook automatisch beëindigd. In beide gevallen verandert de status van de parkeerkaart naar ‘beëindigd’. De parkeerkaart met alle gegevens blijft behouden. Eerste en tweede bewonerskaart worden beëindigd wanneer de vervaldatum is verstreken, en er niet is betaald voor een opeenvolgende termijn. Eerste en tweede bewonersabonnement worden beëindigd wanneer de aanvrager is verhuisd buiten een rechthebbend gebied. Beëindigen op vraag van de houder: bedrag moet kunnen worden teruggegeven/gestort

r.

Financieel beheer van de parkeerkaarten

Iedere betaling voor een parkeerkaart wordt geregistreerd in de digitale ‘fiche’ onder ‘betalingen’. Per betaling wordt hiervoor opgeslagen: de datum, het soort betaling (cash, overschrijving, met betaalkaart), het bedrag, een eventuele opmerking. Per parkeerkaart bestaat de mogelijkheid zelf een ‘nieuwe betaling’ aan te maken. i.

Directe betalingen aan de balie

Zoals in de ‘procedures’ hierboven beschreven zijn betalingen aan de balie mogelijk bij aanvraag en verlenging parkeerkaarten voor bewoners aan het loket. Wanneer een klant een betaling doet aan de balie voor een parkeerkaart, dan wordt deze betaling meteen geregistreerd in de ‘fiche’ van de betreffende parkeerkaart. Eveneens kan een ontvangstbewijs in het dubbel worden afgeprint vanuit de ‘wizard’. Wanneer een klant n.a.v. een betalingsvraag via e-mail/brief voor de verlenging van een parkeerkaart een betaling aan de balie doet, kan een ‘nieuwe betaling’ worden aangemaakt onder ‘betalingen’ in de ‘fiche’ van de parkeerkaart. De datum staat automatisch ingevuld, de gebruiker vult het bedrag, de type betaling (cash, krediet- of debet kaart) en een eventuele opmerking in.

9100 Sint-Niklaas


Pagina 29 van 49

Een ontvangstbewijs wordt afgedrukt. De betaling wordt gelinkt aan het openstaande bedrag n.a.v. de betalingsvraag voor verlenging. De verlenging wordt hiermee meteen uitgevoerd. Iedere cashbetaling, geregistreerd in het kasregister van de fysieke kassa (gekoppeld aan het boekhoudpakket van de Stad Sint-Niklaas) wordt ook geregistreerd in de software. ii.

Bankbetalingen: overschrijvingen

Om de registratie van de betalingen via overschrijving te kunnen uitvoeren, moeten CODAbestanden kunnen ingelezen worden. De CODA-bestanden worden door een gebruiker dagelijks in een bepaalde map op de server geplaatst. De Inschrijver voorziet in zijn antwoord een schematisch overzicht van de architectuur om dit toe te lichten. Automatisch worden de CODA-bestanden geïmporteerd en verwerkt door de backoffice software. Na het inlezen worden ze meteen automatisch verwijderd. Per betaling zijn meerdere mogelijkheden: De betaling gebeurde volgens de correcte gestructureerde mededeling en voor het juiste bedrag. De betaling kan worden toegewezen: de betaling wordt geregistreerd onder ‘betalingen’ in de digitale steekkaart van de betreffende parkeerkaart. Het openstaande bedrag wordt automatisch afgeboekt. Wanneer het een betaling voor een verlenging betrof, wordt de verlenging uitgevoerd. De bevestiging wordt per e-mail/brief verstuurd. De betaling gebeurde volgens de correcte gestructureerde mededeling maar niet voor het juiste bedrag. De betaling kan niet automatisch worden toegewezen en komt terecht bij de betalingen die aandacht behoeven. De betaling werd uitgevoerd zonder gestructureerde mededeling. De betaling kan niet automatisch worden toegewezen en komt terecht bij de betalingen die aandacht behoeven. iii.


Er kan in de beheersoftware een dagelijks overzicht gegeven worden van alle betalingen die aandacht behoeven. Er kan op elk moment een rapport gegenereerd worden met dezelfde gegevens. Deze kunnen worden opgedeeld in verschillende groepen, en worden bij voorkeur ook per groep weergegeven: Betaling met correcte gestructureerde mededeling, maar het betaalde bedrag is hoger bedrag dan het openstaand bedrag. Per betaling wordt een overzicht gegeven van het ‘restbedrag’. Afhankelijk van het ‘restbedrag’ kan de gebruiker beslissen om het restbedrag al dan niet terug te storten. (Indien teruggestort wordt dit toegevoegd aan een CODA bestand) Het openstaande bedrag wordt afgeboekt. De eventuele verlenging wordt uitgevoerd. Betaling met correcte gestructureerde mededeling, geen openstaand bedrag. (Dubbele betaling) De gebruiker geeft per individuele betaling, of per groep opdracht om het volledig betaalde bedrag terug te storten (Een CODA-bestand wordt gecreëerd).

9100 Sint-Niklaas


Pagina 30 van 49

Betaling met correcte gestructureerde mededeling, maar het betaalde bedrag is lager bedrag dan het openstaand bedrag. Het openstaande bedrag wordt verminderd met het betaalde bedrag. De eventuele verlenging wordt niet uitgevoerd. Betaling zonder gestructureerde mededeling. Per individuele betaling kan een ‘toewijzingswizard’ worden opgestart. In de wizard is het mogelijk om steekkaarten van parkeerkaarten te zoeken a.d.h.v. meerdere zoekcriteria (naam, adres, ...). Afhankelijk van de gevonden steekkaarten kan de betaling worden toegewezen. Wanneer het betaalde bedrag het volledige bedrag dekt, wordt het openstaande bedrag afgeboekt. De eventuele verlenging wordt uitgevoerd. Wanneer het betaalde bedrag hoger is dan het openstaande bedrag, kan het ‘restbedrag’ worden teruggestort. Wanneer het betaalde bedrag lager is dan het openstaande bedrag, wordt het openstaande bedrag verminderd met het betaalde bedrag. De eventuele verlenging wordt niet uitgevoerd. Een email (brief) wordt telkens voorbereid.

s. Status van een parkeerkaart Afhankelijk van de fase waarin een parkeerkaart zich bevindt, kan een status worden toegekend. Volgende statussen zijn van toepassing: i.

Actief :

De gegevens van de parkeerkaart zijn volledig. Er is geen openstaand bedrag. De vervaldatum is nog niet bereikt. ii.

Behoeft ‘attest voor hoofdgebruik van de wagen’:

Deze status wordt automatisch toegekend wanneer er bij aanvraag geen ‘attest voor hoofdgebruik van de wagen’ werd gekoppeld aan de fiche. Deze status is enkel van toepassing voor de parkeerkaarten voor wanneer het type aanvrager ‘ bewoner met kenteken niet op eigen naam’ is. Wanneer een gebruiker een ‘attest voor hoofdgebruik wagen’ koppelt aan een parkeerkaart met voorgaande status, verandert de status automatisch naar ‘actief’. Wanneer na een periode van 10 dagen nog geen ‘attest voor hoofdgebruik wagen’ aan de fiche is gekoppeld, verandert de status automatisch naar ‘beëindigd’. iii.

Behoeft controle Bevolkingsregister:

Deze status wordt automatisch toegekend wanneer de controle van het bevolkingsregister bij aanvraag van een parkeerkaart voor bewoners wordt ‘overruled’. Dit gebeurt wanneer het domicilieadres van de aanvrager nog niet werd gewijzigd in het bevolkingsregister.

9100 Sint-Niklaas


Pagina 31 van 49

9100 Sint-Niklaas


Pagina 32 van 49

iv.

Behoeft betaling voor verlenging:

Deze status wordt automatisch toegekend wanneer de vervaldatum van een parkeerkaart voor bewoners is bereikt. Wanneer na een periode van 14 dagen na de vervaldatum nog geen betaling werd geregistreerd voor de verlenging, verandert de status automatisch naar ‘beëindigd’. v.

Beëindigd:

Wanneer de status ‘ beëindigd’ automatisch wordt toegekend, wordt de reden hiervoor mee bewaard. Deze status wordt automatisch toegekend wanneer: 1. 2.

De vervaldatum van een bewonersabonnement is bereikt. (Reden: vervaldatum bereikt) De termijn van een parkeerkaart voor inname openbaar domein is afgelopen. (Reden: Termijn afgelopen)

Zie bovenstaande beschreven automatische veranderingen van de status naar ‘beëindigd’. Wanneer de status ‘ beëindigd’ manueel wordt toegekend, wordt de reden hiervoor mee bewaard. Deze status wordt automatisch toegekend wanneer: 1.

Uit de controle met het bevolkingsregister blijkt dat de aanvrager is verhuisd buiten/binnen de stad. (Reden: verhuisd)

2.

Uit de controle met het bevolkingsregister blijkt dat de aanvrager is overleden. (Reden: overleden)

3.

Dit de wens is van de klant (Reden: op vraag van de klant)

t.

Historieken

Per parkeerkaart wordt een historiek van de acties bijgehouden. Aanmaak parkeerkaart : wanneer + wie Automatische statuswijzigingen: wanneer + reden Manuele statuswijzingen: wie +wanneer + reden

u.

Contactmomenten

Per parkeerkaart wordt een historiek van de contactmomenten met de klant bijgehouden. Deze worden weergegeven in een chronologisch overzicht. Contactmomenten kunnen automatisch/manueel aangemaakt worden: i.

Manueel aangemaakte contactmomenten:

Door een gebruiker kan in de fiche van de parkeerkaart een nieuw contactmoment aangemaakt worden.

9100 Sint-Niklaas


Pagina 33 van 49

Afhankelijk van het gekozen type zijn er verschillende mogelijkheden. Telkens kan worden aangeduid of het om een inkomend of uitgaand contact gaat. Telkens wordt de datum, het uur en de gebruiker die het contactmoment aanmaakt, opgeslagen bij het contactmoment. Verschillende types: Telefoongesprek: Inhoud van het telefoongesprek kan worden genoteerd. E-mail: E-mail kan worden gelinkt aan het contactmoment (.pdf). Brief: Inkomende brief/fax kan worden gelinkt aan een contactmoment (.pdf). Uitgaande brief kan door middel van verschillende keuzemogelijkheden aan de hand van een sjabloon worden samengesteld. ii.

Automatisch aangemaakte contactmomenten:

E-mail/ brief die automatisch wordt voorbereid voor de betalingsaanvraag voor de verlenging van een termijn van een parkeerkaart voor bewoners. Wanneer voor een aangemaakt contactmoment nog een actie van een gebruiker vereist is ( bv. een klant moet worden teruggebeld), kan het contactmoment als ‘onafgerond’ worden opgeslagen. Deze is dan zichtbaar in de lijst van de onafgeronde contactmomenten .

v. Controle bevolkingsregister Alle persoonsgegevens van de parkeerkaarten voor bewoners en de bewonersabonnementen worden geregeld gecontroleerd in het Bevolkingsregister. De Inschrijver beschrijft hiervoor de oplossing in zijn antwoord. Deze controle gebeurt eveneens automatisch eenmaal in de maand ’s nachts.

Bedoeling van de maandelijkse controle en gevolggeving: Opsporing van nieuwe bewoners in een rechthebbend gebied. (wekelijks) Automatische voorbereiding van een brief/e-mail, indien er ondertussen nog geen aanvraag is gebeurd. Opsporing van parkeerkaart- houders die verhuisd zijn naar een adres buiten een rechthebbend gebied. (maandelijks) Automatische voorbereiding van een brief/e-mail met de mededeling dat de parkeerkaart zal worden beëindigd. Opsporing van parkeerkaart- houders die verhuisd zijn naar een ander rechthebbend gebied. (tweewekelijks)

9100 Sint-Niklaas


Pagina 34 van 49

Automatische voorbereiding van een brief/e-mail voor kennisgave en met de mededeling dat de parkeerkaart zal worden aangepast naar het nieuwe domicilieadres. Opsporing van parkeerkaart- houders die zijn overleden. (dagelijks) De voorbereide e-mails/brieven komen terecht in het overzicht van de voorbereide brieven of in het overzicht van de voorbereide e-mails. Het overzicht met de resultaten van de maandelijkse controle met het bevolkingsregister wordt de volgende werkdag in het takenoverzicht getoond: Opsporing van nieuwe bewoners in een rechthebbend gebied. Vermelding aantal klaargezette brieven Opsporing van parkeerkaart- houders die verhuisd zijn naar een adres buiten een rechthebbend gebied. Overzicht van de parkeerkaarten die moeten worden beëindigd. Opsporing van parkeerkaart- houders die verhuisd zijn naar een ander rechthebbend gebied. Overzicht van de parkeerkaarten die moeten worden gewijzigd. Opsporing van parkeerkaart- houders die zijn overleden Overzicht van de parkeerkaarten die moeten worden beëindigd.

w. Takenoverzicht Het takenoverzicht is onafhankelijk van de ingelogde gebruiker. Het takenoverzicht geeft een overzicht van alle ‘onderdelen’ waarvoor nog een actie van een gebruiker noodzakelijk is: i.

Onafgeronde contactmomenten

Eenmaal de correcte actie is ondernomen, moet het contactmoment manueel als ‘afgerond’ worden opgeslagen. Het afgeronde contactmoment verdwijnt uit het takenoverzicht. ii.

Onafgeronde aanvragen

Overzicht van de fiches met status ‘Behoeft attest voor hoofdgebruik van de wagen’ en ‘Behoeft controle Bevolkingsregister’. iii.

Parkeerkaarten die aandacht behoeven

Overzicht van de fiches met status ‘Behoeft aandacht’ iv.


Eenmaal voor een betaling een actie is gebeurd ( toewijzen, terugstorten, ...) verdwijnt die uit het takenoverzicht.

9100 Sint-Niklaas


Pagina 35 van 49

v.

Voorbereide brieven

Eenmaal een brief werd afgeprint, verdwijnt deze uit het overzicht. Deze wordt wel opgeslagen onder de contactmomenten van de betreffende parkeerkaart, en kan te allen tijde terug worden opgeroepen als pdf-bestand. vi.

Voorbereide e-mails

Eenmaal de e-mail werd verstuurd, verdwijnt deze uit het overzicht. Deze wordt wel opgeslagen onder de contactmomenten van de betreffende parkeerkaart.

x. Rapportagemogelijkheden Het resultaat van een in de software geconfigureerde rapportage is een tabel. Deze tabel kan geëxporteerd worden naar CSV. De verkregen informatie kan ook vanuit de software afgedrukt worden als een opgemaakte tabel met daarbij een grafiek van de verkregen waarden. Op ieder afgedrukt rapport wordt de titel van de rapportage vermeld, en de datum van opmaak. Vanuit het overzicht van de parkeerkaarten kan a.d.h.v. een aantal gekozen selectiecriteria ook een bepaalde selectie van parkeerkaarten verkregen worden. Deze selectie kan geëxporteerd worden naar CSV. Een mobiliteitswinkel-beheerder kan ook zelf een eenvoudige rapportage opstellen. De inschrijver geeft aan op welke manier dit gebeurt. Volgende rapportages zijn bij de levering geconfigureerd in de backoffice software Aantal actieve parkeerkaarten voor bewoners per straat, per zone, per maand en per jaar

y. Software moet gebruiksvriendelijk zijn Software moet gebruiksvriendelijk zijn: uitbreiden met vraag voor een '3rd party acces¹ (dwz een handelaar kan inloggen en de parkeergelden voor zijn klant betalen vanuit zijn account.

9100 Sint-Niklaas


Pagina 36 van 49

8. Algemene specificaties handterminals, software en werking. a. Storingsmelding: Wanneer de handterminal (hardware) niet naar behoren functioneert, dan wordt hiervan een visuele en auditieve melding gegeven met vermelding welk onderdeel een storing heeft. Voorbeelden van de hiermee bedoelde storingen: lage batterij, geen netwerkontvangst, geen GPS-signaal, ...

b. Raadplegen databases : Databases dienen geraadpleegd te worden via een beveiligde web service of URL. De inschrijver is verantwoordelijk voor de technische uitvoering.

c. Gegevenstransfer naar de backoffice: De transfer naar de backoffice van de alle ingevoerde gegevens (vaststellingen (incl. foto’s), meldingen (incl. foto’s) ,...) gebeurt standaard realtime. Wanneer die incidenteel niet meteen kan gebeuren, dan gebeurt dit automatisch van zodra het technisch mogelijk is, in de loop van de werkdag. Iedere 5 minuten probeert de software deze automatisch door te sturen. De parkeerwachter dient hiervoor niet manueel opdracht te geven. Wanneer de gegevenstransfer aan het einde van de werkdag nog steeds niet is doorgegaan, dan gebeurt de transfer naar de backoffice automatisch wanneer de handterminals ’s avonds op het laadstation worden geplaatst.

d. Beveiliging gegevenstransfer: Het af- en opladen van de gegevens van/naar de handterminals gebeurt op een manier die de integriteit en de correctheid van de gegevens garandeert. De inschrijver beschrijft de beveiliging en het verloop van dit proces.

e. Beveiliging gegevens: De gegevens die deel uitmaken van de retributiebonnen dienen beveiligd te worden. De inschrijver beschrijft de manier van beveiliging.

f.

Response tijden voor het raadplegen van databases:

De response tijd van een opvraging/match van gegevens (E-ticket en bewonerskaarten,...) moet aanvaardbaar en stabiel zijn. De response tijd moet onafhankelijk van de staat van het geheugen en de batterij gelijk blijven. Er wordt gestreefd naar een interval van 1 tot 3 seconden per opvraging/match, met een maximum van 4 seconden.

9100 Sint-Niklaas


Pagina 37 van 49

g. Synchronisatie: De synchronisatie van de interne klok van de handterminal gebeurt automatisch iedere dag, bij voorkeur via UTC.

h. Automatisch back-up: De handterminals dienen de verwerkte gegevens op te slaan en te bewaren in geval van schade of uitvallen van de handterminal. De inschrijver dient hierbij de intern gebruikte procedure te beschrijven.

i.

Handmatige back-up:

De inschrijver beschrijft de procedure voor het nemen van een handmatige back-up (‘disaster recovery’) in het geval de gegevens in de handterminal niet meer kunnen geraadpleegd worden.

j.

Virtueel toetsenbord:

Het toetsenbord moet op elk moment kunnen ge(de)activeerd worden. Het toetsenbord wordt ge(de)activeerd door op een kleine knop te drukken die op elk scherm aanwezig is. Wanneer het toetsenbord actief is, dan neemt dit een gedeelte van het scherm in beslag. Het toetsenbord blijft actief tot dit door de gebruiker wordt gedeactiveerd.

k. Identificatie handterminal: De handterminal moet identificeerbaar zijn in het backoffice systeem. Daartoe heeft iedere handterminal een uniek ID-nummer.

l.

Privacy:

Alle gebruikte processen en procedures dienen te beantwoorden aan de wet ter bescherming van de privacy.

m. Rechtsgeldigheid De gebruikte processen en procedures beantwoorden aan alle van toepassing zijnde wetten en zijn derhalve rechtsgeldig.

n. Energiebesparing: Slaapstand (standby-modus van de handterminal) wordt ingeschakeld na een door de mobiliteitswinkel-beheerder instelbare tijd. Activatie gebeurt door drukken op de aan/uit knop. Scherm wordt uitgeschakeld na een door de mobiliteitswinkel-beheerder instelbare tijd. Activatie door tikken op het scherm.

9100 Sint-Niklaas


Pagina 38 van 49

9. Technische specificaties van de handterminals voor het toezicht op geparkeerde voertuigen Ergonomie

De handterminals moeten ergonomisch in de hand liggen, dit zowel voor rechts- als linkshandigen.

Gewicht

Maximum 500 gram (incl. batterij). Bij voorkeur zo licht mogelijk.

Scherm

- Kleurenscherm met een min. resolutie van 640x480 pixels en een min. kleurdiepte van 8bits. - Touchscreen met backlight, moet kunnen gelezen worden zonder bijverlichting - Het touch screen moet kunnen gekalibreerd worden - Minimum afmetingen 3,5 inch - Goede leesbaarheid en bruikbaarheid onder alle weersomstandigheden (dag/nacht/regen/intense zon/mist/...) - Scherm moet vanuit meerdere zichthoeken gelezen kunnen worden. - Slagvast en bestand tegen Uv-straling, stickers, graffiti, reinigingsproducten,...

Toetsenbord

-

Autonomie

- Minimale autonomie van 9 uur bij het toestel in werking, bij verzenden van data ( retributiebonnen en foto’s) iedere 5 minuten. - Gegevens moeten bewaard worden bij te lage spanning en bij het wisselen van batterij.

Opladen/ batterij

- De batterij van het toestel wordt opgeladen wanneer het toestel zich in het laadstation bevindt. - Mogelijkheid tot het eenvoudig wisselen van batterij. - Losse batterijen zijn verkrijgbaar, en kunnen apart van het toestel worden opgeladen ( bij voorkeur geïntegreerd in het laadtoestel van de handterminal zelf) - De verschillende types batterijen zijn onderling uitwisselbaar.

Oplaadtijd Valbestendigheid

Binnen drie uren voor 95% opgeladen. - Aantoonbaar (door voorleggen certificaat) bestand tegen een val van 1,5m op beton. - Voorzien van een 'valbescherming' (vb. band om rond de hand te doen)

Weersbestendigheid

Geïntegreerd tfototoestel Kentekenscanning Geïntegreerde GPSchip

9100 Sint-Niklaas

Fysiek of virtueel toetsenbord (AZERTY), 1 toets per letter Lichte toetsaanslag Er moet bij voorkeur niet geschakeld worden tussen cijfers en letters Moet bruikbaar zijn zonder bijverlichting, toetsverlichting is noodzakelijk

Bestand tegen alle in België voorkomende weersomstandigheden, voldoen aan min. IP54

- Autofocus lens - Minimale resolutie van 3,0 megapixel (dpi instelbaar) - Ingebouwde flitser Mogelijkheid tot het scannen van kentekens. - Optie - Accuraatheid 10 meter - Geïntegreerde A-GPS


Pagina 39 van 49

Intern geheugen

- Minimaal 256 Mb RAM / 1Gb Flash - Intern geheugen is uitbreidbaar met geheugenkaart

Processor Operating system Communicatie

Min. 800 MHz. Processor Windows of Android - Doorsturen en ontvangen van gegevens gebeurt via 3G (In de toekomst moet 4G ook mogelijk zijn) - De communicatie infrastructuur is gecertifieerd/ wordt aanvaard door Proximus - Andere communicatie is mogelijk ( Wi-Fi, Bluetooth,...) De handterminal moet kunnen functioneren als een GSM toestel, d.w.z. mogelijkheid tot opbellen en opgebeld worden en de mogelijkheid voor het versturen en ontvangen van tekstberichten.

Telefoon

Audio Aan - uit toets Accessoires: Tas

Extra accessoires te verkrijgen:

Uitbreidbaarheid

9100 Sint-Niklaas

Geluid moet uitgeschakeld kunnen worden. Robuuste uitvoering, groter dan andere toetsen. - Bijpassende tas/bescherming moet verkrijgbaar zijn. - Alle functionaliteiten blijven behouden wanneer de handterminal zich in de tas bevindt. - Tas is voorzien van een schouderriem en kan worden vastgemaakt aan een riem ( diefstal) - Handterminal moet op eenvoudige wijze uit de tas kunnen gehaald worden. - Noodzakelijke kabels en adapters - laadstation - Schermbeschermer ( beschermsticker op de afmetingen van het scherm) - Stylus De handheld moet toelaten om extra software of uitbreidingen aan de bestaande software te voorzien zodat extra functionaliteiten eenvoudig toegevoegd kunnen worden in functie van controle openbaar domein. Dit kan ook via het openen van een webapplicatie op de handheld via de browser.


Pagina 40 van 49

PERCEEL 2 1. Detail verwachtingen front-end software voor de vaststellingen voor Gemeentelijke Administratieve Sancties De parkeerwachters zullen eveneens verschillende vaststellingen voor gemeentelijke administratieve sancties opmaken. Wanneer de parkeerwachter bij de locatie van een controle de mogelijkheid ‘GAS ‘heeft aangevinkt, dient hij de verschillende inbreuken, die werden gedefinieerd door een beheerder in de back – office te kunnen openen via een combo box. Hij kan de vaststelling definiëren, foto’s nemen en een toelichting invoeren. Vooraleer de vaststelling af te ronden, wordt een overzicht getoond van de belangrijkste gegevens, volledig analoog aan de werkwijze voor retributiebonnen. Wanneer de parkeerwachter op de knop ‘Versturen’ heeft gedrukt, wordt de volledige vaststelling doorgestuurd naar de backoffice software voor de opvolging van GAS van de Stad Sint-Niklaas. De back-office GAS software is de oplossing Ariadne van CIPAL. Deze applicatie voorziet in de mogelijkheid tot koppelen via CSV bestanden. De bijlagen en foto’s, samengevoegd tot een pdf-bestand, kunnen eveneens doorgestuurd worden. De Inschrijver is bij de uitwerking van de koppeling verantwoordelijk om contact op te nemen met CIPAL en de Stad Sint-Niklaas om samen met hen een gezamenlijke oplossing uit te werken voor deze koppeling. Deze wordt - voorafgaand aan de implementatie - verplicht gedocumenteerd in een “interfaceagreement” en ondertekend door alle betrokken partijen (3). De applicatie Ariadne voorziet in een interface en koppelt momenteel al met het systeem ISLP (politie). De aangeboden software kan op een gelijkaardige manier werken. Bijlagen kunnen eveneens geïmporteerd worden mits concrete afspraken over naam en datum van de bestanden. De verwerking Ariadne – GAS , koppeling met ISLP , CRAB , en de ter beschikking te stellen CSVgegevens wordt verder toegelicht . De volledige afhandeling van de GAS moet gebeuren in Ariadne. De vaststelling en evt. een status-update gebeurt in de front- en/of back-end software van de inschrijver. Voor de front-end software voor de vaststellingen voor GAS zijn de verwachtingen betreffende onderstaande punten compleet analoog aan die van de retributiebonnen, zoals hierboven beschreven onder voor de retributies. Opmaak GAS Foto’s nemen Overzicht van de GAS Overzicht al opgemaakte GAS Verzoek tot annulatie Extra informatie Doorgeven van een melding

9100 Sint-Niklaas


Pagina 41 van 49

Telefoneren / tekstberichten Registratie van alle GAS Doorgeven van een melding

2.

Verwerking Ariadne GAS

De software moet volgende gegevens ter beschikking stellen in CSV-formaat om een koppeling met Ariadne GAS te kunnen realiseren. De kwaliteit van de gegevens is heel belangrijk. Ariadne GAS maakt gebruik van authentieke bronnen zoals het rijksregister, CRAB en VKBO. Naast de externe databronnen - DIV en CRAB – verwachten we voor de oplossing van de Inschrijver ook een koppeling met de interne bron Themis Web voor opzoeken & controle burger gegevens. De koppeling met deze authentieke bron is cruciaal voor de garantie van de kwaliteit van data. De burgergegevens (rijksregisternummer) en/of Bedrijfsgegevens (Ondernemingsnummer) zullen in andere processen verder gebruikt worden zoals schuldbemiddeling, GAS, etc. Momenteel zijn Rijksregisternummer of VKBO -nummer verplicht om mee te geven, omdat deze gegevens uniek zijn en zorgen voor een juiste match met de overtreder of verdachte in ThemisWeb.

Verklaring van de interface met Ariadne Gas – ter illustratie (Voor de laatste, correcte versie gelieve CIPAL DV te contacteren, CP: Hans Bartholomeus of Koen Goor). Onderstaande velden (infra) zijn overgenomen uit de interface van ISLP (vaststellingen Politie) met Ariadne GAS. Niet alle velden zijn van toepassing voor de parkeerwachters. Het biedt wel een beeld van de verwachting van het bestand dat aangeleverd dient te worden. Met CIPAL moet tijdens de uitwerking afgesproken worden welke velden verplicht zijn. We veronderstellen dat de Inschrijver zich op voorhand op de hoogte stelt en in zijn antwoord bevestigt dat alle verplichte velden kunnen aangeleverd worden door zijn oplossing en de interface kan gerealiseerd worden – tenzij dit expliciet staat vermeld en met verwijzing naar de communicatie met CIPAL die de Inschrijver heeft ondernomen voorafgaand aan het indienen van zijn offerte. Daarnaast vragen wij dat eventuele foto’s gebundeld in PDF bestanden digitaal ter beschikking worden gesteld samen met de aangeleverde CSV bestanden. De namen van de PDF bestanden moeten afgelijnd zijn en moeten ook opgebouwd worden in het resultaatbestand. De naam van de PDF moet bestaan uit: de laatste 6 cijfers van het PV, het jaartal van datum opmaak PV met extensie .PDF. BV: PV nummer: ME.98.L1.400000 , datum opmaak PV: 20150101, naam PV PDF: 4000002015.PDF (Evt. indien afgesproken met CIPAL kan hiervan afgeweken worden. Een interface-agreement – document ter bevestiging moet hiervoor opgemaakt worden). Het CSV-bestand en de eventuele pdf’s worden automatisch op een bepaalde plaats op een server van Sint-Niklaas geplaatst. De leverancier voorziet een transfer-programma (SFTP, of andere) om deze bestanden automatisch (geen manuele handeling) op de servers van Sint-Niklaas te plaatsen. Hiervoor wordt ook een Interface-Agreement document opgemaakt. Sint-Niklaas kan tijdens de implementatie van het project de voorgestelde oplossing steeds weigeren indien deze niet voldoet aan de verwachtingen (veiligheid, gebruiksgemak, etc) en een

9100 Sint-Niklaas


Pagina 42 van 49

eigen technische oplossing voorstellen. De eventuele kosten om deze te ontwikkelen worden gedragen door de Inschrijver. In het antwoord en de offerte van de Inschrijver verwachten we een korte omschrijving van deze oplossing en manier van koppelen. (Copy uit ISLP – bepaalde kolommen niet van toepassing, details verder te bespreken tijdens uitvoering project).

Voor de koppeling met ISLP wordt ook voorzien in het toevoegen van bijlagen (pdf) met een bepaalde benaming. Deze structuur kan dienen ter informatie voor de koppeling van de software met Ariadne voor het doorsturen van bijlagen (foto’s, etc). Daarnaast vragen wij de politie de PV’s digitaal (PDF bestanden) ter beschikking te stellen samen met de aangeleverde CSV bestanden.

9100 Sint-Niklaas


Pagina 43 van 49

De namen van de PDF bestanden moeten afgelijnd zijn en moeten ook opgebouwd worden in het resultaatbestand (uit IMT). De naam van de PDF moet bestaan uit: de laatste 6 cijfers van het PV, het jaartal van datum opmaak PV met extentie .PDF. BV: PV nummer: ME.98.L1.400000 , datum opmaak PV: 20150101, naam PV PDF: 4000002015.PDF

Zo komen we tot het resultaat van een resultaatbestand met bijhorende PDF (PV) documenten.

9100 Sint-Niklaas


Pagina 44 van 49

PERCEEL 3 1. Verwachtingen digitaal loket De inschrijver ontwerpt, levert, plaatst en stelt een digitaal loket in dienst. Dit is een web-based systeem voor het afhandelen van alle mogelijke parkeeractiviteiten, zoals in dit lastenboek uitvoerig werd beschreven. Dit platform moet de burger toelaten via het web dezelfde activiteiten betreffende parkeren uit te voeren als de diensten, die hij kan krijgen in de mobiliteitswinkel. Dit web-based platform dient onder meer , niet limitatief , volgende zaken te bevatten: Algemene informatie over parkeren in Sint-Niklaas Beschrijving van alle parkeerproducten Voorwaarden tot verkrijging van deze producten Kostprijzen van de producten Wetgeving en reglementen rond parkeren in de Stad Sint-Niklaas Mogelijkheid tot aanvragen en betalen van de parkeerproducten (de inschrijver stelt voor hoe de burger kan inloggen ; e-id – e-mail en hoe hij de integriteit van de gegevens garandeert) Mogelijkheid tot aanvragen en betalen van de parkeerproducten (de inschrijver stelt voor hoe de burger kan inloggen ; e-id – e-mail en hoe hij de integriteit van de gegevens garandeert) we geven de voorkeur aan mydigipass.com. De mogelijkheid om hiermee te koppelen is een belangrijk selectiecriterium. Mogelijkheid tot indienen van klachten Termijnen FAQ Dit digitaal platform wordt geleverd door de inschrijver inclusief link tussen deze oplossing en back-end software parkeerbeheer; inclusief installatie & opleiding front-office en koppeling; inclusief onderhoudscontract voor een periode van 4 jaar ingaand na de garantieperiode. Het platform is bij voorkeur ontworpen in de huisstijl van de Stad Sint-Niklaas. De vereiste van een open digitaal platform is hier heel belangrijk. In de loop van 2016-2017 wordt in Sint-Niklaas het nieuwe dienstverleningsconcept uitgewerkt. Het digitale luik neemt een belangrijk deel in. De mogelijkheid tot koppeling van het digitaal loket aan de website en de ondersteunende software (Green Valley suite) is van cruciaal belang. Deze koppeling verloopt in 2 richtingen, applicaties die gegevens van het digitaal loket raadplegen (overzicht aanvragen van een bepaald persoon opvragen via een webservice, beschrijving producten ophalen, etc.) of gegevens rechtstreeks aanmaken via de API (bijv. Een klacht). Een “link” (url-kopppeling) naar een dossier in het digitale loket moet eveneens mogelijk zijn waarmee de gebruiker rechtstreeks kan doorklikken van de link naar het dossier. De inschrijver beschrijft in zijn antwoord de mogelijkheden van het digitale loket, zowel functioneel als technisch. Het spreekt voor zich dat kwaliteit van de gegevens hier een belangrijke rol spelen. We verwachten voor de oplossing van de Inschrijver een koppeling met de interne bron Themis Web.

9100 Sint-Niklaas


Pagina 45 van 49

De koppeling met deze authentieke bron is cruciaal voor de garantie van de kwaliteit van data. De burgergegevens (rijksregisternummer) en/of Bedrijfsgegevens (Ondernemingsnummer) zullen in andere processen verder gebruikt worden.

9100 Sint-Niklaas


Pagina 46 van 49

VEREISTEN BIJ PERCELEN 1 – 2 en 3 1. Algemeen De gevraagde functionaliteiten staan opgelijst per hoofdfunctionaliteit. Per hoofdfunctionaliteit moet de inschrijver een beschrijving geven hoe de gevraagde functionaliteiten worden gerealiseerd. Indien aan bepaalde gevraagde functionaliteiten niet kan worden voldaan moet de inschrijver dit expliciet vermelden met verwijzing naar de paragraaf in dit document. De inschrijver geeft aan of de functionaliteit: - Niet voorzien wordt - Momenteel niet aanwezig, wordt voorzien tegen datum: … / … / …… ZONDER MEERKOST - Gedeeltelijk aanwezig is. aangeven wat ontbreekt. Indien er niets wordt vermeld, wordt aangenomen dat gevraagde functionaliteit volledig afwezig is. Indien achteraf blijkt dat de vermelde gegevens niet correct zijn, kan dit tot schorsing leiden van de gunning. De toepassing moet webbased toegankelijk zijn. Zowel de online, als de lokale loket gebruikers als de back-office gebruikers connecteren via webbrowser met de toepassing. De toepassing ondersteunt de klassieke webbrowsers zijnde IE, Google Chrome als Mozilla Firefox. De applicatie kan eventueel ook via een app beschikbaar gemaakt worden voor de mobiele gebruiker. Sint-Niklaas maakt gebruikt van iPad (Apple). De gegevens verlopen over een beveiligde connectie. De lay-out van de toepassing moet in lijn zijn met de huisstijl van stad en OCMW van Sint-Niklaas

2. Vrijblijvende functionaliteiten De inschrijver geeft aan welke niet-gevraagde functionaliteiten er standaard in de voorgestelde toepassing zitten vervat. De inschrijver verduidelijkt welke meerwaarde deze functionaliteiten kunnen betekenen in de voorgestelde context bij de stad Sint-Niklaas.

3. Integraties Alle oplossingen dienen te voorzien in standaard koppelingen Front-Back – end zoals hierboven beschreven. De inschrijver beschrijft en verduidelijkt op een schematische manier de mogelijkheden voor integraties van/met back-end en export -mogelijkheden van gegevens. Daarnaast worden volgende koppelingen gevraagd – Gelieve deze apart te budgetteren: -

-

Koppeling GAS-gegevens Back-office met Ariadne GAS – CIPAL voor verwerking CSV bestand met alle noodzakelijke gegevens voor Ariadne en bijlagen (foto’s, ed) Manueel of automatisch te exporteren uit Back-office applicatie. Export bestanden worden op een shared-drive gezet (intern) om verwerkt te worden in Ariadne. Koppeling Midoffice – Green Valley (verder te bekijken volgens processen) Koppeling Mercurius boekhouding – CIPAL (verder te bekijken volgens processen)

9100 Sint-Niklaas


Pagina 47 van 49

-

Koppeling Themis Web/bevolkingsregister/VKBO - CIPAL (voor opzoeken, controle burger gegevens) Koppeling GIS of CRAB-AGIV voor stratenlijst Koppeling DIV

Voorafgaand aan de implementatie van de interfaces wordt elke koppeling verplicht gedocumenteerd in een “interface-agreement” en ondertekend door alle betrokken partijen. Sint-Niklaas kan tijdens de implementatie van het project de voorgestelde oplossing steeds weigeren indien deze niet voldoet aan de verwachtingen (veiligheid, gebruiksgemak, etc) en in samenspraak met de leveranciers een alternatieve, technische oplossing binnen de bestaande overeenkomst, voorstellen. Aan de leverancier wordt gevraagd om een technische beschrijving te geven van de bestaande oplossing of een voorstel tot oplossing aan te reiken voor de beschreven onderdelen. Belangrijk is dat deze integraties mogelijk zijn (en dat er op voorhand beschreven staat hoe dit technisch is uitgewerkt vooraleer de opdracht toe te kennen) en dat de alle dossiergegevens eenvoudig te ontsluiten zijn. Het document kan dan samen met het (technische) voorstel van de leverancier dienen als basis voor de scope-bepaling, wie welke ontwikkeling doet en via welke technische oplossing. Het moet dan aan de hand van het voorstel mogelijk zijn om toekomstige bottle-necks en (technische) beperkingen te identificeren of een vervolg-traject af te spreken.

4. Technische vereisten Toegang tot de applicatie De gegevens in de databank worden beschreven door de leverancier in een handleiding en de gegevens zijn volledig ter beschikking en in eigendom van Sint-Niklaas. De applicatie en de databank moet toelaten om gegevens te exporteren naar externe applicaties op een automatische manier (niet enkel via een manuele export-import). De oplossing beschikt ook over een API (http://nl.wikipedia.org/wiki/Application_programming_interface) om gegevens op een programmatische manier op te vragen en up te daten vanuit externe applicaties. De gegevens worden gestockeerd in een open database en zijn eigendom van Sint-Niklaas. Via een API of andere tools kunnen de gegevens steeds op een eenvoudige manier opgevraagd worden. De gegevens staan ter beschikking en zijn vrij te gebruiken door Sint-Niklaas of andere leveranciers in opdracht van Sint-Niklaas. Office 2007 en 365 De applicatie is compatibel met Office 2007 en Office 365-producten. Deze laatste worden regelmatig ge-upgraded. De Inschrijver bevestigt dat de oplossing steeds compatibel is met Office 2007 en met de laatste versie van Office 365. Zoniet kan dit tot een opschorting van betaling leiden totdat de oplossing werkt met de laatste versies van de Office365-producten. Technische beschrijving en back-up De inschrijver geeft een beschrijving van de gegarandeerde technische infrastructuur en bijhorende back-up oplossing alsook de monitoring-aspecten die leiden tot de aangeboden SLA. Bijlage Er wordt gevraagd voor een cloud-oplossing. De annex is een beschrijving van de technische componenten in Sint-Niklaas (in bijlage) maakt echter wel integraal onderdeel uit van het bestek en de technische voorwaarden waar van toepassing. Software

9100 Sint-Niklaas


Pagina 48 van 49

Indien de leverancier zijn activiteiten om één of andere reden stopzet, moet de broncode van de volledige toepassing ter beschikking gesteld worden van de stad, zonder dat daarbij enige vergoeding kan worden geëist en volledig vrij van auteursrechten of moet continuïteit voorzien worden. mydigipass.com Software moet compatibel zijn/mogelijkheden bieden voor een SSO vanuit de burger (Single Sign-on). We opteren voor een generieke methode zoals mydigipass.com

5. Plan van Aanpak De inschrijver moet een plan van aanpak bijvoegen met een gedetailleerd stappenplan en timing ter realisatie van het volledige project. Tevens wordt de samenstelling van het projectteam beschreven. Verder geeft de inschrijver aan wat zijn strategie en mogelijkheden zijn voor het integreren/overnemen van core-gegevens uit bestaande toepassing(en). (Access-databank).

6. Opleiding De inschrijver geeft aan welke opleidingen nodig zijn ter realisatie van het project (eindgebruikers en beheerders opleiding). Per nodige opleiding wordt een korte beschrijving alsook de voorgestelde duurtijd en max. aantal deelnemers vermeld. De opleidingen gaan idealiter door in de opleidingslokalen van stad en OCMW van Sint-Niklaas. Per opleiding moet de overeenkomstige (gebruikers en administrators) documentatie worden voorzien.

7. Documentatie Volgende documentatie (in het Nederlands) moet worden opgeleverd: Functioneel referentie handboek Gebruikers handleiding (bij de opleiding) Administrators handleiding (bij opleiding) Technische handleiding (ICT-ondersteuning interfaces, etc.)

9100 Sint-Niklaas


Pagina 49 van 49

B. TECHNISCHE VOORSCHRIFTEN

Recommend Documents