Neue Rechnung mit bekanntem Kunden

[OrionVII]

Hallo zusammen,

Aus dem frmKunden will ich per Button das frmRechnungen öffnen und dort eine neue Rechnung mit den Kundendaten des im frmKunden ausgewählten Datensatz erstellen. frmRechnungen soll sich also öffnen, die Kundendaten sind übernommen und (ganz wichtig) eine neue RechnungsID wird vergeben. Die Rechnungsdetails im frmRechnungsdetails UFO sollen natürlich zunächst leer sein.
Wie ich den Kunden übertrage, habe ich aus dem Artikel Formulare synchronisieren von DonKarl umgesetzt. Ich muss ergo "nur noch" die Rechnungsnummer erstellen lassen und den fokus auf das erste Feld der echnungsdtail setzen.

Viele Grüße aus der Algarve

[Knobbi38]

Hallo,

eine neue Rechnungsnummer wird vorzugsweise erst beim Speichern der Rechnung erstellt, damit diese fortlaufend ohne Lücken generiert wird. Dafür ermittelt man mit DMAX() die aktuell höchste Rechnungsnummer und addiert 1 dazu.

Damit der Fokus auf ein Control im Unterformular gesetzt werden kann, muss erst das Subform-Control den Fokus erhalten und dann im zweiten Schritt das Control innerhalb der SubForm selbst. Bitte beachte, dass SubForm-Control und SubForm immer unterschiedliche Bezeichner (Name) haben sollten!

Wie ich den Kunden übertrage, habe ich aus dem Artikel Formulare synchronisieren von DonKarl umgesetzt.

Was genau meinst du damit? Der Artikel bzw. die FAQ bezieht sich eigentlich auf ein andere Aufgabestellung und ist hierfür eher weniger geeignet.

Knobbi38

Siehe auch:
http://access.mvps.org/access/forms/frm0031.htm

[MzKlMu]

Hallo,

Wie ich den Kunden übertrage,

Da 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.

Zeige bitte mal ein Bild des Beziehungsfensters.

[PhilS]

fortlaufend ohne Lücken

Nur 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. 

[MzKlMu]

Hallo,

dass die Nummern eindeutig sind, aber nicht zwingend ohne Lücken. 

Und daher könnte man auch einen Autowert als Rechnungsnummer verwenden und hätte das Problem mit der automatischen Erstellung der Rechnungsnummer damit auch gleich erledigt.

[Knobbi38]

@PhilS

fortlaufend ohne Lücken

Nur 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

[Knobbi38]

Da 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

[Bitsqueezer]

Hallo 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

[Knobbi38]

Hallo 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

[MzKlMu]

Hallo,

sondern auch um Kunden. Auch diese können z.B. anders firmieren

Dann 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.

[Knobbi38]

bestehenden 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

[trebuh]

Ich habe jetzt keine Antwort für den Fragesteller, aber Grundsätzlich zur Rechnung.

Also Lücken bei den Rechnungsnummern halte ich auch für sehr leichtsinnig.
Zum einen schaut ja der Steuerberater darauf, von wo bis wo die Rechnungsnummern des Geschäftsjahres gehen,
und zum anderen, ist so was bei einer Steuerprüfung ein gefundenes Fressen für den Prüfer.
Da könnte ja die ein oder andere Rechnung gelöscht und eventuell "Schwarz" abgerechnet worden sein?
Jedenfalls wird er schon genauer schauen.
Wenn Rechnungen einen Fehler haben, dann werden sie storniert.
Gut, im kleinen Rahmen kann man die Rechnung durch den Aktenvernichter lassen und den Rechnungsempfänger informieren, das selbe zu tun.
Aber bei größeren Firmen hast da Schwierigkeiten.
Und auf der anderen Seite, ist es ja auch programmtechnisch kein Problem.

Was auf jeden Fall sinnvoll ist, ist die erwähnte Adresstabelle.
Somit kann man einem Kunden mehrere Adressdaten zuordnen.

Als Beispiel mal ein Großwaldbesitzer.
Da kann (oder gibt es) mehrere Revierleiter.
Die Tätigkeiten sollen dann den jeweiligen Revierleitern zugeordnet werden können.

Oder anderes Beispiel, wenn die Rechnungen an eine Stadt oder Gemeinde gehen.
Mal geht die Rechnung an den Sachbearbeiter, und ein anderes Mal an einen anderen.
Das kann man dann wirklich toll über die Adresstabelle machen.

Wenn es für ein Firma einen Rechtsnachfolger gibt, und die Firma dann einen anderen Namen bekommt, so würde ich auch eine neue Kundennummer anlegen, und irgendwo in den Bemerkungen auf die alte Kundennummer (Firma verweisen).