Access 2016. Gegroepeerd rapport.

[KPTPTT]

Hallo. Vanwege een succesvolle applicatie willen de gebruikers meer nuttige functies maar met de volgende functie zoek ik met hulp naar een oplossing.
Er is sprake van een Query waarin Werkorders zijn opgenomen en iedere record een klus omvat met een werkordernummer. Iedere werkorder wordt door maximaal 3 verschillende uitvoerders (monteur 1 en/of monteur 2 en/of monteur 3) uitgevoerd. Voor deze Monteursvelden is vanuit een formulier een keuze gemaakt vanuit een andere Monteurstabel met ca. 40 uitvoerders. In de Query zijn hiervoor, naast het veld Werkorders onder andere drie velden Monteur 1, 2 en 3 beschikbaar. In deze velden staan bij iedere record de gekozen monteursnaam uit de Monteurstabel.
Iedere maand willen we de status van uitvoering van het werk controleren door vanuit de Query een rapportage te maken. Ik heb deze rapportage gemaakt en de werkorders bij één bepaalde monteur (1) gegroepeerd (Wizard Rapport, indeling "Overzicht"). Het levert precies het goede resultaat op (koptekst: naam Monteur 1 en daaronder een lijstje met de toebehorende werkorders) maar, dezelfde werkorder kan ook door monteur 2 en/ of monteur 3 worden uitgevoerd. In dat geval wil ik de naam van monteur 2 en monteur 3 in het rapport met daaronder ook de daarbij behorende werkorders. Dit kunnen dus soms dezelfde werkorders zijn die ook al gepresenteerd worden bij bv. monteur 1. Per Naam dus de bijbehorende werkorders.

Voorbeeld Query:
Werkorder 1   Naam Monteur 1                                               Resultaat rapport: Naam Monteur 1               Naam Monteur 2             Naam Monteur 3
Werkorder 2   Naam Monteur 1 -                  Naam Monteur 3                                Werkorder 1                  Werkorder 3                Werkorder 2
Werkorder 3                    Naam Monteur 2 - Naam Monteur 3                                Werkorder 2                  Werkorder 4                Werkorder 3
Werkorder 4   Naam Monteur 1 - Naam Monteur 2 - Naam Monteur 3                                Werkorder 4                  Werkorder 5                Werkorder 4
Werkorder 5                    Naam Monteur 2

Hoe kan ik dit voor elkaar krijgen? Ik vermoed niet via de wizard voor het maken van een rapport maar meer in het op één op andere manier "combineren" van de drie monteursvelden in de Query. Ik benieuwd wie een oplossing heeft. Alvast bedankt.

 

[OctaFish]

Je hebt je tabel waarschijnlijk niet genormaliseerd, en 3 velden gemaakt voor de 3 mogelijke monteurs. En dan kan wat jij wilt niet. Normaliseer je tabel (met dus een koppeling naar een tabel waarin je per order één monteur vastlegt) en het gaat prima.

 

[KPTPTT]

Dank voor je antwoord.
Ik heb inderdaad 3 velden met namen van monteurs in het formulier. Deze 3 monteurs zijn in een tabel Opdrachten met de werkorders opgenomen. De monteurvelden zijn dmv. een koppeltabel met een "veel op veel relatie" gerelateerd aan een aparte tabel met 40 monteurs namen. Ik kan niet volstaan met 1 monteur bij iedere order. Het doel is dat er maximaal 3 monteurs toegewezen worden aan één order. De rapportage bevat dan voor iedere monteur een lijst met werkorders. Kan ik dmv. VBA zelf een dedicated rapport genereren? Hoe zou ik dat moeten doen?

 

[KPTPTT]

Ik heb wat gestoeid met het rapport om de 3 monteursnamen er in te krijgen. Zie het resultaat in bijgevoegd document. Het resultaat zou misschien met filteren en sorteren mbv. VBA tot een bruikbare rapportage kunnen komen. Ik weet alleen niet hoe in VBA. Mogelijke oplossing:

- Met een knop in het navigatievenster, start VBA en openen van het rapport.
- VBA filtert op leeg Monteursveld met bijbehorend werknummer en wist deze regel. (Lege velden worden verwijderd en de regels met een monteursnaam blijven)
- VBA sorteert op dezelfde naam en plaatst de werkorders bij de naam. Dus samenvoegen van iedere voorkomende naam met daarbij de lijst met één of meerdere bijbehorende werknummers.
- VBA het rapport op en toont het resultaat van het rapport.

Hoe zou ik het kunnen realiseren en wat voor code. Alvast dank.Bekijk bijlage Voorbeeld rapport.docx

 

[OctaFish]

Ik snap je niet; je zegt dat je een gekoppelde tabel gebruikt voor de monteurs, maar waarom zie ik dat dan niet terug in je rapport?

 

[KPTPTT]

Ik heb geen idee hoe ik mijn vraagstuk kan oplossen door op één of andere manier de gekoppelde tabel in het rapport te gebruiken. De drie velden in het rapport "tonen" de monteursnamen via de gekoppelde tabel uit de monteurstabel.
Bij iedere werkorder horen (noodzakelijkerwijs) maximaal drie namen en die zijn uiteindelijk gedestilleerd uit de monteurstabel. In het (proef) werkorder formulier staan de drie namen, dat werkt. Ik heb deze drie namen (velden o_Monteur 1, o_Monteur 2 en o_Monteur 3) gebruikt voor het rapport. Wat kan ik anders gebruiken? Hoe los ik het op?

 

[OctaFish]

De drie velden in het rapport "tonen" de monteursnamen via de gekoppelde tabel uit de monteurstabel.

Dat is niet correct gebruik van je monteurs. Als ik het over een gekoppelde tabel heb, dan heb ik het niet over een keuzelijst waarin je de monteurs zoekt, dat is namelijk geen koppeltabel.

... Werkorders zijn opgenomen en iedere record een klus omvat met een werkordernummer. Iedere werkorder wordt door maximaal 3 verschillende uitvoerders (monteur 1 en/of monteur 2 en/of monteur 3) uitgevoerd.

Wat je dus nodig hebt, is een tabel die je aan de tabel Werkorders hangt, laten we zeggen: WO_Monteurs. In die nieuwe tabel staat dan in ieder geval een veld met het WerkOrderID en een veld MonteurID. Op die manier heb je een veel-op-veel tussen Werkorders en Monteurs en een één-op-veel tussen Werkorders en WO_Monteurs en Monteurs en WO_Monteurs.
In een veel-op-veel is er geen limiet aan het aantal monteurs dat je kan koppelen (uiteraard wel een index op WerkOrderID+MonteurID). In het formulier kun je dan bijvoorbeeld een kleine keuzelijst (zonder invoervak) maken waarin je monteurs kiest (gebaseerd op actieve monteurs die nog niet op de Werkorder zitten) en met een druk op de knop koppel je die dan aan de Werkorder (effectief gezien maak je dan 3 records aan in de tabel WO_Monteurs). Met een gebeurtenis op de keuzelijst kun je afdwingen dat je maar 3 monteurs mag kiezen. De tweede keuzelijst maak je groot genoeg om 3 monteurs te laten zien.

Voordeel van deze constructie: als je ooit besluit (of het bedrijf) om met 4 monteurs te gaan werken, dan hoef je alleen de procedure op de keuzelijst aan te passen, alles blijft dan gewoon werken. En je eigenlijke probleem, waarmee je deze topic bent gestart, is als sneeuw voor de zon verdwenen .

 

[KPTPTT]

Ik weet niet wat met het beantwoorden gebeurd. Ik heb inmiddels twee antwoorden gestuurd maar zie dat deze niet zijn geplaatst. Ik heb je antwoord zo goed mogelijk begrepen. Ik heb echter geen problemen met het toevoegen en de keuze van de monteurs maar met de gegroepeerde rapportage. Ik kan de db niet aanpassen, dat is teveel risico in een operationele situatie. Ik moet het doen met wat aan materiaal voorhanden is. Er zijn drie namen en op iedere naam moet in een rapport worden gesorteerd op werknummer. Iedere monteur heeft een groepje werknummers onder zich. Hetzelfde werknummer kan dus maximaal drie keer voorkomen bij de verschillende namen. Hoe kan ik dit realiseren met behulp van VBA?
Ik denk aan het volgende: Met "Dcount" het hele rapport doorlopen, testen op lege velden Monteursnaam 1,2 en 3 en de lege velden niet in het rapport te plaatsen. Daarna met "Dlookup" onderzoeken of er dubbele monteursnamen zijn met hetzelfde werknummer maar er blijft een rapport over waar de monteurs nog niet gegroepeerd zijn. Hoe kan ik het realiseren? (zie bijgevoegd voorbeeld, bijlage 15-10/16:51)

 

[OctaFish]

Soms is het nuttig om even terug naar het begin te gaan.

Vanwege een succesvolle applicatie willen de gebruikers meer nuttige functies

Dan heb je het dus over een (aantal) RFC(s) die soms binnen de bestaande applicatie kunnen worden opgelost (minor upgrade) en soms tot een nieuwe versie leiden.

Ik kan de db niet aanpassen, dat is teveel risico in een operationele situatie.

Aanpassingen doe je natuurlijk nooit gelijk in een productieomgeving, maar altijd in een test of ontwikkel omgeving. Lijkt mij zo logisch dat het niet eens besproken hoeft te worden.
Jouw probleem (waarom wil je dat met VBA oplossen? Zou je niet eerst naar een functionele oplossing kijken?) is vast wel op te lossen, maar het blijft lapwerk. Er is blijkbaar bij het ontwerp niet of te weinig rekening gehouden met toekomstige vragen of ontwikkelingen. Dan komt er een moment dat je moet besluiten (als organisatie) om dat ontwerp eens tegen het licht te houden. Een niet-genormaliseerde database gaat je altijd (vroeger of later) problemen leveren. Die moet je dus ooit een keer tackelen. En nu zijn de gebruikers nog tevreden, dus een prima moment .

 

[KPTPTT]

Misschien valt de hele situatie wel mee als je de constructie en het resultaat van de db zou kunnen zien ook als je mijn werkzame achtergrond zou weten. Ik probeer in dit forum ideeën en richting te zoeken voor een vraagstuk en hoop vanuit de huidige constructie van de db er een oplossing voor het rapport is.

 

[OctaFish]

Ik hou mij (en moet mij houden) aan de informatie die jij ons geeft en dan zie ik een slecht genormaliseerde db met problemen. Zonder db is het sowieso heel lastig om te kijken wat een goede oplossing zou zijn, maar ik ben uiteraard niet gewend en gewoon om slechte oplossingen te bedenken. Liever steek ik energie in oplossingen waar je nu en later wat aan hebt. En als dat inhoudt dat er wat stevige taal moet worden gesproken, dan is dat vervelend (voor jou in dit geval) maar ik vind wel dat ik dat moet doen. Het is dus niet dat ik je niet wil helpen . Maar ik denk (nog steeds): beter nu gekeerd, dan later tegen nog veel grotere problemen aangelopen. En vergis je niet: databases ontwerpen is een vak; dat mag nooit iets zijn dat je er even bij 'moet' doen, omdat de rest net even wat eerder naar achteren is gestapt als jij .

 

[KPTPTT]

Ik begrijp je standpunt. Ik heb je uitleg bij #7 nog eens gelezen en volgens mij komt de constructie van de db overeen met wat je hebt uiteengezet. Ik heb een tabel Opdrachten met alle werkorderinfo, een tabel WO-Monteurs (met MonteurID en WerkorderID, voor de veel op veel relatie) die enerzijds hangt aan de tabel Opdrachten (één op veel) en een tabel Monteurs die anderzijds hangt aan de tabel Wo-Monteurs (één op veel). Exact zoals je beschrijft. Ik heb een keuzelijst in het formulier en koppel een monteur aan de order. De monteursnaam wordt opgeslagen in de tabel Opdrachten in een daartoe bestemd veld.
Ik kan mij niet voorstellen hoe je de rest van je uitleg vorm geeft. Een keuzelijst waarbij drie monteurs zichtbaar zijn. Volgens mij kun je in een keuzelijst steeds kiezen uit één. Komen de drie namen dan in het ene veld in de tabel opdrachten? In de tabel Wo-Monteurs is sprake van 1 record. Misschien voor dat laatste deel van item #7 nog een uitleg wat je bedoelt.

 

[OctaFish]

Ik las je verhaal en dacht inderdaad: *******, hij heeft het prima voor elkaar. En toen las ik deze zin:

De monteursnaam wordt opgeslagen in de tabel Opdrachten in een daartoe bestemd veld.

En dáár ga je dus de teil in. Waarom doe je dat? Je hébt de perfecte constructie gemaakt (tabel Opdrachten met alle werkorderinfo, een tabel WO-Monteurs (met MonteurID en WerkorderID) en dan ga je alsnog de monteurs in de verkeerde tabel opslaan! Je bent er, kortom, bijna: je staat voor het huis met de deur uitnodigend open, en je belt dan bij de buren aan om te vragen waar de entree is .

Mijn idee, zoals ik het zou uitvoeren, is dus heel simpel: op het formulier Werkorders staat een keuzelijst met (gefilterd op WO) beschikbare monteurs. Die keuzelijst hangt aan de tabel Monteurs, je filter baseer je op WO-Monteurs. De keuzelijst heeft dus die twee tabellen als bron. Vervolgens hang je een actie aan een knop (en eventueel een trigger op de keuzelijst als je drie monteurs hebt geselecteerd) die m.b.v. een Toevoegquery de gekozen monteurs toevoegen aan de tabel WO-Monteurs. Die zie je vervolgens terug in een tweede keuzelijst (gekoppeld aan WO-monteurs), zodat je per werkorder kan zien welke monteurs zijn gekozen. Daarmee ondersteun je dus volledig de tabelopzet, waarbij je werkorders hebt, en monteurs in WO-Monteurs.
Eventueel hang je aan de tweede keuzelijst nog een actie om een monteur weer van de werkorder af te halen (te verwijderen dus uit WO-monteurs) als je een monteur wilt vervangen.

Deze opzet leent zich dan prima voor je rapport, want dat baseer je op een Kruistabel waarbij je de kolom Monteur als kolomkop definieert en de Werkorder als Rijkop. En dan ben je een heel eind. Jouw gevraagde output zou ook nog wel kunnen, maar dan moet je met subrapporten gaan werken, en elk subrapport baseren op een andere monteurID. Heb je 40 monteurs, dan krijg je m.i. een waardeloos en onleesbaar overzicht .

 

[KPTPTT]

Dank je wel voor je uitvoerige uiteenzetting. Het zal vast simpel zijn, maar voor mij is dat achteraf als ik het voor elkaar hebt gekregen. Ik begrijp dat ik een keuzelijst moet maken (via Wizard?) op basis van tabel monteurs en monteursnaam. Dan wordt het onduidelijk. Hoe stel ik een filter in op basis van WO-Monteurs zodat er twee tabellen hangen aan het keuzevak. Dat kan niet in de wizard. Ik heb nog wat uitgeprobeerd door de Rijbron aan te passen, er wordt een query geopend maar ook dat is geen succes. Je hebt het ook over een tweede keuzevak. Moeten dat er geen drie zijn? In een keuzelijst kun je maar één monteur kiezen en niet meerdere? Moet ik een toevoegquery maken? In welke tabel worden de vele duizenden gekozen monteursnamen opgeslagen, nu in tabel Opdrachten en straks in WO-Monteurs? Sorry, het zijn veel vragen.

 

[OctaFish]

Je haalt een paar dingen door elkaar, vrees ik. Om te beginnen het verschil tussen een Keuzelijst en een Keuzelijst met invoervak. De laatste kan inderdaad maar één waarde hebben, maar een keuzelijst kan dus in gesteld worden op meerdere waarden. Hij werkt dan wat anders, maar dat maakt voor het proces niet uit.
De eerste keuzelijst is niet-gebonden; die gebruik je alleen om de monteur(s) te kiezen. Dus die stel je in op meerdere waarden. De tweede keuzelijst (ingesteld op een waarde) laat de records zien uit de tabel WO_Monteurs. En dan uiteraard alleen de monteurs die aan het actieve (op het hoofdformulier) project gekoppeld zijn.

De eerste keuzelijst kan je best met de wizard maken; uiteindelijk zie je in eerste instantie alleen de monteurgegevens uit de monteurstabel. Om de lijst te filteren moet je naderhand de tabel WO_Monteurs aan de tabel Monteurs toevoegen, met een Outer Join: hiermee filter je dan de monteurs er uit die al aan de werkorder hangen. Die wil je immers niet nog een keer kunnen toevoegen. Niet noodzakelijk overigens, je kunt die controle ook uitvoeren als je de monteurs gaat toevoegen (met de toevoegmacro).

OK, de helft van de klus is klaar, je hebt een keuzelijst gemaakt waarin je meerdere monteurs kan selecteren. De volgende stap is een knop maken die de gekozen selectie (monteursID en WerkorderID) toevoegt aan de tabel WO_Monteurs. Dat doe je dus met een toevoegquery, of met een Recordset. Maakt niet zoveel uit. Je wilt maximaal 3 monteurs, dus die knop doet die check ook. Of, zoals ik eerder zei, je doet dat via de keuzelijst (zou ik doen).

Dan heb je dus een keuzelijst gebruikt om 3 monteurs te selecteren, en op de knop gedrukt waarmee je de 3 monteurs aan de tabel hebt toegevoegd. Dan wil je die keuzes ook nog zien. En daar komt dan de tweede keuzelijst om de hoek kijken, die dus is gebaseerd op de tabel WO_Monteurs. Die keuzelijst is gefilterd op de WerkorderID, en laat dus de gekozen monteurs zien. Zelf zou ik die tweede keuzelijst dus gebruiken om eventueel monteurs te veranderen, bijvoorbeeld door een klik actie op de keuzelijst die het aangeklikte record weer verwijdert uit de tabel WO_Monteurs. Waardoor je dus weer de gelegenheid hebt om een andere monteur te kiezen.

Maak anders een dummy db waarin je de noodzakelijke tabellen en formulieren zet met wat dummy data, dan kan ik het wel voor je maken als je er niet uitkomt. Dat doe ik waarschijnlijk sneller dan de tijd die ik nou aan het typen ben .