Afstudeerverslag Gijs Abbring

Afstudeerverslag

Administratie importeren

Gijs Abbring, 28 oktober 2019

Studentnummer

424569

Periode

Mei - november 2019

Begeleidende docent

Paul de Groot

Bedrijfsbegeleiders

Ivo van Hurne

Versiebeheer

Versie Beschrijving Datum

0.1 Concept verslag 14-10-2019

0.2 Verwerken feedback Saxion 23-10-2019 0.3 Verwerken feedback Moneybird 25-10-2019

1.0 Oplevering verslag 28-10-2019

Tabel 1: Versiebeheer

Voorwoord

U leest het afstudeerverslag over het automatisch importeren van administraties naar Moneybird. Dit verslag is geschreven als afstudeeronderzoek ter afsluiting van de opleiding HBO-ICT software engineering aan de hogeschool Saxion in Enschede.

Het afstudeertraject heeft plaatsgevonden van 7 mei t/m 14 november 2019 bij Moneybird. Tijdens dit traject heb ik op onderzoekende wijze een prototype gebouwd voor het importeren van een administratie.

Dit project heb ik gedaan onder begeleiding van Ivo van Hurne en Robbin Voortman namens Moneybird en Paul de Groot namens Saxion. Ik wil hen bedanken voor de fijne begeleiding, goede samenwerking en kritische feedback. Zonder hun begeleiding had ik dit project niet tot een goed einde kunnen brengen. Ook wil ik graag Joost Diepenmaat en Edwin Vlieg bedanken voor de mogelijkheid om mijn studie af te ronden bij Moneybird.

Ik wens u veel leesplezier toe.

Gijs Abbring

Enschede, 28 oktober 2019

Samenvatting

Moneybird is een online boekhoudprogramma voor zzp’ers en mkb’ers. In de afgelopen elf jaar heeft Moneybird al meer dan 150.000 klanten aan zich verbonden. Als een nieuwe klant

overstapt naar Moneybird loopt hij/zij tegen het probleem aan dat er veel handwerk vereist is om gegevens te kunnen overzetten vanaf een vorig boekhoudpakket.

Dit afstudeerproject heeft als doel om het overstappen naar Moneybird zo makkelijk mogelijk te maken voor nieuwe klanten. Om dit te kunnen realiseren in de vorm van een prototype is het project begonnen met een onderzoek. In dit onderzoek is gekeken naar de markt waarin Moneybird zich bevindt en uit welke gegevens een administratie bestaat.

Uit het onderzoek bleek dat een XML auditfile financieel (XAF) de beste oplossing biedt. Dit is een XML bestand dat is ontwikkeld door de Belastingdienst, bedoeld als inzage in een

administratie. Hierin staan veel gegevens over een administratie, zoals facturen, klanten, leveranciers en grootboekrekeningen.

Uiteindelijk is er een prototype opgeleverd waarmee een XAF kan worden ingelezen in

Moneybird. Het prototype is gebouwd en getest om de XAF van de negen pakketten te kunnen inlezen waarvan de meeste klanten overstappen, tijdens het onderzoek is bepaald welke pakketten dit zijn.

Inhoudsopgave

4.1.1 Tools voor het proces 10

4.2 Ontwikkelstraat 11

4.2.1 Tools voor het ontwikkelen 11

4.3 Test Driven Development 12

5 Onderzoeksresultaten 13

5.1 Welke gegevens willen klanten graag overzetten? 13

5.2 Wat zijn de tien financiële softwarepakketten

waar de meeste klanten van overstappen naar Moneybird? 14 5.2.1 Welke financiële softwarepakketten zijn er in de markt van Moneybird? 14 5.3 Uit welke gegevens bestaat een boekhouding

en waar moeten deze gegevens aan voldoen? 15

5.4 Kunnen de financiële softwarepakketten de benodigde gegevens exporteren? 18 5.4.1 Verschil boekhoudsoftware en facturatie software 18

5.4.2 PDF 18

5.4.3 XML Auditfile Financieel (XAF) 19

5.4.4 CSV of Excel 23

5.4.5 API 24

5.4.6 Overzicht exportmogelijkheden top 10 25

5.5 Conclusie 26

6 Requirements 27

7 Implementatie 28

7.1 Applicatie architectuur 28

7.2 Flow 30

7.3 User interfaces & user experience 31

7.3.1 User interface: uploaden 31

7.4 Opslag 32

7.4.1 Moneybird Storage 32

7.4.2 Database 32

7.4.3 Polymorphic association 33 7.5 Validatie 34 7.5.1 XSD validatie 34 7.6 Verwerken 36 7.6.1 Klanten en leveranciers 36 7.6.2 Grootboekrekeningen/categorieën 36 7.6.3 Verkoopfacturen 38

7.6.4 User interface: Resultaat 41

7.7 Huidige staat prototype 42

8 Conclusie 43

9 Aanbevelingen 44

9.1 Meer gegevens uitlezen 44

9.2 Betere weergave resultaten 44

9.3 PDF facturen als bijlage 44

9.4 Wizard 44

10 Reflectie 45

11 Lijst van begrippen 47

11.1 Boekhoudbegrippen 48

12 Bronnenlijst 49

13 Bijlage A - Financiële pakketten 51

14 Bijlage B - Resultaten enquete 52

1 Inleiding

Dit verslag beschrijft de afstudeerperiode bij Moneybird. Het betreft de periode van 7 mei 2019 tot en met 15 november 2019. Moneybird is een organisatie die boekhoudsoftware bouwt voor zzp’ers en mkb’ers. Moneybird richt hierbij op de ondernemers. Moneybird probeert de software voor hen zo simpel en makkelijk mogelijk te maken.

In 2008 begonnen Joost, Berend en Edwin met Moneybird. Zij liepen tijdens het ondernemen tegen het probleem aan dat het bijhouden van de financiële administratie erg tijdrovend is. Ze vonden dat dit makkelijker kon en zijn zelf software hiervoor gaan schrijven. Wat destijds ooit begon als facturatiepakket is nu uitgegroeid tot volwaardig boekhoudpakket. Met inmiddels 38 mensen werkt Moneybird continu aan het verbeteren van de software. Moneybird doet dit voor zo’n 150.000 zzp-ers en mkb'ers.

Regelmatig krijgt Moneybird de vraag van klanten of de bestaande boekhouding kan worden geïmporteerd. Op dit moment biedt Moneybird alleen de oplossing aan om een beginbalans in te vullen. Alle andere gegevens moeten klanten momenteel handmatig invullen. Uit deze vraag van klanten is daarom de volgende hoofdvraag gesteld voor het project.

Hoe kan een nieuwe klant zo makkelijk en snel mogelijk

zijn oude administratie importeren naar Moneybird?

In dit document wordt de gehele afstudeerperiode besproken. Het project is uitgevoerd als onderzoek, waarvoor eerst data is verzameld die relevant is voor de hoofdvraag. Vervolgens is er een prototype geschreven op basis van de gekozen oplossing uit het onderzoek. Het verslag beschrijft de opzet, het proces en de resultaten van het onderzoek.

2 Probleemstelling

Bij Moneybird komen er regelmatig nieuwe klanten met de vraag of de bestaande boekhouding uit een ander boekhoudprogramma kan worden geïmporteerd in Moneybird. Momenteel is het alleen mogelijk om dit handmatig te doen. Moneybird biedt wel een API aan, alleen is dit niet weggelegd voor de doorsnee gebruiker.

Op dit moment is het invoeren van de beginbalans de enige optie voor de gebruiker. Hierdoor heb je als gebruiker de minimale gegevens ingevuld die nodig zijn om verder te kunnen. Als een klant meer gegevens wil, heeft hij twee opties: twee boekhoudingen bijhouden of handmatig gegevens gaan invullen. Beide keuzes hebben als nadeel dat ze tijdrovend zijn en erg foutgevoelig.

Om aan te geven in hoeverre het probleem speelt bij klanten, zijn er verschillende gegevens beschikbaar.

Moneybird heeft op de website een kennisbank beschikbaar voor klanten, hier kunnen klanten veel informatie vinden over features van de software. Recent heeft Moneybird een overzicht gemaakt van de meest gelinkte artikelen over alle tickets van het afgelopen jaar. De tickets zijn mails of berichten die klanten sturen naar Moneybird.

Het artikel (_​https://www.moneybird.nl/kennisbank/overstappen-boekhoudpakket/_​) waar het meeste naar gelinkt is geeft aan dat er veel vraag naar deze functionaliteit is. In dit artikel wordt de bovenstaande situatie uitgelegd, waarbij klanten alleen een beginbalans kunnen invullen en de rest handmatig zullen moeten doen.

Ook is er een onderwerp te vinden op Phabricator (Het (project)managementsysteem van Moneybird) waar wekelijks supportmedewerkers reacties/vragen van klanten plaatsen. In de reacties is te lezen dat klanten van verschillende softwarepakketten over willen stappen of graag verkoopfacturen op een slimmere manier willen importeren dan nu mogelijk is.

Als derde is er een onderzoek _{​(Storm van Leeuwen, 2019)​ gepubliceerd waarbij een enquête} op basis van een steekproef is gehouden. Hier deden 560 mensen aan mee. Na screening vragen hebben zij uiteindelijk 94 gekwalificeerde deelnemers hieruit gevonden. Van deze deelnemers geeft 37% aan te willen overstappen naar een ander boekhoudprogramma. Dit is een vrij hoog percentage. Door het overstappen naar Moneybird makkelijker te maken voor nieuwe klanten kan dat potentieel veel nieuwe klanten opleveren.

3 Opzet

Het onderzoek bestaat uit twee onderdelen: een kwalitatief onderzoek en een mogelijke implementatie in de vorm van een prototype.

Het kwalitatieve onderzoek is gedaan door gebruik te maken van deskresearch. Dit houdt in dat de gegevens worden verzameld vanaf de computer. Er wordt dan gezocht naar interessante gegevens voor het onderzoek. Daarnaast zijn er proef accounts aangemaakt bij verschillende pakketten, welke dit zijn wordt in het onderzoek bepaald. Als laatste is er ook gebruik gemaakt van de beschikbare data in Moneybird. Denk hierbij aan de supportvragen die Moneybird binnenkrijgt.

Doordat in het begin nog niet precies duidelijk is wat de beste oplossing is, zijn er vier

deelvragen opgesteld om de beste oplossing te vinden. Op basis van de antwoorden op deze vragen is een eerste conclusie getrokken. Deze conclusie leidt tot requirements en prioriteiten voor een prototype, waarna er een implementatie kan worden gebouwd.

De implementatie geeft antwoordt op de laatste twee deelvragen. Voor de implementatie is ook deskresearch gedaan en is er gebruik gemaakt van de kennis binnen moneybird.

3.1 Onderzoeksvragen

Naar aanleiding van de probleemstelling is de volgende hoofdvraag opgesteld:

Hoe kan een nieuwe klant zo makkelijk en snel mogelijk zijn oude administratie

importeren naar Moneybird?

Deelvragen

1. Welke gegevens willen klanten graag overzetten?

2. Wat zijn de tien financiële softwarepakketten waar de meeste klanten van overstappen naar Moneybird

a. Welke financiële softwarepakketten zijn er in de markt van Moneybird? 3. Uit welke gegevens bestaat een boekhouding en waar moeten deze gegevens aan

voldoen?

4. Kunnen de financiële softwarepakketten de benodigde gegevens exporteren? a. Overzicht Top 10 financiële softwarepakketten.

5. Hoe is de tool het makkelijkste te gebruiken voor gebruikers?

6. Hoe is het technisch mogelijk om een administratie te kunnen importeren?

4 Aanpak

4.1 Proces

Omdat aan het begin van het project nog niet duidelijk was hoe het probleem moest worden opgelost, is er agile gewerkt met iteraties van één week. Elke week heeft er een

afstudeeroverleg plaatsgevonden, waar de afgelopen week werd besproken en de planning voor de komende week wordt doorgenomen. Hierdoor blijft de voortgang met de

bedrijfsbegeleiders altijd transparant en is het ook mogelijk om te kunnen veranderen van prioriteiten of nieuwe taken in te plannen.

Kanban

Voor het bouwen van de implementatie is er voor de kanban methode gekozen _{​(Kinberg &} Skarin, 2009)_{​. Kanban komt oorspronkelijk uit Japan en betekent letterlijk visueel (kan) en kaart} of bord (ban). Kanban kent vier principes:

- Visualiseer het werk

- Beperk de hoeveelheid onderhanden. - Workflow

- Monitoren, wijzigen, verbeteren

Er is gekozen voor kanban, omdat het hiermee eenvoudig is om het werk te visualiseren. Hierdoor is het makkelijk om de voortgang transparant te houden met de belanghebbenden. Daarnaast heb je zelf ook een goed overzicht van het werk. Doordat kanban geen vaste

meetings heeft gedefinieerd voor teams, is het ook goed te gebruiken voor projecten die worden uitgevoerd door één persoon.

Visualiseren

Het visualiseren gebeurd door middel van een projectbord. Dit bord wordt onderhouden in de tool Phabricator. Aan het begin van de implementatie is de backlog gevuld met taken die nodig zijn om het gewenste prototype te realiseren.

Figuur 1: Het project board op een willekeurig moment in het project.

Beperk de hoeveelheid onderhanden werk

Kanban kent de regel om zo min mogelijk tegelijk uit te voeren. Zo houd je de focus op een taak en rond je deze eerst af voordat je de volgende uitvoert. Daarom zijn er nooit meer dan twee taken in de doing fase te vinden.

Workflow

Om een taak te kunnen afronden, zijn er verschillende fases gedefinieerd in het bord:

1. Backlog_{​: Hier staan in eerste instantie alle taken, die op dat moment bekend zijn. Deze} zijn gesorteerd op de prioriteit die op dat moment belangrijk is.

2. To do_{​: Als er is besloten om een taak van de backlog te gaan uitvoeren in de komende} iteratie of periode wordt deze in ‘to do’ gezet. Op deze manier is er een overzicht van welke taken er waarschijnlijk ook daadwerkelijk af komen.

3. Doing_{​: In de doing fase wordt een taak uitgevoerd. Een van de principes van Kanban is,} om in deze fase zo min mogelijk tegelijk uit te voeren en zo veel mogelijk af te ronden. 4. Review_{​: In de review fase wordt de taak bekeken door een andere programmeur van}

Moneybird, dit zijn voornamelijk de bedrijfsbegeleiders geweest. Als zij akkoord gaan kan de taak naar done.

5. Done_{​: De taak is klaar en er kan een volgende taak worden opgepakt.} Monitoren, wijzigen, verbeteren

Zoals eerder besproken, is er wekelijks overleg met de bedrijfsbegeleiders. Waar elke keer goed wordt gemonitord en eventuele wijzigingen en verbeteringen worden besproken.

Milestones

Later in het project ontstond het probleem dat het niet overzichtelijk was, wat er allemaal zou worden opgeleverd in de nog resterende tijd. Om dit inzichtelijk te maken, zijn er toen

milestones opgesteld. Hierin staat beschreven in welke week een bepaalde taak af zou moeten zijn om het einddoel te kunnen halen. Door wekelijks deze globale planning te bespreken, was er een goed overzicht van het eindresultaat.

4.1.1 Tools voor het proces

Slack is het communicatiemiddel voor de simpele en kortere berichten bij Moneybird. Voor de afstudeerperiode is Slack erg handig om snel en makkelijk berichten te delen met collega's. Door in slack een eigen kanaal te gebruiken voor het afstudeerproject is het eenvoudig om snel informatie uit te wisselen die relevant is voor het project.

Google

Iedere werknemer bij Moneybird heeft een eigen Google account. Hiervan wordt de mail en de agenda gebruikt. Alle documenten worden opgeslagen in Google Drive en bewerkt met tools zoals Google Docs.

Phabricator

Phabricator is de project management tool van Moneybird. Het kanban bord, zoals te zien op de bovenstaande afbeelding, wordt beheerd in Phabricator. Daarnaast is Phabricator ook gebruikt voor de notulen van het wekelijkse overleg.

4.2 Ontwikkelstraat

Moneybird heeft al een goede ontwikkelstraat, deze is daarom ook gebruikt bij het bouwen van de implementatie. Het ontwikkelproces van een backlog taak naar de uiteindelijke Moneybird applicatie gaat als volgt:

1. De taak met de meeste prioriteit wordt opgepakt.

2. Er wordt een feature branch aangemaakt op basis van de laatste develop branch. 3. De specs worden geschreven (test driven development, zie volgende hoofdstuk) 4. De implementatie wordt geschreven.

5. Er wordt een code review aangevraagd, waarbij er ook een automatisch een build wordt gestart.

6. De feedback van de review en de build worden, wanneer nodig, verwerkt. 7. De verandering wordt gepusht naar de development branch.

4.2.1 Tools voor het ontwikkelen

De implementatie is geschreven in Ruby on Rails. Dit is het framework waarin de Moneybird applicatie is geschreven. Bij het ontwikkelen hieraan zijn verschillende tools gebruikt, waarbij sommige standaard zijn binnen Moneybird.

Visual studio code

Visual studio code is gebruikt als de IDE.

Phabricator

Voor het ontwikkelen is Phabricator gebruikt als kennisbank en voor de code reviews. Met Phabricator is het makkelijk om een verandering in de code te koppelen aan een taak van het kanban bord. Via arcanist, de command line tool voor Phabricator, kan er een code review en een build wordt gestart.

Git(hub)

Git is gebruikt voor het versiebeheer van de code. De code zelf wordt uiteindelijk ondergebracht in Github.

Buildkite

Buildkite is de tool waarmee build automation wordt uitgevoerd.

4.3 Test Driven Development

Het testen van het prototype is gedaan volgens Test Driven Development (TDD). Dit is een principe waarbij je eerst geautomatiseerde tests gaat schrijven en dan code gaat schrijven om geschreven tests te laten slagen.

Voor het schrijven van de geautomatiseerde tests wordt het framework Rspec gebruikt. Dit is een framework dat standaard beschikbaar is voor Ruby. Met dit framework worden zo

genoemde specs geschreven.

Test Driven Development volgt de onderstaande stappen totdat alle specs zijn geschreven en slagen.

- Schrijf een spec - Voer de specs uit

- Schrijf code om de tests te laten slagen - Voer de specs uit

- Refactor de code

Zoals eerder vermeld maakt Moneybird gebruikt van build automation. Bij elke build worden dan ook alle specs gedraaid. Op deze manier wordt dus ook getest of de bestaande functionaliteit nog steeds werkt.

5 Onderzoeksresultaten

Zoals in de opzet vermeld bestaat het onderzoek uit twee onderdelen. In dit hoofdstuk worden de resultaten van het literatuuronderzoek behandeld. Dit zijn de eerste vier deelvragen. De deelvragen hebben als doel om te bepalen welke oplossing de beste is voor het probleem en welke requirements er hiervoor nodig zijn. In dit hoofdstuk worden de resultaten besproken en toegelicht aan de hand van de data.

5.1 Welke gegevens willen klanten graag overzetten?

Om deze vraag te kunnen beantwoorden is er een steekproef genomen op de tickets in

Sirportly, het supportsysteem van Moneybird. Voor de steekproef zijn alle tickets van de periode 1 mei 2019 tot 13 juni 2019 gebruikt, waarin vragen zijn over overstappen naar Moneybird. Om een beeld te geven waar de klanten van willen overstappen uit deze tickets is in dit

overzichtelijk gemaakt in de onderstaande afbeelding (figuur 2).

Figuur 2: Overzicht van 49 tickets over het overstappen naar Moneybird

In de chart is te zien dat de meeste mensen niet vermelden wat hun huidige systeem is. De meeste vragen gaan over hoe ze kunnen overstappen of hoe ze facturen kunnen importeren naar Moneybird. Bij de categorie overig zijn er een aantal vragen van mensen die Moneybird administraties willen samenvoegen of mensen die facturen willen importeren van systemen die specifiek voor een bepaalde branche zijn gemaakt, zoals advocatuur.

Uit deze steekproef zou je de nieuwe klanten kunnen opdelen in twee groepen. Klanten die graag een hele boekhouding van hun huidige boekhoudpakket willen meenemen en klanten die alleen verkoopfacturen willen importeren, van bijvoorbeeld hun facturatiepakket.

5.2 Wat zijn de tien financiële softwarepakketten waar de meeste

klanten van overstappen naar Moneybird?

Er is voor gekozen om een top 10 van boekhoudpakketten samen te stellen waarvan klanten overstappen naar Moneybird. Doordat er geen recente marktaandelen beschikbaar zijn en er geen harde data beschikbaar is over de pakketten waar klanten van overstappen, is er gekozen om dit via een enquête in kaart te brengen. De enquête is gehouden over de support

medewerkers van Moneybird. Hen is gevraagd om onafhankelijk een top 10 samen te stellen op basis van hun ervaring. De resultaten zijn de vinden in de bijlage ‘resultaten enquête’.

5.2.1 Welke financiële softwarepakketten zijn er in de markt van

Moneybird?

Moneybird krijgt dagelijks veel nieuwe klanten, veel van deze klanten stappen dan ook over vanuit andere financiële software. Binnen de financiële software zijn er twee soorten software voor de doelgroep van zzp’ers en mkb’ers: facturatiesoftware en boekhoudsoftware.

De facturatiesoftware heeft als doel om de ondernemer te helpen tijdens de dagelijkse verkooptaken, zoals klanten beheren en offertes of facturen versturen. Terwijl een

boekhoudprogramma als doel heeft om de financiële staat onderneming in kaart te brengen en te beheren.

Alle softwarepakketten die gebruikt zijn voor dit onderzoek zijn te vinden in de bijlage ‘financiële pakketten’. Hierin zijn staan 54 boekhoudpakketten welke afkomstig zijn uit de Gids

boekhoudsoftware 2019 _{​(Bottemanne, 2019)​. Daarnaast is er data beschikbaar van elf} facturatiepakketten, die gevonden zijn op de website van Softwarepakketten.

Top 10

De uiteindelijke top 10 is berekend op basis van posities die respondenten hebben toegekend aan de softwarepakketten. Hiervoor geldt dat het aantal punten de omgekeerde positie is, dus tien punten voor de eerste plek, negen punten voor de tweede plek etc. Uit de steekproef van de tickets van Sirportly waren er elf tickets waarin werd beschreven van wat het huidige/ vorige pakket is. Van deze elf staan er acht in de onderstaande top 10.

1. Exact 6. Moneymonk

2. Snelstart 7. Twinfield

3. Acumulus 8. Informer

4. Davilex 9. Jortt

5. e-boekhouden 10. Tellow

5.3 Uit welke gegevens bestaat een boekhouding en waar

moeten deze gegevens aan voldoen?

Bij deze deelvraag wordt er gekeken naar de gegevens in Moneybird en naar eventuele wettelijke verplichtingen die gelden voor een administratie. Om de bepalen welke gegevens er nodig zijn, is de Moneybird applicatie gebruikt. Daarnaast heeft een Moneybird een API

documentatie (Moneybird, 2019) waarin staat beschreven waar gegevens aan moeten voldoen. Als laatste is ook de website van de Belastingdienst _{​(Belastingdienst, z.d.-a)​ gebruikt om de} wettelijke eisen van een boekhouding in beeld te brengen.

Bedrijfsgegevens

Van het bedrijf van de klant zijn er verschillende gegevens nodig zodat hij in staat is om zaken als facturen en offertes te versturen. Het gaat dan om de volgende gegevens:

- Naam van het bedrijf - Adres van het bedrijf - Btw-nummer

- Kvk-nummer - Rechtsvorm

Contacten

De contacten binnen Moneybird zijn een verzameling van alle debiteuren en crediteuren, ook wel klanten en leveranciers genoemd. Als de contacten als CSV of vCard beschikbaar zijn, is het al mogelijk om deze te importeren, andere formaten worden nog niet ondersteunt. De contacten zijn in Moneybird nodig om verkoopfacturen, inkoopfacturen, bonnetjes of algemene documenten aan de maken. Voor het aanmaken van een contact is minimaal een bedrijfsnaam of een voor- en achternaam van een persoon nodig. Daarnaast zijn de adresgegevens voor klanten ook nodig, deze zijn namelijk verplicht op een factuur.

Grootboekrekening/categorieën

In Moneybird worden grootboekrekeningen categorieën genoemd. Bij het maken van een Moneybird administratie zijn er standaard al veel categorieën beschikbaar zoals, omzet,

algemene kosten, debiteuren etc. Om een categorie aan te maken in Moneybird is er een naam en een categorie type nodig. De categorie types zijn gebaseerd op de verschillende posten op de resultatenrekening en balans. Hieronder een overzicht van alle types.

Resultatenrekening Balans

- Omzet

- Kosten van de omzet

- Kosten

- Overige inkomsten en uitgaven

- Vaste activa

- Vlottende activa

- Eigen vermogen

- Voorzieningen

- Lang vreemd vermogen

- Kort vreemd vermogen

Tabel 2: Overzicht van alle categorie types in Moneybird.

Verkoopfacturen

Moneybird stelt een aantal verplichtingen aan een factuur. Deze zijn onder andere gebaseerd op wettelijke verplichtingen. Ook heeft een verkoopfactuur ook een aantal afhankelijkheden. Het is namelijk niet mogelijk om een factuur aan te maken zonder een contact, bedrijfsgegevens en factuurregels met de bijbehorende categorieën. Een factuur vereist dus minimaal de volgende gegevens:

- Naam en adres van de afnemer en bedrijf van de klant - Btw-nummer klant - Kvk-nummer klant - Factuurdatum - Opeenvolgend nummer - Factuurregels - Bedrag - Beschrijving - Categorie - Bedrag exclusief BTW - BTW bedrag Inkoopfacturen en bonnetjes

Moneybird heeft voor gebruikers een onderscheidt gemaakt in inkoopfacturen en bonnetjes. Het verschil hierin is dat bonnetjes al betaald zijn op het moment van invoeren en facturen nog niet. Voor inkoopfacturen en bonnetjes gelden dezelfde regels en afhankelijkheden als bij de

verkoopfacturen, alleen is het bedrijf van de klant nu de afnemer.

Openingsbalans

Om de balans van het oude pakket mee te nemen naar Moneybird een moet er een

openingsbalans worden gegenereerd in Moneybird. Het invullen van de openingsbalans is een memoriaalboeking. De balans bestaat uit twee zijdes debit en credit, de bedragen van deze twee zijdes zullen hetzelfde moeten zijn om een geldige aanpassing te maken op de balans.

Bank- en kastransacties

Alle inkomende en uitgaande geldtransacties van een administratie vallen hieronder. Om in een Moneybird een transactie aan te maken is een rekening, kenmerk en het bedrag nodig. Bij transacties is het dus belangrijk dat de rekeningen van de ondernemer al zijn toegevoegd.

Overige gegevens

Binnen Moneybird kunnen er nog veel meer gegevens worden toegevoegd. Dit zijn gegevens geen invloed hebben op de balans of resultatenrekeningen van een administratie, wel kunnen ze wenselijk zijn voor klanten. Denk hierbij aan algemene documenten, producten (die op facturen kunnen worden gebruikt) of offertes.

5.4 Kunnen de financiële softwarepakketten de benodigde

gegevens exporteren?

Er zijn verschillende manieren beschikbaar om data te kunnen exporteren. Bij deze deelvraag zal worden onderzocht welke exportmogelijkheden er zijn en welke bedrijven deze

ondersteunen. Ook zal inzichtelijk worden gemaakt wat de mogelijkheden zijn met dit type export.

De data hiervoor is verzameld op basis van de Gids boekhoudsoftware 2019 van het GBNED (Bottemanne, 2019)_{​. In deze gids staan alle 54 boekhoudpakketten van Nederland met data} over verschillende features. Om vervolgens meer informatie te winnen over de top 10 pakketten van de tweede deelvraag, zijn er proefaccounts aangemaakt bij deze pakketten. De formaten die besproken worden: PDF, CSV/Excel, XML auditfile financieel en API.

5.4.1 Verschil boekhoudsoftware en facturatie software

Over het algemeen zijn er een aantal verschillen tussen boekhoudsoftware en

facturatiesoftware. Bij facturatie software is het over het algemeen zo dat de facturen en contacten te exporteren zijn als Excel-bestand of CSV. Als dit niet het geval is dan zijn de facturen vaak beschikbaar als XML of PDF-bestand. Voor boekhoudsoftware is er vaak een XML auditfile financieel beschikbaar, bij boekhoudpakketten is in mindere mate CSV of Excel bestanden beschikbaar.

5.4.2 PDF

Alle pakketten, zowel boekhoud- als facturatiepakketten zijn in staat om facturen te exporteren als PDF documenten. Doordat PDF niet bedoeld is als een datastructuur is het moeilijk om geautomatiseerd de data eruit te lezen.

Voordelen

Nadelen

Alle pakketten kunnen het exporteren Niet goed uit te lezen, waardoor nog veel handwerk vereist is.

Originele document Alleen facturen kunnen als PDF worden geëxporteerd, data zoals contacten of grootboekrekeningen niet.

Tabel 3: Voor- en nadelen van PDF

5.4.3 XML Auditfile Financieel (XAF)

Een XML Auditfile Financieel, ook wel XAF genoemd, is een XML bestand dat is ontwikkeld door de belastingdienst bedoeld als inzage in een administratie. In het bestand zijn de meest relevante gegevens van een administratie over een bepaalde periode zijn opgeslagen. Het bestand bevat de stamgegevens, openingsbalans en transacties over een bepaalde periode, vaak een boekjaar. In de onderstaande grafiek is te zien dat ruim 80% van alle

boekhoudsoftware auditfiles kan exporteren _{​(Bottemanne, 2019)​.}

Figuur 3: Overzicht van alle boekhoudpakketten die een Auditfile van versie 3.1 of hoger kunnen exporteren.

XSD

Het valideren van een XAF bestand gebeurt middels een XSD. XSD is een bestand dat de structuur van een XML beschrijft. Het is dan mogelijk om een XML bestand te valideren op basis van een XSD. De Belastingdienst heeft alle documentatie _{​(Belastingdienst, z.d.-b)​ over de} XAF openbaar gezet, hierin is onder andere de XSD te vinden. Hieronder een belangrijk citaat uit de documentatie.

“Vanwege de diversiteit aan gegevens in de diverse software systemen zijn in deze specificatie veel velden optioneel gemaakt. Het is echter verplicht de optionele velden te vullen indien de gegevens in het systeem voorhanden zijn.”

In de bovenstaande tekst wordt gezegd dat veel velden optioneel zijn. Dit is ook goed te zien in bijvoorbeeld de XSD. Maar doordat pakketten wel de verplichting hebben om de gegevens in te vullen, bevatten de auditfiles in de praktijk veel nuttige informatie. Er zijn daarom twee tabellen opgesteld om overzichtelijk weer te geven welke gegevens er beschikbaar zijn.

XML auditfile financieel voor de top 10

Om weer te geven welke informatie de auditfiles van de top 10 pakketten exporteren, is de onderstaande tabel opgesteld. Het onderdeel transacties is heel breed, daarom is op de volgende pagina voor het onderdeel transacties nog zo’n tabel opgesteld.

XAF Contacten Grootboekrekeningen Openingsbalans Transacties

Exact ✓ ✓ ✓ ✓ Snelstart ✓ ✓ x ✓ Acumulus x x x x Visma/Davilex ✓ ✓ ✓ ✓ e-boekhouden ✓ ✓ ✓ ✓ Moneymonk ✓ ✓ x ✓ Twinfield ✓ ✓ x ✓ Informer ✓ ✓ x ✓ Jortt ✓ ✓ x ✓ Tellow ✓ ✓ x ✓

Tabel 4: Overzicht van de inhoud van de XAF voor de top 10 pakketten

Transacties

De transacties zijn het belangrijkste onderdeel van de administratie, hier is namelijk het

financieel dagboek te vinden. In het dagboek staat alle gebeurtenissen die leiden tot wijzigingen van het vermogen van de onderneming. Doordat dit onderdeel verschilt per pakket is er een overzicht gemaakt.

Met de kolommen wordt het volgende bedoeld:

- Factuurregels_{​: Alle factuurregels staan in de XAF. Per regel zijn dan de volgende} gegevens vereist: prijs, omschrijving, BTW en grootboekrekening/categorie.

- Factuurregels detail: _{​zelfde als factuurregels alleen nu is ook een aantal per regel} vereist.

- Factuur verwijzing_{​: Er wordt bij een factuur verwezen naar een document, via het} element invRef, docRef, recRef.

- Betaling verwijzing_{​:​ ​Er wordt bij een betaling verwezen naar de factuur, via het element} invRef, docRef of recRef.

- Verwijzing via beschrijving_{​: Er wordt bij een betaling verwezen naar de factuur door} het desc element te gebruiken.

XAF Transacties Factuurregels Factuurregels detail Factuur Verwijzing Betaling verwijzing Verwijzing via beschrijving Exact ✓ ✓ ✓ ✓ x Snelstart ✓ x ✓ ✓ x Acumulus x x x x x Visma/Davilex ✓ x ✓ ✓ ✓ e-boekhouden ✓ x ✓ ✓ x Moneymonk ✓ x ✓ x ✓ Twinfield x x ✓ ✓ x Informer ✓ x x x ✓ Jortt x x ✓ x x Tellow ✓ x ✓ ✓ x

Tabel 5: Overzicht van de inhoud van het onderdeel transacties in de XAF voor de top 10 pakketten.

Toelichting transacties

Voor de transacties zijn twee zaken van de belang: tot in hoe ver zijn de details beschikbaar en de koppelingen van facturen met de transacties.

Zoals in de tabel is zien ontbreken de factuurregels vaak in detail in de XAF, dit komt

voornamelijk doordat de hoeveelheid van een factuurregels niet altijd goed is ingevuld. Het is wel mogelijk om een factuur aan te maken zonder hoeveelheid. Het aanleveren van een PDF facturen kan de oplossing bieden op missende gegevens. Bij bijna ieder pakket is er wel een verwijzing, kenmerk of referentie te vinden naar de factuur.

Een tweede probleem van de transacties is dat het ook niet altijd mogelijk is om te achterhalen wat de status is van facturen. In een auditfile staat niet wat de uiterlijke factuurdatum is.

Hierdoor is niet te achterhalen of de factuur verlopen is. Als de mutatie van de betaling een verwijzing/referentie bevat naar de factuur is het wel mogelijk om te achterhalen. Als de betaling buiten de periode van de auditfile om is gebeurd is het ook niet mogelijk om te achterhalen of de betaling al heeft plaatsgevonden.

Voordelen

Nadelen

De XAF auditfile kan alle benodigde informatie bevatten.

Alle gegevens over de boekhouding zijn optioneel.

De hele boekhouding staat in een bestand Vaak zijn net niet alle gegevens van een factuur aanwezig.

Een standaard Alleen boekhoudpakketten kunnen auditfiles exporteren.

Makkelijk in te lezen en te valideren door gebruik te maken van een XSD

De originele documenten ontbreken

Tabel 6: Voor- en nadelen van de XAF.

5.4.4 CSV of Excel

Veel pakketten zijn in staat om CSV of Excel bestanden te kunnen exporteren. Doordat er voor CSV of Excel bestanden geen standaarden zijn, is er geen overzicht gemaakt tussen de verschillende pakketten. De verschillen zijn te groot om hier goede vergelijkingen in te maken. Wel bieden veel pakketten en vooral ook facturatiepakketten exportmogelijkheden op deze manier aan. Het gaat dan vooral om de volgende gegevens:

- Alle facturen

- Debiteuren- of crediteurenoverzicht - Grootboekoverzicht (inclusief bedragen)

Figuur 4: Statistiek van de CSV/Excel exportmogelijkheden voor 11 facturatiepakketten.

Voordelen Nadelen

Bijna alle pakketten kunnen tenminste een gedeelte van de benodigde informatie exporteren.

Geen standaard.

Bevat alleen delen van een boekhouding, nooit een gehele boekhouding

Bevat vaak niet alle gegevens die nodig zijn voor een factuur

De originele documenten ontbreken

Tabel 7: voor- en nadelen van CSV/Excel

5.4.5 API

Veel financiële softwarepakketten kunnen data exporteren via een API. Via API’s is het mogelijk om nagenoeg alle data van een pakket te kunnen ophalen. Bij de API’s valt op dat bij de top 10 softwarepakketten er negen zijn die een API aanbieden, terwijl in de markt van de

boekhoudpakketten dit maar zo’n 40% zijn. Dit is onder andere te verklaren doordat er ook veel pakketten zijn die nog on premise werken.

Doordat API’s geen standaard volgen, moet er een implementatie per pakket moeten worden geschreven. Daarnaast zullen ook de koppelingen met de API’s up-to-date moeten blijven. Dit betekent dat het veel tijd in beslag zal nemen om nieuwe pakketten toe te voegen en de huidige pakketten te onderhouden.

Figuur 5 en 6: Boekhoudpakketten(links) en facturatie pakketten(rechts) die een API ter beschikking stellen.

Extra vraagstuk

De API is bedoeld om koppelingen te maken met andere software. Als je tegen deze API wil aanpraten, is het vaak is vereist om de applicatie (Moneybird) te registreren. Het is nog maar zeer de vraag of andere pakketten dit allemaal zullen accepteren. In dit onderzoek is er geen verder onderzoek gedaan naar dit vraagstuk. Dit zal dus nog moeten gebeuren als er gekozen wordt om een API te gaan gebruiken.

Voordelen Nadelen

Nagenoeg alle data op te halen Geen standaard, waardoor een implementatie per pakket vereist is. 9 van de top 10 boekhoudpakketten bieden

een API aan.

API koppelingen moeten worden onderhouden.

Tabel 8: voor- en nadelen van een API

5.4.6 Overzicht exportmogelijkheden top 10

In de onderstaande tabel is een overzicht te zien van de top 10 pakketten met al hun export mogelijkheden.

Om als groen gecheckt te staan gelden de volgende regels per exporttype.

- XAF_{​: Het pakket moet een XAF van versie 3.1 of hoger kunnen exporteren.} - CSV/Excel_{​: Het pakket kan facturen, debiteuren, crediteuren of een grootboek}

exporteren in CSV of excel formaat.

- UBL_{​: Het pakket kan UBL facturen exporteren naar de gebruiker.}

- API_{​: Het pakket stelt een API beschikbaar voor koppeling. Oranje betekent dat de} klanten niet standaard toegang hebben tot de API.

Export XAF CSV/Excel PDF API

Exact ✓ ✓ ✓ ✓ Snelstart ✓ x ✓ ✓ Acumulus x ✓ ✓ ✓ Visma/Davilex ✓ ✓ ✓ ✓ e-boekhouden ✓ ✓ ✓ ✓ Moneymonk ✓ x ✓ x Twinfield ✓ ✓ ✓ ✓ Informer ✓ x ✓ ✓ Jortt ✓ x ✓ ✓ Tellow ✓ ✓ ✓ ~

Tabel 9: Overzicht van alle exportmogelijkheden voor de top 10 pakketten.

Toelichting

De bovenstaande tabel laat een aantal interessante interessante statistieken zien. Zo liggen de statistieken van de exportmogelijkheden van de top 10 hoger ten opzichte van de rest van de markt, dit geldt voor zowel de XAF als de API.

5.5 Conclusie

In markt van de financiële software voor kleine bedrijven zijn er verschillende mogelijkheden om data te kunnen exporteren en vervolgens importeren naar Moneybird. Voor dit onderzoek is er gekeken naar XAF, PDF, CSV/Excel en API’s. Om in kaart te brengen wat goede opties kunnen zijn, is er onderzoek gedaan naar de behoefte van de klant, de mogelijkheden die bedrijven bieden en de verplichtingen waar de data aan moet voldoen.

Uit de data van de tickets is gebleken dat de facturen het belangrijkste punt zijn voor de klant. Doordat Moneybird momenteel geen oplossing biedt om deze makkelijk te importeren vanuit andere softwarepakketten, is dit een veelgevraagde feature van klanten.

Om een goede keuze te maken tussen de verschillende exportmogelijkheden is er een selectie gemaakt op tien financiële softwarepakketten waar de meeste klanten van overstappen naar Moneybird. Per pakket is inzichtelijk gemaakt welke exportmogelijkheden er aanwezig zijn. Hierin viel op dat de top 10 pakketten beter in staat zijn om data te kunnen exporteren dan de rest van de markt. Zo biedt de top 10 procentueel gezien meer mogelijkheden. Bijvoorbeeld bij de API’s waar 90% van de top 10 pakketten dit aanbiedt en maar 50% van de gehele markt dit aanbiedt.

Van de exportmogelijkheden is de XAF de beste keuze. De XAF is het enige formaat dat een standaard volgt en bevat daarnaast veel gegevens. Via een API is het mogelijk om de meeste gegevens te exporteren, alleen moet er dan een implementatie per pakket geschreven en onderhouden worden. Daarnaast is er ook het extra vraagstuk waarbij Moneybird zich moet registreren als applicatie. Ook CSV/excel bestanden zijn niet interessant doordat er geen standaard is. Daarnaast ontbreken er vaak gegevens en biedt ook maar 6 van de 10 pakketten een CSV export aan. PDF facturen op zichzelf kunnen handig zijn voor klanten, alleen wordt er dan nog steeds veel handwerk van de klant gevraagd.

De XAF volgt een standaard, bevat veel informatie over een administratie en kan door 80% van de softwarepakketten worden geëxporteerd. Hierdoor hoeft er maar een implementatie te worden geschreven voor alle pakketten. Dit betekent ook dat er alleen maar onderhoud hoeft te komen voor deze implementatie en dat er makkelijk nieuwe pakketten kunnen worden

ondersteunt.

Boekhoudkundig bevat een XAF nagenoeg alle informatie die nodig is. Doordat veel velden optioneel zijn, kan er data ontbreken. In de praktijk vullen softwarepakketten de XAF wel in met de beschikbare gegevens waardoor het een interessante optie is. Een XAF bevat geen

documenten waardoor de officiële factuur of bon mist. Dit zou kunnen worden opgelost door deze documenten als PDF erbij te leveren. Op basis van factuurnummers kunnen deze dan gekoppeld worden.

6 Requirements

De requirements zijn opgesteld op basis van de resultaten van de eerste deelvragen van het onderzoek. Doordat aan het begin van het project nog niet duidelijk was welke requirements er aan het project moesten worden gesteld, zijn deze later opgesteld.

Requirement Functioneel Prioriteit

De top 5 pakketten* die auditfiles kunnen exporteren, moeten minimaal de gegevens die beschreven worden in de tweede

requirement kunnen verwerken. F Must

De verkoopfacturen en de daarbij behorende data (klantgegevens

en grootboekrekeningen) kunnen worden verwerkt. F Must Het moet eenvoudig zijn om auditfiles van nieuwe

boekhoudpakketten te ondersteunen. Alleen het implementeren van de uitzonderingen van een nieuw pakket moeten nog geschreven

worden worden. NF Must

De bedrijfsgegevens kunnen worden geïmporteerd F Should De top 10 pakketten* die auditfiles kunnen exporteren, moeten

minimaal de gegevens van de must requirements kunnen

verwerken F Should

De inkoopfacturen en transacties kunnen worden geïmporteerd. F Should De gebruiker kan PDF documenten uploaden die worden

opgeslagen als bijlage van facturen of bonnetjes. F Could De tool is in staat om ongestructureerde** data te verwerken naar

Moneybird. F Won’t

Tabel 10: Requirements voor het prototype

Extra opmerkingen

* De top 5 of 10 boekhoudpakketten die bepaald zijn tijdens het onderzoek.

** Ongestructureerde data is data die niet een specifiek formaat volgt.

Tabel 11: Extra opmerkingen requirements

7 Implementatie

In het hoofdstuk implementatie worden de laatste twee deelvragen beantwoordt. Er wordt besproken welke technische keuzes er zijn gemaakt en hoe het prototype het makkelijkste is te gebruiken voor klanten. De implementatie is geschreven in Ruby on Rails _{​(“Ruby on Rails”,} z.d.)_{​, dit is is een open source framework voor het maken van webapplicaties. Dit wordt gebruikt} omdat de Moneybird applicatie hierin is geschreven.

7.1 Applicatie architectuur

MVC is een architectuur voor softwareapplicaties, Ruby on Rails maakt hier gebruik van. Naast models, views en controllers biedt Rails nog meer standaardcomponenten, zoals Jobs en Mutations. Laatstgenoemde framework is gekozen om de controllers overzichtelijker te houden en de business logic te verdelen in kleine stukjes. Daarnaast is het valideren van de variabelen ook makkelijk gemaakt met mutations.

Figuur 7: Overzicht van de Moneybird applicatie structuur.

In het bovenstaande overzicht is de architectuur van de Moneybird applicatie te zien. Alle blauwe blokken zij de verschillende componenten, die elk hun eigen taak hebben in de

applicatie. In het overzicht zijn alleen de componenten meegenomen die worden gebruikt in dit project, hier zitten tevens ook de belangrijkste componenten in.

Bij het opvragen van de applicatie via de webserver zorgt de _{​router​ ervoor dat de juiste} controller_{​ wordt aangeroepen, zodat de gebruiker krijgt te zien wat hij opvraagt. De controller} regelt nu de business logic van de applicatie door gebruik te maken van de _{​jobs​ en ​mutations.}

Als er een _{​job​ wordt gestart, wordt de code uitgevoerd in de achtergrond. Dit is handig bij het} uitvoeren van grote taken. Moneybird gebruikt hiervoor de gem Sidekiq _{​(Perham, 2012/2019)​.} Met deze gem is het simpel om efficiënt achtergrondprocessen te draaien in Ruby.

Voor het uitvoeren van kleine stukjes logica worden _{​mutations​ geschreven. De ​mutations} zorgen ervoor dat niet alle logica in de controllers staat, maar dat het verdeeld is over verschillende _{​mutations​. Hierdoor is het makkelijker om kleine delen code te testen en te} hergebruiken. Hiervoor wordt de gem mutations _{​(“Cypriss/mutations”, z.d.)​ gebruikt.} Via _{​validators​ is het mogelijk om extra validaties te schrijven voor een model. ​Validators} checken dan bepaalde waardes van het veld

Als de _{​controller​ klaar is met het ophalen van de data zorgt de ​view​ component ervoor dat de} data goed wordt weergegeven.

7.2 Flow

Om een overzichtelijk beeld te geven van de import functie is er een data flow diagram opgesteld. De startsituatie is het uploadscherm. Dit is het eerste scherm van de flow. De

gebruiker kan hier zijn XAF uploaden waarna hij zal moeten wachten totdat de import klaar is en hij het resultaat op zijn te zien krijgt.

Figuur 10: Data flow diagram van de import functie

De bovenstaande diagram geeft globaal weer welke processen (cirkels) er zijn en welke data er wordt opgeslagen (de rechthoeken met een open rechterkant).

Alle processen die in de blauwe rechthoek staan worden uitgevoerd als een background job. Als een taak langer dan één seconde duurt is het al niet meer wenselijk om dit synchroon op te lossen. De gebruiker blijft dan tegen een ladende pagina kijken. Door het valideren en verwerken als background job uit te voeren, ondervindt de gebruiker geen vertragingen in de applicatie. Daarnaast zou de gebruiker zelfs Moneybird kunnen afsluiten en later het resultaat gaan bekijken.

Zoals vermeld in het hoofdstuk opslag, heeft een import verschillende statussen. De job verandert tijdens het valideer- en verwerk proces steeds de status. Zolang de status niet ‘finished’ of ‘finished_with_error’ is, zal de gebruiker een loader zien op het scherm om aan te geven dat de import nog bezig is.

Als er tijdens het valideren van het bestand een fout optreedt wordt deze fout weggeschreven naar de database, wordt de status verandert naar ‘finished_with_error’ en wordt het process beëindigd. Als er tijdens het verwerken iets fout gaat wordt er weggeschreven welke objecten er niet zijn gelukt, zodat aan het einde van het proces de gebruiker precies kan zien wat er niet is meegenomen. Op deze manier blijft de gebruiker altijd overzicht houden van het gehele proces en kan hij/zij eventueel zelf een aantal zaken corrigeren of handmatig invullen waar nodig.

7.3 User interfaces & user experience

Een van de deelvragen luidt: Hoe is de tool het makkelijkste te gebruiken voor gebruikers? Een antwoordt op deze vraag is gezocht door in samenwerking met de UX/UX-designers van Moneybird de schermen en flow voor gebruikers te ontwikkelen. Om een goed antwoord te kunnen vinden op de vraag zijn gebruikerstesten vereist. Dit is omwille van de tijd niet gebeurd. De huidige schermen zijn ontwikkeld op basis van de ervaring van de designers binnen

Moneybird.

Voor het ontwikkelen van de schermen heeft Moneybird een eigen design system met daarin veel componenten van de Moneybird UI, zoals de buttons of tabellen. Hierdoor zijn de schermen eenvoudig te definiëren en zijn de consistent met de rest van de applicatie. Bij het maken van de schermen is er dan ook zoveel mogelijk gebruik gemaakt van de beschikbare componenten.

7.3.1 User interface: uploaden

In de onderstaande afbeelding (figuur 9) is het upload scherm te zien. Aan de hand van de korte beschrijving wordt uitgelegd wat de gebruiker wat hij kan verwachten als hij een bestand gaat uploaden en de import gaat starten. Er wordt precies uitgelegd welke pakketten er ondersteunt worden en welke gegevens er in Moneybird worden geïmporteerd. Zo weet de gebruiker wat hij kan verwachten en kan hij de keuze maken om verder te gaan door het bestand te uploaden en op “Start importeren” klikken of hij kan nog annuleren.

Figuur 9: Scherm om een XAF te uploaden

7.4 Opslag

7.4.1 Moneybird Storage

Moneybird Storage is een interface met AWS S3 (Een cloudopslag voor bestanden van

Amazon). De interface is gebouwd om het downloaden en uploaden te vergemakkelijken. Als de gebruiker een bestand upload, is de eerste stap om deze te uploaden naar Moneybird Storage. De bestanden worden opgeslagen zodat ze altijd weer kunnen worden geraadpleegd als er iets fout gaat bij het analyseren of verwerken van de gegevens.

7.4.2 Database

Om bij te houden welke data er is geïmporteerd en welke bestanden hiervoor zijn gebruikt zijn, is er een database ontwerp nodig. Een import wordt opgeslagen in _{​administration_imports​.} Deze tabel heeft een one-to-many relatie met een administratie, waardoor het mogelijk is om meerdere imports per administratie te doen. Hierdoor is het mogelijk om bijvoorbeeld meerdere boekjaren te importeren. Het state veld is bedoeld om de gebruiker op de hoogte te houden van de import.

Om ook ondersteuning te bieden voor meerdere bestanden, zoals PDF documenten, is er de tabel _{​administration_import_files.​ De tabel slaat de hash op die nodig is om het bestand uit} Moneybird storage te lezen en het type bestand zodat de bestanden goed worden verwerkt.

Figuur 7: Overzicht van de Moneybird applicatie structuur.

Om bij te houden welke data er verwerkt wordt en welke data er niet, zijn er twee tabellen: administration_import_data_{​ en ​administration_import_unprocessed​.}

In de tabel _{​administration_import_data​ staat beschreven welke database rijen zijn}

toegevoegd bij de import. Hierdoor wordt precies bijgehouden welke data er geïmporteerd is, zodat er nog een mogelijkheid is om de import terug te draaien. Ook is het nu mogelijk om via de user interface te laten zien dat het object via een import is ontstaan.

In de tabel _{​administration_import_unprocessed​ wordt de data opgeslagen met het type json.} Doordat vooraf niet bekend is welke velden aanwezig zijn, is het niet wenselijk om dit op een relationele manier op te slaan. Postgres biedt drie mogelijkheden om ongestructureerde data op te slaan: hstore, JSON en JSONB _{​(Kerstiens, 2016)​.}

Hstore is de eerste manier die Postgres ondersteunde om ongestructureerde op te slaan. Met hstore is het mogelijk om op te slaan volgens het key/value principe. Doordat de value geen array/lijst kan zijn, is hstore niet geschikt. Een factuur bevat bijvoorbeeld factuurregels en deze kunnen dan niet worden opgeslagen.

JSON en JSONB ondersteunen het JSON formaat, waardoor arrays wel mogelijk zijn. Het verschil tussen deze twee is dat JSONB een binaire representatie is van JSON. Dit houdt in dat JSONB de data efficiënter opslaat, terwijl JSON de data als text opslaat. Daarnaast biedt JSONB ook ondersteuning voor indexes, wat voordelen oplevert als je queries wil uitvoeren over de data. Doordat JSONB betere performance biedt, is de JSONB de beste optie. Het enige nadeel van een binaire representatie is dat data anders wordt opgeslagen waardoor de

volgorde zou kunnen veranderen.

7.4.3 Polymorphic association

Om bij te houden welke modellen er allemaal zijn ontstaan door een import, wordt de polymorphic association gebruikt. Met polymorphic association is mogelijk om een relatie te leggen van één model naar verschillende andere modellen.

Als tegenhanger van polymorphic association wordt STI (single table inheritance) of abstract classes gezien _{​(“STI, Polymorphism and Abstract Classes”, 2019)​. Het nadeel van de beide} opties is dat de modellen dan moeten erven van een bepaalde class, waardoor er

aanpassingen komen in de huidige modellen/database van Moneybird. Met polymorphic association wordt er een nieuwe tabel/model gemaakt waar deze data in staat. Dit maakt het ook makkelijk om te schalen naar nieuwe modellen.

Figuur 8: Polymorphic association overzicht.

Het extra model dat nodig is bij polymorphic association is _{​administration_import_data.​ Er zijn} dus altijd twee velden vereist voor het extra model dat nodig. Dit zijn de volgende twee velden

- Bookkeeping_type_{​: type model, bijvoorbeeld contact of verkoopfactuur.} - Bookkeeping_id_{​: id van de rij, dus het id van het contact bijvoorbeeld.}

7.5 Validatie

Om te valideren dat de geüploade bestanden geldig zijn voor een import, wordt de inhoud eerst gevalideerd.

7.5.1 XSD validatie

Het valideren van een auditfile gebeurt middels een XSD. In een XSD staat beschreven welke velden er allemaal zijn toegestaan en of deze velden verplicht of optioneel zijn.

Voor het valideren wordt de XSD van de belastingdienst gebruikt. In theorie zouden alle auditfiles hieraan moeten voldoen, alleen blijkt dit in de praktijk niet zo te zijn. Dit komt door spelfouten, hoofdlettergevoeligheid en het ontbreken van verplichte velden. Daarnaast staat de standaard XSD situaties toe die niet mogen in Moneybird. Om deze problemen niet naar de klanten door te schuiven zijn er twee oplossingen geïmplementeerd.

Aanpassingen

Als eerste zijn er aanpassingen gemaakt aan de standaard XSD. Dit om te voorkomen dat de validatie fout gaat op irrelevante zaken. Het kan namelijk voorkomen dat bedrijven zich niet houden aan bepaalde standaarden, zoals de volgorde van de data of het niet invullen van verplichte velden. Door de standaard XSD aan te passen, zal de validatie niet falen op dit soort onnodige zaken en zal de gebruiker ook geen last ondervinden van dit probleem.

Problemen detecteren en verhelpen

Sommige zaken zijn niet op te lossen door de XSD aan te passen. Hierbij gaat het om

spelfouten en situaties waarbij softwarepakketten zich niet aan de standaard houden voor een bepaalde waarde. Om ook deze problemen niet naar de klant door te spelen, is er een validator geschreven die de bekende problemen van de auditfiles van de top 10 softwarepakketten detecteert en verhelpt. Hierdoor zal de validatie niet fout gaan op deze onnodige zaken. Daarnaast is het heel makkelijk om nieuwe fixes toe te voegen of te verwijderen, door

simpelweg een nieuwe methode toe te voegen of een bestaande methode te verwijderen. Dit heeft als voordeel dat de code eenvoudiger kan worden, omdat inconsistenties van de bestanden vroegtijdig kunnen worden opgelost.

Foutafhandeling

Tijdens de validatie fase kunnen er verschillende fouten optreden. Om de gebruiker duidelijk te maken wat er fout gaat worden er verschillende fouten afgevangen.

In de praktijk is gebleken dat boekhoudpakketten creatief zijn in het bepalen van het

bestandstype. Het kan voorkomen dat auditfiles worden geëxporteerd als .txt of .pdf bestanden. Hierdoor is het niet mogelijk om aan de frontend te valideren of het een XML bestand is. Er is daarom een validator geschreven die het bestand controleert. Deze code wordt als eerste uitgevoerd bij het uitvoeren van de background job. Als de validator een fout constateert wordt de job beëindigd en krijgt de gebruiker het scherm zoals in figuur 11 te zien.

Bij het valideren kunnen de volgende fouten optreden

- Te oude versie_{​: Als de gebruiker een XAF upload van versie lager dan 3.1 komt er een} foutmelding. Hierin staat dat alleen versies hoger dan 3.1 worden ondersteunt omdat lagere versies te weinig gegevens bevatten.

- Er is geen XAF geupload_{​: Als een gebruiker iets anders dan een XAF probeert te} uploaden krijgt hij/zij een foutmelding waarin wordt vermeld dat Moneybird alleen XAF bestanden kan verwerken.

- Onbekende fout_{​: Het kan voorkomen dat er de code crasht op een willekeurig moment.} Daarom worden alle exceptions afgevangen en krijgt de gebruiker een foutmelding te zien waarin staat hij/zij contact moet opnemen met de supportafdeling van Moneybird.

Figuur 11: Scherm wanneer er een fout optreed bij het uploaden

7.6 Verwerken

In dit hoofdstuk worden de technische keuzes behandeld, die zijn gemaakt bij het ontwerpen en implementeren van de verwerkingsfase. Bij deze fase is het belangrijk dat het verwerken in de juiste volgorde gebeurd. Voor elke factuur is immers een klant, grootboekrekening en vaak een BTW-tarief nodig.

7.6.1 Klanten en leveranciers

Alle klanten en leveranciers die gebruikt worden in een administratie zijn te vinden in de auditfile, in Moneybird is dit het model Contact. Het verwerken van de contacten is een relatief simpele taak doordat de meeste velden rechtstreeks kunnen worden overgenomen.

De grootste uitdaging van dit onderdeel is het splitsen van de volledige naam in de voor- en achternaam. Als eerste wordt er gezocht naar tussenvoegsels, als deze er is wordt voor- achternaam hier gesplitst. In alle andere gevallen wordt er gesplitst na het eerste woord in de volledige naam.

7.6.2 Grootboekrekeningen/categorieën

In de XAF staan alle grootboekrekeningen van een administratie, dit zijn in Moneybird de categorieën. Doordat Moneybird het onderdeel onderdeel categorieën op een andere manier invult dan gebruikelijk in de markt, waren er hier verschillende uitdagingen. Voor de definities van de grootboekrekeningen zijn twee bronnen: het RGS _{​(Referentie Grootboekschema, z.d.)} en administratie-keu _{​(“Grootboekrekeningschema – Administratie Kau”, z.d.)}

Standaardcategorieën

Moneybird biedt out-of-box al veel standaard categorieën. Dit zijn veelgebruikte categorieën van een administratie, zoals omzet of debiteuren. Om te voorkomen dat ze dubbel in de

administratie komen, wordt er eerste de naam van de grootboekrekening vergeleken met de standaardcategorieën. De categorie wordt dan alleen gewijzigd op de grootboekcode.

Ook komt het voor dat bepaalde categorieën worden gegenereerd door Moneybird, zoals het Eigen vermogen of het resultaat van een boekjaar. Doordat ze al bestaan, is het niet nodig om ze over te nemen. Ook de BTW posten zijn grootboekrekeningen, alleen staan deze in

Moneybird onder de BTW tarieven. Deze categorieën worden daarom ook overgeslagen. Bij de facturen worden ze op de goede manier toegevoegd.

Type categorie

Om aan te geven van welk type een grootboekrekening is, is het gebruikelijk om dit te doen met een grootboekcode. Dit is niet verplicht, maar wordt wel gebruikt bij het overgrote deel van de boekhoudingen. Bij Moneybird is het wel mogelijk om een grootboekcode in te vullen, maar is dit ook niet verplicht.

Moneybird kent namelijk eigen gedefinieerd categorietypes, dit zijn de onderdelen die je kunt vinden op de balans of resultatenrekening, zoals vaste activa, omzet, kosten, etc. De

grootboekcodes komen in essentie ook op deze onderdelen, alleen maken ze bij de balans nog een aantal verschillen.

Grootboekcodes zijn altijd vier cijfers lang, voor het bepalen van de categorie, is alleen het eerste getal van belang. Deze geeft aan in welke categorie hij thuishoort. Alle grootboekcodes die starten met 3, zijn dus bijvoorbeeld altijd voorraadrekeningen en die vallen dan altijd onder vlottende activa.

Grootboekcode Moneybird categorie type Definitie

0 Vaste activa

Eigen vermogen Langlopende schulden

Vaste active en passiva

1 Vlottende activa Kortlopende schulden

Vlottende activa en passiva 2 Vlottende activa

Kortlopende schulden

Tussenrekeningen

3 Vlottende activa Voorraadrekeningen

Tabel 12: Overzicht van de Moneybird categorieën voor de balans ten opzichte van de grootboekcodes

Zoals te zien is in de tabel, kunnen meerdere Moneybird categorieën vallen onder één

grootboekcode. Om toch de juiste categorie te kunnen vinden, wordt er gezocht naar typerende woorden voor de grootboekrekening. Als dan nog steeds niet kan worden bepaald wat het type is, wordt de grootboekrekeningen overgeslagen en kan hij misschien later worden toegevoegd als hij ergens in een mutatie/transactie wordt gebruikt. Bij het resultaat van het importeren krijgt de gebruiker dan te zien welke grootboekrekeningen er niet verwerkt zijn, zodat hij/zij dit alsnog nog handmatig zou kunnen doen.

Grootboekcode Moneybird categorie type Definitie

4 Kosten Kostenrekeningen

7 Kosten van de omzet inkopen

8 Omzet omzet

9 Overige inkomsten en uitgaven Financiële baten en lasten

Tabel 13: Overzicht van de Moneybird categorieën voor de resultatenrekening ten opzichte van de grootboekcodes

7.6.3 Verkoopfacturen

In een auditfile zijn alle transacties/mutaties te vinden onder verschillende journalen.

Verkoop(facturen) of debiteuren is een voorbeeld van zo’n journaal. Een journaal bestaat dan uit een lijst met verkoopfacturen en hun balansmutaties. Alle boekhoudkundige informatie is hierin te vinden.

Factuurnummering

Wettelijk gezien is het verplicht om de factuur te voorzien van een factuurnummer. De ondernemer is vrij om te kiezen hoe dit nummer eruit ziet, zolang de factuurnummers elkaar maar opvolgen. In de praktijk viel op dat boekhoudpakketten creatief zijn in het invullen van de factuurnummers. Er worden verschillende velden gebruikt voor het invullen. Hierdoor is het lastig om te zoeken naar het factuurnummer.

Het veld ‘invRef’ wordt standaard als factuurnummer gebruikt. Als deze niet aanwezig moeten er keuzes worden om het factuurnummer te vinden. Er wordt dan in de volgende velden

gezocht naar een factuurnummer: ‘docRef’, ‘recRef’ of ‘nr’. Als de waarde een van deze velden begint met het boekjaar, de letter F of de letter VF wordt het factuurnummer herkent.

Factuurregels

Van elke factuur zijn de balansmutaties beschikbaar. Hierdoor kun je precies herleiden wat de factuurregels zijn en op welke tegenrekening de factuur is geboekt, zodat je kan achterhalen wat de status van de factuur is. Hieronder staat een voorbeeld van een openstaande factuur en daaronder de balansmutatie, zoals die ook te vinden is een auditfile.

Figuur 12: Voorbeeld van een verkoopfactuur

Debet Credit

Debiteuren 847 Eigen vermogen - Fiets A - Fiets B 700 300 400 Te betalen BTW 147 Totaal 847 Totaal 847

Tabel 15: Voorbeeld balans voor een verkoopfactuur

Zoals te zien op de balans beschrijft de credit kant hoe de factuur eruit ziet en laat de debet zien hoe de factuur is betaald. Op basis van de credit kant wordt de inhoud van de factuur verwerkt en op basis van de debetkant wordt de status van de factuur bepaald.

Factuurstatus

De factuurstatus wordt bepaald op basis van de debetkant van de balans. Het kan voorkomen dat de betaling niet in de huidige mutatie is te vinden, maar in een journaal van een

bankrekeningen of kas. Als deze wordt verwerkt wordt de status dus alsnog goed aangepast. In de onderstaande tabel is een overzicht te zien van de verschillende status in Moneybird.

Status Balans mutatie

Openstaand Debiteuren

Betaald Bank of kas (vlottende activa)

Verlopen Debiteuren en de vervaldatum is verstreken

Tabel 16: Factuur statussen van Moneybird voor een verkoopfactuur

BTW berekeningen

Bij het maken van een factuur in Moneybird heb je de optie om te selecteren of de prijzen inclusief of exclusief BTW zijn. Deze optie is er omdat er in sommige gevallen kleine verschillen zijn, doordat er wordt afgrond. In het onderstaande voorbeeld is te zien dat het totaalbedrag van 2697 euro 1 cent verschilt bij een verkeerde berekening.

Figuur 13: Voorbeeld van een factuur inclusief BTW

Figuur 14: Voorbeeld van een factuur exclusief BTW

Doordat het bedrag Inclusief en exclusief BTW altijd in de auditfiles is te vinden is het mogelijk om te bereken op welke manier er gerekend moet worden. Dit gebeurt door de het bedrag exclusief BTW maal de BTW te vergelijken met het bedrag inclusief BTW. Als deze niet hetzelfde is moeten de prijzen inclusief BTW berekend worden.

7.6.4 User interface: Resultaat

In de onderstaande afbeelding is het scherm te zien, wanneer de import succesvol is

uitgevoerd. Om de gebruiker in een feestelijk stemming te brengen komt er zelfs even confetti door het scherm..

Om de gebruiker duidelijk te maken dat de import gelukt is staat er met grote letters: “Je geïmporteerde boekhouding staat nu in Moneybird!”. Daaronder staat een kleine beschrijving waarin staat welke modellen er zijn verwerkt. Dit kunnen dus contacten, categorieën of facturen zijn. Er is voor gekozen om deze omschrijving heel simpel te houden en geen hoeveelheden te laten zien. Omdat gebruikers waarschijnlijk geen weet hebben van hoeveelheden.

In een volgende versie zou het ook wenselijk zijn om door te kunnen linken naar een pagina met de resultaten waarop ook de niet verwerkte gegevens staan.

Figuur 15: Resultaat na succesvolle import

7.7 Huidige staat prototype

Met de huidige staat van het prototype is het mogelijk om facturen, contacten en categorieën in te lezen in Moneybird uit de XAF bestanden van de negen boekhoudpakketten. Het prototype staat nu als private feature in de Moneybird applicatie. Dit betekent dat hij alleen beschikbaar is in de development omgeving. Technisch gezien is het vrij eenvoudig om de feature naar

Moneybird klanten openbaar te stellen. Er zijn alleen meer zaken van belang om een eventuele live gang te kunnen realiseren.

Zo zal het prototype eerst goed getest moeten worden op bugs of tekortkomingen. Het prototype is momenteel getest op twee manieren. Door specs te schrijven en door de XAF bestanden te uploaden die zijn gedownload vanuit de proef accounts die zijn aangemaakt bij de negen softwarepakketten. Doordat er goed getest is met deze XAF bestanden en de specs alle situaties beschrijven die in XAF bestanden kunnen voorkomen, ben ik er vrij zeker van dat de gegevens goed worden verwerkt naar Moneybird.

Er zijn nog geen testen uitgevoerd met gebruikers. Dit is wel een vereiste om eventueel live te kunnen gaan. Het is momenteel niet bekend hoe gemakkelijk en duidelijk de tool daadwerkelijk is in de praktijk. De volgende stap zou daarom moeten zijn om deze versie te gaan testen met gebruikers zodat inzichtelijk is wat er eventueel nog moet gebeuren.

8 Conclusie

In dit onderzoek is er gezocht naar een antwoord op de vraag: Hoe kan een nieuwe klant zo makkelijk en snel mogelijk zijn oude administratie importeren naar Moneybird? Hiervoor is voornamelijk deskresearch gedaan. De bronnen bestaan uit websites, Moneybird tools en onderzoeken die zijn gepubliceerd op het internet.

Om de onderzoeksvraag te beantwoorden is het project begonnen met een onderzoek naar de markt waarin Moneybird zich bevindt en om welke data het precies gaat. Uit het onderzoek is onder andere een top 10 boekhoudpakketten gekomen waarvan klanten overstappen naar Moneybird. Bij deze pakketten zijn proefaccounts gemaakt en is er data geëxporteerd. Deze data is gebruikt voor het bouwen van het prototype.

Uit het onderzoek is voortgekomen dat de XML auditfile financieel (XAF) de beste oplossing biedt op het probleem. Doordat het formaat een standaard volgt heeft hoeft er maar één

implementatie geschreven worden. Wel heeft de XAF het probleem dat er op sommige plekken te veel vrijheid is, waardoor er alsnog verschillen ontstaan tussen de pakketten. De

uitzonderingen uitzoeken en implementeren kon daardoor tijdrovend zijn. Ook het feit dat Moneybird bepaalde zaken, zoals de categorieën anders aanpakt dan de rest van de markt leverde interessante uitdagingen op.

Het prototype voldoet aan de vooraf opgesteld must requirements. Er kunnen facturen,

contacten en categorieën van de top 10 pakketten worden geïmporteerd. Doordat de XAF een standaard volgt is het eenvoudig om nieuwe pakketten ook te ondersteunen, omdat er alleen eventuele uitzonderingen moeten worden geïmplementeerd.

Het prototype is getest door specs te schrijven en door XAF bestanden te uploaden die zijn gedownload van de proef accounts van de negen pakketten. Hierdoor is het prototype in staat om de gegevens van een XAF goed te verwerken in Moneybird. Op dit moment ontbreken nog de gebruikerstesten. Gebruikerstesten zijn nog nodig om feedback te geven op de schermen en de flow die de gebruiker nog moet doorlopen.

9 Aanbevelingen

Met de huidige staat van het prototype zou de klant al goed op weg kunnen worden geholpen, alleen zijn er nog een aantal verbeterpunten die het leven van de klant nog makkelijker zouden kunnen maken. Dit hoofdstuk beschrijft deze verbeterpunten voor het prototype.

9.1 Meer gegevens uitlezen

Op het moment is het mogelijk om facturen, categorieën/grootboekrekeningen en klanten en leveranciers te importeren. In een XAF is nog meer informatie te vinden die interessant kan zijn om in te lezen, zoals banktransacties of inkoopfacturen.

9.2 Betere weergave resultaten

Momenteel ziet de gebruiker bij een succesvolle import alleen de modellen die zijn geïmporteerd. Door de gebruiker ook te laten zien hoeveel er is geïmporteerd en welke gegevens niet krijgt hij/zij een beter beeld. Ook kan de gebruiker dan handmatig de niet verwerkte gegevens invullen.

9.3 PDF facturen als bijlage

Doordat de XAF alleen de data bevat ontbreken de originele documenten. Dit kan worden opgelost door de gebruiker alle facturen te laten exporteren en deze vervolgens ook uploaden naast een XAF. In de XAF wordt bij het onderdeel transacties op verschillende manier verwezen naar de factuur. Doordat het document vaak als bestandsnaam het factuurnummer heeft is, dit vrij eenvoudig te koppelen. Ook heeft moneybird al functionaliteit beschikbaar om data uit een PDF te lezen en zo het factuurnummer te vinden.

9.4 Wizard

Om het opzetten van een nieuwe administratie in Moneybird compleet te maken zou een wizard nog veel mogelijkheden kunnen bieden. Een XAF biedt veel gegevens, alleen het kan heel handig zijn als de gebruiker daar een aanvulling op doet. Hieronder een aantal voorstellen om toe te voegen in een wizard:

- Vervaltermijn verkoopfactuur: _{​In de XAF staat niet beschreven wanneer een} verkoopfactuur is verlopen. Door een klant te laten invullen welk vervaltermijn hij/zij hanteert voor de verkoopfacturen, staan deze datums allemaal goed.

- Bankkoppeling_{​: doordat banken als categorieën in de XAF staan, is het mogelijk om de} gebruiker te vragen zijn bankgegevens in te vullen. Als er dan transacties aanwezig zijn kunnen deze ook worden meegenomen. Daarnaast heeft de klant dan ook gelijk zijn bankgegevens ingesteld.