Jump to content
  • 0

Fakturatieprogramma gevraagd

Mac-Aroni

Asked by Mac-Aroni,

Question

Mac-Aroni

Mac-Aroni

Posted
Posted

Hallo, ben nieuw op dit forum. Mocht deze vraag ongepast zijn, excuses daarvoor; Ik ben dringend op zoek een soort van database die een faktuur kan vormen. De database zou uit drie files moeten bestaan : dwz ten eerste de faktuur, de twee file is een klantenbestand, en een derde file is een produktenbestand. Wie kan me aan zo'n database helpen ? Ben al maanden het net aan het afschuimen, maar vind niks voor een Mac.

Ik beschik over filemaker Pro 8.5. Eenvoudige databases kan ik zelf maken, das geen punt, maar ik kan absoluut geen relaties bouwen. Momenteel heb ik geen vrije tijd om me daarin te verdiepen, hopelijk is er iemand die dit kant en klaar heeft. Ik ben bereid er een vergoeding voor te geven.

Thx

18 answers to this question

Recommended Posts

  • 0
Marlinda

Marlinda

Posted
Posted
Hallo, ben nieuw op dit forum. Mocht deze vraag ongepast zijn, excuses daarvoor; Ik ben dringend op zoek een soort van database die een faktuur kan vormen. De database zou uit drie files moeten bestaan : dwz ten eerste de faktuur, de twee file is een klantenbestand, en een derde file is een produktenbestand. Wie kan me aan zo'n database helpen ? Ben al maanden het net aan het afschuimen, maar vind niks voor een Mac.

Ik beschik over filemaker Pro 8.5. Eenvoudige databases kan ik zelf maken, das geen punt, maar ik kan absoluut geen relaties bouwen. Momenteel heb ik geen vrije tijd om me daarin te verdiepen, hopelijk is er iemand die dit kant en klaar heeft. Ik ben bereid er een vergoeding voor te geven.

Thx

 

Ik heb zo een database klaar. Maar welke velden moeten er in elke file staan. Is toch voor ieder verschillend! Het is wel allemaal onder windows gemaakt, maar dat zou geen probleem mogen geven.

  • 0
clarify9

clarify9

Posted
Posted

Of doorloop even de Filemaker Zelfstudie te vinden in de programma map van Filemaker in de map Nederlandse Extra's.

 

Aan de hand van een voorbeeld (het beruchte reisbureau) leer je binnen 1-2 uur alles over relaties en lukt het vast wel!

 

Suc6

  • 0
Captain Haddock

Captain Haddock

Posted
Posted

Ik wil best wat voor je maken, maar relaties zijn echt niet zo moeilijk hoor.

 

Even heel kort en simpel: je hebt een tabel met cd's en een tabel met cd-titels. De velden uit CDS: cdID, cdtitel, artiest, uitgever, cdnummer. In de tabel TITELS: titel, artiest, lengte, songtekst en... cdID.

 

Met andere woorden: in plaats van bij elke titel de algemene cd-gegevens in te vullen, voer je nu slechts één uniek ID in dat leidt naar de cd.

 

Want de ene keer wil je een overzicht van alle cd's, daarvoor is de tabel cd's voldoende. Maar soms wil je alle titels van één cd op een rijtje, de andere keer alle titels van De Kast, dus alle van hun cd's, maar ook de titels die je op verzamelcd's hebt. En dan liefst op alfabetische volgorde.

 

Daarvoor maak je een relatie tussen CDS::cdID en TITELS::cdID. Je maakt een layout met de velden uit CDS en daaronder een portal met daarin bijvoorbeeld de velden TITELS::artiest, TITELS::titel en TITELS::lengte CDS::cdID met daarin de velden voorkomt . En let op nou komt-ie: als je door je cd's bladert, zie je elke keer een andere cd met de bijbehorende tracks eronder.

 

Met andere woorden: een relatie is een sleutelgaatje in de deur, die je toegang geeft tot een andere kamer. Maar dan moet het sleutelgaatje aan de andere kant wel op precies dezelfde plek zitten. Vandaar: een ID, dat beide records aan elkaar linkt.

 

Als je 't goed instelt (nieuwe records maken toestaan) kun je ook nieuwe tracks invoeren, die automatisch gekoppeld worden aan de cd, zonder dat je dus bij elke track de algemene cd-gegevens hoeft in te voeren.

 

Wil je echter alle tracks van De Kast dan ga je naar je tabel titels en zoek je op De Kast. Wil je weten op welke cd dat nummer staat? Zet je achter de titel een veld met CDS::cdtitel.

 

Jij maakt vier tabellen aan: klanten, producten, facturen en factuurregels. Zorg dat ze allemaal een uniek ID-veld hebben. Elke factuur krijgt een veld klantID, je raadt het al: het nummer van de klant waar de factuur naar toe moet. Boven in de layout dus drie velden: klanten::naam, klanten::adres en klanten::pcwp

 

Je maakt een portal waarin de factuurregels verschijnen; elke regel bestaat uit een productID, een aantal en een prijs. Dat laatste is een calculatie: aantal x producten::stuksprijs.

 

Nou ja, nu ik toch bezig ben kan ik net zo goed een voorbeeldbestandje uploaden. Dit is al niet meer kort te noemen.

 

En kijk eens: per factuur één klant, een aantal factuurregels (die allemaal hetzelfde factuurID hebben) en bij klanten heb je weer een overzicht van alle facturen van die klant (die allemaal hetzelfde klantID hebben).

 

Gesnopen? Mag jij iets bedenken zodat je niet alle artikelnummers uit je

hoofd hoeft te leren. Hint: set field.

facturen.fp7

  • 0
Gido_

Gido_

Posted
Posted

Probleem is hier dat je niet gelijk met lookups hebt gewerkt.

Verander je momenteel een klant- of produktgegeven, dan zal ook je factuur veranderen :!:

 

Je zal dat wel weten, maar ik zeg het maar voor de mensen "who run with it" :wink:

  • 0
Captain Haddock

Captain Haddock

Posted
Posted

Dit bestand was gemaakt als voorbeeld hoe relaties werken he.

 

'k Werk persoonlijk trouwens met zo min mogelijk lookups. Anders krijg je de situatie dat je een fout adres op de factuur verbetert en de klant de volgende keer weer een factuur op z'n oude adres krijgt. En er zijn meer nadelen. Ik blokkeer dan nog liever het veld voor invoer.

 

't Enige waar ik in dit soort toepassingen lookups voor gebruik is de btw, want 't wordt wat lastig als per 1 maart het tarief verandert en je ziet in je jaaroverzicht dat ook met terugwerkende kracht gelden...

  • 0
Rony Rabijns

Rony Rabijns

Posted
Posted
'k Werk persoonlijk trouwens met zo min mogelijk lookups. Anders krijg je de situatie dat je een fout adres op de factuur verbetert en de klant de volgende keer weer een factuur op z'n oude adres krijgt.

 

Ik ben niet akkoord met je stelling.

Je moet proberen te vermijden dat je klantbeheer doet in andere databanken dan die van de klanten. Zoiets heet normalisatie en wordt vaak over het hoofd gezien.

Je mag de gebruiker geen (basis)klantgegevens laten aanpassen in een facturatiebestand.

  • 0
hiker

hiker

Posted
Posted

 

't Enige waar ik in dit soort toepassingen lookups voor gebruik is de btw, want 't wordt wat lastig als per 1 maart het tarief verandert en je ziet in je jaaroverzicht dat ook met terugwerkende kracht gelden...

 

En dat valt weer op te lossen met een berekening: voor 1 maart: dan oude BTW%, na 1 maart: nieuwe BTW%.

  • 0
tackenco

tackenco

Posted
Posted

Mijn stelling is dat je bij het maken van een factuur, zodra deze definitief is, alle gegevens hard in die factuur moet hebben staan. en ook dat je je klanten niet onnodig op kosten moet jagen zodra er iets in de wetgeveing veranderd of dat je bijvoorbeeld ieder jaar het factuurnumme weer op 0 moet komen zetten.

 

Als een factuur nadat je deze verstuurd hebt nog kan veranderen doordat je ergens in je applicatie iets veranderd weet je na een tijdje nooit meer wat je werkelijk verstuurd hebt tenzij je de papieren versie erbij pakt.

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