Database voor facturen te maken

  • Onderwerp starter Onderwerp starter Erc
  • Startdatum Startdatum
Status
Niet open voor verdere reacties.
Dag Erc:
je kan de resultaten berekenen in een query, maar vergeet niet de resultaten hard weg te schrijven in de factuurtabellen: de detailresultaten in de factuurregels (je moet per detailregel ook BTW berekenen), en het grote totaal plus eventueel de tussentotalen BTW per tarief, in de hoofdtabel. Zo kan je later nog altijd de factuur opnieuw afdrukken zoals ze geweest is, zelfs als de prijzen of BTW tarieven of productomschrijvingen later veranderd zijn.
Zelfs al is dit een forum voor liefhebbers, eens je met facturen werkt ben je professioneel bezig en moet je aan bepaalderegels voldoen. In België kunnen ook eenmanszaken een bezoek van de auditor krijgen en ik vermoed dat dit in Nederland niet anders is.
 
Dag Erc:
je kan de resultaten berekenen in een query, maar vergeet niet de resultaten hard weg te schrijven in de factuurtabellen: de detailresultaten in de factuurregels (je moet per detailregel ook BTW berekenen), en het grote totaal plus eventueel de tussentotalen BTW per tarief, in de hoofdtabel. Zo kan je later nog altijd de factuur opnieuw afdrukken zoals ze geweest is, zelfs als de prijzen of BTW tarieven of productomschrijvingen later veranderd zijn.

Hard wegschrijven: wat bedoel je hier exact mee? Ik ben nu al die berekeningen in een query aan het maken, ik zal het vanavond opnieuw posten op het forum.

Dag Erc:
Zelfs al is dit een forum voor liefhebbers, eens je met facturen werkt ben je professioneel bezig en moet je aan bepaalderegels voldoen. In België kunnen ook eenmanszaken een bezoek van de auditor krijgen en ik vermoed dat dit in Nederland niet anders is.

Noella, Ik ben er heel bewust van maar als office liefhebber wil ik ook zoveel mogelijk zelf bijleren, omdat ik er vooral dagelijks mee bezig ben.

Groeten
Ercan
 
Het antwoord op je laatste vraag gaf al de oplossing voor het probleem dat Noella aanstipte. Door de prijs gegevens in de keuzelijst te zetten voor je artikelen, kun je de velden in je tabel Factuurregels gewoon gebruiken om ze te vullen vanuit de keuzelijst. De velden vul je dan vanuit de keuzelijst met VBA.
 
Hard wegschrijven = het resultaat van de berekeningen kopiëren naar een veld in één van de factuurtabellen. Dat doe je ook met de adresgegevens van de klant. Want als je later de factuur terug moet afdrukken dan moet je dat doen met het adres van de klant op het moment dat de factuur werd aangemaakt, niet met het huidige adres dat anders kan zijn. Dus in de factuurlijnen moet je velden hebben om het totaal per lijn en het BTW bedrag zoals berekend op dat moment op te slaan. In de factuurhoofding moet je velden hebben voor alle gegevens die op je factuur afgedrukt staan: naam en adresgegevens van de klant, BTW totalen per tarief, factuurtotaal, BTW totaal, enzovoort. Als je later een factuur opnieuw moet afdrukken moet dit mogelijk zijn met alleen de velden in de factuurtabellen zonder dat je gekoppelde gegevens moet gaan opzoeken in andere tabellen, want die kunnen achteraf veranderd zijn (bv. klant verhuist).
Dit zijn niet echt regels van Office, maar boekhoud regels. Onafhankelijk van het programma dat je gebruikt moet je zorgen dat deze in orde zijn.
 
Het antwoord op je laatste vraag gaf al de oplossing voor het probleem dat Noella aanstipte. Door de prijs gegevens in de keuzelijst te zetten voor je artikelen, kun je de velden in je tabel Factuurregels gewoon gebruiken om ze te vullen vanuit de keuzelijst. De velden vul je dan vanuit de keuzelijst met VBA.

Is er ook een andere oplossing mogelijk buiten VBA, ik ken er helemaal niets van.
 
Je kan het proberen via update en/of append queries.
 
Is er ook een andere oplossing mogelijk buiten VBA, ik ken er helemaal niets van.
Nee, niet als je een degelijk systeem wilt maken. Overigens is de code die je daarvoor nodig hebt echt het simpelste van het simpelste. Stel je hebt in je subformulier voor de FactuurRegels een keuzelijst met artikelen, die we dan even cboArtikel noemen. Je hebt dus, om je facturen 'datumproof' te maken, twee extra velden nodig in de tabel FactuurRegels. In ieder geval bevat je tabel deze velden:
1. FactuurRegelID (Autonummering)
2. FactuurID (verwijzing naar de factuur; hiermee koppel je de artikelen aan de factuur)
3. ArtikelNummer (haal je op met de keuzelijst uit de tabel Artikelen)
4. ArtikelPrijs (komt ook uit de tabel Artikelen, zit in de keuzelijst)
4. BTW (zie punt 4).
5. Aantal (hoeveel artikelen worden er besteld)

Velden voor totalen, al dan niet met en zonder BTW, zijn overbodig (in mijn ogen onzinnig zelfs) want die kun je altijd berekenen in de queries die je verder nog gebruikt. In een database sla je bij voorkeur nooit meer dubbele gegevens op dan noodzakelijk is. In dit geval ziet de query voor de keuzelijst er dan zo uit:
Code:
SELECT ArtikelID, ArtikelNaam, Prijs, BTW FROM tArtikelen Order By ArtikelNaam
Zelf zou ik in die tabel ook nog aangeven of een artikel nog geleverd wordt of niet (met een selectievakje) zodat je de query ook kunt filteren op de actuele artikelen. Het heeft natuurlijk geen zin om artikelen te kiezen die je niet meer levert.

Gaan we naar het subformulier kijken, waar je dus de bovenstaande velden (minimaal) in hebt neergezet. In je subformulier heb je alle tekstvelden dus aan deze tabelvelden gekoppeld. Alleen is het nu de bedoeling dat je de velden [ArtikelPrijs] en [BTW] automatisch vult zodra je een artikel kiest. En dat doe je dus met een stukje VBA dat je triggert vanuit die keuzelijst met invoervak (die we dus cboArtikel hebben genoemd). Dan ziet alle benodigde code er zo uit:

Code:
Private Sub cboArtikel_Click()
     Me.ArtikelPrijs.Value = Me.cboArtikel.Column(2)
     Me.BTW.Value = Me.cboArtikel.Column(3)
End Sub

Om te zien wat er hier gebeurt, pakken we de keuzelijst er nog even bij. Die heeft deze velden: ArtikelID, ArtikelNaam, Prijs, BTW. We hebben dus het derde en vierde veld nodig om de prijs en de BTW te lezen, want de keuzelijst zelf is gekoppeld aan het veld ArtikelID, en het veld ArtikelNaam wordt alleen gebruikt om in de keuzelijst een artikel te kunnen selecteren. Dat wordt verder dus nergens voor gebruikt.
Waarom ik tóch Column(2) en Column(3) gebruik, komt doordat de eigenschap Column begint te tellen bij 0. Het eerste veld is dus niet Column(1), maar Column(0). En als je dan doortelt, kom je dus bij de kolommen 2 en 3 uit.

Maar dat is dus alles wat je nodig hebt om waarden uit een keuzelijst te halen. Vergeet de 'oplossing' van Noella, want dat is echt een hele verkeerde methode :).
 
Eén kleine opmerking: velden met totalen zijn helemaal niet onzinnig, voor het vermijden van afrondingsverschillen en de audit zijn ze nodig. Bedrijfsregels primeren steeds boven database regels. De software is er om het bedrijf te ondersteunen, niet vice versa.
 
Afronden doe je natuurlijk op de juiste plek, in de factuurregels. Dan kloppen je totalen ook altijd. Al moet ik er gelijk bijzeggen dat ik in de dagelijkse praktijk dat soort onzin (op de verkeerde plek afronden) dagelijks tegenkom, dus ik zal wel gekke henkie zijn :). Ik moet nu bijvoorbeeld deze tarieven invoeren:
Code:
 3 dagen 	 16,12 
 2 dagen 	 10,75 
 1 dagen 	 5,37
Ja, zegt EZ dan, dat komt doordat de prijs eigenlijk 5,3733 is, en dan rondt-ie dus naar boven af....
En dat software de bedrijfsregels moet ondersteunen en niet omgekeerd, is leuk in theorie, maar in de praktijk, waar je steeds meer SaaS tegenkomt, vaak een utopie. Al kun je natuurlijk best met een ezel en een zwaard windmolens te lijf gaan.
 
Ik zie het eventjes niet zitten, maar ik wil ook niet opgeven :d.

Het is toch wel helemaal anders dan ik had gedacht, ik had de link met Excel gelegd, maar in Access is het toch wel totaal anders.
 
Een goede raad: voor je verder gaat, maak eerst een goede analyse van wat de applicatie precies moet doen, en ontwerp reeds een paar testen en welke resultaten de app moet opleveren om aan je eisen te voldoen. Enterprise architect van Sparx systems is een goed analyse pakket voor een goede prijs (nog geen 100 EUR) om je analyses te maken https://www.sparxsystems.com/.
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan