MANPOWER: Jaarrooster voor Arbeiders met opdrachten in ACCESS

  • Onderwerp starter Onderwerp starter Dados
  • Startdatum Startdatum
Status
Niet open voor verdere reacties.

Dados

Gebruiker
Lid geworden
5 feb 2015
Berichten
7
Dag Allen,

We gebruiken op dit moment een excel als manpower voor onze groepje arbeiders. We zouden deze graag willen maken in Access om te automatiseren en te vereenvoudigen.
Ik ben op dit moment aan het zoeken hoe ik een combinatie kan maken van Naam_arbeider als records en Datum als field. Zodat ik taken kan invoeren onder datum en Naam_arbeider.

Is er hier iemand die iets gelijkaardig heeft gemaakt? Of me hierbij helpen om deze te realiseren. Heb gebruik gemaakt van CrossTable, maar in deze kunnen er geen invoeringen gemaakt worden.

Alvast bedankt,
 
Allereerst welkom bij HelpMij! Ik snap vrees ik niet heel veel van je vraag, anders dan dat je iets wilt automatiseren :).
Blijkbaar heb je al een database gemaakt, want anders zou je geen kruistabel hebben. Want in een kruistabel kun je inderdaad (en ook logisch) geen data invoeren. Dat kan overigens in een draaitabel (ander naampje, zelfde ding) in Excel ook niet. Maar ook dat wist je ongetwijfeld al.

Wellicht handig als je de database er even bij doet, zodat we kunnen zien wat de bedoeling is. Overigens mag je dat natuurlijk ook met tekst doen.

Zoals ik het nu begrijp: je hebt een tabel Arbeiders (Medewerkers klinkt vriendelijker, 'arbeiders' is wel erg Russisch :) ) en een tabel met registraties. Ik vermoed dat dit werkuren/projecten zijn, maar dat kan ik niet uit je verhaal halen. Maar wat wil je bereiken met
Ik ben op dit moment aan het zoeken hoe ik een combinatie kan maken van Naam_arbeider als records en Datum als field. Zodat ik taken kan invoeren onder datum en Naam_arbeider.
?
 
Octafish, bedankt voor je snelle reactie.

We hebben op dit moment een excel file zoals foto hieronder. Ik zou dit ook in een Access willen doen om te beveiligen en om later workload te berekenen.Manpower voorbeeld.jpg

Had graag mijn voorlopige access bestand willen uploaden, maar lukt niet.


Octafish, alvast bedankt voor uw tijd en hulp!
 
Een database mag je niet zonder meer uploaden, want de database extensies worden geblokkeerd. Je zult er dus in ieder geval een zipje van moeten maken. Als de zip te groot is, dan kun je de db nog een keer Comprimeren en Herstellen; dat doet wonderen voor de grootte. Daarna is de zip vermoedelijk wel klein genoeg (<=200kb). Eventueel kun je met WinRar nog deelbestanden maken van 200kb. Die kun je dan ook wel uploaden als dat er tenminste maar een paar zijn.
Laatste alternatief (hoef je al de bovenstaande stappen ook niet te doen) is om de db op een fileshare als wikisend.com te zetten.

Je plaatje is overigens niet overdreven ingewikkeld, en moet makkelijk te maken zijn in Access. Kwestie van een Personen tabel, en een werklijst tabel waarin je een datum invoert en een categorie. Die tabel Werklijst bevat dan in ieder geval het PersoonID zodat je de twee tabellen kunt koppelen, en je kunt dan een formulier maken op basis van de werklijst waarin je m.b.v. een keuzelijst met invoervak de personen kiest.
Het overzicht dat je in je plaatje laat zien kun je dan weer makkelijk genereren met een draaitabel.
 
Nou, daar was ik snel uit :). Het probleem dat je nu wellicht nog niet hebt, maar absoluut gaat krijgen, is dat deze structuur heel slecht is. Want wat ga je straks doen als je voor Februari wilt invoeren? En Maart? Allemaal aparte tabellen maken? Dat is niet zoals je een database moet opzetten. Eigenlijk heb ik de opzet al in bericht #4 aangegeven, en die zou ik dus eerst maken. Je moet echt met één tabel gaan werken voor de gegevens, bijvoorbeeld tWerkschema, waarin dan de volgende velden zitten:

WerklijstID (sleutelveld), MedewerkerID, Datum, Activiteit en eventueel nog meer velden.
Ik vermoed (op basis van je Excel lijst) dat een medewerker maar één activiteit doet per dag, en dat zou inhouden dat je een uniek index moet maken voor de velden [MedewerkerID] en [Datum] om te voorkomen dat je 2 of meer records voor één medewerker op één dag maakt, want dat mag dan dus niet.
 
Octafish, bedankt voor je tijd. Ik ben ondertussen veel verder geholpen. Grote dank!
HOpelijk tot later nog eens;)
 
Octafish, probleem blijft natuurlijk zoals in een kuistabel, dat je de cellen niet kunt wijzigen. Dat je voor een wijziging naar tabel/query moet om deze uit te voeren. Dat was dan ook reden dat ik tabellen had met datumfields en daarin mijn taken. voorlopig zit ik opnieuw vast. Heb ondertussen tblWerknemers(WerknemersID, WerknemersNaamVoornaam, Ploeg) + tblWerklijst(ActiviteitID, Datum, WerknemersID(relatie met tblWerknemers).

Bedankt,
 
Octafish, probleem blijft natuurlijk zoals in een kuistabel, dat je de cellen niet kunt wijzigen. Dat je voor een wijziging naar tabel/query moet om deze uit te voeren.
Ik zie 2 denkfouten in jouw denkwijze. Grootste fout is natuurlijk: gebruikers hebben niets (maar dan ook helemaal niets) in tabellen te zoeken. Gegevens muteren/toevoegen/verwijderen doe je vanuit formulieren waarin je alle rechten etc. netjes kunt regelen, en alle benodigde automatiek kunt inbouwen. Tabellen zijn slechts (voor zover je van 'slechts' kunt spreken natuurlijk) het fundament van je database. En net als dat je bij een goed gebouwde woning nooit naar het fundament hoeft te kijken, doe je dat bij een database ook niet. Is het gebouw slecht gebouwd, ja, dan werp je eens een blik op het fundament. En dat doe je ook bij een database: deugt die niet, dan moet je in de tabel werken.
Formulieren dus, en nooit tabellen!

Tweede denkfout: waarom zou je in een kruistabel-achtig rooster willen werken? Verlaagt dat het aantal handelingen? Nauwelijjks. Verbetert dat de functionaliteit? Integendeel: die ligt gelijk op de schroothoop! Je bent met een database bezig, niet met een spreadsheet! In de opzet die je had, is elke mogelijkheid om zinvolle rapportages vakkundig de nek omgedraaid. Genormaliseerd werken, wat je doet in mijn opzet, is vele malen beter dan in zo'n Excel blad. Het is ook een stukje gewenning denk ik, maar je moet echt proberen te denken in gegevensverwerking en niet in fraaie, doch onbruikbare schema's :).
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan