[MYSQL] Boekhouding tabellen, welke aanpak ?

[MichielioZ]

Ik begon met een tabel 'facturen' en daarnaast een tabel met de regels van de facturen (om ze te kunnen genereren met FPDF).
Als een klant een betaling heeft uitgevoerd komt er in de tabel 'betalingen' een regel die gekoppeld is aan de factuur.
Nu is het zo dat er naast de verkoop ook inkoop ingevoerd moet kunnen worden om hiermee de basis boekhouding te kunnen doen.
Mijn vraag is nu, welke van de 2 modellen is beter :
1) Een tabel 'inkoop' erbij maken
2) Een tabel 'boekhouding' maken, waarin een (enum)veld komt dat bepaalt of het om inkoop danwel verkoop gaat. Hierin komen dan wel 2-3 kolommen die specifiek voor inkoop zijn, maar default op NULL staan.

Mijn persoonlijke voorkeur gaat uit naar 2) omdat veel data hetzelfde is in de tabellen, echter zijn die NULL velden me dan weer een doorn in het oog...
Is er een duidelijke winnaar voor jullie (esthetisch, danwel op 'performance' vlak) ?

[StephanL]

Ik zelf, zeg 1, maar ligt ook aan welke structuur de beide tabellen hebben.

Als je namelijk beide scheid van elkaar, heb je ook de records tussen inkoop en verkoop gescheiden van elkaar. Dit maakt voor jou niet misschien uit, maar om het allemaal op te zoeken voor de database wel.Daarbij is het normaal gespoken zo, dat je probeert om, in dit geval, inkoop en verkoop zo veel mogelijk uit elkaar houden, dus niet in 1 tabel.

Dit valt onder het normaliseren van de database(dat ik dat ooit zal zeggen )

[Alain]

Ik zou geen van beiden kiezen. Een tabel beschrijft een 'ding' en niet een 'proces'. Zo zou je een inkooporder (ding) kunnen versturen die afwijkt van de orderbevestiging (ding) en dus de inkoopfactuur (ding). Dat zijn allemaal onderdelen van het proces inkoop.

Zo is boekhouding ook een proces dat afhankelijk is 'dingen' en geen 'ding' op zich is.

Als ik een tip mag geven zou ik eerst eens naar het algemene plaatje kijken en daar alle 'dingen' (of entiteiten) uit halen. Als je begint met een tabel factuur en eindigt met een tabel boekhouding, dan ben je mijns inziens op de verkeerde weg.

[MichielioZ]

AlainS schreef op woensdag 02 juli 2008 @ 10:35:
Ik zou geen van beiden kiezen. Een tabel beschrijft een 'ding' en niet een 'proces'. Zo zou je een inkooporder (ding) kunnen versturen die afwijkt van de orderbevestiging (ding) en dus de inkoopfactuur (ding). Dat zijn allemaal onderdelen van het proces inkoop.

Zo is boekhouding ook een proces dat afhankelijk is 'dingen' en geen 'ding' op zich is.

Als ik een tip mag geven zou ik eerst eens naar het algemene plaatje kijken en daar alle 'dingen' (of entiteiten) uit halen. Als je begint met een tabel factuur en eindigt met een tabel boekhouding, dan ben je mijns inziens op de verkeerde weg.

Ok, ik begrijp je standpunt, maar ben het in dit geval niet 100% met je eens
Bij inkoop horen bijvoorbeeld ook (en in dit geval het meeste) benzinebonnetjes...
Er is in dit geval geen inkooporder of orderbevestiging nodig, een factuur inboeken volstaat.
Sowieso wil ik niet een geheel proces omschrijven met die tabel, maar echt alleen de inkoopfacturen.

Verder is het idd goed om vanuit het totaalplaatje te werken, maar in de praktijk "ontstaat" dat plaatje geleidelijk. In mijn geval : de klant wilde een systeem om te kunnen plannen en factureren, niets meer, niets minder. Pas daarna is de vraag gekomen om inkoop erbij te maken.
Bedankt iig voor je input, vooralsnog denk ik dat ik het bij 2 tabellen houd (kan ze altijd nog makkelijk samenvoegen, mocht ik van gedachte veranderen)

[Creepy]

Je beschrijving lijkt me prima, je hebt inkoop en verkoop facturen. Maar maak daar dan niet 1 tabel van met een totaal nietszeggende naam (boekhouding). Grote kans dat je per inkoop of verkoop factuur een aantal verschillende zaken wilt vastleggen. Om nu makkelijker uit te breiden is het handiger om een extra tabel erbij te maken voor je inkoop facturen, scheelt je weer alle andere logica voor het ophalen en bewerken van verkoop facturen aanpassen.

Het "totaal" plaatje past altijd aan. Een klant komt altijd met andere of extra wensen, maar dat snappen de meeste devvers hier denk ik wel Maar dat maakt het niet OK om normalisatie regels volledig overboord te gooien en niets zeggende tabelnamen te gaan gebruiken.

[bigbeng]

De eerste vraag die bij mij opkomt is: wil je dit echt zelf gaan uitdenken en programmeren? Er zijn al diverse standaardpakketten op de markt die zeer betaalbaar zijn. Maatwerksystemen van deze soort hebben de neiging om steeds ingewikkelder te worden en daarmee steeds moeilijker te onderhouden. Nu kun je het misschien nog met een weekje of twee aan programmeerwerk af, maar elke volgende wijziging gaat je steeds meer tijd kosten.

Kun je niet beter een pakket als Exact Compact of Unit 4 Multivers aanschaffen, waar alles wat jij nu doet al inzit? En daar dan eventueel maatwerk op maken als er zaken ontbreken? Scheelt jou een boel nadenkwerk over boekhouden, facturering en inkoop. En ik denk dat het uiteindelijk ook geld scheelt.

[? ?]

..

[ Voor 108% gewijzigd door ? ? op 25-01-2013 09:51 ]

[MichielioZ]

bigbeng schreef op woensdag 02 juli 2008 @ 11:51:
De eerste vraag die bij mij opkomt is: wil je dit echt zelf gaan uitdenken en programmeren? Er zijn al diverse standaardpakketten op de markt die zeer betaalbaar zijn. Maatwerksystemen van deze soort hebben de neiging om steeds ingewikkelder te worden en daarmee steeds moeilijker te onderhouden. Nu kun je het misschien nog met een weekje of twee aan programmeerwerk af, maar elke volgende wijziging gaat je steeds meer tijd kosten.

Kun je niet beter een pakket als Exact Compact of Unit 4 Multivers aanschaffen, waar alles wat jij nu doet al inzit? En daar dan eventueel maatwerk op maken als er zaken ontbreken? Scheelt jou een boel nadenkwerk over boekhouden, facturering en inkoop. En ik denk dat het uiteindelijk ook geld scheelt.

Probleem is dat de boekhouding al zelf (door iemand in 't bedrijf) werd gedaan en alle data verspreid is over verschillende excel files. Er moet dus een hoop oude data in (gewoon door CSV vanuit excel en uitlezen met PHP). Meeste staat er inmiddels al in.
Op zich is een eenvoudige boekhouding goed zelf te doen, heb het zelf nog iets anders dan era.zer aangeeft.
Bedrijven => id, adresgegevens, facturatiegegevens (op dit moment 1 bedrijf, maar je weet maar nooit)
Klanten => id, adresgegevens, facturatiegegevens
Leveranciers => id, adresgegevens, facturatiegegevens
Inkoop => id,bedrijfsid,leveranciersid,factuurgegevens,excl,btw6,btw19,incl
Verkoop=>id,bedrijfsid,klantid,factuurgegevens,excl,btw6,btw19,incl
Betalingen=>verkoopid,inkoopid,datum,bedrag,betaalrekening,ontvangstrekening

Hierbij is alles met "gegevens" erachter natuurlijk wat uitgebreider dan 1 kolom.
De basisgegevens komen mijns inziens zo goed in de database... of zie ik iets over het hoofd ?

[? ?]

..

[ Voor 107% gewijzigd door ? ? op 25-01-2013 09:51 ]

[Creepy]

Zeker niet omdat het hoge BTW tarief wel eens 20% zou kunnen gaan worden..... je zou niet de eerste zijn die z'n halve app. moet omgooien omdat er een BTW tarief wordt aangepast..

[MichielioZ]

era.zer schreef op woensdag 02 juli 2008 @ 13:08:
In mijn voorbeeld is het iets breder en kun je achterhalen op welke rekening iets geboekt werd (het is een boekhouding). De afzonderlijke regels voor een inkoop/verkoop zijn bv. van belang. De uitsplitsing die jij maakt naar btw6/19 zit bij mij gelinkt aan het type rekeningnr dat gebruikt wordt.
Ik kan ook al m'n autokosten of bureelkosten of advertentiekosten afzonderlijk zien enz. Maar als dat niet van belang is hoeft dat niet denk ik, alhoewel ik btw6/19 velden niet zo "mooi" vind.

Sorry, was ook niet 100% volledig met mijn post...
Inkoop heeft altijd een kostenplaats en een omschrijving, waarbij de kostenplaatsen gedefinieerd worden als "hoofdgroep: subcategorie" (zijn defaults voor aangemaakt), hierdoor kan ik dus ook filtreren welke bedragen bij welke kostenplaatsen horen.
De btw6 en btw19 velden heten eigenlijk 'btw1' en btw2' omdat bijvoorbeeld btw19 binnenkort kan veranderen in percentage.
Verder leek mij het idee van de rekeningen genoeg data te bevatten (elk bedrijf,leverancier,klant heeft een veld bankrekening en bij betaling zijn er velden omdat het soms iets anders loopt dan "standaard"), of ben ik hiermee onvolledig ?

[beany]

Sterker nog, ik heb een aparte tabel met BTW percentages met een type en een startdatum. Op deze manier kan ik oneindig(maximaal aantal rows in een tabel is de beperking) aantal BTW percentages hebben, die op elk willekeurig moment mogen wijzigen. Ook in de history duiken en zaken na willen rekenen gaat dan nog perfect.

[MichielioZ]

beany schreef op woensdag 02 juli 2008 @ 13:20:
Sterker nog, ik heb een aparte tabel met BTW percentages met een type en een startdatum. Op deze manier kan ik oneindig(maximaal aantal rows in een tabel is de beperking) aantal BTW percentages hebben, die op elk willekeurig moment mogen wijzigen. Ook in de history duiken en zaken na willen rekenen gaat dan nog perfect.

Persoonlijk zet ik dit soort uitzonderingen liever in PHP zelf, maar kan idd ook met een tabel...
Ben zelf van mening dat een database bedoelt is om, in verhouding grote hoeveelheden, data op te slaan... maar dat is waarschijnlijk puur persoonlijk

[beany]

MichielioZ schreef op woensdag 02 juli 2008 @ 13:42:
[...]

Persoonlijk zet ik dit soort uitzonderingen liever in PHP zelf, maar kan idd ook met een tabel...
Ben zelf van mening dat een database bedoelt is om, in verhouding grote hoeveelheden, data op te slaan... maar dat is waarschijnlijk puur persoonlijk

BTW percentages, en de type BTW(hoog, laag, 0) is data. En data hoort wat mij betreft in een database. Op deze manier kan je dan factuurregels ook koppelen, de integriteit is meer zeker.

Ik hecht er nogal waarde aan om data in kolommen niet afhankelijk te maken van een data in code.

[mocean]

Als uitbreiding zou ik ook aanbevelen om per bank-rekening je afschriften in te boeken. En dit dan te koppelen aan je facturen. Op 1 factuur kunnen namelijk meerdere + en - betalingen gebeuren (als er eens wat verkeerd wordt overgemaakt), verspreid over meerdere afschriften.

Verder is het een goede controle, dat al je boekingen op je afschrift, moeten kloppen met het begin- en eindsaldo op het afschrift. Zo voorkom je ook fouten.

[Creepy]

MichielioZ schreef op woensdag 02 juli 2008 @ 13:42:
[...]

Persoonlijk zet ik dit soort uitzonderingen liever in PHP zelf, maar kan idd ook met een tabel...
Ben zelf van mening dat een database bedoelt is om, in verhouding grote hoeveelheden, data op te slaan... maar dat is waarschijnlijk puur persoonlijk

Hmmja...dus bij elke BTW wijzigingen moet jij je code gaan updaten. Maar als het in de database staat kan de klant dat met een klein config schermpje zelf Straks komen er ineens drie BTW tarieven.. wat dan? Als het dan in ene tabel staat is het geen probleem of je nu 1 of 100 BTW tarieven hebt Onderhoudstechnisch een stuk makkelijker. Tenzij je graag wilt blijven factureren voor de klant.....

Anyway, btw1, btw2... dat zijn herhaaldelijke zaken. Ondanks dat het er maar twee zijn kan je die toch echt beter in een aparte tabel zijn, je zal straks maar ineens btw3 moeten toevoegen... als je in die aparte tabel dan ook nog een start en stop datum opneemt kan je van te voren al een nieuw BTW tarief invoeren, dat scheelt iemand weer om op 12 uur 's nachts de wijziging door te voeren

[ Voor 23% gewijzigd door Creepy op 02-07-2008 14:45 ]

[beany]

Creepy schreef op woensdag 02 juli 2008 @ 14:40:
Anyway, btw1, btw2... dat zijn herhaaldelijke zaken. Ondanks dat het er maar twee zijn kan je die toch echt beter in een aparte tabel zijn, je zal straks maar ineens btw3 moeten toevoegen... als je in die aparte tabel dan ook nog een start en stop datum opneemt kan je van te voren al een nieuw BTW tarief invoeren, dat scheelt iemand weer om op 12 uur 's nachts de wijziging door te voeren

In principe is een start datum alleen al genoeg. Als er van een record een nieuwere datum is, heb je dus niet de meest recente te pakken. Dit voorkomt ook fouten bij het toevoegen van records in de BTW tabel(dat BTW periodes elkaar kunnen overlappen).

[MichielioZ]

mocean schreef op woensdag 02 juli 2008 @ 14:29:
Als uitbreiding zou ik ook aanbevelen om per bank-rekening je afschriften in te boeken. En dit dan te koppelen aan je facturen. Op 1 factuur kunnen namelijk meerdere + en - betalingen gebeuren (als er eens wat verkeerd wordt overgemaakt), verspreid over meerdere afschriften.

Met de tabel 'betalingen' kan dit toch gewoon ? (of zie ik dat verkeerd)
Komt er gewoon een nieuwe regel in met hetzelfde verkoop/inkoopid maar een andere datum/bedrag..

Verder is het dus door menigeen aangeraden om een btw tabel te maken...
Ondanks het feit dat het er bij mij nog niet helemaal in wilt dat dit vaak genoeg verandert, ga ik 't dan toch maar aanpassen. Uiteindelijk hebben jullie iig gelijk dat je maar beter op dingen voorbereid kan zijn dan achteraf erachter komen dat je aanpak verkeerd was...

edit:
Had een rare redenatie achter de manier waarop je de btw tabel moet implementeren.

[ Voor 27% gewijzigd door MichielioZ op 02-07-2008 15:12 ]

[beany]

MichielioZ schreef op woensdag 02 juli 2008 @ 15:07:
Verder is het dus door menigeen aangeraden om een btw tabel te maken...
Ondanks het feit dat het er bij mij nog niet helemaal in wilt dat dit vaak genoeg verandert, ga ik 't dan toch maar aanpassen. Uiteindelijk hebben jullie iig gelijk dat je maar beter op dingen voorbereid kan zijn dan achteraf erachter komen dat je aanpak verkeerd was...

edit:
Had een rare redenatie achter de manier waarop je de btw tabel moet implementeren.

Het verandert ook niet vaak, gelukkig niet. Maar het gaat erom dat een beheerder van de applicatie een wijziging kan doorvoeren zonder dat een programmeur nodig is. Het is een stuk flexibiliteit van je applicatie.

[curry684]

MichielioZ schreef op woensdag 02 juli 2008 @ 09:15:
1) Een tabel 'inkoop' erbij maken
2) Een tabel 'boekhouding' maken, waarin een (enum)veld komt dat bepaalt of het om inkoop danwel verkoop gaat. Hierin komen dan wel 2-3 kolommen die specifiek voor inkoop zijn, maar default op NULL staan.

Allebei vloeken volstrekt tegen de basisbeginselen van dubbel boekhouden. En een niet-dubbele boekhouding kun je net zo goed niet voeren in de praktijk.

[MichielioZ]

curry684 schreef op woensdag 02 juli 2008 @ 15:39:
[...]

Allebei vloeken volstrekt tegen de basisbeginselen van dubbel boekhouden. En een niet-dubbele boekhouding kun je net zo goed niet voeren in de praktijk.

Ik heb excel lijsten met inkoop en verkoop en de rekeningen waar naartoe en waar vandaan is betaald.
Mij leek het handig om dit dan in een tabel inkoop, verkoop en betalingen te zetten. Moet natuurlijk wel toegeven (moge duidelijk zijn uit 't feit dat ik dit topic start) dat ik geen overmatige kennis van boekhouden heb, maar zover ik dubbel boekhouden begrijp moeten deze gegevens toch genoeg zijn ?!

[curry684]

Het idee achter dubbel boekhouden is juist dat een transactie compleet los staat van of iets in- of verkoop is.

Iedere transactie levert 2 aan elkaar tegengestelde boekingen op, vandaar de term 'dubbel boekhouden'. Het sturen van een factuur levert dus boekingen op van een omzetrekening (8xxx) naar de debiteurenrekening (1300 meestal). Zodra de klant hem betaalt krijg je boek je het bedrag weg van de debiteurenrekening naar de bankrekening (1100 of zo). Doordat de som van alle boekingen altijd 0 moet zijn is het door dit systeem vrijwel onmogelijk om geld te verduisteren - het staat altijd op een rekening of er is een onbalans die te traceren is.

Zie ook Wikipedia: Dubbel boekhouden. Voor een betrouwbare boekhouding opzetten heb je dus journaalposten en dagboeken nodig, en die hebben niets van doen met in- of verkoop.

[Bolukan]

In de boekhoudwereld zie je dat optie 2 (1 grote tabel) is opgekomen (voorbeeld Exact Globe). Voordeel is dat je op 1 tabel kunt queryen om willekeurige info naar boven te halen. Het nadeel van lege plekken (irrelevante kolommen voor de mutatie) in je database, is minder relevant gezien de lage kosten om zo´n database te draaien. Alles normaliseren is niet altijd economisch en de beste keuze !!

Wel zou ik aparte tabellen hanteren voor zaken die batchgewijze worden ingeladen, bijvoorbeeld betalingen, die eerst verrijkt (matching) of gecontroleerd (standaard import-file controle) moeten worden.

[MichielioZ]

curry684 schreef op donderdag 03 juli 2008 @ 12:22:
Het idee achter dubbel boekhouden is juist dat een transactie compleet los staat van of iets in- of verkoop is.

Iedere transactie levert 2 aan elkaar tegengestelde boekingen op, vandaar de term 'dubbel boekhouden'. Het sturen van een factuur levert dus boekingen op van een omzetrekening (8xxx) naar de debiteurenrekening (1300 meestal). Zodra de klant hem betaalt krijg je boek je het bedrag weg van de debiteurenrekening naar de bankrekening (1100 of zo). Doordat de som van alle boekingen altijd 0 moet zijn is het door dit systeem vrijwel onmogelijk om geld te verduisteren - het staat altijd op een rekening of er is een onbalans die te traceren is.

Zie ook Wikipedia: Dubbel boekhouden. Voor een betrouwbare boekhouding opzetten heb je dus journaalposten en dagboeken nodig, en die hebben niets van doen met in- of verkoop.

Ok, dit begreep ik inderdaad ook uit de Wikipedia pagina...
Maar volgens mij begrijp ik het dan toch niet helemaal, want ik ben van mening dat ik deze manier van boekhouding ook kan toepassen met de data die ik op "mijn" manier in de database zet.
Ik houd namelijk bij of ik een factuur verstuur en of ik een factuur ontvang en wanneer een betaling voltooid is. Dat ik hieraan boekingen koppel van omzetrekening naar debet/credit rekening en vervolgens naar betaalrekening en hiermee een balans opmaak is iets wat mijns inziens niet perse als zodaning in de database hoeft te staan. (Klant wilt graag makkelijke overzichten kunnen krijgen van alle inkoop en verkoop en zien welke klanten nog moeten betalen e.d., wat makkelijker is op mijn manier lijkt me)
Zit ik gewoon fout te denken ? Of heb ik gelijk ?

[beany]

Bolukan schreef op donderdag 03 juli 2008 @ 13:20:
In de boekhoudwereld zie je dat optie 2 (1 grote tabel) is opgekomen (voorbeeld Exact Globe). Voordeel is dat je op 1 tabel kunt queryen om willekeurige info naar boven te halen. Het nadeel van lege plekken (irrelevante kolommen voor de mutatie) in je database, is minder relevant gezien de lage kosten om zo´n database te draaien. Alles normaliseren is niet altijd economisch en de beste keuze !!

Ik vind jouw voordeel van het lekker makkelijk kunnen queryen totaal niet opwegen tegen de vele nadelen van niet of nauwelijke normaliseren. Je gaat er geheid mee in de problemen komen. Keer een uitbreiding, aanpassing of wetten die veranderen en je kan de sjaak zijn!

Normaliseren == Goed. Wel tot op zekere hoogte, maar je moet het ook niet schuwen.

[curry684]

MichielioZ schreef op vrijdag 04 juli 2008 @ 10:11:
[...]

Ok, dit begreep ik inderdaad ook uit de Wikipedia pagina...
Maar volgens mij begrijp ik het dan toch niet helemaal, want ik ben van mening dat ik deze manier van boekhouding ook kan toepassen met de data die ik op "mijn" manier in de database zet.
Ik houd namelijk bij of ik een factuur verstuur en of ik een factuur ontvang en wanneer een betaling voltooid is. Dat ik hieraan boekingen koppel van omzetrekening naar debet/credit rekening en vervolgens naar betaalrekening en hiermee een balans opmaak is iets wat mijns inziens niet perse als zodaning in de database hoeft te staan. (Klant wilt graag makkelijke overzichten kunnen krijgen van alle inkoop en verkoop en zien welke klanten nog moeten betalen e.d., wat makkelijker is op mijn manier lijkt me)
Zit ik gewoon fout te denken ? Of heb ik gelijk ?

Juist het maken van balansen, omzetrekeningen en openstaande facturen is zo enorm handig met het dubbele grootboeksysteem

Wat je globaal doet is aan ieder grootboek een vlag hangen die definieert of het een balans of omzet/kostenrekening is. De 4xxx en 8xxx series zijn klassiek voor kosten en omzet respectievelijk, en 0xxx en 1xxxx zijn je balansrekeningen. De overige series zijn wat obscuurder en zul je niet gebruiken. Vervolgens kun je simpelweg uitdraaien:

Balans: de som van alle boekingen onder alle balansrekeningen uitgesplitst per grootboek. Automatisch overzicht van wat er op de bank staat, wat je aan activa/passiva hebt en wat er open staat bij klanten of leveranciers.
W/V rekening: de som van alle boekingen onder alle omzet/kostenrekeningen. Automatisch overzicht uitgesplitst per omzet- of kostengroep.
Openstaande betalingen: alle boekingen in je crediteuren- of debiteurengrootboek die nog geen tegenboeking hebben gehad. Doordat de feitelijke betaling uiteindelijk een boeking van deze tussenrekeningen naar de bankrekening of het kasboek oplevert (waarna je deze kunt 'afletteren') is dit een sluitend middel om te bepalen wat er nog betaald of geind moet worden.

[? ?]

..

[ Voor 99% gewijzigd door ? ? op 25-01-2013 09:51 ]

[MichielioZ]

curry684 schreef op vrijdag 04 juli 2008 @ 11:29:
[...]

Juist het maken van balansen, omzetrekeningen en openstaande facturen is zo enorm handig met het dubbele grootboeksysteem

Wat je globaal doet is aan ieder grootboek een vlag hangen die definieert of het een balans of omzet/kostenrekening is. De 4xxx en 8xxx series zijn klassiek voor kosten en omzet respectievelijk, en 0xxx en 1xxxx zijn je balansrekeningen. De overige series zijn wat obscuurder en zul je niet gebruiken. Vervolgens kun je simpelweg uitdraaien:

Balans: de som van alle boekingen onder alle balansrekeningen uitgesplitst per grootboek. Automatisch overzicht van wat er op de bank staat, wat je aan activa/passiva hebt en wat er open staat bij klanten of leveranciers.
W/V rekening: de som van alle boekingen onder alle omzet/kostenrekeningen. Automatisch overzicht uitgesplitst per omzet- of kostengroep.
Openstaande betalingen: alle boekingen in je crediteuren- of debiteurengrootboek die nog geen tegenboeking hebben gehad. Doordat de feitelijke betaling uiteindelijk een boeking van deze tussenrekeningen naar de bankrekening of het kasboek oplevert (waarna je deze kunt 'afletteren') is dit een sluitend middel om te bepalen wat er nog betaald of geind moet worden.

Ok, nu is het duidelijk, ik snap er helemaal niets meer van
Hoe zie jij dit dan in een database ?
Ik zie het misschien fout, maar als bedrijf kan je dingen kopen en dingen verkopen (inkoop,verkoop) en verder is de afwikkeling hiervan belangrijk (betalingen). Volgens mij zijn dit alle gegevens die een bedrijf kan aanleveren... Als dat zo is, dan kan ik die gegevens opslaan en van daaruit gaan boekhouden. Zie ik gegevens over het hoofd of val je puur over het feit dat ik de tabellen "inkoop" en "verkoop" noem ?

edit:
Reactie op era.zer : het gaat hier inderdaad om een relatief klein bedrijf met dus ook een relatief simpele boekhouding. Zit er dus goed in dat het hier om enkel boekhouden gaat, zoals ik al zei : ben niet de meest geinformeerde als het hierom gaat. De vraag van de klant was eigenlijk ook alleen maar "maak onze lijstjes na zoals we die in excel hebben", maar dan wil je 't wel goed doen natuurlijk, vandaar dit topic...

[ Voor 10% gewijzigd door MichielioZ op 04-07-2008 13:18 ]

[hamsteg]

Er is een gratis programma met met goede uitleg ... ZAP ... een beetje aftands maar wel heel duidelijk in het boeken, met grootboek, overzichten etc. Dat jij een BTW tabel gaat opnemen bezorgd mij een beetje de kriebels ... deze tabel mag dienen als hulpmiddel voor het uitdraaien van facturen maar mag intern niet gebruikt worden voor terug rekenen (interne boekhouding werkt met bedragen zonder BTW). De history zijn de absolute getallen in "te verrekenen BTW" / "Te betalen BTW". Waarom het wiel uitvinden?

[curry684]

Hoe zeer ik ook de schurft eraan heb als gebruiker ervan: waarom kopen ze niet gewoon Exact Compact voor iets van 1000 euro? Goedkoper dan een week ontwikkeltijd, en dit gaat je stukken langer kosten. En Exact Compact klopt wel, is dubbel, kan interfacen met je accountant, heeft BTW-regels correct, heeft schermen voor Balans, W/V rekening, Te Vorderen en Te Betalen enzovoorts.

[ Voor 30% gewijzigd door curry684 op 04-07-2008 16:03 ]

[MichielioZ]

curry684 schreef op vrijdag 04 juli 2008 @ 16:02:
Hoe zeer ik ook de schurft eraan heb als gebruiker ervan: waarom kopen ze niet gewoon Exact Compact voor iets van 1000 euro? Goedkoper dan een week ontwikkeltijd, en dit gaat je stukken langer kosten. En Exact Compact klopt wel, is dubbel, kan interfacen met je accountant, heeft BTW-regels correct, heeft schermen voor Balans, W/V rekening, Te Vorderen en Te Betalen enzovoorts.

Tsja, had misschien een optie geweest, ware het niet dat nu al teveel werk is gebeurd om dit alsnog te doen. (niet alleen door mij)
De accountant (intern in het bedrijf) werkte dus met excel en heeft zijn bevindingen in het verleden door de belastingdienst laten controleren. Al deze data is inmiddels in de database gezet en ik kan ook dezelfde "lijstjes" (inclusief W&V Rekening e.d.) namaken...(precies wat ze vroegen)
Nadeel is nu dat ik de database goed wil inrichten en voor de toekomst wil klaarmaken, terwijl ik dus duidelijk te weinig verstand heb van boekhouden.

[Cartman!]

Juist als je zelf al aangeeft er te weinig verstand van te hebben moet je er niet aan beginnen denk ik. Als door een fout in je opzet een groot probleem ontstaat met de boekhouding van het bedrijf dan nemen ze je dat echt niet in dank af. Ik zeg: helaas...zonde van je werk, laat ze Exact Compact kopen.