Ik heb wel een voorbeeld, maar die is voor een klant dus die kan ik niet zomaar delen. Maar de techniek is redelijk simpel, en vergelijkbaar met die van een order + orderregels. Een factuurtabel bevat in dit geval alle factuurgegevens, zoals factuurdatum + nummer, klantgegevens etc. Gaan er meer orders op een factuur, dan heb je een gekoppelde tabel nodig, bijvoorbeeld tFactuurregels. Die koppel je aan de tabel tFacturen op basis van het sleutelveld. Dat kan Factuurnummer zijn (dat moet immers uniek zijn) maar kan ook een Autonummerveld zijn, dat is tenslotte ook uniek. Als je dat als sleutel gebruikt, heb je een Eén-op-veel relatie tussen de twee, en dat moet natuurlijk ook.
In de tabel tFactuurregels krijg je dan het FactuurID, OrdernummerID, etc. Dus deze tabel koppelt ook met de tabel tOrders, die zelf wel weer gekoppeld zal zijn aan tOrderRegels.
Wat de koppeling een beetje lastig maakt, is dat je niet alle orders aan een factuur kan hangen. Klant A hoeft natuurlijk niet op te draaien voor de orders van Klant B. Dus op het facturen formulier wil je in het subformulier alleen orders kunnen zien die aan twee voorwaarden voldoen:
1. Moeten van dezelfde klant zijn
2. Mogen niet op een andere factuur staan. Tenzij het wellicht een creditnota is.
3. Mogen niet meer gemuteerd worden als ze eenmaal zijn gefactureerd.
Dat kun je allemaal op het formulier wel regelen, bijvoorbeeld door twee keuzelijsten te maken, met links de orders die nog niet zijn gefactureerd (kun je makkelijk filteren) en rechts de orders die op de factuur zijn gezet (ook een simpel filter).
Door op de orders links te klikken, kun je een query triggeren die de orders toevoegt aan de tabel tFactuurregels, zodat ze rechts komen te staan en links verdwijnen. Omgekeerd kan dan ook nog, als je per ongeluk de verkeerde order hebt toegevoegd of het totaalbedrag wilt verlagen. Zodra je de factuur definitief maakt, kan dat niet meer.
. Ik heb wel een voorbeeldje liggen van de constructie die ik in #2 heb beschreven, mocht je er zo snel niet uitkomen.
