Aan een opdrachtbon (order) een gewijzigd record hangen

Status
Niet open voor verdere reacties.
Je kunt een UNION query maken die de gegevens uit de twee tabellen samenvoegt in één resultaat.
 
Sleutelvelden als tekst

Daar ben ik weer. Dit ontwerpfoutJE lijkt wel wat consequenties te hebben. Ik vulde de velden met de VrijwilligerID en ExtOrgID gebaseerd op autonummering. Nu is mijn idee de PK aan de te passen en een code mee te geven als INT001 en EXT001. Als we in de toekomst eventueel nog met zzp'ers gaan werken voor grotere klussen dan kan ik daar ZZP001 van maken. Des te meer reden om de uitvoerder in één veld op te slaan. Ik heb een Unieke code in het veld Uitvoerder nodig om later de kunnen bereken hoeveel opdrachten zijn gedaan en door wie. Vergelijkbare code heb ik al van je "gepikt" voor het nummeren van de opdrachtbon.

Mijn vraag: Is dit een goed idee?

De aangepaste PK lijkt ook handig voor de UNION query. Dit lijkt wel te lukken.

Bedankt maar weer. Marjan
 
Dat is een uitstekend idee :). Probeer zoveel mogelijk identieke 'objecten' (een zzp-er verschilt niet zoveel als een organisatie denk ik, voor jouw db althans) in één tabel op te slaan. En dan met codes het ID bepalen (hoeft niet, je kunt dat ook met een statusveld doen maar een code is wel makkelijk en eventueel weer te combineren met de status voor een automatische nummering).
 
een zzp-er verschilt niet zoveel als een organisatie denk ik, voor jouw db althans
Klik om te vergroten...
Klopt: kan prima bij externen.

hoeft niet, je kunt dat ook met een statusveld doen maar een code is wel makkelijk en eventueel weer te combineren met de status voor een automatische nummering
Klik om te vergroten...
Dit snap ik (nog) niet zo goed. Ga ik even over nadenken.

De code is denk ik vooral handig om goede keuzelijsten te krijgen. Vrijwilligers doen verschillende dingen en dus moet ik de keuzelijsten filteren op de keuze van de dienstverlening. Ook wil ik bijv. weten hoeveel klussen iemand gedaan heeft om het een beetje evenredig te verdelen over de vrijwilligers.

Nu heb ik de code van de opdrachtbon aangepast om INT-001 te verkrijgen. Maar ik krijg soms #Grootte! en soms pakt ie hem wel bij NewRecord onderin, maar de volgende keer dan weer niet.
Bij opdrachtbon heb ik trouwens dat het nummer alleen pakt als ik het formulier opnieuw open, niet met de code Docmd.Gotorecord, , New.

Lijkt wel een nieuwe hobby dat Access.

Fijn weekend. Marjan
 
Access een hobby? Nee, dat zie je verkeerd: Access is een roeping :). Je kunt het vergelijken met het supporter zijn van Feijenoord: de meeste dagen breng je door in droefenis en ellende, maar af en toe schijnt de zon door en pak je een hoofdprijs. En dat zijn dan de mooiste dagen die je kunt hebben :D.
 
Ha ha maar dan ken je ook "geen woorden, maar daden". Oftewel heb je ook een antwoord op mijn vraag wat er mis gaat met de nummering?:rolleyes::d
 
Doe er weer eens een voorbeeldje bij met de huidige situatie, dat kijkt makkelijker.
 
Je hebt wel een functie gemaakt, maar die gebruik je niet om een nieuw nummer te genereren. Je bent er kortom bijna, maar moet nog een klein stukje over de drempel. Eerst een aanpassing van je functie, want die kan ook wat strakker (al zag ik dat je mijn eerdere verbeteringen ook achteloos in de prullenbak heb gegooid :) ).
Code: 
Function VrijwilligerCode() As String
Dim strVolgnummer As String, strNieuwVolgNummer As String, strSQL As String
Dim tmpNummer, bJaar As Boolean

    'Huidige volgnummer uit tabel lezen die als parameter is meegegeven
    strSQL = "SELECT TOP 1 [VrijwilligerID] FROM [tblVrijwilliger] ORDER BY [VrijwilligerID] DESC"
    With CurrentDb.OpenRecordset(strSQL)
        If .RecordCount > 0 Then
            strVolgnummer = .Fields(0).Value
        Else
            VrijwilligerCode = "INT-001"
            Exit Function
        End If
    End With
    
    'Laatste nummer opsplitsen en met 1 verhogen
    tmpNummer = Split(strVolgnummer, "-")(UBound(Split(strVolgnummer, "-"))) + 1
    VrijwilligerCode = "INT-" & Right("000" & CInt(tmpNummer), 3)

End Function

En in het veld <Standaardwaarde> van het veld <=VrijwilligerCode()> op je formulier zet je dan: =VrijwilligerCode(). En dan krijg je automatisch een correct nieuw nummer als je een nieuwe vrijwilliger invoert.
 
Bedankt voor de aanpassingen. Ik ga het even testen maar volgens mij had ik bij de veldeigenschappen de standaardwaarde ingevuld zoals jij beschrijft. De code was overigens van jezelf. Gemaakt voor een opdrachtbon, die werd voorafgegaan aan Year(Date). Omdat de variabele bJaar nog wordt gedeclareerd in de nieuwe code (wat hier waarschijnlijk niet hoeft) kan ik meteen vragen waarom die is gedeclareerd, want die zie ik ook niet terug in Function Volgnummer (zie hieronder). Bij het gebruik van deze functie moet ik overigens wel het formulier opnieuw openen. Docmd.Gotorecord NewRecord onder de knop Volgende werkt niet. Alleen sluiten en openen van het formulier.

Code: 
Function Volgnummer() As String
Dim strVolgnummer As String, strNieuwVolgNummer As String, strSQL As String
Dim tmpNummer, bJaar As Boolean

    'Huidige volgnummer uit tabel lezen die als parameter is meegegeven
    strSQL = "SELECT TOP 1 [Opdrachtbon] FROM [tblOpdracht] ORDER BY [Opdrachtbon] DESC"
    With CurrentDb.OpenRecordset(strSQL)
        If .RecordCount > 0 Then
            strVolgnummer = Nz(.Fields(0).Value, 0)
        Else
            Opdrachtbon = Year(Date) & "-0001"
        End If
    End With
    
    'Laatste nummer opspliten en met 1 verhogen
    tmpNummer = Split(strVolgnummer, "-")
    If CInt(tmpNummer(0)) = Year(Date) Then
        strNieuwVolgNummer = tmpNummer(0) & "-" & Right("0000" & CInt(tmpNummer(1)) + 1, 4)
    Else
        strNieuwVolgNummer = tmpNummer(0) & "-0001"
    End If
    
    'Nieuw nummer toekennen aan de functie
    Opdrachtbon = strNieuwVolgNummer

End Function

Overigens heb ik je strakkere code met With ... End With wel gebruikt voor de knoppen. Maar ik werk (voor het gemak) met 2 versies. In het voorbeeld had ik het inderdaad niet aangepast.

Bedankt maar weer.
 
Ik ben natuurlijk afhankelijk van de informatie (en voorbeelden) die ik van jou krijg :). De ‘oude’ functie ziet er inderdaad niet helemaal correct uit (nou ja, hij werkt wel) maar omdat volgnummers veelvuldig terug komen in het forum, blijft er wel eens een variabele (of deelcode) staan die dan niet meer nodig is. Het is aan de gebruiker van de code om deze a) te begrijpen en b) in de eigen db te implementeren.
Ik gebruik tegenwoordig wat andere technieken om de hoogste (of laagste) waarde met SPLIT uit een veld te halen, en die variant zit in de nieuwe functie verwerkt. Dat maakt de code dus gelijk een stuk korter. Het eerste deel (INT-) is op dit formulier standaard, dus dat hoef je verder nergens uit te halen. Maakt de code dus ook korter. Gebruik je een generieke functie (kan best, met wat kleine aanpassingen) dan wordt het iets lastiger.

In jouw voorbeeld gebruik je de functie niet als standaardwaarde; vandaar dat ik dat er maar even bij heb gezet. De standaardwaarde zet je dus op het formulier, niet in de tabel.
 
De nieuwe code voor INT werkt perfect. Bedankt. :) Ik ga de code voor het opdrachtnummer nog even bestuderen en kijken of ik de nieuwe techniek kan toepassen.
 
2 subformulieren of 1

Ik ben weer aan het hobbyen geweest. De lijst met query's is flink uitgebreid. Ik gebruik deze om met Select Case de rijbron in te stellen voor de keuze van de vrijwilliger. Zou je willen kijken of dit een schoonheidsprijs verdiend? Je vindt deze op het frmOpdracht.
Op het frmVrijwilliger had ik een subformulier met een keuzelijst voor de verschillende diensten van de vrijwilliger. Nu hebben sommige vrijwilligers bijv. ook vaste tuinklanten. Ik kan niet overzien of ik nu deze gegevens in 1 tabel kan plaatsen en dus 1 subformullier of dat er redenen zijn om het toch gesplitst te houden. Zou je hier ook je blik op willen werpen?

Als ik nieuw draadje moet aanmaken voor de keuzelijsten dan hoor ik dat graag.

Bedankt maar weer. Hierbij voorbeeld 4.
Code: 
[ATTACH]332025.vB[/ATTACH]
 

Bijlagen

  • NvE helpmij voorbeeld4.zip
    171,3 KB · Weergaven: 26
Ik begin langzamerhand een beetje het licht kwijt te raken in het bos van de tabellen.... Ik weet eigenlijk niet of je op de goede weg bent. Zo zit ik mij nu af te vragen of de constructie met de tabellen Klussen en Dienstverlening wel klopt, en of je al die losse tabellen wel nodig hebt.
Even over de klussen: je hebt nu dus twee velden in tblOpdracht, [KlantOpdID] en [KlusOpdID]. Die staan dus naast elkaar in de tabel, en dat betekent dat je idiote combinaties kan maken, zoals "Rookmelder aanbrengen en batterij vervangen" in "Tuinonderhoud licht". Dat kan eigenlijk niet, en dat zou je ook niet moeten willen faciliteren. Wat je éigenlijk moet doen, is één tabel maken (tblDienstverlening bijvoorbeeld gebruiken) waar je een extra veld in maakt, dat je dan ParentID o.i.d. noemt, maakt niet uit. De totale tabel Klussen verplaats je dan naar die tabel tblDienstverlening, en per ingevoerde klus geef je dan aan bij welke dienstverlening die hoort. Dus de 'klus' "Ophangen van schilderij, plankje, gordijnroetje etc" voeg je toe aan Dienstverlening (krijgt DienstverleningID nr 8) en in het veld ParentID zet je de waarde 1. Daarmee refereer je deze klus aan de hoofdcategorie "Binnenhuis klus".

Eigenlijk zijn de oorspronkelijke dienstverleningsrecords dus hoofdcategorieën (zonder ParentID) en de overige records subcategorieën. Je kunt dat, met deze opzet, zelfs nog verder opsplitsen. Zo kun je het ophangen van objecten bijvoorbeeld best verder splitsen. Een schilderij ophangen met één spijker is toch een heel andere klus dan ophangen van vitrage of gordijnen. Je hebt nu bijvoorbeeld nog geen tijdsblokken bij de klussen, maar dat zou je op die manier best kunnen doen. Dat helpt denk ik ook enorm bij het maken van een planning.
Wat veel belangrijker is: om een klus nu aan een opdracht te hangen, hoef je maar één veld te vullen, met dus het DienstverleningID. Want als je dát weet, heb je ook de categorie (de ParentID namelijk). En nog veel mooier: op het formuiler kun je afhankelijke keuzelijsten maken, waarin je eerst een hoofdcategorie kiest, en in de tweede keuzelijst de eerste groep klussen, en vervolgens in de derde keuzelijst de tweede subgroep.
 
Oeps. Dat is inderdaad niet de bedoeling. Is je voorstel het principe van de duikschool met landen en locaties? Dan moet ik dat nog goed bekijken.
Bedankt. Ik ga aan de slag.
 
Afhankelijke keuzelijsten

Ik heb een poging gewaagd om de keuzelijsten van elkaar afhankelijk te maken. Dat lijkt op zich wel te lukken, maar inmiddels weet ik dat het geen garantie is op de juiste koers. Ik gebruik deze keuzelijsten om in te voeren. In het voorbeeld van de duikschool is de toepassing filteren dus ik heb het een en ander aangepast. Ik loop enorm te prutsen om de ingevoerde waardes uit te lezen als het formulier wordt geopend om gegevens te muteren.

Ik weet nog niet hoe ik het voor de vrijwilligers ga oplossen voor de verschillende activiteiten en de vaste klanten. In de relaties staat dat nog als losse tabellen. Maar alles stap voor stap.

Ik hoop dat je het nog kunt volgen. Hierbij de nieuwe versie. Bedankt maar weer.

Code: 
[ATTACH]332076.vB[/ATTACH]
 

Bijlagen

  • NvE helpmij voorbeeld5.zip
    228,4 KB · Weergaven: 25
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan