[access] database ontwikkelen voor factuur

[Blizard]

Ben bezig met het ontwerpen van een database in access (later koppelen aan formuliertjes, raportjes etc). Maar nu kwam ik op een onaangenaam probleem. Ik had eerst gedacht om alles te koppelen via relaties, maar wanneer ik dan later bv de prijs aanpas van een artikel dan wijzigt deze ook op oude facturen, wat eigenlijk niet mag !
Nu was mijn vraag : hoe organiseer ik mijn tabellen zodat ik deze informatie kan bewaren ?! Ik kan toch moeilijk van te voren bv 20 * een veld voor de prijs etc reserveren voor 1 factuur ?!
Bijkomende vraag : Ik zou de artikels op nieuwe facturen wél graag kiezen uit een artikel lijst (dus hier heb je wel een relatie).
Heeft iemand toevallig een voorbeeldje van een goed database ontwerp hiervoor ?!

[OZ-Gump]

Wellicht is het een idee om, als je graag historische prijs gegevens wil bijhouden, de factuurregels in zijn geheel op te slaan, dus inclusief prijs. Je krijgt dan een tabel factuur waar alle gegevens betreffende de factuur staan (klantgegevens, betalingscondities, levertijd) en een tabel factuurregels, waar gegevens in staan als artikelcode, aantal, prijs per stuk, regeltotaal. Zo heb je een one-to-many relatie die ervoor zorgt dat je historische factuurgegevens kunt opslaan.

[Stefke]

Je moet de prijs (en eventueel andere gegevens die niet moeten veranderen) van een produkt laten wegschrijven in factuurregels. Dus NIET produkten rechtstreeks koppelen aan fakturen, maar alle gegevens die je onveranderd wil vastleggen in de factuur in een factuurregel (meerdere faktuurregels aan 1 factuur) gekoppeld aan de faktuur wegschrijven op het moment dat je een produkt kiest in je faktuurinvulscherm

Dus:

code:

tblProdukten
Produktid Produkt Productprijs
0001      Emmer   EUR 5,00

tblFakturen
Faktuurid Faktuurdatum Relatieid
0001      12-05-2003    0001

tblFaktuurregels
Faktuurregelid Faktuurid Produktid Aantal Prijs
0005           0001      0001      1      5,00

Relaties:
fakturen.faktuurid->faktuurregels.faktuurid
produkten.Produktid->faktuurregels.Produktid

edit: zie ook boven

[ Voor 12% gewijzigd door Stefke op 17-02-2003 10:26 ]

[Blizard]

Daar had ik ook al aan gedacht (snap de bedoeling van je relatie-ID nog niet zo goed ?!). Maar ik krijg het niet voor elkaar om dan toch te kunnen kiezen voor een artikel uit de artikel-tabel (keuzelijstje). En ook het oneindig maken van het aantal artikels lukt me niet echt in access .. Ik heb steeds een vooraf bepaald aantal invoervelden

[Stefke]

Duh, je faktuur hangt toch aan een relatie? Oke, is in dit voorbeeld niet direct van belang.

Je moet een NIET afhankelijk keuzemenu maken gebaseerd op je tabel produkten in het artikelregelvenster (subformulier) in je faktuurscherm. Daarna kun je - liefst in VBA, maar het kan ook met queries - zorgen dat zodra je met dit keuzemenu een produkt gekozen hebt de juiste record wordt aangemaakt (de faktuurregel), als dat nog niet is gebeurd, en de juiste velden ingevuld (bijv de artikelprijs).

Het aantal artikels wordt niet oneindig, de relatie tussen faktuuren en faktuurregels is oneindig (nl. 1 faktuur kan meer regels hebben).
Gewoon een kwestie van de faktuurregelid op autonummering zetten in de tabel faktuurregels, en op long in de tabel fakturen, en dan een relatie overslepen en instellen.

Maybe moet je eerst effe ergens een boekje lezen oid over relaties in het algemeen en in Access, want je mist veel basiskennis volgens mij - teveel om een faktuurprogramma te maken iig. In de helpfile van access zelf wordt het ook erg goed uitgelegd.

[ Voor 40% gewijzigd door Stefke op 17-02-2003 10:40 ]

[StevenK]

OZ-Gump schreef op 17 February 2003 @ 10:22:
Wellicht is het een idee om, als je graag historische prijs gegevens wil bijhouden, de factuurregels in zijn geheel op te slaan, dus inclusief prijs. Je krijgt dan een tabel factuur waar alle gegevens betreffende de factuur staan (klantgegevens, betalingscondities, levertijd) en een tabel factuurregels, waar gegevens in staan als artikelcode, aantal, prijs per stuk, regeltotaal. Zo heb je een one-to-many relatie die ervoor zorgt dat je historische factuurgegevens kunt opslaan.

Sterker nog, de belastingdienst zal dit als een soort van eis stellen.

In een faktuur kan natuurlijk nooit dynamische data opgeslagen worden, want je moet het papieren ding altijd kunnen reproduceren.

Ik heb ook ooit zoiets gebouwd (en gebruik de database nu nog steeds, maar nu SQL/ASP) en bij een faktuur sla ik alle informatie in twee tabellen op:
Faktuur (algemene info, betalingstermijn, adres etc)
Faktuurregels (alle regels van de faktuur)
Overigens sla ik ook het totaal, het btw-bedrag en het totaal incl. BTW in de algemene tabel op, om te voorkomen dat ik bij een migratie naar een ander systeem tegen een of andere rare afronding aanloop.

[nescafe]

Wil je je artikelen toch kunnen koppelen, doe dan als volgt:

Je maakt een formulier afhankelijk van factuurregels.
Op dit formulier heb je een keuzelijst met invoervak, afhankelijk van veld artikelID in je tabel factuurregels. De inhoud van de keuzelijst is afhankelijk van de tabel artikelen.
Het enige dat je nu nog moet doen is een artikelID.afterupdate event aanmaken die het veld factuurregels.prijs vult met de huidige prijs zoals die in de tabel artikelen staat.

Je kan ook geen veld artikelID opnemen in je tabel factuurregels maar dan moet je dus ook de omschrijving meenemen

[ Voor 12% gewijzigd door nescafe op 17-02-2003 14:24 ]

[Stefke]

dat is dus wat ik zei

[nescafe]

excuse me, niet goed gelezen

[Stefke]

meer koffie drinken

[sopsop]

Je kan ook een verloopdatum meenemen in de tabel met prijs.
Je kunt dan van tevoren je prijswijzigingen doorvoeren, zonder dat de huidige prijzen al wijzigen.
Dan krijg je zo'n tabel:

code:

Table prijzen
- PrijsID
- ProduktID
- Vanaf
- Tot

Vanaf en tot zijn date velden. Ga je de prijs ophalen van een produkt op een bestaande faktuur, dan zoek je de prijs op van het bep. produkt die tussen "vanaf" en "tot" zit. Indien Tot leeg is, dan is dat de huidige prijs.
Zolang je maar alle prijswisselingen als nieuwe invoer in de prijzen tabel ziet.

[Crazy D]

Nadeel daarvan is dat je absoluut geen andere prijs kunt invoeren voor een artikel. En je kunt ook in de problemen komen als een faktuur opnieuw moet worden ingevoerd op een andere datum, of je de faktuur alvast invoerd op een datum volgende week oid (of dat netjes weet ik niet, maar het is wel de praktijk). Op die manier een historie van je prijzen bijhouden kan best handig en intressant zijn, maar voor faktuurregels moet je de prijzen gewoon in de regel opslaan. Die prijzen gelden puur en alleen voor die regel, en dat is de info die je hebben wilt.

[Stefke]

De eerder geboden oplossing (door mij en een paar anderen) is de enige juiste. Een faktuur is een boekhoudkunding statisch document, en dat moeten de gegevens dus óók zijn!

[djluc]

Wat je nu zegt zal vast wel zo zijn maar het is niet zo dat je alles in real-life het beste gelijk kunt vertalen naar een database, een andere opzet kan daar soms stukken 'beter' zijn.

[Stefke]

Hoe denk je dat 99% van de faktuurprogramma's werkt? Ik verzin het niet ter plekke of zo, ik ben bedrijfskundige, geen programmeur..

Sterker nog, de belastingdienst zal dit als een soort van eis stellen.

Hoe praktijkgerichter wil je het nog?

[ Voor 14% gewijzigd door Stefke op 17-02-2003 19:22 ]

[Blizard]

Alvast bedankt voor de tips. Maar ik heb inderdaad het maken van een basic factuurprogramma een beetje onderschat. Ik heb wel al een beetje kennis van access & vba (ook wel al boeken over gelezen), maar ik stuit op een paar problemen waar ik niet echt raad mee weet. En in boeken kan je wel help vinden over klantenbestanden etc, maar nergens over facturatie ..

Probleempjes :
- Wanneer ik het formulier (MaakFactuur) open komt er automatisch een factuurnummer in een veldje etc, maar moet ik dit formulier (velden) koppelen aan een tabel of moet ik deze informatie later zelf wegschrijven als de gebruiker op opslaan klikt ?!
- Wanneer ik het formulier link aan de tabel, dan zal onvermijdelijk de factuur worden opgeslagen vanaf het formulier opengaat, wat niet altijd de bedoeling is.
- Ik werk met een subformulier voor de artikelen, maar hoe laat ik de keuzelijst van Art-code vernieuwen (requery werkt niet... ?!) wanneer ik op dezelfde moment nog een artikel heb toegevoegt.
- Sla ik de klantengegevens ook appart op ?! Of wel met een relatie ? (ik vermoed ook appart opslaan ?)

[Stefke]

Blizard schreef op 19 February 2003 @ 13:55:
Alvast bedankt voor de tips. Maar ik heb inderdaad het maken van een basic factuurprogramma een beetje onderschat. Ik heb wel al een beetje kennis van access & vba (ook wel al boeken over gelezen), maar ik stuit op een paar problemen waar ik niet echt raad mee weet. En in boeken kan je wel help vinden over klantenbestanden etc, maar nergens over facturatie ..

Geen enkel software handboek zal jou uitleggen hoe je een facturatiebestand moet maken. Het klantengedoe is slechts een voorbeeld, en als je de werking erachter begrijpt zul je in principe elk probleem moeten kunnen tackelen.

Probleempjes :
- Wanneer ik het formulier (MaakFactuur) open komt er automatisch een factuurnummer in een veldje etc, maar moet ik dit formulier (velden) koppelen aan een tabel of moet ik deze informatie later zelf wegschrijven als de gebruiker op opslaan klikt ?!
- Wanneer ik het formulier link aan de tabel, dan zal onvermijdelijk de factuur worden opgeslagen vanaf het formulier opengaat, wat niet altijd de bedoeling is.
- Ik werk met een subformulier voor de artikelen, maar hoe laat ik de keuzelijst van Art-code vernieuwen (requery werkt niet... ?!) wanneer ik op dezelfde moment nog een artikel heb toegevoegt.
- Sla ik de klantengegevens ook appart op ?! Of wel met een relatie ? (ik vermoed ook appart opslaan ?)

1. Maakfactuur moet gekoppeld zijn aan de tabel facturen en dan aan een record in je tabel facturen (recordsource="tblfacturen"). In de eigenschappen van dat formulier kun je instellen dat het formulier een nieuwe record moet aanmaken op het moment van openen of dat ie gewoon de 1e record moet laten zien. Je zou in het tweede geval dan met de navigatieknoppen kunnen browsen tussen je facturen.
Een record wordt in Access opgeslagen op het moment dat het formulier gesloten wordt of dat je naar een andere record gaat.

2. Dat is niet het geval. De record blijft gesloten tot het moment dat je er in wijzigt en pas op het moment dat het scherm afgesloten wordt (of de record eigenlijk) door het sluiten van het scherm of het browsen naar een andere record worden de wijzigingen opgeslagen.

3. Requery werkt wel degelijk, maar je gebruikt m waarschijnlijk niet goed. Druk anders even op ...F9 geloof ik, of F11, voor je wil kiezen in je keuzevenster. Doorgaans (in de meeste software dus) wordt het invoeren van nieuwe stamgegevens

4. Ja, in een tabel relaties met sleutel relatieid (event. autonummering). Relatieid moet ook in je tabel facturen (long) met een 1 op meer relatie van relaties naar facturen (want 1 relatie kan meer facturen hebben). Of wilde je soms elke relatie helemaal opnieuw invullen in je factuur?
Wil je ook je relatiegegevens opslaan in de factuur zul je die uit je actuele tabel (relaties) moeten overzetten naar de factuur/relatievelden in de fatcuur (zodat het adres dat op de factuur staat bijv. niet veranderd als je je relatiegegevens wijzigt)

Nogmaals, misschien heb je wat boeken en zo gelezen, maar dit zijn echt vragen van een n00b. Op zich niet erg, maar je kunt jezelf goed helpen door gewoon eens helemaal vooraan te beginnen en niet wat stukjes op te zoeken op het moment dat je het nodig hebt
Je begint zeg maar in het midden, en das niet handig.

[ Voor 3% gewijzigd door Stefke op 19-02-2003 14:31 ]

[OZ-Gump]

- Wanneer ik het formulier (MaakFactuur) open komt er automatisch een factuurnummer in een veldje etc, maar moet ik dit formulier (velden) koppelen aan een tabel of moet ik deze informatie later zelf wegschrijven als de gebruiker op opslaan klikt ?!
* Opslaan op het moment dat iemand op opslaan klikt. Dat is in VB makkelijker te maken dan dat je alles gaat lopen verwijderen als blijkt dat het niet goed gegaan is of het venster gesloten wordt zonder dat iets toegevoegd werd. Is ook iets veiliger dan mensen rechtstreeks in de tabel te laten wroeten.
- Wanneer ik het formulier link aan de tabel, dan zal onvermijdelijk de factuur worden opgeslagen vanaf het formulier opengaat, wat niet altijd de bedoeling is.
* En dus met een opslaanknopje werken
- Ik werk met een subformulier voor de artikelen, maar hoe laat ik de keuzelijst van Art-code vernieuwen (requery werkt niet... ?!) wanneer ik op dezelfde moment nog een artikel heb toegevoegt.
* Eerst het complete form requery'en, daarna de listbox. Als je deze gekoppeld hebt door er een recordsource aan te hangen moet dat werken. Dus: even stoeien met een paar requeries of refreshes. (het meervoud van refresh?)
- Sla ik de klantengegevens ook appart op ?! Of wel met een relatie ? (ik vermoed ook appart opslaan ?)
* Je slaat de klantgegevens op in de factuur. Stel namelijk dat de klant tussentijds verhuist? Dan kun je nooit meer de factuur van destijds terugroepen. Als je facturen opslaat moet ALLES apart worden opgeslagen. Ook dingen als BTW en dergelijke. Je mag de klantgegevens wel OOK bijhouden in een aparte tabel, maar die gebruik je dan alleen bij het aanmaken van een opdracht. Zodra voor de opdracht een factuur gemaakt moet worden, sla je alles op in tabellen voor de factuur.

Good luck!

edit:
Nou is Stefijn me voor... damn!

[ Voor 3% gewijzigd door OZ-Gump op 19-02-2003 14:30 ]

[Stefke]

gewonnen

Ik zie hem in VBA nog geen "opslaan"knop maken. Tis ook niet nodig, er wordt automatisch opgeslagen bij het sluiten van de records/formulieren.

[ Voor 10% gewijzigd door Stefke op 19-02-2003 14:33 ]

[OZ-Gump]

Ik zie hem in VBA nog geen "opslaan"knop maken.

Daar heb jij dan weer gelijk in. Ik doe het meestal wel omdat ik graag controle houd over wat er precies gebeurt. Kreeg laatst een progsel van iemand die dat niet had gedaan en die had ik weet niet hoeveel lege records in zijn tabellen staan.
En het is makkelijker voor de controle op verplichte velden. Tenminste, dat vind ik. Ik werk dan ook niet snel met de validation rules. Moet ik misschien toch maar eens aan beginnen...

[Blizard]

Nogmaals, misschien heb je wat boeken en zo gelezen, maar dit zijn echt vragen van een n00b. Op zich niet erg, maar je kunt jezelf goed helpen door gewoon eens helemaal vooraan te beginnen en niet wat stukjes op te zoeken op het moment dat je het nodig hebt
Je begint zeg maar in het midden, en das niet handig.

Kan zijn dat ik verkeerde boeken lees, en ik heb inderdaad de indruk dat ik in het miden begin en eigenlijk beter opnieuw zou beginnen (maar tijdsdruk maakt het er niet makkelijker op ). Ik heb nog nergens gevonden hoe ik apparte info van een subformulier kan opslaan door op een opslaan knop te klikken. Ik heb ook nog nergens gevonden waar ik expleciet kan zeggen dat de info pas mag worden opgeslagen wanneer de gebruiker op opslaan klikt (niet onform close) ..

Sorry als ik n00b overkom, indien het echt niet wil lukken zal ik mij echt eens gaan verdiepen in de basic-lesjes ..

[Stefke]

OZ-Gump schreef op 19 februari 2003 @ 14:39:
[...]
Daar heb jij dan weer gelijk in. Ik doe het meestal wel omdat ik graag controle houd over wat er precies gebeurt. Kreeg laatst een progsel van iemand die dat niet had gedaan en die had ik weet niet hoeveel lege records in zijn tabellen staan.
En het is makkelijker voor de controle op verplichte velden. Tenminste, dat vind ik. Ik werk dan ook niet snel met de validation rules. Moet ik misschien toch maar eens aan beginnen...

klopt, maar dan moet je wel weten hoe dat moet. Ik doe dat zelf ook op die manier.

Blizard schreef op 19 februari 2003 @ 14:45:
[...]


Kan zijn dat ik verkeerde boeken lees, en ik heb inderdaad de indruk dat ik in het miden begin en eigenlijk beter opnieuw zou beginnen (maar tijdsdruk maakt het er niet makkelijker op ). Ik heb nog nergens gevonden hoe ik apparte info van een subformulier kan opslaan door op een opslaan knop te klikken. Ik heb ook nog nergens gevonden waar ik expleciet kan zeggen dat de info pas mag worden opgeslagen wanneer de gebruiker op opslaan klikt (niet onform close) ..

Sorry als ik n00b overkom, indien het echt niet wil lukken zal ik mij echt eens gaan verdiepen in de basic-lesjes ..

Nogmaals: er is geen standaard functie voor het opslaan van records in Access. Het opslaan van records gebeurd door de record te verlaten (als je bijv. in tabellen werkt zie je bij de in bewerkign zijnde record een potloodje, dwz dat de record op dat moment open staat voor bewerking. Als je dan naar een andere record gaat is het potloodje weg en is de record opgeslagen.
Het sluiten van de tabel heeft hetzelfde effect, net als het sluiten van een formulier waar een tabel op is gebaseerd. En dus ook als je de focus verlegt van de in bewerking zijnde record in je subformulier naar je hoofdformulier.

WIl je het opslaan laten gebeuren als bewuste actie zul je met Visual Basis zelf knoppen en de juiste gebeurtenissen moeten programmeren. Ook zul je dan moeten ondervangen dat de gebruiker het scherm kan sluiten op het moment dat de record in bewerking is, anders kunnen ze ook opslaan zonder op die knop te drukken (zoals dat bijv in Word werkt)

[ Voor 3% gewijzigd door Stefke op 19-02-2003 18:32 ]

[Blizard]

WIl je het opslaan laten gebeuren als bewuste actie zul je met Visual Basis zelf knoppen en de juiste gebeurtenissen moeten programmeren. Ook zul je dan moeten ondervangen dat de gebruiker het scherm kan sluiten op het moment dat de record in bewerking is, anders kunnen ze ook opslaan zonder op die knop te drukken (zoals dat bijv in Word werkt)

Opslaan lukt al met de knop, en ik zal waarschijnlijk ook wel wat vinden voor de sluitenknop, maar dan _moet_ de gebruiker altijd een factuur ingeven vooralleer hij het formulier kan verlaten ?! Of zie ik het nou verkeerd ?

Of kan je een knop maken met als functie : closeform zonder opslaan van gegevens ?! vb : DoCmd.Close , , acSaveNo .. de save hier slaat enkel terug op de layout van het formulier, niet op de inhoud ervan ..

[Stefke]

Wat die die opslaan knop van jou precies?

Nogmaals, je moet even begrijpen dat er DUS geen echte "save"-functie bestaat in Access. Het enige dat je kunt doen is dat "simuleren" door een saveknop te maken, die in feite niets anders doet dan de record sluiten (door focus te verleggen of iets anders).
De gebruiker zal denken: "mijn record wordt nu opgeslagen" terwijl die strikt genomen niet precies zo is.

Wat ik altijd doe, is met een zelfgeschreven functie alle velden op een formulier op slot zetten. Met een knop "wijzig" worden de benodigde velden allemaal vrijgegeven zodat de gebruiker gegevens kan wijzigen.
Voor een nieuwe record gebeurt hetzelfde, alleen gaat het formulier ook naar een nieuwe record.
Met een knop "opslaan" worden deze velden weer op slot gezet en is de record "opgeslagen". Hetzelfde gebeurt als de gebruiker het venster sluit.

Voor de gebruiker lijkt het alsof hij op dat moment (op opslaan drukken en alle velden zijn op slot) echt iets opslaat, terwijl dat DUS niet zo is (nogmaals: dat zit dus NIET in access, dat strikte opslaan!!). Het echte opslaan gebeurt pas bij sluiten van het venster, browsen naar een andere record of het sluiten van de database.

Met andere woorden> wat een gebruiker ook doet, een record wordt ALTIJD!!! opgeslagen. Het voordeel is, je kunt geen handelingen verrichten die je gegevens verloren laten gaan. Het nadeel is dat gegevens normaliter altijd bewerkbaar zijn (net als in een tabel, gewoon record selecteren en typen) en als je dus met je kop op het toetsenbord valt terwijl je in je tabel of formulier zit zijn je gegevens bewerkt. Dat heb ik opgelost door de velden dus op slot te zetten of vrij te geven met een wijzig en een opslaanknop.

Ik zou hier niet teveel aandacht aan besteden en eerst je database zelf in orde krijgen. Je bent weer in het midden bezig, snappie

[ Voor 10% gewijzigd door Stefke op 20-02-2003 11:20 ]

[OZ-Gump]

De manier van Stefijn is één oplossing. En een goede, daar niet van! Ikzelf werk meestal echter anders: ik maak een formulier waar de verschillende tekstvelden en combboxen niet aan een veld van een tabel hangen. De gebruiker kan dingen invoeren en op het moment dat op de Opslaan-knop geklikt wordt open je via code de tabel, vul je alle velden in en sla je 't record op. (Dat is wel een werkwijze die beter geschikt is voor het toevoegen van een record.) Op die manier hou je volledig in eigen hand wanneer een record wel of niet opgeslagen wordt. Dat is natuurlijk bij Stefijns oplossing ook zo, maar wel iets anders...

Ik zeg niet dat een van deze twee oplossingen beter is, ze zijn hooguit anders te noemen. Aan jou nu de taak om te bekijken welke jou het beste ligt en het beste past in jouw applicatie.

[farlane]

OZ-Gump schreef op 20 February 2003 @ 11:28:
ik maak een formulier waar de verschillende tekstvelden en combboxen niet aan een veld van een tabel hangen. De gebruiker kan dingen invoeren en op het moment dat op de Opslaan-knop geklikt wordt open je via code de tabel, vul je alle velden in en sla je 't record op.

Naar mijn idee wel een betere manier want als er ook maar iets mis gaat bij het opslaan kun je ( indien je werkt met transactions ) de hele boel makkelijker terugdraaien.

[Stefke]

idd ook een idee, eens kijken of ik er wat mee kan

[Blizard]

Eerst en vooral wil ik jullie ff bedanken voor de tips !
Nu ben ik al tot in de rapport-weergave geraakt, maar daar stuit ik op een nieuw probleem.
De gebruiker kreeg de mogelijkheid om per artikel een btw-code te kiezen. Nu moet er op de factuur per btw-code een subtotaal komen.
Hoe kan ik dit het beste oplossen ?! Stukje vba-code bij rapport-openen (hoe doorlopen van alle bijhorende records ?!) ? Of reeds berekenen in het formulier, en zo opslaan in de tabel ?!

Zijn er boeken die jullie mij aanraden ? Want de meeste zijn voor het eenvoudig opbouwen van forms etc, niet echt diepgaande dingen