Programma van Eisen. Bedrijfsondersteunende informatiesystemen voor universele autobedrijven. ook wel garagesoftware genoemd

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


[VERSIE 2010]

Inhoudsopgave 1. 2.

3 4

5 6

7

Inleiding ........................................................................................................................................ 4 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 Algemene eisen softwareleverancier ................................................................................................ 9 Algemene technische eisen ............................................................................................................ 12 4.1 Algemene gebruikersaspecten................................................................................................ 12 4.2 Technische eisen .................................................................................................................... 13 Systeemconcept ............................................................................................................................. 14 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 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


[VERSIE 2010]

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

3

Definitief 1.0




[VERSIE 2010]

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.

4

Definitief 1.0




[VERSIE 2010]

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 5

Definitief 1.0




[VERSIE 2010]

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 6

Definitief 1.0




[VERSIE 2010]

aangeboden aan de gecertificeerde softwareleveranciers. In het begin van het kalenderjaarwordt het nieuwe PvE vastgesteld. Certificatieproces

7

Definitief 1.0




[VERSIE 2010]

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.

8

Definitief 1.0




[VERSIE 2010]

3 Algemene eisen softwareleverancier Kennis 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.

Data 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.

9

Definitief 1.0




[VERSIE 2010]

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. 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. Financieel 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 10

Definitief 1.0




[VERSIE 2010]

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.

11

Definitief 1.0




[VERSIE 2010]

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.

12

Definitief 1.0




[VERSIE 2010]

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.

13

Definitief 1.0




5

[VERSIE 2010]

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.

Klant & Voertuigverrijking

Werkplaats administratie

Verkoop administratie

Technische Databanken

Taxatie systeem OAB GSW pakket

Garage apparatuur

Internet

Magazijn administratie

Financiële boekhouding

Onderdelen Databanken

Provider Producten & Diensten

Klanten administratie

Modulaire opzet binnen pakket 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.

14

Definitief 1.0




[VERSIE 2010]

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. Schadeherstel administratie welke zorgt voor de vereiste administratieve ondersteuning bij het afwikkelen van schadeopdrachten. Winterbanden administratie gericht op het beheren van de in bewaring gegeven winterbanden c.q. zomerbanden van klanten. 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.

2 3 4

15

Definitief 1.0




5

[VERSIE 2010]

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 1e 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. 16

Definitief 1.0




6

[VERSIE 2010]

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 17

Definitief 1.0




[VERSIE 2010]

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.

18

Definitief 1.0




[VERSIE 2010]

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 19

Definitief 1.0




          

[VERSIE 2010]

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* Overige gegevens  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.

20

Definitief 1.0




  





[VERSIE 2010]

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* Overige gegevens  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; 21

Definitief 1.0




                  

[VERSIE 2010]

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 o o o o o o o o o o o

 

Omschrijving: Codering voor de classificatie waartoe een voertuig behoort. De volgende waarden zijn van toepassing: 1 = personenauto 3 = bedrijfsauto 5 = bedrijfsauto met koppeling 6 = aanhangwagen (zonder de detaillering van 8 en 9) 7 = oplegger 8 = autonome aanhangwagen (was vroeger 6) 9 = middenasaanhangwagen (was vroeger 6) 12 = motorfiets 13 = motorfiets met zijspan 18 = driewielig motorvoertuig (wielen symmetrisch t.o.v. de lengte-as).

Cataloguswaarde; Brandstofsoort; * 22

Definitief 1.0




 

         

  

[VERSIE 2010]

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 Overige gegevens  Voornaam;  Initialen  Tussenvoegsels;  BSN(SoFi)nummer;  Rijbewijsnummer;  Rijbewijs geldig tot  Scan-aanwezig (j/n)  Paspoortnummer;  Paspoort geldig tot  Scan-aanwezig (j/n)  Contactpersoon; 23

Definitief 1.0








     



[VERSIE 2010]

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 24

Definitief 1.0




[VERSIE 2010]

Overige gegevens  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      ID 2     

Artikelnummer leverancier Intern artikelnummer UAN-code Datum geldig vanaf Datum geldig tm Intern artikelnummer Artikelnummer leverancier UAN-code Datum geldig vanaf Datum geldig tm

6.7 Transactie ID 1  Klantnummer  Datum 25

Definitief 1.0




 

[VERSIE 2010]

Tijd Volgnummer

ID 2  Kenteken of Chassisnummer  Datum  Tijd  Volgnummer ID 3  Factuurnummer

Overige gegevens  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 Overige gegevens  Omschrijving norm  Ingangsdatum Norm  Einddatum Norm  Normwaarde  Actie als (groter dan, kleiner dan, gelijk)  Bandbreedte actie in % c.q. aantal 26

Definitief 1.0




 

[VERSIE 2010]

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 Tijd Jaar Geslacht Postcode Ja of Nee Landcode Telefoon

DD/MM/JJJJ uu/mm/ss JJJJ M/V 9999XX J/N ISO Landcode 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.

27

Definitief 1.0




[VERSIE 2010]

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.

28

Definitief 1.0




[VERSIE 2010]

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. 29

Definitief 1.0




-

-

[VERSIE 2010]

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 30

Definitief 1.0




[VERSIE 2010]

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.

31

Definitief 1.0




[VERSIE 2010]

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. 32

Definitief 1.0




[VERSIE 2010]

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.

33

Definitief 1.0




[VERSIE 2010]

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. 34

Definitief 1.0




35

Definitief 1.0

[VERSIE 2010]




7.4

[VERSIE 2010]

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 36

Definitief 1.0




[VERSIE 2010]

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.

37

Definitief 1.0




[VERSIE 2010]

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.

38

Definitief 1.0




[VERSIE 2010]

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.

39

Definitief 1.0




[VERSIE 2010]

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.

40

Definitief 1.0




[VERSIE 2010]

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. 41

Definitief 1.0




[VERSIE 2010]

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

42

Definitief 1.0




[VERSIE 2010]

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

43

Definitief 1.0




[VERSIE 2010]

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 00**


0130 Machines en Installatie 0140 Inventaris 0150 Transportmateriaal 00**

rapportage subtotaal van voorgaande rekeningen nivo 2 44

Definitief 1.0




0***

[VERSIE 2010]


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 45

Definitief 1.0




[VERSIE 2010]

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.

46

Definitief 1.0




[VERSIE 2010]

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 47

Definitief 1.0




o

48

[VERSIE 2010]

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),

Definitief 1.0




[VERSIE 2010]

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.

49

Definitief 1.0




[VERSIE 2010]

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.

50

Definitief 1.0




[VERSIE 2010]

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.

51

Definitief 1.0




9.

[VERSIE 2010]

Bijlagen

9.1 Bijlage Interfaces

52

Definitief 1.0




53

Definitief 1.0

[VERSIE 2010]




54

Definitief 1.0

[VERSIE 2010]




55

Definitief 1.0

[VERSIE 2010]




56

Definitief 1.0

[VERSIE 2010]



Programma van Eisen. Bedrijfsondersteunende informatiesystemen voor universele autobedrijven. ook wel garagesoftware genoemd

Recommend Documents