Database voor facturen te maken

Hallo iedereen

Ik ben bezig met een facturatieprogramma en om het te kunnen afwerken heb ik jullie hulp nodig.

Ik heb mijn tabellen ontworpen en aan de hand daarvan wil ik mijn factuur ontwerpen en per klant kunnen afdrukken.

- Het is de bedoeling dat a.d.h.v. de gekozen nummerplaat de klantgegevens automatisch verschijnen.
- Daarnaast moet ik zelf verschillende artikels kunnen kiezen en toevoegen. De velden prijs excl. BTW, BTW-bedrag en de prijs Incl. BTW moeten automatisch verschijnen nadat
ik het artikel gekozen heb.
- Nadat alle artikels geselecteerd zijn, moet ik een totale prijs kunnen berekenen en een korting kunnen geven.

Ik heb een rapport gemaakt en de nodige velden toegevoegd. Nu zou ik graag willen weten hoe ik de artikels per klant kan selecteren en toevoegen.

Hoe moet ik nu te werk gaan?

Kan ik vanuit een rapport de verschillende artikels en klanten selecteren voor mijn factuur? Ik kan wel keuzelijsten maken in rapporten, maar het werkt niet zoals bij formulieren. Of moet ik eerst een formulier maken en dan pas een rapport om het te kunnen afdrukken?

- Indien ik verschillende records (artikelen) wil kiezen voor mijn factuur, moet ik dan werken met niet-afhankelijke besturingselementen of met subformulieren en –rapporten?
- In Excel kan ik een product kiezen en met de vert. zoekfunctie kan ik automatisch de prijs laten verschijnen, kan dat ook in Ms Access?
- In bijlage kunnen jullie mijn database terugvinden.

Hopelijk was ik duidelijk met mijn uitleg, alvast bedankt voor jullie tips en nog een fijn weekend!



Groeten
Ercan

Erc zei:

Of moet ik eerst een formulier maken en dan pas een rapport om het te kunnen afdrukken?

Klik om te vergroten...

Min of meer de spijker op de kop . Alle vragen zijn simpel op te lossen in Access, maar je moet de technieken uit Excel dus wel vergeten. Ik zal dit weekend naar je voorbeeldje kijken!

Super! Ik kijk uit naar uw antwoord.

Groeten
Ercan

Je voorbeeld bevat nogal wat weinig data en dat is erg lastig om mee te werken. Zorg eerst dat je op zijn minst een paar klanten hebt ingeklopt, en een paar artikelen met prijzen. Nu heb jer er één met een bedrag, en de rest is € 0,-. Dat rekent nogal belabberd...

Dag Ercan, een aantal punten moet je in acht nemen voor facturatie, en dit geldt zowel voor kleine bedrijven als grote:

- de facturen moeten kunnen herafgedrukt worden als het origineel, en dat gebeurt wel vaker dan je denkt. Dus in de factuurtabel moeten de prijzen staan zoals ze op dat moment golden, en alle andere gegevens om de factuur op dat moment af te drukken
- factuurnummering: daar mag geen gat in de nummering zijn dus 1-2-3-4. Als je een factuurnummer mist dan moet je dat aan de audit/BTW/… kunnen uitleggen en staven. Dus voorzie een nummeringstabel. Persoonlijk nummer ik mijn facturen per jaar, dus elk jaar herbegin ik van 1; maar je kan ook kiezen voor doornummeren.
- voorzie ook de mogelijkheid om een credit nota te maken. Als een factuur fout zit, dan moet je die annuleren met een credit nota voor je een nieuwe correcte factuur kan aanmaken

Dus zorg ervoor dat je tabellen dit aankunnen. Pas dan kan je beginnen denken aan de afdrukken. Vergeet ook niet je verkoopsvoorwaarden op de achterkant (of tweede blad voor e-facturen) te vermelden. Dat kan je veel miserie besparen.
succes
Noëlla

NoellaG zei:

- de facturen moeten kunnen herafgedrukt worden als het origineel ... Dus in de factuurtabel moeten de prijzen staan zoals ze op dat moment golden

Klik om te vergroten...

Hoeft niet, zolang een factuur maar reproduceerbaar is. Je kunt het systeem ook zodanig maken dat je altijd de juiste gegevens krijgt als je een factuur nogmaals afdrukt.

NoellaG zei:

- factuurnummering: daar mag geen gat in de nummering zijn dus 1-2-3-4. ... Dus voorzie een nummeringstabel.

Klik om te vergroten...

Hoeft óók niet; als je een functie gebruikt voor je factuurnummers, kun je die gewoon gebruiken voor je facturen. Een aparte tabel is in mijn ogen onzin.

De andere punten zijn wél valide, met name het kunnen crediteren. En denk ook aan deelfacturen, en deelbetalingen. Wellicht komt dat óók voor in jouw omgeving.

Wat míj is opgevallen aan je tabellen, behalve dat er dus nauwelijks data in staat, is dat je geen tabel factuurregels hebt. En die is absoluut nodig om facturen te kunnen maken. Een factuur heeft een aantal vaste gegevens, zoals factuurdatum, klantgegevens etc. en een aantal variabele gegevens op basis van de te factureren artikelen. En die wisselen dus in aantal. Daarvoor gebruik je een aparte tabel die je koppelt aan de tabel facturen (logische link) en aan artikelen.

Meestal gebruiken bedrijven dan een keuzelijst om artikelen te selecteren, en gebruiken ze die keuzelijst om óók de prijzen en BTW uit de artikelen tabel op te halen. Die gegevens staan dan in de keuzelijst, en je zet ze dan in de tabel factuurregels. Op die manier krijg je automatisch per factuur de juiste prijzen op de factuur. Dus het idee dat noella ook memoreerde. Dat het zo niet hoeft, komt doordat je voor je prijzen óók een historie tabel voor je prijzen kan maken, waarin je elke prijswijziging opslaat. Op die manier heb je aan de ene kant de prijsontwikkelingen in je tabel, en aan de andere kant het voordeel dat je op je facturen altijd de correcte prijzen terugziet. Deze constructie is wat lastiger te maken, maar kan dus nuttig zijn in sommige gevallen. Daarnaast heb je nog een vorm die beide methodes combineert. 't Is maar wat je nodig hebt .

Hoe dan ook: je hebt nu al een formulier, én een rapport gemaakt, en dat is in mijn ogen nogal voorbarig (vooral het rapport). Maar éérst de structuur van je database in orde, en ga daarna pas over fomulieren en rapporten nadenken. De kans dat je op dit moment van het ontwerp nog aanpassingen gaat/moet maken in je tabellen is levensgroot. En dat betekent, dat je rapporten en formulieren ook niet meer werken. Kortom: je haalt jezelf allemaal dubbel werk op de hals. Is zonde van je tijd .

Hoeft óók niet; als je een functie gebruikt voor je factuurnummers, kun je die gewoon gebruiken voor je facturen. Een aparte tabel is in mijn ogen onzin.

Klik om te vergroten...

Moet natuurlijk niemand in het prijzenboek of in de artikelen tabel gaan rommelen.

Gefactureerde regels schrijf je altijd 'hard' weg.

@VenA,

correct.
Net zoals de facturen zelf.

Tardis

Ik ben toch zó blij dat mr. T. er is voor de morele support....
Ik heb dus nérgens gezegd dat bij mij de factuurnummers niet hard worden weggeschreven. Ik zeg alleen dat je ze net zo goed met een functie kunt genereren. Natuurlijk worden die nummers in de facturen tabel weggeschreven. Let wel vena: de facturen tabel. Niet de artikelentabel of het prijzenboek...

Ik denk dat er nog veel werk is aan de winkel. Ik zal zoveel mogelijk aanpassingen proberen te brengen in de database, rekening houdend met jullie tips uiteraard. Nadien zal ik de db opnieuw uploaden op de site.

Tip, natuurlijk kan je ook al eens, voor je terug het warme water gaat uitvinden, eens kijken wat er op de markt is
https://www.kashexpert.be/nl/gratis-facturatieprogramma
https://www.e-boekhouden.nl/prijzen/starters

En dan heb je hier nog een site met allemaal voorbeelden van database modellen. Daar zit vast iets tussen dat je als inspiratie kan gebruiken .

NoellaG zei:

Tip, natuurlijk kan je ook al eens, voor je terug het warme water gaat uitvinden, eens kijken wat er op de markt is
https://www.kashexpert.be/nl/gratis-facturatieprogramma
https://www.e-boekhouden.nl/prijzen/starters

Klik om te vergroten...

Beste Noella

Bedankt voor de links die je hebt doorgestuurd. Omdat ik zelf veel bezig ben met Access wil ik de database zelf ontwerpen en ja ik weet dat er nog veel werk aan is.... .

OctaFish zei:

En dan heb je hier nog een site met allemaal voorbeelden van database modellen. Daar zit vast iets tussen dat je als inspiratie kan gebruiken .

Klik om te vergroten...

Bedankt!

Gaat langzaam de goede kant op . Het principe van Facturen --> Factuurregels --> Artikelen heb je nog niet helemaal begrepen denk ik; ik heb dat in bijgaand voorbeeld aangepast. Ook heb ik overtollige velden weggehaald (zoals alle berekende velden; niet gebruiken, nergens voor nodig).
Kijk maar eens of je de verschillen ziet/begrijpt.

Het idee is dus dat je straks een formulier hebt dat de factuurgegevens bevat, waar een functie op staat die automatisch de correcte factuurnummers genereert (gebruik daarvoor een tekstveld als je elk jaar met 1 wilt kunnen beginnen), waar dan een subformulier op staat waarop je de artikelen kiest. Die artikelen komen uit je tabel [tbl_onderdelen], waar je dan ook de prijs mee uitleest. Die sla je op in het veld [Eenheidsprijs]. Daarmee leg je dan de prijs van dat moment vast. Als je in de tabel Onderdelen later de prijs aanpast, heeft dat geen invloed op de oudere facturen.

Ik heb de tabellen ook een logisch voorvoegsel gegeven; het is niet handig om daar nummers voor te gebruiken. Met aanduidingen als "tbl_Facturen" en "qry_Facturen" maak je onderscheid tussen tabellen en queries, en dat zal je later goed kunnen gebruiken. Hou daar dus een vaste structuur voor aan.

Ik heb voorlopig nog geen tijd gehad om verder te werken aan de database, van zodra mijn formulier is aangemaakt, zal ik het terug uploaden. Ik vrees dat het pas tegen volgende week zal zijn.

Groeten
Ercan

Geen probleem natuurlijk. Succes er mee!

OctaFish zei:

Gaat langzaam de goede kant op . Het principe van Facturen --> Factuurregels --> Artikelen heb je nog niet helemaal begrepen denk ik; ik heb dat in bijgaand voorbeeld aangepast. Ook heb ik overtollige velden weggehaald (zoals alle berekende velden; niet gebruiken, nergens voor nodig).
Kijk maar eens of je de verschillen ziet/begrijpt.

Klik om te vergroten...

Beste Octafish

U had gezegd om geen berekende velden te gebruiken, hoe maak ik dan mijn berekeningen voor de factuur? In een query?

In het voorbeeld heb ik dus een formulier gemaakt met tabel klanten en een subformulier met tabel onderdelen.

Ik wil dus voor een bepaalde klant een factuur maken, moet ik een query maken om mijn klanten te kunnen selecteren met een keuzelijst?

Bij het subformulier moet ik de onderdelen kunnen kiezen a.d.h.v. een keuzelijst en de prijs van het artikel moet ook samen met andere velden automatisch verschijnen. Hoe krijg ik dit voor elkaar?
Waarom verschijnt er bij elke klant een record in mijn subformulier.

Waar loopt het mis?

Alvast bedankt voor jullie hulp en tips!

Groeten
Ercan

Ik zal morgen even naar je db kijken, maar een aantal antwoorden kan ik al geven.

Vraag 1: Ja. Berekeningen maak je in een query.
Vraag 2: Hoeft niet, je kunt ook een tabel onder de keuzelijst hangen. Maar vaak is een query beter.
Vraag 3: waarschijnlijk is je subformulier niet goed gekoppeld. Prijzen zet je in de artikelen keuzelijst, en laat je vanuit die keuzelijst in je tabel zetten.