Delphi-PRAXiS
Seite 6 von 8   « Erste     456 78      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   Fortlaufende lückenlose Rechnungsnummern (https://www.delphipraxis.net/185662-fortlaufende-lueckenlose-rechnungsnummern.html)

Captnemo 29. Jun 2015 12:40

AW: Fortlaufende lückenlose Rechnungsnummern
 
Zitat:

Zitat von jaenicke (Beitrag 1307051)
Leider müssen wir die Rechnungsnummer zum Beispiel an Kartenterminals schon vorab übertragen um dort die Zahlung hinterher zuzuordnen. Wenn die Zahlung abgebrochen wird, ist die Rechnungsnummer trotzdem vergeben.

Ich will das nicht in Frage stellen, aber wie kann eine Zahlung dokumentiert werden, wenn sie gar nicht stattgefunden hat?
Okay, ich weiß jetzt nicht, von was für einer Art Kartenterminals du redest. Aber nehmen wir mal Fahrkartenterminals o.ä., da erfolgt der Ausdruck doch erst nach der Zahlung. Da dann ein Betrag geflossen ist, ist die Rechnungsnummer auch notwendigerweise vergeben.

In meinen Rechnungsprogrammen halte ich das so: dann z.B. während der Erfassung wird eine vorläufige Rechnungsnummer vergeben, die aber aus einem anderen Nummernkreis stammt. Solange die Rechnung nicht fakturiert ist, bleibt diese auf allen Ausdrucken bestehen. Wird nun fakturiert, so wird dann aus dem regulären Nummernkreis die endgültige Rechnungsnummer vergeben. Die Zuordnung zur vorläufigen Nummer bleibt aber in der DB und man kann sie ggf. noch mal abfragen. Damit bleibe ich im offiziellen Nummernkreis lückenlos, andererseits sind Lücken im vorläufigen Nummernkreis ohne Relevanz. Nicht fakturierte Rechnungen können gelöscht werden.

jaenicke 29. Jun 2015 12:48

AW: Fortlaufende lückenlose Rechnungsnummern
 
Zitat:

Zitat von Captnemo (Beitrag 1307054)
Ich will das nicht in Frage stellen, aber wie kann eine Zahlung dokumentiert werden, wenn sie gar nicht stattgefunden hat?
Okay, ich weiß jetzt nicht, von was für einer Art Kartenterminals du redest.

Das sind Kreditkartenterminals. Dort gibt es keine andere Möglichkeit. Eine temporäre Rechnungsnummer scheidet auch aus, weil sich diese bei einer erfolgreichen Zahlung nicht mehr korrigieren lässt.

Und dazu kommen eben auch noch die Fiskalgeschichten, Hotelsysteme, ... die es ebenfalls teilweise erforderlich machen eine fertige Rechnungsnummer zu schicken ohne zu wissen, ob die Transaktion erfolgreich sein wird.

p80286 29. Jun 2015 13:01

AW: Fortlaufende lückenlose Rechnungsnummern
 
Zitat:

Zitat von Perlsau (Beitrag 1306997)
Ich kann jederzeit nachweisen, daß die Rechnung nicht bezahlt und daher storniert wurde.

??????
Ich hab Buchhaltung noch von der Pike auf gelernt. Wenn Du damals eine Rechnung ausgestellt hast, dann war die Rechnungsnummer die Nummer des Vorgangs. Wurde die Rechnung storniert, gab es eine entsprechende Gegenbuchung, aber der Vorgang blieb erhalten. Was Du machst ist "radieren" und das ist nicht so gerne gesehen!
Darum hat auch jeder Vorgang eine eigene Buchungsnummer.
(der PK ist nun mal keine Erfindung der DB Leute:stupid:)

Gruß
K-H

Perlsau 29. Jun 2015 13:26

AW: Fortlaufende lückenlose Rechnungsnummern
 
Posting gelöscht wegen eben via anonymer Email erhaltener Drohung vermutlich von einem hiesigen User, mich bei meinem zuständigen Finanzamt anzuzeigen.

baumina 29. Jun 2015 13:32

AW: Fortlaufende lückenlose Rechnungsnummern
 
Was passiert, wenn der Kunde überraschenderweise ein Jahr später doch noch bezahlt?

rokli 29. Jun 2015 13:54

AW: Fortlaufende lückenlose Rechnungsnummern
 
Hallo!

Das ist der Punkt. Wenn der Kunde nach einem Jahr zahlt, weil er z. B. nach der Leistungserbringung für 12 Monate in den Urlaub gefahren ist, dann ist bei einer stornierten Rechnung kein offener Posten mehr da.

Wenn ein Kunde endgültig nicht zahlt, dann muss der offene Posten irgendwann in der Buchhaltung ausgebucht werden, und nicht über einen Storno / Gutschrift etc. (Ertragsminderung, Korrektur der MwSt.... )

LG

p80286 29. Jun 2015 14:18

AW: Fortlaufende lückenlose Rechnungsnummern
 
Es kommt darauf an.
Zum Ende des Berichtsjahres werden die offenen Posten in die Rechnungsabgrenzung "verschoben". Je nach Gesetzeslage kannst Du dann offene Forderungen abschreiben. Sollte wider Erwarten doch noch ein Zahlungseingang erfolgen, kommt der in die sog. A(usser)O(rdentlichen)-Erträge.

(sofern das betrachtete Unternehmen groß genug ist)

Merke: in einer ordentlichen Buchhaltung geht nichts verloren!

Gruß
K-H

Rollo62 29. Jun 2015 14:20

AW: Fortlaufende lückenlose Rechnungsnummern
 
@Phoenix

Zitat:

Seit Jahren vergebe ich Rechnungsnummern immer yyyymmdd/xxx wobei xxx meist 001 ist, und falls ich doch mal mehrere Rechnungen an einem Tag schreibe habe ich für 998 andere Platz
Schöner hätte ich das nicht schreiben können.
Ich mache das Gleiche und fahre sehr gut damit.

Ich denke es geht den Behörden um Eindeutigkeit, und was gibt es Eindeutigeres als einen Timestamp.
Manchmal benutze ich Timestamps als Simple-GUUID, denn die haben auch den Vorteil das es schön lesbar ist
und auch effektiv suchbar.

Jaja, ich weiss das es Probleme geben kann wenn verschiedene Rechner verschiedene Zeiten haben,
dann muss man eben einen Timeserver nehmen.
Für meine Aufgaben, auch als Rechnungsnummer reicht das völlig.

Rollo

frankyboy1974 29. Jun 2015 16:32

AW: Fortlaufende lückenlose Rechnungsnummern
 
Hallo,

ich möchte hier nun mal auf "Nathan der Weise" von Lessing verweisen, von 42 die Quersumme ist 6 und die Hälft von 6 ist 3.:roll:

mfg

Frank

Captnemo 29. Jun 2015 16:55

AW: Fortlaufende lückenlose Rechnungsnummern
 
Zitat:

Zitat von frankyboy1974 (Beitrag 1307104)
Hallo,

ich möchte hier nun mal auf "Nathan der Weise" von Lessing verweisen, von 42 die Quersumme ist 6 und die Hälft von 6 ist 3.:roll:

mfg

Frank

Ergibt das im Zusammenhang hier einen Sinn, oder wolltest du nur auch mal was schreiben?


Alle Zeitangaben in WEZ +1. Es ist jetzt 15:47 Uhr.
Seite 6 von 8   « Erste     456 78      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz