Subfrm / Checklist

Status
Niet open voor verdere reacties.
Thomassoft

Thomassoft

Verenigingslid
Lid geworden
6 jul 2010
Berichten
130
Ik heb een formulier in access met vinkjes (dag, maand, jaar). Ik wil per vinkje (categorie) iedere (dag, maand, jaar) een check kunnen uitvoeren met drie velden (datum, opmerking, persoon). Nu denk ik dat de beste optie is werken met een sub formulier. Alleen heb ik even geen goed idee hoe. Ik wil er juist een overzichtelijk formulier van maken dat je iedere dag of maand een overzicht hebt van de checks die je moet doen en dan kan aanvullen. Iemand een iedee/tip?
 

Bijlagen

  • ISRA FRM.PNG
    ISRA FRM.PNG
    73 KB · Weergaven: 73
Ik heb geen idee wat je nu wilt doen; om te beginnen: denk niet in mogelijke oplossingen, maar vanuit het proces dat je wilt bereiken. De oplossing is dan een logisch gevolg van dat proces. Een opmerking als:
Thomassoft zei:
Nu denk ik dat de beste optie is werken met een sub formulier.
Klik om te vergroten...
Is een voorbeeldje van verkeerd denken. Het kan natuurlijk best zijn dat de uiteindelijke oplossing resulteert in een formulier met een subformulier, maar je moet er dus niet vanuit gaan dat je een subformulier nodig heb, en daar dan de oplossing naar toe praten. :).

Kortom: leg eens uit wat je nu wilt bereiken met die selectievakjes, want ik zie het niet. Is je formulier met die keuzes gebaseerd op een tabel? Zijn er meerdere opties mogelijk per record? Hoe ga je dat overzicht presenteren? Mij lijkt een rapport daarvoor veel handiger dan een formulier bijvoorbeeld, tenzij je de getoonde gegevens daarna wilt gaan bewerken. Dan is een formulier wellicht handiger.
 
Zoals ik het begrijp: je hebt een database met de checks die moeten uitgevoerd worden en de periodiciteit waarmee ze moeten uitgevoerd worden. Je wil een formulier met alle checks die je op een bepaalde dag nog moet uitvoeren.
Je kan dit op veel manieren aanpakken en de aanpak zal grotendeels afhangen van je database structuur

Een mogelijkheid is :
een tabel met daarin de categorieën, bv tblCategorie met catID (autonumber) = PK veld; catOmschrijving (text); catActief(Yes/No); … andere omschrijvende velden
een tabel met de testen bv. tblTest met tstID (autonumber) = PK veld; tstOmschrijving; tstPeriodiciteit (integer);
een tabel met de perioden bv. tblPeriode met perID (autonumber) = PK veld; perOmschrijving(maandelijks, wekelijks, 2-wekelijks, dagelijks, kwartaal, …); perCode (M,W,D,..) ; perAantal (bv. voor een twee wekelijks e periode = 2)
een tabel met Uitgevoerde testen tblTestResultaten met trID (autonumber) = PK veld; trDatumUitgevoerd (datetime); prTest (integer) = FK naar tblTest.tstID; prResultaat (varchar(max)) ; … andere velden

In dat geval schrijf je een query die kijkt naar de datum van vandaag en een lijst geeft van alle testen die nog niet uitgevoerd zijn in de periode waarin de huidige datum valt: alle dagelijkse tests, alle wekelijkse test die nog niet uitgevoerd zijn, … en kan je daar een formulier op baseren.

Met een andere structuur krijg je natuurlijk een andere oplossing.
 
En daarom wacht ik liever op een beter voorbeeld, liefst uiteraard middels een database bestand. Het is zaterdag, dus wél een goede dag om te gaan gokken :D.
 
De structuur van de ISRA tabel heb ik in de bijlage toegevoegd. De overige tabellen voor de checks uitvoering is er nog niet, gezien ik niet goed weet waar te beginnen. De database wordt straks voor meerdere ondernemingen gebruikt. Iedere onderneming begint met een lage backend. Daarbij moet iedere onderneming zijn eigen checklisten kunnen bedenken door het invullen van tblISRA. Er moet een mechanisme komen dan de gebruikers = medewerkers kunnen zien welke checks ze moeten uitvoeren en opmerkingen kunnen maken van wat ze tegenkomen.
 

Bijlagen

  • ISRA TBL.PNG
    ISRA TBL.PNG
    45,4 KB · Weergaven: 66
Je hebt de tabellen(structuur) nog niet, maar bent al wel met de formulieren begonnen? Verkeerde volgorde, als je het mij vraagt. Zorg er eerst voor dat je de complete tabellenstructuur in orde hebt, en ga dan door met de volgende stap: formulieren maken. Formulieren en rapporten zijn in mijn workflow altijd de laatste stap in het bouwproces, en nooit het eerste :).
 
Ergens is het niet slecht om eerst de formulieren te ontwerpen en de rapporten. Zelf gebruik ik daarvoor Enterprise architect. Dat helpt enorm om te zien wat je echt nodig hebt. Daarop kan je dan bekijken welke gegevens je nodig hebt om de formulieren in te maken. Dan normaliseer je die gegevens en kom je tot de tabelstructuur. En daarop kan je dan de echte formulieren/rapporten enten.
Dus an sich een normale, veel gebruikte analyse techniek.
 
NoellaG zei:
Dus an sich een normale, veel gebruikte analyse techniek.
Klik om te vergroten...
Niet bij mij en de ontwerpers die ik persoonlijk ken. Ik maak altijd eerst een Functioneel Ontwerp: hoe lopen de processen, wat wil je uit de de database halen, welke activiteiten moeten binnen de database kunnen worden uitgevoerd. Dat soort vragen. Op basis daarvan bepaal je dan de tabellenstructuur. En dán pas de formulieren. Eerst formulieren maken is doorgaans verspilde tijd, omdat je ze daarna doorgaans tegen veel tijd toch moet aanpassen. Mockup screens zijn prima om een klant te laten zien hoe het [l]uitgewerkte[/i] FO er uit zou kunnen zien. Dat doe je inderdaad niet in Access :).
 
In de analyse faze weet je meestal nog niet met welk programma je gaat werken, dat is één van de dingen die uit de analyse zullen blijken. Access is wel een goed programma om heel snel de analyse schermen uit te werken. Als je daarna met een ander ontwikkelingsprogramma zult werken of met Access, dat maakt niet uit. Je moet toch altijd terug met nieuwe schermen beginnen, dus zie ik geen verspilde tijd.
 
Heren,
De Access Database is een applicatie die we zelf hebben ontwikkelen en waarvoor we updates maken. De applicatie heet ****. We hebben momenteel 22 klanten die hiermee werken. Daarbij hebben we een roadmap met updates. Bij voldoende belangstelling of vraag proberen we functies uit te werken. De applicatie is live met alle klanten. Iedere klant heeft een eigen backend. De klanten hebben het huidige ISRA formulier met achterliggende tabel in gebruik. Echter willen we nu een checklist / controle van de ISRA gaan implementeren. Daarbij hebben we van elke release die we maken een Change en Relase proces met FO en TO.

Dat ter zijde. Hebben jullie tip betreffende mijn optie die ik wil gaan maken?

JB
 
Het wordt er niet duidelijker op, maar dat hoeft wellicht dan ook niet. Een applicatie die al in productie is, is in essentie al wel af, lijkt mij. Dus dan zijn alle opmerkingen over hoe je een db ontwerpt ook een beetje zinloos. Neemt niet weg dat ik nog niet helemaal snap wat je wilt, maar ik heb wel ooit iets gemaakt dat komende overzichten laat zien, en dat lijkt dan wel een beetje op wat jij wilt.

Je moet dus ergens hebben vastgelegd op welke datum de check moet werken. En dat mis ik in je ISRA formulier. Je zult dus ergens een tabel moeten hebben waarin je het Change proces vastlegt. Dan nog snap ik de functie van dat ISRA formulier niet, want wat wil je dan precies zien? Stel dat je alle vinkjes hebt aangeklikt, wat wil je dan als output zien? Een doorlopend formulier met Datum, Opmerking en Persoon, maar dat zegt lijkt mij niet zo bar veel.

Wellicht is het handiger als je een dummy maakt met het gewenste resultaat, want dan kan ik er wat meer chocola van maken.
 
Kan je een voorbeeld geven wat een klant kan invullen in de ISRA tabel en wat dit betekent voor jullie?
 
Goedemorgen,

Ik heb in de bijlage een Dummy database gedaan waarin alleen de ISRA module in staat. De bedoeling is dat een medewerker de ISRA checklisten ontwerpt / samenstelt door het invullen van deze lijst. Weer een andere medewerker moet dus een formulier hebben (met achterliggende tabel) waar hij/zij de checklisten kan uitvoeren op datum en notities erbij kan maken. Daarbij moet hij de checkjlisten zien die hij moet uitvoeren (rekening houdende met wat je aanvinkt in de ISRA).
 

Bijlagen

Da's wel een héél kaal voorbeeldje :). Hier kunnen we niet zoveel mee.
 
Het voorbeeld mist de tabel tblAnnexA. Welke gegevens moeten we ons hier bij voorstellen?
Wat wordt er bedoeld met maatregelen? Kan je een voorbeeld geven van wat hier kan komen te staan?
Idem voor gebruikte checklisten?
Beiden zijn long text velden. Het is toch niet de bedoeling dat daar meerdere maatregelen/checklisten in één veld komen te staan?
 
Dat zeg ik: een héél kaal voorbeeldje :).
 
Sowieso alle tabellen en formulieren die noodzakelijk zijn om het proces te reproduceren. En dus data om te testen. Met één record valt er niets te testen.
 
Zal er vanmiddag een blik op werpen!
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan