Rechnungsnummer: Folgende zeichen sind zugelassen

[#1]

Ich hab eine Rechnungsnummer wie sie oben im Feld der Rechnungsnummer drin steht. Leider will DUO das so nicht haben. Gibt es dafür sachliche Gründe? Was spricht denn gegen Punkte in der Rechnungsnummer?

[#2]

Hallo Herr Ruzycki,

die Punkte (.) in der Rechnungsnummer können bei der späteren Verarbeitung im Rechnungswesen-Programm nicht verwendet werden - deshalb ist der Punkt auch in Unternehmen online nicht möglich. Statt das Punktes empfehle ich Ihnen den Bindestrich zu verwenden.

Viele Grüße

Christian Wielgoß

[#3]

Genau diese Frage stelle ich mir auch.

Immer wenn ich Daten vom Mandanten einspiele und der Punk in der Rechnungsnummer durch ein % ersetzt wird.

Auf der OPOS-Liste sieht das auch schon immer echt blöd aus...

[#4]

Hallo Herr Ruzycki,

die Punkte (.) in der Rechnungsnummer können bei der späteren Verarbeitung im Rechnungswesen-Programm nicht verwendet werden - deshalb ist der Punkt auch in Unternehmen online nicht möglich. Statt das Punktes empfehle ich Ihnen den Bindestrich zu verwenden.

Viele Grüße

Christian Wielgoß

Es ist doch nicht meine Entscheidung ob ich einen Punkt oder was andere nehme. Das hat doch der Rechnungsaussteller entschieden.

Was mir da direkt in den Kopf schießt:

Wie soll ich so eine Rechnung wiederfinden?

Ist das GobD?

Durch was ersetzte ich den Punkt?

Wie teile ich das jedem mit?

Soll ich dem Rechnungsaussteller mitteilen, dass mein Rechnungsprogramm seine Rechnung nicht verarbeiten kann?

[#5]

Hallo Herr Ruzycki,

mehr als die oben genannte Info kann ich Ihnen hierzu auch nicht geben.

Viele Grüße

Christian Wielgoß

[#6]

Hallo,

eine Rechnungsnummer mit Punkten ist eher die Ausnahme als die Regel. Bis heute wurde von keinem Anwender die Implementierung von Punkten oder Kommata in der Rechnungsnummer nachgefragt. Ihren Wunsch dazu haben wir neu angelegt.

Eine Änderung des Datenelements Rechnungsnummer bedingt nicht nur Anpassungen in Vorsystemen (auch Schnittstellen wie DCO und DXsO sind betroffen), sondern auch nachgelagerte Systeme, z.B. alle DATEV Rechnungswesen-Programme (Belegfeld1) müssten angepasst werden.

Wir vestehen, dass das für Sie ärgerlich ist, aber bitten um Ihr Verständnis, dass der Gesamtnutzen für alle Anwender gemessen am enormen Entwicklungsaufwand aus unserer Sicht unverhältnismäßig erscheint und wir den Wunsch bis auf Weiteres nicht umsetzen werden.

Viele Grüße

Silvija Radicek

[#7 · Accepted solution]

Da es gegen keine Regel verstößt in einer Rechnungsnummer Kommata oder Punkte zu verwenden, stellt sich hier natürlich die Frage, warum an dieser Stelle eine Fehlermeldung hochkommt. Es stellt sich gar nicht die Frage wie oft in der Praxis Rechnungsnummern diese Zeichen enthalten. Fakt ist, es ist nicht verkehrt und es kommt in der Praxis vor!

Der Anwender macht an dieser Stelle alles richtig. Ein klassisches Beispiel für nicht ganz so gelungenes UI-Design. Einschränkungen der Anwendung als Fehler des Anwenders deklarieren.

Wie würde ich aus meiner Entwicklersicht dieses Problem lösen? Zwei Ansätze:

1) Wenn an dieser Stelle eine technische Notwendigkeit bestehen würde, zu verhindern . und , einzugeben, dann einfach genauso wie in Kanzlei-Rechnungswesen vorsehen, die entsprechenden Zeichen durch das %-Zeichen auszutauschen. Dies lässt sich ohne großen Aufwand realisieren. Der Anwender wird nicht zum Idioten gestempelt und man hätte auch eine gewisse Durchgängigkeit in den DATEV-Programmen.

2) In vielen Programmiersprachen (einschließlich SQL-Datenbanken) verwendet man an dieser Stelle den Variablen-Typ string. Von Haus aus können hier alle Unicode-Zeichen, die darstellbar sind ohne weitere Probleme verarbeitet werden. Wie halt auch . und ,.

Möchte man die Eingabemöglichkeiten hier einschränken, ist wieder weiterer Programmieraufwand erforderlich um die Eingabe zu validieren und auftretende Exceptions bei falscher Eingabe abzufangen.

Eine E-Mail Adresse wird ebenfalls als String behandelt, wird aber validiert um sicherzustellen, dass z. B. ein @ vorhanden ist. An der Stelle auf jeden Fall sinnvoll.

Angefangen von Kanzlei-Rechnungswesen als "Verursacher" stellt sich die Frage warum man Dinge einschränkt, die gar nicht sinnvoll und notwendig sind?

Den Rattenschwanz an Programmierung um . und , als nicht zulässige Zeichen auszusortieren, hätte man sich sparen können (Da liegt die eigentliche Zeitverschwendung - Nicht in der Behebung).

Auch das ist wieder einfach auszubauen und erspart anderen Entwicklern, die im Bereich Schnittstellen unterwegs sind entsprechend Zeit.

Freundliche Grüße
Sven Ehlers

[#8]

@Sven Ehlers: Sehe ich genauso.

Die Antwort der Datev spricht aber Bände. Aber ich wundere mich über gar nix mehr.

Das geilste für mich ist, dass meine Fragen wie damit umgegangen werden soll einfach mal unbeantwortet bleiben.

[#9]

Hallo zusammen, hat sich an dieser Thematik etwas geändert? Ich nutze den DATEV Belegtransfer 5.41 um meine Belege aus meinem WWS in Kombination mit abgelegten PDF-Rechnungen im DUO Ordner in meine Buchhaltung zu befördern und habe mich gewundert als so viele Belege abgelehnt wurden.

Gibt es hier ggf. einen Work-Around? Ich habe alleine in diesem Jahr bereits 48 Eingehende-Rechnungen (ca. 10% des aktuellem Volumens) die durch obiges Problem nicht importiert werden können, von einem Einzelfall ist also nicht auszugehen.

Viele Grüße
Philipp Heikes

[#10]

Was @Silvija_Döbereiner  nicht sagt, wozu wurde der Punkt als mögliches Zeichen aussortiert?

Nur weil er (möglicherweise, denn ich finde Punkte in diesem Zusammenhang nicht als abwegig) selten benutzt werden (soll), ist keine Erklärung. Dass das Belegfeld 1 einstmals ein bestimmtes Format bekam und seitdem daran festgehalten wird? Schon eher möglich. Doch warum? In 2018 müssten noch Kapazitäten vorhanden gewesen sein, dies zu ändern. Und die zulässigen Zeichen werden sicherlich von Anwendung zu Anwendung vererbt. D.h. einmal verändert, sollte dies für Belegfeld 1 und alle Anwendungen die Belegfeld1 nutzen bzw. Einträge generieren durch gehend gelten. Ich kann da nicht den Programmieraufwand erkennen.

Also lautet die Frage: Aus welchem Grund wurde der Punkt aussortiert?

QJ

[#11]

---

@quantenjoe  schrieb:

Also lautet die Frage: Aus welchem Grund wurde der Punkt aussortiert?

---

Ich tippe auf: das war in den ganz frühen Zeiten der Großrechner und Lochkarten aus irgendeinem Grund notwendig. Und dann wurde es nicht mehr hinterfragt, weil "das haben wir immer schon so gemacht". Bleibt zu hoffen, dass sich bei RWOn (irgendwann) die "Modernisierer" gegenüber den "Traditionalisten" durchsetzen können und alle solcher Obskuritäten nochmal auf den Prüfstand kommen.

[#12]

---

@seprof  schrieb:

1) Wenn an dieser Stelle eine technische Notwendigkeit bestehen würde, zu verhindern . und , einzugeben, dann einfach genauso wie in Kanzlei-Rechnungswesen vorsehen, die entsprechenden Zeichen durch das %-Zeichen auszutauschen. Dies lässt sich ohne großen Aufwand realisieren. Der Anwender wird nicht zum **bleep**en gestempelt und man hätte auch eine gewisse Durchgängigkeit in den DATEV-Programmen.

2) In vielen Programmiersprachen (einschließlich SQL-Datenbanken) verwendet man an dieser Stelle den Variablen-Typ string. Von Haus aus können hier alle Unicode-Zeichen, die darstellbar sind ohne weitere Probleme verarbeitet werden. Wie halt auch . und ,.

---

Sympathische Lösungsansätze, allerdings wäre es dann ja so, dass bei solchen Belegen die Rechnungsnummer in Unternehmen Online von der Eintragung in Belegfeld 1 abweicht, richtig?

Das kann meiner Meinung nach auch zu Verwirrungen führen.

Mein Vorschlag: Diese Lösung, in Rechnungswesen unzulässige Zeichen zu erlauben und bei der Übergabe zu ersetzen, als auswählbare Option anbieten, mit einer schönen dicken Warnung, dass dadurch Rechnungsnummer UO und Belegfeld 1 ReWe voneinander abweichen.

Ich selbst würde sie vermutlich nicht wählen, die Übereinstimmung zwischen den Programmen fühlt sich für mich wichtiger an, als dem Syntax eines Lieferanten bis ins Detail zu entsprechen.

[#13]

---

@Silvija_Döbereiner  schrieb:

Hallo,

eine Rechnungsnummer mit Punkten ist eher die Ausnahme als die Regel.

---

Bei solchen Aussagen wünsche ich der DATEV, dass sie ihre "technical debt" / "technical burden" auf der Passivseite der Bilanz ausweisen muss.

Stellen Sie sich vor, Sie geben in einen Taschenrechner 1x1 ein, und der liefert Ihnen "Error" - dann kommt als Ausrede vom Hersteller "Da 1x1 ohnehin 1 ergibt ist die Multiplikation von 1 und 1 bei unseren Nutzern eher die Ausnahme als die Regel." Nein, das ist einfach "bad design", und damit ist Ihr Laden randvoll.

Ergänzung: viele, viele Open Source Projekte (und auch einige Closed Source Projekte) haben "Bug tracker", "Feature request tracker" usw. Wie wäre es, wenn die Datev so etwas einrichten würde. Dann könnte hier in der Community anstelle irgendeiner halbgaren Ausrede der Verweis auf "Ja, kennen wir, ist hier erfasst und da steht auch, wieso es (noch) nicht umgesetzt ist" geposted werden - das wäre mal vertrauensstiftend.

[#14]

---

@quantenjoe  schrieb:

[...]

Also lautet die Frage: Aus welchem Grund wurde der Punkt aussortiert?

[...]

... ich 'glaube', dass Punkte in Rechnungsnummern unzulässig sind, weil die überintelligente Software eine solche Zeichenkette dann als Zahl interpretieren könnte bzw. die Punkte als Dezimalzeichen oder als Tausender-Trennzeichen

... und das würde dann das gesamte Rechnungswesen 'verunsichern' 😂
(wie es Thomas De Maizière vielleicht formulieren würde)

[#15]

Hallo @PhilippHeikes 

es hat sich nichts geändert. Wir orientieren uns an Kanzlei-Rechnungswesen:

Das Sonderzeichen "." (Punkt) ist 'technisch' ein Trennzeichen und ist deshalb in Kanzlei-Rechnungswesen beim Belegfeld1 als Sonderzeichen  ausgeschlossen.

Wir passen uns an das Programmverhalten von Rechnungswesen an, damit die Belege im Rechnungswesen-Programm auch verarbeitet werden können. 

[#16]

Unabhängig von § 14 Abs. 4 UStG müssen ja auch Rechnungen aus dem Ausland in Deutschland verarbeitet werden können. Dies kann nur durch eine eindeutige Regulierung durch die Finanzverwaltung erfolgen, die den Umgang mit Rechnungsnummer aus dem Ausland eindeutig anordnet.

Das ist leider nicht trivial, aber auch nicht die Aufgabe außerhalb von unserer Finanzbehörde zu lösen.

Meines Wissens ist das aktuell nicht reguliert und somit können Rechnungsnummern allerlei Zeichen enthalten und sind auch nicht in der Länge begrenzt.

Eine Nummer kann per Definition auch alphanumerisch Zeichen enthalten.

Somit auch Satzzeichen wie ein Punkt, Klammern, etc.

Bei der Erfassung dieser sollte man diese daher auch möglichst nicht verändern (müssen).

Die E-Rechnung definiert hier mit BT-1 (Invoice number):
"Eine eindeutige Kennung der Rechnung, die diese im System des Verkäufers identifiziert. Anmerkung: Es ist kein „identification scheme“ zu verwenden.".

Für mich (als Laie) ist hier entgegen § 14 Abs. 4 UStG kein Fortläufigkeit gefordert, noch eine Anforderung an den Zeichensatz.

Die Eindeutigkeit einer Kennung einer Rechnung muss das Ziel haben - global verarbeitungsfähig zu sein.
Zumindest ein vorgebender Zeichensatz und eine Länge sollten international für die eindeutige Kennung der Rechnung geregelt werden.

[#17]

Hallo Frau @Silvija_Döbereiner ,

Ich finde, das ist wieder die typische Datev-Antwort. Nur weil sich wenige (wie viele?) beschweren, wird DATEV nichts unternehmen. DATEV wird sich nicht einmal ansatzweise mit dem Problem beschäftigen.

Die Anwender wenden sich nicht an DATEV, weil die einzelne Meinung offensichtlich nicht ernst genommen wird.

Ab wieviel Beschwerden wird "nachgedacht" und ab wieviel wird reagiert (in wieviel Jahren)?

Wir fliegen zwar zum Mond, aber ein Komma oder ein Punkt ist für ein großes Softwarehaus technisch nicht umsetzbar.

Aber was soll's, ich bin nur Steuerberater und kein IT'ler.

Gruß

Martin Heim

[#18]

... mit Hilfe der guten alten Prozentrechnung kann die Datev immer nachweisen, dass sich nur ein sehr kleiner Prozentsatz der Mitglieder beschwert hat, ganz egal, ob es 10 oder 100 oder 1000 Beschwerden waren. Der Anteil an der Gesamtanzahl der Mitglieder bliebt immer noch verschwindend gering

... und so kann man nach Gutsherrenart frei entscheiden, ob man das eine oder andere Problem(chen) beheben will oder lieber nicht, je nachdem, ob es mehr oder weniger nach Aufwand riecht

[#19]

Vielleicht ist es auch der fehlende Wille zur Innovation.

Kann uns die DATEV nicht mal überraschen und von sich aus etwas Logisches, neues und bahnbrechendes programmieren?

Innovation gibt es überall, sogar bei meinem Bäcker um die Ecke. Aber was will ich von einem Unternehmen erwarten, das in seinen Rechnungsnummern immer noch die vierstellige Jahreszahl verwendet.

Gruß

Martin Heim

[#20]

ich glaube, dass die Datev mit einigen Kernanwendungen programmiertechnisch in einer Sackgasse steckt und zwar in einer 'Sackgasse ohne Wendemöglichkeit'.

Die Datev müsste mE eigentlich einige Kernanwendungen komplett neu entwickeln und die bisherigen CashCows auf den 'Gnadenhof' schicken.

Aber dann würde die Datev bei diesen Anwendungen programmiertechnisch bei Null beginnen und man hätte auf breiter Front Effekte wie bei "Auftragswesen Next", bloß wesentlich gravierender, weil dann jedes Datev-Mitglied davon betroffen wäre und nicht nur die relativ wenigen Unternehmen, die in "Auftragswesen Next" (noch) eine brauchbare und günstige Lösung zu sehen glauben.

Aus meiner Sicht müsste die Datev ein bewährtes, modernes, komplettes Steuersoftwarepaket einkaufen und meinetwegen unter dem Label "DATEV" an die StBs, StBins, WPs, WPins, RAs und RAins und deren Mandanten bringen.

(auf den Hinweis: "handmade by Datev" kann man gut verzichten)

[#21]

Hallo Frau @Silvija_Döbereiner ,

liege ich mit der Vermutung richtig, das noch Cobol-Programmierung zur Verarbeitung der Rechnungswesendaten im RZ verwendet wird? Dann würde ihre Aussage tatsächlich Sinn ergeben.

Deswegen kann ich dann im Belegfeld1 auch keine Leerzeichen verwenden. Richtig?

Freundliche Grüße 

Sven Ehlers

[#22]

fino taxtech; zum Beispiel.

😂😂😂

[#23]

---

@seprof  schrieb:

Hallo Frau @Silvija_Döbereiner ,

liege ich mit der Vermutung richtig, das noch Cobol-Programmierung zur Verarbeitung der Rechnungswesendaten im RZ verwendet wird? Dann würde ihre Aussage tatsächlich Sinn ergeben.

Deswegen kann ich dann im Belegfeld1 auch keine Leerzeichen verwenden. Richtig?

Freundliche Grüße 

Sven Ehlers

---

@seprofMit der Vermutung liegen fast richtig, aber nur fast.

Die Ursache liegt tatsächlich in der von @Silvija_Döbereiner Nutzung als Steuerzeichen. DATEV hat, wie alle Anwender im Web, das Problem mit den unterschiedlichen Zeichentabellen. Am universellsten ist tatsächlich das gute, alte ASCII - und da sind im universellen Teil die Sonderzeichen nicht enthalten, aus dem Zeichensatz werden aber noch die Trennzeichen benötigt. Die Trennzeichen wurden mal mit Komma, Semikolon etc. festgelegt.

Wenn nun, und DATEV arbeitet gern damit, eine csv Datei genutzt wird um irgendwas einzulesen, stört in einem Datenfeld natürlich ein Steuerzeichen. Da csv ja "comma separated values" bedeutet würde ein in einem Datenfeld enthaltenes Komma (oder bei uns häufiger genutzt, Semikolon) natürlich die Trennung auslösen.

Die Erklärung ist bewusst sehr einfach gehalten da es nur die Ursache darstellen soll.

Eigentlich sollt DATEV in den Cloud basierten Diensten schon modernere Mechanismen verwenden da die Digitalisierung ja nun nicht mit großem Aufwand rückwärtsgerichtete Umwandlungen eigentlich vermeiden sollte.

Aber DATEV arbeitet ja nicht in der Cloud sondern im guten, alten Rechenzentrum. Bis DATEV modern ist, ist der Cloud Hype schon lange Geschichte.

[#24]

Excel lässt sich aber auch ganz gerne durch Punkte, Kommata, Semikola, Bindestriche etc. 'verunsichern' und zu 'überintelligenten' (und teilweisen falschen) Konvertierungen verleiten

.... eigentlich sollte doch ein Feld, das als Textfeld definiert ist, alle ASCII-Zeichen 'fressen' die ihm vorgesetzt werden

... und wenn in der CSV-Datei Textfelder und am besten auch Datumsfelder grundsätzlich von Anführungszeichen eingeschlossen wären, sollten auch Leerzeichen und Sonderzeichen möglich sein

[#25]

Hallo Frau Döbereiner,

vielen Dank für die Rückmeldung. Nun kann ich natürlich besser verstehen warum es hier Probleme gibt.

Kann Datev hier einen Lösungsansatz bieten? 

Eine von Ihnen standardisierte Lösung, die am besten im System integriert wäre, hätte einige positive Aspekte:
1. Nicht jeder Mandant müsste in Absprache mit seinem Steuerberater dieses Thema durchgehen.
2. Kostenaufwändige Anpassungen von Schnittstellen (wie diese uns nun bei uns anstehen) würden beim Nutze von Datev wegfallen.

3. Standardisierung hat den Vorteil das die Steuerberater oder deren Fachkräfte sich bei Abweichungen nicht bei jedem Mandanten weniger auf mögliche Quellen der Differenzen der Rechnungsnummern einstellen müssen. 

Bestimmt finden sich noch weitere Positive Punkte für eine Umsetzung aus Ihrem Haus.

Hier wurden bereits einige Möglichkeiten der Verarbeitung genannt.