[MS Access] van offerte automatisch een factuur genereren

[Verwijderd]

Ik zit met een Access probleem voor redelijk gevorderden Access goeroe's (denk ik op dit moment).

De situatie is als volgt:
Ik heb een database met vrijwel allemaal "standaard" tabellen,
artikelen
klant
offerte
offerteregel
factuur
factuurregel

Nu heeft mijn opdrachtgever de wens dat een offerte met een druk op de knop omgezet kan worden naar een factuur. Ik dacht dat dit geen probleem zou zijn, insert query zou volstaan dacht ik.

Dit is idd het geval bij de omzetting van de offertegegevens naar de factuurgegevens (dus voor de tabellen offerte en factuur).

Het probleem zit em echter in de offerteregels. Om offerteregels te koppelen aan een bepaalde offerte is het veld offertenr opgenomen voor elke offerte regel. Dit moet dus ook gebeuren voor factuurregels.

In een en dezelfde macro wil ik nu dus eigenlijk de factuurkop wegschrijven (op dat moment wordt de factuur aangemaakt en wordt er een factuurnr gecreerd). Dit factuurnr moet vervolgens teruggegeven worden en in de volgende insert query (voor de factuurregels) weer gebruikt worden. Ik heb al van alles geprobeerd maar het wil niet lukken.

Kan iemand mij hierbij helpen of heeft iemand ooit iets vergelijkbaars gemaakt? Op welke wijze heb je dan dit probleem opgelost. Een compleet andere oplossing mag ook.

[Verwijderd]

Wij gebruiken een andere tabelstructuur, wellicht dat deze voor jouw ook werkt.

Order (orderID en factuurID)
OrderRegel (orderID)
Factuur (factuurID)

Op het moment dat je een factuur maakt gebruik je de gegevens van de order in en ken je een factuurID toe.

Een bepaalde order en factuur horen toch bij elkaar, en door bovenstaande structuur hoef je geen gegevens dubbel op te slaan. voor de belasting is alleen de factuur van belang.

Als je orderregels van de offerte en factuur verschillen dan zit er ook iets niet goed lijkt mij.

Mocht je opdrachtgever de oude order meerdere malen gebruiken dan kun je een functionaliteit inbouwen om een order te kopieëren.

[ Voor 9% gewijzigd door Verwijderd op 16-06-2004 18:57 ]

[Verwijderd]

Ik snap wat je bedoeld. Maar als ik deze wijziging in dit stadium moet gaan doorvoeren dan haal ik me veel werk op de hals.

Deze eis is namelijk achteraf gekomen. Alle rapporten en formulieren zijn al gereed. Deze moeten dan ook allemaal aangepast worden.

[Boss]

Als (bijna) alle offertes facturen worden, moet je naturlijk niet eens een factuur tabel aanmaken. Lijkt me dat je dan veel te veel gegevens dubbel opslaat, en da's nooit de bedoeling he!
Maargoed, dat heb je dus al gedaan.

Er vanuit gaande dat je factuurnummer veld een auto increment veld is? Voeg de factuurkop toe, en haal daarna met de functie DMAX() het hoogste factuurnummer uit de tabel. Dat gebruik je vervolgens bij de insert van de regels.

Eventueel kan je alles ook met VBA doen, heb je er iets meer controle over dan als alles met queries gaat.
Overigens kan deze methode een probleem geven als je geen autonummering gebruijkt, en als er twee mensen tegelijkertijd een factuur maken van een offerte.

[Brothar]

Maar ... een offerte is géén factuur. Dus opslaan van dezelfde gegevens gebeurt niet.
Een order, met iojn orderregels, geeft aan wat besteld is.
Een factuur, die je kúnt koppelen aan een order, om te kunnen zien wat (oorspronkelijk) besteld is, bevat met zijn factuurregels de goederen die afgenomen zijn.
Je houdt zo m.i. rekening met "credit-facturen" (ik bedoel dus: retouren).
Een retour betekent dan een "negatieve" factuurregel.
De tabel factuurregels bevat dus én een factuurnummer én een ordernummer waar dat artikel oorspronkelijk op heeft gestaan.
Dit kan dan gebruikt worden om bijvoorbeeld eens per week per afnemer 1 factuur voor meerdere orders te draaien.
(Zo zou ik het proberen te maken vanuit je gegeven database-structuur, en van de nood een deugd te maken)

[ Voor 10% gewijzigd door Brothar op 16-06-2004 21:10 ]

[Boss]

Veel gegevens zullen wel dubbel zijn: bezorg adres, factuur adres, aantal, prijs, besteldatum, intern contactpersoon, etc. Toch best nog wat data!

Per regel zou je dan een veld kunnen maken of hij van offerte naar factuurstatus moet of niet...

[djluc]

Maar ... een offerte is géén factuur. Dus opslaan van dezelfde gegevens gebeurt niet.

Je kunt het ook zo zien: een factuur is een bevestigde offerte.

[Brothar]

Klopt djluc, alleen beschrijft een order een situatie die nog niet definitief is, en een factuur beschrift dan wel een definitieve situatie.

't Gaat dan ook in wezen om het verschil tussen "sein" en "sollen" (althans, zo zie ík het ... maar wie ben ik..).
Op de order staat dan het adres waar beoogd wordt te leveren, op de factuur het adres waar ís afgeleverd;
zo ook v.w.b. wat geleverd gaat worden resp. wat is afgenomen.

[ Voor 36% gewijzigd door Brothar op 16-06-2004 21:29 ]

[Verwijderd]

Brothar schreef op 16 juni 2004 @ 21:26:
Op de order staat dan het adres waar beoogd wordt te leveren, op de factuur het adres waar ís afgeleverd;
zo ook v.w.b. wat geleverd gaat worden resp. wat is afgenomen.

Dat klopt ook niet hoor, het factuuradres is in veel gevallen afwijken van het verzendadres.

Op mijn werk hebben we orders die een status kunnen hebben:
- Order
- Offerte
- Pakbon
- Factuur

De hoofdgegevens staan allemaal in de tabel Orders opgeslagen, deze kunnen dan één van bovenstaande statussen hebben. Als het een factuur betrefd dan is er een factuurID ingevuld.

In de tabel factuur hoef je dan alleen nog het factuurnummer op te slaan (eventueel betalingen maar dat is weer afhankelijk van de rest van je model).

Maar goed het databasemodel van de topicstarter kan niet meer veranderd worden.

Macro's gebruiken wij niet dus ik zou je niet kunnen zeggen of het daarmee kan, maar ik denk dat je met 'Modules' en Vba een heel eind kunt komen. Hier zou je je wat in moeten verdiepen, want het gaat mij te ver om dat te schrijven / uit te leggen.

Overigens kan deze methode een probleem geven als je geen autonummering gebruijkt, en als er twee mensen tegelijkertijd een factuur maken van een offerte.

Dat moet geen problemen geven als je gebruik maakt van transactions, dit moet volgens mij ook prima te doen zijn met vba.

[Verwijderd]

Boss schreef op 16 juni 2004 @ 20:58:
Als (bijna) alle offertes facturen worden, moet je naturlijk niet eens een factuur tabel aanmaken. Lijkt me dat je dan veel te veel gegevens dubbel opslaat, en da's nooit de bedoeling he!
Maargoed, dat heb je dus al gedaan.

Er vanuit gaande dat je factuurnummer veld een auto increment veld is? Voeg de factuurkop toe, en haal daarna met de functie DMAX() het hoogste factuurnummer uit de tabel. Dat gebruik je vervolgens bij de insert van de regels.

Eventueel kan je alles ook met VBA doen, heb je er iets meer controle over dan als alles met queries gaat.
Overigens kan deze methode een probleem geven als je geen autonummering gebruijkt, en als er twee mensen tegelijkertijd een factuur maken van een offerte.

Bij een schatting van de opdrachtgever vertelde hij dat waarschijnlijk ongeveer de helft van de offertes een factuur wordt. Dus dat valt op zich mee.
Factuurnr is idd een autonummering. Ik had zoiets al geprobeerd met de functie max, maar dat werkte niet. Kun je misschien aangeven op welke wijze ik deze functie moet gaan toepassen? Want daar gaat het nu fout volgens mij.
Mijn kennis over VBA is (nu nog) te beperkt om zoiets in VBA te realiseren. Het systeem is maar voor een persoon toegankelijk dus ik heb niet te maken met multiuser.

Boss schreef op 16 juni 2004 @ 21:15:
Veel gegevens zullen wel dubbel zijn: bezorg adres, factuur adres, aantal, prijs, besteldatum, intern contactpersoon, etc. Toch best nog wat data!

Per regel zou je dan een veld kunnen maken of hij van offerte naar factuurstatus moet of niet...

Naar mijn idee leg je het grootste deel van de genoemde gegevens vast in de klantentabel. Deze gegevens worden dus zowiezo niet dubbel opgeslagen.
Verder zou dit een optie kunnen zijn als ik al niet zover was geweest.

Verwijderd schreef op 16 juni 2004 @ 21:53:
...
Macro's gebruiken wij niet dus ik zou je niet kunnen zeggen of het daarmee kan, maar ik denk dat je met 'Modules' en Vba een heel eind kunt komen. Hier zou je je wat in moeten verdiepen, want het gaat mij te ver om dat te schrijven / uit te leggen.

Ik zal me er eens in gaan verdiepen.

[Brothar]

wat ik dus (onder andere) bedoelde, is dat een factuurregel wel degelijk een verwijzing naar de orderregel kan bevatten.
Het voordeel is dan dat je je databasestructuur minimaal aanpast - toevoeging van het veld orderregel# in de tabel factuurregels - en dan wél een insert-query kunt gebruiken (tenzij er een Access-addertje onder het gras zit).
N.B. je kunt je databasestructuur nog wél aanpassen zolang het gaat om toevoegen van velden.
Genormaliseerd kán opname van een orderregel# in een factuurregel "redundantie zijn", maar het maakt je het werk makkelijker.
NB. Je factuurregel én je "credit-factuurregel" kunnen dan verwijzen naar dezelfde orderregel !
Factuurregel bevatten dan alleen verwijzingen (als je tenminste wijziging van een orderregel onmogelijk maakt als er een factuurregel voor die orderregel bestaat)

[Verwijderd]

Blijf je in die situatie dan niet zitten met het probleem dat een factuurregel, die aangemaakt wordt door de offerteregel geen koppeling ligt met de factuur. Want dat is het basisprobleem als je het mij vraagt.

Een factuur MOET ook aangemaakt kunnen worden zonder dat er een offerte aan vooraf is gegaan, dit als extra info.

[Boss]

Naar mijn idee leg je het grootste deel van de genoemde gegevens vast in de klantentabel. Deze gegevens worden dus zowiezo niet dubbel opgeslagen.
Verder zou dit een optie kunnen zijn als ik al niet zover was geweest.

Dat dacht ik voeger ook... totdat mensen ineens gingen verhuizen! Sindsdien maak ik bij facturen en dergeljke een kopie van naam/adres zoals het op dat moment is.
Natuurlijk hou ik via een ID veld nog wel de relatie met de klant vast.


Wat snap je niet aan de DMAX() functie? Let bij gebruik op de "" die goed moeten staan!
DMAX("tabelnaam", "kolomnaam") (of andersom, weet ik nu even niet meer).

Een factuur MOET ook aangemaakt kunnen worden zonder dat er een offerte aan vooraf is gegaan, dit als extra info.

Dat is dus een offerte die meteen de factuur status krijgt, in 'mijn' model...

[Verwijderd]

Ik denk dat het vooral de locatie is waar ik die query wil uit laten voeren.

Ik heb een macro gemaakt waarbij eerst met een toevoeg query de factuurkop wordt aangemaat. Vervolgens wil ik met behulp van een tweede toevoegquery de offerteregels kopieren. De waarde voor het factuurnr waaraan deze regels gekoppeld moeten worden moet dus bepaald worden door die dmax functie.

De waarde van de DMax moet dus ingevuld worden als waarde voor het factuurnr in de tabelfactuurregels. Ik weet uberhaupt niet of dit mogelijk is of dat er een stap tussen moet komen...

[Boss]

I die query kan je ipv een veldnaam ook een functie meegeven.

Dan krijg je iets van: Factuurnummer: DMAX("nummer";"tabel")

(let op dat je ; moet gebruiken ipv , in functies in queries).

[Verwijderd]

Boss schreef op 17 juni 2004 @ 12:20:
I die query kan je ipv een veldnaam ook een functie meegeven.

Dan krijg je iets van: Factuurnummer: DMAX("nummer";"tabel")

(let op dat je ; moet gebruiken ipv , in functies in queries).

Dat was het dus, ik heb die DMax functie constant gebruikt op de wijze zoals ie beschreven stond in de help (daar werd ook nog gebruik gemaakt van [ en ]). Hierdoor kreeg ik constant meldingen. Nu werkt het allemaal.

Tnx!!!

[ Voor 8% gewijzigd door Verwijderd op 17-06-2004 12:37 ]