Hallo,
ich habe eine Datenbank, die Artikel, Aufträge, Kunden und Auftragspositionen enthält. Jedem Auftrag können Positionen hinzugefügt werden - soweit klappt alles. Nun kommt aber eine Tabelle Rabatt hinzu. Hier soll es möglich sein, dass ein Kunde auf unterschiedliche Artikel unterschiedliche Rabatte erhalten kann. Hierzu habe ich eine Tabelle Rabatt anelegt, welche eine ID, die ArtikelNr sowie die Kundennummer und den Rabatt beinhaltet.
Nehme ich diese Tabelle (egal ob als Abfrage oder als Tabelle) nun in meine Abfrage mit rein, wo ich die Positionen ausgebe, so kann kein neuer DS angefügt werden.
Hallo,
die Beziehung(en) zu tblRabatte sind falsch. Erstelle eine Tabelle "tblKundenArtikelRabatte", die die Fremdschlüssel zu tblKunden und tblArtikel (--> Beziehungen) enthält und die die Rabatt(-Werte) für diese Konstellation aufnimmt.
Der Primärschlüssel wird aus dieer TAbelle wird nach Auswahl mittels Kombifeld einer Position zugeordnet.
Vielen Dank für die Antwort! Ich bin mir nicht sicher ob es ich richtig verstanden habe. Meist du ich soll die tblKundenArtikelRabatte als Hilfstabelle zur tblRabatte erstellen (siehe Anhang)?
Hallo,
so in etwa...
Zitatals Hilfstabelle
es ist keine
Hilfstabelle, sondern eine
Zuordnungstabelle für die Zuordnung eines Rabattes zu einem KundenArtikel.
-- Beziehung Artikelnummer zu BestellPosition_ArtikelNr entfernen.
-- Bestellposition_ArtikelNr in KundenArtikelRabattid_f umbenennen.
-- Beziehung zwischen KundenArtikelRabattid_f und KundenArtikelRabattid herstellen (1:n, ref. Int.).
Vielen Dank für die Antwort!
Ich glaube es liegt ein Missverständnis vor. Die Rabatte sollen flexibel zugeordnet werden können - sprich Kunde A kann auf Artikel A 10% Rabatt haben, Kunde B kann auf Artikel A 20% Rabatt haben.
Wenn ich die Beziehung Artikelnummer zu BestellPosition_ArtikelNr entferne dann können die Positionen den Aufträgen nicht mehr zugeordnet werden. Das ist eine elementare Bindung.
Hallo,
das siehst Du falsch.. Die Artikelnummer als solche gehört nicht "elementar" zu einer Position, sondern die Artikelnummer, die zu einem Kunden gehört und einen bestimmten Rabatt hat.
Und dies ist die KundenArtikelRabattID, nicht die Artikelnummer.
Zitat...entferne dann können die Positionen den Aufträgen nicht mehr zugeordnet werden
aber natürlich geht zu Zuordnung: über die Tabelle KundenArtikelRabatte zu Tabelle Artikel.
(Was sind jetzt "Aufträge"? Sollen das die Bestellpositionen sein?)
@hackepeter ZitatWas sind jetzt "Aufträge"?
Ich muss jetzt mal eben meiner Signatur gerecht werden. Fragen zu
Fakturierungs-DBs tauchen ja öfter auf. Und da fällt mir immer
wieder die oft verwirrende Nomenklatur von Aufträgen/Bestellungen
auf. Für mich gilt immer
Ein Auftrag ist eine "Bestellung", die ich von einem Kunden erhalte;
eine Bestellung ist ein "Auftrag", den ich an einen Lieferanten/DLer
gebe.
gruss ekkehard
Hallo
@Ekkehard
naja, das mag ja stimmen in einem bestimmten Umfeld/Kontext.
Für mich ist ein Auftrag zunächst etwas, was mich auffordert, etwas Bestimmtes zu tun. Sei es, eine Bestellung an einen Lieferanten zu schicken, ein Schulungsevent abzuhalten, ein Auto zu produzieren oder sonst was durchzuführen. Ein Auftrag kann auch ein Gesamt-Auftrag sein, der weitere (Unter-) Aufträge beinhaltet, z. B. auch wie hier, Bestellungen zu generieren. Dann sollte das aber auch so benannt werden (BestellAuftrag).
Wenn ich plötzlich "Auftrag" statt "Bestellung" höre/lese, muss ich meine grauen Zellen aktivieren (hoffentlich funktionieren die noch) und mich zum Nachdenken überwinden, was denn da nun gerade gemeint ist. Dieses Nachdenken erfordert aber ein gewisses Lösen von meiner Faulheit. Da frage ich dann lieber nach und überlass das Nachdenken anderen... ;) ;) ;) ;D 8) 8)
Hallo Franz,
Sollte ja keine Kritik an deiner Frage sein, und mein Post war ja auch an den TS gerichtet.
ZitatFür mich ist ein Auftrag zunächst etwas, was mich auffordert, etwas Bestimmtes zu tun.
Ohne einen speziellen Zusammenhang würde ich es auch so sehen. Hier geht es
aber offensichtlich um Warenhandel/DL. Sonst hätte ich mir den Post auch gespart.
Es ging mir nur darum, den TS und uns auf eine gemeinsame Nomenklatur zu bringen.
Was wir ja hin bekommen würden, wenn der TS deine Frage beantwortet.
gruss ekkehard
Hallo.
ZitatSollte ja keine Kritik an deiner Frage sein,
hab ich ja auch nicht so aufgefasst :)
Hoffentlich ist der T nicht so ver(w)irrt, als dass noch eine Tabelle "Aufträge" hinzukommt.
Hauptsache ist, die KundenArtikelRabattID wird richtig eingebunden. :-X
Ja, an der Nomenklatur muss ich noch arbeiten. Bestellungen sind in dieser DB Bestellungen von Kunden.
Bestellungen_Positionen sind die einzelnen Positionen in dien Kundenbestellungen.
Zitat von: DF6GL am September 28, 2020, 07:58:15(Was sind jetzt "Aufträge"? Sollen das die Bestellpositionen sein?)
NamePos1
NamePos2
NamePos3
MengePos1
MengePos2
MengePos3
in tblBestellungen können vernachlässigt werden.
Ich habe noch immer ein Verständnisproblem mit der tblKundenArtikelRabatte: Die Zuordnung welcher Kunde welchen Rabatt hat, hatte ich ja vorher schon in der tbl_Rabatte.
Ich habe dennoch die Anpassungen durchgeführt. Wie erwartet funktioniert es nun einen neuen DS anzufügen.
Ich bekomme allerdings die Fehlermeldung: "Es können keine Datensätze eingefügt werden, der Verknüpfungsschlüssel der Tabelle "KundenArtikelRabatte" ist nicht in der Datensatzgruppe vorhanden.
Hallo,
da gibt es noch einiges zu korrigieren:
ZitatNamePos1
NamePos2
NamePos3
MengePos1
MengePos2
MengePos3
entfallen ersatzlos.
Tabelle Rabatt brauchst Du nicht, der Rabatt(wert) kann gleich in KundenArtikelRabatte (Feld "Rabatt") abgelegt werden.
Welchen Sinn hat "Rabatt" in Tabelle Kunden?
MwSt in Tabelle Artikel ist obsolet (oder gibt es zu jedem Artikel eine unterschiedliche MwSt (MwStSatz) ?)
Besser ist der MwStSatz in einer Tabelle mit Gültigkeitsdatum aufgehoben. So könnte man auf temporäre Änderungen (wie zur Zeit aktuell) besser reagieren.
Für was werden Bestellstatus und Bestellungen_Positionen_Status gebraucht, dazu mit Left/Right-Join-Beziehung?
Alle Left/Right-Joinbeziehungen sollten in Inner-Join korrigiert werden.
Die ref. Integrität der Beziehungen zu KundenArtikelRabatte fehlen.
Bei Artikel ist für Beziehungen die ArtikelID (Autowert) zu bevorzugen, nicht die evtl. alfanumerische Artikelnummer.
Weiterhin:
-- auf Sonder- und Leerzeichen dringen verzichten
-- benenne Fremdschlüsselfelder konsequent ("PKFeldname_f")
-- benenne Tabellen mit "tbl" als Prefix (--> tblKunden)
Tipp:
"Sortiere" (platziere) die Tabellen entsprechen ihres Beziehungsmodus so in vertikalen Spalten , als dass die 1-Tabellen immer eine Spalte links von der n-Tabelle zu liegen kommen. Das ergibt bedeutend mehr Transparenz zu den Datenzusammenhängen.
Vielen Dank für die Geduld! Das Ursprungsproblem ist jetzt behoben, neue DS können wie gewünscht hinhzugefügt werden. Das Formular für die Bestellungen enthält ein Unterformular, welches die Bestellpositionen anzeigt. Hier musste ich u.a. die Verknüpfungen anpassen.
Einziges Problem ist nun noch die Rabattverwaltung (s.u.).
Zitat von: DF6GL am September 28, 2020, 17:08:08ZitatNamePos1
NamePos2
NamePos3
MengePos1
MengePos2
MengePos3
entfallen ersatzlos.
geht momentan nicht. Es gibt ein Endlosformular (Übersicht), wo unter anderem die ersten drei Positionen einer Bestellung angezeigt werden. Beim öffnen dieses Formulars gehe ich es durch und schreibe die ersten 3 Positionen + Mengen in diese Felder um sie dann im Endlosformular anzuzeigen. Es ist zwar nicht schön, aber funktionell.
Dim rsPositionen As Recordset
Dim rsBestellungen As Recordset
Dim i As Integer
Dim Menge1 As Integer
Dim Menge2 As Integer
Dim Menge3 As Integer
Dim Name1 As String
Dim Name2 As String
Dim Name3 As String
Dim AktuelleBestellNr As String
Set rsPositionen = CurrentDb.OpenRecordset("qry_Bestellungen_Positionen", dbOpenDynaset)
Set rsBestellungen = CurrentDb.OpenRecordset("Bestellungen", dbOpenDynaset)
'rsPositionen.FindFirst "BestellPosition_BestellNr Like " & Me!Kombinationsfeld15
'If the recordset is empty, exit.
If rsBestellungen.EOF Then Exit Sub
i = 1
rsBestellungen.MoveFirst
Do Until rsBestellungen.EOF
AktuelleBestellNr = rsBestellungen.Fields("BestellNr")
rsPositionen.FindFirst "BestellPosition_BestellNr Like " & AktuelleBestellNr
If Not rsPositionen.NoMatch Then
Name1 = rsPositionen.Fields("Artikelname")
Menge1 = rsPositionen.Fields("BestellPosition_Menge")
rsBestellungen.Edit
rsBestellungen.Fields("NamePos1") = Name1 'Name1 setzen
rsBestellungen.Fields("MengePos1") = Menge1 'Menge1 setzen
rsBestellungen.Update
Else
rsBestellungen.Edit
rsBestellungen.Fields("NamePos1") = ""
rsBestellungen.Fields("MengePos1") = emty
rsBestellungen.Update
End If
rsPositionen.FindNext "BestellPosition_BestellNr Like " & AktuelleBestellNr
If Not rsPositionen.NoMatch Then
Name2 = rsPositionen.Fields("Artikelname")
Menge2 = rsPositionen.Fields("BestellPosition_Menge")
rsBestellungen.Edit
rsBestellungen.Fields("NamePos2") = Name2 'Name2 setzen
rsBestellungen.Fields("MengePos2") = Menge2 'Menge2 setzen
rsBestellungen.Update
Else
rsBestellungen.Edit
rsBestellungen.Fields("NamePos2") = ""
rsBestellungen.Fields("MengePos2") = emty
rsBestellungen.Update
End If
rsPositionen.FindNext "BestellPosition_BestellNr Like " & AktuelleBestellNr
If Not rsPositionen.NoMatch Then
Name3 = rsPositionen.Fields("Artikelname")
Menge3 = rsPositionen.Fields("BestellPosition_Menge")
rsBestellungen.Edit
rsBestellungen.Fields("NamePos3") = Name3 'Name3 setzen
rsBestellungen.Fields("MengePos3") = Menge3 'Menge3 setzen
rsBestellungen.Update
Else
rsBestellungen.Edit
rsBestellungen.Fields("NamePos3") = ""
rsBestellungen.Fields("MengePos3") = emty
rsBestellungen.Update
End If
rsBestellungen.MoveNext
i = i + 1
Loop
Diese Funktion zu optimieren ist allerdings ne andere Baustelle.
Zitat von: DF6GL am September 28, 2020, 17:08:08Tabelle Rabatt brauchst Du nicht, der Rabatt(wert) kann gleich in KundenArtikelRabatte (Feld "Rabatt") abgelegt werden.
Habe ich gelöscht. Ich frage mich nun allerdings, ob es überhaubt noch möglich ist, einem Kunden auf ein Produkt dauerhaft ein Rabatt zu geben? Das ging zumindest mit der Ursprungsimplementierung und ist momentan das einzige Problem.
Zitat von: DF6GL am September 28, 2020, 17:08:08MwSt in Tabelle Artikel ist obsolet (oder gibt es zu jedem Artikel eine unterschiedliche MwSt (MwStSatz) ?)
Vielen Dank für den Hinweis, werde ich später so umsetzen.
Zitat von: DF6GL am September 28, 2020, 17:08:08Für was werden Bestellstatus und Bestellungen_Positionen_Status gebraucht, dazu mit Left/Right-Join-Beziehung?
Bestellstatus dient u.a. zum Filtern für das oben genannte übersichtsformular. Z.B. wird status "Abgeschlossen" ausgeblendet.
Mit Bestellungen_Positionen_Status kann für einzelne Positionen ein Status gesetzt werden (die DB ist für eine kleine Brauerei - der Status soll für Fässer Pfand genutzt werden.
Zitat von: DF6GL am September 28, 2020, 17:08:08Alle Left/Right-Joinbeziehungen sollten in Inner-Join korrigiert werden. Die ref. Integrität der Beziehungen zu KundenArtikelRabatte fehlen.
Habe ich erledigt, danke!
Zitat von: DF6GL am September 28, 2020, 17:08:08Bei Artikel ist für Beziehungen die ArtikelID (Autowert) zu bevorzugen, nicht die evtl. alfanumerische Artikelnummer.
Die Artikelnummer hat ein numerisches System. Autowert geht hier leider nicht.
Zitat von: DF6GL am September 28, 2020, 17:08:08Weiterhin:
-- auf Sonder- und Leerzeichen dringen verzichten
-- benenne Fremdschlüsselfelder konsequent ("PKFeldname_f")
-- benenne Tabellen mit "tbl" als Prefix (--> tblKunden)
In der DB ist leider schon zu viel "drum herum". Bei der nächsten DB werde ich das berücksichtigen.
Für die Mühen hast du dir ein besonderes Bier verdient. Wo soll ich das hin schicken?
Hallo,
ZitatDie Artikelnummer hat ein Nummärisches System. Autowert geht hier leider nicht.
Natürlich geht hier der Autowert, der ist sogar zu bevorzugen, denn Zahlen als Schlüsselfelder sind bedeutend schneller und problemloser in der Handhabung. Du musst nur in der n-Tabelle ein entsprechendes Zahlenfeld anlegen, das Feld das sich auf die Artikelnummer bezieht ist dann zu löschen.
Ich habe mich nicht richtig ausgedrückt. Die Artikelnummer hat ein System, welches aus Nummern zusammengesetzt wird. So fängt sie immer mit 08 an, anschließend kommen Ziffern für Typ, Sorte und Gebinde.
Hallo,
das Alles ist kein Gegenargument für einen Autowert als ArtikelID...
ZitatDie Artikelnummer hat ein numerisches System. Autowert geht hier leider nicht.
Es soll ja auch nicht die
Artikelnummer in einen Autowert konvertiert werden... Das Feld
ArtikelID soll der Primärschlüssel vom Typ Autowert und für die Beziehungen genutzt werden.
Was die
Artikelnummer danach beinhaltet ist Jacke wie Hose. Wichtig wäre hier noch ein (zusätzlicher) eindeutiger Index auf die Artikelnummer.
ZitatSo fängt sie immer mit 08 an, anschließend kommen Ziffern für Typ, Sorte und Gebinde.
Da wäre eine Überprüfung der Normalisierung angebracht. Solche sprechenden Nummern sollten atomisiert (mit zusätzlichen Tabellen für Typ, Sorte und Gebinde) werden.
Zitatgeht momentan nicht. Es gibt ein Endlosformular (Übersicht), wo unter anderem die ersten drei Positionen einer Bestellung angezeigt werden. Beim öffnen dieses Formulars gehe ich es durch und schreibe die ersten 3 Positionen + Mengen in diese Felder um sie dann im Endlosformular anzuzeigen.
Versteh ich nicht...
Warum trägst Du die Positionen nicht gleich in die Bestellung_Positionen ein??
Zitatob es überhaubt noch möglich ist, einem Kunden auf ein Produkt dauerhaft ein Rabatt zu geben?
?? Solange ein Rabatt in KundenArtikelRabatt gespeichert ist, ist er auch verfügbar.
Versteh die Besorgnis nicht...
btw:
rsBestellungen.Fields("MengePos1") = emty
es gibt kein "emty" höchsten "Empty".
Allerdings ist
rsBestellungen.Fields("MengePos1") = NULL
"richtiger".
Deklariere numerische (Ganzzahl-)Variablen nicht mit Integer, sondern mit Long, sonst kann es unangenehme Erscheinungen geben.
Bei Floating-Point nutze Double, bei monetären Zahlen "Währung"
Bei ... As Recordset nutze den Qualifier: ... As Dao.Recordset
Du kannst mir ja eine PN schreiben.