[RoR]Database opzet boekhouding

[djluc]

Ik ben bezig met een project waarbij ik zelf een boekhouding wil schrijven. Dit moet een goedgekeurde boekhouding zijn voor een eenmanszaak voor de Nederlandse belastingdienst geschikt.

Nu bestaan er allerlei regels voor boekhouding en tevens een aantal goede gewoonten zoals double entry booking. Ik wil een systeem maken waarbij dit efficiënt gebeurt zonder al te veel tussenkomst van de gebruiker.

Dit kan ik gaan doen geheel zelf maar er zijn ook reeds database modellen beschikbaar. Ik kijk o.a. naar: http://ept.github.com/invoicing/ en het project: http://ept.github.com/oaccounts/ De laatste is erg interessant, ze willen een standaard model voor boekhoudingen gaan opzetten omdat dit door iedereen verschillend gedaan wordt.

Mijn vraag aan jullie: Is er wellicht een standaard die de ontwikkelaars van oaccounts over het hoofd hebben gezien en die ik kan implementeren zodat ik een goede basis heb voor mijn administratie? We praten dus over balansen, verlies en winstrekeningen als output uiteindelijk. Indien niet wil ik in dit topic mijn opzet gaan ontwikkelen met jullie feedback.

[SinergyX]

Mijn vraag aan jullie: Is er wellicht een standaard die de ontwikkelaars van oaccounts over het hoofd hebben gezien en die ik kan implementeren zodat ik een goede basis heb voor mijn administratie?

Dit snap ik niet helemaal, jij wil een standaard implementeren in jou administratie die juist door de ontwikkelaars over het hoofd is gezien?

[djluc]

Ne, ik hoop dat er een standaard is, wellicht een gebruikelijke standaard in bijvoorbeeld de .net wereld of een ander platform wat ik helemaal niet ken bijvoorbeeld.

Daarom post ik het hier, omdat hier veel ervaren developers zitten die op vele platforms gewerkt hebben. Ik zie iedereen z'n eigen implementatie maken en dat stoort me. De links die ik geef zijn specifiek Ruby on Rails developers en die hebben misschien dus niet een compleet beeld gehad van de bestaande standaarden.

Ik heb overigens ook contact met hen gezocht maar nog geen reactie.

[Boss]

Boekhoudstandaarden hebben helemaal niets met programmeertalen,datamodellen of ontwikkelomgevingen te maken. Er zijn regels voor boekhouding, die verschillen per land. Vervolgens kan iedere programmeur dat in zijn eigen favoriete omgeving implementeren.

Wat denk je te vinden onder bijvoorbeeld een .net boekhoudstandaard?

[djluc]

Het gaat met puur om een goed datamodel. Dat is per platform (.net/ruby/php/etc) niet veel verschillend lijkt mij, hoogstens kolombenamings-standaarden.

Ik begrijp ook dat er standaard regels zijn per land etc. Dat is allemaal duidelijk maar het gaat mij dus om een slimme opzet van het datamodel. Niet om implementatieverschillen e.d. want dat moet ik inderdaad zelf doen.

[Boss]

een datamodel voor boekhouden is in de basis kinderlijk eenvoudig. Sla er een willekeurig HAVO/VWO economieboek maar eens op na. Alles gaat in het grootboek. De verschillen per land zitten vooral in de regels (hoe mag je afschrijven etc) en vereisen doorgaans geen apart datamodel.

[djluc]

Tjsa, kinderlijk eenvoudig, als je kijkt naar financiele pakketten zie je tig tabellen met allerlei gerelateerde zaken. De basis is uiteraard duidelijk, maar wellicht zijn er wel belangrijke punten waar we op moeten letter, bijvoorbeeld door het behouden van de historie.

[bat266]

Even een vraagje, wil je dit doen als oefening of werkelijk just another accounting application gaan maken?

edit

Ik zie dat mijn opmerking misschien wat negatief kan overkomen. Zo is het in ieder geval niet bedoelt. Je moet je alleen realiseren dat als je applicatie gaat maken dat dat heel veel werk is. Meer dan je nu bedenkt. Ook komt er na een eerste versie zeker veel onderhoud bij na het wijzigen van wetten etc. Dus als je dan klanten hebt zul je deze wijzigingen ook moeten doorvoeren.

Verder zijn er al veel goedkope alternatieven. Ook kun je al online boekhouden met verschillende tools.

Nogmaals ik wil je niet ontmoedigen maar denk goed na of je deze stap wilt zetten. Als oefening daarenregen lijkt het me wel een nuttige zet.

(p.s. ik heb zelf ook al meerdere keren een vergelijkbare fout gemaakt. tools die bestaan doen x of y niet optimaal, kan ik wel zelf maken. Zonder te bedenken dat de basis die wel goed werkt heel veel werk is.)

[ Voor 80% gewijzigd door bat266 op 25-01-2010 09:38 ]

[DiedX]

Ik denk dat ik je business-model zie. Ik vraag me alleen af of je het moet willen. Als kleine ondernemer ga ik liever naar Reeleezee of iets degelijks...

Niet dat ik je bubble wil bursten of iets degelijks, maar ik ben bang dat je veel werk gaat steken in iets...

[Jrz]

Ik zou zelf best releezee willen gebruiken maar
1) releezee werkt alleen in IE
2) releezee is duur

Alternatieven zijn er wel, maar werkelijk waar ELKE heeft serieuze tekortkomingen

[djluc]

bat266 schreef op maandag 25 januari 2010 @ 09:21:
Even een vraagje, wil je dit doen als oefening of werkelijk just another accounting application gaan maken?

edit

Ik zie dat mijn opmerking misschien wat negatief kan overkomen. Zo is het in ieder geval niet bedoelt. Je moet je alleen realiseren dat als je applicatie gaat maken dat dat heel veel werk is. Meer dan je nu bedenkt. Ook komt er na een eerste versie zeker veel onderhoud bij na het wijzigen van wetten etc. Dus als je dan klanten hebt zul je deze wijzigingen ook moeten doorvoeren.

Dank voor je inhoudelijke feedback! Dat zijn inderdaad goede punten. Is wijzigingen van de regelgeving echt van toepassing? Het gaat me dus niet om het berekenen van belastingaangiftes e.d. Of bedoel je wijzigingen qua afschrijving bijvoorbeeld?

Verder zijn er al veel goedkope alternatieven. Ook kun je al online boekhouden met verschillende tools.

Nogmaals ik wil je niet ontmoedigen maar denk goed na of je deze stap wilt zetten. Als oefening daarenregen lijkt het me wel een nuttige zet.

(p.s. ik heb zelf ook al meerdere keren een vergelijkbare fout gemaakt. tools die bestaan doen x of y niet optimaal, kan ik wel zelf maken. Zonder te bedenken dat de basis die wel goed werkt heel veel werk is.)

Ik ben me daar inderdaad bewust van en zie het als zakelijke investering. Een tool die wij willen kost minimaal 5000 euro excl. implementatie en jaarlijks onderhoud van minimaal 1000 euro. We hebben dan nog niet de tool die we willen.

Wat is het complete wat we willen maken: Een compleet systeem waarbij we onze bedrijfsprocessen vastleggen. We maken websites. Dus:
Bij de start van een project voeren we werkbonnen in en maken we projectonderdelen aan met deadlines etc. Vervolgens maken we een begroting:
Layout: 500 euro
Programmeren onderdeel x: 200 euro
Programmeren layout: 300 euro
Totaal: 1000 kosten.

Hier hang ik factuurregels aan. De facturen die we invoeren moeten dus meteen in de boekhouding verwerkt worden.

[djluc]

DiedX schreef op maandag 25 januari 2010 @ 09:30:
Ik denk dat ik je business-model zie. Ik vraag me alleen af of je het moet willen. Als kleine ondernemer ga ik liever naar Reeleezee of iets degelijks...

Niet dat ik je bubble wil bursten of iets degelijks, maar ik ben bang dat je veel werk gaat steken in iets...

Het is niet de bedoeling in eerste instantie om dit te gaan verkopen. Het is een interne tool. Mocht dit goed gaan werken en een jaar lang door ontwikkeld zijn dan kan het wellicht een commercieel product worden maar dat is niet de primaire insteek.

Het verschil tussen een boekhoudpakket en wat wij maken is dat we onze complete oplossing op basis van een project. Wij werken geheel werkbonnen en projectgebaseerd.

[Knutselsmurf]

Een boekhoudpakket schrijven dat aan alle regels voldoet, kost veel, heel veel tijd. Als je dat zelf gaat proberen te schrijven, ben je een veelvoud aan geld kwijt dan wanneer je een pakket koopt.

Beter schrijf je een applicatie die aansluit bij de bedrijfsprocessen en zorg je voor goede export-mogelijkheden naar het bestaande boekhoudpakket.

[djluc]

Waarom is het dan zo complex? Ik zie 2 totaal verschillende meningen over dit plan langskomen. De eerste is: Dat is simpel, wat grootboeken, balans gelijkstellen enzovoorts. De 2de groep ziet allerlei problemen, complexiteit, wetgeving etc.

Als ik geen boekhouding integreer op de een of andere manier moet ik ook nog elke maand een boekhouder betalen om wat wij doen op grootboeken te gaan invoeren terwijl wij dit ook weten.

[Boss]

Dit soort applicaties maken wij regelmatig voor diverse klanten. Dat doen we heel eenvoudig: wij leggen het hele proces vast en maken daar de software omheen. Als laatste stap in het proces (nadat de factuur is gemaakt) komt er een export uit voor het administratiepakket (incl debiteuren etc). Het is echt zinloos om op een budget van 5k zelf een boekhoudpakket te maken. Je zit met afschijvingen, memoriaalboekingen, bankafschriften, verschillende rekeningen, kruisposten etc. Daar begin ik gewoon liever niet aan. Tot nu toe is dit altijd een goede keuze gebleken.

[Creepy]

Dat is ook precies wat ik hier lijk te zien. Je wilt een systeem maken voor het bijhouden van (begrotingen van) projecten. Daar rollen blijkbaar facturen en/of factuurregels uit en die schiet je dan een boekhoud pakket binnen. Je kan dat inderdaad zelf maken maar er zijn boekhoudpakketten waarin je dat direct kan inschieten. En voor wat je uitgeeft aan bijv. reeleezee kan je zelf niet gaan zitten ontwikkelen, dat kost je dan uiteindelijk alleen maar meer.

[djluc]

Dank voor jullie feedback, misschien gaan we inderdaad iets te ver misschien ook niet, daarom ben ik de mogelijkheden aan het uitzoeken. Een optie is inderdaad om tot niveau facturen te gaan en niet verder. Sowieso wil ik echter niet dubbel inboeken dus dan zou ik een goede import moeten kunnen realiseren.

Een totaaloplossing, en daarbij is het budget echt geen 5k, we hebben het eerder over 10-15k, is uiteraard een mooiere oplossing. Dus als dat niet te ingewikkeld blijkt te zijn hebben we super oplossing.

[Boss]

Je kan ook altijd nog proberen een open source boekhoudprogramma (zoiets als osFinancials of een webbased pakket) te forken en daar de uitbreidingen op maken die je zelf nodig hebt voor je projectadministratie. Nadeel is dat je je moet inwerken in een bestaand pakket wat ook tijd kost.

[djluc]

Boss schreef op maandag 25 januari 2010 @ 19:10:
Je kan ook altijd nog proberen een open source boekhoudprogramma (zoiets als osFinancials of een webbased pakket) te forken en daar de uitbreidingen op maken die je zelf nodig hebt voor je projectadministratie. Nadeel is dat je je moet inwerken in een bestaand pakket wat ook tijd kost.

Dat is een stap die we dus absoluut niet willen maken. Elk beetje boekhoudpakket heeft wel een projectadministratie module maar "denkt" vanuit boekhouding. Daarom werken die administraties ook niet prettig en adviseert menig administratiekantoor om het "maar gewoon" in Excel te doen. WE hebben daarvoor veel pakketten vergeleken en adviezen gehoord.

[Verwijderd]

djluc schreef op maandag 25 januari 2010 @ 13:44:
Waarom is het dan zo complex? Ik zie 2 totaal verschillende meningen over dit plan langskomen. De eerste is: Dat is simpel, wat grootboeken, balans gelijkstellen enzovoorts. De 2de groep ziet allerlei problemen, complexiteit, wetgeving etc.

Als ik geen boekhouding integreer op de een of andere manier moet ik ook nog elke maand een boekhouder betalen om wat wij doen op grootboeken te gaan invoeren terwijl wij dit ook weten.

Ik hoor ook bij die 2e groep. Als je het maximale budget van 15K terugrekent naar uren dan heb je bij 50 euro per uur maar 300 uur = 7,5 weken de tijd om een compleet boekhoudpakket te maken. Dat is onmogelijk als je kijkt naar de functionaliteit en complexiteit van zelf het meest eenvoudige pakket.

En ja, wijzigingen in de regels zijn wel degelijk belangrijk. Belastingtarieven kunnen wijzigen, geeigende kostenposten, etc en dat gebeurt in de praktijk ook regelmatig. Van Afas kreeg ik om de zoveel tijd een update met de nieuwe boekhoudregels erin toen ik dat beheerde. Nu is Afas wel wat complexer dan wat jij voor ogen hebt waarschijnlijk, maar er zijn toch regels die kunnen veranderen die op jouw systeem van toepassing kunnen zijn, neem bijvoorbeeld de BTW.

Ik zou me richten op een pakket dat het dichtst in de buurt komt van je wensen en dat kopen. Ik vind het (laten) aanpassen van een bestaand open source systeem trouwens ook het onderzoeken waard, maar als al besloten is dat dat niet doorgaat dan zou ik het bij een bestaand pakket houden.

[ Voor 5% gewijzigd door Verwijderd op 03-02-2010 17:35 ]

[djluc]

Bedankt voor je feedback!

Als je de kostenkant inderdaad zo berekent klopt wat je zegt. Aan de andere kant is het mogelijk om in 300 uur aardig wat te ontwikkelen. Wat we inmiddels hebben is urenregistratie e.d. We hebben inmiddels een partij gevonden die met ons samen wil werken om uit te zoeken of we dit product op de markt kunnen zetten bij andere projectgebaseerde bedrijven. We hebben nu dus kennis in huis op het gebied van boekhouding, fiscaliteiten etc.

We zijn op dit moment aan het kijken naar een mogelijkheid om een basis journaalposten e.d. op te zetten als proof of concept om te zien welke issues we vinden. Dit omdat we echt 2 reacties krijgen zoals ook hierboven vermeld: Niet doen! of Is redelijk eenvoudig te doen, gewoon doen! Op basis van die reacties hebben wij nog geen keuze maken wat ons dwingt om het verder uit te zoeken. Dat doen we dus door middel van een proof of concept.


Nog een interessant artikel met betrekking tot belangrijke punten in dit soort belasting en administratieve software: http://www.babantwerp.be/BhsoftwNL.pdf

[bat266]

Goed om in ieder geval meer onderzoek te doen i.p.v. gewoon starten. Al blijft een budget van 15K heel beperkt om het op te zetten. Zeker als het je lukt om in zeg 7,5 week het voor elkaar te krijgen loop je nog steeds de risico's in de onderhoudsfase, vergeet deze kosten niet mee te nemen in de beslissing na de POC.

[Serpie]

Indien je zo'n product op de markt wil zetten krijg je ineens te maken met een hoop meer wensen en eisen die je wellicht voor een eigen product niet nuttig vindt.

Ik noem er maar een paar die me zo te binnen schieten:

• Btw-aangifte (al dan niet elektronisch via BAPI of straks xbrl
• Facturen afdruken
• Elektronisch factureren
• Rapportage (Kolommenbalans, periodebalans, boekingsverslagen, mutatiekaarten)

Daarbij nog boekhoudregels die wellicht ook niet op het eigen bedrijf van toepassing zijn?

• Btw-verlegd
• Marge-regeling
• Export/import

Met 300 uur kom je voor jezelf wellicht een heel eind, voordat je een product hebt wat je standaard op de markt kan zetten en wat door meer mensen gebruikt kan worden ben je heel wat uurtjes verder denk ik zo.