Jump to content
  • 0

relaties met calculaties

Gem

Asked by Gem,

Question

Gem

Gem

Posted
Posted

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?

22 answers to this question

Recommended Posts

  • 0
eroos

eroos

Posted
Posted

Twee manieren op dit te doen.

 

1) Calculatie laten opslaan. Via de optie knop in het berekeningsveld.

2) Berekening in een nummerveld definieren.

 

Zie voorbeeld.

 

Portalen om te laten zien dat je hiermee prima relaties kan leggen.

jaar.fp7

  • 0
Gem

Gem

Posted
  • Author
Posted
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.

  • 0
Yves

Yves

Posted
Posted

Een calculatieveld vult zich wel automatisch. Je nummerveld niet... Jouw veld is dus overbodig (of dient te worden gewijzigd in een calculatie).

  • 0
Gem

Gem

Posted
  • Author
Posted

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

  • 0
eroos

eroos

Posted
Posted

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.

  • 0
Gem

Gem

Posted
  • Author
Posted

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

  • 0
pjotter

pjotter

Posted
Posted

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)

  • 0
Gem

Gem

Posted
  • Author
Posted

beste vriende, bedankt voor alle hulp tot hier.

Toch wil ik dit onderwerp nog eens aansnijden met een ander voorbeeld, misschien duidelijker wat ik juist zoek.

 

Om het een beetje gemakkelijker te maken heb ik een voorbeeld bestand geupload.

faktuur-rappels.fp7

  • 0
eroos

eroos

Posted
Posted

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.

  • 0
eroos

eroos

Posted
Posted

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 :)

  • 0
Gem

Gem

Posted
  • Author
Posted

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? :?

  • 0
eroos

eroos

Posted
Posted

Een calculatie kan alleen gebruikt worden in een relatie als deze is opgeslagen en dus geindexeerd kan worden.

 

Kijk maar eens naar de opties van je calculatieveld.

  • 0
AvD

AvD

Posted
Posted (edited)
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
  • 0
andries

andries

Posted
Posted (edited)

Inderdaad, ik bedoel dat je een unstored calculation kan gebruiken om gerelateerde data op te vragen.

 

 

Hoe ik zelf in volgorde zou gaan staan: ik zou vooraan gaan staan, net na u

Edited by Guest

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.

×
Go to question listing
×
×
  • Create New...