Download hier het Programma van Eisen - Aftersales Magazine

Programma van Eisen Garage software [VERSIE 2010] 

Programma van Eisen 

Bedrijfsondersteunende informatiesystemen 

voor universele autobedrijven 

ook wel “garagesoftware” genoemd 

BOVAG Onafhankelijke Autobedrijven 

Software commissie 

Status: Definitief


Inhoudsopgave 

1. Inleiding ........................................................................................................................................ 4 

2. Certificering en programma van eisen .......................................................................................... 5 

2.1 Partijen ..................................................................................................................................... 5 

2.2 Beheer van Programma van eisen ............................................................................................ 5 

2.3 Certificatieproces ...................................................................................................................... 6 

2.4 Communicatie omtrent de certificering ...................................................................................... 8 

3 Algemene eisen softwareleverancier ................................................................................................ 9 

4 Algemene technische eisen ............................................................................................................ 12 

4.1 Algemene gebruikersaspecten ................................................................................................ 12 

4.2 Technische eisen .................................................................................................................... 13 

5 Systeemconcept ............................................................................................................................. 14 

6 Basis informatie .............................................................................................................................. 17 

6.1 Klant ............................................................................................................................................ 19 

6.2 Bezit ............................................................................................................................................ 20 

6.3 Dienst .......................................................................................................................................... 20 

6.4 Voertuig ....................................................................................................................................... 21 

6.4a Voertuig type gerelateerde gegevens......................................................................................... 22 

6.5 Gebruikers ................................................................................................................................... 23 

6.5a Kwalificatie .............................................................................................................................. 24 

6.6 Onderdelen .................................................................................................................................. 24 

6.6a Kruistabel Artikelnummers ...................................................................................................... 25 

6.7 Transactie .................................................................................................................................... 25 

6.8 Normen ........................................................................................................................................ 26 

6.9 Formaat beschrijving .................................................................................................................... 27 

7 Module Beschrijving ....................................................................................................................... 28 

7.1 Algemeen ............................................................................................................................... 28 

7.2 Relatiebeheer ........................................................................................................................ 28 

7.2.1 Algemeen ........................................................................................................................ 28 

7.2.2 Verkrijgen suspectgegevens ............................................................................................ 29 

7.2.3 Verkrijgen prospectgegevens........................................................................................... 29 

7.2.4 Beheren van klantgegevens ............................................................................................ 29 

7.2.5 Raadplegen klantgegevens ............................................................................................. 30 

7.2.6 Klanten en signalen ......................................................................................................... 30 

7.2.7 Doelgroep selecties ......................................................................................................... 30 

7.2.8 Mailing samenstellen ....................................................................................................... 31 

Wens: 7.2.9 Contact / response vastleggen ................................................................................ 31 

7.3 In en verkoop ......................................................................................................................... 31 

7.3.1 Prospect en proefrit ......................................................................................................... 31 

7.3.2 Offerte ............................................................................................................................. 31 

7.3.3 Koopovereenkomst .......................................................................................................... 32 

7.3.4 Inkoop / Inruil ................................................................................................................... 32 

7.3.5 Verkoop ........................................................................................................................... 34 

7.4 Werkplaats ............................................................................................................................. 36 

7.4.1 Afspraak .......................................................................................................................... 36 

7.4.2 Plannen ........................................................................................................................... 36 

7.4.3 Innemen voertuig ............................................................................................................. 37 

7.4.4 Onderhoud voertuig ......................................................................................................... 38 

7.4.5 Aanbieden voertuig/Factureren ........................................................................................ 39 

7.5 Magazijn ................................................................................................................................ 39 

7.5.1 Invoer onderdelen/verbruiks artikelen .............................................................................. 39 

7.5.2 Voorraad beheer .............................................................................................................. 40 

2 Definitief 1.0 Intern en Vertrouwelijk BOVAG Onafhankelijke Autobedrijven


7.5.3 Uitgifte voorraad .............................................................................................................. 41 

7.5.4 Bestellen onderdelen/artikelen ......................................................................................... 42 

7.5.5 Ontvangst goederen ........................................................................................................ 42 

7.6 Financiën ................................................................................................................................ 43 

7.6.1 Algemeen ........................................................................................................................ 43 

7.6.2 Grootboek stambestand ................................................................................................... 43 

7.6.3 Grootboek mutaties ......................................................................................................... 43 

7.6.4 Facturen ................................................................................................................................ 44 

7.6.5. Overzichten ..................................................................................................................... 44 

7.6.6 Debiteuren ....................................................................................................................... 45 

7.6.7 Crediteuren ...................................................................................................................... 46 

7.7 Managementinformatie ........................................................................................................... 47 

7.7.1. Algemeen ........................................................................................................................ 47 

7.7.2 Operationeel management .................................................................................................... 47 

7.7.3 Tactisch management ........................................................................................................... 49 

7.7.4 Strategisch management ....................................................................................................... 49 

8 Interfaces ........................................................................................................................................... 50 

8.1 Algemeen ............................................................................................................................... 50 

8.2 Flexibiliteit ............................................................................................................................... 50 

8.3 Integratie van diensten ............................................................................................................ 50 

9. Bijlagen ...................................................................................................................................... 52 

9.1 Bijlage Interfaces .................................................................................................................... 52 



1. Inleiding 

In dit document is het vernieuwde Programma van Eisen 2010 opgenomen dat de afdeling BOVAG 

Onafhankelijke Autobedrijven heeft opgesteld voor garagesoftware pakketten. In dit nieuwe Programma 

van Eisen wordt meer aandacht besteed aan integratie van diensten van derden. Hiermee is de focus 

nog wel op leveranciers van garage software pakketten maar kan dit document ook gebruikt worden 

door dienstenleveranciers die willen integreren in garagesoftware. 

Tevens zijn de algemene eisen die gesteld worden aan de leveranciers en de door hun gebruikte 

techniek verder uitgewerkt om aan te sluiten op de hogere eisen die gesteld worden aan de continuïteit 

van dienstverlening en de beveiliging van de informatieprocessen. 

Een andere vernieuwing betreft het certificatieproces. Gezien de snelheid en veelheid van belangrijke 

ontwikkelingen op het gebied van informatisering binnen de mobiliteitsector volstaat een 5 jarige cyclus 

niet meer. Met het nieuwe PvE wordt ook een periodiek certificeringcyclus geïntroduceerd. 

Doel 

Het Programma van Eisen 2010 heeft tot doel de gewenste functionaliteit van een softwarepakket 

inclusief de integratie met informatiediensten en -producten van derden in kaart te brengen. Op basis 

van deze door de gebruikersgroep expliciet gemaakte wensen en verwachtingen kunnen de 

leveranciers hun producten ontwikkelen. Hiermee is het streven om de ondersteuning van de bedrijven 

door de garage software optimaal in te vullen. 

Om het voor de gebruikers transparant te maken welke software oplossing voldoet aan de actuele en 

gerechtvaardigde eisen en verwachtingen wordt het Programma van Eisen gebruikt in een 

certificatieproces om te beoordelen of zowel de aangeboden software als de leverancier voldoet aan 

datgene wat vereist is. 

Als basis voor dit PvE heeft het Programma van Eisen Garagesoftware 2005 gediend maar is op een 

groot aantal punten herzien. Er is gekozen om een Basis pakket van eisen op te stellen, waaraan alle 

softwarepakketten die gecertificeerd zijn of willen zijn aan moeten voldoen. Daarnaast is het mogelijk 

om een aanwijzing te krijgen over extra mogelijkheden van het pakket die voor de gebruiker relevant 

zijn. Deze extra mogelijkheden staan in het document omschreven als “Extra Eisen”. Het staat de 

software ontwikkelaar natuurlijk vrij om naast de basis en extra eisen eigen extra functionaliteit aan het 

softwarepakket toe te voegen. Deze worden niet in de beoordeling meegenomen voor het certificaat 

maar zullen wel resulteren in positieve aantekeningen. 

Beheer van de eisen 

Dit nieuwe PvE is wederom tot stand gekomen door een werkgroep softwarecertificering binnen de 

afdeling welke is samengesteld uit gebruikers van verschillende garagepakketten. Zij zijn daarbij 

ondersteund door het secretariaat van de afdeling en deskundigen van het RDC. Alle leidende 

softwarepakketten zijn door middel van deze gebruikers vertegenwoordigd. Bij deze willen we de 

commissieleden bedanken voor hun inzet voor de totstandkoming van dit document. De werkgroep 

softwarecertificering zal vanwege de periodieke certificatie cyclus een meer permanent karakter krijgen, 

maar daar over meer in hoofdstuk 2. 



2. Certificering en programma van eisen 

Het Programma van Eisen vormt de inhoudelijke norm voor de beoordeling van de aangeboden 

software oplossing en de daaraan verbonden aanbieder. In dit hoofdstuk wordt ingegaan op het 

periodieke certificeringproces. 

2.1 Partijen 

De BOVAG afdeling Onafhankelijke Autobedrijven is opdrachtgever voor het PvE en de daaraan 

verbonden softwarecertificering. 

- Zij initieert, onderhoudt het Programma van Eisen en stelt dit periodiek vast. De afdeling 

organiseert middels de werkgroep softwarecertificering de inbreng van de benodigde technische 

en praktijkkennis in om het Programma van Eisen nauw aan te laten sluiten bij de praktijk van de 

leden. 

- Zij draagt verder zorg voor een objectieve toetsing of software oplossingen en de daaraan 

verbonden dienstverlening voldoen aan het actuele Programma van Eisen. 

- Zij informeert haar leden periodiek over het PvE, de nieuwe gebruikerswensen en eisen 

alsmede welke leveranciers en welke softwarepakketten voldoen aan het Programma van Eisen. 

De BOVAG afdeling Onafhankelijke Autobedrijven verzorgt de projectcoördinatie binnen de softwarecommissie. 

RDC heeft een uitvoerende rol gehad met betrekking tot het opzetten van het Programma 

van Eisen. 

2.2 Beheer van Programma van eisen 

De BOVAG afdeling Onafhankelijke Autobedrijven zorgt voor een inname punt van wensen, eisen en 

eventuele klachten van haar leden over software oplossingen. 

De over een bepaalde periode ingenomen berichten worden gestructureerd doorgegeven aan de 

werkgroep softwarecertificering die de periodiek beoordeeld en eventueel vertaald in voorgenomen 

wijzigingen in eisen en wensen van het PvE. Indien er sprake is van een spoedeisende aanpassing 

vanwege wettelijke, continuïteit- of beveiligingsaspecten zal de werkgroep softwarecertificering deze als 

aanvulling op het lopende PvE benoemen en direct aan de softwareleveranciers mededelen. Indien er 

sprake is van een spoedeisende aanpassing, m.b.t. het onafhankelijke autobedrijf, en deze heeft 

invloed op het softwarepakket, dan dient deze aanpassing op een zo kort mogelijke termijn, wat billijk is 

voor de softwareleverancier, uitgevoerd te worden. Dit zal per noodzakelijke aanpassing individueel 

bekeken worden. 

Er zal een pagina beschikbaar worden gemaakt op www.autobedrijf.nl waarop men zonder inlog de 

laatste stand van zaken kan bekijken met betrekking tot de huidige eisen, nieuwe wensen en het laatste 

nieuws. Deze website is voor iedereen inzichtelijk; leden, niet-leden en softwareleveranciers. 

Periodiek wordt het PvE geactualiseerd met enerzijds deze voorgenomen wijzigingen en anderzijds met 

eisen welke samenhangen met ontwikkelingen in dienstverlening en technologie. 

Jaarlijks verschijnen er nieuwe eisen, men kan zich jaarlijks laten certificeren. Het certificaat zal 

voorzien zijn van een jaartal wat direct de actualiteit van het certificaat aangeeft. De nieuwe eisen zullen 

aan het begin van het nieuwe jaar vrijgegeven worden en vanaf dat moment kan een 



softwareleverancier zich laten certificeren. De nieuwe eisen zullen worden besproken en vastgesteld in 

de softwarecommissie, daarnaast zullen alle actuele wensen en eisen direct kenbaar gemaakt worden 

op de website. 

2.3 Certificatieproces 

Met dit Programma van Eisen wordt een nieuwe koers gezet. Continue worden eisen, wensen en 

klachten over software oplossingen verzameld, spoedeisende wijzigingen worden centraal vastgesteld 

als toevoeging op het actuele PvE en periodiek wordt een actueel PvE vastgesteld. In het PvE wordt 

onderscheid gemaakt tussen wensen en eisen. Eisen zijn de basis voor certificering, wensen zijn 

potentiële eisen die per een bepaalde invoeringsdatum van wens naar eis worden verheven. 

Dit heeft gevolgen voor het certificeringproces. Er wordt voortaan onderscheid gemaakt tussen een 

initiële certificering en het onderhouden van de certificering. Hier gaan we nu nader op in. 

Initiële certificering 

Softwareleveranciers die zich aanmelden voor de certificatie, krijgen een uitgebreide controle. Naast 

een eerste screening via de aanmeldprocedure, wordt het pakket uitgebreid getest door een extern, 

onafhankelijk bureau. 

Deze controle omvat naast de software tevens de gebruikte technologie, de dienstverlening en de 

continuïteit daarvan. De controle van de software geschiedt op basis van een “normenkader” dat is 

afgeleid van dit PvE en door middel van een uitgebreide demonstratie van het pakket in relatie tot het 

PvE. De technologie, continuïteit en dienstverlening aan de hand van vragenlijsten welke onderdeel uit 

maken van het normenkader. De antwoorden op de vragenlijsten kunnen worden getoetst bij gebruikers 

van de software. 

Over de uitkomsten vindt overleg plaats. Na de positieve uitkomsten ontvangt de softwareleverancier 

een certificaat voor de gecontroleerde versie van de softwareoplossing. Dit impliceert dat andere, vaak 

oudere, versies dus niet gecertificeerd zijn. 

Onderhouden van certificering 

Vanaf het moment dat een softwareleverancier een gecertificeerde software oplossing aanbiedt is er 

nauw contact tussen de werkgroep softwarecertificering en de leverancier. Zo worden spoedeisende 

wijzigingen afgestemd en wordt het eindconcept van een nieuw PvE besproken. 

Om de certificering te behouden dient een softwareleverancier periodiek te hebben voldaan aan de 

reactie op spoed eisende wijzigingen en tijdig te voldoen aan de nieuwe eisen in het nieuwe PvE. 

Alleen de eisen zijn onderdeel van certificering. Het voldoen aan wensen wordt in dat proces wel 

geïnventariseerd. 

Indien er duidelijke klachten en/of structurele ontevredenheid is bij de gebruikersgroep of wijzigingen in 

dienstverlening of continuïteit worden gesignaleerd zal dit ook onderwerp van hernieuwde controle zijn. 

Tijdschema 

De werkgroep softwarecertificering vergadert minimaal eens per kwartaal. Indien zich spoedeisende 

wijzigingen voor doen worden deze besproken, gedefinieerd en na afstemming met gecertificeerde 

leveranciers vastgesteld. Deze wijzigingen dienen voor de verplichting beschikbaar te zijn voor de 

gebruikers. 

Periodiek stelt de werkgroep softwarecertificering een vernieuwd programma van eisen op. Hierna 

wordt deze concept versie met de nieuwe wensen en eisen ter reactie en eventuele bespreking 



aangeboden aan de gecertificeerde softwareleveranciers. In het begin van het kalenderjaarwordt het 

nieuwe PvE vastgesteld. 

Certificatieproces 



2.4 Communicatie omtrent de certificering 

Het certificaat wordt alleen afgegeven op het gecertificeerde softwarepakket, de softwareleverancier 

mag dan ook alleen communiceren dat het desbetreffende pakket gecertificeerd is. Bij communicatie 

mag de softwareleverancier gebruik maken van een certificatielogo, dat zal worden aangeleverd door 

het secretariaat. Dit logo mag in de uitingen alleen gebruikt worden voor het gecertificeerde 

softwarepakket. Indien de softwareleverancier zich niet houdt aan bovenstaande richtlijn bestaat de 

mogelijkheid tot intrekking van het certificaat. 

Misbruik van de term 'BOVAG-gecertificeerd' kan uitsluiting betekenen van de certificering. Tevens kan 

zonder rechterlijke tussenkomst een boete worden opgelegd van € 5.000,- bij constatering van misbruik, 

onverminderd het recht van de BOVAG afdeling Onafhankelijke Autobedrijven het hele schadebedrag te 

vorderen. 

De term 'BOVAG-gecertificeerd' mag worden gebruikt, tenzij er sprake is van: 

- intrekking door de BOVAG afdeling Onafhankelijke Autobedrijven; 

- aanvraag of verlening van surseance van betaling bij de softwareleverancier; 

- aanvraag faillissement bij de softwareleverancier; 

- liquidatie of niet tijdelijke stopzetting van de softwareleverancier. 

De softwareleveranciers krijgen in de toekomst de mogelijkheid om het gecertificeerde softwarepakket 

in modules aan te bieden. Ook kunnen bepaalde modules van andere leveranciers worden 

gecombineerd met de eigen modules. Hier zal in de certificering van komend jaar nader naar worden 

gekeken. Echter, in de communicatie richting de klant moet expliciet gemeld worden welke modules dan 

specifiek BOVAG-gecertificeerd zijn. De leverancier die een volledig pakket geheel gecertificeerd 

aanbiedt krijgt in de communicatie voorrang. 



3 Algemene eisen softwareleverancier 

Kennis 

Data 

1. De leverancier is bekend met de bedrijfsvoering binnen het autobedrijf alsmede de uitvoerende 

aspecten van samenwerkingsrelaties tussen autobedrijven en hun zakelijke partners. Van de 

leverancier wordt verwacht dat zijn aangeboden software het bedrijfsproces en de samenwerking 

met partners ondersteunt en verbetert. 

2. De leverancier beschikt over minimaal 5 voldoende gekwalificeerde medewerkers om het product 

en de dienstverlening te ontwikkelen en te ondersteunen. 

3. Bij contractbeëindiging biedt de softwareleverancier de mogelijkheid om databasegegevens in een 

leesbaar formaat beschikbaar te stellen waarmee softwareleveranciers in staat zijn om op basis 

hiervan een dataconversie uit te voeren. De gegevens worden uitsluitend aan de klant verstrekt en 

alleen op het moment dat de klant aan alle reguliere betalingsverplichtingen heeft voldaan. 

4. Het eigendom van de data die door het autobedrijf in het systeem zijn ingevoerd ligt bij het 

autobedrijf. Dit is expliciet vastgelegd in de contracten. Gebruik van deze data door de leverancier 

vraagt altijd vooraf expliciete schriftelijke toestemming van de eigenaar. 

Continuïteit 

5. De leverancier dient in een dusdanige financiële positie te verkeren (over de afgelopen drie jaar 

gemiddeld: een EBITA van meer dan 5%) dat er voldoende draagkracht is om de continuïteit van 

de gecertificeerde dienstverlening zoveel mogelijk zeker te stellen. Overname van een leverancier 

met een gecertificeerd product zal een heroverweging inhouden op dit punt. Bij een leverancier 

die minder dan één jaar op de markt is kan wel een voorlopig certificaat worden toegewezen 

waarbij na een jaar wordt getoetst of voldaan wordt aan de financiële ratio‟s. 

6. Indien een leverancier niet kan voldoen aan de continuïteit van de gecertificeerde dienstverlening 

zal dit worden gesignaleerd via de BOVAG ONAFHANKELIJKE AUTOBEDRIJVEN. Indien dit niet 

binnen 3 maanden leidt tot de gewenste verbetering zal het certificaat worden ingetrokken. Over 

dit feit zullen de (potentiële) gebruikers worden geïnformeerd. 

7. De leverancier heeft een minimaal aantal licentiehouders van het te certificeren pakket om in 

aanmerking te komen van een BOVAG softwarecertificaat. Indien er minder dan 100 

licentiehouders zijn, dan zal het pakket niet meegenomen worden in de certificering. De 

leverancier moet aantonen dat dit aantal niet minder is dan 100. Bij een pakket wat minder dan 

één jaar op de markt is kan wel een voorlopig certificaat worden toegewezen waarbij na een jaar 

wordt getoetst of voldaan wordt aan het aantal licenties. 

8. Wens: De leverancier beschikt over een regeling met zijn gebruikers (bijvoorbeeld via Escrow) 

waardoor bij discontinuïteit van de leverancier en/of ondersteuning de gebruikers voor eigen 

gebruik over de actuele ontwerpen, bron codes en volledige programmatuur en bestandsopzet 

kunnen beschikken. 



Kwaliteit 

9. Per gecertificeerd softwarepakket worden door BOVAG twee afgevaardigden (alleen BOVAG 

leden) benoemd die plaats zullen nemen in de softwarecommissie van BOVAG. Deze commissie 

zal minimaal één maal per kwartaal samenkomen. De zaken die spelen bij de softwarehuizen 

worden meegenomen in deze commissie. De commissie zal bepalen welke wensen omgezet 

worden naar eisen. Hierover vindt overleg plaats met de individuele softwareleveranciers. 

De actuele informatie over gebruikerswensen en eisen alsmede de geplande oplevering daarvan 

is beschikbaar voor alle BOVAG leden en klanten van de softwarepakketten. 

10. De leverancier beschikt over een document met daarin vastgelegd het releasebeleid van de 

onderhavige software. Deze informatie wordt ter beschikking gesteld aan de BOVAG 

softwarecommissie en mag openbaar worden gemaakt. 

Financieel 

Bij de contractsluiting dient er een overzicht met de releasemomenten voor dat jaar aanwezig te 

zijn. De releasemomenten dienen altijd vooraf kenbaar gemaakt te worden aan de leden. 

11. Voor de aanvullende functionaliteiten en koppelingen biedt de leverancier een 

onderhoudscontract aan welke op basis van een vast bedrag per periode alle onderhoud en 

wijzigingen afdekt. Dit bedrag kan aangepast worden indien de module uitgebreid wordt met meer 

functionaliteit en/of meer koppelingen. 

12. De gebruiker heeft de mogelijkheid om per module aanvullende functionaliteit en aanvullende 

koppelingen af te nemen. Per aanvullende module wordt een apart bedrag geoffreerd inzake de 

installatiekosten. In de prijslijst wordt een richtbedrag opgenomen inzake deze kosten. 

13. De eenzijdige opzegging door de leverancier kent een opzegtermijn van minimaal 6 maanden. 

De gebruiker is gerechtigd om de software zonder ondersteuning, tegen betaling van het reguliere 

maandbedrag, tot maximaal 1 jaar na opzegging zonder ondersteuning van de leverancier te 

blijven gebruiken. 

14. De leverancier hanteert een prijslijst waarin alle softwaremodules, interfaces etc. en diensten met 

hun kosten staan vermeld. De gebruiker heeft de mogelijkheid om per module aanvullende 

functionaliteit en aanvullende koppelingen af te nemen. De voorwaarden en kosten hiervan zijn 

alvorens bekend op de prijslijst. 

Ondersteuning 

15. De leverancier biedt opleiding en ondersteuning. Deze staan opgenomen in de prijslijst. Bij de 

installatie van het pakket en/of aanvullende modules is een basisopleidinginstructie en een 

handleiding in de prijs opgenomen. Indien opleiding/instructie in groepsverband en/of op locatie 

wordt gegeven wordt dit helder omschreven. 

16. Indien er wijzigingen worden doorgevoerd zorgt de leverancier voorafgaand aan de 

implementatie daarvan voor een update van de gebruikershandleiding. Bij grote wijzigingen 

verzorgt de leverancier een gratis instructie. Bijvoorbeeld in de vorm van een aanvulling in de 

helpfunctie, handleiding, instructievideo of groepsinstructie. 

17. De helpdesk dient minimaal 7.5 uur bereikbaar te zijn op werkdagen van 8.00 uur tot 18.00 

bereikbaar te zijn. Gebruik van de helpdesk is in de licentiekosten inbegrepen..Wens: Aanvullend 

krijgt het autobedrijf de mogelijkheid ook buiten deze tijden (op werkdagen tot 21.00 uur, en op 

zaterdag van 9.00 uur tot 17.00 uur) de helpdesk te kunnen bereiken. Hiervoor mag een reële 

vergoeding worden gevraagd. 

De afspraken inzake support en service op software en eventueel geleverde hardware zijn 

vastgelegd in een actueel service level agreement (SLA). Per (soort) interface zijn er duidelijke 



aansluiten gebruiksvoorwaarden. De SLA‟s voor interfaces zijn afgeleid van de eisen vanuit de 

module. Bij het koppelen aan interfaces van derde partijen stelt dit eisen aan de derde partij. 

Indien één der partijen de overeenkomst beëindigd wordt ondersteuning verleend gedurende 6 

maanden na het verstrijken van de einddatum van de overeenkomst. Hierbij zijn reële kosten 

verschuldigd. De leverancier biedt de mogelijkheid om voor de betreffende periode een 

ondersteuningscontract af te sluiten tegen in de markt gangbare tarieven. Als de aanbieder van 

de online dienst echter geen ondersteuning meer verleent, is de softwareleverancier ook 

ontslagen van deze verplichting. 

18. Indien er sprake is van een situatie waarin softwareleveranciers op afstand kunnen werken op 

het softwarepakket van het autobedrijf, is het proces zo ingericht dat dit alleen kan na expliciete 

toestemming van het autobedrijf. 



4 Algemene technische eisen 

4.1 Algemene gebruikersaspecten 

1. Alle beschikbare schermen, handleidingen en overige documentatie aangaande de applicatie zijn 

Nederlandstalig 

2. De gebruiker moet kunnen beschikken over een grafische gebruikersinterface en muisbesturing. 

Daar waar het gegevensinvoer betreft geldt in het pakket een standaard gebruiksmethode. 

3. Het pakket is consistent opgezet voor wat betreft functieaanroep, schermopbouw, etc. Het bevat een 

overzichtelijke menustructuur. 

4. Wens: Gebruikersinterface is ingedeeld naar de processtappen relevant voor de bedrijfsactiviteit. Er 

is work-flow ondersteuning om het aflopen, en de voortgang daarin, van de stappen te bewaken. (De 

workflow van iedere module is aangegeven in de paragraaf structuur in hoofdstuk 7). 

5. De gebruiker krijgt de beschikking over mogelijkheden om op een eenvoudige wijze een back-up van 

de bestanden en (naar keuze) bijbehorende software op een externe gegevensdrager te kunnen 

maken en deze terug te kunnen zetten. Het vervaardigen van een back-up dient automatisch, 

volgens een door de gebruiker op te geven schema of tijdstip, uitgevoerd te worden. 

6. Bij herstel van bestanden dient intelligentie in de software aanwezig te zijn die de versie van de 

database en de software controleert i.e. wordt voorkomen dat een database versie niet overeenkomt 

met de software versie. 

7. De leverancier ondersteunt de gebruiker, middels een standaardfunctionaliteit, om een 

gegevensselectie te exporteren in de vorm van een bestand met een standaard formaat i.e. .txt, .csv 

etc 

8. Updates / Fixes op de software dienen vergezeld te zijn van zgn. wizzards waardoor de gebruiker 

deze zelfstandig kan uitvoeren. De installatie van updates / Fixes dienen geen negatieve invloed uit 

te oefenen op overige softwarepakketten en hun functionaliteit. De procedure moet zoveel als 

mogelijk automatisch en zonder handmatige handelingen verlopen. 

9. Omtrent de autorisatie dient er minimaal aan het volgende autorisatieschema voldaan te zijn: Er 

kunnen minimaal 5 gebruikersprofielen aangemaakt worden. Per gebruikersprofiel kan er worden 

aangegeven tot welke modules deze gebruiker toegang heeft. Per module/proces kan er bepaald 

worden welke handelingen de gebruiker mag uitvoeren, lezen en/of wijzigen en/of verwijderen. 

10. Het moet, onder voorwaarden, mogelijk zijn dat een gebruiker van het pakket als beheerder kan 

optreden. Deze beheerder moet de mogelijkheid krijgen om uit te voeren hetgeen onder punt 5 t/m 9 

is aangegeven, back-ups te regelen en wachtwoorden te resetten. 

11. Bij functionaliteiten binnen het pakket die door de gebruiker instelbaar zijn, dient de betreffende 

instellingen door de gebruiker zelf te kunnen worden beheerd, Binnen het pakket is hier een 

standaard methode voor. 

12. Er een audittrail aanwezig is zodat achteraf kan worden nagegaan wie welke transactie(s) wanneer 

heeft uitgevoerd. Dit geldt ook voor beheer activiteiten op locatie dan wel op afstand. Er moet 

nagegaan kunnen worden, welke gebruiker op welke datum/tijdstippen aanpassingen heeft 

doorgevoerd in de gegevens. Bijvoorbeeld Relatiestamkaart, Voertuigenstamkaart, Artikelstamkaart 

en Facturatie. De gegevens over gebruikers, datum/tijdstippen en acties moeten in een algemeen 

formaat geëxporteerd kunnen worden. Het raadplegen is een onderdeel dat aan meerdere personen 

is toe te wijzen via autorisatie. 



4.2 Technische eisen 

1. In het algemeen dient de softwareoplossing gebaseerd te zijn op door bronleveranciers 

ondersteunde en veilig geachte operating systemen en op gangbare hardware configuraties / - 

componenten. 

2. De Leverancier verschaft tijdig een specificatie aan de gebruiker, of op diens eerste verzoek, waarin 

staat aangegeven wat de minimale systeemvereisten en randapparatuur zijn bij installatie op een 

server of een werkstation. (Wat van toepassing is) 

3. Deze opgave gaat vergezeld van een schatting van het verwachte databeslag. 

4. Indien er sprake is van een all-in oplossing (hardware, operating systeem en software Incl. 

Onderhoudscontract) dient de leverancier als onderdeel van zijn onderhoudscontract zorg te dragen 

voor het tijdig updaten van de operating systemen en service packs. Indien dit door de aanwezige 

hardware onmogelijk wordt gemaakt, wordt deze verplichting opgeschort, totdat de gebruiker zijn 

hardware heeft gemoderniseerd. 

5. Wens: Naast gebruik van actuele, ondersteunde en veilig geachte besturingssystemen dient ook de 

software op een actueel gangbaar platform ontwikkeld te zijn. 

6. Wens: Er zijn overzichten beschikbaar die een analyse geven van de datakwaliteit en waar mogelijk 

aangeven naar welke registraties er moet worden gekeken voor mogelijke correcties en/of 

aanvulling. Het vervaardigen van deze overzichten is niet limitatief voor het aantal gegevenssets. 

7. De online real time integratie van diensten en daarmee gepaard gaande berichtuitwisseling van 

andere leveranciers dienen, geprefereerd wordt XML, plaats te kunnen vinden op basis van TCP-IP. 

Dit met inachtneming van de (on)mogelijkheden die de te integreren c.q. te koppelen dienst heeft. 

8. Bij een centraal gehoste vorm kan er sprake zijn van een “geëmuleerde” opzet o.b.v. bijvoorbeeld 

Citrix. Dit heeft tot voordeel dat het pakket zelf vaak nauwelijks of niet hoeft te worden aangepast 

maar is wel kosten verhogend i.v.m. extra licenties. Wens: Het streven om pakketten volledig 

internet based te kunnen laten draaien zonder extra software schillen wordt over gelaten aan de 

markt. 

9. Wens: De garagesoftware modules zijn ook veilig op afstand via internet te bereiken en te 

combineren met andere software (ASP/SAAS). 

10. Bij het gebruik van internet based functionaliteit wordt dit ondersteund door minimaal twee van de 

drie, in het certificatiejaar, meest gebruikte browsers in soorten browser software. 

11. De beheerfunctionaliteit wordt gedaan op basis van sjablonen die door de gebruiker onderhouden 

kunnen worden. 

12. Wens: Voor de eisen inzake identificatie, authenticiteit en autorisatie op diensten wordt aangesloten 

op de actuele branchestandaarden zodra deze zijn vastgesteld via de stichting SIMS. 



5 Systeemconcept 

In de visie van de BOVAG ONAFHANKELIJKE AUTOBEDRIJVEN zal het informatiesysteem van het 

autobedrijf in de nabije toekomst bestaan uit verschillende bouwstenen (modules) die naadloos op 

elkaar aansluiten maar wel onafhankelijk van elkaar gebruikt kunnen worden. Welke modules door het 

autobedrijf worden ingezet is vooral afhankelijk van het type bedrijf (omvang, kernactiviteiten). 

Daarnaast staat volledige integratie centraal. Dit houdt in dat het softwarepakket een geïntegreerde 

koppelingen heeft met de verschillende modules, waardoor bijvoorbeeld de klant- of voertuiggegevens 

maar op één plek binnen het softwarepakket geïdentificeerd en onderhouden hoeft te worden. Dat werd 

al geïllustreerd door het onderstaande schema dat nog stamt uit het PvE van 2005. 

Werkplaats 

administratie 

Technische 

Databanken 

Garage apparatuur 

Magazijn 

administratie 

Onderdelen 

Databanken 

Modulaire opzet binnen pakket 

Klant & 

Voertuigverrijking 

OAB GSW 

pakket 

Provider Producten & 

Diensten 

Verkoop 

administratie 

Taxatie systeem 

In dit PvE 2010 zijn we verder gegaan in het typeren van de modulaire opzet binnen het garage pakket. 

Er wordt daarbij onderscheid gemaakt tussen: 

- Bedrijfsactiviteit specifieke modules waaruit gekozen moet kunnen worden en 

- Generieke modules die altijd aanwezig dienen te zijn. 

Per module zullen de vereiste en gewenste koppelingen worden aangegeven en daarvan afgeleid de 

eisen die dan gelden voor zo‟n koppeling. Het modulaire concept is weergegeven in onderstaand 

schema. 

Internet 

Financiële 

boekhouding 

Klanten 

administratie 



Een volledig aanbod van garagesoftware dient minimaal over de volgende basis functionaliteit te 

beschikken. Overigens kan dit een combinatie zijn van eigen software en software van derden. 

Bedrijfsactiviteit specifiek 

1. Voertuig in- en verkoop incl. voorraad of 

2. Werkplaats of 

3. Onderdelen inkoop en magazijn 

Generiek 

4. CRM (Klantbeheer) 

5. Financiën (boekhouding/facturen) 

6. Management informatie 

Wens: Daarnaast zijn in de werkgroep softwarecertificering de volgende wensen voor de toekomst 

aangegeven. Deze worden hier als separate modules bedoeld echter kunnen wellicht ook inhoud krijgen 

via aanvullende functionaliteit in voornoemde modules. 

1 Tankadministratie waarbij de gegevens van klanten en transacties kunnen worden 

uitgewisseld met de modules Financiën en CRM/Klantbeheer. 

2 Schadeherstel administratie welke zorgt voor de vereiste administratieve ondersteuning bij 

het afwikkelen van schadeopdrachten. 

3 Winterbanden administratie gericht op het beheren van de in bewaring gegeven 

winterbanden c.q. zomerbanden van klanten. 

4 Huurauto/vervangend vervoer administratie met ondersteuning voor het verifieren op ELENA, 

vastleggen van verreden kilometers, verzekering, staat van het voertuig en eventuele 

schade. In de toekomst kan gedacht worden aan een interface met een platform voor online 

elektronische uitwisseling van gereden kilometers op basis van vervoerstelematica. 



5 Website. De in het schema aangeven module website is nog niet nader gedefinieerd maar 

wel een aandachtspunt voor de nabije toekomst. De gegevensuitwisseling tussen de 

internetsite van een autobedrijf en de bedrijfssystemen worden steeds belangrijker. Dit zal 

gaan leiden tot het definiëren van eisen en interfaces tussen de buitenwereld van de 

internetsite en systemen van derden en de binnenwereld van het garagepakket. 

Tevens dienen er in de aangeboden garagesoftware omgeving de volgende gegevensets te aanwezig 

te zijn: 

- Klant : betreft private en rechtspersonen met hun contactgegevens 

- Bezit : betreft het voertuigbezit en de rol van de klant daarin actueel en historisch 

- Voertuig : betreft de volledige beschrijving van een voertuig, de waarde, 

kilometerstanden, foto etc. Het kan hier bijvoorbeeld ook gaan om voertuigen in 

consignatie of ingeruilde voertuigen die nog binnen moeten komen. 

- Transactie : alle soorten financiële transacties (nul tarief kan ook) die tussen een klant en 

het bedrijf dan wel tussen afdelingen binnen het bedrijf hebben plaatsgevonden 

- Normen: gedacht moet worden aan het geven van een melding als bijv.: een auto al x 

dagen in voorraad is, de omloopsnelheid van onderdelen, de voorraadwaarde die een 

bepaalde limiet overschrijdt, afschrijvingsnormen, etc. 

- Magazijn onderdelen : de in magazijn van de garage aanwezige onderdelen en 

materialen 

- Werkplaatscapaciteit : aantal hefbruggen, smeerkuilen etc. en technisch personeel 

- Organisatie : de personele organisatiestructuur en de identiteiten van de personeelsleden 

en de rollen en autorisaties die daaraan verbonden zijn 

Opbouw binnen modules 

De opbouw binnen de modules dient proces gericht te zijn. In de opzet van de gebruikersinterface van 

de module is dit de leidraad waarlangs functies worden gepresenteerd. In de documentatie van het 

pakket, waarin alle aspecten van de modules belicht worden, vormt het gehanteerde processchema een 

essentieel onderdeel. (zie ter illustratie (niet als norm bedoeld) het in- en verkoop proces) 

Een voorbeeld van een inhoudelijke consequentie van de procesbenadering is het volgende. In deze 

benadering gaat het om het vastleggen van een transactie vanaf de 1 e stap en/of interactie. Door dit te 

doen kan het bedrijf veel beter de sales-tunnel en de werkplaatsportefeuille bewaken en haar prestaties 

evalueren. In sommige pakketten kunnen alleen financiële transacties worden vastgelegd en dan pas 

als er een debiteurnummer is toegekend.(zie verder o.a. hoofdstuk 6 Basisinformatie/ transacties) 

Aanvullende modules versus inrichtingsprincipes 

Daarnaast kunnen uiteraard ook aanvullende modules worden aangeboden, zoals de brandstof, verhuur 

en schade. Deze modules vallen buiten het modulaire basispakket van het Programma van Eisen 2010 

en worden derhalve niet in de certificering meegenomen v.w.b. hun inhoud maar wel v.w.b. de wijze 

waarop deze onderdeel uitmaken van het geheel en de wijze waarop koppelingen zijn gerealiseerd. 



6 Basis informatie 

Vooruitlopend op de ontwikkeling van sectorstandaarden is het in dit hoofdstuk beschreven datamodel 

qua structuur een voorbeeld. De aanwezigheid van de genoemde gegevenselementen is een eis, 

uitgezonderd de gegevenselementen die expliciet als wens benoemd zijn. 

Dit hoofdstuk beschrijft de minimaal benodigde basis informatie die per gegevenset (zie vorig hoofdstuk) 

benodigd is. In de beschrijving zullen we per gegevenset ingaan op: 

- De identificerende gegevens van de set 

- De beschrijvende gegevens binnen de set 

- Verwijzing naar eventueel beschikbare standaarden 

In dit hoofdstuk zal per set worden aangegeven welke rubrieken (beschrijvende gegevens) aanwezig 

zijn. Van belang is om te weten dat deze beschrijving niet een blauwdruk van een datamodel is doch 

slechts een conceptuele aanzet daartoe. Door middel van de oprichting van de stichting Standaardisatie 

en Informatiebeleid Mobiliteit Sector (SIMS) in oktober 2009 tracht de branche de komende jaren 

geleidelijk aan tot consensus te komen over een datamodel voor de sector. Voor de eisen inzake SIMS 

worden deze relevant zodra deze definitief zijn vastgelegd. Het is nadrukkelijk de wens om, na 

vastlegging van de gedefinieerde standaards, hiermee te integreren. 

Een illustratie van een conceptueel model treft u hieronder aan. (NB. Onderstaand voorbeeld is niet 

formeel maar een illustratie welke gegevens er onderkend kunnen worden) 

Zoals in de aanhef staat aangegeven vormen de hierna genoemde gegevensets slechts een minimale 

en noodzakelijke basis. Daar waar c.q. wanneer operationele standaards aanwezig zijn zullen die 



zoveel mogelijk worden aangegeven. Het betreft hier een beperkte weergave van een logisch 

datamodel waarbij geen eisen worden gesteld aan de technische/fysieke structuur. Standaards zijn 

momenteel richting gevend. Via SIMS zullen deze specifieker worden voorgeschreven. 



6.1 Klant 

Deze gegevens zullen op verschillende manieren identificeerbaar zijn, aangezien er vanuit verschillende 

modules naar de klant gekeken wordt. Per type klant, rechtspersoon of natuurlijk persoon, worden 

gegevens wel/niet gevuld. De eigenbedrijfsvestigingen worden ook opgenomen in deze tabel. 

ID 1 

Klantnummer 

ID 2 

Postcode 

Huisnummer 

Achternaam 

Eerste voorletter 

ID 3 

Geboortedatum 

Geslacht 

Achternaam 

ID 4 

KvK-nummer (indien zakelijk) 

Overige gegevens 

Voorletters 

Titels leading 

Titels trailing 

Tussenvoegsels; 

Adres (o.b.v. “qualifier”; Privé, Zakelijk, Factuur, Post, Vakantie) 

o Soort adres 

o Van datum 

o Tot datum 

o Postcode 

o Straat;(afgeleid bij gebruik PC-tabel) 

o Huisnummer 

o Huisnummertoevoeging; 

o Woonplaats; (afgeleid bij gebruik PC-tabel) 

o ISO landcode 

o Land; 

o Mail blokkade 

Touch point (op basis van “qualifier”, te weten; Privé, Zakelijk) 

o Soort (vaste telefoon, mobiele telefoon, Faxnr, email, etc) 

o Opt-in datum 

o Telefoonnummer (standaard internationaal vastgelegd (0031=Nederland); 

o E-mail adres 

o Webadres 

Wens: Beroep (ongestructureerd) 

Wens: Hobby (ongestructureerd) 

Betaalwijze; (Bank, Contant, Krediet) 

o Indien Bank/giro het nummer.; 

Kortingspercentage (te bepalen op uren, onderdelen en werk derden). 

Afwijkende financiële afspraken 

Debiteurnummer/Crediteurnummer (indien er een financiële transactie heeft plaatsgevonden) 

Bankrekeningnummer 

Wens: IBAN code 

Wens: Gezinsleden (aantal) op zelfde adres 



Wens: E-Factuur (j/n) 

Wens: Opt-in datum E-factuur 

Rijbewijsnummer; 

o Scan-aanwezig (j/n) 

Paspoortnummer; 

o Scan-aanwezig (j/n) 

KVK Nummer van de werkgever (enkel in geval van een werknemer) 

KvK-nummer (in geval van rechtspersoon) 

BTW-nummer; 

BTW-nummer buitenland 

Klantsoort Zakelijk (KvK verplicht), Privé, Lease/financiering 

Klantgroep 

Datum laatste contactmoment 

6.2 Bezit 

Het bezit van een motorvoertuig wordt hier geregistreerd. Ook de historie wordt bewaard zodat is na te 

gaan welke voertuigen een klant heeft (gehad). 

ID 1 

Klantnummer 

Kenteken* 

Chassisnummer* 

Meldcode* 


Datum deel 2 * 

Datum laatste contact indien geen datum deel 2. 

Rol inzake bezit (meerdere mogelijk) (eigenaar, houder, bezitter, berijder, verzekerde, 

verzekeringnemer, gefinancierde, financierder) 

In bezit tot 

Verwacht in voorraad** 

In Voorraad** 

Uit voorraad** 

Gereserveerd* 

Consignatie** 

Inkoopprijs** 

Verkoopprijs** 

Taxatie waarde 

Vrije tekst (ongestructureerd) 

*RDW Notatie 

**Indien eigen bedrijf is eigenaar/bezitter, eigen bedrijf is dus ook opgevoerd als klant 

6.3 Dienst 

De aan het bezit gekoppelde dienstverleningsafspraken zijn hier geregistreerd. Ook de historie wordt 

bewaard zodat is na te gaan welke diensten een klant wanneer had. Eerste invullingen zijn gegeven 

maar andere type diensten zijn toe te voegen binnen dezelfde structuur. 



Voertuigdienst-ID 

Soort voertuigdienst 

Indien garantie; dan garantiecode (BovagBasis, BovagAanv, BovagPech, MerkGarantie etc) 

(meerdere garantiecodes/vormen zijn mogelijk, niet gelimiteerd) 

o Vanaf datum 

o Tot datum 

o Naam garantie; 

o Omschrijving garantie; 

o Dekking garantie (minimaal 9 vrije tekst regels); 

Wens: Indien verzekering; dan verzekeringscode (Voorbeeld: WA, WA+, WA Casco etc.) (meerdere 

codes/vormen zijn mogelijk, niet gelimiteerd) 

o Vanaf datum 

o Tot datum 

o Naam verzekering; 

o Omschrijving ; 

o Verzekeringsmaatschappij; 

o Tussenpersoon; 

o Premievervaldatum 

o Polisnummer-actueel 

Wens: Indien financiering; dan financieringscode (Financial, Operational, Privé) 

o Lease/financieringmaatschappij; 

o Contractnummer financiering actueel 

o Einde financieringscontract datum 

o Einde financieringscontract km-stand 

6.4 Voertuig 

Naast de technische identificatie is het voor de gebruiker van groot belang dat hij/zij zelf aan het 

voertuig gerelateerde gegevens toe kan voegen/aanpassen. Per voertuig dienen dan ook minimaal de 

volgende elementen vastgelegd kunnen worden: 

ID 1 

Kenteken* 

ID 2 

Chassisnummer* 


Datum afgifte deel 1a;* 

Datum eerste toelating;* 

Bouwjaar indien afwijkend* 

Merk* 

Model 

Modeljaar 

Merk-model-type code (ETG);* 

Uitvoering 

Gasinstallatie* 

Fabrieksgarantie eindigt op 

Kleur carrosserie;* 

Kleur interieur; 

Wens: SCM certificaat klasse; 

Wens: Conformiteitverklaring AIRCO (incl. datum); 

APK datum; 



APK datum volgende APK (automatisch berekenen); 

APK afkeur- en adviespunten (N keer) 

Wens: Voertuig foto's (max. 10); 

o Datum laatste wijziging foto’s 

Wens: Voertuig film 

o Datum laatste wijziging film 

Aanwezige accessoires; (VGS standaard?) 

Marge auto* 

BPM voldaan 

Bruto BPM Oorspronkelijk* 

BPM Oorspronkelijk datum* 

BPM rest 

Laatst afgelezen KM stand 

Datum Laatst afgelezen Km-stand 

Wens: Laknr 

Wens: Kleurbenaming 

Wens: Radiocode 

Wens: ECU-code 

Wens: Sleutelcode 

Wens: Scan kentekenbewijs aanwezig (j/n) 

Trekhaak (j/n) 

*RDW notatie 

6.4a Voertuig type gerelateerde gegevens 

Bij een voertuig zijn een aantal gegevens gerelateerd aan het type. Dit type kan op meerdere autos van 

toepassing zijn waarbij de gegevens het zelfde kunnen zijn. 

ID 1 

Merk-model-type code (ETG);* 

Datum vanaf 

Uitvoering; 

Interieur 

Handelsbenaming 

Merkspecifieke model benaming 

Voertuigclassificatie*( 

o Omschrijving: Codering voor de classificatie waartoe een voertuig behoort. 

o De volgende waarden zijn van toepassing: 

o 1 = personenauto 

o 3 = bedrijfsauto 

o 5 = bedrijfsauto met koppeling 

o 6 = aanhangwagen (zonder de detaillering van 8 en 9) 

o 7 = oplegger 

o 8 = autonome aanhangwagen (was vroeger 6) 

o 9 = middenasaanhangwagen (was vroeger 6) 

o 12 = motorfiets 

o 13 = motorfiets met zijspan 

o 18 = driewielig motorvoertuig (wielen symmetrisch t.o.v. de lengte-as). 

Cataloguswaarde; 

Brandstofsoort; * 



Zuinigheidslabel* 

Brandstofverbruik 

o ECE stad 

o ECE snelweg 

o ECE gemiddeld 

Ledig gewicht; * 

Max. gewicht (GVW); * 

Motorcode;* 

Cilinderinhoud;* 

Vermogen in kW;* 

CO2emissie* 

Transmissie;* 

Wens: VersnellingsBAKcode 

Wens: BACcode (banden) 

Wens: Smeermiddelen 

o Motor 

o Remmen 

o Versnellingsbak 

Wens: Recall’s ( >=1) 

o Van datum 

o Omschrijving 

Distributieriem vervangen bij km 

Onderhoudschema 

*RDW Notatie 

6.5 Gebruikers 

De set gebruikers bevat de noodzakelijke gegevens om een gebruiker van het systeem te identificeren 

en autorisaties te verlenen. Het toekennen van autorisaties geschiedt via de betreffende module. 

Gescheiden hiervan, of gekoppeld hieraan, kunnen ook andere gegevens van de gebruikers worden 

vastgelegd, zoals beschikbare uren per week ten behoeve van planningen. 

ID 

Personeelsnummer 

ID 2 

Achternaam 

Eerste voorletter 

Geboorte datum 

Geslacht 


Voornaam; 

Initialen 

Tussenvoegsels; 

BSN(SoFi)nummer; 

Rijbewijsnummer; 

Rijbewijs geldig tot 

Scan-aanwezig (j/n) 

Paspoortnummer; 

Paspoort geldig tot 

Scan-aanwezig (j/n) 

Contactpersoon; 



Adres(o.b.v. “qualifier”; Privé, Zakelijk, Factuur, Post, Vakantie) 

Soort adres 

Van datum 

Tot datum 

Postcode 

Straat;(afgeleid bij gebruik PC-tabel) 

Huisnummer 

Huisnummertoevoeging; 

Woonplaats; (afgeleid bij gebruik PC-tabel) 

ISO Landcode 

Land; 

Mail blokkade 

Touch point (op basis van “qualifier”, te weten; Privé, Zakelijk) 

Soort (vaste telefoon, mobiele telefoon, email, etc) 

Opt-in datum 

Telefoonnummer (standaard internationaal vastgelegd (0031=Nederland); 

E-mail adres 

Uren per week 

Login naam 

Wachtwoord 

Geblokkeerd (J/N) 

Geblokkeerd datum 

Huidige functie 

KvK-nr Standplaats (n.b. eigen bedrijfsvestigingen opgenomen in klantentabel) 

6.5a Kwalificatie 

ID 

Personeelsnummer 

Soort kwalificatie 

Conform branchecoderingen Innovam 

Keurmeester RDW 

Etc. 

Kwalificatienummer (i.g.v. APK, keurmeesternummer) 

Datum geldig vanaf 

Datum geldig tm 

6.6 Onderdelen 

De set “Onderdelen” is bedoeld om zowel de onderdelen als de verbruiksartikelen zoals olie etc.te 

registreren. 

ID 1 

UAN-code 

ID 2 

Artikelnr-leverancier 

Volgnummer artikel 

Leveranciercode 




Artikelomschrijving; 

Onderdelengroep; 

Actueel aantal in voorraad 

Aantal in Bestelling 

Minimum voorraad 

Levering per (Stuk/Liter/…) 

Eenheidsprijs inkoop 

Eenheidsprijs verkoop; 

Actiedatum van 

Actiedatum tm 

Kortingscode; 

BTW-code; 

Factuurcode (extra kosten bijv. afvalverw.); 

Verpakkingseenheid (aantal stuks per verpakking; 

Merk onderdeel; 

Leverende grossiers; (op basis van “qualifier” ; voorkeur, back-up) 

Datum bestelling/levering; 

Voorraadlocatie; 

In consignatie; (j/n) 

Embalage; (j/n) 

Emballage bedrag; 

6.6a Kruistabel Artikelnummers 

Deze tabel is om duidelijk te maken dat er bij 1 intern artikelnummer verschillende leveranciers zijn die, 

ieder onder hun eigen artikelnummer, het zelfde item kunnen leveren. Bij het doen van bestellingen is 

deze van belang om van de verschillende leveranciers de prijs etc op te vragen. 

Daarbij moet rekening worden gehouden dat per leverancier, voor een zelfde artikel, ook meerdere 

artikelnummers gevoerd worden. 

ID 1 

Artikelnummer leverancier 

Intern artikelnummer 

UAN-code 



ID 2 

Intern artikelnummer 

Artikelnummer leverancier 

UAN-code 



6.7 Transactie 

ID 1 

Klantnummer 

Datum 



Tijd 

Volgnummer 

ID 2 

Kenteken of Chassisnummer 

Datum 

Tijd 

Volgnummer 

ID 3 

Factuurnummer 


Transactie_id 

Soort transactie 

Bijv: In/verkoop voertuig, werkopdracht, magazijnverkoop, magazijn intern, financiering, garantie, 

vervangend vervoer, etc. 

Datum/tijd 

Foutmelding 

Functie 

Totaal Bedrag 

Debet/Credit 

Transactie detailregel (meerdere mogelijk) 

TD volgnummer 

Artikel/Activiteitnummer/boekingscode/kentekennummer 

Aantal (bij activiteiten = minuten) 

Detail bedrag 

Omschrijving 

Personeelsnr. Uitvoering (N keer) 

Datum facturering 

Soort betaling 

Bijv. contant, pin/chip , op rekening 

Personeelsnr. financieel 

6.8 Normen 

Wens: Deze set bevat de gegevens op basis waarvan een actie door het systeem kan worden 

uitgevoerd.Als actie kan gedacht worden aan het geven van een melding bij minimum voorraad etc. 

Iedere module kent zijn eigen normen c.q. acties die daar uit voortvloeien. 

ID 1 

Normnummer 


Omschrijving norm 

Ingangsdatum Norm 

Einddatum Norm 

Normwaarde 

Actie als (groter dan, kleiner dan, gelijk) 

Bandbreedte actie in % c.q. aantal 



Soort actie omschrijving 

Norm-uitschakelen (j/n) 

Wens: Deze normen betreffen een tabel welke onderhouden kan worden middels deze standaard 

structuur. Hiermee kan de gebruiker zelf de norminstellingen beheren voor zijn of haar bedrijf. Het is 

afhankelijk van de bedrijfssoftware en de inrichting daarvan welke normen kunnen worden toegepast 

(oftewel zijn geïmplementeerd). 

Voor het inplannen van werkopdrachten wordt uitgegaan van monteurs, niet van bruggen. 

Daarnaast zijn er normatieve basisgegevens nodig voor de werkplaats. Het gaat hier om de volgende 

zaken: 

Opvoeren coderingen 

De gebruiker kan diverse werkcoderingen opvoeren, per code dienen de volgende elementen 

ingevoerd te worden: 

Code; 

Omschrijving; 

Flat-rate (uren). 

Opvoeren recepturen 

Een receptuur is een bundeling van een aantal code‟s die samen een standaard activiteit 

vormen. 

De gebruiker kan diverse recepturen opvoeren, per receptuur dienen de volgende elementen 

ingevoerd te worden: 

Receptuur; 

Omschrijving; 

Code(-s); 

Code omschrijving. 

Importeren ROB coderingen 

Er dient een mogelijkheid te zijn om de actuele standaard ROB-codes te importeren. 

6.9 Formaat beschrijving 

Bij het vastleggen van de gegevens dient bij een aantal veel voorkomende rubrieken rekening te 

worden gehouden met het format waarin dit gebeurd. 

In onderstaande opsomming zijn de belangrijkste opgesomd. 

Datum DD/MM/JJJJ 

Tijd uu/mm/ss 

Jaar JJJJ 

Geslacht M/V 

Postcode 9999XX 

Ja of Nee J/N 

Landcode ISO Landcode 

Telefoon 0031 123 456789 

Foto‟s, films en scan‟s worden in een aparte media map opgeslagen. Dit dan wel met, afhankelijk van 

het type bron, als ID het documentnummer of het Voertuig-ID. 



7 Module Beschrijving 

7.1 Algemeen 

Als er melding wordt gemaakt van opvragen en/of rapportage wordt bedoeld dat de gegevens op het 

scherm, middels een afdruk of via export naar Officepakketten worden getoond. 

Bij het maken van rapportages zal de gebruiker worden ondersteund door de mogelijkheid om 

zelfstandig te kunnen kiezen welke velden er worden getoond en welk sjabloon daarbij gebruikt wordt. 

Van iedere actie binnen de modules wordt in een logfile bijgehouden welke actie wanneer en door wie is 

uitgevoerd. Bij mutaties op stamgegevens wordt in aanvulling op de logfile bij het stamgegeven 

vastgelegd wie het stamgegeven het laatst gemuteerd heeft. Deze informatie wordt getoond als het 

stamgegeven wordt getoond. 

De hier genoemde functionaliteiten zijn niet alles omvattend of in detail weergegeven. Het is aan de 

softwareleverancier om hier praktisch mee om te gaan. In het hoofdstuk 6 “Basisinformatie” treft u de 

beschrijving van de (minimale set) gegevens aan die door de functionaliteiten binnen het pakket 

gebruikt kunnen worden. 

De BOVAG stelt op termijn “Elektronische Formulieren” beschikbaar. Het gebruik van deze formulieren 

bij de relevante stappen in het proces geldt nu niet als basiseis. Het is nadrukkelijk de wens om, zodra 

de interfacebeschrijving bij SIMS gedefinieerd is en beschikbaar is voor de markt, dit in de software te 

integreren. Daarnaast is het de gebruiker als alternatief mogelijk om door middel van aanpasbare 

sjablonen vorm te geven aan de formulieren. 

7.2 Relatiebeheer 

7.2.1 Algemeen 

Als de klant is geïdentificeerd worden afhankelijk van de functie de relevante info getoond. 

Zaken die getoond worden zijn o.a. laatste werkplaats bezoek incl. verrichtingen, openstaande 

rekeningen, offerte, garantieafspraken. 

De module relatiebeheer laat de klant centraal staan in de administratie. In deze module worden alle 

relevante gegevens van relaties vastgelegd. Een relatie kent verschillende verschijningsvormen. 

Zo dient er, afhankelijk van de module waarin gewerkt wordt, onderscheidt te worden gemaakt in Klant 

(Debiteur)) , Suspect, Prospect, Medewerker en Leverancier( Crediteur). 

Wens: Het systeem ondersteunt het registreren van familiebanden tussen relaties zoals partner, kind 

als deze op hetzelfde adres gevestigd zijn. 

Afhankelijk van de verschijningsvorm van een relatie is het geheel, niet of slechts gedeeltelijk mogelijk 

gegevens in te voeren/muteren of op te vragen. Dit wordt geregeld in de autorisatie binnen het systeem. 

Bij het invoeren van een nieuwe relatie wordt op basis van postcode/huisnummer gekeken of er 

meerdere relaties op dat adres bekend zijn. Zo ja, dan worden deze getoond. Eventueel kan een 

selectie worden gemaakt van een specifieke relatie uit de getoonde lijst. Dit om te voorkomen dat 

eenzelfde relatie onbewust meerdere malen wordt opgevoerd. 

Hieraan gerelateerd zal het systeem voorzien in een “ontdubbelings” functie waarbij, na bevestiging van 

de gebruiker, dubbele relaties die feitelijk één en de zelfde zijn, samen worden gevoegd onder één 

nummer met behoud van alle relevante en fiscale gegevens. 



Privacy aspecten 

Om privacy reden is het van belang om onderscheid te maken tussen de verschillende statussen van 

personen in relatie tot uw bedrijf. 

Hierbij is een suspect een (rechts)persoon waar voorheen nog geen contact mee is geweest. Een 

prospect heeft wel met uw bedrijf contact gehad, maar dit heeft niet geleid tot een order. Van een klant 

is sprake als er een financiële transactie heeft plaatsgevonden. Bij de eerste keer dat dit gebeurt wordt 

een debiteurnummer verbonden aan de klant. 

Daarbij dienen klantcontacten met datum / tijd vast gelegd te kunnen worden in relatie tot de betreffende 

persoon. Indien een klant een mail blokkade of een registratie in het bel-me-niet register heeft dient 

deze blokkade te worden vastgelegd en te kunnen worden onderhouden. 

In geval van email of telefoonnummer vastlegging is het tevens belangrijk om de toestemming voor 

gebruik van email en mobiel telefoonnummer vast te leggen (opt-in). Hiervoor dient er expliciet een 

reminder op het scherm te staan die aangeeft dat om toestemming gevraagd moet worden als het om 

het registreren van dit soort gegevens gaat. 

Hiermee is de informatie aanwezig om een zorgvuldig privacy beleid richting uw (potentiële) klanten te 

voeren. 

7.2.2 Verkrijgen suspectgegevens 

Middels deze functionaliteit is het mogelijk om gegevens over NAW met en zonder voertuigbezit te 

importeren. Het gaat om (rechts)personen die nog geen klant zijn bij het bedrijf. 

Deze gegevens kunnen zowel bestandsgewijs als middels een systeemkoppeling met een externe bron 

verkregen worden. 

Bij het opslaan van de gegevens wordt een “suspect” indicatie toegevoegd. Hiermee kan vanuit privacy 

regels rekening worden gehouden met het gebruik. Immers, er is geen sprake van een relatie. 

7.2.3 Verkrijgen prospectgegevens 

Middels deze functionaliteit worden gegevens die ingevoerd worden in de eigen website, 

afspraaksystemen, elektronische proefrit en offerte formulieren, opgeslagen. Hier is wel sprake van een 

relatie maar nog niet van een klant. 

Deze gegevens kunnen zowel bestandsgewijs als middels een systeemkoppeling met een interne of 

externe bron verkregen worden. 

7.2.4 Beheren van klantgegevens 

Aangezien er sinds 1 maart 2007 geen nieuwe data meer kan worden gekregen van de RDW, is de 

retailer c.q. het autobedrijf de belangrijkste bron geworden voor de gegevens over klanten en hun 

actuele voertuigbezit. De kerngegevens zijn in onderstaand overzicht weergegeven. 

Nu is het van belang dat deze gegevens actueel blijven. Om dit te ondersteunen dient het systeem : 

- Bij een online real time raadpleging van bij externe bronnen aanwezige gegevens dient eerst 

invoer plaats te vinden op basis van de velden; kenteken, achternaam (of bij bedrijven KvKnr), 

postcode, huisnummer, datum deel 2 of datum laatste contact met optioneel geslacht en 

geboortedatum. 



- Er een periodieke validatie plaatsvindt van alle gegevens in het overzicht bij externe bronnen. Dit 

impliceert een bestand extraheren, dit aanbieden aan een validatie service en het retour bestand 

beoordelen op mutaties en die verwerken in klantbestanden binnen het garagepakket c.q. crmpakket 

wat daaraan is gekoppeld. 

- Een verrijking kan plaatsvinden met aanvullende voertuigdata als onderdeel van de voornoemde 

2 punten. 

Rollen : Een klant, privé of zakelijk, kan een verschillende rol vervullen in relatie tot een voertuig. Hierbij 

wordt in ieder geval gedacht aan; houder, berijder, eigenaar, fleetmanager, financier, verzekeraar, etc. 

Deze rol dient voor CRM onderscheiden te worden. 

Op basis van deze rol kunnen ook de zogenaamde “touch points” (adres, telefoon, email, etc.)per rol 

worden bijgehouden in plaats van per persoon. Immers, een persoon kan meerdere rollen hebben en 

dus per rol (eigenaar, bestuurder, administratieklant /P&O /Fleetmanager Manager) anders benaderd 

willen worden. 

Separaat aan de rolindeling is er een aparte rubriek waarin de klantgroep kan worden vastgelegd. 

Bij de klantgegevens kan worden geregistreerd hoe de (nieuwe) klant in contact is gekomen met het 

bedrijf. ingegeven worden 

De klantgroepen en contact-oorsprong (advertentie, mond tot mond etc) worden gestuurd via tabellen 

die door de gebruiker onderhouden wordt. 

Wens; Relaties: Een (rechts)persoon kan een relatie hebben met een andere (rechts)persoon. Van 

belang is dat deze relatie kunnen worden vastgelegd. Hierbij wordt in ieder geval gedacht aan; 

Bedrijfsonderdeel van, Bedrijfsbestuurder van, etc. 

(On)gestructureerde informatie: Naast de voornoemde gestructureerde / gestandaardiseerde gegevens 

zijn er ook gegevens die als vrije tekst worden opgeslagen. 

7.2.5 Raadplegen klantgegevens 

Bij functies waarbij een “relatie" betrokken is ondersteund het systeem dit door, ongeacht de 

verschijningsvorm (Klant, Debiteur, Leverancier, Gezinslid, Berijder etc) , de relatie opvraagbaar te 

maken op nummer, kenteken, naam (ook gedeeltelijk) , postcode. Een selectielijst wordt aangeboden 

indien niet uniek geïdentificeerd kan worden. 

7.2.6 Klanten en signalen 

Aan een relatie kunnen agenda-items worden gekoppeld tbv gemaakte afspraken voor een proefrit, 

werkplaats etc. Hierop kan worden gerapporteerd en gesignaleerd. Signalen worden verstuurd naar het 

aan de actie gekoppelde e-mailadres van de gebruiker. Er kan ook de naam van een andere gebruiker 

worden opgegeven. Signalen zijn ook overall opvraagbaar. 

7.2.7 Doelgroep selecties 

Naast het opvragen op het scherm kunnen over de relaties rapportages en mailings vervaardigd 

worden. De selecties hierop zijn gebonden aan de module van waaruit dit wordt aangeroepen. Zo kan 

er over de werkorders een selectie worden gemaakt van alle klanten die van datum/tm datum een 

afspraak hebben gemaakt. Een andere doelgroep kan een subset van klanten zijn die binnen een x 



periode een APK keuring aan hun voertuig moeten uitvoeren. Of klanten met een laatste factuurdatum 

ouder dan x dagen. 

7.2.8 Mailing samenstellen 

Het systeem ondersteund het vervaardigen van mailings. Voor het aanmaken van een mailing worden 

de geselecteerde contactgegevens gekoppeld aan een sjabloon voor de mailing. Dit zijn niet enkel 

persoonlijke brieven, ook SMS en e-mail behoren tot de mogelijkheden. 

Er kunnen verschillende sjablonen worden voorbereid en worden gewijzigd. 

Het systeem ondersteund het samenvoegen van adressen. Indien de familienaam en het adres met 

elkaar overeenkomen kan er voor gekozen worden om 1 adressticker te vervaardigen met de aanhef 

„Familie”. 

Wens: 7.2.9 Contact / response vastleggen 

Per mailing kan de response worden gemeten en worden opgevraagd. 

7.3 In en verkoop 

7.3.1 Prospect en proefrit 

Registreren (zie 7.2.3) 

Van een prospect worden, indien de prospect onbekend is, de relevante gegevens ingevoerd. Hieronder 

wordt verstaan de NAW en contactgegevens zoals e-mail, (mobiel)telefoonnummer. Is de prospect 

reeds bekend dan kunnen de historie gegevens worden opgevraagd. Zoals bezoek-, afspraak-, 

betalingsgegevens etc. 

Nieuwe afspraken kunnen worden geregistreerd in het systeem. 

Proefrit 

Voor het maken van de proefrit moet het mogelijk zijn om van de BOVAG Wens: Elektronische 

formulieren gebruik te maken. Het aanvullen/wijzigen van prospectgegevens, het scannen en opslaan 

van de ID wordt in deze module ondersteund. 

Het systeem is in staat om het ID, zoals het rijbewijs, extern te valideren. 

7.3.2 Offerte 

De offerte wordt vervaardigd op basis van het BOVAG Wens: Elektronische offerteformulier. De 

beschikbare gegevens van de klant en het voertuig worden door het systeem opgehaald en in het 

formulier geplaatst. 

Bij het opstellen van de offerte wordt gebruik gemaakt van de eventueel aanwezige taxatiegegevens of 

handmatig ingevoerde inruilbedragen. 

De offerte wordt opgeslagen bij de relatie. In de agenda wordt automatisch een notitie gemaakt. Op 

deze notitie zal het systeem een signaal afgeven als de termijn, zoals ingegeven bij de 

beheergegevens, verstreken is. 



Wens: Naast het vervaardigen van de offerte biedt het systeem de mogelijkheid om de garantiepas, 

mobiliteitspas, verzekeringen financieringdocumenten te vervaardigen. 

7.3.3 Koopovereenkomst 

Algemeen 

Voorafgaande aan de daadwerkelijk verkoop kan een koopovereenkomst worden geregistreerd op basis 

van de BOVAG Wens: Elektronische koopovereenkomst. Als er in een eerder stadium een offerte is 

aangemaakt worden de gegevens uit de offerte als basis gebruikt. 

Wens: De financiële gegevens worden doorgesluisd naar de financiële administratie als te verwachte 

verkopen in een bepaalde periode. 

Afronding koopovereenkomst 

Na het sluiten van de koopovereenkomst is de gebruiker in staat om, onder vermelding van de 

afleverdatum, via het systeem opdrachten voor de werkplaats in te voeren (Rijklaar maken, in- 

/ombouwen), eventuele bestellingen bij het magazijn te plaatsen en checklists te vervaardigen. 

Alle gegevens worden gekoppeld aan de relatie. 

7.3.4 Inkoop / Inruil 

In dit onderdeel is er veelal sprake van de het bevragen van externe functionaliteit. Dit stelt veel eisen 

aan de interfacing met dergelijke systemen. 

BPM Calculator 

In veel gevallen zal hier sprake zijn van externe functionaliteit om voor de import/export van voertuigen 

de BPM te berekenen. Hierbij dient rekening gehouden te worden met door de Douane erkende 

providers. 

Hiervoor dienen de noodzakelijke gegevens van het voertuig te worden ingevoerd (merk/model/type 

bouwjaar/kilometers etc) waarna de functie wordt uitgevoerd. Dit geldt voor personenauto‟s en 

motorrijwielen die vanaf 1 januari 1993 op NL kenteken zijn gezet. 

De BPM calculator wordt gebruikt bij: 

Bij de inkoop van een voertuig controleren of er over het voertuig BPM afgedragen is; 

de verkoop van een voertuig waarvoor eerder nog geen BPM afgedragen is om te bepalen welk 

resterend BPM bedrag verschuldigd is; 

de import van een auto om het verschuldigde (resterende) BPM bedrag te bepalen; 

de export van een auto om het eventueel terug te vorderen (resterende)BPM bedrag te bepalen. 

Het pakket biedt de mogelijkheid om deze gegevens bij het voertuig op te slaan (indien aanwezig in de 

database). 

Taxatierapport 

Bij het vervaardigen van het BOVAG Wens: Elektronische taxatierapport wordt met behulp van de 

beschikbare gegevens van een klant en het voertuig, het formulier vervaardigd. 

Wens: Hierbij wordt de waardebepaling volgens een door de leverancier/klant geselecteerde provider 

uitgevoerd en getoond op het formulier. De KM stand wordt via NAP opgevoerd, gecontroleerd en 

vervolgens geretourneerd aan het garagebedrijf. Minimaal de laatste 5 standen worden getoond. Waar 

nodig kunnen gegevens handmatig worden ingevoerd. De gegevens worden t.b.v. de historie aan de 

klantgegevens gekoppeld. 



Checklist 

Alvorens een voertuig wordt geaccepteerd kan er een controle worden uitgevoerd. 

Deze controle gaat aan de hand van een standaard checklist. Hierbij gebruikt het systeem een sjabloon 

dat door de gebruiker kan worden aangepast. 

De bevindingen van de checklist worden ingevoerd in het systeem. De checklist + bevindingen worden 

opgeslagen in het systeem en kunnen op basis van kenteken of VIN worden opgeroepen. 

Inname van een voertuig 

Indien er sprake is van inruil kan de inleverdatum van het voertuig worden vastgelegd. Indien er 

bevindingen zijn die het inschakelen van de werkplaats noodzakelijk maken kan een werkplaatsorder 

worden aangemaakt. In geval het een nieuw geleverd voertuig betreft kan de werkplaatsorder “rijklaar 

maken” worden opgevoerd. 

Bij het in de bedrijfsvoorraad opnemen van het voertuig dient het systeem de gebruiker te ondersteunen 

middels het kunnen activeren van ORB. De datum waarop dit gebeurd is bepalend voor latere 

signalering. De indicatie Marge/BTW auto, zoals door de gebruiker ingegeven, wordt geregistreerd. 

Voordat de gegevens definitief worden gemaakt kan de gebruiker deze nog aanpassen. 

Er kan een vrijwaring voor de verkopende partij worden vervaardigd. 

Het in bedrijfsvoorraad nemen resulteert in een transactie richting de voorraad en financiële modules. 

Indien een voertuig in consignatie is genomen heeft dit geen financiële transactie tot gevolg. 

De gegevens van deze transactie worden, indien van toepassing, bij de relatie in de historie verwerkt. 

Indien een voertuig langer dan in de beheertabel is opgegeven in voorraad is, komt hiervan een 

signalering. 

Wens: Het is mogelijk op met een druk op de knop een herwaardering voor een gekentekend voertuig 

uit te voeren. 

Voertuigverrijking 

Om voertuiggegevens automatisch, of incidenteel, te verrijken zal het systeem de mogelijkheid bieden 

om voertuiggegevens via een door de klant geselecteerde provider en op basis van het kenteken Wens: 

of VIN op te halen en te verwerken. 

Te koop aanbieden 

Bij het in voorraad nemen van een voertuig ondersteund het systeem om beeldmateriaal (min 10 x) en 

videobeelden van het voertuig op te slaan. 

Wens: Er is een interface aanwezig om een voertuig dat in voorraad is/wordt genomen, door de 

gebruiker te plaatsen op een of meerdere internetsites. 

Wens: Het systeem bezit de functionaliteit om prijskaarten te vervaardigen waarbij een keuze uit 

verschillende lay-outs mogelijk is. In ieder geval dienen lay-outs aanwezig te zijn om een prijskaart voor 

een specifieke auto te vervaardigen, een overzicht per merk, categorie etc. 

Voertuig voorraadtaxatie 

Het systeem voorziet in de mogelijkheid om via een overzicht alle voertuigen in voorraad (excl. 

consignatie) weer te geven met de inkoopwaarde en de opgegeven verkoopwaarde. Voor 

gekentekende voertuigen kan een optie worden meegegeven om een hertaxatie uit te voeren. Deze 

optie kan de gebruiker naar behoefte aan/uit zetten. 



7.3.5 Verkoop 

Algemeen 

Het systeem ondersteunt het verwerken van kosten en kortingen in verschillende categorieën op de 

factuur zoals op de verkoopprijs, inruilprijs, rijklaar maken, leges, uren, materiaal, accessoires etc. 

Het systeem verwerkt de berekening van de BPM op basis van de laatste wettelijke inzichten. Tevens 

zal op basis van de gegevens die bij de relatie zijn ingevoerd BTW op de juiste wettelijke wijze worden 

berekend. Het systeem ondersteund het verschil in marge en BTW voertuigen. 

Eindcontrolelijst 

Het systeem kan een eindcontrolelijst vervaardigen waarop de relevante voertuig-, klanten 

berijdergegevens worden getoond en de gemaakte afspraken. 

Factuur 

De factuur wordt vervaardigd op basis van het BOVAG Wens: Elektronische factuurformulier. (Zie 

eerdere opmerking over de BOVAG elektronische formulieren) 

De gebruiker heeft de vrijheid om per factuur vrije tekst in te voeren. Op de factuur staan minimaal de 

Klantgegevens, Autogegevens, specificatie van kosten en kortingen, verzekeringen, garanties en de 

naam van de verkoper. 

Als gevolg van de factuur wordt de voorraadpositie bijgewerkt (onderdelen/voertuigen) en financiële 

transacties doorgeboekt. Indien facturatie en levering samenvallen wordt als gevolg van de factuur de 

voorraadpositie bijgewerkt (onderdelen/voertuigen) en financiële transacties doorgeboekt. Wanneer er 

gecorrigeerd wordt moet dat in de boekingsperiode van de correctie, 

Het systeem ondersteund de functionaliteit voor het aanmaken en verzenden van elektronische 

facturen. Voor externe partijen waar een interface mee is zal dit bepaald worden door de interface. 

Minimaal dient het mogelijk te zijn de factuur in PDF aan te maken en via email te verzenden. 

Garantie 

Als er sprake is van garantie (opgegeven door de gebruiker) wordt bij de factuur ook de daarbij 

behorende documenten afgedrukt, voorzien van de klant en voertuiggegevens. Waar gewenst wordt 

een garantie- en/of mobiliteitspas vervaardigd. 

Het systeem reageert met een melding als het verlengingsmoment is genaderd met het aantal dagen 

zoals opgegeven bij de beheergegevens. 

Inruil/vrijwaring 

Als er van inruil sprake is worden de aanwezige taxatiegegevens tijdens het vervaardigen van de 

factuur overgenomen of (indien niet aanwezig) handmatig ingevoerd. Er wordt een vrijwaring 

vervaardigd. Zie voor de details het inkoop proces. 

Tenaam stellen 

De module voorziet in de mogelijkheid om het voertuig eenvoudig op naam te stellen. Dit kan door 

vanuit het scherm met verkoopfunctionaliteiten een knop te activeren die het betreffende externe proces 

van RDW start wanneer dit voor de gebruiker beschikbaar is. 

Bij het tenaamstelling voertuig van de RDW, is het niet mogelijk, anders dan bij andere diensten , om 

een automatische koppeling en gegevensuitwisseling te maken tussen de RDW dienst en 

garagebedrijven. 

Wens: Indien er een ontwikkeling plaatsvindt bij de RDW waarmee integratie mogelijk is zal dit t.z.t. 

leiden tot een interface. 

Het systeem zal voorzien in de mogelijkheid om, naast de ORB melding van de inname van een 

ingeruild voertuig, het verkochte voertuig uit de interne bedrijfsvoorraadadministratie te halen als zijnde 

geleverd. 





7.4 Werkplaats 

Dit hoofdstuk beschrijft de minimale functionele basis eisen van de module werkplaats. 

7.4.1 Afspraak 

Als een klant zich meldt (balie/telefoon) kan deze worden geïdentificeerd zoals beschreven onder 

hoofdstuk 7.2. Na het selecteren van de klant of voertuig worden de voertuiggegevens en de historie 

getoond. 

Indien er bij selectie via klant meerdere voertuigen actueel zijn (meerdere voertuigen binnen gezin of 

bedrijf) wordt een selectie gemaakt op het voertuig dat voor onderhoud wordt aangemeld. Tevens zal 

het totaalbedrag van de openstaande rekeningen (gezin/bedrijf) worden getoond en de datum waarop 

er voor het laatst een betaling is ontvangen. Wens: Openstaande rekeningen van een klant zijn, indien 

van toepassing, van alle vestigingen raadpleegbaar. 

Bij een nieuwe klant worden de gegevens van de klant, hoe het van het bedrijf kennis heeft genomen 

etc. en het voertuig (indien onbekend) ingevoerd. Op dat moment kan de gebruiker kiezen om gebruik 

te maken van voertuig en/of NAW verrijking. 

Het systeem voorziet er in dat er voorafgaande aan het inplannen voor onderhoud een offerte kan 

worden vervaardigd met daarop de gespecificeerde activiteiten en onderdelen. Tijdens het vervaardigen 

van de offerte zal ook gekeken worden naar de voorraadsituatie van de gespecificeerde 

artikelen/onderdelen. Tevens kan dit resulteren in een afspraak voor een vast bedrag voor een 

werkopdracht. 

Het systeem zal, indien een door de gebruiker vastgelegde tijd verstreken is na het vervaardigen van 

een offerte, een signaal afgeven. De offerte kan worden aangemerkt als “niet actueel” en wordt in de 

historie bij de relatie geplaatst of worden doorgezet als werkorder. 

Het systeem voorziet in de mogelijkheid om afspraken te bevestigen via sms, e-mail. In het bericht is 

een gedeelte vast en een gedeelte variabel. De sjablonen zijn te vinden op de locatie die in de 

beheertabel is ingevuld. Het variabele deel kan door de gebruiker worden benut voor mededelingen. 

Bij de werkorder bestaat de mogelijkheid om het onderhoudsschema te koppelen en de bijbehorende 

recepturen op te halen. 

7.4.2 Plannen 

Het systeem beschikt over een werkplaats planningsmodule. Deze module maakt gebruik van de 

relaties die als (werkplaats) medewerkers zijn geregistreerd. Tevens biedt het de mogelijkheid om 

leen/huur auto‟s, fietsen etc te administreren. Bij het plannen van werkzaamheden wordt rekening 

gehouden met het op die dag beschikbare aantal medewerkers en beschikbaar vervangend vervoer op 

die dag. 

Offerte 

Indien een vervaardigde offerte wordt omgezet naar een verzoek tot onderhoud kan dit met de druk op 

de knop gebeuren. Aanpassingen op de werkzaamheden zoals die in de offerte staan aangegeven 

kunnen via de werkorder gedaan worden. 

Werkplaatsorder 

Bij het samenstellen van de werkorder op basis van activiteitscoderingen/recepturen en de benodigde 

uren zal een controle op de aanwezige voorraad plaats vinden. Via de werkplaatsorder worden 

onderdelen geclaimd. Indien het aantal onvoldoende is zal er een signaal gegeven worden. Naar keuze 



kan de gebruiker direct een artikel bestellen. 

Op de werkplaatsorder worden onderdelen getoond met de magazijnlocatie. 

Tijdens het invoeren van de werkplaatsorder is het mogelijk om de details van activiteitencodes en 

samenstelling van recepturen op te vragen. 

Het is mogelijk om werkorders in te voeren die niet aan een kenteken/relatie gekoppeld zijn. 

Het is mogelijk om aan een werkorder een “type werkorder” toe te kennen. De verschillende typen 

worden door de gebruiker via de beheertabel ingevoerd. Er kan per type werkorder een overzicht 

worden vervaardigd. 

Bij onderhoud/inspectie zal bij de inroostering gecontroleerd worden of de gekoppelde keurmeester op 

dat moment in bezit is van geldige certificaten. Indien (binnenkort) niet geldig volgt een signalering. 

Denk hierbij aan APK, Airco etc. 

Er is een mogelijkheid om vrije tekst in te voeren bij de opdracht. 

Het systeem zal er rekening mee houden dat werkorders naar elkaar kunnen verwijzen. Bij het 

aanmaken van een werkorder bestaat daarmee de mogelijkheid om aan te geven aan welke vorige 

werkorder de nieuwe gekoppeld wordt. Hierdoor kan een kettingstructuur van aan elkaar gerelateerde 

werkorders ontstaan. Dit is met name van belang waar het gaat om garantie werkzaamheden. 

Het is mogelijk om een overzicht te vervaardigen van geplande werkplaatsorders over een dag/week/ 

medewerkers of combinaties daarvan..De lay-out verloopt (bij keuze afdrukken) via een sjabloon dat 

door de gebruiker is te wijzigen. Als het overzicht per “type werkorder” wordt vervaardigd zal ook de 

werkorder worden getoond waarnaar terug verwezen wordt. 

Indien met meerdere personen aan een werkorder wordt gewerkt kan een verdeling van uren op basis 

van % plaatsvinden en een handmatige verdeling. 

Bij een werkorder kan per orderregel aangegeven worden of deze moet worden doorbelast aan de 

klant. Orderregels die niet aan de klant worden doorberekend komen wel op de factuur in aantal en 

stuksprijs maar met de waarde nul als totaalbedrag voor de betreffende orderregel. 

7.4.3 Innemen voertuig 

Bij inname van het te onderhouden voertuig kunnen aanvullende afspraken worden geregistreerd. De 

gegevens van de klant/voertuig worden geselecteerd waarna de klanten voertuiggegevens zichtbaar 

worden. Eventuele wijzigingen kunnen nog worden aangebracht in de gegevens van de klant en de 

werkorder. Als er geen werkorder is, bestaat er de mogelijkheid om deze aan te maken. 

Bij de inname kan een drempelbedrag worden opgegeven bij de werkorder. 

Het systeem biedt de mogelijkheid om (klant)documenten te scannen en te bewaren. 

Akte van sessie 

Het systeem voorziet in de mogelijkheid om op basis van door de gebruiker te wijzigen sjablonen, een 

akte van cessie te vervaardigen. De getekende akte kan, na deze eventueel te hebben gescand, bij de 

gegevens worden opgeslagen en later worden geraadpleegd en/of afgedrukt. Op de akte worden de 

gegevens van de geselecteerde klant/voertuig overgenomen. 



Vervangend vervoer 

Indien er een reservering is gemaakt voor een huur/leen voertuig (Auto, fiets etc) zal het systeem het 

BOVAG Wens: Elektronische formulier gebruiken om de huur/leenovereenkomst te vervaardigen. Deze 

wordt waar mogelijk gevuld met de gegevens van de klant en het betreffende voertuig. 

Alle relevante gegevens die het systeem niet kan leveren kunnen via het beeldscherm worden 

ingevoerd. 

Indien geen reservering is gemaakt kan deze ad-hoc worden vervaardigd. 

De getekende overeenkomst kan, na deze te hebben gescand, bij de gegevens worden opgeslagen en 

later worden geraadpleegd en/of afgedrukt. 

7.4.4 Onderhoud voertuig 

APK 

Het systeem bevat een volledige integratie met een APK raadpleeg/afmeldsysteem. De gegevens die 

van het RDW retour komen (APK rapport) worden opgeslagen bij de voertuiggegevens van de klant. De 

werkplaatsmedewerker zal in het systeem aangeven of er adviespunten zijn. Hierop wordt door het 

systeem een signaal vervaardigd. 

Technische Voertuig Informatie 

Het systeem is gekoppeld met een TVI provider. Zodra de koppeling wordt aangesproken worden de 

identificerende voertuiggegevens die door het TVI gebruikt wordt meegenomen zodat de gebruiker op 

een snelle manier de informatie kan raadplegen. De basisvorm is het ophalen van de technische 

informatie uit het kenteken register. De basis versus de professionele variant is specifieke informatie 

zoals handboeken, elektrische schema‟s etc. 

Wens: Daarnaast biedt het systeem de mogelijkheid om voertuiggegevens naar diagnostische 

apparatuur te verzenden/ontvangen. 

Gewerkte uren/ verbruikte onderdelen/middelen 

Het systeem staat toe dat de werkplaatsmedewerker zelf uren “schrijft” op de werkplaatsbon en dat dit 

ook centraal kan geschieden. Op wat voor manier de uren door de werkplaatsmedewerker worden 

geschreven staat de leverancier vrij. (beeldscherm/toetsenbord, barcodescanning etc) 

Centraal kan er een verdeling worden aangebracht in het aantal uren op een activiteitencode/receptuur 

dan wel een nieuwe activiteit toevoegen waarop handmatig uren geboekt worden. 

Alle gebruikte onderdelen en (smeer)middelen worden, met uitzondering van klein materiaal, bij het 

afboeken uit de voorraad geregistreerd op de werkplaatsorder 

Het systeem biedt de mogelijkheid om gedurende de dag een overzicht te tonen wie met welke 

werkplaatsorder bezig is en sinds wanneer. 

Het systeem geeft een signaal als het totaal van de werkzaamheden/onderdelen een vooraf 

afgesproken bedrag (drempelbedrag) dreigt te overschrijden. 

Na afloop van de werkzaamheden wordt de werkplaatsorder gereed gemeld. 

Lease en KM stand 

Ten behoeven van reparaties aan leasevoertuigen is er een automatische koppeling aanwezig met het 

ROB platform waarmee de relevante informatie wordt uitgewisseld. 



De kilometerstand ten tijde van het reparatiemoment wordt automatisch aan het NAP platform 

doorgegeven met alle daarbij behorende relevante informatie. Ook indien OKR bij RDW in de loop van 

2012 operationeel wordt. 

7.4.5 Aanbieden voertuig/Factureren 

Innemen huur/leen voertuig 

Het administratief afhandelen van het huur/leen voertuig kan achteraf gebeuren. Bij daadwerkelijk 

inname kan worden volstaan door in het systeem bij de overeenkomst te noteren dat het voertuig is 

ingeleverd. Invoeren van km-standen etc, aftanken kan (handmatig of electronisch) direct plaatsvinden 

of achteraf. 

Indien achteraf sprake is van bijkomende kosten (verreden km‟s, brandstof, schade) die niet 

gedeclareerd zijn staat het systeem toe dat deze kosten op het bedrijf worden genomen, in backlog 

blijven tot een volgende onderhoudsbeurt of dat een klant-factuur wordt vervaardigd. Te alle tijden wordt 

dit bij de klanthistorie opgenomen. 

Factuur 

Het systeem staat toe dat op basis van de (eventueel aangepaste) werkplaatsorder een factuur wordt 

vervaardigd. Facturen op naam worden, afhankelijk van wat bij de relatie staat aangegeven, op een 

verzamelnota, per opdracht en/of als e-factuur verzonden. 

De indeling van de factuur is door de gebruiker via een sjabloon te wijzigen. Wens: deze indeling dient 

te voldoen aan de BOVAG factuur adviezen. 

Het systeem biedt de mogelijkheid om facturen te splitsen. Ook ondersteund het bij de splitsing 

verschillende geadresseerden. Op de factuur staan alle relevante gegevens. Iedere factuur wordt in de 

historie verwerkt. 

De gebruiker heeft de mogelijkheid om facturen meerdere malen (proef) af te drukken. Bij de definitieve 

afdruk worden de gegevens doorgesluisd naar de andere modules. 

Het systeem laat toe dat er deelbetalingen kunnen plaatsvinden en dat er gelijktijdig via meerdere 

bronnen betaald kan worden. (contant, pin, factuur, etc..) 

7.5 Magazijn 

Dit hoofdstuk beschrijft de minimale functionele basis eisen voor de module magazijn. 

Wens: Het systeem ondersteund het voeren van meerdere magazijnen. 

7.5.1 Invoer onderdelen/verbruiks artikelen 

Stamgegevens 

Het systeem biedt voor het invoeren van onderdelen/artikelen verschillende mogelijkheden. Handmatige 

invoer en invoer via een bestand afkomstig van de leverancier. Ondersteuning van interne/externe 

artikelnummers wordt gegeven. Bij invoer van een extern bestand krijgt de gebruiker de mogelijkheid 

om op record en veld nivo gegevens te weigeren en/of aan te passen. Het systeem ondersteund 

catalogi van meerdere leveranciers. 

Het groeperen van onderdelen/artikelen is mogelijk. 



Bij het wijzigen van inkoop prijzen wordt afhankelijk van een specifieke gebruikersinstelling de reeds 

geleverde, maar nog niet gefactureerde, onderdelen van voor de prijswijziging tegen het toen (of nu) 

geldende prijs gefactureerd. In een actieperiode voor een artikelgroep/onderdeel of artikel is een 

speciaal tarief mogelijk. Een stamgegeven mag niet verwijderd worden, deze moeten worden 

gearchiveerd of laten staan. Als er in het lopende boekjaar reeds op geboekt is. Er is een indicatie 

“buiten gebruik” waardoor het onderdeel/artikel niet meer besteld kan worden. 

Indien een onderdeel/artikel een ander nummer krijgt toegekend moet het mogelijk zijn om de 

betreffende onderdelen/artikelen, ook in de historie, te relateren van het nieuwe nummer. 

Bij een onderdeel/artikel is het mogelijk om een alternatief nummer/leverancier te registreren. 

De gebruiker wordt door het systeem ondersteund op het gebied van interne en externe 

artikelnummers. Bij interne artikelnummers kunnen meerdere leveranciers betrokken zijn. Het systeem 

ondersteunt het inlezen van externe artikelgegevens waarbij een koppeling met het interne 

artikelnummer kan worden gemaakt. Hierdoor kan bij het opvragen van de gegevens van een intern 

artikelnummer alle synoniem artikelnummers van de verschillende leveranciers getoond worden 

inclusief prijs en andere relevante informatie. Wens: Het is de wens om uiteindelijk naar een 

automatisch matching proces over te gaan. 

Het systeem voorziet in de mogelijkheid om de gebruiker een samengesteld onderdeel/artikel te laten 

vervaardigen. Het samengestelde onderdeel is een samenstelling van individuele onderdelen/artikelen. 

Onderdelen/artikelen die in consignatie zijn genomen worden qua aantal meegenomen in de voorraad, 

niet financieel. 

Prijswijzigingen worden van een datum voorzien. Deze datum mag in de toekomst liggen. Nadat een 

wijziging is ingegaan vindt er een herwaardering van de voorraad plaats waarvan de financiële 

consequenties naar de betreffende module worden doorgesluisd. 

Zoeken 

Voor het gehele systeem geldt dat zoeken op onderdeel/artikel mogelijk is op meervoudige 

deelbenaming (bijv. alle artikelen met de tekst “xxx” en “yyy”in de omschrijving) , nummer, leverancier, 

artikelgroep. Hierbij heeft de gebruiker de mogelijkheid om uit een scherm waarop meerdere artikelen 

worden getoond omdat de omschrijving (deels) overeenkomt of een specifiek artikel dat door meerdere 

leveranciers aangeboden wordt. Naast het artikelnr. wordt alle relevante informatie getoond zoals 

omschrijving, leverancier, besteleenheid, voorraad, prijs etc. Uit de getoonde selectie kan uiteindelijk de 

gewenste regel geselecteerd worden. 

Afvoer 

Het afvoeren van onderdelen/artikelen die gerelateerd zijn aan een verwijdering-/milieubijdrage, dient te 

worden geregistreerd. Van de historie dient een overzicht vervaardigd te kunnen worden waarop de 

verwijdering-/milieubijdrage staan inclusief een telling van de afgevoerde onderdelen/artikelen. 

Middels een selectiemogelijkheid kan het overzicht op datum van/tm worden vervaardigd. Financiële 

consequenties worden naar de betreffende module doorgesluisd. 

7.5.2 Voorraad beheer 

Voorraadcontrole 

Het systeem ondersteunt de gebruiker bij het controleren van de voorraad. Overzichten van de voorraad 

kunnen op verschillende volgorden worden vervaardigd zoals magazijn, magazijnlocatie, artikelgroep 

etc. Het systeem ondersteund het opvragen van de voorraad voor een specifiek onderdeel/artikel. De 

gebruiker heeft daarnaast de keuze om wens: per magazijn, en magazijnlocaties van/tm de 

voorraad(overzichten) op te vragen. 



Naast de voorraad in aantallen wordt ook de waarde (inkoop/verkoop) weergegeven, de gereserveerde 

aantallen en de aantallen/datum in bestelling bij leverancier. Er worden (sub)totaal tellingen 

weergegeven. 

Van samengestelde onderdelen wordt op verzoek de specificatie weergegeven. 

Voorraadmutatie overzicht 

Het mutatieoverzicht geeft de gebruiker inzicht in de mutaties die hebben plaatsgevonden. 

Mutaties zijn opvraagbaar op verschillende niveaus zoals per onderdeel/artikel, artikelgroep etc. Bij het 

opvragen wordt alle relevante informatie getoond. Het is mogelijk om selecties op datum van t/m in te 

geven. 

Corrigeren 

De gebruiker heeft de mogelijkheid om afwijkingen in de voorraad te corrigeren. Deze mutaties worden 

doorverwerkt naar de Financiële module. Bij een voorraadcorrectie kan de mutatie van extra informatie 

worden voorzien die de gebruiker kan invoeren. 

7.5.3 Uitgifte voorraad 

Algemeen 

Het systeem ondersteund de afgifte van voorraad en niet voorraad onderdelen/artikelen. 

Uitgaven worden geboekt op werkplaatsorders, via directe uitgifte of een verkooporder. 

Het is mogelijk om onderdelen/artikelen die zijn uitgegeven administratief te verzamel en via een 

automatisch te vervaardigen pakbon en bijbehorende factuur te verwerken. 

Uitgiften en retouren worden in de voorraad en financieel verwerkt. 

Verkopen onder de netto inkoopprijs worden gesignaleerd. 

Als de voorraadpositie (voorraad -/- afgiften -/- gereserveerd) onder de minimumvoorraad komt geeft het 

systeem een signalering. Dit kan apart via een overzicht of als onderdeel van een proces dat het 

besteladvies produceert. 

Werkplaatsorders 

Onderdelen/artikelen die via een werkplaatsorder zijn gereserveerd en worden afgehaald kunnen direct 

op de werkplaatsorder worden geadministreerd. 

Niet voorraad onderdeel/artikel 

Een onderdeel/artikel dat niet op voorraad wordt gehouden kan worden geboekt op een werkplaatsorder 

of verkooporder. Hierbij dient apart het aantal, de inkoop-/verkoopprijs en omschrijving te worden 

ingevoerd. Eventueel kan het kenteken worden geregistreerd. Naast de omschrijving van het 

onderdeel/artikel heeft de gebruiker de mogelijkheid om extra tekst in te voeren. 

Directe verkoop 

Het systeem biedt de mogelijkheid om vanuit het magazijn directe verkopen te doen. Er kan een 

afwijkende prijs worden opgegeven. 

Het is hierbij noodzakelijk om een, eventueel interne, relatie te koppelen. Na ingaven van de verkochte 

onderdelen/artikelen wordt de factuur vervaardigd. De layout is door de gebruiker via het sjabloon zelf 

aan te passen. Het systeem registreert hoe de afnemer betaald. 

Dead Stock 

Bij voorraad onderdelen/artikelen waarvan de omloopsnelheid lager ligt dan in de beheerparameter is 

aangegeven krijgt de status “Niet bestellen”. Hiervan kan een overzicht worden vervaardigd. 

Herwaarderen 

Het herwaarderen van de magazijnvoorraad vindt plaats via de financiële administratie. 



7.5.4 Bestellen onderdelen/artikelen 

Besteladvies 

Het systeem kan een besteladvies vervaardigen van onderdelen/artikelen die onder de minimum 

voorraad zijn beland. (voorraad -/- reserveringen). 

Er wordt rekening gehouden met de omloopsnelheid en de levertermijn. 

Als te bestellen aantal wordt de waarde overgenomen zoals die bij de stamgegevens is opgenomen. 

In het besteladvies worden de openstaande werkorders betrokken waarbij niet voorraad artikelen zijn 

opgenomen. 

Aanpassen besteladvies 

De bestelopdracht voor een leverancier kan worden gesplitst in meerdere opdrachten. 

De opdracht kan door de gebruiker worden aangepast op aantal en/of leverancier. Een bestelregel kan 

worden verwijderd. 

Bestellen 

Het systeem zal, nadat de gebruiker akkoord heeft gegeven, de bestellingen elektronisch verzenden. Bij 

de betreffende artikelen worden de aantallen en de besteldatum bijgewerkt en de financiële mutaties 

doorverwerkt. Op de openstaande werkplaatsorder wordt de besteldatum bij het betreffende 

onderdeel/artikel zichtbaar. 

Het systeem voorziet in de mogelijkheid om handmatig een bestelling te vervaardigen. 

Catalogi 

Het systeem is geïntegreerd met een aantal catalogi (minimaal 3) waarbij de gebruiker ondersteund 

wordt om onderdelen/artikelen te bestellen. Op basis van de voertuigidentificatie (merk/model/type) die 

het systeem meeneemt naar de catalogus, kan snel gezocht worden naar het betreffen het 

onderdeel/artikel. 

Het geselecteerde onderdeel/artikel wordt vanuit de catalogus meegenomen naar het systeem voor 

verdere verwerking. 

7.5.5 Ontvangst goederen 

Wens: Barcodestickers 

Vanuit de bestellijst kan een scherm opgevraagd worden van alle bestelde en nog te ontvangen 

goederen. Hierop kan worden aangegeven van welke artikelen een barcodesticker gewenst is. Ook het 

aantal kan worden opgegeven. Als barcode wordt het interne artikelnummer gebruikt. 

Barcodestickers kunnen ook worden vervaardigd zonder de bestellijst te raadplegen en rechtstreeks, na 

ingave van intern artikelnummer en aantal, worden afgedrukt. 

Op de stikker wordt de barcode, omschrijving, leverancierscode, artikelnummer leverancier en 

magazijnlokatie afgedrukt. 

Ontvangst registreren 

Het registreren van de ontvangen goederen kan via of een handmatige ingave van intern artikelnummer 

en stuks of via Wens: een barcodelezer 



Na registratie worden de gegevens verwerkt in de betreffende bestanden zoals bestellijst, 

journaalposten, voorraadmutaties, werkorders etc. 

Retourgoederen zoals manko‟s, niet bestelde goederen etc worden apart geregistreerd en behandeld. 

Bij het invoeren van een artikelnummer worden de relevante gegevens zoals magazijnlocatie etc 

getoond. 

7.6 Financiën 

7.6.1 Algemeen 

De module “Financiën” kan een geïntegreerd onderdeel uitmaken van de door de software leverancier 

aangedragen oplossing. In die gevallen waarin dit niet zo is dient de software leverancier er in te 

voorzien dat er met meer dan één financieel pakket zodanig gekoppeld kan worden dat de gegevens 

worden overgenomen zonder dat de gebruiker gegevens dubbel hoeft in te voeren. 

Dit houdt ook in dat, los van de financiële transacties, gegevens over relaties (debiteuren/crediteuren) 

die worden vastgelegd of gemuteerd, zoals omschreven in één van de hiervoor omschreven modules, 

worden verwerkt in de financiële module. Dit stelt speciale eisen aan het (als voorbeeld) tonen van 

betaalgedrag van de relatie op moment dat er een afspraak voor de werkplaats wordt gemaakt. Het 

betaalgedrag van facturen ontstaan bij de verschillende vestigingen worden getoond. 

Dit hoofdstuk beschrijft niet alle functionaliteit die van een financiële module in de praktijk verwacht mag 

worden. Het beperkt zich tot de relevante zaken die bij de softwarecertificering van belang zijn. U treft 

dus geen beschrijving aan over het boeken van transacties in, of afsluiten van, periodes of hoe 

journaalposten worden verwerkt.. Deze zaken worden als bekend verondersteld. 

De module biedt de mogelijkheid om (min.10) bedrijven/afdelingen te administreren en te consolideren 

en de mogelijkheid tot koppeling met de geldende betaalmogelijkheden. (bankpas/PIN pas/creditcard) 

7.6.2 Grootboek stambestand 

Het systeem ondersteund het actuele advies rekeningschema zoals opgesteld door de BOVAG. 

Binnen dit schema kan BOVAG aangeven welke rekeningen van belang zijn voor benchmarks. Hier 

moet rekening worden gehouden bij de inrichting. 

In de markt wordt, zeker bij de kleinere ondernemingen, veelal gebruik gemaakt van een extern bureau 

dat de financiën verwerkt. Het hanteren van het specifieke BOVAG rekeningschema is hierbij niet altijd 

mogelijk. Het is de wens om voor deze groep ondernemers een conversie mogelijkheid te bieden die 

de externe gegevens kan converteren naar BOVAG rekeningschema zodat de bedrijfsvergelijking kan 

plaatsvinden. 

Naast het inrichten van het rekeningschema kan de gebruiker handmatig de stamgegevens wijzigen, 

nieuwe rekeningen en kostenplaatsen (indien kostenplaatsen ondersteund worden) aanleggen dan wel 

verwijderen. 

7.6.3 Grootboek mutaties 



Het systeem biedt naast de standaard handmatige verwerking van journaalposten ook de mogelijkheid 

om elektronische bank mutaties in te lezen en te verwerken. Dit geldt ook voor journaalposten die door 

de deelsystemen (Werkplaats etc) worden gegenereerd. Voordat journaalposten verwerkt worden 

kunnen, indien nodig, wijzigingen worden aangebracht en meerdere malen een controle verslag worden 

vervaardigd. 

Het systeem houdt rekening met de diverse soorten betalingen gedaan aan de balie (PIN, chartaal etc) 

waarbij ook een deelbetaling op de juiste wijze kan worden geadministreerd. Bij een betalingsverschil of 

deelbetaling wordt de gebruiker hierop geattendeerd. 

De gebruiker kan automatisch periodieke/vaste journaalposten verwerken. 

7.6.4 Facturen 

Bij het inboeken van facturen moet de mogelijkheid worden geboden om factuurbedragen sec. ten laste 

te brengen van de periode waarin die verwerkt is en in de verslaglegging te verdelen over het aantal 

perioden waarmee gewerkt wordt. 

7.6.5. Overzichten 

Naast de standaard grootboek overzichten dient het systeem te voorzien in de mogelijkheid om: 

Algemeen 

Door de gebruiker zelf overzichten te laten samenstellen op niveau van holding en/of bedrijf en/of 

afdeling (indien mogelijk) . Daarbij moet ook aangegeven kunnen worden over welke bedragen een 

verschil in % moet worden getoond indien het een vergelijkingsoverzicht betreft. 

BOVAG Bedrijfsvergelijk 

Wens: Met hett systeem kan op eenvoudige wijze een BOVAG-Bedrijfsvergelijk worden uitgevoerd. 

Het systeem biedt de mogelijkheid om een voorlopig/saldi/(verkorte)kolommenbalans te vervaardigen. 

Variabele toepassing subtotaal rapportage 

De gebruiker kan rapportage-subtotaal rekeningen aanmaken op verschillende niveau‟s 

Voorbeeld: 

0010 Goodwill 

0020 Afschrijving Goodwill 

00** rapportage subtotaal van voorgaande rekeningen nivo 2 

0100 Terreinen 

0110 Bedrijfsgebouwen 

0120 Verbouwingen 


0130 Machines en Installatie 

0140 Inventaris 

0150 Transportmateriaal 




0*** rapportage subtotaal van voorgaande rekeningen nivo 3 

BTW 

Bij het vervaardigen van de resultatenoverzichten wordt vooraf de mogelijkheid geboden om wel/niet de 

globalisatie BTW te berekenen in de maand/kwartaal overzichten. 

(Meer)Jaren vergelijk 

Om perioden/kwartalen of jaarcijfers met elkaar te kunnen vergelijken biedt het systeem de mogelijkheid 

om eenvoudig de cijfers van de gewenste selectie te tonen. Hiermee kan snel inzicht worden verkregen 

met voorgaande perioden/kwartalen en jaren. 

BTW/Marge auto's 

De gebruiker heeft de mogelijkheid een overzicht van de BTW/marge auto‟s in voorraad uit te draaien 

op een lijst. Hierbij zal de rest BPM apart uitgesplitst getoond worden. Ook zal hierbij aangegeven 

worden of het BPM bedrag wel of niet voldaan is. Dit laatste zal door de gebruiker handmatig moeten 

worden ingegeven. 

Elektronische aangifte BTW 

Het systeem stelt de gebruiker in staat om elektronische BTW aangifte te doen, volgens de door de 

belastingsdienst omschreven voorwaarden 

Voorraadwaarde 

Het systeem kan op een willekeurig tijdstip overzichten vervaardigen van de voorraadwaarde per 

magazijn. 

7.6.6 Debiteuren 

Algemeen 

De gebruiker heeft de mogelijkheid om een debiteur aan te maken, te raadplegen, te wijzigen en te 

selecteren. Per debiteur kan aangegeven worden wat de kredietruimte is en de korting op 

uren/materiaal/ werk derden. Daarnaast kan de historie per debiteur tot minimaal vijf jaar worden 

opgevraagd. Bij de overschrijding van de kredietruimte wordt de gebruiker hierop geattendeerd 

Verzamelfactuur 

De gebruiker kan aangeven of een relatie via een verzamelfactuur gefactureerd wordt. Indien dit het 

geval is kunnen meerdere werkorders en/of magazijnleveringen op een verzamelfactuur worden 

weergegeven. 

Factuur Crediteren 

Het systeem zal de gebruiker de mogelijkheid bieden om een factuur met een simpele handeling geheel 

tegen te boeken. Het systeem laat daarbij alle detailregels zien. Indien de gebruiker één of meerdere 

regels niet wil crediteren kan dat aangegeven worden. Het systeem maakt een creditnota aan van de 

gehele factuur. Indien er factuurregels als niet te crediteren staat aangegeven worden automatisch een 

nieuwe factuur vervaardigd met de bedoelde regels. In alle gevallen is er sprake van het opeenvolgend 

doornummeren van facturen. 

Nummering 

Binnen de Debiteuren module kunnen verschillende series factuurnummers worden gehanteerd. 

Betalingsherinneringen 



Aan de hand van de openstaande debiteuren/posten heeft de gebruiker de mogelijkheid om naar een 

selectie van debiteuren/posten en/of op datum een herinnering te versturen. Wens: Het systeem 

onderkent minimaal 4 sjablonen. Bij het versturen van de herinneringen wordt voor elke debiteur in het 

stambestand gekeken of de herinnering via E-mail of per reguliere post dient te worden aangeboden. 

Hiervan kan in het gereedstaande herinneringenbestand worden afgeweken. 

De gebruiker kan een drempel instellen voor het bedrag waaronder geen herinneringen hoeven te 

worden verstuurd. Indien een debiteur openstaande posten heeft uit verschillende perioden waardoor 

op het moment van controle meerdere soorten aanmaningen verzonden zouden moeten worden, 

dienen deze te worden samengevoegd. 

Afboeken openstaande posten 

De gebruiker heeft de mogelijkheid om openstaande posten af te boeken. Het systeem doet een 

voorstel van openstaande posten langer dan een x periode. Ook posten waarop langere tijd geen 

deelbetaling op ontvangen is vallen hieronder. 

De gebruiker kan wijzigingen op het voorstel aanbrengen. Indien de klant zich opnieuw meldt zal de 

gebruiker op de receptie worden geattendeerd op oninbare kosten. 

Historie debiteuren 

Het on-line kunnen raadplegen van de debiteuren historie is niet gebonden aan een aantal jaren. De 

gebruiker heeft de mogelijkheid om de debiteuren historie voor minimaal 5 jaar na te slaan op basis van 

debiteurennummer, naam en bedrag. 

7.6.7 Crediteuren 

Algemeen 

De gebruiker heeft de mogelijkheid om een crediteur aan te maken, te raadplegen, te wijzigen en te 

selecteren. Per crediteur kan aangegeven worden wat de betalingstermijn Daarnaast kan de historie per 

crediteur tot minimaal vijf jaar worden opgevraagd. Bij de overschrijding van de betalingstermijn wordt 

de gebruiker hierop geattendeerd 

Wens: Betalingsvoorstel 

Het systeem kan een betalingsvoorstel vervaardigen op basis van verstreken betalingstermijn. De 

gebruiker heeft de mogelijkheid om het voorstel te wijzigen door facturen toe te voegen of uit het 

voorstel te verwijderen. In het voorstel worden debet en credit facturen opgenomen. 

Het doen van deelbetalingen is mogelijk waarbij het systeem de gebruiker attendeert als er teveel/te 

weinig betaald wordt. 

Als de gebruiker akkoord is met het voorstel kunnen de betalingsopdrachten worden klaargezet. 

Betalingen klaarzetten 

De gebruiker heeft de mogelijkheid om een batch van betalingen klaar te zetten op datum. Bij de 

contactlegging met het betaalsysteem wordt de batch overgezet naar het betaalsysteem. Bij het 

klaarzetten van de betaling heeft de gebruiker de keuze via welke bank de betalingen gaan 

plaatsvinden. Als standaard wordt de bank getoond die in de beheermodule als preferent is 

aangegeven. Hiervan kan worden afgeweken. 



7.7 Managementinformatie 

7.7.1. Algemeen 

Het is de bedoeling dat er management informatie vervaardigd kan worden uit het pakket, onderstaande 

informatie geeft aan wat er belangrijk is voor een autobedrijf, dit is als voorbeeld te gebruiken. 

In het kader van de managementinformatie wordt in eerste instantie gefocussed op de operationele 

managementinformatie. Echter bij de tactische en strategische informatie wordt hier ook kort ingegaan. 

In het onderstaande schema worden deze begrippen gepositioneerd. 

7.7.2 Operationeel management 

Ten einde de performance van de operationele processen goed in de gaten te houden en daar tijdig op 

te kunnen sturen is de behoefte om voor de volgende processen binnen het autobedrijf zogenaamde 

“BOVAG Onafhankelijke Autobedrijven” te maken met daarop de relevante kengetallen. De volgende 

BOVAG Onafhankelijke Autobedrijven worden onderscheiden: 

- In- en Verkoop van auto‟s alsmede voorraad 

o Hier gaat het om aantallen per maand, statijden, transactieresultaten, transacties per 

verkoper, proefritten, offertes, orders en betaling, etc. 

- Werkplaats 

o Hier gaat het om afspraken, werkplaatsbezetting, transacties, uren versus onderdelen (uit 

magazijn of besteld), garantiewerk, vaste bedragen versus besteed, uren en onderdelen 

per monteur, vervangend vervoer, betaling, etc. 

- In- en (interne)Verkoop van onderdelen alsmede voorraad 

o Hier gaat het om bestellingen, manco/surplus, emballage, interne en externe verkoop 

- Financiën 

o Hier gaat het om de reguliere financiële kengetallen. 

- Klanten 



o Hier gaat het om klantenbestand (< 2 jaar contact geweest), aantal verloren klanten, 

aantal nieuwe klanten, aantal suspects (gemailed/benaderd maar geen prospect of 

klant), aantal prospects (proefrit, offerte), Vaste klanten (minstens 1x per jaar), 



7.7.3 Tactisch management 

In het kader hiervan is het van belang om de volgende informatie per kalendermaand beschikbaar te 

hebben: 

- De voorraadwaarde in gegarandeerde , inkoop en verkoopprijs t.o.v. het bedrag voorraadkrediet. 

- De normbezetting van monteurs binnen de werkplaats ten opzichte van de werkelijke bezetting 

(*) en de gefactureerde deel van de bezetting. 

- De voorraadwaarde van onderdelen, waarde van bestelde onderdelen, waarde van in 

werkopdrachten gebruikte onderdelen. 

- Top klanten in/verkoop (transactiewaarde < 2 jaar) en top klanten werkplaats (transactiewaarde 

< 1 jaar) en minimale volledigheid van contactgegevens (NAW, Tel, email) per resp. suspect, 

prospect, klant. 

(*) de werkelijk bezetting kan door invoer van het personeel (zie hoofdstuk 6) met het aantal uur dat ze die maand 

hebben gewerkt of door de koppeling met een aanwezigheidsregistratiesysteem indien dit aanwezig is. 

7.7.4 Strategisch management 

Bij dit onderwerp gaat het om de performance van het bedrijf ten opzichte van zijn marktomgeving. De 

verwachting is dat er op dit terrein de komende jaren meer ontwikkelingen zullen gaan komen. Te 

denken valt hierbij o.a. aan: 

- Integreren van statistische marktinformatie 

- Benchmark binnen BOVAG 

- Benchmark binnen franchise formules 

Vooralsnog geven we dit aan om alvast rekening mee te houden (zie ook 7.6.2) bij de inrichting van de 

gegevensverzamelingen binnen de garagesoftware omgeving. 



8 Interfaces 

8.1 Algemeen 

De bedrijfsomgeving van het autobedrijf is naast een goed functionerend bedrijfsysteem in sterk 

groeiende mate afhankelijk van de informatie uit en informatie uitwisseling met externe bronnen. Het 

streven is om deze informatiestromen zoveel mogelijk te integreren. 

In bijlage 1 treft u een overzicht aan van alle processen en activiteiten en hun behoefte aan integratie 

van informatie. Hierbij is de data bewust in functionele termen aangegeven. Voor de invulling van deze 

functionele datasets zijn er in de meeste gevallen verschillende providers die in meer of mindere mate 

of met meer of mindere kwaliteit dit invullen. Zo zijn er verschillende leveranciers van taxatie informatie, 

technische informatie, RDW providers, occasionsites, etc. etc. In de bijlage zal, in de eindversie, worden 

aangegeven welke interfaces op dit moment geintegreerd aanwezig moeten zijn als eis en welke 

wenselijk zijn. 

8.2 Flexibiliteit 

De ondernemer zal zoveel mogelijk flexibiliteit willen hebben bij de keuze van deze business service 

providers. Wij onderkennen dat standaardisatie dit proces erg kan helpen. Allereerst gaan we daar uit 

van berichten gebaseerd op XML / webservices. Tevens zal de standaardisatie inzake identity en acees 

management kunnen bijdragen. 

Daarnaast vragen wij echter aan de softwareleverancier een flexibele opzet van deze interfaces 

waarlangs de ondernemer een keuze kan maken voor een provider met een minimum van benodigde 

inspanning van leverancier zijde. 

8.3 Integratie van diensten 

BOVAG is de belangenbehartiger voor haar aangesloten autobedrijven. Op het gebied van 

informatisering organiseert BOVAG de beschikbaarheid van verschillende producten en diensten voor 

haar leden. Deze diensten kennen in veel gevallen een relatie met de data en/of functionaliteiten in de 

bedrijfssystemen en dus de garagesoftware. Deze relatie wordt geconcretiseerd door geïntegreerde 

koppelingen te maken. Deze noemen we interfaces. 

In de rol die bepaalde diensten hebben worden verschillende niveaus onderscheiden. Een interface 

betreft altijd een samenwerking tussen systemen en daarmee de organisaties die daaraan verbonden 

zijn. Afhankelijk van het niveau zijn er verschillende verantwoordelijkheden bij verschillende partijen aan 

te geven. 

Onderstaand worden de niveaus beschreven waarin de integratie verantwoordelijkheden voor diensten 

zijn ingedeeld. 

Niveau 1 is een wettelijke verplichting in combinatie met een branche belang. Om administratieve lasten 

te verminderen en de data voor hergebruik door de branche beschikbaar te houden dienen deze te 

worden ingebouwd in het garagesysteem. Hierbij dienen de berichten voorzien te zijn van de 

identificatie van het bedrijf en van de softwareleverancier. Controle op gebruik vindt plaats door de 

wettelijke instantie. 



Niveau 2 betreft een BOVAG belang. De diensten en producten die op dit niveau worden aangeboden 

zijn voorbehouden aan BOVAG leden. De eisen die als verplichting aan BOVAG leden worden 

opgelegd, vastgesteld in het Algemeen Bestuur van BOVAG Onafhankelijke Autobedrijven 

Dit zijn diensten voor leden die verplicht gekoppeld worden in het garagepakket. De BOVAG geeft per 

dienst de specificaties op basis waarvan deze koppeling moet worden gebouwd. Hierbij dienen de 

berichten voorzien te zijn van de identificatie van het bedrijf en van de softwareleverancier. 

Deze staan altijd aan en de invulling is default verplicht. Indien de gebruiker hier van af wil wijken zal hij 

op basis van een persoonlijke autorisatie dit via een aparte beheerfunctie moeten doen en met 

vastlegging van de identiteit in het audittrail. De controle op gebruik vindt via de desbetreffende dienst 

plaats door de BOVAG. Daarbij kan BOVAG informatie per lid opvragen bij softwareleveranciers over de 

voornoemde instelling en eventuele wijziging daarvan. 

Het is daarnaast belangrijk dat de BOVAG huisstijl consistent blijft. Als er via het pakket uitingen inzake 

BOVAG en/of BOVAG diensten worden gedaan dient de uitstraling gelijk te blijven zoals BOVAG het 

actueel heeft ingericht en presenteert. 

Geredeneerd vanuit het autobedrijf: met een BOVAG gecertificeerd garagepakket bent u ervan 

verzekerd dat u altijd kunt werken met de BOVAG producten en voldoet u automatisch aan de 

lidmaatschapseisen en de huisstijl van BOVAG. 

Niveau 3 is een collectief service belang. Het gaat hier om professionele platforms waarin transacties 

worden uitgewisseld en/of informatie gedeeld met andere partijen (bijv. ROB). De beschikbaarheid voor 

deze diensten is verplicht voor het softwarepakket. Hierbij dienen de berichten voorzien te zijn van de 

identificatie van het bedrijf en van de softwareleverancier. De leverancier is verplicht om de koppeling te 

maken, De leden hebben zelf de keuze om gebruik te maken van deze dienst. De controle op gebruik 

vindt via de desbetreffende dienstverlener. Het dient mogelijkheid te zijn om een vergelijkbaar product 

van een andere aanbieder te kunnen koppelen. De diensten waarvoor dit geldt worden vastgesteld door 

de werkgroep Softwarecertificering. 

Wens: Niveau 4 is een servicebelang. Het integreren van deze categorie is vrijwillig. In 

overeenstemming tussen het lid c.q. leden en de leverancier worden er producten gekoppeld. De 

manier van koppelen is wel volgens BOVAG opgestelde eisen. Het gebruik is vrijwillig en wordt 

overgelaten aan de afspraken daarover tussen dienstleverancier en gebruiker. 

De koppelingen en hun indeling in niveau zijn in bijlage 1 aangegeven. Het onderhouden van dit 

overzicht is een taak van de softwarecommissie. De indeling van een interface kan gewijzigd worden. 



9. Bijlagen 

9.1 Bijlage Interfaces

Download hier het Programma van Eisen - Aftersales Magazine

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?