Jump to content
  • 0

een relatie met een rééks van data


Frank ter Braak

Question

Posted

Ik wil een huurcontracten oproepen in een calender op elke datum van de duur tussen de start- en eind datum.

Nu kun je wel zoeken naar een reeks met "datum1...datum2"

Maar hoe leg je een relatie tot zo'n reeks.

 

Ik doe het nu met een text calculatie veld:

("datum" is de startdatum)

If(einddatum = "";DateToText(datum);

DateToText(If(datum <= einddatum;datum;"")) & "¶" &

DateToText(If(datum + 1 <= einddatum;datum + 1;"")) & "¶" &

DateToText(If(datum + 2 <= einddatum;datum + 2;"")) & "¶" &

DateToText(If(datum + 3 <= einddatum;datum + 3;"")) & "¶" &

DateToText(If(datum + 4 <= einddatum;datum + 4;"")) & "¶" &

DateToText(If(datum + 5 <= einddatum;datum + 5;"")) & "¶" &

DateToText(If(datum + 6 <= einddatum;datum + 6;"")) & "¶" &

DateToText(If(datum + 7 <= einddatum;datum + 7;"")) & "¶" &

DateToText(If(datum + 8 <= einddatum;datum + 8;"")) & "¶" &

DateToText(If(datum + 9 <= einddatum;datum + 9;"")) & "¶" &

enz.

enz.

 

Om de calculatie niet te lang te maken heb ik deze lijst tot 31 dagen doorgevoerd.

Zou je niet een kortere calculatie kunnen maken die niet gebonden is aan de duur van een huurcontract dus ook als je iets (een ligfiets in mijn geval) bv. een jaar verhuurd?

 

Kennen jullie overigens files/templates die voor huurreserveringen geschikt zijn? Files die je overzicht geven van lopende resrveringen en ook controleren op dubbele boekingen.

 

Frank

17 answers to this question

Recommended Posts

  • 0
Posted

Als het niet om datums ging zou je het multiple keys-principe kunnen gebruiken, maar met datums werkt dat dus niet. Bovendien vrees ik dat het succes van de ligfietsen langere periodes veroorzaakt.

 

Je werkt daarom beter met een eigen kalender waarbij je aan elke dag een unieke ID toekent. Dan zijn multiple keys wel mogelijk. Ik vermoed en hoop dat je daar morgen antwoord op krijgt van een specialist.

  • 0
Posted

Wat bedoel je met:

het multiple keys-principe

Wat ik omschrijf is dat niet een multiple Key? Want ondanks zijn beperkingen werkt dat toch wel.

Zijn dat div waardes gescheiden door een return zodat ze afzonderlijk als Key gebruikt kunnen worden?

 

en wat bedoel je met:

een eigen kalender met voor elke dag een unieke ID

Bedoel je dat er voor elke dag van het jaar een record aangemaakt wordt en dat je aan die dagelijkse records de div afspraken of huurcontracten hangt via een relatie met het unieke record ID?

Mijn kalender genereerd pas records als er daadwerkelijk afspraken gemaakt worden. En toont alle mogelijke data alleen via ingewikkelde scripts en calculatie's

 

Frank

  • 0
Posted

Ik volg AvD hierin...... kunnen wij anders ? :wink:

 

In mijn vorig leven (voor de jongens van de eerste confituursessie, ja het is zover, we worden nu via een 'andere' instantie betaald) zat ik met een soortgelijk probleem. De oplossing lag in de lijn die AvD opgeeft.

 

De multi-key weg loont soms wel de moeite om meer uitgediept te worden.

Het ligt niet altijd voor de hand om zo de oplossing 'te zien', dat wel.

 

Hetzelfde geldt voor wat Peter ooit zei, de look-up functie geeft soms de 'uitwijkmogelijkheid' om tot een oplossing te komen.

 

De binnenwegen geven een beter zicht op de mogelijkheden van een land dan de snelwegen.... :lol:

  • 0
Posted

Dit is één van mijn stokpaardjes...

Ik heb een ingenieus reserveringssysteem ontwikkeld voor verhuur van appartementen aan de kust, misschien een beetje vergelijkbaar.

 

Ik ben ook begonnen met jouw denkwijze, maar ben snel overgeschakeld naar een andere manier.

Bij ons heeft elk goed heeft een veld "beschikbaarheid" (text) dat een reeks van 0-en en 1-en bevat (vrij of niet vrij). Er zijn ook nog andere codes (opties, eigenaar, onderhoud,...), maar die laten we even terzijde.

 

Dit veld wordt grafisch vertaald met blokjes die ofwel groen of rood gekleurd zijn.

 

Deze string wordt beïnvloed en geraadpleegd door calculaties met patterncount en middle-funties om een reservatie te plaatsen of om te onderzoeken of een goed al dan niet beschikbaar is.

 

Laat nu uw verbeelding voor zich spreken...

 

HTH,

Stef

  • 0
Posted
... een veld "beschikbaarheid" (text) dat een reeks van 0-en en 1-en bevat (vrij of niet vrij).

 

Dit veld wordt grafisch vertaald met blokjes die ofwel groen of rood gekleurd zijn.

 

Laat nu uw verbeelding voor zich spreken...

 

Ik laat mijn verbeelding spreken en vraag mij dan het volgende af:

 

Stel je boekt per dag en max 2 jaar van te voren, dan heb je een textveld met 2x365 positie's die vrij (0) of bezet (1) zijn. Dat snap ik denk ik maar hoe vertaal je al deze (?) positie's in gekleurde blokjes? Dat zou ik graag willen leren!

 

Een andere punt: de tijd verstrijkt. Zou je elke dag al deze tekstvelden moeten updaten zodat ze weer beginnen met vandaag? Of doe je dat één keer per week of maand. Ik zou me niet twee positie's wensen maar vier met ieder een eigen kleur. Namelijk: vrij/optie/bezet/vandaag (of vandaag én ouder).

 

Zou je (van je stokpaardje) nog iets meer tipjes willen oplichten of is het meer een hint om je in te huren om het echt goed te doen? :wink:

 

PS het engelse artikel over Smart Ranges is interessant maar voor mij nog iets te ingewikkeld. Als ik er een dag aan besteed dan snap ik het denk ik maar misschien kom ik er dan ook achter dat het niet helemaal is wat ik zoek.

 

Een mogelijkheid die ik wel snap en zou kunnen maken is om het keyveld met de data te vullen via een script met een loop. En die kan twee keer loopen voor een boeking van een weekend en 365 keer loopen voor de huur van een jaar.

 

Frank ter Braak

  • 0
Posted

Stel je boekt per dag en max 2 jaar van te voren, dan heb je een textveld met 2x365 positie's die vrij (0) of bezet (1) zijn. Dat snap ik denk ik maar hoe vertaal je al deze (?) positie's in gekleurde blokjes? Dat zou ik graag willen leren!

 

Een tekstveld kan tot 64000 karakters bevatten. Tel zelf maar uit hoeveel jaren je hierin krijgt verwerkt...

Je moet natuurlijk een beginpunt aanmaken, en dit kan met een script bijgewerkt worden.

 

HTH,

Stef

  • 0
Posted
Ik wil een huurcontracten oproepen in een calender op elke datum van de duur tussen de start- en eind datum.

Nu kun je wel zoeken naar een reeks met "datum1...datum2"

Maar hoe leg je een relatie tot zo'n reeks.

 

Windows of Mac?

het is namelijk op allebei te doen met een paar extra files, maar het is pokketraag door de loops-in-loops die je dan nodig hebt om je reserveringen te beheren. over een netwerk is het dan helemaal om zeep.

Tenzij je op een mac werkt; want dan kan applescript als snelheidsduiveltje ingezet worden :twisted:

  • 0
Posted

Ik gebruik het in een netwerk maar gelukkig wel met Mac's (OSX).

Je maakt me nieuwsgierig hoe je dit met AppleScript doet en hoe je dit zonder zou doen ook trouwens.

Waarom zou dit met AppleScrip zoveel sneller zijn.

 

Ik hang aan uw lippen

 

frank

  • 0
Posted
Ik hang aan uw lippen

frank

 

nou, nou, zeer vereerd

allereerst dit : ik vermoed dat het probleem dat ik heb opgelost een stukje complexer is dan het jouwe : het ging om een systeem voor huurcontracten van vakantieverblijven, en dus in de toeristische sfeer waar huurprijzen variabel zijn naargelang het seizoen, de prijspolitiek van de verhuurder en natuurlijk van de uitrustingsgraad van het verblijf. de bedoeling was niet zozeer de planning te visualiseren, dan wel de huurprijs automatisch te berekenen bij de opmaak van een huurcontract. Visualisatie wordt dan een zijdelings akkefietje.

Om dat te doen zat ik zowieso in de situatie dat alle dagen moesten opgenomen worden in een calender-achtig bestand (1 record voor iedere denkbare combinatie van dag-verblijf) waarin de huurprijzen werden uitgezet, ongeacht of ze verhuurd werden of niet. Om dat overzichtelijk te houden voor de gebruikers moest ik vanuit portalen (en dus relaties) werken die uitzicht gaven op records die periodes bevatten, maw records met een van-veld en een tot-veld. achterliggend werd dan dat calender-achtig bestand volledig scriptmatig beheerd dmv knoppen in de portaalrijen. Op die scripts kom ik later terug.

Met wat verbeeldingskracht kan je dit aanpassen in de richting van een planningsoverzicht waar je inderdaad een hoop "nutteloze" records moet gaan creeeren en beheren voor die dagen dat je niets verhuurt. Nu wil ik geen discussie opstarten over de zin en onzin van die "lege" records, maar ik vind dat persoonlijk wel meevallen om twee redenen : -1- de gebruiker merkt er niets van, aangezien hij/zij alleen maar overzichtelijke periodes voor de neus krijgt; en -2- de dag-records bestaan al, het volstaat dus ze op te zoeken en het beschikbaar/verhuurd-veld te switchen.

Als je geen al te domme dingen doet hoef je ook niet in te zitten met performantie : ter vergelijking : ik heb ongeveer 1500 logementen over een slordige anderhalf jaar in dat systeem zitten : dat is grosomodo 800 000 à 1 miljoen records (zo weinig mogelijk en alleen numerieke velden).

Nu, over die scripts : je kan je wel inbeelden dat je een behoorlijke stapel loops moet gebruiken, nogal wat globals en een paar zeer ambachtelijke find-opdrachten. Als je dus met dergelijke scripts 1 periode-record moet gaan "expanderen" naar 2 maand ofte 62 dagen, maar met hetzelfde gemak 2 jaar ofte 730 dagen, dan is filemaker een eindje bezig (een periode van 6 maanden kostte een slordige 24 seconds op mijn pmac 200, altijd eens testen op een oud machien, nietwaar) Om dat op te lossen heb ik eigenlijk krek hetzelfde geimplementeerd in applescript, dat tot mijn grote ontsteltenis wel erg SQL-achtige trekjes begon te vertonen. Maar het werkte, dezelfde test deed het in meer dan 1, minder dan 2 seconds en kwam in de buurt van 2 seconds om 2 jaar te expanderen.

Op het einde van de rit was het niet alleen een factor 15 à 60 sneller, er waren ook minder scripts doordat je de command-flow niet voorturend van script-in-bestand-x naar script-in-bestand-y moet doorgeven, er waren geen globals nodig, aangezien je de variabelen die je nodig hebt gewoon in de AS-code declareert.

En dan om af te sluiten :

Waarom zou dit met AppleScrip zoveel sneller zijn.

Hey, dit is geen AppleScript-forum :wink:

http://bbs.appescript.net/

Omdat je met AppleEvents eigenlijk op de ruggengraat van FileMaker zit, daar waar de scripting-commando's op een hoger niveau in de interpretatie zit. in het nederlands : FileMaker heeft meer werk om een Sciptmaker-commando uit te voeren dan een een AppleScript-commando.

 

happy scripting!

  • 0
Posted

Met onze methode is er slechts één extra databank : de verhuurperiodes (start- en stopdatum, prijs)

 

De beschikbaarheid zit in één veld bij de goederen (zoals bovenaan beschreven).

Wij doen nog niet eens een zoekopdracht (laat staan loops), alles wordt bepaald door relaties.

Het enige is wel dat de niet beschikbare goederen ook worden getoond onderaan in de lijst, maar dat is juist wat de klant vroeg.

Opzoeken is een kwestie van milliseconden.

 

Ter illustratie enkele schermen:

 

Beschikbaarheid:

http://www.willcom.be/demo/pandperiode.jpg

 

Resultaat zoekopdracht:

http://www.willcom.be/demo/opzoekresultaat.jpg

 

HTH,

Stef

  • 0
Posted

Yep,

 

met de prentjes erbij zie ik al beter wat je bedoelt.

grappig eigenlijk, we hebben gelijkaardige applicaties ontwikkeld op totaal verschillende manieren, hoewel dat hier, me dunkt, ook wel aan de wensen van de klant lag.

ik heb de indruk dat ik eigenlijk niet op de originele vraag heb geantwoord.

En eerlijk, ik zou het probleem zoals het bij jou uitgezet is, lang niet zo stijlvol hebben opgelost.

Vraagje : doe jij ook de prijsberekening ? en zo ja, hoe krijg je dat dan voor elkaar ?

  • 0
Posted

Hey Charlie,

 

De prijsberekening heb ik aan de hand van de wensen van verschillende klanten soft-coded ontworpen. Jij weet evengoed dat dit vrij complex kan zijn. De prijsberekening wordt als het ware door een prijsberekeningsfile "getrokken" en ingevuld als de opgevraagde periodes afwijken van de standaardperiodes, een beetje complex om dat hier uit de doeken te doen.

 

Vraagje: werk jij voor één kantoor of meerdere? Waar ben je gevestigd? Misschien kunnen we eens afspreken.

 

MVG,

Stef

  • 0
Posted

Ik gebruik nog steeds een techniek die stamt uit de fp3 periode.(er bestond toen denkelijk nog geen plug-in daarvoor !!??)

Het is (was) voor het opvolgen van de bezetting van hot cells.

 

De laatste ingave per record (uur einde) maakt deel uit van een script en er moet dus in het veld geklikt worden voor waardeingave. Met de 'visibility' techniek komt een knop te voorschijn voor het verder laten lopen van de script.

 

In een 'Store_date' bestand wordt een (script)check gedaan of de periode reeds bestaat (samenvoeging van verschillende velden). Wordt er een 'dubbel' gevonden, kan de bewerking niet doorgaan. Geen dubbel = creatie van records tussen begin en einddatum.

 

Het verwijderen van een record in het hoofdbestand, geeft ook het verwijderen in het 'Store_date' bestand van de gerelateerde records.

 

Ondanks het uiteindelijk grote aantal records, geeft de controle geen noemenswaardige vertraging.

  • 0
Posted

Ik wil iedereen bedanken voor het mee- en vooruitdenken. Ik werde even stil van jullie reactie's.

 

Al met al heb ik met mijn gemiddelede vaardigheid iets bedacht en in enkele testfiles uitgeprobeerd. Het werk voor mijn situatie goed en snel, ik ga het gauw in mijn systeen implementeren.

 

Ik zal het proberen te omschrijven.

 

fietsen bestand met o.a. ± 50 huurfietsen

afspraken bestand: per afspraak gekoppeld aan één klant en meerdere afspraak regels (afspraakregel bestand)

Tevens een Calenderbestand (op basis van de CC Calender) om overzicht te krijgen over o.a. de afspraakregels.

 

In het afsprakenbestand kies ik een start en eind datum (via tussenkomst van het Calenderbestand) een script vult vervolgens het "gewenste data" veld met alle tussenliggende data. In de huurfietsbestand heeft elke huurfiets ook een "reserveringen" veld met alle data van de reseveringen van deze fiets.

Een relatie tussen de gewenste huur data en de reeds gereserveerde data van de huurfietsen toont juist alle fietsen die tussen de gewenste start en eind datum al minstens één keer gereserveerd en dus niet vrij zijn. Ik had dus eigenlijk een negatieve relatie (bestaat zoiets al?) die juist de wel beschikbare fietsen toont.

Dat heb ik opgelost met een textveld "beschikbaar" in de huurfiets record die middels een calculatie een veld met een 1 (relatie niet valide = vrij) of een 0 (relatie wel valide = niet vrij) vult.

 

In het afsprakenbestand heb ik een togle veld dat ik met een radio button op 1 of 0 kan zetten. De relatie tussen deze twee "1/0" velden toont dan netjes of de beschikbare óf de reeds bezette fietsen.

 

Helaas werkt een relatie met een calculatie veld niet zodat ik het "beschikbaar" textveld in het huurfietsen bestand via een vervang met calculatie moet updaten tov de "gewenste data" in het afspraken bestand hetgeen snelgenoeg is met ± 50 huurfietsen.

 

Het "beschikbaar" veld wordt gevuld middels een calculatie die kijkt naar de relatie met het "gewenste data" veld in het afspraken bestand dus dat "gewenste data" veld mag weer geen globaal veld zijn, anders werk die relatie niet. Nu vervang ik in alle record de "gewenste data" met vervang & calculatie om overal de data te krijgen van het actieve afspraak record.

Dit laatste vind ik echter niet elegant, het lijkt mij te traag worden als er op den duur heel veel records in het afspraken bestand staan. Hebben jullie tips om dit eenvoudig te omzeilen. (kan ik de "gewenste data" in een one_record_file zetten? bedenk ik me nu :idea: )

 

Ik kijk via het calender bestand naar alle afspraakregels middels een relatie met een veld waar alle data van die huurperiode staan. zo word een afspraakregel keurig bij alle geldige data in een maand overzicht weergegeven. Alle dagen van de maand toont een eigen portaal met de afspraken van die dag.

 

Ik wil nog aan elke huurfiets een eigen kleur meegeven zodat ze in dit overzicht hekenbaar zijn. Ook wil ik deze "dag portalen" laten sorteren op het aantal dagen dat een afspraakregel omvat. Op die manier komen alle lange huurperiodes bovenaan te staan en zullen ze (meestal?) netjes naast elkaar staan en door de kleur een doorlopende balk suggereren. (dit laatste wel bedacht maar nog niet getest. Als dit lukt ziet het er bijna net zo mooi en overzichtelijk uit als bv iCal op OSX en kan ik ook iCal door een filemaker Calender vervangen.

 

Groet, Frank ter Braak

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...