Datenvisualisierung Rechnung

[#1]

---

@Slawomir_Procelewski  schrieb:
[...]

Das aktuelle Design der Rechnungsvisualisierung wurde bereits im Herbst des letzten Jahres im Rahmen eines Kundeneinbezugs verschiedenen Kunden vorgestellt. Leider wurden nicht alle Mängel sofort erkannt. Alle Anpassungen und Korrekturen müssen jedoch zum generellen UX-Konzept passen. Aus diesem Grund können Änderungen, selbst wenn sie klein erscheinen, nicht sofort umgesetzt werden.

---

Drei kurze Anmerkungen dazu:

• Schön das sich da was bewegt.
• Wenn die Designmängel trotz Kundeneinbezug nicht erkannt worden sind, dann überdenkt bitte mal die Zusammensetzung der Kunden-/Testgruppe.
  (Und Bitte kauft euren UX/UI Designern Bildschirmarbeitsplatzbrillen: Denn die Fehler sind WIRKLICH offensichtlich. Aber bitte vor Erwerb der Brillen ärztliche Atteste einholen, den sonsts gibt es später Probleme bei der Prüfung etc. pp.; Ja, dass war jetzt überspitzt)
• Was soll die Aussage "... müssen zum generellen UX-Konzept passen"?
  Bitte versteht, dass dem Anwender (also wir, das Buchhalterfußvolk) die Optik schnurz ist. Egal ob die Kästchen die richtige Rundung haben und optisch ansprechendern Whitspace zwischen den Zeilen ist. Und absolut egal  ob das zum Designkonzept der DATEV passt. Effizente Wahrnehmung über Optik bitte. Aoh, und checkt mal bitte die Schriftart. Es gibt mit Sicherheit leserliches als den Font der zur Zeit verwendet wird.

[#2]

Guten Tag,

ja die Beiträge haben sich überschnitten

---

@Slawomir_Procelewski  schrieb:

Guten Tag @deusex ,

Einige Ihrer Fragen habe ich bereits im vorherigen Beitrag beantwortet. Zu den weiteren Fragen:

1. Sichtkomponente einer ZUGFeRD-Rechnung: Diese ist als Anhang in jeder Rechnungsvisualisierung verfügbar. Die Anhänge sind separat im DMS Viewer sichtbar. Es ist lediglich erforderlich, den Anhang "_Sichtkomponente" anzuklicken, anstatt durch die gesamte Rechnung zu scrollen.

2. Schriftgrößen: Wir werden die Schriftgrößen erneut überprüfen.

---

Danke für den Supertipp:

Jetzt wähle ich mittels Vorschau in der DokVerw eine Rechnung aus, klicke auf den Reiter Anlagen und klicke nochmals auf Sichtkomponente.

Damit ich wieder "aktiv" in die DokVerw komme, klicke ich also in der DokVerw auf die nächste Rechnung, welche natürlich wieder mit der Visualisierung öffnet und das Spiel geht von vorne los.

Echt jetzt ?!

Sehen Sie Herr @Slawomir_Procelewski , es ist genau das, was ich beschrieben habe, dass auf Seiten der Programmgestaltung offenbar keine Ahnung herrscht, wie die Arbeitsabläufe in der Praxis ausschauen.

So schlagen Sie mir also eine Klickorgie vor, wenn ein einfaches Durchscrollen per Vorschau DAP (Dokumente) gewünscht ist, um die Wesentlichen Informationen einer Rechnung auf Seite 1 der Visualisierung zu sehen.

Wer hat nur den VAZ oder den Bearbeitungszeitraum bei LoBu und FiBu, als weniger wichtig eingstuft ?

Das lassen wir nun so stehen und wie sagt man so schön: Da ist noch reichlich Luft nach oben !

Sie dürfen mir glauben: Ich schlage mich nun seit 13 Jahren mit den DATEV-Online-Anwendungen herum und hatte lange Jahre einen regen Austausch mit der DATEV und habe auch gerne bei der Weiterentwicklung unterstützt, aber ebensolche "Tipps" und die Ignoranz brachten mich dazu, meine Nerven zu schonen und mich zurückzuziehen.

Mich interessiert die Sichtkomponente nicht und die sollte auch nicht interessieren, da sie rechtlich irrelevant ist und ausschließlich die Daten der Visualisierung zu prüfen sind.

In diesem Fall stellt m.E. die korrekte Angabe von VAZ bzw. Abrechnungsmonat sogar den Bestandteil nach §14 (4) Nr. 5 UStG.

Die Sichtkomponente nichts anderes als eine Übergangskrücke ist, bis die E-Rechnung etabliert wurde. Man sollte sich möglichst schnell von ihr entwöhnen (können).

Es wäre an der Zeit, dass DATEV endlich einfach mal was richtig macht und nicht verbal um ihre Programmunzulänglichkeiten herumzueiern. Ich will jetzt auch nicht zu hart klingen, da das "E-Baby" ja grade auf die Welt gekommen ist und sicherlich noch einigen Anpassungen erfolgen müssen.

Warum man sich von vornherein auf minimalste Schriftgrößen einlässt, die kaum lesbar sind und die Visualiesierung ansonsten "weiße Wüsten" enthält, unterstreicht leider meine Einschätzung.

Für die Programmumgebung sind Sie nicht persönlich verantwortlich; jedoch für das was Sie den Usern mitteilen. edit: Grade gesehen, dass Sie PO sind, womit Ersteres dann doch auch zutrifft.

Das wäre es dann auch von meiner Seite zum Thema. Ihr wisst Bescheid.

[#3]

Sehr geehrter Herr Procelewski,

was ist im Hause Datev eigentlich los? Es ärgert mich langsam wirklich. Ich möchte mich eigentlich mit solchen Marginalien herumschlagen müssen und Zeit in den Foren verbrennen müssen. 

Es wurde wirklich mehrfach deutlich zum Ausdruck gebracht, dass es unsinnig ist, die Visualisierung so wie jetzt im DMS anzubieten, dass es für den Arbeitsalltag notwendig ist, das Klarschrift-Pdf. zuerst anzuzeigen.

Es ist sinnlos, jetzt in den Zeiten knapper Ressourcen bei Ihnen Energie in die Verschlimmbesserung der ersten beiden Visualisierungskomponenten zu stecken, wenn Sie doch nur die Reihenfolge umdrehen müssen oder das Ding einfach abschalten, bis Ihnen etwas besserer einfällt.

Was hindert Sie, den Visualisierer abzuschalten oder abschaltbar zu machen?

Ich verstehe nicht, warum die Datev derartig stur an etwas festhält, das offenbar so niemand haben möchte und nach dem auch keiner gefragt hat.

Sie behindern mich in der täglichen Arbeit durch einen ungefragten Eingriff in meine Handakten.

Sie gehen allerdings erneut auf diesen Punkt nicht wirklich ein. Um es noch einmal deutlich auszudrücken: Bitte sorgen Sie dafür, dass das Pdf. vorne steht oder lassen Sie mir die Wahl, die Visualisierung abzuschalten.

Ich kann aus den Ausführungen "der Datev" nur schließen, dass sie (klein geschrieben) das, was gefordert wird, schlichtweg nicht wollen (Beweggründe sind absolut unklar), oder Ihre Entwickler die Notwendigkeit einfach nicht verstehen. Bitte entschuldigen Sie diese Deutlichkeit, aber mir fehlt hier einfach eine deutliche Positionierung.

Sie führen aus, dass diverse Dinge nicht aufgefallen sind. Dies offenbart eine nicht vorhandene Qualitätskontrolle.

Ich frage mich zudem, wer eigentlich diese berühmten Kunden sind, die Entwürfe immer gutheißen, denen aber die einfachsten Dinge nicht auffallen. 

Bei mir schwindet die Hoffnung, dass sich an den Datev-Produkten irgendetwas verbessert, wenn an den Cloudprodukten in einer derartigen Praxisunkenntnis, fehlender sinnvolle Eigenkreativität, nicht vorhandener Funktions- und Qualitätskontrolle gearbeitet wird und zudem erkannte Fehler nicht ad hoc nachgebessert werden können. 

Das Cloudkonzept wird der Mehrheit aller Nutzer, also den Steuerberatern, wirklich völlig egal sein. Dies ist deshalb so, weil uns nur die Bilder auf dem Bildschirm interessieren, nicht wie sie produziert werden. Das Cloudprogramm ist keine Entschuldigung für Alles und Jedes. 

Wenn Sie in Ihren Konzepten generelle Mängel, so wie jetzt erkennen, müssen Sie diese Sache stoppen und neu überlegen. Die Anzeige von Rechnungen in der Bearbeitung berührt die die Kernaufgaben der Steuerberater. Wenn Sie feststellen, dass Ihre Entwickler schon hierbei gepatzt haben, ist dies notwendig. 

Eine abschließende Anmerkung zu Ihrem Hinweis zu mangelhaften Überleitung ins DMS:

Ich kann es nicht glauben, dass im Jahre 2025 Ihre Abteilungen nicht zusammen arbeiten und die Funktionalitäten übergreifend geprüft werden. Die Vorstände haben doch vor Jahren erklärt, dass dieses Abteilungsdenken bei der Datev als Problem erkannt worden ist und behoben werden soll?

Wie kann es sein, dass die Rechnungen derartig unsinnig im DMS ankommen und dies niemandem auffällt? Warum stoßen Sie dies nicht von sich aus an, denn schließlich betrifft es Ihr Produkt. 

Zum Abschluss ein Screenshot Ihrer Rechnung an uns im Visualisierer:

528 Seiten! Ein Sprungziel zum verwertbaren Teil fehlt. 

Dies offenbart Ihr Problem doch recht anschaulich. 

Mfg. 

stbab1

[#4]

---

Einige Ihrer Fragen habe ich bereits im vorherigen Beitrag beantwortet. Zu den weiteren Fragen:

1. Sichtkomponente einer ZUGFeRD-Rechnung: Diese ist als Anhang in jeder Rechnungsvisualisierung verfügbar. Die Anhänge sind separat im DMS Viewer sichtbar. Es ist lediglich erforderlich, den Anhang "_Sichtkomponente" anzuklicken, anstatt durch die gesamte Rechnung zu scrollen.

---

@Slawomir_Procelewskiich falle gerade vom blauben ab. Unsere Mandanten verwenden für ihre Kundennummern den Nummernkreislauf der Debitorenkonten. Folglich sind Debitorennummer und Kundennummer identisch. Beim Buchen muss somit nur die Kundennummer für das Debitorenkonto erfasst werden.

Jetzt kommen Sie mit der Datenvisualisierung in der Erfassung daher und bieten mir an keiner Stelle der Datenvisualisierung die Kundennummer an, schon garnicht auf der ersten Seite der Datenvisualisierung. Die folge beim buchen ist, ein Griff zur Maus, Klick oben auf Anlagen, Klick auf Sichtkomponente.pdf, Klick auf Erfassungsfeld in Rewe. Und erst jetzt geht die Buchung weiter, wie zu Zeiten ohne E-Rechnung. Bezahlen Sie mir den Mehraufwand durch diese Klickerorgien? Das erfassen einer einziegen Ausgangsrechnung dauert somit ein Vielfaches länger.

Sorgen Sie daher bitte schnellstens dafür, dass der Anwender entscheiden kann ob die Sichtkomponente oder die Datenvisualisierung zuerst angezeigt wird.

Es ist auffallend, dass die Datev für die Datenvisualisierung 6 Seiten benötigt, während die Sichtkomponente.pdf nur 1 Seite braucht um alle Daten wiederzugeben.

Der Zwang zur vorgeschalteten Datenvisualisierung ist nur wieder eine Bevormundung durch die DATEV, schon wieder!

Danke.

[#5]

---

@Slawomir_Procelewski  schrieb:

Schriftgrößen: Wir werden die Schriftgrößen erneut überprüfen.

---

Dumme Frage, aber hat DATEV keine internen Guidelines für Usability? Schriftgrößen kleiner 10pt gehören in Bildschirmanzeigen grundsätzlich verboten, und auch auf Papier sollten sie außerhalb des "Kleingedruckten" nicht vorkommen (selbst da grenzt die Schriftgrößewinze mitunter an Körperverletzung und arglistige Täuschung).

Meiner Meinung nach sollte sämtlicher Text der Visualisierung die gleiche Schriftgröße haben und Hervorhebung ausschließlich über Fettdruck oder Unterstreichung passieren.

[#6]

@StBAB1 528 Seiten unglaublich!

Interessant wäre hier nochmal zu wissen, wie viel Seiten davon Visualisierung und wie viel Seiten die pfd-Sichtkomponente sind.

MfG

A. Boese

[#7]

369 Seiten Visualisierung und 159 Seiten Pdf. 

Die Visualisierung ist unbenutzbar. 

Die Volltextsuche liefert in der Visualisierung Phantomtreffer, d.h. es wird ein Treffer angezeigt, an dem kein Text zu erkennen ist. 

[#8]

Meine Kollegin rief mich gestern Abend noch verzweifelt an. "Die DATEV Rechnung sieht so komisch aus, was ist das? Ich finde da nix! Letzten Monat war alles noch normal."

"Jaaaa, Willkommen in der DATEV-Welt der E-Rechnung." Ich hab ihr dann eine Exceltabelle gezogen. 🤣

[#9]

---

@StBAB1  schrieb:

Die Volltextsuche liefert in der Visualisierung Phantomtreffer, d.h. es wird ein Treffer angezeigt, an dem kein Text zu erkennen ist. 

---

Dazu hatte ich an anderer Stelle schonmal die Vermutung geäußert, dass der Viewer die Seitenzahl des PDF-Teils zurück bekommt, für die Anzeige dann aber vergisst die Visualisierung dazu zu addieren. D.h. die Suche findet auf Seite 34 des PDF den Text, der Viewer springt dann aber zu Seite 34 des Gesamtdokuments statt Seite 403 (369+34).

[#10]

---

@rschoepe  schrieb:

Dazu hatte ich an anderer Stelle schonmal die Vermutung geäußert, dass der Viewer die Seitenzahl des PDF-Teils zurück bekommt, für die Anzeige dann aber vergisst die Visualisierung dazu zu addieren. D.h. die Suche findet auf Seite 34 des PDF den Text, der Viewer springt dann aber zu Seite 34 des Gesamtdokuments statt Seite 403 (369+34).

---

Das deckt sich mit der Erfahrung die ich machen musste, als mir bei einer E-Rechnung die OCR-Erkennung Werte geliefert hat:

@T_Ahmad  schrieb:

Kanzlei Rewe lässt eine OCR Erkennung drüber laufen (ich möchte schreien!!!) und markiert dann auch noch statt auf der Sichtkomponente auf der letzten Seite, die Werte auf der ersten Seite der Visualisierung.

Also nochmal:

Die Daten werden per OCR auf der letzten Seite ausgelesen statt aus dem XML-Datensatz übernommen.

Die übernommenen Daten werden nicht in der Sichtkomponente markiert.

Auf der Höhe, auf der in der Sichtkomponente die übernommenen Werte markiert sein sollten, findet sich in der Visualisierung eine Markierung, welche quasi einen leeren Bereich der Visualisierung hervorhebt.

Der Fehler wurde somit vor mindestens 21 Tagen entdeckt und von den fleißigen Mitlesern der Datev scheinbar nicht wahrgenommen oder nicht weitergegeben. Oder man ist eben so ausgelastet damit, kostenpflichtige Zusatzangebote in der Cloud zu entwickeln, dass einfach keine Zeit geblieben ist um diesen wichtigen, mutmaßlich leicht zu behebenden, Fehler zu beheben.

Das wirft die Frage auf, wer intern die Anwendungen testet und welche Kanzleien an der Pilotierung beteiligt waren. Das was wir hier schlussendlich als "bestmögliche Lösung" bekommen haben, gleicht einem Alptraum. Zwickt mich bitte jemand?

[#11]

Leider wurde bei post bezüglich der Auslesbarkeit der xml-Datei geschlossen.

Der Kardinalfehler ist, sich auf die Visualisierung zu stürzen und die E-Rechnung nicht direkt per xml in Kanzlei-Rewe einzulesen. Ich wäre nie auf die Idee gekommen, dass die Datev dass nicht programmiert, obwohl Herr Lahm ja so toll Werbung dafür macht. Wann kommt das? Kommt das=

Also nochmals: @Datev: Wann kommt die direkte Einlesbarkeit in Kanzlei-Rewe? Kommt diese über ein Vorsystem per Stapelvorschlag o.ä. (Bitte keine Ausführungen mehr zum Viewer, wir haben alles bzgl. E-Rechnungen gestoppt und erfüllen die gesetzlichen Pflichten)! Wir machen uns das Leben als Buchhalter aber nicht schwerer. 

[#12]

Guten Tag @Slawomir_Procelewski 

meine Mitarbeitenden haben nun die ersten echten E-Rechnungen mit dem Viewer gebucht.

Fazit: Die Sichtkomponente vorneweg ist absolut hinderlich, weil nur ein kleiner Teil der tatsächlichen Rechnung auf einen Blick erkennbar ist.

Ein "Klick auf pdf Visualisierung des Rechnungssteller" ist KEINE OPTION, weil jeder Klick den Automatisierungsprozess stoppt und zu Mehrkosten und Mehrzeiten führt. 

Macht das so, das erst die Visualisierung kommt, dann die Sichtkomponente. Alles andere ist keine Option.

Und ich will nicht hören, dass das BMF vorgibt... Das tut es an dieser Stelle nämlich nicht.

[#13]

---

Macht das so, das erst die Visualisierung kommt, dann die Sichtkomponente. Alles andere ist keine Option.

---

Sie meinten das sicher andersrum.

[#14]

Guten Abend @mic,

Sie schreiben:

Jetzt kommen Sie mit der Datenvisualisierung in der Erfassung daher und bieten mir an keiner Stelle der Datenvisualisierung die Kundennummer an, schon garnicht auf der ersten Seite der Datenvisualisierung.

Ich möchte an dieser Stelle nachfragen, ob es sich um eine Rechnung handelt, die mit einer DATEV-Anwendung erstellt wurde. Falls ja, könnten Sie bitte angeben, welche Anwendung genutzt wurde? Laut unseren Tests sollte die Kundennummer (sofern im Datensatz vorhanden) bereits auf der ersten Seite bei den Rechnungsdaten angezeigt werden.

[#15]

---

@T_Ahmad schrieb:Zwickt mich bitte jemand?

---

---

Wir haben Ihren Wunsch nach „Zwicken“ aufgenommen. Leider können wir zum derzeitigen Zeitpunkt keine Aussage darüber treffen, wann eine Umsetzung von „Zwicken“ möglich ist. Da „Zwicken“ generell mit erheblichem Aufwand verbunden ist, wurde es in den Wartungsmodus versetzt. Weitere Neuerungen werden erst mit „Zwicken next“ zu erwarten sein.

Munter bleiben!

[#16]

Die Rechnung wurde mit Lexoffice /Lexware erstellt.

[#17]

---

@mic  schrieb:

Die Rechnung wurde mit Lexoffice /Lexware erstellt.

---

Oh nein, er hat das böse Wort genannt.

[#18]

Oh mein Gott😬  Was habe ich nur getan😰

Mal schauen welches Musikinstrument ich in der Band der Ehemaligen nach dem Ausscheiden hier spielen werde? Vieleicht eine Metallposaune?!

[#19]

Die Rechnung wurde mit Lexoffice /Lexware erstellt.

Vielen Dank für die Information.

Wie bereits erwähnt, basiert unsere Visualisierung auf dem XML-Datensatz. Sind dort bestimmte Informationen nicht enthalten, werden diese auch in der Visualisierung nicht angezeigt, selbst wenn sie in der Sichtkomponente vorhanden sind.

In diesem Zusammenhang ist hier "nur" die Datenqualität von Lexoffice zu kritisieren.

[#20]

---

@Norddeutsch_Gunns  schrieb:

Der Kardinalfehler ist, sich auf die Visualisierung zu stürzen und die E-Rechnung nicht direkt per xml in Kanzlei-Rewe einzulesen. Ich wäre nie auf die Idee gekommen, dass die Datev dass nicht programmiert, obwohl Herr Lahm ja so toll Werbung dafür macht. Wann kommt das? Kommt das=

---

Digitalisierung Made in Germany, oder so. In Duo funktioniert das Auslesen der XML-Werte ohne OCR grandios. Mein "Workaround" ist es derzeit meinen Mandanten großflächig das Überweisen der eigenen Rechnungen über Bank Online (Aus meiner Sicht das einzig zufriedenstellende DATEV-Produkt derzeit, abgesehen von der Verfügbarkeit) via HBCI (weil Geld) anzudrehen. Hat für mich den Vorteil, dass die XML-Werte so den Weg ins Kanzlei-Rewe zu finden scheinen. Ich behaupte fast ich werde schneller allen unseren Mandanten das aufschwätzen, als die Datev uns hier eine brauchbare Lösung bietet.

@Taxprof  schrieb:

Ein "Klick auf pdf Visualisierung des Rechnungssteller" ist KEINE OPTION, weil jeder Klick den Automatisierungsprozess stoppt und zu Mehrkosten und Mehrzeiten führt. 

---

Hier ein paar alternative Lösungsansätze für die Datev:

1. Visualisierung der XML-Daten ohne unnötige Lücken und im 16:9-Format. Mit farblicher Hervorhebung der buchungsrelevanten Daten. Meinetwegen auch einfach als zwei A4-Hochkant-Seiten nebeneinander darstellen, eine mit den Daten die derzeit auf der ersten Seite stehen, die andere mit den Einzelnen Warenpositionen mit Steuerschlüssel.

2. Visualisierung der XML-Daten neben der Sichtkomponente. So wie die an der Seite eingeblendeten OCR-Werte bisher, nur eben etwas breiter.

3. Einrichtung eines Hotkey um zwischen Visualisierung und Sichtkomponente zu wechseln. (STRG + SHIFT + A wäre glaube ich noch frei. A steht hier als Eselsbrücke für "Ach Datev Ach..." Wäre auch einhändig gut zu erreichen.)

@Hauke_Hamann  schrieb:

---

@T_Ahmad schrieb:Zwickt mich bitte jemand?

---

---

Wir haben Ihren Wunsch nach „Zwicken“ aufgenommen. Leider können wir zum derzeitigen Zeitpunkt keine Aussage darüber treffen, wann eine Umsetzung von „Zwicken“ möglich ist. Da „Zwicken“ generell mit erheblichem Aufwand verbunden ist, wurde es in den Wartungsmodus versetzt. Weitere Neuerungen werden erst mit „Zwicken next“ zu erwarten sein.

Munter bleiben!

---

Lass mich raten, ZwickenNext kostet dann mehr Geld als zwicken und altbekannte Features, wie das Stupsen und Piksen, werden nicht implementiert und die Umsetzung dieser auf einen unbestimmten Zeitpunkt in der Zukunft verschoben? 

@Slawomir_Procelewski  schrieb:
In diesem Zusammenhang ist hier "nur" die Datenqualität von Lexoffice zu kritisieren.

---

Ich bin ein sehr großer Kritiker der Buchhaltung-für-Jedermann-Lösung aus dem Hause Haufe, weil das Backend stellenweise erhebliche Mängel aufweist. Aber eines muss man denen lassen: Zumindest schafft man es dort ein schönes Frontend anzubieten, welches an den Bedürfnissen der Anwendern ausgerichtet ist. In Sachen Visualisierung ist man der Datev da um einiges voraus. Vielleicht sollte man da mal zur Konkurrenz schauen und lernen was diese besser macht, anstatt Kritik zu äußern. Zumindest ist der Support bei beiden ähnlich gut.

---

[#21]

@Slawomir_Procelewski  Danke für die Auskunft. Leider tritt das Problem der fehlenden Kundenummer auch bei Rechnungen aus SevDesk auf.

Da das Problem bei zwei verschiedenen Anbietern auftritt, bitte ich die fehlende Kundennummer etwas genauer zu prüfen und nicht lapidar wegzuwischen. Eventuell wird das entsprechende Feld etwas anders bezeichnet. Bei Bedarf nenne ich Ihnen gerne die entsprechenden Datenbestände, damit Sie sich das anschauen können.

Immerhin ist SevDesk nicht das verhasste Lexoffice.

[#22]

Noch eine Stimme für pdf-Rechnung zuerst zusehen und anschließend die Visualisierung.

Bei einem Mandanten wurde in der Visualisierung ein komplett falscher Kreditor angegeben. Da passte so gar nichts übereinander, Adresse / Telefon / Kundennummer... Ohne pdf-Rechnung wäre das echt in die Hose gegangen. Man muss viel mehr aufpassen, was auf einmal im Buchungsvorschlag angezeigt wird. Ein "blindes" Buchen ist gar nicht möglich. Es tut mir leid das so sagen zu müssen, aber vor Einführung der E-Rechnung lag die Treffer Anzahl im Kreditorenbereich hier bei 100%.

Plus: Riesen großes Manko: Kostenstellen (hier Filialbetrieb mit einer Kostenstelle je Filiale) taucht nicht auf der Visualisierung auf. Ebenso wenig wie die Nennung der Filiale. Wie soll das denn bitte laufen??????????

Folge: Visualisierung wird ignoriert und weiterhin nach der pdf-Rechnung gebucht. Ist nicht im Sinne des Erfinders.

Aber... es steckt ja alles noch in den Kinderschuhen (genau wie UO im Jahr 2007). Ich habe Hoffnung, dass sich hier noch etwas tut im Laufe der nächsten Monate.

[#23]

@mic 

Wobei der "Fehler" wohl eher in dem Aufbau des xml Satzes auf Nutzerseite liegen dürfte. Die Rechnung von sevDesk an den Nutzer enthält klar die Kundennummer, wird dann auch im Viewer angezeigt. Und was nicht vorhanden ist kann der Viewer auch nicht anzeigen.

[#24]

---

@sala  schrieb:

Noch eine Stimme für pdf-Rechnung zuerst zusehen und anschließend die Visualisierung.

Bei einem Mandanten wurde in der Visualisierung ein komplett falscher Kreditor angegeben. Da passte so gar nichts übereinander, Adresse / Telefon / Kundennummer... Ohne pdf-Rechnung wäre das echt in die Hose gegangen. Man muss viel mehr aufpassen, was auf einmal im Buchungsvorschlag angezeigt wird. Ein "blindes" Buchen ist gar nicht möglich. Es tut mir leid das so sagen zu müssen, aber vor Einführung der E-Rechnung lag die Treffer Anzahl im Kreditorenbereich hier bei 100%.

Plus: Riesen großes Manko: Kostenstellen (hier Filialbetrieb mit einer Kostenstelle je Filiale) taucht nicht auf der Visualisierung auf. Ebenso wenig wie die Nennung der Filiale. Wie soll das denn bitte laufen??????????

Folge: Visualisierung wird ignoriert und weiterhin nach der pdf-Rechnung gebucht. Ist nicht im Sinne des Erfinders.

Aber... es steckt ja alles noch in den Kinderschuhen (genau wie UO im Jahr 2007). Ich habe Hoffnung, dass sich hier noch etwas tut im Laufe der nächsten Monate.

---

Was steht denn im XML-Datensatz? Ich kann mir nicht vorstellen, dass die Visualisierung hier halluziniert hat, vermutlich stimmen die XML-Daten nicht. In dem Falle die PDF als Grundlage für die Buchung zu verwenden halte ich für nicht vertretbar. 

Als Unternehmer prüfe ich meine eingehenden Rechnungen selbst, was auch beinhaltet die XML-Daten mit der Sichtkomponente abzugleichen. Wenn es hier Abweichungen gibt, liegt keine ordnungsgemäße Rechnung vor und ich halte die Zahlung zurück bis diese korrigiert wurde.

Auf Kanzleiebene muss ich den Mandanten auf derartige Fehler hinweisen. Den Mehraufwand den wir nun haben, da wir für die Mandanten zum Teil die Belege noch prüfen müssen, wird man wohl entsprechend durch höhere Preise decken müssen. Aber das ist Chefsache.

Nach derzeitigem Stand sieht es so aus, dass wir Sachbearbeiter weniger Fälle übernehmen können um die Qualität der Arbeit aufrecht zu erhalten. Zu verdanken haben wir das zu großen Teilen der Datev und ihrem halbgaren Konzept für die E-Rechnung.

[#25]

Hallo @T_Ahmad 

da es hier um ZUGFERD-Rechnungen geht.

Die beschriebenen "Abweichungen" zwischen PDF-Datei und Visualisierung können auch auftreten trotz erfolgreicher Validierung der Rechnung.

Hintergrund sind die für das ZUGFERD-Format möglichen unterschiedlichen Profile.

Eine ZUGFERD-Rechnung, ausgestellt mit dem BASIC-Profil, hat in der Visualisierungskomponente wesentlich weniger Daten als die PDF-Datei.

Eine vollständige inhaltliche Umsetzung wird es wahrscheinlich nur mit dem EXTENDED-Profil geben

Da kann die DATEV nichts dafür, wenn der Aussteller nur das Minimum umgesetzt hat.

Steuerlich korrekt. Die XML-Datei ist eine korrekte Rechnung, zum Buchen benötigen wir dann trotzdem die PDF-Datei. 

Es wäre einerseits von Vorteil, wenn ZUGFERD V. 2.4 die Profile auf zwei zusammenschmelzen würde. Profil EXTENDED und Profil X-Rechnung.

Andererseits ist bei EXTENDED die Visualisierung noch viel umfangreicher, weil es dann ganz viele Leerfelder gibt... 

[#26]

Hallo T_Ahmad, es handelt sich um eine Rechung im ZUGFeRD-Format. Ich habe keine XML zum nachprüfen.

Eine Überprüfung der Rechnungen durch uns ist nicht machbar. Bei dem betreffenden Mandat kommen monatlich mehrere tausend Buchungssätze zusammen wovon ca. die Hälfte Eingangsrechnungen sind. 

Wie gesagt, ich gehe davon aus, dass es sich hier um eine einmalige Ausnahme handelt. Und dass sich in Zukunft im Bereich E-Rechnung noch einiges tun wird.

[#27]

---

@noescher  schrieb:

Hintergrund sind die für das ZUGFERD-Format möglichen unterschiedlichen Profile.

Eine ZUGFERD-Rechnung, ausgestellt mit dem BASIC-Profil, hat in der Visualisierungskomponente wesentlich weniger Daten als die PDF-Datei.

Eine vollständige inhaltliche Umsetzung wird es wahrscheinlich nur mit dem EXTENDED-Profil geben

[...]

Da kann die DATEV nichts dafür, wenn der Aussteller nur das Minimum umgesetzt hat.

Steuerlich korrekt. Die XML-Datei ist eine korrekte Rechnung, zum Buchen benötigen wir dann trotzdem die PDF-Datei. 

---

Soweit so gut. Wenn das BASIC-Profil eingesetzt wurde, enthält der Datensatz keine Adressdaten und diese wären  (falsch) aus der Sichtkomponente gezogen worden. In dem Falle wäre der Fehler ebenfalls bei der DATEV.

Wenn es das EXTENDED-Profil war gibt es zwei Möglichkeiten:

1. Der Datensatz ist falsch bestückt. Fehler beim Rechnungsaussteller.

2. Der Datensatz ist richtig bestückt, wurde aber falsch ausgelesen. Fehler bei der DATEV.

Die Leerfelder im EXTENDED-Profil nicht zu visualisieren sollte selbstverständlich sein. Wenn die Visualisierung das nicht schafft, weiß ich auch nicht weiter. Schocken kann mich aber nichts mehr.

Fakt ist: Die XML-Daten können weniger Umfangreich als die Sichtkomponente sein. Sie dürfen aber keinesfalls inhaltlich von dieser abweichen. Wenn das doch der Fall ist, sind die Daten des XML-Anhangs die korrekte Rechnung. 

Im Fall von Abweichungen zwischen den strukturierten Rechnungsdaten und den sonstigen Informationen gehen die Daten des strukturierten Teils denen der Bilddatei vor. An der grundsätzlichen Zulässigkeit eines hybriden Formats ändert dies aber nichts.

Siehe Randziffer 31 des BMF Schreibens: Ausstellung von Rechnungen nach § 14 UStG; Einführung der obligatorischen elektronischen Rechnung bei Umsätzen zwischen inländischen Unternehmern ab dem 1. Januar 2025

@sala  schrieb:

Hallo T_Ahmad, es handelt sich um eine Rechung im ZUGFeRD-Format. Ich habe keine XML zum nachprüfen.

Eine Überprüfung der Rechnungen durch uns ist nicht machbar. Bei dem betreffenden Mandat kommen monatlich mehrere tausend Buchungssätze zusammen wovon ca. die Hälfte Eingangsrechnungen sind. 

Wie gesagt, ich gehe davon aus, dass es sich hier um eine einmalige Ausnahme handelt. Und dass sich in Zukunft im Bereich E-Rechnung noch einiges tun wird.

---

Wenn keine XML-Daten vorhanden sind, handelt es sich nicht um eine ZUGFeRD-Rechnung.

Der ZUGFeRD-Standard definiert, dass die XML-Datei als Anlage innerhalb einer PDF-Datei vorliegt.

Es gibt keine E-Rechnung ohne strukturierte Daten.

Einfach mal den Beleg speichern, im Adobe Reader öffnen, links auf die Büroklammer und dann die Anlage Faktur-X.xml im Webbrowser öffnen. So sehen die strukturierten Daten ohne Visualisierung aus.

[#28]

Auch auf dem von Ihnen beschriebenen Weg sehe ich in der Anlage nur die Sichtkomponente pdf (genau wie beim Buchen auch). Es mag bei der Übermittlung der Rechnung vom Mandat an mich verloren gegangen sein, das kann ich nicht nachvollziehen. Mir wird beim buchen bzw. in der Belegansicht angezeigt, dass es sich um eine  ZUGFeRD Rechnung handelt.

Da wir uns noch bis mindestens 31.12.2026 im Übergangszeitraum befinden, sehe ich das aktuell noch nicht als allzu kritisch an. Die pdf reicht da noch aus.  

Wie bereits erwähnt, gehe ich davon aus, dass solche Fehler in den nächsten Monaten behoben werden. 

[#29]

---

@sala  schrieb:

Auch auf dem von Ihnen beschriebenen Weg sehe ich in der Anlage nur die Sichtkomponente pdf (genau wie beim Buchen auch). Es mag bei der Übermittlung der Rechnung vom Mandat an mich verloren gegangen sein, das kann ich nicht nachvollziehen. Mir wird beim buchen bzw. in der Belegansicht angezeigt, dass es sich um eine  ZUGFeRD Rechnung handelt.

Da wir uns noch bis mindestens 31.12.2026 im Übergangszeitraum befinden, sehe ich das aktuell noch nicht als allzu kritisch an. Die pdf reicht da noch aus.  

Wie bereits erwähnt, gehe ich davon aus, dass solche Fehler in den nächsten Monaten behoben werden. 

Ohne jetzt wirken zu wollen, päpstlicher als der Papst zu sein:

Bitte das mit dem Übergangszeitraum nicht falsch verstehen: Eine sonstige Rechnung (=einfache PDF) ist aktuell noch zulässig. Wenn jedoch eine E-Rechnung (X-Rechnung oder ZUGFeRD) ausgestellt wird, müssen wir diese auch im Original als solche verarbeiten und archivieren. 

Der XML-Anhang darf keinesfalls auf dem Weg der Übermittlung verloren gehen. Nur die PDF/A-Konforme PDF-Datei mitsamt XML-Anhang ist der Originale Beleg. 

Wenn ich z. B. eine ZUGFeRD-Rechnung speichere indem ich mit dem SkyPDF-Druck eine neue PDF erstelle habe ich eine Rechnungskopie die u. U. nicht mehr zum Vorsteuer-Abzug berechtigt.

Wenn in der Belegansicht angezeigt wird, dass es sich um eine ZUGFeRD-Rechnung handelt dann muss auch der XML-Datensatz vorhanden sein. Alles andere macht keinen Sinn.

Hier zur Veranschaulichung nochmal ein Ausschnitt aus einer Beispielrechnung:

Im Browser geöffnet sieht die enthaltene factur-x.xml dann so aus:

Spoiler

This XML file does not appear to have any style information associated with it. The document tree is shown below.
<rsm:CrossIndustryInvoice xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100" xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100" xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100 ../../../schemas/UN_CEFACT/CrossIndustryInvoice_100pD16B.xsd">
<rsm:ExchangedDocumentContext>
<ram:GuidelineSpecifiedDocumentContextParameter>
<ram:ID>urn:cen.eu:en16931:2017</ram:ID>
</ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>
<rsm:ExchangedDocument>
<ram:ID>2021_10</ram:ID>
<ram:TypeCode>380</ram:TypeCode>
<ram:IssueDateTime>
<udt:DateTimeString format="102">20210924</udt:DateTimeString>
</ram:IssueDateTime>
</rsm:ExchangedDocument>
<rsm:SupplyChainTradeTransaction>
<ram:IncludedSupplyChainTradeLineItem>
<ram:AssociatedDocumentLineDocument>
<ram:LineID>1</ram:LineID>
</ram:AssociatedDocumentLineDocument>
<ram:SpecifiedTradeProduct>
<ram:Name>Project management</ram:Name>
<ram:Description/>
</ram:SpecifiedTradeProduct>
<ram:SpecifiedLineTradeAgreement>
<ram:NetPriceProductTradePrice>
<ram:ChargeAmount>500.000000</ram:ChargeAmount>
</ram:NetPriceProductTradePrice>
</ram:SpecifiedLineTradeAgreement>
<ram:SpecifiedLineTradeDelivery>
<ram:BilledQuantity unitCode="C62">2.00</ram:BilledQuantity>
</ram:SpecifiedLineTradeDelivery>
<ram:SpecifiedLineTradeSettlement>
<ram:ApplicableTradeTax>
<ram:TypeCode>VAT</ram:TypeCode>
<ram:CategoryCode>S</ram:CategoryCode>
<ram:RateApplicablePercent>19.00</ram:RateApplicablePercent>
</ram:ApplicableTradeTax>
<ram:SpecifiedTradeSettlementLineMonetarySummation>
<ram:LineTotalAmount>1000.00</ram:LineTotalAmount>
</ram:SpecifiedTradeSettlementLineMonetarySummation>
</ram:SpecifiedLineTradeSettlement>
</ram:IncludedSupplyChainTradeLineItem>
<ram:IncludedSupplyChainTradeLineItem>
<ram:AssociatedDocumentLineDocument>
<ram:LineID>2</ram:LineID>
</ram:AssociatedDocumentLineDocument>
<ram:SpecifiedTradeProduct>
<ram:Name>Consulting</ram:Name>
<ram:Description/>
</ram:SpecifiedTradeProduct>
<ram:SpecifiedLineTradeAgreement>
<ram:NetPriceProductTradePrice>
<ram:ChargeAmount>40.000000</ram:ChargeAmount>
</ram:NetPriceProductTradePrice>
</ram:SpecifiedLineTradeAgreement>
<ram:SpecifiedLineTradeDelivery>
<ram:BilledQuantity unitCode="C62">5.00</ram:BilledQuantity>
</ram:SpecifiedLineTradeDelivery>
<ram:SpecifiedLineTradeSettlement>
<ram:ApplicableTradeTax>
<ram:TypeCode>VAT</ram:TypeCode>
<ram:CategoryCode>S</ram:CategoryCode>
<ram:RateApplicablePercent>19.00</ram:RateApplicablePercent>
</ram:ApplicableTradeTax>
<ram:SpecifiedTradeSettlementLineMonetarySummation>
<ram:LineTotalAmount>200.00</ram:LineTotalAmount>
</ram:SpecifiedTradeSettlementLineMonetarySummation>
</ram:SpecifiedLineTradeSettlement>
</ram:IncludedSupplyChainTradeLineItem>
<ram:ApplicableHeaderTradeAgreement>
<ram:BuyerReference>139877</ram:BuyerReference>
<ram:SellerTradeParty>
<ram:Name>Webware Internet Solutions GmbH</ram:Name>
<ram:SpecifiedLegalOrganization>
<ram:ID>HRB 15635</ram:ID>
</ram:SpecifiedLegalOrganization>
<ram:DefinedTradeContact>
<ram:PersonName>John Doe</ram:PersonName>
<ram:TelephoneUniversalCommunication>
<ram:CompleteNumber>+49(0)561-560123456</ram:CompleteNumber>
</ram:TelephoneUniversalCommunication>
<ram:EmailURIUniversalCommunication>
<ram:URIID>johndoe@webware24.de</ram:URIID>
</ram:EmailURIUniversalCommunication>
</ram:DefinedTradeContact>
<ram:PostalTradeAddress>
<ram:PostcodeCode>34130</ram:PostcodeCode>
<ram:LineOne>Teichstr. 14-16</ram:LineOne>
<ram:CityName>Kassel</ram:CityName>
<ram:CountryID>DE</ram:CountryID>
</ram:PostalTradeAddress>
<ram:URIUniversalCommunication>
<ram:URIID schemeID="9930">DE279247134</ram:URIID>
</ram:URIUniversalCommunication>
<ram:SpecifiedTaxRegistration>
<ram:ID schemeID="FC">262/481/0918</ram:ID>
</ram:SpecifiedTaxRegistration>
<ram:SpecifiedTaxRegistration>
<ram:ID schemeID="VA">DE279247134</ram:ID>
</ram:SpecifiedTaxRegistration>
</ram:SellerTradeParty>
<ram:BuyerTradeParty>
<ram:Name>Agoratech</ram:Name>
<ram:PostalTradeAddress>
<ram:PostcodeCode>34130</ram:PostcodeCode>
<ram:LineOne>Teichstr. 14-16</ram:LineOne>
<ram:CityName>Kassel</ram:CityName>
<ram:CountryID>DE</ram:CountryID>
</ram:PostalTradeAddress>
<ram:URIUniversalCommunication>
<ram:URIID schemeID="9930">DE319642369</ram:URIID>
</ram:URIUniversalCommunication>
</ram:BuyerTradeParty>
</ram:ApplicableHeaderTradeAgreement>
<ram:ApplicableHeaderTradeDelivery>
<ram:ActualDeliverySupplyChainEvent>
<ram:OccurrenceDateTime>
<udt:DateTimeString format="102">20211101</udt:DateTimeString>
</ram:OccurrenceDateTime>
</ram:ActualDeliverySupplyChainEvent>
</ram:ApplicableHeaderTradeDelivery>
<ram:ApplicableHeaderTradeSettlement>
<ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
<ram:SpecifiedTradeSettlementPaymentMeans>
<ram:TypeCode>42</ram:TypeCode>
<ram:PayeePartyCreditorFinancialAccount>
<ram:IBANID/>
</ram:PayeePartyCreditorFinancialAccount>
<ram:PayeeSpecifiedCreditorFinancialInstitution>
<ram:BICID/>
</ram:PayeeSpecifiedCreditorFinancialInstitution>
</ram:SpecifiedTradeSettlementPaymentMeans>
<ram:ApplicableTradeTax>
<ram:CalculatedAmount>228</ram:CalculatedAmount>
<ram:TypeCode>VAT</ram:TypeCode>
<ram:BasisAmount>1200</ram:BasisAmount>
<ram:CategoryCode>S</ram:CategoryCode>
<ram:RateApplicablePercent>19.00</ram:RateApplicablePercent>
</ram:ApplicableTradeTax>
<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
<ram:LineTotalAmount>1200</ram:LineTotalAmount>
<ram:ChargeTotalAmount>0</ram:ChargeTotalAmount>
<ram:AllowanceTotalAmount>0</ram:AllowanceTotalAmount>
<ram:TaxBasisTotalAmount>1200.00</ram:TaxBasisTotalAmount>
<ram:TaxTotalAmount currencyID="EUR">228.00</ram:TaxTotalAmount>
<ram:GrandTotalAmount>1428.00</ram:GrandTotalAmount>
<ram:TotalPrepaidAmount>0.00</ram:TotalPrepaidAmount>
<ram:DuePayableAmount>1428.00</ram:DuePayableAmount>
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>
</ram:ApplicableHeaderTradeSettlement>
</rsm:SupplyChainTradeTransaction>
</rsm:CrossIndustryInvoice>

Bild sicherheitshalber unkenntlich gemacht durch @Sarah_Reitzmann 

[#30]

---

Hier zur Veranschaulichung nochmal ein Ausschnitt aus einer Beispielrechnung:

Spoiler

---

So in der Theorie, ich habe heute eine Rechnung bekommen als PDF (PDF/A-Standard) und in der Mail hing eine xml.Datei mit dran.

Also nicht eingebettet. Schön getrennt.

Wie oder was lade ich nun in DUO hoch? Nur eins von Beiden, beide Versionen?

Bild sicherheitshalber unkenntlich gemacht durch @Sarah_Reitzmann