Ga naar inhoud
  • 0

relaties met calculaties

Gem

Gevraagd door Gem,

Vraag

Gem

Gem

Geplaatst:
Geplaatst:

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 naar reactie

22 antwoorden op deze vraag

Aanbevolen berichten

  • 0
Gem

Gem

Geplaatst:
  • Auteur
Geplaatst:
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 naar reactie
  • 0
eroos

eroos

Geplaatst:
Geplaatst:

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 naar reactie
  • 0
Gem

Gem

Geplaatst:
  • Auteur
Geplaatst:

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 naar reactie
  • 0
pjotter

pjotter

Geplaatst:
Geplaatst:

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 naar reactie
  • 0
eroos

eroos

Geplaatst:
Geplaatst:

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 naar reactie
  • 0
eroos

eroos

Geplaatst:
Geplaatst:

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 naar reactie
  • 0
Gem

Gem

Geplaatst:
  • Auteur
Geplaatst:

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 naar reactie
  • 0
AvD

AvD

Geplaatst:
Geplaatst: (aangepast)
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: ).

aangepast door Gast
Link naar reactie

Doe mee aan dit gesprek

Je kunt dit nu plaatsen en later registreren. Indien je reeds een account hebt, log dan nu in om het bericht te plaatsen met je account.

Gast
Beantwoord deze vraag...

×   Geplakt als verrijkte tekst.   Plak in plaats daarvan als platte tekst

  Er zijn maximaal 75 emoji toegestaan.

×   Je link werd automatisch ingevoegd.   Tonen als normale link

×   Je vorige inhoud werd hersteld.   Leeg de tekstverwerker

×   Je kunt afbeeldingen niet direct plakken. Upload of voeg afbeeldingen vanaf een URL in

×
Ga naar vragenoverzicht
×
×
  • Nieuwe aanmaken...