ACCESS Expressie: Loonkost weergeven per uitvoerder

Status
Niet open voor verdere reacties.

fde

Gebruiker
Lid geworden
31 aug 2017
Berichten
110
Betreft de form frm_uitvoerder_loon_details (=enkelvoudig formulier) met als recordbron tbl_uitvoerder_loon. (lees: loon = salaris)
In deze tabel is [ID_UITVOERDER_LOON] de primaire sleutel ; ook is de [ID_UITVOERDER] uit de tabel tbl_uitvoerder toegevoegd.

In dit formulier frm_uitvoerder_loon_details probeer ik per id de loonkost per periode/jaar te berekenen.

Momenteel kan ik alle loonkost berekenen (tekstveld SQL) per periode:
Code:
=DSum("[UITVOERDER_LOONKOST]";"[tbl_uitvoerder_loon]";"[UITVOERDER_DATUM_VAN] between #2017/01/01#and#2017/12/31#")
.
Met deze code bereken ik alles en niet per ID!

Kan iemand me op weg helpen aub.
 
Je moet er een WHERE bijzetten. Overigens een onhandige filtering op datum. Kan een stuk slimmer en dynamischer.
 
Wat bedoel je met datums dynamischer toepassen?
Het gene wat ik toepas is hetgene wat ik kan vinden. Weet wel wat ik wil , maar ben jammer genoeg geen vba (.net) specialist.
WHERE heb ik geprobeerd (in allerlei mogelijkheden - het gene wat ik erover kon terug vinden) maar waarschijnlijk zal ik de expressie niet juist hebben aangevuld / geïnterpreteerd.
 
Je zegt ID, maar ik vermoed dat je ID_Uitvoerder bedoelt. Dan krijg je zoiets:
Code:
DSum("[UITVOERDER_LOONKOST]";"[tbl_uitvoerder_loon]";"YEAR([UITVOERDER_DATUM_VAN]) = YEAR(Date()) And [ID_Uitvoerder] = " & [ID_Uitvoerder])
 
Deze code werkt perfect als het gaat over 2017.
Doch op het formulier staan 4 loonkostvelden 2015 - 2016 - 2017 - 2018 (deze laatste kan maar pas weergeven na input volgend jaar).
Hoe kan ik de expressie dan het beste aanpassen?
 
Doch op het formulier staan 4 loonkostvelden 2015 - 2016 - 2017 - 2018 (deze laatste kan maar pas weergeven na input volgend jaar).
Huh? Waar komen die 4 velden vandaan? Dat riekt naar een slecht ontworpen database.... Sowieso is filteren op niet-bestaande waarden (2018) natuurlijk volkomen onzinnig, daarnaast is het uiterst onhandig om het zo te doen. Filteren doe ik per definitie altijd op bestaande waarden. Iets anders is dus onzinnig en nutteloos. Die bestaande waarden zet je simpel in een keuzelijst (met invoervak) (SELECT DISTINCT YEAR([UITVOERDER_DATUM_VAN])) zodat de gebruiker het juiste jaar (of jaren) kan selecteren. Vervolgens gebruik je de keuzelijst in de code om op te filteren.
Dan krijg je dus dit:
Code:
DSum("[UITVOERDER_LOONKOST]";"[tbl_uitvoerder_loon]";"YEAR([UITVOERDER_DATUM_VAN]) = " & Me.cboJaarVan & " And [ID_Uitvoerder] = " & Me.ID_Uitvoerder)
Dan ga ik er wel vanuit dat de DSUM vanuit een formulier wordt gemaakt.
 
Huh? Waar komen die 4 velden vandaan? Dat riekt naar een slecht ontworpen database.... .
Laat me eerst enkel constructieve informatie te geven. Sinds 1985 heb ik het geluk (ongeluk) om betrokken te worden bij de implementatie van (middel)grote ERP-pakketten in grote ondernemingen waar ik toen werkzaam was (o.a. Unilever - Shell - NL-Gasmaatschappij - BASF - Total - GSK - Arcelor "om er enkelen op te noemen".) ; dit zowel in stuur- als pilootgroep en nadien bij de functionele analyses. Die grote ERP-pakketten zijn/waren in volgorde toen: DBase IV (Dos), Lotus (Dos & Windows), AS-400(mainframe) en later Remax/Rimses, MS-Dynamics, SAP (Sql7), JD-Edwards (Oracle), Ultimo en Baan IV (Oracle) en daaraan gekoppeld diverse financiële software zoals Expert-M, Exact, Vero en Yuki .
Dus laat me zeggen dat ik zeer goed weet hoe een database ontworpen en geïnterpreteerd dient te worden maar evengoed de tekortkomingen.
Versta me niet verkeerd: Databases & de links onderling dat versta (ken ik) zeer goed! de programmatie onderling; daarin ben ik een totale leek.

Sowieso is filteren op niet-bestaande waarden (2018) natuurlijk volkomen onzinnig, daarnaast is het uiterst onhandig om het zo te doen. Filteren doe ik per definitie altijd op bestaande waarden. Iets anders is dus onzinnig en nutteloos

Mijn betrachting is met zomin mogelijk werk en "her" programmeerwerk te bewerkstellen. Daarom mijn vraag! Trouwens 2018 komt eraan in een week.
Misschien verklaart de print-screen van frm_uitvoerder_loon_details veel. Ik kan alleen maar putten uit m'n vroegere bedrijfservaring in m'n vraagstelling en onze eigen doelstellingen.

Als ik iets geleerd heb uit het verleden van alle "grote pakketten" is dat je meerdere schermen dient te doorlopen alvorens alles is ingevuld - laat staan dat alvorens je historiek te zien krijgt en zulke werkwijze wil ik ten alle tijde vermijden

In onze oude situatie waren dit verschillende Excel's met enkele 10-tallen tabbladen (per uitvoerder) en de daarbij behorende aparte pivot 's voor alles uit te rekenen.

Nu wordt alles op 1 scherm weergegeven (eerste 4 kolommen) als inputmogelijkheid en alle mogelijke berekeningen vanaf de 5de kolom. (Ingave verloning - directe berekening van facturatie en marges)

uitvoerder_loongegevens_marge.PNG
 
Laatst bewerkt:
Dus laat me zeggen dat ik zeer goed weet hoe een database ontworpen en geïnterpreteerd dient te worden. Versta me niet verkeerd: Databases & de links onderling dat versta (ken ik) zeer goed!
Wat iemand weet en kent/kan, kunnen wij op basis van een vraagstelling uiteraard nooit bepalen; wij zijn altijd afhankelijk van de door de TS aangeboden informatie. Het is dan ook nooit mijn bedoeling om tegen schenen te schoppen, ik baseer mij slechts op de aangeboden informatie.

En op basis van die informatie verbaas ik mij over het gebruik van de DSUM functie; ik denk dat je overzichten op basis van kruistabellen prima zouden moeten kunnen werken. Het enige ‘probleem’ is dat een kruistabel dynamisch is en formulieren (qua layout) niet, en je zult dus op een dynamische manier dat formulier moeten vullen en de labels ook. Een probleem dat ik in één van de Access cursussen daarom ook heb behandeld. Maar dat vereist dus wel een geautomatiseerd formulier, want ik zou dat niet via handwerk willen doen.
 
Ik neem je absoluut niets kwalijk hoor, dat meen ik.

Trouwens, ik heb jouw access cursus en de je website volledig doorgenomen Octa, en heb er veel van opgestoken/geleerd en maak er nog steeds gebruik van alsook van de geboden oplossingen die ooit zijn gepost op helpmij.nl.

En ja ik weet het : ik doe veel manueel werk maar net zoals in onze branche (detachering) wijzigt er weinig en kan ik me meer concentreren op maatwerk.
Buiten de opvolging van kandidaten (sollicitanten) - facturen opmaken - opvolging van de uitvoerders (hun persoonlijke problemen, wat is er gefactureerd en wat brengen ze op = marge) gebeurt er weinig. En als ik zaken foutief vraag/bereken heeft dit te maken met te weinig kennis, zeker niet uit onwil.

Ik kan misschien enkele zaken wat meer dynamisch maken, dat kan; daar heb je 100% gelijk in. Maarals leek op 2 à 3 maanden tijd alles in access krijgen maar ook werkende krijgen en je eigen job doen (handige Harry kan en doet alles) is geen sinecure.

Zoals ik reeds eerder zei; ik zal nog meer opletten als ik een vraag verstuur dat deze voldoende is uitgelegd. ( ik weet wel wat in m'n koppie zit - maar het juist uitleggen/vragen is niet simpel).

Groet, Frank
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan