Eerst keuze artikel daarna keuze leverancier

[gangstalaz]

Hallo,

Ik heb een database met een hoofd en een subformulier. In het hoofdformulier staan de leveranciersgegevens en in het subformulier de artikelen met de prijzen e.d..
Deze zijn aan elkaar gekoppeld, dus wanneer er een leverancier gekozen wordt, krijg ik alleen de artikelen van die leverancier te zien in het subformulier. Dit heb ik en wil ik ook nog steeds behouden.

Ik had een soortgelijk vraag al eerder gesteld maar deze is toch wat anders.

Nu zou ik graag de volgende willen:

Ik wil nu dat de medewerkers van het bedrijf ALLE artikelen van alle leveranciers kunnen zien, voordat ze een leverancier keuze maken (zie bijlage , deze is wel een printscreen van een ander database waar ik geen bestellingen kan plaatsen).
Als ik dat nu wil doen, krijk ik de volgende foutmelding:

Ik heb dit nodig voor een optimale keuze uit leveranciers (prijs/ kwaliteit verhouding).
Dat moet echt kunnen gebeuren. Ik kan wel een ander formulier (keuzelijst) maken waar ze eerst kunnen zoeken naar artikelen/ leverancier en daarna teruggaan naar het huidige formulier om te bestellen. Maar het is dan echt een omweg voor de medewerkers van hier. Zij willen een zo simpel mogelijke database. Zonder andere formulieren e.d..
En als het op deze manier zou werken, kunnen ze ook eerst een artikel kiezen (leverancier is de in de achterste kolom te zien) en kunnen ze daarna in het hoofdformulier op die leverancier klikken (voor leveranciers informatie).

Dus wat ik ook graag zou willen is dat ze alle artikelen/leveranciers/prijzen etc (hele keuzelijst) kunnen zien/selecteren en daarna in het hoofdformulier die leverancier zoeken/kiezen.

Ik hoop dat het mogelijk is. Want anders is het niet volgens verwachtingen.

Alvast bedankt!

 

[OctaFish]

Uit het feit dat niemand zijn vingers heeft willen branden aan deze topic, kun je al een beetje afleiden dat dit geen oplossing is die we propageren. En ik doe dat dus ook niet. Het principe van een centrale bestelling maken, en vervolgens artikelen bestellen bij de geselecteerde leverancier is dermate ingeburgerd, en werkbaar, dat elke variatie hierop sterk afgeraden moet worden. Uit de oorspronkelijke opzet van de db heb je zelf ook al kunnen zien (en anders heb ik hopelijk voldoende aangetoond) dat de gewenste opzet niet werkt, en allerlei problemen in de hand werkt. Deze werkwijze moet je de opdrachtgever dan ook ten zeerste afraden.

Het is in beginsel zo, dat nieuwe software in eerste instantie als uitgangspunt moet hebben dat de huidige werkprocedures zoveel mogelijk in de nieuwe software moeten worden gewaarborgd om de werkprocessen binnen het bedrijf zo min mogelijk te verstoren, maar als die werkwijze zo overduidelijk niet werkt, dan moet je er niet aan beginnen. Het is dan jouw taak om de opdrachtgever duidelijk te maken dat deze wens niet gebouwd zou moeten worden. In plaats daarvan moet je een alternatief aanbieden, die wèl een goede werking van de database oplevert. En dat is dus dat je éérst een leverancier opzoekt, en vervolgens op basis van die leverancier een bestelling maakt. Elke andere oplossing is ridicuul, en moet je niet willen maken/leveren.

Voor mij zou dit een punt zijn om met zo'n project te staken, als de opdrachtgever daarmee niet akkoord gaat. De vraag voor een zo simpel mogelijke database is met deze insteek gewoon niet te maken, en je moet in dit geval de stabiliteit van de database de prioriteit geven boven het 'zogenaamde' gebruiksgemak voor de gebruikers. Je snapt, dat ik je voor deze vraag dus geen oplossing ga geven, want het druist tegen al mijn ontwikkelprincipes in...

 

[gangstalaz]

Bedankt voor je uitgebreide informatie Octafish!

Ik zal het dan op een ander manier moeten proberen.