BESTEK LEVERINGEN SOFTWARE VRIJETIJDSDIENSTEN GEMEENTE ZWIJNDRECHT VEREENVOUDIGDE ONDERHANDELINGSPROCEDURE MET BEKENDMAKING. Gemeente Zwijndrecht

GEMEENTE ZWIJNDRECHT

PROVINCIE ANTWERPEN

Ref.: 481

BESTEK VOOR DE OVERHEIDSOPDRACHT VOOR

LEVERINGEN MET ALS VOORWERP

“SOFTWARE VRIJETIJDSDIENSTEN GEMEENTE ZWIJNDRECHT”

VEREENVOUDIGDE ONDERHANDELINGSPROCEDURE MET BEKENDMAKING

Opdrachtgevend bestuur

Gemeente Zwijndrecht

Blz. 1


PROVINCIE ANTWERPEN

Ref.: 481

Inhoudsopgave I. ADMINISTRATIEVE BEPALINGEN ................................................................................................... 5 I.1 BESCHRIJVING VAN DE OPDRACHT ...................................................................................................... 5 I.2 IDENTITEIT VAN DE OPDRACHTGEVER.................................................................................................. 5 I.3 W IJZE VAN GUNNEN ........................................................................................................................... 5 I.4 PRIJSVASTSTELLING .......................................................................................................................... 5 I.5 TOEGANGSRECHT EN KWALITATIEVE SELECTIE .................................................................................... 6 I.6 VORM EN INHOUD VAN DE OFFERTE .................................................................................................... 6 I.7 VERGISSINGEN - LEEMTEN ................................................................................................................. 6 I.8 INDIENEN VAN DE OFFERTE ................................................................................................................ 7 I.9 OPENING VAN DE OFFERTES............................................................................................................... 7 I.10 VERBINTENISTERMIJN ...................................................................................................................... 7 I.11 GUNNINGSCRITERIA ......................................................................................................................... 8 I.12 PRIJSHERZIENINGEN ........................................................................................................................ 8 I.13 VARIANTEN ..................................................................................................................................... 9 I.14 KEUZE VAN OFFERTE ....................................................................................................................... 9 II. CONTRACTUELE BEPALINGEN .................................................................................................. 10 II.1 LEIDEND AMBTENAAR ..................................................................................................................... 10 II.2 VERZEKERINGEN ............................................................................................................................ 10 II.3 BORGTOCHT .................................................................................................................................. 10 II.4 LOOPTIJD ...................................................................................................................................... 10 II.5 BETALINGSTERMIJN........................................................................................................................ 11 II.6 BEËINDIGING VAN DE OVEREENKOMST............................................................................................. 12 II.7 W AARBORGTERMIJN....................................................................................................................... 12 II.8 VOORLOPIGE OPLEVERING.............................................................................................................. 12 II.9 DEFINITIEVE OPLEVERING ............................................................................................................... 13 II.10 RESULTAATSVERBINTENIS ............................................................................................................ 13 II.11 VERBOD OP CONCURRENTIEBEPERKING ........................................................................................ 13 II.12 ONDERAANNEMING ...................................................................................................................... 13 II.13 LOON VERSCHULDIGD AAN WERKNEMERS ...................................................................................... 13 III. TECHNISCHE BEPALINGEN ....................................................................................................... 15 III.1 INLEIDING ..................................................................................................................................... 15 III.2 BREUKLIJNEN ............................................................................................................................... 15 III.3 BEPALINGEN GEMEENSCHAPPELIJK VOOR ALLE TOEPASSINGEN ....................................................... 16 III.3.1 Aanmelden .......................................................................................................................... 16 III.3.2 Gebruikers & beheerders .................................................................................................... 17 III.3.3 Online en real time de beschikbaarheid tonen ................................................................... 18 III.3.4 Winkelkarretje ..................................................................................................................... 19 III.3.5 First in - first served............................................................................................................. 19 III.3.6 Gegevensvalidatie............................................................................................................... 19 III.3.7 Koppelingen ........................................................................................................................ 19 III.3.8 Grafische interface, gebruiksvriendelijkheid & integratie website ....................................... 20 III.3.9 Historiek .............................................................................................................................. 20 III.3.10 Rapportering ..................................................................................................................... 21 III.3.11 Afdrukken .......................................................................................................................... 22 III.3.12 Beheer & administratieve afhandeling .............................................................................. 22 III.3.13 Betalen .............................................................................................................................. 23 III.3.14 Fiscale Attesten ................................................................................................................. 24 III.3.15 Voorwaardelijke inschrijving .............................................................................................. 24 III.3.16 Zelf content toevoegen...................................................................................................... 25 III.3.17 Technische beschrijving van de oplossing........................................................................ 25 III.3.18 Technologie ....................................................................................................................... 25 III.3.19 Hosting .............................................................................................................................. 26

Blz. 2


PROVINCIE ANTWERPEN

Ref.: 481

III.3.20 Congestion protection ....................................................................................................... 26 III.3.21 Beveiliging en Informatieveiligheid .................................................................................... 26 III.3.22 Licenties ............................................................................................................................ 27 III.3.23 Toekomstbestendigheid en Interoperabiliteit .................................................................... 27 III.3.24 Conversie van data uit de vorige toepassing .................................................................... 28 III.3.25 SLA, Support en onderhoud ............................................................................................. 28 III.3.26 Plan van aanpak ............................................................................................................... 29 III.3.27 Testen ............................................................................................................................... 29 III.3.28 Referenties ........................................................................................................................ 29 III.3.29 Opleiding ........................................................................................................................... 30 III.3.30 Beëindiging samenwerking ............................................................................................... 30 III.4 AFZONDERLIJKE MODULES ............................................................................................................ 31 III.4.1 Module 1: Zaalverhuur ........................................................................................................ 31 III.4.2 Module 2: Materiaalverhuur ................................................................................................ 35 III.4.3 Module 3: Inschrijvingen voor vrije tijdsactiviteiten van jeugd, sport, cultuur ..................... 36 III.4.4 Module 4: Speelpleinwerking .............................................................................................. 43 III.4.5 Module 5: Kinderopvang (verplichte optie) ......................................................................... 46 III.4.6 Module 6: Ticketverkoop (verplichte optie) ......................................................................... 52 BIJLAGE A : OFFERTEFORMULIER .................................................................................................. 56 BIJLAGE B : ANTWOORDFORMULIER ............................................................................................. 58 BIJLAGE C : INVENTARIS .................................................................................................................. 80

Blz. 3


PROVINCIE ANTWERPEN

Ref.: 481

Inlichtingen i.v.m. dit bestek kunnen verkregen worden bij: Naam: dienst Welzijnszaken Adres: 2070 Zwijndrecht Contactpersoon: Mevrouw Martine Roothooft Telefoon: 03 250 48 02 E-mail: [email protected] Ontwerper Naam: dienst Contractbeheer Adres: Binnenplein 1 te 2070 Zwijndrecht Contactpersoon: De heer Vincent Foubert Telefoon: 03/250.48.61 E-mail: [email protected] Toepasselijke reglementering 1. Wet van 15 juni 2006 betreffende de overheidsopdrachten en bepaalde opdrachten voor aanneming van werken, leveringen en diensten, en latere wijzigingen. 2. Koninklijk besluit van 15 juli 2011 betreffende plaatsing overheidsopdrachten klassieke sectoren, en latere wijzigingen. 3. Koninklijk besluit van 14 januari 2013 tot bepaling van de algemene uitvoeringsregels van de overheidsopdrachten en van de concessies voor openbare werken, en latere wijzigingen. 4. Wet van 17 juni 2013 betreffende de motivering, de informatie en de rechtsmiddelen inzake overheidsopdrachten en bepaalde opdrachten voor werken, leveringen en diensten. 5. Het Algemeen Reglement voor de Arbeidsbescherming (ARAB), Welzijnswet en Codex over het welzijn op het werk. 6. Wet van 11 februari 2013 tot vaststelling van sancties en maatregelen voor werkgevers van illegaal verblijvende onderdanen van derde landen. Afwijkingen, aanvullingen en opmerkingen Artikel 106 §2 van het koninklijk besluit van 15 juli 2011 De verbintenistermijn wordt van toepassing gemaakt. Artikel 57 van het koninklijk besluit van 15 juli 2011 De verbintenistermijn wordt van 90 op 120 kalenderdagen gebracht.

Blz. 4


PROVINCIE ANTWERPEN

Ref.: 481

I. Administratieve bepalingen Dit eerste deel heeft betrekking op de regeling tot gunning van een overheidsopdracht tot de opdrachtnemer is aangesteld. De bepalingen die vervat zijn in dit deel, hebben betrekking op de wet van 15 juni 2006 en het koninklijk besluit van 15 juli 2011 en latere wijzigingen.

I.1 Beschrijving van de opdracht Voorwerp van deze leveringen: Software vrijetijdsdiensten gemeente Zwijndrecht. Toelichting: De vrijetijdsdiensten van de gemeente Zwijndrecht (Cultuur, Jeugd, Kinderopvang, Sport, …) willen een softwareoplossing om hun vrijetijdsaanbod bekend te maken aan de burgers en deze toe te laten online in te schrijven op activiteiten, tickets aan te kopen voor voorstellingen, zalen, accommodatie of materialen te reserveren, … Dit aanbod is redelijk gevarieerd, de verkoopformules en prijszetting zijn niet eenvormig (abonnementen, beurtenkaarten, diverse kortingen, …) en de gewenste functionaliteit voor klanten varieert ook van online betalen via online reserveren tot online een reservatieaanvraag doen. Bijgevolg is er, naargelang het geval, ook nog een grote variatie in betaalwijzen (online betaling, facturatie achteraf, kassaverkoop, …). Ondanks die grote verscheidenheid wenst de gemeente Zwijndrecht, indien dit haalbaar is, één programma waarin het totale aanbod kan opgenomen en afgehandeld worden. Omdat niet alle burgers vertrouwd zijn met online kopen/registreren/…. moet de oplossing ook bruikbaar zijn als front-office toepassing aan een balie. Leveringsplaats: Gemeente Zwijndrecht, Binnenplein 1 te 2070 Zwijndrecht

I.2 Identiteit van de opdrachtgever Gemeente Zwijndrecht Binnenplein 1 2070 Zwijndrecht

I.3 Wijze van gunnen Overeenkomstig artikel 26, § 2, 1° d (limiet van 209 000,00 euro excl. btw niet overschreden) van de wet van 15 juni 2006, wordt de opdracht gegund bij wijze van de vereenvoudigde onderhandelingsprocedure met bekendmaking.

I.4 Prijsvaststelling De opdracht wordt beschouwd als een opdracht tegen globale prijs. De opdracht tegen een globale prijs is een opdracht waarbij een forfaitaire prijs het geheel van de prestaties van de opdracht of van elke post dekt.

Blz. 5


PROVINCIE ANTWERPEN

Ref.: 481

I.5 Toegangsrecht en kwalitatieve selectie De offerte moet vergezeld zijn van volgende stukken: Juridische situatie van de inschrijver (toegangsrecht) Door eenvoudig deel te nemen aan deze procedure tot gunning verklaart de inschrijver zich niet in één van de uitsluitingsgevallen te bevinden als bedoeld in artikel 61 § 1 en 2 van het KB van 15 juli 2011. Door de aanbestedende overheid wordt het bestaan van sociale en fiscale schulden gecontroleerd. Zij zijn een reden voor uitsluiting van de offerte. Technische bekwaamheid van de inschrijver (kwalitatieve selectie) Een lijst van de voornaamste leveringen die gedurende de afgelopen drie jaar werden verricht, met vermelding van het bedrag, de datum en van de publiek- of privaatrechtelijke instanties waarvoor zij bestemd waren. De leveringen worden aangetoond door attesten die de bevoegde autoriteit heeft afgegeven of medeondertekend of, in geval van leveringen voor een particuliere afnemer, door attesten van de afnemer of bij ontstentenis eenvoudigweg door een verklaring van de leverancier. Minimumeisen: Er worden minstens 3 attesten van goede uitvoering toegevoegd.

I.6 Vorm en inhoud van de offerte De inschrijver maakt zijn offerte op in het Nederlands en vult de inventaris in op het eventueel bij het bestek behorende formulier. Indien hij deze op andere documenten maakt dan op het voorziene formulier, dan draagt hij de volle verantwoordelijkheid voor de volledige overeenstemming van de door hem aangewende documenten met het formulier. De offerte moet door de gedelegeerd – bestuurder of de zaakvoerder van de vennootschap of zijn gemachtigde met een elektronische handtekening ondertekend worden. Wanneer zij door een gemachtigde ondertekend zijn, moet hij of zij, die ondertekent, door middel van een volmacht van de gedelegeerd – bestuurder of de zaakvoerder van de vennootschap bewijzen dat hij gemachtigd is de documenten rechtsgeldig te ondertekenen. Een onvolledige of niet rechtsgeldig elektronisch ondertekende offerte komt niet in aanmerking. Doorhalingen, overschrijvingen, aanvullingen of wijzigingen, zowel in de offerte als in de bijlagen, die de essentiële voorwaarden van de opdracht zoals prijzen, termijnen, technische specificaties kunnen beïnvloeden, moeten eveneens door de inschrijver of zijn gemachtigde ondertekend worden. De prijs van de offerte moet opgegeven worden in EURO en mag slechts twee cijfers na de komma bedragen. Eventuele kortingen moeten steeds in de eenheidsprijs verrekend zijn en worden niet afzonderlijk vermeld.

I.7 Vergissingen - leemten Indien de inschrijver in het bestek of in de aanvullende documenten van de opdracht zodanige vergissingen of leemten vaststelt dat het hem onmogelijk is een prijs te berekenen, of dat de vergelijking van de offertes niet meer opgaat, meldt hij dit onverwijld en in elk geval ten minste 10 dagen voor de uiterste indieningsdatum, schriftelijk aan het bestuur, behalve wanneer het door de inkorting van de termijn voor het indienen van de offertes niet mogelijk is deze voorwaarden na te leven. De aanbestedende overheid oordeelt of het, wegens de belangrijkheid van de vergissingen of de leemten, verantwoord is de opening van de offertes te verdagen en een rechtzetting te publiceren.

Blz. 6


PROVINCIE ANTWERPEN

Ref.: 481

I.8 Indienen van de offerte De offertes mogen alleen verstuurd worden via de e-Tendering internetsite https://eten.publicprocurement.be/ die de naleving waarborgt van de voorwaarden van artikel 52 van het Koninklijk Besluit van 15 juli 2011. Er dient opgemerkt te worden dat het versturen van een offerte per e-mail niet aan deze voorwaarden voldoet. Daarom wordt het niet toegestaan op deze wijze offerte in te dienen. De offertes moeten worden opgemaakt in PDF, Word of Excel. De aanbestedende overheid raadt aan om de offerte met een eID in te dienen. De persoon die de offerte elektronisch ondertekent, moet hiervoor gemachtigd zijn in de statuten of moet een volmacht hebben. Door zijn offerte volledig of gedeeltelijk via elektronische middelen in te dienen, aanvaardt de inschrijver dat de gegevens die voortvloeien uit de werking van het ontvangstsysteem van zijn offerte worden geregistreerd. De offerte moet bij de aanbestedende overheid toekomen vóór de uiterste ontvangstdatum van de offertes. Meer informatie kan u vinden op volgende website: http://www.publicprocurement.be of via de eprocurement helpdesk op het nummer: +32 (0)2 790 52 00. De offerte kan niet ingediend worden op papier

I.9 Opening van de offertes Er is geen publieke opening van de offertes.

I.10 Verbintenistermijn De termijn gedurende dewelke de inschrijver door zijn offerte gebonden blijft, bedraagt 120 kalenderdagen, te rekenen vanaf de uiterste datum voor ontvangst.

Blz. 7


PROVINCIE ANTWERPEN

Ref.: 481

I.11 Gunningscriteria Volgende criteria zijn van toepassing bij de gunning van de opdracht: Nr. 1

Beschrijving

Gewicht

Prijs

30

Regel van drie; Score offerte = (prijs laagste offerte / prijs offerte) * gewicht van het criterium prijs 2

Technische en functionele waarde

50

De mate waarin de verschillende onderdelen beantwoorden aan de beschrijving van de technische en functionele eigenschappen gevraagd in het bestek en de kwaliteit van de producten en de documentatie. 3

Support, SLA en onderhoud

20

De ondersteuning (helpdesk, interventies, availability, ...), SLA en onderhoud tijdens de opdracht worden beoordeeld aan de hand van het voorstel van de inschrijver. Totaal gewicht gunningscriteria:

100

Aan elk criterium werd een gewicht toegekend. Op basis van de afweging van al deze criteria rekening houdende met het gewicht dat er aan werd toegekend, zal de opdracht gegund worden aan de inschrijver die de economisch voordeligste offerte, vanuit het oogpunt van de aanbestedende overheid, heeft ingediend.

I.12 Prijsherzieningen De prijselementen van deze opdracht komen slechts gedeeltelijk voor prijsherziening in aanmerking. Enkel de periodieke (driemaandelijkse) kosten voor licenties, onderhoud en hosting komen voor prijsherziening in aanmerking. De eenmalige kosten (levering + installatie software en opleidingen, alsook eventuele kosten voor aankoop) komen hiervoor niet in aanmerking. Het eerste jaar van de opdracht is geen prijsherziening van toepassing. Daarna kunnen jaarlijks op 1 januari de prijzen van de offerte voor onderhoud, upgrades en helpdesk worden aangepast. De prijsherziening wordt berekend met volgende formule: Prijsherziening = (herzieningscoëfficiënt (k) - 1) * herzienbaar gedeelte k = 0,4 * s/S + 0,4 * i/I + 0,2 S =het gemiddelde van de uurlonen van de geschoolde werklieden, de geoefende werklieden en de handlangers, zoals die door het Nationaal Paritair Comité van het Bouwbedrijf vastgesteld zijn, vermeerderd met het totaal percentage van de sociale lasten en verzekeringen, zoals aangenomen door de Federale Overheidsdienst Economie, KMO, Middenstand en Energie, 10 kalenderdagen voor de opening van de offertes. s = hetzelfde gemiddelde van de uurlonen, zoals aangenomen door de Federale Overheidsdienst Economie, KMO, Middenstand en Energie, op de aanvangsdatum van de maandelijkse periode van het voorschot. I = het referentieindexcijfer op basis van een jaarlijks verbruik van de voornaamste producten in het bouwbedrijf op de inlandse markt, vastgesteld door de Federale Overheidsdienst Economie, KMO, Middenstand en Energie, voor de kalendermaand die de opening van de offertes voorafgaat. i = hetzelfde referentieindexcijfer, vastgesteld door de Federale Overheidsdienst Economie, KMO, Middenstand en Energie, voor de kalendermaand die de maandelijkse periode van het voorschot voorafgaat.

Blz. 8


PROVINCIE ANTWERPEN

Ref.: 481

I.13 Varianten Vrije varianten worden niet toegestaan. Er zijn geen verplichte of facultatieve varianten voorzien.

I.14 Keuze van offerte De aanbestedende overheid kiest de economisch meest voordelige (rekening houdend met de gunningscriteria) offerte. De inschrijver verbindt zich ertoe om zich na de opening van de offertes beschikbaar te kunnen stellen voor nadere uitleg, aanvullingen, concretiseringen. Deze prestaties kunnen nooit leiden tot een vergoeding. Het opdrachtgevend bestuur kan een demonstratie vragen van het voorgestelde systeem. Deze is op kosten van de inschrijvende firma. Door de indiening van zijn offerte aanvaardt de inschrijver al de clausules van het bestek en verzaakt hij aan alle andere voorwaarden. Voor zover tijdens het onderzoek van de offerte door de aanbestedende overheid wordt vastgesteld dat er door de inschrijver voorwaarden zijn gevoegd waardoor het onduidelijk is of de inschrijver voorbehoudsloos akkoord gaat met de voorwaarden van het bestek, behoudt de aanbestedende overheid zich het recht voor om de offerte als substantieel onregelmatig af te wijzen.

Blz. 9


PROVINCIE ANTWERPEN

Ref.: 481

II. Contractuele bepalingen Dit tweede deel regelt de procedure die betrekking heeft op de uitvoering van de opdracht. Voor zover er niet van afgeweken wordt, is het koninklijk besluit van 14 januari 2013 en latere wijzigingen tot bepaling van de algemene uitvoeringsregels van de overheidsopdrachten en van de concessies voor openbare werken van toepassing.

II.1 Leidend ambtenaar De leiding over en het toezicht op de uitvoering van de leveringen zal gebeuren door: Naam: mevrouw Martine Roothooft Adres: Gemeente Zwijndrecht, Binnenplein 1 te 2070 Zwijndrecht Telefoon: 03 250 48 02 E-mail: [email protected]

II.2 Verzekeringen De opdrachtnemer sluit de verzekeringen die zijn aansprakelijkheid inzake arbeidsongevallen dekken, alsook zijn burgerlijke aansprakelijkheid ten aanzien van derden bij de uitvoering van de opdracht. Binnen een termijn van dertig dagen na het sluiten van de opdracht toont de opdrachtnemer aan dat hij deze verzekeringscontracten is aangegaan, aan de hand van een attest waaruit de door de opdrachtdocumenten vereiste omvang van de gewaarborgde aansprakelijkheid blijkt. Op elk ogenblik tijdens de uitvoering van de opdracht legt de opdrachtnemer dit attest over, binnen een termijn van vijftien dagen na ontvangst van het verzoek van de aanbestedende overheid.

II.3 Borgtocht Volgende borgtocht wordt gevraagd: 5% van het oorspronkelijk bedrag van de opdracht (excl. btw), afgerond naar het hogere tiental. Dit totaalbedrag wordt bekomen door de eenmalige kosten te vermeerderen met de huur- of koopkosten en onderhoudskosten voor een periode van 60 maanden. De borgtocht wordt volledig vrijgegeven na de voorlopige oplevering van de laatst in gebruik genomen module (tenzij er redenen zijn om de vrijgave van de borgtocht per gedeelte te regelen). De borgtocht moet gesteld worden binnen 30 kalenderdagen volgend op de dag van de sluiting van de opdracht bij aangetekende zending. Het bewijs van borgstelling moet verstuurd worden aan het adres van de aanbestedende overheid. Wanneer de opdrachtnemer de borgtocht niet stelt binnen de vermelde termijn, kan gehandeld worden overeenkomstig de mogelijkheden vermeld in artikel 29 van het koninklijk besluit van 14 januari 2013. Het verzoek van de opdrachtnemer om over te gaan tot de oplevering geldt als verzoek tot vrijgave van de borgtocht.

II.4 Looptijd Termijn in maanden: 60 maanden na voorlopige oplevering van de eerste in gebruik genomen module (zie rubriek II.8) De overeenkomst vangt aan op de datum van de formele betekening aan de inschrijver van de opdracht, maar de eigenlijke contractuele looptijd van 60 maanden start pas op dag 1 na de

Blz. 10


PROVINCIE ANTWERPEN

Ref.: 481

goedkeuring van het proces-verbaal van voorlopige oplevering van de eerste in gebruik genomen module. De totale looptijd van de opdracht bedraagt dus 60 maanden + de periode van opstart, installatie, implementatie en eventuele conversie van de eerste module. De toewijzing van het project staat gepland in het 2de kwartaal van 2016 en de opstart van alle gewenste modules loopt uiterlijk tot 30 april 2017. Per 1 mei 2017 moeten alle modules in gebruik genomen zijn door de opdrachtgever én de klanten. De gewenste startperiode per module is de volgende (na de nodige termijn voor opleiding en interne opstart): - Module 1: zaalverhuur: begin april 2017 - Module 2: materiaalverhuur: begin januari 2017 - Module 3: Inschrijvingen voor vrije tijdsactiviteiten van jeugd, sport, cultuur: september 2016 - Module 4: speelpleinwerking: begin maart 2017 - Module 5: kinderopvang (verplichte optie): januari 2017 - Module 6: ticketverkoop (verplichte optie): april/mei 2017 Extra modules die in de loop van het contract bijbesteld zouden worden, hebben dezelfde eindtijd als het hoofdcontract. Na de beëindiging van de looptijd van 60 maanden kan het contract stilzwijgend verlengd worden, telkens voor een nieuwe periode van 1 jaar. De opzeggingsmodaliteiten worden verder beschreven onder rubriek II.6.

II.5 Betalingstermijn De facturatie van de geleverde diensten gebeurt per kwartaal door een gedag- en gehandtekende factuur met prijsopgave per module in tweevoud te richten aan de financieel beheerder van de gemeente Zwijndrecht, op het adres zoals vermeld onder punt I.2. De aanbestedende overheid beschikt over een verificatietermijn van 30 kalenderdagen vanaf de datum van de levering om de formaliteiten betreffende de oplevering te vervullen. Deze termijn gaat in de dag volgend op de dag waarop de leveringen ter bestemming zijn gekomen, voor zover de aanbestedende overheid in het bezit van de leveringslijst of factuur wordt gesteld. De betaling van het aan de leverancier verschuldigde bedrag vindt plaats binnen de betalingstermijn van 30 kalenderdagen vanaf de datum van beëindiging van de verificatie, voor zover de aanbestedende overheid tegelijk over de regelmatig opgemaakte factuur beschikt, alsook over de andere, eventueel vereiste documenten. Deze factuur geldt als schuldvordering. Onvolledige of foutieve facturen worden aan de inschrijver teruggezonden. De aanbestedende overheid behoudt zich het recht voor om steeds nader gespecificeerde inlichtingen op te vragen over de samenstelling van de factuur alvorens tot de betaling over te gaan. De eenmalige kosten voor levering + installatie software en opleidingen, alsook eventuele kosten voor aankoop, mogen per module pas na de voorlopige oplevering (zie rubriek II.8) aangerekend worden. De andere kosten (licentiekost, onderhoud en hosting, ) worden vanaf de voorlopige oplevering per kwartaal gefactureerd.

Blz. 11


PROVINCIE ANTWERPEN

Ref.: 481

II.6 Beëindiging van de overeenkomst De opdracht heeft een looptijd van 60 maanden (zie rubriek II.4), startend vanaf dag 1 na goedkeuring van het proces-verbaal van voorlopige oplevering. Tenzij de opdrachtgever uiterlijk 4 maanden voor de beëindiging van deze periode het contract per aangetekend schrijven opzegt, loopt de overeenkomst stilzwijgend verder, telkens voor 1 jaar. De gemeente Zwijndrecht kan het contract dan steeds opzeggen op de jaarlijkse vervaldag, mits het respecteren van een opzegtermijn van 4 maanden. Uit hoofde van deze opzegging ziet de inschrijver af van elke schadeclaim t.o.v. de opdrachtgever. Tijdens de opzegtermijn heeft de inschrijver speciaal aandacht voor de goede uitvoering van de opdracht van deze offerte, op straffe van niet betaling van de hiervoor verschuldigde vergoedingen. De opdrachtgever stelt de inschrijver desgevallend op schriftelijke wijze in gebreke. Bij opzegging en bij het beëindigen van de overeenkomst zorgt de inschrijver er voor dat de noodzakelijke schikkingen worden getroffen in overleg met de opdrachtgever om de dienstverlening niet in het gedrang te brengen. De inschrijver verleent zijn flexibele medewerking aan de introductie van de eventueel nieuwe inschrijver, naast de taak op een zo zorgvuldig mogelijke manier zijn opdracht te volbrengen. Bij het vaststellen van een inbreuk op bovenstaande bepalingen stelt de inschrijver zich bloot aan maatregelen van ambtswege. Daarnaast kan de opdrachtgever, na schriftelijke ingebrekestelling, wegens ernstige nalatigheden van de inschrijver, op elk moment een einde stellen aan de overeenkomst, zo nodig zonder opzegtermijn. Deze maatregel wordt door de opdrachtgever gemotiveerd.

II.7 Waarborgtermijn De waarborgtermijn voor deze leveringen bedraagt 12 kalendermaanden De waarborgtermijn begint vanaf de dag van de voorlopige oplevering op de leveringsplaats.

II.8 Voorlopige oplevering Bij het verstrijken van de verificatietermijn, wordt per in gebruik genomen module naargelang het geval een proces-verbaal van voorlopige oplevering of van weigering van oplevering opgesteld. Voor de oplevering zal de leverancier door middel van een Proof of Concept aantonen dat bij application retirement de relevante informatie op een adequate manier uit de toepassing geëxporteerd kan worden en dat een archiveringsmechanisme voorzien kan worden die de data op een betekenisvolle manier exporteert naar een raadpleegbaar systeem dat niet aan veroudering onderhevig is (bijvoorbeeld door gebruik te maken van gekende toekomstbestendige bestandsformaten, open protocollen, …).

Blz. 12


PROVINCIE ANTWERPEN

Ref.: 481

II.9 Definitieve oplevering De definitieve oplevering gebeurt per module en heeft plaats bij het verstrijken van de waarborgtermijn. Ze gebeurt stilzwijgend wanneer de levering gedurende die termijn geen aanleiding tot klachten heeft gegeven. Wanneer de levering tijdens de waarborgtermijn aanleiding heeft gegeven tot klachten, wordt binnen vijftien dagen voorafgaand aan het verstrijken van die termijn een procesverbaal van definitieve oplevering of van weigering van definitieve oplevering opgesteld.

II.10 Resultaatsverbintenis De gemeente Zwijndrecht vraagt van de inschrijver een duidelijke resultaatsverbintenis. De inschrijver aanvaardt dan ook dat dit bestek bij gunning als een resultaatsverbintenis zal opgevat worden. De inschrijver stelt een oplossing voor met als doel het beoogde resultaat te bereiken. De gemeente Zwijndrecht zoekt een dienstverlener die de expertise heeft om alle gevraagde componenten te installeren.

II.11 Verbod op concurrentiebeperking Elke handeling, overeenkomst of afspraak die de normale mededingingsvoorwaarden kan vertekenen, is verboden. Offertes die met zodanige handeling, overeenkomst of afspraak zijn ingediend, worden uitgesloten. Door eenvoudig deel te nemen aan een procedure tot gunning van een overheidsopdracht verklaart de inschrijver geen concurrentiebeperkende handelingen, overeenkomsten of afspraken te hebben gemaakt.

II.12 Onderaanneming De onderaanneming voor een gedeelte van de opdracht is toegestaan. De namen en identificatie van de eventuele onderaannemers zullen in de offerte vermeld worden. De onderaannemers moeten hun verplichtingen ten aanzien van de RSZ zijn nagekomen, of in voorkomend geval tegenover de vergelijkbare nationale instellingen voor de buitenlandse onderaannemers. De inschrijver zal echter de volledige verantwoordelijkheid dragen voor het gehele project en zal de enige gesprekspartner zijn van de gemeente Zwijndrecht.

II.13 Loon verschuldigd aan werknemers Wanneer de opdrachtnemer of onderaannemer het in artikel 49/1, derde lid van het Sociaal Strafwetboek bedoelde afschrift ontvangt van kennisgeving waarmee hij ervan in kennis wordt gesteld dat hij een zwaarwichtige inbreuk heeft begaan op de verplichting zijn werknemers tijdig het loon te betalen waarop deze recht hebben, onthoudt hij zich ervan, met onmiddellijke ingang, de plaats van uitvoering van de opdracht nog verder te betreden of nog verder uitvoering aan de opdracht te geven, en wel tot hij het bewijs voorlegt aan de aanbestedende instantie dat de betrokken werknemers integraal zijn uitbetaald.

Blz. 13


PROVINCIE ANTWERPEN

Ref.: 481

Hetzelfde geldt wanneer de voormelde opdrachtnemer of onderaannemer ervan in kennis wordt gesteld: - ofwel, naargelang het geval, door de opdrachtnemer of de aanbestedende instantie, dat hij de in artikel 49/1, eerste lid, van het Sociaal Strafwetboek bedoelde kennisgeving heeft ontvangen die betrekking heeft op deze opdrachtnemer of onderaannemer; - ofwel door middel van de in artikel 35/4 van de wet van 12 april 1965 betreffende de bescherming van het loon der werknemers bedoelde aanplakking. De opdrachtnemer of onderaannemer is er bovendien toe gehouden een clausule op te nemen in de onderaannemingsovereenkomst die hij desgevallend zou sluiten, op grond waarvan: 1° de onderaannemer er zich van onthoudt de plaats van uitvoering van de opdracht nog verder te betreden of nog verder uitvoering aan de opdracht te geven, indien uit een in uitvoering van artikel 49/1 van het Sociaal Strafwetboek opgestelde kennisgeving blijkt dat deze onderaannemer op zwaarwichtige wijze tekortschiet in zijn verplichting het aan zijn werknemers verschuldigde loon tijdig uit te betalen; 2° de niet-naleving van de onder 1° gestelde verplichting aanzien wordt als een ernstige tekortkoming in hoofde van de onderaannemer, ingevolge waarvan de opdrachtnemer is gemachtigd de overeenkomst te verbreken; 3° de onderaannemer ertoe is gehouden een soortgelijke clausule als onder 1° en 2° op te nemen in de onderaannemingsovereenkomsten en ervoor te zorgen dat dergelijke clausules ook in de verder onderaannemingsovereenkomsten worden opgenomen.

Blz. 14


PROVINCIE ANTWERPEN

Ref.: 481

III. Technische bepalingen III.1 Inleiding De vrijetijdsdiensten van het gemeentebestuur (Cultuur, Jeugd, Kinderopvang, Sport, …) willen een softwareoplossing om hun vrijetijdsaanbod bekend te maken aan de burgers en deze toe te laten online in te schrijven op activiteiten, tickets aan te kopen voor voorstellingen, zalen, accommodatie of materialen te reserveren, aanwezigheidsregistratie enz. Dit aanbod is redelijk gevarieerd, de verkoopformules en prijszetting zijn niet eenvormig (abonnementen, beurtenkaarten, diverse kortingen, …) , en de gewenste functionaliteit voor klanten varieert ook van online betalen via online reserveren tot online een reservatie aanvraag doen. Bijgevolg is er, naargelang het geval, ook nog een grote variatie in betaalwijzen (online betaling, facturatie achteraf, kassaverkoop, …). De details hiervan worden verder nog toegelicht. Ondanks die grote verscheidenheid wensen de vrijetijdsdiensten, indien dit haalbaar is, één programma waarin het totale aanbod kan opgenomen en afgehandeld worden. De redenen die hiervoor aangehaald worden zijn: 

De gebruiksvriendelijkheid voor de klant/de burger: 1-stop-shopping, 1 centrale plaats waar het volledige vrijetijdsaanbod beschikbaar is



De gebruiksvriendelijkheid voor de baliemedewerkers van de Vrijetijdsbalie : 1 programma waarin ze al hun werk kunnen doen.



Geen duplicatie van gegevens of informatie (bv. adressen van klanten). Ook voor de klanten : 1 gebruikersprofiel/gebruikersnaam/wachtwoord/…



De onderlinge samenhang van de diverse deelaspecten, bv. o o o o

Het huren van een zaal + het ontlenen van materiaal om daar te gebruiken Het deelnemen aan een uitstap + gebruik maken van kinderopvang voor en na die uitstap Het inschrijven voor deelname aan kinderopvang en kunnen terugvallen op speelpleinwerking indien er geen vrije plaatsen zijn in de kinderopvang Enz.

Omdat niet alle burgers vertrouwd zijn met online kopen/registreren/…. moet de oplossing ook bruikbaar zijn als front-office toepassing aan een balie. Indien één allesomvattende oplossing onhaalbaar zou blijken kunnen alternatieve oplossingen overwogen worden, waarbij we o.a. kunnen denken aan een gemeenschappelijke front-office toepassing voor verschillende back-end-processen of –toepassingen, of een groepering van bepaalde functionaliteit in een beperkt aantal toepassingen. Die alternatieven zullen dan uiteraard ook afgewogen moeten worden.

III.2 Breuklijnen Hoewel het allemaal onder de noemer “Vrije Tijd” te vatten is, zitten er toch een aantal duidelijke breuklijnen in het aanbod en de manier waarop we het (administratief) willen afhandelen. Naar “online transactie” is een duidelijke scheiding tussen enerzijds “online kopen en betalen”, “aanvragen en gefactureerd worden” anderzijds. De buitenbeentjes daarbij zijn • Kinderopvang (is eigenlijk een reservering + facturatie (dus iets meer dan aanvraag). Kan eventueel nog als “aanvragen en factureren” beschouwd worden.

Blz. 15

GEMEENTE ZWIJNDRECHT •

PROVINCIE ANTWERPEN

Ref.: 481

Regionale Sport valt helemaal naast het “online kopen en betalen”-mechanisme en wordt ook gefactureerd. Betaling aan de balie is eveneens mogelijk.

Een andere duidelijke breuklijn is “activiteiten” vs. “zalen en materiaal”, maar de verscheidenheid binnen “activiteiten” is zodanig groot dat het verschil met “zalen en materiaal” ons niet echt veel verder helpt. Een derde breuklijn is kinderen versus volwassenen : •

Licht profiel: mogelijks self-service registratie, ….

•

Complex profiel: K&G dossier, complexe relaties ouders-kinderen, ….

Een soortgelijke manier van daar naar te kijken is 

“Inschrijvingen” waarbij personen uniek identificeerbaar moeten zijn : ouders, kinderen, deelnemers aan activiteiten, …



“Tickets” waarbij ‘plaatsen’ verkocht (of gereserveerd) worden zonder dat de persoon die de plaats zal invullen noodzakelijk gekend moet zijn.

III.3 Bepalingen gemeenschappelijk voor alle toepassingen III.3.1 Aanmelden III.3.1.1 Gebruikersprofiel / login Voor de burger moet het aanmelden eenvoudig en gebruiksvriendelijk zijn. Klanten hebben maar 1 gebruikersnaam en paswoord nodig, behalve voor de module tickets waar enkel een e-mailadres volstaat. Ook hoeft een klant maar 1 keer aan te melden, waarna er probleemloos kan worden overgeschakeld van de ene naar de andere module. We willen dus niet dat klanten verschillende wachtwoorden moet gebruiken of meerdere keren moeten aanmelden met hetzelfde wachtwoord omdat ze diverse transacties willen uitvoeren.

III.3.1.2 Klantenprofiel Om gebruik te kunnen maken van de toepassingen moeten de burgers zich eerst registreren. Dit registreren moet in 2 stappen verlopen: aanmaak van een profiel met een geldig email adres, het bevestigen van de gegevens aan de hand van een email die opgestuurd wordt naar hun persoonlijk email adres. Er moet ook een mechanisme voorzien zijn waarbij de burger zijn paswoord zelf kan resetten bv. via een mail die naar zijn persoonlijk email adres gestuurd wordt. Natuurlijk moet het ook mogelijk zijn voor een beheerder van het gemeentebestuur om een paswoord te resetten. Paswoord validatie: paswoorden moeten minimale lengte & complexiteit bezitten en mogen niet overeenkomen met de gebruikersnaam. Als gebruikersnaam gaat de voorkeur uit om geen willekeurige naam te kiezen maar iets wat de gebruiker zelf goed kan onthouden, bij voorkeur zijn eigen email adres. Bij verkoop van tickets on line volstaat een e-mailadres. Ook het aanmelden voor beheerders ( medewerkers gemeentelijke diensten ) moeten met een eigen username en paswoord, er wordt niet met algemene logins gewerkt.

Blz. 16


PROVINCIE ANTWERPEN

Ref.: 481

Het is een pluspunt als de toepassing de gegevens van de e-id kan inlezen bij de registratie van de gebruiker. Het is een pluspunt als het basisprofiel van een gebruiker (naam, adres en contactgegevens) zit opgeslagen, zodat een update van het adres of contactgegevens direct zichtbaar is in alle toepassingen die via de website te gebruiken zijn. Specifieke klantengegevens die eigen zijn aan de deeltoepassing mogen, maar moeten niet uitgewisseld worden. In de toekomst zal het bestuur mogelijk een nieuwe website ontwikkelen waarin ook klantengegevens worden bijgehouden. Hierover kunnen we nu nog geen verdere specificaties geven, maar indien de door u aangeboden software mogelijkheden biedt om te koppelen met een dergelijke klantensysteem, of indien de leverancier hier ervaring mee heeft, dan is dit altijd een meerwaarde en mag dit toegelicht worden in de offerte.

III.3.2 Gebruikers & beheerders III.3.2.1 Klanten Voor alle applicaties (zaalreservaties, tickets, inschrijvingen) geldt dat een aantal gegevens gemeenschappelijk zijn. We willen vermijden dat een klant een wijziging aan zijn basisgegevens in elke afzonderlijke toepassing opnieuw moet ingeven. Afhankelijk van de module wordt het basisprofiel nog verder aangepast met de voorziene parameters per module. Indien er gegevens ontbreken in het profiel waardoor een transactie niet kan worden uitgevoerd, dan zal de software hiervan melding maken en de klant vragen om ze aan te vullen Indien een klant aan het begin van een kalenderjaar inlogt, moet hij een melding krijgen dat hij/zijn profiel moet nakijken en aanpassen indien nodig. Opmerking, niet elke klant zal van de online toepassing gebruik maken, sommigen zullen er de voorkeur aan blijven geven om telefonisch of via de balie geholpen te worden. Het moet dus voor de beheerders ook mogelijk zijn om voor “offline” klanten in het systeem een profiel aan te maken. Velden voor het basisprofiel: Veld Naam vereniging Rijksregisternummer (RRNR) Naam Voornaam Hoofd adres (straat, huisnummer, bus, postcode, gemeente) Rekeningnummer Telefoon/GSM Email adres

vereniging Verplicht hoofdcontactpersoon, verplicht hoofdcontactpersoon, verplicht hoofdcontactpersoon, verplicht Verplicht

Persoon Verplicht

Niet verplicht verplicht bij voorkeur gebruikerslogin van de toepassing, verplicht

Niet verplicht verplicht bij voorkeur gebruikerslogin van de toepassing, verplicht

Verplicht Verplicht Domicilie adres, verplicht

Voor de afzonderlijke programma’s (zaalreservaties, inschrijvingen, ticketverkoop) is het mogelijk dat er bijkomende informatie noodzakelijk is, die extra informatie mag dan in de betreffende toepassing zelf opgeslagen worden. Enkele voorbeelden: -

Voor zaalreservaties geldt dat een organisatie personen moet kunnen toevoegen die uit naam van de organisatie bestellingen mogen plaatsen.

Blz. 17

GEMEENTE ZWIJNDRECHT -

PROVINCIE ANTWERPEN

Ref.: 481

Voor inschrijvingen geldt dat een ouder kinderen moet kunnen toevoegen aan zijn profiel. Zowel voor kinderen als voor volwassenen moeten ook medische gegevens aan het profiel toegevoegd kunnen worden, etc. De informatie die in het uitgebreide profiel moet bijgehouden worden staat in de afzonderlijke modules vermeld, voordat de inschrijver aan wie de opdracht toegewezen zal worden aan de implementatie begint moet in samenspraak met de diensten de informatie nog eens in detail overlopen worden.

Klanten moeten hun profiel kunnen raadplegen en hun gegevens kunnen bijwerken. Ook de aanmeldnaam, wat in de meeste gevallen het email adres van de klant zal zijn, moet veranderd kunnen worden. Er moet een controle zijn op dubbele gegevens. Het systeem moet zoveel mogelijk verhinderen dat dubbele accounts in het systeem kunnen ingegeven worden. Dit kan bv. door een controle op het dubbele rijksregister- of ondernemingsnummers te doen. De controle op dubbele gegevens moet met volgende scenario’s rekening houden: Jan Janssens is papa van Ine en Tom en in zijn vrije tijd is hij voorzitter van een sportvereniging. Het rijksregisternummer van Jan Janssens kan in dit specifieke geval 2 maal in de tabel voorkomen, een e 1 keer in zijn persoonlijke profiel en een 2de keer als voorzitter van de sportclub. Of een kind dat op 2 adressen woont via co-ouderschap en dus ook 2 facturen nodig heeft. Bepaalde velden moeten verplicht gemaakt kunnen worden.

III.3.2.2 Beheerders Elke medewerker die toegang tot de toepassing nodig heeft, krijgt zijn eigen persoonlijke login en paswoord. Er wordt niet met gemeenschappelijke logins gewerkt. Er moeten verschillende rollen aangemaakt kunnen worden waarbij een medewerker een of meerdere rollen kan krijgen die hem toegang geven tot bepaalde delen van de toepassing. Via de rollen moet heel strikt afgebakend kunnen worden tot welke delen van de toepassing een gebruiker rechten heeft (wat is leesbaar, wat kan aangepast worden, welke informatie moet verborgen blijven. Een beheerder cultuur bv. mag enkel de zalen kunnen beheren van de cultuurdienst, een beheerder sport bv. mag enkel de zalen en terreinen kunnen beheren van de sportdienst. Zo zou het bv. handig zijn om een rechtenstructuur te kunnen implementeren die volgende toelaat: -

Een administrator die alle rechten heeft, administrator kan elke instelling van het programma wijzigen, gebruikers aanmaken, … Een beheerder “dienst X” die alle rechten heeft voor de onderdelen die onder de bevoegdheid van de dienst vallen (kan zalen aanmaken, tarieven aanpassen, …) . Een medewerker “dienst X” kan dan bv. enkel “verkoop” doen van “producten” die aangemaakt werden door de beheerder van “dienst X”.

Voor medewerkers geldt dat ze elk veld moeten kunnen overrulen met eigen input (bv. bij annulatie stelt het systeem 80% terugbetaling voor, de beheerder moet die waarde kunnen overrulen met een willekeurige waarde (procentueel of absoluut bedrag)). Een koppeling met onze active directory, waardoor gebruikers via single sign on kunnen aanmelden in de toepassing (met hun domeinaccount), is een meerwaarde, maar geen vereiste. Indien deze koppeling kan worden aangeboden beschrijft de leverancier hoe deze koppeling wordt geïmplementeerd en hoe ze wordt beveiligd.

III.3.3 Online en real time de beschikbaarheid tonen Ook voor de burgers die via de website de toepassing raadplegen moet de actuele bezettingstoestand zichtbaar zijn: Is de zaal nog vrij, zijn er nog vrije plaatsen, …

Blz. 18


PROVINCIE ANTWERPEN

Ref.: 481

III.3.4 Winkelkarretje Klanten kunnen meerdere items bestellen door ze toe te voegen aan een virtueel winkelkarretje. De klant kan dan op het einde bevestigen en afrekenen voor de volledige bestelling.

III.3.5 First in - first served In geval van een beperkt aantal tickets, plaatsen of unieke resources wordt het item “vastgehouden” door de eerste persoon die het aan zijn winkelkarretje toevoegt. De controle op beschikbaarheid of bepalen van de rangorde voor de wachtlijst moet dus gebeuren op het ogenblik van toevoegen aan het winkelkarretje en niet bij de globale afrekening. Als een persoon het item terug vrijgeeft (verwijdert uit zijn karretje) dan kan dit item enkel terug in de pool van vrije plaatsen komen op voorwaarde dat er nog geen wachtlijst voor dit item werd aangemaakt. Zodra er een wachtlijst bestaat, moeten alle volgende items aan de reservelijst worden toegevoegd, ongeacht of er nog een vrije plaats is of niet. Zo kan de beheerder dit item toewijzen aan de eerste op de wachtrij. Klanten moeten ook terug van de wachtlijst geschrapt kunnen worden door de beheerder. De toepassing beschikt over een automatisch mechanisme om gelockte items terug vrij te geven (klant logt uit zonder af te rekenen, klant sluit zijn verkenner zonder af te melden, problemen met de sessie waardoor de connectie met de server verbroken raakt, …).

III.3.6 Gegevensvalidatie Waar mogelijk moeten de ingegeven gegevens gevalideerd worden. Test geldigheid van een rijksregisternummer (delen door 97), test geldigheid van een bankrekeningnummer (delen door 97), is het een geldige datum, controle op dubbele gegevensinvoer, ondernemingsnummer, email adres …

III.3.7 Koppelingen III.3.7.1 Koppelingen Alle gegevens uit de toepassing moeten uit de toepassing gehaald kunnen worden. We wensen periodiek (bv. dagelijks) een export van de gegevens in de toepassing bij ons kunnen ontvangen (of komen afhalen). We wensen ook koppelingen met andere toepassingen te voorzien om dubbel invoeren van gegevens te vermijden. Welke uitwisseling van gegevens met andere programma’s ondersteunt de toepassing? -

Passieve koppelingen: periodieke import/export van gegevens via bestanden (csv, xml, …) Actieve koppeling: real time via een API of webservice

Optie: Het is een pluspunt als de gegevensuitwisseling kan gebeuren volgens de oslo standaard om gegevensuitwisseling met andere applicaties maximaal te kunnen standaardiseren. Optie: voorzien van een tool om bulk imports te doen in de database + documentatie hoe we zelf bv. via csv bestanden met die tool klantengegevens kunnen inladen in de toepassing.

Blz. 19


PROVINCIE ANTWERPEN

Ref.: 481

III.3.7.2 Koppeling met de website www.zwijndrecht.be We wensen een webtoepassing met eenzelfde look en feel als de gemeentelijke website.

III.3.7.3 Koppeling New Horizons/Logins -

Koppeling met de gemeentelijke boekhouding

Het is belangrijk dat de koppeling bidirectioneel werkt, we wensen bv. niet enkel en alleen de betalingsopvolgingstoepassing te voeden met nieuwe gegevens, maar we wensen ook een terugkoppeling van reeds binnengekomen betalingen.

III.3.7.4 Certificaten Er wordt verwacht van de inschrijver dat hij op het ogenblik van de toewijzing alle nodige certificaten kan voorleggen.

III.3.8 Grafische interface, gebruiksvriendelijkheid & integratie website Voor de burger moet het er uit zien alsof de toepassing een onderdeel uitmaakt van de website. De gebruiker moet op een duidelijke manier door de aanvraag heen geleid worden, de gebruiker moet via duidelijke formulieren stap voor stap door zijn bestelling heen geleid worden. We willen vermijden dat het inschrijven of bestellen moet gebeuren via een ingewikkeld formulier of dat de burger eerst verschillende ingewikkelde filters moet instellen om tot zijn bestelling te komen. De inschrijver geeft aan de hand van een demoversie of op een vergelijkbare live implementatie of aan de hand van beelden weer hoe de grafische interface zal ingedeeld worden, hoe de verschillende controls er uitzien, hoe het inschrijven voor de burger zou kunnen verlopen, … m.a.w. materiaal die ons in staat stelt om de grafische interface en de gebruiksvriendelijkheid te kunnen beoordelen en vergelijken met de inzending van andere inschrijvers. Bij de ontwikkeling van de gemeentelijke website zal rekening gehouden worden met de anysurfer aanbevelingen, deze moeten ook bij deze toepassingen zoveel mogelijk gevolgd worden om de toegankelijkheid van de webtoepassing(en) te garanderen. Indien de inschrijver aangeeft de anysurfer aanbevelingen te volgen maar om bepaalde technische of praktische redenen enkele aanbevelingen niet gevolgd kunnen worden, dan geeft de inschrijver aan welke aanbevelingen niet gevolgd kunnen worden. Het is een tevens een pluspunt als de toepassing een “responsive design” bezit en dus ook bruikbaar is op tablets of andere toestellen met andere schermafmetingen of resolutie dan een PC.

III.3.9 Historiek III.3.9.1 Historiek bestellingen Een klant die aangemeld is kan zijn historiek van bestellingen/reservaties opvragen. Om wijzigingen aan bestellingen aan te brengen moet de klant de diensten rechtstreeks contacteren ( email, telefoon, balie, … ), de klant kan geen bestelling annuleren via de website.

Blz. 20


PROVINCIE ANTWERPEN

Ref.: 481

III.3.9.2 Logging communicatie met klant Elke bestelling heeft een unieke referentiecode die duidelijk vermeld wordt in elke communicatie met de klant. Van elke bestelling kan de klant op het einde een overzicht met alle details afdrukken. De details van de bestelling worden ook naar het email adres van de klant gestuurd. Het moet mogelijk zijn om aan de hand van deze unieke code een overzicht van de communicatie met de klant op te vragen (datum aanvraag, datum antwoord + antwoord, kopie van de contracten, datum van betaling ontvangen + bedragen, annuleren, reden, …) zodat in geval van betwistingen nadien alle communicatie eenvoudig uit de toepassing opgevraagd kan worden.

III.3.9.3 Application logging Er is voldoende logging beschikbaar om in geval van problemen de oorzaak van het probleem te kunnen traceren. Uit de logging kan afgeleid worden wat de reactietijd van de website is en wat de exit status van een klant is ( bestelling tot het einde afgewerkt, bestelling geannuleerd, bestelling niet afgerond door een time-out, … enz.).

III.3.10 Rapportering Allerhande rapporten moeten kunnen aangemaakt worden, alles wat in de database zit moet er uit kunnen gehaald worden en in een rapport worden gegoten. De exacte behoeftes zullen waarschijnlijk nog bijgestuurd worden eenmaal we met de nieuwe tool werken, daarom is het heel wenselijk dat de tool de mogelijkheid heeft om zelf complexe rapporten te definiëren. Indien de tool van de inschrijver die mogelijkheid niet heeft en bijkomende rapporten op aanvraag moeten aangemaakt worden dan geeft de inschrijver aan of dit inbegrepen zit in het jaarlijkse supportcontract of als die rapporten afzonderlijk worden aangerekend. Voorbeelden van rapporten zouden kunnen zijn: -

Lijst van klanten die nog openstaande facturen hebben Takenlijsten Lijst van deelnemers voor een activiteit met contactgegevens Wachtlijsten voor een activiteit of voorstelling, per dag, per activiteit of per periode Rapport gebruik zalen per dag + wat er moet klaargezet worden Financiële rapporten ( lijsten met inkomsten per periode, per type verkoop, … ) Maandelijks opvolgen evolutie van het aantal personen die van de online tool gebruik maakt voor bestellingen. Rapport van de registratie van de aanwezigheden …

Rapportering moet in een bruikbaar formaat afgeleverd worden. De gebruiker moet de keuze krijgen om lijsten in een editeerbaar of readonly formaat te exporteren ( bv. excel, word, pdf, … ) Optie Dashboard: De tool heeft een overzichtspagina met daarop een overzicht van aandachtspunten of to do’s in de toepassing: bv. er zijn mensen die de betalingstermijn overschreden hebben. Er is een wachtrij voor een activiteit, voorstelling of zaal waar ondertussen plaatsen vrij gekomen zijn, er zijn aanvragen voor zaalreservaties binnengekomen die wachten op goedkeuring door een beheerder, er zijn kinderen waarvan de medische info werd bijgewerkt, …. Er moet een mogelijkheid worden voorzien dat er informatieve mails kunnen worden verstuurd aan een doelgroep op basis van hun aankopen in het verleden.

Blz. 21


PROVINCIE ANTWERPEN

Ref.: 481

III.3.11 Afdrukken Er zijn verschillende afdrukscenario’s die de toepassing moet ondersteunen, verschillende types documenten moeten naar verschillende printers en/of lades in een printer gestuurd kunnen worden. Tickets moeten afgedrukt kunnen worden op de printer van de vrijetijdsbalie, bibliotheek en ontmoetingscentrum. Documenten moeten in batch kunnen afgedrukt worden (bv. druk alle fiscale attesten voor dit jaar af, druk alle reeds betaalde maar nog niet afgedrukt tickets voor een voorstelling af,…) Rapporten, tickets, fiscale attesten, contracten, offertes, exportfiles, enz. Bij het verloren gaan van een document of file moet het mogelijk zijn om het betreffende document, lijst of bestand op een eenvoudige manier terug opnieuw aan te maken.

III.3.12 Beheer & administratieve afhandeling III.3.12.1 Efficiënte indeling van de schermen Voor de vaak voorkomende taken moet het mogelijk zijn om die in zo weinig mogelijk stappen uit te voeren. Vaak voorkomende taken moeten vanuit één scherm kunnen afgehandeld worden. Kan de inschrijver ons een beeld geven van hoe de gebruikersinterface georganiseerd is?

III.3.12.2 Snelverkoop Mogelijkheid voorzien om zeer snel verkoop van één type product te kunnen behandelen. Bv. Inschrijvingsweekend grabbelpas de mogelijkheid geven om enkel de activiteiten “grabbelpas” zichtbaar te maken op het scherm. Ook bij ticketverkoop moet de mogelijkheid bestaan om bv voor avondverkoop zeer snel tickets te verkopen van een specifieke voorstelling.

III.3.12.3 Efficiënte invoer Invoer van gegevens moet vlot en snel gaan: bv. opzoeken uit een lange lijst met waarden moeten het mogelijk zijn om snel de gewenste waarde te vinden (bv. google-like filter op basis van de reeds ingetikte tekst).

III.3.12.4 Reservelijsten Klanten die een item willen aankopen maar waarvan het item niet meer beschikbaar is (bv. alle plaatsen zijn volzet, voorstelling uitverkocht, …) moeten de kans krijgen om zichzelf op een reservelijst toe te kunnen voegen. Als er terug plaatsen vrijkomen kunnen de diensten dan de klant contacteren en melden dat er plaatsen beschikbaar zijn. Indien een klant een beschikbare plaats wil innemen dan moet de klant op een eenvoudige manier van de reservelijst kunnen overgeboekt worden naar de voorstelling of activiteit. Als de klant overgeboekt is moet de normale administratieve keten gestart worden, maar de dienst moet dan de keuze krijgen als de bestelling, overschrijving, offerte, contract, … via brief of via email naar de klant gestuurd zal worden. Een klant die zichzelf toevoegt op de reservelijst moet daarvoor niet betalen. De klant krijgt een indicatie van zijn plaats op de reservelijst.

Blz. 22


PROVINCIE ANTWERPEN

Ref.: 481

III.3.12.5 Annuleren Annuleren via de website wordt niet ondersteund en moet door een beheerder worden uitgevoerd. Bij annulatie stelt de toepassing zelf het terugbetaalbedrag voor ( bv. > 3weken voor het evenement = 100%, nadien 80%, bij terugbetaling moet men de keuze hebben om een bedrag of een percentage in te geven ). Net zoals bij elk veld in de toepassing moet de beheerder dit veld kunnen overrulen ( bv. toch 100% terugbetaling toestaan ). Het spreekt voor zichzelf dat die annulering ook correct moet doorgestuurd worden naar de boekhouding.

III.3.13 Betalen Afhankelijk van de soort aankoop/bestelling (ticket, zaalreservatie, inschrijving, … ) en verkoopkanaal (balie, telefonisch, online, …) moet de klant keuze krijgen uit verschillende betaalmogelijkheden. Dat betekent ook dat per soort verkoop en per kanaal ingesteld moet kunnen worden welke betalingsmogelijkheden beschikbaar zijn. Elke betaling via overschrijving of een andere online betalingswijze moet d.m.v. een unieke code ervoor zorgen dat we de betaling aan een verkoop kunnen koppelen.

III.3.13.1 Kassaverkoop Koppeling met het boekhoudkundige pakket van de gemeente voor cash ontvangsten bij verkoop aan de balie. De verkochte producten moeten afhankelijk van het product of de dienst die de verkoop regelt op een verschillende balans in de boekhouding geboekt kunnen worden. Het moet ook mogelijk zijn om bepaalde items niet in de boekhouding op te nemen. Het moet mogelijk zijn om een soort kassa rapport aan te maken waarbij een overzicht kan gemaakt worden van de verkopen per verkoper of globaal voor een bepaalde periode ( bv. logging van alle kassaverkopen: date time, klant, referentie verkochte item + beschrijving, bedrag, … ).

III.3.13.2 Facturatie Voor facturatie gebruikt de gemeente het betalingsopvolgingstoepassing New Horizon (firma Logins). De koppeling moet bidirectioneel zijn: we willen niet enkel de facturen uitsturen maar ook de status van de betaling kunnen terugkrijgen. Bv. als er nog onbetaalde facturen zijn voor de sportkampen van het voorgaande jaar dan kan de ouder pas inschrijven voor nieuwe grabbelpasactiviteiten als eerst de oude facturen betaald worden. Bij betaling via overschrijving, krijgt de klant de tijd om de betaling te voldoen binnen een bepaalde termijn. Bij het niet voldoen van de betaling binnen de gestelde termijn wordt de plaats terug vrijgemaakt voor een andere persoon. Het opheffen van de reservatie gebeurt niet automatisch, maar moet door een beheerder gebeuren. Via een rapport of via het dashboard moet wel zichtbaar gemaakt kunnen worden welke betalingstermijnen overschreden werden en hoe lang ze al overschreden zijn. Facturen die uitgestuurd worden kunnen ook cash betaald worden aan de balie. De inschrijver zorgt ervoor dat deze betaling ook correct gedocumenteerd wordt in de boekhoudkundige toepassingen.

III.3.13.3 Facturatie vooraf Voor bepaalde aankopen moet de klant vooraf betalen, bijvoorbeeld bij ticketverkoop en inschrijvingen. Indien de klant kiest om via overschrijving te werken dan moet de opvolging (aanmaak facturen, sturen herinneringen,…) van de facturatie via de gemeentelijke toepassing gebeuren.

Blz. 23


PROVINCIE ANTWERPEN

Ref.: 481

III.3.13.4 Facturatie nadien Voor bepaalde aankopen wordt er pas nadien gefactureerd, typisch voorbeeld is de verhuur van een sportzaal of andere lokalen, Buitenschoolse Kinderopvang. Hier worden niet bij elk afzonderlijke verhuur een factuur opgemaakt, maar worden periodiek ( bv. 1x per maand, of vanaf een bepaald bedrag met een maximum van 3 maanden ) alle facturen opgemaakt en verstuurd.

III.3.13.5 Cash betalen van een factuur Het kan gebeuren dat een klant een factuur aan de balie komt vereffenen, dit moet correct naar de betalingsopvolgingstoepassing en boekhouding kunnen worden doorgestuurd.

III.3.13.6 Online betaling Voor inschrijvingen voor grabbelpas, sportkampen en ticketverkoop wensen we een systeem voor veilige online betaling te voorzien. In dat geval wordt de betaling direct afgehandeld en kan de klant een bewijs van inschrijving of zijn tickets zelf afdrukken. Minimaal volgende betaalsystemen moeten gebruikt kunnen worden: visa, mastercard en bancontact. De inschrijver vermeldt of er extra kosten verbonden zijn aan een dergelijk online betaalsysteem (abonnementskosten, % van de verkoopprijs, …). Momenteel maken we gebruik van Ingenico en we willen dat blijven doen. We gaan er hierbij vanuit dat de leverancier in staat voor de configuratie van de koppeling tussen het betaalsysteem en de webtoepassing, aangezien wij niet op de hoogte zijn van essentiële onderdelen zoals beveiligingsparameters, transactiefeedback en dergelijke meer.

III.3.14 Fiscale Attesten Voor de modules inschrijvingen vakantieaanbod, speelpleinwerking en kinderopvang worden er fiscale attesten afgeleverd, waarvan telkens de specificatie wordt vermeld. Indien de klant gebruik heeft gemaakt van meerdere modules (bv. inschrijvingen/ kinderopvang/ speelpleinwerking), worden de verschillende attesten samengevoegd tot één “centraal” fiscaal attest per gezin en op naam van het kind. De mogelijkheid voorzien dat de klant zelf zijn fiscale attest kan downloaden en afprinten, maar eveneens de mogelijkheid open houden dat de backoffice op vraag van de klant fiscale attesten kan afprinten. De wanbetalers krijgen geen fiscaal attest totdat het openstaand bedrag is betaald.

III.3.15 Voorwaardelijke inschrijving Het moet mogelijk zijn om voorwaarden te koppelen aan inschrijvingen, de voorwaarden moet aan- en afgezet kunnen worden. Enkele voorbeelden -

Als er nog onbetaalde facturen van de Kinderopvang of Grabbelpas zijn, moeten die eerst betaald worden voordat een inschrijving voor het nieuwe seizoen gedaan kan worden. Een kind kan enkel ingeschreven worden in activiteiten van zijn leeftijdsgroep. …

Bij de opstart van de tool moet de lijst met personen die nog onbetaalde facturen hebben (excel-lijst) in de toepassing kunnen ingevoerd worden.

Blz. 24


PROVINCIE ANTWERPEN

Ref.: 481

Optioneel: via de koppeling met New Horizon wordt gekeken of een klant nog onbetaalde facturen heeft bij de gemeente. Deze klanten kunnen dan geen nieuwe aankopen doen zolang ze openstaande bedragen hebben bij de gemeente.

III.3.16 Zelf content toevoegen De beheerders moeten zelf op een eenvoudige manier content kunnen toevoegen aan de toepassing. -

Voor zaalverhuur betekent dit nieuwe zalen en locaties toevoegen, tarieven wijzigen, … Voor de inschrijvingen betekent dit zelf activiteiten aanmaken en zelf tekst toevoegen, … Voor de ticketverkoop betekent dit zelf voorstellingen en cursussen aanmaken, zaalplannen wijzigen, …

III.3.17 Technische beschrijving van de oplossing De inschrijver geeft in zijn offerte een beschrijving van de aangeboden oplossing vanuit een ITperspectief: architectuur, onderdelen, netwerkprotocollen,… zodat we ons een beeld kunnen vormen van het geheel van de oplossing en de samenhang tussen de verschillende componenten, en een inschatting kunnen maken over compatibiliteit met andere toepassingen, eventuele systeemvereisten, toegankelijkheid van data, enz.

III.3.18 Technologie III.3.18.1 Backoffice Het is een voordeel als de toepassing web-based is en geen installatie van software op de PC vereist is, zo niet voorziet de inschrijver dan een evolutie in die richting en binnen welke termijn?

III.3.18.2 Frontoffice Voor de burgers, onze klanten, moet het mogelijk zijn om de toepassing te gebruiken vanop de meest gebruikte browsers en besturingssytemen zonder extra software te installeren. De inschrijver gebruikt geen verouderde technologie of technologie die moeilijk toegankelijk is maar technologie die frequent gebruikt wordt en zijn diensten al bewezen heeft. We hebben een voorkeur voor een oplossing gebouwd rond standaardsoftware die op maat van ons geconfigureerd wordt eerder dan voor een softwarepakket waarvan de code volledig op maat voor ons geschreven werd. We hebben een voorkeur voor platform-onafhankelijke webtoepassingen. Daarom hanteren we als minimumvereiste dat toepassingen volledig functioneel zijn in recente versies van Internet Explorer en IE7 en Firefox (ook op Linux ) en bij voorkeur zijn ze ook nog conform W3C standaarden en voldoen ze aan de “anysurfer”-vereisten. Zie ook eerdere opmerkingen ivm integratie binnen de gemeentelijke website. Indien de aangeboden toepassing hier niet aan voldoet legt de inschrijver in zijn offerte uitvoerig uit welke (client-side) systemen (besturingssysteem, browser, …) ondersteund worden, en welke bijkomende software of configuratie op de clients vereist is om de toepassing te kunnen gebruiken. We geven de voorkeur aan HTTPS, maar we willen hierbij extra complexiteit vermijden, zoals bijvoorbeeld issues met certificaten en waarschuwingen dat ze ongeldig, vervallen, of self-signed zijn.

Blz. 25


PROVINCIE ANTWERPEN

Ref.: 481

III.3.19 Hosting Omdat inschrijving en ticketverkoop onderhevig kunnen zijn aan piekbelasting geven we er de voorkeur aan de toepassing te laten hosten door de leverancier, beheerd door de inschrijver, en dus niet op serverinfrastructuur van de gemeente. Hosting gebeurt in een datacenter in België. De inschrijver voorziet te allen tijde voldoende verwerkingscapaciteit om het systeem vlot te laten werken.

III.3.20 Congestion protection De inschrijver treft de nodige voorzieningen om ervoor te zorgen dat de tool blijft werken, ook bij piekbelasting. De gemeente zorgt ervoor dat de dienstverlener op voorhand wordt ingelicht als er een inschrijvingspiek verwacht wordt, zodat de inschrijver de nodige voorzorgsmaatregelen kan nemen. De inschrijver legt kort uit hoe hij piekbelasting zal opvangen.

III.3.21 Beveiliging en Informatieveiligheid Welke securitymechanismen gebruikt de inschrijver voor het beveiligen van de website en gegevens tegen ongeoorloofde toegang van derden? De inschrijver duidt aan welke beveiligingsmechanismen gebruikt worden en welke andere beveiligingsmechanismen eventueel gebruikt worden in de toepassing, bijvoorbeeld : -

Internetverkeer over een vertrouwde https verbinding. Encryptie van data bij uitwisseling van gegevens met externe toepassingen (https, sftp, scp, …) paswoorden worden niet in cleartext doorgestuurd (over een vertrouwde https verbinding, met een challenge response authentication algoritme zoals CHAP, …) paswoorden worden als paswoordhashes bijgehouden op de server controle op complexiteit van paswoorden gebruik van firewalls om servers te beschermen virusscanner scant server op virussen en malware derden mogen geen toegang verkrijgen tot de data op de server. Beheerders van de server infrastructuur mogen enkel data raadplegen in het kader van troubleshooting. Er is toegangscontrole tot de serverroom Gedetailleerde logging maakt het mogelijk om te achterhalen wie wat en wanneer doet. oude & defecte harde schijven worden vernietigd …

De software waarvan sprake zal in ieder geval informatie bevatten waarbij aandacht voor informatieveiligheid een belangrijke vereiste is: persoonlijke gegevens, gevoelige gegevens (bv. medische gegevens van identificeerbare personen), … , gegevens onderhevig aan weten regelgeving met betrekking tot informatie uit het Rijksregister, de Kruispuntbank Sociale Zekerheid, Kruispuntbank Ondernemingen, … De voorgestelde oplossing moet daarom minstens voorzien in een adequaat gebruikers- en rechtenbeheer. Als gegevens op externe servers staan (datacenter van een leverancier, extern gehoste toepassingen, “cloud”-oplossingen) moet de leverancier in principe ook voldoen aan het informatieveiligheidsbeleid en de weten regelgeving die van toepassing is op informatie uit het Rijksregister, de Kruispuntbank Sociale Zekerheid, Kruispuntbank Ondernemingen, … De leverancier zal in zijn offerte aangeven welke maatregelen hij heeft genomen of zal nemen op het vlak van business continuity en om de confidentialiteit, integriteit en beschikbaarheid van de gegevens te waarborgen. Hierbij kan eveneens

Blz. 26


PROVINCIE ANTWERPEN

Ref.: 481

aangegeven worden aan welke ISO-normen m.b.t. informatieveiligheid (ISO 27001, ISO27018, …) de leverancier of het datacenter gecertifieerd is. Gegevens die in de software opgeslagen of verwerkt worden zullen niet buiten de toepassing toegankelijk zijn (bijv. in tijdelijke bestanden, spools, caches, …) voor niet-geauthenticeerde gebruikers of voor gebruikers met minder rechten dan in de toepassing zelf gedefinieerd. De inschrijver licht in de offerte tevens zijn backup- en recoverystrategie toe, zowel qua Disaster Recovery (Recovery Time Objective (RTO), Recovery Point Objective (RPO)) als, indien van toepassing, qua roll-back bij fouten van gebruikers e.d.

III.3.22 Licenties We geven de voorkeur aan licentiemodellen die het uitrollen van software met zo weinig mogelijk administratieve overhead, zo weinig mogelijk extra complexiteit en zo weinig mogelijk beperkingen wat betreft aantal gebruikers of installed instances mogelijk maken en die toelaten flexibel in te spelen op wijzigende omstandigheden qua noden en aantallen gebruikers, zonder administratieve overlast m.b.t. het beheer van licenties. We geven bijgevolg de voorkeur aan een door OSI als Open Source erkende licentie. Verder geven we de voorkeur aan site-licenties boven concurrent user licenties, en aan concurrent use licenties boven named users, maar indien de keuze van licentiemodel impact heeft op de prijs zal die factor uiteraard ook een rol spelen. De leverancier beschrijft, indien van toepassing, alle toepasselijke registratie-, activatie of andere licentiecontrolemechanismen, inclusief eventuele licensing servers, hardware dongels, installatie van licentiesleutels of product keys, administratieve procedures, … die vereist zijn om de software gebruiken en om (bijkomende) licenties te activeren. De leverancier geeft voor client-side software ook aan op welke manier deze procedures en mechanismen in overeenstemming gebracht kunnen worden met een geautomatiseerd software deployment.

III.3.23 Toekomstbestendigheid en Interoperabiliteit We vinden het belangrijk om een exit-strategie voor softwaretoepassingen te hebben of te kunnen ontwikkelen, en we willen voor de aanschaf van een systeem zicht hebben op hoe die exit-strategie er uit kan zien, zodat we dat ook als overweging kunnen meenemen in de evaluatie van offertes. De offerte zal ons dus voldoende informatie hierover moeten verschaffen. Voor de oplevering zal de leverancier door middel van een Proof of Concept aantonen dat bij application retirement de relevante informatie op een adequate manier uit de toepassing geëxporteerd kan worden en dat een archiveringsmechanisme voorzien kan worden die de data op een betekenisvolle manier exporteert naar een raadpleegbaar systeem dat niet aan veroudering onderhevig is (bijvoorbeeld door gebruik te maken van gekende toekomstbestendige bestandsformaten, open protocollen, …). In het kader van interoperabiliteit en gegevensuitwisseling tussen toepassingen zullen wij ons in de toekomst richten op de OSLO specificatie (Open Standaarden voor Lokale Overheden), zowel wat betreft uitwisselingsformaten als wat betreft het koppelen met authentieke bronnen (bijv. Rijksregister). U kan hiervoor eventueel informatie inwinnen bij de OSLO-werkgroep van V-ICT-OR (www.v-ict-or.be). Aangezien dit om een nog zeer recente specificatie gaat verwachten wij niet dat bestaande software al conform is aan deze specificatie. We verwachten van onze leveranciers wel een engagement om deze standaard in de toekomst te ondersteunen als dat nodig is om interoperabiliteit tussen zijn software en andere door het bestuur gebruikte toepassingen mogelijk te maken of om hergebruik van data in authentieke bronnen te faciliteren. De inschrijver geeft in zijn offerte tevens mee hoe hij de toekomstige ontwikkeling van de gegeven software ziet, en het tijdsbestek daarvoor.

Blz. 27


PROVINCIE ANTWERPEN

Ref.: 481

III.3.24 Conversie van data uit de vorige toepassing Op vlak van conversie van bestaande data uit de huidige toepassingen, willen we enkel klantgegevens importeren (naam, adres, rijksregisternummer, enz.), geen historiek van inschrijvingen of transacties. Deze gegevens worden uitgezuiverd door het bestuur en zullen daarna in een standaard formaat (XLS of CSV) bezorgd worden aan de leverancier zodat hij de data kan importeren. Voor sommige modules kunnen “klantgegevens” toch vrij complex zijn (bijvoorbeeld : relaties tussen ouders en kinderen, nieuw samengestelde gezinnen, …). De leverancier van de nieuwe toepassing zal zijn medewerking verlenen om, indien nodig, deze gegevens te converteren of te manipuleren om een import in de nieuwe software mogelijk te maken.

III.3.25 SLA, Support en onderhoud III.3.25.1 Helpdesk We verwachten een telefonisch vlot bereikbare helpdesk die assistentie kan verlenen op de vragen en problemen van de medewerkers tijdens kantooruren. De werking van de helpdesk wordt beschreven in de offerte. Optioneel: we wensen ook beroep te kunnen doen op de helpdesk tijdens de inschrijvingsmomenten, dit is maximaal 5 per jaar.

III.3.25.2 Interventietijden De inschrijver geeft aan welke interventietijden hij vooropstelt voor het oplossen van problemen. Er mag daarbij een onderverdeling gemaakt worden tussen Critical, Major en Minor problemen.

III.3.25.3 Availability Met availability van de service bedoelen we niet enkel dat een klant op de website moet raken en op een vlotte manier een bestelling moet kunnen invoeren maar ook dat de toepassing beschikbaar is voor de verschillende diensten en dat zij ook vlot hun dagelijkse taken kunnen uitvoeren. Vereiste availability van de service op jaarbasis is 99.73% (24h downtime op jaarbasis). De inschrijver voorziet voldoende monitoring om problemen tijdig te detecteren en grijpt in als het mis loopt.

III.3.25.4 Meten van de availability van de service Om betwistingen achteraf te vermijden is het belangrijk om op voorhand een methode af te spreken om op een objectieve manier de beschikbaarheid van de service vast te stellen. Penalties bij het niet naleven van de SLA Bij het niet halen van het availability cijfer kan het gemeentebestuur per begonnen uur een korting van 1% op de jaarlijkse onderhoudsfactuur eisen. Uitzondering: tijdens de eerste inschrijvingsdagen voor grabbelpas en de themakampen verwachten we op korte tijd een grote toestroom van aanvragen. Het is uitermate belangrijk dat de toepassing op dat ogenblik vlekkeloos de aanvragen kan verwerken. Vanaf een half uur voor het openen van de inschrijvingen tot 3,5 uur na het openen van de inschrijvingen kan het gemeentebestuur voor elke begonnen 15 minuten unavailability een korting van 1% op de jaarlijkse onderhoudsfactuur eisen. Er zijn maximaal 5 inschrijvingsmomenten op een jaar en de inschrijvingsmomenten worden door het gemeentebestuur minimaal 2 weken op voorhand aan de uitvoerder van de opdracht gemeld zodat die zich kan voorbereiden om de systemen optimaal voor te bereiden. Als het gemeentebestuur zich niet aan deze voorwaarden houdt, kan het ook geen aanspraak maken op de korting.

Blz. 28


PROVINCIE ANTWERPEN

Ref.: 481

Het totaal van de korting ten gevolge SLA breach van de service zal maximaal 20% op de jaarlijkse factuur bedragen.

III.3.25.5 Bugs Softwarebugs oplossen zit begrepen in het onderhoudscontract.

III.3.25.6 Updates en geplande onderhoudswerken Installeren van updates en patches, herstarten van servers, vervangen van hardware, …. alle werkzaamheden die minstens een week op voorhand aan ons gemeld worden en die gepland worden op een ogenblik dat de impact voor ons en onze klanten minimaal is en binnen een redelijke termijn worden uitgevoerd worden niet meegerekend in het availability cijfer.

III.3.25.7 Andere Indien de inschrijver betere voorwaarden heeft dan wat gevraagd is of als het jaarlijkse onderhoudscontract bijkomende zaken omvat, graag een oplijsting (bv. de inschrijver levert een pakket af dat steeds verder ontwikkeld wordt en waarvan nieuwe versies en features van de software inbegrepen zijn in het jaarlijkse support en onderhoudscontract, …)

III.3.26 Plan van aanpak In de offerte moet een eerste aanzet van het volledige implementatietraject beschreven worden. De prijs van projectmanagement en implementatie moet mee opgenomen worden in de totaalprijs. Het beschreven implementatietraject omvat minimaal een kick-off-vergadering, een of meerdere acceptatie momenten (aantal o.a. afhankelijk van de fasering van het project), een testfase, en een periode van in dienst nemen van de software, een periode gedurende dewelke de configuratie of parametrisering nog verder bijgesteld kan worden alvorens over te gaan tot de definitieve acceptatie. Na de gunning van de opdracht zal de leverancier, in samenspraak met het bestuur, een volledig projectmatig implementatietraject uitwerken

III.3.27 Testen We verwachten van de inschrijver dat hij alles grondig test vooraleer de software op te leveren. De diensten van het gemeentebestuur moeten ook voldoende de tijd krijgen om de toepassing uit te testen en er vertrouwd mee te raken, we rekenen daarvoor op een maand tijd. De diensten moeten de software een maand voor de oplevering van de software reeds toegang krijgen tot de applicatie. De inschrijver levert daarvoor een testplan af.

III.3.28 Referenties Referenties van gelijkaardige implementaties bij andere besturen (in de buurt) zijn een pluspunt. De inschrijver bezorgt een overzicht.

Blz. 29


PROVINCIE ANTWERPEN

Ref.: 481

III.3.29 Opleiding In de offerte zit inbegrepen alle opleidingen die noodzakelijk zijn om met het pakket te werken. Dit mag opgesplitst zijn in een opleiding voor de beheerders (zij die zalen aanmaken, activiteiten toevoegen, rapporten aanmaken, … ) en de gewone gebruikers (enkel producten verkopen) Afleveren van documentatie en handleidingen in de Nederlandse taal.

III.3.30 Beëindiging samenwerking Inschrijver stelt een systeem voor waarbij het gemeentebestuur toch nog verder met de toepassing kan blijven werken zonder support van de inschrijver als om een of andere reden de samenwerking met de inschrijver wordt stopgezet of de inschrijver zijn activiteiten stopzet. Zie ook hoger rubriek III.3.23 Toekomstbestendigheid en Interoperabiliteit

Blz. 30


PROVINCIE ANTWERPEN

Ref.: 481

III.4 Afzonderlijke modules III.4.1 Module 1: Zaalverhuur Onder zaalverhuur wordt verstaan het beheer van allerhande ruimtes zoals polyvalente zalen, vergaderruimtes, sportvelden, … . De toepassing moet het mogelijk maken om ruimten vlot te kunnen verhuren, door o.a. een accuraat overzicht te geven van de bezetting, het werk voor de administratieve diensten te vereenvoudigen door de repetitieve taken bij de administratieve opvolging zoveel mogelijk te automatiseren, tussenkomst van een beheerder tot een minimum te beperken, koppelingen voorzien met externe toepassingen om dubbele invoer van gegevens te voorkomen en het hergebruiken van gegevens die reeds beschikbaar zijn in andere toepassingen. Een gebruiksvriendelijke online tool moet ervoor zorgen dat de klanten de voorkeur geven aan online ingeven van de reservatie wat er verder voor moet zorgen dat de werklast voor de administratieve diensten vermindert.

III.4.1.1 Licenties Indien het systeem met licenties per gebruiker /connectie op de database werkt, dan zijn hier 12 gebruikers waarvan 8 simultaan.

III.4.1.2 Zalen Mogelijkheid om bij elke zaal/terrein een toelichting te voegen. Koppelen van informatie aan bepaalde zalen: -

-

Capaciteit van de zaal Locatie ( om een koppeling te kunnen maken tussen alle zalen in een specifiek gebouw ) Lijst van types activiteiten die kunnen doorgaan in de zaal. Bv. zaal X is geschikt voor sport. Zaal Y is geschikt voor vergaderingen en cursussen. Dit kan handige informatie zijn voor een zoekfunctie maar het type activiteit kan ook bepalend zijn voor het tarief dat aan de klant zal aangerekend worden. Beheerder van de zaal ( sportdienst, cultuurdienst, Vrijetijdsbalie, … ) Boekhoudkundige informatie (op welk gemeentebudget moeten de inkomsten geboekt worden of is het een zaal waarvoor een 3e partij de facturatie afhandelt ) Lijst van opties die bij deze zaal beschikbaar zijn: bv. drank, beamer, kleedkamer, … bij elke optie moet een aantal en een eenheidsprijs kunnen meegegeven worden. De burger moet kunnen opgeven welke opties gewenst zijn. Mogelijkheid om aan te geven of een activiteit die doorgaat in een zaal privaat of publiek is (mogelijkheid om het instellen van een default waarde voor elke zaal, bv. standaard zijn de activiteiten voor zaal X private activiteiten, zaal Y is een zaal voor intern gebruik ). Koppelen van exclusies, sommige zalen of ruimten zijn deelbaar. Als een deel van een groter geheel verhuurd wordt dan is het geheel niet meer beschikbaar voor verhuur. Idem als het geheel verhuurd wordt dan mogen de afzonderlijke delen niet meer beschikbaar zijn. Per zaal kunnen instellen hoe vroeg op voorhand reservaties ingegeven kunnen worden, bv. verenigingen kunnen de zaal al 12 maand op voorhand aanvragen. Per zaal kunnen instellen welke doelgroep (bv. Jeugdcentrum) de zaal huurt.

III.4.1.3 Reservaties Bij een online geboekte reservatie neemt de klant een optie op de zaal. De reservatie is pas definitief als die bevestigd wordt door de beheerder. Het zou handig zijn als op een of andere manier duidelijk zou zijn voor de beheerder van de zaal of de klant nog onbetaalde openstaande facturen heeft. Reservaties kunnen eenmalig gemaakt worden, seriereservaties (elke maandag, elke eerste dinsdag van de maand,… tussen start en einddatum, willekeurige lijst van datums) moeten op een eenvoudige manier en in een bestelling in het systeem kunnen ingegeven worden. Blz. 31


PROVINCIE ANTWERPEN

Ref.: 481

Klant moet de mogelijkheid hebben om in het bestelformulier geen of meerdere opties uit de lijst van beschikbare opties aan te klikken. Bv. 1x beamer, 2x kleedkamer, … De beheerder van de sportdienst moet de kleedkamers toewijzen. Het toewijzen van (een) kleedkamer(s) aan een reservatie moet vlot gaan (bij het openen van het aanvraagformulier door de beheerder moet de bezetting van de kleedkamers vlot geraadpleegd kunnen worden zodat de kleedkamers op een snelle manier aan een reservatie kunnen worden toegevoegd.). Ook bij het tonen van de activiteiten op het informatiescherm moeten de toegewezen kleedkamers zichtbaar zijn (bv.. 9.00 – 11.00 zaaldeel B: minivoetbal (kleedkamer 1 & 6). Variabele webformulieren moeten het mogelijk maken om afhankelijk van de zaal andere informatie te vragen. Voor bepaalde types van zalen moet het mogelijk zijn om extra vragen te stellen via het orderformulier. Het moet mogelijk zijn om per zaal de minimale verhuurtijd in te stellen (bv. minimaal een uur, minimaal een halve dag, verlengbaar per half uur, … ) Het moet mogelijk zijn om marges in te bouwen waarbij de zaal geblokkeerd blijft voor bbv. het klaarzetten en afruimen van de ruimte. De burger moet in een vrij tekstveld bijkomende informatie kunnen meegeven. De bezoekers van de website moeten de zaalbezetting voor de publieke zalen kunnen raadplegen zonder dat ze aangemeld moeten zijn. Het is pas als een klant effectief een zaal wenst te reserveren dat aanmelden vereist is.

III.4.1.4 Klanten Naast het standaard profiel van de gebruiker of organisatie met daarin naam, adres en contactgegevens moeten ook door de dienst zelf te bepalen informatie gekoppeld kunnen worden aan het klantenprofiel. Bij voorkeur een of meerdere vrije velden die zichtbaar zijn voor alle beheerders (sport, cultuur, …) en een of meerdere velden die slechts zichtbaar zijn voor de eigen dienst (een veld enkel zichtbaar voor de sportdienst, een veld voor de cultuurdienst, … ). Optioneel: Is het mogelijk om het systeem zo te maken dat het enkel de hoofdbeheerder is van de organisatie die contactpersonen kan toevoegen of hun gegevens kan wijzigen? De koppeling met de gebruikers die in naam van de organisatie mogen optreden mag dan eventueel in het zaalreserveringspakket gedocumenteerd worden. Let ook dat de contactgegevens van een persoon die uit naam van een vereniging verschillend kunnen zijn van de persoonlijke contactgegevens . Bij communicatie tussen de dienst en de organisatie wordt naast de aanvrager ook steeds de hoofdcontactpersoon op de hoogte gehouden (ontvangt een kopie van mails en brieven).

III.4.1.5 Administratieve afhandeling De beheerder moet in een duidelijk overzichtsscherm een beeld krijgen van alle onbehandelde nieuwe aanvragen, aanvragen in behandeling, enz. Na controle door de beheerder van de aanvraag en eventuele correcties moet met een eenvoudige “druk op de knop” het administratieve proces gestart worden. Het administratieve proces moet maximaal geautomatiseerd zijn (opmaak contracten, bijwerken van de boekhouding, uitsturen en opvolgen van de facturatie, …). De keuze moet bestaan om communicatie per mail te doen of per brief.

Blz. 32


PROVINCIE ANTWERPEN

Ref.: 481

De beheerder moet de mogelijkheid hebben om alle ingegeven informatie door de klant te overrulen met eigen input. Ook de standaard voorgestelde bedragen en waarden moeten overruled kunnen worden.

III.4.1.6 Verlofkalender Het moet mogelijk zijn om meerdere kalenders met sluitingsdagen en verlof, ... in te geven (bv. een kalender met sluitingsdagen voor de sportdienst, een voor de cultuurdienst, …). Aan elke zaal kan dan een kalender gekoppeld worden. Grafisch voorstellen en bewerken. Gebruiksvriendelijk “Outlook-achtige” kalender interface waarin duidelijk de bezetting van een zaal kan worden weergegeven. Gebruik van een kleurencode om bv. opties, definitieve reservaties en sluitingsperiodes duidelijk weer te geven. Mogelijkheid om korte tekstweergave in de kalender weer te geven: -

Meldingen uit de verlofkalender (Nieuwjaar, Pasen, jaarlijks verlof, … ). Voor publieke activiteiten melding van de naam van de activiteit. Voor private of interne activiteiten een duidelijke melding bv. gereserveerd of bezet. Voor exclusions (delen van een samengestelde ruimte die niet beschikbaar zijn door verhuur van een onderdeel of het geheel): duidelijk melding dat de ruimte niet beschikbaar is als een deel of het geheel reeds verhuurd is. Tijdsaanduiding in de kalender

Mogelijkheid om via de webinterface reservaties grafisch aan te maken en te bewerken zoals in outlook.

III.4.1.7 Tarieven Tarieven zijn afhankelijk van de zaal, soort activiteit, type klant, van de dienst die de zaal verhuurt,… Het moet mogelijk zijn om kortingen in te geven, kortingen moeten met een vast bedrag ingegeven kunnen worden. Indien procentuele ingave ook mogelijk is, is dat een pluspunt. Het is mogelijk om met een vaste maandelijkse huur te werken. Een vereniging kan bv. een permanent en exclusief lokaal toegewezen krijgen. Zie bijlagen voor de actuele tarieven die gehanteerd worden op de sportdienst, jeugddienst en het ontmoetingscentrum.

III.4.1.8 Betalen Bij zaalverhuur kan er online (Ingenico), cash (bancontact) betaald worden of er kan met overschrijving gewerkt worden.

III.4.1.9 Boekhouding Koppeling met de gemeentelijke boekhouding zodat ontvangsten van cash geld in de boekhouding ingeboekt worden. Afhankelijk van de zaal moeten de inkomsten op een specifieke balanspost geboekt kunnen worden (sport, cultuur, …).

III.4.1.10 Zoekfunctie In eerste instantie moet de klant een zaal kunnen zoeken op locatie (bv. O.C. ’t Waaigat, sporthal voetbalterreinen,…).

Blz. 33


PROVINCIE ANTWERPEN

Ref.: 481

Optioneel: de mogelijkheid om een zaal te zoeken per type activiteit: ik wens een zaal te reserveren om te [lijst activiteiten] -> Systeem toont dan enkel zalen/locaties waar activiteit Y kan “beoefend” worden. Rapportering: voorbeelden van rapporten zouden bv kunnen zijn: -

Overzicht per dag van alle activiteiten in een locatie met details die nodig zijn om de zaal te kunnen klaarzetten (bv. om 10u vergadering in zaal X, 4x koffie, 4x frisdrank, 1x beamer) Jaarlijkse rapporten, bv. o jaaroverzicht van welke zalen door wie werden gehuurd, … o jaaroverzicht met bezetting van de zalen op een bepaalde locatie o aantal deelnemers per activiteit, per leeftijdsgroep, … o jaaroverzicht van de inkomsten

- Optioneel: een webpagina, los van de gemeenschappelijke website, met daarop een overzicht van de activiteiten van de dag op een bepaalde locatie. Deze webpagina wordt dan aan de ingang van een locatie op een informatiedisplay afgespeeld. Ideaal worden de activiteiten die nu aan de gang zijn en die activiteiten die gepland staan voor de komende paar uur in een soort takenlijst weergegeven. De informatie wordt over meerdere schermen verdeeld en cyclisch weergegeven indien niet alle info op 1 enkel scherm kan worden afgebeeld.

III.4.1.11 Koppelingen (optioneel) Naast de koppelingen die noodzakelijk zijn en in de algemene vereisten werden beschreven (facturatie, integratie website) moet voor het zaalbeheersysteem ook een koppeling voorzien worden met het energiebeheer van de gebouwen die over een energiebeheersysteem beschikken.

Blz. 34


PROVINCIE ANTWERPEN

Ref.: 481

III.4.2 Module 2: Materiaalverhuur Onder materiaalverhuur wordt verstaan het beheer van de gemeentelijke materialen (tafels, stoelen, podiumelementen,…). De toepassing moet het mogelijk maken om het materiaal vlot te kunnen verhuren, door o.a. een accuraat overzicht te geven van de bezetting, de tussenkomst van de beheerder tot een minimum te beperken. Een gebruiksvriendelijke online tool moet ervoor zorgen dat de klanten de voorkeur geven aan online reserveren waardoor de werklast van het personeel kan verminderen.

III.4.2.1 Licenties Indien het systeem met licenties per gebruiker/connectie op de database werkt, dan zijn hier 4 gebruikers nodig, waarvan 2 simultaan.

III.4.2.2 Materialen Mogelijkheid voorzien om aan de verschillende stukken materiaal uitleg toe te voegen.       

 

een duidelijk overzichtelijk systeem, sterk visueel gericht. Men ziet onmiddellijk dat het materiaal in gebruik is. eenvoudige wijze om materiaal te reserveren eenvoudige wijze om parameters in te voeren en te wijzigen eenvoudige wijze om gewijzigde persoonsgegevens aan te passen Beheerder van het materiaal (VT-balie) per materiaalonderdeel kunnen instellen hoe vroeg op voorhand reservaties ingegeven kunnen worden. bij online geboekte reservatie neemt de klant een optie op materiaal. De reservatie is pas definitief als die bevestigd wordt door de beheerder. Het zou handig zijn als op een of andere manier duidelijk zou zijn voor de beheerder van de materiaaluitleen of de klant nog onbetaalde facturen heeft staan. de klant moet in een vrij tekstveld bijkomende informatie kunnen meegeven. de bezoekers van de website moeten de stand van zaken van de materiaaluitleen kunnen raadplegen zonder dat ze aangemeld moeten zijn. Het is pas als een klant effectief materiaal wenst te reserveren dat aanmelden vereist is.

III.4.2.3 Grafisch voorstellen en bewerken -

Gebruiksvriendelijke “outlook-achtige” kalender interface waarin duidelijk de bezetting van het materiaal kan worden weergegeven. Gebruik van een kleurencode om bv. opties, definitieve reservaties en sluitingsperiodes duidelijk weer te geven. Mogelijkheid om korte tekstweergave of meldingen in de kalender weer te geven.

III.4.2.4 Betalen Bij materiaalverhuur kan cash of met bancontact betaald worden of met een overschrijving gewerkt worden.

III.4.2.5 Boekhouding Koppeling met de gemeentelijke boekhouding New Horizon (firma Cevi) zodat ontvangsten van cash geld of betaling via bancontact in de boekhouding ingeboekt worden.

Blz. 35


PROVINCIE ANTWERPEN

Ref.: 481

III.4.3 Module 3: Inschrijvingen voor vrije tijdsactiviteiten van jeugd, sport, cultuur Onder een inschrijvingsinstrument verstaan we een instrument voor het beheer van activiteiten voor jeugd, sport, cultuur en kinderopvang tijdens de vakantieperiodes. De Vrijetijdsbalie moet in het systeem de activiteiten kunnen ingeven, documenteren, inschrijven van deelnemers voor activiteiten, aanmaken van fiscale attesten voor de ouders,… Het is zeer belangrijk dat het instrument toelaat om online zeer vlot in te schrijven en de piekbelasting die met de momenten van inschrijven gepaard gaat kan verwerken. Ook hier moet de toepassing de werklast voor de VT-balie minimaliseren door de repetitieve en/of arbeidsintensieve taken te automatiseren, het voorzien van logisch ingedeelde schermen die een efficiënte invoer van gegevens mogelijk maken en door koppelingen te voorzien met externe programma’s om maximaal hergebruik van bestaande gegevens mogelijk te maken.


III.4.3.2 Klanten a) Volwassenen: De klanten zijn de ouders die hun kind willen inschrijven in een activiteit of zichzelf willen inschrijven voor een activiteit of als een volwassene zonder kinderen. Het is belangrijk dat de toepassing gezin georiënteerd is. D.w.z. dat een ouder een overzicht houdt op zijn/haar kinderen en dus kinderen moet kunnen toevoegen aan zijn/haar profiel. Verder is het ook belangrijk bij het afdrukken van de fiscale attesten dat een ouder een attest krijgt voor alle kinderen samen. De toepassing houdt uiteraard rekening met de “moderne” gezinssituaties bv. kinderen van gescheiden ouders kunnen een deel van de vakantie bij de vader en een deel bij de moeder zijn. Voor deze toepassing is het belangrijk om naast het basisprofiel van de gebruiker nog bijkomende info bij te houden. b) Kinderen: Extra info die bijgehouden moet worden naast het basisprofiel (zie ook III.4.3.4): Leeftijdsgroep (veld = geboortedatum): programma moet rekening houden met het geboortejaar van de kinderen zodat ze niet per ongeluk ingeschreven kunnen worden in een activiteit die niet voor hen bedoeld is. De beheerder kan het veld ‘geboortejaar’ aanpassen op vraag van de ouder (veld kan niet per activiteit gekozen worden, eenmaal een keuze gemaakt is dit van invloed op alle activiteiten waarvoor de ouder een kind kan inschrijven). Medische info (= een vragenlijst met o.a. Contactgegevens van huisdokter) moet bijgehouden kunnen worden. De medische gegevens moeten jaarlijks bevestigd worden en de datum van de laatste bevestiging moet bijgehouden worden (het is belangrijk dat de toepassing een waarschuwing kan geven indien de medische info van een kind werd bijgewerkt). Kinderen kunnen niet ingeschreven worden voor activiteiten als de medische info niet recent bevestigd werd. Indien de bevestiging nog niet ontvangen werd dan moet de klant bij voorkeur naar het scherm geleid worden waar hij de medische info kan bevestigen. De info moet ook up-to-date kunnen gemaakt worden door de backoffice. Het is ook belangrijk om enkele extra telefoonnummers te kunnen toevoegen zoals gsm moeder en vader, telefoonnummer waarop iemand van de familie te bereiken is in geval van nood. Ook een veld voorzien waarin ouders aangeven wie de kinderen mag ophalen. Aangezien deze info naar alle waarschijnlijkheid voor alle kinderen van eenzelfde gezin dezelfde zal zijn, kan deze info misschien in het profiel van de ouder terecht komen.

Blz. 36


PROVINCIE ANTWERPEN

Ref.: 481

Er moet ook een vrij tekstveld aan het profiel kunnen toegevoegd worden waar informatie voor intern gebruik aan kan toegevoegd worden.

III.4.3.3 Controles De leeftijdsgroep van de kinderen komt overeen met de activiteit, kinderen kunnen niet inschrijven voor activiteiten die niet voor hun leeftijdsgroep bedoeld zijn. Dit moet kunnen overruled worden in backoffice (bv.. voor zittenblijvers). Er moet bijgehouden worden of er nog openstaande facturen zijn. Indien er nog openstaande facturen zijn moet de mogelijkheid bestaan om nieuwe inschrijvingen niet toe te staan. Er mag echter geen koppeling zijn tussen de registratie Speelpleinwerking en controle op onbetaalde facturen. - De controle moet melden aan de klant dat er nog openstaande facturen zijn en dat die eerst betaald moeten worden voordat de ouder kan inschrijven; de ouder kan geen bestelling ingeven. - De controle op openstaande facturen moet afgezet kunnen worden. Zoals bij elke input moet de beheerder de controle kunnen negeren, maar het systeem moet de beheerder er wel attent op maken dat hij iets probeert in te geven wat niet voorzien is. Is de activiteit volgeboekt dan moet de klant de mogelijkheid krijgen om zich toe te voegen op de wachtlijst.

III.4.3.4 Klantenprofiel Het basisprofiel dient aangevuld te worden met enkele specifieke velden: Profiel module inschrijvingen * vetgedrukte velden staan in het basisprofiel Voor de inschrijving van een volwassene volstaat onderstaande info: Veld Persoon Naam Verplicht Voornaam Verplicht Geboortedatum Verplicht Geslacht Verplicht Rijksregisternummer (RRNR) Verplicht Hoofd adres (straat, huisnummer, bus, Domicilie adres, postcode, gemeente) verplicht 2de adres Verblijfadres (enkele indien verschillend van domicilieadres), niet verplicht Telefoon/GSM Verplicht Email adres Verplicht, bij voorkeur gebruikerslogin van de toepassing Rekeningnummer Niet verplicht Wijze van factureren post of email Niet verplicht Sociaal tarief (OCMW, vrijetijdspas) In te vullen door beheerder en van toepassing voor hele gezin

Blz. 37


PROVINCIE ANTWERPEN

Medische fiche volwassene Naam, adres, telefoonnummer huisarts Naam, adres, telefoonnummer (privé + werk) van de persoon die in geval van ziekte of enig ander ongeval dient verwittigd te worden Ziekenfonds Bloedgroep Nuttige medische info (bv.. allergieën, astma, epilepsie, adhd, …) Andere inlichtingen of bemerkingen?

Ref.: 481

Verplicht Verplicht

Niet verplicht Niet verlicht Niet verplicht Niet verplicht

Voor de inschrijving van een kind graag extra info: Naam en voornaam kind Verplicht Geboorteplaats Verplicht Geboortedatum Verplicht Geslacht Verplicht Rijksregisternummer Verplicht Persoonlijke GSM Niet verplicht Persoonlijke e-mail Niet verplicht Contactpersoon 1 (relatie met kind, naam, Niet verplicht adres, tel/gsm) Contactpersoon 2 (relatie met kind, naam, Niet verplicht adres, tel/gsm) -12 jarigen: fiscaal attest op naam van Verplicht Naam school Niet verplicht Medische fiche kind Naam, adres, telefoonnummer huisarts Naam, adres, telefoonnummer (privé + werk) van de persoon die in geval van ziekte of enig ander ongeval dient verwittigd te worden Ziekenfonds Bloedgroep Laatste inenting anti-tetanus (datum): Kan 25m zwemmen: ja/nee Mag alleen naar huis: ja/nee Nuttige medische info (bv.. allergieën, astma, epilepsie, adhd, …) Andere inlichtingen betreffende het karakter?  

Verplicht Verplicht

Niet verplicht Niet verlicht Niet verplicht Niet verplicht Niet verplicht Verplicht Niet verplicht

Profielen volwassene(n) + kind(eren) uit een zelfde gezin koppelen. Aan de Vrijetijdsbalie melden dat het medisch profiel is aangepast.

III.4.3.5 Input van activiteiten De activiteiten moeten in het systeem gedocumenteerd kunnen worden, hier volgt een opsomming van de info die het systeem moet bijhouden en/of afbeelden op het scherm van de beheerder. Het moet mogelijk zijn om per activiteit bijkomende info op te vragen (meerkeuze, tekstveld) al dan niet met een meerprijs. Bv. skiën : schoenmaat, ervaring, inwoner/niet-inwoner. Bv. keuzeactiviteit : sportdag. Er zijn verschillende types activiteiten bv. speelplein, grabbelpas, sportkamp en kinderopvang. Naast het feit dat het type activiteit als filterveld kan gebruikt worden (bv. toon alle activiteiten van grabbelpas) bepaalt het type activiteit ook de betalingswijze: -

grabbelpas en sport is vooraf te betalen, online of aan de VT-balie ( cash of bancontact) bij kinderopvang wordt er pas na de geleverde dienstverlening (maandelijks) afgerekend.

Blz. 38


PROVINCIE ANTWERPEN

Ref.: 481

Ook moet per activiteit een start- en einddatum gekoppeld kunnen worden waartussen de inschrijving voor dit type activiteit open staat. Het zou handig zijn als activiteiten eenvoudig gekopieerd zouden kunnen worden. Het zou handig zijn als die snel zouden kunnen worden aangemaakt en gekopieerd worden, waarbij dan enkel bv de datum dient aangepast te worden. Het systeem moet start- en einddatum, titel, korte en lange omschrijving kunnen bijhouden van de activiteit. Sommige activiteiten duren een aantal uren, een halve dag, een dag, andere meerdere dagen. Per activiteit moeten een aantal zaken bijgehouden kunnen worden, waaronder: - plaats, start- en einddatum - totale kostprijs - organisatie (naam organisatie, titel deelactiviteit, beschrijving, naam contactpersoon, telefoonnummer, gsm nummer, e-mailadres, website). o Bv. activiteit X bestaat uit busrit heen, museum bezoek, frietjes eten, wandeling, busrit terug. o De contactorganisaties zitten bij voorkeur in een afzonderlijke tabel en kunnen geselecteerd worden uit een lijst ( bv. trein, bus, … kunnen meerdere keren terug komen) Kostprijs voor de deelnemer, deelnemerslimiet. Mogelijkheid om een foto toe te voegen aan de activiteit. Berekende waarde: aantal reeds ingeschreven x kostprijs per deelnemer Komt de activiteit in aanmerking voor een fiscaal attest (standaardwaarde bij het ingeven van een activiteit is ja) Per activiteit moeten bij voorkeur een vrij aantal vertrek- en aankomst plaatsen ingegeven kunnen worden. Pluspunt: Het zou zeer handig zijn als het systeem ook toelaat om verborgen activiteiten aan te maken, bv. inschrijvingen sportdag personeel.

III.4.3.6 Dossiers Voor inschrijvingen van kinderen is het belangrijk dat de ouders een “dossier” hebben. Belangrijk zijn : contactinformatie – ruimer dan officieel adres : ouders en/of andere contactpersonen moeten, bv. bij ongeval, kunnen verwittigd worden (ook op hun werk, …).

III.4.3.7 Regionale Sport (Sportdienst) Dit zijn sportactiviteiten van andere inrichters (niet de gemeentelijke sportdienst), maar de sportdienst maakt er wel promotie voor en regelt de inschrijvingen. Dat wil zeggen dat de online toepassing van de gemeente enkel dient als aanvraag-medium. De sportdienst regelt de eigenlijke inschrijving in een ander systeem (Google Docs) en laat de klant/burger iets weten. De inschrijvingen en betalingen worden verwerkt door de sportdienst, maar moeten niet volledig online verwerkt worden omdat er ook in andere gemeenten wordt ingeschreven en het systeem bijgevolg de vrije plaatsen van een activiteit niet kent. De online toepassing van de gemeente dient als aanvraagmedium. De sportdienst kijkt de beschikbaarheid na (gemeenten registreren hun inschrijvingen in Google Docs) en brengt de geïnteresseerde op de hoogte. Mogelijkheid voorzien om aan balie (cash/BC) of via factuur/overschrijving te betalen.

III.4.3.8 Rapporten Met de info in de verschillende deelactiviteiten moet het mogelijk zijn om een rapport op te stellen dat als contract gebruikt kan worden tussen het gemeentebestuur en de betrokken organisatie.

Blz. 39


PROVINCIE ANTWERPEN

Ref.: 481

Activiteiten moeten in een rapport kunnen afgedrukt worden dat kan dienen als input voor de drukker van het jaarlijkse activiteiten programmaboekje. Lijst van activiteiten waarvoor een wachtlijst bestaat en waar op de activiteit zelf terug vrije plaatsen beschikbaar zijn. De lijst moet ook de personen op de wachtlijst met hun contactgegevens tonen zodat die vlot kunnen gecontacteerd worden. Lijst met kinderen van wie de medische gegevens onlangs bijgewerkt werden. Lijst met de aanwezige kinderen per activiteit (dient als aanwezigheidslijst). Deelnemerslijst per activiteit met naam, leeftijd en telefoonnummer. Per activiteit moet een document afgedrukt kunnen worden met alle relevant informatie voor de begeleidende animatoren: start- en aankomstpunten, telefoonnummers en adressen van de verschillende deelactiviteiten, deelnemers aan de activiteit met contactgegevens ouders en relevante medische gegevens, … Rapporten zoals bv een overzicht per leeftijdsgroep van het aantal deelnemers per activiteit, per dag, per tarief, per woonplaats, per leeftijd, per locatie, per wachtlijst.

III.4.3.9 Inschrijven a) via de webinterface Een dynamische gebruiksvriendelijke website waar de burger stap voor stap door de bestelling heen geleid wordt en waar de burger enkel de relevante keuzes gepresenteerd krijgt. Hier volgt een beschrijving van wat wij als een gebruiksvriendelijke interface zien voor de ouders. -

-

de toepassing weet dat de burger op de pagina gekomen is via www.zwijndrecht.be en dat de burger daar al gekozen heeft om zijn kinderen in te schrijven voor een activiteit Ouders moeten activiteiten kunnen filteren op: type (jeugd, sport, cultuur, kinderopvang), leeftijd, vakantie-/niet vakantieaanbod, datum,... Toon een keuzescherm met een lijst met kinderen voor het gezin Na keuze van een kind komt er een lijst met activiteiten waarop ingeschreven kan worden en waarvoor het kind in aanmerking komt op basis van zijn leeftijdsgroep. Indien het kind reeds ingeschreven is voor een activiteit dan kan de klant niet per ongeluk een 2e keer inschrijven voor die activiteit. Controleren of de kinderen die voor kinderopvang zijn ingeschreven een schriftelijke overeenkomst hebben ondertekend aan de Vrijetijdsbalie (verplicht door K&G). Na keuze van het type activiteit komen de controles: o zijn er nog openstaande facturen? o Werd de medische info nog niet recent bevestigd (sinds 1 januari van het betrokken jaar), open dan het profiel van het kind en laat de medische info bevestigen door de ouder.  Optie: de inschrijver voorziet de mogelijkheid in de toepassing om de ouder de medische info met een digitale handtekening te laten ondertekenen. Extra controle inbouwen door melding wanneer men een persoon inschrijft voor 2 of meer activiteiten die op dezelfde data plaatsvinden (niet blokkeren: bv.. deelnemer omnisportkamp die één dag mee naar Efteling gaat) Na controles komen alle activiteiten met titel en kort beschrijving (kan opengeklikt worden met <<meer>> om de uitgebreide info te zien) gerangschikt volgens datum. Enkel de activiteiten voor de leeftijdsgroep van het kind zijn zichtbaar. Elke activiteit heeft een knop “voeg toe aan winkelwagentje” (zie algemene vereisten first in first served). Indien de activiteit reeds volgeboekt is kan de klant zichzelf toevoegen op de reservelijst. Wenst u nog een kind in te schrijven, zo ja ga terug naar de keuzelijst met kinderen en start de flow voor een volgend kind, anders ga naar het scherm om af te rekenen … Betaling via Ingenico

Blz. 40


PROVINCIE ANTWERPEN

Ref.: 481

b) Via de balie of telefonisch Als ouders hun kinderen via de balie willen inschrijven, of telefonisch, dan moet de beheerder alle nodige info op één scherm kunnen ingeven. Mogelijkheid behouden om per activiteit aantal plaatsen te reserveren voor offline verkoop. Het moet mogelijk zijn om per type activiteit een aantal van de plaatsen te reserveren voor offline verkoop op het inschrijvingsmoment. Na de eerste inschrijvingsdag moeten de niet verkocht plaatsen ook toegankelijk gesteld kunnen worden voor online verkoop, dit moet manueel gebeuren. (indien er via de online tool al mensen op de reservelijst terecht gekomen zijn dan moeten die eerst de kans krijgen om een nog beschikbare plaats te boeken, dit is een manuele controle door de beheerder, als daarna nog vrije plaatsen zijn moeten die online beschikbaar gesteld kunnen worden). c) Detail van de inschrijving Na het inschrijven, zij het online of via de balie krijgt de klant een afdrukbaar rapport, op dat rapport staat naast het detail van de bestelling ook een datum, tijdstip en een uniek bestelnummer. Voor betalingen via overschrijving staan daar ook de betalingsgegevens bij. Voor online inschrijvingen wordt datzelfde rapport ook naar het e-mailadres van de ouder opgestuurd. Net zoals elk rapport of ticket moet dit rapport eenvoudig door de beheerder opnieuw kunnen opgevraagd en afgedrukt worden.

III.4.3.10 Animatoren De animatoren zijn de begeleiders van de activiteiten. De toepassing moet contactgegevens kunnen bijhouden, en animatoren koppelen aan activiteiten. Naast de contactgegevens van de animatoren moet de toepassing de prestaties en de graad van de animatoren kunnen bijhouden zodat de gegevens nadien kunnen gebruikt worden voor het berekenen van hun vergoeding. Voor grabbelpasactiviteiten is dit in uren, voor het speelplein in dagen. Optioneel: de animatoren krijgen een vergoeding op basis van hun prestaties. Idealiter kan het programma dit ook bijhouden en op basis van de prestaties, de vergoeding voor een bepaalde tijdspanne berekenen.

III.4.3.11 Betalen De betaalmogelijkheden die mogelijk moeten zijn: - online - cash/bancontact - overschrijving (factuur vooraf/nadien) met automatische opvolging (koppeling New Horizon) voor wegwerken wachtlijsten, regioactiviteiten, kinderopvang, …

III.4.3.12 Kortingen De meeste / alle elementen uit het aanbod hebben kortingen voor vrijetijdspas en een sociaal tarief. In principe kunnen weten wie daarvoor in aanmerking komt en als we dat ingeven (klantendossier) dan zou het programma vanzelf de juiste prijs kunnen aanrekenen. D.w.z. Jaarlijkse controle inbouwen: is de vrijetijdspaskorting nog van toepassing?

III.4.3.13 Fiscale attesten Activiteiten met een maximumbedrag per dag per kind waaraan de kinderen hebben deelgenomen voor hun 12e verjaardag geven recht op een belastingvermindering. Het fiscaal attest is een document dat voor het gezin een overzicht geeft per kind van alle activiteiten waarvoor aan de voorwaarden werd voldaan en waaraan kinderen van dat gezin hebben deelgenomen.

Blz. 41


PROVINCIE ANTWERPEN

Ref.: 481

Fiscale attesten worden niet ter beschikking gesteld aan ouders die nog openstaande facturen hebben. Het bestuur zelf dient de controle te behouden wanneer de fiscale attesten verdeeld zullen worden. De burger kan in zijn profiel aangeven om via de post of via mail te ontvangen. We moeten ook de mogelijkheid hebben om fiscale attesten via het programma op de website beschikbaar te stellen aan de klant. Extra optie: de mogelijkheid voorzien om attesten ziekenfonds online te laten afdrukken.

III.4.3.14 Verkoop van producten in de backoffice Multimove T-shirts, stappentellers, wandel- en fietsbrochures, fietsknooppuntenkaart, beurtenkaart speelpleinwerking, … Producten kunnen bij online verkoop niet worden meegegeven. De software moet kunnen registreren welke producten in de backoffice worden verkocht.

III.4.3.15 Annulering Bij een gedeeltelijke annulering met recht op terugbetaling (bv ziek met doktersbriefje) moet de deelnameprijs gedeeltelijk terugbetaald kunnen worden. Wie twee dagen ziek is in een activiteit van 5 dagen moet 2/5 van de prijs terugbetaald krijgen. D.w.z. dat ook het fiscaal attest in die zin moet worden aangepast.

III.4.3.16 Inschrijvingsbewijs Naast standaardinformatie (data, uur, plaats, meebrengen, bedrag, betaalwijze,…) dient de mogelijkheid te worden voorzien om zelf velden aan te maken en extra info mee te geven.

III.4.3.17 Boekhouding Koppeling met de gemeentelijke boekhouding New Horizon zodat ontvangsten van cash geld of betaling via bancontact in de boekhouding ingeboekt worden. Activiteiten moeten gekoppeld kunnen worden aan beleidsitems, rekeningnummers en actieplannen (BBC).

Blz. 42


PROVINCIE ANTWERPEN

Ref.: 481

III.4.4 Module 4: Speelpleinwerking III.4.4.1 Licenties Indien het systeem met licenties per gebruiker/connectie op de database werkt, dan zijn hier 4 gebruikers nodig, waarvan 2 simultaan.

III.4.4.2 Klanten Idem Module 3. Zelf als beheerder contact- en medische gegevens valideren is belangrijk (niet-digitale doelgroep).

III.4.4.3 Controles Idem module 3. Op het speelplein worden echter een 70-tal kinderen ingeschreven op 30 minuten tijd. Dus de gebruiker mag wel gewezen worden op de openstaande facturen, afwijkende leeftijd of nietgevalideerde contact- en medische gegevens maar dit mag een vlotte en efficiënte inschrijving niet belemmeren.

III.4.4.4 Klantenprofiel Het basisprofiel dient aangevuld te worden met enkele specifieke velden: Profiel module inschrijvingen * vetgedrukte velden staan in het basisprofiel Profiel volwassene: Veld Naam Voornaam Geboortedatum Geslacht Rijksregisternummer (RRNR) Hoofd adres (straat, huisnummer, bus, postcode, gemeente) 2de adres

Persoon Verplicht Verplicht Verplicht Verplicht Verplicht Domicilie adres, verplicht Verblijfadres (enkele indien verschillend van domicilieadres), niet verplicht Verplicht Verplicht, bij voorkeur gebruikerslogin van de toepassing Niet verplicht Niet verplicht In te vullen door beheerder en van toepassing voor hele gezin

Telefoon/GSM Email adres

Rekeningnummer Wijze van factureren post of email Sociaal tarief (OCMW, vrijetijdspas)

Voor de inschrijving van een kind graag extra info: Naam en voornaam kind Geboorteplaats Geboortedatum Geslacht Rijksregisternummer Persoonlijke GSM

Verplicht Verplicht Verplicht Verplicht Verplicht Niet verplicht Blz. 43


PROVINCIE ANTWERPEN

Persoonlijke e-mail Contactpersoon 1 (relatie met kind, naam, adres, tel/gsm) Contactpersoon 2 (relatie met kind, naam, adres, tel/gsm) -12 jarigen: fiscaal attest op naam van Naam school Medische fiche kind Naam, adres, telefoonnummer huisarts Naam, adres, telefoonnummer (privé + werk) van de persoon die in geval van ziekte of enig ander ongeval dient verwittigd te worden Ziekenfonds Bloedgroep Laatste inenting anti-tetanus (datum): Kan 25m zwemmen: ja/nee Mag alleen naar huis: ja/nee Nuttige medische info (bv.. allergieën, astma, epilepsie, adhd, …) Andere inlichtingen betreffende het karakter? 

Ref.: 481

Niet verplicht Niet verplicht Niet verplicht Verplicht Niet verplicht

Verplicht Verplicht


Profielen volwassene(n) + kind(eren) uit een zelfde gezin koppelen.

III.4.4.5 Input van activiteiten Idem module 3. Nadruk op kopiëren van activiteiten (naam, locatie, leeftijd,…).

III.4.4.6 Dossier Idem module 3.

III.4.4.7 Rapporten Idem module 3.

III.4.4.8 Inschrijvingen De toepassing moet het mogelijk maken om kinderen op het speelplein in en uit te schrijven. M.a.w. een werkwijze aanbieden om aan te duiden dat een kind op het speelplein is geweest, maar opgehaald werd en er dus niet meer is. Inschrijven voor het speelplein gebeurt enkel ter plaatse. Daarbij is snelheid en efficiënt van inschrijven belangrijk (het moet mogelijk zijn met 1 beheerder een 70-tal kinderen in te schrijven binnen de tijdsspanne van een half uur). Bij voorkeur een systeem met barcodes en scanners voorstellen. Daarbij moet het mogelijk zijn aan te geven welke betaalmethode gebruikt werd (cash of beurtenkaart). Indien een kind/ouder nog niet in de database zit, moet het mogelijk zijn een kind in te schrijven vanuit de backoffice. Beurtenkaarten worden ook verkocht op het speelplein. Idealiter kunnen de beurtenkaart én de inschrijving voor die dag idealiter in één digitaal winkelmandje, ook als het saldo van de vorige beurtenkaart reeds op was.

III.4.4.9 Betalen Er zijn voor het speelplein 3 betaalmogelijkheden op de locatie zelf:  Cash Blz. 44


PROVINCIE ANTWERPEN

Ref.: 481

 Beurtenkaart (enkel als product, of indien mogelijk met een saldo dat in het programma bijgehouden wordt)  Gratis via OCMW, dit systeem moet toelaten kinderen gratis in te schrijven. Dit op een manier waardoor het enkel in de backoffice zichtbaar is. Dit kan via beurtenkaarten, indien het systeem dan automatisch géén fiscaal attest bezorgt aan de ouders.

III.4.4.10 Kortingen Idem Module 3. Bijkomend: mensen voor wie het OCMW dit nodig acht, kunnen ook gratis gebruik maken van de speelpleinwerking.

III.4.4.11 Fiscale attesten Idem Module 3. Belangrijk voor het speelplein is dat mensen die via OCMW gratis gebruik maken van het speelplein daarvoor geen fiscale attesten ontvangen.

III.4.4.12 Verkoop van producten in de backoffice Speelpleinbeurtenkaart enkel online te verkopen indien het een saldo is dat digitaal bijgehouden wordt. Anders enkel backoffice.

III.4.4.13 Boekhouding Idem module 3.

III.4.4.14 Animatoren Berekening prestaties op basis van aantal dagen en/of soort attest.

Blz. 45


PROVINCIE ANTWERPEN

Ref.: 481

III.4.5 Module 5: Kinderopvang (verplichte optie) De toepassing moet het mogelijk maken om een aanwezigheidsbeheer van de kinderopvang te voeren en kinderen in de opvang zelf vlot in- of uit te schrijven. In de twee kinderopvang locaties moeten per kind de exacte begin- en einduren geregistreerd worden. Kinderopvang wordt in de vakantieperiodes mee in “het aanbod” van vrije tijd opgenomen omdat ouders tijdens schoolvakanties nood hebben aan opvang en eventueel kinderopvang gebruiken als er geen plaats meer is in speelpleinwerking of sportkampen e.d. De inschrijving gebeurt dan op dezelfde manier als voor de andere vrijetijdsactiviteiten. Specifieke vereisten: enkel voor kinderen die wonen of school lopen in Zwijndrecht, of waarvan minstens 1 ouder woont of werkt in Zwijndrecht. Tijdens het schooljaar hoeven kinderen niet vooraf in te schrijven voor kinderopvang. Dat is wel verplicht tijdens de vakantieperiodes (zie module 3). Tijdens het schooljaar Kinderen komen ‘s ochtends binnen. Op een zeer eenvoudige manier moet het kind in het systeem gevonden worden (er zijn immers 1000 actieve kinderen). Het kind krijgt een start uur (= uur van binnenkomen). Het eind uur van de ochtendopvang van dit kind wordt gekoppeld aan de school waar het kind naartoe gaat. Dit gebeurt automatisch. In de namiddag gebeurt hetzelfde: het start uur is gekoppeld aan de school waar het kind naartoe gaat. Het eind uur is het moment dat de ouder het kind komt halen. Tijdens de schoolvakanties Kinderen komen ‘s ochtends binnen. Er is een controle of het kind is ingeschreven voor de kinderopvang of een andere activiteit (zie module 3). Indien dat zo is, is er een tijdsregistratie. Ook ‘s middags kan het kind terugkomen van een activiteit (module 3) en wordt het kind geregistreerd in de opvang. Een aantal aandachtspunten - tijdsregistratie gebeurt per minuut. - Er zijn zes mogelijke start/eindmomenten per dag per kind (bv. Kind komt ‘s ochtends en ‘s middags, maar gaat op woensdagmiddag nog naar een externe activiteit en wordt dus even uitgeschreven en daarna terug ingeschreven). - Manueel aanpassen of het een schooldag of vakantiedag is. Dit moet per school kunnen aangepast worden (bv. Pedagogische studiedag (= vakantiedagtarief) van school 1, maar is een schooldag voor school 2). - afhankelijk van de dag (schooldag of vakantiedag) wordt het tarief bepaald en berekend. - elke tijdsregistratie moet overruled kunnen worden. - eind uur tijdens de ochtend (schooljaar) en start uur in de namiddag (schooljaar) staat per school standaard ingesteld. Dit start uur kan uiteraard in de backoffice gewijzigd worden.


III.4.5.2 Klantenprofiel Het basisprofiel dient aangevuld te worden met enkele specifieke velden: Profiel module inschrijvingen * vetgedrukte velden staan in het basisprofiel Profiel volwassene:

Blz. 46


PROVINCIE ANTWERPEN

Veld Naam Voornaam Geboortedatum Geslacht Rijksregisternummer (RRNR) Hoofd adres (straat, huisnummer, bus, postcode, gemeente) 2de adres

Telefoon/GSM Email adres

Rekeningnummer Wijze van factureren post of email Sociaal tarief (OCMW, vrijetijdspas)

Persoon Verplicht Verplicht Verplicht Verplicht Verplicht Domicilie adres, verplicht Verblijfadres (enkele indien verschillend van domicilieadres), niet verplicht Verplicht Verplicht, bij voorkeur gebruikerslogin van de toepassing Niet verplicht Niet verplicht In te vullen door beheerder en van toepassing voor hele gezin

Voor de inschrijving van een kind graag extra info: Naam en voornaam kind Verplicht Geboorteplaats Verplicht Geboortedatum Verplicht Geslacht Verplicht Rijksregisternummer Verplicht Persoonlijke GSM Niet verplicht Persoonlijke e-mail Niet verplicht Contactpersoon 1 (relatie met kind, naam, Niet verplicht adres, tel/gsm) Contactpersoon 2 (relatie met kind, naam, Niet verplicht adres, tel/gsm) -12 jarigen: fiscaal attest op naam van Verplicht Naam school Verplicht Medische fiche kind Naam, adres, telefoonnummer huisarts Naam, adres, telefoonnummer (privé + werk) van de persoon die in geval van ziekte of enig ander ongeval dient verwittigd te worden Ziekenfonds Bloedgroep Laatste inenting anti-tetanus (datum): Kan 25m zwemmen: ja/nee Mag alleen naar huis: ja/nee Nuttige medische info (bv.. allergieën, astma, epilepsie, adhd, …) Andere inlichtingen of bemerkingen betreffende het karakter?  

Verplicht Verplicht


Profielen volwassene(n) + kind(eren) uit een zelfde gezin koppelen. Aan de Vrijetijdsbalie melden dat het medisch profiel is aangepast.

Blz. 47

Ref.: 481


PROVINCIE ANTWERPEN

Ref.: 481

III.4.5.3 Klanten a) Volwassenen: De klanten zijn de ouders die hun kind willen inschrijven in een activiteit. Het is belangrijk dat de toepassing gezin georiënteerd is. D.w.z. dat een ouder een overzicht houdt op zijn/haar kinderen en dus kinderen moet kunnen toevoegen aan zijn/haar profiel. Verder is het ook belangrijk bij het afdrukken van de fiscale attesten dat een ouder een attest krijgt voor alle kinderen samen. De toepassing houdt uiteraard rekening met de “moderne” gezinssituaties bv. kinderen van gescheiden ouders kunnen een deel van de vakantie bij de vader en een deel bij de moeder zijn. Voor deze toepassing is het belangrijk om naast het basisprofiel van de gebruiker nog bijkomende info bij te houden. b) Kinderen: Extra info die bijgehouden moet worden naast het basisprofiel: Leeftijdsgroep (veld = geboortedatum): programma moet rekening houden met het geboortejaar van de kinderen zodat ze niet per ongeluk ingeschreven kunnen worden in een activiteit die niet voor hen bedoeld is. De beheerder kan het veld ‘geboortejaar’ aanpassen op vraag van de ouder (veld kan niet per activiteit gekozen worden, eenmaal een keuze gemaakt is dit van invloed op alle activiteiten waarvoor de ouder een kind kan inschrijven). Medische info (= een vragenlijst met o.a. Contactgegevens van huisdokter) moet bijgehouden kunnen worden. De medische gegevens moeten jaarlijks bevestigd worden en de datum van de laatste bevestiging moet bijgehouden worden (het is belangrijk dat de toepassing een waarschuwing kan geven indien de medische info van een kind werd bijgewerkt). Kinderen kunnen niet ingeschreven worden voor activiteiten als de medische info niet recent bevestigd werd. Indien de bevestiging nog niet ontvangen werd dan moet de klant bij voorkeur naar het scherm geleid worden waar hij de medische info kan bevestigen. De info moet ook up-to-date kunnen gemaakt worden door de backoffice. Het is ook belangrijk om enkele extra telefoonnummers te kunnen toevoegen zoals gsm moeder en vader, telefoonnummer waarop iemand van de familie te bereiken is in geval van nood. Aangezien deze info naar alle waarschijnlijkheid voor alle kinderen van eenzelfde gezin dezelfde zal zijn, kan deze info misschien in het profiel van de ouder terecht komen. Er moet ook een vrij tekstveld aan het profiel kunnen toegevoegd worden waar informatie voor intern gebruik aan kan toegevoegd worden. Eveneens belangrijk is dat kinderen die in de opvang zijn ingeschreven een schriftelijke overeenkomst hebben ondertekend (=verplicht van K&G).

Blz. 48


PROVINCIE ANTWERPEN

Ref.: 481

III.4.5.4 Controles De leeftijdsgroep van de kinderen komt overeen met de activiteit, kinderen kunnen niet inschrijven voor activiteiten die niet voor hun leeftijdsgroep bedoeld zijn. Dit moet kunnen overruled worden in backoffice (bv.. voor zittenblijvers). Er moet bijgehouden worden of er nog openstaande facturen zijn. Indien er nog openstaande facturen zijn moet de mogelijkheid bestaan om nieuwe inschrijvingen niet toe te staan. Er mag echter geen koppeling zijn tussen de registratie Speelpleinwerking en controle op onbetaalde facturen. - De controle moet melden aan de klant dat er nog openstaande facturen zijn en dat die eerst betaald moeten worden voordat de ouder kan inschrijven; de ouder kan geen bestelling ingeven. - De controle op openstaande facturen moet afgezet kunnen worden. Zoals bij elke input moet de beheerder de controle kunnen negeren, maar het systeem moet de beheerder er wel attent op maken dat hij iets probeert in te geven wat niet voorzien is. Is de activiteit volgeboekt dan moet de klant de mogelijkheid krijgen om zich toe te voegen op de wachtlijst.

III.4.5.5 Dossiers Voor Kinderopvang is het belangrijk dat de ouders een (online)“dossier” hebben. Belangrijk zijn : contactinformatie – ruimer dan officieel adres : ouders en/of andere contactpersonen moeten, bv. bij ongeval, …., kunnen verwittigd worden (ook op hun werk, …). Bij de aanmaak van een nieuw dossier aan de ouders melden dat ze contact moeten opnemen met de Vrijetijdbalie. Daarnaast zijn er voor kinderopvang dossiers nodig voor de kinderen, met een aantal verplichte gegevens zoals bloedgroep, wie mag de kinderen ophalen, enz. die door Kind & Gezin en gezin worden opgelegd. Tot slot zijn er nog paramaters die betrekking hebben op de gezinssituatie die van belang zijn (werk van ouders, alleenstaande ouder, …)

III.4.5.6 Inschrijvingen De toepassing moet het mogelijk maken om kinderen in de kinderopvang (in- en uit) te registreren, zonder in het systeem daarvoor verschillende activiteiten te moeten voor aanmaken. M.a.w. een werkwijze aanbieden om aan te duiden dat een kind in de buitenschoolse kinderopvang is geweest, maar opgehaald werd en er dus niet meer is. Inschrijven voor de buitenschoolse kinderopvang gebeurt enkel ter plaatse. Daarbij is snelheid en efficiëntie van inschrijven belangrijk.

III.4.5.7 Betalen en facturatie De betaalmogelijkheid voor de kinderopvang is enkel via facturatie nadien. Er moet tevens de mogelijkheid bestaan om correcties in de facturen te kunnen aanbrengen. Extra kosten (boetes) moeten manueel kunnen worden toegevoegd. Het moet mogelijk zijn om maandelijkse facturen met een zeer laag facturatiebedrag 3 maanden te laten opsparen en dan in totaliteit te laten betalen.

Blz. 49


PROVINCIE ANTWERPEN

Ref.: 481

Het moet mogelijk zijn om éénzelfde kind op 2 facturatieadressen (=nieuw samengesteld gezin) in te schrijven, zodat er 2 facturen en fiscale attesten kunnen worden afgeleverd. Op de factuur moet het volgende vermeld worden: - de naam van het gezin - per kind een overzicht van de aanwezige dagen en het dagbedrag - per kind een totaalbedrag - per gezin een totaalbedrag - eventuele korting.

III.4.5.8 Tarieven en kortingen De tarieven tijdens het schooljaar zijn verschillend van deze tijdens de vakantieperiodes. De berekening van de tarieven gebeurt tijdens het schooljaar per begonnen half uur en tijdens de schoolvakanties per blok van uren, m.n. drie tarieven, afhankelijk van de duurtijd van de aanwezigheid van het kind (minder dan 3u, tussen 3 en 6u, meer dan 6u). Alle elementen uit het aanbod hebben kortingen voor vrijetijdspas en een sociaal tarief. In principe kunnen we weten wie daarvoor in aanmerking komt en als we dat ingeven klantendossier) dan zou het programma vanzelf de juiste prijs kunnen aanrekenen. Typische voorbeelden:  50% bij sociaal tarief  Voor 2 of meerdere kinderen die tegelijkertijd in de opvang verblijven, geldt een korting van 25%  Beide kortingen zijn cumuleerbaar.

III.4.5.9 Fiscale attesten Activiteiten met een maximumbedrag per dag per kind waaraan de kinderen hebben deelgenomen voor hun 12e verjaardag geven recht op een belastingvermindering. Het fiscaal attest is een document dat voor het gezin een overzicht geeft per kind van alle activiteiten waarvoor aan de voorwaarden werd voldaan en waaraan kinderen van dat gezin hebben deelgenomen. Fiscale attesten worden niet ter beschikking gesteld aan ouders die nog openstaande facturen hebben. Het bestuur zelf dient de controle te behouden wanneer de fiscale attesten verdeeld zullen worden. De burger kan in zijn profiel aangeven om via de post of via mail te ontvangen. We moeten ook de mogelijkheid hebben om fiscale attesten via het programma op de website beschikbaar te stellen aan de klant. Extra optie: de mogelijkheid voorzien om attesten ziekenfonds online te laten afdrukken.

III.4.5.10 Rapporten Per kwartaal en jaarlijks moeten er rapporten per locatie of in globo opgemaakt worden. Daarnaast stelt Kind & Gezin bepaalde parameters voorop die moeten ingevuld worden op voorziene sjablonen (zie bijlage). Alle data die in de software is geregistreerd wordt, moet vlot in allerlei rapporten kunnen worden opgemaakt. Bijvoorbeeld: - aantal kinderen per half uur/per dag/per maand/per kwartaal/jaar/ per gekozen periode - aantal actieve, non-actieve en gearchiveerde kinderen per maand/per kwartaal /per jaar - aantal nieuw ingeschreven kinderen per maand/per jaar - aantal gezinnen

Blz. 50


PROVINCIE ANTWERPEN

Ref.: 481

- aantal alleenstaande ouders - een aanwezigheidsoverzicht per kind per maand - een overzicht per dag/week/maand/kwartaal van het aantal kinderen dat minder dan 3 uur, tussen 3 en 6 uur en meer dan 6 uren aanwezig is. -…

III.4.5.11 Boekhouding Koppeling met de gemeentelijke boekhouding New Horizon zodat ontvangsten in de boekhouding ingeboekt worden.

Blz. 51


PROVINCIE ANTWERPEN

Ref.: 481

III.4.6 Module 6: Ticketverkoop (verplichte optie) Met het ticketverkoopprogramma moet het mogelijk zijn om allerhande activiteiten zoals voorstellingen, cursussen …te beheren. Het ingeven van de details van de activiteit, het beheer van de beschikbare plaatsen, enz. Ook hier is het de bedoeling om een gebruiksvriendelijke online tool te voorzien voor onze klanten via de website en een efficiënte interface voor de beheerders .

III.4.6.1 Licenties Indien het systeem met licenties per gebruiker /connectie op de database werkt dan zijn hier 7 gebruikers waarvan 3 simultaan.

III.4.6.2 Gebruikersprofiel Voor de burger moet het aanmelden in deze module eenvoudig en gebruiksvriendelijk zijn. Klanten hebben geen gebruikersnaam of paswoord nodig en voor het bestellen van tickets volstaat het emailadres.

III.4.6.3 Voorstellingen Een voorstelling bestaat uit een titel, een kort en lange beschrijving, foto, doelgroep, genre voorstelling ( voordracht, muziek, humor, … ), datum & tijd, locatie …Ingeven van een voorstelling moet vlot gaan. Het moet mogelijk zijn om identieke of gelijkaardige voorstellingen te kopiëren en niet helemaal opnieuw te moeten ingegeven. Er moet kunnen meegegeven worden vanaf wanneer er tickets voor de voorstelling kunnen verkocht worden, dit kan verschillend zijn afhankelijk van het kanaal van de verkoop, bv. online verkoop start vroeger dan balieverkoop. a) Genre (optioneel) Genre van de voorstelling moet ingegeven kunnen worden, zo kan je later zoeken op een specifieke soort voorstelling. Mogelijke genres zouden kunnen zijn : muziek, dans, comedy, film, voordracht, opleiding, … b) Types van voorstellingen -

Voorstelling op datum en uur met genummerde plaatsen (zaalplan) Voorstelling op datum en uur met ongenummerde plaatsen Workshops of cursussen met een beperkt aantal plaatsen o Dit type activiteit kan eenmalig doorgaan o Dit type activiteit kan gespreid zijn over een aantal sessies ( bv. een half jaar lang elke maandagavond )

c) Optioneel : koppeling Cultuurnet Vlaanderen Alle gegevens die de voorstelling beschrijven worden ingegeven in de ticket toepassing, het zou handig zijn mochten deze gegevens dan eenvoudig kunnen geëxporteerd worden naar de website www.uitinvlaanderen.be van Cultuurnet Vlaanderen zodat dubbele invoer van gegevens wordt vermeden.

III.4.6.4 Tarieven & kortingen a) Tarieven Veel voorstellingen zullen dezelfde tariefstructuur hebben. Verschillende tariefstructuren moeten eenvoudig ingegeven kunnen worden en aan een voorstelling gekoppeld kunnen worden. -

Zo zijn er tarieven per leeftijdscategorie ( -26, +60 ) Blz. 52


PROVINCIE ANTWERPEN

Ref.: 481

Tarief voorverkoop of verkoop aan kassa Tarieven voor houders van een studentenkaart Volumeverkoop ( bv. vanaf 10 tickets voor zelfde voorstelling ) geeft recht op korting Het in een bestelling ingeven van tickets voor minimaal 5 verschillende voorstelling kopen geeft recht op korting ( = abonnement ). …

De mogelijkheid moet bestaan om aan een tarief een specifiek ticketsjabloon te koppelen (andere layout of informatie op het ticket, bv. bij studentenkaart de melding dat op aanvraag de studentenkaart moet getoond worden aan de ingang, … ). b) Kortingen Kortingen moeten in absolute waarde ingegeven kunnen worden, indien percentuele input ook mogelijk is, is dat mooi meegenomen.

III.4.6.5 Extra kosten Vandaag worden geen extra kosten aangerekend aan de burger, maar dat kan in de toekomst veranderen. De inschrijver geeft aan of het via zijn toepassing mogelijk is om extra kosten aan te rekenen. -

Bv. verzendingskost bij opsturen van tickets Reserveringskosten o Bv. afhankelijk van kanaal ( balie, online, telefonisch, … ) o Per ticket / of globaal op de bestelling o Afhankelijk van betaalwijze o Afdrukken van een duplicaat van een ticket o …

III.4.6.6 Betalen Tickets kunnen online (Ingenico), aan de balie cash (bancontact), via overschrijving of mastercard of via visa betaald worden. Bij een overschrijving geldt dat de plaatsen gedurende een periode gereserveerd zijn en dat de plaatsen pas definitief zijn nadat het bedrag overgeschreven werd. Bij niet betaling binnen de termijn kunnen de plaatsen terug vrijgegeven worden voor verkoop aan een andere klant (dit mag niet automatisch gebeuren).

III.4.6.7 Verkoop Bij voorverkoop aan de balie of telefoon worden de tickets geregistreerd op naam. Ook bij online verkoop moeten de tickets op naam geregistreerd worden. De burger ziet het aanbod op de gemeentelijke website. Als hij een of meerdere tickets wenst, moet hij zich aanmelden. Tickets kunnen aan een mandje toegevoegd worden en daarna kunnen ze afrekenen. Het moet mogelijk zijn om meerdere tickets in een bestelling in te voeren (winkelkarretje). De klant moet gemakkelijk de activiteit kunnen vinden waarvoor hij een ticket wil. Hij moet bij voorkeur kunnen zoeken op categorie (concert, film, tentoonstelling, workshop of cursus), op datum (exacte datum of per periode) en via de zoekfunctie. Bij avondverkoop of verkoop aan de kassa moeten tickets zeer snel kunnen verkocht worden. Tickets moeten dan niet op naam geregistreerd worden. Het verkoopscherm bevat bij voorkeur enkel een lijst van de voorstellingen van die dag/avond, betalingswijze is enkel cash, tarief verkoop aan de kassa en er kan nog gekozen worden voor een korting (-26, 60+, studentenkaart, …) en het aantal tickets. Tickets worden gelogd in de applicatie onder verkoop aan de kassa.

Blz. 53


PROVINCIE ANTWERPEN

Ref.: 481

III.4.6.8 Wachtlijst Als een voorstelling volzet is moet het mogelijk zijn om op een wachtlijst terecht te komen. Via de rapporteringsmodule moet het eenvoudig zijn om een rapport te maken van alle klanten die op een wachtlijst staan voor een met hun contactgegevens zodat die snel kunnen gecontacteerd worden om te zien of ze nog interesse hebben in eventueel vrijgekomen plaatsen voor de voorstelling. De rapporteringstool moet ook een lijst kunnen maken van voorstellingen met vrije plaatsen en personen op een wachtlijst. Personen die geen interesse meer hebben, moeten eenvoudig uit de wachtlijst geschrapt kunnen worden.

III.4.6.9 Afdrukken van tickets Tickets kunnen pas afgedrukt worden als de betaling bevestigd werd. Verschillende statussen van het ticket moeten bijgehouden kunnen worden, bv. gereserveerd, betaald, afgedrukt, … Het moet mogelijk zijn om in 1x alle betaalde maar nog niet afgedrukte tickets voor een voorstelling af te drukken. In bulk afdrukken van resterende, niet-verkochte tickets. Er moet een maximum aantal kunnen opgegeven worden (bv. er zijn nog 40 vrije plaatsen, maar we wensen slechts 20 tickets af te drukken), er staat geen naam op de tickets (bv. enkel vermelding avondverkoop) er staat geen prijs op de tickets (tickets worden niet naar de boekhouding doorgestuurd) en de tickets worden zo gelogd in het systeem zodat ze duidelijk onderscheiden kunnen worden van verkochte tickets. Deze tickets worden dan aan de organiserende partner afgegeven die ze dan kan verkopen op de avond zelf, zonder dat ze toegang hebben tot het ticketsysteem. Het moet mogelijk zijn om de lay-out van de tickets aan te passen. Naast vaste tekst, lijnen en afbeeldingen moet het ook mogelijk zijn om variabele tekst af te drukken op de tickets ( de variabele velden bevatten informatie uit het ticketprogramma zoals naam evenement, naam organisatie, naam klant, uniek ticketnummer, machinaal leesbare codes (barcode, qr code, …), datum en tijdstip evenement, locatie, zaal, bij genummerde tickets ook rij , stoel, … a) Klassieke tickets Tickets moeten op de (ticket)printer afgedrukt kunnen worden. b) E-tickets De mogelijkheid om de burger zelf zijn tickets thuis te laten afdrukken (burger krijgt na betaling zijn tickets via e-mail of kan ze downloaden vanuit de toepassing zelf). Belangrijk verschil is dat als we met e-tickets werken het belangrijk wordt om de tickets te controleren. De inschrijver geeft aan hoe die controle kan gebeuren en welke kosten daarmee gepaard gaan. Bv. stel een systeem met barcodes en scanner: de inschrijver geeft op hoeveel het kost om een scannersysteem aan te schaffen die ook offline kan gebruikt worden en waarbij meerdere scanners gelijktijdig kunnen ingezet worden. De inschrijver geeft prijs op voor 2 scanners en wat de kostprijs van een bijkomende scanner is. Het scannen van barcodes en QR-codes op tablet of smartphones behoort tot de mogelijkheden.

III.4.6.10 Zaalplan De toepassing moet het mogelijk maken om zelf waarheidsgetrouw zaalplannen aan te maken. Bij online verkoop moet het zaalplan ook afgebeeld worden op de website en moet de klant zelf zijn plaats in de zaal kunnen kiezen. De toepassing moet wel een aantal restricties op kunnen leggen aan de klant. Zo mag het niet mogelijk zijn om 1 vrije plaats tussen stoeltjes te laten maar bv minimaal 2, bepaalde plaatsen moeten ook geblokkeerd of bezet kunnen worden (bv. voor technische apparatuur, plaatsen voor rolstoelgebruikers, …). Met een kleurencode moet duidelijk zijn welke plaatsen vrij zijn, welke al bezet zijn, welke plaatsen niet beschikbaar zijn (bv. ingenomen door technische installaties, … ), plaatsen gereserveerd voor

Blz. 54


PROVINCIE ANTWERPEN

Ref.: 481

rolstoelgebruikers… De niet beschikbare of geblokkeerde plaatsen moeten per voorstelling gewijzigd kunnen worden. Het zaalplan met de bezetting moet ook afgedrukt kunnen worden. Optioneel: indien een klant nadien zijn genummerde plaats willen ruilen voor een andere plaats dan moet dat eenvoudig in het systeem ingevoerd kunnen worden zonder dat het ticket geannuleerd dient te worden en een nieuwe verkoop dient ingeleid te worden.

III.4.6.11 Rapporten Bij voorkeur kunnen rapporten zelf aangemaakt worden, zeker moet volgende info kunnen geconsulteerd worden: -

-

overzicht van de verkopen ( per voorstelling, per organisator, per prijsklasse, per verkoop kanaal, per betaalmethode, voor voorstellingen tussen start en einddatum, … ) o bv. geef een overzicht van alle abonnementen die dit seizoen werden verkocht. o geef voor voorstelling X een overzicht van de verkochte tickets per prijscategorie. o geef voor deze maand een overzicht van de voorstellingen met daarbij het aantal verkochte tickets vergeleken met de capaciteit van de voorstelling. o Geef het percentage online verkoop voor de periode, voor voorstelling, … # Tickets verkocht, gereserveerd, nog beschikbaar o Bv. geef een overzicht van alle gereserveerde maar nog niet betaalde tickets + aantal dagen dat het ticket gereserveerd werd. Kassarapport per dag, per periode, per verkoper Zaalplan met een duidelijk beeld van de bezetting …

III.4.6.12 Opties Het zou handig zijn als de plaatsen voor rolstoelgebruikers ook via de website zouden kunnen gereserveerd worden. En dat duidelijk zichtbaar is hoeveel plaatsen voor rolstoelgebruikers moeten klaargezet worden op het ogenblik van een voorstelling. Het zou handig zijn als er een stand-alone versie beschikbaar zou zijn voor avondverkoop voor het geval de internetverbinding zou wegvallen of voor verkoop van tickets op een plaats waar geen internetverbinding beschikbaar is.

III.4.6.13 Boekhouding Koppeling met de gemeentelijke boekhouding New Horizon (firma Cevi) zodat ontvangsten in de boekhouding ingeboekt worden op diverse codes.

Blz. 55


PROVINCIE ANTWERPEN

Ref.: 481

BIJLAGE A : OFFERTEFORMULIER PRIJSOFFERTE VOOR DE OPDRACHT MET ALS VOORWERP “SOFTWARE VRIJETIJDSDIENSTEN GEMEENTE ZWIJNDRECHT” Vereenvoudigde onderhandelingsprocedure met bekendmaking Belangrijk: dit formulier dient volledig te worden ingevuld en ondertekend door de inschrijver. Het totale offertebedrag moet zowel in cijfers als voluit geschreven worden opgegeven. Natuurlijke persoon Ondergetekende (naam en voornaam): Hoedanigheid of beroep: Nationaliteit: Woonplaats (volledig adres): Telefoon: GSM: Fax: E-mail: Contactpersoon: Ofwel (1) Rechtspersoon De vennootschap (benaming, rechtsvorm): Nationaliteit: met zetel te (volledig adres): Telefoon: GSM: Fax: E-mail: Contactpersoon: vertegenwoordigd door de ondergetekende(n): (De gemachtigden voegen bij hun offerte de authentieke of onderhandse akte waaruit hun bevoegdheid blijkt of een gewaarmerkt afschrift van hun volmacht; zij kunnen zich ook beperken tot een verwijzing naar het nr. van de bijlage van het Belgisch Staatsblad waarin hun bevoegdheden zijn bekendgemaakt.) Ofwel (1) Tijdelijke vereniging De ondergetekenden die zich tijdelijk hebben verenigd voor deze aanneming (naam, voornaam hoedanigheid nationaliteit, voorlopige zetel):

VERBINDT OF VERBINDEN ZICH TOT UITVOERING VAN DE AANNEMING OVEREENKOMSTIG DE BEPALINGEN EN VOORWAARDEN VAN HET BESTEK VOOR BOVENGENOEMDE OVERHEIDSOPDRACHT: tegen de som van: (in cijfers, inclusief btw) ...................................................................................................................................................

Blz. 56


PROVINCIE ANTWERPEN

Ref.: 481

(in letters, inclusief btw) ................................................................................................................................................... ................................................................................................................................................... Onderaannemers Er zullen onderaannemers worden aangewend: JA / NEE (doorhalen wat niet van toepassing is)

Personeel Er wordt personeel tewerkgesteld dat onderworpen is aan de sociale zekerheidswetgeving van een andere lidstaat van de Europese Unie: JA / NEE (doorhalen wat niet van toepassing is) Het betreft volgende EU-lidstaat:

Betalingen De betalingen zullen geldig worden uitgevoerd door overschrijving op volgende rekening (IBAN/BIC) ................................................ van de financiële instelling ................................. geopend op naam van ................................. .

Bij de offerte te voegen documenten Bij deze offerte zijn eveneens gevoegd: - de gedateerde en ondertekende documenten, die het bestek verplicht over te leggen; - de modellen, monsters en andere inlichtingen, die het bestek verplicht over te leggen.

Gedaan te ..................................................................................................................................... De ................................................................................................................................................ De inschrijver,

Handtekening: ............................................................................................................................... Naam en voornaam: ....................................................................................................................... Functie: ......................................................................................................................................... Belangrijke nota Er mag geen beroep worden aangetekend tegen mogelijke vormgebreken, fouten of leemten (artikel 87 van het koninklijk besluit van 15 juli 2011).

(1) Doorhalen wat niet van toepassing is

Blz. 57


PROVINCIE ANTWERPEN

Ref.: 481

BIJLAGE B : ANTWOORDFORMULIER Toelichting en voorbeeld De verschillende offertes zullen vergeleken worden aan de hand van dit inschrijvingsformulier. Er zijn 3 antwoordvakjes, Ja, Nee of Optie. Voorbeeld Voor een systeem waar er per aangemaakte beheerderslogin een licentiekost moet betaald worden zou als volgt ingevuld kunnen worden: Beheerders

Ja

Nee

het aantal beheerderslogins heeft geen invloed op de kostprijs aantal beheerders is onbeperkt, maar er moet een licentie betaald worden per aantal simultane sessies er moet een licentiekost betaald worden per beheerderslogin optie: kostprijs per bijkomende licentie (indien van toepassing )

Optie

X X X 100€/jaar

De inschrijver mag verwijzen naar bijlages als hij oordeelt dat verduidelijking noodzakelijk is. Er moet wel een duidelijke referentie gemaakt worden zodat we de relevante info kunnen terugvinden. Als een bepaalde optioneel gevraagde functionaliteit inbegrepen zit in het basispakket dan moet daarvoor geen optionele prijs opgeven, vb. Grafische interface optie: de toepassing volgt het responsive design van www.zwijndrecht.be

Ja

Nee

Optie

X

Vragen III.3. Gemeenschappelijk voor alle toepassingen III.3.1. Aanmelden Ja slechts één login voor de klant voor afhandelen van zaken met www.zwijndrecht.be optie: secure single sign on registratie klant via www.zwijndrecht.be in 2 stappen met email bevestiging controle paswoord complexiteit mogelijkheid tot koppeling van de software met een toekomstig klantensysteem optie: bij registratie nieuwe klant mogelijkheid voorzien om gegevens van e-id in te lezen

Blz. 58

Nee

Optie


PROVINCIE ANTWERPEN

Ref.: 481

indien koppeling mogelijk: toelichting

III.3.2. Gebruikers & beheerders Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

opslaan van het "basisprofiel" van de klant in www.zwijndrecht.be opslaan van het volledige klantenprofiel in www.zwijndrecht.be online en offline klanten kunnen met de toepassing worden beheerd. klant kan eigen profiel bijwerken aanmaak dubbele klantenprofielen niet toelaten klantenprofiel met vrije en verplichte velden beheerders hebben een uniek login beheerders krijgen rechten op basis van een of meerdere rollen beheerders kunnen elk veld in een aanvraag aanpassen het aantal beheerderslogins heeft geen invloed op de kostprijs aantal beheerders is onbeperkt, maar er moet een licentie betaald worden per aantal simultane sessies er moet een licentiekost betaald worden per beheerderslogin optie: kostprijs per bijkomende licentie (indien van toepassing )

III.3.3. Online en real time de beschikbaarheid tonen de actuele bezettingsgraad van de modules is zichtbaar door raadpleging via de website

III.3.4. Winkelkarretje klanten kunnen meerdere items bestellen en toevoegen aan een virtueel winkelkarretje

III.3.5. First in- first served items kunnen toevoegen aan winkelkarretje = garantie dat het beschikbaar is. vrijgeven van vastgehouden items na problemen met de sessie

Blz. 59


PROVINCIE ANTWERPEN

Ref.: 481

III.3.6. Gegevensvalidatie Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

waar mogelijk worden de ingegeven data gevalideerd

III.3.7. Koppelingen periodieke export van alle data koppelingen via periodieke import/export gegevens koppelingen via API of webservice integratie gemeentelijke website www.zwijndrecht.be koppeling software financiële dienst benodigde certificaten kunnen voorgelegd worden optie: gegevensuitwisseling volgens de oslo standaard voor openbare besturen optie: bulk import tool

III.3.8. Grafische interface, gebruiksvriendelijkheid & integratie website grafische interface past in de gemeentelijke website, toepassing is vindbaar in de navigatiestructuur van www.zwijndrecht.be eenvoudige overzichtelijke webinterface voor de klanten klanteninterface is conform de anysurfer aanbevelingen eventueel toe te voegen: bijlage met afwijkingen van de anysurfer aanbevelingen voeg in bijlage materiaal toe die ons helpt om de GUI en gebruiksvriendelijkheid te kunnen beoordelen optie: de toepassing volgt het responsive design van www.zwijndrecht.be

III.3.9. Historiek historiek van communicatie met de klant wordt bijgehouden application logging optie: klanten kunnen historiek van bestellingen opvragen

Blz. 60


PROVINCIE ANTWERPEN

Ref.: 481

III.3.10. Rapportering Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

alles wat in de database zit kan in een rapport weergegeven worden de toepassing bezit een rapporteringsmodule waarbij complexe rapporten zelf gedefinieerd kunnen worden rapporten kunnen op vraag aangemaakt worden, aanmaak van bijkomende rapporten zit inbegrepen in het jaarlijkse onderhoudscontract. Is het aantal rapporten gelimiteerd (vermelding van aantal)? rapporten kunnen op vraag aangemaakt worden en worden afzonderlijk aangerekend rapporten kunnen in verschillende bruikbare formaten geëxporteerd worden ( excel, word, pdf, …) optie: dashboard functie optie: marketing e-mails

III.3.11. Afdrukken afdrukken in tweevoud afdrukken van printopdrachten in batch opnieuw afdrukken/aanmaken van verloren documenten/bestanden

printer vereisten ( lokaal, netwerk, verschillende printers en lades, … )

III.3.12. Beheer & administratieve afhandeling efficiënte beheerdersinterface snelverkoop efficiënte invoermethode reservelijsten annuleren

Geef een beeld van hoe de gebruikersinterface georganiseerd is

Blz. 61


PROVINCIE ANTWERPEN

Ref.: 481

III.3.13. Betalen Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

verschillende betaalmogelijkheden per type item of voorstelling instelbaar en/of verkoopskanaal instelbaar (cash, facturatie met overschrijving, online betalen, beurtenkaart) kassaverkoop; koppeling met pakket van de boekhouding (New Horizon) facturatie; idem facturatie vooraf; idem facturatie nadien; idem cash betalen van een factuur aan de balie; idem online betaling vermelden of er extra kosten zijn verbonden aan een online betaalsysteem voorzien van een koppeling tussen Ingenico en de webtoepassing

III.3.14. Fiscale attesten fiscale attesten voor vakantieaanbod, speelpleinwerking en buitenschoolse kinderopvang voor kinderen jonger dan 12 jaar attesten kunnen samengevoegd worden tot één centraal attest op naam van het gezin/kind mogelijkheid voorzien dat de klant zelf een attest kan downloaden en afprinten geen fiscaal attest voor wanbetalers

III.3.15. Voorwaardelijke inschrijving mogelijkheid om te bestelling, in te schrijven, … kan gekoppeld worden aan één of meerdere voorwaarden optioneel: koppeling met de boekhouding om openstaande facturen bij alle gemeentelijke diensten als voorwaarde te kunnen koppelen

III.3.16. Zelf content toevoegen Op een eenvoudige manier content kunnen toevoegen aan de toepassing

Blz. 62


PROVINCIE ANTWERPEN

Ref.: 481

III.3.17. Technische beschrijving van de oplossing Beschrijf de door u aangeboden oplossing op vlak van IT: welke architectuur wordt er gebruikt, van welke netwerkprotocollen wordt er gebruik gemaakt, enz.

III.3.18. Technologie Ja

Nee

Optie

Ja

Nee

Optie

Is de toepassing web-based?

Op welke besturingssystemen en/of browsers werkt de toepassing? Licht toe waar de toepassing voldoet aan de anysurfervereisten

III.3.19. Hosting Bestaat de mogelijkheid om de technologie te laten hosten door de leverancier, beheerd door de inschrijver en dus niet op de serverinfrastructuur van de gemeente?

III.3.20. Congestion protection Bij grote inschrijfmomenten zal de webtoepassing extra belast worden. De leverancier omschrijft hier welke maatregelen hij zal treffen om met een dergelijke piekbelasting om te gaan.

III.3.21. Beveiliging en informatieveiligheid Welke securitymechanismen gebruikt de inschrijver voor het beveiligen van de website en gegevens tegen ongeoorloofde toegang van derden? Licht bondig de backup- en recoverystrategie toe

Blz. 63


PROVINCIE ANTWERPEN

Ref.: 481

III.3.22. Licenties Beschrijf hier de licentiepolitiek van uw bedrijf

III.3.23. Toekomstbestendigheid en Interoperabiliteit Indien we als bestuur beslissen om naar een nieuwe leverancier over te stappen, willen we data uit jullie toepassing (bv. accountgegevens) overzetten. Beschrijf hier in welke vorm wij deze data zullen aangeleverd krijgen.

III.3.24. Conversie van data uit de vorige toepassing Waarschijnlijk willen we gegevens uit bestaande databases hergebruiken zoals Grabbis (vrijetijdsinschrijvingen) en Reinaert (Kinderopvang), waarbij we de relaties tussen verschillende tabellen (ouders, kinderen) willen behouden. Beschrijf hier op welke manier de leverancier zijn medewerking zal verlenen om deze conversie mogelijk te maken.

III.3.25. SLA, Support en onderhoud Licht hier uw support/onderhoud/SLA toe: wat zijn de interventietijden, welke SLA wordt er dus aangeboden, wat is de availability, welke vorm van ondersteuning mogen we verwachten op belangrijke inschrijvingsdagen, wat valt er juist onder het onderhoudscontract, …

Ja Optie: kan ook beroep gedaan worden op de helpdesk tijdens de inschrijvingsmomenten, dit is maximaal 5 per jaar?

Blz. 64

Nee

Optie


PROVINCIE ANTWERPEN

Ref.: 481

III.3.26. Plan van aanpak Beschrijf het implementatieproject voor de uitrol van de software, met een overzicht van de verschillende stappen

III.3.27. Testen Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

De toepassing wordt grondig getest voor ze wordt afgeleverd De gemeentediensten krijgen ook voldoende tijd om de toepassing uit te testen en er vertrouwd mee te geraken. We rekenen daar een maand voor per module. De inschrijver levert daarvoor een testplan af

III.3.28. Referenties in bijlage wordt een lijst met relevante referenties toegevoegd

III.3.29. Opleiding De offerte voorziet alle opleidingen die noodzakelijk zijn om met het pakket te kunnen werken. Dit mag opgesplitst zijn per module en per doelgroep (beheerders en gebruikers). Afleveren van documentatie en handleidingen in de Nederlandse taal.

III.3.30.Beëindiging van de samenwerking beschrijf hoe we verder kunnen blijven werken met de toepassing zonder support van de inschrijver.

III.4. Afzonderlijke modules III.4.1. Module 1: Zaalverhuur III.4.1.2. Zalen Mogelijkheid om bij elke zaal /terrein een toelichting toe te voegen

Blz. 65


PROVINCIE ANTWERPEN

Ref.: 481

III.4.1.3. Reservaties Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

reservatie publieke zalen moet steeds goedgekeurd worden door de beheerder flexibele input van datums mogelijkheid om opties mee te geven in de reservatie beheer van kleedkamers invulgegevens webformulieren afhankelijk per type zaal dubbele boekingen kunnen ingeven minimale verhuurtijd instellen + marges voor opbouw en afruimen raadplegen van de zaalbezetting op de website zonder aan te melden, enkel aanmelden bij bestelling

III.4.1.4. Klanten extra velden klantenprofiel optioneel: toevoegen van extra contactpersonen aan een organisatie

III.4.1.5. Administratieve afhandeling beheerder moet een duidelijk overzichtsbeeld hebben van alle onbehandelde en nieuwe aanvragen, aanvragen in behandeling beheerder moet op eenvoudige manier correcties kunnen aanbrengen en input kunnen overrulen communicatie per brief of per email

III.4.1.6. Verlofkalender meerdere kalenders met sluitingsdagen en verlof kunnen ingeven grafisch voorstellen en bewerken gebruiksvriendelijke outlookachtige kalender mogelijkheid om tekst weer te geven mogelijkheid om via webinterface reservaties grafisch aan te maken en, te bewerken zoals in outlook

Blz. 66


PROVINCIE ANTWERPEN

Ref.: 481

III.4.1.7. Tarieven Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

tarief is afhankelijk van de zaal, soort activiteit, type klant, dienst die de zaal huurt mogelijkheid om kortingen te geven mogelijk om met vaste maandelijkse huur te werken

III.4.1.8. Betalen betalingen kunnen Online (Ingenico), cash of met overschrijving uitgevoerd worden

III.4.1.9. Boekhouding koppeling met de gemeentelijke boekhouding (New Horizon – Logins)

III.4.1.10. Zoekfunctie zalen kunnen gezocht worden op basis van locatie optie: zalen kunnen gezocht worden op basis van type activiteit optie: een webpagina, los van de gemeenschappelijke website, met daarop een overzicht van de activiteiten van de dag op een bepaalde locatie

III.4.1.11. Koppelingen (optioneel) koppeling met energiebeheer van de gebouwen mogelijk

III.4.2. Module 2 : Materiaalverhuur III.4.2.2. Materialen mogelijkheid om aan de verschillende materialen een toelichting toe te voegen een duidelijk overzichtelijk systeem, sterk visueel gericht eenvoudige wijze om materiaal te reserveren eenvoudige wijze om parameters in te voeren en te wijzigen eenvoudige wijze om gewijzigde persoonsgegevens aan te passen

Blz. 67


PROVINCIE ANTWERPEN

Ref.: 481

per materiaalonderdeel kunnen instellen hoe vroeg op voorhand reservaties ingegeven kunnen worden bij online geboekte reservatie neemt de klant een optie (geen vastlegging) de klant moet in een vrij tekstveld bijkomende informatie kunnen geven de bezoekers van de website moeten de stand van zaken van de materiaaluitleen kunnen raadplegen zonder dat ze aangemeld moeten zijn

III.4.2.3. Grafisch voorstellen en bewerken Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

gebruiksvriendelijke outlookachtige kalender interface waarin de bezetting duidelijk wordt weergegeven mogelijkheid om korte tekstweergave of meldingen in de kalender weer te geven

III.4.2.4. Betalen betalingen kunnen cash, met bancontact betaald worden of met overschrijving uitgevoerd worden

III.4.2.5. Boekhouding koppeling met de gemeentelijke boekhouding (New Horizon – Logins) mogelijk

III.4.3. Module 3 : Inschrijvingen voor vrijetijdsactiviteiten van jeugd, sport en cultuur en Kinderopvang III.4.3.2.Klanten Ja gezin georiënteerde klantenprofielen extra informatie profiel van een volwassene zonder kinderen extra informatie profiel kind extra vrij tekstveld voor informatie voor intern gebruik

Blz. 68

Nee

Optie


PROVINCIE ANTWERPEN

Ref.: 481

III.4.3.3. Controles Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

koppelen van voorwaarden aan inschrijven controle leeftijdsgroep (geboortedatum) controle bevestiging medische infofiche controle openstaande facturen van voorgaande activiteiten controle beschikbaarheid van de plaats

III.4.3.4. Klantenprofiel opslaan van het volledige klantenprofiel in www.zwijndrecht.be online en offline klanten moeten met de toepassing kunnen worden beheerd. klant moet eigen profiel kunnen bijwerken aanmaak dubbele klantenprofielen niet toelaten klantenprofiel met vrije en verplichte velden beheerders hebben een uniek login beheerders krijgen rechten op basis van een of meerdere rollen beheerders kunnen elk veld in een aanvraag aanpassen het aantal beheerderslogins heeft geen invloed op de kostprijs aantal beheerders is onbeperkt, maar er moet een licentie betaald worden per aantal simultane sessies er moet een licentiekost betaald worden per beheerderslogin optie: kostprijs per bijkomende licentie (indien van toepassing )

III.4.3.5. Input van activiteiten per activiteit bijkomende info (meerkeuze, tekstveld, kostprijs, …) per activiteit start- en einddatum, titel, korte omschrijving activiteiten kunnen eenvoudig gekopieerd worden activiteiten kunnen voor enkele uren, een halve dag, een dag, meerdere dagen ingegeven worden optie: verborgen activiteit voor intern gebruik kunnen aanmaken (interne sportdag voor personeel)

Blz. 69


PROVINCIE ANTWERPEN

Ref.: 481

III.4.3.6.Dossiers Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

dossier met contactinformatie ruimer dan officieel adres

III.4.3.7. Regionale sport Online inschrijven wordt enkel gebruikt als aanvraagmedium (de sportdienst werkt de aanvraag verder af)

III.4.3.8. Rapporten op basis van de activiteiten moet een contract kunnen worden opgemaakt tussen gemeentebestuur en betrokken organisatie diverse lijsten kunnen opmaken (aanwezigheidslijst, medische gegevens per kind, start- en aankomstpunten per activiteit…)

III.4.3.9. Inschrijven dynamisch webformulier dat enkel de relevante keuzes voor de ouder toont en de ouder stap voor stap door de reservatie heen leidt. efficiënte interface voor de beheerders die klanten via de balie wensen in te schrijven bewijs van inschrijving voor klanten optie: digitale handtekening onder medische gegevens voor online inschrijvingen

III.4.3.10. Animatoren bijhouden gegevens van animatoren + geleverde prestaties optie: berekenen van de vergoeding op basis van prestaties en ervaring

III.4.3.11. Betalen online, cash, bancontact of met overschrijving

III.4.3.12. Kortingen korting via de vrijetijdspas en sociaal tarief (vooraf ingeven in backoffice)

Blz. 70


PROVINCIE ANTWERPEN

Ref.: 481

jaarlijkse controle inbouwen op gebruik van vrijetijdspas

III.4.3.13. Fiscale attesten Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

fiscale attesten voor vakantieaanbod, speelpleinwerking en buitenschoolse kinderopvang voor kinderen jonger dan 12 jaar attesten kunnen samengevoegd worden tot één centraal attest op naam van het gezin/kind mogelijkheid voorzien dat de klant zelf attest kan downloaden en afprinten geen fiscaal attest voor wanbetalers

III.4.3.14. Verkoop van producten in de backoffice registratie van welke producten werden verkocht

III.4.3.15. Annulering gedeeltelijke terugbetaling bij ziekte (verwerken in fiscaal attest)

III.4.3.16. Inschrijvingsbewijs naast standaardinformatie velden voorzien voor extra informatie

III.4.3.17. Boekhouding koppeling met de gemeentelijke boekhouding (New Horizon – Logins) activiteiten koppelen aan beleidsitems, rekeningnummers en actieplannen

III.4.4. Module 4 : speelpleinwerking III.4.4.2. Klanten gezin georiënteerde klantenprofielen extra informatie profiel kind

Blz. 71


PROVINCIE ANTWERPEN

Ref.: 481

extra vrij tekstveld voor informatie voor intern gebruik de back office moet de contact- en medische gegevens kunnen valideren

III.4.4.3. Controles Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

koppelen van voorwaarden aan inschrijven; kan vlot en efficiënt te gebeuren controle leeftijdsgroep (geboortedatum) controle bevestiging medische infofiche controle openstaande facturen van voorgaande activiteiten controle beschikbaarheid van de plaats

III.4.4.4. Klantenprofiel opslaan van het volledige klantenprofiel in www.zwijndrecht.be online en offline klanten moeten met de toepassing kunnen worden beheerd klant moet eigen profiel kunnen bijwerken aanmaak dubbele klantenprofielen niet toelaten klantenprofiel met vrije en verplichte velden beheerders hebben een uniek login beheerders krijgen rechten op basis van een of meerdere rollen beheerders kunnen elk veld in een aanvraag aanpassen het aantal beheerderslogins heeft geen invloed op de kostprijs aantal beheerders is onbeperkt, maar er moet een licentie betaald worden per aantal simultane sessies er moet een licentiekost betaald worden per beheerderslogin optie: kostprijs per bijkomende licentie (indien van toepassing )

III.4.4.5. Input van activiteiten per activiteit bijkomende info (meerkeuze, tekstveld, kostprijs, …) per activiteit start- en einddatum, titel, korte omschrijving activiteiten kunnen eenvoudig gekopieerd worden

Blz. 72


PROVINCIE ANTWERPEN

Ref.: 481

activiteiten kunnen voor enkele uren, een halve dag, een dag, meerdere dagen ingegeven worden optie: verborgen activiteit voor intern gebruik kunnen aanmaken (interne sportdag voor personeel)

III.4.4.6. Dossiers Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Dossier met contactinformatie ruimer dan officieel adres

III.4.4.7. Rapporten op basis van de activiteiten moet een contract kunnen worden opgemaakt tussen gemeentebestuur en betrokken organisatie diverse lijsten kunnen opmaken (aanwezigheidslijst, medische gegevens per kind, start- en aankomstpunten per activiteit…)

III.4.4.8. Inschrijvingen aan- en afwezigheid van kinderen moet op de locatie zelf worden ingeschreven en geregistreerd beurtenkaarten worden ook op speelpleinlocatie verkocht; saldo beurtenkaart bijhouden

III.4.4.9. Betalen cash of met beurtenkaart (mits bijhouden van het aantal gebruikte beurten) op de locatie zelf gratis via OCMW (géén fiscaal attest)

III.4.4.10. Kortingen korting via de vrijetijdspas en sociaal tarief (vooraf ingeven in backoffice) jaarlijkse controle inbouwen op gebruik van vrijetijdspas

III.4.4.11. Fiscale attesten fiscale attesten voor speelpleinwerking voor kinderen jonger dan 12 jaar mogelijkheid voorzien dat de klant zelf attest kan downloaden en afprinten geen fiscaal attest voor wanbetalers of voor de gratis inschrijvingen via OCMW

Blz. 73


PROVINCIE ANTWERPEN

Ref.: 481

III.4.4.12. Verkoop van producten in de backoffice Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

speelpleinbeurtenkaart enkel online te verkopen indien het saldo wordt geregistreerd.

III.4.4.13. Boekhouding koppeling met de gemeentelijke boekhouding (New Horizon – Logins) activiteiten koppelen aan beleidsitems, rekeningnummers en actieplannen

III.4.4.14. Animatoren bijhouden gegevens van animatoren + geleverde prestaties optie: berekenen van de vergoeding op basis van prestaties en ervaring

III.4.5. Module 5: Kinderopvang III.4.5.2. Klantenprofiel opslaan van het volledige klantenprofiel in www.zwijndrecht.be online en offline klanten moeten met de toepassing kunnen worden beheerd. klant moet eigen profiel kunnen bijwerken aanmaak dubbele klantenprofielen niet toelaten klantenprofiel met vrije en verplichte velden beheerders hebben een uniek login beheerders krijgen rechten op basis van een of meerdere rollen beheerders kunnen elk veld in een aanvraag aanpassen het aantal beheerderslogins heeft geen invloed op de kostprijs aantal beheerders is onbeperkt, maar er moet een licentie betaald worden per aantal simultane sessies er moet een licentiekost betaald worden per beheerderslogin optie: kostprijs per bijkomende licentie (indien van toepassing)

Blz. 74


PROVINCIE ANTWERPEN

Ref.: 481

III.4.5.3. Klanten Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

gezin georiënteerde klantenprofielen extra informatie profiel kind extra vrij tekstveld voor informatie voor intern gebruik backoffice moet de contact- en medische gegevens kunnen valideren Aan de Vrijetijdsbalie melden dat het medisch profiel is aangepast

III.4.5.4. Controles koppelen van voorwaarden aan inschrijven; dient vlot en efficiënt te gebeuren controle leeftijdsgroep (geboortedatum) controle bevestiging medische infofiche controle openstaande facturen van voorgaande activiteiten controle beschikbaarheid van de plaats controle ondertekening schriftelijke overeenkomst

III.4.5.5. Dossiers ouders hebben een (online) dossier met belangrijke contactinfo bij aanmaak van een nieuw dossier melden aan ouders dat ze contact moeten opnemen met de Vrijetijdsbalie voorzien van de verplichte parameters voor Kind & Gezin

III.4.5.6. Inschrijvingen Tijdens het schooljaar: tijdsregistratie van kind (in- en uit), met een automatisch einduur (ochtend) en startuur (middag), afhankelijk van de school waar het kind naartoe gaat. Tijdens het schooljaar: kind kan minstens 3 keer in- en uitgeschreven worden (ochtend, middag, activiteit tijdens zomer) Tijdens de vakantie: Controle van inschrijving voor kinderopvang of andere activiteit tijdsregistratie van kind (in- en uit) Algemeen: -

Tijdsregistratie per minuut Manuele aanpassing van schooldag of vakantiedag

Blz. 75


PROVINCIE ANTWERPEN

Ref.: 481

Tarief wordt bepaald afhankelijk van schooldag of vakantiedag Tijdsregistratie moet overruled kunnen worden

III.4.5.7. Betalen en facturatie Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

betaling enkel via facturatie extra kosten (boetes,…) manueel kunnen invoeren maandelijkse facturen met zeer laag bedrag verzamelen tot één factuur over periode van 3 maanden Is het mogelijk om éénzelfde kind op 2 facturatieadressen (nieuw samengesteld gezin) in te schrijven, zodat er 2 facturen en 2 fiscale attesten worden aangemaakt?

III.4.5.8. Tarieven en kortingen tarieven tijdens schooljaar zijn verschillend van deze tijdens de vakantieperiodes. De berekening van de tarieven tijdens schooljaar gebeurt op basis van begonnen half uur en tijdens de schoolvakanties per blok van uren alle elementen uit het aanbod komen in aanmerking voor kortingen voor vrijetijdspas en sociaal tarief

III.4.5.9. Fiscale attesten fiscale attesten voor buitenschoolse kinderopvang waarbij rekening wordt gehouden met de samengestelde gezinnen mogelijkheid voorzien dat de klant zelf attest kan downloaden en afprinten geen fiscaal attest voor wanbetalers optie: attesten ziekenfonds kunnen online afgedrukt worden

III.4.5.10. Rapporten per kwartaal en jaarlijks moeten er rapporten per locatie of in globo worden opgemaakt opmaak van rapporten voor Kind & Gezin (zie bijlage)

III.4.5.11. Boekhouding koppeling met de boekhouding New Horizon

Blz. 76


PROVINCIE ANTWERPEN

Ref.: 481

III.4.6. Module 6: Ticketverkoop III.4.6.2. Gebruikersprofiel Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

aanmelden gebeurt eenvoudig en gebruiksvriendelijk (zonder paswoord)

III.4.6.3. Voorstellingen gedetailleerd ingeven van de voorstelling in de toepassing ingeven van verschillende types van voorstellingen, opleidingen, tentoonstellingen, … optie: beperkte vorm van stockbeheer optie: koppeling cultuurnet Vlaanderen

III.4.6.4. Tarieven en kortingen verschillende tariefstructuren moeten eenvoudig kunnen worden ingegeven (-26 jaar, 60+,…) weergave in absolute cijfers of percentages

III.4.6.5. Extra kosten mogelijkheid voorzien om in de toekomst extra kosten te kunnen aanrekenen

III.4.6.6. Betalen online, cash, bancontact, via overschrijving bij avondverkoop gebeurt de betaling enkel cash of via bancontact

III.4.6.7. Verkoop bij voorverkoop, verkoop aan de balie of online worden de tickets op naam van de klant geregistreerd aanbod is zichtbaar op de gemeentelijke website de klant moet de activiteiten per categorie kunnen terugvinden bij de avondverkoop van de voorstelling moeten de tickets aan de kassa zeer snel kunnen verkocht worden en dus niet op naam van de klant staan.

Blz. 77


PROVINCIE ANTWERPEN

Ref.: 481

de lay-out van het verkoopscherm bevat bij voorkeur enkel de lijst van de voorstellingen van die dag/avond. het aantal verkochte tickets wordt gelogd in de applicatie verkoop kassa

III.4.6.8. Wachtlijst Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

Ja

Nee

Optie

als de voorstelling volzet is moet de klant op een reservelijst komen te staan via rapporteringsmodule moet een lijst van de wachtlijst kunnen worden gemaakt, waarin de contactgegevens van de klanten zijn opgenomen via rapporteringstool moet ook een lijst kunnen gemaakt worden van de voorstellingen met nog vrije plaatsen en personen op de wachtlijst. Personen die geen interesse hebben moeten eenvoudig uit de wachtlijst kunnen worden geschrapt.

III.4.6.9. Afdrukken van tickets enkel betaalde tickets kunnen afgedrukt worden bulk afdrukken van resterende tickets afdrukken van tickets ondersteuning printer optie: e-tickets, inclusief 2 scanners voor offline inscannen Optie: prijs per bijkomende scanner

III.4.6.10. Zaalplan de software moet toelaten om zelf een zaalplan te kunnen aanmaken bij online verkoop moet de klant zijn plaatsen zelf kunnen aanduiden op het zaalplan. de software moet verhinderen dat de klanten tussen 2 stoelen vrije plaatsen laat bepaalde plaatsen moeten ook geblokkeerd kunnen worden (technische installatie…) optie: de klant kan zijn genummerde plaats op een eenvoudige wijze ruilen voor een andere plaats

III.4.6.11. Rapporten rapport met overzicht van de verkopen

Blz. 78


PROVINCIE ANTWERPEN

Ref.: 481

aantal tickets verkocht, gereserveerd en nog beschikbaar kassarapport per dag, per periode, per verkoper overzicht van zaalbezetting per voorstelling

III.4.6.12. Opties Ja

Nee

Optie

Ja

Nee

Optie

optie: online boeken voor rolstoelgebruikers optie: standalone versie van het programma bij afwezigheid van internet verbinding

III.4.6.13. Boekhouding koppeling met de gemeentelijke boekhouding (New Horizon – Logins)

Blz. 79


PROVINCIE ANTWERPEN

Ref.: 481

BIJLAGE C : INVENTARIS “SOFTWARE VRIJETIJDSDIENSTEN GEMEENTE ZWIJNDRECHT” Belangrijk: de vermelde hoeveelheden zijn de totaalhoeveelheden per artikel over een contractperiode van 5 jaar. De opgegeven eenheidsprijzen moeten dus vermenigvuldigd worden met de opgegeven hoeveelheid om het totaal per artikel te bekomen.

Nr.

Beschrijving

Type

Eenh.

EHP. in cijfers excl. Hoev. btw

Totaal excl. btw Btw%

Module 1: zaalverhuur 1

Levering en installatie software

FH

stuk

1

21%

2

Licentiekost huur of aankoopkost module zaalverhuur (prijs voor het benodigde aantal licenties voor een periode van 5 jaar)

FH

stuk

1

21%

3

Onderhoudskost all-in (eenheidsprijs = kost op driemaandelijkse basis; totaal = kost voor de contractperiode van 5 jaar), incl. support/SLA/helpdesk excl. hosting

FH

prijs/kwartaal

20

21%

4

Kostprijs hosting (eenheidsprijs = kost op driemaandelijkse basis; totaal = kost voor de contractperiode van 5 jaar)

FH

prijs/kwartaal

20

21%

5

Opleiding

FH

stuk

1

21%

Module 2: materiaalverhuur 6


FH

stuk

1

21%

7

Licentiekost huur of aankoopkost module materiaalbeheer (prijs voor het benodigde aantal licenties voor een periode van 5 jaar)

FH

stuk

1

21%

Blz. 80


Nr.

PROVINCIE ANTWERPEN

Ref.: 481

Beschrijving

Type

Eenh.

EHP. in cijfers excl. Hoev. btw


8


FH

prijs/kwartaal

20

21%

9


FH

prijs/kwartaal

20

21%

10

Opleiding

FH

stuk

1

21%

Module 3: inschrijvingen voor vrijetijdsactiviteiten van jeugd, sport en cultuur 11


FH

stuk

1

21%

12

Licentiekost huur of aankoopkost module inschrijvingen voor vrijetijdsactiviteiten van jeugd, sport en cultuur (prijs voor het benodigde aantal licenties voor een periode van 5 jaar)

FH

stuk

1

21%

13


FH

prijs/kwartaal

20

21%

14


FH

prijs/kwartaal

20

21%

15

Opleiding

FH

stuk

1

21%

Module 4: speelpleinwerking 16


FH

stuk

1

21%

17

Licentiekost huur of aankoopkost module speelpleinwerking (prijs voor het benodigde aantal licenties voor een periode van 5 jaar)

FH

stuk

1

21%

18


FH

prijs/kwartaal

20

21%

Blz. 81


Nr.

Beschrijving

19

20

PROVINCIE ANTWERPEN

Ref.: 481 EHP. in cijfers excl. Hoev. btw


Type

Eenh.


FH

prijs/kwartaal

20

21%

Opleiding

FH

stuk

1

21%

Module 5: kinderopvang (optie) 21

[Verplichte optie] Levering en installatie software

FH

stuk

1

21%

22

[Verplichte optie] Licentiekost huur of aankoopkost module kinderopvang (prijs voor het benodigde aantal licenties voor een periode van 5 jaar)

FH

stuk

1

21%

23

[Verplichte optie] Onderhoudskost all-in (eenheidsprijs = kost op driemaandelijkse basis; totaal = kost voor de contractperiode van 5 jaar), incl. support/SLA/helpdesk excl. hosting

FH

prijs/kwartaal

20

21%

24


FH

prijs/kwartaal

20

21%

25

[Verplichte optie] Opleiding

FH

stuk

1

21%

Module 6: ticketverkoop ’t Waaigat (optie) 26

[Verplichte optie] Levering en installatie software

FH

stuk

1

21%

27

[Verplichte optie] Licentiekost huur of aankoopkost module ticketverkoop 't Waaigat (prijs voor het benodigde aantal licenties voor een periode van 5 jaar)

FH

stuk

1

21%

28

[Verplichte optie] Onderhoudskost all-in (eenheidsprijs = kost op driemaandelijkse basis; totaal = kost voor de contractperiode van 5 jaar), incl. support/SLA/helpdesk excl. hosting

FH

prijs/kwartaal

20

21%

29


FH

prijs/kwartaal

20

21%

30

[Verplichte optie] Opleiding

FH

stuk

1

21%

Blz. 82


Nr.

Beschrijving

31

32

PROVINCIE ANTWERPEN

Ref.: 481 EHP. in cijfers excl. Hoev. btw


Type

Eenh.

[Verplichte optie] Aankoop 2 barcode scanners (zie rubriek III.4.6.9)

FH

stuk

2

21%

[Verplichte optie] Aankoop 1 bijkomende barcode scanner (zie rubriek III.4.6.9)

FH

stuk

1

21%

Totaal excl. btw :

Btw 21% :

Totaal incl. btw : De eenheidsprijzen dienen opgegeven te worden tot 2 cijfers na de komma. De producten hoeveelheid x eenheidsprijs dienen echter telkens op 2 cijfers na de komma afgerond te worden. Gezien, onderzocht en aangevuld met eenheidsprijzen, gedeeltelijke sommen en de totale som die gediend hebben tot het vaststellen van het bedrag van mijn inschrijving van heden, om gevoegd te worden bij mijn offerteformulier. Te .......................................... de ...................................................... Functie: ...................................................... Naam en voornaam: ............................................................................ Handtekening:

Blz. 83

BESTEK LEVERINGEN SOFTWARE VRIJETIJDSDIENSTEN GEMEENTE ZWIJNDRECHT VEREENVOUDIGDE ONDERHANDELINGSPROCEDURE MET BEKENDMAKING. Gemeente Zwijndrecht

Recommend Documents