- Welcome to Access-o-Mania.
Hilfe zu Microsoft Access und verwandten Produkten
Neueste Beiträge
#41
Access Programmierung / Re: Filter nach Wert in Zahlen...
Letzter Beitrag von TonyMotion - Januar 21, 2026, 19:00:37.
Hallo Knobbi38 und alle Anderen!
Vielen Dank für Deine Version der DB.
Mir ist aber nicht klar, welche Funktion KomID in tblKommentar hat.
Es ist ja ein Autowert.
Auch fehlt mir die Vorstellung, wie die Abfrage aussehen soll.
Hab' zwar eine erstellt, aber - siehe #3.
Wäre nett, wenn Du mir zeigen und/oder erklären könntest,
wie ein "richtiges" Datenmodell gestaltet werden muss.
Gruß! Tony
.
Hallo Knobbi38 und alle Anderen!
Vielen Dank für Deine Version der DB.
Mir ist aber nicht klar, welche Funktion KomID in tblKommentar hat.
Es ist ja ein Autowert.
Auch fehlt mir die Vorstellung, wie die Abfrage aussehen soll.
Hab' zwar eine erstellt, aber - siehe #3.
Wäre nett, wenn Du mir zeigen und/oder erklären könntest,
wie ein "richtiges" Datenmodell gestaltet werden muss.
Gruß! Tony
.
#42
Tabelle/Abfrage / Re: Tabelle Zeilen und Spalten...
Letzter Beitrag von Knobbi38 - Januar 21, 2026, 18:05:34Hallo Konni,
Access ist eine Datenbank und keine Tabellenkalkulation, deshalb gibt es in Access keinen vergleichbaren Befehl. Möglicherweise kann dir aber eine Kreuztabelle das gewünschte Ergebnis liefern.
Einfach mal im Internet danach suchen; da findest du bestimmt einen passenden Artikel.
Hier ein erster Einstieg:
https://www.access-tutorial.de/abfragen/kreuztabellenabfragen.htm
Knobbi38
Access ist eine Datenbank und keine Tabellenkalkulation, deshalb gibt es in Access keinen vergleichbaren Befehl. Möglicherweise kann dir aber eine Kreuztabelle das gewünschte Ergebnis liefern.
Einfach mal im Internet danach suchen; da findest du bestimmt einen passenden Artikel.
Hier ein erster Einstieg:
https://www.access-tutorial.de/abfragen/kreuztabellenabfragen.htm
Knobbi38
#43
Tabelle/Abfrage / Tabelle Zeilen und Spalten tau...
Letzter Beitrag von Konni - Januar 21, 2026, 17:15:39Hallo Zusammen, ich habe, so glaube ich eine ganz besondere Frage.
Ich habe eine ganz normale Abfrage mit Spalten und Zeilen sowie Rechenspalten in denen summiert wurde (z.B. Salte1 + spalte2)
Ich brauche aber diese andersrum, also die Spalten sollen Zeilen werden und der erste wert der Zeile soll Spalte werden.
In Excel mache ich das mit einem Befehl, aber in Access?
Kann mir da jemand helfen???
Ich habe eine ganz normale Abfrage mit Spalten und Zeilen sowie Rechenspalten in denen summiert wurde (z.B. Salte1 + spalte2)
Ich brauche aber diese andersrum, also die Spalten sollen Zeilen werden und der erste wert der Zeile soll Spalte werden.
In Excel mache ich das mit einem Befehl, aber in Access?
Kann mir da jemand helfen???
#44
Access Programmierung / Re: Filter nach Wert in Zahlen...
Letzter Beitrag von Knobbi38 - Januar 21, 2026, 14:33:46Hallo Tony,
dadurch wurde das Problem mit der Normalisierung der Tabellen nicht behoben.
Bezüglich der Kommentare habe ich dir das mal in dieser DB Version geändert. Eine n:m Beziehung brauchst es m.M.n. hier nicht, könntest du aber bei Bedarf dahingehen erweitern.
Knobbi38
dadurch wurde das Problem mit der Normalisierung der Tabellen nicht behoben.
Bezüglich der Kommentare habe ich dir das mal in dieser DB Version geändert. Eine n:m Beziehung brauchst es m.M.n. hier nicht, könntest du aber bei Bedarf dahingehen erweitern.
Knobbi38
#45
Formular / Re: Neue Rechnung mit bekannte...
Letzter Beitrag von Knobbi38 - Januar 21, 2026, 14:26:36Zitat von: MzKlMu am Januar 21, 2026, 13:58:01bestehenden Kunden einfach zu überschreiben ist dann buchhalterich auch nicht richtig.
Das wird nur in den Stammdaten geändert, nicht in den Belegen für die Buchhaltung, also alles ok.
Sicherlich kann man das auch anders lösen, aber wenn es sich um einen Rechtsnachfolger handelt, sollen ja gerade alle Vereinbarungen, Statistiken usw. beibehalten werden bzw. eine Zuordnung soll weiterhin möglich sein. Hier einfach einen neuen Kunden in den Stammdaten aufzunehmen, ist möglicherweise nicht so einfach bzw. praktikabel, was nicht heißt, daß man das bei der Neuanlage nicht auch übernehmen könnte, aber das wäre dann wirklich redundant.
Gruß Knobbi38
#46
Formular / Re: Neue Rechnung mit bekannte...
Letzter Beitrag von MzKlMu - Januar 21, 2026, 13:58:01Hallo,
Zitatsondern auch um Kunden. Auch diese können z.B. anders firmierenDann wäre es sinnvoll, einen "neuen" Kunden anzulegen mit einer neuen ID. Änderungen müssen ja auch möglicherweise nachverfolgbar sein. Und dann einen bestehenden Kunden einfach zu überschreiben ist dann buchhalterich auch nicht richtig.
#47
Formular / Re: Neue Rechnung mit bekannte...
Letzter Beitrag von Knobbi38 - Januar 21, 2026, 13:42:15Hallo Christian,
natürlich ist es gut, wenn Daten nicht redundant gespeichert werden. Es geht aber nicht nur um die Adresspflege, sondern auch um Kunden. Auch diese können z.B. anders firmieren und dann müsstest du dieses auch noch verwalten.
Wie gesagt, kann man alles mit zusätzlichem Aufwand verwalten. Aus meiner Praxis heraus kann ich aber nur sagen, dass dieser Verwaltungsaufwand oft nicht betrieben und einfach kopiert wird. Das vereinfacht den Prozess bei den Übernahmen von Bestellung->Auftrag->Lieferschein->Rechnung->Buchhaltung und ggf. Mahnwesen enorm. So kann auch der Prozess mit abweichender Rechnungs-/Lieferanschrift relativ einfach gehalten werden. Es ist ja keine echte Redundanz im eigentlichen Sinne und ist hier ausdrücklich erwünscht.
Bei den heutigen Speicherressourcen in einer DB spielt dieses Kopieren eigentlich keine Rolle mehr, der zusätzliche Verwaltungsaufwand aber schon.
Gruß Knobbi38
natürlich ist es gut, wenn Daten nicht redundant gespeichert werden. Es geht aber nicht nur um die Adresspflege, sondern auch um Kunden. Auch diese können z.B. anders firmieren und dann müsstest du dieses auch noch verwalten.
Wie gesagt, kann man alles mit zusätzlichem Aufwand verwalten. Aus meiner Praxis heraus kann ich aber nur sagen, dass dieser Verwaltungsaufwand oft nicht betrieben und einfach kopiert wird. Das vereinfacht den Prozess bei den Übernahmen von Bestellung->Auftrag->Lieferschein->Rechnung->Buchhaltung und ggf. Mahnwesen enorm. So kann auch der Prozess mit abweichender Rechnungs-/Lieferanschrift relativ einfach gehalten werden. Es ist ja keine echte Redundanz im eigentlichen Sinne und ist hier ausdrücklich erwünscht.
Bei den heutigen Speicherressourcen in einer DB spielt dieses Kopieren eigentlich keine Rolle mehr, der zusätzliche Verwaltungsaufwand aber schon.
Gruß Knobbi38
#48
Formular / Re: Neue Rechnung mit bekannte...
Letzter Beitrag von Bitsqueezer - Januar 21, 2026, 13:13:32Hallo Ulrich,
und in einer ordentlichen Datenbank erstellt man eine Adresstabelle und die AdressID kommt in die Rechnung. Ändert sich die Kundenadresse, wird eine neue AdressID erstellt und die alte Adresse bleibt, wie sie ist. Alte Rechnungen haben die alte AdressID und zeigen nach wie vor auf die gleichen Daten. Die KundenID bleibt grundsätzlich unverändert und kommt auch in die Rechnung.
Daten redundant zu halten, ist nicht notwendig, auch in diesem Fall nicht.
Es kommt aber auf den Fall an: Wenn man ein kleines Unternehmen mit überschaubarer Anzahl Kunden hat, machen sich viele den Aufwand von Adresspflege nicht und kopieren die Daten in redundante Felder bzw. erfassen sie sogar jedesmal manuell - alles schon gesehen.
Ich würde allerdings immer eine Adresstabelle verwenden. Diese kann dann über ein Adresstyp-Feld auch andere Adressen wie Lieferanten usw. verwalten, denn auch hier sieht man oft das Konstrukt, daß jede Tabelle, die eine Adresse benötigt, die Adressfelder nochmal erstellt.
Eine Adresstabelle hat daneben auch den Vorteil, zu einem Kunden (Lieferanten etc.) mehr als eine Adresse aktiv vorhalten zu können, so daß man bei Rechnungserstellung oder Lieferscheinerstellung die passende auswählen kann, ebenso eine als Standard definiert werden kann usw.
Zur Rechnungsnummer würde ich allerdings auch sehr genau darauf achten, daß die Nummern lückenlos sind, selbst wenn es gesetzlich nicht gefordert ist. Sonst könnte man Rechnungen erstellen und abrechnen und die Rechnung löschen. Den Abgleich des Rechnungsempfängers mit der Rechnungsnummer des Versenders seitens Finanzamt wird man dort wohl kaum machen. Und zu erklären, warum die Rechnungsnummer fehlt, hinterläßt u.U. keinen guten Eindruck beim Prüfer...
Ich würde hier ebenfalls immer eine Zählertabelle verwenden, die erst unmittelbar vor dem Speichern eine neue Nummer zieht und hier ablegt. Die DMAX-Methode ist beliebt, aber bei vielen Usern gleichzeitig bisweilen fehlerhaft (alles schon gehabt in der Praxis).
Eine ID sollte man generell nicht für "echte" Informationen verwenden, das rächt sich meistens irgendwann aus verschiedenen Gründen. Eine ID soll einen Datensatz eindeutig identifizieren und ansonsten keine Bedeutung haben.
Nur meine Meinung natürlich.
Gruß
Christian
und in einer ordentlichen Datenbank erstellt man eine Adresstabelle und die AdressID kommt in die Rechnung. Ändert sich die Kundenadresse, wird eine neue AdressID erstellt und die alte Adresse bleibt, wie sie ist. Alte Rechnungen haben die alte AdressID und zeigen nach wie vor auf die gleichen Daten. Die KundenID bleibt grundsätzlich unverändert und kommt auch in die Rechnung.
Daten redundant zu halten, ist nicht notwendig, auch in diesem Fall nicht.
Es kommt aber auf den Fall an: Wenn man ein kleines Unternehmen mit überschaubarer Anzahl Kunden hat, machen sich viele den Aufwand von Adresspflege nicht und kopieren die Daten in redundante Felder bzw. erfassen sie sogar jedesmal manuell - alles schon gesehen.
Ich würde allerdings immer eine Adresstabelle verwenden. Diese kann dann über ein Adresstyp-Feld auch andere Adressen wie Lieferanten usw. verwalten, denn auch hier sieht man oft das Konstrukt, daß jede Tabelle, die eine Adresse benötigt, die Adressfelder nochmal erstellt.
Eine Adresstabelle hat daneben auch den Vorteil, zu einem Kunden (Lieferanten etc.) mehr als eine Adresse aktiv vorhalten zu können, so daß man bei Rechnungserstellung oder Lieferscheinerstellung die passende auswählen kann, ebenso eine als Standard definiert werden kann usw.
Zur Rechnungsnummer würde ich allerdings auch sehr genau darauf achten, daß die Nummern lückenlos sind, selbst wenn es gesetzlich nicht gefordert ist. Sonst könnte man Rechnungen erstellen und abrechnen und die Rechnung löschen. Den Abgleich des Rechnungsempfängers mit der Rechnungsnummer des Versenders seitens Finanzamt wird man dort wohl kaum machen. Und zu erklären, warum die Rechnungsnummer fehlt, hinterläßt u.U. keinen guten Eindruck beim Prüfer...
Ich würde hier ebenfalls immer eine Zählertabelle verwenden, die erst unmittelbar vor dem Speichern eine neue Nummer zieht und hier ablegt. Die DMAX-Methode ist beliebt, aber bei vielen Usern gleichzeitig bisweilen fehlerhaft (alles schon gehabt in der Praxis).
Eine ID sollte man generell nicht für "echte" Informationen verwenden, das rächt sich meistens irgendwann aus verschiedenen Gründen. Eine ID soll einen Datensatz eindeutig identifizieren und ansonsten keine Bedeutung haben.
Nur meine Meinung natürlich.
Gruß
Christian
#49
Formular / Re: Neue Rechnung mit bekannte...
Letzter Beitrag von Knobbi38 - Januar 21, 2026, 12:55:22Zitat von: MzKlMuDa muss gar nix übertragen werden, außer dem Schlüsselfeld (KdNr wahrscheinlich) des Kunden. Die restlichen Kundendaten werden dann nur mit einer Abfrage im Formular dargestellt.
In einer ordentlichen Buchhaltung wird so etwas nicht gemacht, denn wenn sich die Kundendaten ändern, würden dann auch alte Rechnungen verändert werden - was nicht sein darf !!!
Deshalb werden die Kundendaten grundsätzlich an dem aktuellen Zeitpunkt der Rechnungsstellung in den Rechnungskopf aus den Stammdaten heraus übernommen und kopiert.
Knobbi38
#50
Formular / Re: Neue Rechnung mit bekannte...
Letzter Beitrag von Knobbi38 - Januar 21, 2026, 12:48:01@PhilS
Das ist zwar letztendlich richtig, aber wenn Lücken sind, kann auch angenommen werden, dass diese einfach gelöscht worden sind - Nachfragen bei einer Buchprüfung sind hier ziemlich sicher. Übrigens ist das Urteil aus 2008.
Hier mal eine etwas neuerer Kommentar von Haufe und dort gibt es immer noch die Einschränkung, dass das zunächst mal nur für eine Gewinnermittlung per Einnahmen-Überschussrechnung gilt, weil die Vorgaben aus dem Umsatzsteuerrecht bezügl. der Vorsteuer dem entgegen stehen - also auf das schmale Brett würde ich mich nicht begeben und Lücken, wenn vielleicht auch rein vorsorglich, vermeiden, was ja relativ einfach möglich ist.
https://www.haufe.de/finance/steuern-finanzen/rechnungsnummern-das-recht-auf-luecke_190_462304.html
@MzKlMu
Oft werden Nummernkreis für Rechnungsnummern verwendet. Autowert ist da nicht so toll und wird in der Praxis eher selten bis gar nicht verwendet, obwohl es theoretisch möglich wäre.
Knobbi38
Zitat von: PhilS am Januar 21, 2026, 12:21:53Zitat von: Knobbi38 am Januar 21, 2026, 10:15:07fortlaufend ohne LückenNur am Rande: Das ist ein rein kosmetisches Problem.
Es gibt von der Oberfinanzdirektion Koblenz eine offizielle Erläuterung (AZ: S 7280 A - St. 44 5.), in der klargestellt wird, dass der Begriff "fortlaufend" in Gesetzestexten zu Belegen und Rechnungen bedeutet, dass die Nummern eindeutig sind, aber nicht zwingend ohne Lücken.
Das ist zwar letztendlich richtig, aber wenn Lücken sind, kann auch angenommen werden, dass diese einfach gelöscht worden sind - Nachfragen bei einer Buchprüfung sind hier ziemlich sicher. Übrigens ist das Urteil aus 2008.
Hier mal eine etwas neuerer Kommentar von Haufe und dort gibt es immer noch die Einschränkung, dass das zunächst mal nur für eine Gewinnermittlung per Einnahmen-Überschussrechnung gilt, weil die Vorgaben aus dem Umsatzsteuerrecht bezügl. der Vorsteuer dem entgegen stehen - also auf das schmale Brett würde ich mich nicht begeben und Lücken, wenn vielleicht auch rein vorsorglich, vermeiden, was ja relativ einfach möglich ist.
https://www.haufe.de/finance/steuern-finanzen/rechnungsnummern-das-recht-auf-luecke_190_462304.html
@MzKlMu
Oft werden Nummernkreis für Rechnungsnummern verwendet. Autowert ist da nicht so toll und wird in der Praxis eher selten bis gar nicht verwendet, obwohl es theoretisch möglich wäre.
Knobbi38