Rapport op basis van criteria

Goede morgen


Dank je wel voor je zeer uitgebreide antwoord.

Zal proberen het te verklaren. De velden 2e kind, betaling vooraf, betaling incasso zijn velden waarmee een korting berekend wordt evenals het veld schoolkorting. En inderdaad maximaal zijn drie kortingen mogelijk, betaling vooraf/incasso, 2e kind en de schoolkorting. Het lijkt er op dat de meeste mensen vooraf willen betalen vanwege de hogere korting dan de korting bij betaling contant.
Ik begrijp uit je woorden, dat de opbouw dus niet goed is. (Als je een idee hebt hoe het anders moet, hoor ik dat graag) Het berekende veld "betalen" werkt wel zoals ik me dat gedacht heb. Heb in een query drie expressies opgenomen met IFF en een veierde die die drie combineert, maar dat zul je wel gezien hebben.


De code die je me aanreikt, kan ik die gebruiken wanneer ik een optie maken om vanuit een keuzelijst (die noem jij consequent cbo?) andere overzichten te laten printen?


Hardstikke bedankt.


PS zag in een ander antwoord dat je met iemand bezig bent om iets te maken, mag ik je daar een prive message voor sturen?

Objecten kun je het beste een vaste beschrijving meegeven in namen. Zo noem ik een tabel meestal tblTabelnaam, of tTabelnaam, een formulier frmFormuliernaam of fFormuliernaam, en op formulieren krijgen tekstvakken het voorvoegsel txt, keuzelijsten als voorvoegsel lst, en keuzelijsten met invoervak cbo etc. De naam is dan doorgaans dezelfde als het veld waar je mee koppelt. Access kan anders namelijk maar moeilijk onderscheid zien tussen het veld Betaling, en de keuzelijst Betaling. Want ze hebben immers nu dezelfde naam. Als jij in een vol voetbalstadion 'Herman, biertje?' roept, krijg je ook meer reacties dan bij 'Herman Pieters, biertje?' Vandaar dat ik het veld [Betaling] koppel aan ofwel een tekstveld txtBetaling, of een keuzelijst met invoervak cboBetaling.
Maak dus altijd onderscheid tussen de verschillende objecten. Zowiezo gebruik ik die voorvoegsels om op basis van de naam ervan bepaalde instellingen te checken.

Back to the Topic... Als je verschillende kortingen hebt, die tegelijkertijd gelden, dan moet je daar uiteraard aparte velden voor gebruiken. Het ging mij om dat onderscheid, wat voor jou helder is maar voor ons natuurlijk niet. Berekende velden in een tabel daar heb ik zelf een gruwelijke hekel aan; gegevens die je kunt berekenen doe je bij voorkeur in een tabel. Enige onderscheid daarin is dan een berekening die afhankelijk is van fluctuerende prijzen, want dat mag natuurlijk niet. Maar zelfs dan zou ik het zelf nog anders oplossen. Maar die keus is aan jou natuurlijk.

Dank je wel voor je uitgebreide toelichting.

Ik dacht dat ik keurig al mijn objecten voorzien had van een voorvoegsel.
tabel tbl
query qry
formulier frm
rapport tbl


Alleen de keuzelijsten niet en die zal ik dus meteen aanpassen.


Begrijp deze zin niet: Berekende velden in een tabel daar heb ik zelf een gruwelijke hekel aan; gegevens die je kunt berekenen doe je bij voorkeur in een tabel.

Een tabel bestaat toch uit velden? Of bedoel je dat ik een query moet maken met daarin de expressies om tot het uiteindelijke te betalen bedrag moet komen.

Je gaf ook aan dat je het zelf anders zou doen, logische vraag natuurlijk hoe dan. Wil graag van een meester leren


Ga nu weer opnieuw bezig met het maken van een keuzelijst om vandaar uit te kunnen printen.

Je hebt geen antwoord gegeven op mijn vraag of ik je een pm mag sturen over een ander project waar je mee bezig bent/was.

Een tabel bestaat uit velden, dat klopt. Een berekend veld is echter geen veld in de ware zin des woords, er zit een berekening achter. En dat alleen al zorgt voor dataredundantie. Als je de Prijs opslaat, en het Kortingspercentage, dan kun je de betaalde prijs namelijk altijd berekenen. Een extra veld daarvoor is dus overbodig. Zoals ik al zei, komt het wel eens voor dat je afhankelijk bent van fluctuerende gegevens. Bijvoorbeeld bij artikelprijzen die nog wel eens verschillen. In een tabel Bestellingen kom je er dan bijna niet omheen om de prijs die op het moment van bestelling actief is op te slaan bij de bestelling. Al helemaal niet als je de prijshistorie niet opslaat. Of, zoals ik in het artikel aangeef, je zoekt de prijs op basis van de datum op in de tabel met Artikelprijzen. Maar dat werkt dus alleen als je een historietabel hebt voor de prijzen. Meestal heb je een tabel Artikelen met daarin een artikelprijs. Verandert de prijs, dan ben je de oude prijs dus kwijt. In een query (of fomulier) wordt dan de nieuwe prijs gebruikt, en niet meer de oude.
In de Access cursus (laatste afleveringen van een paar maanden terug) behandel ik verschillende technieken om met deze materie om te gaan.
Wat je laatste vraag betreft: tuurlijk mag je een mailtje sturen

OK dank je wel voor de uitleg.


De berekening werkt op dit moment zoals ik graag wil. Misschien niet de beste oplossing, maar voor ca 500 cursisten moet het goed gaan


Ga in ieder geval je laatste delen weer opnieuw bestuderen.


Kan je geen PM sturen, want ik ben geen verenigingslid of donateur.

Goeie reden om lid te worden Kun je ook de vorige nieuwsbrieven zien trouwens...

ok zal het overwegen.


Bedankt

Tot die tijd kan je een mailtje sturen

Mail is onderweg.