Jump to content
  • 0

relaties met calculaties


Gem

Question

Hoi

Euh, hopelijk kan iemand mij een richting aanwijzen.

 

1. Een faktuurlayout = tabel FAKTUUR

2. portaal met inhoud van faktuur ofwel faktuurregels = tabel FAKTUURREGELS

 

Ik wens dat iedere faktuurregel een jaartal krijgt om op die manier later te kunnen sorteren in welk jaar wat verkocht werd...

Dus elke faktuurregel heeft een nummerveld genaamd "boekjaar" met als inhoud een formule Year ( FAKTUUR::FakDatum )

 

Nu blijkt een probleem dat mijn veld "boekjaar" niet automatisch ingevuld wordt. Wanneer ik "boekjaar" verander van nummerveld naar calculatieveld werkt het wel prima, maar dan zit ik met het probleem dat ik geen relatie kan leggen met een calculatie. En het veld "boekjaar" wordt dus gebruikt in een relatie met een tabel "OVERZICHT" om te zien wat wanneer werd verkocht (in een portaal).

 

Ik moet dus mijn veld "boekjaar" als nummer definiëren.

Via een script bij het afsluiten van de faktuur lukt het me enkel om 1 faktuurregel een waarde te geven maar niet alle fakuurregels in eens.

 

Weet iemand raad?

Link to comment

22 answers to this question

Recommended Posts

  • 0
En wat denk je van een extra calculatieveld (numeriek) Year(Fakdatum)?

 

Nu geef je best wat meer uitleg want ik volg je niet. In de tabel FAKTUUR heb ik een datumveld FakDatum, waar ik mijn faktuurdatum manueel invoer. In het portaal FAKTUURREGEL (afzonderlijke tabel) heb ik reeds een nummerveld met formule "Year(FAKTUUR::FakDatum)". Wanneer ik hier nu nog een calculatieveld met dezelfde formule aan toevoeg snap ik niet wat dit voor een verschil maakt. Zoals in mijn eerste topic reeds aangehaald, ik gebruik dit veld als een relatie met een derde tabel en kan dus geen calculatieveld gebruiken, anders was het direkt opgelost.

 

thx.

Link to comment
  • 0

Yves, ik begrijp dit volkomen doch met een calculatieveld krijg ik problems met mijn relaties van een andere tabel.

 

Eroos, uw voorbeeld werkt prima maar na verder onderzoek blijkt dat het toch niet 100% is wat ik zoek, of misschien wel maar ik geraak er niet uit...

 

Voor het gemak heb ik een simulatie gedaan.

jaar[2] Copy.fp7

Link to comment
  • 0

Gem,

 

Ik denk dat je het boekjaar ook niet in de factuurregels moet laten opslaan. Dit hoort thuis op het niveau van de factuur. De factuur heeft een boekjaar. En aan de factuur hangen regels die behoren bij die factuur.

 

Je tabel overzicht is overbodig. Zoals pjotter reeds beschreven heeft. Zijn oplossing voor een overzicht is een voorbeeld en één van de vele mogelijkheden om opsommingen te maken van factuurperiodes.

 

Bestudeer de mogelijkheden van resumevelden maar eens. Daar gaat nog een hele wereld achter schuil.

Link to comment
  • 0

hmm, alles eens bekeken en tja ik heb feitelijk nog niet gewerkt met rapporten. Ik gebruikte steeds portalen omdat de gegevens die gefilterd werden ook nog verder gebruikt werden. Maar als ik een vereenvoudiging kan doorvoeren staan mijn oren spits. Zie eens mijn opbouw van mijn structuur allemaal in één bestand.

 

 

 

Hoe kan ik nu bv uit bovenstaand bestand een rapport opvragen van enkel alle peren uit 1999? Met relaties is dit eenvoudig... En laat de aard van het artikel (peren) en het jaartal (1999) variabel zijn. Hiermee bedoel ik dat ik bv na het opvragen van alle peren uit 1999 ook kan listen op alle appels in 2008 enz....

FMopbouw.thumb.JPG.bccc1884292233abec0794b0c3b09e23.JPG

Link to comment
  • 0

Als je elke dag 200 keer iets moet opzoeken dan kan ik mij voorstellen dat je iets met relaties probeert op te lossen. Voor mij is niet goed duidelijk wat de meerwaarde is om elk moment de hoeveelheid appels te weten uit jaren 1999? Volgens mij is dat jaar inmiddels al voorbij en als je van dat jaar een rapport maak eventueel samen met andere jaren dan is dat toch voldoende voor terug zoeken? Het is jouw keuze maar als ik dan naar het overzicht kijk zie ik alleen al 11 tabellen met fakturen (dus extra relaties van de tabel fakturen) en iets van 7 van nota's? Dat lijkt mij al erg veel maar je zult er wel een reden voor hebben?

Terug naar je vraag van het rapport. Als je bij faktuur regels zoekt op jaar en appels en dan rapport dan heb je precies wat je zoekt. Ook voor andere combinaties kun je dat doen. (eventueel met zoek scripts)

Link to comment
  • 0

Gem,

 

Als je een herinnering aan de klant wenst te verzenden dan zou ik wel een historie willen opbouwen met de "rappels" die ik reeds verzonden hebt, inclusief de facturen en de huidige status daarvan.

 

Ik zou dan ook geen directe relatie leggen tussen facturen en rappels maar via een zoekopdracht de openstaande facturen zoeken en deze importeren in een tabel rappelregels en hier een relatie mee leggen met rappels. Je bouwt dan een historisch bestand op en je kan ook nogeens per factuur aangeven hoeveel rappels ze inmiddels voor die specifieke factuur hebben ontvangen. Een incassobureau wil graag een historie overlegt zien wat er allemaal gedaan is om de klant te bewegen te betalen. In jou huidige opzet is dat niet mogelijk.

 

Daarnaast ga je er vanuit dat de klant altijd ineens zal betalen. Wat als de klant in 2, 3 of 4 keer betaald. Dat kun je niet kwijt in je huidige model. En dus kan je ook bij een rappel niet aangeven wat het nog openstaande bedrag is.

 

Hou het simpel en overdenkt je structuur nog eens.

Link to comment
  • 0

Ja.

 

Je zou bijvoorbeeld een overzicht van openstaande facturen kunnen weergeven op de layout van desbetreffende relatie cq klant (portal) en daar een knop maken die een nieuwe herinnering cq rappel aanmaakt voor deze klant. Onder deze knop maak je dan een script die naar een gerelateerde layout gaat van alle openstaande facturen. Daar maak je dan een import actie op naar rappelregels en deze hang je aan een nieuwe rappel.

 

Je hebt nu in een klap de relatiegegevens voor verzending en je hebt alle facturen met onderwerp, factuurnummer, totaal bedrag en hoeveelste herinnering (hier moet je een veld voor aanmaken).

 

Door nu een tabel te maken met betalingen en deze aan je facturen te hangen kun je ook deelbetalingen opslaan en kun je in de rappel precies aangeven hoeveel er nog openstaat.

 

Het is maar een ideetje :)

Link to comment
  • 0

eroos alles goed zoals je me voorstelt, maar kan je me ook vertellen waarom nu precies mijn voorbeeldje niet werkt indien ik het veld "wanbetaling" als relatie gebruik tussen de tabel "rappel" en "faktuur"? Maw van zodra ik een calculatie gebruik als relatie tussen die twee tabellen werkt mijn relatie niet meer. Hoe komt dat eigenlijk?

 

iemand? :?

Link to comment
  • 0
je kan wel aan de 'rechterkant' van de relatie een unstored calculation gebruiken. Of ben ik mis?

Ja, je bent mis, tenzij je met rechts "links" bedoelt. Aan de linkerkant staat de primary key. Je kan daar zelfs een "global" zetten, zoals dat vroeger heette: iets roept iets anders op, dat "iets anders" moet snel herkenbaar zijn en dus geïndexeerd. De oproeper zelf hoeft natuurlijk niet geïndexeerd te zijn. De namen in je telefoonboek staan alfabetisch. Jij zelf hoeft niet alfabetisch te gaan staan (hoe zou je dat trouwens doen? :wink: ).

Edited by Guest
Link to comment

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...