[Database] Ontwerp administratie systeem

[Digihelp ®]

Ik ben bezig met het maken van een administratie systeem voor een ICT service verlener.

Uiteraard ben ik begonnen met het database model, alvorens ik de applicatie ga schrijven (zal php/mysql gaan worden). Ik heb een eerste ontwerp gemaakt, maar aangezien ik niet overtuigd ben van de juistheid zou ik graag jullie feedback willen.

Ik wil met het administratie systeem een aantal dingen doen:

- Elk contact met de klant vastleggen (tel, email, etc)
- Service bezoeken vastleggen
- Andere verkopen aan klanten vastleggen (meetal tijdens een servicebezoek, maar kan ook los)
- De facturatie

Het ontwerp staat hier: http://www.joostsmulders.nl/databasemodel.jpg

Waar ik nog mee zit:
- Hoe registreer ik het als de klant gewoon belt met een vraag, of een emailtje stuurt. Eigenlijk wil ik dat je in het systeem precies elk contact met de klant kan zien. Kan ik dat doen door gewoon de tabel service verzoek te gebruiken door bij soort bijv tel in te vullen, en dan een aantal velden zoals uren leeg te laten, of moet ik hier een andere tabel voor maken ?

- Moet in de factuur tabel ook de totaalprijs en btw worden opgenomen, of moet dat in het kader van de redundancy in de applicatie worden berekent uit de factuurregels.

- Om het uurtarief in rekening te brengen tijdens een service bezoek, alsmede voorrijkosten, zie ik beide nu ook maar als artikel. Is dat de beste oplossing ? Ik heb nog wel een koppeling tussen factuurregel en service bezoek, maar die koppeling zou niet verplicht moeten zijn, omdat er ook losse verkoop mogelijk moet zijn.

Ik hoop dat ik een beetje duidelijk ben geweest. Ben erg benieuwd naar jullie feedback.

[NMe]

los_joost schreef op zaterdag 30 april 2005 @ 19:46:
- Hoe registreer ik het als de klant gewoon belt met een vraag, of een emailtje stuurt. Eigenlijk wil ik dat je in het systeem precies elk contact met de klant kan zien. Kan ik dat doen door gewoon de tabel service verzoek te gebruiken door bij soort bijv tel in te vullen, en dan een aantal velden zoals uren leeg te laten?

Zo zou ik het wel doen ja. Pas wanneer er aardig wat velden bij de een nodig zijn, terwijl de andere soort die niet hoeft, maar juist weer andere velden nodig heeft, dan is het handiger om een nieuwe tabel te maken. Lijkt me hier echter niet de bedoeling.

- Moet in de factuur tabel ook de totaalprijs en btw worden opgenomen, of moet dat in het kader van de redundancy in de applicatie worden berekent uit de factuurregels.

Berekenbare gegevens neem je doorgaans niet op in de database. Als performance van belang is, dan doe je dat juist weer wel. Het hangt er dus een beetje vanaf wat je doet, maar voor de meeste kleinschaligere applicaties, zou ik er geen extra velden voor opnemen en het gewoon berekenen.

- Om het uurtarief in rekening te brengen tijdens een service bezoek, alsmede voorrijkosten, zie ik beide nu ook maar als artikel. Is dat de beste oplossing ? Ik heb nog wel een koppeling tussen factuurregel en service bezoek, maar die koppeling zou niet verplicht moeten zijn, omdat er ook losse verkoop mogelijk moet zijn.

Wanneer uurtarieven en voorrijkosten ooit nog wel eens zouden kunnen veranderen, is het waarschijnlijk inderdaad het handigst om ze gewoon in de tabel op te nemen als product.

[P_de_B]

Even weinig tijd om heel goed te kijken, maar 1 dingetje viel me op. Waarom zijn uren als float gedefinieerd? Dat lijkt me niet het goede type. Ik zou voor een decimal kiezen.

[Digihelp ®]

P_de_B schreef op zaterdag 30 april 2005 @ 20:10:
Even weinig tijd om heel goed te kijken, maar 1 dingetje viel me op. Waarom zijn uren als float gedefinieerd? Dat lijkt me niet het goede type. Ik zou voor een decimal kiezen.

Omdat je ook wel eens 1,5 uur met een service bezoek bezig bent.

[NMe]

P_de_B schreef op zaterdag 30 april 2005 @ 20:10:
Even weinig tijd om heel goed te kijken, maar 1 dingetje viel me op. Waarom zijn uren als float gedefinieerd? Dat lijkt me niet het goede type. Ik zou voor een decimal kiezen.

Geldt dat niet ook voor Klant.korting en alle prijzen? Overigens, waarom sla je de BTW op? Dit is toch altijd een bepaald percentage (19% in dit geval lijkt me). Lijkt me handiger om de prijzen ex. BTW op te nemen, en de prijzen inclusief BTW en de BTW zelf ook te berekenen.

Ow, en waarom een los datum en tijdveld? Waarom niet een veld van het type datetime?

[ Voor 8% gewijzigd door NMe op 30-04-2005 20:20 ]

[P_de_B]

FLOAT is een drijvende komma datatype, en dus niet een exacte representatie van de waarde. Het is een benadering. Daarom mijn voorstel een decimal te gebruiken.

[Digihelp ®]

Zo zou ik het wel doen ja. Pas wanneer er aardig wat velden bij de een nodig zijn, terwijl de andere soort die niet hoeft, maar juist weer andere velden nodig heeft, dan is het handiger om een nieuwe tabel te maken. Lijkt me hier echter niet de bedoeling.

Geen andere velden, alleen minder. Dus in dit geval kan ik het dus laten hoe het is.

Berekenbare gegevens neem je doorgaans niet op in de database. Als performance van belang is, dan doe je dat juist weer wel. Het hangt er dus een beetje vanaf wat je doet, maar voor de meeste kleinschaligere applicaties, zou ik er geen extra velden voor opnemen en het gewoon berekenen.

Dank. Dan kan ik dit er idd gewoon uitlaten.

Wanneer uurtarieven en voorrijkosten ooit nog wel eens zouden kunnen veranderen, is het waarschijnlijk inderdaad het handigst om ze gewoon in de tabel op te nemen als product.

[/quote]

Dat dacht ik dus ook. Maakt het facturen ook weer makkelijker in de applicatie. Nog een tip hoe ik ervoor zorg dat een service bezoek en voorrijkosten wel na elkaar komen te staan, en niet bijvoorbeeld met een ander product er tussen ? Ik kan hier natuurlijk wel iets voor verzinnen, maar ben benieuwd of ik iets kan doen in de database om dat dadelijk in de applicatie heel makkelijk te maken ?

Zijn er verder nog zaken die ik kan verbeteren ? Ik heb wel een aantal databases gemaakt, maar nooit een echte opleiding hiervoor gevolgd.

[Digihelp ®]

P_de_B schreef op zaterdag 30 april 2005 @ 20:20:
FLOAT is een drijvende komma datatype, en dus niet een exacte representatie van de waarde. Het is een benadering. Daarom mijn voorstel een decimal te gebruiken.

Oeps, zat even niet goed op te letten. Een decimal zou inderdaad beter zijn.

[Digihelp ®]

-NMe- schreef op zaterdag 30 april 2005 @ 20:18:
[...]

Geldt dat niet ook voor Klant.korting en alle prijzen? Overigens, waarom sla je de BTW op? Dit is toch altijd een bepaald percentage (19% in dit geval lijkt me). Lijkt me handiger om de prijzen ex. BTW op te nemen, en de prijzen inclusief BTW en de BTW zelf ook te berekenen.

Ow, en waarom een los datum en tijdveld? Waarom niet een veld van het type datetime?

In principe wel. Enige reden om BTW op te slaan, is om historisch juiste gegevens te hebben als het BTW tarief ooit veranderd. Hoe wordt daar normaal gesproken mee om gegaan ? Het is namelijk wel de bedoeling om een kopie factuur uit te kunnen draaien en dan mag natuurlijk niet het BTW tarief veranderd zijn.

Datetime lijkt me idd wel slimmer.

[ Voor 3% gewijzigd door Digihelp ® op 30-04-2005 20:27 ]

[MisterData]

-NMe- schreef op zaterdag 30 april 2005 @ 20:18:
[...]

Geldt dat niet ook voor Klant.korting en alle prijzen? Overigens, waarom sla je de BTW op? Dit is toch altijd een bepaald percentage (19% in dit geval lijkt me). Lijkt me handiger om de prijzen ex. BTW op te nemen, en de prijzen inclusief BTW en de BTW zelf ook te berekenen.

Ow, en waarom een los datum en tijdveld? Waarom niet een veld van het type datetime?

Laag btw en hoog btw is er ook nog he... en wellicht verandert door de tijd heen nog welke BTW-soort op welk product van toepassing is (vallen de kappers bijv onder laag of hoog? was een tijd geleden nog nieuws) Ik zou het gewoon opslaan dus.

[NMe]

los_joost schreef op zaterdag 30 april 2005 @ 20:22:
Dat dacht ik dus ook. Maakt het facturen ook weer makkelijker in de applicatie. Nog een tip hoe ik ervoor zorg dat een service bezoek en voorrijkosten wel na elkaar komen te staan, en niet bijvoorbeeld met een ander product er tussen ? Ik kan hier natuurlijk wel iets voor verzinnen, maar ben benieuwd of ik iets kan doen in de database om dat dadelijk in de applicatie heel makkelijk te maken?

Je zou ervoor kunnen zorgen dat het uurtarief en de voorrijkosten als eerste als product worden toegevoegd, en daarna bij het selecteren een selectie sorteren op datum van toevoegen (id-veld gebruiken). Op die manier staan die kosten altijd bovenaan. Nadeel is natuurlijk dat je dan niet op een andere manier kan sorteren.

De andere logische optie is natuurlijk het sorteren regelen in je applicatie zelf, maar waar je voor kiest is in dit geval denk ik vrij persoonlijk.

[NMe]

MisterData schreef op zaterdag 30 april 2005 @ 20:26:
Laag btw en hoog btw is er ook nog he... en wellicht verandert door de tijd heen nog welke BTW-soort op welk product van toepassing is (vallen de kappers bijv onder laag of hoog? was een tijd geleden nog nieuws) Ik zou het gewoon opslaan dus.

Neem dan een extra tabel op ofzo met "heffingen" erin, met daarin een id, een benaming en een percentage. Dan neem je dan per product op welke heffing erbij hoort. Maar eerlijk gezegd lijkt me dat een beetje overdreven, zo vaak verandert het BTW-tarief ook weer niet, en bedrijven hebben meestal niet met beide BTW-tarieven tegelijk te maken voor zover ik weet.

[Atari Paul]

Let er inderdaad op dat de factuur ten allen tijde hetzelfde blijft (de belastingdienst vindt dat nogal belangrijk).
Dus moet je er ook op letten dat je klantgegevens blijven zoals ze ten tijde van de factuur waren !
Dit blijkt nog niet helemaal uit je datamodel, ikzelf kies er bij dit soort systemen dan ook voor om de factuurgegevens als XML in de database op te slaan.
Dus alle factuurgegevens in 1 XML document te zetten, en dit op te slaan.

[Atari Paul]

NME, let er op dat je ook het nultarief hebt, nu weet ik niet of het bedrijf waar de TS dit voor schrijft daar mee te maken heeft, maar ik zou het in ieder geval navragen.

[P_de_B]

-NMe- schreef op zaterdag 30 april 2005 @ 20:29:
[...]

Neem dan een extra tabel op ofzo met "heffingen" erin, met daarin een id, een benaming en een percentage. Dan neem je dan per product op welke heffing erbij hoort. Maar eerlijk gezegd lijkt me dat een beetje overdreven, zo vaak verandert het BTW-tarief ook weer niet, en bedrijven hebben meestal niet met beide BTW-tarieven tegelijk te maken voor zover ik weet.

Lijkt me niet overdreven en ik denk dat het vaker voorkomt dan je denkt. Bij ons bedrijf is het ook het geval. Je kunt wel zeggen dat het niet vaak voorkomt maar als het percentage veranderd kun je geen oude kopiefacturen meer uitdraaien.

[P_de_B]

Atari Paul schreef op zaterdag 30 april 2005 @ 20:30:
Let er inderdaad op dat de factuur ten allen tijde hetzelfde blijft (de belastingdienst vindt dat nogal belangrijk).
Dus moet je er ook op letten dat je klantgegevens blijven zoals ze ten tijde van de factuur waren !
Dit blijkt nog niet helemaal uit je datamodel, ikzelf kies er bij dit soort systemen dan ook voor om de factuurgegevens als XML in de database op te slaan.
Dus alle factuurgegevens in 1 XML document te zetten, en dit op te slaan.

Waarom zou je het als XML opslaan? Als je het vast wilt opslaan zou ik het in een BLOB veld doen. Exact doet dit bijvoorbeeld ook.

[Digihelp ®]

-NMe- schreef op zaterdag 30 april 2005 @ 20:26:
[...]

Je zou ervoor kunnen zorgen dat het uurtarief en de voorrijkosten als eerste als product worden toegevoegd, en daarna bij het selecteren een selectie sorteren op datum van toevoegen (id-veld gebruiken). Op die manier staan die kosten altijd bovenaan. Nadeel is natuurlijk dat je dan niet op een andere manier kan sorteren.

De andere logische optie is natuurlijk het sorteren regelen in je applicatie zelf, maar waar je voor kiest is in dit geval denk ik vrij persoonlijk.

Wel een goed idee. Ik kan dan ook nog wel een veld Datum opnemen in de tabel Factuurregel, en dan sorteren op artikel id, en dan op datum. Dan heb je wel een mooie sortering denk ik.

[Atari Paul]

P_de_B schreef op zaterdag 30 april 2005 @ 20:33:
[...]


Waarom zou je het als XML opslaan? Als je het vast wilt opslaan zou ik het in een BLOB veld doen. Exact doet dit bijvoorbeeld ook.

Ja goed, dat bedoel ik eigenlijk ook. Ikzelf sla het als XML op om de factuur als PDF of HTML te kunnen genereren. De XML sla ik dan ook op in een TEXT veld.

[NMe]

los_joost schreef op zaterdag 30 april 2005 @ 20:34:
Wel een goed idee. Ik kan dan ook nog wel een veld Datum opnemen in de tabel Factuurregel, en dan sorteren op artikel id, en dan op datum. Dan heb je wel een mooie sortering denk ik.

Factuurregels hebben geen datum lijkt me. Facturen wel.

[Digihelp ®]

P_de_B schreef op zaterdag 30 april 2005 @ 20:33:
[...]


Waarom zou je het als XML opslaan? Als je het vast wilt opslaan zou ik het in een BLOB veld doen. Exact doet dit bijvoorbeeld ook.

Ik denk dat hij bedoelt om een XML bestand in het BLOB veld te stoppen.

Een BTW tabel lijkt me sowieso wel verstandig na jullie gelezen te hebben gelezen. Wanneer sla je de factuur eigenlijk op als XML ? Op het moment dat je hem gaat printen / versturen ?

[Verwijderd]

Atari Paul schreef op zaterdag 30 april 2005 @ 20:30:
... ikzelf kies er bij dit soort systemen dan ook voor om de factuurgegevens als XML in de database op te slaan.
Dus alle factuurgegevens in 1 XML document te zetten, en dit op te slaan.

Lekker handig, heb je beschikking over een heuse relationele database, ga je data als XML opslaan.
Dat je de data kunt exporteren naar een XML bestand is een mogelijkheid, maar die data moet je dan wel uit de database halen.

En wat is er mis met wat extra kolommen in een tabel? Ze zijn zelfs noodzakelijk.

[NMe]

los_joost schreef op zaterdag 30 april 2005 @ 20:37:
Wanneer sla je de factuur eigenlijk op als XML ? Op het moment dat je hem gaat printen / versturen ?

Niet.

XML wordt vaak als doel gezien, en men vergeet dan even te bedenken dat het juist een middel is. Als je geen XML nodig hebt, gebruik het dan ook niet.

[Digihelp ®]

-NMe- schreef op zaterdag 30 april 2005 @ 20:37:
[...]

Factuurregels hebben geen datum lijkt me. Facturen wel.

Dat kan toch wel ? Je kan toch op 1 factuur, verschillende zaken in rekening brengen die op verschillende dagen verkocht zijn aan de klant ? Of kan je beter per keer (dag) een factuur maken ?

[Atari Paul]

los_joost schreef op zaterdag 30 april 2005 @ 20:37:
[...]


Ik denk dat hij bedoelt om een XML bestand in het BLOB veld te stoppen.

Een BTW tabel lijkt me sowieso wel verstandig na jullie gelezen te hebben gelezen. Wanneer sla je de factuur eigenlijk op als XML ? Op het moment dat je hem gaat printen / versturen ?

Inderdaad.

In principe op het moment van printen, omdat er maar 1 origineel mag zijn van een factuur.
Dus na 1 print moeten de vervolgprints van een factuur altijd kopieen zijn.

[NMe]

los_joost schreef op zaterdag 30 april 2005 @ 20:39:
Dat kan toch wel ? Je kan toch op 1 factuur, verschillende zaken in rekening brengen die op verschillende dagen verkocht zijn aan de klant ? Of kan je beter per keer (dag) een factuur maken ?

Hmm, hangt eigenlijk van de werkwijze af, nu ik erbij stilsta. Komt er één factuur per maand ofzo? Of één per bestelling? In het eerste geval heeft een factuurregel een datum, in het tweede geval niet.

[Verwijderd]

-NMe- schreef op zaterdag 30 april 2005 @ 20:37:

Factuurregels hebben geen datum lijkt me. Facturen wel.

Waarom zou een factuurregel geen datum hebben? Als een bepaalde dienst op een bepaalde datum is geleverd dan kan de klant dat ook meteen zien. Een soort specificatie kan zelden kwaad. Het is wel zo duidelijk voor de klant.

[Sybr_E-N]

los_joost schreef op zaterdag 30 april 2005 @ 20:37:
[...]


Ik denk dat hij bedoelt om een XML bestand in het BLOB veld te stoppen.

Een BTW tabel lijkt me sowieso wel verstandig na jullie gelezen te hebben gelezen. Wanneer sla je de factuur eigenlijk op als XML ? Op het moment dat je hem gaat printen / versturen ?

Bedenk wel dat je dan dubbel bezig bent. Beschik je over een goede db, ga je alles opslaan als XML. (XML moet je niet zien als een soort db.). Je het beter opnemen in je database. Dit betekend wel dat je extra kolommen of zelfs tabellen moet gaan opnemen.

edit:
Sorry voor de trage post, ik bedoel ong. net zoals nme en cheatah.

[ Voor 7% gewijzigd door Sybr_E-N op 30-04-2005 20:42 . Reden: Gaat snel hier, ben weer eens traag. ]

[Digihelp ®]

-NMe- schreef op zaterdag 30 april 2005 @ 20:39:
[...]

Niet.

XML wordt vaak als doel gezien, en men vergeet dan even te bedenken dat het juist een middel is. Als je geen XML nodig hebt, gebruik het dan ook niet.

Ok, maar dan zou je dus ook het hele factuuradres in de tabel factuur moeten opnemen, om te zorgen dat dat nooit meer kan veranderen. Of zie ik dat nou verkeerd ?

[Verwijderd]

los_joost schreef op zaterdag 30 april 2005 @ 20:41:

Ok, maar dan zou je dus ook het hele factuuradres in de tabel factuur moeten opnemen, om te zorgen dat dat nooit meer kan veranderen. Of zie ik dat nou verkeerd ?

Dat zie je heel goed. En die mag je niet meer wijzigen.

[NMe]

los_joost schreef op zaterdag 30 april 2005 @ 20:41:
Ok, maar dan zou je dus ook het hele factuuradres in de tabel factuur moeten opnemen, om te zorgen dat dat nooit meer kan veranderen. Of zie ik dat nou verkeerd ?

Als je dan toch die BTW-tabel hebt, dan kun je toch gewoon daarnaar blijven linken? Verandert het BTW-tarief, dan voeg je gewoon een nieuw tarief toe: "BTW-Laag-2005" ofzo. Op die manier blijven oudere facturen gewoon linken naar de oude BTW-tarieven en kun je zonder meer een nieuwe factuur uit de database trekken.

[Digihelp ®]

Nog even iets anders, door mijn database modeleer programma (DBDesigner4) zijn er automatisch een heleboel indexen aangemaakt, met name in de tabellen service bezoek en factuurregel. Is dat de meest efficiente manier ?

[Atari Paul]

Nee, ik weet ook wel dat XML geen doel op zich is. Maar in dit geval vind ik het handiger omdat deze data toch niet meer mag veranderen. Verder heb ik in die tabel wel meer velden staan, zoals het factuurnummer, factuurdatum, debiteurnummer, etc.
Maar dingen zoals adresgegevens sla ik gewoon in de BLOB op, omdat dit toch historische data is waarop geen snelle queries nodig zijn.

Hmm, ok late reactie.....er wordt wel snel gereageerd

[ Voor 9% gewijzigd door Atari Paul op 30-04-2005 20:46 ]

[Digihelp ®]

-NMe- schreef op zaterdag 30 april 2005 @ 20:43:
[...]

Als je dan toch die BTW-tabel hebt, dan kun je toch gewoon daarnaar blijven linken? Verandert het BTW-tarief, dan voeg je gewoon een nieuw tarief toe: "BTW-Laag-2005" ofzo. Op die manier blijven oudere facturen gewoon linken naar de oude BTW-tarieven en kun je zonder meer een nieuwe factuur uit de database trekken.

In het geval van BTW kan dat idd. Maar de factuur linkt ook naar een klantid, en dus indirect naar NAW gegevens. Als die veranderen in de tabel klant, en je draait de factuur opnieuw uit, dan krijg je dus andere NAW gegevens...

[Verwijderd]

Atari Paul schreef op zaterdag 30 april 2005 @ 20:45:
Nee, ik weet ook wel dat XML geen doel op zich is. Maar in dit geval vind ik het handiger omdat deze data toch niet meer mag veranderen. Verder heb ik in die tabel wel meer velden staan, zoals het factuurnummer, factuurdatum, debiteurnummer, etc.
Maar dingen zoals adresgegevens sla ik gewoon in de BLOB op, omdat dit toch historische data is waarop geen snelle queries nodig zijn.

Je weet maar nooit. Als je wilt opzoeken welke facturen er naar een bepaald adres zijn verstuurd, dan moet je toch iets met die data doen.
En of je nou een BLOB kolom hebt waar je geen wijzigingen in mag maken, of je hebt meerdere kolommen. Wat maakt het uit? Als je de applicatie ontwerpt moet je gewoon zorgen dat die zaken niet worden aangepast.

[P_de_B]

Verwijderd schreef op zaterdag 30 april 2005 @ 20:41:
[...]

Waarom zou een factuurregel geen datum hebben? Als een bepaalde dienst op een bepaalde datum is geleverd dan kan de klant dat ook meteen zien. Een soort specificatie kan zelden kwaad. Het is wel zo duidelijk voor de klant.

Die extra info kun je toch uit de serviceregels halen?

[Digihelp ®]

P_de_B schreef op zaterdag 30 april 2005 @ 20:48:
[...]

Die extra info kun je toch uit de serviceregels halen?

Als er een servicebezoek was wel. Maar in het geval van losse verkoop wordt dat lastig. Of is mijn db model op dit punt hier niet heel goed ?

[Atari Paul]

Verwijderd schreef op zaterdag 30 april 2005 @ 20:48:
[...]

Je weet maar nooit. Als je wilt opzoeken welke facturen er naar een bepaald adres zijn verstuurd, dan moet je toch iets met die data doen.
En of je nou een BLOB kolom hebt waar je geen wijzigingen in mag maken, of je hebt meerdere kolommen. Wat maakt het uit? Als je de applicatie ontwerpt moet je gewoon zorgen dat die zaken niet worden aangepast.

Goed, maar dan moet je ook iets als historische adressen van klanten gaan bijhouden. Dus een soort van obsolete datum gaan opnemen bij alle tabellen waar gegevens instaan die kunnen verouderen.

[Digihelp ®]

Atari Paul schreef op zaterdag 30 april 2005 @ 20:54:
Goed, maar dan moet je ook iets als historische adressen van klanten gaan bijhouden. Dus een soort van obsolete datum gaan opnemen bij alle tabellen waar gegevens instaan die kunnen verouderen.

Ik was eigenlijk van plan om gewoon een aantal extra NAW kolommen in de factuur tabel te maken, en daar de gegevens naartoe te kopieren. Op die manier veranderen ze niet meer. Maar ja, als je dus vaak dezelfde klanten heb, dan komt er dus wel veel dubbele data in de db te staan, maar op zich is dat niet heel erg, omdat je die factuur adressen toch nooit meer aan hoeft te passen, tenzij er een fout is gemaakt bij het maken van de factuur.

[P_de_B]

los_joost schreef op zaterdag 30 april 2005 @ 20:50:
[...]


Als er een servicebezoek was wel. Maar in het geval van losse verkoop wordt dat lastig. Of is mijn db model op dit punt hier niet heel goed ?

Dan kom je toch een beetje in een order tabel structuur terecht. Een order kan dan een servicebezoek zijn, of contante verkoop. Van orders en orderregels worden dan weer fakturen gemaakt. Orders slaat op wat/waneer er gebeurt is of wat er verkocht is. Faktuur slaat dan op wat dat gekost heeft (heel kort gezegd).

[Digihelp ®]

P_de_B schreef op zaterdag 30 april 2005 @ 21:14:
Dan kom je toch een beetje in een order tabel structuur terecht. Een order kan dan een servicebezoek zijn, of contante verkoop. Van orders en orderregels worden dan weer fakturen gemaakt. Orders slaat op wat/waneer er gebeurt is of wat er verkocht is. Faktuur slaat dan op wat dat gekost heeft (heel kort gezegd).

Een van de doelen van het systeem is dat ook de monteurs via het systeem kunnen zien naar welke klant ze moeten. Is dat nog wel makkelijk te realizeren als ik er een order structuur van maak ?

[djluc]

los_joost schreef op zondag 01 mei 2005 @ 13:56:
[...]
Een van de doelen van het systeem is dat ook de monteurs via het systeem kunnen zien naar welke klant ze moeten. Is dat nog wel makkelijk te realizeren als ik er een order structuur van maak ?

Ja, aan een order is een klant gekoppeld. Je kan dus deze info eenvoudig uit de db halen.