Input voor factuur uit query en een tabel

Status
Niet open voor verdere reacties.

raymin

Gebruiker
Lid geworden
24 aug 2010
Berichten
127
Ik heb een query "urenregistratie" waarin per regel alle benodigde velden staan om in een factuur/rapport over te nemen.

Ik heb een tabel "factuurinfo" waar alle informatie voor een factuur in staan (die niet in de uren/kosten registratie staan)

Ik wil een formulier maken (waar alle factuur informatie uit de tabel factuurinfo in staat) en hierin een subform maken waarin ik via een datumkeuze (en projectkeuze) gefilterte informatie van de "urenregistratie" weergeef.

gezien jullie hulp moet ik bovenstaande voor elkaar kunnen krijgen:

Nu komt het; ik wil een knop die deze informatie naar een nieuwe tabel/query kopieert, zodat ik via die tabel een controle kan houden op betaalde en niet betaalde facturen enz. (de knop is eigenlijk een "print rapport" knop die op het zelfde moment alle gefilterde data + de "factuurinfo" in een regel plaatst.

ik hoop dat jullie het nog een beetje begrijpen :)
 
Ik denk dat je de verkeerde weg op gaat als je de factuurgegevens naar een nieuwe tabel gaat kopiëren. Als je de tabellen goed hebt opgezet, moet je de status van een factuur in de tabel Factuur kunnen bijhouden via bijvoorbeeld een Statusveld, of eventueel via een gekoppelde extra tabel voor de factuurdetails. Het is dus niet nodig om steeds alles te kopieëren. Dat maakt je db nodeloos ingewikkeld.
 
Ok duidelijk, ik heb nogal de neiging heel moeilijk te gaan doen :D

De extra tabel heb ik idd nodig omdat deze ontbreken in de "urenregistratie" in deze registratie worden wel meteen de bijbehorende details meegenomen zoasl uurloon e.d.

Het idee is dat ik in de tabel "factuur" een ja/nee wil meenemen die aangeeft of een factuur is betaald of niet, waarna ik vervolgens een lijst kan zien van de niet betaalde facturen en de datum hiervan

Hoe kan ik dit het beste opzetten, kun je mij een duwtje in de juiste richting geven?
 
Ik zou geen Ja/Nee veldje gebruiken, maar een Datumveld. Uiteindelijk wil je ook kunnen rapporteren op betaaldatums, neem ik aan. En als een klant betaalt, dan vul je toch een betaaldatum in. Uit het al dan niet gevuld zijn van dit veld weet je automatisch of er betaald is of niet: geen betaaldatum? Niet betaald; wel betaaldatum? factuur is betaald. Idem dito met het versturen van aanmaningen: als je een Betaaltermijn vastlegt, en je hebt een factuurdatum, dan weet je ook wanneer je een aanmaning kunt sturen. Daar heb je dus geen extra datumveld voor nodig.
Je moet voor jezelf dus goed op een rijtje zetten/hebben welke gegevens je kunt herleiden uit andere gegevens. Deze hoef je niet op te slaan, maar bereken je op het formulier/rapport of in een query.
 
Hoi, Ik heb nu een tabel voor de facturen en een "factuurquery" aangemaakt. In deze query komt de uitkomst te staan van mijn factuurtabelgevens automatisch aangevuld met de informatie uit andere tabellen met relevante informatie.

In mijn factuurtabel heb ik twee extra datums opgenomen (zeg maar een van -tot bereik) de regels in de factuurquery hebben namelijk altijd een datum van uitvoering. Nu wil ik in deze query door middel van deze twee datums het bereik beperken. (ik heb meerdere facturen per project en nu staan alle activiteiten onder elkaar op het moment dat ik de "factuur" aanmaak in de tabel.

Ik neem aan dat ik in de querykolom bij "criteria" kan opnemen dat ik het bereik uit de tabel wil gebruiken, weet je misschien wat ik hier moet invullen?


Ik dacht aan [facturen]![Van datum]![Tot en met datum] maar dat is 'm niet ;)
 
Laatst bewerkt:
In mijn factuurtabel heb ik twee extra datums opgenomen

Waarom dan wel?
Je gebruikt, naar ik aanneem, een factuurdatum?
Gebruik die.

Ik krijg, gezien je vraagstelling en het vervolg daarop,het gevoel dat je je ontwerp probeert te sturen vanuit rapportage.
Dat is geen fijn plan, daarmee is de kans groot dat uiteindeliijk een onwerkbare toepassing in elkaar draait.

Niet kwaad bedoelt maar verdiep je eerst eens wat meer in wat relationele databases zijn en hoe deze op te zetten.

Tardis
 
Hoi,

Zo bedoel ik de twee datums niet helemaal.

Ik heb in mijn factuur tabel een factuurdatum, daar gaat dit niet over.

Het gaat erom dat ik per factuur meerdere items ophaal in de query deze hebben zelf allemaal een datum (de datum waarop het te factureren item is gepasseerd) ik factureer per periode, bijvoorbeeld per 20 dagen, kwartaal, week enz.

Als ik nu (nog in de tabel, ik heb nog geen formulier gemaakt) een factuur aanmaak op project, dan zie je in de query alle onder dit project vallende items. ik wil dus op in de factuurtabel al aangeven dat er voor die factuur periode geld.

Ik stuur in ieder geval niets aan vanuit de rapportage. Dat wordt enkel een "uitdraai" van de factuurregel in de factuurtabel en regels uit de query die hieronder vallen.
 
Hierbij even een screenshot van de tabel facturen en van de query waarin (doordat er facturen zijn aangemaakt) enkele regels staan. deze bevatten datums en deze datums wil ik beperken in de facturen tabel.

facturen.png


FacturenQuery.png
 
Ok.
Je hebt dus diensten vanuit projecten die je per een door jouw te kiezen periode wilt factureren.
Kortom, je hebt nog helemaal geen factuur, die wil je nu juist gaan maken.

Dan stuur je facturatie dus aan vanuit gegevens vanuit je projectregels plus evt andere kondities (zoals afspraken die je met klanten heb t gemaakt mbt het factuurmoment).

Zet voor jezelf alle stappen eens logisch chronologisch op papier.
Denk niet vanuit facturen maar denk in de richting waar je stappen logisceiherwijs toe zouden moeten leiden.
De gegevens om je facturen te kunnen maken he je allemaal al.

Tardis
 
Omdat de datumreeks (neem ik aan) niet afhankelijk is van de factuurdatum, of een ander gegeven in je tabel(len) zou ik in dit geval denk ik ook een begin- en een einddatum voor de verzamelfactuur vastleggen. Stuur je facturen die altijd over een volledige maand gaan, of altijd de periode van een fysieke maand, dan kun je die reeks nog wel sturen via functies in een query. Uit oogpunt van flexibiliteit is het gebruik van een begin- en een einddatum wel begrijpelijk.
Blijft de vraag over hoe je de deelfacturen uiteindelijk selecteert... Ik neem aan dat je een factuur maakt op basis van een KlantID, en dat je vervolgens in een subformulier alle projectregels ziet die nog niet gefactureerd zijn. Vervolgens wil je deze projectregels aan een factuur kunnen toewijzen. Dat kan dus alleen aan een hoofdfactuur die al eerder is aangemaakt. De openstaande opdrachtregels zul je op de een of andere manier toch aan die hoofdfactuur moeten koppelen. Hoe had je dat gedacht te doen? En stel dat je dat doet op basis van een datumselectie zoals je in gedachte hebt; wat doe je met de regels die niet in de selectie vallen? Regels die ouder zijn bijvoorbeeld; hoe en wanneer ga je die factureren?
Ik zou zelf denk ik een selectievakje gebruiken om de opdrachtregels te selecteren, en vervolgens met een bijwerkquery het factuurnummer in de Factuurregels tabel bijwerken. Op die manier kun je snel en flexibel regels toevoegen aan een factuur.
 
Ok, het wordt een selectievakje, waarbij ik in een subformulier (dit is dan mijn factuurquery neem ik aan) de regels die ik wil factureren selecteer.

Ik ben je kwijt bij de bijwerkquery die het factuurnummer bijwerkt. Vergeef me als ik nu domme dingen ga vragen :confused:

Ik maak straks in een formulier (die mijn factuurtabel aanstuurt) een nieuwe factuur, in het subformulier (de query) komen bij het kiezen van het project vanzelf de eventueel te factureren regels te staan. Hiervan kies ik dan op basis van een selectievakje welke regels in deze factuur moeten komen.

Als ik dan later weer een nieuwe factuur aanmaak, en kies weer hetzelfde project dan zie ik toch nog steeds alle regels van dit project waarbij er dan reeds een aantal zijn geselecteerd? of is dit wat je bedoeld met een bijwerkquery?

ooohh..... er gaat een lampje branden :d het factuurnummer is dan natuurlijk die van een reeds verzonden factuur. <KNUPPEL>slaat zichzelf voor zijn kop</KNUPPEL> dan is mijn vraag, hoe "werkt" een bijwerkquery?
 
Nog nooit een bijwerkquery gemaakt? Moet je toch eens proberen :)
In jouw geval zou het zo kunnen: je hebt dus in de tabel Opdrachtregels (geen idee of die zo heet, maar ik hou de naam maar even aan voor het gemak een selectievakje gemaakt dat je gaat gebruiken om te factureren regels te selecteren. Dit vakje is standaard leeg. In de tabel Factuurregels staan de records waarvan het selectievakje in de tabel Opdrachtregels op Ja staat, want die zijn in een eerder stadium aan een factuur toegevoegd. Je kunt dus simpel een selectiequery maken met die records waarvan het selectievakje leeg is, en waarvan de OpdrachtID niet voorkomt in de tabel Factuurregels. Immers: een opdrachtregel die is toegevoegd aan een factuur, heeft een record in de tabel Factuurregels.
De selectie (chkFactuur=Leeg en OpdrachtID niet in Factuurregels) gebruik je als basis voor je subformulier, zodat je in dat formulier records kunt selecteren die je wilt opnemen in de factuur. Deze records worden aangevinkt. Je hebt nu dus in de tabel Opdrachtregels drie soorten records:
1. Records waarvan het selectievakje leeg is
2. Records waarvan het selectievakje niet leeg is, en waarvoor geen records bestaan in de tabel Factuurregels
3. Records waarvan het selectievakje niet leeg is, en waarvoor records bestaan in de tabel Factuurregels
De tweede groep ga je toevoegen aan de tabel Factuurregels.

Zoals ik het hier beschrijf, heb je geen Bijwerkquery nodig, maar een Toevoegquery. Want je moet nog factuurregels maken voor de factuur die je net hebt gemaakt. Daarbij heb je in de tabel Factuurregels dus in ieder geval het FactuurID nodig, en het veld OpdrachtID. In die tabel heb je uiteraard meer velden, zoals Betaaldatum, maar die zijn voor het verhaal niet nodig. Waar het om gaat, is dat je de juiste records toevoegt aan de tabel Factuurregels, zodat je een volgende keer hetzelfde proces kunt uitvoeren.

Ik heb dit overigens nog niet uitgeprobeerd, dus het kan zijn dat ik ergens een denkfout maak... In dat geval hoop ik dat iemand je knuppeltje even leent, en richting Rotterdam afreist :D
 
Bedankt voor de uitleg, Ik ga ermee aan de gang Ik laat wel even weten hoe het loopt.

(mocht het nodig zijn, ik kom wekelijks in Rotterdam, breng ik het knuppeltje zelf wel even :d)
 
Zal er zelf ook nog even mee gaan stoeien, want het is een vrij gangbaar onderwerp voor een db.
 
Hoi OctaFish,

Ik heb nu een tabel "facturen" (in jouw uitleg factuurregels) en een tabel "uren registratie" ( in jouw uitleg opdrachtregels)

Ik heb nu in de tabel uren registratie een selectievakje, als ik nu in de tabel facturen een project selecteer en ik selecteer de regels in "uren registratie" (van het project) dan laat een query (die ik factuurQuery heb genoemd) netjes de geslecteerde regels zien.

Zoals je ziet, mis ik nog even de opdrachtID in jouw uitleg, hier raak ik je even kwijt. Ik begrijp dat deze koppeling ergens nodig is, ik zie alleen even niet waar. als er meerdere records uit uren registratie moeten worden gekoppeld aan de record in "facturen" is het dus zo dat het opdrachtID in de tabel "facturen" in meerdere records van "uren registratie" terugkomen. zit ik dan op het juiste spoor?
 
Als ik jouw plaatjes er even bijhaal, dan wordt het misschien wat duidelijker. Eerst overigens een vraagje: als je 'mijn' tabel Factuurregels hebt 'vertaald' naar Factuur, hoe heet dan jouw tabel met de hoofdfactuurgegevens? Want de basistabel zou ik dus Facturen noemen, en de apart te factureren opdrachten noem ik dus Factuurregels. In een rapport zie je die ook als zodanig terug: één factuur, met verschillende 'regels' m.b.t. de opdrachten. Hopelijk zie je de logica ;)
Jouw plaatjes gebruiken ook een veld dat de opdrachten met de facturen verbindt: het veld [Betreft project]. Ik vermoed, dat je daar wel wat mee kunt als verbindend veld ...
 
Hoi OctaFish,

Ben even een paar dagen wat anders wezen doen, m'n hersens zaten in de knoop :D

Mijn tabel "facturen" bevat de standaard factuurgegevens, zoals factuurdatum, betaaldatum (hoofdfactuurgegevens)
Mijn tabel "Uren Registratie" bevat de te factureren regels.
De "Factuur query" bevat de velden die in de tabel factuur wordt opgegeven (in mijn geval geselecteerd op project) In de tabel "Uren Registratie" staat de kolom met de aan te vinken velden. Als ik nu een factuur "aanmaak" voor het project "testproject 2" dan kan ik in "uren registratie" de regels aanvinken. (ik zie ze dan wel allemaal nu, dus ook de andere projecten) in de query komen dan deze regels te staan. Ik gebruik dan het veld "project" toch al als bindend veld?

Ik weet eigenlijk zeker dat ik iets constructief niet goed doe, alleen breek ik mijn hoofd over wat nu precies.
Hieronder even de screenshots van de tabellen die ik gebruik.

Facturen.png


FacturenQuery.png


screenshot3.png


(ik ben me even aan het inlezen betreft toevoegquery, ik moet en zal het begrijpen ;) )
(en ik ben even opnieuw begonnen, met de benamingen die jij noemt, ik denk dat ik het begrijp, alleen nu nog even uitvoeren...dusssss)
 
Laatst bewerkt:
Als ik een toevoeg query maak en ik heb een tabel met dezelfde veldnamen. Hoe voegt de query deze data dan toe aan de tabel? Ik zie de data wel in de query verschijnen, maar deze komt niet in de toegewezen tabel terecht. (of begrijp ik de essentie niet?)

Ik begrijp het als volgt: De criteria die ik opgeef bepalen of deze in de toevoegquery terecht komen, deze zouden dan toch in de toegewezen tabel moeten komen, waarna de query weer leeg is en deze blijven bestaan in de tabel?
 
Een toevoegquery gebruikt velden uit één (of meerdere) tabel(len) en voegt ze toe aan een andere tabel. Hierbij maakt het niet uit of de veldnamen gelijk zijn of niet; je moet in ieder geval alle velden die je wilt vullen in de doeltabel koppelen aan een veld uit de brontabel(len). Als de veldnamen hetzelfde zijn, kan Access de koppeling zelf maken, op basis van die veldnamen. In elk ander geval maak je de koppeling handmatig.
Als jouw toevoegquery niet werkt, dan komt dat vermoedelijk doordat de bron niet kan worden toegevoegd aan de doeltabel, of dat bijvoorbeeld de bron- en doeltabel dezelfde zijn, wat uiteraard niet zo'n goed idee is...
Op basis van de plaatjes kan ik nog steeds niet goed inschatten wat nu het probleem is; kun je misschien toch een voorbeeldje maken in 2003 format?
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan