automatisch aanvullen bij verwijderde gegevens

[denon014]

Je hebt een database met 250 leden zitten en er zijn een paar leden die niet meer lid zijn en die dan ook automatisch uit de database verwijderd worden.

Bij de automatische nummering wordt de verwijderde plaats niet opnieuw ingenomen bij het creëren van een nieuw lid

Hoe kan dit opgelost worden zonder dat de automatische nummering lijkt op een stuk emmental kaas.

[Arnoud]

Persoonlijk zou ik mij er niet druk om maken dat de nummering niet geheel aansluitend is, het gaat er immers om dat elk lid een unieke ID heeft. En trouwens Ementhaler is een uitstekende kaas

 

Als het je echt stoort dan zou je middels een script alleen de data van de record kunnen verwijderen en markeer je dat het record leeg is.

Als je een nieuw lid wilt toevoegen laat je een scriptje eerst checken of er een record leeg is en zo nee dan maak je een nieuwe aan.

Er zijn vast andere oplossingen...

[pjotter]

Ik zit bij onze database met hetzelfde probleem. Er zijn 4 lidsoorten en daarvoor heb ik 4 global fields aangemaakt, daar zet ik elke keer het laatst ingevulde lid nummer. In 2005 begint het nummer met 15.. of 25.. of 35.. of 45.. (in 2006 wordt dit 16 26 enz) Het blijft een "gatenkaas" maar daar heb ik op zich geen probleem mee zoals Arnoud al aangaf. Belangrijker voor ons als vereniging is dat we aan het lidnummer kunnen herkennen wat voor soort lid het is en wanneer hij ongeveer is ingeschreven. (langer als 10 jaar wordt lastig ) Om hoeveel mutaties per jaar gaat het eigenlijk?

[JeanWM]

1. Weet niet in FM 7, maar...

 

2. In FM 6 vraag ik 'missende' nummers op (indien er zijn), haal daar de kleinste waarde uit en die wordt gebruikt in het nieuwe record...

 

3. ..omdat ik mij wel druk dien te maken over 'serials' (wetgeving, geen onverantwoorde 'gaten')..

 

4. Als dat in 6 kan, moet het ook in 7 kunnen

[pjotter]

"missende" nummers zoeken kan ik niet met 6 of 7 waar voer je deze zoek opdracht uit? Probleem blijft echter dan toch nog dat er missende nummers zijn als je meer leden hebt die opzeggen dan er bij komen?

[Arnoud]

Kan wel.

 

Stef heeft hiervoor al eens oplossing gepost.

 

http://www.clarify.net/viewtopic.php?t=644&start=0&postdays=0&postorder=asc&highlight=

[pjotter]

Dat is inderdaad een manier die werkt. Het is wel omslachtig met die extra velden en globals maar via die scripts werkt het perfect. (mooie demo trouwens op die manier). Ik dacht dat JeanWM een bepaald berekening uitvoerde die gewoon in de standaard commando's zat.

Terug naar de vraag van demon014 ik heb bij het aanmaken van een nieuw lid via een script een pauze ingelast waarin ik het lidnummer kan aanpassen aan een van de vrije nummers.

Een punt heeft JeanWM wel wat met: 3. ..omdat ik mij wel druk dien te maken over 'serials' (wetgeving, geen onverantwoorde 'gaten')..

Is op deze manier punt 3 ondervangen als er meer leden opzeggen dan inschrijven?

[JeanWM]

De wetgeving waar ik het over heb is die van de SEP (Secretaría de Educación Pública).

Heb het in eerdere posts al eens over gehad hoe krakkemikkig dat ding in elkaar steekt. Hangt er vanaf tot welk departement je behoort..en als je tot verschillende behoort, hebjetvlagge.... Iedere afdeling wil wel een 'stempel' op 'het syseem' hebben....

 

Het zegt oa dat er wel studenten kunnen 'uitschrijven', maar dat er geen 'gaten' mogen zijn in de opeenvolgende nummergeving.

 

Die moeten eerst 'opgebruikt' worden voor we 'nieuwe' mogen gebruiken.

De echte zin daarvan is ver te zoeken, maar reglement is reglement.

 

Vroeger haalden we de nummers er gewoon uit (records werden naar een historiek file overgeschreven en daarna gedelete in de hoofdfile).

Bij het 'inschrijven' werd eerst een test gedaan naar 'missende nummers' en daar werd dan de kleinste uit genomen (indien er waren) en gebruikt.

Een vergelijkbare techniek als Stef's...

 

Toen kwam er een aanpassing van 'la ley'. We hadden wel een lijst van studenten, maar geen 'verantwoording' van de gaten. Enkel 'student uitgeschreven'. en als je dat niet wil geloven....

 

Was dus niet voldoende meer. Ze willen weten wie, wat wanneer, hoe, waarom etc...

 

Nu zetten we een afhakende student nog steeds in de historiekfile, maar in de hoofdfile wordt het record leeg gemaakt, behalve het nummer en in een veldje wordt het 'waarom' bijgehouden. We moesten dus ook een historiek van het record gaan bijhouden. (We verwijzen via een relatie naar het record in de historiek file, zo hebben we nog een spoor.)

 

Bij een nieuwe inschrijving wordt dus eerst gezocht naar 'lege' records, daar nemen we de kleinste aanwezige waarde (van de nog steeds aanwezige nummers) en dat wordt dan gebruikt voor de nieuwe student, terwijl de 'volledige' lijst géén onverantwoorde gaten vertoond.

Zijn er geen 'lege', dan wordt een nieuw 'serial' aangemaakt.

 

Als er nu meer studenten zouden afhaken dan erbij komen (is gelukkig het geval niet, maar aatvastave), hebben we inderdaad zgn gaten in de lijst, maar er is altijd een aanduiding waarom en we kunnen terugvinden 'wie' en 'wat' enz. door enerzijds de historiek van het record (wordt niet gedelete) en de historiek van de student (in de historiekfile). Dat kan dus voor sommige 'nummers' als historiek aardig oplopen, terwijl anderen nooit veranderen....

Het geheel wordt netjes in een portaal weergegeven.

 

Ons systeem van 'naspeurbaarheid' (eerste vereiste) werkt dus volledig, op niveau van student én op niveau van nummer.

 

Tijdens een uitgevoerde inspectie heeft 'de overheid' een goedkeuring gegeven, het systeem werkt dus....

 

En nu is het wachten naar de volgende vereiste want we schrijven bijna het einde van het school/univ jaar....

[pjotter]

JeanWM, bedankt voor je uitvoerig antwoord. Komt een beetje overeen waar ik mee te maken heb.

De accountant heeft problemen met de ontbrekende gegevens. De oude gegevens worden daarom bewaard in een aparte file maar die nummers kunnen weer worden uitgegeven aan nieuwe leden. Nu is voor de accountant het lid nummer nog het minste probleem. Waar hij de meeste problemen mee heeft is met de nummering van de facturen. Die nummers worden samengesteld uit verschillende velden maar zijn niet opvolgend. Om die reden heb ik dus maar twee nummers op de facturen gemaakt. Het opeenvolgend nummer wat verder verborgen blijft en het "samengestelde" nummer wat op de factuur naar het lid gaat.

 

Voor het lid nummer heb ik trouwens de oplossing van stef er ingezet. Wel lastig als je zo veel vrije nummers hebt ongeveer 500 leden die tot 5000 nummers kunnen krijgen. Mijn oplossing met de de 4 global fields voor de 4 soorten leden werkt op zich nog het snelst.

 

Bij een programma van Pink Roccade blijven alle leden er gewoon in zitten maar worden ze niet actief gezet. De actieve leden zijn zichtbaar de rest niet. Dat is op zich een mooie oplossing alleen wordt de database zo groot na verloop van tijd met veel mutaties per jaar.

[JeanWM]

Een factuurnummer is toch maar een factuurnummer en niets meer....?

 

Los van alle gegevens die je dient te verwerken om tot je factuur te komen....

 

Op welke manier en welke gegevens worden gebruikt voor het opstellen van de factuur, en waar in je database worden ze aangemaakt ?

[pjotter]

Een faktuurnummer wat opvolgend is is ook sluitend te maken.

Waar wij ons nummer uit opbouwen is: waar de faktuur voor wordt gemaakt, het lid nummer, jaartal, en eventueel volgnummer. Een voorbeeld is: HM1233_0502.

Dat is een Hijsmast rekening voor lid 1233 in 2005 en het is de tweede hijsbeweging voor dat lid.Maar je hebt diverse letters vooraf, WH,WW,ZH,ZW,WL,CO,OW enz. Men kon op deze manier dus niet controleren of alle fakturen wel geboekt werden.

De nieuwe nummering van de fakturen loopt gewoon door van 20050001 tot 20059999 maar die wordt dus niet getoond voor de leden wel voor de boekhouder. Op die manier is iedereen tevreden

De fakturen worden gemaakt via een aparte layout in de ledentabel en vandaar wordt de faktuur aangemaakt in een aparte tabel. Vanaf die tabel zal afhankelijk of deze contant is betaald , de faktuur op kostensoort doorgeboekt worden naar kasboek Havenmeester of naar een tab-bestand wat ingelezen kan worden in snelstart ons boekhoud programma.