historie bewaren

[richie]

Ik heb een berekening gemaakt voor een aantal lessen die gevolgd zijn door een cursist. Dit is een berekening per maand.

Aan het eind van de maand staat er dan een bedrag, berekend door aantal maandagen of dinsdagen etc vermenigvuldigd door lesprijs.

Tot zover alles goed.

Ik heb dus een eindbedrag, bv 30.

Dit bedrag ga ik incasseren. Ik geef een datum op, bv 29 mei en daarbij is dus het bedrag van 30.

De volgende maand is het eindbedrag anders. Ik ben dus dan de historie kwijt van het eindbedrag van de vorige maand.

Hoe kan ik een historie opbouwen waarbij staat dat ik aan het eind van de maand een bepaald bedrag in rekening heb gebracht.

 

Alvast hartelijk dank.

[AvD]

Door Jean's hulp in te roepen en relationeel te leren werken.

Even geduld, hij komt zo meteen langs.

[JeanWM]

Even kijken wat we allemaal hebben:

 

1 nieuw forumlid: welkom Richie.

 

We nemen een deel van je post door zonder quotes...

 

Ik heb een berekening gemaakt (calculatieveld.01) voor een aantal (nummerveld.01) lessen (tekstveld.01) die gevolgd zijn (datumveld.01) door een cursist (tekstveld.02).

 

Dit is een berekening (calculatieveldveld.01) per maand(calculatedDatumveld.01).

 

Aan het eind van de maand(datumveld.02) staat er dan een bedrag(calculatieveld.02), berekend door aantal maandagen(calculatedDatumveld.02) of dinsdagen etc vermenigvuldigd door lesprijs(nummerveld.02).

 

Ik heb dus een eindbedrag (calculatieveld.02).

 

Dit bedrag (calculatieveld.02) ga ik incasseren (tekstveld.03). Ik geef een datum op (datumveld.03)

 

Nu moeten we weten wat je database zou moeten doen. Is het:

 

1. Het noteren van bedragen die cursisten betalen voor het volgen van bepaalde lessen op bepaalde dagen.

2. Het bijhouden van wanneer bepaalde cursisten bepaalde lessen volgen en die dan in rekening brengen

3. Het bijhouden van dagen dat cursisten lessen volgen en die op maandbasis in rekening brengen

4. ......

5. ......

 

Je moet dus een duidelijk onderscheid zien te maken tussen entity en attribute, zodat je een ERD (entity relationship diagram) kunt opmaken.

Wat zijn de hoofdgegevens (entity) en wat zijn de details (attribute) daarvan.

 

De cursisten (tekstveld.02) zijn entity, hun gegevens (naam, voornaam enz) zijn attributes.

Ik veronderstel dat je die gegevens ook ergens nodig hebt.

 

De cursussen (tekstveld.01) zijn entity, details daarvan (zoals prijs)zijn attributes.

 

Zijn het cursussen die gevolgd worden door cursisten en waarvoor een bedrag wordt aangerekend of zijn het cursisten die cursussen volgen en daarvoor een bepaald bedrag betalen ?

 

Maar we gaan het niet te moeilijk maken.

Probeer gewoon een duidelijk beschrijving te geven van wat de database moet doen.

Iedere gevonden entiteit moet een uniek ID (nummer of tekst) hebben en die (entity) plaats je best afzonderlijk in een table.

 

Neem de help file eens door op gebied van relaties en bepaal of je een 1-many (een cursist kan enkel 1 of meerdere cursussen volgen), want André heeft gelijk, je werkt best relationeel. Dan raak je je history niet kwijt.

 

Kom dan eens terug om je bevindingen te melden.

[richie]

Bedankt voor jullie reacties.

 

Ik denk dat ik een probleem heb, want ik heb alles in één tabel staan.

Ik kan dus geen relaties leggen.

Ik denk dat ik opnieuw moet beginnen en dan eerst verschillende tabellen aan moet maken, toch ?

[JeanWM]

Misschien niet en misschien best wel.

 

Als je herbegint dan begin je best met je computer uit te schakelen en terug te grijpen naar potlood en papier.

 

Een lijstje maken van alle mogelijke entities die je denkt nodig te hebben, met daarnaast een lijstje met alle attributes die je denkt nodig te hebben van elke entity.

 

Noteer daarbij welk type veld het moet zijn (tekst, nummer, datum etc)

 

Dat gaat je de mogelijkheid geven om te zien of je de nodige informatie al in een bepaalde vorm hebt.

 

Je hebt bv een datum voor een bepaalde lesdag.

Je zegt dat je 'op het einde van de maand.....'.

Je hebt dus bv de datum van de laatste dag van een gegeven maand nodig.

Dat wordt dus een datumveld, maar berekend.

Je hebt een totaal van de lesdagen nodig van een gegeven cursist voor een gegeven maand, dat wordt dus een berekeningsveld, waarbij er twee overeenkomsten zijn: het moet dezelfde student zijn en het moet van dezelfde maand zijn.

 

Je ziet dat je 'student' al ergens hebt en je hebt ook al een veldje met de maand. Breng die twee bv samen in studentMaand.

 

Maak een relatie (kan een self-join zijn) op dat veld en je hebt de basis om alles op te tellen waar studentMaand = studentMaand.

 

Eenmaal dát volledig op papier staat begin je pas in FileMaker.

Je entities worden tabellen, de attributes worden velden.

En vermits je op papier hebt staan waar al je gegevens zitten is het niet moeilijk om dat in FileMakerees om te zetten.

 

Moet je nu ergens een aanpassing maken, grijp dan eerst je papier en kijk daar wat de mogelijke invloed van de aanpassing kan zijn op reeds bestaande velden.

 

Moet je een toevoeging doen, kijk eerst op je papier waar je dat het beste doet en waar en of er al mogelijke gegevens zitten.

 

Zit je vast, dan heb je nog altijd dit Touring Forum....

[richie]

Hi Jean,

 

Het is jammer, want al die gegevens heb ik allemaal al. Per maand wordt er berekend hoeveel dagen een persoon les heeft gehad en welke les en wat dat per les kost. Zelfs bij de eerste maand wordt er inschrijfgeld berekend. Wanneer een persoon ziek is worden die dagen eraf gehaald en ga zo maar door.

Wat dat betreft klopt dat allemaal en ben ik zeer trots op wat ik heb gemaakt. Aan het einde van de maand exporteer ik de gegevens ( persoon, banknummer , bedrag) naar excel. Daarvan maak ik een clieop file wat naar de bank gaat.

In de nieuwe maand berekend filemaker opnieuw hoeveel dagen een persoon les heeft gevolgd. Mijn eindbedrag kan dus anders zijn dan de vorige maand, omdat er nu misschien wel 5 dinsdagen waren bv. Dat is allemaal geen probleem, dat heb ik allemaal verwerkt in formules.

Ik zou natuurlijk de history kunnen bekijken van het eindbedrag in de excel files, maar ik zou zo graag zien dat ik dat eindbedrag en de datum van de incasso ergens op kan slaan en terugvinden in filemaker.

[pjotter]

Als je de gegevens al hebt zijn die gewoon te importeren. Wel zul je goed moeten selecteren en dan importeren. Het zal een wel wat tijd kosten maar weg is het nooit. Het is wel een paar keer proberen hoe je wegschrijf en importeer enz enz. (Eventueel met excel als tussen station.) Een tweede mogelijkheid is om nieuw te starten en een apart extra veld maken met de sum gegevens.

15 mei 2008 aangepast door Gast

[JeanWM]

@ Richie

 

Daarom dat ik begon met

Misschien niet en misschien best wel.

 

We kennen de huidige structuur niet van je toepassing, enkel dat het waarschijnlijk een 'flat file'.

 

De oefening op papier blijft gelden.

 

Kijk welke velden je nu hebt, bepaal in welke tabel ze eigenlijk thuishoren en hevel die over naar de nieuw te maken tabel in je huidige toepassing.

Je maakt de relaties en met relatief weinig inspanning is je toepassing relationeel gemaakt.

 

Om je history compleet te maken kun je de gegevens die je in Excel hebt importeren in je nieuw gemaakte tabellen.

14 mei 2008 aangepast door Gast

[pjotter]

JeanWM dat is ook wat ik bedoelde aan te geven met mijn opmerking. Oude history is nooit weg maar wel soms lastig om te importeren ./ aan te passen in de nieuwe toepassing. Ik gebruik hiervoor excel omdat het dan eenvoudig iscomplete gegevens te wissen/ toe te voegen enz.

Mijn opmerking was ook meer een steun in de rug om aan te geven dat history in een database nooit verloren gaat.

Zelf even gekeken naar de voorbeelden en deze spreken voor zich om als startpunt te dienen.

[JeanWM]

Sorry Pjotter dat mijn post een verkeerde indruk gaf.

Het was een reactie op Richie's post.

 

Introductie is aangepast....

[pjotter]

JeanWM, Ik had absoluut niet het idee dat je mij bedoelde was alleen een aanvulling.

[hiker]

Als je je oude exelbestanden nog hebt, importeer die dan in een nieuwe tabel. via een relatie/portaal kun je dan alle oude gegevens bekijken.

Je huidige werkwijze kun je houden, alleen een extra stap importeren komt erbij.

Dat is het meest simpele.

Later kun je in de tweede tabel dan ook berekeningen toevoegen als min/max/gemiddeld/etc.

[AvD]

Je huidige werkwijze kun je houden (...)

Dat is het meest simpele.

 

Verba volent (gelukkig maar), scripta manent.

 

Wat je hier adviseert, Hiker, blijft hier nog lange tijd voor iedereen te lezen. Ik vind dat jammer.

We zijn hier gewoon goede adviezen te geven om FileMaker-gebruikers te helpen databanken op te bouwen volgens de regels van de kunst.

[richie]

Hallo boys,

 

Ik ben blij met iedere opmerking ! Ik leer er zeer veel van.

Ik heb dus inderdaad het advies opgevolgd om een excel bestand weer te importeren.

 

Het gaat nu als volgt:

 

Ik maak een layout in tabelvorm, genaamd betaal lijst.

Gegevens daar van exporteer ik naar excel. Maak daar een clieop file van wat naar de bank gaat.

Vervolgens heb ik 12 verschillende layouts gemaakt, met daaraan gekoppeld 12 verschillende tables.

 

Nu importeer ik in bijvoorbeeld layout betaling mei naar table betaling mei het excel bestand.

En nu heb ik dus de betaal gegevens in een layout staan betaling mei.

 

Zo doe ik dat nu voor elke maand. Wanneer het jaar om is overschrijf ik de gegevens en zo houd ik dus een historie van een jaar.

 

Waarschijnlijk super omslachtig, maar het werkt denk ikwel allemaal.

De eerste testen zijn in ieder geval goed.

Het enige is dat de record nummers niet gelijk lopen. Van layout betaling mei start hij bij record 1 , terwijl ik op een andere layout bijvoorbeeld bij record 25 was, waar ik een button heb geplaats om naar layout betaling mei te gaan.

Is dat ook nog op te lossen ??

[JeanWM]

Ja.

[richie]

Gelukkig Jean,

 

Dat zal de database nog beter maken.

 

Kan je mij ook vertellen hoe ik dat dan moet doen ?

 

Echt allemaal ontzettend bedankt voor jullie medewerking en snelle respons. Top !!

[JeanWM]

Heb ik al gedaan.

 

Door je structuur relationeel op te zetten.

Je gegevens invoeren in de relationele database.

 

Des noods, eventueel, indien het nodig blijkt te zijn, zou je je gegevens in je Excel spreadsheet kunnen importeren in je database. Enkel om je history van gegevens volledig te maken.

 

Ik vind nergens terug waar ik zou gesteld hebben om je gegevens naar Excel te brengen, dan terug te halen en het geheel in FileMaker als opgewaardeerde spreadsheet te gebruiken.

 

Vergeet het exporteren naar Excel. Je kunt alles in FileMaker doen.

Je historische gegevens blijven behouden, niks geen overschrijven.

Heeft je bank je gegevens nodig in Excel vorm, maak je voorbereiding in FileMaker en sla het op als Excel file, vanuit FileMaker. Dat is alles.

 

Maak je FM database relationeel.

 

Of vergeet FileMaker en doe alles in Excel.

[hiker]

Je huidige werkwijze kun je houden (...)

Dat is het meest simpele.

 

Verba volent (gelukkig maar), scripta manent.

 

Wat je hier adviseert, Hiker, blijft hier nog lange tijd voor iedereen te lezen. Ik vind dat jammer.

We zijn hier gewoon goede adviezen te geven om FileMaker-gebruikers te helpen databanken op te bouwen volgens de regels van de kunst.

 

 

Beste AvD,

Ik snap je opmerking gedeeltelijk, alleen het volgende probleem: het forum heeft weinig actieve leden die goede oplossingen kunnen aandragen. De oplossingen zijn dan vaak moeilijk te volgen voor beginners. Dat is ook te zien aan het aantal keer dat er uitleg gevraagd wordt bij dezelfde vraag.

Als met een hele simpele oplossing een beginnende gebruiker geholpen is dan heeft dat mijn voorkeur, ondanks dat dat niet volgens de databaseregels gaat.

Richie heeft een werkende database waarbij hij een uitvoer maakt naar Exel, nodig voor de bank. Dat heeft hij zelf gemaakt. Zijn vraag wordt beantwoord met de oplossing die ik aandraag. Dat het databasetechnisch gezien anders kan is mij bekend. Ik ga er vanuit dat Richie binnenkort zal zien dat hij dezelfde data exporteert en importeert en dat het waarschijnlijk wel eenvoudiger kan. Dan zal hij zelf oplossingen zoeken (of zich hier melden met de vraag). Maar dan denkt hij er wel zelf over na.

 

Ik heb liever een database die ik zelf gemaakt heb, ondanks niet optimale programmering, dan een database met oplossingen van derden waar ik net niets meer van begrijp.

 

Overigens alle lof voor de weinige actieve leden die altijd met creatieve oplossingen komen en dit forum in stand houden.

[richie]

Beste mensen,

 

Klopt Hiker, wat ik nu gemaakt hebt werkt, maar ik vind het ook wel vreemd dat ik de gegevens eerst exporteer naar excel en daarna weer in een ander tabel importeer. Maar ik zou het ook niet anders weten hoe het moet. Een feit is dat dit werkt.

 

Kan iemand mij dan vertellen hoe ik bepaalde gegevens van een layout kan exporteren naar een ander tabel.

 

Nu ben ik blij met deze oplossing en kan ik verder. Dit financiele gedeelte van de database is maar een klein stuk (wel erg belangrijk hoor) van de database.

 

Bedankt voor jullie hulp jongens !!

 

Richie

[JeanWM]

(deep sigh)

 

We weten nog altijd niet wat je database echt moet doen, wat je probeert te bereiken op basis van welke gegevens.

 

Pas dan kunnen we je een structuurvoorbeeld geven.

Het geheel is tot nu toe veel te vaag om iets zinnigs te kunnen zeggen.

 

Het is goed mogelijk dat met een minimum aan veldverplaatsingen je de oplossing al hebt.

[richie]

Goed Jean, (sorry dat je zo van mij moet zuchten)

 

Ik ben bezig om een administratie database op te zetten voor een zwembad. Hierin staan alle kinderen met hun gegevens. De kinderen kiezen voor zwemles op een bepaalde dag en tijd. Er wordt elke dag zwemles gegeven op verschillende tijden en in verschillende niveaus, zoals beginnersbad etc tot aan C diploma.

 

Zover alles goed.

 

De database houdt ook bij hoelang kinderen in een bepaald niveau aan het zwemmen zijn en hoelang ze over een bepaald niveau gedaan hebben (leerlingvolgsysteem). Tot hier ook alles goed. De database kan gegeven oproepen over welke kinderen op een bepaalde tijd zwemmen, welk niveau etc. Prima.

 

Nu het financiele stuk. De database rekent uit dat een kind, die bijv. op dinsdag om 16.00 uur zwemt, 4 zwemlessen heeft gevolgd in de maand mei. Er wordt dus berekend vanaf de eerste dinsdag van de maand naar het eind van de maand toe (de factuurmaand). Ook kan er ingevoerd worden dat een kind een bepaalde periode ziek is geweest en dan worden die lessen niet in rekenig gebracht.

 

In de bepaalde layout (financieel) zijn er dus velden met: lesprijs ; aantal lessen gevolgd ; evt andere kosten zoals inschrijfgeld bv.

Aan het einde van de maand moet er via incasso het totaal bedrag in rekening worden gebracht. In een veld klik ik de incasso datum aan, in dit geval 29 mei 2008.

Ik heb dus gegevens berekend van totaal bedrag en incasso datum.

 

In de maand juni zal er weer een berekening zijn, maar nu zijn dus de gegevens van de maand mei niet meer zichtbaar, want hij maakt een berekening van de factuurmaand (nu dan juni). Wanneer klanten dus vragen hebben over vorige facturen, kan ik dat niet meer terugvinden.

Wel in excel, want ik heb die bepaalde gegevens op 29 mei geexporteerd naar excel, om vanuit daar een clieop bestand te maken van de bank.

Ik moet dan dus met die vraag vande klant naar excel om te zien hoeveel ik geincasseerd heb bij mensen.

Dat wil ik dus niet. Ik wil in filemaker kunnen zien wat de mensen betaald hebben in afgelopen maanden.

 

Ik heb nu dus gedaan wat Hiker zei. De excel gegevens van mei 08, geimporteerd naar een andere tabel in filemaker, zodat de gegevens nu terug te vinden zijn in filemaker. Niet handig, maar ik zou het anders niet weten.

 

Hopelijk maakt het zo wat duidelijker wat ik allemaal aan het vogelen ben.

 

Tips zijn altijd welkom !!

[JeanWM]

Ik kan niet anders dan terug naar mijn eerste post gaan.

Even heel kort en zeker niet volledig, enkel vogelvlucht en snel....

 

Wat zijn je entities ?

 

Zwemlessen

Leerlingen

 

Je hebt dus minstens twee tabellen nodig, eentje voor de gegevens (attributes) van de lessen en eentje voor de gegevens (attributes) van de leerklingen.

 

De leerling attributes zijn niet zo moeilijk (naam, adres, leeftijd etc)

Daar kun je wat berekeningen op los laten zoals de leeftijd bij het inschrijven, de huidige leeftijd, etc)

Dat zijn over het algemeen vaste gegevens die niet zo snel zullen veranderen.

Zorg ervoor dat je minstens een leerlingID veld hebt dat het record uniek maakt.

 

Zwemlessen is een ander verhaal.

Daar schijn je verschillende categories te hebben, (sorry engelstalig toetsenbord – geen deelteken), die op verschillende dagen en uren kunnen plaatsvinden.

 

Je kunt nu verschillende kanten op. We houden het een beetje simpel.

Iedere category beschouwen we als een entity en de dagen en uren beschouwen we als attributes.

 

Zorg dat je voor iedere category zwemles een ID hebt.

 

Dat zijn de records die je aanmaakt.

Je hebt dus ‘beginnersbad’ met een ID, C_diploma met een ID enz.

 

De variabelen zijn de dagen en uren.

Als dezelfde les op dezelfde dagen van de week op hetzelfde uur gegeven wordt heb je weinig problemen.

Daaruit kan iedere maand een lijst gemaakt worden met de datum.

 

Je maakt een lineItem table waar je de leerling linkt met de les.

Dat zou bv kunnen door met twee portalen te werken....

Daaruit produceer je een soort van ‘aanwezigheidslijst’ die kan geprint worden (is altijd handig).

 

De aanwezigheden noteer je per leerling in een ‘aanwezigheidstabel’.

De datums daarvoor heb je al want die komen uit de zwemlestabel.

Die kan bij het begin van iedere maand opgemaakt worden, waarbij default de leerling aanwezig wordt gezet. Je moet dan enkel de afwezigheden bij houden, is minder werk.

 

Via een portaal in de leerling tabel kun je een related lijst genereren van de maandaanwezigheden van de bewuste leerling en dit geeft je de nodige betalingen, met datum enz. Is enkel een andere vorm van een aanwezigheidslijst.

 

Ik weet niet waar je de bedragen denkt bij te houden maar die kunnen vanuit de gekozen plaats ingelezen worden (lookup of auto-enter).

Dat kan gedaan worden door een ID link tussen category in de lestable en lesID in de leerling table.

 

Alle portalen kun je filteren op maand of op jaar, zodat je per leerling kunt zien wie, wanneer, hoelang en voor hoeveel ‘gezwommen’ heeft.

 

Dat klinkt nu allemaal wel vrij ingewikkeld maar is het in feite niet.

 

We willen je op weg helpen, indien nodig met een voorbeeld bestand.

Maar dan hebben we wel iets nodig om mee te werken.

 

Indien er geen onoverkomelijke geheimen in staan kun je eventueel een (lege) copy van je huidig bestand sturen.

Ik vind wel iemand die dat even relationeel voor je gaat maken zodat je een voorbeeld heb om mee te werken. Maar verwacht het niet terug in enkele uren. We zitten midden in de examens hier.

 

Het kan een manier zijn om je enkele technieken en manieren te tonen hoe je een relationele database opzet. Dat ga je niet zo gemakkelijk terugvinden in een helpfile.

 

Het knelpunt, voor zover ik het kan zien nu, is te weten of de lessen steeds op dezelfde dagen van de week en dezelfde uren gegeven worden.

Al het overige is een beetje rondschuiven met velden.