Door
Chris PHP
op 15-01-2014 15:36
gewijzigd op 15-01-2014 15:37
6.212 views
Heren,
Ik kan er niet helemaal uitkomen wat nu de beste structuur is voor facturen. Ik zal hieronder laten zien hoe ik het nu heb, maar dit zorgt voor ingewikkelde queries lijkt me.
verkoop_facturen
vfactnr (uniek auto increment)
klantnr
vfactdatum
vfactvervaldatum
inkoop_facturen
ifactnr (uniek auto increment)
klantnr
ifactdatum
ifactvervaldatum
join_facturen
joinid (uniek auto increment)
vfactnr
ifactnr
artid
Mijn idee was om in join_facturen dus de juiste factuurnummers zetten met artiekelid's. Echter wanneer ik dus de factuur wil weergeven moet ik gegevens hebben uit 3 a 4 tabellen! Namelijk: klanten, vfactuur/ifactuur, artiekelen en join_facturen.
Mij lijkt dit nogal omslachtig en wellicht een zware query, wat is jullie idee?
Want float 5.45 + 5.45 zou best eens niet op 10.90 uit kunnen komen. Floats zijn bij benadering.
Verder mis je in de facturen het bedrag. Dat bedrag is niet gelijk aan de prijs van het verkochte artikel.
Want stel nu dat je vandaag een ding verkoopt voor 10 euro.
Dan komt daar een factuur uit voor 10 euro.
Morgen wordt het artikel wegens gestegen prijzen naar 11 euro.
Klant betaalt keurig de 10 euro, en jouw administratie beweert dat er 11 in rekening was gebracht....
En ik snap niet helemaal hoe jij join_facturen precies ziet. Of jij bedoelt met inkoopfactuur iets anders dan dat ik doe.
Verder zou ik niet alles zo afkorten. nu is het jou misschien duidelijk, maar is het dat ook nog over 1 jaar, of over 2 jaar voor een collega die er mee moet gaan werken en zich bij alles moet afvragen zou een artomsc soms artikelosmchrijving zijn,
danwel als hij een query schrijft, zich weer moet afvragen: welke letters laat ik weg uit inkoopfactuurvervaldatum
Het is nu iets meer typwerkt, maar scheelt je een hoop potentiële fouten
Thnx voor de input Float -> Decimal duidelijk.
Er komen nog meer velden bij maar het artiekel blijft uniek en de prijs wordt uiteraard ge-upadte wanneer deze hoger of lager wordt. Dus bijv pak koffie is 2,50 dit zal zo blijven totdat ik de prijs verhoof of verlaag. Het totaal bedrag moet nog ergens bij komen, maar ik weet niet precies hoe ik nu een query kan draaien die selecteerd wat ik nodig heb.
De join_facturen is om de artiekelen aan de juiste factuur te koppelen, bijv factuur001 heeft 3 artiekelen dit wordt dus weggeschreven in de join_facturen. De afkortingen is puur voor hier, omdat dit een voorbeeld is. Als ik het alemaal moet uittypen is veel werk.
Tevens documenteer ik alles, wat welke velden inhouden. Klantgegevens hebben zelfs id's ipv relatieve namen. Een aantal gegevens worden daarin encrypted opgeslagen en ge-decrypt wanneer ik ze opvraag. Puur omdat je steeds vaker leest dat er xxx.xxx aantal klantgegevens op straat liggen door database hacks.
een volgnummer (id)
een FK naar een klant-id
een datum
een vervaldatum
een status (open, betaald etc) liefst met een FK naar een status tabel
een betaal datum
eventueel nog een factuurnummer, bijvoorbeeld 2014-1-999 voor factuur met id 999 in het eerste kwartaal
Facturen hebben 1 of meerdere regels
tabelfactuurregels
een id
een FK naar het factuurnummer (id)
een FK naar een artikel id
een aantal (5 stuks)
het bedrag (5 * 10 euro)
een btw percentage
wil je nu weten wat het bedrag is van deze factuur dan zijn er 2 opties:
ofwel bereken je dat door de sommatie van de betreffende factuur regels
ofwel bereken je dat eenmalig en sla je dat bij de factuurtabel op
[size=xsmall]Toevoeging op 15/01/2014 16:09:54:[/size]
oh, en bedenk ook vast wat te doen met facturen die in meerdere etappes betaald worden.
[size=xsmall]Toevoeging op 15/01/2014 16:10:55:[/size]
misschien sowieso wel een tabel voor de registratie van betalingen.
Maar voor het een heel boekhoudpakket wordt: wat ben je aan het bouwen?
Er komen nog meer velden bij maar het artiekel blijft uniek en de prijs wordt uiteraard ge-upadte wanneer deze hoger of lager wordt.
Nou, dat is dus juist niet de bedoeling. ;-)
De prijs van een gefactureerd artikel moet nooit meer kunnen wijzigen. Om die reden moet je een factuurtabel dus ook nooit joinen met een artikeltabel, maar moet je bij het aanmaken van de factuur de betreffende artikelregels kopiëren naar bijvoorbeeld een tabel met factuurregels.
Officieel moet je een factuur ten alle tijde (in ieder geval 5 jaar) op elk moment kunnen reproduceren zoals ie is aangemaakt.
Dat gaat dus niet alleen over de prijs van een artikel, maar ook naar welk adres je hem verstuurt.
Ik heb trouwens voor alleen de product gegevens van een bestelling/factuur al 7 tabellen nodig, dit gaat prima met één query
Maar Chris kan wellicht eerst uit de voeten met de tabellen factuur en factuurrregel.
In factuur onder andere de volledige naw van de koper dus niet alleen een ref key en in factuurregel de producten compleet met omschrijving prijs en btw want in vijf jaar kan het product wel uit de handel zijn en de btw 30%. In factuur kan je desgewenst nog wat andere attributen (aankoop/verkoop) of referentie naar bestelling en betaling of status daarover opnemen. @Ger 7 tabellen? Ik ben benieuwd naar de andere 5?
Daarnaast hoeft de artikelprijs op de factuur niet gelijk te zijn aan de normale artikelprijs. Denk aan aanbiedingen en (kwantum)kortingen. Maar dat zou ook nog in correctieregels verwerkt kunnen worden.
